<html><head><meta http-equiv="Content-Type" content="text/html; charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">John Ericson has submitted <a href="https://github.com/ghc-proposals/ghc-proposals/pull/608" class="">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 class=""><br class=""></div><div class="">Proposed change:</div><div class=""><br class=""></div><div class="">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 class=""><br class=""></div><div class="">-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 class=""><br class=""></div><div class="">Motivation for the change:</div><div class=""><br class=""></div><div class="">- 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 class="">- 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 class=""><br class=""></div><div class="">My opinion:</div><div class=""><br class=""></div><div class="">- 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 class="">- 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 class="">- 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 class=""><br class=""></div><div class="">Please let us know your thoughts!</div><div class="">Richard</div></body></html>