<div dir="ltr">Yes</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Sep 4, 2020 at 2:29 AM Spiwack, Arnaud <<a href="mailto:arnaud.spiwack@tweag.io">arnaud.spiwack@tweag.io</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 dir="ltr"><div><p style="margin:0px 0px 1.2em">Iavor:</p>
<blockquote style="margin:1.2em 0px;border-left:4px solid rgb(221,221,221);padding:0px 1em;color:rgb(119,119,119);quotes:none">
<p style="margin:0px 0px 1.2em">Yeah, I think these are nice examples that illustrate some of the problems with the current behavior of GHC. For example, I think it is weird that <code style="font-size:0.85em;font-family:Consolas,Inconsolata,Courier,monospace;margin:0px 0.15em;padding:0px 0.3em;white-space:pre-wrap;border:1px solid rgb(234,234,234);background-color:rgb(248,248,248);border-radius:3px;display:inline">b</code> non-terminates, but <code style="font-size:0.85em;font-family:Consolas,Inconsolata,Courier,monospace;margin:0px 0.15em;padding:0px 0.3em;white-space:pre-wrap;border:1px solid rgb(234,234,234);background-color:rgb(248,248,248);border-radius:3px;display:inline">c</code> does, because <code style="font-size:0.85em;font-family:Consolas,Inconsolata,Courier,monospace;margin:0px 0.15em;padding:0px 0.3em;white-space:pre-wrap;border:1px solid rgb(234,234,234);background-color:rgb(248,248,248);border-radius:3px;display:inline">z</code> is not used. I would expect those to be equivalent.</p>
</blockquote>
<p style="margin:0px 0px 1.2em">What about if I rewrite all these patterns as</p>
<pre style="font-family:Consolas,Inconsolata,Courier,monospace;font-size:1em;line-height:1.2em;margin:1.2em 0px"><code style="font-size:0.85em;font-family:Consolas,Inconsolata,Courier,monospace;margin:0px 0.15em;white-space:pre-wrap;overflow:auto;border-radius:3px;border:1px solid rgb(204,204,204);padding:0.5em;color:rgb(51,51,51);background:none 0% 0% repeat scroll rgb(248,248,248);display:block"><span><span style="color:rgb(51,51,51);font-weight:bold">data</span> <span style="color:rgb(68,85,136);font-weight:bold">X</span> = <span style="color:rgb(68,85,136);font-weight:bold">MkX</span> <span style="color:rgb(68,85,136);font-weight:bold">Int</span>#</span>
<span style="color:rgb(153,0,0);font-weight:bold">a</span> = <span style="color:rgb(51,51,51);font-weight:bold">let</span> ~(<span style="color:rgb(68,85,136);font-weight:bold">MkX</span> <span style="color:rgb(0,128,128)">3</span>#) = undefined <span style="color:rgb(51,51,51);font-weight:bold">in</span> ()
<span style="color:rgb(153,0,0);font-weight:bold">b</span> = <span style="color:rgb(51,51,51);font-weight:bold">let</span> ~(<span style="color:rgb(68,85,136);font-weight:bold">MkX</span> z) = undefined <span style="color:rgb(51,51,51);font-weight:bold">in</span> ()
<span style="color:rgb(153,0,0);font-weight:bold">c</span> = <span style="color:rgb(51,51,51);font-weight:bold">let</span> ~(<span style="color:rgb(68,85,136);font-weight:bold">MkX</span> _) = undefined <span style="color:rgb(51,51,51);font-weight:bold">in</span> ()
<span style="color:rgb(153,0,0);font-weight:bold">d</span> = <span style="color:rgb(51,51,51);font-weight:bold">let</span> ~(<span style="color:rgb(68,85,136);font-weight:bold">MkX</span> {}) = undefined <span style="color:rgb(51,51,51);font-weight:bold">in</span> ()
<span style="color:rgb(153,0,0);font-weight:bold">e</span> = <span style="color:rgb(51,51,51);font-weight:bold">let</span> ~(_ :: <span style="color:rgb(68,85,136);font-weight:bold">X</span>) = undefined <span style="color:rgb(51,51,51);font-weight:bold">in</span> ()
</code></pre>
<p style="margin:0px 0px 1.2em">Do you still expect <code style="font-size:0.85em;font-family:Consolas,Inconsolata,Courier,monospace;margin:0px 0.15em;padding:0px 0.3em;white-space:pre-wrap;border:1px solid rgb(234,234,234);background-color:rgb(248,248,248);border-radius:3px;display:inline">c</code> to diverge?</p>
<div title="MDH:PGRpdj5JYXZvcjo8YnI+PC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj4mZ3Q7IFllYWgsIEkgdGhp
bmsgdGhlc2UgYXJlIG5pY2UgZXhhbXBsZXMgdGhhdCBpbGx1c3RyYXRlJm5ic3A7c29tZSBvZiB0
aGUgCnByb2JsZW1zJm5ic3A7d2l0aCB0aGUgY3VycmVudCBiZWhhdmlvciBvZiBHSEMuJm5ic3A7
ICZuYnNwO0ZvciBleGFtcGxlLCBJIHRoaW5rIGl0IGlzIAp3ZWlyZCB0aGF0IGBiYCBub24tdGVy
bWluYXRlcywgYnV0IGBjYCBkb2VzLCZuYnNwO2JlY2F1c2UgYHpgIGlzIG5vdCB1c2VkLiZuYnNw
OyBJCiB3b3VsZCBleHBlY3QgdGhvc2UgdG8gYmUgZXF1aXZhbGVudC48L2Rpdj48ZGl2Pjxicj48
L2Rpdj48ZGl2PldoYXQgYWJvdXQgaWYgSSByZXdyaXRlIGFsbCB0aGVzZSBwYXR0ZXJucyBhczwv
ZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+YGBgaGFza2VsbDxicj5kYXRhIFggPSBNa1ggSW50Izxi
cj48YnI+YSA9IGxldCB+KE1rWCAzIykgPSB1bmRlZmluZWQgaW4gKCk8YnI+YiA9IGxldCB+KE1r
WCB6KSA9IHVuZGVmaW5lZCBpbiAoKTxicj5jID0gbGV0IH4oTWtYIF8pID0gdW5kZWZpbmVkIGlu
ICgpPGJyPmQgPSBsZXQgfihNa1gge30pID0gdW5kZWZpbmVkIGluICgpPGJyPmUgPSBsZXQgfihf
IDo6IFgpID0gdW5kZWZpbmVkIGluICgpPGJyPmBgYDwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+
RG8geW91IHN0aWxsIGV4cGVjdCBgY2AgdG8gZGl2ZXJnZT88YnI+PC9kaXY+PGRpdj48L2Rpdj4=" style="height:0px;width:0px;max-height:0px;max-width:0px;overflow:hidden;font-size:0em;padding:0px;margin:0px"></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Sep 3, 2020 at 9:04 PM chessai <<a href="mailto:chessai1996@gmail.com" target="_blank">chessai1996@gmail.com</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 dir="auto">Not saying it's the best option, but it is an idea: Perhaps the behaviour could stay the same, but the proposed behaviour could sit behind a language pragma? I myself would always enable that pragma.</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Sep 3, 2020, 13:59 Domínguez, Facundo <<a href="mailto:facundo.dominguez@tweag.io" target="_blank">facundo.dominguez@tweag.io</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 dir="ltr"><div><font>> I guess a more explicit option would be to make it an error to use
a lazy pattern on an unlifted type, and require programmers to manually
add the `!` but I am not sure that gains much, and is more work in the
compiler.</font></div><div><font><br></font></div><div><font>Not being used to deal with unlifted types, this would be my preferred option. Having the meaning of let change depending on the levity of the type is a good opportunity for confusion.</font></div><div><font><br></font></div><div><font>Cheers,</font></div><div><font>Facundo<br></font></div><div><font><br></font></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Sep 3, 2020 at 3:43 PM Iavor Diatchki <<a href="mailto:iavor.diatchki@gmail.com" rel="noreferrer" target="_blank">iavor.diatchki@gmail.com</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 dir="ltr">Yeah, I think these are nice examples that illustrate some of the problems with the current behavior of GHC. For example, I think it is weird that `b` non-terminates, but `c` does, because `z` is not used. I would expect those to be equivalent.<div><br></div><div>My preference would be to use the simple rule I mentioned before, but change how bang patterns work in pattern bindings. In particular, I think writing a bang pattern should constitute a use of the banged value. I think two equivalent ways to specify this is to say that a) writing a nested bang pattern implicitly adds bangs to the enclosing patterns, or I think equivalently b) writing `!p` is the same as writing `x@p` and adding `seq x` the same way we do for simple `!x = e` definitions</div><div><br></div><div>With this interpretation, all but `e` would diverge, which matches my intuition of how unboxed types should work.</div><div><br></div><div>-Iavor</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Sep 3, 2020 at 11:02 AM Richard Eisenberg <<a href="mailto:rae@richarde.dev" rel="noreferrer" target="_blank">rae@richarde.dev</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><br><div><br><blockquote type="cite"><div>On Sep 3, 2020, at 1:51 PM, Iavor Diatchki <<a href="mailto:iavor.diatchki@gmail.com" rel="noreferrer" target="_blank">iavor.diatchki@gmail.com</a>> wrote:</div><br><div><div dir="ltr">How about the following rule: unlifted patterns are always strict (i.e., you desugar them as if they had an explicit `!`). A pattern is "unlifted" if the type it examines is unlifted. Seems simple enough and, I think, it would do what most folks would expect. </div></div></blockquote><div><br></div><div>I don't think it's this simple. For example:</div><div><br></div><div>> data X = MkX Int#</div><div>></div><div>> a = let MkX 3# = undefined in ()</div><div>> b = let MkX z = undefined in ()</div><div>> c = let MkX _ = undefined in ()</div><div>> d = let MkX {} = undefined in ()</div><div>> e = let _ :: X = undefined in ()</div><div><br></div><div>Which of these diverge? e definitely converges, as X is lifted. b definitely diverges, because it binds z, a variable of an unlifted type, to a component of a diverging computation.</div><div><br></div><div>In GHC today, all the cases other than b converge.</div><div><br></div><div>Iavor suggests that a should diverge: 3# is a pattern of an unlifted type. What about c? What about d? Very unclear to me.</div><div><br></div><div>Note that banging the pattern nested inside the MkX does not change the behavior (in GHC today) for any of the cases where this makes sense to do so.</div><div><br></div><div>Richard</div><div><br></div><blockquote type="cite"><div><div dir="ltr"><div><br></div><div>I guess a more explicit option would be to make it an error to use a lazy pattern on an unlifted type, and require programmers to manually add the `!` but I am not sure that gains much, and is more work in the compiler.</div><div><br></div><div>-Iavor</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Sep 3, 2020 at 10:38 AM Richard Eisenberg <<a href="mailto:rae@richarde.dev" rel="noreferrer" target="_blank">rae@richarde.dev</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><br><div><br><blockquote type="cite"><div>On Sep 3, 2020, at 12:10 PM, Spiwack, Arnaud <<a href="mailto:arnaud.spiwack@tweag.io" rel="noreferrer" target="_blank">arnaud.spiwack@tweag.io</a>> wrote:</div><br><div><span style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none;float:none;display:inline">This is all a tad tricky, I must say.</span></div></blockquote></div><br><div>... which is one of the reasons I originally wanted one simple rule. I'm not now saying I was in the right, but it is an attractive resting point for this discussion.</div><div><br></div><div>To be clear, I don't think there's going to be any concrete action here without a proposal, so perhaps once this thread finds a resting point different than the status quo, someone will have to write it up.</div><div><br></div><div>Richard</div></div>_______________________________________________<br>
ghc-devs mailing list<br>
<a href="mailto:ghc-devs@haskell.org" rel="noreferrer" target="_blank">ghc-devs@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs" rel="noreferrer noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs</a><br>
</blockquote></div>
</div></blockquote></div><br></div></blockquote></div>
_______________________________________________<br>
ghc-devs mailing list<br>
<a href="mailto:ghc-devs@haskell.org" rel="noreferrer" target="_blank">ghc-devs@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs" rel="noreferrer noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs</a><br>
</blockquote></div>
_______________________________________________<br>
ghc-devs mailing list<br>
<a href="mailto:ghc-devs@haskell.org" rel="noreferrer" target="_blank">ghc-devs@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs" rel="noreferrer noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs</a><br>
</blockquote></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>
_______________________________________________<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>