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@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@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe