MonadFail proposal (MFP): Moving fail out of Monad

[David Luposchainsky]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 09.06.2015 23:56, Henning Thielemann wrote:
> You think about making MonadFail a subclass of Applicative where the name 
> MonadFail becomes misleading - how about naming it Fail instead?

I discussed this with Herbert a bit already. The problem with the name "Fail" is
that, if Monad being superclasses of it, hides the fact that there is such a
Monad constraint. Instead, the user has to know that Fail happens to be a
subclass of Monad, and the Monad part is probably the most important thing in the
type, not that there might be some failable pattern somewhere. The name MonadFail
solves this issue by containing "Monad" in its name, but the price we pay for
that is the awkwardness if we relax the superclass.

> We should clearly decide what "fail" is intended for - for programming errors
>  or for exceptions. I guess that people want to use it in the second sense, 
> e.g. something like "guard" driven by a pattern match in the Maybe or list 
> monad. But then "fail" must not have an argument because what user related 
> information can the compiler add automatically? Instead of removing the
> String argument from "fail", the compiler could simply call "mzero" instead.

mzero is only available in MonadPlus, which we want to be independent of
MonadFail. I don't see a way to accomplish this goal without adding more
complicated desugaring rules.

> If we want to use "fail" for exceptions then it would be also ok for parser 
> libraries to use it for parser failures. Nonetheless they might be better 
> served with an Except-like monad where they can choose more specific types
> for the exception messages, e.g. parser errors with source location.  But
> using "mzero" instead of "fail" for monadic pattern matches would alter the
> proposal considerably. Using "mzero" requires a monad with "mplus" and for
> support of monads with "mzero" but no "mplus" we need to split MonadPlus,
> too.

> In summary I think that the cleanest solution would be to phase out "fail" 
> completely in the long run.

If we desugar to anything but simply >>=, we're in a realm of mixups already.
Splitting MonadPlus would be quite an effort, and I don't think it would be worth it.

I agree that <- should desugar straight to >>=. I have not considered removing
the fail desugaring altogether, but I have no idea how much code that would
break. The build logs I posted show roughly 100 Maybe/List invocations with
failable patterns, but we should also not forget about all the explicit "fail"
calls that libraries might do.
All things considered, I don't think we're ready for (judging) this, but maybe we
can revisit the issue some day and simply deprecate MonadFail; in that sense,
we're not going in the wrong direction right now at least.

Greetings,
David/quchen
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBAgAGBQJVd2bNAAoJELrQsaT5WQUsCOMH/0e73pZbXH8r98RpgB4sRU33
ZMZwmkA2wPA5nN996E+cqDmkbCm2qj+O0X3nVkdsM7qi+oRnubnlKWTe+YpPnBsP
in1GGwo9eSry7z4Qyw6ZVIeRXufrjQrze+zQH+dBG/O6Qrrze+t9w9YGAWJxDMVa
KcBdpd4gRXHZH6y0aXEK1eyroIF1k7XVrK4XVyI+WYu2JjpTHWLjaCBzDVS0+PXU
mnTbnA0CrLpGrjCdSiIBeU4ezc57Sn3aNy5gKlZNIchTV81Q/5y5wGE6t/V9wqz4
2fTohs4GWhyjCjLnr6NXWSQDtJN8CUQOadgz9qYnyGOawrKjWQND/ybi3zWE2ZY=
=1hmy
-----END PGP SIGNATURE-----