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

Wed Dec 9 20:17:49 UTC 2020

 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%7C70050d899124429d0d5a08d897c862a2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C637426234195063362%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=kMw%2BvlOxw4ketBttUdHI1zbAL1SyUFduoR7ac54uLrE%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%7C70050d899124429d0d5a08d897c862a2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C637426234195073315%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=zlRcj7FjskXnYJDMtX5Wj8Ognw0mPSR1PVG0XK4RNQ4%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%7C70050d899124429d0d5a08d897c862a2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C637426234195073315%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=zlRcj7FjskXnYJDMtX5Wj8Ognw0mPSR1PVG0XK4RNQ4%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%7C70050d899124429d0d5a08d897c862a2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C637426234195083273%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=zxJsZFQYUe4Yu5bjjPfZKC3NQUmrVcEuU7DjV7lhe0g%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
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20201209/03a1c545/attachment-0001.html>