<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Sep 7, 2020 at 5:12 AM Simon Peyton Jones via ghc-devs <<a href="mailto:ghc-devs@haskell.org" target="_blank">ghc-devs@haskell.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div lang="EN-GB">
<div>
<p class="MsoNormal"><br></p>
<p class="MsoNormal" style="margin-left:36pt"><span><u></u> <u></u></span></p>
<ol style="margin-top:0cm" start="3" type="1">
<li style="margin-left:0cm"><span>I don’t understand the details of Iavor’s proposal to add that “unlifted patterns are strict”, in addition to (1). Do you mean “any sub-pattern
of the LHS has an unlifted type”? I think this is fully compatible with unlifted user defined data<u></u></span></li></ol>
<p class="MsoNormal" style="margin-left:72pt"><span>Just (# a,b #) = e<u></u><u></u></span></p>
<p class="MsoNormal" style="margin-left:36pt"><span>would be strict. And even<u></u><u></u></span></p>
<p class="MsoNormal" style="margin-left:72pt"><span>MkT _ = e<u></u><u></u></span></p>
<p class="MsoNormal" style="margin-left:36pt"><span>would be strict if data T = MkT (# Int,Int #)<u></u><u></u></span></p>
<p class="MsoNormal"><span><u></u> </span></p></div></div></blockquote><div><br></div><div>Yes, the first one would be strict up to the tuple, and the second one would also be strict. I think this is the consistent way to interpret your rule (1) that unlifted bindings are always strict, and it shouldn't really matter if you used a variable pattern, or a wild card pattern. I don't think there's any other part of the language where replacing a `_` with an unused name changes the semantics of the program, and I don't think it should in this case either.</div><div><br></div><div>Just to be fully explicit, the thing I find odd with GHC's current behavior is that these two are different:</div><div><br></div><div>let MkT x = undefined in () --> undefined</div><div>let MkT _ = undefined in () --> ()</div><div><br></div><div>Even more explicitly:</div><div>let (_ :: Int#) = undefined in () --> () -- the value `undefined` is not representable in type `Int#` but GHC is happy to proceed because it doesn't need to represent it</div><div>let (x :: Int#) = undefined in () --> () -- same situation, but now GHC is strict, even though it still doesn't need to represent the value.</div><div><br></div><div>I think that the consistent behavior is for all of these to diverge, because laziness does not mix with unlfited values, at least in the presence of non-termination.</div><div><br></div><div>-Iavor</div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div lang="EN-GB"><div>
<p class="MsoNormal"><span><u></u> <u></u></span></p>
<div style="border-top:none;border-right:none;border-bottom:none;border-left:1.5pt solid blue;padding:0cm 0cm 0cm 4pt">
<div>
<div style="border-right:none;border-bottom:none;border-left:none;border-top:1pt solid rgb(225,225,225);padding:3pt 0cm 0cm">
<p class="MsoNormal"><b><span lang="EN-US">From:</span></b><span lang="EN-US"> ghc-devs <<a href="mailto:ghc-devs-bounces@haskell.org" target="_blank">ghc-devs-bounces@haskell.org</a>>
<b>On Behalf Of </b>Richard Eisenberg<br>
<b>Sent:</b> 02 September 2020 14:47<br>
<b>To:</b> Spiwack, Arnaud <<a href="mailto:arnaud.spiwack@tweag.io" target="_blank">arnaud.spiwack@tweag.io</a>><br>
<b>Cc:</b> GHC developers <<a href="mailto:ghc-devs@haskell.org" target="_blank">ghc-devs@haskell.org</a>><br>
<b>Subject:</b> Re: Implicit reboxing of unboxed tuple in let-patterns<u></u><u></u></span></p>
</div>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<p class="MsoNormal"><br>
<br>
<u></u><u></u></p>
<blockquote style="margin-top:5pt;margin-bottom:5pt">
<div>
<p class="MsoNormal">On Sep 2, 2020, at 9:39 AM, Spiwack, Arnaud <<a href="mailto:arnaud.spiwack@tweag.io" target="_blank">arnaud.spiwack@tweag.io</a>> wrote:<u></u><u></u></p>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<p class="MsoNormal"><span style="font-size:9pt;font-family:Helvetica,sans-serif">Ooh… pattern synonyms for unboxed tuple. I must confess that I don't know what the semantics of these ought to be. It does look like an interesting can of worms. How do they
currently desugar?</span><u></u><u></u></p>
</div>
</blockquote>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<p class="MsoNormal">Right now, there is one rule: if the type of any variable bound in the pattern is unlifted, then the pattern is an unlifter-var pattern and is strict. The pattern must be banged, unless the bound variable is not nested. This rule is consistent
across all features.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">This thread is suggesting to add a special case -- one that seems to match intuition, but it's still a special case. And my question is: should the special case be for unboxed tuples? or should the special case be for any pattern whose
overall type is unlifted?<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">Richard<u></u><u></u></p>
</div>
</div>
</div>
</div>
_______________________________________________<br>
ghc-devs mailing list<br>
<a href="mailto:ghc-devs@haskell.org" target="_blank">ghc-devs@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs</a><br>
</blockquote></div></div>