Clinton:

when the programmer knows that "myDictionary" doesn't contain any empty strings (perhaps because of checking that's already occurred).

I think if the non-empty string invariant is only required for the implementation of one function, it might be safe write a lambda which assumes the invariant, but in general such assumptions are better expressed through the type system (eg, a newtype with only a smart constructor exposed, which checks that the string is nonempty). William:

It's very possible that someone re-factors their code so the type has multiple constructors, but forgets that they wrote some of these lambda expressions. -Wall should warn them about this.

Yikes. This is a very good argument for these warnings to be enabled. I'll probably modify the `stack new` project template to include -fwarn-incomplete-uni-patterns in the cabal file for the time being. On Sat, Nov 7, 2015 at 5:21 PM, Apostolis Xekoukoulotakis wrote:

Just learning Haskell here but I also agree. Rust gives a compile error by default for non-exhaustive patterns. I expect Haskell to be more secure than Rust.

https://doc.rust-lang.org/book/match.html

On Sun, Nov 8, 2015 at 3:16 AM, William Yager wrote:

...

Absolutely agreed. The only time it is generally safe to write pattern matching lambdas is if the type only has a single constructor. It's very possible that someone re-factors their code so the type has multiple constructors, but forgets that they wrote some of these lambda expressions. -Wall should warn them about this.

--Will

On Sat, Nov 7, 2015 at 6:10 PM, Niklas Hambüchen wrote:

...

Hello everyone,

to my dismay, a -Wall compiled program I deployed today crashed with

Exception: Non-exhaustive patterns in lambda

and I learned from http://dev.stephendiehl.com/hask/ that

A more subtle case is when implicitly pattern matching with a single "uni-pattern" in a lambda expression. The following will fail when given a Nothing.

boom = \(Just a) -> something

GHC can warn about these cases with the -fwarn-incomplete-uni-patterns flag.

And in fact:

ghci -Wall

...

map (\Nothing -> "ok") [Just 'a'] ["*** Exception: <interactive>:2:6-21: Non-exhaustive patterns in lambda :set -fwarn-incomplete-uni-patterns map (\Nothing -> "ok") [Just 'a'] <interactive>:4:6: Warning: Pattern match(es) are non-exhaustive

It really surprised me that -fwarn-incomplete-uni-patterns is not included in -Wall; I've felt really safe with my -Wall so far, especially about totality and similar things that will almost certainly lead to crashes.

In an older mail from 2010

(https://mail.haskell.org/pipermail/glasgow-haskell-users/2010-September/0192...) I saw Simon mention that it wasn't planned to warn about inexhaustive patterns like this.

I feel like there has been a strong push towards more totality in the last years, and I would like to ask if enabling -fwarn-incomplete-uni-patterns in -Wall may be reconsidered for a coming next GHC version, or if there are still opponents to that.

Niklas _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe

ne 8. 11. 2015 v 2:16 odesílatel William Yager napsal:

Absolutely agreed. The only time it is generally safe to write pattern matching lambdas is if the type only has a single constructor. It's very possible that someone re-factors their code so the type has multiple constructors, but forgets that they wrote some of these lambda expressions. -Wall should warn them about this.

+1

--Will

On Sat, Nov 7, 2015 at 6:10 PM, Niklas Hambüchen wrote:

...

Hello everyone,

to my dismay, a -Wall compiled program I deployed today crashed with

Exception: Non-exhaustive patterns in lambda

and I learned from http://dev.stephendiehl.com/hask/ that

A more subtle case is when implicitly pattern matching with a single "uni-pattern" in a lambda expression. The following will fail when given a Nothing.

boom = \(Just a) -> something

GHC can warn about these cases with the -fwarn-incomplete-uni-patterns flag.

And in fact:

ghci -Wall

...

map (\Nothing -> "ok") [Just 'a'] ["*** Exception: <interactive>:2:6-21: Non-exhaustive patterns in lambda :set -fwarn-incomplete-uni-patterns map (\Nothing -> "ok") [Just 'a'] <interactive>:4:6: Warning: Pattern match(es) are non-exhaustive

It really surprised me that -fwarn-incomplete-uni-patterns is not included in -Wall; I've felt really safe with my -Wall so far, especially about totality and similar things that will almost certainly lead to crashes.

In an older mail from 2010 ( https://mail.haskell.org/pipermail/glasgow-haskell-users/2010-September/0192... ) I saw Simon mention that it wasn't planned to warn about inexhaustive patterns like this.

I feel like there has been a strong push towards more totality in the last years, and I would like to ask if enabling -fwarn-incomplete-uni-patterns in -Wall may be reconsidered for a coming next GHC version, or if there are still opponents to that.

Niklas _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe

On Sun, Nov 08, 2015 at 09:36:13AM +0100, Joachim Breitner wrote:

Am Sonntag, den 08.11.2015, 01:10 +0100 schrieb Niklas Hambüchen:

...

In an older mail from 2010 (https://mail.haskell.org/pipermail/glasgow-haskell-users/2010-Septem ber/019237.html) I saw Simon mention that it wasn't planned to warn about inexhaustive patterns like this.

note that in that mail, he refers to patterns in where clauses, which is a different use-case than the lambdas you refer to.

[...]

Then you are in a good position to argue that it is an improvement (or you will find that SPJ, as very often, has a good instinct and making it warn about that prohibits many useful idioms.)

Simon's code is inadvisable, in my opinion. It is f xs | null xs = blah | otherwise = x+1 where (x:_) = xs where it really should be f xs = case xs of [] -> blah (x:_) -> x + 1 Tom

On Sun, Nov 08, 2015 at 10:42:35AM +0100, Joachim Breitner wrote:

Am Sonntag, den 08.11.2015, 09:30 +0000 schrieb Tom Ellis:

...

Simon's code is inadvisable, in my opinion.  It is

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

where it really should be

    f xs = case xs of []    -> blah                       (x:_) -> x + 1

yes, in this particular, small example

But often you have complex decisions in the guards that are not obviously related to the pattern match, and the where-bound and partially-pattern-matched value are used in multiple branches of the guard.

I can't address less particular, larger, examples until I'm shown them, but I am going to make the very bold claim that there's *always* a version without partial pattern matches that is at least as clear as the original. I strongly encourage you to challenge me on this claim! Tom