<div dir="ltr"><div class="gmail_default" style="font-family:tahoma,sans-serif">To me this looks uncontroversial. </div><div class="gmail_default" style="font-family:tahoma,sans-serif"><ul><li>We have a currently-deprecated extension -XPatternSignatures</li><li>This proposal rehabilitates it (with a narrower scope than before) and adds a new one -XPatternSignatureBinds</li><li>If you don't use these extensions they won't harm you</li><li>The behaviour of -XScopedTypeVariables is unchanged</li></ul><div>It's a fairly tiny thing, easy to implement, easy to document. I don't care very much, but I'm content to approve it.<br></div><div><br></div><div>My only regret is that we don't have a "warning form" for language extensions
(see <a href="https://github.com/ghc-proposals/ghc-proposals/pull/620">https://github.com/ghc-proposals/ghc-proposals/pull/620</a>)
. I'd like to say -WPatternSignatureBinds, meaning to allow pattern-signatures to bind, but warn on every such occasion. Lacking such a "warning form" we have to *also* have `-Wpattern-signature-binds`.</div><div><br></div><div>Eric, I'm not sure what specifically you are objecting to. Are you making a philosophical point, or is there active harm here?</div><div><br></div><div>Simon<br></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, 27 Jan 2024 at 19:44, Eric Seidel <<a href="mailto:eric@seidel.io">eric@seidel.io</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">The motivation for this change does not make sense to me. ScopedTypeVariables<br>
is used everywhere and is even part of GHC2021. The goal of this change appears<br>
to be to extract out a controversial piece of PatternSignatures such that it<br>
could be later removed entirely, but without addressing the issue of<br>
ScopedTypeVariables.<br>
<br>
That's going about it the wrong way IMO. If we want to remove the behavior<br>
this proposal calls PatternSignatureBinds, the Committee should first adopt<br>
a resolution that we will remove (or alter the meaning of) ScopedTypeVariables<br>
in the next GHC20xx. If we get agreement on that, then this proposal could make<br>
sense as a step towards the broader goal.<br>
<br>
Outside of that broader agreement though, this feels more like a fork-inducing<br>
proposal and I would vote against.<br>
<br>
On Wed, Jan 24, 2024, at 11:32, Richard Eisenberg wrote:<br>
> John Ericson has submitted proposal #608 <br>
> <<a href="https://github.com/ghc-proposals/ghc-proposals/pull/608" rel="noreferrer" target="_blank">https://github.com/ghc-proposals/ghc-proposals/pull/608</a>> about adding <br>
> -XPatternSignatureBinds. The proposal is an amendment and is thus a <br>
> little harder to consume. I recommend reading the summary here.<br>
><br>
> Proposed change:<br>
><br>
> The proposed -XPatternSignatureBinds takes a piece out from <br>
> -XPatternSignatures: with only -XPatternSignatures and not <br>
> -XPatternSignatureBinds, a pattern signature can mention in-scope type <br>
> variables but can never bind fresh ones. With -XPatternSignatureBinds, <br>
> an appearance of an out-of-scope type variable in a pattern signature <br>
> will cause the variable to be bound to the type it unifies with.<br>
><br>
> -XScopedTypeVariables will imply -XPatternSignatures <br>
> -XPatternSignatureBinds (and a few more), so the behavior of <br>
> -XScopedTypeVariables is completely unchanged. Note that <br>
> -XPatternSignatures is currently deprecated (and has been so for a long <br>
> time), so a change in behavior there is not so bad.<br>
><br>
> Motivation for the change:<br>
><br>
> - It is awkward to have a rule in a language where scoping behavior <br>
> depends on what else is in scope. This can confound e.g. tools meant to <br>
> find the bindings sites of a variable occurrence.<br>
> - The implicit binding we have today plays poorly with the plan to <br>
> allow users to pretend GHC has a unified namespace. That is, suppose x <br>
> is in scope as a term variable, and then we have f (... :: ... x ...) = <br>
> ... . Should that x be bound implicitly there or not? It's pretty <br>
> unclear. By separating out -XPatternSignatureBinds from <br>
> -XPatternSignatures, users of the latter are insulated from worrying <br>
> about this potential future change.<br>
><br>
> My opinion:<br>
><br>
> - John has argued that this will make future namespace changes easier. <br>
> I disagree with this assessment, because -XScopedTypeVariables is <br>
> utterly pervasive. So the problem that this change is supposed to solve <br>
> becomes only a tiny bit smaller, benefiting only those users who <br>
> carefully enable -XPatternSignatures but not, say, <br>
> -XScopedTypeVariables.<br>
> - But in the end, I don't care all that much. I've come to the opinion <br>
> that we shouldn't worry about the distinction between warnings and <br>
> extensions. The net effect of this proposal is to promote a warning <br>
> into an extension (because we previously had <br>
> -Wpattern-signature-binds). So if we shouldn't worry about this <br>
> distinction, then this proposal is a no-op on the aspects of the <br>
> language we should care about, and thus accepting and rejecting have <br>
> the same effect. (This little analysis only makes sense because the <br>
> features are so new -- there's no broad re-education to do or <br>
> back-compat issues.)<br>
> - Accepting will make at least one person (John) happy. And I don't <br>
> note anyone who would become unhappy. More happy people is more better. <br>
> So I recommend acceptance. :)<br>
><br>
> Please let us know your thoughts!<br>
> Richard<br>
> _______________________________________________<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>
_______________________________________________<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>