MonadFail proposal (MFP): Moving fail out of Monad

Erik Hesselink hesselink at
Wed Jun 10 12:21:12 UTC 2015

On Wed, Jun 10, 2015 at 2:14 PM, Johan Tibell <johan.tibell at> wrote:
> On Wed, Jun 10, 2015 at 1:46 PM, Roman Cheplyaka <roma at> wrote:
>> On 10/06/15 14:22, Johan Tibell wrote:
>> > On Wed, Jun 10, 2015 at 12:42 AM, David Luposchainsky
>> > <dluposchainsky at <mailto:dluposchainsky at>>
>> > wrote:
>> >
>> >     I think there are two important consequences of MonadFail. First of
>> >     all, we can
>> >     all safely write failable patterns if we so desire. Second, the
>> >     compiler can
>> >     ensure other people's codebases do not lie to us (knowingly or
>> >     unknowingly).
>> >
>> >
>> > The second is a bit overstated I think. Any function you call can still
>> > have partial pattern matches in all the other places Haskell allows them
>> > and you wouldn't know from the type.
>> For most of them, at least you get a warning from GHC (not for patterns
>> inside lambda, sadly, although that should be fixable). But for
>> do
>>   Just x <- a
>>   ...
>> it's not possible in principle to give a warning, because it's not clear
>> whether the implicit call to fail is intended.
> That's a good point. An alternative to changing fail would to add a warning
> for partial matches even in do-notation.

That would be an improvement, but only a small one. You'd have to turn
off the warning if you really meant to use fail, and then if you
changed the monad you're using, or you're writing a polymorphic
function, nothing will warn you.

I'm +1 on this change. The plan looks thorough, minimizing breakage.
It'll bring many advantages. For example, I'll feel much safer when I
use functions like time's parseTimeM, to give a concrete example.



More information about the ghc-devs mailing list