I don't like this proposal. I guess it is mostly a matter of taste, but I think that comas should be used a separator and not a terminator. I don't really buy either the CPP or "cleaner diffs" motivation. Joachim's proposal about the export warnings does make sense though. Cheers, -Iavor On Thu, May 3, 2018 at 2:38 AM Simon Marlow wrote:

I support both adding ExtraCommas (minus constraint tuples) and Joachim's suggestion to modify the warning for duplicate exports. Both of these are useful.

The "cleaner diffs" motivation is more compelling than the CPP argument, in my opinion. I often have to work with Python where it's common practice to include trailing commas in multiline lists, and I miss it in Haskell.

Cheers Simon

On 1 May 2018 at 03:59, Joachim Breitner wrote:

...

Hi,

Am Montag, den 30.04.2018, 19:20 -0500 schrieb Christopher Allen:

...

https://github.com/ghc-proposals/ghc-proposals/pull/87

With the provisos mentioned by Simon starting here in mind:

https://github.com/ghc-proposals/ghc-proposals/pull/87#issuecomment-38553658...

I am not against the proposal, but in the interest of fighting extension fatigue I’d like to draw your attention to this (which I had just posted at https://github.com/ghc-proposals/ghc-proposals/pull/87#issuecomment-38558191... )

If the motivation is really mainly about subexports lists, then we could simply tell GHC to accept

module Foo ( Foo(A), Foo(B), ) where

without warning about the duplicate export of `Foo`.

Is this good enough to solve the subexport list problem for CPP users? (probably yes)

Do we still want ExtraCommas, because it is also useful in lists and other syntactic constructs? (probably probably; I could be swayed either way).

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

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

Hi, Am Samstag, den 02.06.2018, 13:04 -0700 schrieb Iavor Diatchki:

Well, I think it is a bad idea. Obviously I don't think it has a huge impact on the language, but I think it encourages poor style, for very questionable befits. This is quite subjective, of course, but I think that this choice is at odds with Haskell's elegant surface syntax. We don't allow repeated punctuation in written prose,,,, why would we want in our programs?,,,

looks like there is some discussion needed here… Cheers, Joachim -- Joachim Breitner mail@joachim-breitner.de http://www.joachim-breitner.de/

Qualifying what I said toward the end, I don't think we should encourage clutter either. Trailing commas is an ergonomic idea that is already getting proved out by another language community. On Sat, Aug 4, 2018 at 1:27 PM, Christopher Allen wrote:

I've been using Rust which has terminal commas in the syntactic enumerations and it's, frankly, lovely. Less editing and easier copy/paste or use of macros when I am munging code. If it seems sloppy to you, it's probably because you aren't accustomed to it.

We have to remember that we work with code and not sentential English. In my view, mechanical ease should take priority over apparent naturalness. There have been many people who've objected that Haskell function application syntax is unnatural because they are accustomed to C-style f(arg, arg1) syntax.

Cf. https://medium.com/@nikgraf/why-you-should-enforce-dangling-commas-for-multi...

I'd like to see this get in unless there are real technical issues blocking it. I don't think it's our place to block an optional extension on aesthetic grounds unless it was beyond the pale of what the language is or does. I don't see how an extension permitting extra commas would qualify.

On Sat, Aug 4, 2018 at 10:37 AM, Joachim Breitner wrote:

...

Hi,

Am Samstag, den 02.06.2018, 13:04 -0700 schrieb Iavor Diatchki:

...

Well, I think it is a bad idea. Obviously I don't think it has a huge impact on the language, but I think it encourages poor style, for very questionable befits. This is quite subjective, of course, but I think that this choice is at odds with Haskell's elegant surface syntax. We don't allow repeated punctuation in written prose,,,, why would we want in our programs?,,,

looks like there is some discussion needed here…

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

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

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

I agree with Chris, the ergonomic benefits to allowing a leading/trailing comma would be substantial. It would be nice if we had smart, structure-aware editors that made it easy to swap around sequence elements, but they never really caught on. Most people still use line-oriented editors, so I think we should support the more line-oriented editing flow that extra commas enable. It's unfortunate that the extension would conflict with TupleSections, but I don't think that's sufficient reason to block it. I'm in favor of accepting the proposal. On Sat, Aug 4, 2018, at 16:08, Iavor Diatchki wrote:

I find the "cleaner diffs" or "easier editing" motivations to be very weak, and I'd rather not have to explain why `[1,2,]` is a list, but `(1,2,)` is a function.

On Sat, Aug 4, 2018 at 9:31 PM Christopher Allen wrote:

...

Qualifying what I said toward the end, I don't think we should encourage clutter either. Trailing commas is an ergonomic idea that is already getting proved out by another language community.

On Sat, Aug 4, 2018 at 1:27 PM, Christopher Allen wrote:

...

I've been using Rust which has terminal commas in the syntactic enumerations and it's, frankly, lovely. Less editing and easier copy/paste or use of macros when I am munging code. If it seems sloppy to you, it's probably because you aren't accustomed to it.

We have to remember that we work with code and not sentential English. In my view, mechanical ease should take priority over apparent naturalness. There have been many people who've objected that Haskell function application syntax is unnatural because they are accustomed to C-style f(arg, arg1) syntax.

Cf. https://medium.com/@nikgraf/why-you-should-enforce-dangling-commas-for-multi...

I'd like to see this get in unless there are real technical issues blocking it. I don't think it's our place to block an optional extension on aesthetic grounds unless it was beyond the pale of what the language is or does. I don't see how an extension permitting extra commas would qualify.

On Sat, Aug 4, 2018 at 10:37 AM, Joachim Breitner wrote:

...

Hi,

Am Samstag, den 02.06.2018, 13:04 -0700 schrieb Iavor Diatchki:

...

Well, I think it is a bad idea. Obviously I don't think it has a huge impact on the language, but I think it encourages poor style, for very questionable befits. This is quite subjective, of course, but I think that this choice is at odds with Haskell's elegant surface syntax. We don't allow repeated punctuation in written prose,,,, why would we want in our programs?,,,

looks like there is some discussion needed here…

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

...

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

-- 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

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

Hi, similar ambivalence here. If it were not for TupleSections, I’d be clearly in favor. But both TupleSections and ExtraCommas would be clearly marked in in the header of the file¹, and thus be signposted. The proposal currently says “There is a potential interaction with TupleSections”. Why potential? Is it, or is it not? Also, Simon’s request for an explicit listing of all the BNF changes has not happened yet. Chris, maybe request that first from the authors (i.e. return this as “Revision needed”)? I am not sure if the “let’s do this everywhere, but not with tuples” is a good approach. Note that TupleSections is still only an extension, and we _could_ decide that it is better to have uniformity in ExtraCommas, at the expense of making it simply incompatible with TupleSections. I am not sure about this, but I’d at least want to discuss the option. Although even ignoring TupleSections, extending ExtraCommas to tuples raises the question of how (,) should parse – is it the pair constructor, or the unit constructor with an extra comma. So maybe _that_ incompatibility with Haskell98 is the real reason why ExtraCommas just cannot work for tuples. Cheers, Joachim Am Sonntag, den 05.08.2018, 10:47 -0400 schrieb Richard Eisenberg:

I'm ambivalent on this one, seeing both sides of the argument. If I had to choose, I would lean toward "accept" based on the generally positive response the idea has seen.

Richard

...

On Aug 4, 2018, at 4:18 PM, Eric Seidel wrote:

I agree with Chris, the ergonomic benefits to allowing a leading/trailing comma would be substantial. It would be nice if we had smart, structure-aware editors that made it easy to swap around sequence elements, but they never really caught on. Most people still use line-oriented editors, so I think we should support the more line-oriented editing flow that extra commas enable.

It's unfortunate that the extension would conflict with TupleSections, but I don't think that's sufficient reason to block it.

I'm in favor of accepting the proposal.

On Sat, Aug 4, 2018, at 16:08, Iavor Diatchki wrote:

...

I find the "cleaner diffs" or "easier editing" motivations to be very weak, and I'd rather not have to explain why `[1,2,]` is a list, but `(1,2,)` is a function.

On Sat, Aug 4, 2018 at 9:31 PM Christopher Allen wrote:

...

Qualifying what I said toward the end, I don't think we should encourage clutter either. Trailing commas is an ergonomic idea that is already getting proved out by another language community.

On Sat, Aug 4, 2018 at 1:27 PM, Christopher Allen wrote:

...

I've been using Rust which has terminal commas in the syntactic enumerations and it's, frankly, lovely. Less editing and easier copy/paste or use of macros when I am munging code. If it seems sloppy to you, it's probably because you aren't accustomed to it.

We have to remember that we work with code and not sentential English. In my view, mechanical ease should take priority over apparent naturalness. There have been many people who've objected that Haskell function application syntax is unnatural because they are accustomed to C-style f(arg, arg1) syntax.

Cf.

https://medium.com/@nikgraf/why-you-should-enforce-dangling-commas-for-multi...

...

I'd like to see this get in unless there are real technical issues blocking it. I don't think it's our place to block an optional extension on aesthetic grounds unless it was beyond the pale of what the language is or does. I don't see how an extension permitting extra commas would qualify.

On Sat, Aug 4, 2018 at 10:37 AM, Joachim Breitner wrote:

...

Hi,

Am Samstag, den 02.06.2018, 13:04 -0700 schrieb Iavor Diatchki: > Well, I think it is a bad idea. Obviously I don't think it has a > huge impact on the language, but I think it encourages poor style, > for very questionable befits. This is quite subjective, of course, > but I think that this choice is at odds with Haskell's elegant > surface syntax. We don't allow repeated punctuation in written > prose,,,, why would we want in our programs?,,,

looks like there is some discussion needed here…

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

...

...

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

-- 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

_______________________________________________ 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 -- Joachim Breitner mail@joachim-breitner.de http://www.joachim-breitner.de/