(1,0) > 2 I find the arguments in all directions compelling, so it's hard to land on a preference. But looking for a principle that could guide us - perhaps it is "commas are significant in code but not in import/export lists". It would be harder to state a similar principle if we started allowing extra commas in some places in code. Cheers Simon On Mon, 22 Jun 2026 at 21:05, Jaro Reinders via ghc-steering-committee < ghc-steering-committee@haskell.org> wrote:
Dear fellow committee members,
At ZuriHac we briefly discussed the "Unordered extra commas" proposal and concluded we see two promising options for where commas should be allowed:
1. The minimalist option: we limit the proposal to just concern commas in import and export lists (and sublists). With the reasoning that those places are the most important and less likely to set expectations thus reducing potential confusion. Note that trailing commas in import and export lists (not sublists) are already allowed, so this would just add leading commas in these lists and sublists and trailing commas in sublists.
2. The maximalist option: we allow extra commas everywhere except for tuples because that conflicts with TupleSections. Note that with the syntactic unification work this also excludes type level tuples as eventually I assume TupleSections will also apply there. A caveat to that caveat is that constraint contexts are technically its own thing and not a type-level tuple, so extra commas would be allowed there.
Of course there is also always option 0: to do nothing.
Please reply to this e-mail with your vote by June 29.
Cheers,
Jaro
P.S. I'm not entirely sure whether this should be the final vote or whether there should be a second, final vote after changes have been made to the proposal to reflect the results of this vote. On 5/18/26 14:00, Jaro Reinders via ghc-steering-committee 'ghc-steering-committee at haskell.org' wrote:
Dear fellow committee members,
We have a proposal in the pipeline about allowing extra commas <https://github.com/ghc-proposals/ghc-proposals/pull/748> 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