<html><head><style id="css_styles" type="text/css"><!--blockquote.cite { margin-left: 5px; margin-right: 0px; padding-left: 10px; padding-right:0px; border-left: 1px solid #cccccc }
blockquote.cite2 {margin-left: 5px; margin-right: 0px; padding-left: 10px; padding-right:0px; border-left: 1px solid #cccccc; margin-top: 3px; padding-top: 0px; }
a img { border: 0px; }
li[style='text-align: center;'], li[style='text-align: right;'] { list-style-position: inside;}
body { font-family: Segoe UI; font-size: 12pt; }--></style></head><body><div>I agree in principle, but then what about data types with strict fields? E.g.</div><div><br /></div><div>data SMaybe a = SNothing | SJust !a</div><div><br /></div><div>f :: SMaybe Bool -> ()</div><div>f SNothing = ()</div><div><br /></div><div>Today, we'd suggest `SJust _`.</div><div>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.</div><div>So we'd suggest `SJust True` and `SJust False`.</div><div><span><br /></span></div><div><span>Similarly, we'd case split unlifted data types by default, but not lifted data types.</span></div><div><span><br /></span></div><div><span>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.<br />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.</span></div><div><div><div></div></div></div>
<div><br /></div>
<div>------ Originalnachricht ------</div>
<div>Von: "Richard Eisenberg" <<a href="mailto:lists@richarde.dev">lists@richarde.dev</a>></div>
<div>An: "Sebastian Graf" <<a href="mailto:sgraf1337@gmail.com">sgraf1337@gmail.com</a>></div>
<div>Cc: "ghc-devs" <<a href="mailto:ghc-devs@haskell.org">ghc-devs@haskell.org</a>></div>
<div>Gesendet: 10.11.2021 04:44:50</div>
<div>Betreff: Re: Case split uncovered patterns in warnings or not?</div><div><br /></div>
<div id="x8358848d446e436" style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;"><blockquote cite="010f017d07f2c3df-5a0fe22c-63b6-4191-97b3-2ea484ca6a4a-000000@us-east-2.amazonses.com" type="cite" class="cite2">
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.<div class=""><br class="" /></div><div class="">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).</div><div class=""><br class="" /></div><div class="">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.</div><div class=""><br class="" /></div><div class="">Richard<br class="" /><div><br class="" /><blockquote type="cite" class=""><div class="">On Nov 9, 2021, at 8:17 AM, Sebastian Graf <<a href="mailto:sgraf1337@gmail.com" class="">sgraf1337@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline" /><div class=""><div dir="ltr" class=""><div class="">Hi Devs,</div><div class=""><br class="" /></div><div class="">In <a href="https://gitlab.haskell.org/ghc/ghc/-/issues/20642" class="">https://gitlab.haskell.org/ghc/ghc/-/issues/20642</a> we saw that GHC >= 8.10 outputs pattern match warnings a little differently than it used to. Example from there:</div><div class=""><br class="" /></div><div class=""><pre class="gmail-highlight gmail-code" lang="haskell"><span id="gmail-LC1" class="gmail-line" lang="haskell"><span class="gmail-cp">{-# OPTIONS_GHC -Wincomplete-uni-patterns #-}</span></span>
<span id="gmail-LC2" class="gmail-line" lang="haskell"></span>
<span id="gmail-LC3" class="gmail-line" lang="haskell"><span class="gmail-n">foo</span> <span class="gmail-o">::</span> <span class="gmail-p">[</span><span class="gmail-n">a</span><span class="gmail-p">]</span> <span class="gmail-o">-></span> <span class="gmail-p">[</span><span class="gmail-n">a</span><span class="gmail-p">]</span></span>
<span id="gmail-LC4" class="gmail-line" lang="haskell"><span class="gmail-n">foo</span> <span class="gmail-kt">[]</span> <span class="gmail-o">=</span> <span class="gmail-kt">[]</span></span>
<span id="gmail-LC5" class="gmail-line" lang="haskell"><span class="gmail-n">foo</span> <span class="gmail-n">xs</span> <span class="gmail-o">=</span> <span class="gmail-n">ys</span></span>
<span id="gmail-LC6" class="gmail-line" lang="haskell"> <span class="gmail-kr">where</span></span>
<span id="gmail-LC7" class="gmail-line" lang="haskell"> <span class="gmail-p">(</span><span class="gmail-kr">_</span><span class="gmail-p">,</span> <span class="gmail-n">ys</span><span class="gmail-o">@</span><span class="gmail-p">(</span><span class="gmail-kr">_</span><span class="gmail-o">:</span><span class="gmail-kr">_</span><span class="gmail-p">))</span> <span class="gmail-o">=</span> <span class="gmail-n">splitAt</span> <span class="gmail-mi">0</span> <span class="gmail-n">xs</span></span>
<span id="gmail-LC8" class="gmail-line" lang="haskell"></span>
<span id="gmail-LC9" class="gmail-line" lang="haskell"><span class="gmail-n">main</span> <span class="gmail-o">::</span> <span class="gmail-kt">IO</span> <span class="gmail-nb">()</span></span>
<span id="gmail-LC10" class="gmail-line" lang="haskell"><span class="gmail-n">main</span> <span class="gmail-o">=</span> <span class="gmail-n">putStrLn</span> <span class="gmail-o">$</span> <span class="gmail-n">foo</span> <span class="gmail-o">$</span> <span class="gmail-s">"Hello, coverage checker!"</span></span><span style="font-family:arial,sans-serif" class=""><br class="" /></span></pre><pre class="gmail-highlight gmail-code" lang="haskell"><span style="font-family:arial,sans-serif" class="">Instead of saying</span><br class="" /><br class="" /><span id="gmail-LC1" class="gmail-line" lang="plaintext">ListPair.hs:7:3: warning: [-Wincomplete-uni-patterns]</span>
<span id="gmail-LC2" class="gmail-line" lang="plaintext"> Pattern match(es) are non-exhaustive</span>
<span id="gmail-LC3" class="gmail-line" lang="plaintext"> In a pattern binding: Patterns not matched: (_, [])</span>
<br class="" /></pre><pre class="gmail-highlight gmail-code" lang="haskell"><span style="font-family:arial,sans-serif" class="">We now say</span><br class="" /><br class="" /><span id="gmail-LC50" class="gmail-line" lang="plaintext">ListPair.hs:7:3: warning: [-Wincomplete-uni-patterns]</span>
<span id="gmail-LC51" class="gmail-line" lang="plaintext"> Pattern match(es) are non-exhaustive</span>
<span id="gmail-LC52" class="gmail-line" lang="plaintext"> In a pattern binding:</span>
<span id="gmail-LC53" class="gmail-line" lang="plaintext"> Patterns of type ‘([a], [a])’ not matched:</span>
<span id="gmail-LC54" class="gmail-line" lang="plaintext"> ([], [])</span>
<span id="gmail-LC55" class="gmail-line" lang="plaintext"> ((_:_), [])</span>
<br class="" /></pre>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.<br class="" />The motivation for the change is outlined in <a href="https://gitlab.haskell.org/ghc/ghc/-/issues/20642#note_390110" class="">https://gitlab.haskell.org/ghc/ghc/-/issues/20642#note_390110</a>, but I could easily be swayed not to do the case split. Which arguably is less surprising, as Andreas Abel points out.<br class="" /><br class="" />Considering the other examples from my post, which would you prefer?<br class="" /><br class="" />Cheers,<br class="" />Sebastian</div></div>
_______________________________________________<br class="" />ghc-devs mailing list<br class="" /><a href="mailto:ghc-devs@haskell.org" class="">ghc-devs@haskell.org</a><br class="" /><a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs">http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs</a><br class="" /></div></blockquote></div><br class="" /></div></blockquote></div>
</body></html>