<div dir="ltr">I am not sure what you'd expect this to do, but under what I was suggesting it would be equivalent to<div>`let ~(x,y) = undefined in x `seq` y `seq ()`<br></div><div><br></div><div><div>Obviously it would be nice to warn/report error that this is probably a mistake, which seems pretty easy to do.</div><div>What useful functionality do you think is lost by this?</div><div><br></div><div>The main tricky case I can think of is the interaction with pattern synonyms, as one would have to keep track of</div></div><div>strict bindings in those.</div><div><br></div><div><br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Sep 10, 2020 at 10:12 AM Chris Smith <<a href="mailto:cdsmith@gmail.com">cdsmith@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">I agree that the strictness there was surprising, but I think this may be a case where what is superficially expected is, in the end, inconsistent.<div dir="auto"><br></div><div dir="auto">What about:<div dir="auto"><br></div><div dir="auto">let ~(!x, !y) = undefined in ()</div><div dir="auto"><br></div><div dir="auto">If nested bang patterns implied strictness of their parents, this valid expression seems not to make any sense. I can see a few ways to deal with that, but none of them seem intuitive to me.</div><div dir="auto"><br></div><div dir="auto">One could disallow it, and only allow strictness annotations on variables rather than all patterns, but this sacrifices a lot of functionality to avoid that surprise. Alternatively, one could say that upward propagation of strictness is only a default, but that definitely feels like a hack. It might make the original example behave as expected, but it is no longer for the expected reasons, and suddenly there is something even more complex going on.</div><div dir="auto"><br></div><div dir="auto">I don't have a strong opinion here, but I think it's important to consider more complex cases when making the decision.</div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Sep 10, 2020, 12:39 PM Iavor Diatchki <<a href="mailto:iavor.diatchki@gmail.com" 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">Ah, yes, quite right: since the projections match the whole patterns, the bang patterns in a constructor would be forced as soon as one of the fields in the constructor is used, so this also diverges:<div><br></div><div>ex3 = let (x, !y) = (5,undefined) in x</div><div><br></div><div>The rule is consistent, to me it just seems quite unintuitive.</div><div><br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Sep 10, 2020 at 9:18 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>This whole area is clearly somewhat troublesome:<div><div><br><blockquote type="cite"><div>On Sep 10, 2020, at 12:05 PM, Iavor Diatchki <<a href="mailto:iavor.diatchki@gmail.com" rel="noreferrer" target="_blank">iavor.diatchki@gmail.com</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">3. nested bang patterns in pattern bindings should count as "uses" of the value and therefore should be strict. For example if I write `let ( !x, !y ) = undefined in ()`, I think this should be equivalent to `let (x,y) = undefined in x `seq` y `seq` ()`. With the current behavior the bang patterns don't do anything, while my guess would be that most people would expect the suggested behavior instead. As usual, we should not allow that at the top level.</span></div></blockquote></div><br></div><div>This isn't quite right.</div><div><br></div><div>Consider</div><div><br></div><div><div></div></div><blockquote type="cite"><div><div>ex0 = let ( !x, !y ) = undefined in ()</div><div>ex1 = let ( !x, !y ) = (5, undefined) in x</div><div>ex2 = let ( !x, y ) = (5, undefined) in x</div></div></blockquote><div><br></div><div>ex0 converges, because let-bindings are lazy by default.</div><div>ex1 diverges, because the bang on y means that, when the patten-match happens at all, x and y are bound strictly. So bangs *do* matter in nested patterns within pattern bindings. By contrast, ex2 converges.</div><div><br></div><div>Again, I'm not arguing in favor of the current behavior, but I want to make sure we're all as informed as possible in this debate.</div><div><br></div><div>Richard</div></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>
</blockquote></div>