I (and Claude) developed the following generalisation of a spec and posted about it on GH:
-XExtraCommas allows optional leading and trailing commas in grammar productions that use commas to separate elements of a sequence. **Optional leading commas** are allowed iff the sequence has a left introducer token, such as an opening bracket or `|`. **Optional trailing commas** are allowed iff the token that bounds the list on the right is disjoint from `FIRST(element)`. Precisely, `FIRST(element)` must be disjoint to `FOLLOW(sequence)`. A clash with `-XTupleSections` syntax forbids extra commas in tuple syntax.
IMO this spec is flexible enough to allow for incremental implementation improvements without requiring a GHC proposal each time and without requiring us to list all the interacting syntax constructs in the spec. We only need to amend the proposal when we add another TupleSections-like extension. Sebastian Am Mo., 25. Mai 2026 um 10:04 Uhr schrieb Adam Gundry <adam@well-typed.com>:
I agree that ordered/unordered seems to have little to do with whether extra commas are allowed. The main cases where extra commas have a reason to be disallowed are:
- tuples (because of TupleSections) - lists (for consistency with tuples, and to leave open the possibility of list sections I guess?) - constraint contexts (for consistency with tuples)
Are there other cases where they should clearly be disallowed?
I'm generally in support of this idea, but I think we should make sure the treatment of all comma-separated syntax is consistent as far as possible (rather than making an ad hoc selection of some syntactic forms to permit extra commas). Unfortunately the text of the current proposal doesn't demonstrate that the details have been carefully thought through.
Cheers,
Adam
On 25/05/2026 08:04, Sebastian Graf wrote:
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):
* Constraint tuples `(Eq a, Show a) =>` (as pointed out by Jaro). I think it would be hard to allow extra commas in constraint tuples but not general tuples, though. * Fundeps `class C a b | a -> b, b -> a where …` * Multi-name signatures `f, g, h :: Int -> Int` * Nested field-name lists (TIL) `R { x, y :: Int, z :: Bool }` * GADT record fields (different production to regular fields) `data T where MkT :: { x :: Int, y :: Int } -> T` * Fixity `infixl 6 *, +` is deferred. * Pragmas: COMPLETE, MINIMAL, DEPRECATED, WARNING. (Not LANGUAGE or OPTIONS_GHC, I think, because they are ordered.)
Will give it a full read later. Sebastian
Am Sa., 23. Mai 2026 um 18:08 Uhr schrieb Jeff Young <jmy6342@gmail.com <mailto: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 <mailto: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 <mailto:ghc- steering-committee@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 <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 <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
-- Adam Gundry, Haskell Consultant Well-Typed LLP, https://www.well-typed.com/
Registered in England & Wales, OC335890 27 Old Gloucester Street, London WC1N 3AX, England
_______________________________________________ ghc-steering-committee mailing list -- ghc-steering-committee@haskell.org To unsubscribe send an email to ghc-steering-committee-leave@haskell.org