Hi, Am Mittwoch, den 17.04.2019, 13:38 -0500 schrieb Christopher Allen:

I gave my recommendation for ExtraCommas, acceptance of the original proposal as written. I talk with the proposer almost every day so I know where he stands. He still thinks it's worth doing and would like to see it accepted. I think ExtraCommas merits acceptance. If we can't achieve consensus on it then it should be rejected so it gets cleared off the slate. I'm not inclined to argue a syntactic extension like this, but I will say this:

The proposal captures a nice design element that we've seen work very well ergonomically in Rust. We're never going to make the same decisions with the same tradeoffs as a totally different language but any time there is a relatively isolated "good idea" like this, I'd like to see us try to take advantage of that and see if it works for us.

thanks for picking this up. The most contentious point, besides whether its worth the bother at all, was the interaction with TupleSections. Which gives us three options, I think: * reject * accept, covering tuples (and making it conflict with TupleSections) * accept, not covering tuples. No decision is absolutely wrong, none is obviously right. Maybe we should simply do a vote, to get it decided? Simons (as Chairs), what do you think? Cheers, Joachim -- Joachim Breitner mail@joachim-breitner.de http://www.joachim-breitner.de/

I favor accepting the proposal, with or without tuples. I've been writing a bit of Rust recently, and agree with Chris about the ergonomics of trailing commas. On Wed, Apr 17, 2019, at 18:31, Joachim Breitner wrote:

Hi,

Am Mittwoch, den 17.04.2019, 13:38 -0500 schrieb Christopher Allen:

...

I gave my recommendation for ExtraCommas, acceptance of the original proposal as written. I talk with the proposer almost every day so I know where he stands. He still thinks it's worth doing and would like to see it accepted. I think ExtraCommas merits acceptance. If we can't achieve consensus on it then it should be rejected so it gets cleared off the slate. I'm not inclined to argue a syntactic extension like this, but I will say this:

The proposal captures a nice design element that we've seen work very well ergonomically in Rust. We're never going to make the same decisions with the same tradeoffs as a totally different language but any time there is a relatively isolated "good idea" like this, I'd like to see us try to take advantage of that and see if it works for us.

thanks for picking this up.

The most contentious point, besides whether its worth the bother at all, was the interaction with TupleSections. Which gives us three options, I think: * reject * accept, covering tuples (and making it conflict with TupleSections) * accept, not covering tuples.

No decision is absolutely wrong, none is obviously right.

Maybe we should simply do a vote, to get it decided? Simons (as Chairs), what do you think?

Cheers, Joachim

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

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

Attachments: * signature.asc

But it's actually *incompatible* with TupleSections, so how shoule (True,) be interpreted if both are on? S | -----Original Message----- | From: ghc-steering-committee | On Behalf Of Christopher Allen | Sent: 18 April 2019 04:19 | To: Eric Seidel | Cc: ghc-steering-committee@haskell.org | Subject: Re: [ghc-steering-committee] Extra Commas | | I spoke with Matt, he's fine either way with or without tuples. | | I'd prefer "with tuples" for consistency. I use tuples sometimes, but | don't care about sectioning. | | On Wed, Apr 17, 2019 at 8:15 PM Eric Seidel wrote: | > | > I favor accepting the proposal, with or without tuples. I've been | writing a bit of Rust recently, and agree with Chris about the ergonomics | of trailing commas. | > | > On Wed, Apr 17, 2019, at 18:31, Joachim Breitner wrote: | > > Hi, | > > | > > Am Mittwoch, den 17.04.2019, 13:38 -0500 schrieb Christopher Allen: | > > > I gave my recommendation for ExtraCommas, acceptance of the | > > > original proposal as written. I talk with the proposer almost | > > > every day so I know where he stands. He still thinks it's worth | > > > doing and would like to see it accepted. I think ExtraCommas | > > > merits acceptance. If we can't achieve consensus on it then it | > > > should be rejected so it gets cleared off the slate. I'm not | > > > inclined to argue a syntactic extension like this, but I will say | this: | > > > | > > > The proposal captures a nice design element that we've seen work | > > > very well ergonomically in Rust. We're never going to make the | > > > same decisions with the same tradeoffs as a totally different | > > > language but any time there is a relatively isolated "good idea" | > > > like this, I'd like to see us try to take advantage of that and | > > > see if it works for us. | > > | > > thanks for picking this up. | > > | > > The most contentious point, besides whether its worth the bother at | > > all, was the interaction with TupleSections. Which gives us three | > > options, I think: | > > * reject | > > * accept, covering tuples (and making it conflict with | > > TupleSections) | > > * accept, not covering tuples. | > > | > > No decision is absolutely wrong, none is obviously right. | > > | > > Maybe we should simply do a vote, to get it decided? Simons (as | > > Chairs), what do you think? | > > | > > Cheers, | > > Joachim | > > | > > -- | > > Joachim Breitner | > > mail@joachim-breitner.de | > > http://www.joachim-breitner.de/ | > > | > > | > > _______________________________________________ | > > ghc-steering-committee mailing list | > > ghc-steering-committee@haskell.org | > > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-commi | > > ttee | > > | > > Attachments: | > > * signature.asc | > _______________________________________________ | > ghc-steering-committee mailing list | > ghc-steering-committee@haskell.org | > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committ | > ee | | | | -- | Chris Allen | Currently working on http://haskellbook.com | _______________________________________________ | ghc-steering-committee mailing list | ghc-steering-committee@haskell.org | https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

| "tuples included" means "incompatible with tuple sections" means "they are | mutually exclusive to a module." You mean, some kind of new error message that says "these two extension are mutually incompatible". I can't say I love this. Let's just leave out tuples from ExtraCommas. (Actually I could imagine [a,,b,] meaning \xy. [a,x,b,y], one day. Maybe we omit list literals too? Or would that break the key use-cases? Simon | -----Original Message----- | From: Christopher Allen | Sent: 18 April 2019 10:08 | To: Simon Peyton Jones | Cc: Eric Seidel ; ghc-steering-committee@haskell.org | Subject: Re: [ghc-steering-committee] Extra Commas | | My understanding of previous discussions was that: | | | On Thu, Apr 18, 2019 at 2:17 AM Simon Peyton Jones | wrote: | > | > But it's actually *incompatible* with TupleSections, so how shoule | > (True,) | > be interpreted if both are on? | > | > S | > | > | -----Original Message----- | > | From: ghc-steering-committee | > | | > | On Behalf Of Christopher Allen | > | Sent: 18 April 2019 04:19 | > | To: Eric Seidel | > | Cc: ghc-steering-committee@haskell.org | > | Subject: Re: [ghc-steering-committee] Extra Commas | > | | > | I spoke with Matt, he's fine either way with or without tuples. | > | | > | I'd prefer "with tuples" for consistency. I use tuples sometimes, | > | but don't care about sectioning. | > | | > | On Wed, Apr 17, 2019 at 8:15 PM Eric Seidel wrote: | > | > | > | > I favor accepting the proposal, with or without tuples. I've been | > | writing a bit of Rust recently, and agree with Chris about the | > | ergonomics of trailing commas. | > | > | > | > On Wed, Apr 17, 2019, at 18:31, Joachim Breitner wrote: | > | > > Hi, | > | > > | > | > > Am Mittwoch, den 17.04.2019, 13:38 -0500 schrieb Christopher | Allen: | > | > > > I gave my recommendation for ExtraCommas, acceptance of the | > | > > > original proposal as written. I talk with the proposer almost | > | > > > every day so I know where he stands. He still thinks it's | > | worth > > > doing and would like to see it accepted. I think | > | ExtraCommas > > > merits acceptance. If we can't achieve consensus | > | on it then it > > > should be rejected so it gets cleared off the | > | slate. I'm not > > > inclined to argue a syntactic extension like | > | this, but I will say | > | this: | > | > > > | > | > > > The proposal captures a nice design element that we've seen | > | work > > > very well ergonomically in Rust. We're never going to | > | make the > > > same decisions with the same tradeoffs as a totally | > | different > > > language but any time there is a relatively isolated | "good idea" | > | > > > like this, I'd like to see us try to take advantage of that | > | and > > > see if it works for us. | > | > > | > | > > thanks for picking this up. | > | > > | > | > > The most contentious point, besides whether its worth the | > | bother at > > all, was the interaction with TupleSections. Which | > | gives us three > > options, I think: | > | > > * reject | > | > > * accept, covering tuples (and making it conflict with > > | > | TupleSections) > > * accept, not covering tuples. | > | > > | > | > > No decision is absolutely wrong, none is obviously right. | > | > > | > | > > Maybe we should simply do a vote, to get it decided? Simons (as | > | > > Chairs), what do you think? | > | > > | > | > > Cheers, | > | > > Joachim | > | > > | > | > > -- | > | > > Joachim Breitner | > | > > mail@joachim-breitner.de | > | > > | > | https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww | > | .joachim-breitner.de%2F&data=02%7C01%7Csimonpj%40microsoft.com%7 | > | C670f986836834427a29408d6c3dd5cd0%7C72f988bf86f141af91ab2d7cd011db47 | > | %7C1%7C0%7C636911752855987147&sdata=gCdvqR5gm0K54rJMnfcnIiOyyv4u | > | 9fb%2BRkQMqGibDlM%3D&reserved=0 | > | > > | > | > > | > | > > _______________________________________________ | > | > > ghc-steering-committee mailing list > > | > | ghc-steering-committee@haskell.org | > | > > | > | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fma | > | il.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-commi&a | > | mp;data=02%7C01%7Csimonpj%40microsoft.com%7C670f986836834427a29408d6 | > | c3dd5cd0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63691175285598 | > | 7147&sdata=NZqChpNEoHihvoow29uxmmDyPuLeVgn4iNwkcdMDno8%3D&re | > | served=0 | > | > > ttee | > | > > | > | > > Attachments: | > | > > * signature.asc | > | > _______________________________________________ | > | > ghc-steering-committee mailing list > | > | ghc-steering-committee@haskell.org | > | > | > | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fma | > | il.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committ | > | &data=02%7C01%7Csimonpj%40microsoft.com%7C670f986836834427a29408 | > | d6c3dd5cd0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636911752855 | > | 987147&sdata=1PZCPlMWYOlGrlN7MFkvn7rmpdMUqv%2BShDLpFyO4Y%2FI%3D& | > | amp;reserved=0 | > | > ee | > | | > | | > | | > | -- | > | Chris Allen | > | Currently working on | > | https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fhas | > | kellbook.com&data=02%7C01%7Csimonpj%40microsoft.com%7C670f986836 | > | 834427a29408d6c3dd5cd0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C | > | 636911752855987147&sdata=u6TzKujVuJnrWL%2BnPr0YlcE7w8xHnENsWZUDK | > | 8IyjBI%3D&reserved=0 | > | _______________________________________________ | > | ghc-steering-committee mailing list | > | ghc-steering-committee@haskell.org | > | | > | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fma | > | il.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committ | > | ee&data=02%7C01%7Csimonpj%40microsoft.com%7C670f986836834427a294 | > | 08d6c3dd5cd0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6369117528 | > | 55987147&sdata=ESnHSYRuMMUvenMjIzpapcKWVfzbAqLJ9%2BcSNjoWklk%3D& | > | amp;reserved=0 | | | | -- | Chris Allen | Currently working on | https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fhaskellbo | ok.com&data=02%7C01%7Csimonpj%40microsoft.com%7C670f986836834427a29408 | d6c3dd5cd0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636911752855987147 | &sdata=u6TzKujVuJnrWL%2BnPr0YlcE7w8xHnENsWZUDK8IyjBI%3D&reserved=0

I approve of this Salomonic proposal. Am Donnerstag, den 18.04.2019, 11:06 -0400 schrieb Richard Eisenberg:

I strongly dislike the idea of mutually-incompatible extensions.

We could say that ExtraCommas allows extra commas everywhere, including in tuples and lists. We could also say that TupleSections overrides this behavior in tuples and gives it new meaning. We could further imagine ListSections that would override the behavior in lists. To me, this is preferable than mutual incompatibility.

Does this make for a nice user experience? I'm not sure. Happily, the reinterpretation from TupleSections or ListSections would change types, so you'd get errors up front. These errors might even be clever enough to notice that both ExtraCommas and TupleSections are in effect and gently remind the user that this combination can be confusing. Actually, this might be a nice "have your cake and eat it too" moment: let's just do all the things!

Richard

...

On Apr 18, 2019, at 10:52 AM, Simon Peyton Jones via ghc-steering-committee wrote:

...

"tuples included" means "incompatible with tuple sections" means "they are mutually exclusive to a module."

You mean, some kind of new error message that says "these two extension are mutually incompatible". I can't say I love this. Let's just leave out tuples from ExtraCommas.

(Actually I could imagine [a,,b,] meaning \xy. [a,x,b,y], one day. Maybe we omit list literals too? Or would that break the key use-cases?

Simon

...

-----Original Message----- From: Christopher Allen Sent: 18 April 2019 10:08 To: Simon Peyton Jones Cc: Eric Seidel ; ghc-steering-committee@haskell.org Subject: Re: [ghc-steering-committee] Extra Commas

My understanding of previous discussions was that:

On Thu, Apr 18, 2019 at 2:17 AM Simon Peyton Jones wrote:

...

But it's actually *incompatible* with TupleSections, so how shoule (True,) be interpreted if both are on?

S

| -----Original Message----- | From: ghc-steering-committee | | On Behalf Of Christopher Allen | Sent: 18 April 2019 04:19 | To: Eric Seidel | Cc: ghc-steering-committee@haskell.org | Subject: Re: [ghc-steering-committee] Extra Commas | | I spoke with Matt, he's fine either way with or without tuples. | | I'd prefer "with tuples" for consistency. I use tuples sometimes, | but don't care about sectioning. | | On Wed, Apr 17, 2019 at 8:15 PM Eric Seidel wrote: | > | > I favor accepting the proposal, with or without tuples. I've been | writing a bit of Rust recently, and agree with Chris about the | ergonomics of trailing commas. | > | > On Wed, Apr 17, 2019, at 18:31, Joachim Breitner wrote: | > > Hi, | > > | > > Am Mittwoch, den 17.04.2019, 13:38 -0500 schrieb Christopher

Allen:

...

| > > > I gave my recommendation for ExtraCommas, acceptance of the | > > > original proposal as written. I talk with the proposer almost | > > > every day so I know where he stands. He still thinks it's | worth > > > doing and would like to see it accepted. I think | ExtraCommas > > > merits acceptance. If we can't achieve consensus | on it then it > > > should be rejected so it gets cleared off the | slate. I'm not > > > inclined to argue a syntactic extension like | this, but I will say | this: | > > > | > > > The proposal captures a nice design element that we've seen | work > > > very well ergonomically in Rust. We're never going to | make the > > > same decisions with the same tradeoffs as a totally | different > > > language but any time there is a relatively isolated "good idea" | > > > like this, I'd like to see us try to take advantage of that | and > > > see if it works for us. | > > | > > thanks for picking this up. | > > | > > The most contentious point, besides whether its worth the | bother at > > all, was the interaction with TupleSections. Which | gives us three > > options, I think: | > > * reject | > > * accept, covering tuples (and making it conflict with > > | TupleSections) > > * accept, not covering tuples. | > > | > > No decision is absolutely wrong, none is obviously right. | > > | > > Maybe we should simply do a vote, to get it decided? Simons (as | > > Chairs), what do you think? | > > | > > Cheers, | > > Joachim | > > | > > -- | > > Joachim Breitner | > > mail@joachim-breitner.de | > > | https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww | .joachim-breitner.de%2F&data=02%7C01%7Csimonpj%40microsoft.com%7 | C670f986836834427a29408d6c3dd5cd0%7C72f988bf86f141af91ab2d7cd011db47 | %7C1%7C0%7C636911752855987147&sdata=gCdvqR5gm0K54rJMnfcnIiOyyv4u | 9fb%2BRkQMqGibDlM%3D&reserved=0 | > > | > > | > > _______________________________________________ | > > ghc-steering-committee mailing list > > | ghc-steering-committee@haskell.org | > > | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fma | il.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-commi&a | mp;data=02%7C01%7Csimonpj%40microsoft.com%7C670f986836834427a29408d6 | c3dd5cd0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63691175285598 | 7147&sdata=NZqChpNEoHihvoow29uxmmDyPuLeVgn4iNwkcdMDno8%3D&re | served=0 | > > ttee | > > | > > Attachments: | > > * signature.asc | > _______________________________________________ | > ghc-steering-committee mailing list > | ghc-steering-committee@haskell.org | > | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fma | il.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committ | &data=02%7C01%7Csimonpj%40microsoft.com%7C670f986836834427a29408 | d6c3dd5cd0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636911752855 | 987147&sdata=1PZCPlMWYOlGrlN7MFkvn7rmpdMUqv%2BShDLpFyO4Y%2FI%3D& | amp;reserved=0 | > ee | | | | -- | Chris Allen | Currently working on | https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fhas | kellbook.com&data=02%7C01%7Csimonpj%40microsoft.com%7C670f986836 | 834427a29408d6c3dd5cd0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C | 636911752855987147&sdata=u6TzKujVuJnrWL%2BnPr0YlcE7w8xHnENsWZUDK | 8IyjBI%3D&reserved=0 | _______________________________________________ | ghc-steering-committee mailing list | ghc-steering-committee@haskell.org | | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fma | il.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committ | ee&data=02%7C01%7Csimonpj%40microsoft.com%7C670f986836834427a294 | 08d6c3dd5cd0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6369117528 | 55987147&sdata=ESnHSYRuMMUvenMjIzpapcKWVfzbAqLJ9%2BcSNjoWklk%3D& | amp;reserved=0

-- Chris Allen Currently working on https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fhaskellbo ok.com&data=02%7C01%7Csimonpj%40microsoft.com%7C670f986836834427a29408 d6c3dd5cd0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636911752855987147 &sdata=u6TzKujVuJnrWL%2BnPr0YlcE7w8xHnENsWZUDK8IyjBI%3D&reserved=0

---

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

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee -- Joachim Breitner mail@joachim-breitner.de http://www.joachim-breitner.de/

As I have said previously, I strongly agree with Simon on that we need to make some editorial decisions. Concerning the general proposal, I think, the convenience of trailing commas is a consequence of insufficient editor support and IMHO it’d be better to improve that support rather than applying band-aids to the language. However, I can live with the extensions as long as their is no conflict with TupleSections. Cheers, Manuel

Am 24.04.2019 um 09:30 schrieb Simon Marlow :

I'm also strongly against mutually incompatible extensions.

I'm not sure about allowing the combination of TupleSections and ExtraCommas. It would mean that (x,) has a different meaning depending on what extensions are in force. This is a pretty strange direction to take the language in, and raises questions about whether we should think of GHC as a testing ground for language extensions of which only some will eventually make it into a language standard, or whether we should take a position on which extensions are sensible when there are conflicts. Personally I'm in favour of the committee taking some editorial decisions here - not just assessing which extensions make sense in isolation, but considering whether an extension makes sense in the context of the other extensions we already have.

But back to the current proposal, I would vote for allowing the parts of the proposal that don't conflict with TupleSections.

Cheers Simon

On Thu, 18 Apr 2019 at 16:06, Richard Eisenberg mailto:rae@richarde.dev> wrote: I strongly dislike the idea of mutually-incompatible extensions.

We could say that ExtraCommas allows extra commas everywhere, including in tuples and lists. We could also say that TupleSections overrides this behavior in tuples and gives it new meaning. We could further imagine ListSections that would override the behavior in lists. To me, this is preferable than mutual incompatibility.

Does this make for a nice user experience? I'm not sure. Happily, the reinterpretation from TupleSections or ListSections would change types, so you'd get errors up front. These errors might even be clever enough to notice that both ExtraCommas and TupleSections are in effect and gently remind the user that this combination can be confusing. Actually, this might be a nice "have your cake and eat it too" moment: let's just do all the things!

Richard

...

On Apr 18, 2019, at 10:52 AM, Simon Peyton Jones via ghc-steering-committee mailto:ghc-steering-committee@haskell.org> wrote:

| "tuples included" means "incompatible with tuple sections" means "they are | mutually exclusive to a module."

You mean, some kind of new error message that says "these two extension are mutually incompatible". I can't say I love this. Let's just leave out tuples from ExtraCommas.

(Actually I could imagine [a,,b,] meaning \xy. [a,x,b,y], one day. Maybe we omit list literals too? Or would that break the key use-cases?

Simon

| -----Original Message----- | From: Christopher Allen mailto:cma@bitemyapp.com> | Sent: 18 April 2019 10:08 | To: Simon Peyton Jones mailto:simonpj@microsoft.com> | Cc: Eric Seidel mailto:eric@seidel.io>; ghc-steering-committee@haskell.org mailto:ghc-steering-committee@haskell.org | Subject: Re: [ghc-steering-committee] Extra Commas | | My understanding of previous discussions was that: | | | On Thu, Apr 18, 2019 at 2:17 AM Simon Peyton Jones mailto:simonpj@microsoft.com> | wrote: | > | > But it's actually *incompatible* with TupleSections, so how shoule | > (True,) | > be interpreted if both are on? | > | > S | > | > | -----Original Message----- | > | From: ghc-steering-committee | > | mailto:ghc-steering-committee-bounces@haskell.org> | > | On Behalf Of Christopher Allen | > | Sent: 18 April 2019 04:19 | > | To: Eric Seidel mailto:eric@seidel.io> | > | Cc: ghc-steering-committee@haskell.org mailto:ghc-steering-committee@haskell.org | > | Subject: Re: [ghc-steering-committee] Extra Commas | > | | > | I spoke with Matt, he's fine either way with or without tuples. | > | | > | I'd prefer "with tuples" for consistency. I use tuples sometimes, | > | but don't care about sectioning. | > | | > | On Wed, Apr 17, 2019 at 8:15 PM Eric Seidel mailto:eric@seidel.io> wrote: | > | > | > | > I favor accepting the proposal, with or without tuples. I've been | > | writing a bit of Rust recently, and agree with Chris about the | > | ergonomics of trailing commas. | > | > | > | > On Wed, Apr 17, 2019, at 18:31, Joachim Breitner wrote: | > | > > Hi, | > | > > | > | > > Am Mittwoch, den 17.04.2019, 13:38 -0500 schrieb Christopher | Allen: | > | > > > I gave my recommendation for ExtraCommas, acceptance of the | > | > > > original proposal as written. I talk with the proposer almost | > | > > > every day so I know where he stands. He still thinks it's | > | worth > > > doing and would like to see it accepted. I think | > | ExtraCommas > > > merits acceptance. If we can't achieve consensus | > | on it then it > > > should be rejected so it gets cleared off the | > | slate. I'm not > > > inclined to argue a syntactic extension like | > | this, but I will say | > | this: | > | > > > | > | > > > The proposal captures a nice design element that we've seen | > | work > > > very well ergonomically in Rust. We're never going to | > | make the > > > same decisions with the same tradeoffs as a totally | > | different > > > language but any time there is a relatively isolated | "good idea" | > | > > > like this, I'd like to see us try to take advantage of that | > | and > > > see if it works for us. | > | > > | > | > > thanks for picking this up. | > | > > | > | > > The most contentious point, besides whether its worth the | > | bother at > > all, was the interaction with TupleSections. Which | > | gives us three > > options, I think: | > | > > * reject | > | > > * accept, covering tuples (and making it conflict with > > | > | TupleSections) > > * accept, not covering tuples. | > | > > | > | > > No decision is absolutely wrong, none is obviously right. | > | > > | > | > > Maybe we should simply do a vote, to get it decided? Simons (as | > | > > Chairs), what do you think? | > | > > | > | > > Cheers, | > | > > Joachim | > | > > | > | > > -- | > | > > Joachim Breitner | > | > > mail@joachim-breitner.de mailto:mail@joachim-breitner.de | > | > > | > | https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww | > | .joachim-breitner.de http://joachim-breitner.de/%2F&data=02%7C01%7Csimonpj%40microsoft.com http://40microsoft.com/%7 | > | C670f986836834427a29408d6c3dd5cd0%7C72f988bf86f141af91ab2d7cd011db47 | > | %7C1%7C0%7C636911752855987147&sdata=gCdvqR5gm0K54rJMnfcnIiOyyv4u | > | 9fb%2BRkQMqGibDlM%3D&reserved=0 | > | > > | > | > > | > | > > _______________________________________________ | > | > > ghc-steering-committee mailing list > > | > | ghc-steering-committee@haskell.org mailto:ghc-steering-committee@haskell.org | > | > > | > | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fma https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fma | > | il.haskell.org http://il.haskell.org/%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-commi&a | > | mp;data=02%7C01%7Csimonpj%40microsoft.com http://40microsoft.com/%7C670f986836834427a29408d6 | > | c3dd5cd0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63691175285598 | > | 7147&sdata=NZqChpNEoHihvoow29uxmmDyPuLeVgn4iNwkcdMDno8%3D&re | > | served=0 | > | > > ttee | > | > > | > | > > Attachments: | > | > > * signature.asc | > | > _______________________________________________ | > | > ghc-steering-committee mailing list > | > | ghc-steering-committee@haskell.org mailto:ghc-steering-committee@haskell.org | > | > | > | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fma https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fma | > | il.haskell.org http://il.haskell.org/%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committ | > | &data=02%7C01%7Csimonpj%40microsoft.com http://40microsoft.com/%7C670f986836834427a29408 | > | d6c3dd5cd0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636911752855 | > | 987147&sdata=1PZCPlMWYOlGrlN7MFkvn7rmpdMUqv%2BShDLpFyO4Y%2FI%3D& | > | amp;reserved=0 | > | > ee | > | | > | | > | | > | -- | > | Chris Allen | > | Currently working on | > | https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fhas https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fhas | > | kellbook.com http://kellbook.com/&data=02%7C01%7Csimonpj%40microsoft.com http://40microsoft.com/%7C670f986836 | > | 834427a29408d6c3dd5cd0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C | > | 636911752855987147&sdata=u6TzKujVuJnrWL%2BnPr0YlcE7w8xHnENsWZUDK | > | 8IyjBI%3D&reserved=0 | > | _______________________________________________ | > | ghc-steering-committee mailing list | > | ghc-steering-committee@haskell.org mailto:ghc-steering-committee@haskell.org | > | | > | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fma https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fma | > | il.haskell.org http://il.haskell.org/%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committ | > | ee&data=02%7C01%7Csimonpj%40microsoft.com http://40microsoft.com/%7C670f986836834427a294 | > | 08d6c3dd5cd0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6369117528 | > | 55987147&sdata=ESnHSYRuMMUvenMjIzpapcKWVfzbAqLJ9%2BcSNjoWklk%3D& | > | amp;reserved=0 | | | | -- | Chris Allen | Currently working on | https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fhaskellbo https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fhaskellbo | ok.com http://ok.com/&data=02%7C01%7Csimonpj%40microsoft.com http://40microsoft.com/%7C670f986836834427a29408 | d6c3dd5cd0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636911752855987147 | &sdata=u6TzKujVuJnrWL%2BnPr0YlcE7w8xHnENsWZUDK8IyjBI%3D&reserved=0 _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org mailto:ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

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

I’m ok with accepting, but excluding tuples, including constraint tuples. I’m be ok with excluding list literals too. We should ask the author if s/he feels that these exclusions would unacceptably eviscerate the proposal i.e. make it not worth doing. The upside is that it’s clearly a superficial, syntax-only issue. Nothing deep is at stake here. Simon From: ghc-steering-committee On Behalf Of Vitaly Bragilevsky Sent: 24 April 2019 20:20 To: ghc-steering-committee@haskell.org Subject: Re: [ghc-steering-committee] Extra Commas I am next voting to accept this proposal, not covering tuples. Vitaly ср, 24 апр. 2019 г. в 19:17, Manuel M T Chakravarty mailto:chak@justtesting.org>: As I have said previously, I strongly agree with Simon on that we need to make some editorial decisions. Concerning the general proposal, I think, the convenience of trailing commas is a consequence of insufficient editor support and IMHO it’d be better to improve that support rather than applying band-aids to the language. However, I can live with the extensions as long as their is no conflict with TupleSections. Cheers, Manuel Am 24.04.2019 um 09:30 schrieb Simon Marlow mailto:marlowsd@gmail.com>: I'm also strongly against mutually incompatible extensions. I'm not sure about allowing the combination of TupleSections and ExtraCommas. It would mean that (x,) has a different meaning depending on what extensions are in force. This is a pretty strange direction to take the language in, and raises questions about whether we should think of GHC as a testing ground for language extensions of which only some will eventually make it into a language standard, or whether we should take a position on which extensions are sensible when there are conflicts. Personally I'm in favour of the committee taking some editorial decisions here - not just assessing which extensions make sense in isolation, but considering whether an extension makes sense in the context of the other extensions we already have. But back to the current proposal, I would vote for allowing the parts of the proposal that don't conflict with TupleSections. Cheers Simon On Thu, 18 Apr 2019 at 16:06, Richard Eisenberg mailto:rae@richarde.dev> wrote: I strongly dislike the idea of mutually-incompatible extensions. We could say that ExtraCommas allows extra commas everywhere, including in tuples and lists. We could also say that TupleSections overrides this behavior in tuples and gives it new meaning. We could further imagine ListSections that would override the behavior in lists. To me, this is preferable than mutual incompatibility. Does this make for a nice user experience? I'm not sure. Happily, the reinterpretation from TupleSections or ListSections would change types, so you'd get errors up front. These errors might even be clever enough to notice that both ExtraCommas and TupleSections are in effect and gently remind the user that this combination can be confusing. Actually, this might be a nice "have your cake and eat it too" moment: let's just do all the things! Richard

On Apr 18, 2019, at 10:52 AM, Simon Peyton Jones via ghc-steering-committee mailto:ghc-steering-committee@haskell.org> wrote:

| "tuples included" means "incompatible with tuple sections" means "they are | mutually exclusive to a module."

You mean, some kind of new error message that says "these two extension are mutually incompatible". I can't say I love this. Let's just leave out tuples from ExtraCommas.

(Actually I could imagine [a,,b,] meaning \xy. [a,x,b,y], one day. Maybe we omit list literals too? Or would that break the key use-cases?

Simon

| -----Original Message----- | From: Christopher Allen mailto:cma@bitemyapp.com> | Sent: 18 April 2019 10:08 | To: Simon Peyton Jones mailto:simonpj@microsoft.com> | Cc: Eric Seidel mailto:eric@seidel.io>; ghc-steering-committee@haskell.orgmailto:ghc-steering-committee@haskell.org | Subject: Re: [ghc-steering-committee] Extra Commas | | My understanding of previous discussions was that: | | | On Thu, Apr 18, 2019 at 2:17 AM Simon Peyton Jones mailto:simonpj@microsoft.com> | wrote: | > | > But it's actually *incompatible* with TupleSections, so how shoule | > (True,) | > be interpreted if both are on? | > | > S | > | > | -----Original Message----- | > | From: ghc-steering-committee | > | mailto:ghc-steering-committee-bounces@haskell.org> | > | On Behalf Of Christopher Allen | > | Sent: 18 April 2019 04:19 | > | To: Eric Seidel mailto:eric@seidel.io> | > | Cc: ghc-steering-committee@haskell.orgmailto:ghc-steering-committee@haskell.org | > | Subject: Re: [ghc-steering-committee] Extra Commas | > | | > | I spoke with Matt, he's fine either way with or without tuples. | > | | > | I'd prefer "with tuples" for consistency. I use tuples sometimes, | > | but don't care about sectioning. | > | | > | On Wed, Apr 17, 2019 at 8:15 PM Eric Seidel mailto:eric@seidel.io> wrote: | > | > | > | > I favor accepting the proposal, with or without tuples. I've been | > | writing a bit of Rust recently, and agree with Chris about the | > | ergonomics of trailing commas. | > | > | > | > On Wed, Apr 17, 2019, at 18:31, Joachim Breitner wrote: | > | > > Hi, | > | > > | > | > > Am Mittwoch, den 17.04.2019, 13:38 -0500 schrieb Christopher | Allen: | > | > > > I gave my recommendation for ExtraCommas, acceptance of the | > | > > > original proposal as written. I talk with the proposer almost | > | > > > every day so I know where he stands. He still thinks it's | > | worth > > > doing and would like to see it accepted. I think | > | ExtraCommas > > > merits acceptance. If we can't achieve consensus | > | on it then it > > > should be rejected so it gets cleared off the | > | slate. I'm not > > > inclined to argue a syntactic extension like | > | this, but I will say | > | this: | > | > > > | > | > > > The proposal captures a nice design element that we've seen | > | work > > > very well ergonomically in Rust. We're never going to | > | make the > > > same decisions with the same tradeoffs as a totally | > | different > > > language but any time there is a relatively isolated | "good idea" | > | > > > like this, I'd like to see us try to take advantage of that | > | and > > > see if it works for us. | > | > > | > | > > thanks for picking this up. | > | > > | > | > > The most contentious point, besides whether its worth the | > | bother at > > all, was the interaction with TupleSections. Which | > | gives us three > > options, I think: | > | > > * reject | > | > > * accept, covering tuples (and making it conflict with > > | > | TupleSections) > > * accept, not covering tuples. | > | > > | > | > > No decision is absolutely wrong, none is obviously right. | > | > > | > | > > Maybe we should simply do a vote, to get it decided? Simons (as | > | > > Chairs), what do you think? | > | > > | > | > > Cheers, | > | > > Joachim | > | > > | > | > > -- | > | > > Joachim Breitner | > | > > mail@joachim-breitner.demailto:mail@joachim-breitner.de | > | > > | > | https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww | > | .joachim-breitner.dehttps://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fjoachim-breitner.de%2F&data=01%7C01%7Csimonpj%40microsoft.com%7C44d0ff746f33476c675a08d6c8e9f00b%7C72f988bf86f141af91ab2d7cd011db47%7C1&sdata=lR2NQIVgxszL9PfjVDhzaQ%2Ba38gdzT3MtLR5CWq1E5o%3D&reserved=0%2F&data=02%7C01%7Csimonpj%40microsoft.comhttps://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2F40microsoft.com%2F&data=01%7C01%7Csimonpj%40microsoft.com%7C44d0ff746f33476c675a08d6c8e9f00b%7C72f988bf86f141af91ab2d7cd011db47%7C1&sdata=kUDsQaZBMxnDrAPTlK8CfqknqyGTnQEwCSbMxsU7Bt8%3D&reserved=0%7 | > | C670f986836834427a29408d6c3dd5cd0%7C72f988bf86f141af91ab2d7cd011db47 | > | %7C1%7C0%7C636911752855987147&sdata=gCdvqR5gm0K54rJMnfcnIiOyyv4u | > | 9fb%2BRkQMqGibDlM%3D&reserved=0 | > | > > | > | > > | > | > > _______________________________________________ | > | > > ghc-steering-committee mailing list > > | > | ghc-steering-committee@haskell.orgmailto:ghc-steering-committee@haskell.org | > | > > | > | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fma | > | il.haskell.orghttps://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fil.haskell.org%2F&data=01%7C01%7Csimonpj%40microsoft.com%7C44d0ff746f33476c675a08d6c8e9f00b%7C72f988bf86f141af91ab2d7cd011db47%7C1&sdata=VuEBvcSJl8AXHj6DluWHV02IWb2t4IJoDVR0t8lM2Ec%3D&reserved=0%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-commi&a | > | mp;data=02%7C01%7Csimonpj%40microsoft.comhttps://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2F40microsoft.com%2F&data=01%7C01%7Csimonpj%40microsoft.com%7C44d0ff746f33476c675a08d6c8e9f00b%7C72f988bf86f141af91ab2d7cd011db47%7C1&sdata=kUDsQaZBMxnDrAPTlK8CfqknqyGTnQEwCSbMxsU7Bt8%3D&reserved=0%7C670f986836834427a29408d6 | > | c3dd5cd0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63691175285598 | > | 7147&sdata=NZqChpNEoHihvoow29uxmmDyPuLeVgn4iNwkcdMDno8%3D&re | > | served=0 | > | > > ttee | > | > > | > | > > Attachments: | > | > > * signature.asc | > | > _______________________________________________ | > | > ghc-steering-committee mailing list > | > | ghc-steering-committee@haskell.orgmailto:ghc-steering-committee@haskell.org | > | > | > | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fma | > | il.haskell.orghttps://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fil.haskell.org%2F&data=01%7C01%7Csimonpj%40microsoft.com%7C44d0ff746f33476c675a08d6c8e9f00b%7C72f988bf86f141af91ab2d7cd011db47%7C1&sdata=VuEBvcSJl8AXHj6DluWHV02IWb2t4IJoDVR0t8lM2Ec%3D&reserved=0%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committ | > | &data=02%7C01%7Csimonpj%40microsoft.comhttps://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2F40microsoft.com%2F&data=01%7C01%7Csimonpj%40microsoft.com%7C44d0ff746f33476c675a08d6c8e9f00b%7C72f988bf86f141af91ab2d7cd011db47%7C1&sdata=kUDsQaZBMxnDrAPTlK8CfqknqyGTnQEwCSbMxsU7Bt8%3D&reserved=0%7C670f986836834427a29408 | > | d6c3dd5cd0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636911752855 | > | 987147&sdata=1PZCPlMWYOlGrlN7MFkvn7rmpdMUqv%2BShDLpFyO4Y%2FI%3D& | > | amp;reserved=0 | > | > ee | > | | > | | > | | > | -- | > | Chris Allen | > | Currently working on | > | https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fhas | > | kellbook.comhttps://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fkellbook.com%2F&data=01%7C01%7Csimonpj%40microsoft.com%7C44d0ff746f33476c675a08d6c8e9f00b%7C72f988bf86f141af91ab2d7cd011db47%7C1&sdata=bPi0phmrOo4ANN016iNxh7TbcxKmKeLi%2B7%2FWQbDF4X4%3D&reserved=0&data=02%7C01%7Csimonpj%40microsoft.comhttps://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2F40microsoft.com%2F&data=01%7C01%7Csimonpj%40microsoft.com%7C44d0ff746f33476c675a08d6c8e9f00b%7C72f988bf86f141af91ab2d7cd011db47%7C1&sdata=kUDsQaZBMxnDrAPTlK8CfqknqyGTnQEwCSbMxsU7Bt8%3D&reserved=0%7C670f986836 | > | 834427a29408d6c3dd5cd0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C | > | 636911752855987147&sdata=u6TzKujVuJnrWL%2BnPr0YlcE7w8xHnENsWZUDK | > | 8IyjBI%3D&reserved=0 | > | _______________________________________________ | > | ghc-steering-committee mailing list | > | ghc-steering-committee@haskell.orgmailto:ghc-steering-committee@haskell.org | > | | > | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fma | > | il.haskell.orghttps://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fil.haskell.org%2F&data=01%7C01%7Csimonpj%40microsoft.com%7C44d0ff746f33476c675a08d6c8e9f00b%7C72f988bf86f141af91ab2d7cd011db47%7C1&sdata=VuEBvcSJl8AXHj6DluWHV02IWb2t4IJoDVR0t8lM2Ec%3D&reserved=0%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committ | > | ee&data=02%7C01%7Csimonpj%40microsoft.comhttps://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2F40microsoft.com%2F&data=01%7C01%7Csimonpj%40microsoft.com%7C44d0ff746f33476c675a08d6c8e9f00b%7C72f988bf86f141af91ab2d7cd011db47%7C1&sdata=kUDsQaZBMxnDrAPTlK8CfqknqyGTnQEwCSbMxsU7Bt8%3D&reserved=0%7C670f986836834427a294 | > | 08d6c3dd5cd0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6369117528 | > | 55987147&sdata=ESnHSYRuMMUvenMjIzpapcKWVfzbAqLJ9%2BcSNjoWklk%3D& | > | amp;reserved=0 | | | | -- | Chris Allen | Currently working on | https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fhaskellbo | ok.comhttps://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fok.com%2F&data=01%7C01%7Csimonpj%40microsoft.com%7C44d0ff746f33476c675a08d6c8e9f00b%7C72f988bf86f141af91ab2d7cd011db47%7C1&sdata=4S14KSnrnmz05CBO%2FEapo5NMBEYlFAdt6c8lN6F19%2B0%3D&reserved=0&data=02%7C01%7Csimonpj%40microsoft.comhttps://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2F40microsoft.com%2F&data=01%7C01%7Csimonpj%40microsoft.com%7C44d0ff746f33476c675a08d6c8e9f00b%7C72f988bf86f141af91ab2d7cd011db47%7C1&sdata=kUDsQaZBMxnDrAPTlK8CfqknqyGTnQEwCSbMxsU7Bt8%3D&reserved=0%7C670f986836834427a29408 | d6c3dd5cd0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636911752855987147 | &sdata=u6TzKujVuJnrWL%2BnPr0YlcE7w8xHnENsWZUDK8IyjBI%3D&reserved=0 _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.orgmailto:ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committeehttps://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committee&data=01%7C01%7Csimonpj%40microsoft.com%7C44d0ff746f33476c675a08d6c8e9f00b%7C72f988bf86f141af91ab2d7cd011db47%7C1&sdata=BbCdHXiCFrLq9VnYXeWp5ypKqGDI4bO8AVXzLxV3clw%3D&reserved=0

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.orgmailto:ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committeehttps://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committee&data=01%7C01%7Csimonpj%40microsoft.com%7C44d0ff746f33476c675a08d6c8e9f00b%7C72f988bf86f141af91ab2d7cd011db47%7C1&sdata=BbCdHXiCFrLq9VnYXeWp5ypKqGDI4bO8AVXzLxV3clw%3D&reserved=0 _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.orgmailto:ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committeehttps://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committee&data=01%7C01%7Csimonpj%40microsoft.com%7C44d0ff746f33476c675a08d6c8e9f00b%7C72f988bf86f141af91ab2d7cd011db47%7C1&sdata=BbCdHXiCFrLq9VnYXeWp5ypKqGDI4bO8AVXzLxV3clw%3D&reserved=0 _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.orgmailto:ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committeehttps://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committee&data=01%7C01%7Csimonpj%40microsoft.com%7C44d0ff746f33476c675a08d6c8e9f00b%7C72f988bf86f141af91ab2d7cd011db47%7C1&sdata=BbCdHXiCFrLq9VnYXeWp5ypKqGDI4bO8AVXzLxV3clw%3D&reserved=0

Restating my point more explicitly: if you implemented the extension as described post-modification: I wouldn't enable it and I'm one of the biggest fans of Rust's syntax in this respect. I use Rust for fun and for work right now. A follow-up thought for this: the opinions and priorities of people who simply didn't want the extension or didn't plan to use it weighed heavily on where the proposal went. This took it places nobody interested in the proposal was interested in moving forward with. We might want to consider how we evaluate proposals in light of that problem. In the past I've held off commenting on proposals I wasn't interested in but considered benign to my priorities. I don't think everyone is operating on the same principle and it's making the process more bureaucratic and less effective for helping Haskell users achieve their ends. On Mon, Jul 8, 2019 at 1:05 PM Christopher Allen wrote:

To reiterate nobody wants that or is interested in a partial solution. The original proposer included. Neither of us are interested in editing or implementing the post-modification proposal. I'd like to return to the original proposer's final intent: closing the issue as rejected. I'd sooner sit on it and wait for a time when it won't get mutilated. A partial solution means a full implementation has zero chance of getting accepted.

If there are no objections, I will re-close the proposal as rejected.

On Mon, Jul 8, 2019 at 5:23 AM Simon Peyton Jones via ghc-steering-committee wrote:

...

I’m ok with accepting, but excluding tuples, including constraint tuples.

I’m be ok with excluding list literals too.

We should ask the author if s/he feels that these exclusions would unacceptably eviscerate the proposal i.e. make it not worth doing.

The upside is that it’s clearly a superficial, syntax-only issue. Nothing deep is at stake here.

Simon

From: ghc-steering-committee On Behalf Of Vitaly Bragilevsky Sent: 24 April 2019 20:20 To: ghc-steering-committee@haskell.org Subject: Re: [ghc-steering-committee] Extra Commas

I am next voting to accept this proposal, not covering tuples.

Vitaly

ср, 24 апр. 2019 г. в 19:17, Manuel M T Chakravarty :

As I have said previously, I strongly agree with Simon on that we need to make some editorial decisions.

Concerning the general proposal, I think, the convenience of trailing commas is a consequence of insufficient editor support and IMHO it’d be better to improve that support rather than applying band-aids to the language. However, I can live with the extensions as long as their is no conflict with TupleSections.

Cheers,

Manuel

Am 24.04.2019 um 09:30 schrieb Simon Marlow :

I'm also strongly against mutually incompatible extensions.

I'm not sure about allowing the combination of TupleSections and ExtraCommas. It would mean that (x,) has a different meaning depending on what extensions are in force. This is a pretty strange direction to take the language in, and raises questions about whether we should think of GHC as a testing ground for language extensions of which only some will eventually make it into a language standard, or whether we should take a position on which extensions are sensible when there are conflicts. Personally I'm in favour of the committee taking some editorial decisions here - not just assessing which extensions make sense in isolation, but considering whether an extension makes sense in the context of the other extensions we already have.

But back to the current proposal, I would vote for allowing the parts of the proposal that don't conflict with TupleSections.

Cheers

Simon

On Thu, 18 Apr 2019 at 16:06, Richard Eisenberg wrote:

I strongly dislike the idea of mutually-incompatible extensions.

We could say that ExtraCommas allows extra commas everywhere, including in tuples and lists. We could also say that TupleSections overrides this behavior in tuples and gives it new meaning. We could further imagine ListSections that would override the behavior in lists. To me, this is preferable than mutual incompatibility.

Does this make for a nice user experience? I'm not sure. Happily, the reinterpretation from TupleSections or ListSections would change types, so you'd get errors up front. These errors might even be clever enough to notice that both ExtraCommas and TupleSections are in effect and gently remind the user that this combination can be confusing. Actually, this might be a nice "have your cake and eat it too" moment: let's just do all the things!

Richard

...

On Apr 18, 2019, at 10:52 AM, Simon Peyton Jones via ghc-steering-committee wrote:

| "tuples included" means "incompatible with tuple sections" means "they are | mutually exclusive to a module."

You mean, some kind of new error message that says "these two extension are mutually incompatible". I can't say I love this. Let's just leave out tuples from ExtraCommas.

(Actually I could imagine [a,,b,] meaning \xy. [a,x,b,y], one day. Maybe we omit list literals too? Or would that break the key use-cases?

Simon

| -----Original Message----- | From: Christopher Allen | Sent: 18 April 2019 10:08 | To: Simon Peyton Jones | Cc: Eric Seidel ; ghc-steering-committee@haskell.org | Subject: Re: [ghc-steering-committee] Extra Commas | | My understanding of previous discussions was that: | | | On Thu, Apr 18, 2019 at 2:17 AM Simon Peyton Jones | wrote: | > | > But it's actually *incompatible* with TupleSections, so how shoule | > (True,) | > be interpreted if both are on? | > | > S | > | > | -----Original Message----- | > | From: ghc-steering-committee | > | | > | On Behalf Of Christopher Allen | > | Sent: 18 April 2019 04:19 | > | To: Eric Seidel | > | Cc: ghc-steering-committee@haskell.org | > | Subject: Re: [ghc-steering-committee] Extra Commas | > | | > | I spoke with Matt, he's fine either way with or without tuples. | > | | > | I'd prefer "with tuples" for consistency. I use tuples sometimes, | > | but don't care about sectioning. | > | | > | On Wed, Apr 17, 2019 at 8:15 PM Eric Seidel wrote: | > | > | > | > I favor accepting the proposal, with or without tuples. I've been | > | writing a bit of Rust recently, and agree with Chris about the | > | ergonomics of trailing commas. | > | > | > | > On Wed, Apr 17, 2019, at 18:31, Joachim Breitner wrote: | > | > > Hi, | > | > > | > | > > Am Mittwoch, den 17.04.2019, 13:38 -0500 schrieb Christopher | Allen: | > | > > > I gave my recommendation for ExtraCommas, acceptance of the | > | > > > original proposal as written. I talk with the proposer almost | > | > > > every day so I know where he stands. He still thinks it's | > | worth > > > doing and would like to see it accepted. I think | > | ExtraCommas > > > merits acceptance. If we can't achieve consensus | > | on it then it > > > should be rejected so it gets cleared off the | > | slate. I'm not > > > inclined to argue a syntactic extension like | > | this, but I will say | > | this: | > | > > > | > | > > > The proposal captures a nice design element that we've seen | > | work > > > very well ergonomically in Rust. We're never going to | > | make the > > > same decisions with the same tradeoffs as a totally | > | different > > > language but any time there is a relatively isolated | "good idea" | > | > > > like this, I'd like to see us try to take advantage of that | > | and > > > see if it works for us. | > | > > | > | > > thanks for picking this up. | > | > > | > | > > The most contentious point, besides whether its worth the | > | bother at > > all, was the interaction with TupleSections. Which | > | gives us three > > options, I think: | > | > > * reject | > | > > * accept, covering tuples (and making it conflict with > > | > | TupleSections) > > * accept, not covering tuples. | > | > > | > | > > No decision is absolutely wrong, none is obviously right. | > | > > | > | > > Maybe we should simply do a vote, to get it decided? Simons (as | > | > > Chairs), what do you think? | > | > > | > | > > Cheers, | > | > > Joachim | > | > > | > | > > -- | > | > > Joachim Breitner | > | > > mail@joachim-breitner.de | > | > > | > | https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww | > | .joachim-breitner.de%2F&data=02%7C01%7Csimonpj%40microsoft.com%7 | > | C670f986836834427a29408d6c3dd5cd0%7C72f988bf86f141af91ab2d7cd011db47 | > | %7C1%7C0%7C636911752855987147&sdata=gCdvqR5gm0K54rJMnfcnIiOyyv4u | > | 9fb%2BRkQMqGibDlM%3D&reserved=0 | > | > > | > | > > | > | > > _______________________________________________ | > | > > ghc-steering-committee mailing list > > | > | ghc-steering-committee@haskell.org | > | > > | > | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fma | > | il.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-commi&a | > | mp;data=02%7C01%7Csimonpj%40microsoft.com%7C670f986836834427a29408d6 | > | c3dd5cd0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63691175285598 | > | 7147&sdata=NZqChpNEoHihvoow29uxmmDyPuLeVgn4iNwkcdMDno8%3D&re | > | served=0 | > | > > ttee | > | > > | > | > > Attachments: | > | > > * signature.asc | > | > _______________________________________________ | > | > ghc-steering-committee mailing list > | > | ghc-steering-committee@haskell.org | > | > | > | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fma | > | il.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committ | > | &data=02%7C01%7Csimonpj%40microsoft.com%7C670f986836834427a29408 | > | d6c3dd5cd0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636911752855 | > | 987147&sdata=1PZCPlMWYOlGrlN7MFkvn7rmpdMUqv%2BShDLpFyO4Y%2FI%3D& | > | amp;reserved=0 | > | > ee | > | | > | | > | | > | -- | > | Chris Allen | > | Currently working on | > | https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fhas | > | kellbook.com&data=02%7C01%7Csimonpj%40microsoft.com%7C670f986836 | > | 834427a29408d6c3dd5cd0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C | > | 636911752855987147&sdata=u6TzKujVuJnrWL%2BnPr0YlcE7w8xHnENsWZUDK | > | 8IyjBI%3D&reserved=0 | > | _______________________________________________ | > | ghc-steering-committee mailing list | > | ghc-steering-committee@haskell.org | > | | > | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fma | > | il.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committ | > | ee&data=02%7C01%7Csimonpj%40microsoft.com%7C670f986836834427a294 | > | 08d6c3dd5cd0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6369117528 | > | 55987147&sdata=ESnHSYRuMMUvenMjIzpapcKWVfzbAqLJ9%2BcSNjoWklk%3D& | > | amp;reserved=0 | | | | -- | Chris Allen | Currently working on | https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fhaskellbo | ok.com&data=02%7C01%7Csimonpj%40microsoft.com%7C670f986836834427a29408 | d6c3dd5cd0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636911752855987147 | &sdata=u6TzKujVuJnrWL%2BnPr0YlcE7w8xHnENsWZUDK8IyjBI%3D&reserved=0 _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

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

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

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

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

-- Chris Allen Currently working on http://haskellbook.com

-- Chris Allen Currently working on http://haskellbook.com

On Apr 24, 2019, at 3:30 AM, Simon Marlow wrote:

I'm not sure about allowing the combination of TupleSections and ExtraCommas. It would mean that (x,) has a different meaning depending on what extensions are in force.

While I agree that this situation is suboptimal, it already exists in multiple ways. For example `f $x` has different meanings depending on whether -XTemplateHaskell is enabled -- and sometimes, both would type-check but mean different things. `data T a = MkT` has a different meaning depending on whether -XPolyKinds is enabled, and this change is not strictly conservative due to the potential for ambiguity when generalizing. At top-level, `pattern Nothing = Just ()` has a different meaning depending on whether -XPatternSynonyms is enabled; both meanings are error-free. My point here is that this argument doesn't hold much sway, for me -- the cows have already left the pasture. (I do agree that letting yet another calf out isn't great, but it's not, to me, a self-standing argument for rejection.) What allowed me to consider the possibility of combining both extensions is that the change in interpretation would almost always lead to a type error, so that an author meaning one interpretation but getting another can simply twiddle extensions. If the change in interpretation would manifest only at runtime, say, or only in downstream modules, I'd be much less sanguine. So my vote is to have both, but do not interpret this as a vote against "everything but tuples", which seems to be gaining momentum. Richard PS: I agree that this is a matter of editor support, and I'm not a fan of extra commas. But I hear a chorus of voices asking for this feature, and so I'm inclined to go with the wisdom of the crowd here.

So I still think accepting this is a mistake, but if everyone else finds it useful, obviously, it is not something that will interfere with my use of Haskell in significant ways. If it were just me I wouldn’t do it either. But it seems important to some people, and it doesn’t harm anyone (provided we can avoid it interacting badly with tuple sections). So I’m not going to stand in the way. Simon From: ghc-steering-committee On Behalf Of Iavor Diatchki Sent: 25 April 2019 18:43 To: Richard Eisenberg Cc: ghc-steering-committee@haskell.org Subject: Re: [ghc-steering-committee] Extra Commas On Thu, Apr 25, 2019 at 9:19 AM Richard Eisenberg mailto:rae@richarde.dev> wrote:

On Apr 24, 2019, at 3:30 AM, Simon Marlow mailto:marlowsd@gmail.com> wrote:

I'm not sure about allowing the combination of TupleSections and ExtraCommas. It would mean that (x,) has a different meaning depending on what extensions are in force.

While I agree that this situation is suboptimal, it already exists in multiple ways. For example `f $x` has different meanings depending on whether -XTemplateHaskell is enabled -- and sometimes, both would type-check but mean different things. `data T a = MkT` has a different meaning depending on whether -XPolyKinds is enabled, and this change is not strictly conservative due to the potential for ambiguity when generalizing. At top-level, `pattern Nothing = Just ()` has a different meaning depending on whether -XPatternSynonyms is enabled; both meanings are error-free. My point here is that this argument doesn't hold much sway, for me -- the cows have already left the pasture. (I do agree that letting yet another calf out isn't great, but it's not, to me, a self-standing argument for rejection.) It seems that these are examples of things working differently depending on if an extension is on or not, which is not a problem because, well, this is the whole point of turning on the extension. I don't think we have many examples where different extensions conflict with each other, so we'd probably want to write some code to report an error if both extensions are on, as clearly someone made a mistake. Unfortunately, this does not work if you write all extensions in the cabal file, rather then enumerating them in each separate module, so maybe in that case we don't report an error. Or we just arbitrarily order the extensions so that one takes precedence over the other... So my vote is to have both, but do not interpret this as a vote against "everything but tuples", which seems to be gaining momentum. What we seem to be discussing is a specification that would read something like this: 1) "(a,)" is an error, unless (2) "tuple sections" are one, in which case it is a function, unless (3) "extra commas" is on, in which case it just means "a", or maybe with (2) and (3) swapped. Ugh. And, presumably having "extra commas" work on tuples, would be useful if one had some really big tuples, and didn't want to delete the extra comma at the end. Having really big tuples does not make programs easier to read and manipulate, so I question what sort of programs are we trying to make easier to write. PS: I agree that this is a matter of editor support, and I'm not a fan of extra commas. But I hear a chorus of voices asking for this feature, and so I'm inclined to go with the wisdom of the crowd here. Well, I remain completely unconvinced by the wisdom of the crowd in this case, at least for "extra commas" in the expression language. The main reasoning I've see in the discussion are: 1. Improved "ergonomics", but I am not sure what that means, 2. Cleaner "diffs"---I find this completely unconvincing because 1) there are plenty of tools for working with diffs and an extra modified line when someone edits a list really make no difference, 2) the use case we are optimizing for are: programs with lots of large list/tuple literals, where most of the edits are to add/remove/reorder the elements in those literals; how common are those, really? 3. Easier support for CPP---also unconvincing as it is easy to work around by naming the parts of the list that may change; not only is this easy to do, but it likely makes the code more readable. Note that the CPP use case likely does not apply to tuples, as if you comment out some of the fields, the whole type would change, and now you'd have to CPP all uses of the tuples as well. So I still think accepting this is a mistake, but if everyone else finds it useful, obviously, it is not something that will interfere with my use of Haskell in significant ways. -Iavor

Just to remind everyone, here's the proposal https://github.com/parsonsmatt/ghc-proposals/blob/trailing-leading-commas/pr... I think the TupleSections conflict means that the proposal does *not* plan to allow leading or trailing commas in tuples. That's an exception, but has no other technical difficulty. I wonder if, for uniformity, the same exception should be made for constraint tuples, disallowing f :: (Monad m,) => blah because constraint tuples *are* really just tuples, and perhaps (Monad m,) :: Constraint -> Constraint. The proposal has a "maybe" for pattern guards, so we don't have a clear recommendation from the author there. But aside from these points I see not great difficulty. It's a superficial syntactic change (like putting 'qualified' in a different place; some people like it, and no harm is done to people who don't want it. Simon | -----Original Message----- | From: ghc-steering-committee | On Behalf Of Joachim Breitner | Sent: 17 April 2019 23:31 | To: ghc-steering-committee@haskell.org | Subject: Re: [ghc-steering-committee] Extra Commas | | Hi, | | Am Mittwoch, den 17.04.2019, 13:38 -0500 schrieb Christopher Allen: | > I gave my recommendation for ExtraCommas, acceptance of the original | > proposal as written. I talk with the proposer almost every day so I | > know where he stands. He still thinks it's worth doing and would like | > to see it accepted. I think ExtraCommas merits acceptance. If we can't | > achieve consensus on it then it should be rejected so it gets cleared | > off the slate. I'm not inclined to argue a syntactic extension like | > this, but I will say this: | > | > The proposal captures a nice design element that we've seen work very | > well ergonomically in Rust. We're never going to make the same | > decisions with the same tradeoffs as a totally different language but | > any time there is a relatively isolated "good idea" like this, I'd | > like to see us try to take advantage of that and see if it works for | > us. | | thanks for picking this up. | | The most contentious point, besides whether its worth the bother at all, | was the interaction with TupleSections. Which gives us three options, I | think: | * reject | * accept, covering tuples (and making it conflict with TupleSections) | * accept, not covering tuples. | | No decision is absolutely wrong, none is obviously right. | | Maybe we should simply do a vote, to get it decided? Simons (as Chairs), | what do you think? | | Cheers, | Joachim | | -- | Joachim Breitner | mail@joachim-breitner.de | http://www.joachim-breitner.de/