Case split uncovered patterns in warnings or not?

[Spiwack, Arnaud]

> But actually I had hoped we can come up with something more general and
less ad-hoc than the behavior of 8.8. Maybe there isn't and 8.8 already
lived in the sweet spot.

I think that it's quite fine (maybe desirable even) for error and warning
messages to be ad hoc.

On Wed, Nov 10, 2021 at 8:29 AM Sebastian Graf <sgraf1337 at gmail.com> wrote:

> I agree in principle, but then what about data types with strict fields?
> E.g.
>
> data SMaybe a = SNothing | SJust !a
>
> f :: SMaybe Bool -> ()
> f SNothing = ()
>
> Today, we'd suggest `SJust _`.
> But the checker can't differentiate between evaluation done by a
> pattern-match of the user vs. something like a strict field that was
> unlifted to begin with.
> So we'd suggest `SJust True` and `SJust False`.
>
> Similarly, we'd case split unlifted data types by default, but not lifted
> data types.
>
> I think I can easily make the whole function
> (`GHC.HsToCore.Pmc.Solver.generateInhabitingPatterns`) dependent on whether
> it's called from an EmptyCase or not, to recover the behavior pre-8.10.
> But actually I had hoped we can come up with something more general and
> less ad-hoc than the behavior of 8.8. Maybe there isn't and 8.8 already
> lived in the sweet spot.
>
> ------ Originalnachricht ------
> Von: "Richard Eisenberg" <lists at richarde.dev>
> An: "Sebastian Graf" <sgraf1337 at gmail.com>
> Cc: "ghc-devs" <ghc-devs at haskell.org>
> Gesendet: 10.11.2021 04:44:50
> Betreff: Re: Case split uncovered patterns in warnings or not?
>
> Maybe the answer should depend on whether the scrutinee has already been
> forced. The new output ("We now say", below) offers up patterns that will
> change the strictness behavior of the code. The old output did not.
>
> Reading the link below, I see that, previously, there was an inconsistency
> with -XEmptyCase, which *did* unroll one level of constructor. But maybe
> that made sense because -XEmptyCase is strict (unlike normal case).
>
> I'm just saying this because I think listing the constructors in the
> -XEmptyCase case is a good practice, but otherwise I think they're
> clutterful... and strictness is a perhaps more principled way of making
> this distinction.
>
> Richard
>
> On Nov 9, 2021, at 8:17 AM, Sebastian Graf <sgraf1337 at gmail.com> wrote:
>
> Hi Devs,
>
> In https://gitlab.haskell.org/ghc/ghc/-/issues/20642 we saw that GHC >=
> 8.10 outputs pattern match warnings a little differently than it used to.
> Example from there:
>
> {-# OPTIONS_GHC -Wincomplete-uni-patterns #-}foo :: [a] -> [a]foo [] = []foo xs = ys  where  (_, ys@(_:_)) = splitAt 0 xsmain :: IO ()main = putStrLn $ foo $ "Hello, coverage checker!"
>
> Instead of saying
>
> ListPair.hs:7:3: warning: [-Wincomplete-uni-patterns]    Pattern match(es) are non-exhaustive    In a pattern binding: Patterns not matched: (_, [])
>
> We now say
>
> ListPair.hs:7:3: warning: [-Wincomplete-uni-patterns]    Pattern match(es) are non-exhaustive    In a pattern binding:        Patterns of type ‘([a], [a])’ not matched:            ([], [])            ((_:_), [])
>
> E.g., newer versions do (one) case split on pattern variables that haven't
> even been scrutinised by the pattern match. That amounts to quantitatively
> more pattern suggestions and for each variable a list of constructors that
> could be matched on.
> The motivation for the change is outlined in
> https://gitlab.haskell.org/ghc/ghc/-/issues/20642#note_390110, but I
> could easily be swayed not to do the case split. Which arguably is less
> surprising, as Andreas Abel points out.
>
> Considering the other examples from my post, which would you prefer?
>
> Cheers,
> Sebastian
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20211110/c18863bb/attachment.html>