<div dir="ltr">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.<div><br></div><div>For example, whilst:</div><div><br></div><div>capitalise (l:ls) = (toUpper l):ls</div><div><br></div><div>you could argue as bad code because it fails on the empty string case, something like:</div><div><br></div><div>capitalisedDictionary = map (\(l:ls) -> (toUpper l):ls) myDictionary where</div><div>  myDIctionary = ...<br><br>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). </div><div><br>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?). <br></div><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Nov 8, 2015 at 11:10 AM, Niklas Hambüchen <span dir="ltr"><<a href="mailto:mail@nh2.me" target="_blank">mail@nh2.me</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hello everyone,<br>
<br>
to my dismay, a -Wall compiled program I deployed today crashed with<br>
<br>
  Exception: Non-exhaustive patterns in lambda<br>
<br>
and I learned from <a href="http://dev.stephendiehl.com/hask/" rel="noreferrer" target="_blank">http://dev.stephendiehl.com/hask/</a> that<br>
<br>
  A more subtle case is when implicitly pattern matching with a single<br>
  "uni-pattern" in a lambda expression. The following will fail when<br>
  given a Nothing.<br>
<br>
    boom = \(Just a) -> something<br>
<br>
  GHC can warn about these cases with the<br>
  -fwarn-incomplete-uni-patterns flag.<br>
<br>
And in fact:<br>
<br>
  ghci -Wall<br>
  > map (\Nothing -> "ok") [Just 'a']<br>
  ["*** Exception: <interactive>:2:6-21: Non-exhaustive patterns in lambda<br>
  > :set -fwarn-incomplete-uni-patterns<br>
  > map (\Nothing -> "ok") [Just 'a']<br>
  <interactive>:4:6: Warning:<br>
      Pattern match(es) are non-exhaustive<br>
<br>
It really surprised me that -fwarn-incomplete-uni-patterns is not<br>
included in -Wall; I've felt really safe with my -Wall so far,<br>
especially about totality and similar things that will almost certainly<br>
lead to crashes.<br>
<br>
In an older mail from 2010<br>
(<a href="https://mail.haskell.org/pipermail/glasgow-haskell-users/2010-September/019237.html" rel="noreferrer" target="_blank">https://mail.haskell.org/pipermail/glasgow-haskell-users/2010-September/019237.html</a>)<br>
I saw Simon mention that it wasn't planned to warn about inexhaustive<br>
patterns like this.<br>
<br>
I feel like there has been a strong push towards more totality in the<br>
last years, and I would like to ask if enabling<br>
-fwarn-incomplete-uni-patterns in -Wall may be reconsidered for a coming<br>
next GHC version, or if there are still opponents to that.<br>
<br>
Niklas<br>
_______________________________________________<br>
Haskell-Cafe mailing list<br>
<a href="mailto:Haskell-Cafe@haskell.org">Haskell-Cafe@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe</a><br>
</blockquote></div><br></div>