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