<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">facundo.dominguez@tweag.io</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;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" target="_blank" rel="noreferrer">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" target="_blank" rel="noreferrer">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" target="_blank" rel="noreferrer">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" target="_blank" rel="noreferrer">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" target="_blank" rel="noreferrer">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" target="_blank" rel="noreferrer">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" target="_blank" rel="noreferrer">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" rel="noreferrer">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>