I've posted on GitHub (https://github.com/ghc-proposals/ghc-proposals/pull/405#issuecomment-7845159... https://github.com/ghc-proposals/ghc-proposals/pull/405#issuecomment-7845159...). I'm unconvinced by this motivation, unfortunately. Richard

On Feb 23, 2021, at 11:35 AM, Joachim Breitner wrote:

Hi,

fine with acceptance. Having more fine grained extensions while we are not 100% where the thing is going may pay off in the future, while GHC2028 (rough guess) or Haskell2030 (who knows?) will alleviate the pain of too fine-grained extensions.

Cheers, Joachim

Am Dienstag, den 23.02.2021, 15:06 +0000 schrieb Simon Peyton Jones via ghc-steering-committee:

...

Friends Please see this proposal #405 to split RecordDotSyntax into two extensions It is a small modification of #282 on record dot syntax. The top comment gives links to the versions of the proposal before and after the change. The main payload is: Instead of RecordDotSyntax, have to independent extensions, OverloadedRecordDot and OverloadedRecordUpdates. I recommend acceptance of this proposal, but invite the committee’s view on one point (the final bullet below). Here is the thinking RecordDotSyntax is the extension that we will eventually want programmers to user. It will probably ultimately imply NoFieldSelectors. But we aren’t quite ready make that choice yet. So we don’t want to specify exactly what RecordDotSyntax does yet. So we want another, less ambitious, extension to enable record-dot syntax itself, and its desugaring into getField; and similarly for record updates. This patch to the proposal goes just a little further, by dis-aggregating into two independent extensions, OverloadedRecordDot and OverloadedRecordUpdates. An alternative, if the committee prefers, would be to have a single extension (say, OverloadedRecords). Please express your opinion. This should not take us long. (Technical and clarification questions would be best done on the Githhub thread, as always.) Simon _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee -- Joachim Breitner mail@joachim-breitner.de http://www.joachim-breitner.de/

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

On Feb 26, 2021, at 4:32 AM, Simon Peyton Jones via ghc-steering-committee wrote:

Friends

There has been a bit of discussion, but it seems to have died down again. Any other views?

Richard, you were a bit negative – has the intervening discussion reassured you?

I was negative on the motivation, but not the proposal. I'm a bit skeptical of the end goal of a -XRecordDotSyntax that implies a bunch of other flags, but that's not on the table at the moment. I'm in support of the extension breakdown as proposed and vote to accept. Richard

I’d like us to decide pretty soon…. no point in delay.

Simon

From: Simon Peyton Jones Sent: 23 February 2021 15:06 To: ghc-steering-committee Cc: Simon Peyton Jones Subject: Modification to record dot syntax propsal

Friends

Please see this proposal #405 to split RecordDotSyntax into two extensions https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%2Fpull%2F405&data=04%7C01%7Csimonpj%40microsoft.com%7Caa27192c62ab448a4e2c08d8d80c8937%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637496895641978235%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=oJDy%2BiYI4kEaC%2FUJIfZbph2JnZr%2FTK%2F5aZqA6djwF3A%3D&reserved=0 It is a small modification of #282 on record dot syntax. The top comment gives links to the versions of the proposal before and after the change.

The main payload is:

Instead of RecordDotSyntax, have to independent extensions, OverloadedRecordDot and OverloadedRecordUpdates. I recommend acceptance of this proposal, but invite the committee’s view on one point (the final bullet below). Here is the thinking

RecordDotSyntax is the extension that we will eventually want programmers to user. It will probably ultimately implyNoFieldSelectors. But we aren’t quite ready make that choice yet. So we don’t want to specify exactly whatRecordDotSyntax does yet. So we want another, less ambitious, extension to enable record-dot syntax itself, and its desugaring into getField; and similarly for record updates. This patch to the proposal goes just a little further, by dis-aggregating into two independent extensions,OverloadedRecordDot and OverloadedRecordUpdates. An alternative, if the committee prefers, would be to have a single extension (say, OverloadedRecords). Please express your opinion. This should not take us long. (Technical and clarification questions would be best done on the Githhub thread, as always.)

Simon

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

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.

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.

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 mailto:arnaud.spiwack@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 mailto:simonpj@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 mailto:ghc-steering-committee-bounces@haskell.org> On Behalf Of Spiwack, Arnaud Sent: 26 February 2021 22:33 To: Iavor Diatchki mailto:iavor.diatchki@gmail.com> Cc: ghc-steering-committee mailto:ghc-steering-committee@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.

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 mailto:iavor.diatchki@gmail.com> Sent: 01 March 2021 17:23 To: Spiwack, Arnaud mailto:arnaud.spiwack@tweag.io> Cc: Simon Peyton Jones mailto:simonpj@microsoft.com>; ghc-steering-committee mailto:ghc-steering-committee@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 mailto:arnaud.spiwack@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 mailto:simonpj@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 mailto:ghc-steering-committee-bounces@haskell.org> On Behalf Of Spiwack, Arnaud Sent: 26 February 2021 22:33 To: Iavor Diatchki mailto:iavor.diatchki@gmail.com> Cc: ghc-steering-committee mailto:ghc-steering-committee@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.

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 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 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 mailto:iavor.diatchki@gmail.com> Sent: 01 March 2021 17:23 To: Spiwack, Arnaud mailto:arnaud.spiwack@tweag.io> Cc: Simon Peyton Jones mailto:simonpj@microsoft.com>; ghc-steering-committee mailto:ghc-steering-committee@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 mailto:arnaud.spiwack@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 mailto:simonpj@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.

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.

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 mailto:ghc-steering-committee-bounces@haskell.org> On Behalf Of Spiwack, Arnaud Sent: 26 February 2021 22:33 To: Iavor Diatchki mailto:iavor.diatchki@gmail.com> Cc: ghc-steering-committee mailto:ghc-steering-committee@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@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

I don't really know what it means for an extension to "experimental"---aren't they all? I'd rather not have the Update part advertised in the manual, as I do think it's design should be reconsidered---tools are not going to trip on it, as no one should be using it, for all practical purposes it is not there. I am fine with leaving it in the source code of GHC, as I expect that eventually we'll come up with a suitable design, and expect that large parts of the implementation would be the same, so I see no reason to make the authors remove their code, only to have to add it again later. -Iavor On Wed, Mar 3, 2021 at 8:05 AM 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 *Sent:* 02 March 2021 16:46 *To:* Simon Peyton Jones *Cc:* ghc-steering-committee *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@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

...

*On Behalf Of *Simon Peyton Jones via ghc-steering-committee *Sent:* 01 March 2021 17:51 *To:* Iavor Diatchki ; Spiwack, Arnaud < arnaud.spiwack@tweag.io> *Cc:* ghc-steering-committee *Subject:* Re: [ghc-steering-committee] Modification to record dot syntax

*From:* ghc-steering-committee

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 < ghc-steering-committee@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 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

...

*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

*From:* ghc-steering-committee

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://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%7Ccf65595be24d42cab2ca08d8dd9ab96c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637503003928846093%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=3goska4aw00W0GxIvfDOj3JCdEaQ0CB8Zowb1u5RbMo%3D&reserved=0

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

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 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 *Sent:* 02 March 2021 16:46 *To:* Simon Peyton Jones *Cc:* ghc-steering-committee *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 wrote:

...

...

...

Friends

...

...

Having consulted the authors, I propose that we do this:

...

...

* Proceed with OverloadedRecordDot for 9.2, exactly as in the

...

...

* 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@haskell.org> *On Behalf Of *Simon Peyton Jones via ghc-steering-committee *Sent:* 01 March 2021 17:51 *To:* Iavor Diatchki ; Spiwack, Arnaud < arnaud.spiwack@tweag.io> *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

original proposal except for the extension name. 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 ;

...

...

*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

ghc-steering-committee 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@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@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

...

...

...

...

...

...

...

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

notation, and one for overloaded update. Iavor likes the first but not the second. Neil likes both. Having separate extensions lets us experiment. things up so fine, but it’s not new.

...

...

...

...

...

...

...

...

...

...

If there are alternative suggestions, let’s hear them.

...

...

...

...

...

...

Simon

...

...

...

...

...

...

*From:* ghc-steering-committee <

...

...

...

...

*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

ghc-steering-committee-bounces@haskell.org> *On Behalf Of *Spiwack, Arnaud 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://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%7Ccf65595be24d42cab2ca08d8dd9ab96c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637503003928846093%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=3goska4aw00W0GxIvfDOj3JCdEaQ0CB8Zowb1u5RbMo%3D&reserved=0

...

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

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 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 *On Behalf Of *Spiwack, Arnaud *Sent:* 04 March 2021 09:22 *To:* Eric Seidel *Cc:* Simon Peyton Jones via ghc-steering-committee < ghc-steering-committee@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 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 *Sent:* 02 March 2021 16:46 *To:* Simon Peyton Jones *Cc:* ghc-steering-committee *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 wrote:

...

...

...

Friends

...

...

Having consulted the authors, I propose that we do this:

...

...

* Proceed with OverloadedRecordDot for 9.2, exactly as in the

...

...

* 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@haskell.org> *On Behalf Of *Simon Peyton Jones via ghc-steering-committee *Sent:* 01 March 2021 17:51 *To:* Iavor Diatchki ; Spiwack, Arnaud < arnaud.spiwack@tweag.io> *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

original proposal except for the extension name. 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 ;

...

...

*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

ghc-steering-committee 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@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@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

...

...

...

...

...

...

...

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

notation, and one for overloaded update. Iavor likes the first but not the second. Neil likes both. Having separate extensions lets us experiment. things up so fine, but it’s not new.

...

...

...

...

...

...

...

...

...

...

If there are alternative suggestions, let’s hear them.

...

...

...

...

...

...

Simon

...

...

...

...

...

...

*From:* ghc-steering-committee <

...

...

...

...

*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

ghc-steering-committee-bounces@haskell.org> *On Behalf Of *Spiwack, Arnaud 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://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@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@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

Hi, I think it’s bad style to hide something from the documentation that’s implemented. Either really nobody should use it, but then the code should just simply be removed or moved to a branch or at least _statically_ disabled. It seems we don’t want that, so I think documentation is desirable. (Not a very strong opinion though) But now we have a feature that’s implemented, documented and guarded behind a flag. Not sure how that practically differs from an “experimentally accepted” feature. So a a warning “this is not yet accepted” may be good to address some anxiety around it, but doesn’t seem to actually mean that much. So maybe the warning can be phrased in a more meaningful way for the user (“This extension is likely to change or may even be removed completely, please only enable it to play around with it”) instead of referring to the status of internal processes. Cheers, Joachim Am Donnerstag, den 04.03.2021, 09:46 +0000 schrieb Simon Peyton Jones via ghc-steering-committee:

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.

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.

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://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee -- Joachim Breitner mail@joachim-breitner.de http://www.joachim-breitner.de/

| 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

Here's the text https://docs.google.com/document/d/1GbWAC8URaVRmj6Lkj1b10okNsVuUfO6U0qq-lrSp... From: Spiwack, Arnaud Sent: 04 March 2021 15:29 To: Simon Peyton Jones Cc: Eric Seidel ; ghc-steering-committee@haskell.org Subject: 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 mailto:ghc-steering-committee@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 mailto:bounces@haskell.org> On Behalf Of Eric Seidel | Sent: 04 March 2021 14:38 | To: ghc-steering-committee@haskell.orgmailto: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 mailto:simonpj@microsoft.com> | > *Sent:* 02 March 2021 12:45 | > *To:* ghc-steering-committee mailto:ghc-steering-committee@haskell.org> | > *Cc:* Simon Peyton Jones mailto:simonpj@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 | > mailto:ghc-steering-committee-bounces@haskell.org> *On Behalf Of *Simon | > Peyton Jones via ghc-steering-committee | > *Sent:* 01 March 2021 17:51 | > *To:* Iavor Diatchki mailto:iavor.diatchki@gmail.com>; Spiwack, Arnaud | > mailto:arnaud.spiwack@tweag.io> | > *Cc:* ghc-steering-committee mailto:ghc-steering-committee@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 mailto:iavor.diatchki@gmail.com> | > *Sent:* 01 March 2021 17:23 | > *To:* Spiwack, Arnaud mailto:arnaud.spiwack@tweag.io> | > *Cc:* Simon Peyton Jones mailto:simonpj@microsoft.com>; | > ghc-steering-committee mailto:ghc-steering-committee@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 | mailto:arnaud.spiwack@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 | mailto:simonpj@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 mailto:bounces@haskell.org> *On Behalf Of *Spiwack, Arnaud | > >> *Sent:* 26 February 2021 22:33 | > >> *To:* Iavor Diatchki mailto:iavor.diatchki@gmail.com> | > >> *Cc:* ghc-steering-committee mailto:ghc-steering-committee@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@haskell.orgmailto:ghc-steering-committee@haskell.org | > | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail | .haskell.orghttps://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fhaskell.org%2F&data=04%7C01%7Csimonpj%40microsoft.com%7Cc9fd0d48bfb0488ab1f208d8df225bdf%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637504685977282748%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=mJwXqs%2FBs3qhnroUA%2FHLmBF8Y2hgNf8Ha65v%2BuWWotI%3D&reserved=0%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering- | committee&data=04%7C01%7Csimonpj%40microsoft.comhttps://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2F40microsoft.com%2F&data=04%7C01%7Csimonpj%40microsoft.com%7Cc9fd0d48bfb0488ab1f208d8df225bdf%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637504685977292739%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=%2B7yr5Qa%2FcqrDvM6f0WeNaZt1ub3o%2Bj0SGjFeX2ASFXw%3D&reserved=0%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.orgmailto:ghc-steering-committee@haskell.org | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail | .haskell.orghttps://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fhaskell.org%2F&data=04%7C01%7Csimonpj%40microsoft.com%7Cc9fd0d48bfb0488ab1f208d8df225bdf%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637504685977302733%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=8851cSrXEPVuoeqJJlFtCM%2BVNJhT%2BhvPXfmTY9sm4mk%3D&reserved=0%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering- | committee&data=04%7C01%7Csimonpj%40microsoft.comhttps://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2F40microsoft.com%2F&data=04%7C01%7Csimonpj%40microsoft.com%7Cc9fd0d48bfb0488ab1f208d8df225bdf%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637504685977302733%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=d1brPSssIphSkd1RwlnV%2Bj%2FotGv5Czxv1kYLkxBzUoE%3D&reserved=0%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.orgmailto:ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committeehttps://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%7Cc9fd0d48bfb0488ab1f208d8df225bdf%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637504685977312732%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=eqlY43l%2Bma8Vl3hQt6gqWmdUEkGF9xkCMbbBvcbK40w%3D&reserved=0

Bad look or not, it seems better to me to change our mind than accept something "to save face" :) It seems hard to imagine that I am the only one here who uses type changing updates in records. How are other members of the committee reconciling this change? Are you planning to change your code to use record wild cards as Neil suggested---this seems a lot worse than the status quo? Or is the plan the plan to just fork the language and use the pragma to disambiguate? I don't mind if the extension is in GHC's code, but I think that if we add it to the GHC manual, people will use it, and it will be a much bigger deal to change later. On Thu, Mar 4, 2021 at 9:59 AM Eric Seidel wrote:

Yes that clears up the current situation. And from the current email chain it looks like the authors are aware of the plan to send record updates back for revision? I'd just want to make sure that the updated proposal reflects that split on which parts have been accepted.

For what it's worth, I do recall the loss of type-changing update being part of the original proposal and thought the proposal was still good on balance. The tradeoffs were definitely discussed in the giant Github thread, I don't recall if we discussed that aspect here though.. Regardless, I think it's a bad look for us to walk back a decision on account of not having read the proposal closely enough!

On Thu, Mar 4, 2021, at 09:53, Simon Peyton Jones 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

Iavor, I concur with Simon and Eric. Accepting a proposal is a promise that the proposal will not be debated on the design front in the future. That is, when the implementation comes up it is out of scope to discuss design. That's the deal. GHC proposals are a process. The goal of this process is to foster participation of the wider community to the evolution of GHC, by reducing stress and uncertainty, and focusing productivity. This is why changing the design of an accepted proposal requires another proposal, submitted to the same level of scrutiny as the original proposal. Even, and in particular, by members of the steering committee. In this particular case, the authors have agreed to the change, and this is something that we feel is important enough to press forward quickly. So in the interest of everybody's time, I suggest that we move on. But, generally, the point stands. /Arnaud On Thu, Mar 4, 2021 at 8:45 PM Eric Seidel wrote:

I agree it’s more important to get things right than to look good, but we should aim to do both of course. As Simon mentioned earlier, this will erode the community’s confidence if it happens too often. So I’m ok with reversing our decision on this point (happily it sounds like there’s already work underway on an improved design), but I think we should reflect on why we didn’t have this discussion back when we were discussing the original proposal.

Sent from my iPhone

On Mar 4, 2021, at 14:04, Iavor Diatchki wrote:

 Bad look or not, it seems better to me to change our mind than accept something "to save face" :) It seems hard to imagine that I am the only one here who uses type changing updates in records. How are other members of the committee reconciling this change? Are you planning to change your code to use record wild cards as Neil suggested---this seems a lot worse than the status quo? Or is the plan the plan to just fork the language and use the pragma to disambiguate?

I don't mind if the extension is in GHC's code, but I think that if we add it to the GHC manual, people will use it, and it will be a much bigger deal to change later.

On Thu, Mar 4, 2021 at 9:59 AM Eric Seidel wrote:

...

Yes that clears up the current situation. And from the current email chain it looks like the authors are aware of the plan to send record updates back for revision? I'd just want to make sure that the updated proposal reflects that split on which parts have been accepted.

For what it's worth, I do recall the loss of type-changing update being part of the original proposal and thought the proposal was still good on balance. The tradeoffs were definitely discussed in the giant Github thread, I don't recall if we discussed that aspect here though.. Regardless, I think it's a bad look for us to walk back a decision on account of not having read the proposal closely enough!

...

| 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

...

| 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

On Thu, Mar 4, 2021, at 09:53, Simon Peyton Jones wrote: that's 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 < ghc-steering-committee@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@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

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

So, why the hurry to add this to GHC now, when we know from experience how painful it is to remove things, once they are out in the wild? I thought had agreed the following: 1. We accept the proposal. 2. However, the loss of type-changing updates is a real concern, so the committee want to express doubt about the OverloadedRecordUpdate part, even though we previously accepted it. Sorry about that. It’s a change in our stance. 3. It’s fine for the authors to continue with the implementation. If OverloadedRecordUpdate in GHC’s code base, it should be documented in the user manual. They should signal in that documentation that this part of the design may well change in the future, so it would be inadvisable to start using it for long-lived libraries. 4. Arnaud wanted clarification in Alternatives, section 7.7. To avoid confusion about what “clarify” means, Arnaud and I drafted thishttps://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F1GbWAC8URaVRmj6Lkj1b10okNsVuUfO6U0qq-lrSpses%2Fedit%3Fusp%3Dsharing&data=04%7C01%7Csimonpj%40microsoft.com%7C2f00be7cdc504b92fcc708d8df229562%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637504686911684988%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=bWQMb8whuhbQamUYbMReDvrCEjhJtX1oG2tQZcCwE6k%3D&reserved=0. They have already adopted this wording. 5. We’ll look forward to a new record-update proposal soon, which Adam is working on. I think this is fine. We discussed the original proposal for months, and this modification draws back on that accepted proposal, and so should be even easier to agree. Please yell now (today) if you really think this is a mistake. I have checked with the authors and this is acceptable to them. I think if we say no, we want to back to the drawing board for the entire design they’ll just give up, and with some justification. OK? Simon From: ghc-steering-committee On Behalf Of Iavor Diatchki Sent: 05 March 2021 16:03 To: Spiwack, Arnaud ; ghc-steering-committee Subject: Re: [ghc-steering-committee] Modification to record dot syntax propsal I find that this committee is having less and less technical discussion on concrete issues, and there is a lot of talk of process, rules, and definitions, that I do not find useful. It is extremely difficult to anticipate all aspects of a design without implementing it and using it for a while, so I completely disagree that we should not revisit accepted proposals. While "experimental" extensions are totally fine in my book, I really do think we should avoid intentionally introducing things that we know now are likely to change. The overloaded records update is such an extension: it changes a useful, standardized, and in my experience, not uncommonly used feature, into a less general version (in one dimension, anyway). Furthermore, we are aware that there is already work by Adam to address this, so the extension will likely change (or perhaps we are going to have yet another record related extension). So, why the hurry to add this to GHC now, when we know from experience how painful it is to remove things, once they are out in the wild? On Fri, Mar 5, 2021, 02:50 Spiwack, Arnaud mailto:arnaud.spiwack@tweag.io> wrote: Iavor, I concur with Simon and Eric. Accepting a proposal is a promise that the proposal will not be debated on the design front in the future. That is, when the implementation comes up it is out of scope to discuss design. That's the deal. GHC proposals are a process. The goal of this process is to foster participation of the wider community to the evolution of GHC, by reducing stress and uncertainty, and focusing productivity. This is why changing the design of an accepted proposal requires another proposal, submitted to the same level of scrutiny as the original proposal. Even, and in particular, by members of the steering committee. In this particular case, the authors have agreed to the change, and this is something that we feel is important enough to press forward quickly. So in the interest of everybody's time, I suggest that we move on. But, generally, the point stands. /Arnaud On Thu, Mar 4, 2021 at 8:45 PM Eric Seidel mailto:eric@seidel.io> wrote: I agree it’s more important to get things right than to look good, but we should aim to do both of course. As Simon mentioned earlier, this will erode the community’s confidence if it happens too often. So I’m ok with reversing our decision on this point (happily it sounds like there’s already work underway on an improved design), but I think we should reflect on why we didn’t have this discussion back when we were discussing the original proposal. Sent from my iPhone On Mar 4, 2021, at 14:04, Iavor Diatchki mailto:iavor.diatchki@gmail.com> wrote:  Bad look or not, it seems better to me to change our mind than accept something "to save face" :) It seems hard to imagine that I am the only one here who uses type changing updates in records. How are other members of the committee reconciling this change? Are you planning to change your code to use record wild cards as Neil suggested---this seems a lot worse than the status quo? Or is the plan the plan to just fork the language and use the pragma to disambiguate? I don't mind if the extension is in GHC's code, but I think that if we add it to the GHC manual, people will use it, and it will be a much bigger deal to change later. On Thu, Mar 4, 2021 at 9:59 AM Eric Seidel mailto:eric@seidel.io> wrote: Yes that clears up the current situation. And from the current email chain it looks like the authors are aware of the plan to send record updates back for revision? I'd just want to make sure that the updated proposal reflects that split on which parts have been accepted. For what it's worth, I do recall the loss of type-changing update being part of the original proposal and thought the proposal was still good on balance. The tradeoffs were definitely discussed in the giant Github thread, I don't recall if we discussed that aspect here though.. Regardless, I think it's a bad look for us to walk back a decision on account of not having read the proposal closely enough! On Thu, Mar 4, 2021, at 09:53, Simon Peyton Jones 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 mailto:bounces@haskell.org> On Behalf Of Eric Seidel | Sent: 04 March 2021 14:38 | To: ghc-steering-committee@haskell.orgmailto: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 mailto:simonpj@microsoft.com> | > *Sent:* 02 March 2021 12:45 | > *To:* ghc-steering-committee mailto:ghc-steering-committee@haskell.org> | > *Cc:* Simon Peyton Jones mailto:simonpj@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 | > mailto:ghc-steering-committee-bounces@haskell.org> *On Behalf Of *Simon | > Peyton Jones via ghc-steering-committee | > *Sent:* 01 March 2021 17:51 | > *To:* Iavor Diatchki mailto:iavor.diatchki@gmail.com>; Spiwack, Arnaud | > mailto:arnaud.spiwack@tweag.io> | > *Cc:* ghc-steering-committee mailto:ghc-steering-committee@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 mailto:iavor.diatchki@gmail.com> | > *Sent:* 01 March 2021 17:23 | > *To:* Spiwack, Arnaud mailto:arnaud.spiwack@tweag.io> | > *Cc:* Simon Peyton Jones mailto:simonpj@microsoft.com>; | > ghc-steering-committee mailto:ghc-steering-committee@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 | mailto:arnaud.spiwack@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 | mailto:simonpj@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 mailto:bounces@haskell.org> *On Behalf Of *Spiwack, Arnaud | > >> *Sent:* 26 February 2021 22:33 | > >> *To:* Iavor Diatchki mailto:iavor.diatchki@gmail.com> | > >> *Cc:* ghc-steering-committee mailto:ghc-steering-committee@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@haskell.orgmailto:ghc-steering-committee@haskell.org | > | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail | .haskell.orghttps://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fhaskell.org%2F&data=04%7C01%7Csimonpj%40microsoft.com%7Ce0e7e14d1ba74d216e9e08d8dff055dc%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637505571335600745%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=s8rfn2SfP1OFefRGDsd%2FmqTI%2FLu3z7qMkFNhZBlZDbc%3D&reserved=0%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering- | committee&data=04%7C01%7Csimonpj%40microsoft.comhttps://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2F40microsoft.com%2F&data=04%7C01%7Csimonpj%40microsoft.com%7Ce0e7e14d1ba74d216e9e08d8dff055dc%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637505571335610744%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=0iayJnlnpm5mchQpMmPgRY5bw2t%2FSrHkYmfnXamfgjQ%3D&reserved=0%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.orgmailto:ghc-steering-committee@haskell.org | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail | .haskell.orghttps://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fhaskell.org%2F&data=04%7C01%7Csimonpj%40microsoft.com%7Ce0e7e14d1ba74d216e9e08d8dff055dc%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637505571335620741%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=Ba9awmAYQ%2BPEtLYOlw2Mu8irB%2FGwmvv2OM30ofAMCmA%3D&reserved=0%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering- | committee&data=04%7C01%7Csimonpj%40microsoft.comhttps://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2F40microsoft.com%2F&data=04%7C01%7Csimonpj%40microsoft.com%7Ce0e7e14d1ba74d216e9e08d8dff055dc%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637505571335620741%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=%2BikTVk4HLF4Gey%2BgOoWnbhGKbYhUADxIfZNAzEBtFp8%3D&reserved=0%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.orgmailto:ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committeehttps://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%7Ce0e7e14d1ba74d216e9e08d8dff055dc%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637505571335630737%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=6A2TJygA2WZ29GqX4kBSJmZi5kX2O2Tmawv4SvpNZuk%3D&reserved=0 _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.orgmailto:ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committeehttps://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%7Ce0e7e14d1ba74d216e9e08d8dff055dc%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637505571335630737%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=6A2TJygA2WZ29GqX4kBSJmZi5kX2O2Tmawv4SvpNZuk%3D&reserved=0

I have one disagreement with what Simon says below:

However, the loss of type-changing updates is a real concern, so the committee want to express doubt about the OverloadedRecordUpdate part, even though we previously accepted it. Sorry about that. It’s a change in our stance.

I don't see this result from this thread. Instead, I see that one member of the committee has expressed doubt about this. This is a valid concern and one that we could continue to discuss, but I don't feel comfortable stating that the "committee" expresses doubt. If there are others on the committee who share similar doubts and want to un-accept part of the original proposal, please speak up -- I may have misread the room. Otherwise, I don't think this point accurately represents the discussion we have had here. I'm happy with the other points. Thanks, Richard

On Mar 5, 2021, at 12:19 PM, Simon Peyton Jones via ghc-steering-committee wrote:

So, why the hurry to add this to GHC now, when we know from experience how painful it is to remove things, once they are out in the wild?

I thought had agreed the following: We accept the proposal. It’s fine for the authors to continue with the implementation. If OverloadedRecordUpdate in GHC’s code base, it should be documented in the user manual. They should signal in that documentation that this part of the design may well change in the future, so it would be inadvisable to start using it for long-lived libraries. Arnaud wanted clarification in Alternatives, section 7.7. To avoid confusion about what “clarify” means, Arnaud and I drafted this https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F1GbWAC8URaVRmj6Lkj1b10okNsVuUfO6U0qq-lrSpses%2Fedit%3Fusp%3Dsharing&data=04%7C01%7Csimonpj%40microsoft.com%7C2f00be7cdc504b92fcc708d8df229562%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637504686911684988%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=bWQMb8whuhbQamUYbMReDvrCEjhJtX1oG2tQZcCwE6k%3D&reserved=0. They have already adopted this wording. We’ll look forward to a new record-update proposal soon, which Adam is working on. I think this is fine. We discussed the original proposal for months, and this modification draws back on that accepted proposal, and so should be even easier to agree.

Please yell now (today) if you really think this is a mistake. I have checked with the authors and this is acceptable to them. I think if we say no, we want to back to the drawing board for the entire design they’ll just give up, and with some justification.

OK?

Simon

From: ghc-steering-committee On Behalf Of Iavor Diatchki Sent: 05 March 2021 16:03 To: Spiwack, Arnaud ; ghc-steering-committee Subject: Re: [ghc-steering-committee] Modification to record dot syntax propsal

I find that this committee is having less and less technical discussion on concrete issues, and there is a lot of talk of process, rules, and definitions, that I do not find useful.

It is extremely difficult to anticipate all aspects of a design without implementing it and using it for a while, so I completely disagree that we should not revisit accepted proposals.

While "experimental" extensions are totally fine in my book, I really do think we should avoid intentionally introducing things that we know now are likely to change. The overloaded records update is such an extension: it changes a useful, standardized, and in my experience, not uncommonly used feature, into a less general version (in one dimension, anyway). Furthermore, we are aware that there is already work by Adam to address this, so the extension will likely change (or perhaps we are going to have yet another record related extension).

So, why the hurry to add this to GHC now, when we know from experience how painful it is to remove things, once they are out in the wild?

On Fri, Mar 5, 2021, 02:50 Spiwack, Arnaud mailto:arnaud.spiwack@tweag.io> wrote:

Iavor,

I concur with Simon and Eric. Accepting a proposal is a promise that the proposal will not be debated on the design front in the future. That is, when the implementation comes up it is out of scope to discuss design. That's the deal. GHC proposals are a process. The goal of this process is to foster participation of the wider community to the evolution of GHC, by reducing stress and uncertainty, and focusing productivity. This is why changing the design of an accepted proposal requires another proposal, submitted to the same level of scrutiny as the original proposal. Even, and in particular, by members of the steering committee.

In this particular case, the authors have agreed to the change, and this is something that we feel is important enough to press forward quickly. So in the interest of everybody's time, I suggest that we move on. But, generally, the point stands.

/Arnaud

On Thu, Mar 4, 2021 at 8:45 PM Eric Seidel mailto:eric@seidel.io> wrote:

I agree it’s more important to get things right than to look good, but we should aim to do both of course. As Simon mentioned earlier, this will erode the community’s confidence if it happens too often. So I’m ok with reversing our decision on this point (happily it sounds like there’s already work underway on an improved design), but I think we should reflect on why we didn’t have this discussion back when we were discussing the original proposal.

Sent from my iPhone

On Mar 4, 2021, at 14:04, Iavor Diatchki mailto:iavor.diatchki@gmail.com> wrote:



Bad look or not, it seems better to me to change our mind than accept something "to save face" :) It seems hard to imagine that I am the only one here who uses type changing updates in records. How are other members of the committee reconciling this change? Are you planning to change your code to use record wild cards as Neil suggested---this seems a lot worse than the status quo? Or is the plan the plan to just fork the language and use the pragma to disambiguate?

I don't mind if the extension is in GHC's code, but I think that if we add it to the GHC manual, people will use it, and it will be a much bigger deal to change later.

On Thu, Mar 4, 2021 at 9:59 AM Eric Seidel mailto:eric@seidel.io> wrote:

Yes that clears up the current situation. And from the current email chain it looks like the authors are aware of the plan to send record updates back for revision? I'd just want to make sure that the updated proposal reflects that split on which parts have been accepted.

For what it's worth, I do recall the loss of type-changing update being part of the original proposal and thought the proposal was still good on balance. The tradeoffs were definitely discussed in the giant Github thread, I don't recall if we discussed that aspect here though.. Regardless, I think it's a bad look for us to walk back a decision on account of not having read the proposal closely enough!

On Thu, Mar 4, 2021, at 09:53, Simon Peyton Jones 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 mailto:bounces@haskell.org> On Behalf Of Eric Seidel | Sent: 04 March 2021 14:38 | To: ghc-steering-committee@haskell.org mailto: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 mailto:simonpj@microsoft.com> | > *Sent:* 02 March 2021 12:45 | > *To:* ghc-steering-committee mailto:ghc-steering-committee@haskell.org> | > *Cc:* Simon Peyton Jones mailto:simonpj@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 | > mailto:ghc-steering-committee-bounces@haskell.org> *On Behalf Of *Simon | > Peyton Jones via ghc-steering-committee | > *Sent:* 01 March 2021 17:51 | > *To:* Iavor Diatchki mailto:iavor.diatchki@gmail.com>; Spiwack, Arnaud | > mailto:arnaud.spiwack@tweag.io> | > *Cc:* ghc-steering-committee mailto:ghc-steering-committee@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 mailto:iavor.diatchki@gmail.com> | > *Sent:* 01 March 2021 17:23 | > *To:* Spiwack, Arnaud mailto:arnaud.spiwack@tweag.io> | > *Cc:* Simon Peyton Jones mailto:simonpj@microsoft.com>; | > ghc-steering-committee mailto:ghc-steering-committee@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 | mailto:arnaud.spiwack@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 | mailto:simonpj@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 mailto:bounces@haskell.org> *On Behalf Of *Spiwack, Arnaud | > >> *Sent:* 26 February 2021 22:33 | > >> *To:* Iavor Diatchki mailto:iavor.diatchki@gmail.com> | > >> *Cc:* ghc-steering-committee mailto:ghc-steering-committee@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@haskell.org mailto:ghc-steering-committee@haskell.org | > | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail | .haskell.org https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fhaskell.org%2F&data=04%7C01%7Csimonpj%40microsoft.com%7Ce0e7e14d1ba74d216e9e08d8dff055dc%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637505571335600745%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=s8rfn2SfP1OFefRGDsd%2FmqTI%2FLu3z7qMkFNhZBlZDbc%3D&reserved=0%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering- | committee&data=04%7C01%7Csimonpj%40microsoft.com https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2F40microsoft.com%2F&data=04%7C01%7Csimonpj%40microsoft.com%7Ce0e7e14d1ba74d216e9e08d8dff055dc%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637505571335610744%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=0iayJnlnpm5mchQpMmPgRY5bw2t%2FSrHkYmfnXamfgjQ%3D&reserved=0%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 mailto:ghc-steering-committee@haskell.org | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail | .haskell.org https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fhaskell.org%2F&data=04%7C01%7Csimonpj%40microsoft.com%7Ce0e7e14d1ba74d216e9e08d8dff055dc%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637505571335620741%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=Ba9awmAYQ%2BPEtLYOlw2Mu8irB%2FGwmvv2OM30ofAMCmA%3D&reserved=0%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering- | committee&data=04%7C01%7Csimonpj%40microsoft.com https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2F40microsoft.com%2F&data=04%7C01%7Csimonpj%40microsoft.com%7Ce0e7e14d1ba74d216e9e08d8dff055dc%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637505571335620741%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=%2BikTVk4HLF4Gey%2BgOoWnbhGKbYhUADxIfZNAzEBtFp8%3D&reserved=0%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 mailto:ghc-steering-committee@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%7Ce0e7e14d1ba74d216e9e08d8dff055dc%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637505571335630737%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=6A2TJygA2WZ29GqX4kBSJmZi5kX2O2Tmawv4SvpNZuk%3D&reserved=0 _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org mailto:ghc-steering-committee@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%7Ce0e7e14d1ba74d216e9e08d8dff055dc%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637505571335630737%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=6A2TJygA2WZ29GqX4kBSJmZi5kX2O2Tmawv4SvpNZuk%3D&reserved=0_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

Richard,

...

1. However, the loss of type-changing updates is a real concern, so the committee want to express doubt about the OverloadedRecordUpdate part, even though we previously accepted it. Sorry about that. It’s a change in our stance.

I don't see this result from this thread. Instead, I see that one member of the committee has expressed doubt about this. This is a valid concern and one that we could continue to discuss, but I don't feel comfortable stating that the "committee" expresses doubt. If there are others on the committee who share similar doubts and want to un-accept part of the original proposal, please speak up -- I may have misread the room. Otherwise, I don't think this point accurately represents the discussion we have had here.

A simpler synthesis would be that there's now work on improving OverloadedRecordUpdate to allow type-changing updates, so we'll mark OverloadedRecordUpdate as experimental. I'm also happy with the other points. Iavor,

It is extremely difficult to anticipate all aspects of a design without implementing it and using it for a while, so I completely disagree that we should not revisit accepted proposals.

I don't believe any of us have suggested that we should not be allowed to revise proposals based on experience implementing or using them. That's happened on several occasions and I don't recall any objections. What happened here is different. We have a proposal that explicitly listed a known limitation -- loss of type-changing update [1] -- and we accepted the proposal despite that limitation. The objections you've raised are not based on any new information or experience, they could have been raised during the original discussion. I'm not objecting to raising them or acting on them now, but I do think we have to acknowledge that we failed to discuss the original proposal in its entirety. If I were the authors I'd be quite frustrated with us, thankfully they've been very gracious. [1]: https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0282-re... On Fri, Mar 5, 2021, at 12:36, Richard Eisenberg wrote:

I have one disagreement with what Simon says below:

...

1. However, the loss of type-changing updates is a real concern, so the committee want to express doubt about the OverloadedRecordUpdate part, even though we previously accepted it. Sorry about that. It’s a change in our stance.

I don't see this result from this thread. Instead, I see that one member of the committee has expressed doubt about this. This is a valid concern and one that we could continue to discuss, but I don't feel comfortable stating that the "committee" expresses doubt. If there are others on the committee who share similar doubts and want to un-accept part of the original proposal, please speak up -- I may have misread the room. Otherwise, I don't think this point accurately represents the discussion we have had here.

I'm happy with the other points.

Thanks, Richard

...

On Mar 5, 2021, at 12:19 PM, Simon Peyton Jones via ghc-steering-committee wrote:

So, why the hurry to add this to GHC now, when we know from experience how painful it is to remove things, once they are out in the wild?

...

I thought had agreed the following: 1. We accept the proposal. 2. It’s fine for the authors to continue with the implementation. If OverloadedRecordUpdate in GHC’s code base, it should be documented in the user manual. They should signal in that documentation that this part of the design may well change in the future, so it would be inadvisable to start using it for long-lived libraries. 3. Arnaud wanted clarification in Alternatives, section 7.7. To avoid confusion about what “clarify” means, Arnaud and I drafted this https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F1GbWAC8URaVRmj6Lkj1b10okNsVuUfO6U0qq-lrSpses%2Fedit%3Fusp%3Dsharing&data=04%7C01%7Csimonpj%40microsoft.com%7C2f00be7cdc504b92fcc708d8df229562%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637504686911684988%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=bWQMb8whuhbQamUYbMReDvrCEjhJtX1oG2tQZcCwE6k%3D&reserved=0. They have already adopted this wording. 4. We’ll look forward to a new record-update proposal soon, which Adam is working on. I think this is fine. We discussed the original proposal for months, and this modification draws back on that accepted proposal, and so should be even easier to agree.

Please yell now (today) if you really think this is a mistake. I have checked with the authors and this is acceptable to them. I think if we say no, we want to back to the drawing board for the entire design they’ll just give up, and with some justification.

OK?

Simon

*From:* ghc-steering-committee *On Behalf Of *Iavor Diatchki *Sent:* 05 March 2021 16:03 *To:* Spiwack, Arnaud ; ghc-steering-committee *Subject:* Re: [ghc-steering-committee] Modification to record dot syntax propsal

I find that this committee is having less and less technical discussion on concrete issues, and there is a lot of talk of process, rules, and definitions, that I do not find useful.

...

...

...

While "experimental" extensions are totally fine in my book, I really do think we should avoid intentionally introducing things that we know now are likely to change. The overloaded records update is such an extension: it changes a useful, standardized, and in my experience, not uncommonly used feature, into a less general version (in one dimension, anyway). Furthermore, we are aware that there is already work by Adam to address this, so the extension will likely change (or perhaps we are going to have yet another record related extension).

...

...

So, why the hurry to add this to GHC now, when we know from experience how painful it is to remove things, once they are out in the wild?

...

On Fri, Mar 5, 2021, 02:50 Spiwack, Arnaud wrote:

...

...

Iavor,

...

...

...

...

I concur with Simon and Eric. Accepting a proposal is a promise that the proposal will not be debated on the design front in the future. That is, when the implementation comes up it is out of scope to discuss design. That's the deal. GHC proposals are a process. The goal of this process is to foster participation of the wider community to the evolution of GHC, by reducing stress and uncertainty, and focusing productivity. This is why changing the design of an accepted proposal requires another proposal, submitted to the same level of scrutiny as the original proposal. Even, and in particular, by members of the steering committee.

...

...

...

...

In this particular case, the authors have agreed to the change, and this is something that we feel is important enough to press forward quickly. So in the interest of everybody's time, I suggest that we move on. But, generally, the point stands.

...

...

...

...

/Arnaud

...

...

...

...

On Thu, Mar 4, 2021 at 8:45 PM Eric Seidel wrote:

...

...

...

I agree it’s more important to get things right than to look good, but we should aim to do both of course. As Simon mentioned earlier, this will erode the community’s confidence if it happens too often. So I’m ok with reversing our decision on this point (happily it sounds like there’s already work underway on an improved design), but I think we should reflect on why we didn’t have this discussion back when we were discussing the original proposal.

...

...

...

Sent from my iPhone

...

...

...

...

...

...

...

On Mar 4, 2021, at 14:04, Iavor Diatchki wrote:

...

...

...

...



...

...

...

...

Bad look or not, it seems better to me to change our mind than accept something "to save face" :) It seems hard to imagine that I am the only one here who uses type changing updates in records. How are other members of the committee reconciling this change? Are you planning to change your code to use record wild cards as Neil suggested---this seems a lot worse than the status quo? Or is the plan the plan to just fork the language and use the pragma to disambiguate?

...

...

...

...

...

...

...

...

I don't mind if the extension is in GHC's code, but I think that if we add it to the GHC manual, people will use it, and it will be a much bigger deal to change later.

...

...

...

...

...

...

...

...

On Thu, Mar 4, 2021 at 9:59 AM Eric Seidel wrote:

...

...

...

...

...

Yes that clears up the current situation. And from the current email chain it looks like the authors are aware of the plan to send record updates back for revision? I'd just want to make sure that the updated proposal reflects that split on which parts have been accepted.

For what it's worth, I do recall the loss of type-changing update being part of the original proposal and thought the proposal was still good on balance. The tradeoffs were definitely discussed in the giant Github thread, I don't recall if we discussed that aspect here though.. Regardless, I think it's a bad look for us to walk back a decision on account of not having read the proposal closely enough!

On Thu, Mar 4, 2021, at 09:53, Simon Peyton Jones 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@haskell.org> 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 <ghc-steering-committee- > | bounces@haskell.org> *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 https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fhaskell.org%2F&data=04%7C01%7Csimonpj%40microsoft.com%7Ce0e7e14d1ba74d216e9e08d8dff055dc%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637505571335600745%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=s8rfn2SfP1OFefRGDsd%2FmqTI%2FLu3z7qMkFNhZBlZDbc%3D&reserved=0%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering- > | committee&data=04%7C01%7Csimonpj%40microsoft.com https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2F40microsoft.com%2F&data=04%7C01%7Csimonpj%40microsoft.com%7Ce0e7e14d1ba74d216e9e08d8dff055dc%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637505571335610744%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=0iayJnlnpm5mchQpMmPgRY5bw2t%2FSrHkYmfnXamfgjQ%3D&reserved=0%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 https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fhaskell.org%2F&data=04%7C01%7Csimonpj%40microsoft.com%7Ce0e7e14d1ba74d216e9e08d8dff055dc%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637505571335620741%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=Ba9awmAYQ%2BPEtLYOlw2Mu8irB%2FGwmvv2OM30ofAMCmA%3D&reserved=0%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering- > | committee&data=04%7C01%7Csimonpj%40microsoft.com https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2F40microsoft.com%2F&data=04%7C01%7Csimonpj%40microsoft.com%7Ce0e7e14d1ba74d216e9e08d8dff055dc%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637505571335620741%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=%2BikTVk4HLF4Gey%2BgOoWnbhGKbYhUADxIfZNAzEBtFp8%3D&reserved=0%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 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%7Ce0e7e14d1ba74d216e9e08d8dff055dc%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637505571335630737%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=6A2TJygA2WZ29GqX4kBSJmZi5kX2O2Tmawv4SvpNZuk%3D&reserved=0

...

...

...

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@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%7Ce0e7e14d1ba74d216e9e08d8dff055dc%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637505571335630737%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=6A2TJygA2WZ29GqX4kBSJmZi5kX2O2Tmawv4SvpNZuk%3D&reserved=0

...

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

I think this all comes back to: What does an extension mean? I think it means that users are opting into a language feature. For me, the existence of an extension emphatically does *not* mean that the extension is potentially part of some future standard. I think this viewpoint is different for others of us, and it's worth having a conversation about this. I may start that conversation soon, if no one beats me to it. Under my interpretation of extension (opt-in feature), -XOverloadedRecordUpdate works great. I have never knowingly used type-changing update, though I see why it can be useful. While the fork-like nature of the proposal is regrettable, I think it's worthwhile, on balance. I was aware of this particular issue back when we were deciding about the original proposal and voted in favor of acceptance. My stance has not changed. So, for me, it's not about "saving face", which I agree is generally a poor reason to make a poor decision. I want to keep the feature as proposed on its own merits. Indeed, I would be happy to fully advertise both new extensions (that is, -XOverloadedRecordDot and -XOverloadedRecordUpdate) in the next release of GHC. The reason I'm also happy to keep the second one less advertised is because an update is in the works, as we've been told -- not because I find the original proposal bad. And, just to reiterate my position: if it's implemented and not statically excluded, it should be documented. For an experimental feature that is subject to change, the documentation burden is lower (but not absent). But extensions are discoverable, for example with ghc --supported-extensions. The extensions also live in GHC.LanguageExtension, so that downstream tools know of the extensions GHC supports. I have had several times when I've run across undocumented features in GHC, and it's been quite frustrating to figure out what they do. I don't think we should intentionally make this mistake. All I'm asking for is a mention in the manual, with a statement that the feature is subject to change, and with a pointer to the proposal. More is fine, too, but my minimum ask is pretty small. Richard

On Mar 4, 2021, at 12:59 PM, Eric Seidel wrote:

Yes that clears up the current situation. And from the current email chain it looks like the authors are aware of the plan to send record updates back for revision? I'd just want to make sure that the updated proposal reflects that split on which parts have been accepted.

For what it's worth, I do recall the loss of type-changing update being part of the original proposal and thought the proposal was still good on balance. The tradeoffs were definitely discussed in the giant Github thread, I don't recall if we discussed that aspect here though.. Regardless, I think it's a bad look for us to walk back a decision on account of not having read the proposal closely enough!

On Thu, Mar 4, 2021, at 09:53, Simon Peyton Jones 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

That's good vocabulary. One other dimension: * Is the extension *stable* or *experimental*. By "stable* I mean that we will make efforts not to gratuitously change its meaning. By "experimental" I mean that its meaning may change in future, or the extension may disappear altogether. Consequence: if you are building a long-lived library, you probably want to avoid relying on experimental features, because they may change or disappear, in which case you'll have to update your library. Most features we discuss are intended to be stable. The OverloadedRecordUpdate sounds more experimental at this stage. | That leaves the question of whether we should allow for any permanent | extensions. I didn't understand this bit. We have *lots* of permanent extensions. Indeed everything in GHC2021 is permanent by definition (we've made them part of the GHC2021 language) isn't it? Simon | -----Original Message----- | From: ghc-steering-committee On Behalf Of Eric Seidel | Sent: 05 March 2021 01:39 | To: ghc-steering-committee@haskell.org | Subject: Re: [ghc-steering-committee] What is an extension? (was: | Modification to record dot syntax propsal) | | On Thu, Mar 4, 2021, at 15:01, Richard Eisenberg wrote: | > I think this all comes back to: What does an extension mean? I think | > it means that users are opting into a language feature. For me, the | > existence of an extension emphatically does *not* mean that the | > extension is potentially part of some future standard. I think this | > viewpoint is different for others of us, and it's worth having a | > conversation about this. I may start that conversation soon, if no | one | > beats me to it. | | Let's go ahead and have this conversation. Here are a few questions | that come to mind: | | - Does an extension *expand* the language or *change* it? In other | words, does an extension strictly accept more programs than before, or | can it change the meaning of existing programs, or even reject | previously valid programs? | | - Is an extension *transitional* or *permanent*? Do we expect the | extension to eventually be on-by-default and effectively disappear, or | will it continue to be opt-in? | | - Is an extension *contained* within a module or is it *infectious*? | Does my choice of extensions when writing a module affect which | extensions downstream clients must enable? (I would say most | extensions are contained, e.g. you can apply a type family without | enabling TypeFamilies or match on a pattern synonym without enabling | PatternSynonyms. However, you cannot call a function that takes an | implicit parameter without enabling ImplicitParams.) | | The "no-fork" criterion for evaluating proposals argues that all | extensions should be transitional, but does not address the other | questions. I think extensions that change the language or are | infectious should meet a higher bar to be accepted, but we should not | reject them outright. If we agree that the proposal would improve the | language, we should allow for some disruption. I don't think we should | aim for backwards compatibility at any cost. | | That leaves the question of whether we should allow for any permanent | extensions. I think the most important aspect of the "no-fork" | criterion is that permanent extensions that change the language or | infect downstream modules are bad. This is where you start to create | truly incompatible dialects of the language. During the GHC2021 | discussion, a few of us (myself included) voiced support for something | along the lines of language levels: extensions that add more advanced | features to the language like FFI or fancy types, and that you might | want to contain to a subset of modules to facilitate reasoning about | your code. In other words, permanent extensions are acceptable so long | as they both expand the language and are contained within a module. | | So I think there are three classes of reasonable extensions: | | 1. transitional AND expand AND contained: this class is hopefully | uncontroversial 2. transitional AND (change OR infectious): we should | have the ability to make big changes, but should use it judiciously 3. | permanent AND expand AND contained: extensions are a handy way to | indicate that a module deals with more advanced areas of the language | (and can serve to isolate those concerns) | | Eric | _______________________________________________ | 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%7Ce1d6aea762ee415 | 54ba308d8df7788ee%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6375050 | 51854197326%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMz | IiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=33rA74unELy12hNzQKI% | 2BBkrv%2Fwt3067zTiFoM4j6lXI%3D&reserved=0

Aha I see. You meant "transient" = extensions that we expect to include in GHCxxx one day "permanent" = extensions that we would never do that for, like OverlappingInstances, or Strict. Fine. I totally misunderstood that. I'm not sure of better names... Simon | -----Original Message----- | From: Eric Seidel | Sent: 05 March 2021 14:03 | To: Simon Peyton Jones | Cc: ghc-steering-committee@haskell.org | Subject: Re: [ghc-steering-committee] What is an extension? (was: | Modification to record dot syntax propsal) | | The transient vs permanent dimension is more aspirational than the | others. I would classify extensions that were included in GHC2021 as | transient. The hope is that these extensions eventually make it into | the next Haskell Report, and effectively disappear from our lexicon. | They’re no longer extensions to Haskell, they’re simply part of | Haskell. | | In contrast, extensions like Strict/StrictData have no hope of ever | making it into a future standard, and thus I’d call them permanent. | | Does that make sense? I’d welcome better terminology. | | Sent from my iPhone | | > On Mar 5, 2021, at 03:26, Simon Peyton Jones | wrote: | > | > That's good vocabulary. | > | > One other dimension: | > | > * Is the extension *stable* or *experimental*. | > | > By "stable* I mean that we will make efforts not to gratuitously | change its meaning. By "experimental" I mean that its meaning may | change in future, or the extension may disappear altogether. | > | > Consequence: if you are building a long-lived library, you probably | want to avoid relying on experimental features, because they may | change or disappear, in which case you'll have to update your library. | > | > Most features we discuss are intended to be stable. The | OverloadedRecordUpdate sounds more experimental at this stage. | > | > | That leaves the question of whether we should allow for any | > | permanent extensions. | > | > I didn't understand this bit. We have *lots* of permanent | extensions. Indeed everything in GHC2021 is permanent by definition | (we've made them part of the GHC2021 language) isn't it? | > | > Simon | > | > | -----Original Message----- | > | From: ghc-steering-committee | bounces@haskell.org> On Behalf Of Eric Seidel | > | Sent: 05 March 2021 01:39 | > | To: ghc-steering-committee@haskell.org | > | Subject: Re: [ghc-steering-committee] What is an extension? (was: | > | Modification to record dot syntax propsal) | > | | > | On Thu, Mar 4, 2021, at 15:01, Richard Eisenberg wrote: | > | > I think this all comes back to: What does an extension mean? I | > | think > it means that users are opting into a language feature. | For | > | me, the > existence of an extension emphatically does *not* mean | > | that the > extension is potentially part of some future standard. | I | > | think this > viewpoint is different for others of us, and it's | > | worth having a > conversation about this. I may start that | > | conversation soon, if no one > beats me to it. | > | | > | Let's go ahead and have this conversation. Here are a few | questions | > | that come to mind: | > | | > | - Does an extension *expand* the language or *change* it? In | other | > | words, does an extension strictly accept more programs than | before, | > | or can it change the meaning of existing programs, or even reject | > | previously valid programs? | > | | > | - Is an extension *transitional* or *permanent*? Do we expect the | > | extension to eventually be on-by-default and effectively | disappear, | > | or will it continue to be opt-in? | > | | > | - Is an extension *contained* within a module or is it | *infectious*? | > | Does my choice of extensions when writing a module affect which | > | extensions downstream clients must enable? (I would say most | > | extensions are contained, e.g. you can apply a type family without | > | enabling TypeFamilies or match on a pattern synonym without | enabling | > | PatternSynonyms. However, you cannot call a function that takes an | > | implicit parameter without enabling ImplicitParams.) | > | | > | The "no-fork" criterion for evaluating proposals argues that all | > | extensions should be transitional, but does not address the other | > | questions. I think extensions that change the language or are | > | infectious should meet a higher bar to be accepted, but we should | > | not reject them outright. If we agree that the proposal would | > | improve the language, we should allow for some disruption. I | don't | > | think we should aim for backwards compatibility at any cost. | > | | > | That leaves the question of whether we should allow for any | > | permanent extensions. I think the most important aspect of the | "no-fork" | > | criterion is that permanent extensions that change the language | or | > | infect downstream modules are bad. This is where you start to | create | > | truly incompatible dialects of the language. During the GHC2021 | > | discussion, a few of us (myself included) voiced support for | > | something along the lines of language levels: extensions that add | > | more advanced features to the language like FFI or fancy types, | and | > | that you might want to contain to a subset of modules to | facilitate | > | reasoning about your code. In other words, permanent extensions | are | > | acceptable so long as they both expand the language and are | contained within a module. | > | | > | So I think there are three classes of reasonable extensions: | > | | > | 1. transitional AND expand AND contained: this class is hopefully | > | uncontroversial 2. transitional AND (change OR infectious): we | > | should have the ability to make big changes, but should use it | judiciously 3. | > | permanent AND expand AND contained: extensions are a handy way to | > | indicate that a module deals with more advanced areas of the | > | language (and can serve to isolate those concerns) | > | | > | Eric | > | _______________________________________________ | > | ghc-steering-committee mailing list | > | ghc-steering-committee@haskell.org | > | | > | | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fma | > | il | > | .haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering- | > | | > | | committee&data=04%7C01%7Csimonpj%40microsoft.com%7Ce1d6aea762ee4 | > | 15 | > | | > | | 54ba308d8df7788ee%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63750 | > | 50 | > | | 51854197326%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2lu | > | Mz | > | | IiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=33rA74unELy12hNzQK | > | I% | > | 2BBkrv%2Fwt3067zTiFoM4j6lXI%3D&reserved=0