Non-exhaustive pattern match(es) warning in lambda functions

Sittampalam, Ganesh ganesh.sittampalam at
Wed Nov 17 05:52:52 EST 2010

Mitar wrote:
> Hi!
> On Thu, Sep 23, 2010 at 2:19 PM, Christian Maeder
> <Christian.Maeder at> wrote: 
>> I tend to introduce artificial error cases for "the Impossible", to
>> avoid warnings, although the compiler generated error messages are
>> better to locate the problem.
> But this is often problematic. I was also doing that a lot. For
> example, having something like: 
> data Foo = Foo1 | Foo2 | Foo3
> and than code:
> case f of
>   Foo -> doSomething
>   _     -> undefined -- impossible
> The problem is that if you extend later on Foo data type with for
> example Foo4 you are not warned that maybe you should also check this
> part of the code for possible changes (and maybe not impossible
> situation anymore). Because I like this best with strict typing. That
> if I change some type compiler warns me of all places in the code I
> have to update things.     
> So then I have this problem between wanting type system to help me
> but also wanting that it does not warn if there is no reason for
> that.  
> I could of course write all cases out. But this gets tedious with such
> functions:
> bar :: Foo -> Foo -> Foo -> Foo
> where only bar Foo1 Foo2 Foo3 is possible, but you have to write out
> all combinations, if you want it to warn you when you add additional
> constructor do Foo data type.  

If GHC added support "or" patterns, you could write them out quite

bar Foo1 Foo2 Foo3 = ...
bar (Foo1|Foo2|Foo3) (Foo1|Foo2|Foo3) (Foo1|Foo2|Foo3) = error "..."


Please access the attached hyperlink for an important electronic communications disclaimer: 

More information about the Glasgow-haskell-users mailing list