Re: [ghc-steering-committee] Modification to record dot syntax propsal

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 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 On Behalf Of Eric Seidel | Sent: 04 March 2021 14:38 | To: ghc-steering-committee@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 | > *Sent:* 02 March 2021 12:45 | > *To:* ghc-steering-committee | > *Cc:* Simon Peyton Jones | > *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 | > *On Behalf Of *Simon | > Peyton Jones via ghc-steering-committee | > *Sent:* 01 March 2021 17:51 | > *To:* Iavor Diatchki ; Spiwack, Arnaud | > | > *Cc:* ghc-steering-committee | > *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 | > *Sent:* 01 March 2021 17:23 | > *To:* Spiwack, Arnaud | > *Cc:* Simon Peyton Jones ; | > ghc-steering-committee | > *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 | 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 | 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 *On Behalf Of *Spiwack, Arnaud | > >> *Sent:* 26 February 2021 22:33 | > >> *To:* Iavor Diatchki | > >> *Cc:* ghc-steering-committee | > >> *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@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@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@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee