[ghc-steering-committee] #370: Syntax for Modifiers, Recommendation: Acceptance

Fri Dec 18 07:18:56 UTC 2020

 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 at 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 at gmail.com>
> wrote:
>
>>
>>
>> On 11 Dec 2020 at 21:35:20, Richard Eisenberg <rae at 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-741785189
>> :
>>
>> 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 at 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 at 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 at tweag.io>
>>>> *Sent:* 10 December 2020 08:06
>>>> *To:* Alejandro Serrano Mena <trupill at gmail.com>
>>>> *Cc:* Richard Eisenberg <rae at richarde.dev>;
>>>> ghc-steering-committee at haskell.org; Simon Peyton Jones <
>>>> simonpj at 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 at 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 at 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 at 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 at haskell.org> *On Behalf Of *Alejandro
>>>> Serrano Mena
>>>> *Sent:* 03 December 2020 20:17
>>>> *To:* Richard Eisenberg <rae at richarde.dev>
>>>> *Cc:* ghc-steering-committee at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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>
>>>>
>>>>
>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20201218/dfad4d5b/attachment-0001.html>