From simonpj at microsoft.com  Mon Mar  1 09:19:10 2021
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Mon, 1 Mar 2021 09:19:10 +0000
Subject: [ghc-steering-committee] Modification to record dot syntax
	propsal
In-Reply-To: <VI1PR83MB0222BD8EC07924531D115264AD809@VI1PR83MB0222.EURPRD83.prod.outlook.com>
References: <VI1PR83MB0222BD8EC07924531D115264AD809@VI1PR83MB0222.EURPRD83.prod.outlook.com>
Message-ID: <VI1PR83MB0222683E12E94EBF9AC82C21AD9A9@VI1PR83MB0222.EURPRD83.prod.outlook.com>

I'll mark this accepted on Wednesday, unless anyone else wants to express an opinion, or offer an alternative.
Simon

From: Simon Peyton Jones <simonpj at microsoft.com>
Sent: 23 February 2021 15:06
To: ghc-steering-committee <ghc-steering-committee at haskell.org>
Cc: Simon Peyton Jones <simonpj at microsoft.com>
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 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20210301/292c652d/attachment.html>

From arnaud.spiwack at tweag.io  Mon Mar  1 09:40:02 2021
From: arnaud.spiwack at tweag.io (Spiwack, Arnaud)
Date: Mon, 1 Mar 2021 10:40:02 +0100
Subject: [ghc-steering-committee] Modification to record dot syntax
	propsal
In-Reply-To: <VI1PR83MB022233AD140B7B84463C45D4AD9D9@VI1PR83MB0222.EURPRD83.prod.outlook.com>
References: <VI1PR83MB0222BD8EC07924531D115264AD809@VI1PR83MB0222.EURPRD83.prod.outlook.com>
 <VI1PR83MB02221D0C9C4C75606C6F9FD3AD9D9@VI1PR83MB0222.EURPRD83.prod.outlook.com>
 <010f0177defd0abc-ddb39126-a38d-4cd7-b888-81acd5493dea-000000@us-east-2.amazonses.com>
 <CAGK9nur-Q+gft7qQodSCsaK4xnvpZoXwccaNYU4VNH_keoGEOA@mail.gmail.com>
 <CAH6fHQm1OFX+0i+CVwDC_m0HdQ=fnFN0uTtjdA9zifZV3ZVJoA@mail.gmail.com>
 <VI1PR83MB022233AD140B7B84463C45D4AD9D9@VI1PR83MB0222.EURPRD83.prod.outlook.com>
Message-ID: <CAH6fHQ=1Hb5jZH3Yhr-BejT2j83++iykvCZPVYC9HYMueOmHZA@mail.gmail.com>

Simon, all,

After reading more of the PR thread (in particular the fews posts after
Simon's recommendation), I have to admit: I am thoroughly confused. I'm not
sure that two people in that thread have the same motivation, end goal, or
design in mind.

The motivations provided by the modified *Alternatives* section is not much
more helpful (at the risk of caricaturing a little, it basically reads: “we
made two extensions rather than one because we can”). Though it makes it
clear that the end goal is to fold a bunch of record-related extensions
into one glorious record extension (well, probably not fold them, but make
a meta-extension that implies all the extensions that we've decided we
like).

My starting point is that:
- Additional extensions have a maintenance cost
- Additional extensions impose a cognitive burden on their use
- I expect that a new extension will break my code in the next few releases.

Based on this, I don't care how this extension or the glorious record
extension are named; but if we want to have two extensions we should have a
serious reason. Right now, the one reason that I see (and Iavor raised), is
that the update part of `RecordDotSyntax` is not backward compatible. Is it
a strong enough reason? I don't know. The only data point that I can
provide is that when we discussed the original proposal, I brought it up
several times, and it didn't seem very important at the time (the
conversation focused on other points of the proposal).

So, I'm still reluctant. I feel that, at the very least, the motivations
are not well-enough articulated in the proposal (I'll make a comment to
this effect on Github when I'm done composing this email).

I appreciate that I'm in the minority here. Yet, I'm still unconvinced.

Best,
Arnaud

On Sat, Feb 27, 2021 at 12:39 AM Simon Peyton Jones <simonpj at microsoft.com>
wrote:

> Generally, I'm not in favour in proposals which split extensions though:
> we already have so many extensions. Are the reasons for this split strong
> enough? I haven't had time to dig into the details.
>
> Arnaud, happily, you don’t have to dig very deep – just read the handful
> of posts following my recommendation.
>
>
>
> There seem to be two motivations.
>
>
>
>    1. There really are two orthogonal extensions, one for r.x notation,
>    and one for overloaded update.  Iavor likes the first but not the second.
>    Neil likes both.  Having separate extensions lets us experiment.
>
>
>
>    1. You suggest that changing the definition of RecordDotSyntax in a
>    subsequent release, e.g. by subsequently making it imply NoFieldSelectors,
>    would be fine. But it certainly imposes pain – some programs would stop
>    compiling.  The approach offered by this proposal avoids that problem.
>
>
>
> Yes, there are lots of extensions surrounding records: NoFieldSelectors,
> DuplicateRecordFields, NamedFieldPuns, DisambiguateRecordFields,
> RecordWildCards.  It may not be pretty to divide things up so fine, but
> it’s not new.
>
>
>
>
>
> If there are alternative suggestions, let’s hear them.
>
>
>
> Simon
>
>
>
> *From:* ghc-steering-committee <ghc-steering-committee-bounces at haskell.org>
> *On Behalf Of *Spiwack, Arnaud
> *Sent:* 26 February 2021 22:33
> *To:* Iavor Diatchki <iavor.diatchki at gmail.com>
> *Cc:* ghc-steering-committee <ghc-steering-committee at haskell.org>
> *Subject:* Re: [ghc-steering-committee] Modification to record dot syntax
> propsal
>
>
>
>
>
> I do think that  reusing the record update syntax for the overloaded
> monomorphic update is a mistake---it is not something I had noticed during
> our original discussion.
>
>
>
> This is the one reason I can see for cutting this extension in smaller
> pieces. But, then again, -XOverloadedRecordUpdate would be a fork-like
> extension.
>
>
>
> Generally, I'm not in favour in proposals which split extensions though:
> we already have so many extensions. Are the reasons for this split strong
> enough? I haven't had time to dig into the details.
>
>
>
> I'm not sure that not having the design of the proposal quite finalised is
> a good reason, extensions mutate in their first iterations, I don't think
> that it's a problem.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20210301/c95745b7/attachment-0001.html>

From iavor.diatchki at gmail.com  Mon Mar  1 17:23:29 2021
From: iavor.diatchki at gmail.com (Iavor Diatchki)
Date: Mon, 1 Mar 2021 09:23:29 -0800
Subject: [ghc-steering-committee] Modification to record dot syntax
	propsal
In-Reply-To: <CAH6fHQ=1Hb5jZH3Yhr-BejT2j83++iykvCZPVYC9HYMueOmHZA@mail.gmail.com>
References: <VI1PR83MB0222BD8EC07924531D115264AD809@VI1PR83MB0222.EURPRD83.prod.outlook.com>
 <VI1PR83MB02221D0C9C4C75606C6F9FD3AD9D9@VI1PR83MB0222.EURPRD83.prod.outlook.com>
 <010f0177defd0abc-ddb39126-a38d-4cd7-b888-81acd5493dea-000000@us-east-2.amazonses.com>
 <CAGK9nur-Q+gft7qQodSCsaK4xnvpZoXwccaNYU4VNH_keoGEOA@mail.gmail.com>
 <CAH6fHQm1OFX+0i+CVwDC_m0HdQ=fnFN0uTtjdA9zifZV3ZVJoA@mail.gmail.com>
 <VI1PR83MB022233AD140B7B84463C45D4AD9D9@VI1PR83MB0222.EURPRD83.prod.outlook.com>
 <CAH6fHQ=1Hb5jZH3Yhr-BejT2j83++iykvCZPVYC9HYMueOmHZA@mail.gmail.com>
Message-ID: <CAGK9nurtqxSTdeUya415wvdswjpTm9noUnLw+WMJv06ozhoETg@mail.gmail.com>

Hello,

I think there is a strong motivation to *at least* split the extensions:
with the current design, enabling the special `.` notation also *disables*
type changing record update, which has nothing to do with the `.` notation.

My preference would be to:
  1. Split the original proposal into two parts: one about `.` notation,
the other about record update (as suggested by this proposal)
  2. Treat the `.` notation part as accepted
  3. Require changes on the record update part, so that you don't have to
choose between it and type changing record updates, which are quite useful,
and I don't think we should aim for a Haskell without them.

I don't buy the argument of "this is already accepted", as I don't think
many of us had noticed that part of the proposal (I certainly didn't), and
I think we should be flexible enough to revisit previous decisions when we
notice problems with them.

-Iavor



On Mon, Mar 1, 2021 at 1:40 AM Spiwack, Arnaud <arnaud.spiwack at tweag.io>
wrote:

> Simon, all,
>
> After reading more of the PR thread (in particular the fews posts after
> Simon's recommendation), I have to admit: I am thoroughly confused. I'm not
> sure that two people in that thread have the same motivation, end goal, or
> design in mind.
>
> The motivations provided by the modified *Alternatives* section is not
> much more helpful (at the risk of caricaturing a little, it basically
> reads: “we made two extensions rather than one because we can”). Though it
> makes it clear that the end goal is to fold a bunch of record-related
> extensions into one glorious record extension (well, probably not fold
> them, but make a meta-extension that implies all the extensions that we've
> decided we like).
>
> My starting point is that:
> - Additional extensions have a maintenance cost
> - Additional extensions impose a cognitive burden on their use
> - I expect that a new extension will break my code in the next few
> releases.
>
> Based on this, I don't care how this extension or the glorious record
> extension are named; but if we want to have two extensions we should have a
> serious reason. Right now, the one reason that I see (and Iavor raised), is
> that the update part of `RecordDotSyntax` is not backward compatible. Is it
> a strong enough reason? I don't know. The only data point that I can
> provide is that when we discussed the original proposal, I brought it up
> several times, and it didn't seem very important at the time (the
> conversation focused on other points of the proposal).
>
> So, I'm still reluctant. I feel that, at the very least, the motivations
> are not well-enough articulated in the proposal (I'll make a comment to
> this effect on Github when I'm done composing this email).
>
> I appreciate that I'm in the minority here. Yet, I'm still unconvinced.
>
> Best,
> Arnaud
>
> On Sat, Feb 27, 2021 at 12:39 AM Simon Peyton Jones <simonpj at microsoft.com>
> wrote:
>
>> Generally, I'm not in favour in proposals which split extensions though:
>> we already have so many extensions. Are the reasons for this split strong
>> enough? I haven't had time to dig into the details.
>>
>> Arnaud, happily, you don’t have to dig very deep – just read the handful
>> of posts following my recommendation.
>>
>>
>>
>> There seem to be two motivations.
>>
>>
>>
>>    1. There really are two orthogonal extensions, one for r.x notation,
>>    and one for overloaded update.  Iavor likes the first but not the second.
>>    Neil likes both.  Having separate extensions lets us experiment.
>>
>>
>>
>>    1. You suggest that changing the definition of RecordDotSyntax in a
>>    subsequent release, e.g. by subsequently making it imply NoFieldSelectors,
>>    would be fine. But it certainly imposes pain – some programs would stop
>>    compiling.  The approach offered by this proposal avoids that problem.
>>
>>
>>
>> Yes, there are lots of extensions surrounding records: NoFieldSelectors,
>> DuplicateRecordFields, NamedFieldPuns, DisambiguateRecordFields,
>> RecordWildCards.  It may not be pretty to divide things up so fine, but
>> it’s not new.
>>
>>
>>
>>
>>
>> If there are alternative suggestions, let’s hear them.
>>
>>
>>
>> Simon
>>
>>
>>
>> *From:* ghc-steering-committee <
>> ghc-steering-committee-bounces at haskell.org> *On Behalf Of *Spiwack,
>> Arnaud
>> *Sent:* 26 February 2021 22:33
>> *To:* Iavor Diatchki <iavor.diatchki at gmail.com>
>> *Cc:* ghc-steering-committee <ghc-steering-committee at haskell.org>
>> *Subject:* Re: [ghc-steering-committee] Modification to record dot
>> syntax propsal
>>
>>
>>
>>
>>
>> I do think that  reusing the record update syntax for the overloaded
>> monomorphic update is a mistake---it is not something I had noticed during
>> our original discussion.
>>
>>
>>
>> This is the one reason I can see for cutting this extension in smaller
>> pieces. But, then again, -XOverloadedRecordUpdate would be a fork-like
>> extension.
>>
>>
>>
>> Generally, I'm not in favour in proposals which split extensions though:
>> we already have so many extensions. Are the reasons for this split strong
>> enough? I haven't had time to dig into the details.
>>
>>
>>
>> I'm not sure that not having the design of the proposal quite finalised
>> is a good reason, extensions mutate in their first iterations, I don't
>> think that it's a problem.
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20210301/57709b20/attachment.html>

From simonpj at microsoft.com  Mon Mar  1 17:51:07 2021
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Mon, 1 Mar 2021 17:51:07 +0000
Subject: [ghc-steering-committee] Modification to record dot syntax
 propsal
In-Reply-To: <CAGK9nurtqxSTdeUya415wvdswjpTm9noUnLw+WMJv06ozhoETg@mail.gmail.com>
References: <VI1PR83MB0222BD8EC07924531D115264AD809@VI1PR83MB0222.EURPRD83.prod.outlook.com>
 <VI1PR83MB02221D0C9C4C75606C6F9FD3AD9D9@VI1PR83MB0222.EURPRD83.prod.outlook.com>
 <010f0177defd0abc-ddb39126-a38d-4cd7-b888-81acd5493dea-000000@us-east-2.amazonses.com>
 <CAGK9nur-Q+gft7qQodSCsaK4xnvpZoXwccaNYU4VNH_keoGEOA@mail.gmail.com>
 <CAH6fHQm1OFX+0i+CVwDC_m0HdQ=fnFN0uTtjdA9zifZV3ZVJoA@mail.gmail.com>
 <VI1PR83MB022233AD140B7B84463C45D4AD9D9@VI1PR83MB0222.EURPRD83.prod.outlook.com>
 <CAH6fHQ=1Hb5jZH3Yhr-BejT2j83++iykvCZPVYC9HYMueOmHZA@mail.gmail.com>
 <CAGK9nurtqxSTdeUya415wvdswjpTm9noUnLw+WMJv06ozhoETg@mail.gmail.com>
Message-ID: <VI1PR83MB02228D79560C8A731F0116D5AD9A9@VI1PR83MB0222.EURPRD83.prod.outlook.com>

I don't buy the argument of "this is already accepted", as I don't think many of us had noticed that part of the proposal (I certainly didn't), and I think we should be flexible enough to revisit previous decisions when we notice problems with them.
I agree in principle that we can revisit decisions.   But we have to be aware that it is potentially very discouraging for proposal authors to

  *   propose something,
  *   have it extensively debated (including this very point),
  *   have it accepted,
  *   implement it,
and then be told that the committee has changed its mind.  That’s pretty bad from their point of view.

Still, Adam is working on a new SetField proposal, so perhaps that’s a figleaf.  I’ll consult them.

Simon


From: Iavor Diatchki <iavor.diatchki at gmail.com>
Sent: 01 March 2021 17:23
To: Spiwack, Arnaud <arnaud.spiwack at tweag.io>
Cc: Simon Peyton Jones <simonpj at microsoft.com>; ghc-steering-committee <ghc-steering-committee at haskell.org>
Subject: Re: [ghc-steering-committee] Modification to record dot syntax propsal

Hello,

I think there is a strong motivation to *at least* split the extensions:  with the current design, enabling the special `.` notation also *disables* type changing record update, which has nothing to do with the `.` notation.

My preference would be to:
  1. Split the original proposal into two parts: one about `.` notation, the other about record update (as suggested by this proposal)
  2. Treat the `.` notation part as accepted
  3. Require changes on the record update part, so that you don't have to choose between it and type changing record updates, which are quite useful, and I don't think we should aim for a Haskell without them.

I don't buy the argument of "this is already accepted", as I don't think many of us had noticed that part of the proposal (I certainly didn't), and I think we should be flexible enough to revisit previous decisions when we notice problems with them.

-Iavor



On Mon, Mar 1, 2021 at 1:40 AM Spiwack, Arnaud <arnaud.spiwack at tweag.io<mailto:arnaud.spiwack at tweag.io>> wrote:
Simon, all,

After reading more of the PR thread (in particular the fews posts after Simon's recommendation), I have to admit: I am thoroughly confused. I'm not sure that two people in that thread have the same motivation, end goal, or design in mind.

The motivations provided by the modified Alternatives section is not much more helpful (at the risk of caricaturing a little, it basically reads: “we made two extensions rather than one because we can”). Though it makes it clear that the end goal is to fold a bunch of record-related extensions into one glorious record extension (well, probably not fold them, but make a meta-extension that implies all the extensions that we've decided we like).

My starting point is that:
- Additional extensions have a maintenance cost
- Additional extensions impose a cognitive burden on their use
- I expect that a new extension will break my code in the next few releases.

Based on this, I don't care how this extension or the glorious record extension are named; but if we want to have two extensions we should have a serious reason. Right now, the one reason that I see (and Iavor raised), is that the update part of `RecordDotSyntax` is not backward compatible. Is it a strong enough reason? I don't know. The only data point that I can provide is that when we discussed the original proposal, I brought it up several times, and it didn't seem very important at the time (the conversation focused on other points of the proposal).

So, I'm still reluctant. I feel that, at the very least, the motivations are not well-enough articulated in the proposal (I'll make a comment to this effect on Github when I'm done composing this email).

I appreciate that I'm in the minority here. Yet, I'm still unconvinced.

Best,
Arnaud

On Sat, Feb 27, 2021 at 12:39 AM Simon Peyton Jones <simonpj at microsoft.com<mailto:simonpj at microsoft.com>> wrote:
Generally, I'm not in favour in proposals which split extensions though: we already have so many extensions. Are the reasons for this split strong enough? I haven't had time to dig into the details.
Arnaud, happily, you don’t have to dig very deep – just read the handful of posts following my recommendation.

There seem to be two motivations.


  1.  There really are two orthogonal extensions, one for r.x notation, and one for overloaded update.  Iavor likes the first but not the second.  Neil likes both.  Having separate extensions lets us experiment.



  1.  You suggest that changing the definition of RecordDotSyntax in a subsequent release, e.g. by subsequently making it imply NoFieldSelectors, would be fine. But it certainly imposes pain – some programs would stop compiling.  The approach offered by this proposal avoids that problem.

Yes, there are lots of extensions surrounding records: NoFieldSelectors, DuplicateRecordFields, NamedFieldPuns, DisambiguateRecordFields, RecordWildCards.  It may not be pretty to divide things up so fine, but it’s not new.


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

Simon

From: ghc-steering-committee <ghc-steering-committee-bounces at haskell.org<mailto:ghc-steering-committee-bounces at haskell.org>> On Behalf Of Spiwack, Arnaud
Sent: 26 February 2021 22:33
To: Iavor Diatchki <iavor.diatchki at gmail.com<mailto:iavor.diatchki at gmail.com>>
Cc: ghc-steering-committee <ghc-steering-committee at haskell.org<mailto:ghc-steering-committee at haskell.org>>
Subject: Re: [ghc-steering-committee] Modification to record dot syntax propsal


I do think that  reusing the record update syntax for the overloaded monomorphic update is a mistake---it is not something I had noticed during our original discussion.

This is the one reason I can see for cutting this extension in smaller pieces. But, then again, -XOverloadedRecordUpdate would be a fork-like extension.

Generally, I'm not in favour in proposals which split extensions though: we already have so many extensions. Are the reasons for this split strong enough? I haven't had time to dig into the details.

I'm not sure that not having the design of the proposal quite finalised is a good reason, extensions mutate in their first iterations, I don't think that it's a problem.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20210301/b104ea58/attachment-0001.html>

From rae at richarde.dev  Mon Mar  1 22:03:51 2021
From: rae at richarde.dev (Richard Eisenberg)
Date: Mon, 1 Mar 2021 22:03:51 +0000
Subject: [ghc-steering-committee] Modification to record dot syntax
 propsal
In-Reply-To: <VI1PR83MB02228D79560C8A731F0116D5AD9A9@VI1PR83MB0222.EURPRD83.prod.outlook.com>
References: <VI1PR83MB0222BD8EC07924531D115264AD809@VI1PR83MB0222.EURPRD83.prod.outlook.com>
 <VI1PR83MB02221D0C9C4C75606C6F9FD3AD9D9@VI1PR83MB0222.EURPRD83.prod.outlook.com>
 <010f0177defd0abc-ddb39126-a38d-4cd7-b888-81acd5493dea-000000@us-east-2.amazonses.com>
 <CAGK9nur-Q+gft7qQodSCsaK4xnvpZoXwccaNYU4VNH_keoGEOA@mail.gmail.com>
 <CAH6fHQm1OFX+0i+CVwDC_m0HdQ=fnFN0uTtjdA9zifZV3ZVJoA@mail.gmail.com>
 <VI1PR83MB022233AD140B7B84463C45D4AD9D9@VI1PR83MB0222.EURPRD83.prod.outlook.com>
 <CAH6fHQ=1Hb5jZH3Yhr-BejT2j83++iykvCZPVYC9HYMueOmHZA@mail.gmail.com>
 <CAGK9nurtqxSTdeUya415wvdswjpTm9noUnLw+WMJv06ozhoETg@mail.gmail.com>
 <VI1PR83MB02228D79560C8A731F0116D5AD9A9@VI1PR83MB0222.EURPRD83.prod.outlook.com>
Message-ID: <010f0177efd1acec-ad95cda1-2995-4c89-99dc-c8bfdae1cf41-000000@us-east-2.amazonses.com>

I agree with Arnaud about the motivation, as I expressed earlier. That said, I'm happy enough with the technical content of the "let's split the extensions", and so am happy to let this go forward. My sense is that, while we're all on the same train at the moment, different people are planning on disembarking at different stops (that is, heading for different final designs), which may cause trouble later.

As one data point, I was aware of the loss of type-changing update in the previous go-round, was disappointed about this, but felt that the proposal was good on balance. I would be sad if we renege on this point.

I do think we need to have a discussion on what the point of an extension is. Is an extension an optional feature? a way for users to express that they know what they're doing and can accept the consequences? a preview of features that will one day become on by default? I can perhaps guide that discussion, but not today. (Tomorrow is the ICFP deadline.) I do think there will be quite a range of views on this point, and these differences have cropped up on occasion.

Richard

> On Mar 1, 2021, at 12:51 PM, Simon Peyton Jones via ghc-steering-committee <ghc-steering-committee at haskell.org> wrote:
> 
> I don't buy the argument of "this is already accepted", as I don't think many of us had noticed that part of the proposal (I certainly didn't), and I think we should be flexible enough to revisit previous decisions when we notice problems with them.
> 
> I agree in principle that we can revisit decisions.   But we have to be aware that it is potentially very discouraging for proposal authors to
> propose something,
> have it extensively debated (including this very point), 
> have it accepted,
> implement it,
> and then be told that the committee has changed its mind.  That’s pretty bad from their point of view.
>  
> Still, Adam is working on a new SetField proposal, so perhaps that’s a figleaf.  I’ll consult them.
> 
> Simon
>  
>  
> From: Iavor Diatchki <iavor.diatchki at gmail.com> 
> Sent: 01 March 2021 17:23
> To: Spiwack, Arnaud <arnaud.spiwack at tweag.io>
> Cc: Simon Peyton Jones <simonpj at microsoft.com>; ghc-steering-committee <ghc-steering-committee at haskell.org>
> Subject: Re: [ghc-steering-committee] Modification to record dot syntax propsal
>  
> Hello,
> 
>  
> 
> I think there is a strong motivation to *at least* split the extensions:  with the current design, enabling the special `.` notation also *disables* type changing record update, which has nothing to do with the `.` notation.
> 
>  
> 
> My preference would be to:
> 
>   1. Split the original proposal into two parts: one about `.` notation, the other about record update (as suggested by this proposal)
> 
>   2. Treat the `.` notation part as accepted
> 
>   3. Require changes on the record update part, so that you don't have to choose between it and type changing record updates, which are quite useful, and I don't think we should aim for a Haskell without them.
> 
>  
> 
> I don't buy the argument of "this is already accepted", as I don't think many of us had noticed that part of the proposal (I certainly didn't), and I think we should be flexible enough to revisit previous decisions when we notice problems with them.
> 
>  
> 
> -Iavor
> 
>  
> 
>  
> 
>  
> 
> On Mon, Mar 1, 2021 at 1:40 AM Spiwack, Arnaud <arnaud.spiwack at tweag.io <mailto:arnaud.spiwack at tweag.io>> wrote:
> 
> Simon, all,
> 
>  
> 
> After reading more of the PR thread (in particular the fews posts after Simon's recommendation), I have to admit: I am thoroughly confused. I'm not sure that two people in that thread have the same motivation, end goal, or design in mind.
> 
>  
> 
> The motivations provided by the modified Alternatives section is not much more helpful (at the risk of caricaturing a little, it basically reads: “we made two extensions rather than one because we can”). Though it makes it clear that the end goal is to fold a bunch of record-related extensions into one glorious record extension (well, probably not fold them, but make a meta-extension that implies all the extensions that we've decided we like).
> 
>  
> 
> My starting point is that:
> 
> - Additional extensions have a maintenance cost
> 
> - Additional extensions impose a cognitive burden on their use
> 
> - I expect that a new extension will break my code in the next few releases.
> 
>  
> 
> Based on this, I don't care how this extension or the glorious record extension are named; but if we want to have two extensions we should have a serious reason. Right now, the one reason that I see (and Iavor raised), is that the update part of `RecordDotSyntax` is not backward compatible. Is it a strong enough reason? I don't know. The only data point that I can provide is that when we discussed the original proposal, I brought it up several times, and it didn't seem very important at the time (the conversation focused on other points of the proposal).
> 
>  
> 
> So, I'm still reluctant. I feel that, at the very least, the motivations are not well-enough articulated in the proposal (I'll make a comment to this effect on Github when I'm done composing this email).
> 
>  
> 
> I appreciate that I'm in the minority here. Yet, I'm still unconvinced.
> 
>  
> 
> Best,
> 
> Arnaud
> 
>  
> 
> On Sat, Feb 27, 2021 at 12:39 AM Simon Peyton Jones <simonpj at microsoft.com <mailto:simonpj at microsoft.com>> wrote:
> 
> Generally, I'm not in favour in proposals which split extensions though: we already have so many extensions. Are the reasons for this split strong enough? I haven't had time to dig into the details.
> 
> Arnaud, happily, you don’t have to dig very deep – just read the handful of posts following my recommendation.
>  
> There seem to be two motivations.
>  
> 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 <ghc-steering-committee-bounces at haskell.org <mailto:ghc-steering-committee-bounces at haskell.org>> On Behalf Of Spiwack, Arnaud
> Sent: 26 February 2021 22:33
> To: Iavor Diatchki <iavor.diatchki at gmail.com <mailto:iavor.diatchki at gmail.com>>
> Cc: ghc-steering-committee <ghc-steering-committee at haskell.org <mailto:ghc-steering-committee at haskell.org>>
> Subject: Re: [ghc-steering-committee] Modification to record dot syntax propsal
>  
>  
> 
> I do think that  reusing the record update syntax for the overloaded monomorphic update is a mistake---it is not something I had noticed during our original discussion.
> 
>  
> 
> This is the one reason I can see for cutting this extension in smaller pieces. But, then again, -XOverloadedRecordUpdate would be a fork-like extension.
> 
>  
> 
> Generally, I'm not in favour in proposals which split extensions though: we already have so many extensions. Are the reasons for this split strong enough? I haven't had time to dig into the details.
> 
>  
> 
> I'm not sure that not having the design of the proposal quite finalised is a good reason, extensions mutate in their first iterations, I don't think that it's a problem.
> 
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20210301/52d3c918/attachment-0001.html>

From simonpj at microsoft.com  Tue Mar  2 12:45:29 2021
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Tue, 2 Mar 2021 12:45:29 +0000
Subject: [ghc-steering-committee] Modification to record dot syntax
 propsal
In-Reply-To: <VI1PR83MB02228D79560C8A731F0116D5AD9A9@VI1PR83MB0222.EURPRD83.prod.outlook.com>
References: <VI1PR83MB0222BD8EC07924531D115264AD809@VI1PR83MB0222.EURPRD83.prod.outlook.com>
 <VI1PR83MB02221D0C9C4C75606C6F9FD3AD9D9@VI1PR83MB0222.EURPRD83.prod.outlook.com>
 <010f0177defd0abc-ddb39126-a38d-4cd7-b888-81acd5493dea-000000@us-east-2.amazonses.com>
 <CAGK9nur-Q+gft7qQodSCsaK4xnvpZoXwccaNYU4VNH_keoGEOA@mail.gmail.com>
 <CAH6fHQm1OFX+0i+CVwDC_m0HdQ=fnFN0uTtjdA9zifZV3ZVJoA@mail.gmail.com>
 <VI1PR83MB022233AD140B7B84463C45D4AD9D9@VI1PR83MB0222.EURPRD83.prod.outlook.com>
 <CAH6fHQ=1Hb5jZH3Yhr-BejT2j83++iykvCZPVYC9HYMueOmHZA@mail.gmail.com>
 <CAGK9nurtqxSTdeUya415wvdswjpTm9noUnLw+WMJv06ozhoETg@mail.gmail.com>
 <VI1PR83MB02228D79560C8A731F0116D5AD9A9@VI1PR83MB0222.EURPRD83.prod.outlook.com>
Message-ID: <VI1PR83MB0222FFB6BA71803975996928AD999@VI1PR83MB0222.EURPRD83.prod.outlook.com>

Friends

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


  *   Proceed with OverloadedRecordDot for 9.2, exactly as in the original proposal except for the extension name.
  *   Record update will remain exactly as now, in 9.2; that is, drawing back from the original proposal.
  *   There may be some code in 9.2 that allows overloaded record update, protected by OverloadedRecordUpdate, but not in the user manual, and not treated as an accepted proposal.   I don’t think we should ask the authors to remove it, and it will allow experimentation.
  *   Adam is leading on a revised record-update proposal. This will cover
     *   the tradeoffs between type-changing and non-type-changing update
     *   what the current record-update syntax stands for, and/or any new syntax

Is that acceptable to everyone?

Simon

From: ghc-steering-committee <ghc-steering-committee-bounces at haskell.org> On Behalf Of Simon Peyton Jones via ghc-steering-committee
Sent: 01 March 2021 17:51
To: Iavor Diatchki <iavor.diatchki at gmail.com>; Spiwack, Arnaud <arnaud.spiwack at tweag.io>
Cc: ghc-steering-committee <ghc-steering-committee at haskell.org>
Subject: Re: [ghc-steering-committee] Modification to record dot syntax propsal

I don't buy the argument of "this is already accepted", as I don't think many of us had noticed that part of the proposal (I certainly didn't), and I think we should be flexible enough to revisit previous decisions when we notice problems with them.
I agree in principle that we can revisit decisions.   But we have to be aware that it is potentially very discouraging for proposal authors to

  *   propose something,
  *   have it extensively debated (including this very point),
  *   have it accepted,
  *   implement it,
and then be told that the committee has changed its mind.  That’s pretty bad from their point of view.

Still, Adam is working on a new SetField proposal, so perhaps that’s a figleaf.  I’ll consult them.

Simon


From: Iavor Diatchki <iavor.diatchki at gmail.com<mailto:iavor.diatchki at gmail.com>>
Sent: 01 March 2021 17:23
To: Spiwack, Arnaud <arnaud.spiwack at tweag.io<mailto:arnaud.spiwack at tweag.io>>
Cc: Simon Peyton Jones <simonpj at microsoft.com<mailto:simonpj at microsoft.com>>; ghc-steering-committee <ghc-steering-committee at haskell.org<mailto:ghc-steering-committee at haskell.org>>
Subject: Re: [ghc-steering-committee] Modification to record dot syntax propsal

Hello,

I think there is a strong motivation to *at least* split the extensions:  with the current design, enabling the special `.` notation also *disables* type changing record update, which has nothing to do with the `.` notation.

My preference would be to:
  1. Split the original proposal into two parts: one about `.` notation, the other about record update (as suggested by this proposal)
  2. Treat the `.` notation part as accepted
  3. Require changes on the record update part, so that you don't have to choose between it and type changing record updates, which are quite useful, and I don't think we should aim for a Haskell without them.

I don't buy the argument of "this is already accepted", as I don't think many of us had noticed that part of the proposal (I certainly didn't), and I think we should be flexible enough to revisit previous decisions when we notice problems with them.

-Iavor



On Mon, Mar 1, 2021 at 1:40 AM Spiwack, Arnaud <arnaud.spiwack at tweag.io<mailto:arnaud.spiwack at tweag.io>> wrote:
Simon, all,

After reading more of the PR thread (in particular the fews posts after Simon's recommendation), I have to admit: I am thoroughly confused. I'm not sure that two people in that thread have the same motivation, end goal, or design in mind.

The motivations provided by the modified Alternatives section is not much more helpful (at the risk of caricaturing a little, it basically reads: “we made two extensions rather than one because we can”). Though it makes it clear that the end goal is to fold a bunch of record-related extensions into one glorious record extension (well, probably not fold them, but make a meta-extension that implies all the extensions that we've decided we like).

My starting point is that:
- Additional extensions have a maintenance cost
- Additional extensions impose a cognitive burden on their use
- I expect that a new extension will break my code in the next few releases.

Based on this, I don't care how this extension or the glorious record extension are named; but if we want to have two extensions we should have a serious reason. Right now, the one reason that I see (and Iavor raised), is that the update part of `RecordDotSyntax` is not backward compatible. Is it a strong enough reason? I don't know. The only data point that I can provide is that when we discussed the original proposal, I brought it up several times, and it didn't seem very important at the time (the conversation focused on other points of the proposal).

So, I'm still reluctant. I feel that, at the very least, the motivations are not well-enough articulated in the proposal (I'll make a comment to this effect on Github when I'm done composing this email).

I appreciate that I'm in the minority here. Yet, I'm still unconvinced.

Best,
Arnaud

On Sat, Feb 27, 2021 at 12:39 AM Simon Peyton Jones <simonpj at microsoft.com<mailto:simonpj at microsoft.com>> wrote:
Generally, I'm not in favour in proposals which split extensions though: we already have so many extensions. Are the reasons for this split strong enough? I haven't had time to dig into the details.
Arnaud, happily, you don’t have to dig very deep – just read the handful of posts following my recommendation.

There seem to be two motivations.


  1.  There really are two orthogonal extensions, one for r.x notation, and one for overloaded update.  Iavor likes the first but not the second.  Neil likes both.  Having separate extensions lets us experiment.



  1.  You suggest that changing the definition of RecordDotSyntax in a subsequent release, e.g. by subsequently making it imply NoFieldSelectors, would be fine. But it certainly imposes pain – some programs would stop compiling.  The approach offered by this proposal avoids that problem.

Yes, there are lots of extensions surrounding records: NoFieldSelectors, DuplicateRecordFields, NamedFieldPuns, DisambiguateRecordFields, RecordWildCards.  It may not be pretty to divide things up so fine, but it’s not new.


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

Simon

From: ghc-steering-committee <ghc-steering-committee-bounces at haskell.org<mailto:ghc-steering-committee-bounces at haskell.org>> On Behalf Of Spiwack, Arnaud
Sent: 26 February 2021 22:33
To: Iavor Diatchki <iavor.diatchki at gmail.com<mailto:iavor.diatchki at gmail.com>>
Cc: ghc-steering-committee <ghc-steering-committee at haskell.org<mailto:ghc-steering-committee at haskell.org>>
Subject: Re: [ghc-steering-committee] Modification to record dot syntax propsal


I do think that  reusing the record update syntax for the overloaded monomorphic update is a mistake---it is not something I had noticed during our original discussion.

This is the one reason I can see for cutting this extension in smaller pieces. But, then again, -XOverloadedRecordUpdate would be a fork-like extension.

Generally, I'm not in favour in proposals which split extensions though: we already have so many extensions. Are the reasons for this split strong enough? I haven't had time to dig into the details.

I'm not sure that not having the design of the proposal quite finalised is a good reason, extensions mutate in their first iterations, I don't think that it's a problem.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20210302/9ea232f9/attachment-0001.html>

From iavor.diatchki at gmail.com  Tue Mar  2 15:55:28 2021
From: iavor.diatchki at gmail.com (Iavor Diatchki)
Date: Tue, 2 Mar 2021 07:55:28 -0800
Subject: [ghc-steering-committee] Modification to record dot syntax
	propsal
In-Reply-To: <VI1PR83MB0222FFB6BA71803975996928AD999@VI1PR83MB0222.EURPRD83.prod.outlook.com>
References: <VI1PR83MB0222BD8EC07924531D115264AD809@VI1PR83MB0222.EURPRD83.prod.outlook.com>
 <VI1PR83MB02221D0C9C4C75606C6F9FD3AD9D9@VI1PR83MB0222.EURPRD83.prod.outlook.com>
 <010f0177defd0abc-ddb39126-a38d-4cd7-b888-81acd5493dea-000000@us-east-2.amazonses.com>
 <CAGK9nur-Q+gft7qQodSCsaK4xnvpZoXwccaNYU4VNH_keoGEOA@mail.gmail.com>
 <CAH6fHQm1OFX+0i+CVwDC_m0HdQ=fnFN0uTtjdA9zifZV3ZVJoA@mail.gmail.com>
 <VI1PR83MB022233AD140B7B84463C45D4AD9D9@VI1PR83MB0222.EURPRD83.prod.outlook.com>
 <CAH6fHQ=1Hb5jZH3Yhr-BejT2j83++iykvCZPVYC9HYMueOmHZA@mail.gmail.com>
 <CAGK9nurtqxSTdeUya415wvdswjpTm9noUnLw+WMJv06ozhoETg@mail.gmail.com>
 <VI1PR83MB02228D79560C8A731F0116D5AD9A9@VI1PR83MB0222.EURPRD83.prod.outlook.com>
 <VI1PR83MB0222FFB6BA71803975996928AD999@VI1PR83MB0222.EURPRD83.prod.outlook.com>
Message-ID: <CAGK9nuob3LmwQZ42zYBBTFjsySusxhtQ5PAMKP2aBcEDyBdKBQ@mail.gmail.com>

That seems reasonable to me.

On Tue, Mar 2, 2021 at 4:46 AM Simon Peyton Jones via
ghc-steering-committee <ghc-steering-committee at haskell.org> wrote:

> Friends
>
>
>
> Having consulted the authors, I propose that we do this:
>
>
>
>    - Proceed with OverloadedRecordDot for 9.2, exactly as in the original
>    proposal except for the extension name.
>    - Record update will remain exactly as now, in 9.2; that is, drawing
>    back from the original proposal.
>    - There may be some *code* in 9.2 that allows overloaded record
>    update, protected by OverloadedRecordUpdate, but not in the user manual,
>    and not treated as an accepted proposal.   I don’t think we should ask the
>    authors to remove it, and it will allow experimentation.
>    - Adam is leading on a revised record-update proposal. This will cover
>       - the tradeoffs between type-changing and non-type-changing update
>       - what the current record-update syntax stands for, and/or any new
>       syntax
>
>
>
> Is that acceptable to everyone?
>
>
>
> Simon
>
>
>
> *From:* ghc-steering-committee <ghc-steering-committee-bounces at haskell.org>
> *On Behalf Of *Simon Peyton Jones via ghc-steering-committee
> *Sent:* 01 March 2021 17:51
> *To:* Iavor Diatchki <iavor.diatchki at gmail.com>; Spiwack, Arnaud <
> arnaud.spiwack at tweag.io>
> *Cc:* ghc-steering-committee <ghc-steering-committee at haskell.org>
> *Subject:* Re: [ghc-steering-committee] Modification to record dot syntax
> propsal
>
>
>
> I don't buy the argument of "this is already accepted", as I don't think
> many of us had noticed that part of the proposal (I certainly didn't), and
> I think we should be flexible enough to revisit previous decisions when we
> notice problems with them.
>
> I agree in principle that we can revisit decisions.   But we have to be
> aware that it is potentially very discouraging for proposal authors to
>
>    - propose something,
>    - have it *extensively* debated (including this very point),
>    - have it accepted,
>    - implement it,
>
> and then be told that the committee has changed its mind.  That’s pretty
> bad from their point of view.
>
>
>
> Still, Adam is working on a new SetField proposal, so perhaps that’s a
> figleaf.  I’ll consult them.
>
>
> Simon
>
>
>
>
>
> *From:* Iavor Diatchki <iavor.diatchki at gmail.com>
> *Sent:* 01 March 2021 17:23
> *To:* Spiwack, Arnaud <arnaud.spiwack at tweag.io>
> *Cc:* Simon Peyton Jones <simonpj at microsoft.com>; ghc-steering-committee <
> ghc-steering-committee at haskell.org>
> *Subject:* Re: [ghc-steering-committee] Modification to record dot syntax
> propsal
>
>
>
> Hello,
>
>
>
> I think there is a strong motivation to *at least* split the extensions:
> with the current design, enabling the special `.` notation also *disables*
> type changing record update, which has nothing to do with the `.` notation.
>
>
>
> My preference would be to:
>
>   1. Split the original proposal into two parts: one about `.` notation,
> the other about record update (as suggested by this proposal)
>
>   2. Treat the `.` notation part as accepted
>
>   3. Require changes on the record update part, so that you don't have to
> choose between it and type changing record updates, which are quite useful,
> and I don't think we should aim for a Haskell without them.
>
>
>
> I don't buy the argument of "this is already accepted", as I don't think
> many of us had noticed that part of the proposal (I certainly didn't), and
> I think we should be flexible enough to revisit previous decisions when we
> notice problems with them.
>
>
>
> -Iavor
>
>
>
>
>
>
>
> On Mon, Mar 1, 2021 at 1:40 AM Spiwack, Arnaud <arnaud.spiwack at tweag.io>
> wrote:
>
> Simon, all,
>
>
>
> After reading more of the PR thread (in particular the fews posts after
> Simon's recommendation), I have to admit: I am thoroughly confused. I'm not
> sure that two people in that thread have the same motivation, end goal, or
> design in mind.
>
>
>
> The motivations provided by the modified *Alternatives* section is not
> much more helpful (at the risk of caricaturing a little, it basically
> reads: “we made two extensions rather than one because we can”). Though it
> makes it clear that the end goal is to fold a bunch of record-related
> extensions into one glorious record extension (well, probably not fold
> them, but make a meta-extension that implies all the extensions that we've
> decided we like).
>
>
>
> My starting point is that:
>
> - Additional extensions have a maintenance cost
>
> - Additional extensions impose a cognitive burden on their use
>
> - I expect that a new extension will break my code in the next few
> releases.
>
>
>
> Based on this, I don't care how this extension or the glorious record
> extension are named; but if we want to have two extensions we should have a
> serious reason. Right now, the one reason that I see (and Iavor raised), is
> that the update part of `RecordDotSyntax` is not backward compatible. Is it
> a strong enough reason? I don't know. The only data point that I can
> provide is that when we discussed the original proposal, I brought it up
> several times, and it didn't seem very important at the time (the
> conversation focused on other points of the proposal).
>
>
>
> So, I'm still reluctant. I feel that, at the very least, the motivations
> are not well-enough articulated in the proposal (I'll make a comment to
> this effect on Github when I'm done composing this email).
>
>
>
> I appreciate that I'm in the minority here. Yet, I'm still unconvinced.
>
>
>
> Best,
>
> Arnaud
>
>
>
> On Sat, Feb 27, 2021 at 12:39 AM Simon Peyton Jones <simonpj at microsoft.com>
> wrote:
>
> Generally, I'm not in favour in proposals which split extensions though:
> we already have so many extensions. Are the reasons for this split strong
> enough? I haven't had time to dig into the details.
>
> Arnaud, happily, you don’t have to dig very deep – just read the handful
> of posts following my recommendation.
>
>
>
> There seem to be two motivations.
>
>
>
>    1. There really are two orthogonal extensions, one for r.x notation,
>    and one for overloaded update.  Iavor likes the first but not the second.
>    Neil likes both.  Having separate extensions lets us experiment.
>
>
>
>    1. You suggest that changing the definition of RecordDotSyntax in a
>    subsequent release, e.g. by subsequently making it imply NoFieldSelectors,
>    would be fine. But it certainly imposes pain – some programs would stop
>    compiling.  The approach offered by this proposal avoids that problem.
>
>
>
> Yes, there are lots of extensions surrounding records: NoFieldSelectors,
> DuplicateRecordFields, NamedFieldPuns, DisambiguateRecordFields,
> RecordWildCards.  It may not be pretty to divide things up so fine, but
> it’s not new.
>
>
>
>
>
> If there are alternative suggestions, let’s hear them.
>
>
>
> Simon
>
>
>
> *From:* ghc-steering-committee <ghc-steering-committee-bounces at haskell.org>
> *On Behalf Of *Spiwack, Arnaud
> *Sent:* 26 February 2021 22:33
> *To:* Iavor Diatchki <iavor.diatchki at gmail.com>
> *Cc:* ghc-steering-committee <ghc-steering-committee at haskell.org>
> *Subject:* Re: [ghc-steering-committee] Modification to record dot syntax
> propsal
>
>
>
>
>
> I do think that  reusing the record update syntax for the overloaded
> monomorphic update is a mistake---it is not something I had noticed during
> our original discussion.
>
>
>
> This is the one reason I can see for cutting this extension in smaller
> pieces. But, then again, -XOverloadedRecordUpdate would be a fork-like
> extension.
>
>
>
> Generally, I'm not in favour in proposals which split extensions though:
> we already have so many extensions. Are the reasons for this split strong
> enough? I haven't had time to dig into the details.
>
>
>
> I'm not sure that not having the design of the proposal quite finalised is
> a good reason, extensions mutate in their first iterations, I don't think
> that it's a problem.
>
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20210302/1cf2be62/attachment-0001.html>

From rae at richarde.dev  Tue Mar  2 16:46:26 2021
From: rae at richarde.dev (Richard Eisenberg)
Date: Tue, 2 Mar 2021 16:46:26 +0000
Subject: [ghc-steering-committee] Modification to record dot syntax
 propsal
In-Reply-To: <VI1PR83MB0222FFB6BA71803975996928AD999@VI1PR83MB0222.EURPRD83.prod.outlook.com>
References: <VI1PR83MB0222BD8EC07924531D115264AD809@VI1PR83MB0222.EURPRD83.prod.outlook.com>
 <VI1PR83MB02221D0C9C4C75606C6F9FD3AD9D9@VI1PR83MB0222.EURPRD83.prod.outlook.com>
 <010f0177defd0abc-ddb39126-a38d-4cd7-b888-81acd5493dea-000000@us-east-2.amazonses.com>
 <CAGK9nur-Q+gft7qQodSCsaK4xnvpZoXwccaNYU4VNH_keoGEOA@mail.gmail.com>
 <CAH6fHQm1OFX+0i+CVwDC_m0HdQ=fnFN0uTtjdA9zifZV3ZVJoA@mail.gmail.com>
 <VI1PR83MB022233AD140B7B84463C45D4AD9D9@VI1PR83MB0222.EURPRD83.prod.outlook.com>
 <CAH6fHQ=1Hb5jZH3Yhr-BejT2j83++iykvCZPVYC9HYMueOmHZA@mail.gmail.com>
 <CAGK9nurtqxSTdeUya415wvdswjpTm9noUnLw+WMJv06ozhoETg@mail.gmail.com>
 <VI1PR83MB02228D79560C8A731F0116D5AD9A9@VI1PR83MB0222.EURPRD83.prod.outlook.com>
 <VI1PR83MB0222FFB6BA71803975996928AD999@VI1PR83MB0222.EURPRD83.prod.outlook.com>
Message-ID: <010f0177f3d56e4b-3c8a92a0-1511-47bc-8c63-3ec32620a52e-000000@us-east-2.amazonses.com>

I don't love having a feature that's completely unmentioned in the manual -- too much of a root to trip over. (For example, tooling may run into -XOverloadedRecordUpdate, but now has no official place to look to see what it is.) I'd be fine with a short section in the manual describing that an experimental -XOverloadedRecordUpdate extension exists, is subject to change, and is meant to roughly implement some part of some proposal. This can be done in just a few sentences, with a link to the proposal, but just being silent seems unhelpful to users.

With that small tweak, I'm quite happy to agree with the proposal here.

In terms of actual official GHC Steering Committee business, this proposal is really just about changing the name of the extension from -XRecordDotSyntax to -XOverloadedRecordDot. The implementation will simply fall short of the entire proposal. Is that accurate?

Richard

> On Mar 2, 2021, at 7:45 AM, Simon Peyton Jones via ghc-steering-committee <ghc-steering-committee at haskell.org> wrote:
> 
> Friends
>  
> Having consulted the authors, I propose that we do this:
>  
> Proceed with OverloadedRecordDot for 9.2, exactly as in the original proposal except for the extension name.
> Record update will remain exactly as now, in 9.2; that is, drawing back from the original proposal.
> There may be some code in 9.2 that allows overloaded record update, protected by OverloadedRecordUpdate, but not in the user manual, and not treated as an accepted proposal.   I don’t think we should ask the authors to remove it, and it will allow experimentation.
> Adam is leading on a revised record-update proposal. This will cover
> the tradeoffs between type-changing and non-type-changing update
> what the current record-update syntax stands for, and/or any new syntax
>  
> Is that acceptable to everyone?
>  
> Simon
>  
> From: ghc-steering-committee <ghc-steering-committee-bounces at haskell.org> On Behalf Of Simon Peyton Jones via ghc-steering-committee
> Sent: 01 March 2021 17:51
> To: Iavor Diatchki <iavor.diatchki at gmail.com>; Spiwack, Arnaud <arnaud.spiwack at tweag.io>
> Cc: ghc-steering-committee <ghc-steering-committee at haskell.org>
> Subject: Re: [ghc-steering-committee] Modification to record dot syntax propsal
>  
> I don't buy the argument of "this is already accepted", as I don't think many of us had noticed that part of the proposal (I certainly didn't), and I think we should be flexible enough to revisit previous decisions when we notice problems with them.
> 
> I agree in principle that we can revisit decisions.   But we have to be aware that it is potentially very discouraging for proposal authors to
> propose something,
> have it extensively debated (including this very point), 
> have it accepted,
> implement it,
> and then be told that the committee has changed its mind.  That’s pretty bad from their point of view.
>  
> Still, Adam is working on a new SetField proposal, so perhaps that’s a figleaf.  I’ll consult them.
> 
> Simon
>  
>  
> From: Iavor Diatchki <iavor.diatchki at gmail.com <mailto:iavor.diatchki at gmail.com>> 
> Sent: 01 March 2021 17:23
> To: Spiwack, Arnaud <arnaud.spiwack at tweag.io <mailto:arnaud.spiwack at tweag.io>>
> Cc: Simon Peyton Jones <simonpj at microsoft.com <mailto:simonpj at microsoft.com>>; ghc-steering-committee <ghc-steering-committee at haskell.org <mailto:ghc-steering-committee at haskell.org>>
> Subject: Re: [ghc-steering-committee] Modification to record dot syntax propsal
>  
> Hello,
> 
>  
> 
> I think there is a strong motivation to *at least* split the extensions:  with the current design, enabling the special `.` notation also *disables* type changing record update, which has nothing to do with the `.` notation.
> 
>  
> 
> My preference would be to:
> 
>   1. Split the original proposal into two parts: one about `.` notation, the other about record update (as suggested by this proposal)
> 
>   2. Treat the `.` notation part as accepted
> 
>   3. Require changes on the record update part, so that you don't have to choose between it and type changing record updates, which are quite useful, and I don't think we should aim for a Haskell without them.
> 
>  
> 
> I don't buy the argument of "this is already accepted", as I don't think many of us had noticed that part of the proposal (I certainly didn't), and I think we should be flexible enough to revisit previous decisions when we notice problems with them.
> 
>  
> 
> -Iavor
> 
>  
> 
>  
> 
>  
> 
> On Mon, Mar 1, 2021 at 1:40 AM Spiwack, Arnaud <arnaud.spiwack at tweag.io <mailto:arnaud.spiwack at tweag.io>> wrote:
> 
> Simon, all,
> 
>  
> 
> After reading more of the PR thread (in particular the fews posts after Simon's recommendation), I have to admit: I am thoroughly confused. I'm not sure that two people in that thread have the same motivation, end goal, or design in mind.
> 
>  
> 
> The motivations provided by the modified Alternatives section is not much more helpful (at the risk of caricaturing a little, it basically reads: “we made two extensions rather than one because we can”). Though it makes it clear that the end goal is to fold a bunch of record-related extensions into one glorious record extension (well, probably not fold them, but make a meta-extension that implies all the extensions that we've decided we like).
> 
>  
> 
> My starting point is that:
> 
> - Additional extensions have a maintenance cost
> 
> - Additional extensions impose a cognitive burden on their use
> 
> - I expect that a new extension will break my code in the next few releases.
> 
>  
> 
> Based on this, I don't care how this extension or the glorious record extension are named; but if we want to have two extensions we should have a serious reason. Right now, the one reason that I see (and Iavor raised), is that the update part of `RecordDotSyntax` is not backward compatible. Is it a strong enough reason? I don't know. The only data point that I can provide is that when we discussed the original proposal, I brought it up several times, and it didn't seem very important at the time (the conversation focused on other points of the proposal).
> 
>  
> 
> So, I'm still reluctant. I feel that, at the very least, the motivations are not well-enough articulated in the proposal (I'll make a comment to this effect on Github when I'm done composing this email).
> 
>  
> 
> I appreciate that I'm in the minority here. Yet, I'm still unconvinced.
> 
>  
> 
> Best,
> 
> Arnaud
> 
>  
> 
> On Sat, Feb 27, 2021 at 12:39 AM Simon Peyton Jones <simonpj at microsoft.com <mailto:simonpj at microsoft.com>> wrote:
> 
> Generally, I'm not in favour in proposals which split extensions though: we already have so many extensions. Are the reasons for this split strong enough? I haven't had time to dig into the details.
> 
> Arnaud, happily, you don’t have to dig very deep – just read the handful of posts following my recommendation.
>  
> There seem to be two motivations.
>  
> 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 <ghc-steering-committee-bounces at haskell.org <mailto:ghc-steering-committee-bounces at haskell.org>> On Behalf Of Spiwack, Arnaud
> Sent: 26 February 2021 22:33
> To: Iavor Diatchki <iavor.diatchki at gmail.com <mailto:iavor.diatchki at gmail.com>>
> Cc: ghc-steering-committee <ghc-steering-committee at haskell.org <mailto:ghc-steering-committee at haskell.org>>
> Subject: Re: [ghc-steering-committee] Modification to record dot syntax propsal
>  
>  
> 
> I do think that  reusing the record update syntax for the overloaded monomorphic update is a mistake---it is not something I had noticed during our original discussion.
> 
>  
> 
> This is the one reason I can see for cutting this extension in smaller pieces. But, then again, -XOverloadedRecordUpdate would be a fork-like extension.
> 
>  
> 
> Generally, I'm not in favour in proposals which split extensions though: we already have so many extensions. Are the reasons for this split strong enough? I haven't had time to dig into the details.
> 
>  
> 
> I'm not sure that not having the design of the proposal quite finalised is a good reason, extensions mutate in their first iterations, I don't think that it's a problem.
> 
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20210302/9e65e20c/attachment-0001.html>

From simonpj at microsoft.com  Wed Mar  3 16:04:36 2021
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Wed, 3 Mar 2021 16:04:36 +0000
Subject: [ghc-steering-committee] Modification to record dot syntax
 propsal
In-Reply-To: <010f0177f3d56e4b-3c8a92a0-1511-47bc-8c63-3ec32620a52e-000000@us-east-2.amazonses.com>
References: <VI1PR83MB0222BD8EC07924531D115264AD809@VI1PR83MB0222.EURPRD83.prod.outlook.com>
 <VI1PR83MB02221D0C9C4C75606C6F9FD3AD9D9@VI1PR83MB0222.EURPRD83.prod.outlook.com>
 <010f0177defd0abc-ddb39126-a38d-4cd7-b888-81acd5493dea-000000@us-east-2.amazonses.com>
 <CAGK9nur-Q+gft7qQodSCsaK4xnvpZoXwccaNYU4VNH_keoGEOA@mail.gmail.com>
 <CAH6fHQm1OFX+0i+CVwDC_m0HdQ=fnFN0uTtjdA9zifZV3ZVJoA@mail.gmail.com>
 <VI1PR83MB022233AD140B7B84463C45D4AD9D9@VI1PR83MB0222.EURPRD83.prod.outlook.com>
 <CAH6fHQ=1Hb5jZH3Yhr-BejT2j83++iykvCZPVYC9HYMueOmHZA@mail.gmail.com>
 <CAGK9nurtqxSTdeUya415wvdswjpTm9noUnLw+WMJv06ozhoETg@mail.gmail.com>
 <VI1PR83MB02228D79560C8A731F0116D5AD9A9@VI1PR83MB0222.EURPRD83.prod.outlook.com>
 <VI1PR83MB0222FFB6BA71803975996928AD999@VI1PR83MB0222.EURPRD83.prod.outlook.com>
 <010f0177f3d56e4b-3c8a92a0-1511-47bc-8c63-3ec32620a52e-000000@us-east-2.amazonses.com>
Message-ID: <VI1PR83MB02226708EB4258DBDC9F11D1AD989@VI1PR83MB0222.EURPRD83.prod.outlook.com>

In terms of actual official GHC Steering Committee business, this proposal is really just about changing the name of the extension from -XRecordDotSyntax to -XOverloadedRecordDot. The implementation will simply fall short of the entire proposal. Is that accurate?

Not quite.

  *   It replaces RecordDotSyntax with two separate extensions, OverloadedRecordDot and OverloadedRecordUpdate.
  *   The second, OverloadedRecordUpdate would be advertised as experimental and subject to change. (I'm totally happy with having it in the user manual if that's what everyone is happy with.)
  *   If you switch on experimental OverloadedRecordUpdate, you get the whole proposal, with no falling short. But the committee has expressed some second thoughts about update, hence advertising it as experimental.
OK?  Only Richard, Iavor, Joachim, Arnaud have said anything on this thread.   I'm taking silence as assent ... yell by the end of today if you are unhappy.  I'd like to communicate with the authors.

Simon

From: Richard Eisenberg <rae at richarde.dev>
Sent: 02 March 2021 16:46
To: Simon Peyton Jones <simonpj at microsoft.com>
Cc: ghc-steering-committee <ghc-steering-committee at haskell.org>
Subject: Re: [ghc-steering-committee] Modification to record dot syntax propsal

I don't love having a feature that's completely unmentioned in the manual -- too much of a root to trip over. (For example, tooling may run into -XOverloadedRecordUpdate, but now has no official place to look to see what it is.) I'd be fine with a short section in the manual describing that an experimental -XOverloadedRecordUpdate extension exists, is subject to change, and is meant to roughly implement some part of some proposal. This can be done in just a few sentences, with a link to the proposal, but just being silent seems unhelpful to users.

With that small tweak, I'm quite happy to agree with the proposal here.

In terms of actual official GHC Steering Committee business, this proposal is really just about changing the name of the extension from -XRecordDotSyntax to -XOverloadedRecordDot. The implementation will simply fall short of the entire proposal. Is that accurate?

Richard


On Mar 2, 2021, at 7:45 AM, Simon Peyton Jones via ghc-steering-committee <ghc-steering-committee at haskell.org<mailto:ghc-steering-committee at haskell.org>> wrote:

Friends

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


  *   Proceed with OverloadedRecordDot for 9.2, exactly as in the original proposal except for the extension name.
  *   Record update will remain exactly as now, in 9.2; that is, drawing back from the original proposal.
  *   There may be some code in 9.2 that allows overloaded record update, protected by OverloadedRecordUpdate, but not in the user manual, and not treated as an accepted proposal.   I don't think we should ask the authors to remove it, and it will allow experimentation.
  *   Adam is leading on a revised record-update proposal. This will cover

     *   the tradeoffs between type-changing and non-type-changing update
     *   what the current record-update syntax stands for, and/or any new syntax

Is that acceptable to everyone?

Simon

From: ghc-steering-committee <ghc-steering-committee-bounces at haskell.org<mailto:ghc-steering-committee-bounces at haskell.org>> On Behalf Of Simon Peyton Jones via ghc-steering-committee
Sent: 01 March 2021 17:51
To: Iavor Diatchki <iavor.diatchki at gmail.com<mailto:iavor.diatchki at gmail.com>>; Spiwack, Arnaud <arnaud.spiwack at tweag.io<mailto:arnaud.spiwack at tweag.io>>
Cc: ghc-steering-committee <ghc-steering-committee at haskell.org<mailto:ghc-steering-committee at haskell.org>>
Subject: Re: [ghc-steering-committee] Modification to record dot syntax propsal

I don't buy the argument of "this is already accepted", as I don't think many of us had noticed that part of the proposal (I certainly didn't), and I think we should be flexible enough to revisit previous decisions when we notice problems with them.
I agree in principle that we can revisit decisions.   But we have to be aware that it is potentially very discouraging for proposal authors to

*         propose something,

*         have it extensively debated (including this very point),

*         have it accepted,

*         implement it,
and then be told that the committee has changed its mind.  That's pretty bad from their point of view.

Still, Adam is working on a new SetField proposal, so perhaps that's a figleaf.  I'll consult them.

Simon


From: Iavor Diatchki <iavor.diatchki at gmail.com<mailto:iavor.diatchki at gmail.com>>
Sent: 01 March 2021 17:23
To: Spiwack, Arnaud <arnaud.spiwack at tweag.io<mailto:arnaud.spiwack at tweag.io>>
Cc: Simon Peyton Jones <simonpj at microsoft.com<mailto:simonpj at microsoft.com>>; ghc-steering-committee <ghc-steering-committee at haskell.org<mailto:ghc-steering-committee at haskell.org>>
Subject: Re: [ghc-steering-committee] Modification to record dot syntax propsal

Hello,

I think there is a strong motivation to *at least* split the extensions:  with the current design, enabling the special `.` notation also *disables* type changing record update, which has nothing to do with the `.` notation.

My preference would be to:
  1. Split the original proposal into two parts: one about `.` notation, the other about record update (as suggested by this proposal)
  2. Treat the `.` notation part as accepted
  3. Require changes on the record update part, so that you don't have to choose between it and type changing record updates, which are quite useful, and I don't think we should aim for a Haskell without them.

I don't buy the argument of "this is already accepted", as I don't think many of us had noticed that part of the proposal (I certainly didn't), and I think we should be flexible enough to revisit previous decisions when we notice problems with them.

-Iavor



On Mon, Mar 1, 2021 at 1:40 AM Spiwack, Arnaud <arnaud.spiwack at tweag.io<mailto:arnaud.spiwack at tweag.io>> wrote:
Simon, all,

After reading more of the PR thread (in particular the fews posts after Simon's recommendation), I have to admit: I am thoroughly confused. I'm not sure that two people in that thread have the same motivation, end goal, or design in mind.

The motivations provided by the modified Alternatives section is not much more helpful (at the risk of caricaturing a little, it basically reads: "we made two extensions rather than one because we can"). Though it makes it clear that the end goal is to fold a bunch of record-related extensions into one glorious record extension (well, probably not fold them, but make a meta-extension that implies all the extensions that we've decided we like).

My starting point is that:
- Additional extensions have a maintenance cost
- Additional extensions impose a cognitive burden on their use
- I expect that a new extension will break my code in the next few releases.

Based on this, I don't care how this extension or the glorious record extension are named; but if we want to have two extensions we should have a serious reason. Right now, the one reason that I see (and Iavor raised), is that the update part of `RecordDotSyntax` is not backward compatible. Is it a strong enough reason? I don't know. The only data point that I can provide is that when we discussed the original proposal, I brought it up several times, and it didn't seem very important at the time (the conversation focused on other points of the proposal).

So, I'm still reluctant. I feel that, at the very least, the motivations are not well-enough articulated in the proposal (I'll make a comment to this effect on Github when I'm done composing this email).

I appreciate that I'm in the minority here. Yet, I'm still unconvinced.

Best,
Arnaud

On Sat, Feb 27, 2021 at 12:39 AM Simon Peyton Jones <simonpj at microsoft.com<mailto:simonpj at microsoft.com>> wrote:
Generally, I'm not in favour in proposals which split extensions though: we already have so many extensions. Are the reasons for this split strong enough? I haven't had time to dig into the details.
Arnaud, happily, you don't have to dig very deep - just read the handful of posts following my recommendation.

There seem to be two motivations.


  1.  There really are two orthogonal extensions, one for r.x notation, and one for overloaded update.  Iavor likes the first but not the second.  Neil likes both.  Having separate extensions lets us experiment.


  1.  You suggest that changing the definition of RecordDotSyntax in a subsequent release, e.g. by subsequently making it imply NoFieldSelectors, would be fine. But it certainly imposes pain - some programs would stop compiling.  The approach offered by this proposal avoids that problem.

Yes, there are lots of extensions surrounding records: NoFieldSelectors, DuplicateRecordFields, NamedFieldPuns, DisambiguateRecordFields, RecordWildCards.  It may not be pretty to divide things up so fine, but it's not new.


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

Simon

From: ghc-steering-committee <ghc-steering-committee-bounces at haskell.org<mailto:ghc-steering-committee-bounces at haskell.org>> On Behalf Of Spiwack, Arnaud
Sent: 26 February 2021 22:33
To: Iavor Diatchki <iavor.diatchki at gmail.com<mailto:iavor.diatchki at gmail.com>>
Cc: ghc-steering-committee <ghc-steering-committee at haskell.org<mailto:ghc-steering-committee at haskell.org>>
Subject: Re: [ghc-steering-committee] Modification to record dot syntax propsal


I do think that  reusing the record update syntax for the overloaded monomorphic update is a mistake---it is not something I had noticed during our original discussion.

This is the one reason I can see for cutting this extension in smaller pieces. But, then again, -XOverloadedRecordUpdate would be a fork-like extension.

Generally, I'm not in favour in proposals which split extensions though: we already have so many extensions. Are the reasons for this split strong enough? I haven't had time to dig into the details.

I'm not sure that not having the design of the proposal quite finalised is a good reason, extensions mutate in their first iterations, I don't think that it's a problem.
_______________________________________________
ghc-steering-committee mailing list
ghc-steering-committee at haskell.org<mailto:ghc-steering-committee at haskell.org>
https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committee&data=04%7C01%7Csimonpj%40microsoft.com%7Ccf65595be24d42cab2ca08d8dd9ab96c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637503003928846093%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=3goska4aw00W0GxIvfDOj3JCdEaQ0CB8Zowb1u5RbMo%3D&reserved=0>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20210303/ba8f2aaa/attachment-0001.html>

From iavor.diatchki at gmail.com  Wed Mar  3 16:12:51 2021
From: iavor.diatchki at gmail.com (Iavor Diatchki)
Date: Wed, 3 Mar 2021 08:12:51 -0800
Subject: [ghc-steering-committee] Modification to record dot syntax
	propsal
In-Reply-To: <VI1PR83MB02226708EB4258DBDC9F11D1AD989@VI1PR83MB0222.EURPRD83.prod.outlook.com>
References: <VI1PR83MB0222BD8EC07924531D115264AD809@VI1PR83MB0222.EURPRD83.prod.outlook.com>
 <VI1PR83MB02221D0C9C4C75606C6F9FD3AD9D9@VI1PR83MB0222.EURPRD83.prod.outlook.com>
 <010f0177defd0abc-ddb39126-a38d-4cd7-b888-81acd5493dea-000000@us-east-2.amazonses.com>
 <CAGK9nur-Q+gft7qQodSCsaK4xnvpZoXwccaNYU4VNH_keoGEOA@mail.gmail.com>
 <CAH6fHQm1OFX+0i+CVwDC_m0HdQ=fnFN0uTtjdA9zifZV3ZVJoA@mail.gmail.com>
 <VI1PR83MB022233AD140B7B84463C45D4AD9D9@VI1PR83MB0222.EURPRD83.prod.outlook.com>
 <CAH6fHQ=1Hb5jZH3Yhr-BejT2j83++iykvCZPVYC9HYMueOmHZA@mail.gmail.com>
 <CAGK9nurtqxSTdeUya415wvdswjpTm9noUnLw+WMJv06ozhoETg@mail.gmail.com>
 <VI1PR83MB02228D79560C8A731F0116D5AD9A9@VI1PR83MB0222.EURPRD83.prod.outlook.com>
 <VI1PR83MB0222FFB6BA71803975996928AD999@VI1PR83MB0222.EURPRD83.prod.outlook.com>
 <010f0177f3d56e4b-3c8a92a0-1511-47bc-8c63-3ec32620a52e-000000@us-east-2.amazonses.com>
 <VI1PR83MB02226708EB4258DBDC9F11D1AD989@VI1PR83MB0222.EURPRD83.prod.outlook.com>
Message-ID: <CAGK9nuo=VZ-1cSqD7VFjFoA3jLHy==9H6zC5G2_E2mgQo3iSJA@mail.gmail.com>

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 <ghc-steering-committee at haskell.org> wrote:

> In terms of actual official GHC Steering Committee business, this proposal
> is really just about changing the name of the extension from
> -XRecordDotSyntax to -XOverloadedRecordDot. The implementation will simply
> fall short of the entire proposal. Is that accurate?
>
>
>
> Not quite.
>
>    - It replaces RecordDotSyntax with two separate extensions,
>    OverloadedRecordDot and OverloadedRecordUpdate.
>    - The second, OverloadedRecordUpdate would be advertised as
>    experimental and subject to change. (I’m totally happy with having it in
>    the user manual if that’s what everyone is happy with.)
>    - If you switch on experimental OverloadedRecordUpdate, you get the
>    whole proposal, with no falling short. But the committee has expressed some
>    second thoughts about update, hence advertising it as experimental.
>
> OK?  Only Richard, Iavor, Joachim, Arnaud have said anything on this
> thread.   I’m taking silence as assent … yell by the end of today if you
> are unhappy.  I’d like to communicate with the authors.
>
>
>
> Simon
>
>
>
> *From:* Richard Eisenberg <rae at richarde.dev>
> *Sent:* 02 March 2021 16:46
> *To:* Simon Peyton Jones <simonpj at microsoft.com>
> *Cc:* ghc-steering-committee <ghc-steering-committee at haskell.org>
> *Subject:* Re: [ghc-steering-committee] Modification to record dot syntax
> propsal
>
>
>
> I don't love having a feature that's completely unmentioned in the manual
> -- too much of a root to trip over. (For example, tooling may run into
> -XOverloadedRecordUpdate, but now has no official place to look to see what
> it is.) I'd be fine with a short section in the manual describing that an
> experimental -XOverloadedRecordUpdate extension exists, is subject to
> change, and is meant to roughly implement some part of some proposal. This
> can be done in just a few sentences, with a link to the proposal, but just
> being silent seems unhelpful to users.
>
>
>
> With that small tweak, I'm quite happy to agree with the proposal here.
>
>
>
> In terms of actual official GHC Steering Committee business, this proposal
> is really just about changing the name of the extension from
> -XRecordDotSyntax to -XOverloadedRecordDot. The implementation will simply
> fall short of the entire proposal. Is that accurate?
>
>
>
> Richard
>
>
>
> On Mar 2, 2021, at 7:45 AM, Simon Peyton Jones via ghc-steering-committee <
> ghc-steering-committee at haskell.org> wrote:
>
>
>
> Friends
>
>
>
> Having consulted the authors, I propose that we do this:
>
>
>
>    - Proceed with OverloadedRecordDot for 9.2, exactly as in the original
>    proposal except for the extension name.
>    - Record update will remain exactly as now, in 9.2; that is, drawing
>    back from the original proposal.
>    - There may be some *code* in 9.2 that allows overloaded record
>    update, protected by OverloadedRecordUpdate, but not in the user manual,
>    and not treated as an accepted proposal.   I don’t think we should ask the
>    authors to remove it, and it will allow experimentation.
>    - Adam is leading on a revised record-update proposal. This will cover
>
>
>    - the tradeoffs between type-changing and non-type-changing update
>       - what the current record-update syntax stands for, and/or any new
>       syntax
>
>
>
> Is that acceptable to everyone?
>
>
>
> Simon
>
>
>
> *From:* ghc-steering-committee <ghc-steering-committee-bounces at haskell.org
> > *On Behalf Of *Simon Peyton Jones via ghc-steering-committee
> *Sent:* 01 March 2021 17:51
> *To:* Iavor Diatchki <iavor.diatchki at gmail.com>; Spiwack, Arnaud <
> arnaud.spiwack at tweag.io>
> *Cc:* ghc-steering-committee <ghc-steering-committee at haskell.org>
> *Subject:* Re: [ghc-steering-committee] Modification to record dot syntax
> propsal
>
>
>
> I don't buy the argument of "this is already accepted", as I don't think
> many of us had noticed that part of the proposal (I certainly didn't), and
> I think we should be flexible enough to revisit previous decisions when we
> notice problems with them.
>
> I agree in principle that we can revisit decisions.   But we have to be
> aware that it is potentially very discouraging for proposal authors to
>
> ·         propose something,
>
> ·         have it *extensively* debated (including this very point),
>
> ·         have it accepted,
>
> ·         implement it,
>
> and then be told that the committee has changed its mind.  That’s pretty
> bad from their point of view.
>
>
>
> Still, Adam is working on a new SetField proposal, so perhaps that’s a
> figleaf.  I’ll consult them.
>
>
> Simon
>
>
>
>
>
> *From:* Iavor Diatchki <iavor.diatchki at gmail.com>
> *Sent:* 01 March 2021 17:23
> *To:* Spiwack, Arnaud <arnaud.spiwack at tweag.io>
> *Cc:* Simon Peyton Jones <simonpj at microsoft.com>; ghc-steering-committee <
> ghc-steering-committee at haskell.org>
> *Subject:* Re: [ghc-steering-committee] Modification to record dot syntax
> propsal
>
>
>
> Hello,
>
>
>
> I think there is a strong motivation to *at least* split the extensions:
> with the current design, enabling the special `.` notation also *disables*
> type changing record update, which has nothing to do with the `.` notation.
>
>
>
> My preference would be to:
>
>   1. Split the original proposal into two parts: one about `.` notation,
> the other about record update (as suggested by this proposal)
>
>   2. Treat the `.` notation part as accepted
>
>   3. Require changes on the record update part, so that you don't have to
> choose between it and type changing record updates, which are quite useful,
> and I don't think we should aim for a Haskell without them.
>
>
>
> I don't buy the argument of "this is already accepted", as I don't think
> many of us had noticed that part of the proposal (I certainly didn't), and
> I think we should be flexible enough to revisit previous decisions when we
> notice problems with them.
>
>
>
> -Iavor
>
>
>
>
>
>
>
> On Mon, Mar 1, 2021 at 1:40 AM Spiwack, Arnaud <arnaud.spiwack at tweag.io>
> wrote:
>
> Simon, all,
>
>
>
> After reading more of the PR thread (in particular the fews posts after
> Simon's recommendation), I have to admit: I am thoroughly confused. I'm not
> sure that two people in that thread have the same motivation, end goal, or
> design in mind.
>
>
>
> The motivations provided by the modified *Alternatives* section is not
> much more helpful (at the risk of caricaturing a little, it basically
> reads: “we made two extensions rather than one because we can”). Though it
> makes it clear that the end goal is to fold a bunch of record-related
> extensions into one glorious record extension (well, probably not fold
> them, but make a meta-extension that implies all the extensions that we've
> decided we like).
>
>
>
> My starting point is that:
>
> - Additional extensions have a maintenance cost
>
> - Additional extensions impose a cognitive burden on their use
>
> - I expect that a new extension will break my code in the next few
> releases.
>
>
>
> Based on this, I don't care how this extension or the glorious record
> extension are named; but if we want to have two extensions we should have a
> serious reason. Right now, the one reason that I see (and Iavor raised), is
> that the update part of `RecordDotSyntax` is not backward compatible. Is it
> a strong enough reason? I don't know. The only data point that I can
> provide is that when we discussed the original proposal, I brought it up
> several times, and it didn't seem very important at the time (the
> conversation focused on other points of the proposal).
>
>
>
> So, I'm still reluctant. I feel that, at the very least, the motivations
> are not well-enough articulated in the proposal (I'll make a comment to
> this effect on Github when I'm done composing this email).
>
>
>
> I appreciate that I'm in the minority here. Yet, I'm still unconvinced.
>
>
>
> Best,
>
> Arnaud
>
>
>
> On Sat, Feb 27, 2021 at 12:39 AM Simon Peyton Jones <simonpj at microsoft.com>
> wrote:
>
> Generally, I'm not in favour in proposals which split extensions though:
> we already have so many extensions. Are the reasons for this split strong
> enough? I haven't had time to dig into the details.
>
> Arnaud, happily, you don’t have to dig very deep – just read the handful
> of posts following my recommendation.
>
>
>
> There seem to be two motivations.
>
>
>
>    1. There really are two orthogonal extensions, one for r.x notation,
>    and one for overloaded update.  Iavor likes the first but not the second.
>    Neil likes both.  Having separate extensions lets us experiment.
>
>
>
>    1. You suggest that changing the definition of RecordDotSyntax in a
>    subsequent release, e.g. by subsequently making it imply NoFieldSelectors,
>    would be fine. But it certainly imposes pain – some programs would stop
>    compiling.  The approach offered by this proposal avoids that problem.
>
>
>
> Yes, there are lots of extensions surrounding records: NoFieldSelectors,
> DuplicateRecordFields, NamedFieldPuns, DisambiguateRecordFields,
> RecordWildCards.  It may not be pretty to divide things up so fine, but
> it’s not new.
>
>
>
>
>
> If there are alternative suggestions, let’s hear them.
>
>
>
> Simon
>
>
>
> *From:* ghc-steering-committee <ghc-steering-committee-bounces at haskell.org
> > *On Behalf Of *Spiwack, Arnaud
> *Sent:* 26 February 2021 22:33
> *To:* Iavor Diatchki <iavor.diatchki at gmail.com>
> *Cc:* ghc-steering-committee <ghc-steering-committee at haskell.org>
> *Subject:* Re: [ghc-steering-committee] Modification to record dot syntax
> propsal
>
>
>
>
>
> I do think that  reusing the record update syntax for the overloaded
> monomorphic update is a mistake---it is not something I had noticed during
> our original discussion.
>
>
>
> This is the one reason I can see for cutting this extension in smaller
> pieces. But, then again, -XOverloadedRecordUpdate would be a fork-like
> extension.
>
>
>
> Generally, I'm not in favour in proposals which split extensions though:
> we already have so many extensions. Are the reasons for this split strong
> enough? I haven't had time to dig into the details.
>
>
>
> I'm not sure that not having the design of the proposal quite finalised is
> a good reason, extensions mutate in their first iterations, I don't think
> that it's a problem.
>
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committee&data=04%7C01%7Csimonpj%40microsoft.com%7Ccf65595be24d42cab2ca08d8dd9ab96c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637503003928846093%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=3goska4aw00W0GxIvfDOj3JCdEaQ0CB8Zowb1u5RbMo%3D&reserved=0>
>
>
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20210303/84e7e123/attachment-0001.html>

From eric at seidel.io  Thu Mar  4 01:17:22 2021
From: eric at seidel.io (Eric Seidel)
Date: Wed, 03 Mar 2021 20:17:22 -0500
Subject: [ghc-steering-committee]
 =?utf-8?q?Modification_to_record_dot_syn?= =?utf-8?q?tax_propsal?=
In-Reply-To: <VI1PR83MB02226708EB4258DBDC9F11D1AD989@VI1PR83MB0222.EURPRD83.prod.outlook.com>
References: <VI1PR83MB0222BD8EC07924531D115264AD809@VI1PR83MB0222.EURPRD83.prod.outlook.com>
 <VI1PR83MB02221D0C9C4C75606C6F9FD3AD9D9@VI1PR83MB0222.EURPRD83.prod.outlook.com>
 <010f0177defd0abc-ddb39126-a38d-4cd7-b888-81acd5493dea-000000@us-east-2.amazonses.com>
 <CAGK9nur-Q+gft7qQodSCsaK4xnvpZoXwccaNYU4VNH_keoGEOA@mail.gmail.com>
 <CAH6fHQm1OFX+0i+CVwDC_m0HdQ=fnFN0uTtjdA9zifZV3ZVJoA@mail.gmail.com>
 <VI1PR83MB022233AD140B7B84463C45D4AD9D9@VI1PR83MB0222.EURPRD83.prod.outlook.com>
 <CAH6fHQ=1Hb5jZH3Yhr-BejT2j83++iykvCZPVYC9HYMueOmHZA@mail.gmail.com>
 <CAGK9nurtqxSTdeUya415wvdswjpTm9noUnLw+WMJv06ozhoETg@mail.gmail.com>
 <VI1PR83MB02228D79560C8A731F0116D5AD9A9@VI1PR83MB0222.EURPRD83.prod.outlook.com>
 <VI1PR83MB0222FFB6BA71803975996928AD999@VI1PR83MB0222.EURPRD83.prod.outlook.com>
 <010f0177f3d56e4b-3c8a92a0-1511-47bc-8c63-3ec32620a52e-000000@us-east-2.amazonses.com>
 <VI1PR83MB02226708EB4258DBDC9F11D1AD989@VI1PR83MB0222.EURPRD83.prod.outlook.com>
Message-ID: <26d2c4be-cef7-4b76-b641-d0ec8ba2fb85@www.fastmail.com>

I explicitly assent to accepting this revision. I agree with Arnaud and Richard that the motivation feels lacking, but we have enough precedent for fine-grained extensions that I feel comfortable with this as an implementation strategy.

On Wed, Mar 3, 2021, at 11:04, Simon Peyton Jones via ghc-steering-committee wrote:
>  
> In terms of actual official GHC Steering Committee business, this 
> proposal is really just about changing the name of the extension from 
> -XRecordDotSyntax to -XOverloadedRecordDot. The implementation will 
> simply fall short of the entire proposal. Is that accurate?
> 
>  
> 
> Not quite. 
> 
>  * It replaces RecordDotSyntax with two separate extensions, 
> OverloadedRecordDot and OverloadedRecordUpdate.
>  * The second, OverloadedRecordUpdate would be advertised as 
> experimental and subject to change. (I’m totally happy with having it 
> in the user manual if that’s what everyone is happy with.)
>  * If you switch on experimental OverloadedRecordUpdate, you get the 
> whole proposal, with no falling short. But the committee has expressed 
> some second thoughts about update, hence advertising it as experimental.
> OK?  Only Richard, Iavor, Joachim, Arnaud have said anything on this 
> thread.   I’m taking silence as assent … yell by the end of today if 
> you are unhappy.  I’d like to communicate with the authors.  
> 
>  
> 
> Simon
> 
>  
> 
> *From:* Richard Eisenberg <rae at richarde.dev> 
> *Sent:* 02 March 2021 16:46
> *To:* Simon Peyton Jones <simonpj at microsoft.com>
> *Cc:* ghc-steering-committee <ghc-steering-committee at haskell.org>
> *Subject:* Re: [ghc-steering-committee] Modification to record dot 
> syntax propsal
> 
>  
> 
> I don't love having a feature that's completely unmentioned in the 
> manual -- too much of a root to trip over. (For example, tooling may 
> run into -XOverloadedRecordUpdate, but now has no official place to 
> look to see what it is.) I'd be fine with a short section in the manual 
> describing that an experimental -XOverloadedRecordUpdate extension 
> exists, is subject to change, and is meant to roughly implement some 
> part of some proposal. This can be done in just a few sentences, with a 
> link to the proposal, but just being silent seems unhelpful to users.
> 
>  
> 
> With that small tweak, I'm quite happy to agree with the proposal here.
> 
>  
> 
> In terms of actual official GHC Steering Committee business, this 
> proposal is really just about changing the name of the extension from 
> -XRecordDotSyntax to -XOverloadedRecordDot. The implementation will 
> simply fall short of the entire proposal. Is that accurate?
> 
>  
> 
> Richard
> 
> 
> 
> 
> > On Mar 2, 2021, at 7:45 AM, Simon Peyton Jones via ghc-steering-committee <ghc-steering-committee at haskell.org> wrote:
> 
> >  
> 
> > Friends
> 
> >  
> 
> > Having consulted the authors, I propose that we do this:
> 
> >  
> 
> >  * Proceed with OverloadedRecordDot for 9.2, exactly as in the original proposal except for the extension name.
> >  * Record update will remain exactly as now, in 9.2; that is, drawing back from the original proposal.
> >  * There may be some *code* in 9.2 that allows overloaded record update, protected by OverloadedRecordUpdate, but not in the user manual, and not treated as an accepted proposal.   I don’t think we should ask the authors to remove it, and it will allow experimentation.
> >  * Adam is leading on a revised record-update proposal. This will cover
> >    * the tradeoffs between type-changing and non-type-changing update
> >    * what the current record-update syntax stands for, and/or any new syntax
> >  
> 
> > Is that acceptable to everyone?
> 
> >  
> 
> > Simon
> 
> >  
> 
> > *From:* ghc-steering-committee <ghc-steering-committee-bounces at haskell.org> *On Behalf Of *Simon Peyton Jones via ghc-steering-committee
> > *Sent:* 01 March 2021 17:51
> > *To:* Iavor Diatchki <iavor.diatchki at gmail.com>; Spiwack, Arnaud <arnaud.spiwack at tweag.io>
> > *Cc:* ghc-steering-committee <ghc-steering-committee at haskell.org>
> > *Subject:* Re: [ghc-steering-committee] Modification to record dot syntax propsal
> 
> >  
> 
> > I don't buy the argument of "this is already accepted", as I don't think many of us had noticed that part of the proposal (I certainly didn't), and I think we should be flexible enough to revisit previous decisions when we notice problems with them.
> 
> > I agree in principle that we can revisit decisions.   But we have to be aware that it is potentially very discouraging for proposal authors to
> 
> > ·         propose something,
> 
> > ·         have it *extensively* debated (including this very point), 
> 
> > ·         have it accepted,
> 
> > ·         implement it,
> 
> > and then be told that the committee has changed its mind.  That’s pretty bad from their point of view.
> 
> >  
> 
> > Still, Adam is working on a new SetField proposal, so perhaps that’s a figleaf.  I’ll consult them.
> 
> > 
> > Simon
> 
> >  
> 
> >  
> 
> > *From:* Iavor Diatchki <iavor.diatchki at gmail.com> 
> > *Sent:* 01 March 2021 17:23
> > *To:* Spiwack, Arnaud <arnaud.spiwack at tweag.io>
> > *Cc:* Simon Peyton Jones <simonpj at microsoft.com>; ghc-steering-committee <ghc-steering-committee at haskell.org>
> > *Subject:* Re: [ghc-steering-committee] Modification to record dot syntax propsal
> 
> >  
> 
> > Hello,
> 
> >  
> 
> > I think there is a strong motivation to *at least* split the extensions:  with the current design, enabling the special `.` notation also *disables* type changing record update, which has nothing to do with the `.` notation.
> 
> >  
> 
> > My preference would be to:
> 
> >   1. Split the original proposal into two parts: one about `.` notation, the other about record update (as suggested by this proposal)
> 
> >   2. Treat the `.` notation part as accepted
> 
> >   3. Require changes on the record update part, so that you don't have to choose between it and type changing record updates, which are quite useful, and I don't think we should aim for a Haskell without them.
> 
> >  
> 
> > I don't buy the argument of "this is already accepted", as I don't think many of us had noticed that part of the proposal (I certainly didn't), and I think we should be flexible enough to revisit previous decisions when we notice problems with them.
> 
> >  
> 
> > -Iavor
> 
> >  
> 
> >  
> 
> >  
> 
> > On Mon, Mar 1, 2021 at 1:40 AM Spiwack, Arnaud <arnaud.spiwack at tweag.io> wrote:
> 
> >> Simon, all,
> 
> >>  
> 
> >> After reading more of the PR thread (in particular the fews posts after Simon's recommendation), I have to admit: I am thoroughly confused. I'm not sure that two people in that thread have the same motivation, end goal, or design in mind.
> 
> >>  
> 
> >> The motivations provided by the modified *Alternatives* section is not much more helpful (at the risk of caricaturing a little, it basically reads: “we made two extensions rather than one because we can”). Though it makes it clear that the end goal is to fold a bunch of record-related extensions into one glorious record extension (well, probably not fold them, but make a meta-extension that implies all the extensions that we've decided we like).
> 
> >>  
> 
> >> My starting point is that:
> 
> >> - Additional extensions have a maintenance cost
> 
> >> - Additional extensions impose a cognitive burden on their use
> 
> >> - I expect that a new extension will break my code in the next few releases.
> 
> >>  
> 
> >> Based on this, I don't care how this extension or the glorious record extension are named; but if we want to have two extensions we should have a serious reason. Right now, the one reason that I see (and Iavor raised), is that the update part of `RecordDotSyntax` is not backward compatible. Is it a strong enough reason? I don't know. The only data point that I can provide is that when we discussed the original proposal, I brought it up several times, and it didn't seem very important at the time (the conversation focused on other points of the proposal).
> 
> >>  
> 
> >> So, I'm still reluctant. I feel that, at the very least, the motivations are not well-enough articulated in the proposal (I'll make a comment to this effect on Github when I'm done composing this email).
> 
> >>  
> 
> >> I appreciate that I'm in the minority here. Yet, I'm still unconvinced.
> 
> >>  
> 
> >> Best,
> 
> >> Arnaud
> 
> >>  
> 
> >> On Sat, Feb 27, 2021 at 12:39 AM Simon Peyton Jones <simonpj at microsoft.com> wrote:
> 
> >>> Generally, I'm not in favour in proposals which split extensions though: we already have so many extensions. Are the reasons for this split strong enough? I haven't had time to dig into the details.
> 
> >>> Arnaud, happily, you don’t have to dig very deep – just read the handful of posts following my recommendation.
> 
> >>>  
> 
> >>> There seem to be two motivations.
> 
> >>>  
> 
> >>>  1. There really are two orthogonal extensions, one for r.x notation, and one for overloaded update.  Iavor likes the first but not the second.  Neil likes both.  Having separate extensions lets us experiment.
> >>>  
> 
> >>>  1. You suggest that changing the definition of RecordDotSyntax in a subsequent release, e.g. by subsequently making it imply NoFieldSelectors, would be fine. But it certainly imposes pain – some programs would stop compiling.  The approach offered by this proposal avoids that problem.
> >>>  
> 
> >>> Yes, there are lots of extensions surrounding records: NoFieldSelectors, DuplicateRecordFields, NamedFieldPuns, DisambiguateRecordFields, RecordWildCards.  It may not be pretty to divide things up so fine, but it’s not new.
> 
> >>>  
> 
> >>>  
> 
> >>> If there are alternative suggestions, let’s hear them.
> 
> >>>  
> 
> >>> Simon
> 
> >>>  
> 
> >>> *From:* ghc-steering-committee <ghc-steering-committee-bounces at haskell.org> *On Behalf Of *Spiwack, Arnaud
> >>> *Sent:* 26 February 2021 22:33
> >>> *To:* Iavor Diatchki <iavor.diatchki at gmail.com>
> >>> *Cc:* ghc-steering-committee <ghc-steering-committee at haskell.org>
> >>> *Subject:* Re: [ghc-steering-committee] Modification to record dot syntax propsal
> 
> >>>  
> 
> >>>  
> 
> >>>> I do think that  reusing the record update syntax for the overloaded monomorphic update is a mistake---it is not something I had noticed during our original discussion.
> 
> >>>  
> 
> >>> This is the one reason I can see for cutting this extension in smaller pieces. But, then again, -XOverloadedRecordUpdate would be a fork-like extension.
> 
> >>>  
> 
> >>> Generally, I'm not in favour in proposals which split extensions though: we already have so many extensions. Are the reasons for this split strong enough? I haven't had time to dig into the details.
> 
> >>>  
> 
> >>> I'm not sure that not having the design of the proposal quite finalised is a good reason, extensions mutate in their first iterations, I don't think that it's a problem.
> 
> > _______________________________________________
> > ghc-steering-committee mailing list
> > ghc-steering-committee at haskell.org
> > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committee&data=04%7C01%7Csimonpj%40microsoft.com%7Ccf65595be24d42cab2ca08d8dd9ab96c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637503003928846093%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=3goska4aw00W0GxIvfDOj3JCdEaQ0CB8Zowb1u5RbMo%3D&reserved=0>
> 
>  
> 
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>

From arnaud.spiwack at tweag.io  Thu Mar  4 09:22:16 2021
From: arnaud.spiwack at tweag.io (Spiwack, Arnaud)
Date: Thu, 4 Mar 2021 10:22:16 +0100
Subject: [ghc-steering-committee] Modification to record dot syntax
	propsal
In-Reply-To: <26d2c4be-cef7-4b76-b641-d0ec8ba2fb85@www.fastmail.com>
References: <VI1PR83MB0222BD8EC07924531D115264AD809@VI1PR83MB0222.EURPRD83.prod.outlook.com>
 <VI1PR83MB02221D0C9C4C75606C6F9FD3AD9D9@VI1PR83MB0222.EURPRD83.prod.outlook.com>
 <010f0177defd0abc-ddb39126-a38d-4cd7-b888-81acd5493dea-000000@us-east-2.amazonses.com>
 <CAGK9nur-Q+gft7qQodSCsaK4xnvpZoXwccaNYU4VNH_keoGEOA@mail.gmail.com>
 <CAH6fHQm1OFX+0i+CVwDC_m0HdQ=fnFN0uTtjdA9zifZV3ZVJoA@mail.gmail.com>
 <VI1PR83MB022233AD140B7B84463C45D4AD9D9@VI1PR83MB0222.EURPRD83.prod.outlook.com>
 <CAH6fHQ=1Hb5jZH3Yhr-BejT2j83++iykvCZPVYC9HYMueOmHZA@mail.gmail.com>
 <CAGK9nurtqxSTdeUya415wvdswjpTm9noUnLw+WMJv06ozhoETg@mail.gmail.com>
 <VI1PR83MB02228D79560C8A731F0116D5AD9A9@VI1PR83MB0222.EURPRD83.prod.outlook.com>
 <VI1PR83MB0222FFB6BA71803975996928AD999@VI1PR83MB0222.EURPRD83.prod.outlook.com>
 <010f0177f3d56e4b-3c8a92a0-1511-47bc-8c63-3ec32620a52e-000000@us-east-2.amazonses.com>
 <VI1PR83MB02226708EB4258DBDC9F11D1AD989@VI1PR83MB0222.EURPRD83.prod.outlook.com>
 <26d2c4be-cef7-4b76-b641-d0ec8ba2fb85@www.fastmail.com>
Message-ID: <CAH6fHQ=B-XZcNAe+0FgbSJxHu3aAcTTO3G6X5XLsT-OaApcfkg@mail.gmail.com>

I'm really the only one pushing back here. And since time is sort of of the
essence, in this particular, I suppose that we can accept.

Still, as I said in the Github thread, I would really appreciate a more
fleshed out motivation to be documented in the proposal (in the
alternatives subsection where the authors compare one vs two extensions). A
proposal is for design documentation, and here, the design decision can
only be found in a Github thread. It would be much better if the proposal
document reflected this thread.

On Thu, Mar 4, 2021 at 2:18 AM Eric Seidel <eric at seidel.io> wrote:

> I explicitly assent to accepting this revision. I agree with Arnaud and
> Richard that the motivation feels lacking, but we have enough precedent for
> fine-grained extensions that I feel comfortable with this as an
> implementation strategy.
>
> On Wed, Mar 3, 2021, at 11:04, Simon Peyton Jones via
> ghc-steering-committee wrote:
> >
> > In terms of actual official GHC Steering Committee business, this
> > proposal is really just about changing the name of the extension from
> > -XRecordDotSyntax to -XOverloadedRecordDot. The implementation will
> > simply fall short of the entire proposal. Is that accurate?
> >
> >
> >
> > Not quite.
> >
> >  * It replaces RecordDotSyntax with two separate extensions,
> > OverloadedRecordDot and OverloadedRecordUpdate.
> >  * The second, OverloadedRecordUpdate would be advertised as
> > experimental and subject to change. (I’m totally happy with having it
> > in the user manual if that’s what everyone is happy with.)
> >  * If you switch on experimental OverloadedRecordUpdate, you get the
> > whole proposal, with no falling short. But the committee has expressed
> > some second thoughts about update, hence advertising it as experimental.
> > OK?  Only Richard, Iavor, Joachim, Arnaud have said anything on this
> > thread.   I’m taking silence as assent … yell by the end of today if
> > you are unhappy.  I’d like to communicate with the authors.
> >
> >
> >
> > Simon
> >
> >
> >
> > *From:* Richard Eisenberg <rae at richarde.dev>
> > *Sent:* 02 March 2021 16:46
> > *To:* Simon Peyton Jones <simonpj at microsoft.com>
> > *Cc:* ghc-steering-committee <ghc-steering-committee at haskell.org>
> > *Subject:* Re: [ghc-steering-committee] Modification to record dot
> > syntax propsal
> >
> >
> >
> > I don't love having a feature that's completely unmentioned in the
> > manual -- too much of a root to trip over. (For example, tooling may
> > run into -XOverloadedRecordUpdate, but now has no official place to
> > look to see what it is.) I'd be fine with a short section in the manual
> > describing that an experimental -XOverloadedRecordUpdate extension
> > exists, is subject to change, and is meant to roughly implement some
> > part of some proposal. This can be done in just a few sentences, with a
> > link to the proposal, but just being silent seems unhelpful to users.
> >
> >
> >
> > With that small tweak, I'm quite happy to agree with the proposal here.
> >
> >
> >
> > In terms of actual official GHC Steering Committee business, this
> > proposal is really just about changing the name of the extension from
> > -XRecordDotSyntax to -XOverloadedRecordDot. The implementation will
> > simply fall short of the entire proposal. Is that accurate?
> >
> >
> >
> > Richard
> >
> >
> >
> >
> > > On Mar 2, 2021, at 7:45 AM, Simon Peyton Jones via
> ghc-steering-committee <ghc-steering-committee at haskell.org> wrote:
> >
> > >
> >
> > > Friends
> >
> > >
> >
> > > Having consulted the authors, I propose that we do this:
> >
> > >
> >
> > >  * Proceed with OverloadedRecordDot for 9.2, exactly as in the
> original proposal except for the extension name.
> > >  * Record update will remain exactly as now, in 9.2; that is, drawing
> back from the original proposal.
> > >  * There may be some *code* in 9.2 that allows overloaded record
> update, protected by OverloadedRecordUpdate, but not in the user manual,
> and not treated as an accepted proposal.   I don’t think we should ask the
> authors to remove it, and it will allow experimentation.
> > >  * Adam is leading on a revised record-update proposal. This will cover
> > >    * the tradeoffs between type-changing and non-type-changing update
> > >    * what the current record-update syntax stands for, and/or any new
> syntax
> > >
> >
> > > Is that acceptable to everyone?
> >
> > >
> >
> > > Simon
> >
> > >
> >
> > > *From:* ghc-steering-committee <
> ghc-steering-committee-bounces at haskell.org> *On Behalf Of *Simon Peyton
> Jones via ghc-steering-committee
> > > *Sent:* 01 March 2021 17:51
> > > *To:* Iavor Diatchki <iavor.diatchki at gmail.com>; Spiwack, Arnaud <
> arnaud.spiwack at tweag.io>
> > > *Cc:* ghc-steering-committee <ghc-steering-committee at haskell.org>
> > > *Subject:* Re: [ghc-steering-committee] Modification to record dot
> syntax propsal
> >
> > >
> >
> > > I don't buy the argument of "this is already accepted", as I don't
> think many of us had noticed that part of the proposal (I certainly
> didn't), and I think we should be flexible enough to revisit previous
> decisions when we notice problems with them.
> >
> > > I agree in principle that we can revisit decisions.   But we have to
> be aware that it is potentially very discouraging for proposal authors to
> >
> > > ·         propose something,
> >
> > > ·         have it *extensively* debated (including this very point),
> >
> > > ·         have it accepted,
> >
> > > ·         implement it,
> >
> > > and then be told that the committee has changed its mind.  That’s
> pretty bad from their point of view.
> >
> > >
> >
> > > Still, Adam is working on a new SetField proposal, so perhaps that’s a
> figleaf.  I’ll consult them.
> >
> > >
> > > Simon
> >
> > >
> >
> > >
> >
> > > *From:* Iavor Diatchki <iavor.diatchki at gmail.com>
> > > *Sent:* 01 March 2021 17:23
> > > *To:* Spiwack, Arnaud <arnaud.spiwack at tweag.io>
> > > *Cc:* Simon Peyton Jones <simonpj at microsoft.com>;
> ghc-steering-committee <ghc-steering-committee at haskell.org>
> > > *Subject:* Re: [ghc-steering-committee] Modification to record dot
> syntax propsal
> >
> > >
> >
> > > Hello,
> >
> > >
> >
> > > I think there is a strong motivation to *at least* split the
> extensions:  with the current design, enabling the special `.` notation
> also *disables* type changing record update, which has nothing to do with
> the `.` notation.
> >
> > >
> >
> > > My preference would be to:
> >
> > >   1. Split the original proposal into two parts: one about `.`
> notation, the other about record update (as suggested by this proposal)
> >
> > >   2. Treat the `.` notation part as accepted
> >
> > >   3. Require changes on the record update part, so that you don't have
> to choose between it and type changing record updates, which are quite
> useful, and I don't think we should aim for a Haskell without them.
> >
> > >
> >
> > > I don't buy the argument of "this is already accepted", as I don't
> think many of us had noticed that part of the proposal (I certainly
> didn't), and I think we should be flexible enough to revisit previous
> decisions when we notice problems with them.
> >
> > >
> >
> > > -Iavor
> >
> > >
> >
> > >
> >
> > >
> >
> > > On Mon, Mar 1, 2021 at 1:40 AM Spiwack, Arnaud <
> arnaud.spiwack at tweag.io> wrote:
> >
> > >> Simon, all,
> >
> > >>
> >
> > >> After reading more of the PR thread (in particular the fews posts
> after Simon's recommendation), I have to admit: I am thoroughly confused.
> I'm not sure that two people in that thread have the same motivation, end
> goal, or design in mind.
> >
> > >>
> >
> > >> The motivations provided by the modified *Alternatives* section is
> not much more helpful (at the risk of caricaturing a little, it basically
> reads: “we made two extensions rather than one because we can”). Though it
> makes it clear that the end goal is to fold a bunch of record-related
> extensions into one glorious record extension (well, probably not fold
> them, but make a meta-extension that implies all the extensions that we've
> decided we like).
> >
> > >>
> >
> > >> My starting point is that:
> >
> > >> - Additional extensions have a maintenance cost
> >
> > >> - Additional extensions impose a cognitive burden on their use
> >
> > >> - I expect that a new extension will break my code in the next few
> releases.
> >
> > >>
> >
> > >> Based on this, I don't care how this extension or the glorious record
> extension are named; but if we want to have two extensions we should have a
> serious reason. Right now, the one reason that I see (and Iavor raised), is
> that the update part of `RecordDotSyntax` is not backward compatible. Is it
> a strong enough reason? I don't know. The only data point that I can
> provide is that when we discussed the original proposal, I brought it up
> several times, and it didn't seem very important at the time (the
> conversation focused on other points of the proposal).
> >
> > >>
> >
> > >> So, I'm still reluctant. I feel that, at the very least, the
> motivations are not well-enough articulated in the proposal (I'll make a
> comment to this effect on Github when I'm done composing this email).
> >
> > >>
> >
> > >> I appreciate that I'm in the minority here. Yet, I'm still
> unconvinced.
> >
> > >>
> >
> > >> Best,
> >
> > >> Arnaud
> >
> > >>
> >
> > >> On Sat, Feb 27, 2021 at 12:39 AM Simon Peyton Jones <
> simonpj at microsoft.com> wrote:
> >
> > >>> Generally, I'm not in favour in proposals which split extensions
> though: we already have so many extensions. Are the reasons for this split
> strong enough? I haven't had time to dig into the details.
> >
> > >>> Arnaud, happily, you don’t have to dig very deep – just read the
> handful of posts following my recommendation.
> >
> > >>>
> >
> > >>> There seem to be two motivations.
> >
> > >>>
> >
> > >>>  1. There really are two orthogonal extensions, one for r.x
> notation, and one for overloaded update.  Iavor likes the first but not the
> second.  Neil likes both.  Having separate extensions lets us experiment.
> > >>>
> >
> > >>>  1. You suggest that changing the definition of RecordDotSyntax in a
> subsequent release, e.g. by subsequently making it imply NoFieldSelectors,
> would be fine. But it certainly imposes pain – some programs would stop
> compiling.  The approach offered by this proposal avoids that problem.
> > >>>
> >
> > >>> Yes, there are lots of extensions surrounding records:
> NoFieldSelectors, DuplicateRecordFields, NamedFieldPuns,
> DisambiguateRecordFields, RecordWildCards.  It may not be pretty to divide
> things up so fine, but it’s not new.
> >
> > >>>
> >
> > >>>
> >
> > >>> If there are alternative suggestions, let’s hear them.
> >
> > >>>
> >
> > >>> Simon
> >
> > >>>
> >
> > >>> *From:* ghc-steering-committee <
> ghc-steering-committee-bounces at haskell.org> *On Behalf Of *Spiwack, Arnaud
> > >>> *Sent:* 26 February 2021 22:33
> > >>> *To:* Iavor Diatchki <iavor.diatchki at gmail.com>
> > >>> *Cc:* ghc-steering-committee <ghc-steering-committee at haskell.org>
> > >>> *Subject:* Re: [ghc-steering-committee] Modification to record dot
> syntax propsal
> >
> > >>>
> >
> > >>>
> >
> > >>>> I do think that  reusing the record update syntax for the
> overloaded monomorphic update is a mistake---it is not something I had
> noticed during our original discussion.
> >
> > >>>
> >
> > >>> This is the one reason I can see for cutting this extension in
> smaller pieces. But, then again, -XOverloadedRecordUpdate would be a
> fork-like extension.
> >
> > >>>
> >
> > >>> Generally, I'm not in favour in proposals which split extensions
> though: we already have so many extensions. Are the reasons for this split
> strong enough? I haven't had time to dig into the details.
> >
> > >>>
> >
> > >>> I'm not sure that not having the design of the proposal quite
> finalised is a good reason, extensions mutate in their first iterations, I
> don't think that it's a problem.
> >
> > > _______________________________________________
> > > ghc-steering-committee mailing list
> > > ghc-steering-committee at haskell.org
> > >
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee <
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committee&data=04%7C01%7Csimonpj%40microsoft.com%7Ccf65595be24d42cab2ca08d8dd9ab96c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637503003928846093%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=3goska4aw00W0GxIvfDOj3JCdEaQ0CB8Zowb1u5RbMo%3D&reserved=0
> >
> >
> >
> >
> > _______________________________________________
> > ghc-steering-committee mailing list
> > ghc-steering-committee at haskell.org
> > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
> >
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20210304/fdbbc3e0/attachment-0001.html>

From simonpj at microsoft.com  Thu Mar  4 09:39:47 2021
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Thu, 4 Mar 2021 09:39:47 +0000
Subject: [ghc-steering-committee] Modification to record dot
	syntax	propsal
In-Reply-To: <CAH6fHQ=B-XZcNAe+0FgbSJxHu3aAcTTO3G6X5XLsT-OaApcfkg@mail.gmail.com>
References: <VI1PR83MB0222BD8EC07924531D115264AD809@VI1PR83MB0222.EURPRD83.prod.outlook.com>
 <VI1PR83MB02221D0C9C4C75606C6F9FD3AD9D9@VI1PR83MB0222.EURPRD83.prod.outlook.com>
 <010f0177defd0abc-ddb39126-a38d-4cd7-b888-81acd5493dea-000000@us-east-2.amazonses.com>
 <CAGK9nur-Q+gft7qQodSCsaK4xnvpZoXwccaNYU4VNH_keoGEOA@mail.gmail.com>
 <CAH6fHQm1OFX+0i+CVwDC_m0HdQ=fnFN0uTtjdA9zifZV3ZVJoA@mail.gmail.com>
 <VI1PR83MB022233AD140B7B84463C45D4AD9D9@VI1PR83MB0222.EURPRD83.prod.outlook.com>
 <CAH6fHQ=1Hb5jZH3Yhr-BejT2j83++iykvCZPVYC9HYMueOmHZA@mail.gmail.com>
 <CAGK9nurtqxSTdeUya415wvdswjpTm9noUnLw+WMJv06ozhoETg@mail.gmail.com>
 <VI1PR83MB02228D79560C8A731F0116D5AD9A9@VI1PR83MB0222.EURPRD83.prod.outlook.com>
 <VI1PR83MB0222FFB6BA71803975996928AD999@VI1PR83MB0222.EURPRD83.prod.outlook.com>
 <010f0177f3d56e4b-3c8a92a0-1511-47bc-8c63-3ec32620a52e-000000@us-east-2.amazonses.com>
 <VI1PR83MB02226708EB4258DBDC9F11D1AD989@VI1PR83MB0222.EURPRD83.prod.outlook.com>
 <26d2c4be-cef7-4b76-b641-d0ec8ba2fb85@www.fastmail.com>
 <CAH6fHQ=B-XZcNAe+0FgbSJxHu3aAcTTO3G6X5XLsT-OaApcfkg@mail.gmail.com>
Message-ID: <VI1PR83MB022229BDE81BE187F1AA7D8BAD979@VI1PR83MB0222.EURPRD83.prod.outlook.com>

Arnaud

I'm all for improving the proposal.  But rather than have the authors guess, can you be more specific about what you want?

To be concrete, do you want this (copied from up-thread) in the compare-one-vs-two subsection?

  1.  Add two extensions, as proposed here. Pro: flexibility for people like Iavor who want type-changing update, but would still like dot-notation. Pro: orthogonal things are controlled by separate flags. Con: each has to be documented separately: two flags with one para each, instead of one flag with two paras. (The implementation cost is zero: it's only a question of which flag to test.)
  2.  Add one extension (OverloadedRecordFields, say) to do what OverloadedRecordDot and OverloadedRecordUpdate to in this proposal. Pro: only one extension. Con: some users might want dot-notation, but not want to give up type-changing update.
  3.  Use RecordDotSyntax, and be prepared to change what it means (e.g. add NoFieldSelectors) later. Pro: only one extension. Con: changing the meaning of an extension will break programs.
Would adding that address your concern?   Or did you have something else in mind?

Simon

From: ghc-steering-committee <ghc-steering-committee-bounces at haskell.org> On Behalf Of Spiwack, Arnaud
Sent: 04 March 2021 09:22
To: Eric Seidel <eric at seidel.io>
Cc: Simon Peyton Jones via ghc-steering-committee <ghc-steering-committee at haskell.org>
Subject: Re: [ghc-steering-committee] Modification to record dot syntax propsal

I'm really the only one pushing back here. And since time is sort of of the essence, in this particular, I suppose that we can accept.

Still, as I said in the Github thread, I would really appreciate a more fleshed out motivation to be documented in the proposal (in the alternatives subsection where the authors compare one vs two extensions). A proposal is for design documentation, and here, the design decision can only be found in a Github thread. It would be much better if the proposal document reflected this thread.

On Thu, Mar 4, 2021 at 2:18 AM Eric Seidel <eric at seidel.io<mailto:eric at seidel.io>> wrote:
I explicitly assent to accepting this revision. I agree with Arnaud and Richard that the motivation feels lacking, but we have enough precedent for fine-grained extensions that I feel comfortable with this as an implementation strategy.

On Wed, Mar 3, 2021, at 11:04, Simon Peyton Jones via ghc-steering-committee wrote:
>
> In terms of actual official GHC Steering Committee business, this
> proposal is really just about changing the name of the extension from
> -XRecordDotSyntax to -XOverloadedRecordDot. The implementation will
> simply fall short of the entire proposal. Is that accurate?
>
>
>
> Not quite.
>
>  * It replaces RecordDotSyntax with two separate extensions,
> OverloadedRecordDot and OverloadedRecordUpdate.
>  * The second, OverloadedRecordUpdate would be advertised as
> experimental and subject to change. (I'm totally happy with having it
> in the user manual if that's what everyone is happy with.)
>  * If you switch on experimental OverloadedRecordUpdate, you get the
> whole proposal, with no falling short. But the committee has expressed
> some second thoughts about update, hence advertising it as experimental.
> OK?  Only Richard, Iavor, Joachim, Arnaud have said anything on this
> thread.   I'm taking silence as assent ... yell by the end of today if
> you are unhappy.  I'd like to communicate with the authors.
>
>
>
> Simon
>
>
>
> *From:* Richard Eisenberg <rae at richarde.dev<mailto:rae at richarde.dev>>
> *Sent:* 02 March 2021 16:46
> *To:* Simon Peyton Jones <simonpj at microsoft.com<mailto:simonpj at microsoft.com>>
> *Cc:* ghc-steering-committee <ghc-steering-committee at haskell.org<mailto:ghc-steering-committee at haskell.org>>
> *Subject:* Re: [ghc-steering-committee] Modification to record dot
> syntax propsal
>
>
>
> I don't love having a feature that's completely unmentioned in the
> manual -- too much of a root to trip over. (For example, tooling may
> run into -XOverloadedRecordUpdate, but now has no official place to
> look to see what it is.) I'd be fine with a short section in the manual
> describing that an experimental -XOverloadedRecordUpdate extension
> exists, is subject to change, and is meant to roughly implement some
> part of some proposal. This can be done in just a few sentences, with a
> link to the proposal, but just being silent seems unhelpful to users.
>
>
>
> With that small tweak, I'm quite happy to agree with the proposal here.
>
>
>
> In terms of actual official GHC Steering Committee business, this
> proposal is really just about changing the name of the extension from
> -XRecordDotSyntax to -XOverloadedRecordDot. The implementation will
> simply fall short of the entire proposal. Is that accurate?
>
>
>
> Richard
>
>
>
>
> > On Mar 2, 2021, at 7:45 AM, Simon Peyton Jones via ghc-steering-committee <ghc-steering-committee at haskell.org<mailto:ghc-steering-committee at haskell.org>> wrote:
>
> >
>
> > Friends
>
> >
>
> > Having consulted the authors, I propose that we do this:
>
> >
>
> >  * Proceed with OverloadedRecordDot for 9.2, exactly as in the original proposal except for the extension name.
> >  * Record update will remain exactly as now, in 9.2; that is, drawing back from the original proposal.
> >  * There may be some *code* in 9.2 that allows overloaded record update, protected by OverloadedRecordUpdate, but not in the user manual, and not treated as an accepted proposal.   I don't think we should ask the authors to remove it, and it will allow experimentation.
> >  * Adam is leading on a revised record-update proposal. This will cover
> >    * the tradeoffs between type-changing and non-type-changing update
> >    * what the current record-update syntax stands for, and/or any new syntax
> >
>
> > Is that acceptable to everyone?
>
> >
>
> > Simon
>
> >
>
> > *From:* ghc-steering-committee <ghc-steering-committee-bounces at haskell.org<mailto:ghc-steering-committee-bounces at haskell.org>> *On Behalf Of *Simon Peyton Jones via ghc-steering-committee
> > *Sent:* 01 March 2021 17:51
> > *To:* Iavor Diatchki <iavor.diatchki at gmail.com<mailto:iavor.diatchki at gmail.com>>; Spiwack, Arnaud <arnaud.spiwack at tweag.io<mailto:arnaud.spiwack at tweag.io>>
> > *Cc:* ghc-steering-committee <ghc-steering-committee at haskell.org<mailto:ghc-steering-committee at haskell.org>>
> > *Subject:* Re: [ghc-steering-committee] Modification to record dot syntax propsal
>
> >
>
> > I don't buy the argument of "this is already accepted", as I don't think many of us had noticed that part of the proposal (I certainly didn't), and I think we should be flexible enough to revisit previous decisions when we notice problems with them.
>
> > I agree in principle that we can revisit decisions.   But we have to be aware that it is potentially very discouraging for proposal authors to
>
> > *         propose something,
>
> > *         have it *extensively* debated (including this very point),
>
> > *         have it accepted,
>
> > *         implement it,
>
> > and then be told that the committee has changed its mind.  That's pretty bad from their point of view.
>
> >
>
> > Still, Adam is working on a new SetField proposal, so perhaps that's a figleaf.  I'll consult them.
>
> >
> > Simon
>
> >
>
> >
>
> > *From:* Iavor Diatchki <iavor.diatchki at gmail.com<mailto:iavor.diatchki at gmail.com>>
> > *Sent:* 01 March 2021 17:23
> > *To:* Spiwack, Arnaud <arnaud.spiwack at tweag.io<mailto:arnaud.spiwack at tweag.io>>
> > *Cc:* Simon Peyton Jones <simonpj at microsoft.com<mailto:simonpj at microsoft.com>>; ghc-steering-committee <ghc-steering-committee at haskell.org<mailto:ghc-steering-committee at haskell.org>>
> > *Subject:* Re: [ghc-steering-committee] Modification to record dot syntax propsal
>
> >
>
> > Hello,
>
> >
>
> > I think there is a strong motivation to *at least* split the extensions:  with the current design, enabling the special `.` notation also *disables* type changing record update, which has nothing to do with the `.` notation.
>
> >
>
> > My preference would be to:
>
> >   1. Split the original proposal into two parts: one about `.` notation, the other about record update (as suggested by this proposal)
>
> >   2. Treat the `.` notation part as accepted
>
> >   3. Require changes on the record update part, so that you don't have to choose between it and type changing record updates, which are quite useful, and I don't think we should aim for a Haskell without them.
>
> >
>
> > I don't buy the argument of "this is already accepted", as I don't think many of us had noticed that part of the proposal (I certainly didn't), and I think we should be flexible enough to revisit previous decisions when we notice problems with them.
>
> >
>
> > -Iavor
>
> >
>
> >
>
> >
>
> > On Mon, Mar 1, 2021 at 1:40 AM Spiwack, Arnaud <arnaud.spiwack at tweag.io<mailto:arnaud.spiwack at tweag.io>> wrote:
>
> >> Simon, all,
>
> >>
>
> >> After reading more of the PR thread (in particular the fews posts after Simon's recommendation), I have to admit: I am thoroughly confused. I'm not sure that two people in that thread have the same motivation, end goal, or design in mind.
>
> >>
>
> >> The motivations provided by the modified *Alternatives* section is not much more helpful (at the risk of caricaturing a little, it basically reads: "we made two extensions rather than one because we can"). Though it makes it clear that the end goal is to fold a bunch of record-related extensions into one glorious record extension (well, probably not fold them, but make a meta-extension that implies all the extensions that we've decided we like).
>
> >>
>
> >> My starting point is that:
>
> >> - Additional extensions have a maintenance cost
>
> >> - Additional extensions impose a cognitive burden on their use
>
> >> - I expect that a new extension will break my code in the next few releases.
>
> >>
>
> >> Based on this, I don't care how this extension or the glorious record extension are named; but if we want to have two extensions we should have a serious reason. Right now, the one reason that I see (and Iavor raised), is that the update part of `RecordDotSyntax` is not backward compatible. Is it a strong enough reason? I don't know. The only data point that I can provide is that when we discussed the original proposal, I brought it up several times, and it didn't seem very important at the time (the conversation focused on other points of the proposal).
>
> >>
>
> >> So, I'm still reluctant. I feel that, at the very least, the motivations are not well-enough articulated in the proposal (I'll make a comment to this effect on Github when I'm done composing this email).
>
> >>
>
> >> I appreciate that I'm in the minority here. Yet, I'm still unconvinced.
>
> >>
>
> >> Best,
>
> >> Arnaud
>
> >>
>
> >> On Sat, Feb 27, 2021 at 12:39 AM Simon Peyton Jones <simonpj at microsoft.com<mailto:simonpj at microsoft.com>> wrote:
>
> >>> Generally, I'm not in favour in proposals which split extensions though: we already have so many extensions. Are the reasons for this split strong enough? I haven't had time to dig into the details.
>
> >>> Arnaud, happily, you don't have to dig very deep - just read the handful of posts following my recommendation.
>
> >>>
>
> >>> There seem to be two motivations.
>
> >>>
>
> >>>  1. There really are two orthogonal extensions, one for r.x notation, and one for overloaded update.  Iavor likes the first but not the second.  Neil likes both.  Having separate extensions lets us experiment.
> >>>
>
> >>>  1. You suggest that changing the definition of RecordDotSyntax in a subsequent release, e.g. by subsequently making it imply NoFieldSelectors, would be fine. But it certainly imposes pain - some programs would stop compiling.  The approach offered by this proposal avoids that problem.
> >>>
>
> >>> Yes, there are lots of extensions surrounding records: NoFieldSelectors, DuplicateRecordFields, NamedFieldPuns, DisambiguateRecordFields, RecordWildCards.  It may not be pretty to divide things up so fine, but it's not new.
>
> >>>
>
> >>>
>
> >>> If there are alternative suggestions, let's hear them.
>
> >>>
>
> >>> Simon
>
> >>>
>
> >>> *From:* ghc-steering-committee <ghc-steering-committee-bounces at haskell.org<mailto:ghc-steering-committee-bounces at haskell.org>> *On Behalf Of *Spiwack, Arnaud
> >>> *Sent:* 26 February 2021 22:33
> >>> *To:* Iavor Diatchki <iavor.diatchki at gmail.com<mailto:iavor.diatchki at gmail.com>>
> >>> *Cc:* ghc-steering-committee <ghc-steering-committee at haskell.org<mailto:ghc-steering-committee at haskell.org>>
> >>> *Subject:* Re: [ghc-steering-committee] Modification to record dot syntax propsal
>
> >>>
>
> >>>
>
> >>>> I do think that  reusing the record update syntax for the overloaded monomorphic update is a mistake---it is not something I had noticed during our original discussion.
>
> >>>
>
> >>> This is the one reason I can see for cutting this extension in smaller pieces. But, then again, -XOverloadedRecordUpdate would be a fork-like extension.
>
> >>>
>
> >>> Generally, I'm not in favour in proposals which split extensions though: we already have so many extensions. Are the reasons for this split strong enough? I haven't had time to dig into the details.
>
> >>>
>
> >>> I'm not sure that not having the design of the proposal quite finalised is a good reason, extensions mutate in their first iterations, I don't think that it's a problem.
>
> > _______________________________________________
> > ghc-steering-committee mailing list
> > ghc-steering-committee at haskell.org<mailto:ghc-steering-committee at haskell.org>
> > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committee&data=04%7C01%7Csimonpj%40microsoft.com%7Cb9e5de3ee68046ca17e808d8deef1f43%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637504466356690323%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=uuQ%2BWONzGX08Su2VfRDmoOXkMo0RjHEpIsIfE3zTwPs%3D&reserved=0> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committee&data=04%7C01%7Csimonpj%40microsoft.com%7Ccf65595be24d42cab2ca08d8dd9ab96c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637503003928846093%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=3goska4aw00W0GxIvfDOj3JCdEaQ0CB8Zowb1u5RbMo%3D&reserved=0<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committee&data=04%7C01%7Csimonpj%40microsoft.com%7Cb9e5de3ee68046ca17e808d8deef1f43%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637504466356700318%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=vUnHBFFzM0vAKHsOMUeKeTtes1C4qnJpEAfsbN%2FaPGM%3D&reserved=0>>
>
>
>
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org<mailto:ghc-steering-committee at haskell.org>
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committee&data=04%7C01%7Csimonpj%40microsoft.com%7Cb9e5de3ee68046ca17e808d8deef1f43%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637504466356710308%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=NphMrHpqCq%2BBHniQiLFSBREpzr8e%2Bgdwgp9%2Bv5y6fAI%3D&reserved=0>
>
_______________________________________________
ghc-steering-committee mailing list
ghc-steering-committee at haskell.org<mailto:ghc-steering-committee at haskell.org>
https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committee&data=04%7C01%7Csimonpj%40microsoft.com%7Cb9e5de3ee68046ca17e808d8deef1f43%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637504466356710308%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=NphMrHpqCq%2BBHniQiLFSBREpzr8e%2Bgdwgp9%2Bv5y6fAI%3D&reserved=0>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20210304/46f3c4e4/attachment-0001.html>

From simonpj at microsoft.com  Thu Mar  4 09:46:47 2021
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Thu, 4 Mar 2021 09:46:47 +0000
Subject: [ghc-steering-committee] Modification to record dot syntax
 propsal
In-Reply-To: <VI1PR83MB0222FFB6BA71803975996928AD999@VI1PR83MB0222.EURPRD83.prod.outlook.com>
References: <VI1PR83MB0222BD8EC07924531D115264AD809@VI1PR83MB0222.EURPRD83.prod.outlook.com>
 <VI1PR83MB02221D0C9C4C75606C6F9FD3AD9D9@VI1PR83MB0222.EURPRD83.prod.outlook.com>
 <010f0177defd0abc-ddb39126-a38d-4cd7-b888-81acd5493dea-000000@us-east-2.amazonses.com>
 <CAGK9nur-Q+gft7qQodSCsaK4xnvpZoXwccaNYU4VNH_keoGEOA@mail.gmail.com>
 <CAH6fHQm1OFX+0i+CVwDC_m0HdQ=fnFN0uTtjdA9zifZV3ZVJoA@mail.gmail.com>
 <VI1PR83MB022233AD140B7B84463C45D4AD9D9@VI1PR83MB0222.EURPRD83.prod.outlook.com>
 <CAH6fHQ=1Hb5jZH3Yhr-BejT2j83++iykvCZPVYC9HYMueOmHZA@mail.gmail.com>
 <CAGK9nurtqxSTdeUya415wvdswjpTm9noUnLw+WMJv06ozhoETg@mail.gmail.com>
 <VI1PR83MB02228D79560C8A731F0116D5AD9A9@VI1PR83MB0222.EURPRD83.prod.outlook.com>
 <VI1PR83MB0222FFB6BA71803975996928AD999@VI1PR83MB0222.EURPRD83.prod.outlook.com>
Message-ID: <VI1PR83MB02226750776BFB3526A5A011AD979@VI1PR83MB0222.EURPRD83.prod.outlook.com>

Friends



We’ve agree to accept my suggestion below.



But there is one point at issue: should OverloadedRecordUpdate be documented in the user manual, albeit identified as a not-yet-accepted feature?



  *   Richard positively wants it in the manual
  *   Iavor positively doesn’t want it there.



I don’t mind either way.



What do others think?  It’s not a big deal, but we owe the authors a decision.  Answer by the end of the week please, and I’ll make a shepherd decision based on the opinions I get.



Simon


From: Simon Peyton Jones <simonpj at microsoft.com>
Sent: 02 March 2021 12:45
To: ghc-steering-committee <ghc-steering-committee at haskell.org>
Cc: Simon Peyton Jones <simonpj at microsoft.com>
Subject: RE: [ghc-steering-committee] Modification to record dot syntax propsal

Friends

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


  *   Proceed with OverloadedRecordDot for 9.2, exactly as in the original proposal except for the extension name.
  *   Record update will remain exactly as now, in 9.2; that is, drawing back from the original proposal.
  *   There may be some code in 9.2 that allows overloaded record update, protected by OverloadedRecordUpdate, but not in the user manual, and not treated as an accepted proposal.   I don’t think we should ask the authors to remove it, and it will allow experimentation.
  *   Adam is leading on a revised record-update proposal. This will cover

     *   the tradeoffs between type-changing and non-type-changing update
     *   what the current record-update syntax stands for, and/or any new syntax

Is that acceptable to everyone?

Simon

From: ghc-steering-committee <ghc-steering-committee-bounces at haskell.org<mailto:ghc-steering-committee-bounces at haskell.org>> On Behalf Of Simon Peyton Jones via ghc-steering-committee
Sent: 01 March 2021 17:51
To: Iavor Diatchki <iavor.diatchki at gmail.com<mailto:iavor.diatchki at gmail.com>>; Spiwack, Arnaud <arnaud.spiwack at tweag.io<mailto:arnaud.spiwack at tweag.io>>
Cc: ghc-steering-committee <ghc-steering-committee at haskell.org<mailto:ghc-steering-committee at haskell.org>>
Subject: Re: [ghc-steering-committee] Modification to record dot syntax propsal

I don't buy the argument of "this is already accepted", as I don't think many of us had noticed that part of the proposal (I certainly didn't), and I think we should be flexible enough to revisit previous decisions when we notice problems with them.
I agree in principle that we can revisit decisions.   But we have to be aware that it is potentially very discouraging for proposal authors to

  *   propose something,
  *   have it extensively debated (including this very point),
  *   have it accepted,
  *   implement it,
and then be told that the committee has changed its mind.  That’s pretty bad from their point of view.

Still, Adam is working on a new SetField proposal, so perhaps that’s a figleaf.  I’ll consult them.

Simon


From: Iavor Diatchki <iavor.diatchki at gmail.com<mailto:iavor.diatchki at gmail.com>>
Sent: 01 March 2021 17:23
To: Spiwack, Arnaud <arnaud.spiwack at tweag.io<mailto:arnaud.spiwack at tweag.io>>
Cc: Simon Peyton Jones <simonpj at microsoft.com<mailto:simonpj at microsoft.com>>; ghc-steering-committee <ghc-steering-committee at haskell.org<mailto:ghc-steering-committee at haskell.org>>
Subject: Re: [ghc-steering-committee] Modification to record dot syntax propsal

Hello,

I think there is a strong motivation to *at least* split the extensions:  with the current design, enabling the special `.` notation also *disables* type changing record update, which has nothing to do with the `.` notation.

My preference would be to:
  1. Split the original proposal into two parts: one about `.` notation, the other about record update (as suggested by this proposal)
  2. Treat the `.` notation part as accepted
  3. Require changes on the record update part, so that you don't have to choose between it and type changing record updates, which are quite useful, and I don't think we should aim for a Haskell without them.

I don't buy the argument of "this is already accepted", as I don't think many of us had noticed that part of the proposal (I certainly didn't), and I think we should be flexible enough to revisit previous decisions when we notice problems with them.

-Iavor



On Mon, Mar 1, 2021 at 1:40 AM Spiwack, Arnaud <arnaud.spiwack at tweag.io<mailto:arnaud.spiwack at tweag.io>> wrote:
Simon, all,

After reading more of the PR thread (in particular the fews posts after Simon's recommendation), I have to admit: I am thoroughly confused. I'm not sure that two people in that thread have the same motivation, end goal, or design in mind.

The motivations provided by the modified Alternatives section is not much more helpful (at the risk of caricaturing a little, it basically reads: “we made two extensions rather than one because we can”). Though it makes it clear that the end goal is to fold a bunch of record-related extensions into one glorious record extension (well, probably not fold them, but make a meta-extension that implies all the extensions that we've decided we like).

My starting point is that:
- Additional extensions have a maintenance cost
- Additional extensions impose a cognitive burden on their use
- I expect that a new extension will break my code in the next few releases.

Based on this, I don't care how this extension or the glorious record extension are named; but if we want to have two extensions we should have a serious reason. Right now, the one reason that I see (and Iavor raised), is that the update part of `RecordDotSyntax` is not backward compatible. Is it a strong enough reason? I don't know. The only data point that I can provide is that when we discussed the original proposal, I brought it up several times, and it didn't seem very important at the time (the conversation focused on other points of the proposal).

So, I'm still reluctant. I feel that, at the very least, the motivations are not well-enough articulated in the proposal (I'll make a comment to this effect on Github when I'm done composing this email).

I appreciate that I'm in the minority here. Yet, I'm still unconvinced.

Best,
Arnaud

On Sat, Feb 27, 2021 at 12:39 AM Simon Peyton Jones <simonpj at microsoft.com<mailto:simonpj at microsoft.com>> wrote:
Generally, I'm not in favour in proposals which split extensions though: we already have so many extensions. Are the reasons for this split strong enough? I haven't had time to dig into the details.
Arnaud, happily, you don’t have to dig very deep – just read the handful of posts following my recommendation.

There seem to be two motivations.


  1.  There really are two orthogonal extensions, one for r.x notation, and one for overloaded update.  Iavor likes the first but not the second.  Neil likes both.  Having separate extensions lets us experiment.



  1.  You suggest that changing the definition of RecordDotSyntax in a subsequent release, e.g. by subsequently making it imply NoFieldSelectors, would be fine. But it certainly imposes pain – some programs would stop compiling.  The approach offered by this proposal avoids that problem.

Yes, there are lots of extensions surrounding records: NoFieldSelectors, DuplicateRecordFields, NamedFieldPuns, DisambiguateRecordFields, RecordWildCards.  It may not be pretty to divide things up so fine, but it’s not new.


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

Simon

From: ghc-steering-committee <ghc-steering-committee-bounces at haskell.org<mailto:ghc-steering-committee-bounces at haskell.org>> On Behalf Of Spiwack, Arnaud
Sent: 26 February 2021 22:33
To: Iavor Diatchki <iavor.diatchki at gmail.com<mailto:iavor.diatchki at gmail.com>>
Cc: ghc-steering-committee <ghc-steering-committee at haskell.org<mailto:ghc-steering-committee at haskell.org>>
Subject: Re: [ghc-steering-committee] Modification to record dot syntax propsal


I do think that  reusing the record update syntax for the overloaded monomorphic update is a mistake---it is not something I had noticed during our original discussion.

This is the one reason I can see for cutting this extension in smaller pieces. But, then again, -XOverloadedRecordUpdate would be a fork-like extension.

Generally, I'm not in favour in proposals which split extensions though: we already have so many extensions. Are the reasons for this split strong enough? I haven't had time to dig into the details.

I'm not sure that not having the design of the proposal quite finalised is a good reason, extensions mutate in their first iterations, I don't think that it's a problem.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20210304/e732f84c/attachment-0001.html>

From mail at joachim-breitner.de  Thu Mar  4 10:36:35 2021
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Thu, 04 Mar 2021 11:36:35 +0100
Subject: [ghc-steering-committee] Modification to record dot syntax
 propsal
In-Reply-To: <VI1PR83MB02226750776BFB3526A5A011AD979@VI1PR83MB0222.EURPRD83.prod.outlook.com>
References: <VI1PR83MB0222BD8EC07924531D115264AD809@VI1PR83MB0222.EURPRD83.prod.outlook.com>
 <VI1PR83MB02221D0C9C4C75606C6F9FD3AD9D9@VI1PR83MB0222.EURPRD83.prod.outlook.com>
 <010f0177defd0abc-ddb39126-a38d-4cd7-b888-81acd5493dea-000000@us-east-2.amazonses.com>
 <CAGK9nur-Q+gft7qQodSCsaK4xnvpZoXwccaNYU4VNH_keoGEOA@mail.gmail.com>
 <CAH6fHQm1OFX+0i+CVwDC_m0HdQ=fnFN0uTtjdA9zifZV3ZVJoA@mail.gmail.com>
 <VI1PR83MB022233AD140B7B84463C45D4AD9D9@VI1PR83MB0222.EURPRD83.prod.outlook.com>
 <CAH6fHQ=1Hb5jZH3Yhr-BejT2j83++iykvCZPVYC9HYMueOmHZA@mail.gmail.com>
 <CAGK9nurtqxSTdeUya415wvdswjpTm9noUnLw+WMJv06ozhoETg@mail.gmail.com>
 <VI1PR83MB02228D79560C8A731F0116D5AD9A9@VI1PR83MB0222.EURPRD83.prod.outlook.com>
 <VI1PR83MB0222FFB6BA71803975996928AD999@VI1PR83MB0222.EURPRD83.prod.outlook.com>
 <VI1PR83MB02226750776BFB3526A5A011AD979@VI1PR83MB0222.EURPRD83.prod.outlook.com>
Message-ID: <efccbd6a4ccb0360df749189795c5ce05d6a56d3.camel@joachim-breitner.de>

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 <simonpj at microsoft.com> 
> Sent: 02 March 2021 12:45
> To: ghc-steering-committee <ghc-steering-committee at haskell.org>
> Cc: Simon Peyton Jones <simonpj at microsoft.com>
> Subject: RE: [ghc-steering-committee] Modification to record dot syntax propsal
>  
> Friends
>  
> Having consulted the authors, I propose that we do this:
>  
> Proceed with OverloadedRecordDot for 9.2, exactly as in the original proposal except for the extension name.
> Record update will remain exactly as now, in 9.2; that is, drawing back from the original proposal.
> There may be some code in 9.2 that allows overloaded record update, protected by OverloadedRecordUpdate, but not in the user manual, and not treated as an accepted proposal.   I don’t think we should ask the authors to remove it, and it will allow experimentation.
> Adam is leading on a revised record-update proposal. This will cover
> the tradeoffs between type-changing and non-type-changing update
> what the current record-update syntax stands for, and/or any new syntax
>  
> Is that acceptable to everyone?
>  
> Simon
>  
> From: ghc-steering-committee <ghc-steering-committee-bounces at haskell.org> On Behalf Of Simon Peyton Jones via ghc-steering-committee
> Sent: 01 March 2021 17:51
> To: Iavor Diatchki <iavor.diatchki at gmail.com>; Spiwack, Arnaud <arnaud.spiwack at tweag.io>
> Cc: ghc-steering-committee <ghc-steering-committee at haskell.org>
> Subject: Re: [ghc-steering-committee] Modification to record dot syntax propsal
>  
> I don't buy the argument of "this is already accepted", as I don't think many of us had noticed that part of the proposal (I certainly didn't), and I think we should be flexible enough to revisit previous decisions when we notice problems with them.
> I agree in principle that we can revisit decisions.   But we have to be aware that it is potentially very discouraging for proposal authors to
> propose something,
> have it extensively debated (including this very point),
> have it accepted,
> implement it,
> and then be told that the committee has changed its mind.  That’s pretty bad from their point of view.
>  
> Still, Adam is working on a new SetField proposal, so perhaps that’s a figleaf.  I’ll consult them.
> 
> Simon
>  
>  
> From: Iavor Diatchki <iavor.diatchki at gmail.com> 
> Sent: 01 March 2021 17:23
> To: Spiwack, Arnaud <arnaud.spiwack at tweag.io>
> Cc: Simon Peyton Jones <simonpj at microsoft.com>; ghc-steering-committee <ghc-steering-committee at haskell.org>
> Subject: Re: [ghc-steering-committee] Modification to record dot syntax propsal
>  
> Hello,
>  
> I think there is a strong motivation to *at least* split the extensions:  with the current design, enabling the special `.` notation also *disables* type changing record update, which has nothing to do with the `.` notation.
>  
> My preference would be to:
>   1. Split the original proposal into two parts: one about `.` notation, the other about record update (as suggested by this proposal)
>   2. Treat the `.` notation part as accepted
>   3. Require changes on the record update part, so that you don't have to choose between it and type changing record updates, which are quite useful, and I don't think we should aim for a Haskell without them.
>  
> I don't buy the argument of "this is already accepted", as I don't think many of us had noticed that part of the proposal (I certainly didn't), and I think we should be flexible enough to revisit previous decisions when we notice problems with them.
>  
> -Iavor
>  
>  
>  
> On Mon, Mar 1, 2021 at 1:40 AM Spiwack, Arnaud <arnaud.spiwack at tweag.io> wrote:
> > Simon, all,
> >  
> > After reading more of the PR thread (in particular the fews posts after Simon's recommendation), I have to admit: I am thoroughly confused. I'm not sure that two people in that thread have the same motivation, end goal, or design in mind.
> >  
> > The motivations provided by the modified Alternatives section is not much more helpful (at the risk of caricaturing a little, it basically reads: “we made two extensions rather than one because we can”). Though it makes it clear that the end goal is to fold a bunch of record-related extensions into one glorious record extension (well, probably not fold them, but make a meta-extension that implies all the extensions that we've decided we like).
> >  
> > My starting point is that:
> > - Additional extensions have a maintenance cost
> > - Additional extensions impose a cognitive burden on their use
> > - I expect that a new extension will break my code in the next few releases.
> >  
> > Based on this, I don't care how this extension or the glorious record extension are named; but if we want to have two extensions we should have a serious reason. Right now, the one reason that I see (and Iavor raised), is that the update part of `RecordDotSyntax` is not backward compatible. Is it a strong enough reason? I don't know. The only data point that I can provide is that when we discussed the original proposal, I brought it up several times, and it didn't seem very important at the time (the conversation focused on other points of the proposal).
> >  
> > So, I'm still reluctant. I feel that, at the very least, the motivations are not well-enough articulated in the proposal (I'll make a comment to this effect on Github when I'm done composing this email).
> >  
> > I appreciate that I'm in the minority here. Yet, I'm still unconvinced.
> >  
> > Best,
> > Arnaud
> >  
> > On Sat, Feb 27, 2021 at 12:39 AM Simon Peyton Jones <simonpj at microsoft.com> wrote:
> > > Generally, I'm not in favour in proposals which split extensions though: we already have so many extensions. Are the reasons for this split strong enough? I haven't had time to dig into the details.
> > > Arnaud, happily, you don’t have to dig very deep – just read the handful of posts following my recommendation.
> > >  
> > > There seem to be two motivations.
> > >  
> > > 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 <ghc-steering-committee-bounces at haskell.org> On Behalf Of Spiwack, Arnaud
> > > Sent: 26 February 2021 22:33
> > > To: Iavor Diatchki <iavor.diatchki at gmail.com>
> > > Cc: ghc-steering-committee <ghc-steering-committee at haskell.org>
> > > Subject: Re: [ghc-steering-committee] Modification to record dot syntax propsal
> > >  
> > >  
> > > > I do think that  reusing the record update syntax for the overloaded monomorphic update is a mistake---it is not something I had noticed during our original discussion.
> > > 
> > >  
> > > This is the one reason I can see for cutting this extension in smaller pieces. But, then again, -XOverloadedRecordUpdate would be a fork-like extension.
> > >  
> > > Generally, I'm not in favour in proposals which split extensions though: we already have so many extensions. Are the reasons for this split strong enough? I haven't had time to dig into the details.
> > >  
> > > I'm not sure that not having the design of the proposal quite finalised is a good reason, extensions mutate in their first iterations, I don't think that it's a problem.
> 
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
-- 
Joachim Breitner
  mail at joachim-breitner.de
  http://www.joachim-breitner.de/



From arnaud.spiwack at tweag.io  Thu Mar  4 12:08:37 2021
From: arnaud.spiwack at tweag.io (Spiwack, Arnaud)
Date: Thu, 4 Mar 2021 13:08:37 +0100
Subject: [ghc-steering-committee] Modification to record dot syntax
	propsal
In-Reply-To: <VI1PR83MB022229BDE81BE187F1AA7D8BAD979@VI1PR83MB0222.EURPRD83.prod.outlook.com>
References: <VI1PR83MB0222BD8EC07924531D115264AD809@VI1PR83MB0222.EURPRD83.prod.outlook.com>
 <VI1PR83MB02221D0C9C4C75606C6F9FD3AD9D9@VI1PR83MB0222.EURPRD83.prod.outlook.com>
 <010f0177defd0abc-ddb39126-a38d-4cd7-b888-81acd5493dea-000000@us-east-2.amazonses.com>
 <CAGK9nur-Q+gft7qQodSCsaK4xnvpZoXwccaNYU4VNH_keoGEOA@mail.gmail.com>
 <CAH6fHQm1OFX+0i+CVwDC_m0HdQ=fnFN0uTtjdA9zifZV3ZVJoA@mail.gmail.com>
 <VI1PR83MB022233AD140B7B84463C45D4AD9D9@VI1PR83MB0222.EURPRD83.prod.outlook.com>
 <CAH6fHQ=1Hb5jZH3Yhr-BejT2j83++iykvCZPVYC9HYMueOmHZA@mail.gmail.com>
 <CAGK9nurtqxSTdeUya415wvdswjpTm9noUnLw+WMJv06ozhoETg@mail.gmail.com>
 <VI1PR83MB02228D79560C8A731F0116D5AD9A9@VI1PR83MB0222.EURPRD83.prod.outlook.com>
 <VI1PR83MB0222FFB6BA71803975996928AD999@VI1PR83MB0222.EURPRD83.prod.outlook.com>
 <010f0177f3d56e4b-3c8a92a0-1511-47bc-8c63-3ec32620a52e-000000@us-east-2.amazonses.com>
 <VI1PR83MB02226708EB4258DBDC9F11D1AD989@VI1PR83MB0222.EURPRD83.prod.outlook.com>
 <26d2c4be-cef7-4b76-b641-d0ec8ba2fb85@www.fastmail.com>
 <CAH6fHQ=B-XZcNAe+0FgbSJxHu3aAcTTO3G6X5XLsT-OaApcfkg@mail.gmail.com>
 <VI1PR83MB022229BDE81BE187F1AA7D8BAD979@VI1PR83MB0222.EURPRD83.prod.outlook.com>
Message-ID: <CAH6fHQ=uQH7WaCddKXZG5hQyqh8nooAYNSuEVPFq8K+qUzx+qw@mail.gmail.com>

I would have drafted a suggested change myself, but I wasn’t being
difficult when I said that I didn’t understand the motivation. This whole
conversation has really lost me.

Regarding the proposed motivation: I think that 3) is irrelevant to our
point. But 1) and 2) surprise me. I don’t believe that it’s the real
motivation: “orthogonal things are controlled by separate flags” still
reads pretty much as “because we can” to me. If it’s really the one
motivation, fine, let’s write this (but then, I think that the current
patch already contains more or less this argument). But if it really is the
motivation, I find it incredibly weak. I don’t believe that it is though.
Maybe the point is hinted in 2) there is a loss in expressiveness in the
proposal, but it’s only one aspect of the proposal, and we want to isolate
it, so that the backward-compatible part can benefit all. Is that a fair
characterisation? I honestly don’t know

This motivation that I drafted makes it sound like we are making a
fork-like extension in OverloadedRecordUpdate. We’ve usually frowned upon
fork-like extensions. Are we ok with this one?

PS: I agree with Richard and Joachim, it ought to be documented. It also
ought to be documented that it is a work in progress and positively *will*
change in the next releases.

On Thu, Mar 4, 2021 at 10:39 AM Simon Peyton Jones <simonpj at microsoft.com>
wrote:

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

From eric at seidel.io  Thu Mar  4 14:38:09 2021
From: eric at seidel.io (Eric Seidel)
Date: Thu, 04 Mar 2021 09:38:09 -0500
Subject: [ghc-steering-committee]
 =?utf-8?q?Modification_to_record_dot_syn?= =?utf-8?q?tax_propsal?=
In-Reply-To: <VI1PR83MB02226750776BFB3526A5A011AD979@VI1PR83MB0222.EURPRD83.prod.outlook.com>
References: <VI1PR83MB0222BD8EC07924531D115264AD809@VI1PR83MB0222.EURPRD83.prod.outlook.com>
 <VI1PR83MB02221D0C9C4C75606C6F9FD3AD9D9@VI1PR83MB0222.EURPRD83.prod.outlook.com>
 <010f0177defd0abc-ddb39126-a38d-4cd7-b888-81acd5493dea-000000@us-east-2.amazonses.com>
 <CAGK9nur-Q+gft7qQodSCsaK4xnvpZoXwccaNYU4VNH_keoGEOA@mail.gmail.com>
 <CAH6fHQm1OFX+0i+CVwDC_m0HdQ=fnFN0uTtjdA9zifZV3ZVJoA@mail.gmail.com>
 <VI1PR83MB022233AD140B7B84463C45D4AD9D9@VI1PR83MB0222.EURPRD83.prod.outlook.com>
 <CAH6fHQ=1Hb5jZH3Yhr-BejT2j83++iykvCZPVYC9HYMueOmHZA@mail.gmail.com>
 <CAGK9nurtqxSTdeUya415wvdswjpTm9noUnLw+WMJv06ozhoETg@mail.gmail.com>
 <VI1PR83MB02228D79560C8A731F0116D5AD9A9@VI1PR83MB0222.EURPRD83.prod.outlook.com>
 <VI1PR83MB0222FFB6BA71803975996928AD999@VI1PR83MB0222.EURPRD83.prod.outlook.com>
 <VI1PR83MB02226750776BFB3526A5A011AD979@VI1PR83MB0222.EURPRD83.prod.outlook.com>
Message-ID: <a953b43e-89dd-41c4-b6f2-24c93403498a@www.fastmail.com>

I agree with Richard and Joachim that it should be documented in the user guide. It's much better to document features with the expected level of support than to let users stumble upon them and make their own assumptions about stability.

That being said, I don't see anything in the revised proposal about the stability of OverloadedRecordUpdate. Are you saying that as part of this revision, we'll explicitly accept OverloadedRecordDot and send OverloadedRecordUpdate back for revision?

On Thu, Mar 4, 2021, at 04:46, Simon Peyton Jones via ghc-steering-committee wrote:
>  
> Friends
> 
>  
> 
> We’ve agree to accept my suggestion below.
> 
>  
> 
> But there is one point at issue: should OverloadedRecordUpdate be 
> documented in the user manual, albeit identified as a not-yet-accepted 
> feature?
> 
>  
> 
>  * Richard positively wants it in the manual
>  * Iavor positively doesn’t want it there.
>  
> 
> I don’t mind either way.
> 
>  
> 
> What do others think?  It’s not a big deal, but we owe the authors a 
> decision.  Answer by the end of the week please, and I’ll make a 
> shepherd decision based on the opinions I get.
> 
>  
> 
> Simon
> 
>  
> 
>  
> 
> *From:* Simon Peyton Jones <simonpj at microsoft.com> 
> *Sent:* 02 March 2021 12:45
> *To:* ghc-steering-committee <ghc-steering-committee at haskell.org>
> *Cc:* Simon Peyton Jones <simonpj at microsoft.com>
> *Subject:* RE: [ghc-steering-committee] Modification to record dot 
> syntax propsal
> 
>  
> 
> Friends
> 
>  
> 
> Having consulted the authors, I propose that we do this:
> 
>  
> 
>  * Proceed with OverloadedRecordDot for 9.2, exactly as in the original 
> proposal except for the extension name.
>  * Record update will remain exactly as now, in 9.2; that is, drawing 
> back from the original proposal.
>  * There may be some *code* in 9.2 that allows overloaded record 
> update, protected by OverloadedRecordUpdate, but not in the user 
> manual, and not treated as an accepted proposal.   I don’t think we 
> should ask the authors to remove it, and it will allow experimentation.
>  * Adam is leading on a revised record-update proposal. This will cover
>    * the tradeoffs between type-changing and non-type-changing update
>    * what the current record-update syntax stands for, and/or any new 
> syntax
>  
> 
> Is that acceptable to everyone?
> 
>  
> 
> Simon
> 
>  
> 
> *From:* ghc-steering-committee 
> <ghc-steering-committee-bounces at haskell.org> *On Behalf Of *Simon 
> Peyton Jones via ghc-steering-committee
> *Sent:* 01 March 2021 17:51
> *To:* Iavor Diatchki <iavor.diatchki at gmail.com>; Spiwack, Arnaud 
> <arnaud.spiwack at tweag.io>
> *Cc:* ghc-steering-committee <ghc-steering-committee at haskell.org>
> *Subject:* Re: [ghc-steering-committee] Modification to record dot 
> syntax propsal
> 
>  
> 
> I don't buy the argument of "this is already accepted", as I don't 
> think many of us had noticed that part of the proposal (I certainly 
> didn't), and I think we should be flexible enough to revisit previous 
> decisions when we notice problems with them.
> 
> I agree in principle that we can revisit decisions.   But we have to be 
> aware that it is potentially very discouraging for proposal authors to
> 
>  * propose something, 
>  * have it *extensively* debated (including this very point), 
>  * have it accepted, 
>  * implement it, 
> and then be told that the committee has changed its mind.  That’s 
> pretty bad from their point of view.
> 
>  
> 
> Still, Adam is working on a new SetField proposal, so perhaps that’s a 
> figleaf.  I’ll consult them.
> 
> 
> Simon
> 
>  
> 
>  
> 
> *From:* Iavor Diatchki <iavor.diatchki at gmail.com> 
> *Sent:* 01 March 2021 17:23
> *To:* Spiwack, Arnaud <arnaud.spiwack at tweag.io>
> *Cc:* Simon Peyton Jones <simonpj at microsoft.com>; 
> ghc-steering-committee <ghc-steering-committee at haskell.org>
> *Subject:* Re: [ghc-steering-committee] Modification to record dot 
> syntax propsal
> 
>  
> 
> Hello,
> 
>  
> 
> I think there is a strong motivation to *at least* split the 
> extensions:  with the current design, enabling the special `.` notation 
> also *disables* type changing record update, which has nothing to do 
> with the `.` notation.
> 
>  
> 
> My preference would be to:
> 
>   1. Split the original proposal into two parts: one about `.` 
> notation, the other about record update (as suggested by this proposal)
> 
>   2. Treat the `.` notation part as accepted
> 
>   3. Require changes on the record update part, so that you don't have 
> to choose between it and type changing record updates, which are quite 
> useful, and I don't think we should aim for a Haskell without them.
> 
>  
> 
> I don't buy the argument of "this is already accepted", as I don't 
> think many of us had noticed that part of the proposal (I certainly 
> didn't), and I think we should be flexible enough to revisit previous 
> decisions when we notice problems with them.
> 
>  
> 
> -Iavor
> 
>  
> 
>  
> 
>  
> 
> On Mon, Mar 1, 2021 at 1:40 AM Spiwack, Arnaud <arnaud.spiwack at tweag.io> wrote:
> 
> > Simon, all,
> 
> >  
> 
> > After reading more of the PR thread (in particular the fews posts after Simon's recommendation), I have to admit: I am thoroughly confused. I'm not sure that two people in that thread have the same motivation, end goal, or design in mind.
> 
> >  
> 
> > The motivations provided by the modified *Alternatives* section is not much more helpful (at the risk of caricaturing a little, it basically reads: “we made two extensions rather than one because we can”). Though it makes it clear that the end goal is to fold a bunch of record-related extensions into one glorious record extension (well, probably not fold them, but make a meta-extension that implies all the extensions that we've decided we like).
> 
> >  
> 
> > My starting point is that:
> 
> > - Additional extensions have a maintenance cost
> 
> > - Additional extensions impose a cognitive burden on their use
> 
> > - I expect that a new extension will break my code in the next few releases.
> 
> >  
> 
> > Based on this, I don't care how this extension or the glorious record extension are named; but if we want to have two extensions we should have a serious reason. Right now, the one reason that I see (and Iavor raised), is that the update part of `RecordDotSyntax` is not backward compatible. Is it a strong enough reason? I don't know. The only data point that I can provide is that when we discussed the original proposal, I brought it up several times, and it didn't seem very important at the time (the conversation focused on other points of the proposal).
> 
> >  
> 
> > So, I'm still reluctant. I feel that, at the very least, the motivations are not well-enough articulated in the proposal (I'll make a comment to this effect on Github when I'm done composing this email).
> 
> >  
> 
> > I appreciate that I'm in the minority here. Yet, I'm still unconvinced.
> 
> >  
> 
> > Best,
> 
> > Arnaud
> 
> >  
> 
> > On Sat, Feb 27, 2021 at 12:39 AM Simon Peyton Jones <simonpj at microsoft.com> wrote:
> 
> >> Generally, I'm not in favour in proposals which split extensions though: we already have so many extensions. Are the reasons for this split strong enough? I haven't had time to dig into the details.
> 
> >> Arnaud, happily, you don’t have to dig very deep – just read the handful of posts following my recommendation.
> 
> >>  
> 
> >> There seem to be two motivations.
> 
> >>  
> 
> >>  1. There really are two orthogonal extensions, one for r.x notation, and one for overloaded update.  Iavor likes the first but not the second.  Neil likes both.  Having separate extensions lets us experiment.
> >>  
> 
> >>  1. You suggest that changing the definition of RecordDotSyntax in a subsequent release, e.g. by subsequently making it imply NoFieldSelectors, would be fine. But it certainly imposes pain – some programs would stop compiling.  The approach offered by this proposal avoids that problem.
> >>  
> 
> >> Yes, there are lots of extensions surrounding records: NoFieldSelectors, DuplicateRecordFields, NamedFieldPuns, DisambiguateRecordFields, RecordWildCards.  It may not be pretty to divide things up so fine, but it’s not new.
> 
> >>  
> 
> >>  
> 
> >> If there are alternative suggestions, let’s hear them.
> 
> >>  
> 
> >> Simon
> 
> >>  
> 
> >> *From:* ghc-steering-committee <ghc-steering-committee-bounces at haskell.org> *On Behalf Of *Spiwack, Arnaud
> >> *Sent:* 26 February 2021 22:33
> >> *To:* Iavor Diatchki <iavor.diatchki at gmail.com>
> >> *Cc:* ghc-steering-committee <ghc-steering-committee at haskell.org>
> >> *Subject:* Re: [ghc-steering-committee] Modification to record dot syntax propsal
> 
> >>  
> 
> >>  
> 
> >>> I do think that  reusing the record update syntax for the overloaded monomorphic update is a mistake---it is not something I had noticed during our original discussion.
> 
> >>  
> 
> >> This is the one reason I can see for cutting this extension in smaller pieces. But, then again, -XOverloadedRecordUpdate would be a fork-like extension.
> 
> >>  
> 
> >> Generally, I'm not in favour in proposals which split extensions though: we already have so many extensions. Are the reasons for this split strong enough? I haven't had time to dig into the details.
> 
> >>  
> 
> >> I'm not sure that not having the design of the proposal quite finalised is a good reason, extensions mutate in their first iterations, I don't think that it's a problem.
> 
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>

From simonpj at microsoft.com  Thu Mar  4 14:53:06 2021
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Thu, 4 Mar 2021 14:53:06 +0000
Subject: [ghc-steering-committee] Modification to record dot syntax
 propsal
In-Reply-To: <a953b43e-89dd-41c4-b6f2-24c93403498a@www.fastmail.com>
References: <VI1PR83MB0222BD8EC07924531D115264AD809@VI1PR83MB0222.EURPRD83.prod.outlook.com>
 <VI1PR83MB02221D0C9C4C75606C6F9FD3AD9D9@VI1PR83MB0222.EURPRD83.prod.outlook.com>
 <010f0177defd0abc-ddb39126-a38d-4cd7-b888-81acd5493dea-000000@us-east-2.amazonses.com>
 <CAGK9nur-Q+gft7qQodSCsaK4xnvpZoXwccaNYU4VNH_keoGEOA@mail.gmail.com>
 <CAH6fHQm1OFX+0i+CVwDC_m0HdQ=fnFN0uTtjdA9zifZV3ZVJoA@mail.gmail.com>
 <VI1PR83MB022233AD140B7B84463C45D4AD9D9@VI1PR83MB0222.EURPRD83.prod.outlook.com>
 <CAH6fHQ=1Hb5jZH3Yhr-BejT2j83++iykvCZPVYC9HYMueOmHZA@mail.gmail.com>
 <CAGK9nurtqxSTdeUya415wvdswjpTm9noUnLw+WMJv06ozhoETg@mail.gmail.com>
 <VI1PR83MB02228D79560C8A731F0116D5AD9A9@VI1PR83MB0222.EURPRD83.prod.outlook.com>
 <VI1PR83MB0222FFB6BA71803975996928AD999@VI1PR83MB0222.EURPRD83.prod.outlook.com>
 <VI1PR83MB02226750776BFB3526A5A011AD979@VI1PR83MB0222.EURPRD83.prod.outlook.com>
 <a953b43e-89dd-41c4-b6f2-24c93403498a@www.fastmail.com>
Message-ID: <VI1PR83MB0222668EAF9B03C9FFBE9D8DAD979@VI1PR83MB0222.EURPRD83.prod.outlook.com>

|  That being said, I don't see anything in the revised proposal about
|  the stability of OverloadedRecordUpdate. Are you saying that as part
|  of this revision, we'll explicitly accept OverloadedRecordDot and send
|  OverloadedRecordUpdate back for revision?

We *already* accepted both, as part of accepting the earlier RecordDotSyntax proposal.   But in this round, Iavor has pushed back against OverloadedRecordUpdate.  No one else has expressed a view on this point.

But rather than debate it at length I proposed to explicitly un-accept the OverloadedRecordUpdate part of the proposal.  It'll return as part of a new record-update proposal that Adam is working on.

In the meantime OverloadedRecordUpdate will be in GHC's codebase, and (assuming that's what the majority wants) documented in the user manual, with a prominent "may change" caveat.

Does that make it clear?

Simon 

|  -----Original Message-----
|  From: ghc-steering-committee <ghc-steering-committee-
|  bounces at haskell.org> On Behalf Of Eric Seidel
|  Sent: 04 March 2021 14:38
|  To: ghc-steering-committee at haskell.org
|  Subject: Re: [ghc-steering-committee] Modification to record dot
|  syntax propsal
|  
|  I agree with Richard and Joachim that it should be documented in the
|  user guide. It's much better to document features with the expected
|  level of support than to let users stumble upon them and make their
|  own assumptions about stability.
|  
|  That being said, I don't see anything in the revised proposal about
|  the stability of OverloadedRecordUpdate. Are you saying that as part
|  of this revision, we'll explicitly accept OverloadedRecordDot and send
|  OverloadedRecordUpdate back for revision?
|  
|  On Thu, Mar 4, 2021, at 04:46, Simon Peyton Jones via ghc-steering-
|  committee wrote:
|  >
|  > Friends
|  >
|  >
|  >
|  > We've agree to accept my suggestion below.
|  >
|  >
|  >
|  > But there is one point at issue: should OverloadedRecordUpdate be
|  > documented in the user manual, albeit identified as a not-yet-
|  accepted
|  > feature?
|  >
|  >
|  >
|  >  * Richard positively wants it in the manual
|  >  * Iavor positively doesn't want it there.
|  >
|  >
|  > I don't mind either way.
|  >
|  >
|  >
|  > What do others think?  It's not a big deal, but we owe the authors a
|  > decision.  Answer by the end of the week please, and I'll make a
|  > shepherd decision based on the opinions I get.
|  >
|  >
|  >
|  > Simon
|  >
|  >
|  >
|  >
|  >
|  > *From:* Simon Peyton Jones <simonpj at microsoft.com>
|  > *Sent:* 02 March 2021 12:45
|  > *To:* ghc-steering-committee <ghc-steering-committee at haskell.org>
|  > *Cc:* Simon Peyton Jones <simonpj at microsoft.com>
|  > *Subject:* RE: [ghc-steering-committee] Modification to record dot
|  > syntax propsal
|  >
|  >
|  >
|  > Friends
|  >
|  >
|  >
|  > Having consulted the authors, I propose that we do this:
|  >
|  >
|  >
|  >  * Proceed with OverloadedRecordDot for 9.2, exactly as in the
|  > original proposal except for the extension name.
|  >  * Record update will remain exactly as now, in 9.2; that is,
|  drawing
|  > back from the original proposal.
|  >  * There may be some *code* in 9.2 that allows overloaded record
|  > update, protected by OverloadedRecordUpdate, but not in the user
|  > manual, and not treated as an accepted proposal.   I don't think we
|  > should ask the authors to remove it, and it will allow
|  experimentation.
|  >  * Adam is leading on a revised record-update proposal. This will
|  cover
|  >    * the tradeoffs between type-changing and non-type-changing
|  update
|  >    * what the current record-update syntax stands for, and/or any
|  new
|  > syntax
|  >
|  >
|  > Is that acceptable to everyone?
|  >
|  >
|  >
|  > Simon
|  >
|  >
|  >
|  > *From:* ghc-steering-committee
|  > <ghc-steering-committee-bounces at haskell.org> *On Behalf Of *Simon
|  > Peyton Jones via ghc-steering-committee
|  > *Sent:* 01 March 2021 17:51
|  > *To:* Iavor Diatchki <iavor.diatchki at gmail.com>; Spiwack, Arnaud
|  > <arnaud.spiwack at tweag.io>
|  > *Cc:* ghc-steering-committee <ghc-steering-committee at haskell.org>
|  > *Subject:* Re: [ghc-steering-committee] Modification to record dot
|  > syntax propsal
|  >
|  >
|  >
|  > I don't buy the argument of "this is already accepted", as I don't
|  > think many of us had noticed that part of the proposal (I certainly
|  > didn't), and I think we should be flexible enough to revisit
|  previous
|  > decisions when we notice problems with them.
|  >
|  > I agree in principle that we can revisit decisions.   But we have to
|  be
|  > aware that it is potentially very discouraging for proposal authors
|  to
|  >
|  >  * propose something,
|  >  * have it *extensively* debated (including this very point),
|  >  * have it accepted,
|  >  * implement it,
|  > and then be told that the committee has changed its mind.  That's
|  > pretty bad from their point of view.
|  >
|  >
|  >
|  > Still, Adam is working on a new SetField proposal, so perhaps that's
|  a
|  > figleaf.  I'll consult them.
|  >
|  >
|  > Simon
|  >
|  >
|  >
|  >
|  >
|  > *From:* Iavor Diatchki <iavor.diatchki at gmail.com>
|  > *Sent:* 01 March 2021 17:23
|  > *To:* Spiwack, Arnaud <arnaud.spiwack at tweag.io>
|  > *Cc:* Simon Peyton Jones <simonpj at microsoft.com>;
|  > ghc-steering-committee <ghc-steering-committee at haskell.org>
|  > *Subject:* Re: [ghc-steering-committee] Modification to record dot
|  > syntax propsal
|  >
|  >
|  >
|  > Hello,
|  >
|  >
|  >
|  > I think there is a strong motivation to *at least* split the
|  > extensions:  with the current design, enabling the special `.`
|  notation
|  > also *disables* type changing record update, which has nothing to do
|  > with the `.` notation.
|  >
|  >
|  >
|  > My preference would be to:
|  >
|  >   1. Split the original proposal into two parts: one about `.`
|  > notation, the other about record update (as suggested by this
|  proposal)
|  >
|  >   2. Treat the `.` notation part as accepted
|  >
|  >   3. Require changes on the record update part, so that you don't
|  have
|  > to choose between it and type changing record updates, which are
|  quite
|  > useful, and I don't think we should aim for a Haskell without them.
|  >
|  >
|  >
|  > I don't buy the argument of "this is already accepted", as I don't
|  > think many of us had noticed that part of the proposal (I certainly
|  > didn't), and I think we should be flexible enough to revisit
|  previous
|  > decisions when we notice problems with them.
|  >
|  >
|  >
|  > -Iavor
|  >
|  >
|  >
|  >
|  >
|  >
|  >
|  > On Mon, Mar 1, 2021 at 1:40 AM Spiwack, Arnaud
|  <arnaud.spiwack at tweag.io> wrote:
|  >
|  > > Simon, all,
|  >
|  > >
|  >
|  > > After reading more of the PR thread (in particular the fews posts
|  after Simon's recommendation), I have to admit: I am thoroughly
|  confused. I'm not sure that two people in that thread have the same
|  motivation, end goal, or design in mind.
|  >
|  > >
|  >
|  > > The motivations provided by the modified *Alternatives* section is
|  not much more helpful (at the risk of caricaturing a little, it
|  basically reads: "we made two extensions rather than one because we
|  can"). Though it makes it clear that the end goal is to fold a bunch
|  of record-related extensions into one glorious record extension (well,
|  probably not fold them, but make a meta-extension that implies all the
|  extensions that we've decided we like).
|  >
|  > >
|  >
|  > > My starting point is that:
|  >
|  > > - Additional extensions have a maintenance cost
|  >
|  > > - Additional extensions impose a cognitive burden on their use
|  >
|  > > - I expect that a new extension will break my code in the next few
|  releases.
|  >
|  > >
|  >
|  > > Based on this, I don't care how this extension or the glorious
|  record extension are named; but if we want to have two extensions we
|  should have a serious reason. Right now, the one reason that I see
|  (and Iavor raised), is that the update part of `RecordDotSyntax` is
|  not backward compatible. Is it a strong enough reason? I don't know.
|  The only data point that I can provide is that when we discussed the
|  original proposal, I brought it up several times, and it didn't seem
|  very important at the time (the conversation focused on other points
|  of the proposal).
|  >
|  > >
|  >
|  > > So, I'm still reluctant. I feel that, at the very least, the
|  motivations are not well-enough articulated in the proposal (I'll make
|  a comment to this effect on Github when I'm done composing this
|  email).
|  >
|  > >
|  >
|  > > I appreciate that I'm in the minority here. Yet, I'm still
|  unconvinced.
|  >
|  > >
|  >
|  > > Best,
|  >
|  > > Arnaud
|  >
|  > >
|  >
|  > > On Sat, Feb 27, 2021 at 12:39 AM Simon Peyton Jones
|  <simonpj at microsoft.com> wrote:
|  >
|  > >> Generally, I'm not in favour in proposals which split extensions
|  though: we already have so many extensions. Are the reasons for this
|  split strong enough? I haven't had time to dig into the details.
|  >
|  > >> Arnaud, happily, you don't have to dig very deep - just read the
|  handful of posts following my recommendation.
|  >
|  > >>
|  >
|  > >> There seem to be two motivations.
|  >
|  > >>
|  >
|  > >>  1. There really are two orthogonal extensions, one for r.x
|  notation, and one for overloaded update.  Iavor likes the first but
|  not the second.  Neil likes both.  Having separate extensions lets us
|  experiment.
|  > >>
|  >
|  > >>  1. You suggest that changing the definition of RecordDotSyntax
|  in a subsequent release, e.g. by subsequently making it imply
|  NoFieldSelectors, would be fine. But it certainly imposes pain - some
|  programs would stop compiling.  The approach offered by this proposal
|  avoids that problem.
|  > >>
|  >
|  > >> Yes, there are lots of extensions surrounding records:
|  NoFieldSelectors, DuplicateRecordFields, NamedFieldPuns,
|  DisambiguateRecordFields, RecordWildCards.  It may not be pretty to
|  divide things up so fine, but it's not new.
|  >
|  > >>
|  >
|  > >>
|  >
|  > >> If there are alternative suggestions, let's hear them.
|  >
|  > >>
|  >
|  > >> Simon
|  >
|  > >>
|  >
|  > >> *From:* ghc-steering-committee <ghc-steering-committee-
|  bounces at haskell.org> *On Behalf Of *Spiwack, Arnaud
|  > >> *Sent:* 26 February 2021 22:33
|  > >> *To:* Iavor Diatchki <iavor.diatchki at gmail.com>
|  > >> *Cc:* ghc-steering-committee <ghc-steering-committee at haskell.org>
|  > >> *Subject:* Re: [ghc-steering-committee] Modification to record
|  dot syntax propsal
|  >
|  > >>
|  >
|  > >>
|  >
|  > >>> I do think that  reusing the record update syntax for the
|  overloaded monomorphic update is a mistake---it is not something I had
|  noticed during our original discussion.
|  >
|  > >>
|  >
|  > >> This is the one reason I can see for cutting this extension in
|  smaller pieces. But, then again, -XOverloadedRecordUpdate would be a
|  fork-like extension.
|  >
|  > >>
|  >
|  > >> Generally, I'm not in favour in proposals which split extensions
|  though: we already have so many extensions. Are the reasons for this
|  split strong enough? I haven't had time to dig into the details.
|  >
|  > >>
|  >
|  > >> I'm not sure that not having the design of the proposal quite
|  finalised is a good reason, extensions mutate in their first
|  iterations, I don't think that it's a problem.
|  >
|  > _______________________________________________
|  > ghc-steering-committee mailing list
|  > ghc-steering-committee at haskell.org
|  >
|  https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail
|  .haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-
|  committee&amp;data=04%7C01%7Csimonpj%40microsoft.com%7C8abc00434aa94b7
|  fa98e08d8df1b5d9f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6375046
|  55938142566%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMz
|  IiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=9DGVl6oJc0%2BIQekuXf
|  zwqviiaT%2FaHZIlIk3R5aMZssA%3D&amp;reserved=0
|  >
|  _______________________________________________
|  ghc-steering-committee mailing list
|  ghc-steering-committee at haskell.org
|  https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail
|  .haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-
|  committee&amp;data=04%7C01%7Csimonpj%40microsoft.com%7C8abc00434aa94b7
|  fa98e08d8df1b5d9f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6375046
|  55938152562%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMz
|  IiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=QZlV0RrRttaiDdrQNiRB
|  vUhS6il1DydPX5cyl%2BdILbI%3D&amp;reserved=0

From arnaud.spiwack at tweag.io  Thu Mar  4 14:53:38 2021
From: arnaud.spiwack at tweag.io (Spiwack, Arnaud)
Date: Thu, 4 Mar 2021 15:53:38 +0100
Subject: [ghc-steering-committee] #403: Cleanup lexical structure,
	recommendation: accept
Message-ID: <CAH6fHQnGv72AF1PrxQhyDSNcgK0gwwaJzHYbhfc+hn44SD1+4w@mail.gmail.com>

Dear all,

As the shepherd for proposal #403 Cleanup lexical structure of numbers and
identifiers <https://github.com/ghc-proposals/ghc-proposals/pull/403>, let
me recommend acceptance.

This proposal does two things related to unicode characters

   - Codify the actual current lexing of unicode symbols, which is actually
   different from the Haskell 2010 report (in particular, only ascii digits
   are allowed in number literals)
   - Adds the possibility to use unicode letters which are neither upper
   case nor lower case (such as many asian scripts) as trailing symbols for
   identifier (as well as in String and Char literals)

It doesn't make it possible (nor close the door) to use letter-like numbers
(such as latin numerals) as identifiers, nor use non-ascii digits in number
literals.

As the title entails, it's essentially a clean up of the documentation, to
match reality. It seems quite uncontroversial.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20210304/c28500c9/attachment.html>

From arnaud.spiwack at tweag.io  Thu Mar  4 15:28:51 2021
From: arnaud.spiwack at tweag.io (Spiwack, Arnaud)
Date: Thu, 4 Mar 2021 16:28:51 +0100
Subject: [ghc-steering-committee] Modification to record dot syntax
	propsal
In-Reply-To: <VI1PR83MB0222668EAF9B03C9FFBE9D8DAD979@VI1PR83MB0222.EURPRD83.prod.outlook.com>
References: <VI1PR83MB0222BD8EC07924531D115264AD809@VI1PR83MB0222.EURPRD83.prod.outlook.com>
 <VI1PR83MB02221D0C9C4C75606C6F9FD3AD9D9@VI1PR83MB0222.EURPRD83.prod.outlook.com>
 <010f0177defd0abc-ddb39126-a38d-4cd7-b888-81acd5493dea-000000@us-east-2.amazonses.com>
 <CAGK9nur-Q+gft7qQodSCsaK4xnvpZoXwccaNYU4VNH_keoGEOA@mail.gmail.com>
 <CAH6fHQm1OFX+0i+CVwDC_m0HdQ=fnFN0uTtjdA9zifZV3ZVJoA@mail.gmail.com>
 <VI1PR83MB022233AD140B7B84463C45D4AD9D9@VI1PR83MB0222.EURPRD83.prod.outlook.com>
 <CAH6fHQ=1Hb5jZH3Yhr-BejT2j83++iykvCZPVYC9HYMueOmHZA@mail.gmail.com>
 <CAGK9nurtqxSTdeUya415wvdswjpTm9noUnLw+WMJv06ozhoETg@mail.gmail.com>
 <VI1PR83MB02228D79560C8A731F0116D5AD9A9@VI1PR83MB0222.EURPRD83.prod.outlook.com>
 <VI1PR83MB0222FFB6BA71803975996928AD999@VI1PR83MB0222.EURPRD83.prod.outlook.com>
 <VI1PR83MB02226750776BFB3526A5A011AD979@VI1PR83MB0222.EURPRD83.prod.outlook.com>
 <a953b43e-89dd-41c4-b6f2-24c93403498a@www.fastmail.com>
 <VI1PR83MB0222668EAF9B03C9FFBE9D8DAD979@VI1PR83MB0222.EURPRD83.prod.outlook.com>
Message-ID: <CAH6fHQnxM9V8jrW8AvL1tw7CUvW7FSqEqGRXN70nOGVpZBCEhQ@mail.gmail.com>

As for my part, Simon and I had a call and he cleared up the situation for
me. We came up with a piece of text that we will offer to the other to
explain the motivation behind the split. I am now fine with the change.

On Thu, Mar 4, 2021 at 3:53 PM Simon Peyton Jones via
ghc-steering-committee <ghc-steering-committee at haskell.org> wrote:

> |  That being said, I don't see anything in the revised proposal about
> |  the stability of OverloadedRecordUpdate. Are you saying that as part
> |  of this revision, we'll explicitly accept OverloadedRecordDot and send
> |  OverloadedRecordUpdate back for revision?
>
> We *already* accepted both, as part of accepting the earlier
> RecordDotSyntax proposal.   But in this round, Iavor has pushed back
> against OverloadedRecordUpdate.  No one else has expressed a view on this
> point.
>
> But rather than debate it at length I proposed to explicitly un-accept the
> OverloadedRecordUpdate part of the proposal.  It'll return as part of a new
> record-update proposal that Adam is working on.
>
> In the meantime OverloadedRecordUpdate will be in GHC's codebase, and
> (assuming that's what the majority wants) documented in the user manual,
> with a prominent "may change" caveat.
>
> Does that make it clear?
>
> Simon
>
> |  -----Original Message-----
> |  From: ghc-steering-committee <ghc-steering-committee-
> |  bounces at haskell.org> On Behalf Of Eric Seidel
> |  Sent: 04 March 2021 14:38
> |  To: ghc-steering-committee at haskell.org
> |  Subject: Re: [ghc-steering-committee] Modification to record dot
> |  syntax propsal
> |
> |  I agree with Richard and Joachim that it should be documented in the
> |  user guide. It's much better to document features with the expected
> |  level of support than to let users stumble upon them and make their
> |  own assumptions about stability.
> |
> |  That being said, I don't see anything in the revised proposal about
> |  the stability of OverloadedRecordUpdate. Are you saying that as part
> |  of this revision, we'll explicitly accept OverloadedRecordDot and send
> |  OverloadedRecordUpdate back for revision?
> |
> |  On Thu, Mar 4, 2021, at 04:46, Simon Peyton Jones via ghc-steering-
> |  committee wrote:
> |  >
> |  > Friends
> |  >
> |  >
> |  >
> |  > We've agree to accept my suggestion below.
> |  >
> |  >
> |  >
> |  > But there is one point at issue: should OverloadedRecordUpdate be
> |  > documented in the user manual, albeit identified as a not-yet-
> |  accepted
> |  > feature?
> |  >
> |  >
> |  >
> |  >  * Richard positively wants it in the manual
> |  >  * Iavor positively doesn't want it there.
> |  >
> |  >
> |  > I don't mind either way.
> |  >
> |  >
> |  >
> |  > What do others think?  It's not a big deal, but we owe the authors a
> |  > decision.  Answer by the end of the week please, and I'll make a
> |  > shepherd decision based on the opinions I get.
> |  >
> |  >
> |  >
> |  > Simon
> |  >
> |  >
> |  >
> |  >
> |  >
> |  > *From:* Simon Peyton Jones <simonpj at microsoft.com>
> |  > *Sent:* 02 March 2021 12:45
> |  > *To:* ghc-steering-committee <ghc-steering-committee at haskell.org>
> |  > *Cc:* Simon Peyton Jones <simonpj at microsoft.com>
> |  > *Subject:* RE: [ghc-steering-committee] Modification to record dot
> |  > syntax propsal
> |  >
> |  >
> |  >
> |  > Friends
> |  >
> |  >
> |  >
> |  > Having consulted the authors, I propose that we do this:
> |  >
> |  >
> |  >
> |  >  * Proceed with OverloadedRecordDot for 9.2, exactly as in the
> |  > original proposal except for the extension name.
> |  >  * Record update will remain exactly as now, in 9.2; that is,
> |  drawing
> |  > back from the original proposal.
> |  >  * There may be some *code* in 9.2 that allows overloaded record
> |  > update, protected by OverloadedRecordUpdate, but not in the user
> |  > manual, and not treated as an accepted proposal.   I don't think we
> |  > should ask the authors to remove it, and it will allow
> |  experimentation.
> |  >  * Adam is leading on a revised record-update proposal. This will
> |  cover
> |  >    * the tradeoffs between type-changing and non-type-changing
> |  update
> |  >    * what the current record-update syntax stands for, and/or any
> |  new
> |  > syntax
> |  >
> |  >
> |  > Is that acceptable to everyone?
> |  >
> |  >
> |  >
> |  > Simon
> |  >
> |  >
> |  >
> |  > *From:* ghc-steering-committee
> |  > <ghc-steering-committee-bounces at haskell.org> *On Behalf Of *Simon
> |  > Peyton Jones via ghc-steering-committee
> |  > *Sent:* 01 March 2021 17:51
> |  > *To:* Iavor Diatchki <iavor.diatchki at gmail.com>; Spiwack, Arnaud
> |  > <arnaud.spiwack at tweag.io>
> |  > *Cc:* ghc-steering-committee <ghc-steering-committee at haskell.org>
> |  > *Subject:* Re: [ghc-steering-committee] Modification to record dot
> |  > syntax propsal
> |  >
> |  >
> |  >
> |  > I don't buy the argument of "this is already accepted", as I don't
> |  > think many of us had noticed that part of the proposal (I certainly
> |  > didn't), and I think we should be flexible enough to revisit
> |  previous
> |  > decisions when we notice problems with them.
> |  >
> |  > I agree in principle that we can revisit decisions.   But we have to
> |  be
> |  > aware that it is potentially very discouraging for proposal authors
> |  to
> |  >
> |  >  * propose something,
> |  >  * have it *extensively* debated (including this very point),
> |  >  * have it accepted,
> |  >  * implement it,
> |  > and then be told that the committee has changed its mind.  That's
> |  > pretty bad from their point of view.
> |  >
> |  >
> |  >
> |  > Still, Adam is working on a new SetField proposal, so perhaps that's
> |  a
> |  > figleaf.  I'll consult them.
> |  >
> |  >
> |  > Simon
> |  >
> |  >
> |  >
> |  >
> |  >
> |  > *From:* Iavor Diatchki <iavor.diatchki at gmail.com>
> |  > *Sent:* 01 March 2021 17:23
> |  > *To:* Spiwack, Arnaud <arnaud.spiwack at tweag.io>
> |  > *Cc:* Simon Peyton Jones <simonpj at microsoft.com>;
> |  > ghc-steering-committee <ghc-steering-committee at haskell.org>
> |  > *Subject:* Re: [ghc-steering-committee] Modification to record dot
> |  > syntax propsal
> |  >
> |  >
> |  >
> |  > Hello,
> |  >
> |  >
> |  >
> |  > I think there is a strong motivation to *at least* split the
> |  > extensions:  with the current design, enabling the special `.`
> |  notation
> |  > also *disables* type changing record update, which has nothing to do
> |  > with the `.` notation.
> |  >
> |  >
> |  >
> |  > My preference would be to:
> |  >
> |  >   1. Split the original proposal into two parts: one about `.`
> |  > notation, the other about record update (as suggested by this
> |  proposal)
> |  >
> |  >   2. Treat the `.` notation part as accepted
> |  >
> |  >   3. Require changes on the record update part, so that you don't
> |  have
> |  > to choose between it and type changing record updates, which are
> |  quite
> |  > useful, and I don't think we should aim for a Haskell without them.
> |  >
> |  >
> |  >
> |  > I don't buy the argument of "this is already accepted", as I don't
> |  > think many of us had noticed that part of the proposal (I certainly
> |  > didn't), and I think we should be flexible enough to revisit
> |  previous
> |  > decisions when we notice problems with them.
> |  >
> |  >
> |  >
> |  > -Iavor
> |  >
> |  >
> |  >
> |  >
> |  >
> |  >
> |  >
> |  > On Mon, Mar 1, 2021 at 1:40 AM Spiwack, Arnaud
> |  <arnaud.spiwack at tweag.io> wrote:
> |  >
> |  > > Simon, all,
> |  >
> |  > >
> |  >
> |  > > After reading more of the PR thread (in particular the fews posts
> |  after Simon's recommendation), I have to admit: I am thoroughly
> |  confused. I'm not sure that two people in that thread have the same
> |  motivation, end goal, or design in mind.
> |  >
> |  > >
> |  >
> |  > > The motivations provided by the modified *Alternatives* section is
> |  not much more helpful (at the risk of caricaturing a little, it
> |  basically reads: "we made two extensions rather than one because we
> |  can"). Though it makes it clear that the end goal is to fold a bunch
> |  of record-related extensions into one glorious record extension (well,
> |  probably not fold them, but make a meta-extension that implies all the
> |  extensions that we've decided we like).
> |  >
> |  > >
> |  >
> |  > > My starting point is that:
> |  >
> |  > > - Additional extensions have a maintenance cost
> |  >
> |  > > - Additional extensions impose a cognitive burden on their use
> |  >
> |  > > - I expect that a new extension will break my code in the next few
> |  releases.
> |  >
> |  > >
> |  >
> |  > > Based on this, I don't care how this extension or the glorious
> |  record extension are named; but if we want to have two extensions we
> |  should have a serious reason. Right now, the one reason that I see
> |  (and Iavor raised), is that the update part of `RecordDotSyntax` is
> |  not backward compatible. Is it a strong enough reason? I don't know.
> |  The only data point that I can provide is that when we discussed the
> |  original proposal, I brought it up several times, and it didn't seem
> |  very important at the time (the conversation focused on other points
> |  of the proposal).
> |  >
> |  > >
> |  >
> |  > > So, I'm still reluctant. I feel that, at the very least, the
> |  motivations are not well-enough articulated in the proposal (I'll make
> |  a comment to this effect on Github when I'm done composing this
> |  email).
> |  >
> |  > >
> |  >
> |  > > I appreciate that I'm in the minority here. Yet, I'm still
> |  unconvinced.
> |  >
> |  > >
> |  >
> |  > > Best,
> |  >
> |  > > Arnaud
> |  >
> |  > >
> |  >
> |  > > On Sat, Feb 27, 2021 at 12:39 AM Simon Peyton Jones
> |  <simonpj at microsoft.com> wrote:
> |  >
> |  > >> Generally, I'm not in favour in proposals which split extensions
> |  though: we already have so many extensions. Are the reasons for this
> |  split strong enough? I haven't had time to dig into the details.
> |  >
> |  > >> Arnaud, happily, you don't have to dig very deep - just read the
> |  handful of posts following my recommendation.
> |  >
> |  > >>
> |  >
> |  > >> There seem to be two motivations.
> |  >
> |  > >>
> |  >
> |  > >>  1. There really are two orthogonal extensions, one for r.x
> |  notation, and one for overloaded update.  Iavor likes the first but
> |  not the second.  Neil likes both.  Having separate extensions lets us
> |  experiment.
> |  > >>
> |  >
> |  > >>  1. You suggest that changing the definition of RecordDotSyntax
> |  in a subsequent release, e.g. by subsequently making it imply
> |  NoFieldSelectors, would be fine. But it certainly imposes pain - some
> |  programs would stop compiling.  The approach offered by this proposal
> |  avoids that problem.
> |  > >>
> |  >
> |  > >> Yes, there are lots of extensions surrounding records:
> |  NoFieldSelectors, DuplicateRecordFields, NamedFieldPuns,
> |  DisambiguateRecordFields, RecordWildCards.  It may not be pretty to
> |  divide things up so fine, but it's not new.
> |  >
> |  > >>
> |  >
> |  > >>
> |  >
> |  > >> If there are alternative suggestions, let's hear them.
> |  >
> |  > >>
> |  >
> |  > >> Simon
> |  >
> |  > >>
> |  >
> |  > >> *From:* ghc-steering-committee <ghc-steering-committee-
> |  bounces at haskell.org> *On Behalf Of *Spiwack, Arnaud
> |  > >> *Sent:* 26 February 2021 22:33
> |  > >> *To:* Iavor Diatchki <iavor.diatchki at gmail.com>
> |  > >> *Cc:* ghc-steering-committee <ghc-steering-committee at haskell.org>
> |  > >> *Subject:* Re: [ghc-steering-committee] Modification to record
> |  dot syntax propsal
> |  >
> |  > >>
> |  >
> |  > >>
> |  >
> |  > >>> I do think that  reusing the record update syntax for the
> |  overloaded monomorphic update is a mistake---it is not something I had
> |  noticed during our original discussion.
> |  >
> |  > >>
> |  >
> |  > >> This is the one reason I can see for cutting this extension in
> |  smaller pieces. But, then again, -XOverloadedRecordUpdate would be a
> |  fork-like extension.
> |  >
> |  > >>
> |  >
> |  > >> Generally, I'm not in favour in proposals which split extensions
> |  though: we already have so many extensions. Are the reasons for this
> |  split strong enough? I haven't had time to dig into the details.
> |  >
> |  > >>
> |  >
> |  > >> I'm not sure that not having the design of the proposal quite
> |  finalised is a good reason, extensions mutate in their first
> |  iterations, I don't think that it's a problem.
> |  >
> |  > _______________________________________________
> |  > ghc-steering-committee mailing list
> |  > ghc-steering-committee at haskell.org
> |  >
> |  https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail
> |  .haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-
> |  committee&amp;data=04%7C01%7Csimonpj%40microsoft.com%7C8abc00434aa94b7
> |  fa98e08d8df1b5d9f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6375046
> |  55938142566%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMz
> |  IiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=9DGVl6oJc0%2BIQekuXf
> |  zwqviiaT%2FaHZIlIk3R5aMZssA%3D&amp;reserved=0
> |  >
> |  _______________________________________________
> |  ghc-steering-committee mailing list
> |  ghc-steering-committee at haskell.org
> |  https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail
> |  .haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-
> |  committee&amp;data=04%7C01%7Csimonpj%40microsoft.com%7C8abc00434aa94b7
> |  fa98e08d8df1b5d9f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6375046
> |  55938152562%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMz
> |  IiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=QZlV0RrRttaiDdrQNiRB
> |  vUhS6il1DydPX5cyl%2BdILbI%3D&amp;reserved=0
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20210304/f0d2ca37/attachment-0001.html>

From simonpj at microsoft.com  Thu Mar  4 15:34:46 2021
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Thu, 4 Mar 2021 15:34:46 +0000
Subject: [ghc-steering-committee] Modification to record dot syntax
 propsal
In-Reply-To: <CAH6fHQnxM9V8jrW8AvL1tw7CUvW7FSqEqGRXN70nOGVpZBCEhQ@mail.gmail.com>
References: <VI1PR83MB0222BD8EC07924531D115264AD809@VI1PR83MB0222.EURPRD83.prod.outlook.com>
 <VI1PR83MB02221D0C9C4C75606C6F9FD3AD9D9@VI1PR83MB0222.EURPRD83.prod.outlook.com>
 <010f0177defd0abc-ddb39126-a38d-4cd7-b888-81acd5493dea-000000@us-east-2.amazonses.com>
 <CAGK9nur-Q+gft7qQodSCsaK4xnvpZoXwccaNYU4VNH_keoGEOA@mail.gmail.com>
 <CAH6fHQm1OFX+0i+CVwDC_m0HdQ=fnFN0uTtjdA9zifZV3ZVJoA@mail.gmail.com>
 <VI1PR83MB022233AD140B7B84463C45D4AD9D9@VI1PR83MB0222.EURPRD83.prod.outlook.com>
 <CAH6fHQ=1Hb5jZH3Yhr-BejT2j83++iykvCZPVYC9HYMueOmHZA@mail.gmail.com>
 <CAGK9nurtqxSTdeUya415wvdswjpTm9noUnLw+WMJv06ozhoETg@mail.gmail.com>
 <VI1PR83MB02228D79560C8A731F0116D5AD9A9@VI1PR83MB0222.EURPRD83.prod.outlook.com>
 <VI1PR83MB0222FFB6BA71803975996928AD999@VI1PR83MB0222.EURPRD83.prod.outlook.com>
 <VI1PR83MB02226750776BFB3526A5A011AD979@VI1PR83MB0222.EURPRD83.prod.outlook.com>
 <a953b43e-89dd-41c4-b6f2-24c93403498a@www.fastmail.com>
 <VI1PR83MB0222668EAF9B03C9FFBE9D8DAD979@VI1PR83MB0222.EURPRD83.prod.outlook.com>
 <CAH6fHQnxM9V8jrW8AvL1tw7CUvW7FSqEqGRXN70nOGVpZBCEhQ@mail.gmail.com>
Message-ID: <VI1PR83MB0222043DD0FF5B7918653A7EAD979@VI1PR83MB0222.EURPRD83.prod.outlook.com>

Here's the text https://docs.google.com/document/d/1GbWAC8URaVRmj6Lkj1b10okNsVuUfO6U0qq-lrSpses/edit?usp=sharing

From: Spiwack, Arnaud <arnaud.spiwack at tweag.io>
Sent: 04 March 2021 15:29
To: Simon Peyton Jones <simonpj at microsoft.com>
Cc: Eric Seidel <eric at seidel.io>; ghc-steering-committee at 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 <ghc-steering-committee at haskell.org<mailto:ghc-steering-committee at haskell.org>> wrote:
|  That being said, I don't see anything in the revised proposal about
|  the stability of OverloadedRecordUpdate. Are you saying that as part
|  of this revision, we'll explicitly accept OverloadedRecordDot and send
|  OverloadedRecordUpdate back for revision?

We *already* accepted both, as part of accepting the earlier RecordDotSyntax proposal.   But in this round, Iavor has pushed back against OverloadedRecordUpdate.  No one else has expressed a view on this point.

But rather than debate it at length I proposed to explicitly un-accept the OverloadedRecordUpdate part of the proposal.  It'll return as part of a new record-update proposal that Adam is working on.

In the meantime OverloadedRecordUpdate will be in GHC's codebase, and (assuming that's what the majority wants) documented in the user manual, with a prominent "may change" caveat.

Does that make it clear?

Simon

|  -----Original Message-----
|  From: ghc-steering-committee <ghc-steering-committee-
|  bounces at haskell.org<mailto:bounces at haskell.org>> On Behalf Of Eric Seidel
|  Sent: 04 March 2021 14:38
|  To: ghc-steering-committee at haskell.org<mailto:ghc-steering-committee at haskell.org>
|  Subject: Re: [ghc-steering-committee] Modification to record dot
|  syntax propsal
|
|  I agree with Richard and Joachim that it should be documented in the
|  user guide. It's much better to document features with the expected
|  level of support than to let users stumble upon them and make their
|  own assumptions about stability.
|
|  That being said, I don't see anything in the revised proposal about
|  the stability of OverloadedRecordUpdate. Are you saying that as part
|  of this revision, we'll explicitly accept OverloadedRecordDot and send
|  OverloadedRecordUpdate back for revision?
|
|  On Thu, Mar 4, 2021, at 04:46, Simon Peyton Jones via ghc-steering-
|  committee wrote:
|  >
|  > Friends
|  >
|  >
|  >
|  > We've agree to accept my suggestion below.
|  >
|  >
|  >
|  > But there is one point at issue: should OverloadedRecordUpdate be
|  > documented in the user manual, albeit identified as a not-yet-
|  accepted
|  > feature?
|  >
|  >
|  >
|  >  * Richard positively wants it in the manual
|  >  * Iavor positively doesn't want it there.
|  >
|  >
|  > I don't mind either way.
|  >
|  >
|  >
|  > What do others think?  It's not a big deal, but we owe the authors a
|  > decision.  Answer by the end of the week please, and I'll make a
|  > shepherd decision based on the opinions I get.
|  >
|  >
|  >
|  > Simon
|  >
|  >
|  >
|  >
|  >
|  > *From:* Simon Peyton Jones <simonpj at microsoft.com<mailto:simonpj at microsoft.com>>
|  > *Sent:* 02 March 2021 12:45
|  > *To:* ghc-steering-committee <ghc-steering-committee at haskell.org<mailto:ghc-steering-committee at haskell.org>>
|  > *Cc:* Simon Peyton Jones <simonpj at microsoft.com<mailto:simonpj at microsoft.com>>
|  > *Subject:* RE: [ghc-steering-committee] Modification to record dot
|  > syntax propsal
|  >
|  >
|  >
|  > Friends
|  >
|  >
|  >
|  > Having consulted the authors, I propose that we do this:
|  >
|  >
|  >
|  >  * Proceed with OverloadedRecordDot for 9.2, exactly as in the
|  > original proposal except for the extension name.
|  >  * Record update will remain exactly as now, in 9.2; that is,
|  drawing
|  > back from the original proposal.
|  >  * There may be some *code* in 9.2 that allows overloaded record
|  > update, protected by OverloadedRecordUpdate, but not in the user
|  > manual, and not treated as an accepted proposal.   I don't think we
|  > should ask the authors to remove it, and it will allow
|  experimentation.
|  >  * Adam is leading on a revised record-update proposal. This will
|  cover
|  >    * the tradeoffs between type-changing and non-type-changing
|  update
|  >    * what the current record-update syntax stands for, and/or any
|  new
|  > syntax
|  >
|  >
|  > Is that acceptable to everyone?
|  >
|  >
|  >
|  > Simon
|  >
|  >
|  >
|  > *From:* ghc-steering-committee
|  > <ghc-steering-committee-bounces at haskell.org<mailto:ghc-steering-committee-bounces at haskell.org>> *On Behalf Of *Simon
|  > Peyton Jones via ghc-steering-committee
|  > *Sent:* 01 March 2021 17:51
|  > *To:* Iavor Diatchki <iavor.diatchki at gmail.com<mailto:iavor.diatchki at gmail.com>>; Spiwack, Arnaud
|  > <arnaud.spiwack at tweag.io<mailto:arnaud.spiwack at tweag.io>>
|  > *Cc:* ghc-steering-committee <ghc-steering-committee at haskell.org<mailto:ghc-steering-committee at haskell.org>>
|  > *Subject:* Re: [ghc-steering-committee] Modification to record dot
|  > syntax propsal
|  >
|  >
|  >
|  > I don't buy the argument of "this is already accepted", as I don't
|  > think many of us had noticed that part of the proposal (I certainly
|  > didn't), and I think we should be flexible enough to revisit
|  previous
|  > decisions when we notice problems with them.
|  >
|  > I agree in principle that we can revisit decisions.   But we have to
|  be
|  > aware that it is potentially very discouraging for proposal authors
|  to
|  >
|  >  * propose something,
|  >  * have it *extensively* debated (including this very point),
|  >  * have it accepted,
|  >  * implement it,
|  > and then be told that the committee has changed its mind.  That's
|  > pretty bad from their point of view.
|  >
|  >
|  >
|  > Still, Adam is working on a new SetField proposal, so perhaps that's
|  a
|  > figleaf.  I'll consult them.
|  >
|  >
|  > Simon
|  >
|  >
|  >
|  >
|  >
|  > *From:* Iavor Diatchki <iavor.diatchki at gmail.com<mailto:iavor.diatchki at gmail.com>>
|  > *Sent:* 01 March 2021 17:23
|  > *To:* Spiwack, Arnaud <arnaud.spiwack at tweag.io<mailto:arnaud.spiwack at tweag.io>>
|  > *Cc:* Simon Peyton Jones <simonpj at microsoft.com<mailto:simonpj at microsoft.com>>;
|  > ghc-steering-committee <ghc-steering-committee at haskell.org<mailto:ghc-steering-committee at haskell.org>>
|  > *Subject:* Re: [ghc-steering-committee] Modification to record dot
|  > syntax propsal
|  >
|  >
|  >
|  > Hello,
|  >
|  >
|  >
|  > I think there is a strong motivation to *at least* split the
|  > extensions:  with the current design, enabling the special `.`
|  notation
|  > also *disables* type changing record update, which has nothing to do
|  > with the `.` notation.
|  >
|  >
|  >
|  > My preference would be to:
|  >
|  >   1. Split the original proposal into two parts: one about `.`
|  > notation, the other about record update (as suggested by this
|  proposal)
|  >
|  >   2. Treat the `.` notation part as accepted
|  >
|  >   3. Require changes on the record update part, so that you don't
|  have
|  > to choose between it and type changing record updates, which are
|  quite
|  > useful, and I don't think we should aim for a Haskell without them.
|  >
|  >
|  >
|  > I don't buy the argument of "this is already accepted", as I don't
|  > think many of us had noticed that part of the proposal (I certainly
|  > didn't), and I think we should be flexible enough to revisit
|  previous
|  > decisions when we notice problems with them.
|  >
|  >
|  >
|  > -Iavor
|  >
|  >
|  >
|  >
|  >
|  >
|  >
|  > On Mon, Mar 1, 2021 at 1:40 AM Spiwack, Arnaud
|  <arnaud.spiwack at tweag.io<mailto:arnaud.spiwack at tweag.io>> wrote:
|  >
|  > > Simon, all,
|  >
|  > >
|  >
|  > > After reading more of the PR thread (in particular the fews posts
|  after Simon's recommendation), I have to admit: I am thoroughly
|  confused. I'm not sure that two people in that thread have the same
|  motivation, end goal, or design in mind.
|  >
|  > >
|  >
|  > > The motivations provided by the modified *Alternatives* section is
|  not much more helpful (at the risk of caricaturing a little, it
|  basically reads: "we made two extensions rather than one because we
|  can"). Though it makes it clear that the end goal is to fold a bunch
|  of record-related extensions into one glorious record extension (well,
|  probably not fold them, but make a meta-extension that implies all the
|  extensions that we've decided we like).
|  >
|  > >
|  >
|  > > My starting point is that:
|  >
|  > > - Additional extensions have a maintenance cost
|  >
|  > > - Additional extensions impose a cognitive burden on their use
|  >
|  > > - I expect that a new extension will break my code in the next few
|  releases.
|  >
|  > >
|  >
|  > > Based on this, I don't care how this extension or the glorious
|  record extension are named; but if we want to have two extensions we
|  should have a serious reason. Right now, the one reason that I see
|  (and Iavor raised), is that the update part of `RecordDotSyntax` is
|  not backward compatible. Is it a strong enough reason? I don't know.
|  The only data point that I can provide is that when we discussed the
|  original proposal, I brought it up several times, and it didn't seem
|  very important at the time (the conversation focused on other points
|  of the proposal).
|  >
|  > >
|  >
|  > > So, I'm still reluctant. I feel that, at the very least, the
|  motivations are not well-enough articulated in the proposal (I'll make
|  a comment to this effect on Github when I'm done composing this
|  email).
|  >
|  > >
|  >
|  > > I appreciate that I'm in the minority here. Yet, I'm still
|  unconvinced.
|  >
|  > >
|  >
|  > > Best,
|  >
|  > > Arnaud
|  >
|  > >
|  >
|  > > On Sat, Feb 27, 2021 at 12:39 AM Simon Peyton Jones
|  <simonpj at microsoft.com<mailto:simonpj at microsoft.com>> wrote:
|  >
|  > >> Generally, I'm not in favour in proposals which split extensions
|  though: we already have so many extensions. Are the reasons for this
|  split strong enough? I haven't had time to dig into the details.
|  >
|  > >> Arnaud, happily, you don't have to dig very deep - just read the
|  handful of posts following my recommendation.
|  >
|  > >>
|  >
|  > >> There seem to be two motivations.
|  >
|  > >>
|  >
|  > >>  1. There really are two orthogonal extensions, one for r.x
|  notation, and one for overloaded update.  Iavor likes the first but
|  not the second.  Neil likes both.  Having separate extensions lets us
|  experiment.
|  > >>
|  >
|  > >>  1. You suggest that changing the definition of RecordDotSyntax
|  in a subsequent release, e.g. by subsequently making it imply
|  NoFieldSelectors, would be fine. But it certainly imposes pain - some
|  programs would stop compiling.  The approach offered by this proposal
|  avoids that problem.
|  > >>
|  >
|  > >> Yes, there are lots of extensions surrounding records:
|  NoFieldSelectors, DuplicateRecordFields, NamedFieldPuns,
|  DisambiguateRecordFields, RecordWildCards.  It may not be pretty to
|  divide things up so fine, but it's not new.
|  >
|  > >>
|  >
|  > >>
|  >
|  > >> If there are alternative suggestions, let's hear them.
|  >
|  > >>
|  >
|  > >> Simon
|  >
|  > >>
|  >
|  > >> *From:* ghc-steering-committee <ghc-steering-committee-
|  bounces at haskell.org<mailto:bounces at haskell.org>> *On Behalf Of *Spiwack, Arnaud
|  > >> *Sent:* 26 February 2021 22:33
|  > >> *To:* Iavor Diatchki <iavor.diatchki at gmail.com<mailto:iavor.diatchki at gmail.com>>
|  > >> *Cc:* ghc-steering-committee <ghc-steering-committee at haskell.org<mailto:ghc-steering-committee at haskell.org>>
|  > >> *Subject:* Re: [ghc-steering-committee] Modification to record
|  dot syntax propsal
|  >
|  > >>
|  >
|  > >>
|  >
|  > >>> I do think that  reusing the record update syntax for the
|  overloaded monomorphic update is a mistake---it is not something I had
|  noticed during our original discussion.
|  >
|  > >>
|  >
|  > >> This is the one reason I can see for cutting this extension in
|  smaller pieces. But, then again, -XOverloadedRecordUpdate would be a
|  fork-like extension.
|  >
|  > >>
|  >
|  > >> Generally, I'm not in favour in proposals which split extensions
|  though: we already have so many extensions. Are the reasons for this
|  split strong enough? I haven't had time to dig into the details.
|  >
|  > >>
|  >
|  > >> I'm not sure that not having the design of the proposal quite
|  finalised is a good reason, extensions mutate in their first
|  iterations, I don't think that it's a problem.
|  >
|  > _______________________________________________
|  > ghc-steering-committee mailing list
|  > ghc-steering-committee at haskell.org<mailto:ghc-steering-committee at 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%7Cc9fd0d48bfb0488ab1f208d8df225bdf%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637504685977282748%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=mJwXqs%2FBs3qhnroUA%2FHLmBF8Y2hgNf8Ha65v%2BuWWotI%3D&reserved=0>%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-
|  committee&amp;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%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&amp;sdata=9DGVl6oJc0%2BIQekuXf
|  zwqviiaT%2FaHZIlIk3R5aMZssA%3D&amp;reserved=0
|  >
|  _______________________________________________
|  ghc-steering-committee mailing list
|  ghc-steering-committee at haskell.org<mailto:ghc-steering-committee at 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%7Cc9fd0d48bfb0488ab1f208d8df225bdf%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637504685977302733%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=8851cSrXEPVuoeqJJlFtCM%2BVNJhT%2BhvPXfmTY9sm4mk%3D&reserved=0>%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-
|  committee&amp;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%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&amp;sdata=QZlV0RrRttaiDdrQNiRB
|  vUhS6il1DydPX5cyl%2BdILbI%3D&amp;reserved=0
_______________________________________________
ghc-steering-committee mailing list
ghc-steering-committee at haskell.org<mailto:ghc-steering-committee at haskell.org>
https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committee&data=04%7C01%7Csimonpj%40microsoft.com%7Cc9fd0d48bfb0488ab1f208d8df225bdf%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637504685977312732%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=eqlY43l%2Bma8Vl3hQt6gqWmdUEkGF9xkCMbbBvcbK40w%3D&reserved=0>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20210304/6e90e462/attachment-0001.html>

From eric at seidel.io  Thu Mar  4 17:59:03 2021
From: eric at seidel.io (Eric Seidel)
Date: Thu, 04 Mar 2021 12:59:03 -0500
Subject: [ghc-steering-committee]
 =?utf-8?q?Modification_to_record_dot_syn?= =?utf-8?q?tax_propsal?=
In-Reply-To: <VI1PR83MB0222668EAF9B03C9FFBE9D8DAD979@VI1PR83MB0222.EURPRD83.prod.outlook.com>
References: <VI1PR83MB0222BD8EC07924531D115264AD809@VI1PR83MB0222.EURPRD83.prod.outlook.com>
 <VI1PR83MB02221D0C9C4C75606C6F9FD3AD9D9@VI1PR83MB0222.EURPRD83.prod.outlook.com>
 <010f0177defd0abc-ddb39126-a38d-4cd7-b888-81acd5493dea-000000@us-east-2.amazonses.com>
 <CAGK9nur-Q+gft7qQodSCsaK4xnvpZoXwccaNYU4VNH_keoGEOA@mail.gmail.com>
 <CAH6fHQm1OFX+0i+CVwDC_m0HdQ=fnFN0uTtjdA9zifZV3ZVJoA@mail.gmail.com>
 <VI1PR83MB022233AD140B7B84463C45D4AD9D9@VI1PR83MB0222.EURPRD83.prod.outlook.com>
 <CAH6fHQ=1Hb5jZH3Yhr-BejT2j83++iykvCZPVYC9HYMueOmHZA@mail.gmail.com>
 <CAGK9nurtqxSTdeUya415wvdswjpTm9noUnLw+WMJv06ozhoETg@mail.gmail.com>
 <VI1PR83MB02228D79560C8A731F0116D5AD9A9@VI1PR83MB0222.EURPRD83.prod.outlook.com>
 <VI1PR83MB0222FFB6BA71803975996928AD999@VI1PR83MB0222.EURPRD83.prod.outlook.com>
 <VI1PR83MB02226750776BFB3526A5A011AD979@VI1PR83MB0222.EURPRD83.prod.outlook.com>
 <a953b43e-89dd-41c4-b6f2-24c93403498a@www.fastmail.com>
 <VI1PR83MB0222668EAF9B03C9FFBE9D8DAD979@VI1PR83MB0222.EURPRD83.prod.outlook.com>
Message-ID: <a41e6ca0-e830-4268-a82c-c79bc4b8d765@www.fastmail.com>

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 at haskell.org> On Behalf Of Eric Seidel
> |  Sent: 04 March 2021 14:38
> |  To: ghc-steering-committee at haskell.org
> |  Subject: Re: [ghc-steering-committee] Modification to record dot
> |  syntax propsal
> |  
> |  I agree with Richard and Joachim that it should be documented in the
> |  user guide. It's much better to document features with the expected
> |  level of support than to let users stumble upon them and make their
> |  own assumptions about stability.
> |  
> |  That being said, I don't see anything in the revised proposal about
> |  the stability of OverloadedRecordUpdate. Are you saying that as part
> |  of this revision, we'll explicitly accept OverloadedRecordDot and send
> |  OverloadedRecordUpdate back for revision?
> |  
> |  On Thu, Mar 4, 2021, at 04:46, Simon Peyton Jones via ghc-steering-
> |  committee wrote:
> |  >
> |  > Friends
> |  >
> |  >
> |  >
> |  > We've agree to accept my suggestion below.
> |  >
> |  >
> |  >
> |  > But there is one point at issue: should OverloadedRecordUpdate be
> |  > documented in the user manual, albeit identified as a not-yet-
> |  accepted
> |  > feature?
> |  >
> |  >
> |  >
> |  >  * Richard positively wants it in the manual
> |  >  * Iavor positively doesn't want it there.
> |  >
> |  >
> |  > I don't mind either way.
> |  >
> |  >
> |  >
> |  > What do others think?  It's not a big deal, but we owe the authors a
> |  > decision.  Answer by the end of the week please, and I'll make a
> |  > shepherd decision based on the opinions I get.
> |  >
> |  >
> |  >
> |  > Simon
> |  >
> |  >
> |  >
> |  >
> |  >
> |  > *From:* Simon Peyton Jones <simonpj at microsoft.com>
> |  > *Sent:* 02 March 2021 12:45
> |  > *To:* ghc-steering-committee <ghc-steering-committee at haskell.org>
> |  > *Cc:* Simon Peyton Jones <simonpj at microsoft.com>
> |  > *Subject:* RE: [ghc-steering-committee] Modification to record dot
> |  > syntax propsal
> |  >
> |  >
> |  >
> |  > Friends
> |  >
> |  >
> |  >
> |  > Having consulted the authors, I propose that we do this:
> |  >
> |  >
> |  >
> |  >  * Proceed with OverloadedRecordDot for 9.2, exactly as in the
> |  > original proposal except for the extension name.
> |  >  * Record update will remain exactly as now, in 9.2; that is,
> |  drawing
> |  > back from the original proposal.
> |  >  * There may be some *code* in 9.2 that allows overloaded record
> |  > update, protected by OverloadedRecordUpdate, but not in the user
> |  > manual, and not treated as an accepted proposal.   I don't think we
> |  > should ask the authors to remove it, and it will allow
> |  experimentation.
> |  >  * Adam is leading on a revised record-update proposal. This will
> |  cover
> |  >    * the tradeoffs between type-changing and non-type-changing
> |  update
> |  >    * what the current record-update syntax stands for, and/or any
> |  new
> |  > syntax
> |  >
> |  >
> |  > Is that acceptable to everyone?
> |  >
> |  >
> |  >
> |  > Simon
> |  >
> |  >
> |  >
> |  > *From:* ghc-steering-committee
> |  > <ghc-steering-committee-bounces at haskell.org> *On Behalf Of *Simon
> |  > Peyton Jones via ghc-steering-committee
> |  > *Sent:* 01 March 2021 17:51
> |  > *To:* Iavor Diatchki <iavor.diatchki at gmail.com>; Spiwack, Arnaud
> |  > <arnaud.spiwack at tweag.io>
> |  > *Cc:* ghc-steering-committee <ghc-steering-committee at haskell.org>
> |  > *Subject:* Re: [ghc-steering-committee] Modification to record dot
> |  > syntax propsal
> |  >
> |  >
> |  >
> |  > I don't buy the argument of "this is already accepted", as I don't
> |  > think many of us had noticed that part of the proposal (I certainly
> |  > didn't), and I think we should be flexible enough to revisit
> |  previous
> |  > decisions when we notice problems with them.
> |  >
> |  > I agree in principle that we can revisit decisions.   But we have to
> |  be
> |  > aware that it is potentially very discouraging for proposal authors
> |  to
> |  >
> |  >  * propose something,
> |  >  * have it *extensively* debated (including this very point),
> |  >  * have it accepted,
> |  >  * implement it,
> |  > and then be told that the committee has changed its mind.  That's
> |  > pretty bad from their point of view.
> |  >
> |  >
> |  >
> |  > Still, Adam is working on a new SetField proposal, so perhaps that's
> |  a
> |  > figleaf.  I'll consult them.
> |  >
> |  >
> |  > Simon
> |  >
> |  >
> |  >
> |  >
> |  >
> |  > *From:* Iavor Diatchki <iavor.diatchki at gmail.com>
> |  > *Sent:* 01 March 2021 17:23
> |  > *To:* Spiwack, Arnaud <arnaud.spiwack at tweag.io>
> |  > *Cc:* Simon Peyton Jones <simonpj at microsoft.com>;
> |  > ghc-steering-committee <ghc-steering-committee at haskell.org>
> |  > *Subject:* Re: [ghc-steering-committee] Modification to record dot
> |  > syntax propsal
> |  >
> |  >
> |  >
> |  > Hello,
> |  >
> |  >
> |  >
> |  > I think there is a strong motivation to *at least* split the
> |  > extensions:  with the current design, enabling the special `.`
> |  notation
> |  > also *disables* type changing record update, which has nothing to do
> |  > with the `.` notation.
> |  >
> |  >
> |  >
> |  > My preference would be to:
> |  >
> |  >   1. Split the original proposal into two parts: one about `.`
> |  > notation, the other about record update (as suggested by this
> |  proposal)
> |  >
> |  >   2. Treat the `.` notation part as accepted
> |  >
> |  >   3. Require changes on the record update part, so that you don't
> |  have
> |  > to choose between it and type changing record updates, which are
> |  quite
> |  > useful, and I don't think we should aim for a Haskell without them.
> |  >
> |  >
> |  >
> |  > I don't buy the argument of "this is already accepted", as I don't
> |  > think many of us had noticed that part of the proposal (I certainly
> |  > didn't), and I think we should be flexible enough to revisit
> |  previous
> |  > decisions when we notice problems with them.
> |  >
> |  >
> |  >
> |  > -Iavor
> |  >
> |  >
> |  >
> |  >
> |  >
> |  >
> |  >
> |  > On Mon, Mar 1, 2021 at 1:40 AM Spiwack, Arnaud
> |  <arnaud.spiwack at tweag.io> wrote:
> |  >
> |  > > Simon, all,
> |  >
> |  > >
> |  >
> |  > > After reading more of the PR thread (in particular the fews posts
> |  after Simon's recommendation), I have to admit: I am thoroughly
> |  confused. I'm not sure that two people in that thread have the same
> |  motivation, end goal, or design in mind.
> |  >
> |  > >
> |  >
> |  > > The motivations provided by the modified *Alternatives* section is
> |  not much more helpful (at the risk of caricaturing a little, it
> |  basically reads: "we made two extensions rather than one because we
> |  can"). Though it makes it clear that the end goal is to fold a bunch
> |  of record-related extensions into one glorious record extension (well,
> |  probably not fold them, but make a meta-extension that implies all the
> |  extensions that we've decided we like).
> |  >
> |  > >
> |  >
> |  > > My starting point is that:
> |  >
> |  > > - Additional extensions have a maintenance cost
> |  >
> |  > > - Additional extensions impose a cognitive burden on their use
> |  >
> |  > > - I expect that a new extension will break my code in the next few
> |  releases.
> |  >
> |  > >
> |  >
> |  > > Based on this, I don't care how this extension or the glorious
> |  record extension are named; but if we want to have two extensions we
> |  should have a serious reason. Right now, the one reason that I see
> |  (and Iavor raised), is that the update part of `RecordDotSyntax` is
> |  not backward compatible. Is it a strong enough reason? I don't know.
> |  The only data point that I can provide is that when we discussed the
> |  original proposal, I brought it up several times, and it didn't seem
> |  very important at the time (the conversation focused on other points
> |  of the proposal).
> |  >
> |  > >
> |  >
> |  > > So, I'm still reluctant. I feel that, at the very least, the
> |  motivations are not well-enough articulated in the proposal (I'll make
> |  a comment to this effect on Github when I'm done composing this
> |  email).
> |  >
> |  > >
> |  >
> |  > > I appreciate that I'm in the minority here. Yet, I'm still
> |  unconvinced.
> |  >
> |  > >
> |  >
> |  > > Best,
> |  >
> |  > > Arnaud
> |  >
> |  > >
> |  >
> |  > > On Sat, Feb 27, 2021 at 12:39 AM Simon Peyton Jones
> |  <simonpj at microsoft.com> wrote:
> |  >
> |  > >> Generally, I'm not in favour in proposals which split extensions
> |  though: we already have so many extensions. Are the reasons for this
> |  split strong enough? I haven't had time to dig into the details.
> |  >
> |  > >> Arnaud, happily, you don't have to dig very deep - just read the
> |  handful of posts following my recommendation.
> |  >
> |  > >>
> |  >
> |  > >> There seem to be two motivations.
> |  >
> |  > >>
> |  >
> |  > >>  1. There really are two orthogonal extensions, one for r.x
> |  notation, and one for overloaded update.  Iavor likes the first but
> |  not the second.  Neil likes both.  Having separate extensions lets us
> |  experiment.
> |  > >>
> |  >
> |  > >>  1. You suggest that changing the definition of RecordDotSyntax
> |  in a subsequent release, e.g. by subsequently making it imply
> |  NoFieldSelectors, would be fine. But it certainly imposes pain - some
> |  programs would stop compiling.  The approach offered by this proposal
> |  avoids that problem.
> |  > >>
> |  >
> |  > >> Yes, there are lots of extensions surrounding records:
> |  NoFieldSelectors, DuplicateRecordFields, NamedFieldPuns,
> |  DisambiguateRecordFields, RecordWildCards.  It may not be pretty to
> |  divide things up so fine, but it's not new.
> |  >
> |  > >>
> |  >
> |  > >>
> |  >
> |  > >> If there are alternative suggestions, let's hear them.
> |  >
> |  > >>
> |  >
> |  > >> Simon
> |  >
> |  > >>
> |  >
> |  > >> *From:* ghc-steering-committee <ghc-steering-committee-
> |  bounces at haskell.org> *On Behalf Of *Spiwack, Arnaud
> |  > >> *Sent:* 26 February 2021 22:33
> |  > >> *To:* Iavor Diatchki <iavor.diatchki at gmail.com>
> |  > >> *Cc:* ghc-steering-committee <ghc-steering-committee at haskell.org>
> |  > >> *Subject:* Re: [ghc-steering-committee] Modification to record
> |  dot syntax propsal
> |  >
> |  > >>
> |  >
> |  > >>
> |  >
> |  > >>> I do think that  reusing the record update syntax for the
> |  overloaded monomorphic update is a mistake---it is not something I had
> |  noticed during our original discussion.
> |  >
> |  > >>
> |  >
> |  > >> This is the one reason I can see for cutting this extension in
> |  smaller pieces. But, then again, -XOverloadedRecordUpdate would be a
> |  fork-like extension.
> |  >
> |  > >>
> |  >
> |  > >> Generally, I'm not in favour in proposals which split extensions
> |  though: we already have so many extensions. Are the reasons for this
> |  split strong enough? I haven't had time to dig into the details.
> |  >
> |  > >>
> |  >
> |  > >> I'm not sure that not having the design of the proposal quite
> |  finalised is a good reason, extensions mutate in their first
> |  iterations, I don't think that it's a problem.
> |  >
> |  > _______________________________________________
> |  > ghc-steering-committee mailing list
> |  > ghc-steering-committee at haskell.org
> |  >
> |  https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail
> |  .haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-
> |  committee&amp;data=04%7C01%7Csimonpj%40microsoft.com%7C8abc00434aa94b7
> |  fa98e08d8df1b5d9f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6375046
> |  55938142566%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMz
> |  IiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=9DGVl6oJc0%2BIQekuXf
> |  zwqviiaT%2FaHZIlIk3R5aMZssA%3D&amp;reserved=0
> |  >
> |  _______________________________________________
> |  ghc-steering-committee mailing list
> |  ghc-steering-committee at haskell.org
> |  https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail
> |  .haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-
> |  committee&amp;data=04%7C01%7Csimonpj%40microsoft.com%7C8abc00434aa94b7
> |  fa98e08d8df1b5d9f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6375046
> |  55938152562%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMz
> |  IiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=QZlV0RrRttaiDdrQNiRB
> |  vUhS6il1DydPX5cyl%2BdILbI%3D&amp;reserved=0
>

From iavor.diatchki at gmail.com  Thu Mar  4 19:03:41 2021
From: iavor.diatchki at gmail.com (Iavor Diatchki)
Date: Thu, 4 Mar 2021 11:03:41 -0800
Subject: [ghc-steering-committee] Modification to record dot syntax
	propsal
In-Reply-To: <a41e6ca0-e830-4268-a82c-c79bc4b8d765@www.fastmail.com>
References: <VI1PR83MB0222BD8EC07924531D115264AD809@VI1PR83MB0222.EURPRD83.prod.outlook.com>
 <VI1PR83MB02221D0C9C4C75606C6F9FD3AD9D9@VI1PR83MB0222.EURPRD83.prod.outlook.com>
 <010f0177defd0abc-ddb39126-a38d-4cd7-b888-81acd5493dea-000000@us-east-2.amazonses.com>
 <CAGK9nur-Q+gft7qQodSCsaK4xnvpZoXwccaNYU4VNH_keoGEOA@mail.gmail.com>
 <CAH6fHQm1OFX+0i+CVwDC_m0HdQ=fnFN0uTtjdA9zifZV3ZVJoA@mail.gmail.com>
 <VI1PR83MB022233AD140B7B84463C45D4AD9D9@VI1PR83MB0222.EURPRD83.prod.outlook.com>
 <CAH6fHQ=1Hb5jZH3Yhr-BejT2j83++iykvCZPVYC9HYMueOmHZA@mail.gmail.com>
 <CAGK9nurtqxSTdeUya415wvdswjpTm9noUnLw+WMJv06ozhoETg@mail.gmail.com>
 <VI1PR83MB02228D79560C8A731F0116D5AD9A9@VI1PR83MB0222.EURPRD83.prod.outlook.com>
 <VI1PR83MB0222FFB6BA71803975996928AD999@VI1PR83MB0222.EURPRD83.prod.outlook.com>
 <VI1PR83MB02226750776BFB3526A5A011AD979@VI1PR83MB0222.EURPRD83.prod.outlook.com>
 <a953b43e-89dd-41c4-b6f2-24c93403498a@www.fastmail.com>
 <VI1PR83MB0222668EAF9B03C9FFBE9D8DAD979@VI1PR83MB0222.EURPRD83.prod.outlook.com>
 <a41e6ca0-e830-4268-a82c-c79bc4b8d765@www.fastmail.com>
Message-ID: <CAGK9nuoy3cbiESa2goLzzOoYxDMXNKm14bGSxmKDRerbJcA7Ng@mail.gmail.com>

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 <eric at 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 <ghc-steering-committee-
> > |  bounces at haskell.org> On Behalf Of Eric Seidel
> > |  Sent: 04 March 2021 14:38
> > |  To: ghc-steering-committee at haskell.org
> > |  Subject: Re: [ghc-steering-committee] Modification to record dot
> > |  syntax propsal
> > |
> > |  I agree with Richard and Joachim that it should be documented in the
> > |  user guide. It's much better to document features with the expected
> > |  level of support than to let users stumble upon them and make their
> > |  own assumptions about stability.
> > |
> > |  That being said, I don't see anything in the revised proposal about
> > |  the stability of OverloadedRecordUpdate. Are you saying that as part
> > |  of this revision, we'll explicitly accept OverloadedRecordDot and send
> > |  OverloadedRecordUpdate back for revision?
> > |
> > |  On Thu, Mar 4, 2021, at 04:46, Simon Peyton Jones via ghc-steering-
> > |  committee wrote:
> > |  >
> > |  > Friends
> > |  >
> > |  >
> > |  >
> > |  > We've agree to accept my suggestion below.
> > |  >
> > |  >
> > |  >
> > |  > But there is one point at issue: should OverloadedRecordUpdate be
> > |  > documented in the user manual, albeit identified as a not-yet-
> > |  accepted
> > |  > feature?
> > |  >
> > |  >
> > |  >
> > |  >  * Richard positively wants it in the manual
> > |  >  * Iavor positively doesn't want it there.
> > |  >
> > |  >
> > |  > I don't mind either way.
> > |  >
> > |  >
> > |  >
> > |  > What do others think?  It's not a big deal, but we owe the authors a
> > |  > decision.  Answer by the end of the week please, and I'll make a
> > |  > shepherd decision based on the opinions I get.
> > |  >
> > |  >
> > |  >
> > |  > Simon
> > |  >
> > |  >
> > |  >
> > |  >
> > |  >
> > |  > *From:* Simon Peyton Jones <simonpj at microsoft.com>
> > |  > *Sent:* 02 March 2021 12:45
> > |  > *To:* ghc-steering-committee <ghc-steering-committee at haskell.org>
> > |  > *Cc:* Simon Peyton Jones <simonpj at microsoft.com>
> > |  > *Subject:* RE: [ghc-steering-committee] Modification to record dot
> > |  > syntax propsal
> > |  >
> > |  >
> > |  >
> > |  > Friends
> > |  >
> > |  >
> > |  >
> > |  > Having consulted the authors, I propose that we do this:
> > |  >
> > |  >
> > |  >
> > |  >  * Proceed with OverloadedRecordDot for 9.2, exactly as in the
> > |  > original proposal except for the extension name.
> > |  >  * Record update will remain exactly as now, in 9.2; that is,
> > |  drawing
> > |  > back from the original proposal.
> > |  >  * There may be some *code* in 9.2 that allows overloaded record
> > |  > update, protected by OverloadedRecordUpdate, but not in the user
> > |  > manual, and not treated as an accepted proposal.   I don't think we
> > |  > should ask the authors to remove it, and it will allow
> > |  experimentation.
> > |  >  * Adam is leading on a revised record-update proposal. This will
> > |  cover
> > |  >    * the tradeoffs between type-changing and non-type-changing
> > |  update
> > |  >    * what the current record-update syntax stands for, and/or any
> > |  new
> > |  > syntax
> > |  >
> > |  >
> > |  > Is that acceptable to everyone?
> > |  >
> > |  >
> > |  >
> > |  > Simon
> > |  >
> > |  >
> > |  >
> > |  > *From:* ghc-steering-committee
> > |  > <ghc-steering-committee-bounces at haskell.org> *On Behalf Of *Simon
> > |  > Peyton Jones via ghc-steering-committee
> > |  > *Sent:* 01 March 2021 17:51
> > |  > *To:* Iavor Diatchki <iavor.diatchki at gmail.com>; Spiwack, Arnaud
> > |  > <arnaud.spiwack at tweag.io>
> > |  > *Cc:* ghc-steering-committee <ghc-steering-committee at haskell.org>
> > |  > *Subject:* Re: [ghc-steering-committee] Modification to record dot
> > |  > syntax propsal
> > |  >
> > |  >
> > |  >
> > |  > I don't buy the argument of "this is already accepted", as I don't
> > |  > think many of us had noticed that part of the proposal (I certainly
> > |  > didn't), and I think we should be flexible enough to revisit
> > |  previous
> > |  > decisions when we notice problems with them.
> > |  >
> > |  > I agree in principle that we can revisit decisions.   But we have to
> > |  be
> > |  > aware that it is potentially very discouraging for proposal authors
> > |  to
> > |  >
> > |  >  * propose something,
> > |  >  * have it *extensively* debated (including this very point),
> > |  >  * have it accepted,
> > |  >  * implement it,
> > |  > and then be told that the committee has changed its mind.  That's
> > |  > pretty bad from their point of view.
> > |  >
> > |  >
> > |  >
> > |  > Still, Adam is working on a new SetField proposal, so perhaps that's
> > |  a
> > |  > figleaf.  I'll consult them.
> > |  >
> > |  >
> > |  > Simon
> > |  >
> > |  >
> > |  >
> > |  >
> > |  >
> > |  > *From:* Iavor Diatchki <iavor.diatchki at gmail.com>
> > |  > *Sent:* 01 March 2021 17:23
> > |  > *To:* Spiwack, Arnaud <arnaud.spiwack at tweag.io>
> > |  > *Cc:* Simon Peyton Jones <simonpj at microsoft.com>;
> > |  > ghc-steering-committee <ghc-steering-committee at haskell.org>
> > |  > *Subject:* Re: [ghc-steering-committee] Modification to record dot
> > |  > syntax propsal
> > |  >
> > |  >
> > |  >
> > |  > Hello,
> > |  >
> > |  >
> > |  >
> > |  > I think there is a strong motivation to *at least* split the
> > |  > extensions:  with the current design, enabling the special `.`
> > |  notation
> > |  > also *disables* type changing record update, which has nothing to do
> > |  > with the `.` notation.
> > |  >
> > |  >
> > |  >
> > |  > My preference would be to:
> > |  >
> > |  >   1. Split the original proposal into two parts: one about `.`
> > |  > notation, the other about record update (as suggested by this
> > |  proposal)
> > |  >
> > |  >   2. Treat the `.` notation part as accepted
> > |  >
> > |  >   3. Require changes on the record update part, so that you don't
> > |  have
> > |  > to choose between it and type changing record updates, which are
> > |  quite
> > |  > useful, and I don't think we should aim for a Haskell without them.
> > |  >
> > |  >
> > |  >
> > |  > I don't buy the argument of "this is already accepted", as I don't
> > |  > think many of us had noticed that part of the proposal (I certainly
> > |  > didn't), and I think we should be flexible enough to revisit
> > |  previous
> > |  > decisions when we notice problems with them.
> > |  >
> > |  >
> > |  >
> > |  > -Iavor
> > |  >
> > |  >
> > |  >
> > |  >
> > |  >
> > |  >
> > |  >
> > |  > On Mon, Mar 1, 2021 at 1:40 AM Spiwack, Arnaud
> > |  <arnaud.spiwack at tweag.io> wrote:
> > |  >
> > |  > > Simon, all,
> > |  >
> > |  > >
> > |  >
> > |  > > After reading more of the PR thread (in particular the fews posts
> > |  after Simon's recommendation), I have to admit: I am thoroughly
> > |  confused. I'm not sure that two people in that thread have the same
> > |  motivation, end goal, or design in mind.
> > |  >
> > |  > >
> > |  >
> > |  > > The motivations provided by the modified *Alternatives* section is
> > |  not much more helpful (at the risk of caricaturing a little, it
> > |  basically reads: "we made two extensions rather than one because we
> > |  can"). Though it makes it clear that the end goal is to fold a bunch
> > |  of record-related extensions into one glorious record extension (well,
> > |  probably not fold them, but make a meta-extension that implies all the
> > |  extensions that we've decided we like).
> > |  >
> > |  > >
> > |  >
> > |  > > My starting point is that:
> > |  >
> > |  > > - Additional extensions have a maintenance cost
> > |  >
> > |  > > - Additional extensions impose a cognitive burden on their use
> > |  >
> > |  > > - I expect that a new extension will break my code in the next few
> > |  releases.
> > |  >
> > |  > >
> > |  >
> > |  > > Based on this, I don't care how this extension or the glorious
> > |  record extension are named; but if we want to have two extensions we
> > |  should have a serious reason. Right now, the one reason that I see
> > |  (and Iavor raised), is that the update part of `RecordDotSyntax` is
> > |  not backward compatible. Is it a strong enough reason? I don't know.
> > |  The only data point that I can provide is that when we discussed the
> > |  original proposal, I brought it up several times, and it didn't seem
> > |  very important at the time (the conversation focused on other points
> > |  of the proposal).
> > |  >
> > |  > >
> > |  >
> > |  > > So, I'm still reluctant. I feel that, at the very least, the
> > |  motivations are not well-enough articulated in the proposal (I'll make
> > |  a comment to this effect on Github when I'm done composing this
> > |  email).
> > |  >
> > |  > >
> > |  >
> > |  > > I appreciate that I'm in the minority here. Yet, I'm still
> > |  unconvinced.
> > |  >
> > |  > >
> > |  >
> > |  > > Best,
> > |  >
> > |  > > Arnaud
> > |  >
> > |  > >
> > |  >
> > |  > > On Sat, Feb 27, 2021 at 12:39 AM Simon Peyton Jones
> > |  <simonpj at microsoft.com> wrote:
> > |  >
> > |  > >> Generally, I'm not in favour in proposals which split extensions
> > |  though: we already have so many extensions. Are the reasons for this
> > |  split strong enough? I haven't had time to dig into the details.
> > |  >
> > |  > >> Arnaud, happily, you don't have to dig very deep - just read the
> > |  handful of posts following my recommendation.
> > |  >
> > |  > >>
> > |  >
> > |  > >> There seem to be two motivations.
> > |  >
> > |  > >>
> > |  >
> > |  > >>  1. There really are two orthogonal extensions, one for r.x
> > |  notation, and one for overloaded update.  Iavor likes the first but
> > |  not the second.  Neil likes both.  Having separate extensions lets us
> > |  experiment.
> > |  > >>
> > |  >
> > |  > >>  1. You suggest that changing the definition of RecordDotSyntax
> > |  in a subsequent release, e.g. by subsequently making it imply
> > |  NoFieldSelectors, would be fine. But it certainly imposes pain - some
> > |  programs would stop compiling.  The approach offered by this proposal
> > |  avoids that problem.
> > |  > >>
> > |  >
> > |  > >> Yes, there are lots of extensions surrounding records:
> > |  NoFieldSelectors, DuplicateRecordFields, NamedFieldPuns,
> > |  DisambiguateRecordFields, RecordWildCards.  It may not be pretty to
> > |  divide things up so fine, but it's not new.
> > |  >
> > |  > >>
> > |  >
> > |  > >>
> > |  >
> > |  > >> If there are alternative suggestions, let's hear them.
> > |  >
> > |  > >>
> > |  >
> > |  > >> Simon
> > |  >
> > |  > >>
> > |  >
> > |  > >> *From:* ghc-steering-committee <ghc-steering-committee-
> > |  bounces at haskell.org> *On Behalf Of *Spiwack, Arnaud
> > |  > >> *Sent:* 26 February 2021 22:33
> > |  > >> *To:* Iavor Diatchki <iavor.diatchki at gmail.com>
> > |  > >> *Cc:* ghc-steering-committee <ghc-steering-committee at haskell.org
> >
> > |  > >> *Subject:* Re: [ghc-steering-committee] Modification to record
> > |  dot syntax propsal
> > |  >
> > |  > >>
> > |  >
> > |  > >>
> > |  >
> > |  > >>> I do think that  reusing the record update syntax for the
> > |  overloaded monomorphic update is a mistake---it is not something I had
> > |  noticed during our original discussion.
> > |  >
> > |  > >>
> > |  >
> > |  > >> This is the one reason I can see for cutting this extension in
> > |  smaller pieces. But, then again, -XOverloadedRecordUpdate would be a
> > |  fork-like extension.
> > |  >
> > |  > >>
> > |  >
> > |  > >> Generally, I'm not in favour in proposals which split extensions
> > |  though: we already have so many extensions. Are the reasons for this
> > |  split strong enough? I haven't had time to dig into the details.
> > |  >
> > |  > >>
> > |  >
> > |  > >> I'm not sure that not having the design of the proposal quite
> > |  finalised is a good reason, extensions mutate in their first
> > |  iterations, I don't think that it's a problem.
> > |  >
> > |  > _______________________________________________
> > |  > ghc-steering-committee mailing list
> > |  > ghc-steering-committee at haskell.org
> > |  >
> > |
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail
> > |  .haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-
> > |  committee&amp;data=04%7C01%7Csimonpj%40microsoft.com
> %7C8abc00434aa94b7
> > |  fa98e08d8df1b5d9f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6375046
> > |  55938142566%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMz
> > |  IiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=9DGVl6oJc0%2BIQekuXf
> > |  zwqviiaT%2FaHZIlIk3R5aMZssA%3D&amp;reserved=0
> > |  >
> > |  _______________________________________________
> > |  ghc-steering-committee mailing list
> > |  ghc-steering-committee at haskell.org
> > |
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail
> > |  .haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-
> > |  committee&amp;data=04%7C01%7Csimonpj%40microsoft.com
> %7C8abc00434aa94b7
> > |  fa98e08d8df1b5d9f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6375046
> > |  55938152562%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMz
> > |  IiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=QZlV0RrRttaiDdrQNiRB
> > |  vUhS6il1DydPX5cyl%2BdILbI%3D&amp;reserved=0
> >
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20210304/bff6f87d/attachment-0001.html>

From eric at seidel.io  Thu Mar  4 19:44:41 2021
From: eric at seidel.io (Eric Seidel)
Date: Thu, 4 Mar 2021 14:44:41 -0500
Subject: [ghc-steering-committee] Modification to record dot syntax
	propsal
In-Reply-To: <CAGK9nuoy3cbiESa2goLzzOoYxDMXNKm14bGSxmKDRerbJcA7Ng@mail.gmail.com>
References: <CAGK9nuoy3cbiESa2goLzzOoYxDMXNKm14bGSxmKDRerbJcA7Ng@mail.gmail.com>
Message-ID: <6A02AD21-9E34-4879-A40F-5DB86D9A129F@seidel.io>

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 <iavor.diatchki at 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 <eric at 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 <ghc-steering-committee-
>> > |  bounces at haskell.org> On Behalf Of Eric Seidel
>> > |  Sent: 04 March 2021 14:38
>> > |  To: ghc-steering-committee at haskell.org
>> > |  Subject: Re: [ghc-steering-committee] Modification to record dot
>> > |  syntax propsal
>> > |  
>> > |  I agree with Richard and Joachim that it should be documented in the
>> > |  user guide. It's much better to document features with the expected
>> > |  level of support than to let users stumble upon them and make their
>> > |  own assumptions about stability.
>> > |  
>> > |  That being said, I don't see anything in the revised proposal about
>> > |  the stability of OverloadedRecordUpdate. Are you saying that as part
>> > |  of this revision, we'll explicitly accept OverloadedRecordDot and send
>> > |  OverloadedRecordUpdate back for revision?
>> > |  
>> > |  On Thu, Mar 4, 2021, at 04:46, Simon Peyton Jones via ghc-steering-
>> > |  committee wrote:
>> > |  >
>> > |  > Friends
>> > |  >
>> > |  >
>> > |  >
>> > |  > We've agree to accept my suggestion below.
>> > |  >
>> > |  >
>> > |  >
>> > |  > But there is one point at issue: should OverloadedRecordUpdate be
>> > |  > documented in the user manual, albeit identified as a not-yet-
>> > |  accepted
>> > |  > feature?
>> > |  >
>> > |  >
>> > |  >
>> > |  >  * Richard positively wants it in the manual
>> > |  >  * Iavor positively doesn't want it there.
>> > |  >
>> > |  >
>> > |  > I don't mind either way.
>> > |  >
>> > |  >
>> > |  >
>> > |  > What do others think?  It's not a big deal, but we owe the authors a
>> > |  > decision.  Answer by the end of the week please, and I'll make a
>> > |  > shepherd decision based on the opinions I get.
>> > |  >
>> > |  >
>> > |  >
>> > |  > Simon
>> > |  >
>> > |  >
>> > |  >
>> > |  >
>> > |  >
>> > |  > *From:* Simon Peyton Jones <simonpj at microsoft.com>
>> > |  > *Sent:* 02 March 2021 12:45
>> > |  > *To:* ghc-steering-committee <ghc-steering-committee at haskell.org>
>> > |  > *Cc:* Simon Peyton Jones <simonpj at microsoft.com>
>> > |  > *Subject:* RE: [ghc-steering-committee] Modification to record dot
>> > |  > syntax propsal
>> > |  >
>> > |  >
>> > |  >
>> > |  > Friends
>> > |  >
>> > |  >
>> > |  >
>> > |  > Having consulted the authors, I propose that we do this:
>> > |  >
>> > |  >
>> > |  >
>> > |  >  * Proceed with OverloadedRecordDot for 9.2, exactly as in the
>> > |  > original proposal except for the extension name.
>> > |  >  * Record update will remain exactly as now, in 9.2; that is,
>> > |  drawing
>> > |  > back from the original proposal.
>> > |  >  * There may be some *code* in 9.2 that allows overloaded record
>> > |  > update, protected by OverloadedRecordUpdate, but not in the user
>> > |  > manual, and not treated as an accepted proposal.   I don't think we
>> > |  > should ask the authors to remove it, and it will allow
>> > |  experimentation.
>> > |  >  * Adam is leading on a revised record-update proposal. This will
>> > |  cover
>> > |  >    * the tradeoffs between type-changing and non-type-changing
>> > |  update
>> > |  >    * what the current record-update syntax stands for, and/or any
>> > |  new
>> > |  > syntax
>> > |  >
>> > |  >
>> > |  > Is that acceptable to everyone?
>> > |  >
>> > |  >
>> > |  >
>> > |  > Simon
>> > |  >
>> > |  >
>> > |  >
>> > |  > *From:* ghc-steering-committee
>> > |  > <ghc-steering-committee-bounces at haskell.org> *On Behalf Of *Simon
>> > |  > Peyton Jones via ghc-steering-committee
>> > |  > *Sent:* 01 March 2021 17:51
>> > |  > *To:* Iavor Diatchki <iavor.diatchki at gmail.com>; Spiwack, Arnaud
>> > |  > <arnaud.spiwack at tweag.io>
>> > |  > *Cc:* ghc-steering-committee <ghc-steering-committee at haskell.org>
>> > |  > *Subject:* Re: [ghc-steering-committee] Modification to record dot
>> > |  > syntax propsal
>> > |  >
>> > |  >
>> > |  >
>> > |  > I don't buy the argument of "this is already accepted", as I don't
>> > |  > think many of us had noticed that part of the proposal (I certainly
>> > |  > didn't), and I think we should be flexible enough to revisit
>> > |  previous
>> > |  > decisions when we notice problems with them.
>> > |  >
>> > |  > I agree in principle that we can revisit decisions.   But we have to
>> > |  be
>> > |  > aware that it is potentially very discouraging for proposal authors
>> > |  to
>> > |  >
>> > |  >  * propose something,
>> > |  >  * have it *extensively* debated (including this very point),
>> > |  >  * have it accepted,
>> > |  >  * implement it,
>> > |  > and then be told that the committee has changed its mind.  That's
>> > |  > pretty bad from their point of view.
>> > |  >
>> > |  >
>> > |  >
>> > |  > Still, Adam is working on a new SetField proposal, so perhaps that's
>> > |  a
>> > |  > figleaf.  I'll consult them.
>> > |  >
>> > |  >
>> > |  > Simon
>> > |  >
>> > |  >
>> > |  >
>> > |  >
>> > |  >
>> > |  > *From:* Iavor Diatchki <iavor.diatchki at gmail.com>
>> > |  > *Sent:* 01 March 2021 17:23
>> > |  > *To:* Spiwack, Arnaud <arnaud.spiwack at tweag.io>
>> > |  > *Cc:* Simon Peyton Jones <simonpj at microsoft.com>;
>> > |  > ghc-steering-committee <ghc-steering-committee at haskell.org>
>> > |  > *Subject:* Re: [ghc-steering-committee] Modification to record dot
>> > |  > syntax propsal
>> > |  >
>> > |  >
>> > |  >
>> > |  > Hello,
>> > |  >
>> > |  >
>> > |  >
>> > |  > I think there is a strong motivation to *at least* split the
>> > |  > extensions:  with the current design, enabling the special `.`
>> > |  notation
>> > |  > also *disables* type changing record update, which has nothing to do
>> > |  > with the `.` notation.
>> > |  >
>> > |  >
>> > |  >
>> > |  > My preference would be to:
>> > |  >
>> > |  >   1. Split the original proposal into two parts: one about `.`
>> > |  > notation, the other about record update (as suggested by this
>> > |  proposal)
>> > |  >
>> > |  >   2. Treat the `.` notation part as accepted
>> > |  >
>> > |  >   3. Require changes on the record update part, so that you don't
>> > |  have
>> > |  > to choose between it and type changing record updates, which are
>> > |  quite
>> > |  > useful, and I don't think we should aim for a Haskell without them.
>> > |  >
>> > |  >
>> > |  >
>> > |  > I don't buy the argument of "this is already accepted", as I don't
>> > |  > think many of us had noticed that part of the proposal (I certainly
>> > |  > didn't), and I think we should be flexible enough to revisit
>> > |  previous
>> > |  > decisions when we notice problems with them.
>> > |  >
>> > |  >
>> > |  >
>> > |  > -Iavor
>> > |  >
>> > |  >
>> > |  >
>> > |  >
>> > |  >
>> > |  >
>> > |  >
>> > |  > On Mon, Mar 1, 2021 at 1:40 AM Spiwack, Arnaud
>> > |  <arnaud.spiwack at tweag.io> wrote:
>> > |  >
>> > |  > > Simon, all,
>> > |  >
>> > |  > >
>> > |  >
>> > |  > > After reading more of the PR thread (in particular the fews posts
>> > |  after Simon's recommendation), I have to admit: I am thoroughly
>> > |  confused. I'm not sure that two people in that thread have the same
>> > |  motivation, end goal, or design in mind.
>> > |  >
>> > |  > >
>> > |  >
>> > |  > > The motivations provided by the modified *Alternatives* section is
>> > |  not much more helpful (at the risk of caricaturing a little, it
>> > |  basically reads: "we made two extensions rather than one because we
>> > |  can"). Though it makes it clear that the end goal is to fold a bunch
>> > |  of record-related extensions into one glorious record extension (well,
>> > |  probably not fold them, but make a meta-extension that implies all the
>> > |  extensions that we've decided we like).
>> > |  >
>> > |  > >
>> > |  >
>> > |  > > My starting point is that:
>> > |  >
>> > |  > > - Additional extensions have a maintenance cost
>> > |  >
>> > |  > > - Additional extensions impose a cognitive burden on their use
>> > |  >
>> > |  > > - I expect that a new extension will break my code in the next few
>> > |  releases.
>> > |  >
>> > |  > >
>> > |  >
>> > |  > > Based on this, I don't care how this extension or the glorious
>> > |  record extension are named; but if we want to have two extensions we
>> > |  should have a serious reason. Right now, the one reason that I see
>> > |  (and Iavor raised), is that the update part of `RecordDotSyntax` is
>> > |  not backward compatible. Is it a strong enough reason? I don't know.
>> > |  The only data point that I can provide is that when we discussed the
>> > |  original proposal, I brought it up several times, and it didn't seem
>> > |  very important at the time (the conversation focused on other points
>> > |  of the proposal).
>> > |  >
>> > |  > >
>> > |  >
>> > |  > > So, I'm still reluctant. I feel that, at the very least, the
>> > |  motivations are not well-enough articulated in the proposal (I'll make
>> > |  a comment to this effect on Github when I'm done composing this
>> > |  email).
>> > |  >
>> > |  > >
>> > |  >
>> > |  > > I appreciate that I'm in the minority here. Yet, I'm still
>> > |  unconvinced.
>> > |  >
>> > |  > >
>> > |  >
>> > |  > > Best,
>> > |  >
>> > |  > > Arnaud
>> > |  >
>> > |  > >
>> > |  >
>> > |  > > On Sat, Feb 27, 2021 at 12:39 AM Simon Peyton Jones
>> > |  <simonpj at microsoft.com> wrote:
>> > |  >
>> > |  > >> Generally, I'm not in favour in proposals which split extensions
>> > |  though: we already have so many extensions. Are the reasons for this
>> > |  split strong enough? I haven't had time to dig into the details.
>> > |  >
>> > |  > >> Arnaud, happily, you don't have to dig very deep - just read the
>> > |  handful of posts following my recommendation.
>> > |  >
>> > |  > >>
>> > |  >
>> > |  > >> There seem to be two motivations.
>> > |  >
>> > |  > >>
>> > |  >
>> > |  > >>  1. There really are two orthogonal extensions, one for r.x
>> > |  notation, and one for overloaded update.  Iavor likes the first but
>> > |  not the second.  Neil likes both.  Having separate extensions lets us
>> > |  experiment.
>> > |  > >>
>> > |  >
>> > |  > >>  1. You suggest that changing the definition of RecordDotSyntax
>> > |  in a subsequent release, e.g. by subsequently making it imply
>> > |  NoFieldSelectors, would be fine. But it certainly imposes pain - some
>> > |  programs would stop compiling.  The approach offered by this proposal
>> > |  avoids that problem.
>> > |  > >>
>> > |  >
>> > |  > >> Yes, there are lots of extensions surrounding records:
>> > |  NoFieldSelectors, DuplicateRecordFields, NamedFieldPuns,
>> > |  DisambiguateRecordFields, RecordWildCards.  It may not be pretty to
>> > |  divide things up so fine, but it's not new.
>> > |  >
>> > |  > >>
>> > |  >
>> > |  > >>
>> > |  >
>> > |  > >> If there are alternative suggestions, let's hear them.
>> > |  >
>> > |  > >>
>> > |  >
>> > |  > >> Simon
>> > |  >
>> > |  > >>
>> > |  >
>> > |  > >> *From:* ghc-steering-committee <ghc-steering-committee-
>> > |  bounces at haskell.org> *On Behalf Of *Spiwack, Arnaud
>> > |  > >> *Sent:* 26 February 2021 22:33
>> > |  > >> *To:* Iavor Diatchki <iavor.diatchki at gmail.com>
>> > |  > >> *Cc:* ghc-steering-committee <ghc-steering-committee at haskell.org>
>> > |  > >> *Subject:* Re: [ghc-steering-committee] Modification to record
>> > |  dot syntax propsal
>> > |  >
>> > |  > >>
>> > |  >
>> > |  > >>
>> > |  >
>> > |  > >>> I do think that  reusing the record update syntax for the
>> > |  overloaded monomorphic update is a mistake---it is not something I had
>> > |  noticed during our original discussion.
>> > |  >
>> > |  > >>
>> > |  >
>> > |  > >> This is the one reason I can see for cutting this extension in
>> > |  smaller pieces. But, then again, -XOverloadedRecordUpdate would be a
>> > |  fork-like extension.
>> > |  >
>> > |  > >>
>> > |  >
>> > |  > >> Generally, I'm not in favour in proposals which split extensions
>> > |  though: we already have so many extensions. Are the reasons for this
>> > |  split strong enough? I haven't had time to dig into the details.
>> > |  >
>> > |  > >>
>> > |  >
>> > |  > >> I'm not sure that not having the design of the proposal quite
>> > |  finalised is a good reason, extensions mutate in their first
>> > |  iterations, I don't think that it's a problem.
>> > |  >
>> > |  > _______________________________________________
>> > |  > ghc-steering-committee mailing list
>> > |  > ghc-steering-committee at haskell.org
>> > |  >
>> > |  https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail
>> > |  .haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-
>> > |  committee&amp;data=04%7C01%7Csimonpj%40microsoft.com%7C8abc00434aa94b7
>> > |  fa98e08d8df1b5d9f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6375046
>> > |  55938142566%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMz
>> > |  IiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=9DGVl6oJc0%2BIQekuXf
>> > |  zwqviiaT%2FaHZIlIk3R5aMZssA%3D&amp;reserved=0
>> > |  >
>> > |  _______________________________________________
>> > |  ghc-steering-committee mailing list
>> > |  ghc-steering-committee at haskell.org
>> > |  https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail
>> > |  .haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-
>> > |  committee&amp;data=04%7C01%7Csimonpj%40microsoft.com%7C8abc00434aa94b7
>> > |  fa98e08d8df1b5d9f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6375046
>> > |  55938152562%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMz
>> > |  IiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=QZlV0RrRttaiDdrQNiRB
>> > |  vUhS6il1DydPX5cyl%2BdILbI%3D&amp;reserved=0
>> >
>> _______________________________________________
>> ghc-steering-committee mailing list
>> ghc-steering-committee at haskell.org
>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20210304/3200ab6a/attachment-0001.html>

From rae at richarde.dev  Thu Mar  4 20:01:33 2021
From: rae at richarde.dev (Richard Eisenberg)
Date: Thu, 4 Mar 2021 20:01:33 +0000
Subject: [ghc-steering-committee] Modification to record dot syntax
 propsal
In-Reply-To: <a41e6ca0-e830-4268-a82c-c79bc4b8d765@www.fastmail.com>
References: <VI1PR83MB0222BD8EC07924531D115264AD809@VI1PR83MB0222.EURPRD83.prod.outlook.com>
 <VI1PR83MB02221D0C9C4C75606C6F9FD3AD9D9@VI1PR83MB0222.EURPRD83.prod.outlook.com>
 <010f0177defd0abc-ddb39126-a38d-4cd7-b888-81acd5493dea-000000@us-east-2.amazonses.com>
 <CAGK9nur-Q+gft7qQodSCsaK4xnvpZoXwccaNYU4VNH_keoGEOA@mail.gmail.com>
 <CAH6fHQm1OFX+0i+CVwDC_m0HdQ=fnFN0uTtjdA9zifZV3ZVJoA@mail.gmail.com>
 <VI1PR83MB022233AD140B7B84463C45D4AD9D9@VI1PR83MB0222.EURPRD83.prod.outlook.com>
 <CAH6fHQ=1Hb5jZH3Yhr-BejT2j83++iykvCZPVYC9HYMueOmHZA@mail.gmail.com>
 <CAGK9nurtqxSTdeUya415wvdswjpTm9noUnLw+WMJv06ozhoETg@mail.gmail.com>
 <VI1PR83MB02228D79560C8A731F0116D5AD9A9@VI1PR83MB0222.EURPRD83.prod.outlook.com>
 <VI1PR83MB0222FFB6BA71803975996928AD999@VI1PR83MB0222.EURPRD83.prod.outlook.com>
 <VI1PR83MB02226750776BFB3526A5A011AD979@VI1PR83MB0222.EURPRD83.prod.outlook.com>
 <a953b43e-89dd-41c4-b6f2-24c93403498a@www.fastmail.com>
 <VI1PR83MB0222668EAF9B03C9FFBE9D8DAD979@VI1PR83MB0222.EURPRD83.prod.outlook.com>
 <a41e6ca0-e830-4268-a82c-c79bc4b8d765@www.fastmail.com>
Message-ID: <010f0177fed4c5e7-0c7dd06f-ee32-4fd9-99b6-b4ccc3c72e35-000000@us-east-2.amazonses.com>

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 <eric at 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 <ghc-steering-committee-
>> |  bounces at haskell.org> On Behalf Of Eric Seidel
>> |  Sent: 04 March 2021 14:38
>> |  To: ghc-steering-committee at haskell.org
>> |  Subject: Re: [ghc-steering-committee] Modification to record dot
>> |  syntax propsal
>> |  
>> |  I agree with Richard and Joachim that it should be documented in the
>> |  user guide. It's much better to document features with the expected
>> |  level of support than to let users stumble upon them and make their
>> |  own assumptions about stability.
>> |  
>> |  That being said, I don't see anything in the revised proposal about
>> |  the stability of OverloadedRecordUpdate. Are you saying that as part
>> |  of this revision, we'll explicitly accept OverloadedRecordDot and send
>> |  OverloadedRecordUpdate back for revision?
>> |  
>> |  On Thu, Mar 4, 2021, at 04:46, Simon Peyton Jones via ghc-steering-
>> |  committee wrote:
>> |  >
>> |  > Friends
>> |  >
>> |  >
>> |  >
>> |  > We've agree to accept my suggestion below.
>> |  >
>> |  >
>> |  >
>> |  > But there is one point at issue: should OverloadedRecordUpdate be
>> |  > documented in the user manual, albeit identified as a not-yet-
>> |  accepted
>> |  > feature?
>> |  >
>> |  >
>> |  >
>> |  >  * Richard positively wants it in the manual
>> |  >  * Iavor positively doesn't want it there.
>> |  >
>> |  >
>> |  > I don't mind either way.
>> |  >
>> |  >
>> |  >
>> |  > What do others think?  It's not a big deal, but we owe the authors a
>> |  > decision.  Answer by the end of the week please, and I'll make a
>> |  > shepherd decision based on the opinions I get.
>> |  >
>> |  >
>> |  >
>> |  > Simon
>> |  >
>> |  >
>> |  >
>> |  >
>> |  >
>> |  > *From:* Simon Peyton Jones <simonpj at microsoft.com>
>> |  > *Sent:* 02 March 2021 12:45
>> |  > *To:* ghc-steering-committee <ghc-steering-committee at haskell.org>
>> |  > *Cc:* Simon Peyton Jones <simonpj at microsoft.com>
>> |  > *Subject:* RE: [ghc-steering-committee] Modification to record dot
>> |  > syntax propsal
>> |  >
>> |  >
>> |  >
>> |  > Friends
>> |  >
>> |  >
>> |  >
>> |  > Having consulted the authors, I propose that we do this:
>> |  >
>> |  >
>> |  >
>> |  >  * Proceed with OverloadedRecordDot for 9.2, exactly as in the
>> |  > original proposal except for the extension name.
>> |  >  * Record update will remain exactly as now, in 9.2; that is,
>> |  drawing
>> |  > back from the original proposal.
>> |  >  * There may be some *code* in 9.2 that allows overloaded record
>> |  > update, protected by OverloadedRecordUpdate, but not in the user
>> |  > manual, and not treated as an accepted proposal.   I don't think we
>> |  > should ask the authors to remove it, and it will allow
>> |  experimentation.
>> |  >  * Adam is leading on a revised record-update proposal. This will
>> |  cover
>> |  >    * the tradeoffs between type-changing and non-type-changing
>> |  update
>> |  >    * what the current record-update syntax stands for, and/or any
>> |  new
>> |  > syntax
>> |  >
>> |  >
>> |  > Is that acceptable to everyone?
>> |  >
>> |  >
>> |  >
>> |  > Simon
>> |  >
>> |  >
>> |  >
>> |  > *From:* ghc-steering-committee
>> |  > <ghc-steering-committee-bounces at haskell.org> *On Behalf Of *Simon
>> |  > Peyton Jones via ghc-steering-committee
>> |  > *Sent:* 01 March 2021 17:51
>> |  > *To:* Iavor Diatchki <iavor.diatchki at gmail.com>; Spiwack, Arnaud
>> |  > <arnaud.spiwack at tweag.io>
>> |  > *Cc:* ghc-steering-committee <ghc-steering-committee at haskell.org>
>> |  > *Subject:* Re: [ghc-steering-committee] Modification to record dot
>> |  > syntax propsal
>> |  >
>> |  >
>> |  >
>> |  > I don't buy the argument of "this is already accepted", as I don't
>> |  > think many of us had noticed that part of the proposal (I certainly
>> |  > didn't), and I think we should be flexible enough to revisit
>> |  previous
>> |  > decisions when we notice problems with them.
>> |  >
>> |  > I agree in principle that we can revisit decisions.   But we have to
>> |  be
>> |  > aware that it is potentially very discouraging for proposal authors
>> |  to
>> |  >
>> |  >  * propose something,
>> |  >  * have it *extensively* debated (including this very point),
>> |  >  * have it accepted,
>> |  >  * implement it,
>> |  > and then be told that the committee has changed its mind.  That's
>> |  > pretty bad from their point of view.
>> |  >
>> |  >
>> |  >
>> |  > Still, Adam is working on a new SetField proposal, so perhaps that's
>> |  a
>> |  > figleaf.  I'll consult them.
>> |  >
>> |  >
>> |  > Simon
>> |  >
>> |  >
>> |  >
>> |  >
>> |  >
>> |  > *From:* Iavor Diatchki <iavor.diatchki at gmail.com>
>> |  > *Sent:* 01 March 2021 17:23
>> |  > *To:* Spiwack, Arnaud <arnaud.spiwack at tweag.io>
>> |  > *Cc:* Simon Peyton Jones <simonpj at microsoft.com>;
>> |  > ghc-steering-committee <ghc-steering-committee at haskell.org>
>> |  > *Subject:* Re: [ghc-steering-committee] Modification to record dot
>> |  > syntax propsal
>> |  >
>> |  >
>> |  >
>> |  > Hello,
>> |  >
>> |  >
>> |  >
>> |  > I think there is a strong motivation to *at least* split the
>> |  > extensions:  with the current design, enabling the special `.`
>> |  notation
>> |  > also *disables* type changing record update, which has nothing to do
>> |  > with the `.` notation.
>> |  >
>> |  >
>> |  >
>> |  > My preference would be to:
>> |  >
>> |  >   1. Split the original proposal into two parts: one about `.`
>> |  > notation, the other about record update (as suggested by this
>> |  proposal)
>> |  >
>> |  >   2. Treat the `.` notation part as accepted
>> |  >
>> |  >   3. Require changes on the record update part, so that you don't
>> |  have
>> |  > to choose between it and type changing record updates, which are
>> |  quite
>> |  > useful, and I don't think we should aim for a Haskell without them.
>> |  >
>> |  >
>> |  >
>> |  > I don't buy the argument of "this is already accepted", as I don't
>> |  > think many of us had noticed that part of the proposal (I certainly
>> |  > didn't), and I think we should be flexible enough to revisit
>> |  previous
>> |  > decisions when we notice problems with them.
>> |  >
>> |  >
>> |  >
>> |  > -Iavor
>> |  >
>> |  >
>> |  >
>> |  >
>> |  >
>> |  >
>> |  >
>> |  > On Mon, Mar 1, 2021 at 1:40 AM Spiwack, Arnaud
>> |  <arnaud.spiwack at tweag.io> wrote:
>> |  >
>> |  > > Simon, all,
>> |  >
>> |  > >
>> |  >
>> |  > > After reading more of the PR thread (in particular the fews posts
>> |  after Simon's recommendation), I have to admit: I am thoroughly
>> |  confused. I'm not sure that two people in that thread have the same
>> |  motivation, end goal, or design in mind.
>> |  >
>> |  > >
>> |  >
>> |  > > The motivations provided by the modified *Alternatives* section is
>> |  not much more helpful (at the risk of caricaturing a little, it
>> |  basically reads: "we made two extensions rather than one because we
>> |  can"). Though it makes it clear that the end goal is to fold a bunch
>> |  of record-related extensions into one glorious record extension (well,
>> |  probably not fold them, but make a meta-extension that implies all the
>> |  extensions that we've decided we like).
>> |  >
>> |  > >
>> |  >
>> |  > > My starting point is that:
>> |  >
>> |  > > - Additional extensions have a maintenance cost
>> |  >
>> |  > > - Additional extensions impose a cognitive burden on their use
>> |  >
>> |  > > - I expect that a new extension will break my code in the next few
>> |  releases.
>> |  >
>> |  > >
>> |  >
>> |  > > Based on this, I don't care how this extension or the glorious
>> |  record extension are named; but if we want to have two extensions we
>> |  should have a serious reason. Right now, the one reason that I see
>> |  (and Iavor raised), is that the update part of `RecordDotSyntax` is
>> |  not backward compatible. Is it a strong enough reason? I don't know.
>> |  The only data point that I can provide is that when we discussed the
>> |  original proposal, I brought it up several times, and it didn't seem
>> |  very important at the time (the conversation focused on other points
>> |  of the proposal).
>> |  >
>> |  > >
>> |  >
>> |  > > So, I'm still reluctant. I feel that, at the very least, the
>> |  motivations are not well-enough articulated in the proposal (I'll make
>> |  a comment to this effect on Github when I'm done composing this
>> |  email).
>> |  >
>> |  > >
>> |  >
>> |  > > I appreciate that I'm in the minority here. Yet, I'm still
>> |  unconvinced.
>> |  >
>> |  > >
>> |  >
>> |  > > Best,
>> |  >
>> |  > > Arnaud
>> |  >
>> |  > >
>> |  >
>> |  > > On Sat, Feb 27, 2021 at 12:39 AM Simon Peyton Jones
>> |  <simonpj at microsoft.com> wrote:
>> |  >
>> |  > >> Generally, I'm not in favour in proposals which split extensions
>> |  though: we already have so many extensions. Are the reasons for this
>> |  split strong enough? I haven't had time to dig into the details.
>> |  >
>> |  > >> Arnaud, happily, you don't have to dig very deep - just read the
>> |  handful of posts following my recommendation.
>> |  >
>> |  > >>
>> |  >
>> |  > >> There seem to be two motivations.
>> |  >
>> |  > >>
>> |  >
>> |  > >>  1. There really are two orthogonal extensions, one for r.x
>> |  notation, and one for overloaded update.  Iavor likes the first but
>> |  not the second.  Neil likes both.  Having separate extensions lets us
>> |  experiment.
>> |  > >>
>> |  >
>> |  > >>  1. You suggest that changing the definition of RecordDotSyntax
>> |  in a subsequent release, e.g. by subsequently making it imply
>> |  NoFieldSelectors, would be fine. But it certainly imposes pain - some
>> |  programs would stop compiling.  The approach offered by this proposal
>> |  avoids that problem.
>> |  > >>
>> |  >
>> |  > >> Yes, there are lots of extensions surrounding records:
>> |  NoFieldSelectors, DuplicateRecordFields, NamedFieldPuns,
>> |  DisambiguateRecordFields, RecordWildCards.  It may not be pretty to
>> |  divide things up so fine, but it's not new.
>> |  >
>> |  > >>
>> |  >
>> |  > >>
>> |  >
>> |  > >> If there are alternative suggestions, let's hear them.
>> |  >
>> |  > >>
>> |  >
>> |  > >> Simon
>> |  >
>> |  > >>
>> |  >
>> |  > >> *From:* ghc-steering-committee <ghc-steering-committee-
>> |  bounces at haskell.org> *On Behalf Of *Spiwack, Arnaud
>> |  > >> *Sent:* 26 February 2021 22:33
>> |  > >> *To:* Iavor Diatchki <iavor.diatchki at gmail.com>
>> |  > >> *Cc:* ghc-steering-committee <ghc-steering-committee at haskell.org>
>> |  > >> *Subject:* Re: [ghc-steering-committee] Modification to record
>> |  dot syntax propsal
>> |  >
>> |  > >>
>> |  >
>> |  > >>
>> |  >
>> |  > >>> I do think that  reusing the record update syntax for the
>> |  overloaded monomorphic update is a mistake---it is not something I had
>> |  noticed during our original discussion.
>> |  >
>> |  > >>
>> |  >
>> |  > >> This is the one reason I can see for cutting this extension in
>> |  smaller pieces. But, then again, -XOverloadedRecordUpdate would be a
>> |  fork-like extension.
>> |  >
>> |  > >>
>> |  >
>> |  > >> Generally, I'm not in favour in proposals which split extensions
>> |  though: we already have so many extensions. Are the reasons for this
>> |  split strong enough? I haven't had time to dig into the details.
>> |  >
>> |  > >>
>> |  >
>> |  > >> I'm not sure that not having the design of the proposal quite
>> |  finalised is a good reason, extensions mutate in their first
>> |  iterations, I don't think that it's a problem.
>> |  >
>> |  > _______________________________________________
>> |  > ghc-steering-committee mailing list
>> |  > ghc-steering-committee at haskell.org
>> |  >
>> |  https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail
>> |  .haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-
>> |  committee&amp;data=04%7C01%7Csimonpj%40microsoft.com%7C8abc00434aa94b7
>> |  fa98e08d8df1b5d9f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6375046
>> |  55938142566%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMz
>> |  IiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=9DGVl6oJc0%2BIQekuXf
>> |  zwqviiaT%2FaHZIlIk3R5aMZssA%3D&amp;reserved=0
>> |  >
>> |  _______________________________________________
>> |  ghc-steering-committee mailing list
>> |  ghc-steering-committee at haskell.org
>> |  https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail
>> |  .haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-
>> |  committee&amp;data=04%7C01%7Csimonpj%40microsoft.com%7C8abc00434aa94b7
>> |  fa98e08d8df1b5d9f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6375046
>> |  55938152562%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMz
>> |  IiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=QZlV0RrRttaiDdrQNiRB
>> |  vUhS6il1DydPX5cyl%2BdILbI%3D&amp;reserved=0
>> 
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee


From eric at seidel.io  Fri Mar  5 01:38:57 2021
From: eric at seidel.io (Eric Seidel)
Date: Thu, 04 Mar 2021 20:38:57 -0500
Subject: [ghc-steering-committee]
 =?utf-8?q?What_is_an_extension=3F_=28was?=
 =?utf-8?q?=3A_Modification_to_record_dot_syntax_propsal=29?=
In-Reply-To: <010f0177fed4c5e7-0c7dd06f-ee32-4fd9-99b6-b4ccc3c72e35-000000@us-east-2.amazonses.com>
References: <VI1PR83MB0222BD8EC07924531D115264AD809@VI1PR83MB0222.EURPRD83.prod.outlook.com>
 <VI1PR83MB02221D0C9C4C75606C6F9FD3AD9D9@VI1PR83MB0222.EURPRD83.prod.outlook.com>
 <010f0177defd0abc-ddb39126-a38d-4cd7-b888-81acd5493dea-000000@us-east-2.amazonses.com>
 <CAGK9nur-Q+gft7qQodSCsaK4xnvpZoXwccaNYU4VNH_keoGEOA@mail.gmail.com>
 <CAH6fHQm1OFX+0i+CVwDC_m0HdQ=fnFN0uTtjdA9zifZV3ZVJoA@mail.gmail.com>
 <VI1PR83MB022233AD140B7B84463C45D4AD9D9@VI1PR83MB0222.EURPRD83.prod.outlook.com>
 <CAH6fHQ=1Hb5jZH3Yhr-BejT2j83++iykvCZPVYC9HYMueOmHZA@mail.gmail.com>
 <CAGK9nurtqxSTdeUya415wvdswjpTm9noUnLw+WMJv06ozhoETg@mail.gmail.com>
 <VI1PR83MB02228D79560C8A731F0116D5AD9A9@VI1PR83MB0222.EURPRD83.prod.outlook.com>
 <VI1PR83MB0222FFB6BA71803975996928AD999@VI1PR83MB0222.EURPRD83.prod.outlook.com>
 <VI1PR83MB02226750776BFB3526A5A011AD979@VI1PR83MB0222.EURPRD83.prod.outlook.com>
 <a953b43e-89dd-41c4-b6f2-24c93403498a@www.fastmail.com>
 <VI1PR83MB0222668EAF9B03C9FFBE9D8DAD979@VI1PR83MB0222.EURPRD83.prod.outlook.com>
 <a41e6ca0-e830-4268-a82c-c79bc4b8d765@www.fastmail.com>
 <010f0177fed4c5e7-0c7dd06f-ee32-4fd9-99b6-b4ccc3c72e35-000000@us-east-2.amazonses.com>
Message-ID: <ff22ceba-d81a-4980-aa77-bebd883b583c@www.fastmail.com>

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

From mail at joachim-breitner.de  Fri Mar  5 07:44:36 2021
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Fri, 05 Mar 2021 08:44:36 +0100
Subject: [ghc-steering-committee] #403: Cleanup lexical structure,
 recommendation: accept
In-Reply-To: <CAH6fHQnGv72AF1PrxQhyDSNcgK0gwwaJzHYbhfc+hn44SD1+4w@mail.gmail.com>
References: <CAH6fHQnGv72AF1PrxQhyDSNcgK0gwwaJzHYbhfc+hn44SD1+4w@mail.gmail.com>
Message-ID: <30b57087d26f4251a9066b1685ad00829ed49535.camel@joachim-breitner.de>

Hi,

Am Donnerstag, den 04.03.2021, 15:53 +0100 schrieb Spiwack, Arnaud:
> As the shepherd for proposal #403 Cleanup lexical structure of numbers and identifiers, let me recommend acceptance.
> 
> This proposal does two things related to unicode characters
> Codify the actual current lexing of unicode symbols, which is actually different from the Haskell 2010 report (in particular, only ascii digits are allowed in number literals)
> Adds the possibility to use unicode letters which are neither upper case nor lower case (such as many asian scripts) as trailing symbols for identifier (as well as in String and Char literals)
> It doesn't make it possible (nor close the door) to use letter-like numbers (such as latin numerals) as identifiers, nor use non-ascii digits in number literals.
> 
> As the title entails, it's essentially a clean up of the documentation, to match reality. It seems quite uncontroversial.

yes, this looks very reasonable.

Cheers,
Joachim


-- 
Joachim Breitner
  mail at joachim-breitner.de
  http://www.joachim-breitner.de/



From simonpj at microsoft.com  Fri Mar  5 08:26:13 2021
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Fri, 5 Mar 2021 08:26:13 +0000
Subject: [ghc-steering-committee] What is an extension? (was:
 Modification to record dot syntax propsal)
In-Reply-To: <ff22ceba-d81a-4980-aa77-bebd883b583c@www.fastmail.com>
References: <VI1PR83MB0222BD8EC07924531D115264AD809@VI1PR83MB0222.EURPRD83.prod.outlook.com>
 <VI1PR83MB02221D0C9C4C75606C6F9FD3AD9D9@VI1PR83MB0222.EURPRD83.prod.outlook.com>
 <010f0177defd0abc-ddb39126-a38d-4cd7-b888-81acd5493dea-000000@us-east-2.amazonses.com>
 <CAGK9nur-Q+gft7qQodSCsaK4xnvpZoXwccaNYU4VNH_keoGEOA@mail.gmail.com>
 <CAH6fHQm1OFX+0i+CVwDC_m0HdQ=fnFN0uTtjdA9zifZV3ZVJoA@mail.gmail.com>
 <VI1PR83MB022233AD140B7B84463C45D4AD9D9@VI1PR83MB0222.EURPRD83.prod.outlook.com>
 <CAH6fHQ=1Hb5jZH3Yhr-BejT2j83++iykvCZPVYC9HYMueOmHZA@mail.gmail.com>
 <CAGK9nurtqxSTdeUya415wvdswjpTm9noUnLw+WMJv06ozhoETg@mail.gmail.com>
 <VI1PR83MB02228D79560C8A731F0116D5AD9A9@VI1PR83MB0222.EURPRD83.prod.outlook.com>
 <VI1PR83MB0222FFB6BA71803975996928AD999@VI1PR83MB0222.EURPRD83.prod.outlook.com>
 <VI1PR83MB02226750776BFB3526A5A011AD979@VI1PR83MB0222.EURPRD83.prod.outlook.com>
 <a953b43e-89dd-41c4-b6f2-24c93403498a@www.fastmail.com>
 <VI1PR83MB0222668EAF9B03C9FFBE9D8DAD979@VI1PR83MB0222.EURPRD83.prod.outlook.com>
 <a41e6ca0-e830-4268-a82c-c79bc4b8d765@www.fastmail.com>
 <010f0177fed4c5e7-0c7dd06f-ee32-4fd9-99b6-b4ccc3c72e35-000000@us-east-2.amazonses.com>
 <ff22ceba-d81a-4980-aa77-bebd883b583c@www.fastmail.com>
Message-ID: <VI1PR83MB02227518F98DADDBA06408DFAD969@VI1PR83MB0222.EURPRD83.prod.outlook.com>

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 <ghc-steering-committee-
|  bounces at haskell.org> On Behalf Of Eric Seidel
|  Sent: 05 March 2021 01:39
|  To: ghc-steering-committee at 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 at haskell.org
|  https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail
|  .haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-
|  committee&amp;data=04%7C01%7Csimonpj%40microsoft.com%7Ce1d6aea762ee415
|  54ba308d8df7788ee%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6375050
|  51854197326%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMz
|  IiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=33rA74unELy12hNzQKI%
|  2BBkrv%2Fwt3067zTiFoM4j6lXI%3D&amp;reserved=0

From simonpj at microsoft.com  Fri Mar  5 09:21:53 2021
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Fri, 5 Mar 2021 09:21:53 +0000
Subject: [ghc-steering-committee] #403: Cleanup lexical structure,
	recommendation: accept
In-Reply-To: <CAH6fHQnGv72AF1PrxQhyDSNcgK0gwwaJzHYbhfc+hn44SD1+4w@mail.gmail.com>
References: <CAH6fHQnGv72AF1PrxQhyDSNcgK0gwwaJzHYbhfc+hn44SD1+4w@mail.gmail.com>
Message-ID: <VI1PR83MB02229E22E39517DA61FC0427AD969@VI1PR83MB0222.EURPRD83.prod.outlook.com>

I don't have a well-informed opinion, but I certainly have no objection.

Simon

From: ghc-steering-committee <ghc-steering-committee-bounces at haskell.org> On Behalf Of Spiwack, Arnaud
Sent: 04 March 2021 14:54
To: GHC Steering committee <ghc-steering-committee at haskell.org>
Subject: [ghc-steering-committee] #403: Cleanup lexical structure, recommendation: accept

Dear all,

As the shepherd for proposal #403 Cleanup lexical structure of numbers and identifiers<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%2Fpull%2F403&data=04%7C01%7Csimonpj%40microsoft.com%7Cb28a9399e2fd44379fd308d8df1d66b0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637504665725379654%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=Rfp%2F%2BPsrs%2FQWa9k67NTAOLAI7PXccca%2BVLBZvcNVYME%3D&reserved=0>, let me recommend acceptance.

This proposal does two things related to unicode characters

  *   Codify the actual current lexing of unicode symbols, which is actually different from the Haskell 2010 report (in particular, only ascii digits are allowed in number literals)
  *   Adds the possibility to use unicode letters which are neither upper case nor lower case (such as many asian scripts) as trailing symbols for identifier (as well as in String and Char literals)
It doesn't make it possible (nor close the door) to use letter-like numbers (such as latin numerals) as identifiers, nor use non-ascii digits in number literals.

As the title entails, it's essentially a clean up of the documentation, to match reality. It seems quite uncontroversial.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20210305/bbb0084b/attachment-0001.html>

From arnaud.spiwack at tweag.io  Fri Mar  5 10:49:36 2021
From: arnaud.spiwack at tweag.io (Spiwack, Arnaud)
Date: Fri, 5 Mar 2021 11:49:36 +0100
Subject: [ghc-steering-committee] Modification to record dot syntax
	propsal
In-Reply-To: <6A02AD21-9E34-4879-A40F-5DB86D9A129F@seidel.io>
References: <CAGK9nuoy3cbiESa2goLzzOoYxDMXNKm14bGSxmKDRerbJcA7Ng@mail.gmail.com>
 <6A02AD21-9E34-4879-A40F-5DB86D9A129F@seidel.io>
Message-ID: <CAH6fHQn0K23Rhi6mi=A2DePxPzZxLAE6TUEMnxvwi2_17G==jg@mail.gmail.com>

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 <eric at 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 <iavor.diatchki at 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 <eric at 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 <ghc-steering-committee-
>> > |  bounces at haskell.org> On Behalf Of Eric Seidel
>> > |  Sent: 04 March 2021 14:38
>> > |  To: ghc-steering-committee at haskell.org
>> > |  Subject: Re: [ghc-steering-committee] Modification to record dot
>> > |  syntax propsal
>> > |
>> > |  I agree with Richard and Joachim that it should be documented in the
>> > |  user guide. It's much better to document features with the expected
>> > |  level of support than to let users stumble upon them and make their
>> > |  own assumptions about stability.
>> > |
>> > |  That being said, I don't see anything in the revised proposal about
>> > |  the stability of OverloadedRecordUpdate. Are you saying that as part
>> > |  of this revision, we'll explicitly accept OverloadedRecordDot and
>> send
>> > |  OverloadedRecordUpdate back for revision?
>> > |
>> > |  On Thu, Mar 4, 2021, at 04:46, Simon Peyton Jones via ghc-steering-
>> > |  committee wrote:
>> > |  >
>> > |  > Friends
>> > |  >
>> > |  >
>> > |  >
>> > |  > We've agree to accept my suggestion below.
>> > |  >
>> > |  >
>> > |  >
>> > |  > But there is one point at issue: should OverloadedRecordUpdate be
>> > |  > documented in the user manual, albeit identified as a not-yet-
>> > |  accepted
>> > |  > feature?
>> > |  >
>> > |  >
>> > |  >
>> > |  >  * Richard positively wants it in the manual
>> > |  >  * Iavor positively doesn't want it there.
>> > |  >
>> > |  >
>> > |  > I don't mind either way.
>> > |  >
>> > |  >
>> > |  >
>> > |  > What do others think?  It's not a big deal, but we owe the authors
>> a
>> > |  > decision.  Answer by the end of the week please, and I'll make a
>> > |  > shepherd decision based on the opinions I get.
>> > |  >
>> > |  >
>> > |  >
>> > |  > Simon
>> > |  >
>> > |  >
>> > |  >
>> > |  >
>> > |  >
>> > |  > *From:* Simon Peyton Jones <simonpj at microsoft.com>
>> > |  > *Sent:* 02 March 2021 12:45
>> > |  > *To:* ghc-steering-committee <ghc-steering-committee at haskell.org>
>> > |  > *Cc:* Simon Peyton Jones <simonpj at microsoft.com>
>> > |  > *Subject:* RE: [ghc-steering-committee] Modification to record dot
>> > |  > syntax propsal
>> > |  >
>> > |  >
>> > |  >
>> > |  > Friends
>> > |  >
>> > |  >
>> > |  >
>> > |  > Having consulted the authors, I propose that we do this:
>> > |  >
>> > |  >
>> > |  >
>> > |  >  * Proceed with OverloadedRecordDot for 9.2, exactly as in the
>> > |  > original proposal except for the extension name.
>> > |  >  * Record update will remain exactly as now, in 9.2; that is,
>> > |  drawing
>> > |  > back from the original proposal.
>> > |  >  * There may be some *code* in 9.2 that allows overloaded record
>> > |  > update, protected by OverloadedRecordUpdate, but not in the user
>> > |  > manual, and not treated as an accepted proposal.   I don't think we
>> > |  > should ask the authors to remove it, and it will allow
>> > |  experimentation.
>> > |  >  * Adam is leading on a revised record-update proposal. This will
>> > |  cover
>> > |  >    * the tradeoffs between type-changing and non-type-changing
>> > |  update
>> > |  >    * what the current record-update syntax stands for, and/or any
>> > |  new
>> > |  > syntax
>> > |  >
>> > |  >
>> > |  > Is that acceptable to everyone?
>> > |  >
>> > |  >
>> > |  >
>> > |  > Simon
>> > |  >
>> > |  >
>> > |  >
>> > |  > *From:* ghc-steering-committee
>> > |  > <ghc-steering-committee-bounces at haskell.org> *On Behalf Of *Simon
>> > |  > Peyton Jones via ghc-steering-committee
>> > |  > *Sent:* 01 March 2021 17:51
>> > |  > *To:* Iavor Diatchki <iavor.diatchki at gmail.com>; Spiwack, Arnaud
>> > |  > <arnaud.spiwack at tweag.io>
>> > |  > *Cc:* ghc-steering-committee <ghc-steering-committee at haskell.org>
>> > |  > *Subject:* Re: [ghc-steering-committee] Modification to record dot
>> > |  > syntax propsal
>> > |  >
>> > |  >
>> > |  >
>> > |  > I don't buy the argument of "this is already accepted", as I don't
>> > |  > think many of us had noticed that part of the proposal (I certainly
>> > |  > didn't), and I think we should be flexible enough to revisit
>> > |  previous
>> > |  > decisions when we notice problems with them.
>> > |  >
>> > |  > I agree in principle that we can revisit decisions.   But we have
>> to
>> > |  be
>> > |  > aware that it is potentially very discouraging for proposal authors
>> > |  to
>> > |  >
>> > |  >  * propose something,
>> > |  >  * have it *extensively* debated (including this very point),
>> > |  >  * have it accepted,
>> > |  >  * implement it,
>> > |  > and then be told that the committee has changed its mind.  That's
>> > |  > pretty bad from their point of view.
>> > |  >
>> > |  >
>> > |  >
>> > |  > Still, Adam is working on a new SetField proposal, so perhaps
>> that's
>> > |  a
>> > |  > figleaf.  I'll consult them.
>> > |  >
>> > |  >
>> > |  > Simon
>> > |  >
>> > |  >
>> > |  >
>> > |  >
>> > |  >
>> > |  > *From:* Iavor Diatchki <iavor.diatchki at gmail.com>
>> > |  > *Sent:* 01 March 2021 17:23
>> > |  > *To:* Spiwack, Arnaud <arnaud.spiwack at tweag.io>
>> > |  > *Cc:* Simon Peyton Jones <simonpj at microsoft.com>;
>> > |  > ghc-steering-committee <ghc-steering-committee at haskell.org>
>> > |  > *Subject:* Re: [ghc-steering-committee] Modification to record dot
>> > |  > syntax propsal
>> > |  >
>> > |  >
>> > |  >
>> > |  > Hello,
>> > |  >
>> > |  >
>> > |  >
>> > |  > I think there is a strong motivation to *at least* split the
>> > |  > extensions:  with the current design, enabling the special `.`
>> > |  notation
>> > |  > also *disables* type changing record update, which has nothing to
>> do
>> > |  > with the `.` notation.
>> > |  >
>> > |  >
>> > |  >
>> > |  > My preference would be to:
>> > |  >
>> > |  >   1. Split the original proposal into two parts: one about `.`
>> > |  > notation, the other about record update (as suggested by this
>> > |  proposal)
>> > |  >
>> > |  >   2. Treat the `.` notation part as accepted
>> > |  >
>> > |  >   3. Require changes on the record update part, so that you don't
>> > |  have
>> > |  > to choose between it and type changing record updates, which are
>> > |  quite
>> > |  > useful, and I don't think we should aim for a Haskell without them.
>> > |  >
>> > |  >
>> > |  >
>> > |  > I don't buy the argument of "this is already accepted", as I don't
>> > |  > think many of us had noticed that part of the proposal (I certainly
>> > |  > didn't), and I think we should be flexible enough to revisit
>> > |  previous
>> > |  > decisions when we notice problems with them.
>> > |  >
>> > |  >
>> > |  >
>> > |  > -Iavor
>> > |  >
>> > |  >
>> > |  >
>> > |  >
>> > |  >
>> > |  >
>> > |  >
>> > |  > On Mon, Mar 1, 2021 at 1:40 AM Spiwack, Arnaud
>> > |  <arnaud.spiwack at tweag.io> wrote:
>> > |  >
>> > |  > > Simon, all,
>> > |  >
>> > |  > >
>> > |  >
>> > |  > > After reading more of the PR thread (in particular the fews posts
>> > |  after Simon's recommendation), I have to admit: I am thoroughly
>> > |  confused. I'm not sure that two people in that thread have the same
>> > |  motivation, end goal, or design in mind.
>> > |  >
>> > |  > >
>> > |  >
>> > |  > > The motivations provided by the modified *Alternatives* section
>> is
>> > |  not much more helpful (at the risk of caricaturing a little, it
>> > |  basically reads: "we made two extensions rather than one because we
>> > |  can"). Though it makes it clear that the end goal is to fold a bunch
>> > |  of record-related extensions into one glorious record extension
>> (well,
>> > |  probably not fold them, but make a meta-extension that implies all
>> the
>> > |  extensions that we've decided we like).
>> > |  >
>> > |  > >
>> > |  >
>> > |  > > My starting point is that:
>> > |  >
>> > |  > > - Additional extensions have a maintenance cost
>> > |  >
>> > |  > > - Additional extensions impose a cognitive burden on their use
>> > |  >
>> > |  > > - I expect that a new extension will break my code in the next
>> few
>> > |  releases.
>> > |  >
>> > |  > >
>> > |  >
>> > |  > > Based on this, I don't care how this extension or the glorious
>> > |  record extension are named; but if we want to have two extensions we
>> > |  should have a serious reason. Right now, the one reason that I see
>> > |  (and Iavor raised), is that the update part of `RecordDotSyntax` is
>> > |  not backward compatible. Is it a strong enough reason? I don't know.
>> > |  The only data point that I can provide is that when we discussed the
>> > |  original proposal, I brought it up several times, and it didn't seem
>> > |  very important at the time (the conversation focused on other points
>> > |  of the proposal).
>> > |  >
>> > |  > >
>> > |  >
>> > |  > > So, I'm still reluctant. I feel that, at the very least, the
>> > |  motivations are not well-enough articulated in the proposal (I'll
>> make
>> > |  a comment to this effect on Github when I'm done composing this
>> > |  email).
>> > |  >
>> > |  > >
>> > |  >
>> > |  > > I appreciate that I'm in the minority here. Yet, I'm still
>> > |  unconvinced.
>> > |  >
>> > |  > >
>> > |  >
>> > |  > > Best,
>> > |  >
>> > |  > > Arnaud
>> > |  >
>> > |  > >
>> > |  >
>> > |  > > On Sat, Feb 27, 2021 at 12:39 AM Simon Peyton Jones
>> > |  <simonpj at microsoft.com> wrote:
>> > |  >
>> > |  > >> Generally, I'm not in favour in proposals which split extensions
>> > |  though: we already have so many extensions. Are the reasons for this
>> > |  split strong enough? I haven't had time to dig into the details.
>> > |  >
>> > |  > >> Arnaud, happily, you don't have to dig very deep - just read the
>> > |  handful of posts following my recommendation.
>> > |  >
>> > |  > >>
>> > |  >
>> > |  > >> There seem to be two motivations.
>> > |  >
>> > |  > >>
>> > |  >
>> > |  > >>  1. There really are two orthogonal extensions, one for r.x
>> > |  notation, and one for overloaded update.  Iavor likes the first but
>> > |  not the second.  Neil likes both.  Having separate extensions lets us
>> > |  experiment.
>> > |  > >>
>> > |  >
>> > |  > >>  1. You suggest that changing the definition of RecordDotSyntax
>> > |  in a subsequent release, e.g. by subsequently making it imply
>> > |  NoFieldSelectors, would be fine. But it certainly imposes pain - some
>> > |  programs would stop compiling.  The approach offered by this proposal
>> > |  avoids that problem.
>> > |  > >>
>> > |  >
>> > |  > >> Yes, there are lots of extensions surrounding records:
>> > |  NoFieldSelectors, DuplicateRecordFields, NamedFieldPuns,
>> > |  DisambiguateRecordFields, RecordWildCards.  It may not be pretty to
>> > |  divide things up so fine, but it's not new.
>> > |  >
>> > |  > >>
>> > |  >
>> > |  > >>
>> > |  >
>> > |  > >> If there are alternative suggestions, let's hear them.
>> > |  >
>> > |  > >>
>> > |  >
>> > |  > >> Simon
>> > |  >
>> > |  > >>
>> > |  >
>> > |  > >> *From:* ghc-steering-committee <ghc-steering-committee-
>> > |  bounces at haskell.org> *On Behalf Of *Spiwack, Arnaud
>> > |  > >> *Sent:* 26 February 2021 22:33
>> > |  > >> *To:* Iavor Diatchki <iavor.diatchki at gmail.com>
>> > |  > >> *Cc:* ghc-steering-committee <
>> ghc-steering-committee at haskell.org>
>> > |  > >> *Subject:* Re: [ghc-steering-committee] Modification to record
>> > |  dot syntax propsal
>> > |  >
>> > |  > >>
>> > |  >
>> > |  > >>
>> > |  >
>> > |  > >>> I do think that  reusing the record update syntax for the
>> > |  overloaded monomorphic update is a mistake---it is not something I
>> had
>> > |  noticed during our original discussion.
>> > |  >
>> > |  > >>
>> > |  >
>> > |  > >> This is the one reason I can see for cutting this extension in
>> > |  smaller pieces. But, then again, -XOverloadedRecordUpdate would be a
>> > |  fork-like extension.
>> > |  >
>> > |  > >>
>> > |  >
>> > |  > >> Generally, I'm not in favour in proposals which split extensions
>> > |  though: we already have so many extensions. Are the reasons for this
>> > |  split strong enough? I haven't had time to dig into the details.
>> > |  >
>> > |  > >>
>> > |  >
>> > |  > >> I'm not sure that not having the design of the proposal quite
>> > |  finalised is a good reason, extensions mutate in their first
>> > |  iterations, I don't think that it's a problem.
>> > |  >
>> > |  > _______________________________________________
>> > |  > ghc-steering-committee mailing list
>> > |  > ghc-steering-committee at haskell.org
>> > |  >
>> > |
>> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail
>> > |  .haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-
>> > |  committee&amp;data=04%7C01%7Csimonpj%40microsoft.com
>> %7C8abc00434aa94b7
>> > |
>> fa98e08d8df1b5d9f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6375046
>> > |
>> 55938142566%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMz
>> > |
>> IiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=9DGVl6oJc0%2BIQekuXf
>> > |  zwqviiaT%2FaHZIlIk3R5aMZssA%3D&amp;reserved=0
>> > |  >
>> > |  _______________________________________________
>> > |  ghc-steering-committee mailing list
>> > |  ghc-steering-committee at haskell.org
>> > |
>> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail
>> > |  .haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-
>> > |  committee&amp;data=04%7C01%7Csimonpj%40microsoft.com
>> %7C8abc00434aa94b7
>> > |
>> fa98e08d8df1b5d9f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6375046
>> > |
>> 55938152562%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMz
>> > |
>> IiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=QZlV0RrRttaiDdrQNiRB
>> > |  vUhS6il1DydPX5cyl%2BdILbI%3D&amp;reserved=0
>> >
>> _______________________________________________
>> ghc-steering-committee mailing list
>> ghc-steering-committee at haskell.org
>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20210305/693a5fc9/attachment-0001.html>

From eric at seidel.io  Fri Mar  5 14:03:03 2021
From: eric at seidel.io (Eric Seidel)
Date: Fri, 5 Mar 2021 09:03:03 -0500
Subject: [ghc-steering-committee] What is an extension? (was:
	Modification to record dot syntax propsal)
In-Reply-To: <VI1PR83MB02227518F98DADDBA06408DFAD969@VI1PR83MB0222.EURPRD83.prod.outlook.com>
References: <VI1PR83MB02227518F98DADDBA06408DFAD969@VI1PR83MB0222.EURPRD83.prod.outlook.com>
Message-ID: <6D6ABE00-9EFA-40EA-B4D9-07D9DCBA697B@seidel.io>

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 <simonpj at microsoft.com> 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 <ghc-steering-committee-
> |  bounces at haskell.org> On Behalf Of Eric Seidel
> |  Sent: 05 March 2021 01:39
> |  To: ghc-steering-committee at 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 at haskell.org
> |  https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail
> |  .haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-
> |  committee&amp;data=04%7C01%7Csimonpj%40microsoft.com%7Ce1d6aea762ee415
> |  54ba308d8df7788ee%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6375050
> |  51854197326%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMz
> |  IiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=33rA74unELy12hNzQKI%
> |  2BBkrv%2Fwt3067zTiFoM4j6lXI%3D&amp;reserved=0


From simonpj at microsoft.com  Fri Mar  5 14:30:52 2021
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Fri, 5 Mar 2021 14:30:52 +0000
Subject: [ghc-steering-committee] What is an extension? (was:
 Modification to record dot syntax propsal)
In-Reply-To: <6D6ABE00-9EFA-40EA-B4D9-07D9DCBA697B@seidel.io>
References: <VI1PR83MB02227518F98DADDBA06408DFAD969@VI1PR83MB0222.EURPRD83.prod.outlook.com>
 <6D6ABE00-9EFA-40EA-B4D9-07D9DCBA697B@seidel.io>
Message-ID: <AM0PR83MB0276EA6CFFD06F7E7A86EEC7AD969@AM0PR83MB0276.EURPRD83.prod.outlook.com>

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 <eric at seidel.io>
|  Sent: 05 March 2021 14:03
|  To: Simon Peyton Jones <simonpj at microsoft.com>
|  Cc: ghc-steering-committee at 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 <simonpj at microsoft.com>
|  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 <ghc-steering-committee-
|  > | bounces at haskell.org> On Behalf Of Eric Seidel
|  > |  Sent: 05 March 2021 01:39
|  > |  To: ghc-steering-committee at 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 at haskell.org
|  > |
|  > |
|  https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fma
|  > | il
|  > |  .haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-
|  > |
|  > |
|  committee&amp;data=04%7C01%7Csimonpj%40microsoft.com%7Ce1d6aea762ee4
|  > | 15
|  > |
|  > |
|  54ba308d8df7788ee%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63750
|  > | 50
|  > |
|  51854197326%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2lu
|  > | Mz
|  > |
|  IiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=33rA74unELy12hNzQK
|  > | I%
|  > |  2BBkrv%2Fwt3067zTiFoM4j6lXI%3D&amp;reserved=0


From iavor.diatchki at gmail.com  Fri Mar  5 16:03:28 2021
From: iavor.diatchki at gmail.com (Iavor Diatchki)
Date: Fri, 5 Mar 2021 08:03:28 -0800
Subject: [ghc-steering-committee] Modification to record dot syntax
	propsal
In-Reply-To: <CAH6fHQn0K23Rhi6mi=A2DePxPzZxLAE6TUEMnxvwi2_17G==jg@mail.gmail.com>
References: <CAGK9nuoy3cbiESa2goLzzOoYxDMXNKm14bGSxmKDRerbJcA7Ng@mail.gmail.com>
 <6A02AD21-9E34-4879-A40F-5DB86D9A129F@seidel.io>
 <CAH6fHQn0K23Rhi6mi=A2DePxPzZxLAE6TUEMnxvwi2_17G==jg@mail.gmail.com>
Message-ID: <CAGK9nuqWTYSFabPNk8s7Kzv7Fw4f=5k8dXTpGezhqoPixc86aQ@mail.gmail.com>

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 <arnaud.spiwack at 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 <eric at 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 <iavor.diatchki at 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 <eric at 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 <ghc-steering-committee-
>>> > |  bounces at haskell.org> On Behalf Of Eric Seidel
>>> > |  Sent: 04 March 2021 14:38
>>> > |  To: ghc-steering-committee at haskell.org
>>> > |  Subject: Re: [ghc-steering-committee] Modification to record dot
>>> > |  syntax propsal
>>> > |
>>> > |  I agree with Richard and Joachim that it should be documented in the
>>> > |  user guide. It's much better to document features with the expected
>>> > |  level of support than to let users stumble upon them and make their
>>> > |  own assumptions about stability.
>>> > |
>>> > |  That being said, I don't see anything in the revised proposal about
>>> > |  the stability of OverloadedRecordUpdate. Are you saying that as part
>>> > |  of this revision, we'll explicitly accept OverloadedRecordDot and
>>> send
>>> > |  OverloadedRecordUpdate back for revision?
>>> > |
>>> > |  On Thu, Mar 4, 2021, at 04:46, Simon Peyton Jones via ghc-steering-
>>> > |  committee wrote:
>>> > |  >
>>> > |  > Friends
>>> > |  >
>>> > |  >
>>> > |  >
>>> > |  > We've agree to accept my suggestion below.
>>> > |  >
>>> > |  >
>>> > |  >
>>> > |  > But there is one point at issue: should OverloadedRecordUpdate be
>>> > |  > documented in the user manual, albeit identified as a not-yet-
>>> > |  accepted
>>> > |  > feature?
>>> > |  >
>>> > |  >
>>> > |  >
>>> > |  >  * Richard positively wants it in the manual
>>> > |  >  * Iavor positively doesn't want it there.
>>> > |  >
>>> > |  >
>>> > |  > I don't mind either way.
>>> > |  >
>>> > |  >
>>> > |  >
>>> > |  > What do others think?  It's not a big deal, but we owe the
>>> authors a
>>> > |  > decision.  Answer by the end of the week please, and I'll make a
>>> > |  > shepherd decision based on the opinions I get.
>>> > |  >
>>> > |  >
>>> > |  >
>>> > |  > Simon
>>> > |  >
>>> > |  >
>>> > |  >
>>> > |  >
>>> > |  >
>>> > |  > *From:* Simon Peyton Jones <simonpj at microsoft.com>
>>> > |  > *Sent:* 02 March 2021 12:45
>>> > |  > *To:* ghc-steering-committee <ghc-steering-committee at haskell.org>
>>> > |  > *Cc:* Simon Peyton Jones <simonpj at microsoft.com>
>>> > |  > *Subject:* RE: [ghc-steering-committee] Modification to record dot
>>> > |  > syntax propsal
>>> > |  >
>>> > |  >
>>> > |  >
>>> > |  > Friends
>>> > |  >
>>> > |  >
>>> > |  >
>>> > |  > Having consulted the authors, I propose that we do this:
>>> > |  >
>>> > |  >
>>> > |  >
>>> > |  >  * Proceed with OverloadedRecordDot for 9.2, exactly as in the
>>> > |  > original proposal except for the extension name.
>>> > |  >  * Record update will remain exactly as now, in 9.2; that is,
>>> > |  drawing
>>> > |  > back from the original proposal.
>>> > |  >  * There may be some *code* in 9.2 that allows overloaded record
>>> > |  > update, protected by OverloadedRecordUpdate, but not in the user
>>> > |  > manual, and not treated as an accepted proposal.   I don't think
>>> we
>>> > |  > should ask the authors to remove it, and it will allow
>>> > |  experimentation.
>>> > |  >  * Adam is leading on a revised record-update proposal. This will
>>> > |  cover
>>> > |  >    * the tradeoffs between type-changing and non-type-changing
>>> > |  update
>>> > |  >    * what the current record-update syntax stands for, and/or any
>>> > |  new
>>> > |  > syntax
>>> > |  >
>>> > |  >
>>> > |  > Is that acceptable to everyone?
>>> > |  >
>>> > |  >
>>> > |  >
>>> > |  > Simon
>>> > |  >
>>> > |  >
>>> > |  >
>>> > |  > *From:* ghc-steering-committee
>>> > |  > <ghc-steering-committee-bounces at haskell.org> *On Behalf Of *Simon
>>> > |  > Peyton Jones via ghc-steering-committee
>>> > |  > *Sent:* 01 March 2021 17:51
>>> > |  > *To:* Iavor Diatchki <iavor.diatchki at gmail.com>; Spiwack, Arnaud
>>> > |  > <arnaud.spiwack at tweag.io>
>>> > |  > *Cc:* ghc-steering-committee <ghc-steering-committee at haskell.org>
>>> > |  > *Subject:* Re: [ghc-steering-committee] Modification to record dot
>>> > |  > syntax propsal
>>> > |  >
>>> > |  >
>>> > |  >
>>> > |  > I don't buy the argument of "this is already accepted", as I don't
>>> > |  > think many of us had noticed that part of the proposal (I
>>> certainly
>>> > |  > didn't), and I think we should be flexible enough to revisit
>>> > |  previous
>>> > |  > decisions when we notice problems with them.
>>> > |  >
>>> > |  > I agree in principle that we can revisit decisions.   But we have
>>> to
>>> > |  be
>>> > |  > aware that it is potentially very discouraging for proposal
>>> authors
>>> > |  to
>>> > |  >
>>> > |  >  * propose something,
>>> > |  >  * have it *extensively* debated (including this very point),
>>> > |  >  * have it accepted,
>>> > |  >  * implement it,
>>> > |  > and then be told that the committee has changed its mind.  That's
>>> > |  > pretty bad from their point of view.
>>> > |  >
>>> > |  >
>>> > |  >
>>> > |  > Still, Adam is working on a new SetField proposal, so perhaps
>>> that's
>>> > |  a
>>> > |  > figleaf.  I'll consult them.
>>> > |  >
>>> > |  >
>>> > |  > Simon
>>> > |  >
>>> > |  >
>>> > |  >
>>> > |  >
>>> > |  >
>>> > |  > *From:* Iavor Diatchki <iavor.diatchki at gmail.com>
>>> > |  > *Sent:* 01 March 2021 17:23
>>> > |  > *To:* Spiwack, Arnaud <arnaud.spiwack at tweag.io>
>>> > |  > *Cc:* Simon Peyton Jones <simonpj at microsoft.com>;
>>> > |  > ghc-steering-committee <ghc-steering-committee at haskell.org>
>>> > |  > *Subject:* Re: [ghc-steering-committee] Modification to record dot
>>> > |  > syntax propsal
>>> > |  >
>>> > |  >
>>> > |  >
>>> > |  > Hello,
>>> > |  >
>>> > |  >
>>> > |  >
>>> > |  > I think there is a strong motivation to *at least* split the
>>> > |  > extensions:  with the current design, enabling the special `.`
>>> > |  notation
>>> > |  > also *disables* type changing record update, which has nothing to
>>> do
>>> > |  > with the `.` notation.
>>> > |  >
>>> > |  >
>>> > |  >
>>> > |  > My preference would be to:
>>> > |  >
>>> > |  >   1. Split the original proposal into two parts: one about `.`
>>> > |  > notation, the other about record update (as suggested by this
>>> > |  proposal)
>>> > |  >
>>> > |  >   2. Treat the `.` notation part as accepted
>>> > |  >
>>> > |  >   3. Require changes on the record update part, so that you don't
>>> > |  have
>>> > |  > to choose between it and type changing record updates, which are
>>> > |  quite
>>> > |  > useful, and I don't think we should aim for a Haskell without
>>> them.
>>> > |  >
>>> > |  >
>>> > |  >
>>> > |  > I don't buy the argument of "this is already accepted", as I don't
>>> > |  > think many of us had noticed that part of the proposal (I
>>> certainly
>>> > |  > didn't), and I think we should be flexible enough to revisit
>>> > |  previous
>>> > |  > decisions when we notice problems with them.
>>> > |  >
>>> > |  >
>>> > |  >
>>> > |  > -Iavor
>>> > |  >
>>> > |  >
>>> > |  >
>>> > |  >
>>> > |  >
>>> > |  >
>>> > |  >
>>> > |  > On Mon, Mar 1, 2021 at 1:40 AM Spiwack, Arnaud
>>> > |  <arnaud.spiwack at tweag.io> wrote:
>>> > |  >
>>> > |  > > Simon, all,
>>> > |  >
>>> > |  > >
>>> > |  >
>>> > |  > > After reading more of the PR thread (in particular the fews
>>> posts
>>> > |  after Simon's recommendation), I have to admit: I am thoroughly
>>> > |  confused. I'm not sure that two people in that thread have the same
>>> > |  motivation, end goal, or design in mind.
>>> > |  >
>>> > |  > >
>>> > |  >
>>> > |  > > The motivations provided by the modified *Alternatives* section
>>> is
>>> > |  not much more helpful (at the risk of caricaturing a little, it
>>> > |  basically reads: "we made two extensions rather than one because we
>>> > |  can"). Though it makes it clear that the end goal is to fold a bunch
>>> > |  of record-related extensions into one glorious record extension
>>> (well,
>>> > |  probably not fold them, but make a meta-extension that implies all
>>> the
>>> > |  extensions that we've decided we like).
>>> > |  >
>>> > |  > >
>>> > |  >
>>> > |  > > My starting point is that:
>>> > |  >
>>> > |  > > - Additional extensions have a maintenance cost
>>> > |  >
>>> > |  > > - Additional extensions impose a cognitive burden on their use
>>> > |  >
>>> > |  > > - I expect that a new extension will break my code in the next
>>> few
>>> > |  releases.
>>> > |  >
>>> > |  > >
>>> > |  >
>>> > |  > > Based on this, I don't care how this extension or the glorious
>>> > |  record extension are named; but if we want to have two extensions we
>>> > |  should have a serious reason. Right now, the one reason that I see
>>> > |  (and Iavor raised), is that the update part of `RecordDotSyntax` is
>>> > |  not backward compatible. Is it a strong enough reason? I don't know.
>>> > |  The only data point that I can provide is that when we discussed the
>>> > |  original proposal, I brought it up several times, and it didn't seem
>>> > |  very important at the time (the conversation focused on other points
>>> > |  of the proposal).
>>> > |  >
>>> > |  > >
>>> > |  >
>>> > |  > > So, I'm still reluctant. I feel that, at the very least, the
>>> > |  motivations are not well-enough articulated in the proposal (I'll
>>> make
>>> > |  a comment to this effect on Github when I'm done composing this
>>> > |  email).
>>> > |  >
>>> > |  > >
>>> > |  >
>>> > |  > > I appreciate that I'm in the minority here. Yet, I'm still
>>> > |  unconvinced.
>>> > |  >
>>> > |  > >
>>> > |  >
>>> > |  > > Best,
>>> > |  >
>>> > |  > > Arnaud
>>> > |  >
>>> > |  > >
>>> > |  >
>>> > |  > > On Sat, Feb 27, 2021 at 12:39 AM Simon Peyton Jones
>>> > |  <simonpj at microsoft.com> wrote:
>>> > |  >
>>> > |  > >> Generally, I'm not in favour in proposals which split
>>> extensions
>>> > |  though: we already have so many extensions. Are the reasons for this
>>> > |  split strong enough? I haven't had time to dig into the details.
>>> > |  >
>>> > |  > >> Arnaud, happily, you don't have to dig very deep - just read
>>> the
>>> > |  handful of posts following my recommendation.
>>> > |  >
>>> > |  > >>
>>> > |  >
>>> > |  > >> There seem to be two motivations.
>>> > |  >
>>> > |  > >>
>>> > |  >
>>> > |  > >>  1. There really are two orthogonal extensions, one for r.x
>>> > |  notation, and one for overloaded update.  Iavor likes the first but
>>> > |  not the second.  Neil likes both.  Having separate extensions lets
>>> us
>>> > |  experiment.
>>> > |  > >>
>>> > |  >
>>> > |  > >>  1. You suggest that changing the definition of RecordDotSyntax
>>> > |  in a subsequent release, e.g. by subsequently making it imply
>>> > |  NoFieldSelectors, would be fine. But it certainly imposes pain -
>>> some
>>> > |  programs would stop compiling.  The approach offered by this
>>> proposal
>>> > |  avoids that problem.
>>> > |  > >>
>>> > |  >
>>> > |  > >> Yes, there are lots of extensions surrounding records:
>>> > |  NoFieldSelectors, DuplicateRecordFields, NamedFieldPuns,
>>> > |  DisambiguateRecordFields, RecordWildCards.  It may not be pretty to
>>> > |  divide things up so fine, but it's not new.
>>> > |  >
>>> > |  > >>
>>> > |  >
>>> > |  > >>
>>> > |  >
>>> > |  > >> If there are alternative suggestions, let's hear them.
>>> > |  >
>>> > |  > >>
>>> > |  >
>>> > |  > >> Simon
>>> > |  >
>>> > |  > >>
>>> > |  >
>>> > |  > >> *From:* ghc-steering-committee <ghc-steering-committee-
>>> > |  bounces at haskell.org> *On Behalf Of *Spiwack, Arnaud
>>> > |  > >> *Sent:* 26 February 2021 22:33
>>> > |  > >> *To:* Iavor Diatchki <iavor.diatchki at gmail.com>
>>> > |  > >> *Cc:* ghc-steering-committee <
>>> ghc-steering-committee at haskell.org>
>>> > |  > >> *Subject:* Re: [ghc-steering-committee] Modification to record
>>> > |  dot syntax propsal
>>> > |  >
>>> > |  > >>
>>> > |  >
>>> > |  > >>
>>> > |  >
>>> > |  > >>> I do think that  reusing the record update syntax for the
>>> > |  overloaded monomorphic update is a mistake---it is not something I
>>> had
>>> > |  noticed during our original discussion.
>>> > |  >
>>> > |  > >>
>>> > |  >
>>> > |  > >> This is the one reason I can see for cutting this extension in
>>> > |  smaller pieces. But, then again, -XOverloadedRecordUpdate would be a
>>> > |  fork-like extension.
>>> > |  >
>>> > |  > >>
>>> > |  >
>>> > |  > >> Generally, I'm not in favour in proposals which split
>>> extensions
>>> > |  though: we already have so many extensions. Are the reasons for this
>>> > |  split strong enough? I haven't had time to dig into the details.
>>> > |  >
>>> > |  > >>
>>> > |  >
>>> > |  > >> I'm not sure that not having the design of the proposal quite
>>> > |  finalised is a good reason, extensions mutate in their first
>>> > |  iterations, I don't think that it's a problem.
>>> > |  >
>>> > |  > _______________________________________________
>>> > |  > ghc-steering-committee mailing list
>>> > |  > ghc-steering-committee at haskell.org
>>> > |  >
>>> > |
>>> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail
>>> > |  .haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-
>>> > |  committee&amp;data=04%7C01%7Csimonpj%40microsoft.com
>>> %7C8abc00434aa94b7
>>> > |
>>> fa98e08d8df1b5d9f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6375046
>>> > |
>>> 55938142566%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMz
>>> > |
>>> IiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=9DGVl6oJc0%2BIQekuXf
>>> > |  zwqviiaT%2FaHZIlIk3R5aMZssA%3D&amp;reserved=0
>>> > |  >
>>> > |  _______________________________________________
>>> > |  ghc-steering-committee mailing list
>>> > |  ghc-steering-committee at haskell.org
>>> > |
>>> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail
>>> > |  .haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-
>>> > |  committee&amp;data=04%7C01%7Csimonpj%40microsoft.com
>>> %7C8abc00434aa94b7
>>> > |
>>> fa98e08d8df1b5d9f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6375046
>>> > |
>>> 55938152562%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMz
>>> > |
>>> IiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=QZlV0RrRttaiDdrQNiRB
>>> > |  vUhS6il1DydPX5cyl%2BdILbI%3D&amp;reserved=0
>>> >
>>> _______________________________________________
>>> ghc-steering-committee mailing list
>>> ghc-steering-committee at haskell.org
>>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>>
>> _______________________________________________
>> ghc-steering-committee mailing list
>> ghc-steering-committee at haskell.org
>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20210305/335b8882/attachment-0001.html>

From simonpj at microsoft.com  Fri Mar  5 17:19:12 2021
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Fri, 5 Mar 2021 17:19:12 +0000
Subject: [ghc-steering-committee] Modification to record dot
	syntax	propsal
In-Reply-To: <CAGK9nuqWTYSFabPNk8s7Kzv7Fw4f=5k8dXTpGezhqoPixc86aQ@mail.gmail.com>
References: <CAGK9nuoy3cbiESa2goLzzOoYxDMXNKm14bGSxmKDRerbJcA7Ng@mail.gmail.com>
 <6A02AD21-9E34-4879-A40F-5DB86D9A129F@seidel.io>
 <CAH6fHQn0K23Rhi6mi=A2DePxPzZxLAE6TUEMnxvwi2_17G==jg@mail.gmail.com>
 <CAGK9nuqWTYSFabPNk8s7Kzv7Fw4f=5k8dXTpGezhqoPixc86aQ@mail.gmail.com>
Message-ID: <AM0PR83MB02760B6E11F569F5DAA13041AD969@AM0PR83MB0276.EURPRD83.prod.outlook.com>

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 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.
  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 <ghc-steering-committee-bounces at haskell.org> On Behalf Of Iavor Diatchki
Sent: 05 March 2021 16:03
To: Spiwack, Arnaud <arnaud.spiwack at tweag.io>; ghc-steering-committee <ghc-steering-committee at haskell.org>
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 <arnaud.spiwack at tweag.io<mailto:arnaud.spiwack at 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 <eric at seidel.io<mailto:eric at 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 <iavor.diatchki at gmail.com<mailto:iavor.diatchki at 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 <eric at seidel.io<mailto:eric at 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 <ghc-steering-committee-
> |  bounces at haskell.org<mailto:bounces at haskell.org>> On Behalf Of Eric Seidel
> |  Sent: 04 March 2021 14:38
> |  To: ghc-steering-committee at haskell.org<mailto:ghc-steering-committee at haskell.org>
> |  Subject: Re: [ghc-steering-committee] Modification to record dot
> |  syntax propsal
> |
> |  I agree with Richard and Joachim that it should be documented in the
> |  user guide. It's much better to document features with the expected
> |  level of support than to let users stumble upon them and make their
> |  own assumptions about stability.
> |
> |  That being said, I don't see anything in the revised proposal about
> |  the stability of OverloadedRecordUpdate. Are you saying that as part
> |  of this revision, we'll explicitly accept OverloadedRecordDot and send
> |  OverloadedRecordUpdate back for revision?
> |
> |  On Thu, Mar 4, 2021, at 04:46, Simon Peyton Jones via ghc-steering-
> |  committee wrote:
> |  >
> |  > Friends
> |  >
> |  >
> |  >
> |  > We've agree to accept my suggestion below.
> |  >
> |  >
> |  >
> |  > But there is one point at issue: should OverloadedRecordUpdate be
> |  > documented in the user manual, albeit identified as a not-yet-
> |  accepted
> |  > feature?
> |  >
> |  >
> |  >
> |  >  * Richard positively wants it in the manual
> |  >  * Iavor positively doesn't want it there.
> |  >
> |  >
> |  > I don't mind either way.
> |  >
> |  >
> |  >
> |  > What do others think?  It's not a big deal, but we owe the authors a
> |  > decision.  Answer by the end of the week please, and I'll make a
> |  > shepherd decision based on the opinions I get.
> |  >
> |  >
> |  >
> |  > Simon
> |  >
> |  >
> |  >
> |  >
> |  >
> |  > *From:* Simon Peyton Jones <simonpj at microsoft.com<mailto:simonpj at microsoft.com>>
> |  > *Sent:* 02 March 2021 12:45
> |  > *To:* ghc-steering-committee <ghc-steering-committee at haskell.org<mailto:ghc-steering-committee at haskell.org>>
> |  > *Cc:* Simon Peyton Jones <simonpj at microsoft.com<mailto:simonpj at microsoft.com>>
> |  > *Subject:* RE: [ghc-steering-committee] Modification to record dot
> |  > syntax propsal
> |  >
> |  >
> |  >
> |  > Friends
> |  >
> |  >
> |  >
> |  > Having consulted the authors, I propose that we do this:
> |  >
> |  >
> |  >
> |  >  * Proceed with OverloadedRecordDot for 9.2, exactly as in the
> |  > original proposal except for the extension name.
> |  >  * Record update will remain exactly as now, in 9.2; that is,
> |  drawing
> |  > back from the original proposal.
> |  >  * There may be some *code* in 9.2 that allows overloaded record
> |  > update, protected by OverloadedRecordUpdate, but not in the user
> |  > manual, and not treated as an accepted proposal.   I don't think we
> |  > should ask the authors to remove it, and it will allow
> |  experimentation.
> |  >  * Adam is leading on a revised record-update proposal. This will
> |  cover
> |  >    * the tradeoffs between type-changing and non-type-changing
> |  update
> |  >    * what the current record-update syntax stands for, and/or any
> |  new
> |  > syntax
> |  >
> |  >
> |  > Is that acceptable to everyone?
> |  >
> |  >
> |  >
> |  > Simon
> |  >
> |  >
> |  >
> |  > *From:* ghc-steering-committee
> |  > <ghc-steering-committee-bounces at haskell.org<mailto:ghc-steering-committee-bounces at haskell.org>> *On Behalf Of *Simon
> |  > Peyton Jones via ghc-steering-committee
> |  > *Sent:* 01 March 2021 17:51
> |  > *To:* Iavor Diatchki <iavor.diatchki at gmail.com<mailto:iavor.diatchki at gmail.com>>; Spiwack, Arnaud
> |  > <arnaud.spiwack at tweag.io<mailto:arnaud.spiwack at tweag.io>>
> |  > *Cc:* ghc-steering-committee <ghc-steering-committee at haskell.org<mailto:ghc-steering-committee at haskell.org>>
> |  > *Subject:* Re: [ghc-steering-committee] Modification to record dot
> |  > syntax propsal
> |  >
> |  >
> |  >
> |  > I don't buy the argument of "this is already accepted", as I don't
> |  > think many of us had noticed that part of the proposal (I certainly
> |  > didn't), and I think we should be flexible enough to revisit
> |  previous
> |  > decisions when we notice problems with them.
> |  >
> |  > I agree in principle that we can revisit decisions.   But we have to
> |  be
> |  > aware that it is potentially very discouraging for proposal authors
> |  to
> |  >
> |  >  * propose something,
> |  >  * have it *extensively* debated (including this very point),
> |  >  * have it accepted,
> |  >  * implement it,
> |  > and then be told that the committee has changed its mind.  That's
> |  > pretty bad from their point of view.
> |  >
> |  >
> |  >
> |  > Still, Adam is working on a new SetField proposal, so perhaps that's
> |  a
> |  > figleaf.  I'll consult them.
> |  >
> |  >
> |  > Simon
> |  >
> |  >
> |  >
> |  >
> |  >
> |  > *From:* Iavor Diatchki <iavor.diatchki at gmail.com<mailto:iavor.diatchki at gmail.com>>
> |  > *Sent:* 01 March 2021 17:23
> |  > *To:* Spiwack, Arnaud <arnaud.spiwack at tweag.io<mailto:arnaud.spiwack at tweag.io>>
> |  > *Cc:* Simon Peyton Jones <simonpj at microsoft.com<mailto:simonpj at microsoft.com>>;
> |  > ghc-steering-committee <ghc-steering-committee at haskell.org<mailto:ghc-steering-committee at haskell.org>>
> |  > *Subject:* Re: [ghc-steering-committee] Modification to record dot
> |  > syntax propsal
> |  >
> |  >
> |  >
> |  > Hello,
> |  >
> |  >
> |  >
> |  > I think there is a strong motivation to *at least* split the
> |  > extensions:  with the current design, enabling the special `.`
> |  notation
> |  > also *disables* type changing record update, which has nothing to do
> |  > with the `.` notation.
> |  >
> |  >
> |  >
> |  > My preference would be to:
> |  >
> |  >   1. Split the original proposal into two parts: one about `.`
> |  > notation, the other about record update (as suggested by this
> |  proposal)
> |  >
> |  >   2. Treat the `.` notation part as accepted
> |  >
> |  >   3. Require changes on the record update part, so that you don't
> |  have
> |  > to choose between it and type changing record updates, which are
> |  quite
> |  > useful, and I don't think we should aim for a Haskell without them.
> |  >
> |  >
> |  >
> |  > I don't buy the argument of "this is already accepted", as I don't
> |  > think many of us had noticed that part of the proposal (I certainly
> |  > didn't), and I think we should be flexible enough to revisit
> |  previous
> |  > decisions when we notice problems with them.
> |  >
> |  >
> |  >
> |  > -Iavor
> |  >
> |  >
> |  >
> |  >
> |  >
> |  >
> |  >
> |  > On Mon, Mar 1, 2021 at 1:40 AM Spiwack, Arnaud
> |  <arnaud.spiwack at tweag.io<mailto:arnaud.spiwack at tweag.io>> wrote:
> |  >
> |  > > Simon, all,
> |  >
> |  > >
> |  >
> |  > > After reading more of the PR thread (in particular the fews posts
> |  after Simon's recommendation), I have to admit: I am thoroughly
> |  confused. I'm not sure that two people in that thread have the same
> |  motivation, end goal, or design in mind.
> |  >
> |  > >
> |  >
> |  > > The motivations provided by the modified *Alternatives* section is
> |  not much more helpful (at the risk of caricaturing a little, it
> |  basically reads: "we made two extensions rather than one because we
> |  can"). Though it makes it clear that the end goal is to fold a bunch
> |  of record-related extensions into one glorious record extension (well,
> |  probably not fold them, but make a meta-extension that implies all the
> |  extensions that we've decided we like).
> |  >
> |  > >
> |  >
> |  > > My starting point is that:
> |  >
> |  > > - Additional extensions have a maintenance cost
> |  >
> |  > > - Additional extensions impose a cognitive burden on their use
> |  >
> |  > > - I expect that a new extension will break my code in the next few
> |  releases.
> |  >
> |  > >
> |  >
> |  > > Based on this, I don't care how this extension or the glorious
> |  record extension are named; but if we want to have two extensions we
> |  should have a serious reason. Right now, the one reason that I see
> |  (and Iavor raised), is that the update part of `RecordDotSyntax` is
> |  not backward compatible. Is it a strong enough reason? I don't know.
> |  The only data point that I can provide is that when we discussed the
> |  original proposal, I brought it up several times, and it didn't seem
> |  very important at the time (the conversation focused on other points
> |  of the proposal).
> |  >
> |  > >
> |  >
> |  > > So, I'm still reluctant. I feel that, at the very least, the
> |  motivations are not well-enough articulated in the proposal (I'll make
> |  a comment to this effect on Github when I'm done composing this
> |  email).
> |  >
> |  > >
> |  >
> |  > > I appreciate that I'm in the minority here. Yet, I'm still
> |  unconvinced.
> |  >
> |  > >
> |  >
> |  > > Best,
> |  >
> |  > > Arnaud
> |  >
> |  > >
> |  >
> |  > > On Sat, Feb 27, 2021 at 12:39 AM Simon Peyton Jones
> |  <simonpj at microsoft.com<mailto:simonpj at microsoft.com>> wrote:
> |  >
> |  > >> Generally, I'm not in favour in proposals which split extensions
> |  though: we already have so many extensions. Are the reasons for this
> |  split strong enough? I haven't had time to dig into the details.
> |  >
> |  > >> Arnaud, happily, you don't have to dig very deep - just read the
> |  handful of posts following my recommendation.
> |  >
> |  > >>
> |  >
> |  > >> There seem to be two motivations.
> |  >
> |  > >>
> |  >
> |  > >>  1. There really are two orthogonal extensions, one for r.x
> |  notation, and one for overloaded update.  Iavor likes the first but
> |  not the second.  Neil likes both.  Having separate extensions lets us
> |  experiment.
> |  > >>
> |  >
> |  > >>  1. You suggest that changing the definition of RecordDotSyntax
> |  in a subsequent release, e.g. by subsequently making it imply
> |  NoFieldSelectors, would be fine. But it certainly imposes pain - some
> |  programs would stop compiling.  The approach offered by this proposal
> |  avoids that problem.
> |  > >>
> |  >
> |  > >> Yes, there are lots of extensions surrounding records:
> |  NoFieldSelectors, DuplicateRecordFields, NamedFieldPuns,
> |  DisambiguateRecordFields, RecordWildCards.  It may not be pretty to
> |  divide things up so fine, but it's not new.
> |  >
> |  > >>
> |  >
> |  > >>
> |  >
> |  > >> If there are alternative suggestions, let's hear them.
> |  >
> |  > >>
> |  >
> |  > >> Simon
> |  >
> |  > >>
> |  >
> |  > >> *From:* ghc-steering-committee <ghc-steering-committee-
> |  bounces at haskell.org<mailto:bounces at haskell.org>> *On Behalf Of *Spiwack, Arnaud
> |  > >> *Sent:* 26 February 2021 22:33
> |  > >> *To:* Iavor Diatchki <iavor.diatchki at gmail.com<mailto:iavor.diatchki at gmail.com>>
> |  > >> *Cc:* ghc-steering-committee <ghc-steering-committee at haskell.org<mailto:ghc-steering-committee at haskell.org>>
> |  > >> *Subject:* Re: [ghc-steering-committee] Modification to record
> |  dot syntax propsal
> |  >
> |  > >>
> |  >
> |  > >>
> |  >
> |  > >>> I do think that  reusing the record update syntax for the
> |  overloaded monomorphic update is a mistake---it is not something I had
> |  noticed during our original discussion.
> |  >
> |  > >>
> |  >
> |  > >> This is the one reason I can see for cutting this extension in
> |  smaller pieces. But, then again, -XOverloadedRecordUpdate would be a
> |  fork-like extension.
> |  >
> |  > >>
> |  >
> |  > >> Generally, I'm not in favour in proposals which split extensions
> |  though: we already have so many extensions. Are the reasons for this
> |  split strong enough? I haven't had time to dig into the details.
> |  >
> |  > >>
> |  >
> |  > >> I'm not sure that not having the design of the proposal quite
> |  finalised is a good reason, extensions mutate in their first
> |  iterations, I don't think that it's a problem.
> |  >
> |  > _______________________________________________
> |  > ghc-steering-committee mailing list
> |  > ghc-steering-committee at haskell.org<mailto:ghc-steering-committee at 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&amp;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&amp;sdata=9DGVl6oJc0%2BIQekuXf
> |  zwqviiaT%2FaHZIlIk3R5aMZssA%3D&amp;reserved=0
> |  >
> |  _______________________________________________
> |  ghc-steering-committee mailing list
> |  ghc-steering-committee at haskell.org<mailto:ghc-steering-committee at 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&amp;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&amp;sdata=QZlV0RrRttaiDdrQNiRB
> |  vUhS6il1DydPX5cyl%2BdILbI%3D&amp;reserved=0
>
_______________________________________________
ghc-steering-committee mailing list
ghc-steering-committee at haskell.org<mailto:ghc-steering-committee at haskell.org>
https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committee&data=04%7C01%7Csimonpj%40microsoft.com%7Ce0e7e14d1ba74d216e9e08d8dff055dc%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637505571335630737%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=6A2TJygA2WZ29GqX4kBSJmZi5kX2O2Tmawv4SvpNZuk%3D&reserved=0>
_______________________________________________
ghc-steering-committee mailing list
ghc-steering-committee at haskell.org<mailto:ghc-steering-committee at haskell.org>
https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committee&data=04%7C01%7Csimonpj%40microsoft.com%7Ce0e7e14d1ba74d216e9e08d8dff055dc%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637505571335630737%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=6A2TJygA2WZ29GqX4kBSJmZi5kX2O2Tmawv4SvpNZuk%3D&reserved=0>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20210305/b5315c37/attachment-0001.html>

From trupill at gmail.com  Fri Mar  5 17:35:22 2021
From: trupill at gmail.com (Alejandro Serrano Mena)
Date: Fri, 5 Mar 2021 18:35:22 +0100
Subject: [ghc-steering-committee] Modification to record dot syntax
	propsal
In-Reply-To: <AM0PR83MB02760B6E11F569F5DAA13041AD969@AM0PR83MB0276.EURPRD83.prod.outlook.com>
References: <CAGK9nuoy3cbiESa2goLzzOoYxDMXNKm14bGSxmKDRerbJcA7Ng@mail.gmail.com>
 <6A02AD21-9E34-4879-A40F-5DB86D9A129F@seidel.io>
 <CAH6fHQn0K23Rhi6mi=A2DePxPzZxLAE6TUEMnxvwi2_17G==jg@mail.gmail.com>
 <CAGK9nuqWTYSFabPNk8s7Kzv7Fw4f=5k8dXTpGezhqoPixc86aQ@mail.gmail.com>
 <AM0PR83MB02760B6E11F569F5DAA13041AD969@AM0PR83MB0276.EURPRD83.prod.outlook.com>
Message-ID: <CAHnFXOs+SnodPG26tKkHAShy-fYwJZejH1E1iBxy1v8RXffV8A@mail.gmail.com>

The plan looks fine to me.

Alejandro

El El vie, 5 mar 2021 a las 18:19, Simon Peyton Jones via
ghc-steering-committee <ghc-steering-committee at haskell.org> escribió:

> 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 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.
>    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 <ghc-steering-committee-bounces at haskell.org>
> *On Behalf Of *Iavor Diatchki
> *Sent:* 05 March 2021 16:03
> *To:* Spiwack, Arnaud <arnaud.spiwack at tweag.io>; ghc-steering-committee <
> ghc-steering-committee at haskell.org>
> *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 <arnaud.spiwack at 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 <eric at 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 <iavor.diatchki at 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 <eric at 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 <ghc-steering-committee-
> > |  bounces at haskell.org> On Behalf Of Eric Seidel
> > |  Sent: 04 March 2021 14:38
> > |  To: ghc-steering-committee at haskell.org
> > |  Subject: Re: [ghc-steering-committee] Modification to record dot
> > |  syntax propsal
> > |
> > |  I agree with Richard and Joachim that it should be documented in the
> > |  user guide. It's much better to document features with the expected
> > |  level of support than to let users stumble upon them and make their
> > |  own assumptions about stability.
> > |
> > |  That being said, I don't see anything in the revised proposal about
> > |  the stability of OverloadedRecordUpdate. Are you saying that as part
> > |  of this revision, we'll explicitly accept OverloadedRecordDot and send
> > |  OverloadedRecordUpdate back for revision?
> > |
> > |  On Thu, Mar 4, 2021, at 04:46, Simon Peyton Jones via ghc-steering-
> > |  committee wrote:
> > |  >
> > |  > Friends
> > |  >
> > |  >
> > |  >
> > |  > We've agree to accept my suggestion below.
> > |  >
> > |  >
> > |  >
> > |  > But there is one point at issue: should OverloadedRecordUpdate be
> > |  > documented in the user manual, albeit identified as a not-yet-
> > |  accepted
> > |  > feature?
> > |  >
> > |  >
> > |  >
> > |  >  * Richard positively wants it in the manual
> > |  >  * Iavor positively doesn't want it there.
> > |  >
> > |  >
> > |  > I don't mind either way.
> > |  >
> > |  >
> > |  >
> > |  > What do others think?  It's not a big deal, but we owe the authors a
> > |  > decision.  Answer by the end of the week please, and I'll make a
> > |  > shepherd decision based on the opinions I get.
> > |  >
> > |  >
> > |  >
> > |  > Simon
> > |  >
> > |  >
> > |  >
> > |  >
> > |  >
> > |  > *From:* Simon Peyton Jones <simonpj at microsoft.com>
> > |  > *Sent:* 02 March 2021 12:45
> > |  > *To:* ghc-steering-committee <ghc-steering-committee at haskell.org>
> > |  > *Cc:* Simon Peyton Jones <simonpj at microsoft.com>
> > |  > *Subject:* RE: [ghc-steering-committee] Modification to record dot
> > |  > syntax propsal
> > |  >
> > |  >
> > |  >
> > |  > Friends
> > |  >
> > |  >
> > |  >
> > |  > Having consulted the authors, I propose that we do this:
> > |  >
> > |  >
> > |  >
> > |  >  * Proceed with OverloadedRecordDot for 9.2, exactly as in the
> > |  > original proposal except for the extension name.
> > |  >  * Record update will remain exactly as now, in 9.2; that is,
> > |  drawing
> > |  > back from the original proposal.
> > |  >  * There may be some *code* in 9.2 that allows overloaded record
> > |  > update, protected by OverloadedRecordUpdate, but not in the user
> > |  > manual, and not treated as an accepted proposal.   I don't think we
> > |  > should ask the authors to remove it, and it will allow
> > |  experimentation.
> > |  >  * Adam is leading on a revised record-update proposal. This will
> > |  cover
> > |  >    * the tradeoffs between type-changing and non-type-changing
> > |  update
> > |  >    * what the current record-update syntax stands for, and/or any
> > |  new
> > |  > syntax
> > |  >
> > |  >
> > |  > Is that acceptable to everyone?
> > |  >
> > |  >
> > |  >
> > |  > Simon
> > |  >
> > |  >
> > |  >
> > |  > *From:* ghc-steering-committee
> > |  > <ghc-steering-committee-bounces at haskell.org> *On Behalf Of *Simon
> > |  > Peyton Jones via ghc-steering-committee
> > |  > *Sent:* 01 March 2021 17:51
> > |  > *To:* Iavor Diatchki <iavor.diatchki at gmail.com>; Spiwack, Arnaud
> > |  > <arnaud.spiwack at tweag.io>
> > |  > *Cc:* ghc-steering-committee <ghc-steering-committee at haskell.org>
> > |  > *Subject:* Re: [ghc-steering-committee] Modification to record dot
> > |  > syntax propsal
> > |  >
> > |  >
> > |  >
> > |  > I don't buy the argument of "this is already accepted", as I don't
> > |  > think many of us had noticed that part of the proposal (I certainly
> > |  > didn't), and I think we should be flexible enough to revisit
> > |  previous
> > |  > decisions when we notice problems with them.
> > |  >
> > |  > I agree in principle that we can revisit decisions.   But we have to
> > |  be
> > |  > aware that it is potentially very discouraging for proposal authors
> > |  to
> > |  >
> > |  >  * propose something,
> > |  >  * have it *extensively* debated (including this very point),
> > |  >  * have it accepted,
> > |  >  * implement it,
> > |  > and then be told that the committee has changed its mind.  That's
> > |  > pretty bad from their point of view.
> > |  >
> > |  >
> > |  >
> > |  > Still, Adam is working on a new SetField proposal, so perhaps that's
> > |  a
> > |  > figleaf.  I'll consult them.
> > |  >
> > |  >
> > |  > Simon
> > |  >
> > |  >
> > |  >
> > |  >
> > |  >
> > |  > *From:* Iavor Diatchki <iavor.diatchki at gmail.com>
> > |  > *Sent:* 01 March 2021 17:23
> > |  > *To:* Spiwack, Arnaud <arnaud.spiwack at tweag.io>
> > |  > *Cc:* Simon Peyton Jones <simonpj at microsoft.com>;
> > |  > ghc-steering-committee <ghc-steering-committee at haskell.org>
> > |  > *Subject:* Re: [ghc-steering-committee] Modification to record dot
> > |  > syntax propsal
> > |  >
> > |  >
> > |  >
> > |  > Hello,
> > |  >
> > |  >
> > |  >
> > |  > I think there is a strong motivation to *at least* split the
> > |  > extensions:  with the current design, enabling the special `.`
> > |  notation
> > |  > also *disables* type changing record update, which has nothing to do
> > |  > with the `.` notation.
> > |  >
> > |  >
> > |  >
> > |  > My preference would be to:
> > |  >
> > |  >   1. Split the original proposal into two parts: one about `.`
> > |  > notation, the other about record update (as suggested by this
> > |  proposal)
> > |  >
> > |  >   2. Treat the `.` notation part as accepted
> > |  >
> > |  >   3. Require changes on the record update part, so that you don't
> > |  have
> > |  > to choose between it and type changing record updates, which are
> > |  quite
> > |  > useful, and I don't think we should aim for a Haskell without them.
> > |  >
> > |  >
> > |  >
> > |  > I don't buy the argument of "this is already accepted", as I don't
> > |  > think many of us had noticed that part of the proposal (I certainly
> > |  > didn't), and I think we should be flexible enough to revisit
> > |  previous
> > |  > decisions when we notice problems with them.
> > |  >
> > |  >
> > |  >
> > |  > -Iavor
> > |  >
> > |  >
> > |  >
> > |  >
> > |  >
> > |  >
> > |  >
> > |  > On Mon, Mar 1, 2021 at 1:40 AM Spiwack, Arnaud
> > |  <arnaud.spiwack at tweag.io> wrote:
> > |  >
> > |  > > Simon, all,
> > |  >
> > |  > >
> > |  >
> > |  > > After reading more of the PR thread (in particular the fews posts
> > |  after Simon's recommendation), I have to admit: I am thoroughly
> > |  confused. I'm not sure that two people in that thread have the same
> > |  motivation, end goal, or design in mind.
> > |  >
> > |  > >
> > |  >
> > |  > > The motivations provided by the modified *Alternatives* section is
> > |  not much more helpful (at the risk of caricaturing a little, it
> > |  basically reads: "we made two extensions rather than one because we
> > |  can"). Though it makes it clear that the end goal is to fold a bunch
> > |  of record-related extensions into one glorious record extension (well,
> > |  probably not fold them, but make a meta-extension that implies all the
> > |  extensions that we've decided we like).
> > |  >
> > |  > >
> > |  >
> > |  > > My starting point is that:
> > |  >
> > |  > > - Additional extensions have a maintenance cost
> > |  >
> > |  > > - Additional extensions impose a cognitive burden on their use
> > |  >
> > |  > > - I expect that a new extension will break my code in the next few
> > |  releases.
> > |  >
> > |  > >
> > |  >
> > |  > > Based on this, I don't care how this extension or the glorious
> > |  record extension are named; but if we want to have two extensions we
> > |  should have a serious reason. Right now, the one reason that I see
> > |  (and Iavor raised), is that the update part of `RecordDotSyntax` is
> > |  not backward compatible. Is it a strong enough reason? I don't know.
> > |  The only data point that I can provide is that when we discussed the
> > |  original proposal, I brought it up several times, and it didn't seem
> > |  very important at the time (the conversation focused on other points
> > |  of the proposal).
> > |  >
> > |  > >
> > |  >
> > |  > > So, I'm still reluctant. I feel that, at the very least, the
> > |  motivations are not well-enough articulated in the proposal (I'll make
> > |  a comment to this effect on Github when I'm done composing this
> > |  email).
> > |  >
> > |  > >
> > |  >
> > |  > > I appreciate that I'm in the minority here. Yet, I'm still
> > |  unconvinced.
> > |  >
> > |  > >
> > |  >
> > |  > > Best,
> > |  >
> > |  > > Arnaud
> > |  >
> > |  > >
> > |  >
> > |  > > On Sat, Feb 27, 2021 at 12:39 AM Simon Peyton Jones
> > |  <simonpj at microsoft.com> wrote:
> > |  >
> > |  > >> Generally, I'm not in favour in proposals which split extensions
> > |  though: we already have so many extensions. Are the reasons for this
> > |  split strong enough? I haven't had time to dig into the details.
> > |  >
> > |  > >> Arnaud, happily, you don't have to dig very deep - just read the
> > |  handful of posts following my recommendation.
> > |  >
> > |  > >>
> > |  >
> > |  > >> There seem to be two motivations.
> > |  >
> > |  > >>
> > |  >
> > |  > >>  1. There really are two orthogonal extensions, one for r.x
> > |  notation, and one for overloaded update.  Iavor likes the first but
> > |  not the second.  Neil likes both.  Having separate extensions lets us
> > |  experiment.
> > |  > >>
> > |  >
> > |  > >>  1. You suggest that changing the definition of RecordDotSyntax
> > |  in a subsequent release, e.g. by subsequently making it imply
> > |  NoFieldSelectors, would be fine. But it certainly imposes pain - some
> > |  programs would stop compiling.  The approach offered by this proposal
> > |  avoids that problem.
> > |  > >>
> > |  >
> > |  > >> Yes, there are lots of extensions surrounding records:
> > |  NoFieldSelectors, DuplicateRecordFields, NamedFieldPuns,
> > |  DisambiguateRecordFields, RecordWildCards.  It may not be pretty to
> > |  divide things up so fine, but it's not new.
> > |  >
> > |  > >>
> > |  >
> > |  > >>
> > |  >
> > |  > >> If there are alternative suggestions, let's hear them.
> > |  >
> > |  > >>
> > |  >
> > |  > >> Simon
> > |  >
> > |  > >>
> > |  >
> > |  > >> *From:* ghc-steering-committee <ghc-steering-committee-
> > |  bounces at haskell.org> *On Behalf Of *Spiwack, Arnaud
> > |  > >> *Sent:* 26 February 2021 22:33
> > |  > >> *To:* Iavor Diatchki <iavor.diatchki at gmail.com>
> > |  > >> *Cc:* ghc-steering-committee <ghc-steering-committee at haskell.org
> >
> > |  > >> *Subject:* Re: [ghc-steering-committee] Modification to record
> > |  dot syntax propsal
> > |  >
> > |  > >>
> > |  >
> > |  > >>
> > |  >
> > |  > >>> I do think that  reusing the record update syntax for the
> > |  overloaded monomorphic update is a mistake---it is not something I had
> > |  noticed during our original discussion.
> > |  >
> > |  > >>
> > |  >
> > |  > >> This is the one reason I can see for cutting this extension in
> > |  smaller pieces. But, then again, -XOverloadedRecordUpdate would be a
> > |  fork-like extension.
> > |  >
> > |  > >>
> > |  >
> > |  > >> Generally, I'm not in favour in proposals which split extensions
> > |  though: we already have so many extensions. Are the reasons for this
> > |  split strong enough? I haven't had time to dig into the details.
> > |  >
> > |  > >>
> > |  >
> > |  > >> I'm not sure that not having the design of the proposal quite
> > |  finalised is a good reason, extensions mutate in their first
> > |  iterations, I don't think that it's a problem.
> > |  >
> > |  > _______________________________________________
> > |  > ghc-steering-committee mailing list
> > |  > ghc-steering-committee at haskell.org
> > |  >
> > |
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail
> > |  .haskell.org
> <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&amp;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&amp;sdata=9DGVl6oJc0%2BIQekuXf
> > |  zwqviiaT%2FaHZIlIk3R5aMZssA%3D&amp;reserved=0
> > |  >
> > |  _______________________________________________
> > |  ghc-steering-committee mailing list
> > |  ghc-steering-committee at haskell.org
> > |
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail
> > |  .haskell.org
> <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&amp;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&amp;sdata=QZlV0RrRttaiDdrQNiRB
> > |  vUhS6il1DydPX5cyl%2BdILbI%3D&amp;reserved=0
> >
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committee&data=04%7C01%7Csimonpj%40microsoft.com%7Ce0e7e14d1ba74d216e9e08d8dff055dc%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637505571335630737%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=6A2TJygA2WZ29GqX4kBSJmZi5kX2O2Tmawv4SvpNZuk%3D&reserved=0>
>
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committee&data=04%7C01%7Csimonpj%40microsoft.com%7Ce0e7e14d1ba74d216e9e08d8dff055dc%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637505571335630737%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=6A2TJygA2WZ29GqX4kBSJmZi5kX2O2Tmawv4SvpNZuk%3D&reserved=0>
>
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20210305/70d57eb4/attachment-0001.html>

From rae at richarde.dev  Fri Mar  5 17:36:19 2021
From: rae at richarde.dev (Richard Eisenberg)
Date: Fri, 5 Mar 2021 17:36:19 +0000
Subject: [ghc-steering-committee] Modification to record dot
	syntax	propsal
In-Reply-To: <AM0PR83MB02760B6E11F569F5DAA13041AD969@AM0PR83MB0276.EURPRD83.prod.outlook.com>
References: <CAGK9nuoy3cbiESa2goLzzOoYxDMXNKm14bGSxmKDRerbJcA7Ng@mail.gmail.com>
 <6A02AD21-9E34-4879-A40F-5DB86D9A129F@seidel.io>
 <CAH6fHQn0K23Rhi6mi=A2DePxPzZxLAE6TUEMnxvwi2_17G==jg@mail.gmail.com>
 <CAGK9nuqWTYSFabPNk8s7Kzv7Fw4f=5k8dXTpGezhqoPixc86aQ@mail.gmail.com>
 <AM0PR83MB02760B6E11F569F5DAA13041AD969@AM0PR83MB0276.EURPRD83.prod.outlook.com>
Message-ID: <010f017803762b7a-8cf0e76a-8591-42bf-a07b-a4d229bd4762-000000@us-east-2.amazonses.com>

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 <ghc-steering-committee at haskell.org> 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 <ghc-steering-committee-bounces at haskell.org> On Behalf Of Iavor Diatchki
> Sent: 05 March 2021 16:03
> To: Spiwack, Arnaud <arnaud.spiwack at tweag.io>; ghc-steering-committee <ghc-steering-committee at haskell.org>
> 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 <arnaud.spiwack at tweag.io <mailto:arnaud.spiwack at 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 <eric at seidel.io <mailto:eric at 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 <iavor.diatchki at gmail.com <mailto:iavor.diatchki at 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 <eric at seidel.io <mailto:eric at 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 <ghc-steering-committee-
> > |  bounces at haskell.org <mailto:bounces at haskell.org>> On Behalf Of Eric Seidel
> > |  Sent: 04 March 2021 14:38
> > |  To: ghc-steering-committee at haskell.org <mailto:ghc-steering-committee at haskell.org>
> > |  Subject: Re: [ghc-steering-committee] Modification to record dot
> > |  syntax propsal
> > |  
> > |  I agree with Richard and Joachim that it should be documented in the
> > |  user guide. It's much better to document features with the expected
> > |  level of support than to let users stumble upon them and make their
> > |  own assumptions about stability.
> > |  
> > |  That being said, I don't see anything in the revised proposal about
> > |  the stability of OverloadedRecordUpdate. Are you saying that as part
> > |  of this revision, we'll explicitly accept OverloadedRecordDot and send
> > |  OverloadedRecordUpdate back for revision?
> > |  
> > |  On Thu, Mar 4, 2021, at 04:46, Simon Peyton Jones via ghc-steering-
> > |  committee wrote:
> > |  >
> > |  > Friends
> > |  >
> > |  >
> > |  >
> > |  > We've agree to accept my suggestion below.
> > |  >
> > |  >
> > |  >
> > |  > But there is one point at issue: should OverloadedRecordUpdate be
> > |  > documented in the user manual, albeit identified as a not-yet-
> > |  accepted
> > |  > feature?
> > |  >
> > |  >
> > |  >
> > |  >  * Richard positively wants it in the manual
> > |  >  * Iavor positively doesn't want it there.
> > |  >
> > |  >
> > |  > I don't mind either way.
> > |  >
> > |  >
> > |  >
> > |  > What do others think?  It's not a big deal, but we owe the authors a
> > |  > decision.  Answer by the end of the week please, and I'll make a
> > |  > shepherd decision based on the opinions I get.
> > |  >
> > |  >
> > |  >
> > |  > Simon
> > |  >
> > |  >
> > |  >
> > |  >
> > |  >
> > |  > *From:* Simon Peyton Jones <simonpj at microsoft.com <mailto:simonpj at microsoft.com>>
> > |  > *Sent:* 02 March 2021 12:45
> > |  > *To:* ghc-steering-committee <ghc-steering-committee at haskell.org <mailto:ghc-steering-committee at haskell.org>>
> > |  > *Cc:* Simon Peyton Jones <simonpj at microsoft.com <mailto:simonpj at microsoft.com>>
> > |  > *Subject:* RE: [ghc-steering-committee] Modification to record dot
> > |  > syntax propsal
> > |  >
> > |  >
> > |  >
> > |  > Friends
> > |  >
> > |  >
> > |  >
> > |  > Having consulted the authors, I propose that we do this:
> > |  >
> > |  >
> > |  >
> > |  >  * Proceed with OverloadedRecordDot for 9.2, exactly as in the
> > |  > original proposal except for the extension name.
> > |  >  * Record update will remain exactly as now, in 9.2; that is,
> > |  drawing
> > |  > back from the original proposal.
> > |  >  * There may be some *code* in 9.2 that allows overloaded record
> > |  > update, protected by OverloadedRecordUpdate, but not in the user
> > |  > manual, and not treated as an accepted proposal.   I don't think we
> > |  > should ask the authors to remove it, and it will allow
> > |  experimentation.
> > |  >  * Adam is leading on a revised record-update proposal. This will
> > |  cover
> > |  >    * the tradeoffs between type-changing and non-type-changing
> > |  update
> > |  >    * what the current record-update syntax stands for, and/or any
> > |  new
> > |  > syntax
> > |  >
> > |  >
> > |  > Is that acceptable to everyone?
> > |  >
> > |  >
> > |  >
> > |  > Simon
> > |  >
> > |  >
> > |  >
> > |  > *From:* ghc-steering-committee
> > |  > <ghc-steering-committee-bounces at haskell.org <mailto:ghc-steering-committee-bounces at haskell.org>> *On Behalf Of *Simon
> > |  > Peyton Jones via ghc-steering-committee
> > |  > *Sent:* 01 March 2021 17:51
> > |  > *To:* Iavor Diatchki <iavor.diatchki at gmail.com <mailto:iavor.diatchki at gmail.com>>; Spiwack, Arnaud
> > |  > <arnaud.spiwack at tweag.io <mailto:arnaud.spiwack at tweag.io>>
> > |  > *Cc:* ghc-steering-committee <ghc-steering-committee at haskell.org <mailto:ghc-steering-committee at haskell.org>>
> > |  > *Subject:* Re: [ghc-steering-committee] Modification to record dot
> > |  > syntax propsal
> > |  >
> > |  >
> > |  >
> > |  > I don't buy the argument of "this is already accepted", as I don't
> > |  > think many of us had noticed that part of the proposal (I certainly
> > |  > didn't), and I think we should be flexible enough to revisit
> > |  previous
> > |  > decisions when we notice problems with them.
> > |  >
> > |  > I agree in principle that we can revisit decisions.   But we have to
> > |  be
> > |  > aware that it is potentially very discouraging for proposal authors
> > |  to
> > |  >
> > |  >  * propose something,
> > |  >  * have it *extensively* debated (including this very point),
> > |  >  * have it accepted,
> > |  >  * implement it,
> > |  > and then be told that the committee has changed its mind.  That's
> > |  > pretty bad from their point of view.
> > |  >
> > |  >
> > |  >
> > |  > Still, Adam is working on a new SetField proposal, so perhaps that's
> > |  a
> > |  > figleaf.  I'll consult them.
> > |  >
> > |  >
> > |  > Simon
> > |  >
> > |  >
> > |  >
> > |  >
> > |  >
> > |  > *From:* Iavor Diatchki <iavor.diatchki at gmail.com <mailto:iavor.diatchki at gmail.com>>
> > |  > *Sent:* 01 March 2021 17:23
> > |  > *To:* Spiwack, Arnaud <arnaud.spiwack at tweag.io <mailto:arnaud.spiwack at tweag.io>>
> > |  > *Cc:* Simon Peyton Jones <simonpj at microsoft.com <mailto:simonpj at microsoft.com>>;
> > |  > ghc-steering-committee <ghc-steering-committee at haskell.org <mailto:ghc-steering-committee at haskell.org>>
> > |  > *Subject:* Re: [ghc-steering-committee] Modification to record dot
> > |  > syntax propsal
> > |  >
> > |  >
> > |  >
> > |  > Hello,
> > |  >
> > |  >
> > |  >
> > |  > I think there is a strong motivation to *at least* split the
> > |  > extensions:  with the current design, enabling the special `.`
> > |  notation
> > |  > also *disables* type changing record update, which has nothing to do
> > |  > with the `.` notation.
> > |  >
> > |  >
> > |  >
> > |  > My preference would be to:
> > |  >
> > |  >   1. Split the original proposal into two parts: one about `.`
> > |  > notation, the other about record update (as suggested by this
> > |  proposal)
> > |  >
> > |  >   2. Treat the `.` notation part as accepted
> > |  >
> > |  >   3. Require changes on the record update part, so that you don't
> > |  have
> > |  > to choose between it and type changing record updates, which are
> > |  quite
> > |  > useful, and I don't think we should aim for a Haskell without them.
> > |  >
> > |  >
> > |  >
> > |  > I don't buy the argument of "this is already accepted", as I don't
> > |  > think many of us had noticed that part of the proposal (I certainly
> > |  > didn't), and I think we should be flexible enough to revisit
> > |  previous
> > |  > decisions when we notice problems with them.
> > |  >
> > |  >
> > |  >
> > |  > -Iavor
> > |  >
> > |  >
> > |  >
> > |  >
> > |  >
> > |  >
> > |  >
> > |  > On Mon, Mar 1, 2021 at 1:40 AM Spiwack, Arnaud
> > |  <arnaud.spiwack at tweag.io <mailto:arnaud.spiwack at tweag.io>> wrote:
> > |  >
> > |  > > Simon, all,
> > |  >
> > |  > >
> > |  >
> > |  > > After reading more of the PR thread (in particular the fews posts
> > |  after Simon's recommendation), I have to admit: I am thoroughly
> > |  confused. I'm not sure that two people in that thread have the same
> > |  motivation, end goal, or design in mind.
> > |  >
> > |  > >
> > |  >
> > |  > > The motivations provided by the modified *Alternatives* section is
> > |  not much more helpful (at the risk of caricaturing a little, it
> > |  basically reads: "we made two extensions rather than one because we
> > |  can"). Though it makes it clear that the end goal is to fold a bunch
> > |  of record-related extensions into one glorious record extension (well,
> > |  probably not fold them, but make a meta-extension that implies all the
> > |  extensions that we've decided we like).
> > |  >
> > |  > >
> > |  >
> > |  > > My starting point is that:
> > |  >
> > |  > > - Additional extensions have a maintenance cost
> > |  >
> > |  > > - Additional extensions impose a cognitive burden on their use
> > |  >
> > |  > > - I expect that a new extension will break my code in the next few
> > |  releases.
> > |  >
> > |  > >
> > |  >
> > |  > > Based on this, I don't care how this extension or the glorious
> > |  record extension are named; but if we want to have two extensions we
> > |  should have a serious reason. Right now, the one reason that I see
> > |  (and Iavor raised), is that the update part of `RecordDotSyntax` is
> > |  not backward compatible. Is it a strong enough reason? I don't know.
> > |  The only data point that I can provide is that when we discussed the
> > |  original proposal, I brought it up several times, and it didn't seem
> > |  very important at the time (the conversation focused on other points
> > |  of the proposal).
> > |  >
> > |  > >
> > |  >
> > |  > > So, I'm still reluctant. I feel that, at the very least, the
> > |  motivations are not well-enough articulated in the proposal (I'll make
> > |  a comment to this effect on Github when I'm done composing this
> > |  email).
> > |  >
> > |  > >
> > |  >
> > |  > > I appreciate that I'm in the minority here. Yet, I'm still
> > |  unconvinced.
> > |  >
> > |  > >
> > |  >
> > |  > > Best,
> > |  >
> > |  > > Arnaud
> > |  >
> > |  > >
> > |  >
> > |  > > On Sat, Feb 27, 2021 at 12:39 AM Simon Peyton Jones
> > |  <simonpj at microsoft.com <mailto:simonpj at microsoft.com>> wrote:
> > |  >
> > |  > >> Generally, I'm not in favour in proposals which split extensions
> > |  though: we already have so many extensions. Are the reasons for this
> > |  split strong enough? I haven't had time to dig into the details.
> > |  >
> > |  > >> Arnaud, happily, you don't have to dig very deep - just read the
> > |  handful of posts following my recommendation.
> > |  >
> > |  > >>
> > |  >
> > |  > >> There seem to be two motivations.
> > |  >
> > |  > >>
> > |  >
> > |  > >>  1. There really are two orthogonal extensions, one for r.x
> > |  notation, and one for overloaded update.  Iavor likes the first but
> > |  not the second.  Neil likes both.  Having separate extensions lets us
> > |  experiment.
> > |  > >>
> > |  >
> > |  > >>  1. You suggest that changing the definition of RecordDotSyntax
> > |  in a subsequent release, e.g. by subsequently making it imply
> > |  NoFieldSelectors, would be fine. But it certainly imposes pain - some
> > |  programs would stop compiling.  The approach offered by this proposal
> > |  avoids that problem.
> > |  > >>
> > |  >
> > |  > >> Yes, there are lots of extensions surrounding records:
> > |  NoFieldSelectors, DuplicateRecordFields, NamedFieldPuns,
> > |  DisambiguateRecordFields, RecordWildCards.  It may not be pretty to
> > |  divide things up so fine, but it's not new.
> > |  >
> > |  > >>
> > |  >
> > |  > >>
> > |  >
> > |  > >> If there are alternative suggestions, let's hear them.
> > |  >
> > |  > >>
> > |  >
> > |  > >> Simon
> > |  >
> > |  > >>
> > |  >
> > |  > >> *From:* ghc-steering-committee <ghc-steering-committee-
> > |  bounces at haskell.org <mailto:bounces at haskell.org>> *On Behalf Of *Spiwack, Arnaud
> > |  > >> *Sent:* 26 February 2021 22:33
> > |  > >> *To:* Iavor Diatchki <iavor.diatchki at gmail.com <mailto:iavor.diatchki at gmail.com>>
> > |  > >> *Cc:* ghc-steering-committee <ghc-steering-committee at haskell.org <mailto:ghc-steering-committee at haskell.org>>
> > |  > >> *Subject:* Re: [ghc-steering-committee] Modification to record
> > |  dot syntax propsal
> > |  >
> > |  > >>
> > |  >
> > |  > >>
> > |  >
> > |  > >>> I do think that  reusing the record update syntax for the
> > |  overloaded monomorphic update is a mistake---it is not something I had
> > |  noticed during our original discussion.
> > |  >
> > |  > >>
> > |  >
> > |  > >> This is the one reason I can see for cutting this extension in
> > |  smaller pieces. But, then again, -XOverloadedRecordUpdate would be a
> > |  fork-like extension.
> > |  >
> > |  > >>
> > |  >
> > |  > >> Generally, I'm not in favour in proposals which split extensions
> > |  though: we already have so many extensions. Are the reasons for this
> > |  split strong enough? I haven't had time to dig into the details.
> > |  >
> > |  > >>
> > |  >
> > |  > >> I'm not sure that not having the design of the proposal quite
> > |  finalised is a good reason, extensions mutate in their first
> > |  iterations, I don't think that it's a problem.
> > |  >
> > |  > _______________________________________________
> > |  > ghc-steering-committee mailing list
> > |  > ghc-steering-committee at haskell.org <mailto:ghc-steering-committee at 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&amp;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&amp;sdata=9DGVl6oJc0%2BIQekuXf
> > |  zwqviiaT%2FaHZIlIk3R5aMZssA%3D&amp;reserved=0
> > |  >
> > |  _______________________________________________
> > |  ghc-steering-committee mailing list
> > |  ghc-steering-committee at haskell.org <mailto:ghc-steering-committee at 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&amp;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&amp;sdata=QZlV0RrRttaiDdrQNiRB
> > |  vUhS6il1DydPX5cyl%2BdILbI%3D&amp;reserved=0
> >
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org <mailto:ghc-steering-committee at haskell.org>
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committee&data=04%7C01%7Csimonpj%40microsoft.com%7Ce0e7e14d1ba74d216e9e08d8dff055dc%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637505571335630737%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=6A2TJygA2WZ29GqX4kBSJmZi5kX2O2Tmawv4SvpNZuk%3D&reserved=0>
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org <mailto:ghc-steering-committee at haskell.org>
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committee&data=04%7C01%7Csimonpj%40microsoft.com%7Ce0e7e14d1ba74d216e9e08d8dff055dc%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637505571335630737%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=6A2TJygA2WZ29GqX4kBSJmZi5kX2O2Tmawv4SvpNZuk%3D&reserved=0>_______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20210305/d93844d4/attachment-0001.html>

From trupill at gmail.com  Fri Mar  5 17:45:36 2021
From: trupill at gmail.com (Alejandro Serrano Mena)
Date: Fri, 5 Mar 2021 18:45:36 +0100
Subject: [ghc-steering-committee] Modification to record dot syntax
	propsal
In-Reply-To: <010f017803762b7a-8cf0e76a-8591-42bf-a07b-a4d229bd4762-000000@us-east-2.amazonses.com>
References: <CAGK9nuoy3cbiESa2goLzzOoYxDMXNKm14bGSxmKDRerbJcA7Ng@mail.gmail.com>
 <6A02AD21-9E34-4879-A40F-5DB86D9A129F@seidel.io>
 <CAH6fHQn0K23Rhi6mi=A2DePxPzZxLAE6TUEMnxvwi2_17G==jg@mail.gmail.com>
 <CAGK9nuqWTYSFabPNk8s7Kzv7Fw4f=5k8dXTpGezhqoPixc86aQ@mail.gmail.com>
 <AM0PR83MB02760B6E11F569F5DAA13041AD969@AM0PR83MB0276.EURPRD83.prod.outlook.com>
 <010f017803762b7a-8cf0e76a-8591-42bf-a07b-a4d229bd4762-000000@us-east-2.amazonses.com>
Message-ID: <CAHnFXOutYYGEoePrGOLS-FmA8gO=rJnHcS0TFFUbbRsqtSsHxQ@mail.gmail.com>

I haven’t talked too much because I did not follow the original discussion
in depth. However, a change of what record syntax can do seems undesirable
to me, too; and I think just the “getter” part is an improvements over the
current status quo. So I am happy with Simon’s wording of the situation.

Alejandro

El El vie, 5 mar 2021 a las 18:36, Richard Eisenberg <rae at richarde.dev>
escribió:

> 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
> <ghc-steering-committee at haskell.org> 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.
>
>
>    1. 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.
>    2. 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.
>    3. 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 <ghc-steering-committee-bounces at haskell.org
> > *On Behalf Of *Iavor Diatchki
> *Sent:* 05 March 2021 16:03
> *To:* Spiwack, Arnaud <arnaud.spiwack at tweag.io>; ghc-steering-committee <
> ghc-steering-committee at haskell.org>
> *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 <arnaud.spiwack at 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 <eric at 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 <iavor.diatchki at 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 <eric at 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 <ghc-steering-committee-
> > |  bounces at haskell.org> On Behalf Of Eric Seidel
> > |  Sent: 04 March 2021 14:38
> > |  To: ghc-steering-committee at haskell.org
> > |  Subject: Re: [ghc-steering-committee] Modification to record dot
> > |  syntax propsal
> > |
> > |  I agree with Richard and Joachim that it should be documented in the
> > |  user guide. It's much better to document features with the expected
> > |  level of support than to let users stumble upon them and make their
> > |  own assumptions about stability.
> > |
> > |  That being said, I don't see anything in the revised proposal about
> > |  the stability of OverloadedRecordUpdate. Are you saying that as part
> > |  of this revision, we'll explicitly accept OverloadedRecordDot and send
> > |  OverloadedRecordUpdate back for revision?
> > |
> > |  On Thu, Mar 4, 2021, at 04:46, Simon Peyton Jones via ghc-steering-
> > |  committee wrote:
> > |  >
> > |  > Friends
> > |  >
> > |  >
> > |  >
> > |  > We've agree to accept my suggestion below.
> > |  >
> > |  >
> > |  >
> > |  > But there is one point at issue: should OverloadedRecordUpdate be
> > |  > documented in the user manual, albeit identified as a not-yet-
> > |  accepted
> > |  > feature?
> > |  >
> > |  >
> > |  >
> > |  >  * Richard positively wants it in the manual
> > |  >  * Iavor positively doesn't want it there.
> > |  >
> > |  >
> > |  > I don't mind either way.
> > |  >
> > |  >
> > |  >
> > |  > What do others think?  It's not a big deal, but we owe the authors a
> > |  > decision.  Answer by the end of the week please, and I'll make a
> > |  > shepherd decision based on the opinions I get.
> > |  >
> > |  >
> > |  >
> > |  > Simon
> > |  >
> > |  >
> > |  >
> > |  >
> > |  >
> > |  > *From:* Simon Peyton Jones <simonpj at microsoft.com>
> > |  > *Sent:* 02 March 2021 12:45
> > |  > *To:* ghc-steering-committee <ghc-steering-committee at haskell.org>
> > |  > *Cc:* Simon Peyton Jones <simonpj at microsoft.com>
> > |  > *Subject:* RE: [ghc-steering-committee] Modification to record dot
> > |  > syntax propsal
> > |  >
> > |  >
> > |  >
> > |  > Friends
> > |  >
> > |  >
> > |  >
> > |  > Having consulted the authors, I propose that we do this:
> > |  >
> > |  >
> > |  >
> > |  >  * Proceed with OverloadedRecordDot for 9.2, exactly as in the
> > |  > original proposal except for the extension name.
> > |  >  * Record update will remain exactly as now, in 9.2; that is,
> > |  drawing
> > |  > back from the original proposal.
> > |  >  * There may be some *code* in 9.2 that allows overloaded record
> > |  > update, protected by OverloadedRecordUpdate, but not in the user
> > |  > manual, and not treated as an accepted proposal.   I don't think we
> > |  > should ask the authors to remove it, and it will allow
> > |  experimentation.
> > |  >  * Adam is leading on a revised record-update proposal. This will
> > |  cover
> > |  >    * the tradeoffs between type-changing and non-type-changing
> > |  update
> > |  >    * what the current record-update syntax stands for, and/or any
> > |  new
> > |  > syntax
> > |  >
> > |  >
> > |  > Is that acceptable to everyone?
> > |  >
> > |  >
> > |  >
> > |  > Simon
> > |  >
> > |  >
> > |  >
> > |  > *From:* ghc-steering-committee
> > |  > <ghc-steering-committee-bounces at haskell.org> *On Behalf Of *Simon
> > |  > Peyton Jones via ghc-steering-committee
> > |  > *Sent:* 01 March 2021 17:51
> > |  > *To:* Iavor Diatchki <iavor.diatchki at gmail.com>; Spiwack, Arnaud
> > |  > <arnaud.spiwack at tweag.io>
> > |  > *Cc:* ghc-steering-committee <ghc-steering-committee at haskell.org>
> > |  > *Subject:* Re: [ghc-steering-committee] Modification to record dot
> > |  > syntax propsal
> > |  >
> > |  >
> > |  >
> > |  > I don't buy the argument of "this is already accepted", as I don't
> > |  > think many of us had noticed that part of the proposal (I certainly
> > |  > didn't), and I think we should be flexible enough to revisit
> > |  previous
> > |  > decisions when we notice problems with them.
> > |  >
> > |  > I agree in principle that we can revisit decisions.   But we have to
> > |  be
> > |  > aware that it is potentially very discouraging for proposal authors
> > |  to
> > |  >
> > |  >  * propose something,
> > |  >  * have it *extensively* debated (including this very point),
> > |  >  * have it accepted,
> > |  >  * implement it,
> > |  > and then be told that the committee has changed its mind.  That's
> > |  > pretty bad from their point of view.
> > |  >
> > |  >
> > |  >
> > |  > Still, Adam is working on a new SetField proposal, so perhaps that's
> > |  a
> > |  > figleaf.  I'll consult them.
> > |  >
> > |  >
> > |  > Simon
> > |  >
> > |  >
> > |  >
> > |  >
> > |  >
> > |  > *From:* Iavor Diatchki <iavor.diatchki at gmail.com>
> > |  > *Sent:* 01 March 2021 17:23
> > |  > *To:* Spiwack, Arnaud <arnaud.spiwack at tweag.io>
> > |  > *Cc:* Simon Peyton Jones <simonpj at microsoft.com>;
> > |  > ghc-steering-committee <ghc-steering-committee at haskell.org>
> > |  > *Subject:* Re: [ghc-steering-committee] Modification to record dot
> > |  > syntax propsal
> > |  >
> > |  >
> > |  >
> > |  > Hello,
> > |  >
> > |  >
> > |  >
> > |  > I think there is a strong motivation to *at least* split the
> > |  > extensions:  with the current design, enabling the special `.`
> > |  notation
> > |  > also *disables* type changing record update, which has nothing to do
> > |  > with the `.` notation.
> > |  >
> > |  >
> > |  >
> > |  > My preference would be to:
> > |  >
> > |  >   1. Split the original proposal into two parts: one about `.`
> > |  > notation, the other about record update (as suggested by this
> > |  proposal)
> > |  >
> > |  >   2. Treat the `.` notation part as accepted
> > |  >
> > |  >   3. Require changes on the record update part, so that you don't
> > |  have
> > |  > to choose between it and type changing record updates, which are
> > |  quite
> > |  > useful, and I don't think we should aim for a Haskell without them.
> > |  >
> > |  >
> > |  >
> > |  > I don't buy the argument of "this is already accepted", as I don't
> > |  > think many of us had noticed that part of the proposal (I certainly
> > |  > didn't), and I think we should be flexible enough to revisit
> > |  previous
> > |  > decisions when we notice problems with them.
> > |  >
> > |  >
> > |  >
> > |  > -Iavor
> > |  >
> > |  >
> > |  >
> > |  >
> > |  >
> > |  >
> > |  >
> > |  > On Mon, Mar 1, 2021 at 1:40 AM Spiwack, Arnaud
> > |  <arnaud.spiwack at tweag.io> wrote:
> > |  >
> > |  > > Simon, all,
> > |  >
> > |  > >
> > |  >
> > |  > > After reading more of the PR thread (in particular the fews posts
> > |  after Simon's recommendation), I have to admit: I am thoroughly
> > |  confused. I'm not sure that two people in that thread have the same
> > |  motivation, end goal, or design in mind.
> > |  >
> > |  > >
> > |  >
> > |  > > The motivations provided by the modified *Alternatives* section is
> > |  not much more helpful (at the risk of caricaturing a little, it
> > |  basically reads: "we made two extensions rather than one because we
> > |  can"). Though it makes it clear that the end goal is to fold a bunch
> > |  of record-related extensions into one glorious record extension (well,
> > |  probably not fold them, but make a meta-extension that implies all the
> > |  extensions that we've decided we like).
> > |  >
> > |  > >
> > |  >
> > |  > > My starting point is that:
> > |  >
> > |  > > - Additional extensions have a maintenance cost
> > |  >
> > |  > > - Additional extensions impose a cognitive burden on their use
> > |  >
> > |  > > - I expect that a new extension will break my code in the next few
> > |  releases.
> > |  >
> > |  > >
> > |  >
> > |  > > Based on this, I don't care how this extension or the glorious
> > |  record extension are named; but if we want to have two extensions we
> > |  should have a serious reason. Right now, the one reason that I see
> > |  (and Iavor raised), is that the update part of `RecordDotSyntax` is
> > |  not backward compatible. Is it a strong enough reason? I don't know.
> > |  The only data point that I can provide is that when we discussed the
> > |  original proposal, I brought it up several times, and it didn't seem
> > |  very important at the time (the conversation focused on other points
> > |  of the proposal).
> > |  >
> > |  > >
> > |  >
> > |  > > So, I'm still reluctant. I feel that, at the very least, the
> > |  motivations are not well-enough articulated in the proposal (I'll make
> > |  a comment to this effect on Github when I'm done composing this
> > |  email).
> > |  >
> > |  > >
> > |  >
> > |  > > I appreciate that I'm in the minority here. Yet, I'm still
> > |  unconvinced.
> > |  >
> > |  > >
> > |  >
> > |  > > Best,
> > |  >
> > |  > > Arnaud
> > |  >
> > |  > >
> > |  >
> > |  > > On Sat, Feb 27, 2021 at 12:39 AM Simon Peyton Jones
> > |  <simonpj at microsoft.com> wrote:
> > |  >
> > |  > >> Generally, I'm not in favour in proposals which split extensions
> > |  though: we already have so many extensions. Are the reasons for this
> > |  split strong enough? I haven't had time to dig into the details.
> > |  >
> > |  > >> Arnaud, happily, you don't have to dig very deep - just read the
> > |  handful of posts following my recommendation.
> > |  >
> > |  > >>
> > |  >
> > |  > >> There seem to be two motivations.
> > |  >
> > |  > >>
> > |  >
> > |  > >>  1. There really are two orthogonal extensions, one for r.x
> > |  notation, and one for overloaded update.  Iavor likes the first but
> > |  not the second.  Neil likes both.  Having separate extensions lets us
> > |  experiment.
> > |  > >>
> > |  >
> > |  > >>  1. You suggest that changing the definition of RecordDotSyntax
> > |  in a subsequent release, e.g. by subsequently making it imply
> > |  NoFieldSelectors, would be fine. But it certainly imposes pain - some
> > |  programs would stop compiling.  The approach offered by this proposal
> > |  avoids that problem.
> > |  > >>
> > |  >
> > |  > >> Yes, there are lots of extensions surrounding records:
> > |  NoFieldSelectors, DuplicateRecordFields, NamedFieldPuns,
> > |  DisambiguateRecordFields, RecordWildCards.  It may not be pretty to
> > |  divide things up so fine, but it's not new.
> > |  >
> > |  > >>
> > |  >
> > |  > >>
> > |  >
> > |  > >> If there are alternative suggestions, let's hear them.
> > |  >
> > |  > >>
> > |  >
> > |  > >> Simon
> > |  >
> > |  > >>
> > |  >
> > |  > >> *From:* ghc-steering-committee <ghc-steering-committee-
> > |  bounces at haskell.org> *On Behalf Of *Spiwack, Arnaud
> > |  > >> *Sent:* 26 February 2021 22:33
> > |  > >> *To:* Iavor Diatchki <iavor.diatchki at gmail.com>
> > |  > >> *Cc:* ghc-steering-committee <ghc-steering-committee at haskell.org
> >
> > |  > >> *Subject:* Re: [ghc-steering-committee] Modification to record
> > |  dot syntax propsal
> > |  >
> > |  > >>
> > |  >
> > |  > >>
> > |  >
> > |  > >>> I do think that  reusing the record update syntax for the
> > |  overloaded monomorphic update is a mistake---it is not something I had
> > |  noticed during our original discussion.
> > |  >
> > |  > >>
> > |  >
> > |  > >> This is the one reason I can see for cutting this extension in
> > |  smaller pieces. But, then again, -XOverloadedRecordUpdate would be a
> > |  fork-like extension.
> > |  >
> > |  > >>
> > |  >
> > |  > >> Generally, I'm not in favour in proposals which split extensions
> > |  though: we already have so many extensions. Are the reasons for this
> > |  split strong enough? I haven't had time to dig into the details.
> > |  >
> > |  > >>
> > |  >
> > |  > >> I'm not sure that not having the design of the proposal quite
> > |  finalised is a good reason, extensions mutate in their first
> > |  iterations, I don't think that it's a problem.
> > |  >
> > |  > _______________________________________________
> > |  > ghc-steering-committee mailing list
> > |  > ghc-steering-committee at haskell.org
> > |  >
> > |
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail
> > |  .haskell.org
> <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&amp;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&amp;sdata=9DGVl6oJc0%2BIQekuXf
> > |  zwqviiaT%2FaHZIlIk3R5aMZssA%3D&amp;reserved=0
> > |  >
> > |  _______________________________________________
> > |  ghc-steering-committee mailing list
> > |  ghc-steering-committee at haskell.org
> > |
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail
> > |  .haskell.org
> <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&amp;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&amp;sdata=QZlV0RrRttaiDdrQNiRB
> > |  vUhS6il1DydPX5cyl%2BdILbI%3D&amp;reserved=0
> >
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committee&data=04%7C01%7Csimonpj%40microsoft.com%7Ce0e7e14d1ba74d216e9e08d8dff055dc%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637505571335630737%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=6A2TJygA2WZ29GqX4kBSJmZi5kX2O2Tmawv4SvpNZuk%3D&reserved=0>
>
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committee&data=04%7C01%7Csimonpj%40microsoft.com%7Ce0e7e14d1ba74d216e9e08d8dff055dc%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637505571335630737%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=6A2TJygA2WZ29GqX4kBSJmZi5kX2O2Tmawv4SvpNZuk%3D&reserved=0>
>
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
>
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20210305/46eec740/attachment-0001.html>

From trupill at gmail.com  Fri Mar  5 17:46:22 2021
From: trupill at gmail.com (Alejandro Serrano Mena)
Date: Fri, 5 Mar 2021 18:46:22 +0100
Subject: [ghc-steering-committee] #403: Cleanup lexical structure,
 recommendation: accept
In-Reply-To: <VI1PR83MB02229E22E39517DA61FC0427AD969@VI1PR83MB0222.EURPRD83.prod.outlook.com>
References: <CAH6fHQnGv72AF1PrxQhyDSNcgK0gwwaJzHYbhfc+hn44SD1+4w@mail.gmail.com>
 <VI1PR83MB02229E22E39517DA61FC0427AD969@VI1PR83MB0222.EURPRD83.prod.outlook.com>
Message-ID: <CAHnFXOvDF_MYxjS-u0dvo+x9Fdg_rLcZom_hbXoEKmL-9_GyCg@mail.gmail.com>

This proposal seems fine to me.

Alejandro

El El vie, 5 mar 2021 a las 10:22, Simon Peyton Jones via
ghc-steering-committee <ghc-steering-committee at haskell.org> escribió:

> I don’t have a well-informed opinion, but I certainly have no objection.
>
>
>
> Simon
>
>
>
> *From:* ghc-steering-committee <ghc-steering-committee-bounces at haskell.org>
> *On Behalf Of *Spiwack, Arnaud
> *Sent:* 04 March 2021 14:54
> *To:* GHC Steering committee <ghc-steering-committee at haskell.org>
> *Subject:* [ghc-steering-committee] #403: Cleanup lexical structure,
> recommendation: accept
>
>
>
> Dear all,
>
>
>
> As the shepherd for proposal #403 Cleanup lexical structure of numbers
> and identifiers
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%2Fpull%2F403&data=04%7C01%7Csimonpj%40microsoft.com%7Cb28a9399e2fd44379fd308d8df1d66b0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637504665725379654%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=Rfp%2F%2BPsrs%2FQWa9k67NTAOLAI7PXccca%2BVLBZvcNVYME%3D&reserved=0>,
> let me recommend acceptance.
>
>
>
> This proposal does two things related to unicode characters
>
>    - Codify the actual current lexing of unicode symbols, which is
>    actually different from the Haskell 2010 report (in particular, only ascii
>    digits are allowed in number literals)
>    - Adds the possibility to use unicode letters which are neither upper
>    case nor lower case (such as many asian scripts) as trailing symbols for
>    identifier (as well as in String and Char literals)
>
> It doesn't make it possible (nor close the door) to use letter-like
> numbers (such as latin numerals) as identifiers, nor use non-ascii digits
> in number literals.
>
>
>
> As the title entails, it's essentially a clean up of the documentation, to
> match reality. It seems quite uncontroversial.
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20210305/4674ab39/attachment.html>

From iavor.diatchki at gmail.com  Fri Mar  5 18:03:45 2021
From: iavor.diatchki at gmail.com (Iavor Diatchki)
Date: Fri, 5 Mar 2021 10:03:45 -0800
Subject: [ghc-steering-committee] #403: Cleanup lexical structure,
 recommendation: accept
In-Reply-To: <CAHnFXOvDF_MYxjS-u0dvo+x9Fdg_rLcZom_hbXoEKmL-9_GyCg@mail.gmail.com>
References: <CAH6fHQnGv72AF1PrxQhyDSNcgK0gwwaJzHYbhfc+hn44SD1+4w@mail.gmail.com>
 <VI1PR83MB02229E22E39517DA61FC0427AD969@VI1PR83MB0222.EURPRD83.prod.outlook.com>
 <CAHnFXOvDF_MYxjS-u0dvo+x9Fdg_rLcZom_hbXoEKmL-9_GyCg@mail.gmail.com>
Message-ID: <CAGK9nupRPwc1hRx_AmGFujfXBUwX63Msph90nBYv8irdnBOy7A@mail.gmail.com>

I think this looks reasonable too (with the qualification that I didn't
look at it in much detail).

On Fri, Mar 5, 2021 at 9:46 AM Alejandro Serrano Mena <trupill at gmail.com>
wrote:

> This proposal seems fine to me.
>
> Alejandro
>
> El El vie, 5 mar 2021 a las 10:22, Simon Peyton Jones via
> ghc-steering-committee <ghc-steering-committee at haskell.org> escribió:
>
>> I don’t have a well-informed opinion, but I certainly have no objection.
>>
>>
>>
>> Simon
>>
>>
>>
>> *From:* ghc-steering-committee <
>> ghc-steering-committee-bounces at haskell.org> *On Behalf Of *Spiwack,
>> Arnaud
>> *Sent:* 04 March 2021 14:54
>> *To:* GHC Steering committee <ghc-steering-committee at haskell.org>
>> *Subject:* [ghc-steering-committee] #403: Cleanup lexical structure,
>> recommendation: accept
>>
>>
>>
>> Dear all,
>>
>>
>>
>> As the shepherd for proposal #403 Cleanup lexical structure of numbers
>> and identifiers
>> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%2Fpull%2F403&data=04%7C01%7Csimonpj%40microsoft.com%7Cb28a9399e2fd44379fd308d8df1d66b0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637504665725379654%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=Rfp%2F%2BPsrs%2FQWa9k67NTAOLAI7PXccca%2BVLBZvcNVYME%3D&reserved=0>,
>> let me recommend acceptance.
>>
>>
>>
>> This proposal does two things related to unicode characters
>>
>>    - Codify the actual current lexing of unicode symbols, which is
>>    actually different from the Haskell 2010 report (in particular, only ascii
>>    digits are allowed in number literals)
>>    - Adds the possibility to use unicode letters which are neither upper
>>    case nor lower case (such as many asian scripts) as trailing symbols for
>>    identifier (as well as in String and Char literals)
>>
>> It doesn't make it possible (nor close the door) to use letter-like
>> numbers (such as latin numerals) as identifiers, nor use non-ascii digits
>> in number literals.
>>
>>
>>
>> As the title entails, it's essentially a clean up of the documentation,
>> to match reality. It seems quite uncontroversial.
>> _______________________________________________
>> ghc-steering-committee mailing list
>> ghc-steering-committee at haskell.org
>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20210305/fe2d238d/attachment.html>

From iavor.diatchki at gmail.com  Fri Mar  5 19:42:19 2021
From: iavor.diatchki at gmail.com (Iavor Diatchki)
Date: Fri, 5 Mar 2021 11:42:19 -0800
Subject: [ghc-steering-committee] Status
In-Reply-To: <VI1PR83MB0222389754916F1F2E3155ECAD859@VI1PR83MB0222.EURPRD83.prod.outlook.com>
References: <7494e545ea1a9ce59053e0d685c81299922ed62b.camel@joachim-breitner.de>
 <CAGK9nupGZE1Ncdwfz3HXbtrxqvzSeV1zJ9b18BVHHio8Xu32jQ@mail.gmail.com>
 <VI1PR83MB0222389754916F1F2E3155ECAD859@VI1PR83MB0222.EURPRD83.prod.outlook.com>
Message-ID: <CAGK9nupTPOX66xMiB9VjbjpQvkb7_sDrNnbrZb=AJgtDs1XGuA@mail.gmail.com>

I am being nudged to do something with this proposal,  but I am not sure
what...   Is the rest of the committee OK with moving it back "revisions
required", and if so what revisions would we like?

I would be quite happy if someone else wanted to shephard this.  As I
mentioned before, I don't have much interest in DH, so I have not followed
the really long discussion related to that, and if and how it might relate
to #281.

My recommendation for the moment would be:
   * This seems like a useful feature independent of DH, so it would be
nice to come up with a concise notation to use the feature on its own,
without worrying about DH.

Please let me know what you think, as I am not sure what is the committee's
stance on the proposal.

-Iavor





On Thu, Feb 18, 2021 at 1:54 PM Simon Peyton Jones <simonpj at microsoft.com>
wrote:

> There has been a broad further discussion.
>
> What we advertise is that, rather that leave a proposal “under committee
> review”, we will push it back to the author with an invitation to resubmit
> when the discussion has died down and they feel ready to submit a proposal,
> revised in the light of the discussion.  That’s different to reject… it
> means that there is an ongoing debate so it’s not a good time for the
> committee to make a decision.
>
>
> Simon
>
>
>
> *From:* ghc-steering-committee <ghc-steering-committee-bounces at haskell.org>
> *On Behalf Of *Iavor Diatchki
> *Sent:* 18 February 2021 16:47
> *To:* Joachim Breitner <mail at joachim-breitner.de>
> *Cc:* ghc-steering-committee <ghc-steering-committee at haskell.org>
> *Subject:* Re: [ghc-steering-committee] Status
>
>
>
> On #381 I think the idea of visible quantification makes sense every now
> and then, but I don't like the concrete details of the proposal: the magic
> lifting of terms to types seems quite complicated, and using `type` as an
> explicit herald doesn't look nice.  So I don't think it's the right design,
> and therefore I suggest we reject the proposal.
>
>
>
> I am sure that others would disagree as apparently this is an essential
> part of dependent Haskell.   I have not followed the large discussion that
> Richard created, as I am not particularly interested in the design being
> proposed, so perhaps someone else should champion this.
>
>
>
> Aslo, I am not sure if I am actually on the committee, as I thought my
> term had expired?  That might be more reason for someone else to pick it up.
>
>
>
> -Iavor
>
>
>
>
>
>
>
> On Thu, Feb 18, 2021 at 2:32 AM Joachim Breitner <mail at joachim-breitner.de>
> wrote:
>
> Dear Committee,
>
> another status update, because why not.
>
> A small reminder: These mails have two sections, one that’s a delta
> since last status, but below is a summary of all proposals we have to
> act on. Please at least scroll through that on each status mail to see
> if you are listed, maybe you forgot something (or I made a mistake).
>
> So here’s the delta since last month.
>
>  * GHC2021 defined! Yay!
>
>  * Bylaws merged! Yay
>
>  * Simon², Iavor, Richard and me had thus their terms expired.
>
>    The Simons, as key members, wanted to continue and were
>    voted back in.
>
>    The others are now “expiring”, until the next nomination round
>    concludes. Alejandro is going to run that process.
>
>  * we were asked to review these proposals:
>    #390: Fine-grained pragmas, Shepherd: Vitaly
>
>  * we have a recommendation from the shepherd about:
>    #368: Warn on prefix/suffix operators (accept)
>
>  * we have sent the following proposals back to revision
>    - none -
>
>  * we decided about the following proposals
>    #313: Delimited continuation primops (accept)
>    #387: The Char kind (accept)
>    #368: Warn on prefix/suffix operators (accept)
>
> We currently have to act on the following 5 proposals, down by 2.
>
> ## Waiting for committee decision
>
> #381: Visible 'forall' in types of terms, Shepherd: Iavor
>       Recommendation was to reject, but discussion went into the more
>       abstract “whither dependent Haskell”. But what does this mean
>       for this proposal?
>       Iavor, can you pick this up again?
>
> #369: Add sumToTag# primop, Shepherd: Eric
>       Essentially accepted, waiting for feedback from the author on
>       final tweaks. Eric, care to nudge the author, or just do it?
>
> #302: \of, Shepherd: Cale
>       No new discussion yet. It seems there was some confusion, which
>       was cleared up by Tom, and Cale said he’ll pick it up now again.
>
>
> ## Waiting for Shepherd action
>
> #367: Clarify primops using unboxed sums, Shepherd: Simon Marlow
>       Simon said he’d reject it on the Github PR. Still waiting
>       for the discussion to start on the mailing list.
>
> #390: Fine-grained pragmas, Shepherd: Vitaly
>       Still kinda new, but a recommendation would be good soon.
>
>
> Cheers,
> Joachim
> --
> Joachim Breitner
>   mail at joachim-breitner.de
>   http://www.joachim-breitner.de/
> <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.joachim-breitner.de%2F&data=04%7C01%7Csimonpj%40microsoft.com%7Cbc1da190b85a4cf21e4b08d8d42ceb8e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637492636704547033%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=5wTbz6wc4abeqyC3TXDU2O8kftB9Rwz1dHnkXM%2FGErE%3D&reserved=0>
>
>
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committee&data=04%7C01%7Csimonpj%40microsoft.com%7Cbc1da190b85a4cf21e4b08d8d42ceb8e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637492636704557030%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=0MJhOYvjonZABu01LyVUN2zqOKC3xqf5qEidT8d%2B2os%3D&reserved=0>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20210305/dab8fce3/attachment-0001.html>

From simonpj at microsoft.com  Fri Mar  5 23:13:11 2021
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Fri, 5 Mar 2021 23:13:11 +0000
Subject: [ghc-steering-committee] Status
In-Reply-To: <CAGK9nupTPOX66xMiB9VjbjpQvkb7_sDrNnbrZb=AJgtDs1XGuA@mail.gmail.com>
References: <7494e545ea1a9ce59053e0d685c81299922ed62b.camel@joachim-breitner.de>
 <CAGK9nupGZE1Ncdwfz3HXbtrxqvzSeV1zJ9b18BVHHio8Xu32jQ@mail.gmail.com>
 <VI1PR83MB0222389754916F1F2E3155ECAD859@VI1PR83MB0222.EURPRD83.prod.outlook.com>
 <CAGK9nupTPOX66xMiB9VjbjpQvkb7_sDrNnbrZb=AJgtDs1XGuA@mail.gmail.com>
Message-ID: <AM0PR83MB02761C192D1210B90023E12EAD969@AM0PR83MB0276.EURPRD83.prod.outlook.com>

This is about #281 visible dependent quantification.

Our role is to accept, reject, or push back to the author for revision.  We should do so in a timely way.

If I were the shepherd I'd be asking the author "Do you want to revise the proposal at all in the light of all the discussion, or do you want the committee to decide yay/nay based on the proposal as it is now?"

He might want to revise/discuss a bit.  But if he says "please decide on it as-is" then I think you should make a recommendation: accept or reject.  (I don't think the discussion has led to any specific revisions that we want to see.)

I sense you would recommend reject.   That's totally fine. Then the rest of us have to make up our minds.  We might end up with a more nuanced position like "we are not ready to accept this now, so if you want a decision now, it'd be no; but feel free to ask the same question again in six months time".

If you don't feel able to be the shepherd, that's fine too: tell Joachim and he'll finger someone else!

But, by hook or by crook, I do think we should do something, not just sit on it.  Tom's nudge is helpful.

Simon

From: Iavor Diatchki <iavor.diatchki at gmail.com>
Sent: 05 March 2021 19:42
To: Simon Peyton Jones <simonpj at microsoft.com>
Cc: Joachim Breitner <mail at joachim-breitner.de>; ghc-steering-committee <ghc-steering-committee at haskell.org>
Subject: Re: [ghc-steering-committee] Status

I am being nudged to do something with this proposal,  but I am not sure what...   Is the rest of the committee OK with moving it back "revisions required", and if so what revisions would we like?

I would be quite happy if someone else wanted to shephard this.  As I mentioned before, I don't have much interest in DH, so I have not followed the really long discussion related to that, and if and how it might relate to #281.

My recommendation for the moment would be:
   * This seems like a useful feature independent of DH, so it would be nice to come up with a concise notation to use the feature on its own, without worrying about DH.

Please let me know what you think, as I am not sure what is the committee's stance on the proposal.

-Iavor





On Thu, Feb 18, 2021 at 1:54 PM Simon Peyton Jones <simonpj at microsoft.com<mailto:simonpj at microsoft.com>> wrote:
There has been a broad further discussion.
What we advertise is that, rather that leave a proposal "under committee review", we will push it back to the author with an invitation to resubmit when the discussion has died down and they feel ready to submit a proposal, revised in the light of the discussion.  That's different to reject... it means that there is an ongoing debate so it's not a good time for the committee to make a decision.

Simon

From: ghc-steering-committee <ghc-steering-committee-bounces at haskell.org<mailto:ghc-steering-committee-bounces at haskell.org>> On Behalf Of Iavor Diatchki
Sent: 18 February 2021 16:47
To: Joachim Breitner <mail at joachim-breitner.de<mailto:mail at joachim-breitner.de>>
Cc: ghc-steering-committee <ghc-steering-committee at haskell.org<mailto:ghc-steering-committee at haskell.org>>
Subject: Re: [ghc-steering-committee] Status

On #381 I think the idea of visible quantification makes sense every now and then, but I don't like the concrete details of the proposal: the magic lifting of terms to types seems quite complicated, and using `type` as an explicit herald doesn't look nice.  So I don't think it's the right design, and therefore I suggest we reject the proposal.

I am sure that others would disagree as apparently this is an essential part of dependent Haskell.   I have not followed the large discussion that Richard created, as I am not particularly interested in the design being proposed, so perhaps someone else should champion this.

Aslo, I am not sure if I am actually on the committee, as I thought my term had expired?  That might be more reason for someone else to pick it up.

-Iavor



On Thu, Feb 18, 2021 at 2:32 AM Joachim Breitner <mail at joachim-breitner.de<mailto:mail at joachim-breitner.de>> wrote:
Dear Committee,

another status update, because why not.

A small reminder: These mails have two sections, one that's a delta
since last status, but below is a summary of all proposals we have to
act on. Please at least scroll through that on each status mail to see
if you are listed, maybe you forgot something (or I made a mistake).

So here's the delta since last month.

 * GHC2021 defined! Yay!

 * Bylaws merged! Yay

 * Simon², Iavor, Richard and me had thus their terms expired.

   The Simons, as key members, wanted to continue and were
   voted back in.

   The others are now "expiring", until the next nomination round
   concludes. Alejandro is going to run that process.

 * we were asked to review these proposals:
   #390: Fine-grained pragmas, Shepherd: Vitaly

 * we have a recommendation from the shepherd about:
   #368: Warn on prefix/suffix operators (accept)

 * we have sent the following proposals back to revision
   - none -

 * we decided about the following proposals
   #313: Delimited continuation primops (accept)
   #387: The Char kind (accept)
   #368: Warn on prefix/suffix operators (accept)

We currently have to act on the following 5 proposals, down by 2.

## Waiting for committee decision

#381: Visible 'forall' in types of terms, Shepherd: Iavor
      Recommendation was to reject, but discussion went into the more
      abstract "whither dependent Haskell". But what does this mean
      for this proposal?
      Iavor, can you pick this up again?

#369: Add sumToTag# primop, Shepherd: Eric
      Essentially accepted, waiting for feedback from the author on
      final tweaks. Eric, care to nudge the author, or just do it?

#302: \of, Shepherd: Cale
      No new discussion yet. It seems there was some confusion, which
      was cleared up by Tom, and Cale said he'll pick it up now again.


## Waiting for Shepherd action

#367: Clarify primops using unboxed sums, Shepherd: Simon Marlow
      Simon said he'd reject it on the Github PR. Still waiting
      for the discussion to start on the mailing list.

#390: Fine-grained pragmas, Shepherd: Vitaly
      Still kinda new, but a recommendation would be good soon.


Cheers,
Joachim
--
Joachim Breitner
  mail at joachim-breitner.de<mailto:mail at joachim-breitner.de>
  http://www.joachim-breitner.de/<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.joachim-breitner.de%2F&data=04%7C01%7Csimonpj%40microsoft.com%7C0f8040e69348485e5e2808d8e00ed1af%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637505701561371493%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=hAny2jNi%2BPKhgMYqiwt4HyNDkvOSFSHKYfYKmrJ3qOk%3D&reserved=0>


_______________________________________________
ghc-steering-committee mailing list
ghc-steering-committee at haskell.org<mailto:ghc-steering-committee at haskell.org>
https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committee&data=04%7C01%7Csimonpj%40microsoft.com%7C0f8040e69348485e5e2808d8e00ed1af%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637505701561381491%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=U6m9laT7pV9QEuzCyFXY2oZT4RFt2yFhDWuJE7YgIMM%3D&reserved=0>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20210305/50fad407/attachment-0001.html>

From iavor.diatchki at gmail.com  Sat Mar  6 01:02:56 2021
From: iavor.diatchki at gmail.com (Iavor Diatchki)
Date: Fri, 5 Mar 2021 17:02:56 -0800
Subject: [ghc-steering-committee] Status
In-Reply-To: <AM0PR83MB02761C192D1210B90023E12EAD969@AM0PR83MB0276.EURPRD83.prod.outlook.com>
References: <7494e545ea1a9ce59053e0d685c81299922ed62b.camel@joachim-breitner.de>
 <CAGK9nupGZE1Ncdwfz3HXbtrxqvzSeV1zJ9b18BVHHio8Xu32jQ@mail.gmail.com>
 <VI1PR83MB0222389754916F1F2E3155ECAD859@VI1PR83MB0222.EURPRD83.prod.outlook.com>
 <CAGK9nupTPOX66xMiB9VjbjpQvkb7_sDrNnbrZb=AJgtDs1XGuA@mail.gmail.com>
 <AM0PR83MB02761C192D1210B90023E12EAD969@AM0PR83MB0276.EURPRD83.prod.outlook.com>
Message-ID: <CAGK9nuoMm7=jq0K=mtgrjdftGXzbmPgNrupuiBz7cPA=uYcy_Q@mail.gmail.com>

OK, I posted a note on the git-hub, asking @int-index what he wants to do.
In case anyone needs a refresher, this is the discussion we had when I
submitted this to the committee back in November:

https://mail.haskell.org/pipermail/ghc-steering-committee/2020-November/001859.html

another somewhat relevant discussion that followed was this:
https://mail.haskell.org/pipermail/ghc-steering-committee/2020-November/001865.html

and here is a link to the proposal and the git-hub discussion:
https://github.com/ghc-proposals/ghc-proposals/pull/281

-Iavor



On Fri, Mar 5, 2021 at 3:13 PM Simon Peyton Jones <simonpj at microsoft.com>
wrote:

> This is about #281 visible dependent quantification.
>
>
>
> Our role is to accept, reject, or push back to the author for revision.
> We should do so in a timely way.
>
>
>
> If I were the shepherd I’d be asking the author “Do you want to revise the
> proposal at all in the light of all the discussion, or do you want the
> committee to decide yay/nay based on the proposal as it is now?”
>
>
>
> He might want to revise/discuss a bit.  But if he says “please decide on
> it as-is” then I think you should make a recommendation: accept or reject.
> (I don’t think the discussion has led to any specific revisions that we
> want to see.)
>
>
>
> I sense you would recommend reject.   That’s totally fine. Then the rest
> of us have to make up our minds.  We might end up with a more nuanced
> position like “we are not ready to accept this now, so if you want a
> decision now, it’d be no; but feel free to ask the same question again in
> six months time”.
>
>
>
> If you don’t feel able to be the shepherd, that’s fine too: tell Joachim
> and he’ll finger someone else!
>
>
>
> But, by hook or by crook, I do think we should do something, not just sit
> on it.  Tom’s nudge is helpful.
>
>
>
> Simon
>
>
>
> *From:* Iavor Diatchki <iavor.diatchki at gmail.com>
> *Sent:* 05 March 2021 19:42
> *To:* Simon Peyton Jones <simonpj at microsoft.com>
> *Cc:* Joachim Breitner <mail at joachim-breitner.de>; ghc-steering-committee
> <ghc-steering-committee at haskell.org>
> *Subject:* Re: [ghc-steering-committee] Status
>
>
>
> I am being nudged to do something with this proposal,  but I am not sure
> what...   Is the rest of the committee OK with moving it back "revisions
> required", and if so what revisions would we like?
>
>
>
> I would be quite happy if someone else wanted to shephard this.  As I
> mentioned before, I don't have much interest in DH, so I have not followed
> the really long discussion related to that, and if and how it might relate
> to #281.
>
>
>
> My recommendation for the moment would be:
>
>    * This seems like a useful feature independent of DH, so it would be
> nice to come up with a concise notation to use the feature on its own,
> without worrying about DH.
>
>
>
> Please let me know what you think, as I am not sure what is the
> committee's stance on the proposal.
>
>
>
> -Iavor
>
>
>
>
>
>
>
>
>
>
>
> On Thu, Feb 18, 2021 at 1:54 PM Simon Peyton Jones <simonpj at microsoft.com>
> wrote:
>
> There has been a broad further discussion.
>
> What we advertise is that, rather that leave a proposal “under committee
> review”, we will push it back to the author with an invitation to resubmit
> when the discussion has died down and they feel ready to submit a proposal,
> revised in the light of the discussion.  That’s different to reject… it
> means that there is an ongoing debate so it’s not a good time for the
> committee to make a decision.
>
>
> Simon
>
>
>
> *From:* ghc-steering-committee <ghc-steering-committee-bounces at haskell.org>
> *On Behalf Of *Iavor Diatchki
> *Sent:* 18 February 2021 16:47
> *To:* Joachim Breitner <mail at joachim-breitner.de>
> *Cc:* ghc-steering-committee <ghc-steering-committee at haskell.org>
> *Subject:* Re: [ghc-steering-committee] Status
>
>
>
> On #381 I think the idea of visible quantification makes sense every now
> and then, but I don't like the concrete details of the proposal: the magic
> lifting of terms to types seems quite complicated, and using `type` as an
> explicit herald doesn't look nice.  So I don't think it's the right design,
> and therefore I suggest we reject the proposal.
>
>
>
> I am sure that others would disagree as apparently this is an essential
> part of dependent Haskell.   I have not followed the large discussion that
> Richard created, as I am not particularly interested in the design being
> proposed, so perhaps someone else should champion this.
>
>
>
> Aslo, I am not sure if I am actually on the committee, as I thought my
> term had expired?  That might be more reason for someone else to pick it up.
>
>
>
> -Iavor
>
>
>
>
>
>
>
> On Thu, Feb 18, 2021 at 2:32 AM Joachim Breitner <mail at joachim-breitner.de>
> wrote:
>
> Dear Committee,
>
> another status update, because why not.
>
> A small reminder: These mails have two sections, one that’s a delta
> since last status, but below is a summary of all proposals we have to
> act on. Please at least scroll through that on each status mail to see
> if you are listed, maybe you forgot something (or I made a mistake).
>
> So here’s the delta since last month.
>
>  * GHC2021 defined! Yay!
>
>  * Bylaws merged! Yay
>
>  * Simon², Iavor, Richard and me had thus their terms expired.
>
>    The Simons, as key members, wanted to continue and were
>    voted back in.
>
>    The others are now “expiring”, until the next nomination round
>    concludes. Alejandro is going to run that process.
>
>  * we were asked to review these proposals:
>    #390: Fine-grained pragmas, Shepherd: Vitaly
>
>  * we have a recommendation from the shepherd about:
>    #368: Warn on prefix/suffix operators (accept)
>
>  * we have sent the following proposals back to revision
>    - none -
>
>  * we decided about the following proposals
>    #313: Delimited continuation primops (accept)
>    #387: The Char kind (accept)
>    #368: Warn on prefix/suffix operators (accept)
>
> We currently have to act on the following 5 proposals, down by 2.
>
> ## Waiting for committee decision
>
> #381: Visible 'forall' in types of terms, Shepherd: Iavor
>       Recommendation was to reject, but discussion went into the more
>       abstract “whither dependent Haskell”. But what does this mean
>       for this proposal?
>       Iavor, can you pick this up again?
>
> #369: Add sumToTag# primop, Shepherd: Eric
>       Essentially accepted, waiting for feedback from the author on
>       final tweaks. Eric, care to nudge the author, or just do it?
>
> #302: \of, Shepherd: Cale
>       No new discussion yet. It seems there was some confusion, which
>       was cleared up by Tom, and Cale said he’ll pick it up now again.
>
>
> ## Waiting for Shepherd action
>
> #367: Clarify primops using unboxed sums, Shepherd: Simon Marlow
>       Simon said he’d reject it on the Github PR. Still waiting
>       for the discussion to start on the mailing list.
>
> #390: Fine-grained pragmas, Shepherd: Vitaly
>       Still kinda new, but a recommendation would be good soon.
>
>
> Cheers,
> Joachim
> --
> Joachim Breitner
>   mail at joachim-breitner.de
>   http://www.joachim-breitner.de/
> <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.joachim-breitner.de%2F&data=04%7C01%7Csimonpj%40microsoft.com%7C0f8040e69348485e5e2808d8e00ed1af%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637505701561371493%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=hAny2jNi%2BPKhgMYqiwt4HyNDkvOSFSHKYfYKmrJ3qOk%3D&reserved=0>
>
>
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committee&data=04%7C01%7Csimonpj%40microsoft.com%7C0f8040e69348485e5e2808d8e00ed1af%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637505701561381491%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=U6m9laT7pV9QEuzCyFXY2oZT4RFt2yFhDWuJE7YgIMM%3D&reserved=0>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20210305/733134ba/attachment.html>

From iavor.diatchki at gmail.com  Sat Mar  6 16:50:40 2021
From: iavor.diatchki at gmail.com (Iavor Diatchki)
Date: Sat, 6 Mar 2021 08:50:40 -0800
Subject: [ghc-steering-committee] Status
In-Reply-To: <CAGK9nuoMm7=jq0K=mtgrjdftGXzbmPgNrupuiBz7cPA=uYcy_Q@mail.gmail.com>
References: <7494e545ea1a9ce59053e0d685c81299922ed62b.camel@joachim-breitner.de>
 <CAGK9nupGZE1Ncdwfz3HXbtrxqvzSeV1zJ9b18BVHHio8Xu32jQ@mail.gmail.com>
 <VI1PR83MB0222389754916F1F2E3155ECAD859@VI1PR83MB0222.EURPRD83.prod.outlook.com>
 <CAGK9nupTPOX66xMiB9VjbjpQvkb7_sDrNnbrZb=AJgtDs1XGuA@mail.gmail.com>
 <AM0PR83MB02761C192D1210B90023E12EAD969@AM0PR83MB0276.EURPRD83.prod.outlook.com>
 <CAGK9nuoMm7=jq0K=mtgrjdftGXzbmPgNrupuiBz7cPA=uYcy_Q@mail.gmail.com>
Message-ID: <CAGK9nuoo33s3b49rpu9SEcNtD=f=mJX=K=YSzRR9FqH7AeEzQA@mail.gmail.com>

Hello,

This is the author's response to my query:

So, the situation seems to be as follows:
>
>    - if we want dependent types (as described on that Wiki page), I would
>    like to resubmit
>
>
>    - if we do not want them, I will retract the proposal and close it
>
> I need to know the committee’s stance on dependent types to proceed here.


I don't think this proposal is the right place to discuss dependent types,
so I propose that we reject the proposal.  To ensure progress, I'll do so
within a week, so please discuss before then, if you think otherwise.

-Iavor



On Fri, Mar 5, 2021 at 5:02 PM Iavor Diatchki <iavor.diatchki at gmail.com>
wrote:

> OK, I posted a note on the git-hub, asking @int-index what he wants to do.
> In case anyone needs a refresher, this is the discussion we had when I
> submitted this to the committee back in November:
>
>
> https://mail.haskell.org/pipermail/ghc-steering-committee/2020-November/001859.html
>
> another somewhat relevant discussion that followed was this:
>
> https://mail.haskell.org/pipermail/ghc-steering-committee/2020-November/001865.html
>
> and here is a link to the proposal and the git-hub discussion:
> https://github.com/ghc-proposals/ghc-proposals/pull/281
>
> -Iavor
>
>
>
> On Fri, Mar 5, 2021 at 3:13 PM Simon Peyton Jones <simonpj at microsoft.com>
> wrote:
>
>> This is about #281 visible dependent quantification.
>>
>>
>>
>> Our role is to accept, reject, or push back to the author for revision.
>> We should do so in a timely way.
>>
>>
>>
>> If I were the shepherd I’d be asking the author “Do you want to revise
>> the proposal at all in the light of all the discussion, or do you want the
>> committee to decide yay/nay based on the proposal as it is now?”
>>
>>
>>
>> He might want to revise/discuss a bit.  But if he says “please decide on
>> it as-is” then I think you should make a recommendation: accept or reject.
>> (I don’t think the discussion has led to any specific revisions that we
>> want to see.)
>>
>>
>>
>> I sense you would recommend reject.   That’s totally fine. Then the rest
>> of us have to make up our minds.  We might end up with a more nuanced
>> position like “we are not ready to accept this now, so if you want a
>> decision now, it’d be no; but feel free to ask the same question again in
>> six months time”.
>>
>>
>>
>> If you don’t feel able to be the shepherd, that’s fine too: tell Joachim
>> and he’ll finger someone else!
>>
>>
>>
>> But, by hook or by crook, I do think we should do something, not just sit
>> on it.  Tom’s nudge is helpful.
>>
>>
>>
>> Simon
>>
>>
>>
>> *From:* Iavor Diatchki <iavor.diatchki at gmail.com>
>> *Sent:* 05 March 2021 19:42
>> *To:* Simon Peyton Jones <simonpj at microsoft.com>
>> *Cc:* Joachim Breitner <mail at joachim-breitner.de>;
>> ghc-steering-committee <ghc-steering-committee at haskell.org>
>> *Subject:* Re: [ghc-steering-committee] Status
>>
>>
>>
>> I am being nudged to do something with this proposal,  but I am not sure
>> what...   Is the rest of the committee OK with moving it back "revisions
>> required", and if so what revisions would we like?
>>
>>
>>
>> I would be quite happy if someone else wanted to shephard this.  As I
>> mentioned before, I don't have much interest in DH, so I have not followed
>> the really long discussion related to that, and if and how it might relate
>> to #281.
>>
>>
>>
>> My recommendation for the moment would be:
>>
>>    * This seems like a useful feature independent of DH, so it would be
>> nice to come up with a concise notation to use the feature on its own,
>> without worrying about DH.
>>
>>
>>
>> Please let me know what you think, as I am not sure what is the
>> committee's stance on the proposal.
>>
>>
>>
>> -Iavor
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> On Thu, Feb 18, 2021 at 1:54 PM Simon Peyton Jones <simonpj at microsoft.com>
>> wrote:
>>
>> There has been a broad further discussion.
>>
>> What we advertise is that, rather that leave a proposal “under committee
>> review”, we will push it back to the author with an invitation to resubmit
>> when the discussion has died down and they feel ready to submit a proposal,
>> revised in the light of the discussion.  That’s different to reject… it
>> means that there is an ongoing debate so it’s not a good time for the
>> committee to make a decision.
>>
>>
>> Simon
>>
>>
>>
>> *From:* ghc-steering-committee <
>> ghc-steering-committee-bounces at haskell.org> *On Behalf Of *Iavor Diatchki
>> *Sent:* 18 February 2021 16:47
>> *To:* Joachim Breitner <mail at joachim-breitner.de>
>> *Cc:* ghc-steering-committee <ghc-steering-committee at haskell.org>
>> *Subject:* Re: [ghc-steering-committee] Status
>>
>>
>>
>> On #381 I think the idea of visible quantification makes sense every now
>> and then, but I don't like the concrete details of the proposal: the magic
>> lifting of terms to types seems quite complicated, and using `type` as an
>> explicit herald doesn't look nice.  So I don't think it's the right design,
>> and therefore I suggest we reject the proposal.
>>
>>
>>
>> I am sure that others would disagree as apparently this is an essential
>> part of dependent Haskell.   I have not followed the large discussion that
>> Richard created, as I am not particularly interested in the design being
>> proposed, so perhaps someone else should champion this.
>>
>>
>>
>> Aslo, I am not sure if I am actually on the committee, as I thought my
>> term had expired?  That might be more reason for someone else to pick it up.
>>
>>
>>
>> -Iavor
>>
>>
>>
>>
>>
>>
>>
>> On Thu, Feb 18, 2021 at 2:32 AM Joachim Breitner <
>> mail at joachim-breitner.de> wrote:
>>
>> Dear Committee,
>>
>> another status update, because why not.
>>
>> A small reminder: These mails have two sections, one that’s a delta
>> since last status, but below is a summary of all proposals we have to
>> act on. Please at least scroll through that on each status mail to see
>> if you are listed, maybe you forgot something (or I made a mistake).
>>
>> So here’s the delta since last month.
>>
>>  * GHC2021 defined! Yay!
>>
>>  * Bylaws merged! Yay
>>
>>  * Simon², Iavor, Richard and me had thus their terms expired.
>>
>>    The Simons, as key members, wanted to continue and were
>>    voted back in.
>>
>>    The others are now “expiring”, until the next nomination round
>>    concludes. Alejandro is going to run that process.
>>
>>  * we were asked to review these proposals:
>>    #390: Fine-grained pragmas, Shepherd: Vitaly
>>
>>  * we have a recommendation from the shepherd about:
>>    #368: Warn on prefix/suffix operators (accept)
>>
>>  * we have sent the following proposals back to revision
>>    - none -
>>
>>  * we decided about the following proposals
>>    #313: Delimited continuation primops (accept)
>>    #387: The Char kind (accept)
>>    #368: Warn on prefix/suffix operators (accept)
>>
>> We currently have to act on the following 5 proposals, down by 2.
>>
>> ## Waiting for committee decision
>>
>> #381: Visible 'forall' in types of terms, Shepherd: Iavor
>>       Recommendation was to reject, but discussion went into the more
>>       abstract “whither dependent Haskell”. But what does this mean
>>       for this proposal?
>>       Iavor, can you pick this up again?
>>
>> #369: Add sumToTag# primop, Shepherd: Eric
>>       Essentially accepted, waiting for feedback from the author on
>>       final tweaks. Eric, care to nudge the author, or just do it?
>>
>> #302: \of, Shepherd: Cale
>>       No new discussion yet. It seems there was some confusion, which
>>       was cleared up by Tom, and Cale said he’ll pick it up now again.
>>
>>
>> ## Waiting for Shepherd action
>>
>> #367: Clarify primops using unboxed sums, Shepherd: Simon Marlow
>>       Simon said he’d reject it on the Github PR. Still waiting
>>       for the discussion to start on the mailing list.
>>
>> #390: Fine-grained pragmas, Shepherd: Vitaly
>>       Still kinda new, but a recommendation would be good soon.
>>
>>
>> Cheers,
>> Joachim
>> --
>> Joachim Breitner
>>   mail at joachim-breitner.de
>>   http://www.joachim-breitner.de/
>> <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.joachim-breitner.de%2F&data=04%7C01%7Csimonpj%40microsoft.com%7C0f8040e69348485e5e2808d8e00ed1af%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637505701561371493%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=hAny2jNi%2BPKhgMYqiwt4HyNDkvOSFSHKYfYKmrJ3qOk%3D&reserved=0>
>>
>>
>> _______________________________________________
>> ghc-steering-committee mailing list
>> ghc-steering-committee at haskell.org
>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committee&data=04%7C01%7Csimonpj%40microsoft.com%7C0f8040e69348485e5e2808d8e00ed1af%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637505701561381491%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=U6m9laT7pV9QEuzCyFXY2oZT4RFt2yFhDWuJE7YgIMM%3D&reserved=0>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20210306/955a40b5/attachment-0001.html>

From eric at seidel.io  Sat Mar  6 18:30:15 2021
From: eric at seidel.io (Eric Seidel)
Date: Sat, 06 Mar 2021 13:30:15 -0500
Subject: [ghc-steering-committee]
 =?utf-8?q?Modification_to_record_dot=09s?=
 =?utf-8?q?yntax=09propsal?=
In-Reply-To: <010f017803762b7a-8cf0e76a-8591-42bf-a07b-a4d229bd4762-000000@us-east-2.amazonses.com>
References: <CAGK9nuoy3cbiESa2goLzzOoYxDMXNKm14bGSxmKDRerbJcA7Ng@mail.gmail.com>
 <6A02AD21-9E34-4879-A40F-5DB86D9A129F@seidel.io>
 <CAH6fHQn0K23Rhi6mi=A2DePxPzZxLAE6TUEMnxvwi2_17G==jg@mail.gmail.com>
 <CAGK9nuqWTYSFabPNk8s7Kzv7Fw4f=5k8dXTpGezhqoPixc86aQ@mail.gmail.com>
 <AM0PR83MB02760B6E11F569F5DAA13041AD969@AM0PR83MB0276.EURPRD83.prod.outlook.com>
 <010f017803762b7a-8cf0e76a-8591-42bf-a07b-a4d229bd4762-000000@us-east-2.amazonses.com>
Message-ID: <53f5e19c-e222-42c6-b78e-632a5e0ac72b@www.fastmail.com>

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-record-dot-syntax.rst#4-effect-and-interactions

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 <ghc-steering-committee at haskell.org> 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 <ghc-steering-committee-bounces at haskell.org> *On Behalf Of *Iavor Diatchki
> > *Sent:* 05 March 2021 16:03
> > *To:* Spiwack, Arnaud <arnaud.spiwack at tweag.io>; ghc-steering-committee <ghc-steering-committee at haskell.org>
> > *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 <arnaud.spiwack at 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 <eric at 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 <iavor.diatchki at 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 <eric at 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 <ghc-steering-committee-
> >>>>> > |  bounces at haskell.org> On Behalf Of Eric Seidel
> >>>>> > |  Sent: 04 March 2021 14:38
> >>>>> > |  To: ghc-steering-committee at haskell.org
> >>>>> > |  Subject: Re: [ghc-steering-committee] Modification to record dot
> >>>>> > |  syntax propsal
> >>>>> > |  
> >>>>> > |  I agree with Richard and Joachim that it should be documented in the
> >>>>> > |  user guide. It's much better to document features with the expected
> >>>>> > |  level of support than to let users stumble upon them and make their
> >>>>> > |  own assumptions about stability.
> >>>>> > |  
> >>>>> > |  That being said, I don't see anything in the revised proposal about
> >>>>> > |  the stability of OverloadedRecordUpdate. Are you saying that as part
> >>>>> > |  of this revision, we'll explicitly accept OverloadedRecordDot and send
> >>>>> > |  OverloadedRecordUpdate back for revision?
> >>>>> > |  
> >>>>> > |  On Thu, Mar 4, 2021, at 04:46, Simon Peyton Jones via ghc-steering-
> >>>>> > |  committee wrote:
> >>>>> > |  >
> >>>>> > |  > Friends
> >>>>> > |  >
> >>>>> > |  >
> >>>>> > |  >
> >>>>> > |  > We've agree to accept my suggestion below.
> >>>>> > |  >
> >>>>> > |  >
> >>>>> > |  >
> >>>>> > |  > But there is one point at issue: should OverloadedRecordUpdate be
> >>>>> > |  > documented in the user manual, albeit identified as a not-yet-
> >>>>> > |  accepted
> >>>>> > |  > feature?
> >>>>> > |  >
> >>>>> > |  >
> >>>>> > |  >
> >>>>> > |  >  * Richard positively wants it in the manual
> >>>>> > |  >  * Iavor positively doesn't want it there.
> >>>>> > |  >
> >>>>> > |  >
> >>>>> > |  > I don't mind either way.
> >>>>> > |  >
> >>>>> > |  >
> >>>>> > |  >
> >>>>> > |  > What do others think?  It's not a big deal, but we owe the authors a
> >>>>> > |  > decision.  Answer by the end of the week please, and I'll make a
> >>>>> > |  > shepherd decision based on the opinions I get.
> >>>>> > |  >
> >>>>> > |  >
> >>>>> > |  >
> >>>>> > |  > Simon
> >>>>> > |  >
> >>>>> > |  >
> >>>>> > |  >
> >>>>> > |  >
> >>>>> > |  >
> >>>>> > |  > *From:* Simon Peyton Jones <simonpj at microsoft.com>
> >>>>> > |  > *Sent:* 02 March 2021 12:45
> >>>>> > |  > *To:* ghc-steering-committee <ghc-steering-committee at haskell.org>
> >>>>> > |  > *Cc:* Simon Peyton Jones <simonpj at microsoft.com>
> >>>>> > |  > *Subject:* RE: [ghc-steering-committee] Modification to record dot
> >>>>> > |  > syntax propsal
> >>>>> > |  >
> >>>>> > |  >
> >>>>> > |  >
> >>>>> > |  > Friends
> >>>>> > |  >
> >>>>> > |  >
> >>>>> > |  >
> >>>>> > |  > Having consulted the authors, I propose that we do this:
> >>>>> > |  >
> >>>>> > |  >
> >>>>> > |  >
> >>>>> > |  >  * Proceed with OverloadedRecordDot for 9.2, exactly as in the
> >>>>> > |  > original proposal except for the extension name.
> >>>>> > |  >  * Record update will remain exactly as now, in 9.2; that is,
> >>>>> > |  drawing
> >>>>> > |  > back from the original proposal.
> >>>>> > |  >  * There may be some *code* in 9.2 that allows overloaded record
> >>>>> > |  > update, protected by OverloadedRecordUpdate, but not in the user
> >>>>> > |  > manual, and not treated as an accepted proposal.   I don't think we
> >>>>> > |  > should ask the authors to remove it, and it will allow
> >>>>> > |  experimentation.
> >>>>> > |  >  * Adam is leading on a revised record-update proposal. This will
> >>>>> > |  cover
> >>>>> > |  >    * the tradeoffs between type-changing and non-type-changing
> >>>>> > |  update
> >>>>> > |  >    * what the current record-update syntax stands for, and/or any
> >>>>> > |  new
> >>>>> > |  > syntax
> >>>>> > |  >
> >>>>> > |  >
> >>>>> > |  > Is that acceptable to everyone?
> >>>>> > |  >
> >>>>> > |  >
> >>>>> > |  >
> >>>>> > |  > Simon
> >>>>> > |  >
> >>>>> > |  >
> >>>>> > |  >
> >>>>> > |  > *From:* ghc-steering-committee
> >>>>> > |  > <ghc-steering-committee-bounces at haskell.org> *On Behalf Of *Simon
> >>>>> > |  > Peyton Jones via ghc-steering-committee
> >>>>> > |  > *Sent:* 01 March 2021 17:51
> >>>>> > |  > *To:* Iavor Diatchki <iavor.diatchki at gmail.com>; Spiwack, Arnaud
> >>>>> > |  > <arnaud.spiwack at tweag.io>
> >>>>> > |  > *Cc:* ghc-steering-committee <ghc-steering-committee at haskell.org>
> >>>>> > |  > *Subject:* Re: [ghc-steering-committee] Modification to record dot
> >>>>> > |  > syntax propsal
> >>>>> > |  >
> >>>>> > |  >
> >>>>> > |  >
> >>>>> > |  > I don't buy the argument of "this is already accepted", as I don't
> >>>>> > |  > think many of us had noticed that part of the proposal (I certainly
> >>>>> > |  > didn't), and I think we should be flexible enough to revisit
> >>>>> > |  previous
> >>>>> > |  > decisions when we notice problems with them.
> >>>>> > |  >
> >>>>> > |  > I agree in principle that we can revisit decisions.   But we have to
> >>>>> > |  be
> >>>>> > |  > aware that it is potentially very discouraging for proposal authors
> >>>>> > |  to
> >>>>> > |  >
> >>>>> > |  >  * propose something,
> >>>>> > |  >  * have it *extensively* debated (including this very point),
> >>>>> > |  >  * have it accepted,
> >>>>> > |  >  * implement it,
> >>>>> > |  > and then be told that the committee has changed its mind.  That's
> >>>>> > |  > pretty bad from their point of view.
> >>>>> > |  >
> >>>>> > |  >
> >>>>> > |  >
> >>>>> > |  > Still, Adam is working on a new SetField proposal, so perhaps that's
> >>>>> > |  a
> >>>>> > |  > figleaf.  I'll consult them.
> >>>>> > |  >
> >>>>> > |  >
> >>>>> > |  > Simon
> >>>>> > |  >
> >>>>> > |  >
> >>>>> > |  >
> >>>>> > |  >
> >>>>> > |  >
> >>>>> > |  > *From:* Iavor Diatchki <iavor.diatchki at gmail.com>
> >>>>> > |  > *Sent:* 01 March 2021 17:23
> >>>>> > |  > *To:* Spiwack, Arnaud <arnaud.spiwack at tweag.io>
> >>>>> > |  > *Cc:* Simon Peyton Jones <simonpj at microsoft.com>;
> >>>>> > |  > ghc-steering-committee <ghc-steering-committee at haskell.org>
> >>>>> > |  > *Subject:* Re: [ghc-steering-committee] Modification to record dot
> >>>>> > |  > syntax propsal
> >>>>> > |  >
> >>>>> > |  >
> >>>>> > |  >
> >>>>> > |  > Hello,
> >>>>> > |  >
> >>>>> > |  >
> >>>>> > |  >
> >>>>> > |  > I think there is a strong motivation to *at least* split the
> >>>>> > |  > extensions:  with the current design, enabling the special `.`
> >>>>> > |  notation
> >>>>> > |  > also *disables* type changing record update, which has nothing to do
> >>>>> > |  > with the `.` notation.
> >>>>> > |  >
> >>>>> > |  >
> >>>>> > |  >
> >>>>> > |  > My preference would be to:
> >>>>> > |  >
> >>>>> > |  >   1. Split the original proposal into two parts: one about `.`
> >>>>> > |  > notation, the other about record update (as suggested by this
> >>>>> > |  proposal)
> >>>>> > |  >
> >>>>> > |  >   2. Treat the `.` notation part as accepted
> >>>>> > |  >
> >>>>> > |  >   3. Require changes on the record update part, so that you don't
> >>>>> > |  have
> >>>>> > |  > to choose between it and type changing record updates, which are
> >>>>> > |  quite
> >>>>> > |  > useful, and I don't think we should aim for a Haskell without them.
> >>>>> > |  >
> >>>>> > |  >
> >>>>> > |  >
> >>>>> > |  > I don't buy the argument of "this is already accepted", as I don't
> >>>>> > |  > think many of us had noticed that part of the proposal (I certainly
> >>>>> > |  > didn't), and I think we should be flexible enough to revisit
> >>>>> > |  previous
> >>>>> > |  > decisions when we notice problems with them.
> >>>>> > |  >
> >>>>> > |  >
> >>>>> > |  >
> >>>>> > |  > -Iavor
> >>>>> > |  >
> >>>>> > |  >
> >>>>> > |  >
> >>>>> > |  >
> >>>>> > |  >
> >>>>> > |  >
> >>>>> > |  >
> >>>>> > |  > On Mon, Mar 1, 2021 at 1:40 AM Spiwack, Arnaud
> >>>>> > |  <arnaud.spiwack at tweag.io> wrote:
> >>>>> > |  >
> >>>>> > |  > > Simon, all,
> >>>>> > |  >
> >>>>> > |  > >
> >>>>> > |  >
> >>>>> > |  > > After reading more of the PR thread (in particular the fews posts
> >>>>> > |  after Simon's recommendation), I have to admit: I am thoroughly
> >>>>> > |  confused. I'm not sure that two people in that thread have the same
> >>>>> > |  motivation, end goal, or design in mind.
> >>>>> > |  >
> >>>>> > |  > >
> >>>>> > |  >
> >>>>> > |  > > The motivations provided by the modified *Alternatives* section is
> >>>>> > |  not much more helpful (at the risk of caricaturing a little, it
> >>>>> > |  basically reads: "we made two extensions rather than one because we
> >>>>> > |  can"). Though it makes it clear that the end goal is to fold a bunch
> >>>>> > |  of record-related extensions into one glorious record extension (well,
> >>>>> > |  probably not fold them, but make a meta-extension that implies all the
> >>>>> > |  extensions that we've decided we like).
> >>>>> > |  >
> >>>>> > |  > >
> >>>>> > |  >
> >>>>> > |  > > My starting point is that:
> >>>>> > |  >
> >>>>> > |  > > - Additional extensions have a maintenance cost
> >>>>> > |  >
> >>>>> > |  > > - Additional extensions impose a cognitive burden on their use
> >>>>> > |  >
> >>>>> > |  > > - I expect that a new extension will break my code in the next few
> >>>>> > |  releases.
> >>>>> > |  >
> >>>>> > |  > >
> >>>>> > |  >
> >>>>> > |  > > Based on this, I don't care how this extension or the glorious
> >>>>> > |  record extension are named; but if we want to have two extensions we
> >>>>> > |  should have a serious reason. Right now, the one reason that I see
> >>>>> > |  (and Iavor raised), is that the update part of `RecordDotSyntax` is
> >>>>> > |  not backward compatible. Is it a strong enough reason? I don't know.
> >>>>> > |  The only data point that I can provide is that when we discussed the
> >>>>> > |  original proposal, I brought it up several times, and it didn't seem
> >>>>> > |  very important at the time (the conversation focused on other points
> >>>>> > |  of the proposal).
> >>>>> > |  >
> >>>>> > |  > >
> >>>>> > |  >
> >>>>> > |  > > So, I'm still reluctant. I feel that, at the very least, the
> >>>>> > |  motivations are not well-enough articulated in the proposal (I'll make
> >>>>> > |  a comment to this effect on Github when I'm done composing this
> >>>>> > |  email).
> >>>>> > |  >
> >>>>> > |  > >
> >>>>> > |  >
> >>>>> > |  > > I appreciate that I'm in the minority here. Yet, I'm still
> >>>>> > |  unconvinced.
> >>>>> > |  >
> >>>>> > |  > >
> >>>>> > |  >
> >>>>> > |  > > Best,
> >>>>> > |  >
> >>>>> > |  > > Arnaud
> >>>>> > |  >
> >>>>> > |  > >
> >>>>> > |  >
> >>>>> > |  > > On Sat, Feb 27, 2021 at 12:39 AM Simon Peyton Jones
> >>>>> > |  <simonpj at microsoft.com> wrote:
> >>>>> > |  >
> >>>>> > |  > >> Generally, I'm not in favour in proposals which split extensions
> >>>>> > |  though: we already have so many extensions. Are the reasons for this
> >>>>> > |  split strong enough? I haven't had time to dig into the details.
> >>>>> > |  >
> >>>>> > |  > >> Arnaud, happily, you don't have to dig very deep - just read the
> >>>>> > |  handful of posts following my recommendation.
> >>>>> > |  >
> >>>>> > |  > >>
> >>>>> > |  >
> >>>>> > |  > >> There seem to be two motivations.
> >>>>> > |  >
> >>>>> > |  > >>
> >>>>> > |  >
> >>>>> > |  > >>  1. There really are two orthogonal extensions, one for r.x
> >>>>> > |  notation, and one for overloaded update.  Iavor likes the first but
> >>>>> > |  not the second.  Neil likes both.  Having separate extensions lets us
> >>>>> > |  experiment.
> >>>>> > |  > >>
> >>>>> > |  >
> >>>>> > |  > >>  1. You suggest that changing the definition of RecordDotSyntax
> >>>>> > |  in a subsequent release, e.g. by subsequently making it imply
> >>>>> > |  NoFieldSelectors, would be fine. But it certainly imposes pain - some
> >>>>> > |  programs would stop compiling.  The approach offered by this proposal
> >>>>> > |  avoids that problem.
> >>>>> > |  > >>
> >>>>> > |  >
> >>>>> > |  > >> Yes, there are lots of extensions surrounding records:
> >>>>> > |  NoFieldSelectors, DuplicateRecordFields, NamedFieldPuns,
> >>>>> > |  DisambiguateRecordFields, RecordWildCards.  It may not be pretty to
> >>>>> > |  divide things up so fine, but it's not new.
> >>>>> > |  >
> >>>>> > |  > >>
> >>>>> > |  >
> >>>>> > |  > >>
> >>>>> > |  >
> >>>>> > |  > >> If there are alternative suggestions, let's hear them.
> >>>>> > |  >
> >>>>> > |  > >>
> >>>>> > |  >
> >>>>> > |  > >> Simon
> >>>>> > |  >
> >>>>> > |  > >>
> >>>>> > |  >
> >>>>> > |  > >> *From:* ghc-steering-committee <ghc-steering-committee-
> >>>>> > |  bounces at haskell.org> *On Behalf Of *Spiwack, Arnaud
> >>>>> > |  > >> *Sent:* 26 February 2021 22:33
> >>>>> > |  > >> *To:* Iavor Diatchki <iavor.diatchki at gmail.com>
> >>>>> > |  > >> *Cc:* ghc-steering-committee <ghc-steering-committee at haskell.org>
> >>>>> > |  > >> *Subject:* Re: [ghc-steering-committee] Modification to record
> >>>>> > |  dot syntax propsal
> >>>>> > |  >
> >>>>> > |  > >>
> >>>>> > |  >
> >>>>> > |  > >>
> >>>>> > |  >
> >>>>> > |  > >>> I do think that  reusing the record update syntax for the
> >>>>> > |  overloaded monomorphic update is a mistake---it is not something I had
> >>>>> > |  noticed during our original discussion.
> >>>>> > |  >
> >>>>> > |  > >>
> >>>>> > |  >
> >>>>> > |  > >> This is the one reason I can see for cutting this extension in
> >>>>> > |  smaller pieces. But, then again, -XOverloadedRecordUpdate would be a
> >>>>> > |  fork-like extension.
> >>>>> > |  >
> >>>>> > |  > >>
> >>>>> > |  >
> >>>>> > |  > >> Generally, I'm not in favour in proposals which split extensions
> >>>>> > |  though: we already have so many extensions. Are the reasons for this
> >>>>> > |  split strong enough? I haven't had time to dig into the details.
> >>>>> > |  >
> >>>>> > |  > >>
> >>>>> > |  >
> >>>>> > |  > >> I'm not sure that not having the design of the proposal quite
> >>>>> > |  finalised is a good reason, extensions mutate in their first
> >>>>> > |  iterations, I don't think that it's a problem.
> >>>>> > |  >
> >>>>> > |  > _______________________________________________
> >>>>> > |  > ghc-steering-committee mailing list
> >>>>> > |  > ghc-steering-committee at haskell.org
> >>>>> > |  >
> >>>>> > |  https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail
> >>>>> > |  .haskell.org <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&amp;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&amp;sdata=9DGVl6oJc0%2BIQekuXf
> >>>>> > |  zwqviiaT%2FaHZIlIk3R5aMZssA%3D&amp;reserved=0
> >>>>> > |  >
> >>>>> > |  _______________________________________________
> >>>>> > |  ghc-steering-committee mailing list
> >>>>> > |  ghc-steering-committee at haskell.org
> >>>>> > |  https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail
> >>>>> > |  .haskell.org <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&amp;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&amp;sdata=QZlV0RrRttaiDdrQNiRB
> >>>>> > |  vUhS6il1DydPX5cyl%2BdILbI%3D&amp;reserved=0
> >>>>> >
> >>>>> _______________________________________________
> >>>>> ghc-steering-committee mailing list
> >>>>> ghc-steering-committee at haskell.org
> >>>>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committee&data=04%7C01%7Csimonpj%40microsoft.com%7Ce0e7e14d1ba74d216e9e08d8dff055dc%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637505571335630737%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=6A2TJygA2WZ29GqX4kBSJmZi5kX2O2Tmawv4SvpNZuk%3D&reserved=0>
> 
> >>> _______________________________________________
> >>> ghc-steering-committee mailing list
> >>> ghc-steering-committee at haskell.org
> >>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committee&data=04%7C01%7Csimonpj%40microsoft.com%7Ce0e7e14d1ba74d216e9e08d8dff055dc%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637505571335630737%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=6A2TJygA2WZ29GqX4kBSJmZi5kX2O2Tmawv4SvpNZuk%3D&reserved=0>
> 
> > _______________________________________________
> > ghc-steering-committee mailing list
> > ghc-steering-committee at haskell.org
> > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
> 
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>

From rae at richarde.dev  Sat Mar  6 22:15:26 2021
From: rae at richarde.dev (Richard Eisenberg)
Date: Sat, 6 Mar 2021 22:15:26 +0000
Subject: [ghc-steering-committee] Modification to record
	dot	syntax	propsal
In-Reply-To: <53f5e19c-e222-42c6-b78e-632a5e0ac72b@www.fastmail.com>
References: <CAGK9nuoy3cbiESa2goLzzOoYxDMXNKm14bGSxmKDRerbJcA7Ng@mail.gmail.com>
 <6A02AD21-9E34-4879-A40F-5DB86D9A129F@seidel.io>
 <CAH6fHQn0K23Rhi6mi=A2DePxPzZxLAE6TUEMnxvwi2_17G==jg@mail.gmail.com>
 <CAGK9nuqWTYSFabPNk8s7Kzv7Fw4f=5k8dXTpGezhqoPixc86aQ@mail.gmail.com>
 <AM0PR83MB02760B6E11F569F5DAA13041AD969@AM0PR83MB0276.EURPRD83.prod.outlook.com>
 <010f017803762b7a-8cf0e76a-8591-42bf-a07b-a4d229bd4762-000000@us-east-2.amazonses.com>
 <53f5e19c-e222-42c6-b78e-632a5e0ac72b@www.fastmail.com>
Message-ID: <010f0178099c110b-26d07e34-5e43-4327-80fd-b1fd3569a933-000000@us-east-2.amazonses.com>



> On Mar 6, 2021, at 1:30 PM, Eric Seidel <eric at seidel.io> wrote:
> 
> 
> there's now work on improving OverloadedRecordUpdate to allow type-changing updates, so we'll mark OverloadedRecordUpdate as experimental. 

I'm very happy with this phrasing and action. Thanks, Eric.

Thanks,
Richard

From simonpj at microsoft.com  Mon Mar  8 13:54:59 2021
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Mon, 8 Mar 2021 13:54:59 +0000
Subject: [ghc-steering-committee] Status
In-Reply-To: <CAGK9nuoo33s3b49rpu9SEcNtD=f=mJX=K=YSzRR9FqH7AeEzQA@mail.gmail.com>
References: <7494e545ea1a9ce59053e0d685c81299922ed62b.camel@joachim-breitner.de>
 <CAGK9nupGZE1Ncdwfz3HXbtrxqvzSeV1zJ9b18BVHHio8Xu32jQ@mail.gmail.com>
 <VI1PR83MB0222389754916F1F2E3155ECAD859@VI1PR83MB0222.EURPRD83.prod.outlook.com>
 <CAGK9nupTPOX66xMiB9VjbjpQvkb7_sDrNnbrZb=AJgtDs1XGuA@mail.gmail.com>
 <AM0PR83MB02761C192D1210B90023E12EAD969@AM0PR83MB0276.EURPRD83.prod.outlook.com>
 <CAGK9nuoMm7=jq0K=mtgrjdftGXzbmPgNrupuiBz7cPA=uYcy_Q@mail.gmail.com>
 <CAGK9nuoo33s3b49rpu9SEcNtD=f=mJX=K=YSzRR9FqH7AeEzQA@mail.gmail.com>
Message-ID: <AM0PR83MB0276F9B335ECF11A18131FC8AD939@AM0PR83MB0276.EURPRD83.prod.outlook.com>

I don't think this proposal is the right place to discuss dependent types, so I propose that we reject the proposal.  To ensure progress, I'll do so within a week, so please discuss before then, if you think otherwise.

I would suggest that rather than "reject" (which sounds like "we don't want this, don't resubmit it"), we push it back saying that we agree that it'd be better to settle #378 first.  So we we'll mark it as "needs revision" not because we have anything specific to suggest, but so that it's back in the author's control.  He should feel free to re-submit (perhaps revised in some way, as he sees fit) once #378 is resolved.

Simon

From: Iavor Diatchki <iavor.diatchki at gmail.com>
Sent: 06 March 2021 16:51
To: Simon Peyton Jones <simonpj at microsoft.com>
Cc: Joachim Breitner <mail at joachim-breitner.de>; ghc-steering-committee <ghc-steering-committee at haskell.org>
Subject: Re: [ghc-steering-committee] Status

Hello,

This is the author's response to my query:

So, the situation seems to be as follows:

  *   if we want dependent types (as described on that Wiki page), I would like to resubmit

  *   if we do not want them, I will retract the proposal and close it
I need to know the committee's stance on dependent types to proceed here.

I don't think this proposal is the right place to discuss dependent types, so I propose that we reject the proposal.  To ensure progress, I'll do so within a week, so please discuss before then, if you think otherwise.

-Iavor



On Fri, Mar 5, 2021 at 5:02 PM Iavor Diatchki <iavor.diatchki at gmail.com<mailto:iavor.diatchki at gmail.com>> wrote:
OK, I posted a note on the git-hub, asking @int-index what he wants to do.
In case anyone needs a refresher, this is the discussion we had when I submitted this to the committee back in November:

https://mail.haskell.org/pipermail/ghc-steering-committee/2020-November/001859.html<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haskell.org%2Fpipermail%2Fghc-steering-committee%2F2020-November%2F001859.html&data=04%7C01%7Csimonpj%40microsoft.com%7C0b9f9dd78f934d620c5e08d8e0c0012f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637506462581487239%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=2inDHN90f7OQ9XIcd76l50Lwwp6axEUZVdea%2BoRFZzg%3D&reserved=0>

another somewhat relevant discussion that followed was this:
https://mail.haskell.org/pipermail/ghc-steering-committee/2020-November/001865.html<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haskell.org%2Fpipermail%2Fghc-steering-committee%2F2020-November%2F001865.html&data=04%7C01%7Csimonpj%40microsoft.com%7C0b9f9dd78f934d620c5e08d8e0c0012f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637506462581497234%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=k4jiWTo11nNFH6zHyw7oYMFfyl0kxkQEsXKSueeC2Mk%3D&reserved=0>

and here is a link to the proposal and the git-hub discussion:
https://github.com/ghc-proposals/ghc-proposals/pull/281<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%2Fpull%2F281&data=04%7C01%7Csimonpj%40microsoft.com%7C0b9f9dd78f934d620c5e08d8e0c0012f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637506462581497234%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=X7tkk61XrEd9utRxcQjA3Eh3Wi3cDXuJdMae%2BBcx3gM%3D&reserved=0>

-Iavor



On Fri, Mar 5, 2021 at 3:13 PM Simon Peyton Jones <simonpj at microsoft.com<mailto:simonpj at microsoft.com>> wrote:
This is about #281 visible dependent quantification.

Our role is to accept, reject, or push back to the author for revision.  We should do so in a timely way.

If I were the shepherd I'd be asking the author "Do you want to revise the proposal at all in the light of all the discussion, or do you want the committee to decide yay/nay based on the proposal as it is now?"

He might want to revise/discuss a bit.  But if he says "please decide on it as-is" then I think you should make a recommendation: accept or reject.  (I don't think the discussion has led to any specific revisions that we want to see.)

I sense you would recommend reject.   That's totally fine. Then the rest of us have to make up our minds.  We might end up with a more nuanced position like "we are not ready to accept this now, so if you want a decision now, it'd be no; but feel free to ask the same question again in six months time".

If you don't feel able to be the shepherd, that's fine too: tell Joachim and he'll finger someone else!

But, by hook or by crook, I do think we should do something, not just sit on it.  Tom's nudge is helpful.

Simon

From: Iavor Diatchki <iavor.diatchki at gmail.com<mailto:iavor.diatchki at gmail.com>>
Sent: 05 March 2021 19:42
To: Simon Peyton Jones <simonpj at microsoft.com<mailto:simonpj at microsoft.com>>
Cc: Joachim Breitner <mail at joachim-breitner.de<mailto:mail at joachim-breitner.de>>; ghc-steering-committee <ghc-steering-committee at haskell.org<mailto:ghc-steering-committee at haskell.org>>
Subject: Re: [ghc-steering-committee] Status

I am being nudged to do something with this proposal,  but I am not sure what...   Is the rest of the committee OK with moving it back "revisions required", and if so what revisions would we like?

I would be quite happy if someone else wanted to shephard this.  As I mentioned before, I don't have much interest in DH, so I have not followed the really long discussion related to that, and if and how it might relate to #281.

My recommendation for the moment would be:
   * This seems like a useful feature independent of DH, so it would be nice to come up with a concise notation to use the feature on its own, without worrying about DH.

Please let me know what you think, as I am not sure what is the committee's stance on the proposal.

-Iavor





On Thu, Feb 18, 2021 at 1:54 PM Simon Peyton Jones <simonpj at microsoft.com<mailto:simonpj at microsoft.com>> wrote:
There has been a broad further discussion.
What we advertise is that, rather that leave a proposal "under committee review", we will push it back to the author with an invitation to resubmit when the discussion has died down and they feel ready to submit a proposal, revised in the light of the discussion.  That's different to reject... it means that there is an ongoing debate so it's not a good time for the committee to make a decision.

Simon

From: ghc-steering-committee <ghc-steering-committee-bounces at haskell.org<mailto:ghc-steering-committee-bounces at haskell.org>> On Behalf Of Iavor Diatchki
Sent: 18 February 2021 16:47
To: Joachim Breitner <mail at joachim-breitner.de<mailto:mail at joachim-breitner.de>>
Cc: ghc-steering-committee <ghc-steering-committee at haskell.org<mailto:ghc-steering-committee at haskell.org>>
Subject: Re: [ghc-steering-committee] Status

On #381 I think the idea of visible quantification makes sense every now and then, but I don't like the concrete details of the proposal: the magic lifting of terms to types seems quite complicated, and using `type` as an explicit herald doesn't look nice.  So I don't think it's the right design, and therefore I suggest we reject the proposal.

I am sure that others would disagree as apparently this is an essential part of dependent Haskell.   I have not followed the large discussion that Richard created, as I am not particularly interested in the design being proposed, so perhaps someone else should champion this.

Aslo, I am not sure if I am actually on the committee, as I thought my term had expired?  That might be more reason for someone else to pick it up.

-Iavor



On Thu, Feb 18, 2021 at 2:32 AM Joachim Breitner <mail at joachim-breitner.de<mailto:mail at joachim-breitner.de>> wrote:
Dear Committee,

another status update, because why not.

A small reminder: These mails have two sections, one that's a delta
since last status, but below is a summary of all proposals we have to
act on. Please at least scroll through that on each status mail to see
if you are listed, maybe you forgot something (or I made a mistake).

So here's the delta since last month.

 * GHC2021 defined! Yay!

 * Bylaws merged! Yay

 * Simon², Iavor, Richard and me had thus their terms expired.

   The Simons, as key members, wanted to continue and were
   voted back in.

   The others are now "expiring", until the next nomination round
   concludes. Alejandro is going to run that process.

 * we were asked to review these proposals:
   #390: Fine-grained pragmas, Shepherd: Vitaly

 * we have a recommendation from the shepherd about:
   #368: Warn on prefix/suffix operators (accept)

 * we have sent the following proposals back to revision
   - none -

 * we decided about the following proposals
   #313: Delimited continuation primops (accept)
   #387: The Char kind (accept)
   #368: Warn on prefix/suffix operators (accept)

We currently have to act on the following 5 proposals, down by 2.

## Waiting for committee decision

#381: Visible 'forall' in types of terms, Shepherd: Iavor
      Recommendation was to reject, but discussion went into the more
      abstract "whither dependent Haskell". But what does this mean
      for this proposal?
      Iavor, can you pick this up again?

#369: Add sumToTag# primop, Shepherd: Eric
      Essentially accepted, waiting for feedback from the author on
      final tweaks. Eric, care to nudge the author, or just do it?

#302: \of, Shepherd: Cale
      No new discussion yet. It seems there was some confusion, which
      was cleared up by Tom, and Cale said he'll pick it up now again.


## Waiting for Shepherd action

#367: Clarify primops using unboxed sums, Shepherd: Simon Marlow
      Simon said he'd reject it on the Github PR. Still waiting
      for the discussion to start on the mailing list.

#390: Fine-grained pragmas, Shepherd: Vitaly
      Still kinda new, but a recommendation would be good soon.


Cheers,
Joachim
--
Joachim Breitner
  mail at joachim-breitner.de<mailto:mail at joachim-breitner.de>
  http://www.joachim-breitner.de/<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.joachim-breitner.de%2F&data=04%7C01%7Csimonpj%40microsoft.com%7C0b9f9dd78f934d620c5e08d8e0c0012f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637506462581507230%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=gsdKkpp3AhJz2ins9uuctT%2FGf6rr2bScSHFWyX3jFhM%3D&reserved=0>


_______________________________________________
ghc-steering-committee mailing list
ghc-steering-committee at haskell.org<mailto:ghc-steering-committee at haskell.org>
https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committee&data=04%7C01%7Csimonpj%40microsoft.com%7C0b9f9dd78f934d620c5e08d8e0c0012f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637506462581517226%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=BY04FgtL9RHpjI6frr%2BOYfxwPkW5yjN2DeRyv2JaKN4%3D&reserved=0>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20210308/c3024071/attachment-0001.html>

From marlowsd at gmail.com  Mon Mar  8 15:51:45 2021
From: marlowsd at gmail.com (Simon Marlow)
Date: Mon, 8 Mar 2021 15:51:45 +0000
Subject: [ghc-steering-committee] Recommendation: reject #367 (was: Re:
 Please review #367: Clarify primops using unboxed sums,
 Shepherd: Simon Marlow)
In-Reply-To: <50e635bf8c9a58568aa810fc284da4cdf39ce702.camel@joachim-breitner.de>
References: <50e635bf8c9a58568aa810fc284da4cdf39ce702.camel@joachim-breitner.de>
Message-ID: <CANsrgPK4eWHyJDfZmuTdgj5weYvbKroNjxZr+HUW5CfP7hKYHA@mail.gmail.com>

Committee,

Proposal #367 suggests using unboxed sums for the results of 7 (seven)
primops that use sum types but currently have to encode those explicitly
using `Int#`.

https://github.com/treeowl/ghc-proposals/blob/unboxed-sum-primops/proposals/0000-unboxed-sum-primops.md

The proposal is arguably the right thing, however I'm suggesting we reject
it for the following reasons:

   1. The implementations of the primops would bake in the translation of
   unboxed sums. Right now our unboxed sum translation is defined in one place
   - CorePrep - but this proposal would leak it into the implementations of a
   few primops.
   2. Migration would entail adding a backwards-compatibility layer, with
   the associated complexity and risk of performance regressions.
   3. While the current situation is perhaps inelegant, it's not broken and
   it's easy to understand.

Thoughts?

Simon


On Sun, 4 Oct 2020 at 22:14, Joachim Breitner <mail at joachim-breitner.de>
wrote:

> Dear Committee,
>
> this is your secretary speaking:
>
> Clarify primops using unboxed sum
> has been proposed by David Feuer
> https://github.com/ghc-proposals/ghc-proposals/pull/367
>
> https://github.com/treeowl/ghc-proposals/blob/unboxed-sum-primops/proposals/0000-unboxed-sum-primops.md
>
> I’ll propose Simon Marlow as the shepherd.
>
> Please guide us to a conclusion as outlined in
> https://github.com/ghc-proposals/ghc-proposals#committee-process
>
> Thanks,
> Joachim
> --
> Joachim Breitner
>   mail at joachim-breitner.de
>   http://www.joachim-breitner.de/
>
>
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20210308/19a2031f/attachment.html>

From mail at joachim-breitner.de  Mon Mar  8 16:59:25 2021
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Mon, 08 Mar 2021 17:59:25 +0100
Subject: [ghc-steering-committee] Recommendation: reject #367 (was: Re:
 Please review #367: Clarify primops using unboxed sums,
 Shepherd: Simon Marlow)
In-Reply-To: <CANsrgPK4eWHyJDfZmuTdgj5weYvbKroNjxZr+HUW5CfP7hKYHA@mail.gmail.com>
References: <50e635bf8c9a58568aa810fc284da4cdf39ce702.camel@joachim-breitner.de>
 <CANsrgPK4eWHyJDfZmuTdgj5weYvbKroNjxZr+HUW5CfP7hKYHA@mail.gmail.com>
Message-ID: <f9ea90b44714208fa2635ee292871d74a0061079.camel@joachim-breitner.de>

Hi,

your points sounds reasonable, and the author got a heads up on the
Github thread (so unlikely that there was a misunderstanding or
oversight), so I’ll concur with the shepherd.

Cheers,
Joachim


Am Montag, den 08.03.2021, 15:51 +0000 schrieb Simon Marlow:
> Committee,
> 
> Proposal #367 suggests using unboxed sums for the results of 7 (seven) primops that use sum types but currently have to encode those explicitly using `Int#`.
> 
> https://github.com/treeowl/ghc-proposals/blob/unboxed-sum-primops/proposals/0000-unboxed-sum-primops.md
> 
> The proposal is arguably the right thing, however I'm suggesting we reject it for the following reasons:
> The implementations of the primops would bake in the translation of unboxed sums. Right now our unboxed sum translation is defined in one place - CorePrep - but this proposal would leak it into the implementations of a few primops.
> Migration would entail adding a backwards-compatibility layer, with the associated complexity and risk of performance regressions.
> While the current situation is perhaps inelegant, it's not broken and it's easy to understand.
> Thoughts?
> 
> Simon
> 
> 
> On Sun, 4 Oct 2020 at 22:14, Joachim Breitner <mail at joachim-breitner.de> wrote:
> > Dear Committee,
> > 
> > this is your secretary speaking:
> > 
> > Clarify primops using unboxed sum
> > has been proposed by David Feuer
> > https://github.com/ghc-proposals/ghc-proposals/pull/367
> > https://github.com/treeowl/ghc-proposals/blob/unboxed-sum-primops/proposals/0000-unboxed-sum-primops.md
> > 
> > I’ll propose Simon Marlow as the shepherd.
> > 
> > Please guide us to a conclusion as outlined in 
> > https://github.com/ghc-proposals/ghc-proposals#committee-process
> > 
> > Thanks,
> > Joachim
> > _______________________________________________
> > ghc-steering-committee mailing list
> > ghc-steering-committee at haskell.org
> > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
-- 
Joachim Breitner
  mail at joachim-breitner.de
  http://www.joachim-breitner.de/



From rae at richarde.dev  Tue Mar  9 03:25:04 2021
From: rae at richarde.dev (Richard Eisenberg)
Date: Tue, 9 Mar 2021 03:25:04 +0000
Subject: [ghc-steering-committee] Recommendation: reject #367 (was: Re:
 Please review #367: Clarify primops using unboxed sums,
 Shepherd: Simon Marlow)
In-Reply-To: <f9ea90b44714208fa2635ee292871d74a0061079.camel@joachim-breitner.de>
References: <50e635bf8c9a58568aa810fc284da4cdf39ce702.camel@joachim-breitner.de>
 <CANsrgPK4eWHyJDfZmuTdgj5weYvbKroNjxZr+HUW5CfP7hKYHA@mail.gmail.com>
 <f9ea90b44714208fa2635ee292871d74a0061079.camel@joachim-breitner.de>
Message-ID: <010f01781504442d-f0eaea4e-d93b-4dca-9af8-25492e4bcfea-000000@us-east-2.amazonses.com>

I want to accept this. But, in the end, I don't see enough benefit (which seems to be mostly aesthetic) to justify the (somewhat modest, as these things go) costs.

I sadly agree with the shepherd to reject.

Richard

> On Mar 8, 2021, at 11:59 AM, Joachim Breitner <mail at joachim-breitner.de> wrote:
> 
> Hi,
> 
> your points sounds reasonable, and the author got a heads up on the
> Github thread (so unlikely that there was a misunderstanding or
> oversight), so I’ll concur with the shepherd.
> 
> Cheers,
> Joachim
> 
> 
> Am Montag, den 08.03.2021, 15:51 +0000 schrieb Simon Marlow:
>> Committee,
>> 
>> Proposal #367 suggests using unboxed sums for the results of 7 (seven) primops that use sum types but currently have to encode those explicitly using `Int#`.
>> 
>> https://github.com/treeowl/ghc-proposals/blob/unboxed-sum-primops/proposals/0000-unboxed-sum-primops.md
>> 
>> The proposal is arguably the right thing, however I'm suggesting we reject it for the following reasons:
>> The implementations of the primops would bake in the translation of unboxed sums. Right now our unboxed sum translation is defined in one place - CorePrep - but this proposal would leak it into the implementations of a few primops.
>> Migration would entail adding a backwards-compatibility layer, with the associated complexity and risk of performance regressions.
>> While the current situation is perhaps inelegant, it's not broken and it's easy to understand.
>> Thoughts?
>> 
>> Simon
>> 
>> 
>> On Sun, 4 Oct 2020 at 22:14, Joachim Breitner <mail at joachim-breitner.de> wrote:
>>> Dear Committee,
>>> 
>>> this is your secretary speaking:
>>> 
>>> Clarify primops using unboxed sum
>>> has been proposed by David Feuer
>>> https://github.com/ghc-proposals/ghc-proposals/pull/367
>>> https://github.com/treeowl/ghc-proposals/blob/unboxed-sum-primops/proposals/0000-unboxed-sum-primops.md
>>> 
>>> I’ll propose Simon Marlow as the shepherd.
>>> 
>>> Please guide us to a conclusion as outlined in 
>>> https://github.com/ghc-proposals/ghc-proposals#committee-process
>>> 
>>> Thanks,
>>> Joachim
>>> _______________________________________________
>>> ghc-steering-committee mailing list
>>> ghc-steering-committee at haskell.org <mailto:ghc-steering-committee at haskell.org>
>>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee <https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee>
> -- 
> Joachim Breitner
>  mail at joachim-breitner.de <mailto:mail at joachim-breitner.de>
>  http://www.joachim-breitner.de/ <http://www.joachim-breitner.de/>
> 
> 
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org <mailto:ghc-steering-committee at haskell.org>
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee <https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20210309/d84520d5/attachment-0001.html>

From rae at richarde.dev  Tue Mar  9 03:41:03 2021
From: rae at richarde.dev (Richard Eisenberg)
Date: Tue, 9 Mar 2021 03:41:03 +0000
Subject: [ghc-steering-committee] #403: Cleanup lexical structure,
 recommendation: accept
In-Reply-To: <CAGK9nupRPwc1hRx_AmGFujfXBUwX63Msph90nBYv8irdnBOy7A@mail.gmail.com>
References: <CAH6fHQnGv72AF1PrxQhyDSNcgK0gwwaJzHYbhfc+hn44SD1+4w@mail.gmail.com>
 <VI1PR83MB02229E22E39517DA61FC0427AD969@VI1PR83MB0222.EURPRD83.prod.outlook.com>
 <CAHnFXOvDF_MYxjS-u0dvo+x9Fdg_rLcZom_hbXoEKmL-9_GyCg@mail.gmail.com>
 <CAGK9nupRPwc1hRx_AmGFujfXBUwX63Msph90nBYv8irdnBOy7A@mail.gmail.com>
Message-ID: <010f01781512e7a3-5bc80b24-389f-4a0b-9aac-b914fe503af0-000000@us-east-2.amazonses.com>

I'm in support.

Thanks,
Richard

> On Mar 5, 2021, at 1:03 PM, Iavor Diatchki <iavor.diatchki at gmail.com> wrote:
> 
> I think this looks reasonable too (with the qualification that I didn't look at it in much detail).
> 
> On Fri, Mar 5, 2021 at 9:46 AM Alejandro Serrano Mena <trupill at gmail.com <mailto:trupill at gmail.com>> wrote:
> This proposal seems fine to me.
> 
> Alejandro
> 
> El El vie, 5 mar 2021 a las 10:22, Simon Peyton Jones via ghc-steering-committee <ghc-steering-committee at haskell.org <mailto:ghc-steering-committee at haskell.org>> escribió:
> I don’t have a well-informed opinion, but I certainly have no objection.
> 
> 
>  
> 
> Simon
> 
>  
> 
> From: ghc-steering-committee <ghc-steering-committee-bounces at haskell.org <mailto:ghc-steering-committee-bounces at haskell.org>> On Behalf Of Spiwack, Arnaud
> Sent: 04 March 2021 14:54
> To: GHC Steering committee <ghc-steering-committee at haskell.org <mailto:ghc-steering-committee at haskell.org>>
> Subject: [ghc-steering-committee] #403: Cleanup lexical structure, recommendation: accept
> 
>  
> 
> Dear all,
> 
>  
> 
> As the shepherd for proposal #403 Cleanup lexical structure of numbers and identifiers <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%2Fpull%2F403&data=04%7C01%7Csimonpj%40microsoft.com%7Cb28a9399e2fd44379fd308d8df1d66b0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637504665725379654%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=Rfp%2F%2BPsrs%2FQWa9k67NTAOLAI7PXccca%2BVLBZvcNVYME%3D&reserved=0>, let me recommend acceptance.
> 
>  
> 
> This proposal does two things related to unicode characters
> 
> Codify the actual current lexing of unicode symbols, which is actually different from the Haskell 2010 report (in particular, only ascii digits are allowed in number literals)
> Adds the possibility to use unicode letters which are neither upper case nor lower case (such as many asian scripts) as trailing symbols for identifier (as well as in String and Char literals)
> It doesn't make it possible (nor close the door) to use letter-like numbers (such as latin numerals) as identifiers, nor use non-ascii digits in number literals.
> 
>  
> 
> As the title entails, it's essentially a clean up of the documentation, to match reality. It seems quite uncontroversial.
> 
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org <mailto:ghc-steering-committee at haskell.org>
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee <https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee>
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org <mailto:ghc-steering-committee at haskell.org>
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee <https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee>
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20210309/51d827cf/attachment.html>

From rae at richarde.dev  Tue Mar  9 04:35:51 2021
From: rae at richarde.dev (Richard Eisenberg)
Date: Tue, 9 Mar 2021 04:35:51 +0000
Subject: [ghc-steering-committee] Status
In-Reply-To: <AM0PR83MB0276F9B335ECF11A18131FC8AD939@AM0PR83MB0276.EURPRD83.prod.outlook.com>
References: <7494e545ea1a9ce59053e0d685c81299922ed62b.camel@joachim-breitner.de>
 <CAGK9nupGZE1Ncdwfz3HXbtrxqvzSeV1zJ9b18BVHHio8Xu32jQ@mail.gmail.com>
 <VI1PR83MB0222389754916F1F2E3155ECAD859@VI1PR83MB0222.EURPRD83.prod.outlook.com>
 <CAGK9nupTPOX66xMiB9VjbjpQvkb7_sDrNnbrZb=AJgtDs1XGuA@mail.gmail.com>
 <AM0PR83MB02761C192D1210B90023E12EAD969@AM0PR83MB0276.EURPRD83.prod.outlook.com>
 <CAGK9nuoMm7=jq0K=mtgrjdftGXzbmPgNrupuiBz7cPA=uYcy_Q@mail.gmail.com>
 <CAGK9nuoo33s3b49rpu9SEcNtD=f=mJX=K=YSzRR9FqH7AeEzQA@mail.gmail.com>
 <AM0PR83MB0276F9B335ECF11A18131FC8AD939@AM0PR83MB0276.EURPRD83.prod.outlook.com>
Message-ID: <010f0178154511dc-58479ea3-989e-4866-a94f-6f6a9eeec3ad-000000@us-east-2.amazonses.com>

I have now submitted #378 for a committee decision (though I will forgive Joachim if he missed the notification among the 200 comments on that thread). So perhaps we can tackle all of this together.

Richard

> On Mar 8, 2021, at 8:54 AM, Simon Peyton Jones via ghc-steering-committee <ghc-steering-committee at haskell.org> wrote:
> 
> I don't think this proposal is the right place to discuss dependent types, so I propose that we reject the proposal.  To ensure progress, I'll do so within a week, so please discuss before then, if you think otherwise.
>  
> I would suggest that rather than “reject” (which sounds like “we don’t want this, don’t resubmit it”), we push it back saying that we agree that it’d be better to settle #378 first.  So we we’ll mark it as “needs revision” not because we have anything specific to suggest, but so that it’s back in the author’s control.  He should feel free to re-submit (perhaps revised in some way, as he sees fit) once #378 is resolved.
>  
> Simon
>  
> From: Iavor Diatchki <iavor.diatchki at gmail.com> 
> Sent: 06 March 2021 16:51
> To: Simon Peyton Jones <simonpj at microsoft.com>
> Cc: Joachim Breitner <mail at joachim-breitner.de>; ghc-steering-committee <ghc-steering-committee at haskell.org>
> Subject: Re: [ghc-steering-committee] Status
>  
> Hello,
> 
>  
> 
> This is the author's response to my query:
> 
>  
> 
> So, the situation seems to be as follows:
> 
> if we want dependent types (as described on that Wiki page), I would like to resubmit
> if we do not want them, I will retract the proposal and close it
> I need to know the committee’s stance on dependent types to proceed here.
>  
> I don't think this proposal is the right place to discuss dependent types, so I propose that we reject the proposal.  To ensure progress, I'll do so within a week, so please discuss before then, if you think otherwise.
>  
> -Iavor
>  
>  
>  
> On Fri, Mar 5, 2021 at 5:02 PM Iavor Diatchki <iavor.diatchki at gmail.com <mailto:iavor.diatchki at gmail.com>> wrote:
> OK, I posted a note on the git-hub, asking @int-index what he wants to do.
> In case anyone needs a refresher, this is the discussion we had when I submitted this to the committee back in November:
>  
> https://mail.haskell.org/pipermail/ghc-steering-committee/2020-November/001859.html <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haskell.org%2Fpipermail%2Fghc-steering-committee%2F2020-November%2F001859.html&data=04%7C01%7Csimonpj%40microsoft.com%7C0b9f9dd78f934d620c5e08d8e0c0012f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637506462581487239%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=2inDHN90f7OQ9XIcd76l50Lwwp6axEUZVdea%2BoRFZzg%3D&reserved=0>
>  
> another somewhat relevant discussion that followed was this:
> https://mail.haskell.org/pipermail/ghc-steering-committee/2020-November/001865.html <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haskell.org%2Fpipermail%2Fghc-steering-committee%2F2020-November%2F001865.html&data=04%7C01%7Csimonpj%40microsoft.com%7C0b9f9dd78f934d620c5e08d8e0c0012f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637506462581497234%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=k4jiWTo11nNFH6zHyw7oYMFfyl0kxkQEsXKSueeC2Mk%3D&reserved=0>
>  
> and here is a link to the proposal and the git-hub discussion:
> https://github.com/ghc-proposals/ghc-proposals/pull/281 <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%2Fpull%2F281&data=04%7C01%7Csimonpj%40microsoft.com%7C0b9f9dd78f934d620c5e08d8e0c0012f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637506462581497234%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=X7tkk61XrEd9utRxcQjA3Eh3Wi3cDXuJdMae%2BBcx3gM%3D&reserved=0>
>  
> -Iavor
>  
>  
>  
> On Fri, Mar 5, 2021 at 3:13 PM Simon Peyton Jones <simonpj at microsoft.com <mailto:simonpj at microsoft.com>> wrote:
> This is about #281 visible dependent quantification.
>  
> Our role is to accept, reject, or push back to the author for revision.  We should do so in a timely way.
>  
> If I were the shepherd I’d be asking the author “Do you want to revise the proposal at all in the light of all the discussion, or do you want the committee to decide yay/nay based on the proposal as it is now?”   
>  
> He might want to revise/discuss a bit.  But if he says “please decide on it as-is” then I think you should make a recommendation: accept or reject.  (I don’t think the discussion has led to any specific revisions that we want to see.)  
>  
> I sense you would recommend reject.   That’s totally fine. Then the rest of us have to make up our minds.  We might end up with a more nuanced position like “we are not ready to accept this now, so if you want a decision now, it’d be no; but feel free to ask the same question again in six months time”.
>  
> If you don’t feel able to be the shepherd, that’s fine too: tell Joachim and he’ll finger someone else!
>  
> But, by hook or by crook, I do think we should do something, not just sit on it.  Tom’s nudge is helpful.
>  
> Simon
>  
> From: Iavor Diatchki <iavor.diatchki at gmail.com <mailto:iavor.diatchki at gmail.com>> 
> Sent: 05 March 2021 19:42
> To: Simon Peyton Jones <simonpj at microsoft.com <mailto:simonpj at microsoft.com>>
> Cc: Joachim Breitner <mail at joachim-breitner.de <mailto:mail at joachim-breitner.de>>; ghc-steering-committee <ghc-steering-committee at haskell.org <mailto:ghc-steering-committee at haskell.org>>
> Subject: Re: [ghc-steering-committee] Status
>  
> I am being nudged to do something with this proposal,  but I am not sure what...   Is the rest of the committee OK with moving it back "revisions required", and if so what revisions would we like?  
> 
>  
> 
> I would be quite happy if someone else wanted to shephard this.  As I mentioned before, I don't have much interest in DH, so I have not followed the really long discussion related to that, and if and how it might relate to #281. 
> 
>  
> 
> My recommendation for the moment would be:
> 
>    * This seems like a useful feature independent of DH, so it would be nice to come up with a concise notation to use the feature on its own, without worrying about DH.
> 
>  
> 
> Please let me know what you think, as I am not sure what is the committee's stance on the proposal.
> 
>  
> 
> -Iavor
> 
>  
> 
>  
> 
>  
> 
>  
> 
>  
> 
> On Thu, Feb 18, 2021 at 1:54 PM Simon Peyton Jones <simonpj at microsoft.com <mailto:simonpj at microsoft.com>> wrote:
> 
> There has been a broad further discussion.
> What we advertise is that, rather that leave a proposal “under committee review”, we will push it back to the author with an invitation to resubmit when the discussion has died down and they feel ready to submit a proposal, revised in the light of the discussion.  That’s different to reject… it means that there is an ongoing debate so it’s not a good time for the committee to make a decision.
> 
> Simon
>  
> From: ghc-steering-committee <ghc-steering-committee-bounces at haskell.org <mailto:ghc-steering-committee-bounces at haskell.org>> On Behalf Of Iavor Diatchki
> Sent: 18 February 2021 16:47
> To: Joachim Breitner <mail at joachim-breitner.de <mailto:mail at joachim-breitner.de>>
> Cc: ghc-steering-committee <ghc-steering-committee at haskell.org <mailto:ghc-steering-committee at haskell.org>>
> Subject: Re: [ghc-steering-committee] Status
>  
> On #381 I think the idea of visible quantification makes sense every now and then, but I don't like the concrete details of the proposal: the magic lifting of terms to types seems quite complicated, and using `type` as an explicit herald doesn't look nice.  So I don't think it's the right design, and therefore I suggest we reject the proposal.
> 
>  
> 
> I am sure that others would disagree as apparently this is an essential part of dependent Haskell.   I have not followed the large discussion that Richard created, as I am not particularly interested in the design being proposed, so perhaps someone else should champion this.
> 
>  
> 
> Aslo, I am not sure if I am actually on the committee, as I thought my term had expired?  That might be more reason for someone else to pick it up.
> 
>  
> 
> -Iavor
> 
>  
> 
>  
> 
>  
> 
> On Thu, Feb 18, 2021 at 2:32 AM Joachim Breitner <mail at joachim-breitner.de <mailto:mail at joachim-breitner.de>> wrote:
> 
> Dear Committee,
> 
> another status update, because why not.
> 
> A small reminder: These mails have two sections, one that’s a delta
> since last status, but below is a summary of all proposals we have to
> act on. Please at least scroll through that on each status mail to see
> if you are listed, maybe you forgot something (or I made a mistake).
> 
> So here’s the delta since last month.
> 
>  * GHC2021 defined! Yay!
> 
>  * Bylaws merged! Yay
> 
>  * Simon², Iavor, Richard and me had thus their terms expired.
> 
>    The Simons, as key members, wanted to continue and were
>    voted back in.
> 
>    The others are now “expiring”, until the next nomination round
>    concludes. Alejandro is going to run that process.
> 
>  * we were asked to review these proposals:
>    #390: Fine-grained pragmas, Shepherd: Vitaly
> 
>  * we have a recommendation from the shepherd about:
>    #368: Warn on prefix/suffix operators (accept)
> 
>  * we have sent the following proposals back to revision
>    - none -
> 
>  * we decided about the following proposals
>    #313: Delimited continuation primops (accept)
>    #387: The Char kind (accept)
>    #368: Warn on prefix/suffix operators (accept)
> 
> We currently have to act on the following 5 proposals, down by 2.
> 
> ## Waiting for committee decision
> 
> #381: Visible 'forall' in types of terms, Shepherd: Iavor
>       Recommendation was to reject, but discussion went into the more 
>       abstract “whither dependent Haskell”. But what does this mean
>       for this proposal?
>       Iavor, can you pick this up again?
> 
> #369: Add sumToTag# primop, Shepherd: Eric
>       Essentially accepted, waiting for feedback from the author on
>       final tweaks. Eric, care to nudge the author, or just do it?
> 
> #302: \of, Shepherd: Cale
>       No new discussion yet. It seems there was some confusion, which
>       was cleared up by Tom, and Cale said he’ll pick it up now again.
> 
> 
> ## Waiting for Shepherd action
> 
> #367: Clarify primops using unboxed sums, Shepherd: Simon Marlow
>       Simon said he’d reject it on the Github PR. Still waiting
>       for the discussion to start on the mailing list.
> 
> #390: Fine-grained pragmas, Shepherd: Vitaly
>       Still kinda new, but a recommendation would be good soon.
> 
> 
> Cheers,
> Joachim
> -- 
> Joachim Breitner
>   mail at joachim-breitner.de <mailto:mail at joachim-breitner.de>
>   http://www.joachim-breitner.de/ <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.joachim-breitner.de%2F&data=04%7C01%7Csimonpj%40microsoft.com%7C0b9f9dd78f934d620c5e08d8e0c0012f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637506462581507230%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=gsdKkpp3AhJz2ins9uuctT%2FGf6rr2bScSHFWyX3jFhM%3D&reserved=0>
> 
> 
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org <mailto:ghc-steering-committee at haskell.org>
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committee&data=04%7C01%7Csimonpj%40microsoft.com%7C0b9f9dd78f934d620c5e08d8e0c0012f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637506462581517226%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=BY04FgtL9RHpjI6frr%2BOYfxwPkW5yjN2DeRyv2JaKN4%3D&reserved=0>_______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20210309/3f1e96d3/attachment-0001.html>

From iavor.diatchki at gmail.com  Tue Mar  9 05:58:00 2021
From: iavor.diatchki at gmail.com (Iavor Diatchki)
Date: Mon, 8 Mar 2021 21:58:00 -0800
Subject: [ghc-steering-committee] Status
In-Reply-To: <010f0178154511dc-58479ea3-989e-4866-a94f-6f6a9eeec3ad-000000@us-east-2.amazonses.com>
References: <7494e545ea1a9ce59053e0d685c81299922ed62b.camel@joachim-breitner.de>
 <CAGK9nupGZE1Ncdwfz3HXbtrxqvzSeV1zJ9b18BVHHio8Xu32jQ@mail.gmail.com>
 <VI1PR83MB0222389754916F1F2E3155ECAD859@VI1PR83MB0222.EURPRD83.prod.outlook.com>
 <CAGK9nupTPOX66xMiB9VjbjpQvkb7_sDrNnbrZb=AJgtDs1XGuA@mail.gmail.com>
 <AM0PR83MB02761C192D1210B90023E12EAD969@AM0PR83MB0276.EURPRD83.prod.outlook.com>
 <CAGK9nuoMm7=jq0K=mtgrjdftGXzbmPgNrupuiBz7cPA=uYcy_Q@mail.gmail.com>
 <CAGK9nuoo33s3b49rpu9SEcNtD=f=mJX=K=YSzRR9FqH7AeEzQA@mail.gmail.com>
 <AM0PR83MB0276F9B335ECF11A18131FC8AD939@AM0PR83MB0276.EURPRD83.prod.outlook.com>
 <010f0178154511dc-58479ea3-989e-4866-a94f-6f6a9eeec3ad-000000@us-east-2.amazonses.com>
Message-ID: <CAGK9nup52iaxt6fMwRpn2-xXgsWwWeFMcJ2BMuXBgbNUqo35Mg@mail.gmail.com>

I will wait a few more days to see if anyone else expresses an opinion,
otherwise I'll do as Simon suggests.

Could someone clarify what does #281 have to do with dependent types?   The
example that was brought up, and I think is pretty reasonable, is `sizeOf`
from the `Storbale` class:  I might want to write `sizeOf @Bool`.  Is the
plan to require that dependent types are enabled to write stuff like that?

-Iavor



On Mon, Mar 8, 2021 at 8:35 PM Richard Eisenberg <rae at richarde.dev> wrote:

> I have now submitted #378 for a committee decision (though I will forgive
> Joachim if he missed the notification among the 200 comments on that
> thread). So perhaps we can tackle all of this together.
>
> Richard
>
> On Mar 8, 2021, at 8:54 AM, Simon Peyton Jones via ghc-steering-committee <
> ghc-steering-committee at haskell.org> wrote:
>
> I don't think this proposal is the right place to discuss dependent types,
> so I propose that we reject the proposal.  To ensure progress, I'll do so
> within a week, so please discuss before then, if you think otherwise.
>
> I would suggest that rather than “reject” (which sounds like “we don’t
> want this, don’t resubmit it”), we push it back saying that we agree that
> it’d be better to settle #378 first.  So we we’ll mark it as “needs
> revision” not because we have anything specific to suggest, but so that
> it’s back in the author’s control.  He should feel free to re-submit
> (perhaps revised in some way, as he sees fit) once #378 is resolved.
>
> Simon
>
> *From:* Iavor Diatchki <iavor.diatchki at gmail.com>
> *Sent:* 06 March 2021 16:51
> *To:* Simon Peyton Jones <simonpj at microsoft.com>
> *Cc:* Joachim Breitner <mail at joachim-breitner.de>; ghc-steering-committee
> <ghc-steering-committee at haskell.org>
> *Subject:* Re: [ghc-steering-committee] Status
>
>
> Hello,
>
>
>
> This is the author's response to my query:
>
>
>
> So, the situation seems to be as follows:
>
>    - if we want dependent types (as described on that Wiki page), I would
>    like to resubmit
>
>
>    - if we do not want them, I will retract the proposal and close it
>
> I need to know the committee’s stance on dependent types to proceed here.
>
>
> I don't think this proposal is the right place to discuss dependent types,
> so I propose that we reject the proposal.  To ensure progress, I'll do so
> within a week, so please discuss before then, if you think otherwise.
>
> -Iavor
>
>
>
> On Fri, Mar 5, 2021 at 5:02 PM Iavor Diatchki <iavor.diatchki at gmail.com>
> wrote:
>
> OK, I posted a note on the git-hub, asking @int-index what he wants to do.
> In case anyone needs a refresher, this is the discussion we had when I
> submitted this to the committee back in November:
>
>
> https://mail.haskell.org/pipermail/ghc-steering-committee/2020-November/001859.html
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haskell.org%2Fpipermail%2Fghc-steering-committee%2F2020-November%2F001859.html&data=04%7C01%7Csimonpj%40microsoft.com%7C0b9f9dd78f934d620c5e08d8e0c0012f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637506462581487239%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=2inDHN90f7OQ9XIcd76l50Lwwp6axEUZVdea%2BoRFZzg%3D&reserved=0>
>
> another somewhat relevant discussion that followed was this:
>
> https://mail.haskell.org/pipermail/ghc-steering-committee/2020-November/001865.html
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haskell.org%2Fpipermail%2Fghc-steering-committee%2F2020-November%2F001865.html&data=04%7C01%7Csimonpj%40microsoft.com%7C0b9f9dd78f934d620c5e08d8e0c0012f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637506462581497234%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=k4jiWTo11nNFH6zHyw7oYMFfyl0kxkQEsXKSueeC2Mk%3D&reserved=0>
>
> and here is a link to the proposal and the git-hub discussion:
> https://github.com/ghc-proposals/ghc-proposals/pull/281
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%2Fpull%2F281&data=04%7C01%7Csimonpj%40microsoft.com%7C0b9f9dd78f934d620c5e08d8e0c0012f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637506462581497234%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=X7tkk61XrEd9utRxcQjA3Eh3Wi3cDXuJdMae%2BBcx3gM%3D&reserved=0>
>
> -Iavor
>
>
>
> On Fri, Mar 5, 2021 at 3:13 PM Simon Peyton Jones <simonpj at microsoft.com>
> wrote:
>
> This is about #281 visible dependent quantification.
>
> Our role is to accept, reject, or push back to the author for revision.
> We should do so in a timely way.
>
> If I were the shepherd I’d be asking the author “Do you want to revise the
> proposal at all in the light of all the discussion, or do you want the
> committee to decide yay/nay based on the proposal as it is now?”
>
> He might want to revise/discuss a bit.  But if he says “please decide on
> it as-is” then I think you should make a recommendation: accept or reject.
> (I don’t think the discussion has led to any specific revisions that we
> want to see.)
>
> I sense you would recommend reject.   That’s totally fine. Then the rest
> of us have to make up our minds.  We might end up with a more nuanced
> position like “we are not ready to accept this now, so if you want a
> decision now, it’d be no; but feel free to ask the same question again in
> six months time”.
>
> If you don’t feel able to be the shepherd, that’s fine too: tell Joachim
> and he’ll finger someone else!
>
> But, by hook or by crook, I do think we should do something, not just sit
> on it.  Tom’s nudge is helpful.
>
> Simon
>
> *From:* Iavor Diatchki <iavor.diatchki at gmail.com>
> *Sent:* 05 March 2021 19:42
> *To:* Simon Peyton Jones <simonpj at microsoft.com>
> *Cc:* Joachim Breitner <mail at joachim-breitner.de>; ghc-steering-committee
> <ghc-steering-committee at haskell.org>
> *Subject:* Re: [ghc-steering-committee] Status
>
>
> I am being nudged to do something with this proposal,  but I am not sure
> what...   Is the rest of the committee OK with moving it back "revisions
> required", and if so what revisions would we like?
>
>
>
> I would be quite happy if someone else wanted to shephard this.  As I
> mentioned before, I don't have much interest in DH, so I have not followed
> the really long discussion related to that, and if and how it might relate
> to #281.
>
>
>
> My recommendation for the moment would be:
>
>    * This seems like a useful feature independent of DH, so it would be
> nice to come up with a concise notation to use the feature on its own,
> without worrying about DH.
>
>
>
> Please let me know what you think, as I am not sure what is the
> committee's stance on the proposal.
>
>
>
> -Iavor
>
>
>
>
>
>
>
>
>
>
>
> On Thu, Feb 18, 2021 at 1:54 PM Simon Peyton Jones <simonpj at microsoft.com>
> wrote:
>
> There has been a broad further discussion.
> What we advertise is that, rather that leave a proposal “under committee
> review”, we will push it back to the author with an invitation to resubmit
> when the discussion has died down and they feel ready to submit a proposal,
> revised in the light of the discussion.  That’s different to reject… it
> means that there is an ongoing debate so it’s not a good time for the
> committee to make a decision.
>
> Simon
>
> *From:* ghc-steering-committee <ghc-steering-committee-bounces at haskell.org
> > *On Behalf Of *Iavor Diatchki
> *Sent:* 18 February 2021 16:47
> *To:* Joachim Breitner <mail at joachim-breitner.de>
> *Cc:* ghc-steering-committee <ghc-steering-committee at haskell.org>
> *Subject:* Re: [ghc-steering-committee] Status
>
>
> On #381 I think the idea of visible quantification makes sense every now
> and then, but I don't like the concrete details of the proposal: the magic
> lifting of terms to types seems quite complicated, and using `type` as an
> explicit herald doesn't look nice.  So I don't think it's the right design,
> and therefore I suggest we reject the proposal.
>
>
>
> I am sure that others would disagree as apparently this is an essential
> part of dependent Haskell.   I have not followed the large discussion that
> Richard created, as I am not particularly interested in the design being
> proposed, so perhaps someone else should champion this.
>
>
>
> Aslo, I am not sure if I am actually on the committee, as I thought my
> term had expired?  That might be more reason for someone else to pick it up.
>
>
>
> -Iavor
>
>
>
>
>
>
>
> On Thu, Feb 18, 2021 at 2:32 AM Joachim Breitner <mail at joachim-breitner.de>
> wrote:
>
> Dear Committee,
>
> another status update, because why not.
>
> A small reminder: These mails have two sections, one that’s a delta
> since last status, but below is a summary of all proposals we have to
> act on. Please at least scroll through that on each status mail to see
> if you are listed, maybe you forgot something (or I made a mistake).
>
> So here’s the delta since last month.
>
>  * GHC2021 defined! Yay!
>
>  * Bylaws merged! Yay
>
>  * Simon², Iavor, Richard and me had thus their terms expired.
>
>    The Simons, as key members, wanted to continue and were
>    voted back in.
>
>    The others are now “expiring”, until the next nomination round
>    concludes. Alejandro is going to run that process.
>
>  * we were asked to review these proposals:
>    #390: Fine-grained pragmas, Shepherd: Vitaly
>
>  * we have a recommendation from the shepherd about:
>    #368: Warn on prefix/suffix operators (accept)
>
>  * we have sent the following proposals back to revision
>    - none -
>
>  * we decided about the following proposals
>    #313: Delimited continuation primops (accept)
>    #387: The Char kind (accept)
>    #368: Warn on prefix/suffix operators (accept)
>
> We currently have to act on the following 5 proposals, down by 2.
>
> ## Waiting for committee decision
>
> #381: Visible 'forall' in types of terms, Shepherd: Iavor
>       Recommendation was to reject, but discussion went into the more
>       abstract “whither dependent Haskell”. But what does this mean
>       for this proposal?
>       Iavor, can you pick this up again?
>
> #369: Add sumToTag# primop, Shepherd: Eric
>       Essentially accepted, waiting for feedback from the author on
>       final tweaks. Eric, care to nudge the author, or just do it?
>
> #302: \of, Shepherd: Cale
>       No new discussion yet. It seems there was some confusion, which
>       was cleared up by Tom, and Cale said he’ll pick it up now again.
>
>
> ## Waiting for Shepherd action
>
> #367: Clarify primops using unboxed sums, Shepherd: Simon Marlow
>       Simon said he’d reject it on the Github PR. Still waiting
>       for the discussion to start on the mailing list.
>
> #390: Fine-grained pragmas, Shepherd: Vitaly
>       Still kinda new, but a recommendation would be good soon.
>
>
> Cheers,
> Joachim
> --
> Joachim Breitner
>   mail at joachim-breitner.de
>   http://www.joachim-breitner.de/
> <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.joachim-breitner.de%2F&data=04%7C01%7Csimonpj%40microsoft.com%7C0b9f9dd78f934d620c5e08d8e0c0012f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637506462581507230%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=gsdKkpp3AhJz2ins9uuctT%2FGf6rr2bScSHFWyX3jFhM%3D&reserved=0>
>
>
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committee&data=04%7C01%7Csimonpj%40microsoft.com%7C0b9f9dd78f934d620c5e08d8e0c0012f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637506462581517226%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=BY04FgtL9RHpjI6frr%2BOYfxwPkW5yjN2DeRyv2JaKN4%3D&reserved=0>
>
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20210308/61bc08e5/attachment-0001.html>

From mail at joachim-breitner.de  Tue Mar  9 07:58:52 2021
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Tue, 09 Mar 2021 08:58:52 +0100
Subject: [ghc-steering-committee] Please review #378: Support ergonomic
 dependent types, Shepherd: Simon PJ
Message-ID: <bfacc32e6c13ca48ec708f7c6ab85a8188bc28c2.camel@joachim-breitner.de>

Dear Committe,

Support ergonomic dependent types
has been proposed by Richard Eisenberg
https://github.com/ghc-proposals/ghc-proposals/pull/378
https://github.com/goldfirere/ghc-proposals/blob/dependent-types/proposals/0000-dependent-type-design.rst

This is a meta-proposal, aimed at refining our criteria when evaluating
proposals, and wants us to confirm that we take compatibility with a
future world where Haskell gains more dependently typed features into
account, and welcome changes that we would likely reject if we did not
expect to move towards that future.
(My rephrasing, please have a look at least at “Motivation” and
“Proposed Change Specification”).

We might need more of a Moderator than a Shepherd here… I propose that
Simon PJ leads us to a decision here. I know that Simon has a strong
opinion on this already and might not be a “neutral moderator”. But
opinions are not a bad thing per se, and I think this questions
requires Chair-level involvement.



Please guide us to a conclusion as outlined in 
https://github.com/ghc-proposals/ghc-proposals#committee-process

Thanks,
Joachim
-- 
-- 
Joachim Breitner
  mail at joachim-breitner.de
  http://www.joachim-breitner.de/



From arnaud.spiwack at tweag.io  Tue Mar  9 08:02:30 2021
From: arnaud.spiwack at tweag.io (Spiwack, Arnaud)
Date: Tue, 9 Mar 2021 09:02:30 +0100
Subject: [ghc-steering-committee] Status
In-Reply-To: <CAGK9nup52iaxt6fMwRpn2-xXgsWwWeFMcJ2BMuXBgbNUqo35Mg@mail.gmail.com>
References: <7494e545ea1a9ce59053e0d685c81299922ed62b.camel@joachim-breitner.de>
 <CAGK9nupGZE1Ncdwfz3HXbtrxqvzSeV1zJ9b18BVHHio8Xu32jQ@mail.gmail.com>
 <VI1PR83MB0222389754916F1F2E3155ECAD859@VI1PR83MB0222.EURPRD83.prod.outlook.com>
 <CAGK9nupTPOX66xMiB9VjbjpQvkb7_sDrNnbrZb=AJgtDs1XGuA@mail.gmail.com>
 <AM0PR83MB02761C192D1210B90023E12EAD969@AM0PR83MB0276.EURPRD83.prod.outlook.com>
 <CAGK9nuoMm7=jq0K=mtgrjdftGXzbmPgNrupuiBz7cPA=uYcy_Q@mail.gmail.com>
 <CAGK9nuoo33s3b49rpu9SEcNtD=f=mJX=K=YSzRR9FqH7AeEzQA@mail.gmail.com>
 <AM0PR83MB0276F9B335ECF11A18131FC8AD939@AM0PR83MB0276.EURPRD83.prod.outlook.com>
 <010f0178154511dc-58479ea3-989e-4866-a94f-6f6a9eeec3ad-000000@us-east-2.amazonses.com>
 <CAGK9nup52iaxt6fMwRpn2-xXgsWwWeFMcJ2BMuXBgbNUqo35Mg@mail.gmail.com>
Message-ID: <CAH6fHQkY0sy6gaYJRtgepQE5TjQOy=MZUB04HhoQZvbMb6utiw@mail.gmail.com>

Simon's suggestion sounds like the proper thing to do to me too.

The connection between #281 and dependent types is a little superficial,
but it #281 mixes the type syntax and the term syntax a bit more (in fact,
most of the details in the proposal are about that). The ability to mix
types and terms some way or another is central to having more dependent
typing. So there is, at the very least, a need for synchronization between
the various corresponding proposals. Though, in fact, this visible forall
thing is part of the dependent type package that Richard has been working
towards. It does fit somewhat naturally in the big picture.

On Tue, Mar 9, 2021 at 6:58 AM Iavor Diatchki <iavor.diatchki at gmail.com>
wrote:

> I will wait a few more days to see if anyone else expresses an opinion,
> otherwise I'll do as Simon suggests.
>
> Could someone clarify what does #281 have to do with dependent types?
>  The example that was brought up, and I think is pretty reasonable, is
> `sizeOf` from the `Storbale` class:  I might want to write `sizeOf @Bool`.
> Is the plan to require that dependent types are enabled to write stuff like
> that?
>
> -Iavor
>
>
>
> On Mon, Mar 8, 2021 at 8:35 PM Richard Eisenberg <rae at richarde.dev> wrote:
>
>> I have now submitted #378 for a committee decision (though I will forgive
>> Joachim if he missed the notification among the 200 comments on that
>> thread). So perhaps we can tackle all of this together.
>>
>> Richard
>>
>> On Mar 8, 2021, at 8:54 AM, Simon Peyton Jones via ghc-steering-committee
>> <ghc-steering-committee at haskell.org> wrote:
>>
>> I don't think this proposal is the right place to discuss dependent
>> types, so I propose that we reject the proposal.  To ensure progress, I'll
>> do so within a week, so please discuss before then, if you think otherwise.
>>
>> I would suggest that rather than “reject” (which sounds like “we don’t
>> want this, don’t resubmit it”), we push it back saying that we agree that
>> it’d be better to settle #378 first.  So we we’ll mark it as “needs
>> revision” not because we have anything specific to suggest, but so that
>> it’s back in the author’s control.  He should feel free to re-submit
>> (perhaps revised in some way, as he sees fit) once #378 is resolved.
>>
>> Simon
>>
>> *From:* Iavor Diatchki <iavor.diatchki at gmail.com>
>> *Sent:* 06 March 2021 16:51
>> *To:* Simon Peyton Jones <simonpj at microsoft.com>
>> *Cc:* Joachim Breitner <mail at joachim-breitner.de>;
>> ghc-steering-committee <ghc-steering-committee at haskell.org>
>> *Subject:* Re: [ghc-steering-committee] Status
>>
>>
>> Hello,
>>
>>
>>
>> This is the author's response to my query:
>>
>>
>>
>> So, the situation seems to be as follows:
>>
>>    - if we want dependent types (as described on that Wiki page), I
>>    would like to resubmit
>>
>>
>>    - if we do not want them, I will retract the proposal and close it
>>
>> I need to know the committee’s stance on dependent types to proceed here.
>>
>>
>> I don't think this proposal is the right place to discuss dependent
>> types, so I propose that we reject the proposal.  To ensure progress, I'll
>> do so within a week, so please discuss before then, if you think otherwise.
>>
>> -Iavor
>>
>>
>>
>> On Fri, Mar 5, 2021 at 5:02 PM Iavor Diatchki <iavor.diatchki at gmail.com>
>> wrote:
>>
>> OK, I posted a note on the git-hub, asking @int-index what he wants to do.
>> In case anyone needs a refresher, this is the discussion we had when I
>> submitted this to the committee back in November:
>>
>>
>> https://mail.haskell.org/pipermail/ghc-steering-committee/2020-November/001859.html
>> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haskell.org%2Fpipermail%2Fghc-steering-committee%2F2020-November%2F001859.html&data=04%7C01%7Csimonpj%40microsoft.com%7C0b9f9dd78f934d620c5e08d8e0c0012f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637506462581487239%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=2inDHN90f7OQ9XIcd76l50Lwwp6axEUZVdea%2BoRFZzg%3D&reserved=0>
>>
>> another somewhat relevant discussion that followed was this:
>>
>> https://mail.haskell.org/pipermail/ghc-steering-committee/2020-November/001865.html
>> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haskell.org%2Fpipermail%2Fghc-steering-committee%2F2020-November%2F001865.html&data=04%7C01%7Csimonpj%40microsoft.com%7C0b9f9dd78f934d620c5e08d8e0c0012f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637506462581497234%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=k4jiWTo11nNFH6zHyw7oYMFfyl0kxkQEsXKSueeC2Mk%3D&reserved=0>
>>
>> and here is a link to the proposal and the git-hub discussion:
>> https://github.com/ghc-proposals/ghc-proposals/pull/281
>> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%2Fpull%2F281&data=04%7C01%7Csimonpj%40microsoft.com%7C0b9f9dd78f934d620c5e08d8e0c0012f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637506462581497234%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=X7tkk61XrEd9utRxcQjA3Eh3Wi3cDXuJdMae%2BBcx3gM%3D&reserved=0>
>>
>> -Iavor
>>
>>
>>
>> On Fri, Mar 5, 2021 at 3:13 PM Simon Peyton Jones <simonpj at microsoft.com>
>> wrote:
>>
>> This is about #281 visible dependent quantification.
>>
>> Our role is to accept, reject, or push back to the author for revision.
>> We should do so in a timely way.
>>
>> If I were the shepherd I’d be asking the author “Do you want to revise
>> the proposal at all in the light of all the discussion, or do you want the
>> committee to decide yay/nay based on the proposal as it is now?”
>>
>> He might want to revise/discuss a bit.  But if he says “please decide on
>> it as-is” then I think you should make a recommendation: accept or reject.
>> (I don’t think the discussion has led to any specific revisions that we
>> want to see.)
>>
>> I sense you would recommend reject.   That’s totally fine. Then the rest
>> of us have to make up our minds.  We might end up with a more nuanced
>> position like “we are not ready to accept this now, so if you want a
>> decision now, it’d be no; but feel free to ask the same question again in
>> six months time”.
>>
>> If you don’t feel able to be the shepherd, that’s fine too: tell Joachim
>> and he’ll finger someone else!
>>
>> But, by hook or by crook, I do think we should do something, not just sit
>> on it.  Tom’s nudge is helpful.
>>
>> Simon
>>
>> *From:* Iavor Diatchki <iavor.diatchki at gmail.com>
>> *Sent:* 05 March 2021 19:42
>> *To:* Simon Peyton Jones <simonpj at microsoft.com>
>> *Cc:* Joachim Breitner <mail at joachim-breitner.de>;
>> ghc-steering-committee <ghc-steering-committee at haskell.org>
>> *Subject:* Re: [ghc-steering-committee] Status
>>
>>
>> I am being nudged to do something with this proposal,  but I am not sure
>> what...   Is the rest of the committee OK with moving it back "revisions
>> required", and if so what revisions would we like?
>>
>>
>>
>> I would be quite happy if someone else wanted to shephard this.  As I
>> mentioned before, I don't have much interest in DH, so I have not followed
>> the really long discussion related to that, and if and how it might relate
>> to #281.
>>
>>
>>
>> My recommendation for the moment would be:
>>
>>    * This seems like a useful feature independent of DH, so it would be
>> nice to come up with a concise notation to use the feature on its own,
>> without worrying about DH.
>>
>>
>>
>> Please let me know what you think, as I am not sure what is the
>> committee's stance on the proposal.
>>
>>
>>
>> -Iavor
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> On Thu, Feb 18, 2021 at 1:54 PM Simon Peyton Jones <simonpj at microsoft.com>
>> wrote:
>>
>> There has been a broad further discussion.
>> What we advertise is that, rather that leave a proposal “under committee
>> review”, we will push it back to the author with an invitation to resubmit
>> when the discussion has died down and they feel ready to submit a proposal,
>> revised in the light of the discussion.  That’s different to reject… it
>> means that there is an ongoing debate so it’s not a good time for the
>> committee to make a decision.
>>
>> Simon
>>
>> *From:* ghc-steering-committee <
>> ghc-steering-committee-bounces at haskell.org> *On Behalf Of *Iavor Diatchki
>> *Sent:* 18 February 2021 16:47
>> *To:* Joachim Breitner <mail at joachim-breitner.de>
>> *Cc:* ghc-steering-committee <ghc-steering-committee at haskell.org>
>> *Subject:* Re: [ghc-steering-committee] Status
>>
>>
>> On #381 I think the idea of visible quantification makes sense every now
>> and then, but I don't like the concrete details of the proposal: the magic
>> lifting of terms to types seems quite complicated, and using `type` as an
>> explicit herald doesn't look nice.  So I don't think it's the right design,
>> and therefore I suggest we reject the proposal.
>>
>>
>>
>> I am sure that others would disagree as apparently this is an essential
>> part of dependent Haskell.   I have not followed the large discussion that
>> Richard created, as I am not particularly interested in the design being
>> proposed, so perhaps someone else should champion this.
>>
>>
>>
>> Aslo, I am not sure if I am actually on the committee, as I thought my
>> term had expired?  That might be more reason for someone else to pick it up.
>>
>>
>>
>> -Iavor
>>
>>
>>
>>
>>
>>
>>
>> On Thu, Feb 18, 2021 at 2:32 AM Joachim Breitner <
>> mail at joachim-breitner.de> wrote:
>>
>> Dear Committee,
>>
>> another status update, because why not.
>>
>> A small reminder: These mails have two sections, one that’s a delta
>> since last status, but below is a summary of all proposals we have to
>> act on. Please at least scroll through that on each status mail to see
>> if you are listed, maybe you forgot something (or I made a mistake).
>>
>> So here’s the delta since last month.
>>
>>  * GHC2021 defined! Yay!
>>
>>  * Bylaws merged! Yay
>>
>>  * Simon², Iavor, Richard and me had thus their terms expired.
>>
>>    The Simons, as key members, wanted to continue and were
>>    voted back in.
>>
>>    The others are now “expiring”, until the next nomination round
>>    concludes. Alejandro is going to run that process.
>>
>>  * we were asked to review these proposals:
>>    #390: Fine-grained pragmas, Shepherd: Vitaly
>>
>>  * we have a recommendation from the shepherd about:
>>    #368: Warn on prefix/suffix operators (accept)
>>
>>  * we have sent the following proposals back to revision
>>    - none -
>>
>>  * we decided about the following proposals
>>    #313: Delimited continuation primops (accept)
>>    #387: The Char kind (accept)
>>    #368: Warn on prefix/suffix operators (accept)
>>
>> We currently have to act on the following 5 proposals, down by 2.
>>
>> ## Waiting for committee decision
>>
>> #381: Visible 'forall' in types of terms, Shepherd: Iavor
>>       Recommendation was to reject, but discussion went into the more
>>       abstract “whither dependent Haskell”. But what does this mean
>>       for this proposal?
>>       Iavor, can you pick this up again?
>>
>> #369: Add sumToTag# primop, Shepherd: Eric
>>       Essentially accepted, waiting for feedback from the author on
>>       final tweaks. Eric, care to nudge the author, or just do it?
>>
>> #302: \of, Shepherd: Cale
>>       No new discussion yet. It seems there was some confusion, which
>>       was cleared up by Tom, and Cale said he’ll pick it up now again.
>>
>>
>> ## Waiting for Shepherd action
>>
>> #367: Clarify primops using unboxed sums, Shepherd: Simon Marlow
>>       Simon said he’d reject it on the Github PR. Still waiting
>>       for the discussion to start on the mailing list.
>>
>> #390: Fine-grained pragmas, Shepherd: Vitaly
>>       Still kinda new, but a recommendation would be good soon.
>>
>>
>> Cheers,
>> Joachim
>> --
>> Joachim Breitner
>>   mail at joachim-breitner.de
>>   http://www.joachim-breitner.de/
>> <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.joachim-breitner.de%2F&data=04%7C01%7Csimonpj%40microsoft.com%7C0b9f9dd78f934d620c5e08d8e0c0012f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637506462581507230%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=gsdKkpp3AhJz2ins9uuctT%2FGf6rr2bScSHFWyX3jFhM%3D&reserved=0>
>>
>>
>> _______________________________________________
>> ghc-steering-committee mailing list
>> ghc-steering-committee at haskell.org
>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committee&data=04%7C01%7Csimonpj%40microsoft.com%7C0b9f9dd78f934d620c5e08d8e0c0012f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637506462581517226%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=BY04FgtL9RHpjI6frr%2BOYfxwPkW5yjN2DeRyv2JaKN4%3D&reserved=0>
>>
>> _______________________________________________
>> ghc-steering-committee mailing list
>> ghc-steering-committee at haskell.org
>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>
>>
>> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20210309/507d87e8/attachment-0001.html>

From arnaud.spiwack at tweag.io  Tue Mar  9 08:14:12 2021
From: arnaud.spiwack at tweag.io (Spiwack, Arnaud)
Date: Tue, 9 Mar 2021 09:14:12 +0100
Subject: [ghc-steering-committee] Recommendation: reject #367 (was: Re:
 Please review #367: Clarify primops using unboxed sums,
 Shepherd: Simon Marlow)
In-Reply-To: <010f01781504442d-f0eaea4e-d93b-4dca-9af8-25492e4bcfea-000000@us-east-2.amazonses.com>
References: <50e635bf8c9a58568aa810fc284da4cdf39ce702.camel@joachim-breitner.de>
 <CANsrgPK4eWHyJDfZmuTdgj5weYvbKroNjxZr+HUW5CfP7hKYHA@mail.gmail.com>
 <f9ea90b44714208fa2635ee292871d74a0061079.camel@joachim-breitner.de>
 <010f01781504442d-f0eaea4e-d93b-4dca-9af8-25492e4bcfea-000000@us-east-2.amazonses.com>
Message-ID: <CAH6fHQ=x+RtcUVQgDkD9fYLU6ntVtzRZJp+51+yzxFd8Oooqmg@mail.gmail.com>

I don't have an informed opinion. I'll trust Simon. It may very well be a
case of “it would have been the right thing to do were we to start from
scratch today, but it is now too late to do so”.

On Tue, Mar 9, 2021 at 4:25 AM Richard Eisenberg <rae at richarde.dev> wrote:

> I want to accept this. But, in the end, I don't see enough benefit (which
> seems to be mostly aesthetic) to justify the (somewhat modest, as these
> things go) costs.
>
> I sadly agree with the shepherd to reject.
>
> Richard
>
> On Mar 8, 2021, at 11:59 AM, Joachim Breitner <mail at joachim-breitner.de>
> wrote:
>
> Hi,
>
> your points sounds reasonable, and the author got a heads up on the
> Github thread (so unlikely that there was a misunderstanding or
> oversight), so I’ll concur with the shepherd.
>
> Cheers,
> Joachim
>
>
> Am Montag, den 08.03.2021, 15:51 +0000 schrieb Simon Marlow:
>
> Committee,
>
> Proposal #367 suggests using unboxed sums for the results of 7 (seven)
> primops that use sum types but currently have to encode those explicitly
> using `Int#`.
>
>
> https://github.com/treeowl/ghc-proposals/blob/unboxed-sum-primops/proposals/0000-unboxed-sum-primops.md
>
> The proposal is arguably the right thing, however I'm suggesting we reject
> it for the following reasons:
> The implementations of the primops would bake in the translation of
> unboxed sums. Right now our unboxed sum translation is defined in one place
> - CorePrep - but this proposal would leak it into the implementations of a
> few primops.
> Migration would entail adding a backwards-compatibility layer, with the
> associated complexity and risk of performance regressions.
> While the current situation is perhaps inelegant, it's not broken and it's
> easy to understand.
> Thoughts?
>
> Simon
>
>
> On Sun, 4 Oct 2020 at 22:14, Joachim Breitner <mail at joachim-breitner.de>
> wrote:
>
> Dear Committee,
>
> this is your secretary speaking:
>
> Clarify primops using unboxed sum
> has been proposed by David Feuer
> https://github.com/ghc-proposals/ghc-proposals/pull/367
>
> https://github.com/treeowl/ghc-proposals/blob/unboxed-sum-primops/proposals/0000-unboxed-sum-primops.md
>
> I’ll propose Simon Marlow as the shepherd.
>
> Please guide us to a conclusion as outlined in
> https://github.com/ghc-proposals/ghc-proposals#committee-process
>
> Thanks,
> Joachim
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
> --
> Joachim Breitner
>  mail at joachim-breitner.de
>  http://www.joachim-breitner.de/
>
>
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
>
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20210309/ea49104f/attachment.html>

From simonpj at microsoft.com  Tue Mar  9 09:32:15 2021
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Tue, 9 Mar 2021 09:32:15 +0000
Subject: [ghc-steering-committee] Please review #378: Support ergonomic
 dependent types, Shepherd: Simon PJ
In-Reply-To: <bfacc32e6c13ca48ec708f7c6ab85a8188bc28c2.camel@joachim-breitner.de>
References: <bfacc32e6c13ca48ec708f7c6ab85a8188bc28c2.camel@joachim-breitner.de>
Message-ID: <AM0PR83MB027624CE10AF0AA369804711AD929@AM0PR83MB0276.EURPRD83.prod.outlook.com>

OK. I expect to recommend acceptance, but I'm encouraging Richard to sharpen
up the proposal a bit first.

Simon

|  -----Original Message-----
|  From: ghc-steering-committee <ghc-steering-committee-
|  bounces at haskell.org> On Behalf Of Joachim Breitner
|  Sent: 09 March 2021 07:59
|  To: ghc-steering-committee <ghc-steering-committee at haskell.org>
|  Subject: [ghc-steering-committee] Please review #378: Support
|  ergonomic dependent types, Shepherd: Simon PJ
|  
|  Dear Committe,
|  
|  Support ergonomic dependent types
|  has been proposed by Richard Eisenberg
|  https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith
|  ub.com%2Fghc-proposals%2Fghc-
|  proposals%2Fpull%2F378&amp;data=04%7C01%7Csimonpj%40microsoft.com%7C00
|  a4caf0e0ef47088ece08d8e2d138f8%7C72f988bf86f141af91ab2d7cd011db47%7C1%
|  7C0%7C637508735553069267%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiL
|  CJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=0Zmcel%
|  2BF0alE2edi11tYc1j3hQgPj59YM%2BSiheV5HKg%3D&amp;reserved=0
|  https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith
|  ub.com%2Fgoldfirere%2Fghc-proposals%2Fblob%2Fdependent-
|  types%2Fproposals%2F0000-dependent-type-
|  design.rst&amp;data=04%7C01%7Csimonpj%40microsoft.com%7C00a4caf0e0ef47
|  088ece08d8e2d138f8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637508
|  735553079263%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luM
|  zIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=fCxgBPggy37Toqff7O3
|  %2BU3MfmNu%2Bq2EuINfGwn3mXtk%3D&amp;reserved=0
|  
|  This is a meta-proposal, aimed at refining our criteria when
|  evaluating proposals, and wants us to confirm that we take
|  compatibility with a future world where Haskell gains more dependently
|  typed features into account, and welcome changes that we would likely
|  reject if we did not expect to move towards that future.
|  (My rephrasing, please have a look at least at "Motivation" and
|  "Proposed Change Specification").
|  
|  We might need more of a Moderator than a Shepherd here... I propose that
|  Simon PJ leads us to a decision here. I know that Simon has a strong
|  opinion on this already and might not be a "neutral moderator". But
|  opinions are not a bad thing per se, and I think this questions
|  requires Chair-level involvement.
|  
|  
|  
|  Please guide us to a conclusion as outlined in
|  https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith
|  ub.com%2Fghc-proposals%2Fghc-proposals%23committee-
|  process&amp;data=04%7C01%7Csimonpj%40microsoft.com%7C00a4caf0e0ef47088
|  ece08d8e2d138f8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637508735
|  553079263%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIi
|  LCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=VQIMqyjGBspDti%2Bx%2FF
|  eb24SUehXLbblJc2aXJF2YQU8%3D&amp;reserved=0
|  
|  Thanks,
|  Joachim
|  --
|  --
|  Joachim Breitner
|    mail at joachim-breitner.de
|  
|  https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.j
|  oachim-
|  breitner.de%2F&amp;data=04%7C01%7Csimonpj%40microsoft.com%7C00a4caf0e0
|  ef47088ece08d8e2d138f8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63
|  7508735553079263%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV
|  2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=%2B9wLNVuFC718I
|  Xi4GFuoI8DQ8CEpo%2F6oNHG5xDweftE%3D&amp;reserved=0
|  
|  
|  _______________________________________________
|  ghc-steering-committee mailing list
|  ghc-steering-committee at haskell.org
|  https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail
|  .haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-
|  committee&amp;data=04%7C01%7Csimonpj%40microsoft.com%7C00a4caf0e0ef470
|  88ece08d8e2d138f8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6375087
|  35553079263%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMz
|  IiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=EGd2zHc79e9JH1POn%2F
|  rWmF%2Ft154dPDHwDMAFS%2FsPUI4%3D&amp;reserved=0

From simonpj at microsoft.com  Tue Mar  9 10:12:04 2021
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Tue, 9 Mar 2021 10:12:04 +0000
Subject: [ghc-steering-committee] Recommendation: reject #367 (was: Re:
 Please review #367: Clarify primops using unboxed sums,
 Shepherd: Simon Marlow)
In-Reply-To: <CANsrgPK4eWHyJDfZmuTdgj5weYvbKroNjxZr+HUW5CfP7hKYHA@mail.gmail.com>
References: <50e635bf8c9a58568aa810fc284da4cdf39ce702.camel@joachim-breitner.de>
 <CANsrgPK4eWHyJDfZmuTdgj5weYvbKroNjxZr+HUW5CfP7hKYHA@mail.gmail.com>
Message-ID: <AM0PR83MB0276FC7F49E997B563113C05AD929@AM0PR83MB0276.EURPRD83.prod.outlook.com>

I'm content to follow Simon's recommendation.

The proposal says

I propose to replace the primops that produce product-encoded sums with ones that produce proper unboxed sums.
And it is nicer to have primops that are more explicit about their types, but of course GHC's ultimate representation of an unboxed sum is precisely the same as the current primop's one.  So this is purely an ergonomic improvement, and one that will be felt only by a small constituency.    So the costs of the current setup are not heavy.

It's a good proposal to have on file, in case it becomes more pressing some day.

Simon

From: ghc-steering-committee <ghc-steering-committee-bounces at haskell.org> On Behalf Of Simon Marlow
Sent: 08 March 2021 15:52
To: Joachim Breitner <mail at joachim-breitner.de>
Cc: ghc-steering-committee at haskell.org
Subject: [ghc-steering-committee] Recommendation: reject #367 (was: Re: Please review #367: Clarify primops using unboxed sums, Shepherd: Simon Marlow)

Committee,

Proposal #367 suggests using unboxed sums for the results of 7 (seven) primops that use sum types but currently have to encode those explicitly using `Int#`.

https://github.com/treeowl/ghc-proposals/blob/unboxed-sum-primops/proposals/0000-unboxed-sum-primops.md<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Ftreeowl%2Fghc-proposals%2Fblob%2Funboxed-sum-primops%2Fproposals%2F0000-unboxed-sum-primops.md&data=04%7C01%7Csimonpj%40microsoft.com%7C000703ba8b6f4771a5c108d8e24a21c6%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637508156673797668%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=Nm7owDB1Mxxt5MG2JGe1%2Fw9t7FpDxBhU%2BppV09grIgg%3D&reserved=0>

The proposal is arguably the right thing, however I'm suggesting we reject it for the following reasons:

  1.  The implementations of the primops would bake in the translation of unboxed sums. Right now our unboxed sum translation is defined in one place - CorePrep - but this proposal would leak it into the implementations of a few primops.
  2.  Migration would entail adding a backwards-compatibility layer, with the associated complexity and risk of performance regressions.
  3.  While the current situation is perhaps inelegant, it's not broken and it's easy to understand.
Thoughts?

Simon


On Sun, 4 Oct 2020 at 22:14, Joachim Breitner <mail at joachim-breitner.de<mailto:mail at joachim-breitner.de>> wrote:
Dear Committee,

this is your secretary speaking:

Clarify primops using unboxed sum
has been proposed by David Feuer
https://github.com/ghc-proposals/ghc-proposals/pull/367<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%2Fpull%2F367&data=04%7C01%7Csimonpj%40microsoft.com%7C000703ba8b6f4771a5c108d8e24a21c6%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637508156673807671%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=VR%2F9%2BRcLdFCqGcmxuCqPseHbr2rTjBDcX6r6NwDDvBs%3D&reserved=0>
https://github.com/treeowl/ghc-proposals/blob/unboxed-sum-primops/proposals/0000-unboxed-sum-primops.md<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Ftreeowl%2Fghc-proposals%2Fblob%2Funboxed-sum-primops%2Fproposals%2F0000-unboxed-sum-primops.md&data=04%7C01%7Csimonpj%40microsoft.com%7C000703ba8b6f4771a5c108d8e24a21c6%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637508156673807671%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=DRJrOd7m2X0sB1d9HdcdyHYUm7Z6HTuT0QHRB56FXFs%3D&reserved=0>

I'll propose Simon Marlow as the shepherd.

Please guide us to a conclusion as outlined in
https://github.com/ghc-proposals/ghc-proposals#committee-process<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%23committee-process&data=04%7C01%7Csimonpj%40microsoft.com%7C000703ba8b6f4771a5c108d8e24a21c6%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637508156673817669%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=D%2FI8%2BJNnqo8XTVWtptXntxmBRwYP2wxZVX8tNxlZCQA%3D&reserved=0>

Thanks,
Joachim
--
Joachim Breitner
  mail at joachim-breitner.de<mailto:mail at joachim-breitner.de>
  http://www.joachim-breitner.de/<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.joachim-breitner.de%2F&data=04%7C01%7Csimonpj%40microsoft.com%7C000703ba8b6f4771a5c108d8e24a21c6%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637508156673827660%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=lHwIB62LfzP%2F6e0MoitU5jlOQivnuB%2FrBlCgE7NOhfk%3D&reserved=0>


_______________________________________________
ghc-steering-committee mailing list
ghc-steering-committee at haskell.org<mailto:ghc-steering-committee at haskell.org>
https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committee&data=04%7C01%7Csimonpj%40microsoft.com%7C000703ba8b6f4771a5c108d8e24a21c6%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637508156673837651%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=oRJy6pL6bv9ZN6Q28ybaOHHMJE4yb9ieW0goPBHU4iw%3D&reserved=0>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20210309/6d495ee4/attachment.html>

From simonpj at microsoft.com  Tue Mar  9 15:36:21 2021
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Tue, 9 Mar 2021 15:36:21 +0000
Subject: [ghc-steering-committee] [ghc-proposals/ghc-proposals] Support
 ergonomic dependent types (#378)
In-Reply-To: <ghc-proposals/ghc-proposals/pull/378/c793940902@github.com>
References: <ghc-proposals/ghc-proposals/pull/378@github.com>
 <ghc-proposals/ghc-proposals/pull/378/c793940902@github.com>
Message-ID: <AM0PR83MB02761A4BBE04550919C9B8C8AD929@AM0PR83MB0276.EURPRD83.prod.outlook.com>

(Writing to the committee rather than polluting the DT proposal thread.)

We have a bullet "Does not create a language fork" in the review criteria<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%23review-criteria&data=04%7C01%7Csimonpj%40microsoft.com%7C2d39084e129047d031f508d8e3044dca%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637508954935323802%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=F0fX%2BB%2BjH7xfJWoiYxNOfJRFvo6vix6HhwID5%2FXt1EU%3D&reserved=0>. I treat it like the other criteria, a fork-like proposal is a red flag, but not an automatic reject.
This relates back to our earlier conversation about proposal properties.  Eric suggested:


  *   Backward compatibility.  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?


  *   Plausible default.   Do we expect the extension to eventually be on-by-default (in GHCxxxx) and effectively disappear, or will it continue to be opt-in?   -XStrict or -XRebindableSyntax are examples of an extension that we want, but that are not plausible defaults.


  *   Localised.  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.)

Reading our "fork-like" criterion, it seems to be saying "it's fork-like if it is not a plausible default (in the above sense), and fork-like is bad".  But as -XStrict and -XRebindableSyntax show, not being a plausible default isn't necessarily bad.

Do we want to revise our language in the criteria?

Simon



From: Eric Seidel <notifications at github.com>
Sent: 09 March 2021 14:05
To: ghc-proposals/ghc-proposals <ghc-proposals at noreply.github.com>
Cc: Simon Peyton Jones <simonpj at microsoft.com>; Assign <assign at noreply.github.com>
Subject: Re: [ghc-proposals/ghc-proposals] Support ergonomic dependent types (#378)


Do we have a write up of what it means to be fork-like? Or what role the fork-like property plays in our deliberations?

We have a bullet "Does not create a language fork" in the review criteria<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%23review-criteria&data=04%7C01%7Csimonpj%40microsoft.com%7C2d39084e129047d031f508d8e3044dca%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637508954935323802%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=F0fX%2BB%2BjH7xfJWoiYxNOfJRFvo6vix6HhwID5%2FXt1EU%3D&reserved=0>. I treat it like the other criteria, a fork-like proposal is a red flag, but not an automatic reject.

-
You are receiving this because you were assigned.
Reply to this email directly, view it on GitHub<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%2Fpull%2F378%23issuecomment-793940902&data=04%7C01%7Csimonpj%40microsoft.com%7C2d39084e129047d031f508d8e3044dca%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637508954935333797%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=GEe4ZWVbIpjkzC%2BSt7lP3NHIeeUgXY6eQEys8wFt1U8%3D&reserved=0>, or unsubscribe<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAAEOY6Y6WR6HKU6KFAV2YS3TCYMHDANCNFSM4TVJPUXQ&data=04%7C01%7Csimonpj%40microsoft.com%7C2d39084e129047d031f508d8e3044dca%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637508954935333797%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=r82A2uAz7kdd85xUqy0N%2FBPJB1sYhBuOTDcbFQ6c4fY%3D&reserved=0>.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20210309/1f5b7fd4/attachment.html>

From trupill at gmail.com  Tue Mar  9 15:38:37 2021
From: trupill at gmail.com (Alejandro Serrano Mena)
Date: Tue, 9 Mar 2021 07:38:37 -0800
Subject: [ghc-steering-committee] Recommendation: reject #367 (was: Re:
 Please review #367: Clarify primops using unboxed sums,
 Shepherd: Simon Marlow)
In-Reply-To: <CAH6fHQ=x+RtcUVQgDkD9fYLU6ntVtzRZJp+51+yzxFd8Oooqmg@mail.gmail.com>
References: <50e635bf8c9a58568aa810fc284da4cdf39ce702.camel@joachim-breitner.de>
 <CANsrgPK4eWHyJDfZmuTdgj5weYvbKroNjxZr+HUW5CfP7hKYHA@mail.gmail.com>
 <f9ea90b44714208fa2635ee292871d74a0061079.camel@joachim-breitner.de>
 <010f01781504442d-f0eaea4e-d93b-4dca-9af8-25492e4bcfea-000000@us-east-2.amazonses.com>
 <CAH6fHQ=x+RtcUVQgDkD9fYLU6ntVtzRZJp+51+yzxFd8Oooqmg@mail.gmail.com>
Message-ID: <CAHnFXOvkThi=v0Y-+iHYTgOLqEHNguucc+NVJuALZzCg1mkrFQ@mail.gmail.com>

 This is my feeling, too.

Alejandro

On 9 Mar 2021 at 09:14:12, Spiwack, Arnaud <arnaud.spiwack at tweag.io> wrote:

> I don't have an informed opinion. I'll trust Simon. It may very well be a
> case of “it would have been the right thing to do were we to start from
> scratch today, but it is now too late to do so”.
>
> On Tue, Mar 9, 2021 at 4:25 AM Richard Eisenberg <rae at richarde.dev> wrote:
>
>> I want to accept this. But, in the end, I don't see enough benefit (which
>> seems to be mostly aesthetic) to justify the (somewhat modest, as these
>> things go) costs.
>>
>> I sadly agree with the shepherd to reject.
>>
>> Richard
>>
>> On Mar 8, 2021, at 11:59 AM, Joachim Breitner <mail at joachim-breitner.de>
>> wrote:
>>
>> Hi,
>>
>> your points sounds reasonable, and the author got a heads up on the
>> Github thread (so unlikely that there was a misunderstanding or
>> oversight), so I’ll concur with the shepherd.
>>
>> Cheers,
>> Joachim
>>
>>
>> Am Montag, den 08.03.2021, 15:51 +0000 schrieb Simon Marlow:
>>
>> Committee,
>>
>> Proposal #367 suggests using unboxed sums for the results of 7 (seven)
>> primops that use sum types but currently have to encode those explicitly
>> using `Int#`.
>>
>>
>> https://github.com/treeowl/ghc-proposals/blob/unboxed-sum-primops/proposals/0000-unboxed-sum-primops.md
>>
>> The proposal is arguably the right thing, however I'm suggesting we
>> reject it for the following reasons:
>> The implementations of the primops would bake in the translation of
>> unboxed sums. Right now our unboxed sum translation is defined in one place
>> - CorePrep - but this proposal would leak it into the implementations of a
>> few primops.
>> Migration would entail adding a backwards-compatibility layer, with the
>> associated complexity and risk of performance regressions.
>> While the current situation is perhaps inelegant, it's not broken and
>> it's easy to understand.
>> Thoughts?
>>
>> Simon
>>
>>
>> On Sun, 4 Oct 2020 at 22:14, Joachim Breitner <mail at joachim-breitner.de>
>> wrote:
>>
>> Dear Committee,
>>
>> this is your secretary speaking:
>>
>> Clarify primops using unboxed sum
>> has been proposed by David Feuer
>> https://github.com/ghc-proposals/ghc-proposals/pull/367
>>
>> https://github.com/treeowl/ghc-proposals/blob/unboxed-sum-primops/proposals/0000-unboxed-sum-primops.md
>>
>> I’ll propose Simon Marlow as the shepherd.
>>
>> Please guide us to a conclusion as outlined in
>> https://github.com/ghc-proposals/ghc-proposals#committee-process
>>
>> Thanks,
>> Joachim
>> _______________________________________________
>> ghc-steering-committee mailing list
>> ghc-steering-committee at haskell.org
>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>
>> --
>> Joachim Breitner
>>  mail at joachim-breitner.de
>>  http://www.joachim-breitner.de/
>>
>>
>> _______________________________________________
>> ghc-steering-committee mailing list
>> ghc-steering-committee at haskell.org
>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>
>>
>> _______________________________________________
>> ghc-steering-committee mailing list
>> ghc-steering-committee at haskell.org
>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20210309/47bef01b/attachment-0001.html>

From rae at richarde.dev  Tue Mar  9 19:30:03 2021
From: rae at richarde.dev (Richard Eisenberg)
Date: Tue, 9 Mar 2021 19:30:03 +0000
Subject: [ghc-steering-committee] Please review #378: Support ergonomic
 dependent types, Shepherd: Simon PJ
In-Reply-To: <AM0PR83MB027624CE10AF0AA369804711AD929@AM0PR83MB0276.EURPRD83.prod.outlook.com>
References: <bfacc32e6c13ca48ec708f7c6ab85a8188bc28c2.camel@joachim-breitner.de>
 <AM0PR83MB027624CE10AF0AA369804711AD929@AM0PR83MB0276.EURPRD83.prod.outlook.com>
Message-ID: <010f01781877bc26-086933f4-3142-42b2-9442-57a39df83c71-000000@us-east-2.amazonses.com>



> On Mar 9, 2021, at 4:32 AM, Simon Peyton Jones via ghc-steering-committee <ghc-steering-committee at haskell.org> wrote:
> 
> OK. I expect to recommend acceptance, but I'm encouraging Richard to sharpen
> up the proposal a bit first.

Yes. Good suggestions on the thread. I've updated the proposal.

Thanks,
Richard

From rae at richarde.dev  Tue Mar  9 19:33:44 2021
From: rae at richarde.dev (Richard Eisenberg)
Date: Tue, 9 Mar 2021 19:33:44 +0000
Subject: [ghc-steering-committee] Status
In-Reply-To: <CAH6fHQkY0sy6gaYJRtgepQE5TjQOy=MZUB04HhoQZvbMb6utiw@mail.gmail.com>
References: <7494e545ea1a9ce59053e0d685c81299922ed62b.camel@joachim-breitner.de>
 <CAGK9nupGZE1Ncdwfz3HXbtrxqvzSeV1zJ9b18BVHHio8Xu32jQ@mail.gmail.com>
 <VI1PR83MB0222389754916F1F2E3155ECAD859@VI1PR83MB0222.EURPRD83.prod.outlook.com>
 <CAGK9nupTPOX66xMiB9VjbjpQvkb7_sDrNnbrZb=AJgtDs1XGuA@mail.gmail.com>
 <AM0PR83MB02761C192D1210B90023E12EAD969@AM0PR83MB0276.EURPRD83.prod.outlook.com>
 <CAGK9nuoMm7=jq0K=mtgrjdftGXzbmPgNrupuiBz7cPA=uYcy_Q@mail.gmail.com>
 <CAGK9nuoo33s3b49rpu9SEcNtD=f=mJX=K=YSzRR9FqH7AeEzQA@mail.gmail.com>
 <AM0PR83MB0276F9B335ECF11A18131FC8AD939@AM0PR83MB0276.EURPRD83.prod.outlook.com>
 <010f0178154511dc-58479ea3-989e-4866-a94f-6f6a9eeec3ad-000000@us-east-2.amazonses.com>
 <CAGK9nup52iaxt6fMwRpn2-xXgsWwWeFMcJ2BMuXBgbNUqo35Mg@mail.gmail.com>
 <CAH6fHQkY0sy6gaYJRtgepQE5TjQOy=MZUB04HhoQZvbMb6utiw@mail.gmail.com>
Message-ID: <010f0178187b1d51-bb9ea7e1-7125-4611-b5df-1f819d38a1b3-000000@us-east-2.amazonses.com>

I agree with Arnaud. The connection to dependent types is pretty tangential, really: it's all about whether we have `sizeOf @Bool` or `sizeOf Bool`. If we had no intention of dependent types, I'd probably favor the former. But forward-compatibility with the design sketch for dependent types (https://gitlab.haskell.org/ghc/ghc/-/wikis/dependent-haskell) suggests using the latter. The problem is that the latter choice is more challenging to support, and indeed drives much of the complexity in the proposal.

So, we are a bit stuck: do we favor the design that's easier to specify and implement today? or do we favor the design that will mesh better tomorrow (assuming tomorrow has dependent types)? Our answer to #378 will inform this decision.

Richard

> On Mar 9, 2021, at 3:02 AM, Spiwack, Arnaud <arnaud.spiwack at tweag.io> wrote:
> 
> Simon's suggestion sounds like the proper thing to do to me too.
> 
> The connection between #281 and dependent types is a little superficial, but it #281 mixes the type syntax and the term syntax a bit more (in fact, most of the details in the proposal are about that). The ability to mix types and terms some way or another is central to having more dependent typing. So there is, at the very least, a need for synchronization between the various corresponding proposals. Though, in fact, this visible forall thing is part of the dependent type package that Richard has been working towards. It does fit somewhat naturally in the big picture.
> 
> On Tue, Mar 9, 2021 at 6:58 AM Iavor Diatchki <iavor.diatchki at gmail.com <mailto:iavor.diatchki at gmail.com>> wrote:
> I will wait a few more days to see if anyone else expresses an opinion, otherwise I'll do as Simon suggests.
> 
> Could someone clarify what does #281 have to do with dependent types?   The example that was brought up, and I think is pretty reasonable, is `sizeOf` from the `Storbale` class:  I might want to write `sizeOf @Bool`.  Is the plan to require that dependent types are enabled to write stuff like that?
> 
> -Iavor
> 
> 
> 
> On Mon, Mar 8, 2021 at 8:35 PM Richard Eisenberg <rae at richarde.dev <mailto:rae at richarde.dev>> wrote:
> I have now submitted #378 for a committee decision (though I will forgive Joachim if he missed the notification among the 200 comments on that thread). So perhaps we can tackle all of this together.
> 
> Richard
> 
>> On Mar 8, 2021, at 8:54 AM, Simon Peyton Jones via ghc-steering-committee <ghc-steering-committee at haskell.org <mailto:ghc-steering-committee at haskell.org>> wrote:
>> 
>> I don't think this proposal is the right place to discuss dependent types, so I propose that we reject the proposal.  To ensure progress, I'll do so within a week, so please discuss before then, if you think otherwise.
>>  
>> I would suggest that rather than “reject” (which sounds like “we don’t want this, don’t resubmit it”), we push it back saying that we agree that it’d be better to settle #378 first.  So we we’ll mark it as “needs revision” not because we have anything specific to suggest, but so that it’s back in the author’s control.  He should feel free to re-submit (perhaps revised in some way, as he sees fit) once #378 is resolved.
>>  
>> Simon
>>  
>> From: Iavor Diatchki <iavor.diatchki at gmail.com <mailto:iavor.diatchki at gmail.com>> 
>> Sent: 06 March 2021 16:51
>> To: Simon Peyton Jones <simonpj at microsoft.com <mailto:simonpj at microsoft.com>>
>> Cc: Joachim Breitner <mail at joachim-breitner.de <mailto:mail at joachim-breitner.de>>; ghc-steering-committee <ghc-steering-committee at haskell.org <mailto:ghc-steering-committee at haskell.org>>
>> Subject: Re: [ghc-steering-committee] Status
>>  
>> Hello,
>> 
>>  
>> 
>> This is the author's response to my query:
>> 
>>  
>> 
>> So, the situation seems to be as follows:
>> 
>> if we want dependent types (as described on that Wiki page), I would like to resubmit
>> if we do not want them, I will retract the proposal and close it
>> I need to know the committee’s stance on dependent types to proceed here.
>>  
>> I don't think this proposal is the right place to discuss dependent types, so I propose that we reject the proposal.  To ensure progress, I'll do so within a week, so please discuss before then, if you think otherwise.
>>  
>> -Iavor
>>  
>>  
>>  
>> On Fri, Mar 5, 2021 at 5:02 PM Iavor Diatchki <iavor.diatchki at gmail.com <mailto:iavor.diatchki at gmail.com>> wrote:
>> OK, I posted a note on the git-hub, asking @int-index what he wants to do.
>> In case anyone needs a refresher, this is the discussion we had when I submitted this to the committee back in November:
>>  
>> https://mail.haskell.org/pipermail/ghc-steering-committee/2020-November/001859.html <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haskell.org%2Fpipermail%2Fghc-steering-committee%2F2020-November%2F001859.html&data=04%7C01%7Csimonpj%40microsoft.com%7C0b9f9dd78f934d620c5e08d8e0c0012f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637506462581487239%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=2inDHN90f7OQ9XIcd76l50Lwwp6axEUZVdea%2BoRFZzg%3D&reserved=0>
>>  
>> another somewhat relevant discussion that followed was this:
>> https://mail.haskell.org/pipermail/ghc-steering-committee/2020-November/001865.html <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haskell.org%2Fpipermail%2Fghc-steering-committee%2F2020-November%2F001865.html&data=04%7C01%7Csimonpj%40microsoft.com%7C0b9f9dd78f934d620c5e08d8e0c0012f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637506462581497234%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=k4jiWTo11nNFH6zHyw7oYMFfyl0kxkQEsXKSueeC2Mk%3D&reserved=0>
>>  
>> and here is a link to the proposal and the git-hub discussion:
>> https://github.com/ghc-proposals/ghc-proposals/pull/281 <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%2Fpull%2F281&data=04%7C01%7Csimonpj%40microsoft.com%7C0b9f9dd78f934d620c5e08d8e0c0012f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637506462581497234%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=X7tkk61XrEd9utRxcQjA3Eh3Wi3cDXuJdMae%2BBcx3gM%3D&reserved=0>
>>  
>> -Iavor
>>  
>>  
>>  
>> On Fri, Mar 5, 2021 at 3:13 PM Simon Peyton Jones <simonpj at microsoft.com <mailto:simonpj at microsoft.com>> wrote:
>> This is about #281 visible dependent quantification.
>>  
>> Our role is to accept, reject, or push back to the author for revision.  We should do so in a timely way.
>>  
>> If I were the shepherd I’d be asking the author “Do you want to revise the proposal at all in the light of all the discussion, or do you want the committee to decide yay/nay based on the proposal as it is now?”   
>>  
>> He might want to revise/discuss a bit.  But if he says “please decide on it as-is” then I think you should make a recommendation: accept or reject.  (I don’t think the discussion has led to any specific revisions that we want to see.)  
>>  
>> I sense you would recommend reject.   That’s totally fine. Then the rest of us have to make up our minds.  We might end up with a more nuanced position like “we are not ready to accept this now, so if you want a decision now, it’d be no; but feel free to ask the same question again in six months time”.
>>  
>> If you don’t feel able to be the shepherd, that’s fine too: tell Joachim and he’ll finger someone else!
>>  
>> But, by hook or by crook, I do think we should do something, not just sit on it.  Tom’s nudge is helpful.
>>  
>> Simon
>>  
>> From: Iavor Diatchki <iavor.diatchki at gmail.com <mailto:iavor.diatchki at gmail.com>> 
>> Sent: 05 March 2021 19:42
>> To: Simon Peyton Jones <simonpj at microsoft.com <mailto:simonpj at microsoft.com>>
>> Cc: Joachim Breitner <mail at joachim-breitner.de <mailto:mail at joachim-breitner.de>>; ghc-steering-committee <ghc-steering-committee at haskell.org <mailto:ghc-steering-committee at haskell.org>>
>> Subject: Re: [ghc-steering-committee] Status
>>  
>> I am being nudged to do something with this proposal,  but I am not sure what...   Is the rest of the committee OK with moving it back "revisions required", and if so what revisions would we like?  
>> 
>>  
>> 
>> I would be quite happy if someone else wanted to shephard this.  As I mentioned before, I don't have much interest in DH, so I have not followed the really long discussion related to that, and if and how it might relate to #281. 
>> 
>>  
>> 
>> My recommendation for the moment would be:
>> 
>>    * This seems like a useful feature independent of DH, so it would be nice to come up with a concise notation to use the feature on its own, without worrying about DH.
>> 
>>  
>> 
>> Please let me know what you think, as I am not sure what is the committee's stance on the proposal.
>> 
>>  
>> 
>> -Iavor
>> 
>>  
>> 
>>  
>> 
>>  
>> 
>>  
>> 
>>  
>> 
>> On Thu, Feb 18, 2021 at 1:54 PM Simon Peyton Jones <simonpj at microsoft.com <mailto:simonpj at microsoft.com>> wrote:
>> 
>> There has been a broad further discussion.
>> What we advertise is that, rather that leave a proposal “under committee review”, we will push it back to the author with an invitation to resubmit when the discussion has died down and they feel ready to submit a proposal, revised in the light of the discussion.  That’s different to reject… it means that there is an ongoing debate so it’s not a good time for the committee to make a decision.
>> 
>> Simon
>>  
>> From: ghc-steering-committee <ghc-steering-committee-bounces at haskell.org <mailto:ghc-steering-committee-bounces at haskell.org>> On Behalf Of Iavor Diatchki
>> Sent: 18 February 2021 16:47
>> To: Joachim Breitner <mail at joachim-breitner.de <mailto:mail at joachim-breitner.de>>
>> Cc: ghc-steering-committee <ghc-steering-committee at haskell.org <mailto:ghc-steering-committee at haskell.org>>
>> Subject: Re: [ghc-steering-committee] Status
>>  
>> On #381 I think the idea of visible quantification makes sense every now and then, but I don't like the concrete details of the proposal: the magic lifting of terms to types seems quite complicated, and using `type` as an explicit herald doesn't look nice.  So I don't think it's the right design, and therefore I suggest we reject the proposal.
>> 
>>  
>> 
>> I am sure that others would disagree as apparently this is an essential part of dependent Haskell.   I have not followed the large discussion that Richard created, as I am not particularly interested in the design being proposed, so perhaps someone else should champion this.
>> 
>>  
>> 
>> Aslo, I am not sure if I am actually on the committee, as I thought my term had expired?  That might be more reason for someone else to pick it up.
>> 
>>  
>> 
>> -Iavor
>> 
>>  
>> 
>>  
>> 
>>  
>> 
>> On Thu, Feb 18, 2021 at 2:32 AM Joachim Breitner <mail at joachim-breitner.de <mailto:mail at joachim-breitner.de>> wrote:
>> 
>> Dear Committee,
>> 
>> another status update, because why not.
>> 
>> A small reminder: These mails have two sections, one that’s a delta
>> since last status, but below is a summary of all proposals we have to
>> act on. Please at least scroll through that on each status mail to see
>> if you are listed, maybe you forgot something (or I made a mistake).
>> 
>> So here’s the delta since last month.
>> 
>>  * GHC2021 defined! Yay!
>> 
>>  * Bylaws merged! Yay
>> 
>>  * Simon², Iavor, Richard and me had thus their terms expired.
>> 
>>    The Simons, as key members, wanted to continue and were
>>    voted back in.
>> 
>>    The others are now “expiring”, until the next nomination round
>>    concludes. Alejandro is going to run that process.
>> 
>>  * we were asked to review these proposals:
>>    #390: Fine-grained pragmas, Shepherd: Vitaly
>> 
>>  * we have a recommendation from the shepherd about:
>>    #368: Warn on prefix/suffix operators (accept)
>> 
>>  * we have sent the following proposals back to revision
>>    - none -
>> 
>>  * we decided about the following proposals
>>    #313: Delimited continuation primops (accept)
>>    #387: The Char kind (accept)
>>    #368: Warn on prefix/suffix operators (accept)
>> 
>> We currently have to act on the following 5 proposals, down by 2.
>> 
>> ## Waiting for committee decision
>> 
>> #381: Visible 'forall' in types of terms, Shepherd: Iavor
>>       Recommendation was to reject, but discussion went into the more 
>>       abstract “whither dependent Haskell”. But what does this mean
>>       for this proposal?
>>       Iavor, can you pick this up again?
>> 
>> #369: Add sumToTag# primop, Shepherd: Eric
>>       Essentially accepted, waiting for feedback from the author on
>>       final tweaks. Eric, care to nudge the author, or just do it?
>> 
>> #302: \of, Shepherd: Cale
>>       No new discussion yet. It seems there was some confusion, which
>>       was cleared up by Tom, and Cale said he’ll pick it up now again.
>> 
>> 
>> ## Waiting for Shepherd action
>> 
>> #367: Clarify primops using unboxed sums, Shepherd: Simon Marlow
>>       Simon said he’d reject it on the Github PR. Still waiting
>>       for the discussion to start on the mailing list.
>> 
>> #390: Fine-grained pragmas, Shepherd: Vitaly
>>       Still kinda new, but a recommendation would be good soon.
>> 
>> 
>> Cheers,
>> Joachim
>> -- 
>> Joachim Breitner
>>   mail at joachim-breitner.de <mailto:mail at joachim-breitner.de>
>>   http://www.joachim-breitner.de/ <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.joachim-breitner.de%2F&data=04%7C01%7Csimonpj%40microsoft.com%7C0b9f9dd78f934d620c5e08d8e0c0012f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637506462581507230%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=gsdKkpp3AhJz2ins9uuctT%2FGf6rr2bScSHFWyX3jFhM%3D&reserved=0>
>> 
>> 
>> _______________________________________________
>> ghc-steering-committee mailing list
>> ghc-steering-committee at haskell.org <mailto:ghc-steering-committee at haskell.org>
>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committee&data=04%7C01%7Csimonpj%40microsoft.com%7C0b9f9dd78f934d620c5e08d8e0c0012f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637506462581517226%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=BY04FgtL9RHpjI6frr%2BOYfxwPkW5yjN2DeRyv2JaKN4%3D&reserved=0>_______________________________________________
>> ghc-steering-committee mailing list
>> ghc-steering-committee at haskell.org <mailto:ghc-steering-committee at haskell.org>
>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee <https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee>
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org <mailto:ghc-steering-committee at haskell.org>
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee <https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20210309/7da2980e/attachment-0001.html>

From iavor.diatchki at gmail.com  Tue Mar  9 20:12:35 2021
From: iavor.diatchki at gmail.com (Iavor Diatchki)
Date: Tue, 9 Mar 2021 12:12:35 -0800
Subject: [ghc-steering-committee] Status
In-Reply-To: <010f0178187b1d51-bb9ea7e1-7125-4611-b5df-1f819d38a1b3-000000@us-east-2.amazonses.com>
References: <7494e545ea1a9ce59053e0d685c81299922ed62b.camel@joachim-breitner.de>
 <CAGK9nupGZE1Ncdwfz3HXbtrxqvzSeV1zJ9b18BVHHio8Xu32jQ@mail.gmail.com>
 <VI1PR83MB0222389754916F1F2E3155ECAD859@VI1PR83MB0222.EURPRD83.prod.outlook.com>
 <CAGK9nupTPOX66xMiB9VjbjpQvkb7_sDrNnbrZb=AJgtDs1XGuA@mail.gmail.com>
 <AM0PR83MB02761C192D1210B90023E12EAD969@AM0PR83MB0276.EURPRD83.prod.outlook.com>
 <CAGK9nuoMm7=jq0K=mtgrjdftGXzbmPgNrupuiBz7cPA=uYcy_Q@mail.gmail.com>
 <CAGK9nuoo33s3b49rpu9SEcNtD=f=mJX=K=YSzRR9FqH7AeEzQA@mail.gmail.com>
 <AM0PR83MB0276F9B335ECF11A18131FC8AD939@AM0PR83MB0276.EURPRD83.prod.outlook.com>
 <010f0178154511dc-58479ea3-989e-4866-a94f-6f6a9eeec3ad-000000@us-east-2.amazonses.com>
 <CAGK9nup52iaxt6fMwRpn2-xXgsWwWeFMcJ2BMuXBgbNUqo35Mg@mail.gmail.com>
 <CAH6fHQkY0sy6gaYJRtgepQE5TjQOy=MZUB04HhoQZvbMb6utiw@mail.gmail.com>
 <010f0178187b1d51-bb9ea7e1-7125-4611-b5df-1f819d38a1b3-000000@us-east-2.amazonses.com>
Message-ID: <CAGK9nup6u06pcqkjjMJptLNaAuAUmRkbMdb3ynjN-bUyGR9G3Q@mail.gmail.com>

I still don't see what `sizeOf Bool` has to do with dependent types---there
does not appear to be a semantic difference between `sizeOf @Bool` and
`sizeOf Bool`, rather it is just a notational difference.   I am really
missing the vision of where folks are picturing us ending up with all these
changes.   Is the thinking that anyone who wants to use the FFI should have
to enable dependent types?

-Iavor



On Tue, Mar 9, 2021 at 11:33 AM Richard Eisenberg <rae at richarde.dev> wrote:

> I agree with Arnaud. The connection to dependent types is pretty
> tangential, really: it's all about whether we have `sizeOf @Bool` or
> `sizeOf Bool`. If we had no intention of dependent types, I'd probably
> favor the former. But forward-compatibility with the design sketch for
> dependent types (
> https://gitlab.haskell.org/ghc/ghc/-/wikis/dependent-haskell) suggests
> using the latter. The problem is that the latter choice is more challenging
> to support, and indeed drives much of the complexity in the proposal.
>
> So, we are a bit stuck: do we favor the design that's easier to specify
> and implement today? or do we favor the design that will mesh better
> tomorrow (assuming tomorrow has dependent types)? Our answer to #378 will
> inform this decision.
>
> Richard
>
> On Mar 9, 2021, at 3:02 AM, Spiwack, Arnaud <arnaud.spiwack at tweag.io>
> wrote:
>
> Simon's suggestion sounds like the proper thing to do to me too.
>
> The connection between #281 and dependent types is a little superficial,
> but it #281 mixes the type syntax and the term syntax a bit more (in fact,
> most of the details in the proposal are about that). The ability to mix
> types and terms some way or another is central to having more dependent
> typing. So there is, at the very least, a need for synchronization between
> the various corresponding proposals. Though, in fact, this visible forall
> thing is part of the dependent type package that Richard has been working
> towards. It does fit somewhat naturally in the big picture.
>
> On Tue, Mar 9, 2021 at 6:58 AM Iavor Diatchki <iavor.diatchki at gmail.com>
> wrote:
>
>> I will wait a few more days to see if anyone else expresses an opinion,
>> otherwise I'll do as Simon suggests.
>>
>> Could someone clarify what does #281 have to do with dependent types?
>>  The example that was brought up, and I think is pretty reasonable, is
>> `sizeOf` from the `Storbale` class:  I might want to write `sizeOf @Bool`.
>> Is the plan to require that dependent types are enabled to write stuff like
>> that?
>>
>> -Iavor
>>
>>
>>
>> On Mon, Mar 8, 2021 at 8:35 PM Richard Eisenberg <rae at richarde.dev>
>> wrote:
>>
>>> I have now submitted #378 for a committee decision (though I will
>>> forgive Joachim if he missed the notification among the 200 comments on
>>> that thread). So perhaps we can tackle all of this together.
>>>
>>> Richard
>>>
>>> On Mar 8, 2021, at 8:54 AM, Simon Peyton Jones via
>>> ghc-steering-committee <ghc-steering-committee at haskell.org> wrote:
>>>
>>> I don't think this proposal is the right place to discuss dependent
>>> types, so I propose that we reject the proposal.  To ensure progress, I'll
>>> do so within a week, so please discuss before then, if you think otherwise.
>>>
>>> I would suggest that rather than “reject” (which sounds like “we don’t
>>> want this, don’t resubmit it”), we push it back saying that we agree that
>>> it’d be better to settle #378 first.  So we we’ll mark it as “needs
>>> revision” not because we have anything specific to suggest, but so that
>>> it’s back in the author’s control.  He should feel free to re-submit
>>> (perhaps revised in some way, as he sees fit) once #378 is resolved.
>>>
>>> Simon
>>>
>>> *From:* Iavor Diatchki <iavor.diatchki at gmail.com>
>>> *Sent:* 06 March 2021 16:51
>>> *To:* Simon Peyton Jones <simonpj at microsoft.com>
>>> *Cc:* Joachim Breitner <mail at joachim-breitner.de>;
>>> ghc-steering-committee <ghc-steering-committee at haskell.org>
>>> *Subject:* Re: [ghc-steering-committee] Status
>>>
>>>
>>> Hello,
>>>
>>>
>>>
>>> This is the author's response to my query:
>>>
>>>
>>>
>>> So, the situation seems to be as follows:
>>>
>>>    - if we want dependent types (as described on that Wiki page), I
>>>    would like to resubmit
>>>
>>>
>>>    - if we do not want them, I will retract the proposal and close it
>>>
>>> I need to know the committee’s stance on dependent types to proceed here.
>>>
>>>
>>> I don't think this proposal is the right place to discuss dependent
>>> types, so I propose that we reject the proposal.  To ensure progress, I'll
>>> do so within a week, so please discuss before then, if you think otherwise.
>>>
>>> -Iavor
>>>
>>>
>>>
>>> On Fri, Mar 5, 2021 at 5:02 PM Iavor Diatchki <iavor.diatchki at gmail.com>
>>> wrote:
>>>
>>> OK, I posted a note on the git-hub, asking @int-index what he wants to
>>> do.
>>> In case anyone needs a refresher, this is the discussion we had when I
>>> submitted this to the committee back in November:
>>>
>>>
>>> https://mail.haskell.org/pipermail/ghc-steering-committee/2020-November/001859.html
>>> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haskell.org%2Fpipermail%2Fghc-steering-committee%2F2020-November%2F001859.html&data=04%7C01%7Csimonpj%40microsoft.com%7C0b9f9dd78f934d620c5e08d8e0c0012f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637506462581487239%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=2inDHN90f7OQ9XIcd76l50Lwwp6axEUZVdea%2BoRFZzg%3D&reserved=0>
>>>
>>> another somewhat relevant discussion that followed was this:
>>>
>>> https://mail.haskell.org/pipermail/ghc-steering-committee/2020-November/001865.html
>>> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haskell.org%2Fpipermail%2Fghc-steering-committee%2F2020-November%2F001865.html&data=04%7C01%7Csimonpj%40microsoft.com%7C0b9f9dd78f934d620c5e08d8e0c0012f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637506462581497234%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=k4jiWTo11nNFH6zHyw7oYMFfyl0kxkQEsXKSueeC2Mk%3D&reserved=0>
>>>
>>> and here is a link to the proposal and the git-hub discussion:
>>> https://github.com/ghc-proposals/ghc-proposals/pull/281
>>> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%2Fpull%2F281&data=04%7C01%7Csimonpj%40microsoft.com%7C0b9f9dd78f934d620c5e08d8e0c0012f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637506462581497234%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=X7tkk61XrEd9utRxcQjA3Eh3Wi3cDXuJdMae%2BBcx3gM%3D&reserved=0>
>>>
>>> -Iavor
>>>
>>>
>>>
>>> On Fri, Mar 5, 2021 at 3:13 PM Simon Peyton Jones <simonpj at microsoft.com>
>>> wrote:
>>>
>>> This is about #281 visible dependent quantification.
>>>
>>> Our role is to accept, reject, or push back to the author for revision.
>>> We should do so in a timely way.
>>>
>>> If I were the shepherd I’d be asking the author “Do you want to revise
>>> the proposal at all in the light of all the discussion, or do you want the
>>> committee to decide yay/nay based on the proposal as it is now?”
>>>
>>> He might want to revise/discuss a bit.  But if he says “please decide on
>>> it as-is” then I think you should make a recommendation: accept or reject.
>>> (I don’t think the discussion has led to any specific revisions that we
>>> want to see.)
>>>
>>> I sense you would recommend reject.   That’s totally fine. Then the rest
>>> of us have to make up our minds.  We might end up with a more nuanced
>>> position like “we are not ready to accept this now, so if you want a
>>> decision now, it’d be no; but feel free to ask the same question again in
>>> six months time”.
>>>
>>> If you don’t feel able to be the shepherd, that’s fine too: tell Joachim
>>> and he’ll finger someone else!
>>>
>>> But, by hook or by crook, I do think we should do something, not just
>>> sit on it.  Tom’s nudge is helpful.
>>>
>>> Simon
>>>
>>> *From:* Iavor Diatchki <iavor.diatchki at gmail.com>
>>> *Sent:* 05 March 2021 19:42
>>> *To:* Simon Peyton Jones <simonpj at microsoft.com>
>>> *Cc:* Joachim Breitner <mail at joachim-breitner.de>;
>>> ghc-steering-committee <ghc-steering-committee at haskell.org>
>>> *Subject:* Re: [ghc-steering-committee] Status
>>>
>>>
>>> I am being nudged to do something with this proposal,  but I am not sure
>>> what...   Is the rest of the committee OK with moving it back "revisions
>>> required", and if so what revisions would we like?
>>>
>>>
>>>
>>> I would be quite happy if someone else wanted to shephard this.  As I
>>> mentioned before, I don't have much interest in DH, so I have not followed
>>> the really long discussion related to that, and if and how it might relate
>>> to #281.
>>>
>>>
>>>
>>> My recommendation for the moment would be:
>>>
>>>    * This seems like a useful feature independent of DH, so it would be
>>> nice to come up with a concise notation to use the feature on its own,
>>> without worrying about DH.
>>>
>>>
>>>
>>> Please let me know what you think, as I am not sure what is the
>>> committee's stance on the proposal.
>>>
>>>
>>>
>>> -Iavor
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Thu, Feb 18, 2021 at 1:54 PM Simon Peyton Jones <
>>> simonpj at microsoft.com> wrote:
>>>
>>> There has been a broad further discussion.
>>> What we advertise is that, rather that leave a proposal “under committee
>>> review”, we will push it back to the author with an invitation to resubmit
>>> when the discussion has died down and they feel ready to submit a proposal,
>>> revised in the light of the discussion.  That’s different to reject… it
>>> means that there is an ongoing debate so it’s not a good time for the
>>> committee to make a decision.
>>>
>>> Simon
>>>
>>> *From:* ghc-steering-committee <
>>> ghc-steering-committee-bounces at haskell.org> *On Behalf Of *Iavor
>>> Diatchki
>>> *Sent:* 18 February 2021 16:47
>>> *To:* Joachim Breitner <mail at joachim-breitner.de>
>>> *Cc:* ghc-steering-committee <ghc-steering-committee at haskell.org>
>>> *Subject:* Re: [ghc-steering-committee] Status
>>>
>>>
>>> On #381 I think the idea of visible quantification makes sense every now
>>> and then, but I don't like the concrete details of the proposal: the magic
>>> lifting of terms to types seems quite complicated, and using `type` as an
>>> explicit herald doesn't look nice.  So I don't think it's the right design,
>>> and therefore I suggest we reject the proposal.
>>>
>>>
>>>
>>> I am sure that others would disagree as apparently this is an essential
>>> part of dependent Haskell.   I have not followed the large discussion that
>>> Richard created, as I am not particularly interested in the design being
>>> proposed, so perhaps someone else should champion this.
>>>
>>>
>>>
>>> Aslo, I am not sure if I am actually on the committee, as I thought my
>>> term had expired?  That might be more reason for someone else to pick it up.
>>>
>>>
>>>
>>> -Iavor
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Thu, Feb 18, 2021 at 2:32 AM Joachim Breitner <
>>> mail at joachim-breitner.de> wrote:
>>>
>>> Dear Committee,
>>>
>>> another status update, because why not.
>>>
>>> A small reminder: These mails have two sections, one that’s a delta
>>> since last status, but below is a summary of all proposals we have to
>>> act on. Please at least scroll through that on each status mail to see
>>> if you are listed, maybe you forgot something (or I made a mistake).
>>>
>>> So here’s the delta since last month.
>>>
>>>  * GHC2021 defined! Yay!
>>>
>>>  * Bylaws merged! Yay
>>>
>>>  * Simon², Iavor, Richard and me had thus their terms expired.
>>>
>>>    The Simons, as key members, wanted to continue and were
>>>    voted back in.
>>>
>>>    The others are now “expiring”, until the next nomination round
>>>    concludes. Alejandro is going to run that process.
>>>
>>>  * we were asked to review these proposals:
>>>    #390: Fine-grained pragmas, Shepherd: Vitaly
>>>
>>>  * we have a recommendation from the shepherd about:
>>>    #368: Warn on prefix/suffix operators (accept)
>>>
>>>  * we have sent the following proposals back to revision
>>>    - none -
>>>
>>>  * we decided about the following proposals
>>>    #313: Delimited continuation primops (accept)
>>>    #387: The Char kind (accept)
>>>    #368: Warn on prefix/suffix operators (accept)
>>>
>>> We currently have to act on the following 5 proposals, down by 2.
>>>
>>> ## Waiting for committee decision
>>>
>>> #381: Visible 'forall' in types of terms, Shepherd: Iavor
>>>       Recommendation was to reject, but discussion went into the more
>>>       abstract “whither dependent Haskell”. But what does this mean
>>>       for this proposal?
>>>       Iavor, can you pick this up again?
>>>
>>> #369: Add sumToTag# primop, Shepherd: Eric
>>>       Essentially accepted, waiting for feedback from the author on
>>>       final tweaks. Eric, care to nudge the author, or just do it?
>>>
>>> #302: \of, Shepherd: Cale
>>>       No new discussion yet. It seems there was some confusion, which
>>>       was cleared up by Tom, and Cale said he’ll pick it up now again.
>>>
>>>
>>> ## Waiting for Shepherd action
>>>
>>> #367: Clarify primops using unboxed sums, Shepherd: Simon Marlow
>>>       Simon said he’d reject it on the Github PR. Still waiting
>>>       for the discussion to start on the mailing list.
>>>
>>> #390: Fine-grained pragmas, Shepherd: Vitaly
>>>       Still kinda new, but a recommendation would be good soon.
>>>
>>>
>>> Cheers,
>>> Joachim
>>> --
>>> Joachim Breitner
>>>   mail at joachim-breitner.de
>>>   http://www.joachim-breitner.de/
>>> <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.joachim-breitner.de%2F&data=04%7C01%7Csimonpj%40microsoft.com%7C0b9f9dd78f934d620c5e08d8e0c0012f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637506462581507230%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=gsdKkpp3AhJz2ins9uuctT%2FGf6rr2bScSHFWyX3jFhM%3D&reserved=0>
>>>
>>>
>>> _______________________________________________
>>> ghc-steering-committee mailing list
>>> ghc-steering-committee at haskell.org
>>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committee&data=04%7C01%7Csimonpj%40microsoft.com%7C0b9f9dd78f934d620c5e08d8e0c0012f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637506462581517226%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=BY04FgtL9RHpjI6frr%2BOYfxwPkW5yjN2DeRyv2JaKN4%3D&reserved=0>
>>>
>>> _______________________________________________
>>> ghc-steering-committee mailing list
>>> ghc-steering-committee at haskell.org
>>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>>
>>>
>>> _______________________________________________
>> ghc-steering-committee mailing list
>> ghc-steering-committee at haskell.org
>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20210309/6e736db5/attachment-0001.html>

From rae at richarde.dev  Tue Mar  9 20:22:27 2021
From: rae at richarde.dev (Richard Eisenberg)
Date: Tue, 9 Mar 2021 20:22:27 +0000
Subject: [ghc-steering-committee] Status
In-Reply-To: <CAGK9nup6u06pcqkjjMJptLNaAuAUmRkbMdb3ynjN-bUyGR9G3Q@mail.gmail.com>
References: <7494e545ea1a9ce59053e0d685c81299922ed62b.camel@joachim-breitner.de>
 <CAGK9nupGZE1Ncdwfz3HXbtrxqvzSeV1zJ9b18BVHHio8Xu32jQ@mail.gmail.com>
 <VI1PR83MB0222389754916F1F2E3155ECAD859@VI1PR83MB0222.EURPRD83.prod.outlook.com>
 <CAGK9nupTPOX66xMiB9VjbjpQvkb7_sDrNnbrZb=AJgtDs1XGuA@mail.gmail.com>
 <AM0PR83MB02761C192D1210B90023E12EAD969@AM0PR83MB0276.EURPRD83.prod.outlook.com>
 <CAGK9nuoMm7=jq0K=mtgrjdftGXzbmPgNrupuiBz7cPA=uYcy_Q@mail.gmail.com>
 <CAGK9nuoo33s3b49rpu9SEcNtD=f=mJX=K=YSzRR9FqH7AeEzQA@mail.gmail.com>
 <AM0PR83MB0276F9B335ECF11A18131FC8AD939@AM0PR83MB0276.EURPRD83.prod.outlook.com>
 <010f0178154511dc-58479ea3-989e-4866-a94f-6f6a9eeec3ad-000000@us-east-2.amazonses.com>
 <CAGK9nup52iaxt6fMwRpn2-xXgsWwWeFMcJ2BMuXBgbNUqo35Mg@mail.gmail.com>
 <CAH6fHQkY0sy6gaYJRtgepQE5TjQOy=MZUB04HhoQZvbMb6utiw@mail.gmail.com>
 <010f0178187b1d51-bb9ea7e1-7125-4611-b5df-1f819d38a1b3-000000@us-east-2.amazonses.com>
 <CAGK9nup6u06pcqkjjMJptLNaAuAUmRkbMdb3ynjN-bUyGR9G3Q@mail.gmail.com>
Message-ID: <010f017818a7b729-6829598e-1009-4e18-b026-5571573691d8-000000@us-east-2.amazonses.com>



> On Mar 9, 2021, at 3:12 PM, Iavor Diatchki <iavor.diatchki at gmail.com> wrote:
> 
> I still don't see what `sizeOf Bool` has to do with dependent types---there does not appear to be a semantic difference between `sizeOf @Bool` and `sizeOf Bool`, rather it is just a notational difference. 

Yes -- it's exactly the notational difference that's at issue. It's all a question of whether we want to require users to write @ before a required dependent (or type-level) argument. That really is it, but a good choice on this narrow (for me) hinges on whether or not we are working toward a future with dependent types.

>  I am really missing the vision of where folks are picturing us ending up with all these changes.   Is the thinking that anyone who wants to use the FFI should have to enable dependent types?

No. It's possible they would need no extensions at all. If there is no data constructor in scope named Bool, then sizeOf Bool might be accepted without any extensions on, I think. We often require an extension only at the definition site, not at usage sites.

Does this help?

Richard

> 
> -Iavor
> 
> 
> 
> On Tue, Mar 9, 2021 at 11:33 AM Richard Eisenberg <rae at richarde.dev <mailto:rae at richarde.dev>> wrote:
> I agree with Arnaud. The connection to dependent types is pretty tangential, really: it's all about whether we have `sizeOf @Bool` or `sizeOf Bool`. If we had no intention of dependent types, I'd probably favor the former. But forward-compatibility with the design sketch for dependent types (https://gitlab.haskell.org/ghc/ghc/-/wikis/dependent-haskell <https://gitlab.haskell.org/ghc/ghc/-/wikis/dependent-haskell>) suggests using the latter. The problem is that the latter choice is more challenging to support, and indeed drives much of the complexity in the proposal.
> 
> So, we are a bit stuck: do we favor the design that's easier to specify and implement today? or do we favor the design that will mesh better tomorrow (assuming tomorrow has dependent types)? Our answer to #378 will inform this decision.
> 
> Richard
> 
>> On Mar 9, 2021, at 3:02 AM, Spiwack, Arnaud <arnaud.spiwack at tweag.io <mailto:arnaud.spiwack at tweag.io>> wrote:
>> 
>> Simon's suggestion sounds like the proper thing to do to me too.
>> 
>> The connection between #281 and dependent types is a little superficial, but it #281 mixes the type syntax and the term syntax a bit more (in fact, most of the details in the proposal are about that). The ability to mix types and terms some way or another is central to having more dependent typing. So there is, at the very least, a need for synchronization between the various corresponding proposals. Though, in fact, this visible forall thing is part of the dependent type package that Richard has been working towards. It does fit somewhat naturally in the big picture.
>> 
>> On Tue, Mar 9, 2021 at 6:58 AM Iavor Diatchki <iavor.diatchki at gmail.com <mailto:iavor.diatchki at gmail.com>> wrote:
>> I will wait a few more days to see if anyone else expresses an opinion, otherwise I'll do as Simon suggests.
>> 
>> Could someone clarify what does #281 have to do with dependent types?   The example that was brought up, and I think is pretty reasonable, is `sizeOf` from the `Storbale` class:  I might want to write `sizeOf @Bool`.  Is the plan to require that dependent types are enabled to write stuff like that?
>> 
>> -Iavor
>> 
>> 
>> 
>> On Mon, Mar 8, 2021 at 8:35 PM Richard Eisenberg <rae at richarde.dev <mailto:rae at richarde.dev>> wrote:
>> I have now submitted #378 for a committee decision (though I will forgive Joachim if he missed the notification among the 200 comments on that thread). So perhaps we can tackle all of this together.
>> 
>> Richard
>> 
>>> On Mar 8, 2021, at 8:54 AM, Simon Peyton Jones via ghc-steering-committee <ghc-steering-committee at haskell.org <mailto:ghc-steering-committee at haskell.org>> wrote:
>>> 
>>> I don't think this proposal is the right place to discuss dependent types, so I propose that we reject the proposal.  To ensure progress, I'll do so within a week, so please discuss before then, if you think otherwise.
>>>  
>>> I would suggest that rather than “reject” (which sounds like “we don’t want this, don’t resubmit it”), we push it back saying that we agree that it’d be better to settle #378 first.  So we we’ll mark it as “needs revision” not because we have anything specific to suggest, but so that it’s back in the author’s control.  He should feel free to re-submit (perhaps revised in some way, as he sees fit) once #378 is resolved.
>>>  
>>> Simon
>>>  
>>> From: Iavor Diatchki <iavor.diatchki at gmail.com <mailto:iavor.diatchki at gmail.com>> 
>>> Sent: 06 March 2021 16:51
>>> To: Simon Peyton Jones <simonpj at microsoft.com <mailto:simonpj at microsoft.com>>
>>> Cc: Joachim Breitner <mail at joachim-breitner.de <mailto:mail at joachim-breitner.de>>; ghc-steering-committee <ghc-steering-committee at haskell.org <mailto:ghc-steering-committee at haskell.org>>
>>> Subject: Re: [ghc-steering-committee] Status
>>>  
>>> Hello,
>>> 
>>>  
>>> 
>>> This is the author's response to my query:
>>> 
>>>  
>>> 
>>> So, the situation seems to be as follows:
>>> 
>>> if we want dependent types (as described on that Wiki page), I would like to resubmit
>>> if we do not want them, I will retract the proposal and close it
>>> I need to know the committee’s stance on dependent types to proceed here.
>>>  
>>> I don't think this proposal is the right place to discuss dependent types, so I propose that we reject the proposal.  To ensure progress, I'll do so within a week, so please discuss before then, if you think otherwise.
>>>  
>>> -Iavor
>>>  
>>>  
>>>  
>>> On Fri, Mar 5, 2021 at 5:02 PM Iavor Diatchki <iavor.diatchki at gmail.com <mailto:iavor.diatchki at gmail.com>> wrote:
>>> OK, I posted a note on the git-hub, asking @int-index what he wants to do.
>>> In case anyone needs a refresher, this is the discussion we had when I submitted this to the committee back in November:
>>>  
>>> https://mail.haskell.org/pipermail/ghc-steering-committee/2020-November/001859.html <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haskell.org%2Fpipermail%2Fghc-steering-committee%2F2020-November%2F001859.html&data=04%7C01%7Csimonpj%40microsoft.com%7C0b9f9dd78f934d620c5e08d8e0c0012f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637506462581487239%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=2inDHN90f7OQ9XIcd76l50Lwwp6axEUZVdea%2BoRFZzg%3D&reserved=0>
>>>  
>>> another somewhat relevant discussion that followed was this:
>>> https://mail.haskell.org/pipermail/ghc-steering-committee/2020-November/001865.html <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haskell.org%2Fpipermail%2Fghc-steering-committee%2F2020-November%2F001865.html&data=04%7C01%7Csimonpj%40microsoft.com%7C0b9f9dd78f934d620c5e08d8e0c0012f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637506462581497234%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=k4jiWTo11nNFH6zHyw7oYMFfyl0kxkQEsXKSueeC2Mk%3D&reserved=0>
>>>  
>>> and here is a link to the proposal and the git-hub discussion:
>>> https://github.com/ghc-proposals/ghc-proposals/pull/281 <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%2Fpull%2F281&data=04%7C01%7Csimonpj%40microsoft.com%7C0b9f9dd78f934d620c5e08d8e0c0012f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637506462581497234%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=X7tkk61XrEd9utRxcQjA3Eh3Wi3cDXuJdMae%2BBcx3gM%3D&reserved=0>
>>>  
>>> -Iavor
>>>  
>>>  
>>>  
>>> On Fri, Mar 5, 2021 at 3:13 PM Simon Peyton Jones <simonpj at microsoft.com <mailto:simonpj at microsoft.com>> wrote:
>>> This is about #281 visible dependent quantification.
>>>  
>>> Our role is to accept, reject, or push back to the author for revision.  We should do so in a timely way.
>>>  
>>> If I were the shepherd I’d be asking the author “Do you want to revise the proposal at all in the light of all the discussion, or do you want the committee to decide yay/nay based on the proposal as it is now?”   
>>>  
>>> He might want to revise/discuss a bit.  But if he says “please decide on it as-is” then I think you should make a recommendation: accept or reject.  (I don’t think the discussion has led to any specific revisions that we want to see.)  
>>>  
>>> I sense you would recommend reject.   That’s totally fine. Then the rest of us have to make up our minds.  We might end up with a more nuanced position like “we are not ready to accept this now, so if you want a decision now, it’d be no; but feel free to ask the same question again in six months time”.
>>>  
>>> If you don’t feel able to be the shepherd, that’s fine too: tell Joachim and he’ll finger someone else!
>>>  
>>> But, by hook or by crook, I do think we should do something, not just sit on it.  Tom’s nudge is helpful.
>>>  
>>> Simon
>>>  
>>> From: Iavor Diatchki <iavor.diatchki at gmail.com <mailto:iavor.diatchki at gmail.com>> 
>>> Sent: 05 March 2021 19:42
>>> To: Simon Peyton Jones <simonpj at microsoft.com <mailto:simonpj at microsoft.com>>
>>> Cc: Joachim Breitner <mail at joachim-breitner.de <mailto:mail at joachim-breitner.de>>; ghc-steering-committee <ghc-steering-committee at haskell.org <mailto:ghc-steering-committee at haskell.org>>
>>> Subject: Re: [ghc-steering-committee] Status
>>>  
>>> I am being nudged to do something with this proposal,  but I am not sure what...   Is the rest of the committee OK with moving it back "revisions required", and if so what revisions would we like?  
>>> 
>>>  
>>> 
>>> I would be quite happy if someone else wanted to shephard this.  As I mentioned before, I don't have much interest in DH, so I have not followed the really long discussion related to that, and if and how it might relate to #281. 
>>> 
>>>  
>>> 
>>> My recommendation for the moment would be:
>>> 
>>>    * This seems like a useful feature independent of DH, so it would be nice to come up with a concise notation to use the feature on its own, without worrying about DH.
>>> 
>>>  
>>> 
>>> Please let me know what you think, as I am not sure what is the committee's stance on the proposal.
>>> 
>>>  
>>> 
>>> -Iavor
>>> 
>>>  
>>> 
>>>  
>>> 
>>>  
>>> 
>>>  
>>> 
>>>  
>>> 
>>> On Thu, Feb 18, 2021 at 1:54 PM Simon Peyton Jones <simonpj at microsoft.com <mailto:simonpj at microsoft.com>> wrote:
>>> 
>>> There has been a broad further discussion.
>>> What we advertise is that, rather that leave a proposal “under committee review”, we will push it back to the author with an invitation to resubmit when the discussion has died down and they feel ready to submit a proposal, revised in the light of the discussion.  That’s different to reject… it means that there is an ongoing debate so it’s not a good time for the committee to make a decision.
>>> 
>>> Simon
>>>  
>>> From: ghc-steering-committee <ghc-steering-committee-bounces at haskell.org <mailto:ghc-steering-committee-bounces at haskell.org>> On Behalf Of Iavor Diatchki
>>> Sent: 18 February 2021 16:47
>>> To: Joachim Breitner <mail at joachim-breitner.de <mailto:mail at joachim-breitner.de>>
>>> Cc: ghc-steering-committee <ghc-steering-committee at haskell.org <mailto:ghc-steering-committee at haskell.org>>
>>> Subject: Re: [ghc-steering-committee] Status
>>>  
>>> On #381 I think the idea of visible quantification makes sense every now and then, but I don't like the concrete details of the proposal: the magic lifting of terms to types seems quite complicated, and using `type` as an explicit herald doesn't look nice.  So I don't think it's the right design, and therefore I suggest we reject the proposal.
>>> 
>>>  
>>> 
>>> I am sure that others would disagree as apparently this is an essential part of dependent Haskell.   I have not followed the large discussion that Richard created, as I am not particularly interested in the design being proposed, so perhaps someone else should champion this.
>>> 
>>>  
>>> 
>>> Aslo, I am not sure if I am actually on the committee, as I thought my term had expired?  That might be more reason for someone else to pick it up.
>>> 
>>>  
>>> 
>>> -Iavor
>>> 
>>>  
>>> 
>>>  
>>> 
>>>  
>>> 
>>> On Thu, Feb 18, 2021 at 2:32 AM Joachim Breitner <mail at joachim-breitner.de <mailto:mail at joachim-breitner.de>> wrote:
>>> 
>>> Dear Committee,
>>> 
>>> another status update, because why not.
>>> 
>>> A small reminder: These mails have two sections, one that’s a delta
>>> since last status, but below is a summary of all proposals we have to
>>> act on. Please at least scroll through that on each status mail to see
>>> if you are listed, maybe you forgot something (or I made a mistake).
>>> 
>>> So here’s the delta since last month.
>>> 
>>>  * GHC2021 defined! Yay!
>>> 
>>>  * Bylaws merged! Yay
>>> 
>>>  * Simon², Iavor, Richard and me had thus their terms expired.
>>> 
>>>    The Simons, as key members, wanted to continue and were
>>>    voted back in.
>>> 
>>>    The others are now “expiring”, until the next nomination round
>>>    concludes. Alejandro is going to run that process.
>>> 
>>>  * we were asked to review these proposals:
>>>    #390: Fine-grained pragmas, Shepherd: Vitaly
>>> 
>>>  * we have a recommendation from the shepherd about:
>>>    #368: Warn on prefix/suffix operators (accept)
>>> 
>>>  * we have sent the following proposals back to revision
>>>    - none -
>>> 
>>>  * we decided about the following proposals
>>>    #313: Delimited continuation primops (accept)
>>>    #387: The Char kind (accept)
>>>    #368: Warn on prefix/suffix operators (accept)
>>> 
>>> We currently have to act on the following 5 proposals, down by 2.
>>> 
>>> ## Waiting for committee decision
>>> 
>>> #381: Visible 'forall' in types of terms, Shepherd: Iavor
>>>       Recommendation was to reject, but discussion went into the more 
>>>       abstract “whither dependent Haskell”. But what does this mean
>>>       for this proposal?
>>>       Iavor, can you pick this up again?
>>> 
>>> #369: Add sumToTag# primop, Shepherd: Eric
>>>       Essentially accepted, waiting for feedback from the author on
>>>       final tweaks. Eric, care to nudge the author, or just do it?
>>> 
>>> #302: \of, Shepherd: Cale
>>>       No new discussion yet. It seems there was some confusion, which
>>>       was cleared up by Tom, and Cale said he’ll pick it up now again.
>>> 
>>> 
>>> ## Waiting for Shepherd action
>>> 
>>> #367: Clarify primops using unboxed sums, Shepherd: Simon Marlow
>>>       Simon said he’d reject it on the Github PR. Still waiting
>>>       for the discussion to start on the mailing list.
>>> 
>>> #390: Fine-grained pragmas, Shepherd: Vitaly
>>>       Still kinda new, but a recommendation would be good soon.
>>> 
>>> 
>>> Cheers,
>>> Joachim
>>> -- 
>>> Joachim Breitner
>>>   mail at joachim-breitner.de <mailto:mail at joachim-breitner.de>
>>>   http://www.joachim-breitner.de/ <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.joachim-breitner.de%2F&data=04%7C01%7Csimonpj%40microsoft.com%7C0b9f9dd78f934d620c5e08d8e0c0012f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637506462581507230%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=gsdKkpp3AhJz2ins9uuctT%2FGf6rr2bScSHFWyX3jFhM%3D&reserved=0>
>>> 
>>> 
>>> _______________________________________________
>>> ghc-steering-committee mailing list
>>> ghc-steering-committee at haskell.org <mailto:ghc-steering-committee at haskell.org>
>>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committee&data=04%7C01%7Csimonpj%40microsoft.com%7C0b9f9dd78f934d620c5e08d8e0c0012f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637506462581517226%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=BY04FgtL9RHpjI6frr%2BOYfxwPkW5yjN2DeRyv2JaKN4%3D&reserved=0>_______________________________________________
>>> ghc-steering-committee mailing list
>>> ghc-steering-committee at haskell.org <mailto:ghc-steering-committee at haskell.org>
>>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee <https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee>
>> _______________________________________________
>> ghc-steering-committee mailing list
>> ghc-steering-committee at haskell.org <mailto:ghc-steering-committee at haskell.org>
>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee <https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee>
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20210309/ea212769/attachment-0001.html>

From iavor.diatchki at gmail.com  Tue Mar  9 20:34:13 2021
From: iavor.diatchki at gmail.com (Iavor Diatchki)
Date: Tue, 9 Mar 2021 12:34:13 -0800
Subject: [ghc-steering-committee] Status
In-Reply-To: <010f017818a7b729-6829598e-1009-4e18-b026-5571573691d8-000000@us-east-2.amazonses.com>
References: <7494e545ea1a9ce59053e0d685c81299922ed62b.camel@joachim-breitner.de>
 <CAGK9nupGZE1Ncdwfz3HXbtrxqvzSeV1zJ9b18BVHHio8Xu32jQ@mail.gmail.com>
 <VI1PR83MB0222389754916F1F2E3155ECAD859@VI1PR83MB0222.EURPRD83.prod.outlook.com>
 <CAGK9nupTPOX66xMiB9VjbjpQvkb7_sDrNnbrZb=AJgtDs1XGuA@mail.gmail.com>
 <AM0PR83MB02761C192D1210B90023E12EAD969@AM0PR83MB0276.EURPRD83.prod.outlook.com>
 <CAGK9nuoMm7=jq0K=mtgrjdftGXzbmPgNrupuiBz7cPA=uYcy_Q@mail.gmail.com>
 <CAGK9nuoo33s3b49rpu9SEcNtD=f=mJX=K=YSzRR9FqH7AeEzQA@mail.gmail.com>
 <AM0PR83MB0276F9B335ECF11A18131FC8AD939@AM0PR83MB0276.EURPRD83.prod.outlook.com>
 <010f0178154511dc-58479ea3-989e-4866-a94f-6f6a9eeec3ad-000000@us-east-2.amazonses.com>
 <CAGK9nup52iaxt6fMwRpn2-xXgsWwWeFMcJ2BMuXBgbNUqo35Mg@mail.gmail.com>
 <CAH6fHQkY0sy6gaYJRtgepQE5TjQOy=MZUB04HhoQZvbMb6utiw@mail.gmail.com>
 <010f0178187b1d51-bb9ea7e1-7125-4611-b5df-1f819d38a1b3-000000@us-east-2.amazonses.com>
 <CAGK9nup6u06pcqkjjMJptLNaAuAUmRkbMdb3ynjN-bUyGR9G3Q@mail.gmail.com>
 <010f017818a7b729-6829598e-1009-4e18-b026-5571573691d8-000000@us-east-2.amazonses.com>
Message-ID: <CAGK9nupyZ1RWhyOfyW7iLwLgxh=eGOXmjXoizQextPn91UZDJg@mail.gmail.com>

On Tue, Mar 9, 2021 at 12:22 PM Richard Eisenberg <rae at richarde.dev> wrote:

>
>
> On Mar 9, 2021, at 3:12 PM, Iavor Diatchki <iavor.diatchki at gmail.com>
> wrote:
>
> I still don't see what `sizeOf Bool` has to do with dependent
> types---there does not appear to be a semantic difference between
> `sizeOf @Bool` and `sizeOf Bool`, rather it is just a notational
> difference.
>
>
> Yes -- it's exactly the notational difference that's at issue. It's all a
> question of whether we want to require users to write @ before a required
> dependent (or type-level) argument. That really is it, but a good choice on
> this narrow (for me) hinges on whether or not we are working toward a
> future with dependent types.
>

For what it's worth I find `sizeOf @Bool` considerably more readable than
`sizeOf Bool`.




>  I am really missing the vision of where folks are picturing us ending up
> with all these changes.   Is the thinking that anyone who wants to use the
> FFI should have to enable dependent types?
>
>
> No. It's possible they would need no extensions at all. If there is no
> data constructor in scope named Bool, then sizeOf Bool might be accepted
> without any extensions on, I think. We often require an extension only at
> the definition site, not at usage sites.
>
> Does this help?
>
>
Well, it sounds like you are saying that to use FFI one would have to buy
into DH design.  My concern is not about what pragmas the users have to
write---after all we could make them write no pragams whatsoever.  It is
about what users would have to understand. For example, why does it matter
that there is no data constructor `Bool` in scope?   I am passing a type to
`sizeOf`, why would GHC all of a sudden get confused between the type and
the value?




> On Tue, Mar 9, 2021 at 11:33 AM Richard Eisenberg <rae at richarde.dev>
> wrote:
>
>> I agree with Arnaud. The connection to dependent types is pretty
>> tangential, really: it's all about whether we have `sizeOf @Bool` or
>> `sizeOf Bool`. If we had no intention of dependent types, I'd probably
>> favor the former. But forward-compatibility with the design sketch for
>> dependent types (
>> https://gitlab.haskell.org/ghc/ghc/-/wikis/dependent-haskell) suggests
>> using the latter. The problem is that the latter choice is more challenging
>> to support, and indeed drives much of the complexity in the proposal.
>>
>> So, we are a bit stuck: do we favor the design that's easier to specify
>> and implement today? or do we favor the design that will mesh better
>> tomorrow (assuming tomorrow has dependent types)? Our answer to #378 will
>> inform this decision.
>>
>> Richard
>>
>> On Mar 9, 2021, at 3:02 AM, Spiwack, Arnaud <arnaud.spiwack at tweag.io>
>> wrote:
>>
>> Simon's suggestion sounds like the proper thing to do to me too.
>>
>> The connection between #281 and dependent types is a little superficial,
>> but it #281 mixes the type syntax and the term syntax a bit more (in fact,
>> most of the details in the proposal are about that). The ability to mix
>> types and terms some way or another is central to having more dependent
>> typing. So there is, at the very least, a need for synchronization between
>> the various corresponding proposals. Though, in fact, this visible forall
>> thing is part of the dependent type package that Richard has been working
>> towards. It does fit somewhat naturally in the big picture.
>>
>> On Tue, Mar 9, 2021 at 6:58 AM Iavor Diatchki <iavor.diatchki at gmail.com>
>> wrote:
>>
>>> I will wait a few more days to see if anyone else expresses an opinion,
>>> otherwise I'll do as Simon suggests.
>>>
>>> Could someone clarify what does #281 have to do with dependent types?
>>>  The example that was brought up, and I think is pretty reasonable, is
>>> `sizeOf` from the `Storbale` class:  I might want to write `sizeOf @Bool`.
>>> Is the plan to require that dependent types are enabled to write stuff like
>>> that?
>>>
>>> -Iavor
>>>
>>>
>>>
>>> On Mon, Mar 8, 2021 at 8:35 PM Richard Eisenberg <rae at richarde.dev>
>>> wrote:
>>>
>>>> I have now submitted #378 for a committee decision (though I will
>>>> forgive Joachim if he missed the notification among the 200 comments on
>>>> that thread). So perhaps we can tackle all of this together.
>>>>
>>>> Richard
>>>>
>>>> On Mar 8, 2021, at 8:54 AM, Simon Peyton Jones via
>>>> ghc-steering-committee <ghc-steering-committee at haskell.org> wrote:
>>>>
>>>> I don't think this proposal is the right place to discuss dependent
>>>> types, so I propose that we reject the proposal.  To ensure progress, I'll
>>>> do so within a week, so please discuss before then, if you think otherwise.
>>>>
>>>> I would suggest that rather than “reject” (which sounds like “we don’t
>>>> want this, don’t resubmit it”), we push it back saying that we agree that
>>>> it’d be better to settle #378 first.  So we we’ll mark it as “needs
>>>> revision” not because we have anything specific to suggest, but so that
>>>> it’s back in the author’s control.  He should feel free to re-submit
>>>> (perhaps revised in some way, as he sees fit) once #378 is resolved.
>>>>
>>>> Simon
>>>>
>>>> *From:* Iavor Diatchki <iavor.diatchki at gmail.com>
>>>> *Sent:* 06 March 2021 16:51
>>>> *To:* Simon Peyton Jones <simonpj at microsoft.com>
>>>> *Cc:* Joachim Breitner <mail at joachim-breitner.de>;
>>>> ghc-steering-committee <ghc-steering-committee at haskell.org>
>>>> *Subject:* Re: [ghc-steering-committee] Status
>>>>
>>>>
>>>> Hello,
>>>>
>>>>
>>>>
>>>> This is the author's response to my query:
>>>>
>>>>
>>>>
>>>> So, the situation seems to be as follows:
>>>>
>>>>    - if we want dependent types (as described on that Wiki page), I
>>>>    would like to resubmit
>>>>
>>>>
>>>>    - if we do not want them, I will retract the proposal and close it
>>>>
>>>> I need to know the committee’s stance on dependent types to proceed
>>>> here.
>>>>
>>>>
>>>> I don't think this proposal is the right place to discuss dependent
>>>> types, so I propose that we reject the proposal.  To ensure progress, I'll
>>>> do so within a week, so please discuss before then, if you think otherwise.
>>>>
>>>> -Iavor
>>>>
>>>>
>>>>
>>>> On Fri, Mar 5, 2021 at 5:02 PM Iavor Diatchki <iavor.diatchki at gmail.com>
>>>> wrote:
>>>>
>>>> OK, I posted a note on the git-hub, asking @int-index what he wants to
>>>> do.
>>>> In case anyone needs a refresher, this is the discussion we had when I
>>>> submitted this to the committee back in November:
>>>>
>>>>
>>>> https://mail.haskell.org/pipermail/ghc-steering-committee/2020-November/001859.html
>>>> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haskell.org%2Fpipermail%2Fghc-steering-committee%2F2020-November%2F001859.html&data=04%7C01%7Csimonpj%40microsoft.com%7C0b9f9dd78f934d620c5e08d8e0c0012f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637506462581487239%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=2inDHN90f7OQ9XIcd76l50Lwwp6axEUZVdea%2BoRFZzg%3D&reserved=0>
>>>>
>>>> another somewhat relevant discussion that followed was this:
>>>>
>>>> https://mail.haskell.org/pipermail/ghc-steering-committee/2020-November/001865.html
>>>> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haskell.org%2Fpipermail%2Fghc-steering-committee%2F2020-November%2F001865.html&data=04%7C01%7Csimonpj%40microsoft.com%7C0b9f9dd78f934d620c5e08d8e0c0012f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637506462581497234%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=k4jiWTo11nNFH6zHyw7oYMFfyl0kxkQEsXKSueeC2Mk%3D&reserved=0>
>>>>
>>>> and here is a link to the proposal and the git-hub discussion:
>>>> https://github.com/ghc-proposals/ghc-proposals/pull/281
>>>> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%2Fpull%2F281&data=04%7C01%7Csimonpj%40microsoft.com%7C0b9f9dd78f934d620c5e08d8e0c0012f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637506462581497234%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=X7tkk61XrEd9utRxcQjA3Eh3Wi3cDXuJdMae%2BBcx3gM%3D&reserved=0>
>>>>
>>>> -Iavor
>>>>
>>>>
>>>>
>>>> On Fri, Mar 5, 2021 at 3:13 PM Simon Peyton Jones <
>>>> simonpj at microsoft.com> wrote:
>>>>
>>>> This is about #281 visible dependent quantification.
>>>>
>>>> Our role is to accept, reject, or push back to the author for
>>>> revision.  We should do so in a timely way.
>>>>
>>>> If I were the shepherd I’d be asking the author “Do you want to revise
>>>> the proposal at all in the light of all the discussion, or do you want the
>>>> committee to decide yay/nay based on the proposal as it is now?”
>>>>
>>>> He might want to revise/discuss a bit.  But if he says “please decide
>>>> on it as-is” then I think you should make a recommendation: accept or
>>>> reject.  (I don’t think the discussion has led to any specific revisions
>>>> that we want to see.)
>>>>
>>>> I sense you would recommend reject.   That’s totally fine. Then the
>>>> rest of us have to make up our minds.  We might end up with a more nuanced
>>>> position like “we are not ready to accept this now, so if you want a
>>>> decision now, it’d be no; but feel free to ask the same question again in
>>>> six months time”.
>>>>
>>>> If you don’t feel able to be the shepherd, that’s fine too: tell
>>>> Joachim and he’ll finger someone else!
>>>>
>>>> But, by hook or by crook, I do think we should do something, not just
>>>> sit on it.  Tom’s nudge is helpful.
>>>>
>>>> Simon
>>>>
>>>> *From:* Iavor Diatchki <iavor.diatchki at gmail.com>
>>>> *Sent:* 05 March 2021 19:42
>>>> *To:* Simon Peyton Jones <simonpj at microsoft.com>
>>>> *Cc:* Joachim Breitner <mail at joachim-breitner.de>;
>>>> ghc-steering-committee <ghc-steering-committee at haskell.org>
>>>> *Subject:* Re: [ghc-steering-committee] Status
>>>>
>>>>
>>>> I am being nudged to do something with this proposal,  but I am not
>>>> sure what...   Is the rest of the committee OK with moving it back
>>>> "revisions required", and if so what revisions would we like?
>>>>
>>>>
>>>>
>>>> I would be quite happy if someone else wanted to shephard this.  As I
>>>> mentioned before, I don't have much interest in DH, so I have not followed
>>>> the really long discussion related to that, and if and how it might relate
>>>> to #281.
>>>>
>>>>
>>>>
>>>> My recommendation for the moment would be:
>>>>
>>>>    * This seems like a useful feature independent of DH, so it would be
>>>> nice to come up with a concise notation to use the feature on its own,
>>>> without worrying about DH.
>>>>
>>>>
>>>>
>>>> Please let me know what you think, as I am not sure what is the
>>>> committee's stance on the proposal.
>>>>
>>>>
>>>>
>>>> -Iavor
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On Thu, Feb 18, 2021 at 1:54 PM Simon Peyton Jones <
>>>> simonpj at microsoft.com> wrote:
>>>>
>>>> There has been a broad further discussion.
>>>> What we advertise is that, rather that leave a proposal “under
>>>> committee review”, we will push it back to the author with an invitation to
>>>> resubmit when the discussion has died down and they feel ready to submit a
>>>> proposal, revised in the light of the discussion.  That’s different to
>>>> reject… it means that there is an ongoing debate so it’s not a good time
>>>> for the committee to make a decision.
>>>>
>>>> Simon
>>>>
>>>> *From:* ghc-steering-committee <
>>>> ghc-steering-committee-bounces at haskell.org> *On Behalf Of *Iavor
>>>> Diatchki
>>>> *Sent:* 18 February 2021 16:47
>>>> *To:* Joachim Breitner <mail at joachim-breitner.de>
>>>> *Cc:* ghc-steering-committee <ghc-steering-committee at haskell.org>
>>>> *Subject:* Re: [ghc-steering-committee] Status
>>>>
>>>>
>>>> On #381 I think the idea of visible quantification makes sense every
>>>> now and then, but I don't like the concrete details of the proposal: the
>>>> magic lifting of terms to types seems quite complicated, and using `type`
>>>> as an explicit herald doesn't look nice.  So I don't think it's the right
>>>> design, and therefore I suggest we reject the proposal.
>>>>
>>>>
>>>>
>>>> I am sure that others would disagree as apparently this is an essential
>>>> part of dependent Haskell.   I have not followed the large discussion that
>>>> Richard created, as I am not particularly interested in the design being
>>>> proposed, so perhaps someone else should champion this.
>>>>
>>>>
>>>>
>>>> Aslo, I am not sure if I am actually on the committee, as I thought my
>>>> term had expired?  That might be more reason for someone else to pick it up.
>>>>
>>>>
>>>>
>>>> -Iavor
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On Thu, Feb 18, 2021 at 2:32 AM Joachim Breitner <
>>>> mail at joachim-breitner.de> wrote:
>>>>
>>>> Dear Committee,
>>>>
>>>> another status update, because why not.
>>>>
>>>> A small reminder: These mails have two sections, one that’s a delta
>>>> since last status, but below is a summary of all proposals we have to
>>>> act on. Please at least scroll through that on each status mail to see
>>>> if you are listed, maybe you forgot something (or I made a mistake).
>>>>
>>>> So here’s the delta since last month.
>>>>
>>>>  * GHC2021 defined! Yay!
>>>>
>>>>  * Bylaws merged! Yay
>>>>
>>>>  * Simon², Iavor, Richard and me had thus their terms expired.
>>>>
>>>>    The Simons, as key members, wanted to continue and were
>>>>    voted back in.
>>>>
>>>>    The others are now “expiring”, until the next nomination round
>>>>    concludes. Alejandro is going to run that process.
>>>>
>>>>  * we were asked to review these proposals:
>>>>    #390: Fine-grained pragmas, Shepherd: Vitaly
>>>>
>>>>  * we have a recommendation from the shepherd about:
>>>>    #368: Warn on prefix/suffix operators (accept)
>>>>
>>>>  * we have sent the following proposals back to revision
>>>>    - none -
>>>>
>>>>  * we decided about the following proposals
>>>>    #313: Delimited continuation primops (accept)
>>>>    #387: The Char kind (accept)
>>>>    #368: Warn on prefix/suffix operators (accept)
>>>>
>>>> We currently have to act on the following 5 proposals, down by 2.
>>>>
>>>> ## Waiting for committee decision
>>>>
>>>> #381: Visible 'forall' in types of terms, Shepherd: Iavor
>>>>       Recommendation was to reject, but discussion went into the more
>>>>       abstract “whither dependent Haskell”. But what does this mean
>>>>       for this proposal?
>>>>       Iavor, can you pick this up again?
>>>>
>>>> #369: Add sumToTag# primop, Shepherd: Eric
>>>>       Essentially accepted, waiting for feedback from the author on
>>>>       final tweaks. Eric, care to nudge the author, or just do it?
>>>>
>>>> #302: \of, Shepherd: Cale
>>>>       No new discussion yet. It seems there was some confusion, which
>>>>       was cleared up by Tom, and Cale said he’ll pick it up now again.
>>>>
>>>>
>>>> ## Waiting for Shepherd action
>>>>
>>>> #367: Clarify primops using unboxed sums, Shepherd: Simon Marlow
>>>>       Simon said he’d reject it on the Github PR. Still waiting
>>>>       for the discussion to start on the mailing list.
>>>>
>>>> #390: Fine-grained pragmas, Shepherd: Vitaly
>>>>       Still kinda new, but a recommendation would be good soon.
>>>>
>>>>
>>>> Cheers,
>>>> Joachim
>>>> --
>>>> Joachim Breitner
>>>>   mail at joachim-breitner.de
>>>>   http://www.joachim-breitner.de/
>>>> <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.joachim-breitner.de%2F&data=04%7C01%7Csimonpj%40microsoft.com%7C0b9f9dd78f934d620c5e08d8e0c0012f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637506462581507230%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=gsdKkpp3AhJz2ins9uuctT%2FGf6rr2bScSHFWyX3jFhM%3D&reserved=0>
>>>>
>>>>
>>>> _______________________________________________
>>>> ghc-steering-committee mailing list
>>>> ghc-steering-committee at haskell.org
>>>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>>> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committee&data=04%7C01%7Csimonpj%40microsoft.com%7C0b9f9dd78f934d620c5e08d8e0c0012f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637506462581517226%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=BY04FgtL9RHpjI6frr%2BOYfxwPkW5yjN2DeRyv2JaKN4%3D&reserved=0>
>>>>
>>>> _______________________________________________
>>>> ghc-steering-committee mailing list
>>>> ghc-steering-committee at haskell.org
>>>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>>>
>>>>
>>>> _______________________________________________
>>> ghc-steering-committee mailing list
>>> ghc-steering-committee at haskell.org
>>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20210309/a97c71f5/attachment-0001.html>

From rae at richarde.dev  Wed Mar 10 04:11:43 2021
From: rae at richarde.dev (Richard Eisenberg)
Date: Wed, 10 Mar 2021 04:11:43 +0000
Subject: [ghc-steering-committee] Status
In-Reply-To: <CAGK9nupyZ1RWhyOfyW7iLwLgxh=eGOXmjXoizQextPn91UZDJg@mail.gmail.com>
References: <7494e545ea1a9ce59053e0d685c81299922ed62b.camel@joachim-breitner.de>
 <CAGK9nupGZE1Ncdwfz3HXbtrxqvzSeV1zJ9b18BVHHio8Xu32jQ@mail.gmail.com>
 <VI1PR83MB0222389754916F1F2E3155ECAD859@VI1PR83MB0222.EURPRD83.prod.outlook.com>
 <CAGK9nupTPOX66xMiB9VjbjpQvkb7_sDrNnbrZb=AJgtDs1XGuA@mail.gmail.com>
 <AM0PR83MB02761C192D1210B90023E12EAD969@AM0PR83MB0276.EURPRD83.prod.outlook.com>
 <CAGK9nuoMm7=jq0K=mtgrjdftGXzbmPgNrupuiBz7cPA=uYcy_Q@mail.gmail.com>
 <CAGK9nuoo33s3b49rpu9SEcNtD=f=mJX=K=YSzRR9FqH7AeEzQA@mail.gmail.com>
 <AM0PR83MB0276F9B335ECF11A18131FC8AD939@AM0PR83MB0276.EURPRD83.prod.outlook.com>
 <010f0178154511dc-58479ea3-989e-4866-a94f-6f6a9eeec3ad-000000@us-east-2.amazonses.com>
 <CAGK9nup52iaxt6fMwRpn2-xXgsWwWeFMcJ2BMuXBgbNUqo35Mg@mail.gmail.com>
 <CAH6fHQkY0sy6gaYJRtgepQE5TjQOy=MZUB04HhoQZvbMb6utiw@mail.gmail.com>
 <010f0178187b1d51-bb9ea7e1-7125-4611-b5df-1f819d38a1b3-000000@us-east-2.amazonses.com>
 <CAGK9nup6u06pcqkjjMJptLNaAuAUmRkbMdb3ynjN-bUyGR9G3Q@mail.gmail.com>
 <010f017818a7b729-6829598e-1009-4e18-b026-5571573691d8-000000@us-east-2.amazonses.com>
 <CAGK9nupyZ1RWhyOfyW7iLwLgxh=eGOXmjXoizQextPn91UZDJg@mail.gmail.com>
Message-ID: <010f01781a5554d3-90a1932b-a802-4d49-95a6-c9a9b00d2eee-000000@us-east-2.amazonses.com>



> On Mar 9, 2021, at 3:34 PM, Iavor Diatchki <iavor.diatchki at gmail.com> wrote:
> 
> Well, it sounds like you are saying that to use FFI one would have to buy into DH design.  My concern is not about what pragmas the users have to write---after all we could make them write no pragams whatsoever.  It is about what users would have to understand. For example, why does it matter that there is no data constructor `Bool` in scope?   I am passing a type to `sizeOf`, why would GHC all of a sudden get confused between the type and the value?

Just as much as users of arithmetic have to buy into a design using type-classes. That is, we're aiming to design a cohesive language, and that means that someone trying to understand the design of the language (i.e. our FFI user) will have to consider it holistically.

As for confusion between types and values: this is the heart of the matter. I agree that, taking #281 alone, it would make more sense to say sizeOf @Bool. But in the context of a design that might support dependent types, it makes more sense to say sizeOf Bool, and have name lookup try both namespaces (the data constructor namespace first, followed by the type namespace). This is why I wrote #378, so that we could decide which design is better for #281.

Richard
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20210310/5c2b71cf/attachment.html>

From iavor.diatchki at gmail.com  Wed Mar 10 17:04:56 2021
From: iavor.diatchki at gmail.com (Iavor Diatchki)
Date: Wed, 10 Mar 2021 09:04:56 -0800
Subject: [ghc-steering-committee] Status
In-Reply-To: <010f01781a5554d3-90a1932b-a802-4d49-95a6-c9a9b00d2eee-000000@us-east-2.amazonses.com>
References: <7494e545ea1a9ce59053e0d685c81299922ed62b.camel@joachim-breitner.de>
 <CAGK9nupGZE1Ncdwfz3HXbtrxqvzSeV1zJ9b18BVHHio8Xu32jQ@mail.gmail.com>
 <VI1PR83MB0222389754916F1F2E3155ECAD859@VI1PR83MB0222.EURPRD83.prod.outlook.com>
 <CAGK9nupTPOX66xMiB9VjbjpQvkb7_sDrNnbrZb=AJgtDs1XGuA@mail.gmail.com>
 <AM0PR83MB02761C192D1210B90023E12EAD969@AM0PR83MB0276.EURPRD83.prod.outlook.com>
 <CAGK9nuoMm7=jq0K=mtgrjdftGXzbmPgNrupuiBz7cPA=uYcy_Q@mail.gmail.com>
 <CAGK9nuoo33s3b49rpu9SEcNtD=f=mJX=K=YSzRR9FqH7AeEzQA@mail.gmail.com>
 <AM0PR83MB0276F9B335ECF11A18131FC8AD939@AM0PR83MB0276.EURPRD83.prod.outlook.com>
 <010f0178154511dc-58479ea3-989e-4866-a94f-6f6a9eeec3ad-000000@us-east-2.amazonses.com>
 <CAGK9nup52iaxt6fMwRpn2-xXgsWwWeFMcJ2BMuXBgbNUqo35Mg@mail.gmail.com>
 <CAH6fHQkY0sy6gaYJRtgepQE5TjQOy=MZUB04HhoQZvbMb6utiw@mail.gmail.com>
 <010f0178187b1d51-bb9ea7e1-7125-4611-b5df-1f819d38a1b3-000000@us-east-2.amazonses.com>
 <CAGK9nup6u06pcqkjjMJptLNaAuAUmRkbMdb3ynjN-bUyGR9G3Q@mail.gmail.com>
 <010f017818a7b729-6829598e-1009-4e18-b026-5571573691d8-000000@us-east-2.amazonses.com>
 <CAGK9nupyZ1RWhyOfyW7iLwLgxh=eGOXmjXoizQextPn91UZDJg@mail.gmail.com>
 <010f01781a5554d3-90a1932b-a802-4d49-95a6-c9a9b00d2eee-000000@us-east-2.amazonses.com>
Message-ID: <CAGK9nupLy+g137TxD=0uGGk3f+=_q=E0VmJhTb+5qpohEymtvg@mail.gmail.com>

On Tue, Mar 9, 2021 at 8:11 PM Richard Eisenberg <rae at richarde.dev> wrote:

>
>
> On Mar 9, 2021, at 3:34 PM, Iavor Diatchki <iavor.diatchki at gmail.com>
> wrote:
>
> Well, it sounds like you are saying that to use FFI one would have to buy
> into DH design.  My concern is not about what pragmas the users have to
> write---after all we could make them write no pragams whatsoever.  It is
> about what users would have to understand. For example, why does it matter
> that there is no data constructor `Bool` in scope?   I am passing a type to
> `sizeOf`, why would GHC all of a sudden get confused between the type and
> the value?
>
>
> Just as much as users of arithmetic have to buy into a design using
> type-classes. That is, we're aiming to design a cohesive language, and that
> means that someone trying to understand the design of the language (i.e.
> our FFI user) will have to consider it holistically.
>

I don't see how type-classes are related to the current point. Yes, we want
to consider a cohesive language design, but this doesn't mean that
everything has to depend on everything.  The nice benefit of the extension
system is that it allows us to experiment with language changes modularly.
As I see it, here we have a choice between:
   A. a modular opt-int design that is close to what is already used by a
lot of a projects (i.e., something like `sizeOf @Bool`), and
   B. an alternative design (i..e, `sizeOf Bool`) that depends on an
unrelated feature (dependent types), that we have zero experience with, and
require major changes to how something as basic as name resolution works.

It sounds like #378 is asking us to always make choice B.   I think a
better plan is to prefer option A, as we have been for a long time now.  I
don't think that precludes the work on dependent types in any way
(ergonomic or not, whatever that means).  Once that work is done, it might
subsume some existing extensions, and folks would have a choice to write
things one way or another depending on their needs.  I expect in the long
run, one of the designs might become the common way to do stuff, and
eventually we might depreciate some of the extensions that are not used any
more.     To me, this seems to be the right way to grow a living language
like Haskell.


As for confusion between types and values: this is the heart of the matter.
> I agree that, taking #281 alone, it would make more sense to say sizeOf
> @Bool. But in the context of a design that might support dependent types,
> it makes more sense to say sizeOf Bool, and have name lookup try both
> namespaces (the data constructor namespace first, followed by the type
> namespace). This is why I wrote #378, so that we could decide which design
> is better for #281.
>

I don't see how `sizeOf Bool` makes more sense than `sizeOf @Bool` in a
language with dependent types, this seems purely a matter of taste.  As I
mentioned before, I find `sizeOf @Bool` more readable than `sizeOf Bool`
exactly because I don't need to keep in my head yet another thing (i.e.,
which `Bool` are we talking about here).  By the way, in case the `Bool`
example seems absurd, using `newtype`s is quite common when doing FFI
bindings, and the normal pattern there is to use the same name for the
value and type constructor, so this is something that we should not gloss
over lightly.

-Iavor
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20210310/c0cc4ce1/attachment.html>

From rae at richarde.dev  Wed Mar 10 18:07:47 2021
From: rae at richarde.dev (Richard Eisenberg)
Date: Wed, 10 Mar 2021 18:07:47 +0000
Subject: [ghc-steering-committee] Status
In-Reply-To: <CAGK9nupLy+g137TxD=0uGGk3f+=_q=E0VmJhTb+5qpohEymtvg@mail.gmail.com>
References: <7494e545ea1a9ce59053e0d685c81299922ed62b.camel@joachim-breitner.de>
 <CAGK9nupGZE1Ncdwfz3HXbtrxqvzSeV1zJ9b18BVHHio8Xu32jQ@mail.gmail.com>
 <VI1PR83MB0222389754916F1F2E3155ECAD859@VI1PR83MB0222.EURPRD83.prod.outlook.com>
 <CAGK9nupTPOX66xMiB9VjbjpQvkb7_sDrNnbrZb=AJgtDs1XGuA@mail.gmail.com>
 <AM0PR83MB02761C192D1210B90023E12EAD969@AM0PR83MB0276.EURPRD83.prod.outlook.com>
 <CAGK9nuoMm7=jq0K=mtgrjdftGXzbmPgNrupuiBz7cPA=uYcy_Q@mail.gmail.com>
 <CAGK9nuoo33s3b49rpu9SEcNtD=f=mJX=K=YSzRR9FqH7AeEzQA@mail.gmail.com>
 <AM0PR83MB0276F9B335ECF11A18131FC8AD939@AM0PR83MB0276.EURPRD83.prod.outlook.com>
 <010f0178154511dc-58479ea3-989e-4866-a94f-6f6a9eeec3ad-000000@us-east-2.amazonses.com>
 <CAGK9nup52iaxt6fMwRpn2-xXgsWwWeFMcJ2BMuXBgbNUqo35Mg@mail.gmail.com>
 <CAH6fHQkY0sy6gaYJRtgepQE5TjQOy=MZUB04HhoQZvbMb6utiw@mail.gmail.com>
 <010f0178187b1d51-bb9ea7e1-7125-4611-b5df-1f819d38a1b3-000000@us-east-2.amazonses.com>
 <CAGK9nup6u06pcqkjjMJptLNaAuAUmRkbMdb3ynjN-bUyGR9G3Q@mail.gmail.com>
 <010f017818a7b729-6829598e-1009-4e18-b026-5571573691d8-000000@us-east-2.amazonses.com>
 <CAGK9nupyZ1RWhyOfyW7iLwLgxh=eGOXmjXoizQextPn91UZDJg@mail.gmail.com>
 <010f01781a5554d3-90a1932b-a802-4d49-95a6-c9a9b00d2eee-000000@us-east-2.amazonses.com>
 <CAGK9nupLy+g137TxD=0uGGk3f+=_q=E0VmJhTb+5qpohEymtvg@mail.gmail.com>
Message-ID: <010f01781d52c84b-d732eff0-d503-4105-b7f6-7afb03cbe28d-000000@us-east-2.amazonses.com>



> On Mar 10, 2021, at 12:04 PM, Iavor Diatchki <iavor.diatchki at gmail.com> wrote:
> 
>  Yes, we want to consider a cohesive language design, but this doesn't mean that everything has to depend on everything.  The nice benefit of the extension system is that it allows us to experiment with language changes modularly.  As I see it, here we have a choice between:
>    A. a modular opt-int design that is close to what is already used by a lot of a projects (i.e., something like `sizeOf @Bool`), and
>    B. an alternative design (i..e, `sizeOf Bool`) that depends on an unrelated feature (dependent types), that we have zero experience with, and require major changes to how something as basic as name resolution works.
> 
> It sounds like #378 is asking us to always make choice B.

Ideally, we wouldn't have to choose between these. In other proposals, we have worked hard to find a design that meets both your A and B. (These are essentially the same as the (1) and (2) from https://github.com/goldfirere/ghc-proposals/blob/dependent-types/proposals/0000-dependent-type-design.rst#motivation-for-why-we-need-this-proposal -- glad we agree on this starting point.) The problem is that we don't seem to have a design for #281 that satisfies both A and B. Proposal #378 essentially says that, when considering the Haskell language and how a new feature fits in, we consider the language sketched in https://gitlab.haskell.org/ghc/ghc/-/wikis/dependent-haskell, in addition to all the features in today's Haskell.

>    I think a better plan is to prefer option A, as we have been for a long time now.  I don't think that precludes the work on dependent types in any way (ergonomic or not, whatever that means).

I disagree here. A critical part of the design for dependent types is the Syntactic Unification Principle from the wiki page:

> Syntactic Unification Principle (SUP). In the absence of punning, there is no difference between type-syntax and term-syntax.

The idea here is that programmers should not have to worry about whether a piece of syntax is a type or a term. Indeed, my hope is that programmers simply stop making this distinction, as I don't think it is a helpful one -- indeed, I've discovered I don't even really know what that distinction means in a dependently-typed language. (A difference between *compile-time* information and *runtime* information is critical and an important pillar of the design of dependent types.)

Requiring a programmer to put an @ before some arguments but not others would be very strange in such a world. It violates the SUP.

>   Once that work is done, it might subsume some existing extensions, and folks would have a choice to write things one way or another depending on their needs.  I expect in the long run, one of the designs might become the common way to do stuff, and eventually we might depreciate some of the extensions that are not used any more.     To me, this seems to be the right way to grow a living language like Haskell. 

This is a plausible way forward, yes. But it will require a breaking change to the language, one we can avoid with a little forward planning now.
> 
>  As I mentioned before, I find `sizeOf @Bool` more readable than `sizeOf Bool` exactly because I don't need to keep in my head yet another thing (i.e., which `Bool` are we talking about here).

Yes -- exactly! I also don't want to keep another thing in my head: whether the argument to sizeOf is in term-syntax or type-syntax.

>   By the way, in case the `Bool` example seems absurd, using `newtype`s is quite common when doing FFI bindings, and the normal pattern there is to use the same name for the value and type constructor, so this is something that we should not gloss over lightly.

This is a good point. There are several ways forward:

* Users can always use `sizeOf (type Bool)` if they want to. This is documented in https://github.com/int-index/ghc-proposals/blob/visible-forall/proposals/0000-visible-forall.rst#43secondary-change-type-herald

* Nothing stops us from having sizeOf :: forall a. KnownSize a => Int; this would still work with sizeOf @Bool. We could have both sizeOf :: forall a -> KnownSize a => Int (which uses sizeOf Bool) and the other one, perhaps exported from different modules, and then users can choose which one they prefer.

* Users can make a type-level module alias using the syntax in #270. This would allow sizeOf T.Bool.

* Users can avoid punning by changing the names of their constructors.

These choices are all (except the last one) entirely local. Note that nothing anywhere here requires a change from the status quo, which is today's sizeOf.

Richard

From trupill at gmail.com  Wed Mar 10 20:09:08 2021
From: trupill at gmail.com (Alejandro Serrano Mena)
Date: Wed, 10 Mar 2021 15:09:08 -0500
Subject: [ghc-steering-committee] New (and old) members of the Committee
Message-ID: <CAHnFXOvy8XnjqCT41Y0mzuSx8QAGBn_qp0_Jhb-1dk=kEpEugg@mail.gmail.com>

Dear Committee,

It’s my pleasure that announce that the three members with an expired term
(Joachim, Iavor, and Richard) have renewed their membership. In addition,
we have a new member in the Committee: Vladislav Zavialov. We found all
four applications to be really strong!

Could anybody help me adding Vladislav to the mailing list and giving him
the proper permissions? That way I could give him a proper welcome to the
Committee :)

Alejandro
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20210310/be89a01b/attachment.html>

From rae at richarde.dev  Wed Mar 10 20:42:17 2021
From: rae at richarde.dev (Richard Eisenberg)
Date: Wed, 10 Mar 2021 20:42:17 +0000
Subject: [ghc-steering-committee] New (and old) members of the Committee
In-Reply-To: <CAHnFXOvy8XnjqCT41Y0mzuSx8QAGBn_qp0_Jhb-1dk=kEpEugg@mail.gmail.com>
References: <CAHnFXOvy8XnjqCT41Y0mzuSx8QAGBn_qp0_Jhb-1dk=kEpEugg@mail.gmail.com>
Message-ID: <010f01781de0389d-739778f8-f11d-4a92-9258-14bf90964f03-000000@us-east-2.amazonses.com>

Welcome, Vlad!

Vlad is already on this list (according to the list of subscribers). He will need GitHub permissions, but it looks like Joachim is the one with the right permissions to do that.

Sidenote: Joachim, perhaps you should also grant maintainer access to the ghc-proposals team (https://github.com/orgs/ghc-proposals/teams/ghc-steering-committee/members) to the Simons, in case action needs to be taken while you're unavailable.

Thanks for steering this process, Alejandro!

Richard

> On Mar 10, 2021, at 3:09 PM, Alejandro Serrano Mena <trupill at gmail.com> wrote:
> 
> Dear Committee,
> 
> It’s my pleasure that announce that the three members with an expired term (Joachim, Iavor, and Richard) have renewed their membership. In addition, we have a new member in the Committee: Vladislav Zavialov. We found all four applications to be really strong!
> 
> Could anybody help me adding Vladislav to the mailing list and giving him the proper permissions? That way I could give him a proper welcome to the Committee :)
> 
> Alejandro
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee


From simonpj at microsoft.com  Wed Mar 10 22:31:22 2021
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Wed, 10 Mar 2021 22:31:22 +0000
Subject: [ghc-steering-committee] New (and old) members of the Committee
In-Reply-To: <CAHnFXOvy8XnjqCT41Y0mzuSx8QAGBn_qp0_Jhb-1dk=kEpEugg@mail.gmail.com>
References: <CAHnFXOvy8XnjqCT41Y0mzuSx8QAGBn_qp0_Jhb-1dk=kEpEugg@mail.gmail.com>
Message-ID: <AM0PR83MB02760CDA2D2937BDD43D8058AD919@AM0PR83MB0276.EURPRD83.prod.outlook.com>

Joachim

Welcome back!   Are you willing to continue to act as our secretary?   You do it so well, and I was worrying a bit about what we’d do if you stepped down 😊.

Simon

From: ghc-steering-committee <ghc-steering-committee-bounces at haskell.org> On Behalf Of Alejandro Serrano Mena
Sent: 10 March 2021 20:09
To: Simon Peyton Jones via ghc-steering-committee <ghc-steering-committee at haskell.org>
Subject: [ghc-steering-committee] New (and old) members of the Committee

Dear Committee,

It’s my pleasure that announce that the three members with an expired term (Joachim, Iavor, and Richard) have renewed their membership. In addition, we have a new member in the Committee: Vladislav Zavialov. We found all four applications to be really strong!

Could anybody help me adding Vladislav to the mailing list and giving him the proper permissions? That way I could give him a proper welcome to the Committee :)

Alejandro
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20210310/c69df268/attachment.html>

From mail at joachim-breitner.de  Thu Mar 11 08:31:35 2021
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Thu, 11 Mar 2021 09:31:35 +0100
Subject: [ghc-steering-committee] New (and old) members of the Committee
In-Reply-To: <AM0PR83MB02760CDA2D2937BDD43D8058AD919@AM0PR83MB0276.EURPRD83.prod.outlook.com>
References: <CAHnFXOvy8XnjqCT41Y0mzuSx8QAGBn_qp0_Jhb-1dk=kEpEugg@mail.gmail.com>
 <AM0PR83MB02760CDA2D2937BDD43D8058AD919@AM0PR83MB0276.EURPRD83.prod.outlook.com>
Message-ID: <b44caada4fe980bbe40f5217b3ddf3a7a0c5d4bc.camel@joachim-breitner.de>

Hi Committee,

glad you all still like me (or at least a majority).

> Welcome back!   Are you willing to continue to act as our 
> secretary?   You do it so well, and I was worrying a bit about what 
> we’d do if you stepped down 😊.

Yes, I’m happy to carry on as usual.

Cheers,
Joachim

-- 
Joachim Breitner
  mail at joachim-breitner.de
  http://www.joachim-breitner.de/



From mail at joachim-breitner.de  Thu Mar 11 08:42:26 2021
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Thu, 11 Mar 2021 09:42:26 +0100
Subject: [ghc-steering-committee] New (and old) members of the Committee
In-Reply-To: <010f01781de0389d-739778f8-f11d-4a92-9258-14bf90964f03-000000@us-east-2.amazonses.com>
References: <CAHnFXOvy8XnjqCT41Y0mzuSx8QAGBn_qp0_Jhb-1dk=kEpEugg@mail.gmail.com>
 <010f01781de0389d-739778f8-f11d-4a92-9258-14bf90964f03-000000@us-east-2.amazonses.com>
Message-ID: <b2b3b8a07218d427c0bee16ef303bd220800e05a.camel@joachim-breitner.de>

Hi,

Welcome Vlad!

I updated
https://github.com/ghc-proposals/ghc-proposals#who-is-the-committee
to include Vlad, and note the renewed terms for Richard, Iavor and me.

We have now 12 members, so we are well-staffed now. This means that
although Vitaly and Eric’s terms will expire in September and Arnauds
in July next year, this does not trigger a round of nominations (and
they can continue to stick around), and the next round of nominations
will be in January 2023, when also Tom, Cale and Alejandro’s terms
expire. This is assuming there are no early downsteppings.

Am Mittwoch, den 10.03.2021, 20:42 +0000 schrieb Richard Eisenberg:
> He will need GitHub permissions, but it looks like Joachim is the one
> with the right permissions to do that.

Invited.

> Sidenote: Joachim, perh to the Simons, in case action needs to be
> taken while you're unavailable.

good idea, done


> Thanks for steering this process, Alejandro!

Agreed!


Cheers,
Joachim
-- 
Joachim Breitner
  mail at joachim-breitner.de
  http://www.joachim-breitner.de/



From trupill at gmail.com  Thu Mar 11 08:53:54 2021
From: trupill at gmail.com (Alejandro Serrano Mena)
Date: Thu, 11 Mar 2021 00:53:54 -0800
Subject: [ghc-steering-committee] New (and old) members of the Committee
In-Reply-To: <010f01781de0389d-739778f8-f11d-4a92-9258-14bf90964f03-000000@us-east-2.amazonses.com>
References: <CAHnFXOvy8XnjqCT41Y0mzuSx8QAGBn_qp0_Jhb-1dk=kEpEugg@mail.gmail.com>
 <010f01781de0389d-739778f8-f11d-4a92-9258-14bf90964f03-000000@us-east-2.amazonses.com>
Message-ID: <CAHnFXOt8VcbAJ7Xy5EnOQQEkE-YPENsMQSfpMN4SMd87PuJcMQ@mail.gmail.com>

Welcome, Vlad! I’m very happy to have you among us :)

Right now we are discussing a few proposals, feel free to jump into the
discussion (the archives should give you a rough idea). In particular, we
are debating lately about dependent types and the general meaning of
“extension”, which are topics which I think would benefit from a fresh pair
of eyes.

Regards,
Alejandro

On 10 Mar 2021 at 21:42:17, Richard Eisenberg <rae at richarde.dev> wrote:

> Welcome, Vlad!
>
> Vlad is already on this list (according to the list of subscribers). He
> will need GitHub permissions, but it looks like Joachim is the one with the
> right permissions to do that.
>
> Sidenote: Joachim, perhaps you should also grant maintainer access to the
> ghc-proposals team (
> https://github.com/orgs/ghc-proposals/teams/ghc-steering-committee/members)
> to the Simons, in case action needs to be taken while you're unavailable.
>
> Thanks for steering this process, Alejandro!
>
> Richard
>
> On Mar 10, 2021, at 3:09 PM, Alejandro Serrano Mena <trupill at gmail.com>
> wrote:
>
>
> Dear Committee,
>
>
> It’s my pleasure that announce that the three members with an expired term
> (Joachim, Iavor, and Richard) have renewed their membership. In addition,
> we have a new member in the Committee: Vladislav Zavialov. We found all
> four applications to be really strong!
>
>
> Could anybody help me adding Vladislav to the mailing list and giving him
> the proper permissions? That way I could give him a proper welcome to the
> Committee :)
>
>
> Alejandro
>
> _______________________________________________
>
> ghc-steering-committee mailing list
>
> ghc-steering-committee at haskell.org
>
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20210311/9cd8003d/attachment-0001.html>

From arnaud.spiwack at tweag.io  Thu Mar 11 09:46:06 2021
From: arnaud.spiwack at tweag.io (Spiwack, Arnaud)
Date: Thu, 11 Mar 2021 10:46:06 +0100
Subject: [ghc-steering-committee] #403: Cleanup lexical structure,
 recommendation: accept
In-Reply-To: <010f01781512e7a3-5bc80b24-389f-4a0b-9aac-b914fe503af0-000000@us-east-2.amazonses.com>
References: <CAH6fHQnGv72AF1PrxQhyDSNcgK0gwwaJzHYbhfc+hn44SD1+4w@mail.gmail.com>
 <VI1PR83MB02229E22E39517DA61FC0427AD969@VI1PR83MB0222.EURPRD83.prod.outlook.com>
 <CAHnFXOvDF_MYxjS-u0dvo+x9Fdg_rLcZom_hbXoEKmL-9_GyCg@mail.gmail.com>
 <CAGK9nupRPwc1hRx_AmGFujfXBUwX63Msph90nBYv8irdnBOy7A@mail.gmail.com>
 <010f01781512e7a3-5bc80b24-389f-4a0b-9aac-b914fe503af0-000000@us-east-2.amazonses.com>
Message-ID: <CAH6fHQnFWpoHouPYqXvuzUdpRrRdJH3KZqcWtNZ5xqRkSSMQrA@mail.gmail.com>

Dear all,

About half of us have opined, so far. If nobody complains, I'll treat
silence as assent and mark this proposal as accepted on Tuesday (16 March).

On Tue, Mar 9, 2021 at 4:41 AM Richard Eisenberg <rae at richarde.dev> wrote:

> I'm in support.
>
> Thanks,
> Richard
>
> On Mar 5, 2021, at 1:03 PM, Iavor Diatchki <iavor.diatchki at gmail.com>
> wrote:
>
> I think this looks reasonable too (with the qualification that I didn't
> look at it in much detail).
>
> On Fri, Mar 5, 2021 at 9:46 AM Alejandro Serrano Mena <trupill at gmail.com>
> wrote:
>
>> This proposal seems fine to me.
>>
>> Alejandro
>>
>> El El vie, 5 mar 2021 a las 10:22, Simon Peyton Jones via
>> ghc-steering-committee <ghc-steering-committee at haskell.org> escribió:
>>
>>> I don’t have a well-informed opinion, but I certainly have no objection.
>>>
>>>
>>>
>>> Simon
>>>
>>>
>>>
>>> *From:* ghc-steering-committee <
>>> ghc-steering-committee-bounces at haskell.org> *On Behalf Of *Spiwack,
>>> Arnaud
>>> *Sent:* 04 March 2021 14:54
>>> *To:* GHC Steering committee <ghc-steering-committee at haskell.org>
>>> *Subject:* [ghc-steering-committee] #403: Cleanup lexical structure,
>>> recommendation: accept
>>>
>>>
>>>
>>> Dear all,
>>>
>>>
>>>
>>> As the shepherd for proposal #403 Cleanup lexical structure of numbers
>>> and identifiers
>>> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%2Fpull%2F403&data=04%7C01%7Csimonpj%40microsoft.com%7Cb28a9399e2fd44379fd308d8df1d66b0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637504665725379654%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=Rfp%2F%2BPsrs%2FQWa9k67NTAOLAI7PXccca%2BVLBZvcNVYME%3D&reserved=0>,
>>> let me recommend acceptance.
>>>
>>>
>>>
>>> This proposal does two things related to unicode characters
>>>
>>>    - Codify the actual current lexing of unicode symbols, which is
>>>    actually different from the Haskell 2010 report (in particular, only ascii
>>>    digits are allowed in number literals)
>>>    - Adds the possibility to use unicode letters which are neither
>>>    upper case nor lower case (such as many asian scripts) as trailing symbols
>>>    for identifier (as well as in String and Char literals)
>>>
>>> It doesn't make it possible (nor close the door) to use letter-like
>>> numbers (such as latin numerals) as identifiers, nor use non-ascii digits
>>> in number literals.
>>>
>>>
>>>
>>> As the title entails, it's essentially a clean up of the documentation,
>>> to match reality. It seems quite uncontroversial.
>>> _______________________________________________
>>> ghc-steering-committee mailing list
>>> ghc-steering-committee at haskell.org
>>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>>
>> _______________________________________________
>> ghc-steering-committee mailing list
>> ghc-steering-committee at haskell.org
>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
>
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20210311/2d73b234/attachment.html>

From vlad.z.4096 at gmail.com  Thu Mar 11 11:25:26 2021
From: vlad.z.4096 at gmail.com (Vladislav Zavialov (int-index))
Date: Thu, 11 Mar 2021 14:25:26 +0300
Subject: [ghc-steering-committee] New (and old) members of the Committee
In-Reply-To: <CAHnFXOt8VcbAJ7Xy5EnOQQEkE-YPENsMQSfpMN4SMd87PuJcMQ@mail.gmail.com>
References: <CAHnFXOvy8XnjqCT41Y0mzuSx8QAGBn_qp0_Jhb-1dk=kEpEugg@mail.gmail.com>
 <010f01781de0389d-739778f8-f11d-4a92-9258-14bf90964f03-000000@us-east-2.amazonses.com>
 <CAHnFXOt8VcbAJ7Xy5EnOQQEkE-YPENsMQSfpMN4SMd87PuJcMQ@mail.gmail.com>
Message-ID: <0C946729-D9E4-4153-A617-40925EE1DEE2@gmail.com>

Hello! Thank you everyone for the warm welcome.

I will now go through the proposals under consideration and see if I can add something to the discussion.

- Vlad

> On 11 Mar 2021, at 11:53, Alejandro Serrano Mena <trupill at gmail.com> wrote:
> 
> Welcome, Vlad! I’m very happy to have you among us :)
> 
> Right now we are discussing a few proposals, feel free to jump into the discussion (the archives should give you a rough idea). In particular, we are debating lately about dependent types and the general meaning of “extension”, which are topics which I think would benefit from a fresh pair of eyes.
> 
> Regards,
> Alejandro
> 
> On 10 Mar 2021 at 21:42:17, Richard Eisenberg <rae at richarde.dev> wrote:
> Welcome, Vlad!
> 
> Vlad is already on this list (according to the list of subscribers). He will need GitHub permissions, but it looks like Joachim is the one with the right permissions to do that.
> 
> Sidenote: Joachim, perhaps you should also grant maintainer access to the ghc-proposals team (https://github.com/orgs/ghc-proposals/teams/ghc-steering-committee/members) to the Simons, in case action needs to be taken while you're unavailable.
> 
> Thanks for steering this process, Alejandro!
> 
> Richard
> 
>> On Mar 10, 2021, at 3:09 PM, Alejandro Serrano Mena <trupill at gmail.com> wrote:
>> 
>> Dear Committee,
>> 
>> It’s my pleasure that announce that the three members with an expired term (Joachim, Iavor, and Richard) have renewed their membership. In addition, we have a new member in the Committee: Vladislav Zavialov. We found all four applications to be really strong!
>> 
>> Could anybody help me adding Vladislav to the mailing list and giving him the proper permissions? That way I could give him a proper welcome to the Committee :)
>> 
>> Alejandro
>> _______________________________________________
>> ghc-steering-committee mailing list
>> ghc-steering-committee at haskell.org
>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
> 
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee


From vlad.z.4096 at gmail.com  Thu Mar 11 12:51:15 2021
From: vlad.z.4096 at gmail.com (Vladislav Zavialov (int-index))
Date: Thu, 11 Mar 2021 15:51:15 +0300
Subject: [ghc-steering-committee] Recommendation: reject #367 (was: Re:
 Please review #367: Clarify primops using unboxed sums,
 Shepherd: Simon Marlow)
In-Reply-To: <CAHnFXOvkThi=v0Y-+iHYTgOLqEHNguucc+NVJuALZzCg1mkrFQ@mail.gmail.com>
References: <50e635bf8c9a58568aa810fc284da4cdf39ce702.camel@joachim-breitner.de>
 <CANsrgPK4eWHyJDfZmuTdgj5weYvbKroNjxZr+HUW5CfP7hKYHA@mail.gmail.com>
 <f9ea90b44714208fa2635ee292871d74a0061079.camel@joachim-breitner.de>
 <010f01781504442d-f0eaea4e-d93b-4dca-9af8-25492e4bcfea-000000@us-east-2.amazonses.com>
 <CAH6fHQ=x+RtcUVQgDkD9fYLU6ntVtzRZJp+51+yzxFd8Oooqmg@mail.gmail.com>
 <CAHnFXOvkThi=v0Y-+iHYTgOLqEHNguucc+NVJuALZzCg1mkrFQ@mail.gmail.com>
Message-ID: <EA87A049-065F-4F00-B58E-B5A63ECEDA0D@gmail.com>

The complexity of the proposed migration strategy (with a transient compatibility layer) does not seem justified. I’m not sure if we should be worried about breaking changes to primops at all – they are more of an implementation detail than a user-facing API. We are supposed to export user-facing wrappers separately, and be able to change primops at will.

Consider the tryTakeMVar# primop. Hackage Search reveals that it is used only by a handful of packages: base, ghc-prim, ghc, ghc-lib, ghc-lib-parser, concurrent-st, exctcore, haskell-names, haste-compiler, lhc, prim, primal, primitive, primitive-unlifted.

The first three are under our control and can be updated immediately (base, ghc-prim, ghc). The following two are by their own nature compatibility layers (ghc-lib, ghc-lib-parser). And I’m sure the remaining 9 will be able to adapt without a complicated migration (we could even ask the implementor to submit patches to these projects, 9 is not a large amount).

So I would recommend to ask the author to remove the migration plan and then I’d vote +0.5 on the proposal. As to the proposal in its current form, I concur with the recommendation to reject.

- Vlad

> On 9 Mar 2021, at 18:38, Alejandro Serrano Mena <trupill at gmail.com> wrote:
> 
> This is my feeling, too.
> 
> Alejandro
> 
> On 9 Mar 2021 at 09:14:12, Spiwack, Arnaud <arnaud.spiwack at tweag.io> wrote:
> I don't have an informed opinion. I'll trust Simon. It may very well be a case of “it would have been the right thing to do were we to start from scratch today, but it is now too late to do so”.
> 
> On Tue, Mar 9, 2021 at 4:25 AM Richard Eisenberg <rae at richarde.dev> wrote:
> I want to accept this. But, in the end, I don't see enough benefit (which seems to be mostly aesthetic) to justify the (somewhat modest, as these things go) costs.
> 
> I sadly agree with the shepherd to reject.
> 
> Richard
> 
>> On Mar 8, 2021, at 11:59 AM, Joachim Breitner <mail at joachim-breitner.de> wrote:
>> 
>> Hi,
>> 
>> your points sounds reasonable, and the author got a heads up on the
>> Github thread (so unlikely that there was a misunderstanding or
>> oversight), so I’ll concur with the shepherd.
>> 
>> Cheers,
>> Joachim
>> 
>> 
>> Am Montag, den 08.03.2021, 15:51 +0000 schrieb Simon Marlow:
>>> Committee,
>>> 
>>> Proposal #367 suggests using unboxed sums for the results of 7 (seven) primops that use sum types but currently have to encode those explicitly using `Int#`.
>>> 
>>> https://github.com/treeowl/ghc-proposals/blob/unboxed-sum-primops/proposals/0000-unboxed-sum-primops.md
>>> 
>>> The proposal is arguably the right thing, however I'm suggesting we reject it for the following reasons:
>>> The implementations of the primops would bake in the translation of unboxed sums. Right now our unboxed sum translation is defined in one place - CorePrep - but this proposal would leak it into the implementations of a few primops.
>>> Migration would entail adding a backwards-compatibility layer, with the associated complexity and risk of performance regressions.
>>> While the current situation is perhaps inelegant, it's not broken and it's easy to understand.
>>> Thoughts?
>>> 
>>> Simon
>>> 
>>> 
>>> On Sun, 4 Oct 2020 at 22:14, Joachim Breitner <mail at joachim-breitner.de> wrote:
>>>> Dear Committee,
>>>> 
>>>> this is your secretary speaking:
>>>> 
>>>> Clarify primops using unboxed sum
>>>> has been proposed by David Feuer
>>>> https://github.com/ghc-proposals/ghc-proposals/pull/367
>>>> https://github.com/treeowl/ghc-proposals/blob/unboxed-sum-primops/proposals/0000-unboxed-sum-primops.md
>>>> 
>>>> I’ll propose Simon Marlow as the shepherd.
>>>> 
>>>> Please guide us to a conclusion as outlined in 
>>>> https://github.com/ghc-proposals/ghc-proposals#committee-process
>>>> 
>>>> Thanks,
>>>> Joachim
>>>> _______________________________________________
>>>> ghc-steering-committee mailing list
>>>> ghc-steering-committee at haskell.org
>>>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>> -- 
>> Joachim Breitner
>>  mail at joachim-breitner.de
>>  http://www.joachim-breitner.de/
>> 
>> 
>> _______________________________________________
>> ghc-steering-committee mailing list
>> ghc-steering-committee at haskell.org
>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
> 
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee


From vlad.z.4096 at gmail.com  Thu Mar 11 13:31:22 2021
From: vlad.z.4096 at gmail.com (Vladislav Zavialov (int-index))
Date: Thu, 11 Mar 2021 16:31:22 +0300
Subject: [ghc-steering-committee] #390: Fine-grained pragmas,
 recommendation: accept
In-Reply-To: <CALpVSmPJDcaPaWNUKrE4gUOatQ0gLj=RQaxi5Ew+R3bxm_P_ww@mail.gmail.com>
References: <CALpVSmPJDcaPaWNUKrE4gUOatQ0gLj=RQaxi5Ew+R3bxm_P_ww@mail.gmail.com>
Message-ID: <989E9E72-9923-4870-B424-B1B2D07A738D@gmail.com>

I like the proposal and I would be happy to vote for its acceptance. However, it requires a little bit of polishing up with regards to its use of modifiers. In particular, it seems to treat modifiers as built-in units, whereas the core idea behind modifiers is that they are based on actual promoted types (with the exception of %1).

Hence it seems appropriate to send it back for revision until this point is addressed.

- Vlad

> On 20 Feb 2021, at 14:34, Vitaly Bragilevsky <bravit111 at gmail.com> wrote:
> 
> Dear Committee,
> 
> Our own Alejandro has been proposed
> Fine-grained pragmas for classes, families, and instances
> https://github.com/ghc-proposals/ghc-proposals/pull/390
> https://github.com/serras/ghc-proposals/blob/instance-pragmas/proposals/0000-fine-grained-undecidable.md
> 
> His idea is to bring the flexibility of overlaps/overlapping/overlappable pragmas to termination checking, type inference, and constraint solving. Alejandro proposes to introduce the following %-modifiers (as in already accepted #370, https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0370-modifiers.rst):
> %NoTerminationCheck
> %LiberalCoverage
> %LiberalInjectivity
> %Overlapping
> %Overlappable
> %Overlaps
> to liberate conditions for classes and instances, type families, forall-types, etc. The first three modifiers can be used instead of the scary-sounding UndecidableInstances extension. The last three modifiers are supposed to be used instead of the  overlap*-pragmas for instances we already have. Note that this proposal doesn't suggest deprecating those extensions and pragmas.
> 
> I think that this proposal goes in the right direction and recommend accepting it.
> 
> As far as I understand, all the committee members, including those with terms about to expire, have the right to either support this proposal or to raise a voice against it either here or at https://github.com/ghc-proposals/ghc-proposals/pull/390.
> 
> Regards,
> Vitaly
> 
> 
> 
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee


From rae at richarde.dev  Thu Mar 11 13:55:23 2021
From: rae at richarde.dev (Richard Eisenberg)
Date: Thu, 11 Mar 2021 13:55:23 +0000
Subject: [ghc-steering-committee] Recommendation: reject #367 (was: Re:
 Please review #367: Clarify primops using unboxed sums,
 Shepherd: Simon Marlow)
In-Reply-To: <EA87A049-065F-4F00-B58E-B5A63ECEDA0D@gmail.com>
References: <50e635bf8c9a58568aa810fc284da4cdf39ce702.camel@joachim-breitner.de>
 <CANsrgPK4eWHyJDfZmuTdgj5weYvbKroNjxZr+HUW5CfP7hKYHA@mail.gmail.com>
 <f9ea90b44714208fa2635ee292871d74a0061079.camel@joachim-breitner.de>
 <010f01781504442d-f0eaea4e-d93b-4dca-9af8-25492e4bcfea-000000@us-east-2.amazonses.com>
 <CAH6fHQ=x+RtcUVQgDkD9fYLU6ntVtzRZJp+51+yzxFd8Oooqmg@mail.gmail.com>
 <CAHnFXOvkThi=v0Y-+iHYTgOLqEHNguucc+NVJuALZzCg1mkrFQ@mail.gmail.com>
 <EA87A049-065F-4F00-B58E-B5A63ECEDA0D@gmail.com>
Message-ID: <010f01782192101b-eedcb228-429d-46db-89c4-2de5f62e023a-000000@us-east-2.amazonses.com>

There's an interesting point here I'd like to highlight: Vlad is implicitly suggesting a new policy of allowing primop interfaces to change between releases without a migration plan. I don't have an informed opinion of whether this is a good idea, but it does seem plausible -- especially if there are also stable interfaces wrapping the primops.

Enshrining this policy would allow us to accept this current #367 as well as, perhaps, other proposals in this space that would be otherwise hard to accept.

Richard

> On Mar 11, 2021, at 7:51 AM, Vladislav Zavialov (int-index) <vlad.z.4096 at gmail.com> wrote:
> 
> The complexity of the proposed migration strategy (with a transient compatibility layer) does not seem justified. I’m not sure if we should be worried about breaking changes to primops at all – they are more of an implementation detail than a user-facing API. We are supposed to export user-facing wrappers separately, and be able to change primops at will.
> 
> Consider the tryTakeMVar# primop. Hackage Search reveals that it is used only by a handful of packages: base, ghc-prim, ghc, ghc-lib, ghc-lib-parser, concurrent-st, exctcore, haskell-names, haste-compiler, lhc, prim, primal, primitive, primitive-unlifted.
> 
> The first three are under our control and can be updated immediately (base, ghc-prim, ghc). The following two are by their own nature compatibility layers (ghc-lib, ghc-lib-parser). And I’m sure the remaining 9 will be able to adapt without a complicated migration (we could even ask the implementor to submit patches to these projects, 9 is not a large amount).
> 
> So I would recommend to ask the author to remove the migration plan and then I’d vote +0.5 on the proposal. As to the proposal in its current form, I concur with the recommendation to reject.
> 
> - Vlad
> 
>> On 9 Mar 2021, at 18:38, Alejandro Serrano Mena <trupill at gmail.com> wrote:
>> 
>> This is my feeling, too.
>> 
>> Alejandro
>> 
>> On 9 Mar 2021 at 09:14:12, Spiwack, Arnaud <arnaud.spiwack at tweag.io> wrote:
>> I don't have an informed opinion. I'll trust Simon. It may very well be a case of “it would have been the right thing to do were we to start from scratch today, but it is now too late to do so”.
>> 
>> On Tue, Mar 9, 2021 at 4:25 AM Richard Eisenberg <rae at richarde.dev> wrote:
>> I want to accept this. But, in the end, I don't see enough benefit (which seems to be mostly aesthetic) to justify the (somewhat modest, as these things go) costs.
>> 
>> I sadly agree with the shepherd to reject.
>> 
>> Richard
>> 
>>> On Mar 8, 2021, at 11:59 AM, Joachim Breitner <mail at joachim-breitner.de> wrote:
>>> 
>>> Hi,
>>> 
>>> your points sounds reasonable, and the author got a heads up on the
>>> Github thread (so unlikely that there was a misunderstanding or
>>> oversight), so I’ll concur with the shepherd.
>>> 
>>> Cheers,
>>> Joachim
>>> 
>>> 
>>> Am Montag, den 08.03.2021, 15:51 +0000 schrieb Simon Marlow:
>>>> Committee,
>>>> 
>>>> Proposal #367 suggests using unboxed sums for the results of 7 (seven) primops that use sum types but currently have to encode those explicitly using `Int#`.
>>>> 
>>>> https://github.com/treeowl/ghc-proposals/blob/unboxed-sum-primops/proposals/0000-unboxed-sum-primops.md
>>>> 
>>>> The proposal is arguably the right thing, however I'm suggesting we reject it for the following reasons:
>>>> The implementations of the primops would bake in the translation of unboxed sums. Right now our unboxed sum translation is defined in one place - CorePrep - but this proposal would leak it into the implementations of a few primops.
>>>> Migration would entail adding a backwards-compatibility layer, with the associated complexity and risk of performance regressions.
>>>> While the current situation is perhaps inelegant, it's not broken and it's easy to understand.
>>>> Thoughts?
>>>> 
>>>> Simon
>>>> 
>>>> 
>>>> On Sun, 4 Oct 2020 at 22:14, Joachim Breitner <mail at joachim-breitner.de> wrote:
>>>>> Dear Committee,
>>>>> 
>>>>> this is your secretary speaking:
>>>>> 
>>>>> Clarify primops using unboxed sum
>>>>> has been proposed by David Feuer
>>>>> https://github.com/ghc-proposals/ghc-proposals/pull/367
>>>>> https://github.com/treeowl/ghc-proposals/blob/unboxed-sum-primops/proposals/0000-unboxed-sum-primops.md
>>>>> 
>>>>> I’ll propose Simon Marlow as the shepherd.
>>>>> 
>>>>> Please guide us to a conclusion as outlined in 
>>>>> https://github.com/ghc-proposals/ghc-proposals#committee-process
>>>>> 
>>>>> Thanks,
>>>>> Joachim
>>>>> _______________________________________________
>>>>> ghc-steering-committee mailing list
>>>>> ghc-steering-committee at haskell.org
>>>>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>> -- 
>>> Joachim Breitner
>>> mail at joachim-breitner.de
>>> http://www.joachim-breitner.de/
>>> 
>>> 
>>> _______________________________________________
>>> ghc-steering-committee mailing list
>>> ghc-steering-committee at haskell.org
>>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>> 
>> _______________________________________________
>> ghc-steering-committee mailing list
>> ghc-steering-committee at haskell.org
>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>> _______________________________________________
>> ghc-steering-committee mailing list
>> ghc-steering-committee at haskell.org
>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>> _______________________________________________
>> ghc-steering-committee mailing list
>> ghc-steering-committee at haskell.org
>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
> 
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee


From vlad.z.4096 at gmail.com  Thu Mar 11 14:26:18 2021
From: vlad.z.4096 at gmail.com (Vladislav Zavialov (int-index))
Date: Thu, 11 Mar 2021 17:26:18 +0300
Subject: [ghc-steering-committee] #403: Cleanup lexical structure,
 recommendation: accept
In-Reply-To: <CAH6fHQnFWpoHouPYqXvuzUdpRrRdJH3KZqcWtNZ5xqRkSSMQrA@mail.gmail.com>
References: <CAH6fHQnGv72AF1PrxQhyDSNcgK0gwwaJzHYbhfc+hn44SD1+4w@mail.gmail.com>
 <VI1PR83MB02229E22E39517DA61FC0427AD969@VI1PR83MB0222.EURPRD83.prod.outlook.com>
 <CAHnFXOvDF_MYxjS-u0dvo+x9Fdg_rLcZom_hbXoEKmL-9_GyCg@mail.gmail.com>
 <CAGK9nupRPwc1hRx_AmGFujfXBUwX63Msph90nBYv8irdnBOy7A@mail.gmail.com>
 <010f01781512e7a3-5bc80b24-389f-4a0b-9aac-b914fe503af0-000000@us-east-2.amazonses.com>
 <CAH6fHQnFWpoHouPYqXvuzUdpRrRdJH3KZqcWtNZ5xqRkSSMQrA@mail.gmail.com>
Message-ID: <B11C0876-A3B5-46CE-8A62-BB5912B0700A@gmail.com>

I’m in favor of the proposal, but there’s something I don’t entirely understand. We are about to double down on a deviation from the Haskell 2010 report, with no way to turn it off. Such deviations are typically documented in the “Known bugs and infelicities” section of the User’s Guide.

And yet this is not a bug, it’s a feature, driven by user requests (the proposal even goes as far as to cite the tickets).

So, where will the new canonical lexical grammar live? Where do we point our users to when they try to figure out what’s allowed in identifiers/literals and what isn't?

- Vlad

> On 11 Mar 2021, at 12:46, Spiwack, Arnaud <arnaud.spiwack at tweag.io> wrote:
> 
> Dear all,
> 
> About half of us have opined, so far. If nobody complains, I'll treat silence as assent and mark this proposal as accepted on Tuesday (16 March).
> 
> On Tue, Mar 9, 2021 at 4:41 AM Richard Eisenberg <rae at richarde.dev> wrote:
> I'm in support.
> 
> Thanks,
> Richard
> 
>> On Mar 5, 2021, at 1:03 PM, Iavor Diatchki <iavor.diatchki at gmail.com> wrote:
>> 
>> I think this looks reasonable too (with the qualification that I didn't look at it in much detail).
>> 
>> On Fri, Mar 5, 2021 at 9:46 AM Alejandro Serrano Mena <trupill at gmail.com> wrote:
>> This proposal seems fine to me.
>> 
>> Alejandro
>> 
>> El El vie, 5 mar 2021 a las 10:22, Simon Peyton Jones via ghc-steering-committee <ghc-steering-committee at haskell.org> escribió:
>> I don’t have a well-informed opinion, but I certainly have no objection.
>> 
>>  
>> 
>> Simon
>> 
>>  
>> 
>> From: ghc-steering-committee <ghc-steering-committee-bounces at haskell.org> On Behalf Of Spiwack, Arnaud
>> Sent: 04 March 2021 14:54
>> To: GHC Steering committee <ghc-steering-committee at haskell.org>
>> Subject: [ghc-steering-committee] #403: Cleanup lexical structure, recommendation: accept
>> 
>>  
>> 
>> Dear all,
>> 
>>  
>> 
>> As the shepherd for proposal #403 Cleanup lexical structure of numbers and identifiers, let me recommend acceptance.
>> 
>>  
>> 
>> This proposal does two things related to unicode characters
>> 
>> 	• Codify the actual current lexing of unicode symbols, which is actually different from the Haskell 2010 report (in particular, only ascii digits are allowed in number literals)
>> 	• Adds the possibility to use unicode letters which are neither upper case nor lower case (such as many asian scripts) as trailing symbols for identifier (as well as in String and Char literals)
>> It doesn't make it possible (nor close the door) to use letter-like numbers (such as latin numerals) as identifiers, nor use non-ascii digits in number literals.
>> 
>>  
>> 
>> As the title entails, it's essentially a clean up of the documentation, to match reality. It seems quite uncontroversial.
>> 
>> _______________________________________________
>> ghc-steering-committee mailing list
>> ghc-steering-committee at haskell.org
>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>> _______________________________________________
>> ghc-steering-committee mailing list
>> ghc-steering-committee at haskell.org
>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>> _______________________________________________
>> ghc-steering-committee mailing list
>> ghc-steering-committee at haskell.org
>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
> 
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee


From vlad.z.4096 at gmail.com  Thu Mar 11 15:49:26 2021
From: vlad.z.4096 at gmail.com (Vladislav Zavialov (int-index))
Date: Thu, 11 Mar 2021 18:49:26 +0300
Subject: [ghc-steering-committee] Please review #378: Support ergonomic
 dependent types, Shepherd: Simon PJ
In-Reply-To: <bfacc32e6c13ca48ec708f7c6ab85a8188bc28c2.camel@joachim-breitner.de>
References: <bfacc32e6c13ca48ec708f7c6ab85a8188bc28c2.camel@joachim-breitner.de>
Message-ID: <1850212A-B70F-4524-8A2F-FB02B31AB7CF@gmail.com>

There are a few issues I see with this proposal. Let me first enumerate the issues, and then I will offer possible solutions.

1. The proposal does not live up to its name. The claim is that we want to support “ergonomic dependent types”, and yet the proposed design falls short of this claim. We will not have ergonomic dependently-typed programming until we are able to use term-level functions at the type level, and yet this is not part of the stated goals. The proposed design includes the notion of a “Static Subset”, which is not ergonomic in my opinion.

2. The proposal is inherently ‘mutable’: it refers to GHC Wiki when it clarifies what is meant by “ergonomic dependent types”, but the Wiki can be modified without GHC Steering Committee’s involvement. In fact, it’s part of the plan to refine the design over time! For example, it is still unclear (to me) whether we want `foreach` quantification or `Relevant` constraints. There must be an immutable component included in the proposal itself, one on which we will all agree, and then any change to it will have to go through the proposal process again. Otherwise, it seems like we are basically adding an (unintentional) loophole.

3. The proposal does an insufficiently good job of describing our values and priorities. Sceptics worry that lots of code will break, or that GHC will become slower, or that error messages will regress, and so on. The proposal should make clear that it is part of the effort to avoid these potential problems, rather than march blindly towards a vaguely defined bright future.

So, here are some corrections I’d like to see.

1. Rename the proposal to something along the lines of “Support Ergonomic Dependent Types – Part I”. We will inevitably follow up with Part II about type-level functions, complete term/type unification, and such. I mean the things listed under the “The Glorious Future” section of the Wiki page. If we accept this proposal, we are not accepting everything that is claimed to be related to Dependent Haskell – we are setting our destination to a specific subset of dependently-typed features. I don’t care about the exact phrasing (could be something like “A Step Towards Ergonomic Dependent Types”, or “Foundation for Dependent Types in GHC”, or anything else). I do care that it’s made clear that this proposal is not the full story. 

2. Copy the key parts of the Wiki page into the Proposed Change Specification. The key parts are already identified there: Predictable Erasure Principle, Lexical Scoping Principle, Syntactic Unification Principle. These principles will hold in any design that we shall settle on. They represent a high-level description of what we’re trying to agree on. On the other hand, code examples and various details must stay on the Wiki page, and then get elaborated in individual feature proposals. So let’s add the essential bits to the proposal text, but not more than necessary (4-5 principles, each backed by a few sentences).

3. The proposed change specification should explicitly state that dependent types do not become the one and only goal. We continue to care about compile times, error messages, backwards compatibility, type inference, and so on. I think the proponents of dependent types (including myself) have mistakenly assumed this to be obvious. Just writing this down will reassure a lot of people, or at least I hope so.

Thanks!
- Vlad

> On 9 Mar 2021, at 10:58, Joachim Breitner <mail at joachim-breitner.de> wrote:
> 
> Dear Committe,
> 
> Support ergonomic dependent types
> has been proposed by Richard Eisenberg
> https://github.com/ghc-proposals/ghc-proposals/pull/378
> https://github.com/goldfirere/ghc-proposals/blob/dependent-types/proposals/0000-dependent-type-design.rst
> 
> This is a meta-proposal, aimed at refining our criteria when evaluating
> proposals, and wants us to confirm that we take compatibility with a
> future world where Haskell gains more dependently typed features into
> account, and welcome changes that we would likely reject if we did not
> expect to move towards that future.
> (My rephrasing, please have a look at least at “Motivation” and
> “Proposed Change Specification”).
> 
> We might need more of a Moderator than a Shepherd here… I propose that
> Simon PJ leads us to a decision here. I know that Simon has a strong
> opinion on this already and might not be a “neutral moderator”. But
> opinions are not a bad thing per se, and I think this questions
> requires Chair-level involvement.
> 
> 
> 
> Please guide us to a conclusion as outlined in 
> https://github.com/ghc-proposals/ghc-proposals#committee-process
> 
> Thanks,
> Joachim
> -- 
> -- 
> Joachim Breitner
>  mail at joachim-breitner.de
>  http://www.joachim-breitner.de/
> 
> 
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee


From rae at richarde.dev  Thu Mar 11 22:17:56 2021
From: rae at richarde.dev (Richard Eisenberg)
Date: Thu, 11 Mar 2021 22:17:56 +0000
Subject: [ghc-steering-committee] Please review #378: Support ergonomic
 dependent types, Shepherd: Simon PJ
In-Reply-To: <1850212A-B70F-4524-8A2F-FB02B31AB7CF@gmail.com>
References: <bfacc32e6c13ca48ec708f7c6ab85a8188bc28c2.camel@joachim-breitner.de>
 <1850212A-B70F-4524-8A2F-FB02B31AB7CF@gmail.com>
Message-ID: <010f0178235e26f7-76fbcaf0-01e3-4733-bbb7-16d9e3e9491f-000000@us-east-2.amazonses.com>

Hi Vlad,

Very good points. Allow me to respond.

> On Mar 11, 2021, at 10:49 AM, Vladislav Zavialov (int-index) <vlad.z.4096 at gmail.com> wrote:
> 
> There are a few issues I see with this proposal. Let me first enumerate the issues, and then I will offer possible solutions.
> 
> 1. The proposal does not live up to its name. The claim is that we want to support “ergonomic dependent types”, and yet the proposed design falls short of this claim. We will not have ergonomic dependently-typed programming until we are able to use term-level functions at the type level, and yet this is not part of the stated goals. The proposed design includes the notion of a “Static Subset”, which is not ergonomic in my opinion.

I agree that there is tension between "ergonomic" and the Static Subset. But I do not think these are in direct conflict, precisely because the Static Subset need not be a strict subset. Once the Static Subset includes the entire language -- including reduction of functions in types -- then we will have full dependent types. The wiki page does not outlaw this state of affairs; it simply does not require it. This is a key part of the design in the wiki page: it's a design we can build today and then grow bit by bit until we really do have good dependent types.

> 
> 2. The proposal is inherently ‘mutable’: it refers to GHC Wiki when it clarifies what is meant by “ergonomic dependent types”, but the Wiki can be modified without GHC Steering Committee’s involvement. In fact, it’s part of the plan to refine the design over time! For example, it is still unclear (to me) whether we want `foreach` quantification or `Relevant` constraints. There must be an immutable component included in the proposal itself, one on which we will all agree, and then any change to it will have to go through the proposal process again. Otherwise, it seems like we are basically adding an (unintentional) loophole.

While you're technically accurate here, I'm not worried about this possibility, as it would seem to require a degree of willful sleight of hand. Wiki pages have immutable histories, so we can always do archaeology if we need to. I think of the mutability here as a feature, not a bug: as we flesh out the design, we can update the wiki page. It's true that this capability could be abused, but I'd rather take that risk.

> 
> 3. The proposal does an insufficiently good job of describing our values and priorities. Sceptics worry that lots of code will break, or that GHC will become slower, or that error messages will regress, and so on. The proposal should make clear that it is part of the effort to avoid these potential problems, rather than march blindly towards a vaguely defined bright future.

I have added a list of common misconceptions to the wiki page. Might these address your concerns?

> 
> So, here are some corrections I’d like to see.
> 
> 1. Rename the proposal to something along the lines of “Support Ergonomic Dependent Types – Part I”. We will inevitably follow up with Part II about type-level functions, complete term/type unification, and such. I mean the things listed under the “The Glorious Future” section of the Wiki page. If we accept this proposal, we are not accepting everything that is claimed to be related to Dependent Haskell – we are setting our destination to a specific subset of dependently-typed features. I don’t care about the exact phrasing (could be something like “A Step Towards Ergonomic Dependent Types”, or “Foundation for Dependent Types in GHC”, or anything else). I do care that it’s made clear that this proposal is not the full story. 

I'm quite happy to drop "ergonomic", as that term is squishy and troublesome. But I actually do not think that this proposal needs a sequel, so I don't want to set it up to require one.

> 
> 2. Copy the key parts of the Wiki page into the Proposed Change Specification. The key parts are already identified there: Predictable Erasure Principle, Lexical Scoping Principle, Syntactic Unification Principle. These principles will hold in any design that we shall settle on. They represent a high-level description of what we’re trying to agree on. On the other hand, code examples and various details must stay on the Wiki page, and then get elaborated in individual feature proposals. So let’s add the essential bits to the proposal text, but not more than necessary (4-5 principles, each backed by a few sentences).

I see your point here, but I think that keeping this open and mutable is better. What do others think?

> 
> 3. The proposed change specification should explicitly state that dependent types do not become the one and only goal. We continue to care about compile times, error messages, backwards compatibility, type inference, and so on. I think the proponents of dependent types (including myself) have mistakenly assumed this to be obvious. Just writing this down will reassure a lot of people, or at least I hope so.

This is easy, and I certainly agree with the intent. I will do so shortly.

Thanks for this feedback!
Richard

> 
> Thanks!
> - Vlad
> 
>> On 9 Mar 2021, at 10:58, Joachim Breitner <mail at joachim-breitner.de> wrote:
>> 
>> Dear Committe,
>> 
>> Support ergonomic dependent types
>> has been proposed by Richard Eisenberg
>> https://github.com/ghc-proposals/ghc-proposals/pull/378
>> https://github.com/goldfirere/ghc-proposals/blob/dependent-types/proposals/0000-dependent-type-design.rst
>> 
>> This is a meta-proposal, aimed at refining our criteria when evaluating
>> proposals, and wants us to confirm that we take compatibility with a
>> future world where Haskell gains more dependently typed features into
>> account, and welcome changes that we would likely reject if we did not
>> expect to move towards that future.
>> (My rephrasing, please have a look at least at “Motivation” and
>> “Proposed Change Specification”).
>> 
>> We might need more of a Moderator than a Shepherd here… I propose that
>> Simon PJ leads us to a decision here. I know that Simon has a strong
>> opinion on this already and might not be a “neutral moderator”. But
>> opinions are not a bad thing per se, and I think this questions
>> requires Chair-level involvement.
>> 
>> 
>> 
>> Please guide us to a conclusion as outlined in 
>> https://github.com/ghc-proposals/ghc-proposals#committee-process
>> 
>> Thanks,
>> Joachim
>> -- 
>> -- 
>> Joachim Breitner
>> mail at joachim-breitner.de
>> http://www.joachim-breitner.de/
>> 
>> 
>> _______________________________________________
>> ghc-steering-committee mailing list
>> ghc-steering-committee at haskell.org
>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
> 
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee


From bravit111 at gmail.com  Sat Mar 13 09:38:16 2021
From: bravit111 at gmail.com (Vitaly Bragilevsky)
Date: Sat, 13 Mar 2021 12:38:16 +0300
Subject: [ghc-steering-committee] #390: Fine-grained pragmas,
 recommendation: accept
In-Reply-To: <989E9E72-9923-4870-B424-B1B2D07A738D@gmail.com>
References: <CALpVSmPJDcaPaWNUKrE4gUOatQ0gLj=RQaxi5Ew+R3bxm_P_ww@mail.gmail.com>
 <989E9E72-9923-4870-B424-B1B2D07A738D@gmail.com>
Message-ID: <CALpVSmMKSn3o+0_rzvxUckeEykY_Jk5tGRLBrFf12t1H_bZ0QA@mail.gmail.com>

чт, 11 мар. 2021 г. в 16:31, Vladislav Zavialov (int-index) <
vlad.z.4096 at gmail.com>:

> I like the proposal and I would be happy to vote for its acceptance.
> However, it requires a little bit of polishing up with regards to its use
> of modifiers. In particular, it seems to treat modifiers as built-in units,
> whereas the core idea behind modifiers is that they are based on actual
> promoted types (with the exception of %1).
>
> Hence it seems appropriate to send it back for revision until this point
> is addressed.
>

Yes, I agree. There is also another issue. I think we need either a
deprecation story for UndecidableInstances, or a statement that it should
survive with some motivation behind that.

So, I'm sending this proposal back to Alejandro for review and set the
"needs revision" label on GitHub.

Vitaly

>
> - Vlad
>
> > On 20 Feb 2021, at 14:34, Vitaly Bragilevsky <bravit111 at gmail.com>
> wrote:
> >
> > Dear Committee,
> >
> > Our own Alejandro has been proposed
> > Fine-grained pragmas for classes, families, and instances
> > https://github.com/ghc-proposals/ghc-proposals/pull/390
> >
> https://github.com/serras/ghc-proposals/blob/instance-pragmas/proposals/0000-fine-grained-undecidable.md
> >
> > His idea is to bring the flexibility of
> overlaps/overlapping/overlappable pragmas to termination checking, type
> inference, and constraint solving. Alejandro proposes to introduce the
> following %-modifiers (as in already accepted #370,
> https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0370-modifiers.rst
> ):
> > %NoTerminationCheck
> > %LiberalCoverage
> > %LiberalInjectivity
> > %Overlapping
> > %Overlappable
> > %Overlaps
> > to liberate conditions for classes and instances, type families,
> forall-types, etc. The first three modifiers can be used instead of the
> scary-sounding UndecidableInstances extension. The last three modifiers are
> supposed to be used instead of the  overlap*-pragmas for instances we
> already have. Note that this proposal doesn't suggest deprecating those
> extensions and pragmas.
> >
> > I think that this proposal goes in the right direction and recommend
> accepting it.
> >
> > As far as I understand, all the committee members, including those with
> terms about to expire, have the right to either support this proposal or to
> raise a voice against it either here or at
> https://github.com/ghc-proposals/ghc-proposals/pull/390.
> >
> > Regards,
> > Vitaly
> >
> >
> >
> > _______________________________________________
> > ghc-steering-committee mailing list
> > ghc-steering-committee at haskell.org
> > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20210313/d160914b/attachment.html>

From arnaud.spiwack at tweag.io  Wed Mar 17 09:56:39 2021
From: arnaud.spiwack at tweag.io (Spiwack, Arnaud)
Date: Wed, 17 Mar 2021 10:56:39 +0100
Subject: [ghc-steering-committee] #403: Cleanup lexical structure,
 recommendation: accept
In-Reply-To: <B11C0876-A3B5-46CE-8A62-BB5912B0700A@gmail.com>
References: <CAH6fHQnGv72AF1PrxQhyDSNcgK0gwwaJzHYbhfc+hn44SD1+4w@mail.gmail.com>
 <VI1PR83MB02229E22E39517DA61FC0427AD969@VI1PR83MB0222.EURPRD83.prod.outlook.com>
 <CAHnFXOvDF_MYxjS-u0dvo+x9Fdg_rLcZom_hbXoEKmL-9_GyCg@mail.gmail.com>
 <CAGK9nupRPwc1hRx_AmGFujfXBUwX63Msph90nBYv8irdnBOy7A@mail.gmail.com>
 <010f01781512e7a3-5bc80b24-389f-4a0b-9aac-b914fe503af0-000000@us-east-2.amazonses.com>
 <CAH6fHQnFWpoHouPYqXvuzUdpRrRdJH3KZqcWtNZ5xqRkSSMQrA@mail.gmail.com>
 <B11C0876-A3B5-46CE-8A62-BB5912B0700A@gmail.com>
Message-ID: <CAH6fHQmu6Ncxohk70hrQegMj8WQdzyRhoa4BK20Fa3omkvSpnQ@mail.gmail.com>

I think we can figure out the right place for the documentation when the MR
comes around.

Nobody having opposed the proposal, I'll now mark it as accepted.

On Thu, Mar 11, 2021 at 3:26 PM Vladislav Zavialov (int-index) <
vlad.z.4096 at gmail.com> wrote:

> I’m in favor of the proposal, but there’s something I don’t entirely
> understand. We are about to double down on a deviation from the Haskell
> 2010 report, with no way to turn it off. Such deviations are typically
> documented in the “Known bugs and infelicities” section of the User’s Guide.
>
> And yet this is not a bug, it’s a feature, driven by user requests (the
> proposal even goes as far as to cite the tickets).
>
> So, where will the new canonical lexical grammar live? Where do we point
> our users to when they try to figure out what’s allowed in
> identifiers/literals and what isn't?
>
> - Vlad
>
> > On 11 Mar 2021, at 12:46, Spiwack, Arnaud <arnaud.spiwack at tweag.io>
> wrote:
> >
> > Dear all,
> >
> > About half of us have opined, so far. If nobody complains, I'll treat
> silence as assent and mark this proposal as accepted on Tuesday (16 March).
> >
> > On Tue, Mar 9, 2021 at 4:41 AM Richard Eisenberg <rae at richarde.dev>
> wrote:
> > I'm in support.
> >
> > Thanks,
> > Richard
> >
> >> On Mar 5, 2021, at 1:03 PM, Iavor Diatchki <iavor.diatchki at gmail.com>
> wrote:
> >>
> >> I think this looks reasonable too (with the qualification that I didn't
> look at it in much detail).
> >>
> >> On Fri, Mar 5, 2021 at 9:46 AM Alejandro Serrano Mena <
> trupill at gmail.com> wrote:
> >> This proposal seems fine to me.
> >>
> >> Alejandro
> >>
> >> El El vie, 5 mar 2021 a las 10:22, Simon Peyton Jones via
> ghc-steering-committee <ghc-steering-committee at haskell.org> escribió:
> >> I don’t have a well-informed opinion, but I certainly have no objection.
> >>
> >>
> >>
> >> Simon
> >>
> >>
> >>
> >> From: ghc-steering-committee <
> ghc-steering-committee-bounces at haskell.org> On Behalf Of Spiwack, Arnaud
> >> Sent: 04 March 2021 14:54
> >> To: GHC Steering committee <ghc-steering-committee at haskell.org>
> >> Subject: [ghc-steering-committee] #403: Cleanup lexical structure,
> recommendation: accept
> >>
> >>
> >>
> >> Dear all,
> >>
> >>
> >>
> >> As the shepherd for proposal #403 Cleanup lexical structure of numbers
> and identifiers, let me recommend acceptance.
> >>
> >>
> >>
> >> This proposal does two things related to unicode characters
> >>
> >>      • Codify the actual current lexing of unicode symbols, which is
> actually different from the Haskell 2010 report (in particular, only ascii
> digits are allowed in number literals)
> >>      • Adds the possibility to use unicode letters which are neither
> upper case nor lower case (such as many asian scripts) as trailing symbols
> for identifier (as well as in String and Char literals)
> >> It doesn't make it possible (nor close the door) to use letter-like
> numbers (such as latin numerals) as identifiers, nor use non-ascii digits
> in number literals.
> >>
> >>
> >>
> >> As the title entails, it's essentially a clean up of the documentation,
> to match reality. It seems quite uncontroversial.
> >>
> >> _______________________________________________
> >> ghc-steering-committee mailing list
> >> ghc-steering-committee at haskell.org
> >>
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
> >> _______________________________________________
> >> ghc-steering-committee mailing list
> >> ghc-steering-committee at haskell.org
> >>
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
> >> _______________________________________________
> >> ghc-steering-committee mailing list
> >> ghc-steering-committee at haskell.org
> >>
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
> >
> > _______________________________________________
> > ghc-steering-committee mailing list
> > ghc-steering-committee at haskell.org
> > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
> > _______________________________________________
> > ghc-steering-committee mailing list
> > ghc-steering-committee at haskell.org
> > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20210317/a0641121/attachment.html>

From iavor.diatchki at gmail.com  Wed Mar 17 17:16:47 2021
From: iavor.diatchki at gmail.com (Iavor Diatchki)
Date: Wed, 17 Mar 2021 10:16:47 -0700
Subject: [ghc-steering-committee] Status #281
Message-ID: <CAGK9nuokpsbUmyfkydPVP-8nv1d9C0LSRqvMaXzOcx4=GLGivA@mail.gmail.com>

Hello,

Just FYI, as I have updated the status of #281 to "revision needed" as we
discussed.

-Iavor
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20210317/5d8f839d/attachment.html>

From mail at joachim-breitner.de  Wed Mar 17 21:14:43 2021
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Wed, 17 Mar 2021 22:14:43 +0100
Subject: [ghc-steering-committee]  Please review #283: Local modules,
 Shepherd: Vladislav
Message-ID: <da39600c4dbb86aa874e5b6549be6b549b6a36cc.camel@joachim-breitner.de>

Dear Committe,

Local modules
has been proposed by Richard Eisenberg
https://github.com/ghc-proposals/ghc-proposals/pull/283
https://github.com/goldfirere/ghc-proposals/blob/local-modules/proposals/0000-local-modules.rst

I propose Vladislav, as our newest member, to be the shepherd for this gem.

Please guide us to a conclusion as outlined in 
https://github.com/ghc-proposals/ghc-proposals#committee-process

Thanks,
Joachim
-- 
-- 
Joachim Breitner
  mail at joachim-breitner.de
  http://www.joachim-breitner.de/



From mail at joachim-breitner.de  Wed Mar 17 21:16:01 2021
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Wed, 17 Mar 2021 22:16:01 +0100
Subject: [ghc-steering-committee]  Please review #283: Local modules,
 Shepherd: Arnaud
Message-ID: <1d194b23e3ae40ec8f098f2eea4b4f023eaf99e7.camel@joachim-breitner.de>

[Corrected message]


Dear Committe,

Local modules
has been proposed by Richard Eisenberg
https://github.com/ghc-proposals/ghc-proposals/pull/283
https://github.com/goldfirere/ghc-proposals/blob/local-modules/proposals/0000-local-modules.rst

This is actually a re-submission, so the Shepherd was and still is Arnaud.

(Sorry, Vladislav, but you’ll get something to do soon I am sure :-))

Please guide us to a conclusion as outlined in 
https://github.com/ghc-proposals/ghc-proposals#committee-process

Thanks,
Joachim
-- 
-- 
Joachim Breitner
  mail at joachim-breitner.de
  http://www.joachim-breitner.de/



From rae at richarde.dev  Thu Mar 18 20:05:39 2021
From: rae at richarde.dev (Richard Eisenberg)
Date: Thu, 18 Mar 2021 20:05:39 +0000
Subject: [ghc-steering-committee] Proposal #402 (changes to GADT syntax);
	rec: accept
Message-ID: <010f017846f18f9a-b6f06ca5-eac3-4532-94dd-a45bb8260698-000000@us-east-2.amazonses.com>

Hi GHCSC,

I am the shepherd for Proposal #402, which has been submitted for our consideration.

Proposal text: https://github.com/serokell/ghc-proposals/blob/gadt-syntax/proposals/0000-gadt-syntax.rst
PR discussion: https://github.com/ghc-proposals/ghc-proposals/pull/402

-----------------
Proposal Summary:

The proposal changes a few aspects of GADT constructor syntax, in part to make them simpler, and in part to make them more expressive. Only non-record syntax is treated by this proposal; GADT record constructors are entirely unaffected.

The two changes are:

1. Drop support for parentheses around result types in GADT constructor signatures.
2. Add support for nested quantifiers in GADT constructor signatures.

Examples & motivation:

1. This would now be rejected:

data T where
  MkT :: Int -> (Bool -> T)

Those parentheses are not allowed.

On the other hand

data S where
  MkS :: Int -> Bool -> (S)

remains accepted.

This change is mainly to simplify the implementation, but it also helps users understand that the thing after `MkS ::` really is not a type: it's a list of constructor arguments written in a concrete syntax that looks like a type. See the proposal for more explanation of how this is not a type.

2. This would now be accepted:

data Q a where
  MkQ :: forall e. Int -> e -> forall a -> forall b. a -> b -> Show a => Q (a,b)

Note the appearance of `forall a ->`, `forall b.`, and `Show a =>` after visible arguments.

Constructors with forall ... -> syntax (such as our MkQ) will not be allowed in expressions or patterns (that would require #281), but will be allowed in types.

This change is a generalization of the syntax we have today, and it allows library authors more flexibility in designing interfaces, as they can now choose where type arguments should be written in a constructor.

------------------------
Recommendation:

I recommend acceptance.

1. Dropping the parentheses sounds trivial, but keeping them means we have to do extra work in the design of our data structures to remember the parentheses. Because constructor "types" aren't types, this information isn't otherwise needed.

2. This generalization increases our expressiveness and removes what may feel like an artificial limitation. Furthermore, it is necessary in the case where we might have later arguments depend on earlier ones (possible for promoted constructors).

Please share opinions on acceptance/rejection here, or technical thoughts on the ticket itself.

I will accept in two weeks if there are no objections.

Thanks!
Richard

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20210318/e43ed3b5/attachment.html>

From eric at seidel.io  Fri Mar 19 01:12:07 2021
From: eric at seidel.io (Eric Seidel)
Date: Thu, 18 Mar 2021 21:12:07 -0400
Subject: [ghc-steering-committee]
 =?utf-8?q?Proposal_=23402_=28changes_to_?=
 =?utf-8?q?GADT_syntax=29=3B=09rec=3A_accept?=
In-Reply-To: <010f017846f18f9a-b6f06ca5-eac3-4532-94dd-a45bb8260698-000000@us-east-2.amazonses.com>
References: <010f017846f18f9a-b6f06ca5-eac3-4532-94dd-a45bb8260698-000000@us-east-2.amazonses.com>
Message-ID: <9042cbd3-19e7-4c58-bb7d-5bb57369d1b4@www.fastmail.com>

I think the case for restricting the use of parentheses in GADTs is pretty weak, for a few reasons.

1. The RHS of a GADT constructor signature may not share the same grammar as a type, but it was clearly designed to resemble type syntax. And there's nothing confusing about writing

  data Foo where
    MkFoo :: Int -> (Double -> Foo)

Data constructors are curried, so that's a perfectly valid way to think about MkFoo's type.

2. The proposal notes that GADT signatures support things, like strictness annotations and record syntax, that types do not. But both of these things would be useful additions to standard type syntax. Specifying strictness as part of the type would be much more ergonomic than doing it at the term level (and having to deal with footguns around wildcard patterns, nobody should have to write !_). Similarly, anonymous records are a frequently requested addition to Haskell, we just haven't found a good way to add them yet. So I'm inclined to argue that the discrepancy between constructor signatures and types should be rectified by making types more like constructor sigs.

3. The second part of the proposal addresses another discrepancy between constructor sigs and types, by making constructor sigs more like types!

My inclination is to accept change (2) and reject change (1).

Eric

On Thu, Mar 18, 2021, at 16:05, Richard Eisenberg wrote:
> Hi GHCSC,
> 
> I am the shepherd for Proposal #402, which has been submitted for our 
> consideration.
> 
> Proposal text: 
> https://github.com/serokell/ghc-proposals/blob/gadt-syntax/proposals/0000-gadt-syntax.rst
> PR discussion: https://github.com/ghc-proposals/ghc-proposals/pull/402
> 
> -----------------
> *Proposal Summary:*
> 
> The proposal changes a few aspects of GADT constructor syntax, in part 
> to make them simpler, and in part to make them more expressive. Only 
> non-record syntax is treated by this proposal; GADT record constructors 
> are entirely unaffected.
> 
> The two changes are:
> 
> 1. Drop support for parentheses around result types in GADT constructor 
> signatures.
> 2. Add support for nested quantifiers in GADT constructor signatures.
> 
> Examples & motivation:
> 
> 1. This would now be rejected:
> 
> data T where
>   MkT :: Int -> (Bool -> T)
> 
> Those parentheses are not allowed.
> 
> On the other hand
> 
> data S where
>   MkS :: Int -> Bool -> (S)
> 
> remains accepted.
> 
> This change is mainly to simplify the implementation, but it also helps 
> users understand that the thing after `MkS ::` really is not a type: 
> it's a list of constructor arguments written in a concrete syntax that 
> looks like a type. See the proposal for more explanation of how this is 
> not a type.
> 
> 2. This would now be accepted:
> 
> data Q a where
>   MkQ :: forall e. Int -> e -> forall a -> forall b. a -> b -> Show a => Q (a,b)
> 
> Note the appearance of `forall a ->`, `forall b.`, and `Show a =>` 
> after visible arguments.
> 
> Constructors with forall ... -> syntax (such as our MkQ) will not be 
> allowed in expressions or patterns (that would require #281), but will 
> be allowed in types.
> 
> This change is a generalization of the syntax we have today, and it 
> allows library authors more flexibility in designing interfaces, as 
> they can now choose where type arguments should be written in a 
> constructor.
> 
> ------------------------
> *Recommendation:*
> *
> *
> I recommend acceptance.
> 
> 1. Dropping the parentheses sounds trivial, but keeping them means we 
> have to do extra work in the design of our data structures to remember 
> the parentheses. Because constructor "types" aren't types, this 
> information isn't otherwise needed.
> 
> 2. This generalization increases our expressiveness and removes what 
> may feel like an artificial limitation. Furthermore, it is necessary in 
> the case where we might have later arguments depend on earlier ones 
> (possible for promoted constructors).
> 
> Please share opinions on acceptance/rejection here, or technical 
> thoughts on the ticket itself.
> 
> I will accept in two weeks if there are no objections.
> 
> Thanks!
> Richard
> 
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org <mailto:ghc-steering-committee%40haskell.org>
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>

From trupill at gmail.com  Fri Mar 19 09:14:40 2021
From: trupill at gmail.com (Alejandro Serrano Mena)
Date: Fri, 19 Mar 2021 02:14:40 -0700
Subject: [ghc-steering-committee] Proposal #402 (changes to GADT syntax);
 rec: accept
In-Reply-To: <9042cbd3-19e7-4c58-bb7d-5bb57369d1b4@www.fastmail.com>
References: <010f017846f18f9a-b6f06ca5-eac3-4532-94dd-a45bb8260698-000000@us-east-2.amazonses.com>
 <9042cbd3-19e7-4c58-bb7d-5bb57369d1b4@www.fastmail.com>
Message-ID: <CAHnFXOsLFM-fuu6E+yuTXHRuTxKGrp70Pmq3d6xuYfLb-JqrNA@mail.gmail.com>

I mostly agree with Eric’s response.

@Richard could you give us a small summary about why (1) simplifies the
implementation so much? As a GHC user, I would find it entirely reasonable
to had written `MkS :: Int -> (Double -> Foo)` but when showing some error
message getting instead `MkS :: Int -> Double -> Foo`.

Thanks in advance,
Alejandro

On 19 Mar 2021 at 02:12:07, Eric Seidel <eric at seidel.io> wrote:

> I think the case for restricting the use of parentheses in GADTs is pretty
> weak, for a few reasons.
>
> 1. The RHS of a GADT constructor signature may not share the same grammar
> as a type, but it was clearly designed to resemble type syntax. And there's
> nothing confusing about writing
>
>  data Foo where
>    MkFoo :: Int -> (Double -> Foo)
>
> Data constructors are curried, so that's a perfectly valid way to think
> about MkFoo's type.
>
> 2. The proposal notes that GADT signatures support things, like strictness
> annotations and record syntax, that types do not. But both of these things
> would be useful additions to standard type syntax. Specifying strictness as
> part of the type would be much more ergonomic than doing it at the term
> level (and having to deal with footguns around wildcard patterns, nobody
> should have to write !_). Similarly, anonymous records are a frequently
> requested addition to Haskell, we just haven't found a good way to add them
> yet. So I'm inclined to argue that the discrepancy between constructor
> signatures and types should be rectified by making types more like
> constructor sigs.
>
> 3. The second part of the proposal addresses another discrepancy between
> constructor sigs and types, by making constructor sigs more like types!
>
> My inclination is to accept change (2) and reject change (1).
>
> Eric
>
> On Thu, Mar 18, 2021, at 16:05, Richard Eisenberg wrote:
>
> Hi GHCSC,
>
>
> I am the shepherd for Proposal #402, which has been submitted for our
>
> consideration.
>
>
> Proposal text:
>
>
> https://github.com/serokell/ghc-proposals/blob/gadt-syntax/proposals/0000-gadt-syntax.rst
>
> PR discussion: https://github.com/ghc-proposals/ghc-proposals/pull/402
>
>
> -----------------
>
> *Proposal Summary:*
>
>
> The proposal changes a few aspects of GADT constructor syntax, in part
>
> to make them simpler, and in part to make them more expressive. Only
>
> non-record syntax is treated by this proposal; GADT record constructors
>
> are entirely unaffected.
>
>
> The two changes are:
>
>
> 1. Drop support for parentheses around result types in GADT constructor
>
> signatures.
>
> 2. Add support for nested quantifiers in GADT constructor signatures.
>
>
> Examples & motivation:
>
>
> 1. This would now be rejected:
>
>
> data T where
>
>   MkT :: Int -> (Bool -> T)
>
>
> Those parentheses are not allowed.
>
>
> On the other hand
>
>
> data S where
>
>   MkS :: Int -> Bool -> (S)
>
>
> remains accepted.
>
>
> This change is mainly to simplify the implementation, but it also helps
>
> users understand that the thing after `MkS ::` really is not a type:
>
> it's a list of constructor arguments written in a concrete syntax that
>
> looks like a type. See the proposal for more explanation of how this is
>
> not a type.
>
>
> 2. This would now be accepted:
>
>
> data Q a where
>
>   MkQ :: forall e. Int -> e -> forall a -> forall b. a -> b -> Show a => Q
> (a,b)
>
>
> Note the appearance of `forall a ->`, `forall b.`, and `Show a =>`
>
> after visible arguments.
>
>
> Constructors with forall ... -> syntax (such as our MkQ) will not be
>
> allowed in expressions or patterns (that would require #281), but will
>
> be allowed in types.
>
>
> This change is a generalization of the syntax we have today, and it
>
> allows library authors more flexibility in designing interfaces, as
>
> they can now choose where type arguments should be written in a
>
> constructor.
>
>
> ------------------------
>
> *Recommendation:*
>
> *
>
> *
>
> I recommend acceptance.
>
>
> 1. Dropping the parentheses sounds trivial, but keeping them means we
>
> have to do extra work in the design of our data structures to remember
>
> the parentheses. Because constructor "types" aren't types, this
>
> information isn't otherwise needed.
>
>
> 2. This generalization increases our expressiveness and removes what
>
> may feel like an artificial limitation. Furthermore, it is necessary in
>
> the case where we might have later arguments depend on earlier ones
>
> (possible for promoted constructors).
>
>
> Please share opinions on acceptance/rejection here, or technical
>
> thoughts on the ticket itself.
>
>
> I will accept in two weeks if there are no objections.
>
>
> Thanks!
>
> Richard
>
>
> _______________________________________________
>
> ghc-steering-committee mailing list
>
> ghc-steering-committee at haskell.org <mailto:
> ghc-steering-committee%40haskell.org>
>
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
>
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20210319/1d1f3299/attachment-0001.html>

From simonpj at microsoft.com  Fri Mar 19 10:35:36 2021
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Fri, 19 Mar 2021 10:35:36 +0000
Subject: [ghc-steering-committee] Proposal #402 (changes to GADT syntax);
	rec: accept
In-Reply-To: <9042cbd3-19e7-4c58-bb7d-5bb57369d1b4@www.fastmail.com>
References: <010f017846f18f9a-b6f06ca5-eac3-4532-94dd-a45bb8260698-000000@us-east-2.amazonses.com>
 <9042cbd3-19e7-4c58-bb7d-5bb57369d1b4@www.fastmail.com>
Message-ID: <AM0PR83MB0276ADA91F77B84D43A24038AD689@AM0PR83MB0276.EURPRD83.prod.outlook.com>

|  2. The proposal notes that GADT signatures support things, like
|  strictness annotations and record syntax, that types do not. But both
|  of these things would be useful additions to standard type syntax.
|  Specifying strictness as part of the type would be much more ergonomic
|  than doing it at the term level (and having to deal with footguns
|  around wildcard patterns, nobody should have to write !_). Similarly,
|  anonymous records are a frequently requested addition to Haskell, we
|  just haven't found a good way to add them yet. So I'm inclined to
|  argue that the discrepancy between constructor signatures and types
|  should be rectified by making types more like constructor sigs.

You seem to be saying that we might extend ordinary types by including strictness information, UNPACK pragmas, anonymous records.

You, or anyone else, are more than welcome to make a proposal along those lines, although I have no idea what a type with a nested strictness annotation or UNPACK pragma might mean.  And anonymous records are a whole swamp of their own.

But I don't think we should de-rail this very modest proposal because it (sensibly) does not venture into these deep waters.

Simon

|  -----Original Message-----
|  From: ghc-steering-committee <ghc-steering-committee-
|  bounces at haskell.org> On Behalf Of Eric Seidel
|  Sent: 19 March 2021 01:12
|  To: ghc-steering-committee at haskell.org
|  Subject: Re: [ghc-steering-committee] Proposal #402 (changes to GADT
|  syntax); rec: accept
|  
|  I think the case for restricting the use of parentheses in GADTs is
|  pretty weak, for a few reasons.
|  
|  1. The RHS of a GADT constructor signature may not share the same
|  grammar as a type, but it was clearly designed to resemble type
|  syntax. And there's nothing confusing about writing
|  
|    data Foo where
|      MkFoo :: Int -> (Double -> Foo)
|  
|  Data constructors are curried, so that's a perfectly valid way to
|  think about MkFoo's type.
|  
|  2. The proposal notes that GADT signatures support things, like
|  strictness annotations and record syntax, that types do not. But both
|  of these things would be useful additions to standard type syntax.
|  Specifying strictness as part of the type would be much more ergonomic
|  than doing it at the term level (and having to deal with footguns
|  around wildcard patterns, nobody should have to write !_). Similarly,
|  anonymous records are a frequently requested addition to Haskell, we
|  just haven't found a good way to add them yet. So I'm inclined to
|  argue that the discrepancy between constructor signatures and types
|  should be rectified by making types more like constructor sigs.
|  
|  3. The second part of the proposal addresses another discrepancy
|  between constructor sigs and types, by making constructor sigs more
|  like types!
|  
|  My inclination is to accept change (2) and reject change (1).
|  
|  Eric
|  
|  On Thu, Mar 18, 2021, at 16:05, Richard Eisenberg wrote:
|  > Hi GHCSC,
|  >
|  > I am the shepherd for Proposal #402, which has been submitted for
|  our
|  > consideration.
|  >
|  > Proposal text:
|  >
|  https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith
|  > ub.com%2Fserokell%2Fghc-proposals%2Fblob%2Fgadt-
|  syntax%2Fproposals%2F0
|  > 000-gadt-
|  syntax.rst&amp;data=04%7C01%7Csimonpj%40microsoft.com%7C13543
|  >
|  5d4c02d4b5fee6308d8ea741b27%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0
|  >
|  %7C637517131721649358%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQ
|  >
|  IjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=SrADiQ3mdc
|  > 1I%2ByHeIsVIrrqxNpHMDrrzI8i%2BtR3jTmQ%3D&amp;reserved=0
|  > PR discussion:
|  >
|  https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith
|  > ub.com%2Fghc-proposals%2Fghc-
|  proposals%2Fpull%2F402&amp;data=04%7C01%7
|  >
|  Csimonpj%40microsoft.com%7C135435d4c02d4b5fee6308d8ea741b27%7C72f988bf
|  >
|  86f141af91ab2d7cd011db47%7C1%7C0%7C637517131721649358%7CUnknown%7CTWFp
|  >
|  bGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn
|  >
|  0%3D%7C1000&amp;sdata=uxtcdSD%2BF2cHMLabWGNwjR2j95z3Ew6GlpnGBMjbM%2Fw%
|  > 3D&amp;reserved=0
|  >
|  > -----------------
|  > *Proposal Summary:*
|  >
|  > The proposal changes a few aspects of GADT constructor syntax, in
|  part
|  > to make them simpler, and in part to make them more expressive. Only
|  > non-record syntax is treated by this proposal; GADT record
|  > constructors are entirely unaffected.
|  >
|  > The two changes are:
|  >
|  > 1. Drop support for parentheses around result types in GADT
|  > constructor signatures.
|  > 2. Add support for nested quantifiers in GADT constructor
|  signatures.
|  >
|  > Examples & motivation:
|  >
|  > 1. This would now be rejected:
|  >
|  > data T where
|  >   MkT :: Int -> (Bool -> T)
|  >
|  > Those parentheses are not allowed.
|  >
|  > On the other hand
|  >
|  > data S where
|  >   MkS :: Int -> Bool -> (S)
|  >
|  > remains accepted.
|  >
|  > This change is mainly to simplify the implementation, but it also
|  > helps users understand that the thing after `MkS ::` really is not a
|  type:
|  > it's a list of constructor arguments written in a concrete syntax
|  that
|  > looks like a type. See the proposal for more explanation of how this
|  > is not a type.
|  >
|  > 2. This would now be accepted:
|  >
|  > data Q a where
|  >   MkQ :: forall e. Int -> e -> forall a -> forall b. a -> b -> Show
|  a
|  > => Q (a,b)
|  >
|  > Note the appearance of `forall a ->`, `forall b.`, and `Show a =>`
|  > after visible arguments.
|  >
|  > Constructors with forall ... -> syntax (such as our MkQ) will not be
|  > allowed in expressions or patterns (that would require #281), but
|  will
|  > be allowed in types.
|  >
|  > This change is a generalization of the syntax we have today, and it
|  > allows library authors more flexibility in designing interfaces, as
|  > they can now choose where type arguments should be written in a
|  > constructor.
|  >
|  > ------------------------
|  > *Recommendation:*
|  > *
|  > *
|  > I recommend acceptance.
|  >
|  > 1. Dropping the parentheses sounds trivial, but keeping them means
|  we
|  > have to do extra work in the design of our data structures to
|  remember
|  > the parentheses. Because constructor "types" aren't types, this
|  > information isn't otherwise needed.
|  >
|  > 2. This generalization increases our expressiveness and removes what
|  > may feel like an artificial limitation. Furthermore, it is necessary
|  > in the case where we might have later arguments depend on earlier
|  ones
|  > (possible for promoted constructors).
|  >
|  > Please share opinions on acceptance/rejection here, or technical
|  > thoughts on the ticket itself.
|  >
|  > I will accept in two weeks if there are no objections.
|  >
|  > Thanks!
|  > Richard
|  >
|  > _______________________________________________
|  > ghc-steering-committee mailing list
|  > ghc-steering-committee at haskell.org
|  > <mailto:ghc-steering-committee%40haskell.org>
|  >
|  https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail
|  > .haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-
|  committee&a
|  >
|  mp;data=04%7C01%7Csimonpj%40microsoft.com%7C135435d4c02d4b5fee6308d8ea
|  >
|  741b27%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637517131721649358
|  >
|  %7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6I
|  >
|  k1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=MYNdwRX%2FB1cM6FHOCWEdYB55Tj2XC
|  > YkvrBUC4UVU8L8%3D&amp;reserved=0
|  >
|  _______________________________________________
|  ghc-steering-committee mailing list
|  ghc-steering-committee at haskell.org
|  https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail
|  .haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-
|  committee&amp;data=04%7C01%7Csimonpj%40microsoft.com%7C135435d4c02d4b5
|  fee6308d8ea741b27%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6375171
|  31721649358%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMz
|  IiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=MYNdwRX%2FB1cM6FHOCW
|  EdYB55Tj2XCYkvrBUC4UVU8L8%3D&amp;reserved=0

From eric at seidel.io  Fri Mar 19 12:04:09 2021
From: eric at seidel.io (Eric Seidel)
Date: Fri, 19 Mar 2021 08:04:09 -0400
Subject: [ghc-steering-committee]
 =?utf-8?q?Proposal_=23402_=28changes_to_?=
 =?utf-8?q?GADT_syntax=29=3B=09rec=3A_accept?=
In-Reply-To: <AM0PR83MB0276ADA91F77B84D43A24038AD689@AM0PR83MB0276.EURPRD83.prod.outlook.com>
References: <010f017846f18f9a-b6f06ca5-eac3-4532-94dd-a45bb8260698-000000@us-east-2.amazonses.com>
 <9042cbd3-19e7-4c58-bb7d-5bb57369d1b4@www.fastmail.com>
 <AM0PR83MB0276ADA91F77B84D43A24038AD689@AM0PR83MB0276.EURPRD83.prod.outlook.com>
Message-ID: <c2ef63a7-e5dd-4815-895e-e2c57b6b659b@www.fastmail.com>

On Fri, Mar 19, 2021, at 06:35, Simon Peyton Jones wrote:
> You seem to be saying that we might extend ordinary types by including 
> strictness information, UNPACK pragmas, anonymous records.

We already have an active proposal to add anonymous records, and I think there's a good case for adding strictness annotations to ordinary function types, at least for top-level arguments like in GADT signatures. 

But my bigger point is that this proposal argues that types and constructor signatures should be wholly separate beasts. I disagree. We should seek to minimize the difference between the two. I don't expect to make them identical (e.g. I don't see a use for UNPACK pragmas in function types), but a world where constructor sigs are a strict superset of types seems plausible, and change (2) moves us in that direction. That's why I'm in favor of (2) and against (1).

Eric

From mail at joachim-breitner.de  Fri Mar 19 14:43:28 2021
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Fri, 19 Mar 2021 15:43:28 +0100
Subject: [ghc-steering-committee] Recommendation: reject #367 (was: Re:
 Please review #367: Clarify primops using unboxed sums,
 Shepherd: Simon Marlow)
In-Reply-To: <CANsrgPK4eWHyJDfZmuTdgj5weYvbKroNjxZr+HUW5CfP7hKYHA@mail.gmail.com>
References: <50e635bf8c9a58568aa810fc284da4cdf39ce702.camel@joachim-breitner.de>
 <CANsrgPK4eWHyJDfZmuTdgj5weYvbKroNjxZr+HUW5CfP7hKYHA@mail.gmail.com>
Message-ID: <a99a0d1688de505768fd968085a3436d79528eb7.camel@joachim-breitner.de>

Hi,

Am Montag, den 08.03.2021, 15:51 +0000 schrieb Simon Marlow:
> The proposal is arguably the right thing, however I'm suggesting we
> reject it for the following reasons:

looks like we have consensus, marking this as rejected.

(Thanks Tom for the nudge).

Cheers,
Joachim

-- 
Joachim Breitner
  mail at joachim-breitner.de
  http://www.joachim-breitner.de/



From iavor.diatchki at gmail.com  Fri Mar 19 16:18:32 2021
From: iavor.diatchki at gmail.com (Iavor Diatchki)
Date: Fri, 19 Mar 2021 09:18:32 -0700
Subject: [ghc-steering-committee] Proposal #402 (changes to GADT syntax);
 rec: accept
In-Reply-To: <010f017846f18f9a-b6f06ca5-eac3-4532-94dd-a45bb8260698-000000@us-east-2.amazonses.com>
References: <010f017846f18f9a-b6f06ca5-eac3-4532-94dd-a45bb8260698-000000@us-east-2.amazonses.com>
Message-ID: <CAGK9nuqXcdriZkqT5Sb6XaPfwdDC=nBjYDp75mik5=fsNuOS-w@mail.gmail.com>

Hello,

I agree that thinking of the GADT constructors as types is confusing and
not very consistent.  In addition to the issues listed in the proposal, the
following doesn't work, which should if they were really types:

   type T = Int -> S
   data S where C :: T

On the other hand, I fail to see what's the purpose of the proposal,
despite the long motivation section (maybe bad reading comprehension before
coffee :-)).   The benefits are:
  1. We can't write parens in the signatures,
  2. We can write nested quantifiers

If (1) would make something simpler, I'd be fine with it, but it seems like
an odd restriction that we don't need, as we have it working fine at the
moment.  So why not just document what we are doing now?
I don't see any benefits to (2), it seems just as easy to write the
quantifiers at the beginning of the signature, which is what they'd
presumably mean anyway.  And given that we just argued that these are not
really types, I don't see why we are trying to make them look more like
types, by supporting a somewhat weird corner case of type signatures...

Ultimately, I don't feel strongly about this, and perhaps the benefit is
that we'd have a properly specified GADT syntax.  If this is the
motivation, the proposal should say so, rather than starting with an
assumed misconception of the reader  My gut feeling is exactly the opposite
to Eric's, and I am more OK with (1) if it makes the grammar simpler, but
(2) seems quite superfluous to me.

Cheers,
-Iavor

















On Thu, Mar 18, 2021 at 1:05 PM Richard Eisenberg <rae at richarde.dev> wrote:

> Hi GHCSC,
>
> I am the shepherd for Proposal #402, which has been submitted for our
> consideration.
>
> Proposal text:
> https://github.com/serokell/ghc-proposals/blob/gadt-syntax/proposals/0000-gadt-syntax.rst
> PR discussion: https://github.com/ghc-proposals/ghc-proposals/pull/402
>
> -----------------
> *Proposal Summary:*
>
> The proposal changes a few aspects of GADT constructor syntax, in part to
> make them simpler, and in part to make them more expressive. Only
> non-record syntax is treated by this proposal; GADT record constructors are
> entirely unaffected.
>
> The two changes are:
>
> 1. Drop support for parentheses around result types in GADT constructor
> signatures.
> 2. Add support for nested quantifiers in GADT constructor signatures.
>
> Examples & motivation:
>
> 1. This would now be rejected:
>
> data T where
>   MkT :: Int -> (Bool -> T)
>
> Those parentheses are not allowed.
>
> On the other hand
>
> data S where
>   MkS :: Int -> Bool -> (S)
>
> remains accepted.
>
> This change is mainly to simplify the implementation, but it also helps
> users understand that the thing after `MkS ::` really is not a type: it's a
> list of constructor arguments written in a concrete syntax that looks like
> a type. See the proposal for more explanation of how this is not a type.
>
> 2. This would now be accepted:
>
> data Q a where
>   MkQ :: forall e. Int -> e -> forall a -> forall b. a -> b -> Show a => Q
> (a,b)
>
> Note the appearance of `forall a ->`, `forall b.`, and `Show a =>` after
> visible arguments.
>
> Constructors with forall ... -> syntax (such as our MkQ) will not be
> allowed in expressions or patterns (that would require #281), but will be
> allowed in types.
>
> This change is a generalization of the syntax we have today, and it allows
> library authors more flexibility in designing interfaces, as they can now
> choose where type arguments should be written in a constructor.
>
> ------------------------
> *Recommendation:*
>
> I recommend acceptance.
>
> 1. Dropping the parentheses sounds trivial, but keeping them means we have
> to do extra work in the design of our data structures to remember the
> parentheses. Because constructor "types" aren't types, this information
> isn't otherwise needed.
>
> 2. This generalization increases our expressiveness and removes what may
> feel like an artificial limitation. Furthermore, it is necessary in the
> case where we might have later arguments depend on earlier ones (possible
> for promoted constructors).
>
> Please share opinions on acceptance/rejection here, or technical thoughts
> on the ticket itself.
>
> I will accept in two weeks if there are no objections.
>
> Thanks!
> Richard
>
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20210319/289ca328/attachment.html>

From mail at joachim-breitner.de  Fri Mar 19 18:26:13 2021
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Fri, 19 Mar 2021 19:26:13 +0100
Subject: [ghc-steering-committee] Proposal #402 (changes to GADT syntax);
 rec: accept
In-Reply-To: <CAGK9nuqXcdriZkqT5Sb6XaPfwdDC=nBjYDp75mik5=fsNuOS-w@mail.gmail.com>
References: <010f017846f18f9a-b6f06ca5-eac3-4532-94dd-a45bb8260698-000000@us-east-2.amazonses.com>
 <CAGK9nuqXcdriZkqT5Sb6XaPfwdDC=nBjYDp75mik5=fsNuOS-w@mail.gmail.com>
Message-ID: <55c091cc351053df0bd1e1360c49c9239039fdcc.camel@joachim-breitner.de>

Hi,

TL;DR: Not in favor of (1), but of (2).

I agree about (1), and would lean towards not changing the behavior,
and still allow parentheses.

Am Freitag, den 19.03.2021, 09:18 -0700 schrieb Iavor Diatchki:
> I don't see any benefits to (2), it seems just as easy to write the
> quantifiers at the beginning of the signature, which is what they'd
> presumably mean anyway. 

I don't remember the occasion, but ran into a related restriction very
recently, where I wanted to list all the constraints a

  C1 =>
  C2 =>
  T1 ->
  T2 ->
  …

but was told by the compiler I better use 

  (C1, C2) =>
  T1 ->
  T2 ->
  …


so I am in favor of the change (2), simply because it may reduce
friction and gives me more leeway in writing it the way it suits me.

I could imagine that in some cases it might be nice to mix forall’s and
constraints, if it somehow serves the narrative better.

Cheers,
Joachim


-- 
Joachim Breitner
  mail at joachim-breitner.de
  http://www.joachim-breitner.de/



From mail at joachim-breitner.de  Fri Mar 19 18:27:37 2021
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Fri, 19 Mar 2021 19:27:37 +0100
Subject: [ghc-steering-committee]   Please review #396: Defaulting plugins,
 Shepherd: Vladislav
Message-ID: <4a92adaabe0d6f5d54b1fff3ec99091ba567c4a8.camel@joachim-breitner.de>

Dear Committe,

Defaulting Plugins
has been proposed by Andrei Barbu
https://github.com/ghc-proposals/ghc-proposals/pull/396
https://github.com/abarbu/ghc-proposals/blob/master/proposals/0000-defaulting-plugins.rst

I propose Vladislav, as our newest member, to shepherd this.

Please guide us to a conclusion as outlined in 
https://github.com/ghc-proposals/ghc-proposals#committee-process

Thanks,
Joachim
-- 
-- 
Joachim Breitner
  mail at joachim-breitner.de
  http://www.joachim-breitner.de/



From rae at richarde.dev  Fri Mar 19 18:38:22 2021
From: rae at richarde.dev (Richard Eisenberg)
Date: Fri, 19 Mar 2021 18:38:22 +0000
Subject: [ghc-steering-committee] Proposal #402 (changes to GADT syntax);
 rec: accept
In-Reply-To: <CAGK9nuqXcdriZkqT5Sb6XaPfwdDC=nBjYDp75mik5=fsNuOS-w@mail.gmail.com>
References: <010f017846f18f9a-b6f06ca5-eac3-4532-94dd-a45bb8260698-000000@us-east-2.amazonses.com>
 <CAGK9nuqXcdriZkqT5Sb6XaPfwdDC=nBjYDp75mik5=fsNuOS-w@mail.gmail.com>
Message-ID: <010f01784bc8030b-9fbc0af7-d51f-4437-af11-e88b71b8461b-000000@us-east-2.amazonses.com>



> On Mar 19, 2021, at 12:18 PM, Iavor Diatchki <iavor.diatchki at gmail.com> wrote:
> 
>    type T = Int -> S
>    data S where C :: T

It's true that this doesn't work today -- and that there are no plans for something like that working. If we were clearer that constructor signatures weren't types, then this case would be easier to understand. Perhaps this is why I'm in favor of dropping the parentheses; allowing them is actually an  exception to the general rule here. (The general rule: the thing after the :: is a `->`-separated list of arguments, terminated by the return type.)

Richard


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20210319/af32f800/attachment.html>

From eric at seidel.io  Sat Mar 20 02:16:22 2021
From: eric at seidel.io (Eric Seidel)
Date: Fri, 19 Mar 2021 22:16:22 -0400
Subject: [ghc-steering-committee]
 =?utf-8?q?Proposal_=23402_=28changes_to_?=
 =?utf-8?q?GADT_syntax=29=3B_rec=3A_accept?=
In-Reply-To: <010f01784bc8030b-9fbc0af7-d51f-4437-af11-e88b71b8461b-000000@us-east-2.amazonses.com>
References: <010f017846f18f9a-b6f06ca5-eac3-4532-94dd-a45bb8260698-000000@us-east-2.amazonses.com>
 <CAGK9nuqXcdriZkqT5Sb6XaPfwdDC=nBjYDp75mik5=fsNuOS-w@mail.gmail.com>
 <010f01784bc8030b-9fbc0af7-d51f-4437-af11-e88b71b8461b-000000@us-east-2.amazonses.com>
Message-ID: <e425b809-8334-4018-8dae-59917d8f4274@www.fastmail.com>

My intuition behind GADT syntax has always been that it looks like type syntax because sometimes we really just want to write down the constructor's type. The original motivation was to let us specify the result type, but this proposal gives us another reason around controlling the placement of foralls.

If GADT signatures are supposed to feel like types, then we should seek to minimize the differences. That would mean keeping optional parens and allowing control over the placement of foralls. Iavor's example of type synonyms is another inconsistency that doesn't seem to be motivated by a technical reason.

On the other hand, if we want to convey that GADTs signatures are not types, then we should not reuse the `->`. We could instead write something like

  data T a where
    C1 Int :: T Int
    C2 !Bool :: T Bool
    C3 { a :: Int, b :: !Bool } :: T (Int, Bool)

Those signatures are very clearly not types.

Eric

On Fri, Mar 19, 2021, at 14:38, Richard Eisenberg wrote:
> 
> 
> > On Mar 19, 2021, at 12:18 PM, Iavor Diatchki <iavor.diatchki at gmail.com> wrote:
> > 
> >    type T = Int -> S
> >    data S where C :: T
> 
> It's true that this doesn't work today -- and that there are no plans 
> for something like that working. If we were clearer that constructor 
> signatures weren't types, then this case would be easier to understand. 
> Perhaps this is why I'm in favor of dropping the parentheses; allowing 
> them is actually an  exception to the general rule here. (The general 
> rule: the thing after the :: is a `->`-separated list of arguments, 
> terminated by the return type.)
> 
> Richard
> 
> 
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org <mailto:ghc-steering-committee%40haskell.org>
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>

From rae at richarde.dev  Mon Mar 22 13:45:29 2021
From: rae at richarde.dev (Richard Eisenberg)
Date: Mon, 22 Mar 2021 13:45:29 +0000
Subject: [ghc-steering-committee] Proposal #402 (changes to GADT syntax);
 rec: accept
In-Reply-To: <e425b809-8334-4018-8dae-59917d8f4274@www.fastmail.com>
References: <010f017846f18f9a-b6f06ca5-eac3-4532-94dd-a45bb8260698-000000@us-east-2.amazonses.com>
 <CAGK9nuqXcdriZkqT5Sb6XaPfwdDC=nBjYDp75mik5=fsNuOS-w@mail.gmail.com>
 <010f01784bc8030b-9fbc0af7-d51f-4437-af11-e88b71b8461b-000000@us-east-2.amazonses.com>
 <e425b809-8334-4018-8dae-59917d8f4274@www.fastmail.com>
Message-ID: <010f01785a2ef1cc-13378a12-969b-47a8-93d0-31066ec87ea3-000000@us-east-2.amazonses.com>



> On Mar 19, 2021, at 10:16 PM, Eric Seidel <eric at seidel.io> wrote:
> 
> Iavor's example of type synonyms is another inconsistency that doesn't seem to be motivated by a technical reason.

Good point. I suppose if we did allow type synonyms there, then GADT sigs really would become more like a superset of the grammar for types.

Note that Agda can pull this off:

> data T : Set
> 
> syn : Set
> syn = ℕ → T
> 
> syn2 : Bool → Set
> syn2 false = ℕ → T
> syn2 true = T
> 
> data T where
>   MkT : syn
>   MkT2 : syn2 false
>   MkT3 : syn2 true

This is accepted. `syn` is like a type synonym, while `syn2` is like a type family. I don't like having Agda out in front of Haskell in this way. :( Maybe we should just fix these problems instead of banning parens?

Richard
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20210322/9d3a41f8/attachment.html>

From eric at seidel.io  Mon Mar 22 13:59:12 2021
From: eric at seidel.io (Eric Seidel)
Date: Mon, 22 Mar 2021 09:59:12 -0400
Subject: [ghc-steering-committee]
 =?utf-8?q?Proposal_=23402_=28changes_to_?=
 =?utf-8?q?GADT_syntax=29=3B_rec=3A_accept?=
In-Reply-To: <010f01785a2ef1cc-13378a12-969b-47a8-93d0-31066ec87ea3-000000@us-east-2.amazonses.com>
References: <010f017846f18f9a-b6f06ca5-eac3-4532-94dd-a45bb8260698-000000@us-east-2.amazonses.com>
 <CAGK9nuqXcdriZkqT5Sb6XaPfwdDC=nBjYDp75mik5=fsNuOS-w@mail.gmail.com>
 <010f01784bc8030b-9fbc0af7-d51f-4437-af11-e88b71b8461b-000000@us-east-2.amazonses.com>
 <e425b809-8334-4018-8dae-59917d8f4274@www.fastmail.com>
 <010f01785a2ef1cc-13378a12-969b-47a8-93d0-31066ec87ea3-000000@us-east-2.amazonses.com>
Message-ID: <8022cc7b-f5f6-4b6f-b339-83ae31f99d97@www.fastmail.com>

If we can get it to the point where GADT signatures are truly a superset of type signatures, then we could unify the two in the parser. We would always parse the superset and reject disallowed signatures, e.g. UNPACK pragmas in function types, with much better error messages! I think that would be a much better solution than banning parens in GADT sigs.

On Mon, Mar 22, 2021, at 09:45, Richard Eisenberg wrote:
> 
> 
> > On Mar 19, 2021, at 10:16 PM, Eric Seidel <eric at seidel.io> wrote:
> > 
> > Iavor's example of type synonyms is another inconsistency that doesn't seem to be motivated by a technical reason.
> 
> Good point. I suppose if we did allow type synonyms there, then GADT 
> sigs really would become more like a superset of the grammar for types.
> 
> Note that Agda can pull this off:
> 
> > data T : Set
> > 
> > syn : Set
> > syn = ℕ → T
> > 
> > syn2 : Bool → Set
> > syn2 false = ℕ → T
> > syn2 true = T
> > 
> > data T where
> >   MkT : syn
> >   MkT2 : syn2 false
> >   MkT3 : syn2 true
> 
> This is accepted. `syn` is like a type synonym, while `syn2` is like a 
> type family. I don't like having Agda out in front of Haskell in this 
> way. :( Maybe we should just fix these problems instead of banning 
> parens?
> 
> Richard

From iavor.diatchki at gmail.com  Mon Mar 22 16:17:23 2021
From: iavor.diatchki at gmail.com (Iavor Diatchki)
Date: Mon, 22 Mar 2021 09:17:23 -0700
Subject: [ghc-steering-committee] Proposal #402 (changes to GADT syntax);
 rec: accept
In-Reply-To: <8022cc7b-f5f6-4b6f-b339-83ae31f99d97@www.fastmail.com>
References: <010f017846f18f9a-b6f06ca5-eac3-4532-94dd-a45bb8260698-000000@us-east-2.amazonses.com>
 <CAGK9nuqXcdriZkqT5Sb6XaPfwdDC=nBjYDp75mik5=fsNuOS-w@mail.gmail.com>
 <010f01784bc8030b-9fbc0af7-d51f-4437-af11-e88b71b8461b-000000@us-east-2.amazonses.com>
 <e425b809-8334-4018-8dae-59917d8f4274@www.fastmail.com>
 <010f01785a2ef1cc-13378a12-969b-47a8-93d0-31066ec87ea3-000000@us-east-2.amazonses.com>
 <8022cc7b-f5f6-4b6f-b339-83ae31f99d97@www.fastmail.com>
Message-ID: <CAGK9nuoqpo_XiVj1cgWtAZBaywV0JBHu0Mw9ewY1_cyUfFD0wg@mail.gmail.com>

Just FYI, I believe they are already unified in the parser---GHC always
parses "something like a type" and then validates it to make sure that all
the extras make sense in the given context.    I am not sure when the
validity check for GADTs happens, but I suspect if the check is delayed
sufficiently, GHC could simply "look through the type synonym" to make sure
the declaration is OK, which would make the example I gave work, if that's
what we wanted.

So, I suspect the issue here is more of design, and technically it
shouldn't be hard to make the changes one way or another.

-Iavor

On Mon, Mar 22, 2021 at 6:59 AM Eric Seidel <eric at seidel.io> wrote:

> If we can get it to the point where GADT signatures are truly a superset
> of type signatures, then we could unify the two in the parser. We would
> always parse the superset and reject disallowed signatures, e.g. UNPACK
> pragmas in function types, with much better error messages! I think that
> would be a much better solution than banning parens in GADT sigs.
>
> On Mon, Mar 22, 2021, at 09:45, Richard Eisenberg wrote:
> >
> >
> > > On Mar 19, 2021, at 10:16 PM, Eric Seidel <eric at seidel.io> wrote:
> > >
> > > Iavor's example of type synonyms is another inconsistency that doesn't
> seem to be motivated by a technical reason.
> >
> > Good point. I suppose if we did allow type synonyms there, then GADT
> > sigs really would become more like a superset of the grammar for types.
> >
> > Note that Agda can pull this off:
> >
> > > data T : Set
> > >
> > > syn : Set
> > > syn = ℕ → T
> > >
> > > syn2 : Bool → Set
> > > syn2 false = ℕ → T
> > > syn2 true = T
> > >
> > > data T where
> > >   MkT : syn
> > >   MkT2 : syn2 false
> > >   MkT3 : syn2 true
> >
> > This is accepted. `syn` is like a type synonym, while `syn2` is like a
> > type family. I don't like having Agda out in front of Haskell in this
> > way. :( Maybe we should just fix these problems instead of banning
> > parens?
> >
> > Richard
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20210322/d44fc187/attachment.html>

From simonpj at microsoft.com  Mon Mar 22 22:32:28 2021
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Mon, 22 Mar 2021 22:32:28 +0000
Subject: [ghc-steering-committee] Proposal #402 (changes to GADT syntax);
 rec: accept
In-Reply-To: <8022cc7b-f5f6-4b6f-b339-83ae31f99d97@www.fastmail.com>
References: <010f017846f18f9a-b6f06ca5-eac3-4532-94dd-a45bb8260698-000000@us-east-2.amazonses.com>
 <CAGK9nuqXcdriZkqT5Sb6XaPfwdDC=nBjYDp75mik5=fsNuOS-w@mail.gmail.com>
 <010f01784bc8030b-9fbc0af7-d51f-4437-af11-e88b71b8461b-000000@us-east-2.amazonses.com>
 <e425b809-8334-4018-8dae-59917d8f4274@www.fastmail.com>
 <010f01785a2ef1cc-13378a12-969b-47a8-93d0-31066ec87ea3-000000@us-east-2.amazonses.com>
 <8022cc7b-f5f6-4b6f-b339-83ae31f99d97@www.fastmail.com>
Message-ID: <AM0PR83MB0276A06FC0C824CF6C701D15AD659@AM0PR83MB0276.EURPRD83.prod.outlook.com>

Let's not get too bogged down in implementation.

The only question we have on the table, really is

     What do we want to be legal in a data constructor signature?

I've posted on the GitHub thread.

Simon

|  -----Original Message-----
|  From: ghc-steering-committee <ghc-steering-committee-
|  bounces at haskell.org> On Behalf Of Eric Seidel
|  Sent: 22 March 2021 13:59
|  To: ghc-steering-committee at haskell.org
|  Subject: Re: [ghc-steering-committee] Proposal #402 (changes to GADT
|  syntax); rec: accept
|  
|  If we can get it to the point where GADT signatures are truly a
|  superset of type signatures, then we could unify the two in the
|  parser. We would always parse the superset and reject disallowed
|  signatures, e.g. UNPACK pragmas in function types, with much better
|  error messages! I think that would be a much better solution than
|  banning parens in GADT sigs.
|  
|  On Mon, Mar 22, 2021, at 09:45, Richard Eisenberg wrote:
|  >
|  >
|  > > On Mar 19, 2021, at 10:16 PM, Eric Seidel <eric at seidel.io> wrote:
|  > >
|  > > Iavor's example of type synonyms is another inconsistency that
|  doesn't seem to be motivated by a technical reason.
|  >
|  > Good point. I suppose if we did allow type synonyms there, then GADT
|  > sigs really would become more like a superset of the grammar for
|  types.
|  >
|  > Note that Agda can pull this off:
|  >
|  > > data T : Set
|  > >
|  > > syn : Set
|  > > syn = ℕ → T
|  > >
|  > > syn2 : Bool → Set
|  > > syn2 false = ℕ → T
|  > > syn2 true = T
|  > >
|  > > data T where
|  > >   MkT : syn
|  > >   MkT2 : syn2 false
|  > >   MkT3 : syn2 true
|  >
|  > This is accepted. `syn` is like a type synonym, while `syn2` is like
|  a
|  > type family. I don't like having Agda out in front of Haskell in
|  this
|  > way. :( Maybe we should just fix these problems instead of banning
|  > parens?
|  >
|  > Richard
|  _______________________________________________
|  ghc-steering-committee mailing list
|  ghc-steering-committee at haskell.org
|  https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail
|  .haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-
|  committee&amp;data=04%7C01%7Csimonpj%40microsoft.com%7C760a5c3d8a5d480
|  1ec3908d8ed3ac0a4%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6375201
|  83896349666%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMz
|  IiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=3CX3NinWswOHBXKcylYM
|  F%2FCsvMcek2PTvTxnczluaSw%3D&amp;reserved=0

From mail at joachim-breitner.de  Sat Mar 27 16:54:25 2021
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Sat, 27 Mar 2021 17:54:25 +0100
Subject: [ghc-steering-committee] Please review #371: Exporting ~ from
 Data.Type.Equality, Shepherd: Richard
Message-ID: <6a12f7f3060922534dec502f34fcc58dc13f8426.camel@joachim-breitner.de>

Dear Committe,

Exporting ~ from Data.Type.Equality
has been proposed by Vladislav Zavialov
https://github.com/ghc-proposals/ghc-proposals/pull/371
https://github.com/int-index/ghc-proposals/blob/non-magical-eq/proposals/0000-non-magical-eq.md

This looks rather small, and Richard has already vetted and refined
this, in particular about the migration story, so I think he could just
as well shepherd this through.

Please guide us to a conclusion as outlined in 
https://github.com/ghc-proposals/ghc-proposals#committee-process

Thanks,
Joachim
-- 
-- 
Joachim Breitner
  mail at joachim-breitner.de
  http://www.joachim-breitner.de/



From simonpj at microsoft.com  Mon Mar 29 12:17:28 2021
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Mon, 29 Mar 2021 12:17:28 +0000
Subject: [ghc-steering-committee] Recommendation for #378: support the
	design for dependent types
Message-ID: <AM0PR83MB02766DCF828C0055859AA718AD7E9@AM0PR83MB0276.EURPRD83.prod.outlook.com>

Dear GHC Steering Committee
I'm recommending acceptance of Proposal #378: Support the design for dependent types<https://github.com/ghc-proposals/ghc-proposals/pull/378>
As you'll see, there is a lot of useful context, but the payload is pretty simple

When evaluating new proposals, the GHC committee would consider compatibility with the proposed design sketch of dependent types on the GHC wiki<https://gitlab.haskell.org/ghc/ghc/-/wikis/dependent-haskell>. Generally speaking, new proposals should be forward-compatible with the design sketch; that is, the new features proposed would continue to be at home when surrounded by other dependent-type features.

Of course, the committee remains free to revise the design sketch or to accept proposals that encroach upon it (i.e. contradicting this guidance), but such choices should be made explicitly.

See also the committee's Review Criteria<https://github.com/ghc-proposals/ghc-proposals/#review-criteria>: put another way, this proposal says that we consider the design sketch alongside other features of today's Haskell when assessing a new proposal's fit with the language.

Note that compatibility with dependent types is far from the only criterion the committee would use to evaluate a proposal. Other review criteria, such as learnability, clarity of error messages, performance, etc., remain just as ever.
Any views?  Let's try to converge rapidly.... the proposal has been substantially refined by a lot of debate.
Simon
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20210329/8fa5f813/attachment.html>

From iavor.diatchki at gmail.com  Mon Mar 29 16:39:56 2021
From: iavor.diatchki at gmail.com (Iavor Diatchki)
Date: Mon, 29 Mar 2021 09:39:56 -0700
Subject: [ghc-steering-committee] Recommendation for #378: support the
 design for dependent types
In-Reply-To: <AM0PR83MB02766DCF828C0055859AA718AD7E9@AM0PR83MB0276.EURPRD83.prod.outlook.com>
References: <AM0PR83MB02766DCF828C0055859AA718AD7E9@AM0PR83MB0276.EURPRD83.prod.outlook.com>
Message-ID: <CAGK9nuqJPSYdsQ4Ws5Xe=E=5p=93aO1q2c_viPgBoB5hKut_RA@mail.gmail.com>

Hello,

my preference would be to reject this proposal, and turn the "proposed
design for dependent haskell" (the link in Simon's e-mail) into its own
proposal so that we can discuss it, and suggest changes.   It seems really
odd to agree to adhere to a design that we never discussed.

By the way, it's really great to finally see something written down about
the actual design of DH.  I had a quick read, and I have some questions,
which is why I think it makes more sense to have the design as its own
proposal.  In particular, it seems to me like it might be quite possible to
split the DH design into a collection of separate extensions, which might
make it easier to understand, although I don't fully understand the whole
picture, and might be wrong about that.

-Iavor






On Mon, Mar 29, 2021 at 5:17 AM Simon Peyton Jones via
ghc-steering-committee <ghc-steering-committee at haskell.org> wrote:

> Dear GHC Steering Committee
>
> I’m recommending acceptance of Proposal #378: Support the design for
> dependent types <https://github.com/ghc-proposals/ghc-proposals/pull/378>
>
> As you’ll see, there is a lot of useful context, but the payload is pretty
> simple
>
> *When evaluating new proposals, the GHC committee would consider
> compatibility with the proposed design sketch of dependent types on the GHC
> wiki <https://gitlab.haskell.org/ghc/ghc/-/wikis/dependent-haskell>.
> Generally speaking, new proposals should be forward-compatible with the
> design sketch; that is, the new features proposed would continue to be at
> home when surrounded by other dependent-type features.*
>
> *Of course, the committee remains free to revise the design sketch or to
> accept proposals that encroach upon it (i.e. contradicting this guidance),
> but such choices should be made explicitly.*
>
> *See also the committee's Review Criteria
> <https://github.com/ghc-proposals/ghc-proposals/#review-criteria>: put
> another way, this proposal says that we consider the design sketch
> alongside other features of today's Haskell when assessing a new proposal's
> fit with the language.*
>
> *Note that compatibility with dependent types is far from the only
> criterion the committee would use to evaluate a proposal. Other review
> criteria, such as learnability, clarity of error messages, performance,
> etc., remain just as ever.*
>
> Any views?  Let’s try to converge rapidly…. the proposal has been
> substantially refined by a lot of debate.
>
> Simon
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20210329/56b07c95/attachment.html>

From rae at richarde.dev  Tue Mar 30 03:27:05 2021
From: rae at richarde.dev (Richard Eisenberg)
Date: Tue, 30 Mar 2021 03:27:05 +0000
Subject: [ghc-steering-committee] Recommendation for #378: support the
 design for dependent types
In-Reply-To: <CAGK9nuqJPSYdsQ4Ws5Xe=E=5p=93aO1q2c_viPgBoB5hKut_RA@mail.gmail.com>
References: <AM0PR83MB02766DCF828C0055859AA718AD7E9@AM0PR83MB0276.EURPRD83.prod.outlook.com>
 <CAGK9nuqJPSYdsQ4Ws5Xe=E=5p=93aO1q2c_viPgBoB5hKut_RA@mail.gmail.com>
Message-ID: <010f0178812ba956-adfc97cc-9971-4997-bd0a-de1c59c7ba43-000000@us-east-2.amazonses.com>

Iavor raises an interesting point.

I wrote Proposal #378 in the way I did (somewhat vaguely, about design decisions made by the committee) because I hadn't yet pinned down exactly what DH was in a way that would make for a more proper proposal. I knew we needed the Syntactic Unification Principle and some of the other high-level goals, but I hadn't articulated these to myself or to anyone else.

However, thanks to Simon PJ's patient help and then initiative in starting https://gitlab.haskell.org/ghc/ghc/-/wikis/dependent-haskell, we now have something much closer to a proper proposal than I expected to end up with. It's not exactly fully specified in a few places, but I think this page is good enough to consider for some sort of conditional approval. Then, maybe we could get to implementing it (perhaps in pieces) and use that real experience to refine the proposal and revisit the conditional acceptance via modifications to the design.

What do others think? I'm happy to rephrase #378 as a more proper proposal (albeit seeking only conditional acceptance) if we think it's mature enough to.

However, if the current text is not mature enough to form the basis of a more proper proposal, I do not wish to invest lots and lots more time in fleshing out a general direction that the committee is uninterested in. So perhaps the real goal of my writing #378 is to surface the appetite of the committee in pursuing this direction. There is always a chicken-and-egg problem in making a choice about direction, in that it's hard to know the pros and cons of an unexplored avenue of inquiry. But maybe we have enough information now that we can make such a decision without further anticipatory exploration.

Thanks,
Richard

> On Mar 29, 2021, at 12:39 PM, Iavor Diatchki <iavor.diatchki at gmail.com> wrote:
> 
> Hello,
> 
> my preference would be to reject this proposal, and turn the "proposed design for dependent haskell" (the link in Simon's e-mail) into its own proposal so that we can discuss it, and suggest changes.   It seems really odd to agree to adhere to a design that we never discussed.
>  
> By the way, it's really great to finally see something written down about the actual design of DH.  I had a quick read, and I have some questions, which is why I think it makes more sense to have the design as its own proposal.  In particular, it seems to me like it might be quite possible to split the DH design into a collection of separate extensions, which might make it easier to understand, although I don't fully understand the whole picture, and might be wrong about that.
> 
> -Iavor
> 
> 
> 
> 
> 
> 
> On Mon, Mar 29, 2021 at 5:17 AM Simon Peyton Jones via ghc-steering-committee <ghc-steering-committee at haskell.org <mailto:ghc-steering-committee at haskell.org>> wrote:
> Dear GHC Steering Committee
> 
> I’m recommending acceptance of Proposal #378: Support the design for dependent types <https://github.com/ghc-proposals/ghc-proposals/pull/378>
> As you’ll see, there is a lot of useful context, but the payload is pretty simple
> 
> When evaluating new proposals, the GHC committee would consider compatibility with the proposed design sketch of dependent types on the GHC wiki <https://gitlab.haskell.org/ghc/ghc/-/wikis/dependent-haskell>. Generally speaking, new proposals should be forward-compatible with the design sketch; that is, the new features proposed would continue to be at home when surrounded by other dependent-type features.
> 
> Of course, the committee remains free to revise the design sketch or to accept proposals that encroach upon it (i.e. contradicting this guidance), but such choices should be made explicitly.
> 
> See also the committee's Review Criteria <https://github.com/ghc-proposals/ghc-proposals/#review-criteria>: put another way, this proposal says that we consider the design sketch alongside other features of today's Haskell when assessing a new proposal's fit with the language.
> 
> Note that compatibility with dependent types is far from the only criterion the committee would use to evaluate a proposal. Other review criteria, such as learnability, clarity of error messages, performance, etc., remain just as ever.
> 
> Any views?  Let’s try to converge rapidly…. the proposal has been substantially refined by a lot of debate.
> 
> Simon
> 
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org <mailto:ghc-steering-committee at haskell.org>
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee <https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee>
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20210330/a1b4c52d/attachment-0001.html>

From eric at seidel.io  Tue Mar 30 12:54:34 2021
From: eric at seidel.io (Eric Seidel)
Date: Tue, 30 Mar 2021 08:54:34 -0400
Subject: [ghc-steering-committee]
 =?utf-8?q?Recommendation_for_=23378=3A_s?=
 =?utf-8?q?upport_the_design_for_dependent_types?=
In-Reply-To: <010f0178812ba956-adfc97cc-9971-4997-bd0a-de1c59c7ba43-000000@us-east-2.amazonses.com>
References: <AM0PR83MB02766DCF828C0055859AA718AD7E9@AM0PR83MB0276.EURPRD83.prod.outlook.com>
 <CAGK9nuqJPSYdsQ4Ws5Xe=E=5p=93aO1q2c_viPgBoB5hKut_RA@mail.gmail.com>
 <010f0178812ba956-adfc97cc-9971-4997-bd0a-de1c59c7ba43-000000@us-east-2.amazonses.com>
Message-ID: <e94b5cf3-4a04-4293-9052-53915c05ae7d@www.fastmail.com>

I think I would also prefer to have a more concrete proposal that we would conditionally accept. The only thing to be careful about is to make clear which parts of the design you consider absolutely necessary (eg the unification of type and term syntax) and which you consider more up for debate and refinement.

On Mon, Mar 29, 2021, at 23:27, Richard Eisenberg wrote:
> Iavor raises an interesting point.
> 
> I wrote Proposal #378 in the way I did (somewhat vaguely, about design 
> decisions made by the committee) because I hadn't yet pinned down 
> exactly what DH was in a way that would make for a more proper 
> proposal. I knew we needed the Syntactic Unification Principle and some 
> of the other high-level goals, but I hadn't articulated these to myself 
> or to anyone else.
> 
> However, thanks to Simon PJ's patient help and then initiative in 
> starting https://gitlab.haskell.org/ghc/ghc/-/wikis/dependent-haskell, 
> we now have something much closer to a proper proposal than I expected 
> to end up with. It's not exactly fully specified in a few places, but I 
> think this page is good enough to consider for some sort of conditional 
> approval. Then, maybe we could get to implementing it (perhaps in 
> pieces) and use that real experience to refine the proposal and revisit 
> the conditional acceptance via modifications to the design.
> 
> What do others think? I'm happy to rephrase #378 as a more proper 
> proposal (albeit seeking only conditional acceptance) if we think it's 
> mature enough to.
> 
> However, if the current text is not mature enough to form the basis of 
> a more proper proposal, I do not wish to invest lots and lots more time 
> in fleshing out a general direction that the committee is uninterested 
> in. So perhaps the real goal of my writing #378 is to surface the 
> appetite of the committee in pursuing this direction. There is always a 
> chicken-and-egg problem in making a choice about direction, in that 
> it's hard to know the pros and cons of an unexplored avenue of inquiry. 
> But maybe we have enough information now that we can make such a 
> decision without further anticipatory exploration.
> 
> Thanks,
> Richard
> 
> > On Mar 29, 2021, at 12:39 PM, Iavor Diatchki <iavor.diatchki at gmail.com> wrote:
> > 
> > Hello,
> > 
> > my preference would be to reject this proposal, and turn the "proposed design for dependent haskell" (the link in Simon's e-mail) into its own proposal so that we can discuss it, and suggest changes.   It seems really odd to agree to adhere to a design that we never discussed.
> >  
> > By the way, it's really great to finally see something written down about the actual design of DH.  I had a quick read, and I have some questions, which is why I think it makes more sense to have the design as its own proposal.  In particular, it seems to me like it might be quite possible to split the DH design into a collection of separate extensions, which might make it easier to understand, although I don't fully understand the whole picture, and might be wrong about that.
> > 
> > -Iavor
> > 
> > 
> > 
> > 
> > 
> > 
> > On Mon, Mar 29, 2021 at 5:17 AM Simon Peyton Jones via ghc-steering-committee <ghc-steering-committee at haskell.org> wrote:
> >> Dear GHC Steering Committee____
> 
> >> I’m recommending acceptance of Proposal #378: Support the design for dependent types <https://github.com/ghc-proposals/ghc-proposals/pull/378>____
> 
> >> As you’ll see, there is a lot of useful context, but the payload is pretty simple____
> 
> >> *When evaluating new proposals, the GHC committee would consider compatibility with the proposed design sketch of dependent types on the GHC wiki <https://gitlab.haskell.org/ghc/ghc/-/wikis/dependent-haskell>. Generally speaking, new proposals should be forward-compatible with the design sketch; that is, the new features proposed would continue to be at home when surrounded by other dependent-type features.____*
> 
> >> *Of course, the committee remains free to revise the design sketch or to accept proposals that encroach upon it (i.e. contradicting this guidance), but such choices should be made explicitly.____*
> 
> >> *See also the committee's Review Criteria <https://github.com/ghc-proposals/ghc-proposals/#review-criteria>: put another way, this proposal says that we consider the design sketch alongside other features of today's Haskell when assessing a new proposal's fit with the language.____*
> 
> >> *Note that compatibility with dependent types is far from the only criterion the committee would use to evaluate a proposal. Other review criteria, such as learnability, clarity of error messages, performance, etc., remain just as ever.____*
> 
> >> Any views?  Let’s try to converge rapidly…. the proposal has been substantially refined by a lot of debate.____
> 
> >> Simon____
> 
> >> _______________________________________________
> >> ghc-steering-committee mailing list
> >> ghc-steering-committee at haskell.org
> >> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
> > _______________________________________________
> > ghc-steering-committee mailing list
> > ghc-steering-committee at haskell.org
> > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
> 
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org <mailto:ghc-steering-committee%40haskell.org>
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>

From bravit111 at gmail.com  Tue Mar 30 13:08:42 2021
From: bravit111 at gmail.com (Vitaly Bragilevsky)
Date: Tue, 30 Mar 2021 16:08:42 +0300
Subject: [ghc-steering-committee] Recommendation for #378: support the
 design for dependent types
In-Reply-To: <AM0PR83MB02766DCF828C0055859AA718AD7E9@AM0PR83MB0276.EURPRD83.prod.outlook.com>
References: <AM0PR83MB02766DCF828C0055859AA718AD7E9@AM0PR83MB0276.EURPRD83.prod.outlook.com>
Message-ID: <CALpVSmPU4v91riTs33193L-NLBdZzikT4yBjF-+s0LxPC34dXg@mail.gmail.com>

I don't see this proposal as a proper GHC proposal. I don't think we should
accept or reject it. We don't have a formal check for committee criteria
anyway. Am I in support of introducing DH into GHC? Yes, I am. But then
I'll be more inclined to support Richard's objections to any other
proposals if they contradict the DH design sketch. I don't need to swear to
follow these additional criteria.

Vitaly


пн, 29 мар. 2021 г. в 15:17, Simon Peyton Jones via ghc-steering-committee <
ghc-steering-committee at haskell.org>:

> Dear GHC Steering Committee
>
> I’m recommending acceptance of Proposal #378: Support the design for
> dependent types <https://github.com/ghc-proposals/ghc-proposals/pull/378>
>
> As you’ll see, there is a lot of useful context, but the payload is pretty
> simple
>
> *When evaluating new proposals, the GHC committee would consider
> compatibility with the proposed design sketch of dependent types on the GHC
> wiki <https://gitlab.haskell.org/ghc/ghc/-/wikis/dependent-haskell>.
> Generally speaking, new proposals should be forward-compatible with the
> design sketch; that is, the new features proposed would continue to be at
> home when surrounded by other dependent-type features.*
>
> *Of course, the committee remains free to revise the design sketch or to
> accept proposals that encroach upon it (i.e. contradicting this guidance),
> but such choices should be made explicitly.*
>
> *See also the committee's Review Criteria
> <https://github.com/ghc-proposals/ghc-proposals/#review-criteria>: put
> another way, this proposal says that we consider the design sketch
> alongside other features of today's Haskell when assessing a new proposal's
> fit with the language.*
>
> *Note that compatibility with dependent types is far from the only
> criterion the committee would use to evaluate a proposal. Other review
> criteria, such as learnability, clarity of error messages, performance,
> etc., remain just as ever.*
>
> Any views?  Let’s try to converge rapidly…. the proposal has been
> substantially refined by a lot of debate.
>
> Simon
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20210330/af7df3f8/attachment.html>

From rae at richarde.dev  Wed Mar 31 00:50:20 2021
From: rae at richarde.dev (Richard Eisenberg)
Date: Wed, 31 Mar 2021 00:50:20 +0000
Subject: [ghc-steering-committee] #371: Stop treating ~ magically. Rec: weak
	accept
Message-ID: <010f017885c281e2-ddc4c62f-b5e8-4829-bdf2-aab06bbd99f3-000000@us-east-2.amazonses.com>

Hi all,

I am shepherding proposal #371.

Proposal: https://github.com/int-index/ghc-proposals/blob/non-magical-eq/proposals/0000-non-magical-eq.md
Discussion: https://github.com/ghc-proposals/ghc-proposals/pull/371

Summary:

Currently, the type equality operator (~) is always in scope, but you can use it only if -XGADTs or -XTypeFamilies is enabled. The proposal instead changes this arrangement to export (~) from Data.Type.Equality (an existing module in `base`), and requiring -XTypeOperators to use it (as we do for all other infix operators in types). There is an 8-release migration plan, where for 6 releases, all uses of (~) that do not import it from Data.Type.Equality will get a warning telling the user to import Data.Type.Equality.

The motivation for the proposal is uniformity: the goal is to treat (~) just like other type operators.

Recommendation:

I'm very much on the fence on this one, but in the end fall into the "accept" camp. The goal here is to achieve a simple cleanup in the language design (and implementation). It's a worthy goal, but it's disruptive. However, I think the disruption is small enough that it motivates the change. The fix for affected users is quite quick, and large-scale Haskell users probably already have a custom prelude that could make the change even easier to accommodate. Note also that TypeOperators is part of GHC2021, and so the change will likely only be a new import.

What do others think?

Without dissent, I will mark this proposal as accepted in two weeks.

Thanks,
Richard

From arnaud.spiwack at tweag.io  Wed Mar 31 14:29:32 2021
From: arnaud.spiwack at tweag.io (Spiwack, Arnaud)
Date: Wed, 31 Mar 2021 16:29:32 +0200
Subject: [ghc-steering-committee] #371: Stop treating ~ magically. Rec:
 weak accept
In-Reply-To: <010f017885c281e2-ddc4c62f-b5e8-4829-bdf2-aab06bbd99f3-000000@us-east-2.amazonses.com>
References: <010f017885c281e2-ddc4c62f-b5e8-4829-bdf2-aab06bbd99f3-000000@us-east-2.amazonses.com>
Message-ID: <CAH6fHQkzB=CuNWXhWqGJ4UR2zB8HkeFkA7F09iYC9_AVB_gd+Q@mail.gmail.com>

This looks very minor. I'm not convinced that it is worth the hassle (that
being said, it is not hard to write code that is both forward and backward
compatible, so maybe there won't be much headache).

The proposal says

> The compiler internals are simplified, in particular things described in Note
[eqTyCon (~) is built-in syntax].

That's the really appetizing part (the fact that `~` will have a Haddock
documentation is not bad either). Those of us who have been involved in the
parts of the compiler that are touched here: do you think this is a
worthwhile simplification? That would secure my vote.

On Wed, Mar 31, 2021 at 2:50 AM Richard Eisenberg <rae at richarde.dev> wrote:

> Hi all,
>
> I am shepherding proposal #371.
>
> Proposal:
> https://github.com/int-index/ghc-proposals/blob/non-magical-eq/proposals/0000-non-magical-eq.md
> Discussion: https://github.com/ghc-proposals/ghc-proposals/pull/371
>
> Summary:
>
> Currently, the type equality operator (~) is always in scope, but you can
> use it only if -XGADTs or -XTypeFamilies is enabled. The proposal instead
> changes this arrangement to export (~) from Data.Type.Equality (an existing
> module in `base`), and requiring -XTypeOperators to use it (as we do for
> all other infix operators in types). There is an 8-release migration plan,
> where for 6 releases, all uses of (~) that do not import it from
> Data.Type.Equality will get a warning telling the user to import
> Data.Type.Equality.
>
> The motivation for the proposal is uniformity: the goal is to treat (~)
> just like other type operators.
>
> Recommendation:
>
> I'm very much on the fence on this one, but in the end fall into the
> "accept" camp. The goal here is to achieve a simple cleanup in the language
> design (and implementation). It's a worthy goal, but it's disruptive.
> However, I think the disruption is small enough that it motivates the
> change. The fix for affected users is quite quick, and large-scale Haskell
> users probably already have a custom prelude that could make the change
> even easier to accommodate. Note also that TypeOperators is part of
> GHC2021, and so the change will likely only be a new import.
>
> What do others think?
>
> Without dissent, I will mark this proposal as accepted in two weeks.
>
> Thanks,
> Richard
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20210331/eb0ef689/attachment.html>