Am 22.09.2010 18:05, schrieb Simon Peyton-Jones:

Good point. Simon and I have decided we agree. I'll push a patch shortly.

For patterns in left hand sides (lhs) of let or where also no warnings are issued. data Foo = Bar Int | Baz test3 :: Foo -> Int test3 x = let Bar i = x in i Will or should these cases be covered, too? Cheers Christian

S

| -----Original Message----- | From: glasgow-haskell-users-bounces@haskell.org [mailto:glasgow-haskell- | users-bounces@haskell.org] On Behalf Of Mitar | Sent: 21 September 2010 07:44 | To: glasgow-haskell-users | Subject: Non-exhaustive pattern match(es) warning in lambda functions | | Hi! | | Why GHC does not warn (with -Wall) about non-exhaustive pattern | match(es) warning in lambda functions? For example, this code: | | data Foo = Bar | Baz | | test1 :: Foo -> IO () | test1 Bar = return () -- Pattern match(es) are non-exhaustive warning, OK | | test2 :: Foo -> IO () | test2 = \Bar -> return () -- No pattern match(es) are non-exhaustive, BAD | | I think it would be quite useful to also catch such situations and | issue a warning. | | | Mitar | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users@haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

_______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Am 23.09.2010 10:40, schrieb Simon Peyton-Jones:

| For patterns in left hand sides (lhs) of let or where also no warnings | are issued. | | data Foo = Bar Int | Baz | | test3 :: Foo -> Int | test3 x = let Bar i = x in i | | Will or should these cases be covered, too?

No, I don't plan to warn about these, which is the case at present. It's quite common to have let-bindings that are only used sometimes, eg

f xs | null xs = blah | otherwise = x+1 where (x:_) = xs

I use this a lot.

There are two things that compete: 1. Get warnings (or information) about possible pattern match errors 2. Writing -Wall clean code I suppose I can write: test2 = \ ~Bar -> return () to avoid the warning. But this style should not be encouraged. 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. Clearly calling "head" or "tail" should not issue warnings, because you have been warned when defining them (ignoring that someone else compiled the Prelude for you). You are also not warned when introducing partial field selectors, though. (But for a data type with more than one variant it would more interesting to now, if a selector happens to be total.) C.

| | Cheers Christian | | > | > S | > | > | -----Original Message----- | > | From: glasgow-haskell-users-bounces@haskell.org [mailto:glasgow-haskell- | > | users-bounces@haskell.org] On Behalf Of Mitar | > | Sent: 21 September 2010 07:44 | > | To: glasgow-haskell-users | > | Subject: Non-exhaustive pattern match(es) warning in lambda functions | > | | > | Hi! | > | | > | Why GHC does not warn (with -Wall) about non-exhaustive pattern | > | match(es) warning in lambda functions? For example, this code: | > | | > | data Foo = Bar | Baz | > | | > | test1 :: Foo -> IO () | > | test1 Bar = return () -- Pattern match(es) are non-exhaustive warning, OK | > | | > | test2 :: Foo -> IO () | > | test2 = \Bar -> return () -- No pattern match(es) are non-exhaustive, BAD | > | | > | I think it would be quite useful to also catch such situations and | > | issue a warning. | > | | > | | > | Mitar

Mitar wrote:

Hi!

On Thu, Sep 23, 2010 at 2:19 PM, Christian Maeder 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 ===============================================================================

What was the name of the flag for ghc-7.0.1? I did not find it in the documentation. -fwarn-incomplete-patterns does not work for my lambda expressions. Cheers Christian Am 22.09.2010 18:05, schrieb Simon Peyton-Jones:

Good point. Simon and I have decided we agree. I'll push a patch shortly.

S

| -----Original Message----- | From: glasgow-haskell-users-bounces@haskell.org [mailto:glasgow-haskell- | users-bounces@haskell.org] On Behalf Of Mitar | Sent: 21 September 2010 07:44 | To: glasgow-haskell-users | Subject: Non-exhaustive pattern match(es) warning in lambda functions | | Hi! | | Why GHC does not warn (with -Wall) about non-exhaustive pattern | match(es) warning in lambda functions? For example, this code: | | data Foo = Bar | Baz | | test1 :: Foo -> IO () | test1 Bar = return () -- Pattern match(es) are non-exhaustive warning, OK | | test2 :: Foo -> IO () | test2 = \Bar -> return () -- No pattern match(es) are non-exhaustive, BAD | | I think it would be quite useful to also catch such situations and | issue a warning. | | | Mitar