broken Monad Either instance?

Isaac Dupree ml at
Tue Nov 29 00:26:47 CET 2011

On 11/28/2011 05:32 PM, Jake McArthur wrote:
> On Mon, Nov 28, 2011 at 2:47 PM, Bas van Dijk<v.dijk.bas at>  wrote:
>> 4) Only give do-expressions with pattern bindings with uncomplete
>> patterns a MonadFail constraint.
>> To me 2, 3 and 4 seem fishy. I like 1 a lot but I'm unsure how many
>> programs will break because of it.
> Number 4 is the one I had in mind. The basic rule would be that if the
> pattern is refutable (that is, not irrefutable as defined by section
> 3.17.2 in the Haskell 2010 report) then MonadFail is required.

That seems like a fishy rule for the purpose.

Refutable: (a, b)
Irrefutable: a
Refutable patterns are those which immediately fail if the value bound 
is ⊥ (bottom). [1]

If the value is ⊥ for a refutable monadic pattern, MonadFail can't do 
anything about this. An imprecise exception will be thrown.  No 
exceptions.(pun horribly intended[2]).

And I don't think we can tweak the suggested rule to allow 
single-constructor 'data' (which we know would never be able to call 
"fail" via pattern) if we want it also to behave exactly as nicely as 
we'd like for all GADTs.  Argh.

I suppose we could make a keyword 'fdo', generating type MonadFail, like 
'mdo' generates MonadFix...
(or actually we switched to "do { rec }" rather than "mdo" [3]... so.)


H2010 says, as you cited, "It is sometimes helpful to distinguish two 
kinds of patterns. Matching an irrefutable pattern is non-strict: the 
pattern matches even if the value to be matched is ⊥. Matching a 
refutable pattern is strict: if the value to be matched is ⊥ the match 
diverges. The irrefutable patterns are as follows: a variable, a 
wildcard, N apat where N is a constructor defined by newtype and apat is 
irrefutable (see Section 4.2.3), var at apat where apat is irrefutable, or 
of the form ~apat (whether or not apat is irrefutable). All other 
patterns are refutable."

[2] ...and not quite accurate because nontermination is also a ⊥.  But I 
couldn't resist.


More information about the Libraries mailing list