<div dir="ltr"><div class="gmail_default" style="font-family:tahoma,sans-serif">Richard, <br></div><div class="gmail_default" style="font-family:tahoma,sans-serif"><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif">A month after your recommendation this one is still unresolved.  Might you find the time to drive it to a conclusion?  Thanks!</div><div class="gmail_default" style="font-family:tahoma,sans-serif"><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif">Simon<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, 24 Jan 2024 at 18:33, Richard Eisenberg <<a href="mailto:rae@richarde.dev">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 style="overflow-wrap: break-word;">John Ericson has submitted <a href="https://github.com/ghc-proposals/ghc-proposals/pull/608" target="_blank">proposal #608</a> about adding -XPatternSignatureBinds. The proposal is an amendment and is thus a little harder to consume. I recommend reading the summary here.<div><br></div><div>Proposed change:</div><div><br></div><div>The proposed -XPatternSignatureBinds takes a piece out from -XPatternSignatures: with only -XPatternSignatures and not -XPatternSignatureBinds, a pattern signature  can mention in-scope type variables but can never bind fresh ones. With -XPatternSignatureBinds, an appearance of an out-of-scope type variable in a pattern signature will cause the variable to be bound to the type it unifies with.</div><div><br></div><div>-XScopedTypeVariables will imply -XPatternSignatures -XPatternSignatureBinds (and a few more), so the behavior of -XScopedTypeVariables is completely unchanged. Note that -XPatternSignatures is currently deprecated (and has been so for a long time), so a change in behavior there is not so bad.</div><div><br></div><div>Motivation for the change:</div><div><br></div><div>- It is awkward to have a rule in a language where scoping behavior depends on what else is in scope. This can confound e.g. tools meant to find the bindings sites of a variable occurrence.</div><div>- The implicit binding we have today plays poorly with the plan to allow users to pretend GHC has a unified namespace. That is, suppose x is in scope as a term variable, and then we have f (... :: ... x ...) = ... . Should that x be bound implicitly there or not? It's pretty unclear. By separating out -XPatternSignatureBinds from -XPatternSignatures, users of the latter are insulated from worrying about this potential future change.</div><div><br></div><div>My opinion:</div><div><br></div><div>- John has argued that this will make future namespace changes easier. I disagree with this assessment, because -XScopedTypeVariables is utterly pervasive. So the problem that this change is supposed to solve becomes only a tiny bit smaller, benefiting only those users who carefully enable -XPatternSignatures but not, say, -XScopedTypeVariables.</div><div>- But in the end, I don't care all that much. I've come to the opinion that we shouldn't worry about the distinction between warnings and extensions. The net effect of this proposal is to promote a warning into an extension (because we previously had -Wpattern-signature-binds). So if we shouldn't worry about this distinction, then this proposal is a no-op on the aspects of the language we should care about, and thus accepting and rejecting have the same effect. (This little analysis only makes sense because the features are so new -- there's no broad re-education to do or back-compat issues.)</div><div>- Accepting will make at least one person (John) happy. And I don't note anyone who would become unhappy. More happy people is more better. So I recommend acceptance. :)</div><div><br></div><div>Please let us know your thoughts!</div><div>Richard</div></div>_______________________________________________<br>
ghc-steering-committee mailing list<br>
<a href="mailto:ghc-steering-committee@haskell.org" target="_blank">ghc-steering-committee@haskell.org</a><br>
<a href="https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee" rel="noreferrer" target="_blank">https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee</a><br>
</blockquote></div>