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 <mail@nh2.me> 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/019237.html)
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