(Original MFP: https://github.com/quchen/articles/blob/master/monad_fail.md)
A week has passed since I posted the MFP, and the initial discussion is mostly over. Here are my observations:
- Everyone agrees that
fail
should not be inMonad
. - Almost everyone agrees that it should be thrown out of it.
- Some would prefer to see the special desugaring be gone entirely.
- The name
MonadFail
is controversial, because of a potentialApplicative
constraint. - We're still unsure about whether
IO
should get aMonadFail
instance, but the bias seems to be towards "yes".
Johann suggested an optional warning whenever something desugars to use fail
.
I think that's an idea we should think about. It is easily implemented in the
compiler, and would probably behave similar to -fwarn-unused-do-binds in
practice: notation that is not wrong, but might not be what the programmer
intended.
Henning is concerned about the confusion between exceptions and programming errors. In his words,
We should clearly decide what "fail" is intended for - for programming errors or for exceptions.
What I see clashing with his point is backwards compatibility. Removing the
String
argument breaks all explicit invocations of fail
. Unfortunately,
we're not in a position to break very much. If someone has a better idea I'd
love to hear about it though.
ApplicativeDo is somewhere out there on the horizon, and we're not sure yet how
much fail
makes sense in the context of Applicative
. An Applicative
computation is statically determined in its shape, so it either always or never
fails. Depending on previous results would introduce the Monad
constraint
anyway.
Henning has started to look at the impact of the proposal when explicit
invocations of fail
are considered as well, something I have not done in my
original survey. Luckily, things don't look too bad, Lens and its forest of
dependencies can be fixed in around ten trivial changes, for example.
Greetings, David/quchen