Proposal #556 recommendation: accept

Hi all, Vlad has proposed https://github.com/ghc-proposals/ghc-proposals/pull/556, an amendment to recently accepted proposal #448 on scoped type variables. It adds a nuance saying that f (MkT @(a :: <<here>>)) = ... should have the same scoping behavior as f (MkT (x :: <<here>>)) = ... Note that the first is a kind signature of a visible-type-application-in-a-pattern, while the second is a pattern signature. The intended scoping rule says that the use of an in-scope type variable in these positions is an occurrence, while the use of an out-of-scope type variable brings that variable into scope. Vlad's proposal corrects the phrasing in the original proposal that aligns the treatment of the kind signature with the type it is describing, forbidding e.g. the use of a repeated variable in the kind signature. Vlad's amendment makes the proposal what I had intended when I wrote #448; I strongly recommend acceptance. I think this is a small tweak of a technical detail buried in #448 and hope this does not cause widespread debate. I will accept this proposal in a week if I don't hear objections. Thanks! Richard

Am Donnerstag, dem 02.02.2023 um 12:40 +0000 schrieb Richard Eisenberg:
Vlad's amendment makes the proposal what I had intended when I wrote #448; I strongly recommend acceptance.
I concur! -- Joachim Breitner mail@joachim-breitner.de http://www.joachim-breitner.de/

I concur!
Simon
On Thu, 2 Feb 2023 at 12:40, Richard Eisenberg
Hi all,
Vlad has proposed https://github.com/ghc-proposals/ghc-proposals/pull/556, an amendment to recently accepted proposal #448 on scoped type variables. It adds a nuance saying that
f (MkT @(a :: <<here>>)) = ...
should have the same scoping behavior as
f (MkT (x :: <<here>>)) = ...
Note that the first is a kind signature of a visible-type-application-in-a-pattern, while the second is a pattern signature. The intended scoping rule says that the use of an in-scope type variable in these positions is an occurrence, while the use of an out-of-scope type variable brings that variable into scope. Vlad's proposal corrects the phrasing in the original proposal that aligns the treatment of the kind signature with the type it is describing, forbidding e.g. the use of a repeated variable in the kind signature.
Vlad's amendment makes the proposal what I had intended when I wrote #448; I strongly recommend acceptance.
I think this is a small tweak of a technical detail buried in #448 and hope this does not cause widespread debate. I will accept this proposal in a week if I don't hear objections.
Thanks! Richard _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

Me too. +1
On 2 Feb 2023, at 13:00, Simon Peyton Jones
wrote: I concur!
Simon
On Thu, 2 Feb 2023 at 12:40, Richard Eisenberg
mailto:lists@richarde.dev> wrote: Hi all,
Vlad has proposed https://github.com/ghc-proposals/ghc-proposals/pull/556, an amendment to recently accepted proposal #448 on scoped type variables. It adds a nuance saying that
f (MkT @(a :: <<here>>)) = ...
should have the same scoping behavior as
f (MkT (x :: <<here>>)) = ...
Note that the first is a kind signature of a visible-type-application-in-a-pattern, while the second is a pattern signature. The intended scoping rule says that the use of an in-scope type variable in these positions is an occurrence, while the use of an out-of-scope type variable brings that variable into scope. Vlad's proposal corrects the phrasing in the original proposal that aligns the treatment of the kind signature with the type it is describing, forbidding e.g. the use of a repeated variable in the kind signature.
Vlad's amendment makes the proposal what I had intended when I wrote #448; I strongly recommend acceptance.
I think this is a small tweak of a technical detail buried in #448 and hope this does not cause widespread debate. I will accept this proposal in a week if I don't hear objections.
Thanks! Richard _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org mailto: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

With several votes in favor and nothing against, I declare this to be accepted. Joachim, would you mind merging? I'm in a train and cannot easily do so from here. Thanks! Richard
On Feb 2, 2023, at 9:31 AM, Chris Dornan
wrote: Me too. +1
On 2 Feb 2023, at 13:00, Simon Peyton Jones
wrote: I concur!
Simon
On Thu, 2 Feb 2023 at 12:40, Richard Eisenberg
mailto:lists@richarde.dev> wrote: Hi all, Vlad has proposed https://github.com/ghc-proposals/ghc-proposals/pull/556 https://github.com/ghc-proposals/ghc-proposals/pull/556, an amendment to recently accepted proposal #448 on scoped type variables. It adds a nuance saying that
f (MkT @(a :: <<here>>)) = ...
should have the same scoping behavior as
f (MkT (x :: <<here>>)) = ...
Note that the first is a kind signature of a visible-type-application-in-a-pattern, while the second is a pattern signature. The intended scoping rule says that the use of an in-scope type variable in these positions is an occurrence, while the use of an out-of-scope type variable brings that variable into scope. Vlad's proposal corrects the phrasing in the original proposal that aligns the treatment of the kind signature with the type it is describing, forbidding e.g. the use of a repeated variable in the kind signature.
Vlad's amendment makes the proposal what I had intended when I wrote #448; I strongly recommend acceptance.
I think this is a small tweak of a technical detail buried in #448 and hope this does not cause widespread debate. I will accept this proposal in a week if I don't hear objections.
Thanks! Richard _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org mailto:ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee 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
participants (4)
-
Chris Dornan
-
Joachim Breitner
-
Richard Eisenberg
-
Simon Peyton Jones