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" <li...@richarde.dev>
An: "Sebastian Graf" <sgraf1...@gmail.com>
Cc: "ghc-devs" <ghc-devs@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 <sgraf1...@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[]=[]fooxs=yswhere(_,ys@(_:_))=splitAt0xsmain::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@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
_______________________________________________
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
