[ghc-steering-committee] Proposal #608, -XPatternSignatureBinds. Rec: accept

[Richard Eisenberg]

John Ericson has submitted proposal #608 <https://github.com/ghc-proposals/ghc-proposals/pull/608> about adding -XPatternSignatureBinds. The proposal is an amendment and is thus a little harder to consume. I recommend reading the summary here.

Proposed change:

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.

-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.

Motivation for the change:

- 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.
- 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.

My opinion:

- 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.
- 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.)
- 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. :)

Please let us know your thoughts!
Richard
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20240124/933b0828/attachment.html>