Hi there,

First off, I think "unordered" might be the wrong qualifier here. Note that `default (Double, Integer)` is ordered, yet included in the set. I think we should just call it -XExtraCommas?

Just FYI, here are some "unordered sequences" that are not mentioned in the proposal (thanks, Claude):
Will give it a full read later.
Sebastian


Am Sa., 23. Mai 2026 um 18:08 Uhr schrieb Jeff Young <jmy6342@gmail.com>:
Hi everyone,

I support the proposal. I do not have very strong feelings about it but my preference is to allow leading and trailing commas without repetitive commas. Secondly, I unfortunately have to withdraw from the committee. I've been advised by a doctor to take a step back from some responsibilities and so I am heeding that advice. 

My apologies for the rather short tenure,

Jeff

On Tue, May 19, 2026 at 4:09 AM Simon Peyton Jones <simon.peytonjones@gmail.com> wrote:
I support the proposal

1. Does this proposal make the right selection of places where to allow extra commas? This proposal for example does not include commas in contexts ((...here...) => ...), or in lists. I personally think we should choose carefully to avoid the situation where we do want to allow extra commas in more places in the future, because we then either need a new extension or we need to change the meaning of this extension.

I'm happy with the choice here.  In tuples for example, extra commas can mean a tuple-section, e.g. (2,,4) with `-XTupleSections` means `\x. (2,x,4)`.

 2. Which extra commas do we allow? The current proposal is to allow an extra comma at the start AND at the end of a sequence. I personally think we should be more conservative and only allow one OR the other (exclusively). Another alternative is to allow extra commas anywhere in the list, even multiple in a row.

I prefer to allow both rather than to insist on one or the other.  It's a bit more liberal and has no downside that I can see. 

I would be entirely OK with allowing extra commas, thus
     ...deriving( Foldable,  ,  , Traversable ,,, )
It seems more consistent than only allowing a single extra comma at the beginning or end.  But I do not feel strongly.   Jaro, once others have expressed their views, you'll need to drive us to a conclusion about these issues, maybe by voting... it's just a matter of taste.

Simon
 




On Mon, 18 May 2026 at 13:00, Jaro Reinders via ghc-steering-committee <ghc-steering-committee@haskell.org> wrote:
Dear fellow committee members,

We have a proposal in the pipeline about allowing extra commas in sequences where the order does not matter. These extra commas (before the first item and/or after the last item) make code layout more consistent and reduce clutter in diffs. 

This is a limited version of an earlier proposal which did not make it because it sparked too much controversy. The current only allows redundant commas in uncontroversial places, which roughly lines up with the intuition that for all these places the order of the sequence items does not matter.

Since there hasn't been much discussion lately on this proposal, I'm asking you to provide your opinion. There are two main points of discussion:

1. Does this proposal make the right selection of places where to allow extra commas? This proposal for example does not include commas in contexts ((...here...) => ...), or in lists. I personally think we should choose carefully to avoid the situation where we do want to allow extra commas in more places in the future, because we then either need a new extension or we need to change the meaning of this extension.

2. Which extra commas do we allow? The current proposal is to allow an extra comma at the start AND at the end of a sequence. I personally think we should be more conservative and only allow one OR the other (exclusively). Another alternative is to allow extra commas anywhere in the list, even multiple in a row.

I'm looking forward to your opinions,

Jaro
_______________________________________________
ghc-steering-committee mailing list -- ghc-steering-committee@haskell.org
To unsubscribe send an email to ghc-steering-committee-leave@haskell.org
_______________________________________________
ghc-steering-committee mailing list -- ghc-steering-committee@haskell.org
To unsubscribe send an email to ghc-steering-committee-leave@haskell.org
_______________________________________________
ghc-steering-committee mailing list -- ghc-steering-committee@haskell.org
To unsubscribe send an email to ghc-steering-committee-leave@haskell.org