I'm also happily in favour, for the reason Joachim articulates. Adam On 24/01/2024 18:24, Joachim Breitner wrote:

Hi,

Am Mittwoch, dem 24.01.2024 um 17:32 +0000 schrieb Richard Eisenberg:

...

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

unless I am mistaken, this proposal will also un-deprecated -XPatternSignatures, and give it the semantics I asked for in #119: allow me to write

foo :: Monad m => m Int foo = do list :: String <- return "" return $ length list

without treading into type variable territory, having to turn on ScopedTypeVariables or anything like that. Finally!

So it also makes me a bit happy; in favor.

Cheers, Joachim

-- Adam Gundry, Haskell Consultant Well-Typed LLP, https://www.well-typed.com/ Registered in England & Wales, OC335890 27 Old Gloucester Street, London WC1N 3AX, England

Do we envision, maybe, a future with `-XPatternSignature`, in a version that is incapable of binding and `-XTypeAbstractions`? If so, the split sounds like a reasonable move. Otherwise, the benefit of the split sounds rather slim, and it would need to be weighed against the costs and benefits on the implementation. On Thu, 25 Jan 2024 at 07:07, Moritz Angermann wrote:

As this is guarded behind a language extension and as such should not impact any existing code. I'm happy to see this change.

On Thu, 25 Jan 2024 at 04:43, Adam Gundry wrote:

...

I'm also happily in favour, for the reason Joachim articulates.

Adam

On 24/01/2024 18:24, Joachim Breitner wrote:

...

Hi,

Am Mittwoch, dem 24.01.2024 um 17:32 +0000 schrieb Richard Eisenberg:

...

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

unless I am mistaken, this proposal will also un-deprecated -XPatternSignatures, and give it the semantics I asked for in #119: allow me to write

foo :: Monad m => m Int foo = do list :: String <- return "" return $ length list

without treading into type variable territory, having to turn on ScopedTypeVariables or anything like that. Finally!

So it also makes me a bit happy; in favor.

Cheers, Joachim

-- Adam Gundry, Haskell Consultant Well-Typed LLP, https://www.well-typed.com/

Registered in England & Wales, OC335890 27 Old Gloucester Street, London WC1N 3AX, England

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

-- Arnaud Spiwack Director, Research at https://moduscreate.com and https://tweag.io.

What I was asking was whether we imagined that `-XPatternSignatures` without the ability to bind would be in a future `GHC20xx`, but we don't think that `-XPatternSignature` with the ability to bind ought to. (and I was musing that the ability to bind would be replaced by `-XTypeAbstractions`). On Fri, 26 Jan 2024 at 16:43, Richard Eisenberg wrote:

I'm not sure I understand Arnaud's question here: this proposal removes the binding capability from -XPatternSignatures. I don't think there's an interaction with -XTypeAbstractions.

On Fri, Jan 26, 2024 at 3:04 AM Arnaud Spiwack wrote:

...

Do we envision, maybe, a future with `-XPatternSignature`, in a version that is incapable of binding and `-XTypeAbstractions`? If so, the split sounds like a reasonable move. Otherwise, the benefit of the split sounds rather slim, and it would need to be weighed against the costs and benefits on the implementation.

On Thu, 25 Jan 2024 at 07:07, Moritz Angermann < moritz.angermann@gmail.com> wrote:

...

As this is guarded behind a language extension and as such should not impact any existing code. I'm happy to see this change.

On Thu, 25 Jan 2024 at 04:43, Adam Gundry wrote:

...

I'm also happily in favour, for the reason Joachim articulates.

Adam

On 24/01/2024 18:24, Joachim Breitner wrote:

...

Hi,

Am Mittwoch, dem 24.01.2024 um 17:32 +0000 schrieb Richard Eisenberg:

...

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

unless I am mistaken, this proposal will also un-deprecated -XPatternSignatures, and give it the semantics I asked for in #119: allow me to write

foo :: Monad m => m Int foo = do list :: String <- return "" return $ length list

without treading into type variable territory, having to turn on ScopedTypeVariables or anything like that. Finally!

So it also makes me a bit happy; in favor.

Cheers, Joachim

-- Adam Gundry, Haskell Consultant Well-Typed LLP, https://www.well-typed.com/

Registered in England & Wales, OC335890 27 Old Gloucester Street, London WC1N 3AX, England

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

-- Arnaud Spiwack Director, Research at https://moduscreate.com and https://tweag.io. _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

-- Arnaud Spiwack Director, Research at https://moduscreate.com and https://tweag.io.

I would argue that we should be willing to remove (mis)features from future GHC20xx editions, and that (the PatternSignatureBinds component of) ScopedTypeVariables is potentially such a misfeature. Of course that could be quite a disruptive change, so for now I'm happy to see this proposal accepted so that we have at least the option of a more principled language design in the future. Incidentally, I respectfully disagree with Richard's characterisation of this proposal as merely promoting a warning to be an extension. That would be true if PatternSignatureBinds/ScopedTypeVariables was a conservative extension, but it isn't - enabling the extension can change the meaning of existing programs [1]. Adam [1] https://gist.github.com/adamgundry/5446f390ee84254c43a0425e821dc930 On 26/01/2024 19:30, Richard Eisenberg wrote:

Well, -XScopedTypeVariables is in GHC2021, and I think we're generally imagining increasing the size of this subset, not decreasing it. So the case you're wondering about (where we'd want one but not the other) seems unlikely to me.

On the other hand, if I generalize your question a bit to think about whether we'd want one but not the other in some language edition as in https://github.com/ghc-proposals/ghc-proposals/pull/628 https://github.com/ghc-proposals/ghc-proposals/pull/628, then quite possibly. But if we go in that direction, the precise arrangement of language extensions matters not so much, because that view of the world removes language extensions from the set of things a user should be worrying about.

Richard

On Fri, Jan 26, 2024 at 11:10 AM Arnaud Spiwack mailto:arnaud.spiwack@tweag.io> wrote:

What I was asking was whether we imagined that `-XPatternSignatures` without the ability to bind would be in a future `GHC20xx`, but we don't think that `-XPatternSignature` with the ability to bind ought to. (and I was musing that the ability to bind would be replaced by `-XTypeAbstractions`).

On Fri, 26 Jan 2024 at 16:43, Richard Eisenberg mailto:reisenberg@janestreet.com> wrote:

I'm not sure I understand Arnaud's question here: this proposal removes the binding capability from -XPatternSignatures. I don't think there's an interaction with -XTypeAbstractions.

On Fri, Jan 26, 2024 at 3:04 AM Arnaud Spiwack mailto:arnaud.spiwack@tweag.io> wrote:

Do we envision, maybe, a future with `-XPatternSignature`, in a version that is incapable of binding and `-XTypeAbstractions`? If so, the split sounds like a reasonable move. Otherwise, the benefit of the split sounds rather slim, and it would need to be weighed against the costs and benefits on the implementation.

On Thu, 25 Jan 2024 at 07:07, Moritz Angermann mailto:moritz.angermann@gmail.com> wrote:

As this is guarded behind a language extension and as such should not impact any existing code. I'm happy to see this change.

On Thu, 25 Jan 2024 at 04:43, Adam Gundry mailto:adam@well-typed.com> wrote:

I'm also happily in favour, for the reason Joachim articulates.

Adam

On 24/01/2024 18:24, Joachim Breitner wrote: > Hi, > > Am Mittwoch, dem 24.01.2024 um 17:32 +0000 schrieb Richard Eisenberg: >> - 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. :) > > unless I am mistaken, this proposal will also un-deprecated > -XPatternSignatures, and give it the semantics I asked for in #119: > allow me to write > >     foo :: Monad m => m Int >     foo = do >       list :: String <- return "" >       return $ length list > > without treading into type variable territory, having to turn on > ScopedTypeVariables or anything like that. Finally! > > > So it also makes me a bit happy; in favor. > > Cheers, > Joachim > >

-- Adam Gundry, Haskell Consultant Well-Typed LLP, https://www.well-typed.com/ Registered in England & Wales, OC335890 27 Old Gloucester Street, London WC1N 3AX, England

Does this one have a purpose? Well, yes. It allows people who want pattern signatures that do not bind to have pattern signatures that do not bind. Given that it is easy to specify, and easy to implement, I'm inclined to give them their wishes. Having lots of combinations be possible (for users who care to specify them), as GHC has historically done, is fully compatible with language editions that embody a particular set of choices. I like language editions, but I don't see them as a reason to restrict choice. (If it was hard to implement something that would be a strike against choice; but that's not at issue here.) I don't think this particular issue is worth burning many cycles over :-). Let's just accept and move on. Simon On Mon, 29 Jan 2024 at 09:36, Arnaud Spiwack wrote:

On Fri, 26 Jan 2024 at 21:14, Adam Gundry wrote:

...

I would argue that we should be willing to remove (mis)features from future GHC20xx editions, and that (the PatternSignatureBinds component of) ScopedTypeVariables is potentially such a misfeature.

I agree (in fact, I'd say that it's the whole point of language editions). Hence my question :-) .

I don't, however, agree that we should make arguments on the grounds of the swiss-army-knife philosophy (“make it possible to customise GHC to everybody's desires”). I think that 2023 has been a convincing demonstration that this philosophy hasn't served us well, and has been counterproductive. Actually, I was under the impression that all the discourse about basing our stability guarantees on language editions was a definite adoption of the newer point of view. It does seem, though, that we're not yet in complete agreement there.

I'm content to concede here, but you'll have noticed in my recent interventions that I'm increasingly prudent about entropy-increasing changes (I'm worried, I guess, about death by a thousand paper cuts). I'd rather changes that we accept have a purpose. Does this one have a purpose? _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

To me this looks uncontroversial. - We have a currently-deprecated extension -XPatternSignatures - This proposal rehabilitates it (with a narrower scope than before) and adds a new one -XPatternSignatureBinds - If you don't use these extensions they won't harm you - The behaviour of -XScopedTypeVariables is unchanged 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. My only regret is that we don't have a "warning form" for language extensions (see https://github.com/ghc-proposals/ghc-proposals/pull/620) . 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`. Eric, I'm not sure what specifically you are objecting to. Are you making a philosophical point, or is there active harm here? Simon On Sat, 27 Jan 2024 at 19:44, Eric Seidel wrote:

The motivation for this change does not make sense to me. ScopedTypeVariables is used everywhere and is even part of GHC2021. The goal of this change appears to be to extract out a controversial piece of PatternSignatures such that it could be later removed entirely, but without addressing the issue of ScopedTypeVariables.

That's going about it the wrong way IMO. If we want to remove the behavior this proposal calls PatternSignatureBinds, the Committee should first adopt a resolution that we will remove (or alter the meaning of) ScopedTypeVariables in the next GHC20xx. If we get agreement on that, then this proposal could make sense as a step towards the broader goal.

Outside of that broader agreement though, this feels more like a fork-inducing proposal and I would vote against.

On Wed, Jan 24, 2024, at 11:32, Richard Eisenberg 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@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

---

ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

When I review a proposal for a new extension, one of the questions I ask myself is "would I eventually support including this in a GHC20xx standard?" If the answer is no (and if the extension is not one of the advanced or niche things like CPP), then I'm much less likely to support it. Aha. Now I understand your point thanks. In the glorious future, what do we want? - 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! - Plan B. Pattern signatures never bring anything into scope. To do that, use @type patterns. For example, instead of f (Just (x::a)) = rhs say f (Just @a x) = rhs Now it's clear that `a` is being brought into scope. I lean towards Plan B, but you raise a good point. I'd love to know what our consensus is. RSVP steering committee members. Simon On Sun, 28 Jan 2024 at 00:12, Eric Seidel wrote:

I think it's mostly a philosophical point. We have GHC2021 which is the current "blessed" version of the language. It includes ScopedTypeVariables, which if I understand correctly is a superset of PatternSigs. We also want to move in the direction of having *fewer* interacting extensions. In my mind that is one of the main motivations for introducing the GHC20xx standards. When I review a proposal for a new extension, one of the questions I ask myself is "would I eventually support including this in a GHC20xx standard?" If the answer is no (and if the extension is not one of the advanced or niche things like CPP), then I'm much less likely to support it.

So what is the purpose of refactoring extensions that are implied by ScopedTypeVariables? It seems like needless churn if ScopedTypeVariables is here to stay. On the other hand, if we mean to change ScopedTypeVariables we should be explicit about that.

...

To me this looks uncontroversial. • We have a currently-deprecated extension -XPatternSignatures • This proposal rehabilitates it (with a narrower scope than before) and adds a new one -XPatternSignatureBinds • If you don't use these extensions they won't harm you • The behaviour of -XScopedTypeVariables is unchanged 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.

My only regret is that we don't have a "warning form" for language extensions (see https://github.com/ghc-proposals/ghc-proposals/pull/620) . 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`.

Eric, I'm not sure what specifically you are objecting to. Are you making a philosophical point, or is there active harm here?

Simon

On Sat, 27 Jan 2024 at 19:44, Eric Seidel wrote:

...

The motivation for this change does not make sense to me. ScopedTypeVariables is used everywhere and is even part of GHC2021. The goal of this change appears to be to extract out a controversial piece of PatternSignatures such

On Sat, Jan 27, 2024, at 16:56, Simon Peyton Jones wrote: that it

...

...

could be later removed entirely, but without addressing the issue of ScopedTypeVariables.

That's going about it the wrong way IMO. If we want to remove the behavior this proposal calls PatternSignatureBinds, the Committee should first adopt a resolution that we will remove (or alter the meaning of) ScopedTypeVariables in the next GHC20xx. If we get agreement on that, then this proposal could make sense as a step towards the broader goal.

Outside of that broader agreement though, this feels more like a fork-inducing proposal and I would vote against.

On Wed, Jan 24, 2024, at 11:32, Richard Eisenberg 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@haskell.org

https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org

https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

It's clear that a lot of existing code expects A. Deprecating PatternSignatureBinds/ScopedTypeVariables is surely off the table for the foreseeable future, because it would be much too disruptive. But it would be a shame if GHC didn't make it *possible* to do B, which is all this proposal entails. I think it's too early to say whether removing PatternSignatureBinds/ScopedTypeVariables from a future GHC20xx will be a good idea at some point. It's conceivable, because as we've discussed before, it is possible to remove features from future GHC20xx editions without breaking existing code and while still supporting the features for backwards compatibility (perhaps indefinitely). And that should be enough to justify accepting this proposal IMHO. Adam On 29/01/2024 00:50, Eric Seidel wrote:

Yep that’s the question.

If we were starting from scratch I would agree that B is better. But I worry that there may be a lot of code out there that expects A.

So then this becomes a question of tradeoffs, is the simplification benefit of this change sufficient to justify the migration cost we may be imposing on the community?

It seems unlikely to me.

Sent from my iPhone

...

On Jan 28, 2024, at 12:22, Simon Peyton Jones wrote:



When I review a proposal for a new extension, one of the questions I ask myself is "would I eventually support including this in a GHC20xx standard?" If the answer is no (and if the extension is not one of the advanced or niche things like CPP), then I'm much less likely to support it.

Aha.  Now I understand your point thanks.

In the glorious future, what do we want?

* 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!

* Plan B.   Pattern signatures never bring anything into scope.  To do that, use @type patterns.  For example, instead of     f (Just (x::a)) = rhs say     f (Just @a x) = rhs Now it's clear that `a` is being brought into scope.

I lean towards Plan B, but you raise a good point.  I'd love to know what our consensus is.   RSVP steering committee members.

Simon

On Sun, 28 Jan 2024 at 00:12, Eric Seidel mailto:eric@seidel.io> wrote:

I think it's mostly a philosophical point. We have GHC2021 which is the current "blessed" version of the language. It includes ScopedTypeVariables, which if I understand correctly is a superset of PatternSigs. We also want to move in the direction of having *fewer* interacting extensions. In my mind that is one of the main motivations for introducing the GHC20xx standards. When I review a proposal for a new extension, one of the questions I ask myself is "would I eventually support including this in a GHC20xx standard?" If the answer is no (and if the extension is not one of the advanced or niche things like CPP), then I'm much less likely to support it.

So what is the purpose of refactoring extensions that are implied by ScopedTypeVariables? It seems like needless churn if ScopedTypeVariables is here to stay. On the other hand, if we mean to change ScopedTypeVariables we should be explicit about that.

On Sat, Jan 27, 2024, at 16:56, Simon Peyton Jones wrote: > To me this looks uncontroversial. >  • We have a currently-deprecated extension -XPatternSignatures >  • This proposal rehabilitates it (with a narrower scope than before) > and adds a new one -XPatternSignatureBinds >  • If you don't use these extensions they won't harm you >  • The behaviour of -XScopedTypeVariables is unchanged > 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. > > My only regret is that we don't have a "warning form" for language > extensions (see > https://github.com/ghc-proposals/ghc-proposals/pull/620 https://github.com/ghc-proposals/ghc-proposals/pull/620) . 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`. > > Eric, I'm not sure what specifically you are objecting to.  Are you > making a philosophical point, or is there active harm here? > > Simon > > On Sat, 27 Jan 2024 at 19:44, Eric Seidel mailto:eric@seidel.io> wrote: >> The motivation for this change does not make sense to me. ScopedTypeVariables >> is used everywhere and is even part of GHC2021. The goal of this change appears >> to be to extract out a controversial piece of PatternSignatures such that it >> could be later removed entirely, but without addressing the issue of >> ScopedTypeVariables. >> >> That's going about it the wrong way IMO. If we want to remove the behavior >> this proposal calls PatternSignatureBinds, the Committee should first adopt >> a resolution that we will remove (or alter the meaning of) ScopedTypeVariables >> in the next GHC20xx. If we get agreement on that, then this proposal could make >> sense as a step towards the broader goal. >> >> Outside of that broader agreement though, this feels more like a fork-inducing >> proposal and I would vote against. >> >> On Wed, Jan 24, 2024, at 11:32, Richard Eisenberg wrote: >> > John Ericson has submitted proposal #608 >> > <https://github.com/ghc-proposals/ghc-proposals/pull/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

-- Adam Gundry, Haskell Consultant Well-Typed LLP, https://www.well-typed.com/ Registered in England & Wales, OC335890 27 Old Gloucester Street, London WC1N 3AX, England

"Only exceptionally would we fix a design flaw in a way that breaks programs compiled with existing language editions." https://github.com/ghc-proposals/ghc-proposals/blob/wip/general-rules/princi... This is not exceptional is it? It's just a regular design flaw :) If we must fix it, let's do it in a way that complies with the stability principle. Cheers Simon On Mon, 29 Jan 2024 at 11:15, Joachim Breitner wrote:

Hi,

Am Montag, dem 29.01.2024 um 11:03 +0000 schrieb Simon Marlow:

...

I might be a bit confused, but doesn't this proposal change the meaning of an existing extension (PatternSignatures)?

a long-ago deprecated one:

~ $ ghci GHCi, version 9.4.8: https://www.haskell.org/ghc/ :? for help ghci> :set -XPatternSignatures

<no location info>: warning: [-Wdeprecated-flags] -XPatternSignatures is deprecated: use -XScopedTypeVariables or pragma {-# LANGUAGE ScopedTypeVariables #-} instead

Hopefully our stability principles does not require us to heed programs that ignored deprecation flags for a while?

My understanding of

https://github.com/ghc-proposals/ghc-proposals/blob/wip/general-rules/princi... is that, despite “stable package” not saying “does not use features deprecated long ago”, it’s still ok to break such programs, as this is our mechanism GR3?

Of course we could side-step this procedural question about repurposing an old extension and introduce `SimplePatternSignatures` instead. Not in favor, simply because as a user I more than once intuitively reached for `PatternSignatures` to get the proposed behavior.

Cheers, Joachim

-- Joachim Breitner mail@joachim-breitner.de http://www.joachim-breitner.de/

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

Hmm, deciding that the stability principles don't apply to pre-existing deprecations would not be in the right spirit, if you ask me. I think we should apply the rules consistently to every proposal going forward, being already deprecated doesn't get you a pass. In this case we really don't have to break existing code, so let's not do it. It's not that hard to make a new extension or to change the behaviour in GHC2024 is it? Cheers Simon On Mon, 29 Jan 2024 at 11:42, Joachim Breitner wrote:

Hi,

well, we were more liberal at deprecating things in the past than we will be under the new regime, and we might not have invoked GR2 here.

But the extension already _is_ deprecated. If deprecating (even for the wrong reasons) and waiting multiple releases does not allow us to break the deprecated thing, then what is the point of GR3?

I am quite fond of the new stability regime, it sets out clear requirements on code (set a language flag, heed deprecation warnings, although the latter could be spelled out more explicitly), in return for clear promises. Let’s not water this down by not taking the set of requirements of requirements seriously ourselves.

Cheers, Joachim

...

"Only exceptionally would we fix a design flaw in a way that breaks

Am Montag, dem 29.01.2024 um 11:32 +0000 schrieb Simon Marlow: programs compiled with existing language editions." https://github.com/ghc-proposals/ghc-proposals/blob/wip/general-rules/princi...

...

This is not exceptional is it? It's just a regular design flaw :) If we

must fix it, let's do it in a way that complies with the stability principle.

...

Cheers Simon

On Mon, 29 Jan 2024 at 11:15, Joachim Breitner

...

...

Hi,

Am Montag, dem 29.01.2024 um 11:03 +0000 schrieb Simon Marlow:

...

I might be a bit confused, but doesn't this proposal change the meaning of an existing extension (PatternSignatures)?

a long-ago deprecated one:

~ $ ghci GHCi, version 9.4.8: https://www.haskell.org/ghc/ :? for help ghci> :set -XPatternSignatures

<no location info>: warning: [-Wdeprecated-flags] -XPatternSignatures is deprecated: use -XScopedTypeVariables or

wrote: pragma {-# LANGUAGE ScopedTypeVariables #-} instead

...

...

Hopefully our stability principles does not require us to heed programs that ignored deprecation flags for a while?

My understanding of

https://github.com/ghc-proposals/ghc-proposals/blob/wip/general-rules/princi...

...

is that, despite “stable package” not saying “does not use features deprecated long ago”, it’s still ok to break such programs, as this is our mechanism GR3?

Of course we could side-step this procedural question about repurposing an old extension and introduce `SimplePatternSignatures` instead. Not in favor, simply because as a user I more than once intuitively reached for `PatternSignatures` to get the proposed behavior.

Cheers, Joachim

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org

https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

-- Joachim Breitner mail@joachim-breitner.de http://www.joachim-breitner.de/

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

On Mon, 29 Jan 2024 at 13:56, Richard Eisenberg wrote:

Simon M:

deciding that the stability principles don't apply to pre-existing deprecations would not be in the right spirit, if you ask me

To me, it's in the spirit of "deprecation", if not stability. That is, what does it mean to deprecate a feature? I think it means that users should expect the feature to disappear at some point in the future; in other words, it explicitly labels a feature as non-stable. Up until now, we hadn't settled on a meaning of stability, and so by extension we hadn't settled on a meaning for deprecation. So maybe we say "the feature wasn't actually deprecated because we didn't know what *deprecated* meant", but I think this one has been labeled deprecated for long enough that we should feel comfortable removing it / changing it.

This raises an interesting distinction that I hadn't realised before (and sorry about the tangent but it seemed important to highlight). We may actually want two different kinds of deprecation: 1. Deprecated and may change in a future GHC release (GR3-style deprecation; we expect these to be rare) 2. Deprecated and may change in a future language edition (no impact on stability; doesn't require GR2 justification; more common) I kind of expected most existing deprecations would turn into (2) given the new stability requirements. Cheers Simon

---------------

My initial support for this proposal was based on the fact that it made a few people happy. Now it's become clear that it also makes a few people unhappy. I'm still hoping for a language-edition-based future https://github.com/ghc-proposals/ghc-proposals/pull/628 where this proposal doesn't matter, so I'm pretty agnostic. Maybe on balance it's a better use of time debating that potential future (I'll prepare a proper proposal this week) than to debate this finer point?

Richard

On Mon, Jan 29, 2024 at 8:07 AM Simon Marlow wrote:

...

Hmm, deciding that the stability principles don't apply to pre-existing deprecations would not be in the right spirit, if you ask me. I think we should apply the rules consistently to every proposal going forward, being already deprecated doesn't get you a pass. In this case we really don't have to break existing code, so let's not do it.

It's not that hard to make a new extension or to change the behaviour in GHC2024 is it?

Cheers Simon

On Mon, 29 Jan 2024 at 11:42, Joachim Breitner wrote:

...

Hi,

well, we were more liberal at deprecating things in the past than we will be under the new regime, and we might not have invoked GR2 here.

But the extension already _is_ deprecated. If deprecating (even for the wrong reasons) and waiting multiple releases does not allow us to break the deprecated thing, then what is the point of GR3?

I am quite fond of the new stability regime, it sets out clear requirements on code (set a language flag, heed deprecation warnings, although the latter could be spelled out more explicitly), in return for clear promises. Let’s not water this down by not taking the set of requirements of requirements seriously ourselves.

Cheers, Joachim

...

"Only exceptionally would we fix a design flaw in a way that breaks

Am Montag, dem 29.01.2024 um 11:32 +0000 schrieb Simon Marlow: programs compiled with existing language editions." https://github.com/ghc-proposals/ghc-proposals/blob/wip/general-rules/princi...

...

This is not exceptional is it? It's just a regular design flaw :) If

we must fix it, let's do it in a way that complies with the stability principle.

...

Cheers Simon

On Mon, 29 Jan 2024 at 11:15, Joachim Breitner <

...

...

Hi,

Am Montag, dem 29.01.2024 um 11:03 +0000 schrieb Simon Marlow:

...

I might be a bit confused, but doesn't this proposal change the meaning of an existing extension (PatternSignatures)?

a long-ago deprecated one:

~ $ ghci GHCi, version 9.4.8: https://www.haskell.org/ghc/ :? for help ghci> :set -XPatternSignatures

<no location info>: warning: [-Wdeprecated-flags] -XPatternSignatures is deprecated: use -XScopedTypeVariables or

...

...

Hopefully our stability principles does not require us to heed

mail@joachim-breitner.de> wrote: pragma {-# LANGUAGE ScopedTypeVariables #-} instead programs

...

...

that ignored deprecation flags for a while?

My understanding of

https://github.com/ghc-proposals/ghc-proposals/blob/wip/general-rules/princi...

...

is that, despite “stable package” not saying “does not use features deprecated long ago”, it’s still ok to break such programs, as this is our mechanism GR3?

Of course we could side-step this procedural question about repurposing an old extension and introduce `SimplePatternSignatures` instead. Not in favor, simply because as a user I more than once intuitively reached for `PatternSignatures` to get the proposed behavior.

Cheers, Joachim

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org

https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

-- Joachim Breitner mail@joachim-breitner.de http://www.joachim-breitner.de/

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

I see. So you are proposing - PatternSignatures = SimplePatternSignatures + PatternSignatureBinds That's fine with me. Simon On Wed, 31 Jan 2024 at 21:30, Adam Gundry wrote:

John responded to some of this discussion on the proposal:

https://github.com/ghc-proposals/ghc-proposals/pull/608#issuecomment-1919413... .

I think we should try to resolve this thread rather than leave it hanging. Given Simon's opposition to the idea of changing PatternSignatures, it seems to me the next best thing would be Joachim's observation that we could define a new extension SimplePatternSignatures (or however we call it) and modify #448 to use that instead. Perhaps that's a compromise we can live with? John indicates that he'd be happy with that outcome.

Cheers,

Adam

On 29/01/2024 15:30, Simon Marlow wrote:

...

On Mon, 29 Jan 2024 at 13:56, Richard Eisenberg mailto:reisenberg@janestreet.com> wrote:

Simon M:

deciding that the stability principles don't apply to pre-existing deprecations would not be in the right spirit, if you ask me

To me, it's in the spirit of "deprecation", if not stability. That is, what does it mean to deprecate a feature? I think it means that users should expect the feature to disappear at some point in the future; in other words, it explicitly labels a feature as non-stable. Up until now, we hadn't settled on a meaning of stability, and so by extension we hadn't settled on a meaning for deprecation. So maybe we say "the feature wasn't actually deprecated because we didn't know what /deprecated/ meant", but I think this one has been labeled deprecated for long enough that we should feel comfortable removing it / changing it.

This raises an interesting distinction that I hadn't realised before (and sorry about the tangent but it seemed important to highlight). We may actually want two different kinds of deprecation:

1. Deprecated and may change in a future GHC release (GR3-style deprecation; we expect these to be rare) 2. Deprecated and may change in a future language edition (no impact on stability; doesn't require GR2 justification; more common)

I kind of expected most existing deprecations would turn into (2) given the new stability requirements.

Cheers Simon

---------------

My initial support for this proposal was based on the fact that it made a few people happy. Now it's become clear that it also makes a few people unhappy. I'm still hoping for a language-edition-based future https://github.com/ghc-proposals/ghc-proposals/pull/628 where this proposal doesn't matter, so I'm pretty agnostic. Maybe on balance it's a better use of time debating that potential future (I'll prepare a proper proposal this week) than to debate this finer point?

Richard

On Mon, Jan 29, 2024 at 8:07 AM Simon Marlow mailto:marlowsd@gmail.com> wrote:

Hmm, deciding that the stability principles don't apply to pre-existing deprecations would not be in the right spirit, if you ask me. I think we should apply the rules consistently to every proposal going forward, being already deprecated doesn't get you a pass. In this case we really don't have to break existing code, so let's not do it.

It's not that hard to make a new extension or to change the behaviour in GHC2024 is it?

Cheers Simon

On Mon, 29 Jan 2024 at 11:42, Joachim Breitner mailto:mail@joachim-breitner.de> wrote:

Hi,

well, we were more liberal at deprecating things in the past than we will be under the new regime, and we might not have invoked GR2 here.

But the extension already _is_ deprecated. If deprecating (even for the wrong reasons) and waiting multiple releases does not allow us to break the deprecated thing, then what is the point of GR3?

I am quite fond of the new stability regime, it sets out clear requirements on code (set a language flag, heed deprecation warnings, although the latter could be spelled out more explicitly), in return for clear promises. Let’s not water this down by not taking the set of requirements of requirements seriously ourselves.

Cheers, Joachim

Am Montag, dem 29.01.2024 um 11:32 +0000 schrieb Simon Marlow: > "Only exceptionally would we fix a design flaw in a way that breaks programs compiled with existing language editions."

https://github.com/ghc-proposals/ghc-proposals/blob/wip/general-rules/princi... < https://github.com/ghc-proposals/ghc-proposals/blob/wip/general-rules/princi...

...

> > This is not exceptional is it? It's just a regular design flaw :) If we must fix it, let's do it in a way that complies with the stability principle. > > Cheers > Simon > > > On Mon, 29 Jan 2024 at 11:15, Joachim Breitner mailto:mail@joachim-breitner.de> wrote: > > Hi, > > > > Am Montag, dem 29.01.2024 um 11:03 +0000 schrieb Simon Marlow: > > > I might be a bit confused, but doesn't this proposal change the meaning of an existing > > > extension (PatternSignatures)? > > > > a long-ago deprecated one: > > > > ~ $ ghci > > GHCi, version 9.4.8: https://www.haskell.org/ghc/ https://www.haskell.org/ghc/ :? for help > > ghci> :set -XPatternSignatures > > > > <no location info>: warning: [-Wdeprecated-flags] > > -XPatternSignatures is deprecated: use -XScopedTypeVariables or pragma {-# LANGUAGE ScopedTypeVariables #-} instead > > > > Hopefully our stability principles does not require us to heed programs > > that ignored deprecation flags for a while? > > > > My understanding of > >

https://github.com/ghc-proposals/ghc-proposals/blob/wip/general-rules/princi... < https://github.com/ghc-proposals/ghc-proposals/blob/wip/general-rules/princi...

...

> > is that, despite “stable package” not saying “does not use features > > deprecated long ago”, it’s still ok to break such programs, as this is > > our mechanism GR3? > > > > > > Of course we could side-step this procedural question about repurposing > > an old extension and introduce `SimplePatternSignatures` instead. Not > > in favor, simply because as a user I more than once intuitively reached > > for `PatternSignatures` to get the proposed behavior. > > > > Cheers, > > Joachim

-- Adam Gundry, Haskell Consultant Well-Typed LLP, https://www.well-typed.com/

Registered in England & Wales, OC335890 27 Old Gloucester Street, London WC1N 3AX, England

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee