-----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-----