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

[Simon Peyton Jones]

Richard,

A month after your recommendation this one is still unresolved.  Might you
find the time to drive it to a conclusion?  Thanks!

Simon

On Wed, 24 Jan 2024 at 18:33, Richard Eisenberg <rae at richarde.dev> wrote:

> 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
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20240222/9209ec6d/attachment.html>