Case split uncovered patterns in warnings or not?

[Sebastian Graf]

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[]=[]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 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/d26cb919/attachment.html>