Thanks Jaro As I mentioned in Zurich, I also prefer the minimalist approach (1) if we are to do anything at all. I’m not strongly opposed to doing (1), but I would be opposed to the maximalist approach (2), which feels too ad-hoc. The specification for (1) is clearer and I can see how it might be useful. Cheers, Rodrigo
On 23 Jun 2026, at 08:57, Simon Peyton Jones <simon.peytonjones@gmail.com> wrote:
Good summary.
I think I prefer (1) minimalist. The benefits are higher and the costs (in the form of unforeseen interactions) are lower.
Simon
On Mon, 22 Jun 2026 at 21:05, Jaro Reinders via ghc-steering-committee <ghc-steering-committee@haskell.org <mailto: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 <http://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 <mailto:ghc-steering-committee@haskell.org> To unsubscribe send an email to ghc-steering-committee-leave@haskell.org <mailto: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