Re: MonadFail proposal (MFP): Moving fail out of Monad

You could handle that case explicitly by giving a class that converted a string into e and putting that constraint on the MonadFail instance for Either: class Error a where strMsg :: String -> a instance Error e => MonadFail (Either e) where fail = Left . strMsg We used to do this in the mtl, with the Error class, but it then had to encumber the entire Monad, so even folks who didn't want it needed to supply a garbage instance. Right now, fail for Either is necessarily _error_ because we can't put it in the left side without incurring a constraint on every user of the monad. At least here the ad hoc construction can be offloaded to the particular MonadFail instance, or to whatever monad someone makes up for working with their Either-like construction. -Edward On Wed, Jun 10, 2015 at 5:44 PM, David Feuer wrote:

My main concern, I suppose, is that I don't see a way (without extensions) to deal with even the most basic interesting failure monad: Either e. It therefore seems really only to be suitable for pattern match failure and user-generated IOErrors, which don't really strike me as terribly natural bedfellows.

...

This would require you to add MPTCs to the language standard, which means standardizing how they work.

Any solution involving SomeException or any of its variants is going to drag in GADTs, Typeable, higher rank types.

... and it would drag them inexorably into the Prelude, not just base.

Compared to a simple

class Monad m => MonadFail m where fail :: String -> m a

that is a very hard sell!

On the other hand, I do think what we could do is add more information about pattern match failures by adding another member to the class

class Monad m => MonadFail m where patternMatchFailure :: Location -> String -> whatever else you like -> m a patternMatchFailure l s ... = fail (code to generate the string we generate in the compiler using just the parts we're passed)

fail :: String -> m a

Then the existing 'fail' desugaring could be done in terms of this additional member and its default implementation.

This remains entirely in the "small" subset of Haskell that is well behaved. It doesn't change if we go and radically redefine the way the exception hierarchy works, and it doesn't require a ton of standardization effort.

Now if we want to make the fail instance for IO or other MonadThrow instances package up the patternMatchFailure and throw it in an exception we have the freedom, but we're avoid locking ourselves in to actually

On Wed, Jun 10, 2015 at 10:55 AM, Edward Kmett wrote: trying to

...

figure out how to standardize all of the particulars of the exception machinery into the language standard.

-Edward

On Wed, Jun 10, 2015 at 4:19 PM, David Feuer wrote:

...

Here's a crazy question: would a version of MonadError without the fundep do the trick?

class Monad m => MonadFail e m where fail :: e -> m a

instance MonadFail a [] where fail = const []

instance (a ~ e) => MonadFail e (Either a) where fail = Left

instance MonadFail SomeException IO where fail = throwIO instance MonadFail IOException IO where fail = throwIO ... instance MonadFail String IO where fail = throwIO . userError

On Wed, Jun 10, 2015 at 8:32 AM, Mario Blažević wrote:

...

+1 from me.

A minor nitpick: the proposal should clarify which of the existing instances of Monad from base get a MonadFail instance. My

understanding

...

...

is that none of them would define fail = error, but that has not been made explicit.

_______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

---

Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries