[ghc-steering-committee] Modification to record dot syntax propsal
Spiwack, Arnaud
arnaud.spiwack at tweag.io
Thu Mar 4 12:08:37 UTC 2021
I would have drafted a suggested change myself, but I wasn’t being
difficult when I said that I didn’t understand the motivation. This whole
conversation has really lost me.
Regarding the proposed motivation: I think that 3) is irrelevant to our
point. But 1) and 2) surprise me. I don’t believe that it’s the real
motivation: “orthogonal things are controlled by separate flags” still
reads pretty much as “because we can” to me. If it’s really the one
motivation, fine, let’s write this (but then, I think that the current
patch already contains more or less this argument). But if it really is the
motivation, I find it incredibly weak. I don’t believe that it is though.
Maybe the point is hinted in 2) there is a loss in expressiveness in the
proposal, but it’s only one aspect of the proposal, and we want to isolate
it, so that the backward-compatible part can benefit all. Is that a fair
characterisation? I honestly don’t know
This motivation that I drafted makes it sound like we are making a
fork-like extension in OverloadedRecordUpdate. We’ve usually frowned upon
fork-like extensions. Are we ok with this one?
PS: I agree with Richard and Joachim, it ought to be documented. It also
ought to be documented that it is a work in progress and positively *will*
change in the next releases.
On Thu, Mar 4, 2021 at 10:39 AM Simon Peyton Jones <simonpj at microsoft.com>
wrote:
> Arnaud
>
>
>
> I’m all for improving the proposal. But rather than have the authors
> guess, can you be more specific about what you want?
>
>
>
> To be concrete, do you want this (copied from up-thread) in the
> compare-one-vs-two subsection?
>
> 1. Add two extensions, as proposed here. Pro: flexibility for people
> like Iavor who want type-changing update, but would still like
> dot-notation. Pro: orthogonal things are controlled by separate flags. Con:
> each has to be documented separately: two flags with one para each, instead
> of one flag with two paras. (The implementation cost is zero: it's only a
> question of which flag to test.)
> 2. Add one extension (OverloadedRecordFields, say) to do what
> OverloadedRecordDot and OverloadedRecordUpdate to in this proposal. Pro:
> only one extension. Con: some users might want dot-notation, but not want
> to give up type-changing update.
> 3. Use RecordDotSyntax, and be prepared to change what it means (e.g.
> add NoFieldSelectors) later. Pro: only one extension. Con: changing the
> meaning of an extension will break programs.
>
> Would adding that address your concern? Or did you have something else
> in mind?
>
>
> Simon
>
>
>
> *From:* ghc-steering-committee <ghc-steering-committee-bounces at haskell.org>
> *On Behalf Of *Spiwack, Arnaud
> *Sent:* 04 March 2021 09:22
> *To:* Eric Seidel <eric at seidel.io>
> *Cc:* Simon Peyton Jones via ghc-steering-committee <
> ghc-steering-committee at haskell.org>
> *Subject:* Re: [ghc-steering-committee] Modification to record dot syntax
> propsal
>
>
>
> I'm really the only one pushing back here. And since time is sort of of
> the essence, in this particular, I suppose that we can accept.
>
>
>
> Still, as I said in the Github thread, I would really appreciate a more
> fleshed out motivation to be documented in the proposal (in the
> alternatives subsection where the authors compare one vs two extensions). A
> proposal is for design documentation, and here, the design decision can
> only be found in a Github thread. It would be much better if the proposal
> document reflected this thread.
>
>
>
> On Thu, Mar 4, 2021 at 2:18 AM Eric Seidel <eric at seidel.io> wrote:
>
> I explicitly assent to accepting this revision. I agree with Arnaud and
> Richard that the motivation feels lacking, but we have enough precedent for
> fine-grained extensions that I feel comfortable with this as an
> implementation strategy.
>
> On Wed, Mar 3, 2021, at 11:04, Simon Peyton Jones via
> ghc-steering-committee wrote:
> >
> > In terms of actual official GHC Steering Committee business, this
> > proposal is really just about changing the name of the extension from
> > -XRecordDotSyntax to -XOverloadedRecordDot. The implementation will
> > simply fall short of the entire proposal. Is that accurate?
> >
> >
> >
> > Not quite.
> >
> > * It replaces RecordDotSyntax with two separate extensions,
> > OverloadedRecordDot and OverloadedRecordUpdate.
> > * The second, OverloadedRecordUpdate would be advertised as
> > experimental and subject to change. (I’m totally happy with having it
> > in the user manual if that’s what everyone is happy with.)
> > * If you switch on experimental OverloadedRecordUpdate, you get the
> > whole proposal, with no falling short. But the committee has expressed
> > some second thoughts about update, hence advertising it as experimental.
> > OK? Only Richard, Iavor, Joachim, Arnaud have said anything on this
> > thread. I’m taking silence as assent … yell by the end of today if
> > you are unhappy. I’d like to communicate with the authors.
> >
> >
> >
> > Simon
> >
> >
> >
> > *From:* Richard Eisenberg <rae at richarde.dev>
> > *Sent:* 02 March 2021 16:46
> > *To:* Simon Peyton Jones <simonpj at microsoft.com>
> > *Cc:* ghc-steering-committee <ghc-steering-committee at haskell.org>
> > *Subject:* Re: [ghc-steering-committee] Modification to record dot
> > syntax propsal
> >
> >
> >
> > I don't love having a feature that's completely unmentioned in the
> > manual -- too much of a root to trip over. (For example, tooling may
> > run into -XOverloadedRecordUpdate, but now has no official place to
> > look to see what it is.) I'd be fine with a short section in the manual
> > describing that an experimental -XOverloadedRecordUpdate extension
> > exists, is subject to change, and is meant to roughly implement some
> > part of some proposal. This can be done in just a few sentences, with a
> > link to the proposal, but just being silent seems unhelpful to users.
> >
> >
> >
> > With that small tweak, I'm quite happy to agree with the proposal here.
> >
> >
> >
> > In terms of actual official GHC Steering Committee business, this
> > proposal is really just about changing the name of the extension from
> > -XRecordDotSyntax to -XOverloadedRecordDot. The implementation will
> > simply fall short of the entire proposal. Is that accurate?
> >
> >
> >
> > Richard
> >
> >
> >
> >
> > > On Mar 2, 2021, at 7:45 AM, Simon Peyton Jones via
> ghc-steering-committee <ghc-steering-committee at haskell.org> wrote:
> >
> > >
> >
> > > Friends
> >
> > >
> >
> > > Having consulted the authors, I propose that we do this:
> >
> > >
> >
> > > * Proceed with OverloadedRecordDot for 9.2, exactly as in the
> original proposal except for the extension name.
> > > * Record update will remain exactly as now, in 9.2; that is, drawing
> back from the original proposal.
> > > * There may be some *code* in 9.2 that allows overloaded record
> update, protected by OverloadedRecordUpdate, but not in the user manual,
> and not treated as an accepted proposal. I don’t think we should ask the
> authors to remove it, and it will allow experimentation.
> > > * Adam is leading on a revised record-update proposal. This will cover
> > > * the tradeoffs between type-changing and non-type-changing update
> > > * what the current record-update syntax stands for, and/or any new
> syntax
> > >
> >
> > > Is that acceptable to everyone?
> >
> > >
> >
> > > Simon
> >
> > >
> >
> > > *From:* ghc-steering-committee <
> ghc-steering-committee-bounces at haskell.org> *On Behalf Of *Simon Peyton
> Jones via ghc-steering-committee
> > > *Sent:* 01 March 2021 17:51
> > > *To:* Iavor Diatchki <iavor.diatchki at gmail.com>; Spiwack, Arnaud <
> arnaud.spiwack at tweag.io>
> > > *Cc:* ghc-steering-committee <ghc-steering-committee at haskell.org>
> > > *Subject:* Re: [ghc-steering-committee] Modification to record dot
> syntax propsal
> >
> > >
> >
> > > I don't buy the argument of "this is already accepted", as I don't
> think many of us had noticed that part of the proposal (I certainly
> didn't), and I think we should be flexible enough to revisit previous
> decisions when we notice problems with them.
> >
> > > I agree in principle that we can revisit decisions. But we have to
> be aware that it is potentially very discouraging for proposal authors to
> >
> > > · propose something,
> >
> > > · have it *extensively* debated (including this very point),
> >
> > > · have it accepted,
> >
> > > · implement it,
> >
> > > and then be told that the committee has changed its mind. That’s
> pretty bad from their point of view.
> >
> > >
> >
> > > Still, Adam is working on a new SetField proposal, so perhaps that’s a
> figleaf. I’ll consult them.
> >
> > >
> > > Simon
> >
> > >
> >
> > >
> >
> > > *From:* Iavor Diatchki <iavor.diatchki at gmail.com>
> > > *Sent:* 01 March 2021 17:23
> > > *To:* Spiwack, Arnaud <arnaud.spiwack at tweag.io>
> > > *Cc:* Simon Peyton Jones <simonpj at microsoft.com>;
> ghc-steering-committee <ghc-steering-committee at haskell.org>
> > > *Subject:* Re: [ghc-steering-committee] Modification to record dot
> syntax propsal
> >
> > >
> >
> > > Hello,
> >
> > >
> >
> > > I think there is a strong motivation to *at least* split the
> extensions: with the current design, enabling the special `.` notation
> also *disables* type changing record update, which has nothing to do with
> the `.` notation.
> >
> > >
> >
> > > My preference would be to:
> >
> > > 1. Split the original proposal into two parts: one about `.`
> notation, the other about record update (as suggested by this proposal)
> >
> > > 2. Treat the `.` notation part as accepted
> >
> > > 3. Require changes on the record update part, so that you don't have
> to choose between it and type changing record updates, which are quite
> useful, and I don't think we should aim for a Haskell without them.
> >
> > >
> >
> > > I don't buy the argument of "this is already accepted", as I don't
> think many of us had noticed that part of the proposal (I certainly
> didn't), and I think we should be flexible enough to revisit previous
> decisions when we notice problems with them.
> >
> > >
> >
> > > -Iavor
> >
> > >
> >
> > >
> >
> > >
> >
> > > On Mon, Mar 1, 2021 at 1:40 AM Spiwack, Arnaud <
> arnaud.spiwack at tweag.io> wrote:
> >
> > >> Simon, all,
> >
> > >>
> >
> > >> After reading more of the PR thread (in particular the fews posts
> after Simon's recommendation), I have to admit: I am thoroughly confused.
> I'm not sure that two people in that thread have the same motivation, end
> goal, or design in mind.
> >
> > >>
> >
> > >> The motivations provided by the modified *Alternatives* section is
> not much more helpful (at the risk of caricaturing a little, it basically
> reads: “we made two extensions rather than one because we can”). Though it
> makes it clear that the end goal is to fold a bunch of record-related
> extensions into one glorious record extension (well, probably not fold
> them, but make a meta-extension that implies all the extensions that we've
> decided we like).
> >
> > >>
> >
> > >> My starting point is that:
> >
> > >> - Additional extensions have a maintenance cost
> >
> > >> - Additional extensions impose a cognitive burden on their use
> >
> > >> - I expect that a new extension will break my code in the next few
> releases.
> >
> > >>
> >
> > >> Based on this, I don't care how this extension or the glorious record
> extension are named; but if we want to have two extensions we should have a
> serious reason. Right now, the one reason that I see (and Iavor raised), is
> that the update part of `RecordDotSyntax` is not backward compatible. Is it
> a strong enough reason? I don't know. The only data point that I can
> provide is that when we discussed the original proposal, I brought it up
> several times, and it didn't seem very important at the time (the
> conversation focused on other points of the proposal).
> >
> > >>
> >
> > >> So, I'm still reluctant. I feel that, at the very least, the
> motivations are not well-enough articulated in the proposal (I'll make a
> comment to this effect on Github when I'm done composing this email).
> >
> > >>
> >
> > >> I appreciate that I'm in the minority here. Yet, I'm still
> unconvinced.
> >
> > >>
> >
> > >> Best,
> >
> > >> Arnaud
> >
> > >>
> >
> > >> On Sat, Feb 27, 2021 at 12:39 AM Simon Peyton Jones <
> simonpj at microsoft.com> wrote:
> >
> > >>> Generally, I'm not in favour in proposals which split extensions
> though: we already have so many extensions. Are the reasons for this split
> strong enough? I haven't had time to dig into the details.
> >
> > >>> Arnaud, happily, you don’t have to dig very deep – just read the
> handful of posts following my recommendation.
> >
> > >>>
> >
> > >>> There seem to be two motivations.
> >
> > >>>
> >
> > >>> 1. There really are two orthogonal extensions, one for r.x
> notation, and one for overloaded update. Iavor likes the first but not the
> second. Neil likes both. Having separate extensions lets us experiment.
> > >>>
> >
> > >>> 1. You suggest that changing the definition of RecordDotSyntax in a
> subsequent release, e.g. by subsequently making it imply NoFieldSelectors,
> would be fine. But it certainly imposes pain – some programs would stop
> compiling. The approach offered by this proposal avoids that problem.
> > >>>
> >
> > >>> Yes, there are lots of extensions surrounding records:
> NoFieldSelectors, DuplicateRecordFields, NamedFieldPuns,
> DisambiguateRecordFields, RecordWildCards. It may not be pretty to divide
> things up so fine, but it’s not new.
> >
> > >>>
> >
> > >>>
> >
> > >>> If there are alternative suggestions, let’s hear them.
> >
> > >>>
> >
> > >>> Simon
> >
> > >>>
> >
> > >>> *From:* ghc-steering-committee <
> ghc-steering-committee-bounces at haskell.org> *On Behalf Of *Spiwack, Arnaud
> > >>> *Sent:* 26 February 2021 22:33
> > >>> *To:* Iavor Diatchki <iavor.diatchki at gmail.com>
> > >>> *Cc:* ghc-steering-committee <ghc-steering-committee at haskell.org>
> > >>> *Subject:* Re: [ghc-steering-committee] Modification to record dot
> syntax propsal
> >
> > >>>
> >
> > >>>
> >
> > >>>> I do think that reusing the record update syntax for the
> overloaded monomorphic update is a mistake---it is not something I had
> noticed during our original discussion.
> >
> > >>>
> >
> > >>> This is the one reason I can see for cutting this extension in
> smaller pieces. But, then again, -XOverloadedRecordUpdate would be a
> fork-like extension.
> >
> > >>>
> >
> > >>> Generally, I'm not in favour in proposals which split extensions
> though: we already have so many extensions. Are the reasons for this split
> strong enough? I haven't had time to dig into the details.
> >
> > >>>
> >
> > >>> I'm not sure that not having the design of the proposal quite
> finalised is a good reason, extensions mutate in their first iterations, I
> don't think that it's a problem.
> >
> > > _______________________________________________
> > > 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%7Cb9e5de3ee68046ca17e808d8deef1f43%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637504466356690323%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=uuQ%2BWONzGX08Su2VfRDmoOXkMo0RjHEpIsIfE3zTwPs%3D&reserved=0>
> <
> 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%7Ccf65595be24d42cab2ca08d8dd9ab96c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637503003928846093%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=3goska4aw00W0GxIvfDOj3JCdEaQ0CB8Zowb1u5RbMo%3D&reserved=0
> <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%7Cb9e5de3ee68046ca17e808d8deef1f43%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637504466356700318%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=vUnHBFFzM0vAKHsOMUeKeTtes1C4qnJpEAfsbN%2FaPGM%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%7Cb9e5de3ee68046ca17e808d8deef1f43%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637504466356710308%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=NphMrHpqCq%2BBHniQiLFSBREpzr8e%2Bgdwgp9%2Bv5y6fAI%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%7Cb9e5de3ee68046ca17e808d8deef1f43%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637504466356710308%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=NphMrHpqCq%2BBHniQiLFSBREpzr8e%2Bgdwgp9%2Bv5y6fAI%3D&reserved=0>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20210304/510ff8bf/attachment-0001.html>
More information about the ghc-steering-committee
mailing list