[ghc-steering-committee] Modification to record dot syntax propsal
Spiwack, Arnaud
arnaud.spiwack at tweag.io
Thu Mar 4 15:28:51 UTC 2021
As for my part, Simon and I had a call and he cleared up the situation for
me. We came up with a piece of text that we will offer to the other to
explain the motivation behind the split. I am now fine with the change.
On Thu, Mar 4, 2021 at 3:53 PM Simon Peyton Jones via
ghc-steering-committee <ghc-steering-committee at haskell.org> wrote:
> | That being said, I don't see anything in the revised proposal about
> | the stability of OverloadedRecordUpdate. Are you saying that as part
> | of this revision, we'll explicitly accept OverloadedRecordDot and send
> | OverloadedRecordUpdate back for revision?
>
> We *already* accepted both, as part of accepting the earlier
> RecordDotSyntax proposal. But in this round, Iavor has pushed back
> against OverloadedRecordUpdate. No one else has expressed a view on this
> point.
>
> But rather than debate it at length I proposed to explicitly un-accept the
> OverloadedRecordUpdate part of the proposal. It'll return as part of a new
> record-update proposal that Adam is working on.
>
> In the meantime OverloadedRecordUpdate will be in GHC's codebase, and
> (assuming that's what the majority wants) documented in the user manual,
> with a prominent "may change" caveat.
>
> Does that make it clear?
>
> Simon
>
> | -----Original Message-----
> | From: ghc-steering-committee <ghc-steering-committee-
> | bounces at haskell.org> On Behalf Of Eric Seidel
> | Sent: 04 March 2021 14:38
> | To: ghc-steering-committee at haskell.org
> | Subject: Re: [ghc-steering-committee] Modification to record dot
> | syntax propsal
> |
> | I agree with Richard and Joachim that it should be documented in the
> | user guide. It's much better to document features with the expected
> | level of support than to let users stumble upon them and make their
> | own assumptions about stability.
> |
> | That being said, I don't see anything in the revised proposal about
> | the stability of OverloadedRecordUpdate. Are you saying that as part
> | of this revision, we'll explicitly accept OverloadedRecordDot and send
> | OverloadedRecordUpdate back for revision?
> |
> | On Thu, Mar 4, 2021, at 04:46, Simon Peyton Jones via ghc-steering-
> | committee wrote:
> | >
> | > Friends
> | >
> | >
> | >
> | > We've agree to accept my suggestion below.
> | >
> | >
> | >
> | > But there is one point at issue: should OverloadedRecordUpdate be
> | > documented in the user manual, albeit identified as a not-yet-
> | accepted
> | > feature?
> | >
> | >
> | >
> | > * Richard positively wants it in the manual
> | > * Iavor positively doesn't want it there.
> | >
> | >
> | > I don't mind either way.
> | >
> | >
> | >
> | > What do others think? It's not a big deal, but we owe the authors a
> | > decision. Answer by the end of the week please, and I'll make a
> | > shepherd decision based on the opinions I get.
> | >
> | >
> | >
> | > Simon
> | >
> | >
> | >
> | >
> | >
> | > *From:* Simon Peyton Jones <simonpj at microsoft.com>
> | > *Sent:* 02 March 2021 12:45
> | > *To:* ghc-steering-committee <ghc-steering-committee at haskell.org>
> | > *Cc:* Simon Peyton Jones <simonpj at microsoft.com>
> | > *Subject:* RE: [ghc-steering-committee] Modification to record dot
> | > syntax propsal
> | >
> | >
> | >
> | > 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://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%7C8abc00434aa94b7
> | fa98e08d8df1b5d9f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6375046
> | 55938142566%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMz
> | IiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=9DGVl6oJc0%2BIQekuXf
> | zwqviiaT%2FaHZIlIk3R5aMZssA%3D&reserved=0
> | >
> | _______________________________________________
> | ghc-steering-committee mailing list
> | ghc-steering-committee at haskell.org
> | 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%7C8abc00434aa94b7
> | fa98e08d8df1b5d9f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6375046
> | 55938152562%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMz
> | IiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=QZlV0RrRttaiDdrQNiRB
> | vUhS6il1DydPX5cyl%2BdILbI%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/20210304/f0d2ca37/attachment-0001.html>
More information about the ghc-steering-committee
mailing list