Non-exhaustive pattern match(es) warning in lambda functions
ganesh.sittampalam at credit-suisse.com
Wed Nov 17 05:52:52 EST 2010
> 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
> I could of course write all cases out. But this gets tedious with such
> 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