<div dir="ltr">I agree that this should be included in -Wall. I've many times added a uni pattern "temporarily" and sometimes forgotten to fix it later on.<div><br></div><div>- Adam</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Nov 8, 2015 at 2:29 AM, Patrick Redmond <span dir="ltr"><<a href="mailto:plredmond@gmail.com" target="_blank">plredmond@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Clinton:<br>
<span class="">> when the programmer knows that "myDictionary" doesn't contain any empty strings (perhaps because of checking that's already occurred).<br>
<br>
</span>I think if the non-empty string invariant is only required for the<br>
implementation of one function, it might be safe write a lambda which<br>
assumes the invariant, but in general such assumptions are better<br>
expressed through the type system (eg, a newtype with only a smart<br>
constructor exposed, which checks that the string is nonempty).<br>
<br>
William:<br>
<span class="">> 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.<br>
<br>
</span>Yikes. This is a very good argument for these warnings to be enabled.<br>
I'll probably modify the `stack new` project template to include<br>
-fwarn-incomplete-uni-patterns in the cabal file for the time being.<br>
<div class="HOEnZb"><div class="h5"><br>
On Sat, Nov 7, 2015 at 5:21 PM, Apostolis Xekoukoulotakis<br>
<<a href="mailto:apostolis.xekoukoulotakis@gmail.com">apostolis.xekoukoulotakis@gmail.com</a>> wrote:<br>
> Just learning Haskell here but I also agree. Rust gives a compile error by<br>
> default for non-exhaustive patterns.<br>
> I expect Haskell to be more secure than Rust.<br>
><br>
> <a href="https://doc.rust-lang.org/book/match.html" rel="noreferrer" target="_blank">https://doc.rust-lang.org/book/match.html</a><br>
><br>
> On Sun, Nov 8, 2015 at 3:16 AM, William Yager <<a href="mailto:will.yager@gmail.com">will.yager@gmail.com</a>> wrote:<br>
>><br>
>> Absolutely agreed. The only time it is generally safe to write pattern<br>
>> matching lambdas is if the type only has a single constructor. It's very<br>
>> possible that someone re-factors their code so the type has multiple<br>
>> constructors, but forgets that they wrote some of these lambda expressions.<br>
>> -Wall should warn them about this.<br>
>><br>
>> --Will<br>
>><br>
>> On Sat, Nov 7, 2015 at 6:10 PM, Niklas Hambüchen <<a href="mailto:mail@nh2.me">mail@nh2.me</a>> wrote:<br>
>>><br>
>>> 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<br>
>>> 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>
>>><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>
>><br>
>><br>
>><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>
>><br>
><br>
><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>
><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>
</div></div></blockquote></div><br></div>