MonadFail proposal (MFP): Moving fail out of Monad

[Edward Kmett]

I can give a couple of "rather academic" issues that the status quo causes:

An example of where this has bit us in the hindquarters in the past is that
the old Error class based instance for Monad (Either a) from the mtl
incurred a constraint on the entire Monad instance in order to support
'fail'.

This ruled out many applications for the Either monad, e.g. apo/gapo are
based on the real (Either e) monad, just as para/zygo are based on the
"real" ((,) e) comonad. This rather complicated the use of recursion
schemes and in fact was what drove me to write what turned into the
"either" package in the first place.

Now we don't try to support 'fail' at all for that Monad. Under this
proposal though, one _could_ add a MonadFail instance that incurred a
rather ad hoc constraint on the left hand side of the sum without
encumbering the Monad itself.

In general you have no way of knowing that you stick to the product-like
structure of the Monad in the current ecosystem, because 'fail' is always
there, you can get to values in the Monad you couldn't reach with just
return and (>>=).

Ideally you'd have (forall m. Monad m => m a) being isomorphic to a, this
can be useful for ensuring we can plumb user-defined effects through code:

http://comonad.com/reader/2011/searching-infinity/

but in Haskell as it exists today you always have to worry about it
invoking a call to fail, and having a special form of _distinguishable_
bottom available from that computation so it is really more like `Either
String a`.

Can you just say "don't do that?"

Sure, but it is the moral equivalent of programming with nulls all over
your code.

-Edward

On Wed, Jun 10, 2015 at 12:26 AM, Johan Tibell <johan.tibell at gmail.com>
wrote:

> Thanks for putting this together.
>
> The proposal says:
>
> "As a consequence, in current Haskell, you can not use Monad-polymorphic
> code safely, because although it claims to work for all Monads, it might
> just crash on you. This kind of implicit non-totality baked into the class
> is terrible."
>
> Is this actually a problem in practice? Is there any code we can point to
> that suffers because of the current state of affairs? Could it be included
> in the proposal?
>
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20150610/6ec7fef7/attachment-0001.html>