> 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 <sgraf1...@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" <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 [] = []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@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
>
_______________________________________________
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
