On 2012-01-24 05:32, Michael Snoyman wrote:
On Fri, Jan 20, 2012 at 6:52 AM, Michael Snoymanmich...@snoyman.com 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:
On Fri, Jan 20, 2012 at 6:52 AM, Michael Snoyman mich...@snoyman.com wrote:
On Fri, Jan 20, 2012 at 6:41 AM, Edward Z. Yang ezy...@mit.edu 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]
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 (a,b)
On Jan 20, 2012, at 1:40 AM, Michael Snoyman wrote:
On Jan 20, 2012 8:31 AM, John Meacham j...@repetae.net 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
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:
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
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
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,
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
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 ::
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
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 add
On Thu, Jan 19, 2012 at 10:43 PM, Gregory Crosswhite
gcrosswh...@gmail.com 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
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 ezy...@mit.edu wrote:
Oh, I'm sorry! On a closer reading of your message, you're asking not
only asking why
On Fri, Jan 20, 2012 at 6:41 AM, Edward Z. Yang ezy...@mit.edu 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
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
On Thu, Jan 19, 2012 at 8:53 PM, Edward Z. Yang ezy...@mit.edu 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
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. Instead, we
On Jan 20, 2012 8:31 AM, John Meacham j...@repetae.net 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 warnings!
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 --- say,
On Thu, Jan 19, 2012 at 11:11 PM, Dan Doel dan.d...@gmail.com 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
On Fri, Jan 20 2012 at 06:22 +0100, Evan Laforge wrote:
On Thu, Jan 19, 2012 at 8:53 PM, Edward Z. Yang ezy...@mit.edu 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
22 matches
Mail list logo