<div dir="ltr"><blockquote class="gmail_default gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
When I review a proposal for a new extension, one of the<br>
questions I ask myself is "would I eventually support including this in<br>
a GHC20xx standard?" If the answer is no (and if the extension is not one<br>
of the advanced or niche things like CPP), then I'm much less likely to<br>
support it.
</blockquote><div><br></div><div style="font-family:tahoma,sans-serif" class="gmail_default">Aha. Now I understand your point thanks.</div><div style="font-family:tahoma,sans-serif" class="gmail_default"><br></div><div style="font-family:tahoma,sans-serif" class="gmail_default">In the glorious future, what do we want?</div><div style="font-family:tahoma,sans-serif" class="gmail_default"><ul><li>Plan A. "A pattern signature brings into scope any variables that aren't already in scope". It's a bit of a tricky rule. If we see `f (Just x) = rhs` we know that it brings `x` into scope regardless. Simple. No so with pattern-signatures!<br><br></li><li>Plan B. Pattern signatures never bring anything into scope. To do that, use @type patterns. For example, instead of<br> f (Just (x::a)) = rhs<br>say<br> f (Just @a x) = rhs<br>Now it's clear that `a` is being brought into scope.</li></ul><div>I lean towards Plan B, but you raise a good point. I'd love to know what our consensus is. RSVP steering committee members.<br></div><div><br></div><div>Simon<br></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, 28 Jan 2024 at 00:12, 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">I think it's mostly a philosophical point. We have GHC2021 which is the<br>
current "blessed" version of the language. It includes ScopedTypeVariables,<br>
which if I understand correctly is a superset of PatternSigs. We also want<br>
to move in the direction of having *fewer* interacting extensions. In my<br>
mind that is one of the main motivations for introducing the GHC20xx<br>
standards. When I review a proposal for a new extension, one of the<br>
questions I ask myself is "would I eventually support including this in<br>
a GHC20xx standard?" If the answer is no (and if the extension is not one<br>
of the advanced or niche things like CPP), then I'm much less likely to<br>
support it.<br>
<br>
So what is the purpose of refactoring extensions that are implied by<br>
ScopedTypeVariables? It seems like needless churn if ScopedTypeVariables<br>
is here to stay. On the other hand, if we mean to change ScopedTypeVariables<br>
we should be explicit about that. <br>
<br>
On Sat, Jan 27, 2024, at 16:56, Simon Peyton Jones wrote:<br>
> To me this looks uncontroversial. <br>
> • We have a currently-deprecated extension -XPatternSignatures<br>
> • This proposal rehabilitates it (with a narrower scope than before) <br>
> and adds a new one -XPatternSignatureBinds<br>
> • If you don't use these extensions they won't harm you<br>
> • The behaviour of -XScopedTypeVariables is unchanged<br>
> It's a fairly tiny thing, easy to implement, easy to document. I don't <br>
> care very much, but I'm content to approve it.<br>
><br>
> My only regret is that we don't have a "warning form" for language <br>
> extensions (see <br>
> <a href="https://github.com/ghc-proposals/ghc-proposals/pull/620" rel="noreferrer" target="_blank">https://github.com/ghc-proposals/ghc-proposals/pull/620</a>) . I'd like to <br>
> say -WPatternSignatureBinds, meaning to allow pattern-signatures to <br>
> bind, but warn on every such occasion. Lacking such a "warning form" <br>
> we have to *also* have `-Wpattern-signature-binds`.<br>
><br>
> Eric, I'm not sure what specifically you are objecting to. Are you <br>
> making a philosophical point, or is there active harm here?<br>
><br>
> Simon<br>
><br>
> On Sat, 27 Jan 2024 at 19:44, Eric Seidel <<a href="mailto:eric@seidel.io" target="_blank">eric@seidel.io</a>> wrote:<br>
>> 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>