Please review #370: Syntax for Modifiers, Shepherd: Alejandro
Dear Committee, this is your secretary speaking: A syntax for modifiers has been proposed by Richard Eisenberg (this time it’s true) https://github.com/ghc-proposals/ghc-proposals/pull/370 https://dfinity.slack.com/archives/C01BJ73A893/p1605922403340800?thread_ts=1... I’ll propose Alejandro as the shepherd, as he has looked at i t in detail already. Please guide us to a conclusion as outlined in https://github.com/ghc-proposals/ghc-proposals#committee-process Thanks, Joachim -- Joachim Breitner mail@joachim-breitner.de http://www.joachim-breitner.de/
Dear all, This proposal suggests adding syntax for a general notion of modifiers, like the ones we’ve been talking about lately affecting linearity or matchability of arrows. For example, if linear types and unsaturated families are accepted as they stand, we would have `Int #1 -> @U Bool` (or something like that), whereas with this proposal we would have the more uniform `Int %1 %Unmatchable -> Bool`. Since the amount of modifiers is likely to increase in the future, I think it’s a great idea to agree and reserve such syntax, instead of coming up with different ways on each proposal. I thus recommend acceptance of this proposal. The proposal itself: (1) introduces syntax for modifiers in types and defines how to type/kind check them, (2) reserved such syntax for other uses in declarations and terms. I think the proposal still has its merits only with (1), even though I lean towards accepting both parts of it. Regards, Alejandro On 21 Nov 2020 at 10:07:18, Joachim Breitner <mail@joachim-breitner.de> wrote:
Dear Committee,
this is your secretary speaking:
A syntax for modifiers has been proposed by Richard Eisenberg (this time it’s true) https://github.com/ghc-proposals/ghc-proposals/pull/370
https://dfinity.slack.com/archives/C01BJ73A893/p1605922403340800?thread_ts=1...
I’ll propose Alejandro as the shepherd, as he has looked at i t in detail already.
Please guide us to a conclusion as outlined in https://github.com/ghc-proposals/ghc-proposals#committee-process
Thanks, 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
I've got to say that I'm rather uncomfortable with the type-based meaning ascription of this proposal. That being said, we do need a lightweight way to add such modifiers to arrows (and anything which can appear to the left of an arrows such as fields of data constructors, whether in record notation or not (though I'm fine with requiring GADT notation when not a record, that's what we did with Linear Types)). There is a staggering amount of possible such modifiers which have been conceptualised. By far, this is the least awful such proposal that I've seen. It's the first time that such a proposal looks even remotely usable. So the pragmatic in me is inclined to accept as well. The need for such a lightweight mechanism to annotate terms, though, is quite a bit less clear to me. Because type disambiguation is rather novel in GHC, I'd rather be prudent in this area, and stage the term bits as future work. Keep the design, and revisit it once we have experience with the mechanism for arrow modifiers. On Thu, Nov 26, 2020 at 8:58 PM Alejandro Serrano Mena <trupill@gmail.com> wrote:
Dear all, This proposal suggests adding syntax for a general notion of modifiers, like the ones we’ve been talking about lately affecting linearity or matchability of arrows. For example, if linear types and unsaturated families are accepted as they stand, we would have `Int #1 -> @U Bool` (or something like that), whereas with this proposal we would have the more uniform `Int %1 %Unmatchable -> Bool`.
Since the amount of modifiers is likely to increase in the future, I think it’s a great idea to agree and reserve such syntax, instead of coming up with different ways on each proposal. I thus recommend acceptance of this proposal.
The proposal itself: (1) introduces syntax for modifiers in types and defines how to type/kind check them, (2) reserved such syntax for other uses in declarations and terms.
I think the proposal still has its merits only with (1), even though I lean towards accepting both parts of it.
Regards, Alejandro
On 21 Nov 2020 at 10:07:18, Joachim Breitner <mail@joachim-breitner.de> wrote:
Dear Committee,
this is your secretary speaking:
A syntax for modifiers has been proposed by Richard Eisenberg (this time it’s true) https://github.com/ghc-proposals/ghc-proposals/pull/370
https://dfinity.slack.com/archives/C01BJ73A893/p1605922403340800?thread_ts=1...
I’ll propose Alejandro as the shepherd, as he has looked at i t in detail already.
Please guide us to a conclusion as outlined in https://github.com/ghc-proposals/ghc-proposals#committee-process
Thanks, 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
_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
Hi, Am Donnerstag, den 26.11.2020, 14:58 -0500 schrieb Alejandro Serrano Mena:
Dear all, This proposal suggests adding syntax for a general notion of modifiers, like the ones we’ve been talking about lately affecting linearity or matchability of arrows. For example, if linear types and unsaturated families are accepted as they stand, we would have `Int #1 -> @U Bool` (or something like that), whereas with this proposal we would have the more uniform `Int %1 %Unmatchable -> Bool`.
Since the amount of modifiers is likely to increase in the future, I think it’s a great idea to agree and reserve such syntax, instead of coming up with different ways on each proposal. I thus recommend acceptance of this proposal.
The proposal itself: (1) introduces syntax for modifiers in types and defines how to type/kind check them, (2) reserved such syntax for other uses in declarations and terms.
I think the proposal still has its merits only with (1), even though I lean towards accepting both parts of it.
I like the idea of reserving syntax here, but parts of the proposal smell a bit like premature generalization to me. Are we confident that all annotations we eventually would like to use with this feature can be expressed as types of a kind that is an instance of Modifier? Or should we reserve the ability to have annotations that don't fit that model? Would we ever have annotation that may affect phases earlier than than typechecking? What if we want to use (%type e) and (%data e) to help with the SingleNamepace issues? Look like useful annotations to me, but I am not sure if they fit the framework proposed here. The fact that we special-case %1 supports that. The proposal explicitly has to state “No modifier polymorphism!”. But isn't that indication that using the type system to model the various modifiers might be the wrong tool? I wonder if there is a way where the %(…) on it’s own only reserve syntax, and the various uses of that syntax can be disambiguated _statically_ based on the content of …. Not great syntax, because not concise, enough, but morally I’d feel more at ease with Int %(multiplicity Many) -> Int Int %(multiplicity 1) -> Int Int %(multiplicity m) -> Int where multiplicity is a modifier keyword, to express the existing features (including implicit generalization of m). Then we can extend this to Int %oneShot -> Int and Int %(matchability M) -> Int and maybe even foo (%type [a]) -- where foo :: forall a -> () which is a modifier that So at the moment, I am inclined to reject this proposal, until I am convinced that we are not painting ourselves into a “all modifiers are types of special kinds and that’s all the syntax and behaviour we ever need” corner. Minor detail: If we can annotate infix use of the (->) “type operator”, should we also be able to annotate other infix operators, i.e. constr ::= (btype | ! atype) {modifier} conop (btype | ! atype) infixexp ::= lexp {modifier} qop infixexp Cheers, Joachim -- Joachim Breitner mail@joachim-breitner.de http://www.joachim-breitner.de/
I left a few comments and questions on the PR itself, but I'm leaning towards rejecting the proposal in its current form as well. This doesn't (yet) feel like a generic mechanism, in particular because the only modifier that has been specified would be deeply wired into GHC itself. On Fri, Nov 27, 2020, at 04:46, Joachim Breitner wrote:
Hi,
Am Donnerstag, den 26.11.2020, 14:58 -0500 schrieb Alejandro Serrano Mena:
Dear all, This proposal suggests adding syntax for a general notion of modifiers, like the ones we’ve been talking about lately affecting linearity or matchability of arrows. For example, if linear types and unsaturated families are accepted as they stand, we would have `Int #1 -> @U Bool` (or something like that), whereas with this proposal we would have the more uniform `Int %1 %Unmatchable -> Bool`.
Since the amount of modifiers is likely to increase in the future, I think it’s a great idea to agree and reserve such syntax, instead of coming up with different ways on each proposal. I thus recommend acceptance of this proposal.
The proposal itself: (1) introduces syntax for modifiers in types and defines how to type/kind check them, (2) reserved such syntax for other uses in declarations and terms.
I think the proposal still has its merits only with (1), even though I lean towards accepting both parts of it.
I like the idea of reserving syntax here, but parts of the proposal smell a bit like premature generalization to me. Are we confident that all annotations we eventually would like to use with this feature can be expressed as types of a kind that is an instance of Modifier? Or should we reserve the ability to have annotations that don't fit that model?
Would we ever have annotation that may affect phases earlier than than typechecking? What if we want to use (%type e) and (%data e) to help with the SingleNamepace issues? Look like useful annotations to me, but I am not sure if they fit the framework proposed here.
The fact that we special-case %1 supports that.
The proposal explicitly has to state “No modifier polymorphism!”. But isn't that indication that using the type system to model the various modifiers might be the wrong tool?
I wonder if there is a way where the %(…) on it’s own only reserve syntax, and the various uses of that syntax can be disambiguated _statically_ based on the content of ….
Not great syntax, because not concise, enough, but morally I’d feel more at ease with
Int %(multiplicity Many) -> Int Int %(multiplicity 1) -> Int Int %(multiplicity m) -> Int
where multiplicity is a modifier keyword, to express the existing features (including implicit generalization of m). Then we can extend this to
Int %oneShot -> Int
and
Int %(matchability M) -> Int
and maybe even
foo (%type [a]) -- where foo :: forall a -> ()
which is a modifier that
So at the moment, I am inclined to reject this proposal, until I am convinced that we are not painting ourselves into a “all modifiers are types of special kinds and that’s all the syntax and behaviour we ever need” corner.
Minor detail: If we can annotate infix use of the (->) “type operator”, should we also be able to annotate other infix operators, i.e.
constr ::= (btype | ! atype) {modifier} conop (btype | ! atype) infixexp ::= lexp {modifier} qop infixexp
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
After some discussion in the GitHub thread, changes are going to arrive to the proposal. I think the best is to send the proposal back to the “Needs revision” state. Regards, Alejandro On 29 Nov 2020 at 23:12:44, Eric Seidel <eric@seidel.io> wrote:
I left a few comments and questions on the PR itself, but I'm leaning towards rejecting the proposal in its current form as well. This doesn't (yet) feel like a generic mechanism, in particular because the only modifier that has been specified would be deeply wired into GHC itself.
On Fri, Nov 27, 2020, at 04:46, Joachim Breitner wrote:
Hi,
Am Donnerstag, den 26.11.2020, 14:58 -0500 schrieb Alejandro Serrano
Mena:
Dear all,
This proposal suggests adding syntax for a general notion of
modifiers, like the ones we’ve been talking about lately affecting
linearity or matchability of arrows. For example, if linear types and
unsaturated families are accepted as they stand, we would have `Int
#1 -> @U Bool` (or something like that), whereas with this proposal
we would have the more uniform `Int %1 %Unmatchable -> Bool`.
Since the amount of modifiers is likely to increase in the future, I
think it’s a great idea to agree and reserve such syntax, instead of
coming up with different ways on each proposal. I thus recommend
acceptance of this proposal.
The proposal itself:
(1) introduces syntax for modifiers in types and defines how to
type/kind check them,
(2) reserved such syntax for other uses in declarations and terms.
I think the proposal still has its merits only with (1), even though
I lean towards accepting both parts of it.
I like the idea of reserving syntax here, but parts of the proposal
smell a bit like premature generalization to me. Are we confident that
all annotations we eventually would like to use with this feature can
be expressed as types of a kind that is an instance of Modifier? Or
should we reserve the ability to have annotations that don't fit that
model?
Would we ever have annotation that may affect phases earlier than than
typechecking? What if we want to use (%type e) and (%data e) to help
with the SingleNamepace issues? Look like useful annotations to me, but
I am not sure if they fit the framework proposed here.
The fact that we special-case %1 supports that.
The proposal explicitly has to state “No modifier polymorphism!”. But
isn't that indication that using the type system to model the various
modifiers might be the wrong tool?
I wonder if there is a way where the %(…) on it’s own only reserve
syntax, and the various uses of that syntax can be disambiguated
_statically_ based on the content of ….
Not great syntax, because not concise, enough, but morally I’d feel
more at ease with
Int %(multiplicity Many) -> Int
Int %(multiplicity 1) -> Int
Int %(multiplicity m) -> Int
where multiplicity is a modifier keyword, to express the existing
features (including implicit generalization of m). Then we can extend
this to
Int %oneShot -> Int
and
Int %(matchability M) -> Int
and maybe even
foo (%type [a]) -- where foo :: forall a -> ()
which is a modifier that
So at the moment, I am inclined to reject this proposal, until I am
convinced that we are not painting ourselves into a “all modifiers are
types of special kinds and that’s all the syntax and behaviour we ever
need” corner.
Minor detail: If we can annotate infix use of the (->) “type operator”,
should we also be able to annotate other infix operators, i.e.
constr ::= (btype | ! atype) {modifier} conop (btype | ! atype)
infixexp ::= lexp {modifier} qop infixexp
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
_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
To my surprise, I found myself leaning against. So I updated and simplified the proposal to remove Modifier. This makes modifiers a bit more magical, but more likely to actually work in practice. The type inference story previously may have been intractable. I've requested that the committee consider the updates in parallel with community feedback. Thanks, Richard
On Nov 30, 2020, at 2:36 PM, Alejandro Serrano Mena <trupill@gmail.com> wrote:
After some discussion in the GitHub thread, changes are going to arrive to the proposal. I think the best is to send the proposal back to the “Needs revision” state.
Regards, Alejandro
On 29 Nov 2020 at 23:12:44, Eric Seidel <eric@seidel.io <mailto:eric@seidel.io>> wrote: I left a few comments and questions on the PR itself, but I'm leaning towards rejecting the proposal in its current form as well. This doesn't (yet) feel like a generic mechanism, in particular because the only modifier that has been specified would be deeply wired into GHC itself.
On Fri, Nov 27, 2020, at 04:46, Joachim Breitner wrote:
Hi,
Am Donnerstag, den 26.11.2020, 14:58 -0500 schrieb Alejandro Serrano Mena:
Dear all, This proposal suggests adding syntax for a general notion of modifiers, like the ones we’ve been talking about lately affecting linearity or matchability of arrows. For example, if linear types and unsaturated families are accepted as they stand, we would have `Int #1 -> @U Bool` (or something like that), whereas with this proposal we would have the more uniform `Int %1 %Unmatchable -> Bool`.
Since the amount of modifiers is likely to increase in the future, I think it’s a great idea to agree and reserve such syntax, instead of coming up with different ways on each proposal. I thus recommend acceptance of this proposal.
The proposal itself: (1) introduces syntax for modifiers in types and defines how to type/kind check them, (2) reserved such syntax for other uses in declarations and terms.
I think the proposal still has its merits only with (1), even though I lean towards accepting both parts of it.
I like the idea of reserving syntax here, but parts of the proposal smell a bit like premature generalization to me. Are we confident that all annotations we eventually would like to use with this feature can be expressed as types of a kind that is an instance of Modifier? Or should we reserve the ability to have annotations that don't fit that model?
Would we ever have annotation that may affect phases earlier than than typechecking? What if we want to use (%type e) and (%data e) to help with the SingleNamepace issues? Look like useful annotations to me, but I am not sure if they fit the framework proposed here.
The fact that we special-case %1 supports that.
The proposal explicitly has to state “No modifier polymorphism!”. But isn't that indication that using the type system to model the various modifiers might be the wrong tool?
I wonder if there is a way where the %(…) on it’s own only reserve syntax, and the various uses of that syntax can be disambiguated _statically_ based on the content of ….
Not great syntax, because not concise, enough, but morally I’d feel more at ease with
Int %(multiplicity Many) -> Int Int %(multiplicity 1) -> Int Int %(multiplicity m) -> Int
where multiplicity is a modifier keyword, to express the existing features (including implicit generalization of m). Then we can extend this to
Int %oneShot -> Int
and
Int %(matchability M) -> Int
and maybe even
foo (%type [a]) -- where foo :: forall a -> ()
which is a modifier that
So at the moment, I am inclined to reject this proposal, until I am convinced that we are not painting ourselves into a “all modifiers are types of special kinds and that’s all the syntax and behaviour we ever need” corner.
Minor detail: If we can annotate infix use of the (->) “type operator”, should we also be able to annotate other infix operators, i.e.
constr ::= (btype | ! atype) {modifier} conop (btype | ! atype) infixexp ::= lexp {modifier} qop infixexp
Cheers, Joachim
-- Joachim Breitner mail@joachim-breitner.de <mailto:mail@joachim-breitner.de> http://www.joachim-breitner.de/ <http://www.joachim-breitner.de/>
_______________________________________________ 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 <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
I'm still a bit skeptical of the specifics around tying modifiers to types, but I think the proposal is well-motivated and that we should find *some* solution before arrows become too complex. On Mon, Nov 30, 2020, at 14:52, Richard Eisenberg wrote:
To my surprise, I found myself leaning against. So I updated and simplified the proposal to remove Modifier. This makes modifiers a bit more magical, but more likely to actually work in practice. The type inference story previously may have been intractable.
I've requested that the committee consider the updates in parallel with community feedback.
Thanks, Richard
On Nov 30, 2020, at 2:36 PM, Alejandro Serrano Mena <trupill@gmail.com> wrote:
After some discussion in the GitHub thread, changes are going to arrive to the proposal. I think the best is to send the proposal back to the “Needs revision” state.
Regards, Alejandro
On 29 Nov 2020 at 23:12:44, Eric Seidel <eric@seidel.io> wrote:
I left a few comments and questions on the PR itself, but I'm leaning towards rejecting the proposal in its current form as well. This doesn't (yet) feel like a generic mechanism, in particular because the only modifier that has been specified would be deeply wired into GHC itself.
On Fri, Nov 27, 2020, at 04:46, Joachim Breitner wrote:
Hi,
Am Donnerstag, den 26.11.2020, 14:58 -0500 schrieb Alejandro Serrano Mena:
Dear all, This proposal suggests adding syntax for a general notion of modifiers, like the ones we’ve been talking about lately affecting linearity or matchability of arrows. For example, if linear types and unsaturated families are accepted as they stand, we would have `Int #1 -> @U Bool` (or something like that), whereas with this proposal we would have the more uniform `Int %1 %Unmatchable -> Bool`.
Since the amount of modifiers is likely to increase in the future, I think it’s a great idea to agree and reserve such syntax, instead of coming up with different ways on each proposal. I thus recommend acceptance of this proposal.
The proposal itself: (1) introduces syntax for modifiers in types and defines how to type/kind check them, (2) reserved such syntax for other uses in declarations and terms.
I think the proposal still has its merits only with (1), even though I lean towards accepting both parts of it.
I like the idea of reserving syntax here, but parts of the proposal smell a bit like premature generalization to me. Are we confident that all annotations we eventually would like to use with this feature can be expressed as types of a kind that is an instance of Modifier? Or should we reserve the ability to have annotations that don't fit that model?
Would we ever have annotation that may affect phases earlier than than typechecking? What if we want to use (%type e) and (%data e) to help with the SingleNamepace issues? Look like useful annotations to me, but I am not sure if they fit the framework proposed here.
The fact that we special-case %1 supports that.
The proposal explicitly has to state “No modifier polymorphism!”. But isn't that indication that using the type system to model the various modifiers might be the wrong tool?
I wonder if there is a way where the %(…) on it’s own only reserve syntax, and the various uses of that syntax can be disambiguated _statically_ based on the content of ….
Not great syntax, because not concise, enough, but morally I’d feel more at ease with
Int %(multiplicity Many) -> Int Int %(multiplicity 1) -> Int Int %(multiplicity m) -> Int
where multiplicity is a modifier keyword, to express the existing features (including implicit generalization of m). Then we can extend this to
Int %oneShot -> Int
and
Int %(matchability M) -> Int
and maybe even
foo (%type [a]) -- where foo :: forall a -> ()
which is a modifier that
So at the moment, I am inclined to reject this proposal, until I am convinced that we are not painting ourselves into a “all modifiers are types of special kinds and that’s all the syntax and behaviour we ever need” corner.
Minor detail: If we can annotate infix use of the (->) “type operator”, should we also be able to annotate other infix operators, i.e.
constr ::= (btype | ! atype) {modifier} conop (btype | ! atype) infixexp ::= lexp {modifier} qop infixexp
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
_______________________________________________ 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
Dear Committee, Richard has requested for us to consider the new version of this proposal. As opposed to the previous version, this one is only about reserving syntax for “modifiers”, which at the beginning would be used for things like linearity or matchability of arrows. I think this is a good proposal, and one which would save us from re-considering syntax for every possible extension (and if linearity appears before the arrow and matchability after it, where would a future dimension go?). Thus I keep recommending acceptance on this new incarnation. Regards, Alejandro On 30 Nov 2020 at 20:52:26, Richard Eisenberg <rae@richarde.dev> wrote:
To my surprise, I found myself leaning against. So I updated and simplified the proposal to remove Modifier. This makes modifiers a bit more magical, but more likely to actually work in practice. The type inference story previously may have been intractable.
I've requested that the committee consider the updates in parallel with community feedback.
Thanks, Richard
On Nov 30, 2020, at 2:36 PM, Alejandro Serrano Mena <trupill@gmail.com> wrote:
After some discussion in the GitHub thread, changes are going to arrive to the proposal. I think the best is to send the proposal back to the “Needs revision” state.
Regards, Alejandro
On 29 Nov 2020 at 23:12:44, Eric Seidel <eric@seidel.io> wrote:
I left a few comments and questions on the PR itself, but I'm leaning towards rejecting the proposal in its current form as well. This doesn't (yet) feel like a generic mechanism, in particular because the only modifier that has been specified would be deeply wired into GHC itself.
On Fri, Nov 27, 2020, at 04:46, Joachim Breitner wrote:
Hi,
Am Donnerstag, den 26.11.2020, 14:58 -0500 schrieb Alejandro Serrano
Mena:
Dear all,
This proposal suggests adding syntax for a general notion of
modifiers, like the ones we’ve been talking about lately affecting
linearity or matchability of arrows. For example, if linear types and
unsaturated families are accepted as they stand, we would have `Int
#1 -> @U Bool` (or something like that), whereas with this proposal
we would have the more uniform `Int %1 %Unmatchable -> Bool`.
Since the amount of modifiers is likely to increase in the future, I
think it’s a great idea to agree and reserve such syntax, instead of
coming up with different ways on each proposal. I thus recommend
acceptance of this proposal.
The proposal itself:
(1) introduces syntax for modifiers in types and defines how to
type/kind check them,
(2) reserved such syntax for other uses in declarations and terms.
I think the proposal still has its merits only with (1), even though
I lean towards accepting both parts of it.
I like the idea of reserving syntax here, but parts of the proposal
smell a bit like premature generalization to me. Are we confident that
all annotations we eventually would like to use with this feature can
be expressed as types of a kind that is an instance of Modifier? Or
should we reserve the ability to have annotations that don't fit that
model?
Would we ever have annotation that may affect phases earlier than than
typechecking? What if we want to use (%type e) and (%data e) to help
with the SingleNamepace issues? Look like useful annotations to me, but
I am not sure if they fit the framework proposed here.
The fact that we special-case %1 supports that.
The proposal explicitly has to state “No modifier polymorphism!”. But
isn't that indication that using the type system to model the various
modifiers might be the wrong tool?
I wonder if there is a way where the %(…) on it’s own only reserve
syntax, and the various uses of that syntax can be disambiguated
_statically_ based on the content of ….
Not great syntax, because not concise, enough, but morally I’d feel
more at ease with
Int %(multiplicity Many) -> Int
Int %(multiplicity 1) -> Int
Int %(multiplicity m) -> Int
where multiplicity is a modifier keyword, to express the existing
features (including implicit generalization of m). Then we can extend
this to
Int %oneShot -> Int
and
Int %(matchability M) -> Int
and maybe even
foo (%type [a]) -- where foo :: forall a -> ()
which is a modifier that
So at the moment, I am inclined to reject this proposal, until I am
convinced that we are not painting ourselves into a “all modifiers are
types of special kinds and that’s all the syntax and behaviour we ever
need” corner.
Minor detail: If we can annotate infix use of the (->) “type operator”,
should we also be able to annotate other infix operators, i.e.
constr ::= (btype | ! atype) {modifier} conop (btype | ! atype)
infixexp ::= lexp {modifier} qop infixexp
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
_______________________________________________ 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
Hi, thanks, that’s better. It is still a pretty generic bet on the future (here is a general syntax that we now hope will be useful for multiple things that we don’t even know about yet). But that’s fine, especially if the bet wins. Do we actually need a dedicated language extension for it, though? Why not make this proposal “from now on, LinearHaskell uses this syntax, and we plan to use compatible syntax for other extensions”? (this is all there effectively really is, isn’t it? a tweak to LinearHaskell, and a pledge to follow this pattern) Cheers, Joachim Am Donnerstag, den 03.12.2020, 12:16 -0800 schrieb Alejandro Serrano Mena:
Dear Committee,
Richard has requested for us to consider the new version of this proposal. As opposed to the previous version, this one is only about reserving syntax for “modifiers”, which at the beginning would be used for things like linearity or matchability of arrows.
I think this is a good proposal, and one which would save us from re-considering syntax for every possible extension (and if linearity appears before the arrow and matchability after it, where would a future dimension go?). Thus I keep recommending acceptance on this new incarnation.
Regards, Alejandro
On 30 Nov 2020 at 20:52:26, Richard Eisenberg <rae@richarde.dev> wrote:
To my surprise, I found myself leaning against. So I updated and simplified the proposal to remove Modifier. This makes modifiers a bit more magical, but more likely to actually work in practice. The type inference story previously may have been intractable.
I've requested that the committee consider the updates in parallel with community feedback.
Thanks, Richard
On Nov 30, 2020, at 2:36 PM, Alejandro Serrano Mena <trupill@gmail.com> wrote:
After some discussion in the GitHub thread, changes are going to arrive to the proposal. I think the best is to send the proposal back to the “Needs revision” state.
Regards, Alejandro
On 29 Nov 2020 at 23:12:44, Eric Seidel <eric@seidel.io> wrote:
I left a few comments and questions on the PR itself, but I'm leaning towards rejecting the proposal in its current form as well. This doesn't (yet) feel like a generic mechanism, in particular because the only modifier that has been specified would be deeply wired into GHC itself.
On Fri, Nov 27, 2020, at 04:46, Joachim Breitner wrote:
Hi, Am Donnerstag, den 26.11.2020, 14:58 -0500 schrieb Alejandro Serrano Mena:
Dear all, This proposal suggests adding syntax for a general notion of modifiers, like the ones we’ve been talking about lately affecting linearity or matchability of arrows. For example, if linear types and unsaturated families are accepted as they stand, we would have `Int #1 -> @U Bool` (or something like that), whereas with this proposal we would have the more uniform `Int %1 %Unmatchable -> Bool`.
Since the amount of modifiers is likely to increase in the future, I think it’s a great idea to agree and reserve such syntax, instead of coming up with different ways on each proposal. I thus recommend acceptance of this proposal.
The proposal itself: (1) introduces syntax for modifiers in types and defines how to type/kind check them, (2) reserved such syntax for other uses in declarations and terms.
I think the proposal still has its merits only with (1), even though I lean towards accepting both parts of it. I like the idea of reserving syntax here, but parts of the proposal smell a bit like premature generalization to me. Are we confident that all annotations we eventually would like to use with this feature can be expressed as types of a kind that is an instance of Modifier? Or should we reserve the ability to have annotations that don't fit that model? Would we ever have annotation that may affect phases earlier than than typechecking? What if we want to use (%type e) and (%data e) to help with the SingleNamepace issues? Look like useful annotations to me, but I am not sure if they fit the framework proposed here. The fact that we special-case %1 supports that. The proposal explicitly has to state “No modifier polymorphism!”. But isn't that indication that using the type system to model the various modifiers might be the wrong tool? I wonder if there is a way where the %(…) on it’s own only reserve syntax, and the various uses of that syntax can be disambiguated _statically_ based on the content of …. Not great syntax, because not concise, enough, but morally I’d feel more at ease with Int %(multiplicity Many) -> Int Int %(multiplicity 1) -> Int Int %(multiplicity m) -> Int where multiplicity is a modifier keyword, to express the existing features (including implicit generalization of m). Then we can extend this to Int %oneShot -> Int and Int %(matchability M) -> Int and maybe even foo (%type [a]) -- where foo :: forall a -> () which is a modifier that So at the moment, I am inclined to reject this proposal, until I am convinced that we are not painting ourselves into a “all modifiers are types of special kinds and that’s all the syntax and behaviour we ever need” corner. Minor detail: If we can annotate infix use of the (->) “type operator”, should we also be able to annotate other infix operators, i.e. constr ::= (btype | ! atype) {modifier} conop (btype | ! atype) infixexp ::= lexp {modifier} qop infixexp 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
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
_______________________________________________ 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/
I’ve replied on GitHub. Generally in favour. But mark it as experimental… I don’t want to be locked into “we decided on this in Dec 2020 so now it’s too late”. WE can learn from experience. Simon From: ghc-steering-committee <ghc-steering-committee-bounces@haskell.org> On Behalf Of Alejandro Serrano Mena Sent: 03 December 2020 20:17 To: Richard Eisenberg <rae@richarde.dev> Cc: ghc-steering-committee@haskell.org Subject: Re: [ghc-steering-committee] #370: Syntax for Modifiers, Recommendation: Acceptance Dear Committee, Richard has requested for us to consider the new version of this proposal. As opposed to the previous version, this one is only about reserving syntax for “modifiers”, which at the beginning would be used for things like linearity or matchability of arrows. I think this is a good proposal, and one which would save us from re-considering syntax for every possible extension (and if linearity appears before the arrow and matchability after it, where would a future dimension go?). Thus I keep recommending acceptance on this new incarnation. Regards, Alejandro On 30 Nov 2020 at 20:52:26, Richard Eisenberg <rae@richarde.dev<mailto:rae@richarde.dev>> wrote: To my surprise, I found myself leaning against. So I updated and simplified the proposal to remove Modifier. This makes modifiers a bit more magical, but more likely to actually work in practice. The type inference story previously may have been intractable. I've requested that the committee consider the updates in parallel with community feedback. Thanks, Richard On Nov 30, 2020, at 2:36 PM, Alejandro Serrano Mena <trupill@gmail.com<mailto:trupill@gmail.com>> wrote: After some discussion in the GitHub thread, changes are going to arrive to the proposal. I think the best is to send the proposal back to the “Needs revision” state. Regards, Alejandro On 29 Nov 2020 at 23:12:44, Eric Seidel <eric@seidel.io<mailto:eric@seidel.io>> wrote: I left a few comments and questions on the PR itself, but I'm leaning towards rejecting the proposal in its current form as well. This doesn't (yet) feel like a generic mechanism, in particular because the only modifier that has been specified would be deeply wired into GHC itself. On Fri, Nov 27, 2020, at 04:46, Joachim Breitner wrote: Hi, Am Donnerstag, den 26.11.2020, 14:58 -0500 schrieb Alejandro Serrano Mena:
Dear all, This proposal suggests adding syntax for a general notion of modifiers, like the ones we’ve been talking about lately affecting linearity or matchability of arrows. For example, if linear types and unsaturated families are accepted as they stand, we would have `Int #1 -> @U Bool` (or something like that), whereas with this proposal we would have the more uniform `Int %1 %Unmatchable -> Bool`.
Since the amount of modifiers is likely to increase in the future, I think it’s a great idea to agree and reserve such syntax, instead of coming up with different ways on each proposal. I thus recommend acceptance of this proposal.
The proposal itself: (1) introduces syntax for modifiers in types and defines how to type/kind check them, (2) reserved such syntax for other uses in declarations and terms.
I think the proposal still has its merits only with (1), even though I lean towards accepting both parts of it.
I like the idea of reserving syntax here, but parts of the proposal smell a bit like premature generalization to me. Are we confident that all annotations we eventually would like to use with this feature can be expressed as types of a kind that is an instance of Modifier? Or should we reserve the ability to have annotations that don't fit that model? Would we ever have annotation that may affect phases earlier than than typechecking? What if we want to use (%type e) and (%data e) to help with the SingleNamepace issues? Look like useful annotations to me, but I am not sure if they fit the framework proposed here. The fact that we special-case %1 supports that. The proposal explicitly has to state “No modifier polymorphism!”. But isn't that indication that using the type system to model the various modifiers might be the wrong tool? I wonder if there is a way where the %(…) on it’s own only reserve syntax, and the various uses of that syntax can be disambiguated _statically_ based on the content of …. Not great syntax, because not concise, enough, but morally I’d feel more at ease with Int %(multiplicity Many) -> Int Int %(multiplicity 1) -> Int Int %(multiplicity m) -> Int where multiplicity is a modifier keyword, to express the existing features (including implicit generalization of m). Then we can extend this to Int %oneShot -> Int and Int %(matchability M) -> Int and maybe even foo (%type [a]) -- where foo :: forall a -> () which is a modifier that So at the moment, I am inclined to reject this proposal, until I am convinced that we are not painting ourselves into a “all modifiers are types of special kinds and that’s all the syntax and behaviour we ever need” corner. Minor detail: If we can annotate infix use of the (->) “type operator”, should we also be able to annotate other infix operators, i.e. constr ::= (btype | ! atype) {modifier} conop (btype | ! atype) infixexp ::= lexp {modifier} qop infixexp Cheers, Joachim -- Joachim Breitner mail@joachim-breitner.de<mailto:mail@joachim-breitner.de> http://www.joachim-breitner.de/<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.joachim-breitner.de%2F&data=04%7C01%7Csimonpj%40microsoft.com%7C70050d899124429d0d5a08d897c862a2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C637426234195063362%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=kMw%2BvlOxw4ketBttUdHI1zbAL1SyUFduoR7ac54uLrE%3D&reserved=0> _______________________________________________ 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://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committee&data=04%7C01%7Csimonpj%40microsoft.com%7C70050d899124429d0d5a08d897c862a2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C637426234195073315%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=zlRcj7FjskXnYJDMtX5Wj8Ognw0mPSR1PVG0XK4RNQ4%3D&reserved=0> _______________________________________________ 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://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committee&data=04%7C01%7Csimonpj%40microsoft.com%7C70050d899124429d0d5a08d897c862a2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C637426234195073315%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=zlRcj7FjskXnYJDMtX5Wj8Ognw0mPSR1PVG0XK4RNQ4%3D&reserved=0> _______________________________________________ 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://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committee&data=04%7C01%7Csimonpj%40microsoft.com%7C70050d899124429d0d5a08d897c862a2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C637426234195083273%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=zxJsZFQYUe4Yu5bjjPfZKC3NQUmrVcEuU7DjV7lhe0g%3D&reserved=0>
It's always possible to change. I don't think accepting a proposal means (or ought to mean) that we are locked into anything. Accepting a proposal means that we won't oppose a design-related argument to a PR that implements (part or all of) an accepted proposal. I don't know how to quantify the degree of confidence that we have in the stability of a proposal. Here we are all saying: this is better than anything so far, and we rather need something like this to be a thing, but it's really a shot in the dark. And this lack of confidence will be reflected in the manual description. But even if we are confident in the stability of a proposal, it may very well happen that it changes dramatically, even soon. On Wed, Dec 9, 2020 at 2:55 PM Simon Peyton Jones via ghc-steering-committee <ghc-steering-committee@haskell.org> wrote:
I’ve replied on GitHub. Generally in favour. But mark it as experimental… I don’t want to be locked into “we decided on this in Dec 2020 so now it’s too late”. WE can learn from experience.
Simon
*From:* ghc-steering-committee <ghc-steering-committee-bounces@haskell.org> *On Behalf Of *Alejandro Serrano Mena *Sent:* 03 December 2020 20:17 *To:* Richard Eisenberg <rae@richarde.dev> *Cc:* ghc-steering-committee@haskell.org *Subject:* Re: [ghc-steering-committee] #370: Syntax for Modifiers, Recommendation: Acceptance
Dear Committee,
Richard has requested for us to consider the new version of this proposal. As opposed to the previous version, this one is only about reserving syntax for “modifiers”, which at the beginning would be used for things like linearity or matchability of arrows.
I think this is a good proposal, and one which would save us from re-considering syntax for every possible extension (and if linearity appears before the arrow and matchability after it, where would a future dimension go?). Thus I keep recommending acceptance on this new incarnation.
Regards,
Alejandro
On 30 Nov 2020 at 20:52:26, Richard Eisenberg <rae@richarde.dev> wrote:
To my surprise, I found myself leaning against. So I updated and simplified the proposal to remove Modifier. This makes modifiers a bit more magical, but more likely to actually work in practice. The type inference story previously may have been intractable.
I've requested that the committee consider the updates in parallel with community feedback.
Thanks,
Richard
On Nov 30, 2020, at 2:36 PM, Alejandro Serrano Mena <trupill@gmail.com> wrote:
After some discussion in the GitHub thread, changes are going to arrive to the proposal. I think the best is to send the proposal back to the “Needs revision” state.
Regards,
Alejandro
On 29 Nov 2020 at 23:12:44, Eric Seidel <eric@seidel.io> wrote:
I left a few comments and questions on the PR itself, but I'm leaning towards rejecting the proposal in its current form as well. This doesn't (yet) feel like a generic mechanism, in particular because the only modifier that has been specified would be deeply wired into GHC itself.
On Fri, Nov 27, 2020, at 04:46, Joachim Breitner wrote:
Hi,
Am Donnerstag, den 26.11.2020, 14:58 -0500 schrieb Alejandro Serrano
Mena:
Dear all,
This proposal suggests adding syntax for a general notion of
modifiers, like the ones we’ve been talking about lately affecting
linearity or matchability of arrows. For example, if linear types and
unsaturated families are accepted as they stand, we would have `Int
#1 -> @U Bool` (or something like that), whereas with this proposal
we would have the more uniform `Int %1 %Unmatchable -> Bool`.
Since the amount of modifiers is likely to increase in the future, I
think it’s a great idea to agree and reserve such syntax, instead of
coming up with different ways on each proposal. I thus recommend
acceptance of this proposal.
The proposal itself:
(1) introduces syntax for modifiers in types and defines how to
type/kind check them,
(2) reserved such syntax for other uses in declarations and terms.
I think the proposal still has its merits only with (1), even though
I lean towards accepting both parts of it.
I like the idea of reserving syntax here, but parts of the proposal
smell a bit like premature generalization to me. Are we confident that
all annotations we eventually would like to use with this feature can
be expressed as types of a kind that is an instance of Modifier? Or
should we reserve the ability to have annotations that don't fit that
model?
Would we ever have annotation that may affect phases earlier than than
typechecking? What if we want to use (%type e) and (%data e) to help
with the SingleNamepace issues? Look like useful annotations to me, but
I am not sure if they fit the framework proposed here.
The fact that we special-case %1 supports that.
The proposal explicitly has to state “No modifier polymorphism!”. But
isn't that indication that using the type system to model the various
modifiers might be the wrong tool?
I wonder if there is a way where the %(…) on it’s own only reserve
syntax, and the various uses of that syntax can be disambiguated
_statically_ based on the content of ….
Not great syntax, because not concise, enough, but morally I’d feel
more at ease with
Int %(multiplicity Many) -> Int
Int %(multiplicity 1) -> Int
Int %(multiplicity m) -> Int
where multiplicity is a modifier keyword, to express the existing
features (including implicit generalization of m). Then we can extend
this to
Int %oneShot -> Int
and
Int %(matchability M) -> Int
and maybe even
foo (%type [a]) -- where foo :: forall a -> ()
which is a modifier that
So at the moment, I am inclined to reject this proposal, until I am
convinced that we are not painting ourselves into a “all modifiers are
types of special kinds and that’s all the syntax and behaviour we ever
need” corner.
Minor detail: If we can annotate infix use of the (->) “type operator”,
should we also be able to annotate other infix operators, i.e.
constr ::= (btype | ! atype) {modifier} conop (btype | ! atype)
infixexp ::= lexp {modifier} qop infixexp
Cheers,
Joachim
--
Joachim Breitner
mail@joachim-breitner.de
http://www.joachim-breitner.de/ <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.joachim-breitner.de%2F&data=04%7C01%7Csimonpj%40microsoft.com%7C70050d899124429d0d5a08d897c862a2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C637426234195063362%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=kMw%2BvlOxw4ketBttUdHI1zbAL1SyUFduoR7ac54uLrE%3D&reserved=0>
_______________________________________________
ghc-steering-committee mailing list
ghc-steering-committee@haskell.org
https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committee&data=04%7C01%7Csimonpj%40microsoft.com%7C70050d899124429d0d5a08d897c862a2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C637426234195073315%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=zlRcj7FjskXnYJDMtX5Wj8Ognw0mPSR1PVG0XK4RNQ4%3D&reserved=0>
_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committee&data=04%7C01%7Csimonpj%40microsoft.com%7C70050d899124429d0d5a08d897c862a2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C637426234195073315%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=zlRcj7FjskXnYJDMtX5Wj8Ognw0mPSR1PVG0XK4RNQ4%3D&reserved=0>
_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committee&data=04%7C01%7Csimonpj%40microsoft.com%7C70050d899124429d0d5a08d897c862a2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C637426234195083273%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=zxJsZFQYUe4Yu5bjjPfZKC3NQUmrVcEuU7DjV7lhe0g%3D&reserved=0>
_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
Dear all, As the shepherd of this proposal, I’m quite confused about what the outcome should be. The ghc-proposals README states that: Acceptance of the proposal implies that the implementation will be accepted
into GHC provided it is well-engineered, well-documented, and does not complicate the code-base too much.
Most of the Committee seems to lean towards “this seems OK right now, but we don’t want to be locked” or “mark this as experimental”. However, there’s no such notion as “accept as experimental”. Furthermore, as it stands the proposal gives some syntax, and then asks any new extensions to use that syntax; so it cannot be completely thought as a feature by itself. Regards, Alejandro On 9 Dec 2020 at 15:59:43, Spiwack, Arnaud <arnaud.spiwack@tweag.io> wrote:
It's always possible to change. I don't think accepting a proposal means (or ought to mean) that we are locked into anything. Accepting a proposal means that we won't oppose a design-related argument to a PR that implements (part or all of) an accepted proposal.
I don't know how to quantify the degree of confidence that we have in the stability of a proposal. Here we are all saying: this is better than anything so far, and we rather need something like this to be a thing, but it's really a shot in the dark. And this lack of confidence will be reflected in the manual description. But even if we are confident in the stability of a proposal, it may very well happen that it changes dramatically, even soon.
On Wed, Dec 9, 2020 at 2:55 PM Simon Peyton Jones via ghc-steering-committee <ghc-steering-committee@haskell.org> wrote:
I’ve replied on GitHub. Generally in favour. But mark it as experimental… I don’t want to be locked into “we decided on this in Dec 2020 so now it’s too late”. WE can learn from experience.
Simon
*From:* ghc-steering-committee < ghc-steering-committee-bounces@haskell.org> *On Behalf Of *Alejandro Serrano Mena *Sent:* 03 December 2020 20:17 *To:* Richard Eisenberg <rae@richarde.dev> *Cc:* ghc-steering-committee@haskell.org *Subject:* Re: [ghc-steering-committee] #370: Syntax for Modifiers, Recommendation: Acceptance
Dear Committee,
Richard has requested for us to consider the new version of this proposal. As opposed to the previous version, this one is only about reserving syntax for “modifiers”, which at the beginning would be used for things like linearity or matchability of arrows.
I think this is a good proposal, and one which would save us from re-considering syntax for every possible extension (and if linearity appears before the arrow and matchability after it, where would a future dimension go?). Thus I keep recommending acceptance on this new incarnation.
Regards,
Alejandro
On 30 Nov 2020 at 20:52:26, Richard Eisenberg <rae@richarde.dev> wrote:
To my surprise, I found myself leaning against. So I updated and simplified the proposal to remove Modifier. This makes modifiers a bit more magical, but more likely to actually work in practice. The type inference story previously may have been intractable.
I've requested that the committee consider the updates in parallel with community feedback.
Thanks,
Richard
On Nov 30, 2020, at 2:36 PM, Alejandro Serrano Mena <trupill@gmail.com> wrote:
After some discussion in the GitHub thread, changes are going to arrive to the proposal. I think the best is to send the proposal back to the “Needs revision” state.
Regards,
Alejandro
On 29 Nov 2020 at 23:12:44, Eric Seidel <eric@seidel.io> wrote:
I left a few comments and questions on the PR itself, but I'm leaning towards rejecting the proposal in its current form as well. This doesn't (yet) feel like a generic mechanism, in particular because the only modifier that has been specified would be deeply wired into GHC itself.
On Fri, Nov 27, 2020, at 04:46, Joachim Breitner wrote:
Hi,
Am Donnerstag, den 26.11.2020, 14:58 -0500 schrieb Alejandro Serrano
Mena:
Dear all,
This proposal suggests adding syntax for a general notion of
modifiers, like the ones we’ve been talking about lately affecting
linearity or matchability of arrows. For example, if linear types and
unsaturated families are accepted as they stand, we would have `Int
#1 -> @U Bool` (or something like that), whereas with this proposal
we would have the more uniform `Int %1 %Unmatchable -> Bool`.
Since the amount of modifiers is likely to increase in the future, I
think it’s a great idea to agree and reserve such syntax, instead of
coming up with different ways on each proposal. I thus recommend
acceptance of this proposal.
The proposal itself:
(1) introduces syntax for modifiers in types and defines how to
type/kind check them,
(2) reserved such syntax for other uses in declarations and terms.
I think the proposal still has its merits only with (1), even though
I lean towards accepting both parts of it.
I like the idea of reserving syntax here, but parts of the proposal
smell a bit like premature generalization to me. Are we confident that
all annotations we eventually would like to use with this feature can
be expressed as types of a kind that is an instance of Modifier? Or
should we reserve the ability to have annotations that don't fit that
model?
Would we ever have annotation that may affect phases earlier than than
typechecking? What if we want to use (%type e) and (%data e) to help
with the SingleNamepace issues? Look like useful annotations to me, but
I am not sure if they fit the framework proposed here.
The fact that we special-case %1 supports that.
The proposal explicitly has to state “No modifier polymorphism!”. But
isn't that indication that using the type system to model the various
modifiers might be the wrong tool?
I wonder if there is a way where the %(…) on it’s own only reserve
syntax, and the various uses of that syntax can be disambiguated
_statically_ based on the content of ….
Not great syntax, because not concise, enough, but morally I’d feel
more at ease with
Int %(multiplicity Many) -> Int
Int %(multiplicity 1) -> Int
Int %(multiplicity m) -> Int
where multiplicity is a modifier keyword, to express the existing
features (including implicit generalization of m). Then we can extend
this to
Int %oneShot -> Int
and
Int %(matchability M) -> Int
and maybe even
foo (%type [a]) -- where foo :: forall a -> ()
which is a modifier that
So at the moment, I am inclined to reject this proposal, until I am
convinced that we are not painting ourselves into a “all modifiers are
types of special kinds and that’s all the syntax and behaviour we ever
need” corner.
Minor detail: If we can annotate infix use of the (->) “type operator”,
should we also be able to annotate other infix operators, i.e.
constr ::= (btype | ! atype) {modifier} conop (btype | ! atype)
infixexp ::= lexp {modifier} qop infixexp
Cheers,
Joachim
--
Joachim Breitner
mail@joachim-breitner.de
http://www.joachim-breitner.de/ <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.joachim-breitner.de%2F&data=04%7C01%7Csimonpj%40microsoft.com%7C70050d899124429d0d5a08d897c862a2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C637426234195063362%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=kMw%2BvlOxw4ketBttUdHI1zbAL1SyUFduoR7ac54uLrE%3D&reserved=0>
_______________________________________________
ghc-steering-committee mailing list
ghc-steering-committee@haskell.org
https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committee&data=04%7C01%7Csimonpj%40microsoft.com%7C70050d899124429d0d5a08d897c862a2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C637426234195073315%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=zlRcj7FjskXnYJDMtX5Wj8Ognw0mPSR1PVG0XK4RNQ4%3D&reserved=0>
_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committee&data=04%7C01%7Csimonpj%40microsoft.com%7C70050d899124429d0d5a08d897c862a2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C637426234195073315%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=zlRcj7FjskXnYJDMtX5Wj8Ognw0mPSR1PVG0XK4RNQ4%3D&reserved=0>
_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committee&data=04%7C01%7Csimonpj%40microsoft.com%7C70050d899124429d0d5a08d897c862a2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C637426234195083273%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=zxJsZFQYUe4Yu5bjjPfZKC3NQUmrVcEuU7DjV7lhe0g%3D&reserved=0>
_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
That was the point of my previous email: accept, and accept-as-experimental are actually one and the same. What Simon is driving at, I think, is: depending on what the proposal is about, we want to apply more or less strict standard of acceptance (if a proposal is about fixing something in an existing feature, then we better be rather sure that it is indeed an improvement; but if it's about adding something new in an untrodden territory, then we can't really be sure, and it's worth experimenting with). On Wed, Dec 9, 2020 at 9:17 PM Alejandro Serrano Mena <trupill@gmail.com> wrote:
Dear all, As the shepherd of this proposal, I’m quite confused about what the outcome should be. The ghc-proposals README states that:
Acceptance of the proposal implies that the implementation will be
accepted into GHC provided it is well-engineered, well-documented, and does not complicate the code-base too much.
Most of the Committee seems to lean towards “this seems OK right now, but we don’t want to be locked” or “mark this as experimental”. However, there’s no such notion as “accept as experimental”. Furthermore, as it stands the proposal gives some syntax, and then asks any new extensions to use that syntax; so it cannot be completely thought as a feature by itself.
Regards, Alejandro
On 9 Dec 2020 at 15:59:43, Spiwack, Arnaud <arnaud.spiwack@tweag.io> wrote:
It's always possible to change. I don't think accepting a proposal means (or ought to mean) that we are locked into anything. Accepting a proposal means that we won't oppose a design-related argument to a PR that implements (part or all of) an accepted proposal.
I don't know how to quantify the degree of confidence that we have in the stability of a proposal. Here we are all saying: this is better than anything so far, and we rather need something like this to be a thing, but it's really a shot in the dark. And this lack of confidence will be reflected in the manual description. But even if we are confident in the stability of a proposal, it may very well happen that it changes dramatically, even soon.
On Wed, Dec 9, 2020 at 2:55 PM Simon Peyton Jones via ghc-steering-committee <ghc-steering-committee@haskell.org> wrote:
I’ve replied on GitHub. Generally in favour. But mark it as experimental… I don’t want to be locked into “we decided on this in Dec 2020 so now it’s too late”. WE can learn from experience.
Simon
*From:* ghc-steering-committee < ghc-steering-committee-bounces@haskell.org> *On Behalf Of *Alejandro Serrano Mena *Sent:* 03 December 2020 20:17 *To:* Richard Eisenberg <rae@richarde.dev> *Cc:* ghc-steering-committee@haskell.org *Subject:* Re: [ghc-steering-committee] #370: Syntax for Modifiers, Recommendation: Acceptance
Dear Committee,
Richard has requested for us to consider the new version of this proposal. As opposed to the previous version, this one is only about reserving syntax for “modifiers”, which at the beginning would be used for things like linearity or matchability of arrows.
I think this is a good proposal, and one which would save us from re-considering syntax for every possible extension (and if linearity appears before the arrow and matchability after it, where would a future dimension go?). Thus I keep recommending acceptance on this new incarnation.
Regards,
Alejandro
On 30 Nov 2020 at 20:52:26, Richard Eisenberg <rae@richarde.dev> wrote:
To my surprise, I found myself leaning against. So I updated and simplified the proposal to remove Modifier. This makes modifiers a bit more magical, but more likely to actually work in practice. The type inference story previously may have been intractable.
I've requested that the committee consider the updates in parallel with community feedback.
Thanks,
Richard
On Nov 30, 2020, at 2:36 PM, Alejandro Serrano Mena <trupill@gmail.com> wrote:
After some discussion in the GitHub thread, changes are going to arrive to the proposal. I think the best is to send the proposal back to the “Needs revision” state.
Regards,
Alejandro
On 29 Nov 2020 at 23:12:44, Eric Seidel <eric@seidel.io> wrote:
I left a few comments and questions on the PR itself, but I'm leaning towards rejecting the proposal in its current form as well. This doesn't (yet) feel like a generic mechanism, in particular because the only modifier that has been specified would be deeply wired into GHC itself.
On Fri, Nov 27, 2020, at 04:46, Joachim Breitner wrote:
Hi,
Am Donnerstag, den 26.11.2020, 14:58 -0500 schrieb Alejandro Serrano
Mena:
Dear all,
This proposal suggests adding syntax for a general notion of
modifiers, like the ones we’ve been talking about lately affecting
linearity or matchability of arrows. For example, if linear types and
unsaturated families are accepted as they stand, we would have `Int
#1 -> @U Bool` (or something like that), whereas with this proposal
we would have the more uniform `Int %1 %Unmatchable -> Bool`.
Since the amount of modifiers is likely to increase in the future, I
think it’s a great idea to agree and reserve such syntax, instead of
coming up with different ways on each proposal. I thus recommend
acceptance of this proposal.
The proposal itself:
(1) introduces syntax for modifiers in types and defines how to
type/kind check them,
(2) reserved such syntax for other uses in declarations and terms.
I think the proposal still has its merits only with (1), even though
I lean towards accepting both parts of it.
I like the idea of reserving syntax here, but parts of the proposal
smell a bit like premature generalization to me. Are we confident that
all annotations we eventually would like to use with this feature can
be expressed as types of a kind that is an instance of Modifier? Or
should we reserve the ability to have annotations that don't fit that
model?
Would we ever have annotation that may affect phases earlier than than
typechecking? What if we want to use (%type e) and (%data e) to help
with the SingleNamepace issues? Look like useful annotations to me, but
I am not sure if they fit the framework proposed here.
The fact that we special-case %1 supports that.
The proposal explicitly has to state “No modifier polymorphism!”. But
isn't that indication that using the type system to model the various
modifiers might be the wrong tool?
I wonder if there is a way where the %(…) on it’s own only reserve
syntax, and the various uses of that syntax can be disambiguated
_statically_ based on the content of ….
Not great syntax, because not concise, enough, but morally I’d feel
more at ease with
Int %(multiplicity Many) -> Int
Int %(multiplicity 1) -> Int
Int %(multiplicity m) -> Int
where multiplicity is a modifier keyword, to express the existing
features (including implicit generalization of m). Then we can extend
this to
Int %oneShot -> Int
and
Int %(matchability M) -> Int
and maybe even
foo (%type [a]) -- where foo :: forall a -> ()
which is a modifier that
So at the moment, I am inclined to reject this proposal, until I am
convinced that we are not painting ourselves into a “all modifiers are
types of special kinds and that’s all the syntax and behaviour we ever
need” corner.
Minor detail: If we can annotate infix use of the (->) “type operator”,
should we also be able to annotate other infix operators, i.e.
constr ::= (btype | ! atype) {modifier} conop (btype | ! atype)
infixexp ::= lexp {modifier} qop infixexp
Cheers,
Joachim
--
Joachim Breitner
mail@joachim-breitner.de
http://www.joachim-breitner.de/ <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.joachim-breitner.de%2F&data=04%7C01%7Csimonpj%40microsoft.com%7C70050d899124429d0d5a08d897c862a2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C637426234195063362%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=kMw%2BvlOxw4ketBttUdHI1zbAL1SyUFduoR7ac54uLrE%3D&reserved=0>
_______________________________________________
ghc-steering-committee mailing list
ghc-steering-committee@haskell.org
https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committee&data=04%7C01%7Csimonpj%40microsoft.com%7C70050d899124429d0d5a08d897c862a2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C637426234195073315%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=zlRcj7FjskXnYJDMtX5Wj8Ognw0mPSR1PVG0XK4RNQ4%3D&reserved=0>
_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committee&data=04%7C01%7Csimonpj%40microsoft.com%7C70050d899124429d0d5a08d897c862a2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C637426234195073315%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=zlRcj7FjskXnYJDMtX5Wj8Ognw0mPSR1PVG0XK4RNQ4%3D&reserved=0>
_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committee&data=04%7C01%7Csimonpj%40microsoft.com%7C70050d899124429d0d5a08d897c862a2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C637426234195083273%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=zxJsZFQYUe4Yu5bjjPfZKC3NQUmrVcEuU7DjV7lhe0g%3D&reserved=0>
_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
That was the point of my previous email: accept, and accept-as-experimental are actually one and the same. Objectively, yes. But I think it helps users to advertise a feature as experimental. It’s a signal to users that this feature is, well, experimental. It is more likely to change. It’s only an indication not a clear distinction. But I find it helpful. For me, it also reflects how I evaluate the proposal. For a change to a well-established feature, we have a lot of experience in how people use that feature. For experimental features we don’t. Example: defaulting for matchability for unsaturated type families. We don’t have unsaturated type families right now, so we don’t have any code that uses them, and hence zero in-the-wild experience about matchability defaulting. We shouldn’t spend ages arguing the toss – just trust Csongor’s judgement and give it a try, but advertising that details may change. Simon From: Spiwack, Arnaud <arnaud.spiwack@tweag.io> Sent: 10 December 2020 08:06 To: Alejandro Serrano Mena <trupill@gmail.com> Cc: Richard Eisenberg <rae@richarde.dev>; ghc-steering-committee@haskell.org; Simon Peyton Jones <simonpj@microsoft.com> Subject: Re: [ghc-steering-committee] #370: Syntax for Modifiers, Recommendation: Acceptance That was the point of my previous email: accept, and accept-as-experimental are actually one and the same. What Simon is driving at, I think, is: depending on what the proposal is about, we want to apply more or less strict standard of acceptance (if a proposal is about fixing something in an existing feature, then we better be rather sure that it is indeed an improvement; but if it's about adding something new in an untrodden territory, then we can't really be sure, and it's worth experimenting with). On Wed, Dec 9, 2020 at 9:17 PM Alejandro Serrano Mena <trupill@gmail.com<mailto:trupill@gmail.com>> wrote: Dear all, As the shepherd of this proposal, I’m quite confused about what the outcome should be. The ghc-proposals README states that: Acceptance of the proposal implies that the implementation will be accepted into GHC provided it is well-engineered, well-documented, and does not complicate the code-base too much. Most of the Committee seems to lean towards “this seems OK right now, but we don’t want to be locked” or “mark this as experimental”. However, there’s no such notion as “accept as experimental”. Furthermore, as it stands the proposal gives some syntax, and then asks any new extensions to use that syntax; so it cannot be completely thought as a feature by itself. Regards, Alejandro On 9 Dec 2020 at 15:59:43, Spiwack, Arnaud <arnaud.spiwack@tweag.io<mailto:arnaud.spiwack@tweag.io>> wrote: It's always possible to change. I don't think accepting a proposal means (or ought to mean) that we are locked into anything. Accepting a proposal means that we won't oppose a design-related argument to a PR that implements (part or all of) an accepted proposal. I don't know how to quantify the degree of confidence that we have in the stability of a proposal. Here we are all saying: this is better than anything so far, and we rather need something like this to be a thing, but it's really a shot in the dark. And this lack of confidence will be reflected in the manual description. But even if we are confident in the stability of a proposal, it may very well happen that it changes dramatically, even soon. On Wed, Dec 9, 2020 at 2:55 PM Simon Peyton Jones via ghc-steering-committee <ghc-steering-committee@haskell.org<mailto:ghc-steering-committee@haskell.org>> wrote: I’ve replied on GitHub. Generally in favour. But mark it as experimental… I don’t want to be locked into “we decided on this in Dec 2020 so now it’s too late”. WE can learn from experience. Simon From: ghc-steering-committee <ghc-steering-committee-bounces@haskell.org<mailto:ghc-steering-committee-bounces@haskell.org>> On Behalf Of Alejandro Serrano Mena Sent: 03 December 2020 20:17 To: Richard Eisenberg <rae@richarde.dev<mailto:rae@richarde.dev>> Cc: ghc-steering-committee@haskell.org<mailto:ghc-steering-committee@haskell.org> Subject: Re: [ghc-steering-committee] #370: Syntax for Modifiers, Recommendation: Acceptance Dear Committee, Richard has requested for us to consider the new version of this proposal. As opposed to the previous version, this one is only about reserving syntax for “modifiers”, which at the beginning would be used for things like linearity or matchability of arrows. I think this is a good proposal, and one which would save us from re-considering syntax for every possible extension (and if linearity appears before the arrow and matchability after it, where would a future dimension go?). Thus I keep recommending acceptance on this new incarnation. Regards, Alejandro On 30 Nov 2020 at 20:52:26, Richard Eisenberg <rae@richarde.dev<mailto:rae@richarde.dev>> wrote: To my surprise, I found myself leaning against. So I updated and simplified the proposal to remove Modifier. This makes modifiers a bit more magical, but more likely to actually work in practice. The type inference story previously may have been intractable. I've requested that the committee consider the updates in parallel with community feedback. Thanks, Richard On Nov 30, 2020, at 2:36 PM, Alejandro Serrano Mena <trupill@gmail.com<mailto:trupill@gmail.com>> wrote: After some discussion in the GitHub thread, changes are going to arrive to the proposal. I think the best is to send the proposal back to the “Needs revision” state. Regards, Alejandro On 29 Nov 2020 at 23:12:44, Eric Seidel <eric@seidel.io<mailto:eric@seidel.io>> wrote: I left a few comments and questions on the PR itself, but I'm leaning towards rejecting the proposal in its current form as well. This doesn't (yet) feel like a generic mechanism, in particular because the only modifier that has been specified would be deeply wired into GHC itself. On Fri, Nov 27, 2020, at 04:46, Joachim Breitner wrote: Hi, Am Donnerstag, den 26.11.2020, 14:58 -0500 schrieb Alejandro Serrano Mena:
Dear all, This proposal suggests adding syntax for a general notion of modifiers, like the ones we’ve been talking about lately affecting linearity or matchability of arrows. For example, if linear types and unsaturated families are accepted as they stand, we would have `Int #1 -> @U Bool` (or something like that), whereas with this proposal we would have the more uniform `Int %1 %Unmatchable -> Bool`.
Since the amount of modifiers is likely to increase in the future, I think it’s a great idea to agree and reserve such syntax, instead of coming up with different ways on each proposal. I thus recommend acceptance of this proposal.
The proposal itself: (1) introduces syntax for modifiers in types and defines how to type/kind check them, (2) reserved such syntax for other uses in declarations and terms.
I think the proposal still has its merits only with (1), even though I lean towards accepting both parts of it.
I like the idea of reserving syntax here, but parts of the proposal smell a bit like premature generalization to me. Are we confident that all annotations we eventually would like to use with this feature can be expressed as types of a kind that is an instance of Modifier? Or should we reserve the ability to have annotations that don't fit that model? Would we ever have annotation that may affect phases earlier than than typechecking? What if we want to use (%type e) and (%data e) to help with the SingleNamepace issues? Look like useful annotations to me, but I am not sure if they fit the framework proposed here. The fact that we special-case %1 supports that. The proposal explicitly has to state “No modifier polymorphism!”. But isn't that indication that using the type system to model the various modifiers might be the wrong tool? I wonder if there is a way where the %(…) on it’s own only reserve syntax, and the various uses of that syntax can be disambiguated _statically_ based on the content of …. Not great syntax, because not concise, enough, but morally I’d feel more at ease with Int %(multiplicity Many) -> Int Int %(multiplicity 1) -> Int Int %(multiplicity m) -> Int where multiplicity is a modifier keyword, to express the existing features (including implicit generalization of m). Then we can extend this to Int %oneShot -> Int and Int %(matchability M) -> Int and maybe even foo (%type [a]) -- where foo :: forall a -> () which is a modifier that So at the moment, I am inclined to reject this proposal, until I am convinced that we are not painting ourselves into a “all modifiers are types of special kinds and that’s all the syntax and behaviour we ever need” corner. Minor detail: If we can annotate infix use of the (->) “type operator”, should we also be able to annotate other infix operators, i.e. constr ::= (btype | ! atype) {modifier} conop (btype | ! atype) infixexp ::= lexp {modifier} qop infixexp Cheers, Joachim -- Joachim Breitner mail@joachim-breitner.de<mailto:mail@joachim-breitner.de> http://www.joachim-breitner.de/<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.joachim-breitner.de%2F&data=04%7C01%7Csimonpj%40microsoft.com%7C97291bd458234e28f0aa08d89ce27f4f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637431843904133795%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=EOafNT2JtRWPODqAKfG3TNH3xqPEe3%2B5ThuYLbjYPiY%3D&reserved=0> _______________________________________________ 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://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committee&data=04%7C01%7Csimonpj%40microsoft.com%7C97291bd458234e28f0aa08d89ce27f4f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637431843904143751%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=CSx3i0ZoLHVnh6rfNzv1qcJwMCXnRxM6iD%2FxYBRTJP8%3D&reserved=0> _______________________________________________ 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://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committee&data=04%7C01%7Csimonpj%40microsoft.com%7C97291bd458234e28f0aa08d89ce27f4f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637431843904143751%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=CSx3i0ZoLHVnh6rfNzv1qcJwMCXnRxM6iD%2FxYBRTJP8%3D&reserved=0> _______________________________________________ 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://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committee&data=04%7C01%7Csimonpj%40microsoft.com%7C97291bd458234e28f0aa08d89ce27f4f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637431843904153698%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=EEoElFpNjneP9rKR808eGaYKwaV66tLHiN0Tbra0GkA%3D&reserved=0> _______________________________________________ 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://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committee&data=04%7C01%7Csimonpj%40microsoft.com%7C97291bd458234e28f0aa08d89ce27f4f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637431843904153698%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=EEoElFpNjneP9rKR808eGaYKwaV66tLHiN0Tbra0GkA%3D&reserved=0>
Should we mark them as “accepted” with the following text? The Committee accepts this proposal as experimental. This means that the
Committee expects changes to this feature in the future, maybe as the result of other accepted proposals.
If you agree, then we can accept this proposal once a little remaining issue with the grammar has been clarified. Regards, Alejandro On 10 Dec 2020 at 09:59:02, Simon Peyton Jones <simonpj@microsoft.com> wrote:
That was the point of my previous email: accept, and accept-as-experimental are actually one and the same.
Objectively, yes. But I think it helps users to advertise a feature as experimental. It’s a signal to users that this feature is, well, experimental. It is more likely to change.
It’s only an indication not a clear distinction. But I find it helpful.
For me, it also reflects how I evaluate the proposal. For a change to a well-established feature, we have a lot of experience in how people use that feature.
For experimental features we don’t. Example: defaulting for matchability for unsaturated type families. We don’t have unsaturated type families right now, so we don’t have any code that uses them, and hence zero in-the-wild experience about matchability defaulting. We shouldn’t spend ages arguing the toss – just trust Csongor’s judgement and give it a try, but advertising that details may change.
Simon
*From:* Spiwack, Arnaud <arnaud.spiwack@tweag.io> *Sent:* 10 December 2020 08:06 *To:* Alejandro Serrano Mena <trupill@gmail.com> *Cc:* Richard Eisenberg <rae@richarde.dev>; ghc-steering-committee@haskell.org; Simon Peyton Jones < simonpj@microsoft.com> *Subject:* Re: [ghc-steering-committee] #370: Syntax for Modifiers, Recommendation: Acceptance
That was the point of my previous email: accept, and accept-as-experimental are actually one and the same.
What Simon is driving at, I think, is: depending on what the proposal is about, we want to apply more or less strict standard of acceptance (if a proposal is about fixing something in an existing feature, then we better be rather sure that it is indeed an improvement; but if it's about adding something new in an untrodden territory, then we can't really be sure, and it's worth experimenting with).
On Wed, Dec 9, 2020 at 9:17 PM Alejandro Serrano Mena <trupill@gmail.com> wrote:
Dear all,
As the shepherd of this proposal, I’m quite confused about what the outcome should be. The ghc-proposals README states that:
Acceptance of the proposal implies that the implementation will be accepted into GHC provided it is well-engineered, well-documented, and does not complicate the code-base too much.
Most of the Committee seems to lean towards “this seems OK right now, but we don’t want to be locked” or “mark this as experimental”. However, there’s no such notion as “accept as experimental”. Furthermore, as it stands the proposal gives some syntax, and then asks any new extensions to use that syntax; so it cannot be completely thought as a feature by itself.
Regards,
Alejandro
On 9 Dec 2020 at 15:59:43, Spiwack, Arnaud <arnaud.spiwack@tweag.io> wrote:
It's always possible to change. I don't think accepting a proposal means (or ought to mean) that we are locked into anything. Accepting a proposal means that we won't oppose a design-related argument to a PR that implements (part or all of) an accepted proposal.
I don't know how to quantify the degree of confidence that we have in the stability of a proposal. Here we are all saying: this is better than anything so far, and we rather need something like this to be a thing, but it's really a shot in the dark. And this lack of confidence will be reflected in the manual description. But even if we are confident in the stability of a proposal, it may very well happen that it changes dramatically, even soon.
On Wed, Dec 9, 2020 at 2:55 PM Simon Peyton Jones via ghc-steering-committee <ghc-steering-committee@haskell.org> wrote:
I’ve replied on GitHub. Generally in favour. But mark it as experimental… I don’t want to be locked into “we decided on this in Dec 2020 so now it’s too late”. WE can learn from experience.
Simon
*From:* ghc-steering-committee <ghc-steering-committee-bounces@haskell.org> *On Behalf Of *Alejandro Serrano Mena *Sent:* 03 December 2020 20:17 *To:* Richard Eisenberg <rae@richarde.dev> *Cc:* ghc-steering-committee@haskell.org *Subject:* Re: [ghc-steering-committee] #370: Syntax for Modifiers, Recommendation: Acceptance
Dear Committee,
Richard has requested for us to consider the new version of this proposal. As opposed to the previous version, this one is only about reserving syntax for “modifiers”, which at the beginning would be used for things like linearity or matchability of arrows.
I think this is a good proposal, and one which would save us from re-considering syntax for every possible extension (and if linearity appears before the arrow and matchability after it, where would a future dimension go?). Thus I keep recommending acceptance on this new incarnation.
Regards,
Alejandro
On 30 Nov 2020 at 20:52:26, Richard Eisenberg <rae@richarde.dev> wrote:
To my surprise, I found myself leaning against. So I updated and simplified the proposal to remove Modifier. This makes modifiers a bit more magical, but more likely to actually work in practice. The type inference story previously may have been intractable.
I've requested that the committee consider the updates in parallel with community feedback.
Thanks,
Richard
On Nov 30, 2020, at 2:36 PM, Alejandro Serrano Mena <trupill@gmail.com> wrote:
After some discussion in the GitHub thread, changes are going to arrive to the proposal. I think the best is to send the proposal back to the “Needs revision” state.
Regards,
Alejandro
On 29 Nov 2020 at 23:12:44, Eric Seidel <eric@seidel.io> wrote:
I left a few comments and questions on the PR itself, but I'm leaning towards rejecting the proposal in its current form as well. This doesn't (yet) feel like a generic mechanism, in particular because the only modifier that has been specified would be deeply wired into GHC itself.
On Fri, Nov 27, 2020, at 04:46, Joachim Breitner wrote:
Hi,
Am Donnerstag, den 26.11.2020, 14:58 -0500 schrieb Alejandro Serrano
Mena:
Dear all,
This proposal suggests adding syntax for a general notion of
modifiers, like the ones we’ve been talking about lately affecting
linearity or matchability of arrows. For example, if linear types and
unsaturated families are accepted as they stand, we would have `Int
#1 -> @U Bool` (or something like that), whereas with this proposal
we would have the more uniform `Int %1 %Unmatchable -> Bool`.
Since the amount of modifiers is likely to increase in the future, I
think it’s a great idea to agree and reserve such syntax, instead of
coming up with different ways on each proposal. I thus recommend
acceptance of this proposal.
The proposal itself:
(1) introduces syntax for modifiers in types and defines how to
type/kind check them,
(2) reserved such syntax for other uses in declarations and terms.
I think the proposal still has its merits only with (1), even though
I lean towards accepting both parts of it.
I like the idea of reserving syntax here, but parts of the proposal
smell a bit like premature generalization to me. Are we confident that
all annotations we eventually would like to use with this feature can
be expressed as types of a kind that is an instance of Modifier? Or
should we reserve the ability to have annotations that don't fit that
model?
Would we ever have annotation that may affect phases earlier than than
typechecking? What if we want to use (%type e) and (%data e) to help
with the SingleNamepace issues? Look like useful annotations to me, but
I am not sure if they fit the framework proposed here.
The fact that we special-case %1 supports that.
The proposal explicitly has to state “No modifier polymorphism!”. But
isn't that indication that using the type system to model the various
modifiers might be the wrong tool?
I wonder if there is a way where the %(…) on it’s own only reserve
syntax, and the various uses of that syntax can be disambiguated
_statically_ based on the content of ….
Not great syntax, because not concise, enough, but morally I’d feel
more at ease with
Int %(multiplicity Many) -> Int
Int %(multiplicity 1) -> Int
Int %(multiplicity m) -> Int
where multiplicity is a modifier keyword, to express the existing
features (including implicit generalization of m). Then we can extend
this to
Int %oneShot -> Int
and
Int %(matchability M) -> Int
and maybe even
foo (%type [a]) -- where foo :: forall a -> ()
which is a modifier that
So at the moment, I am inclined to reject this proposal, until I am
convinced that we are not painting ourselves into a “all modifiers are
types of special kinds and that’s all the syntax and behaviour we ever
need” corner.
Minor detail: If we can annotate infix use of the (->) “type operator”,
should we also be able to annotate other infix operators, i.e.
constr ::= (btype | ! atype) {modifier} conop (btype | ! atype)
infixexp ::= lexp {modifier} qop infixexp
Cheers,
Joachim
--
Joachim Breitner
mail@joachim-breitner.de
http://www.joachim-breitner.de/ <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.joachim-breitner.de%2F&data=04%7C01%7Csimonpj%40microsoft.com%7C97291bd458234e28f0aa08d89ce27f4f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637431843904133795%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=EOafNT2JtRWPODqAKfG3TNH3xqPEe3%2B5ThuYLbjYPiY%3D&reserved=0>
_______________________________________________
ghc-steering-committee mailing list
ghc-steering-committee@haskell.org
https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committee&data=04%7C01%7Csimonpj%40microsoft.com%7C97291bd458234e28f0aa08d89ce27f4f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637431843904143751%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=CSx3i0ZoLHVnh6rfNzv1qcJwMCXnRxM6iD%2FxYBRTJP8%3D&reserved=0>
_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committee&data=04%7C01%7Csimonpj%40microsoft.com%7C97291bd458234e28f0aa08d89ce27f4f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637431843904143751%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=CSx3i0ZoLHVnh6rfNzv1qcJwMCXnRxM6iD%2FxYBRTJP8%3D&reserved=0>
_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committee&data=04%7C01%7Csimonpj%40microsoft.com%7C97291bd458234e28f0aa08d89ce27f4f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637431843904153698%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=EEoElFpNjneP9rKR808eGaYKwaV66tLHiN0Tbra0GkA%3D&reserved=0>
_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committee&data=04%7C01%7Csimonpj%40microsoft.com%7C97291bd458234e28f0aa08d89ce27f4f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637431843904153698%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=EEoElFpNjneP9rKR808eGaYKwaV66tLHiN0Tbra0GkA%3D&reserved=0>
Sorry -- I've lost track here a bit. What's the issue with the grammar? I'm quite happy to label this experimental. The key aspect of the proposal is just to outline a way forward with adding syntax. Richard
On Dec 10, 2020, at 4:29 AM, Alejandro Serrano Mena <trupill@gmail.com> wrote:
Should we mark them as “accepted” with the following text?
The Committee accepts this proposal as experimental. This means that the Committee expects changes to this feature in the future, maybe as the result of other accepted proposals.
If you agree, then we can accept this proposal once a little remaining issue with the grammar has been clarified.
Regards, Alejandro
On 10 Dec 2020 at 09:59:02, Simon Peyton Jones <simonpj@microsoft.com <mailto:simonpj@microsoft.com>> wrote: That was the point of my previous email: accept, and accept-as-experimental are actually one and the same.
Objectively, yes. But I think it helps users to advertise a feature as experimental. It’s a signal to users that this feature is, well, experimental. It is more likely to change.
It’s only an indication not a clear distinction. But I find it helpful.
For me, it also reflects how I evaluate the proposal. For a change to a well-established feature, we have a lot of experience in how people use that feature.
For experimental features we don’t. Example: defaulting for matchability for unsaturated type families. We don’t have unsaturated type families right now, so we don’t have any code that uses them, and hence zero in-the-wild experience about matchability defaulting. We shouldn’t spend ages arguing the toss – just trust Csongor’s judgement and give it a try, but advertising that details may change.
Simon
From: Spiwack, Arnaud <arnaud.spiwack@tweag.io <mailto:arnaud.spiwack@tweag.io>> Sent: 10 December 2020 08:06 To: Alejandro Serrano Mena <trupill@gmail.com <mailto:trupill@gmail.com>> Cc: Richard Eisenberg <rae@richarde.dev <mailto:rae@richarde.dev>>; ghc-steering-committee@haskell.org <mailto:ghc-steering-committee@haskell.org>; Simon Peyton Jones <simonpj@microsoft.com <mailto:simonpj@microsoft.com>> Subject: Re: [ghc-steering-committee] #370: Syntax for Modifiers, Recommendation: Acceptance
That was the point of my previous email: accept, and accept-as-experimental are actually one and the same.
What Simon is driving at, I think, is: depending on what the proposal is about, we want to apply more or less strict standard of acceptance (if a proposal is about fixing something in an existing feature, then we better be rather sure that it is indeed an improvement; but if it's about adding something new in an untrodden territory, then we can't really be sure, and it's worth experimenting with).
On Wed, Dec 9, 2020 at 9:17 PM Alejandro Serrano Mena <trupill@gmail.com <mailto:trupill@gmail.com>> wrote:
Dear all,
As the shepherd of this proposal, I’m quite confused about what the outcome should be. The ghc-proposals README states that:
Acceptance of the proposal implies that the implementation will be accepted into GHC provided it is well-engineered, well-documented, and does not complicate the code-base too much.
Most of the Committee seems to lean towards “this seems OK right now, but we don’t want to be locked” or “mark this as experimental”. However, there’s no such notion as “accept as experimental”. Furthermore, as it stands the proposal gives some syntax, and then asks any new extensions to use that syntax; so it cannot be completely thought as a feature by itself.
Regards,
Alejandro
On 9 Dec 2020 at 15:59:43, Spiwack, Arnaud <arnaud.spiwack@tweag.io <mailto:arnaud.spiwack@tweag.io>> wrote:
It's always possible to change. I don't think accepting a proposal means (or ought to mean) that we are locked into anything. Accepting a proposal means that we won't oppose a design-related argument to a PR that implements (part or all of) an accepted proposal.
I don't know how to quantify the degree of confidence that we have in the stability of a proposal. Here we are all saying: this is better than anything so far, and we rather need something like this to be a thing, but it's really a shot in the dark. And this lack of confidence will be reflected in the manual description. But even if we are confident in the stability of a proposal, it may very well happen that it changes dramatically, even soon.
On Wed, Dec 9, 2020 at 2:55 PM Simon Peyton Jones via ghc-steering-committee <ghc-steering-committee@haskell.org <mailto:ghc-steering-committee@haskell.org>> wrote:
I’ve replied on GitHub. Generally in favour. But mark it as experimental… I don’t want to be locked into “we decided on this in Dec 2020 so now it’s too late”. WE can learn from experience.
Simon
From: ghc-steering-committee <ghc-steering-committee-bounces@haskell.org <mailto:ghc-steering-committee-bounces@haskell.org>> On Behalf Of Alejandro Serrano Mena Sent: 03 December 2020 20:17 To: Richard Eisenberg <rae@richarde.dev <mailto:rae@richarde.dev>> Cc: ghc-steering-committee@haskell.org <mailto:ghc-steering-committee@haskell.org> Subject: Re: [ghc-steering-committee] #370: Syntax for Modifiers, Recommendation: Acceptance
Dear Committee,
Richard has requested for us to consider the new version of this proposal. As opposed to the previous version, this one is only about reserving syntax for “modifiers”, which at the beginning would be used for things like linearity or matchability of arrows.
I think this is a good proposal, and one which would save us from re-considering syntax for every possible extension (and if linearity appears before the arrow and matchability after it, where would a future dimension go?). Thus I keep recommending acceptance on this new incarnation.
Regards,
Alejandro
On 30 Nov 2020 at 20:52:26, Richard Eisenberg <rae@richarde.dev <mailto:rae@richarde.dev>> wrote:
To my surprise, I found myself leaning against. So I updated and simplified the proposal to remove Modifier. This makes modifiers a bit more magical, but more likely to actually work in practice. The type inference story previously may have been intractable.
I've requested that the committee consider the updates in parallel with community feedback.
Thanks,
Richard
On Nov 30, 2020, at 2:36 PM, Alejandro Serrano Mena <trupill@gmail.com <mailto:trupill@gmail.com>> wrote:
After some discussion in the GitHub thread, changes are going to arrive to the proposal. I think the best is to send the proposal back to the “Needs revision” state.
Regards,
Alejandro
On 29 Nov 2020 at 23:12:44, Eric Seidel <eric@seidel.io <mailto:eric@seidel.io>> wrote:
I left a few comments and questions on the PR itself, but I'm leaning towards rejecting the proposal in its current form as well. This doesn't (yet) feel like a generic mechanism, in particular because the only modifier that has been specified would be deeply wired into GHC itself.
On Fri, Nov 27, 2020, at 04:46, Joachim Breitner wrote:
Hi,
Am Donnerstag, den 26.11.2020, 14:58 -0500 schrieb Alejandro Serrano
Mena:
Dear all,
This proposal suggests adding syntax for a general notion of
modifiers, like the ones we’ve been talking about lately affecting
linearity or matchability of arrows. For example, if linear types and
unsaturated families are accepted as they stand, we would have `Int
#1 -> @U Bool` (or something like that), whereas with this proposal
we would have the more uniform `Int %1 %Unmatchable -> Bool`.
Since the amount of modifiers is likely to increase in the future, I
think it’s a great idea to agree and reserve such syntax, instead of
coming up with different ways on each proposal. I thus recommend
acceptance of this proposal.
The proposal itself:
(1) introduces syntax for modifiers in types and defines how to
type/kind check them,
(2) reserved such syntax for other uses in declarations and terms.
I think the proposal still has its merits only with (1), even though
I lean towards accepting both parts of it.
I like the idea of reserving syntax here, but parts of the proposal
smell a bit like premature generalization to me. Are we confident that
all annotations we eventually would like to use with this feature can
be expressed as types of a kind that is an instance of Modifier? Or
should we reserve the ability to have annotations that don't fit that
model?
Would we ever have annotation that may affect phases earlier than than
typechecking? What if we want to use (%type e) and (%data e) to help
with the SingleNamepace issues? Look like useful annotations to me, but
I am not sure if they fit the framework proposed here.
The fact that we special-case %1 supports that.
The proposal explicitly has to state “No modifier polymorphism!”. But
isn't that indication that using the type system to model the various
modifiers might be the wrong tool?
I wonder if there is a way where the %(…) on it’s own only reserve
syntax, and the various uses of that syntax can be disambiguated
_statically_ based on the content of ….
Not great syntax, because not concise, enough, but morally I’d feel
more at ease with
Int %(multiplicity Many) -> Int
Int %(multiplicity 1) -> Int
Int %(multiplicity m) -> Int
where multiplicity is a modifier keyword, to express the existing
features (including implicit generalization of m). Then we can extend
this to
Int %oneShot -> Int
and
Int %(matchability M) -> Int
and maybe even
foo (%type [a]) -- where foo :: forall a -> ()
which is a modifier that
So at the moment, I am inclined to reject this proposal, until I am
convinced that we are not painting ourselves into a “all modifiers are
types of special kinds and that’s all the syntax and behaviour we ever
need” corner.
Minor detail: If we can annotate infix use of the (->) “type operator”,
should we also be able to annotate other infix operators, i.e.
constr ::= (btype | ! atype) {modifier} conop (btype | ! atype)
infixexp ::= lexp {modifier} qop infixexp
Cheers,
Joachim
--
Joachim Breitner
mail@joachim-breitner.de <mailto:mail@joachim-breitner.de> http://www.joachim-breitner.de/ <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.joachim-breitner.de%2F&data=04%7C01%7Csimonpj%40microsoft.com%7C97291bd458234e28f0aa08d89ce27f4f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637431843904133795%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=EOafNT2JtRWPODqAKfG3TNH3xqPEe3%2B5ThuYLbjYPiY%3D&reserved=0>
_______________________________________________
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://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committee&data=04%7C01%7Csimonpj%40microsoft.com%7C97291bd458234e28f0aa08d89ce27f4f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637431843904143751%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=CSx3i0ZoLHVnh6rfNzv1qcJwMCXnRxM6iD%2FxYBRTJP8%3D&reserved=0>
_______________________________________________ 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://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committee&data=04%7C01%7Csimonpj%40microsoft.com%7C97291bd458234e28f0aa08d89ce27f4f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637431843904143751%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=CSx3i0ZoLHVnh6rfNzv1qcJwMCXnRxM6iD%2FxYBRTJP8%3D&reserved=0> _______________________________________________ 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://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committee&data=04%7C01%7Csimonpj%40microsoft.com%7C97291bd458234e28f0aa08d89ce27f4f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637431843904153698%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=EEoElFpNjneP9rKR808eGaYKwaV66tLHiN0Tbra0GkA%3D&reserved=0>
_______________________________________________ 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://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committee&data=04%7C01%7Csimonpj%40microsoft.com%7C97291bd458234e28f0aa08d89ce27f4f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637431843904153698%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=EEoElFpNjneP9rKR808eGaYKwaV66tLHiN0Tbra0GkA%3D&reserved=0>
On 11 Dec 2020 at 21:35:20, Richard Eisenberg <rae@richarde.dev> wrote:
Sorry -- I've lost track here a bit. What's the issue with the grammar?
In this comment https://github.com/ghc-proposals/ghc-proposals/pull/370#issuecomment-7417851... : Syntax: the form btype [ {modifier} -> type ] seems to allow one or zero
modifiers but not two. Or do I misunderstand the braces? Spell it out please
Regards, Alejandro
I'm quite happy to label this experimental. The key aspect of the proposal is just to outline a way forward with adding syntax.
Richard
On Dec 10, 2020, at 4:29 AM, Alejandro Serrano Mena <trupill@gmail.com> wrote:
Should we mark them as “accepted” with the following text?
The Committee accepts this proposal as experimental. This means that the
Committee expects changes to this feature in the future, maybe as the result of other accepted proposals.
If you agree, then we can accept this proposal once a little remaining issue with the grammar has been clarified.
Regards, Alejandro
On 10 Dec 2020 at 09:59:02, Simon Peyton Jones <simonpj@microsoft.com> wrote:
That was the point of my previous email: accept, and accept-as-experimental are actually one and the same.
Objectively, yes. But I think it helps users to advertise a feature as experimental. It’s a signal to users that this feature is, well, experimental. It is more likely to change.
It’s only an indication not a clear distinction. But I find it helpful.
For me, it also reflects how I evaluate the proposal. For a change to a well-established feature, we have a lot of experience in how people use that feature.
For experimental features we don’t. Example: defaulting for matchability for unsaturated type families. We don’t have unsaturated type families right now, so we don’t have any code that uses them, and hence zero in-the-wild experience about matchability defaulting. We shouldn’t spend ages arguing the toss – just trust Csongor’s judgement and give it a try, but advertising that details may change.
Simon
*From:* Spiwack, Arnaud <arnaud.spiwack@tweag.io> *Sent:* 10 December 2020 08:06 *To:* Alejandro Serrano Mena <trupill@gmail.com> *Cc:* Richard Eisenberg <rae@richarde.dev>; ghc-steering-committee@haskell.org; Simon Peyton Jones < simonpj@microsoft.com> *Subject:* Re: [ghc-steering-committee] #370: Syntax for Modifiers, Recommendation: Acceptance
That was the point of my previous email: accept, and accept-as-experimental are actually one and the same.
What Simon is driving at, I think, is: depending on what the proposal is about, we want to apply more or less strict standard of acceptance (if a proposal is about fixing something in an existing feature, then we better be rather sure that it is indeed an improvement; but if it's about adding something new in an untrodden territory, then we can't really be sure, and it's worth experimenting with).
On Wed, Dec 9, 2020 at 9:17 PM Alejandro Serrano Mena <trupill@gmail.com> wrote:
Dear all,
As the shepherd of this proposal, I’m quite confused about what the outcome should be. The ghc-proposals README states that:
Acceptance of the proposal implies that the implementation will be accepted into GHC provided it is well-engineered, well-documented, and does not complicate the code-base too much.
Most of the Committee seems to lean towards “this seems OK right now, but we don’t want to be locked” or “mark this as experimental”. However, there’s no such notion as “accept as experimental”. Furthermore, as it stands the proposal gives some syntax, and then asks any new extensions to use that syntax; so it cannot be completely thought as a feature by itself.
Regards,
Alejandro
On 9 Dec 2020 at 15:59:43, Spiwack, Arnaud <arnaud.spiwack@tweag.io> wrote:
It's always possible to change. I don't think accepting a proposal means (or ought to mean) that we are locked into anything. Accepting a proposal means that we won't oppose a design-related argument to a PR that implements (part or all of) an accepted proposal.
I don't know how to quantify the degree of confidence that we have in the stability of a proposal. Here we are all saying: this is better than anything so far, and we rather need something like this to be a thing, but it's really a shot in the dark. And this lack of confidence will be reflected in the manual description. But even if we are confident in the stability of a proposal, it may very well happen that it changes dramatically, even soon.
On Wed, Dec 9, 2020 at 2:55 PM Simon Peyton Jones via ghc-steering-committee <ghc-steering-committee@haskell.org> wrote:
I’ve replied on GitHub. Generally in favour. But mark it as experimental… I don’t want to be locked into “we decided on this in Dec 2020 so now it’s too late”. WE can learn from experience.
Simon
*From:* ghc-steering-committee < ghc-steering-committee-bounces@haskell.org> *On Behalf Of *Alejandro Serrano Mena *Sent:* 03 December 2020 20:17 *To:* Richard Eisenberg <rae@richarde.dev> *Cc:* ghc-steering-committee@haskell.org *Subject:* Re: [ghc-steering-committee] #370: Syntax for Modifiers, Recommendation: Acceptance
Dear Committee,
Richard has requested for us to consider the new version of this proposal. As opposed to the previous version, this one is only about reserving syntax for “modifiers”, which at the beginning would be used for things like linearity or matchability of arrows.
I think this is a good proposal, and one which would save us from re-considering syntax for every possible extension (and if linearity appears before the arrow and matchability after it, where would a future dimension go?). Thus I keep recommending acceptance on this new incarnation.
Regards,
Alejandro
On 30 Nov 2020 at 20:52:26, Richard Eisenberg <rae@richarde.dev> wrote:
To my surprise, I found myself leaning against. So I updated and simplified the proposal to remove Modifier. This makes modifiers a bit more magical, but more likely to actually work in practice. The type inference story previously may have been intractable.
I've requested that the committee consider the updates in parallel with community feedback.
Thanks,
Richard
On Nov 30, 2020, at 2:36 PM, Alejandro Serrano Mena <trupill@gmail.com> wrote:
After some discussion in the GitHub thread, changes are going to arrive to the proposal. I think the best is to send the proposal back to the “Needs revision” state.
Regards,
Alejandro
On 29 Nov 2020 at 23:12:44, Eric Seidel <eric@seidel.io> wrote:
I left a few comments and questions on the PR itself, but I'm leaning towards rejecting the proposal in its current form as well. This doesn't (yet) feel like a generic mechanism, in particular because the only modifier that has been specified would be deeply wired into GHC itself.
On Fri, Nov 27, 2020, at 04:46, Joachim Breitner wrote:
Hi,
Am Donnerstag, den 26.11.2020, 14:58 -0500 schrieb Alejandro Serrano
Mena:
Dear all,
This proposal suggests adding syntax for a general notion of
modifiers, like the ones we’ve been talking about lately affecting
linearity or matchability of arrows. For example, if linear types and
unsaturated families are accepted as they stand, we would have `Int
#1 -> @U Bool` (or something like that), whereas with this proposal
we would have the more uniform `Int %1 %Unmatchable -> Bool`.
Since the amount of modifiers is likely to increase in the future, I
think it’s a great idea to agree and reserve such syntax, instead of
coming up with different ways on each proposal. I thus recommend
acceptance of this proposal.
The proposal itself:
(1) introduces syntax for modifiers in types and defines how to
type/kind check them,
(2) reserved such syntax for other uses in declarations and terms.
I think the proposal still has its merits only with (1), even though
I lean towards accepting both parts of it.
I like the idea of reserving syntax here, but parts of the proposal
smell a bit like premature generalization to me. Are we confident that
all annotations we eventually would like to use with this feature can
be expressed as types of a kind that is an instance of Modifier? Or
should we reserve the ability to have annotations that don't fit that
model?
Would we ever have annotation that may affect phases earlier than than
typechecking? What if we want to use (%type e) and (%data e) to help
with the SingleNamepace issues? Look like useful annotations to me, but
I am not sure if they fit the framework proposed here.
The fact that we special-case %1 supports that.
The proposal explicitly has to state “No modifier polymorphism!”. But
isn't that indication that using the type system to model the various
modifiers might be the wrong tool?
I wonder if there is a way where the %(…) on it’s own only reserve
syntax, and the various uses of that syntax can be disambiguated
_statically_ based on the content of ….
Not great syntax, because not concise, enough, but morally I’d feel
more at ease with
Int %(multiplicity Many) -> Int
Int %(multiplicity 1) -> Int
Int %(multiplicity m) -> Int
where multiplicity is a modifier keyword, to express the existing
features (including implicit generalization of m). Then we can extend
this to
Int %oneShot -> Int
and
Int %(matchability M) -> Int
and maybe even
foo (%type [a]) -- where foo :: forall a -> ()
which is a modifier that
So at the moment, I am inclined to reject this proposal, until I am
convinced that we are not painting ourselves into a “all modifiers are
types of special kinds and that’s all the syntax and behaviour we ever
need” corner.
Minor detail: If we can annotate infix use of the (->) “type operator”,
should we also be able to annotate other infix operators, i.e.
constr ::= (btype | ! atype) {modifier} conop (btype | ! atype)
infixexp ::= lexp {modifier} qop infixexp
Cheers,
Joachim
--
Joachim Breitner
mail@joachim-breitner.de
http://www.joachim-breitner.de/ <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.joachim-breitner.de%2F&data=04%7C01%7Csimonpj%40microsoft.com%7C97291bd458234e28f0aa08d89ce27f4f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637431843904133795%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=EOafNT2JtRWPODqAKfG3TNH3xqPEe3%2B5ThuYLbjYPiY%3D&reserved=0>
_______________________________________________
ghc-steering-committee mailing list
ghc-steering-committee@haskell.org
https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committee&data=04%7C01%7Csimonpj%40microsoft.com%7C97291bd458234e28f0aa08d89ce27f4f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637431843904143751%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=CSx3i0ZoLHVnh6rfNzv1qcJwMCXnRxM6iD%2FxYBRTJP8%3D&reserved=0>
_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committee&data=04%7C01%7Csimonpj%40microsoft.com%7C97291bd458234e28f0aa08d89ce27f4f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637431843904143751%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=CSx3i0ZoLHVnh6rfNzv1qcJwMCXnRxM6iD%2FxYBRTJP8%3D&reserved=0>
_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committee&data=04%7C01%7Csimonpj%40microsoft.com%7C97291bd458234e28f0aa08d89ce27f4f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637431843904153698%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=EEoElFpNjneP9rKR808eGaYKwaV66tLHiN0Tbra0GkA%3D&reserved=0>
_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committee&data=04%7C01%7Csimonpj%40microsoft.com%7C97291bd458234e28f0aa08d89ce27f4f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637431843904153698%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=EEoElFpNjneP9rKR808eGaYKwaV66tLHiN0Tbra0GkA%3D&reserved=0>
It seems that everything is solve now. Are the any further objections? Otherwise I guess in a couple of days we can mark this as accepted. Regards, Alejandro On 11 Dec 2020 at 22:39:39, Alejandro Serrano Mena <trupill@gmail.com> wrote:
On 11 Dec 2020 at 21:35:20, Richard Eisenberg <rae@richarde.dev> wrote:
Sorry -- I've lost track here a bit. What's the issue with the grammar?
In this comment https://github.com/ghc-proposals/ghc-proposals/pull/370#issuecomment-7417851... :
Syntax: the form btype [ {modifier} -> type ] seems to allow one or zero
modifiers but not two. Or do I misunderstand the braces? Spell it out please
Regards, Alejandro
I'm quite happy to label this experimental. The key aspect of the proposal is just to outline a way forward with adding syntax.
Richard
On Dec 10, 2020, at 4:29 AM, Alejandro Serrano Mena <trupill@gmail.com> wrote:
Should we mark them as “accepted” with the following text?
The Committee accepts this proposal as experimental. This means that the
Committee expects changes to this feature in the future, maybe as the result of other accepted proposals.
If you agree, then we can accept this proposal once a little remaining issue with the grammar has been clarified.
Regards, Alejandro
On 10 Dec 2020 at 09:59:02, Simon Peyton Jones <simonpj@microsoft.com> wrote:
That was the point of my previous email: accept, and accept-as-experimental are actually one and the same.
Objectively, yes. But I think it helps users to advertise a feature as experimental. It’s a signal to users that this feature is, well, experimental. It is more likely to change.
It’s only an indication not a clear distinction. But I find it helpful.
For me, it also reflects how I evaluate the proposal. For a change to a well-established feature, we have a lot of experience in how people use that feature.
For experimental features we don’t. Example: defaulting for matchability for unsaturated type families. We don’t have unsaturated type families right now, so we don’t have any code that uses them, and hence zero in-the-wild experience about matchability defaulting. We shouldn’t spend ages arguing the toss – just trust Csongor’s judgement and give it a try, but advertising that details may change.
Simon
*From:* Spiwack, Arnaud <arnaud.spiwack@tweag.io> *Sent:* 10 December 2020 08:06 *To:* Alejandro Serrano Mena <trupill@gmail.com> *Cc:* Richard Eisenberg <rae@richarde.dev>; ghc-steering-committee@haskell.org; Simon Peyton Jones < simonpj@microsoft.com> *Subject:* Re: [ghc-steering-committee] #370: Syntax for Modifiers, Recommendation: Acceptance
That was the point of my previous email: accept, and accept-as-experimental are actually one and the same.
What Simon is driving at, I think, is: depending on what the proposal is about, we want to apply more or less strict standard of acceptance (if a proposal is about fixing something in an existing feature, then we better be rather sure that it is indeed an improvement; but if it's about adding something new in an untrodden territory, then we can't really be sure, and it's worth experimenting with).
On Wed, Dec 9, 2020 at 9:17 PM Alejandro Serrano Mena <trupill@gmail.com> wrote:
Dear all,
As the shepherd of this proposal, I’m quite confused about what the outcome should be. The ghc-proposals README states that:
Acceptance of the proposal implies that the implementation will be accepted into GHC provided it is well-engineered, well-documented, and does not complicate the code-base too much.
Most of the Committee seems to lean towards “this seems OK right now, but we don’t want to be locked” or “mark this as experimental”. However, there’s no such notion as “accept as experimental”. Furthermore, as it stands the proposal gives some syntax, and then asks any new extensions to use that syntax; so it cannot be completely thought as a feature by itself.
Regards,
Alejandro
On 9 Dec 2020 at 15:59:43, Spiwack, Arnaud <arnaud.spiwack@tweag.io> wrote:
It's always possible to change. I don't think accepting a proposal means (or ought to mean) that we are locked into anything. Accepting a proposal means that we won't oppose a design-related argument to a PR that implements (part or all of) an accepted proposal.
I don't know how to quantify the degree of confidence that we have in the stability of a proposal. Here we are all saying: this is better than anything so far, and we rather need something like this to be a thing, but it's really a shot in the dark. And this lack of confidence will be reflected in the manual description. But even if we are confident in the stability of a proposal, it may very well happen that it changes dramatically, even soon.
On Wed, Dec 9, 2020 at 2:55 PM Simon Peyton Jones via ghc-steering-committee <ghc-steering-committee@haskell.org> wrote:
I’ve replied on GitHub. Generally in favour. But mark it as experimental… I don’t want to be locked into “we decided on this in Dec 2020 so now it’s too late”. WE can learn from experience.
Simon
*From:* ghc-steering-committee < ghc-steering-committee-bounces@haskell.org> *On Behalf Of *Alejandro Serrano Mena *Sent:* 03 December 2020 20:17 *To:* Richard Eisenberg <rae@richarde.dev> *Cc:* ghc-steering-committee@haskell.org *Subject:* Re: [ghc-steering-committee] #370: Syntax for Modifiers, Recommendation: Acceptance
Dear Committee,
Richard has requested for us to consider the new version of this proposal. As opposed to the previous version, this one is only about reserving syntax for “modifiers”, which at the beginning would be used for things like linearity or matchability of arrows.
I think this is a good proposal, and one which would save us from re-considering syntax for every possible extension (and if linearity appears before the arrow and matchability after it, where would a future dimension go?). Thus I keep recommending acceptance on this new incarnation.
Regards,
Alejandro
On 30 Nov 2020 at 20:52:26, Richard Eisenberg <rae@richarde.dev> wrote:
To my surprise, I found myself leaning against. So I updated and simplified the proposal to remove Modifier. This makes modifiers a bit more magical, but more likely to actually work in practice. The type inference story previously may have been intractable.
I've requested that the committee consider the updates in parallel with community feedback.
Thanks,
Richard
On Nov 30, 2020, at 2:36 PM, Alejandro Serrano Mena <trupill@gmail.com> wrote:
After some discussion in the GitHub thread, changes are going to arrive to the proposal. I think the best is to send the proposal back to the “Needs revision” state.
Regards,
Alejandro
On 29 Nov 2020 at 23:12:44, Eric Seidel <eric@seidel.io> wrote:
I left a few comments and questions on the PR itself, but I'm leaning towards rejecting the proposal in its current form as well. This doesn't (yet) feel like a generic mechanism, in particular because the only modifier that has been specified would be deeply wired into GHC itself.
On Fri, Nov 27, 2020, at 04:46, Joachim Breitner wrote:
Hi,
Am Donnerstag, den 26.11.2020, 14:58 -0500 schrieb Alejandro Serrano
Mena:
Dear all,
This proposal suggests adding syntax for a general notion of
modifiers, like the ones we’ve been talking about lately affecting
linearity or matchability of arrows. For example, if linear types and
unsaturated families are accepted as they stand, we would have `Int
#1 -> @U Bool` (or something like that), whereas with this proposal
we would have the more uniform `Int %1 %Unmatchable -> Bool`.
Since the amount of modifiers is likely to increase in the future, I
think it’s a great idea to agree and reserve such syntax, instead of
coming up with different ways on each proposal. I thus recommend
acceptance of this proposal.
The proposal itself:
(1) introduces syntax for modifiers in types and defines how to
type/kind check them,
(2) reserved such syntax for other uses in declarations and terms.
I think the proposal still has its merits only with (1), even though
I lean towards accepting both parts of it.
I like the idea of reserving syntax here, but parts of the proposal
smell a bit like premature generalization to me. Are we confident that
all annotations we eventually would like to use with this feature can
be expressed as types of a kind that is an instance of Modifier? Or
should we reserve the ability to have annotations that don't fit that
model?
Would we ever have annotation that may affect phases earlier than than
typechecking? What if we want to use (%type e) and (%data e) to help
with the SingleNamepace issues? Look like useful annotations to me, but
I am not sure if they fit the framework proposed here.
The fact that we special-case %1 supports that.
The proposal explicitly has to state “No modifier polymorphism!”. But
isn't that indication that using the type system to model the various
modifiers might be the wrong tool?
I wonder if there is a way where the %(…) on it’s own only reserve
syntax, and the various uses of that syntax can be disambiguated
_statically_ based on the content of ….
Not great syntax, because not concise, enough, but morally I’d feel
more at ease with
Int %(multiplicity Many) -> Int
Int %(multiplicity 1) -> Int
Int %(multiplicity m) -> Int
where multiplicity is a modifier keyword, to express the existing
features (including implicit generalization of m). Then we can extend
this to
Int %oneShot -> Int
and
Int %(matchability M) -> Int
and maybe even
foo (%type [a]) -- where foo :: forall a -> ()
which is a modifier that
So at the moment, I am inclined to reject this proposal, until I am
convinced that we are not painting ourselves into a “all modifiers are
types of special kinds and that’s all the syntax and behaviour we ever
need” corner.
Minor detail: If we can annotate infix use of the (->) “type operator”,
should we also be able to annotate other infix operators, i.e.
constr ::= (btype | ! atype) {modifier} conop (btype | ! atype)
infixexp ::= lexp {modifier} qop infixexp
Cheers,
Joachim
--
Joachim Breitner
mail@joachim-breitner.de
http://www.joachim-breitner.de/ <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.joachim-breitner.de%2F&data=04%7C01%7Csimonpj%40microsoft.com%7C97291bd458234e28f0aa08d89ce27f4f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637431843904133795%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=EOafNT2JtRWPODqAKfG3TNH3xqPEe3%2B5ThuYLbjYPiY%3D&reserved=0>
_______________________________________________
ghc-steering-committee mailing list
ghc-steering-committee@haskell.org
https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committee&data=04%7C01%7Csimonpj%40microsoft.com%7C97291bd458234e28f0aa08d89ce27f4f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637431843904143751%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=CSx3i0ZoLHVnh6rfNzv1qcJwMCXnRxM6iD%2FxYBRTJP8%3D&reserved=0>
_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committee&data=04%7C01%7Csimonpj%40microsoft.com%7C97291bd458234e28f0aa08d89ce27f4f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637431843904143751%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=CSx3i0ZoLHVnh6rfNzv1qcJwMCXnRxM6iD%2FxYBRTJP8%3D&reserved=0>
_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committee&data=04%7C01%7Csimonpj%40microsoft.com%7C97291bd458234e28f0aa08d89ce27f4f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637431843904153698%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=EEoElFpNjneP9rKR808eGaYKwaV66tLHiN0Tbra0GkA%3D&reserved=0>
_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committee&data=04%7C01%7Csimonpj%40microsoft.com%7C97291bd458234e28f0aa08d89ce27f4f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637431843904153698%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=EEoElFpNjneP9rKR808eGaYKwaV66tLHiN0Tbra0GkA%3D&reserved=0>
Dear Committee, I think we can mark this as accepted now. Regards, Alejandro On 15 Dec 2020 at 21:06:51, Alejandro Serrano Mena <trupill@gmail.com> wrote:
It seems that everything is solve now. Are the any further objections? Otherwise I guess in a couple of days we can mark this as accepted.
Regards, Alejandro
On 11 Dec 2020 at 22:39:39, Alejandro Serrano Mena <trupill@gmail.com> wrote:
On 11 Dec 2020 at 21:35:20, Richard Eisenberg <rae@richarde.dev> wrote:
Sorry -- I've lost track here a bit. What's the issue with the grammar?
In this comment https://github.com/ghc-proposals/ghc-proposals/pull/370#issuecomment-7417851... :
Syntax: the form btype [ {modifier} -> type ] seems to allow one or zero
modifiers but not two. Or do I misunderstand the braces? Spell it out please
Regards, Alejandro
I'm quite happy to label this experimental. The key aspect of the proposal is just to outline a way forward with adding syntax.
Richard
On Dec 10, 2020, at 4:29 AM, Alejandro Serrano Mena <trupill@gmail.com> wrote:
Should we mark them as “accepted” with the following text?
The Committee accepts this proposal as experimental. This means that the
Committee expects changes to this feature in the future, maybe as the result of other accepted proposals.
If you agree, then we can accept this proposal once a little remaining issue with the grammar has been clarified.
Regards, Alejandro
On 10 Dec 2020 at 09:59:02, Simon Peyton Jones <simonpj@microsoft.com> wrote:
That was the point of my previous email: accept, and accept-as-experimental are actually one and the same.
Objectively, yes. But I think it helps users to advertise a feature as experimental. It’s a signal to users that this feature is, well, experimental. It is more likely to change.
It’s only an indication not a clear distinction. But I find it helpful.
For me, it also reflects how I evaluate the proposal. For a change to a well-established feature, we have a lot of experience in how people use that feature.
For experimental features we don’t. Example: defaulting for matchability for unsaturated type families. We don’t have unsaturated type families right now, so we don’t have any code that uses them, and hence zero in-the-wild experience about matchability defaulting. We shouldn’t spend ages arguing the toss – just trust Csongor’s judgement and give it a try, but advertising that details may change.
Simon
*From:* Spiwack, Arnaud <arnaud.spiwack@tweag.io> *Sent:* 10 December 2020 08:06 *To:* Alejandro Serrano Mena <trupill@gmail.com> *Cc:* Richard Eisenberg <rae@richarde.dev>; ghc-steering-committee@haskell.org; Simon Peyton Jones < simonpj@microsoft.com> *Subject:* Re: [ghc-steering-committee] #370: Syntax for Modifiers, Recommendation: Acceptance
That was the point of my previous email: accept, and accept-as-experimental are actually one and the same.
What Simon is driving at, I think, is: depending on what the proposal is about, we want to apply more or less strict standard of acceptance (if a proposal is about fixing something in an existing feature, then we better be rather sure that it is indeed an improvement; but if it's about adding something new in an untrodden territory, then we can't really be sure, and it's worth experimenting with).
On Wed, Dec 9, 2020 at 9:17 PM Alejandro Serrano Mena < trupill@gmail.com> wrote:
Dear all,
As the shepherd of this proposal, I’m quite confused about what the outcome should be. The ghc-proposals README states that:
Acceptance of the proposal implies that the implementation will be accepted into GHC provided it is well-engineered, well-documented, and does not complicate the code-base too much.
Most of the Committee seems to lean towards “this seems OK right now, but we don’t want to be locked” or “mark this as experimental”. However, there’s no such notion as “accept as experimental”. Furthermore, as it stands the proposal gives some syntax, and then asks any new extensions to use that syntax; so it cannot be completely thought as a feature by itself.
Regards,
Alejandro
On 9 Dec 2020 at 15:59:43, Spiwack, Arnaud <arnaud.spiwack@tweag.io> wrote:
It's always possible to change. I don't think accepting a proposal means (or ought to mean) that we are locked into anything. Accepting a proposal means that we won't oppose a design-related argument to a PR that implements (part or all of) an accepted proposal.
I don't know how to quantify the degree of confidence that we have in the stability of a proposal. Here we are all saying: this is better than anything so far, and we rather need something like this to be a thing, but it's really a shot in the dark. And this lack of confidence will be reflected in the manual description. But even if we are confident in the stability of a proposal, it may very well happen that it changes dramatically, even soon.
On Wed, Dec 9, 2020 at 2:55 PM Simon Peyton Jones via ghc-steering-committee <ghc-steering-committee@haskell.org> wrote:
I’ve replied on GitHub. Generally in favour. But mark it as experimental… I don’t want to be locked into “we decided on this in Dec 2020 so now it’s too late”. WE can learn from experience.
Simon
*From:* ghc-steering-committee < ghc-steering-committee-bounces@haskell.org> *On Behalf Of *Alejandro Serrano Mena *Sent:* 03 December 2020 20:17 *To:* Richard Eisenberg <rae@richarde.dev> *Cc:* ghc-steering-committee@haskell.org *Subject:* Re: [ghc-steering-committee] #370: Syntax for Modifiers, Recommendation: Acceptance
Dear Committee,
Richard has requested for us to consider the new version of this proposal. As opposed to the previous version, this one is only about reserving syntax for “modifiers”, which at the beginning would be used for things like linearity or matchability of arrows.
I think this is a good proposal, and one which would save us from re-considering syntax for every possible extension (and if linearity appears before the arrow and matchability after it, where would a future dimension go?). Thus I keep recommending acceptance on this new incarnation.
Regards,
Alejandro
On 30 Nov 2020 at 20:52:26, Richard Eisenberg <rae@richarde.dev> wrote:
To my surprise, I found myself leaning against. So I updated and simplified the proposal to remove Modifier. This makes modifiers a bit more magical, but more likely to actually work in practice. The type inference story previously may have been intractable.
I've requested that the committee consider the updates in parallel with community feedback.
Thanks,
Richard
On Nov 30, 2020, at 2:36 PM, Alejandro Serrano Mena <trupill@gmail.com> wrote:
After some discussion in the GitHub thread, changes are going to arrive to the proposal. I think the best is to send the proposal back to the “Needs revision” state.
Regards,
Alejandro
On 29 Nov 2020 at 23:12:44, Eric Seidel <eric@seidel.io> wrote:
I left a few comments and questions on the PR itself, but I'm leaning towards rejecting the proposal in its current form as well. This doesn't (yet) feel like a generic mechanism, in particular because the only modifier that has been specified would be deeply wired into GHC itself.
On Fri, Nov 27, 2020, at 04:46, Joachim Breitner wrote:
Hi,
Am Donnerstag, den 26.11.2020, 14:58 -0500 schrieb Alejandro Serrano
Mena:
Dear all,
This proposal suggests adding syntax for a general notion of
modifiers, like the ones we’ve been talking about lately affecting
linearity or matchability of arrows. For example, if linear types and
unsaturated families are accepted as they stand, we would have `Int
#1 -> @U Bool` (or something like that), whereas with this proposal
we would have the more uniform `Int %1 %Unmatchable -> Bool`.
Since the amount of modifiers is likely to increase in the future, I
think it’s a great idea to agree and reserve such syntax, instead of
coming up with different ways on each proposal. I thus recommend
acceptance of this proposal.
The proposal itself:
(1) introduces syntax for modifiers in types and defines how to
type/kind check them,
(2) reserved such syntax for other uses in declarations and terms.
I think the proposal still has its merits only with (1), even though
I lean towards accepting both parts of it.
I like the idea of reserving syntax here, but parts of the proposal
smell a bit like premature generalization to me. Are we confident that
all annotations we eventually would like to use with this feature can
be expressed as types of a kind that is an instance of Modifier? Or
should we reserve the ability to have annotations that don't fit that
model?
Would we ever have annotation that may affect phases earlier than than
typechecking? What if we want to use (%type e) and (%data e) to help
with the SingleNamepace issues? Look like useful annotations to me, but
I am not sure if they fit the framework proposed here.
The fact that we special-case %1 supports that.
The proposal explicitly has to state “No modifier polymorphism!”. But
isn't that indication that using the type system to model the various
modifiers might be the wrong tool?
I wonder if there is a way where the %(…) on it’s own only reserve
syntax, and the various uses of that syntax can be disambiguated
_statically_ based on the content of ….
Not great syntax, because not concise, enough, but morally I’d feel
more at ease with
Int %(multiplicity Many) -> Int
Int %(multiplicity 1) -> Int
Int %(multiplicity m) -> Int
where multiplicity is a modifier keyword, to express the existing
features (including implicit generalization of m). Then we can extend
this to
Int %oneShot -> Int
and
Int %(matchability M) -> Int
and maybe even
foo (%type [a]) -- where foo :: forall a -> ()
which is a modifier that
So at the moment, I am inclined to reject this proposal, until I am
convinced that we are not painting ourselves into a “all modifiers are
types of special kinds and that’s all the syntax and behaviour we ever
need” corner.
Minor detail: If we can annotate infix use of the (->) “type operator”,
should we also be able to annotate other infix operators, i.e.
constr ::= (btype | ! atype) {modifier} conop (btype | ! atype)
infixexp ::= lexp {modifier} qop infixexp
Cheers,
Joachim
--
Joachim Breitner
mail@joachim-breitner.de
http://www.joachim-breitner.de/ <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.joachim-breitner.de%2F&data=04%7C01%7Csimonpj%40microsoft.com%7C97291bd458234e28f0aa08d89ce27f4f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637431843904133795%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=EOafNT2JtRWPODqAKfG3TNH3xqPEe3%2B5ThuYLbjYPiY%3D&reserved=0>
_______________________________________________
ghc-steering-committee mailing list
ghc-steering-committee@haskell.org
https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committee&data=04%7C01%7Csimonpj%40microsoft.com%7C97291bd458234e28f0aa08d89ce27f4f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637431843904143751%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=CSx3i0ZoLHVnh6rfNzv1qcJwMCXnRxM6iD%2FxYBRTJP8%3D&reserved=0>
_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committee&data=04%7C01%7Csimonpj%40microsoft.com%7C97291bd458234e28f0aa08d89ce27f4f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637431843904143751%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=CSx3i0ZoLHVnh6rfNzv1qcJwMCXnRxM6iD%2FxYBRTJP8%3D&reserved=0>
_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committee&data=04%7C01%7Csimonpj%40microsoft.com%7C97291bd458234e28f0aa08d89ce27f4f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637431843904153698%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=EEoElFpNjneP9rKR808eGaYKwaV66tLHiN0Tbra0GkA%3D&reserved=0>
_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committee&data=04%7C01%7Csimonpj%40microsoft.com%7C97291bd458234e28f0aa08d89ce27f4f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637431843904153698%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=EEoElFpNjneP9rKR808eGaYKwaV66tLHiN0Tbra0GkA%3D&reserved=0>
Hi, Am Freitag, den 18.12.2020, 07:18 +0000 schrieb Alejandro Serrano Mena:
I think we can mark this as accepted now.
merged. Cheers, Joachim -- Joachim Breitner mail@joachim-breitner.de http://www.joachim-breitner.de/
participants (6)
-
Alejandro Serrano Mena -
Eric Seidel -
Joachim Breitner -
Richard Eisenberg -
Simon Peyton Jones -
Spiwack, Arnaud