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

[Adam Bergmark]

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.

- Adam


On Sun, Nov 8, 2015 at 2:29 AM, Patrick Redmond <plredmond at gmail.com> wrote:

> 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
> >
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151108/be7c2c61/attachment.html>