[Haskell-cafe] Do we need Monad fail (or MonadFail)?

[Jonathan Geddes]

I'd love for the compiler to give an error (or maybe just a warning)
in the case that I have a pattern match in a monad that just blows up
(throws an exception) on a pattern match failure.

Currently there's no way to know the behavior of failed pattern match
failures without looking at the instance for the current monad. And
what if you're writing "monad agnostic" (higher-order polymorphism?)
code?

If there were a MonadFail class, you could explicitly codify that you
expect a monad to NOT crash your program in the case of a pattern
match.

For example:

someFunction :: (MonadState m, MonadFail m) => a -> m a
someFunction arg = do
    [x,y,z] <- action arg
    return z

Of course one of the "laws" for MonadFail would be that fail never
throws an exception. The compiler couldn't exactly enforce it, but
we're used to expecting sane instances that obey laws. I think IO
would be the exception (no pun intended) to this and be an instance of
MonadFail, but just throw an exception on fail. Since you can only
catch exceptions in the IO monad, this sounds reasonable to me.

--Jonathan

On Tue, Dec 21, 2010 at 2:49 AM, John Smith <voldermort at hotmail.com> wrote:
> Monads seem to use fail in one of three ways:
>
> -Regular monads leave it at the default definition of error
> -MonadPlus sometimes redefines it to mzero
> -IO redefines it to failIO
>
> Are there any other definitions of fail? If not, does the special case of IO
> really need a class-level definition, or could there be another way of
> dealing with failed pattern matches?
>
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>