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

[Sittampalam, Ganesh]

Mitar wrote:
> Hi!
> 
> On Thu, Sep 23, 2010 at 2:19 PM, Christian Maeder
> <Christian.Maeder at dfki.de> 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
concisely:

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

Ganesh

=============================================================================== 
Please access the attached hyperlink for an important electronic communications disclaimer: 
http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html 
===============================================================================