[Haskell-cafe] More death to partial functions: Should -fwarn-incomplete-uni-patterns be enabled with -Wall?

[Patrick Redmond]

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
<apostolis.xekoukoulotakis at gmail.com> 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 <will.yager at gmail.com> 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 <mail at 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 at haskell.org
>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>>
>>
>>
>> _______________________________________________
>> Haskell-Cafe mailing list
>> Haskell-Cafe at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>>
>
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>