[Haskell-cafe] Why were unfailable patterns removed and "fail" added to Monad?
Michael Snoyman
michael at snoyman.com
Fri Jan 20 05:29:59 CET 2012
On Fri, Jan 20, 2012 at 5:23 AM, Edward Z. Yang <ezyang at mit.edu> 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) 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 an extra constructor to a single-constructor type
> then pattern matches on the original constructor suddenly become
> failable
>
> (b) is a real killer: suppose that you want to add a new constructor and
> fix all of the places where you assumed there was only one constructor.
> The compiler needs to emit warnings in this case, and not silently transform
> these into failable patterns handled by MonadZero...
But wait a second... this is exactly the situation we have today!
Suppose I write some code:
data MyType = Foo
test myType = do
Foo <- myType
return ()
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 guaranteed that it *never* will. This has
actually been something that bothers me a lot. Whereas everywhere else
in my pattern matching code, the compiler can make sure I didn't make
some stupid mistake, in do-notation I can suddenly get a runtime
error.
My opinion is we should either reinstate the MonadZero constraint, or
simply can failable pattern matches.
Michael
More information about the Haskell-Cafe
mailing list