I guess the difference between lambdas and top level functions is that it's
more reasonable to assume top level functions must expect to deal with
every value (particularly when they're part of an interface), whereas
inline lambdas often can reasonably make assumptions about their input.
For example, whilst:
capitalise (l:ls) = (toUpper l):ls
you could argue as bad code because it fails on the empty string case,
something like:
capitalisedDictionary = map (\(l:ls) -> (toUpper l):ls) myDictionary where
myDIctionary = ...
you could argue is perfectly reasonable code. when the programmer knows
that "myDictionary" doesn't contain any empty strings (perhaps because of
checking that's already occurred).
You could even go further here, and suggest that GHC should have an option
"don't check incomplete patterns", allowing GHC to assume strings are non
empty in this case, blowing up spectacularly C style at run time if this is
incorrect with either a seg fault or launching the nuclear missiles,
although this could allow optimisation opportunities (does GHC already have
such an option?).
On Sun, Nov 8, 2015 at 11:10 AM, Niklas Hambüchen
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