On 2012-01-24 05:32, Michael Snoyman wrote:
On Fri, Jan 20, 2012 at 6:52 AM, Michael Snoyman wrote:
provide an extra warning flag (turned on by -Wall) that will
>> warn when you match on a failable pattern.
I've filed a feature request for this warning:
http://hackage.haskell.org/trac/ghc/ti
On Fri, Jan 20, 2012 at 6:52 AM, Michael Snoyman wrote:
> On Fri, Jan 20, 2012 at 6:41 AM, Edward Z. Yang wrote:
>> Aw, that is really suboptimal. Have you filed a bug?
>
> I think it's a feature, not a bug. When dealing with monads that
> provide nice[1] implementations of `fail`, you can (ab)u
On 20/01/2012 03:23, Edward Z. Yang wrote:
> Oh, I'm sorry! On a closer reading of your message, you're asking not
> only asking why 'fail' was added to Monad, but why unfailable patterns
> were removed.
>
> Well, from the message linked:
>
> In Haskell 1.4 g would not be in MonadZero because
I don't currently have anything to add to this discussion, but I want to
encourage you all to keep having it because I think it has potential to
improve the language in the "do things right or don't do them at all"
philosophy that Haskell tends towards.
-- ryan
On Fri, Jan 20, 2012 at 6:32 AM,
On 19/01/2012 10:19 PM, Edward Z. Yang wrote:
In other words,
MonadZero has no place in dealing with pattern match failure!
I completely agree. See "Bimonadic semantics for basic pattern matching
calculi" [1] for an exploration of just that. In the language of that
paper, the issue is that
On 2012-01-19 23:52, Michael Snoyman wrote:
maybe I should file a feature request: provide an extra warning
flag (turned on by -Wall) that will warn when you match on a failable
pattern.
I fully agree if it's IO, so that a failed pattern match leads to an
exception. The "nice" implementations
Actually, that's not what this conversation is about - it's about what to with
those types of bindings instead of the way 1.4 had been doing it.
On Jan 19, 2012, at 10:19 PM, Edward Z. Yang wrote:
> Hello Gregory,
>
> The original (1998!) conversation can be found here:
>
>http://www.mail-
On Jan 20, 2012, at 1:40 AM, Michael Snoyman wrote:
> On Jan 20, 2012 8:31 AM, "John Meacham" wrote:
> >
> > > As expected, no warnings. But if I change this "unfailable" code above
> > > to the following failable version:
> > >
> > >data MyType = Foo | Bar
> > >
> > >test myType = do
> >
On Fri, Jan 20 2012 at 06:22 +0100, Evan Laforge wrote:
> On Thu, Jan 19, 2012 at 8:53 PM, Edward Z. Yang wrote:
>> It's not obvious that this should be turned on by -Wall, since
>> you would also trigger errors on uses like:
>>
>> [ x | Just x <- xs ]
> [...]
> I would have suggested that li
On Thu, Jan 19, 2012 at 11:11 PM, Dan Doel wrote:
> No, this is not correct. Unfailable patterns were specified in Haskell
> 1.4 (or, they were called "failure-free" there; they likely existed
> earlier, too, but I'll leave the research to people who are
> interested). They were "new" in the sense
On 01/20/12 14:52, Michael Snoyman wrote:
> Essentially, I would want:
>
> SomeConstr args <- someAction
>
> to be interpreted as:
>
> temp <- someAction
> case temp of
> SomeConstr args ->
I completely agree; perhaps what we really want though is something
more akin to a language extension -
On Jan 20, 2012 8:31 AM, "John Meacham" wrote:
>
> > As expected, no warnings. But if I change this "unfailable" code above
> > to the following failable version:
> >
> >data MyType = Foo | Bar
> >
> >test myType = do
> >Foo <- myType
> >return ()
> >
> > I *still* get no w
> As expected, no warnings. But if I change this "unfailable" code above
> to the following failable version:
>
> data MyType = Foo | Bar
>
> test myType = do
> Foo <- myType
> return ()
>
> I *still* get no warnings! We didn't make sure the compiler spits out
> warnings. Instea
On Thu, Jan 19, 2012 at 8:53 PM, Edward Z. Yang wrote:
> It's not obvious that this should be turned on by -Wall, since
> you would also trigger errors on uses like:
>
> [ x | Just x <- xs ]
I was going to say, perhaps refutable matches were considered
important was because back then list and
It's not obvious that this should be turned on by -Wall, since
you would also trigger errors on uses like:
[ x | Just x <- xs ]
T_T
But I do think it ought to be an option.
Cheers,
Edward
Excerpts from Michael Snoyman's message of Thu Jan 19 23:52:10 -0500 2012:
> On Fri, Jan 20, 2012 at 6
On Fri, Jan 20, 2012 at 6:41 AM, Edward Z. Yang wrote:
> Aw, that is really suboptimal. Have you filed a bug?
I think it's a feature, not a bug. When dealing with monads that
provide nice[1] implementations of `fail`, you can (ab)use this to
avoid writing a bunch of case expressions. I remember
Aw, that is really suboptimal. Have you filed a bug?
Edward
Excerpts from Michael Snoyman's message of Thu Jan 19 23:29:59 -0500 2012:
> On Fri, Jan 20, 2012 at 5:23 AM, Edward Z. Yang wrote:
> > Oh, I'm sorry! On a closer reading of your message, you're asking not
> > only asking why 'fail' wa
On Fri, Jan 20, 2012 at 5:23 AM, Edward Z. Yang wrote:
> Oh, I'm sorry! On a closer reading of your message, you're asking not
> only asking why 'fail' was added to Monad, but why unfailable patterns
> were removed.
>
> Well, from the message linked:
>
> In Haskell 1.4 g would not be in MonadZe
On Thu, Jan 19, 2012 at 10:43 PM, Gregory Crosswhite
wrote:
> first, that the notion of "unfailable" was not removed from the language
> so much as not added in the first place
No, this is not correct. Unfailable patterns were specified in Haskell
1.4 (or, they were called "failure-free" there; t
On 01/20/12 13:23, Edward Z. Yang wrote:
> In Haskell 1.4 g would not be in MonadZero because (a,b) is unfailable
> (it can't fail to match). But the Haskell 1.4 story is unattractive
> becuase
> a) we have to introduce the (new) concept of unfailable
> b) if you a
Oh, I'm sorry! On a closer reading of your message, you're asking not
only asking why 'fail' was added to Monad, but why unfailable patterns
were removed.
Well, from the message linked:
In Haskell 1.4 g would not be in MonadZero because (a,b) is unfailable
(it can't fail to match). But t
Hello Gregory,
The original (1998!) conversation can be found here:
http://www.mail-archive.com/haskell@haskell.org/msg03002.html
I think Simon Peyton-Jones' example really sums up the whole issue:
But [MonadZero] really sticks in my craw. How can we explain this:
f :: Mon
Today I learned (tldr; TIL) that the "fail" in the Monad class was added
as a hack to deal with the consequences of the decision to remove
"unfailable" patterns from the language. I will attempt to describe the
story as I have picked it up from reading around, but please feel free
to correct me on
23 matches
Mail list logo
