Dear fellow committee members, Viktor has implemented option 2 following the result of our vote, so the proposal now allows leading and trailing commas in every comma-separated list except for things that look like tuples (i.e., anything in a term, type, or constraint that is delimited by parentheses). This proposal reduces a multitude of small friction points to do with such sequences: allowing for easier addition and removal, nicer diffs, simpler CPP, and easier code generation by external tools. The benefits are not ground-breaking, but the cost is also small. So, I ask you to review this proposal and I recommend that we should accept it. Cheers, Jaro On 7/1/26 23:12, Jaro Reinders via ghc-steering-committee 'ghc-steering-committee at haskell.org' wrote:
Dear all,
The results are in. I'm not sure what the usual vote counting method is, but I'll use the Concordet method, which imagines three head-to-head elections:
- 0 vs. 1, which would have resulted in option 1 winning with 5 out of 7 votes
- 0 vs. 2, which would result in option 2 winning with 4 out of 7 votes
- 1 vs. 2, which would result in option 2 winning with 5 out of 8 votes
(If a committee member did not express their preference between the two options in one of these three imagined head-to-head elections, then I did not count their vote. That's why two scenarios have 7 total votes and the other has 8 total votes.)
So *option 2* is a Concordet winner, winning against both option 0 and option 1 separately. However, the results also show the committee is quite divided and some of the votes on option 2 were conditional.
One of the main concerns is the need for a simple rule for when extra commas are allowed that is also not too ad hoc. I propose the following:
"Extra commas are allowed everywhere, except as part of constructs which are delimited by round brackets in terms or types (or constraints)."
The need to avoid conflicts with tuple sections means this is still a bit ad hoc, but I hope this to be acceptable for everyone and recommend that the proposal proceeds in this direction. If you have remaining objections or suggestions, please share them so that we can take them into account.
Thank you for voting,
Jaro
On 6/22/26 22:05, Jaro Reinders via ghc-steering-committee 'ghc-steering-committee at 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