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> 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> 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

_______________________________________________ ghc-steering-committee mailing list -- ghc-steering-committee@haskell.org To unsubscribe send an email to ghc-steering-committee-leave@haskell.org

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

Having thought about this some more, I think we should accept this proposal in principle, subject to the following revisions: - Rename the extension ExtraCommas. - Define the extension to work for all comma-separated syntax using a specification along the lines Sebastian proposes, including allowing list expressions, but with a specific exception for tuple syntax (including type-level tuples and constraint contexts). - Have the proposal explicitly set out the consequences of that specification given GHC's current grammar (i.e. set out all the syntactic forms that are affected, and those that are excluded by the tuple syntax exception). How does that sound? I think if we agree this, one of the committee should offer to help Viktor with the final revisions. (I'm willing to do this, but if someone else would be willing I don't feel strongly, e.g. Jaro you are the shepherd and I believe you looked at prototyping an implementation so you may have a clearer view?) Cheers, Adam On 25/05/2026 12:44, Sebastian Graf wrote:

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 <mailto: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> > <mailto: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> <mailto: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> <mailto:ghc- <mailto:ghc-> > steering-committee@haskell.org <mailto: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/ <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:committee@haskell.org> <mailto:ghc- steering- <mailto:ghc-steering-> > committee@haskell.org <mailto:committee@haskell.org>> >             To unsubscribe send an email to ghc-steering-committee- > leave@haskell.org <mailto:leave@haskell.org> <mailto:ghc- steering-committee- <mailto:ghc-steering-committee-> > leave@haskell.org <mailto:leave@haskell.org>> > >         _______________________________________________ >         ghc-steering-committee mailing list -- ghc-steering- > committee@haskell.org <mailto:committee@haskell.org> <mailto:ghc- steering-committee@haskell.org <mailto:ghc-steering- committee@haskell.org>> >         To unsubscribe send an email to ghc-steering-committee- > leave@haskell.org <mailto:leave@haskell.org> <mailto:ghc- steering-committee-leave@haskell.org <mailto:ghc-steering-committee- leave@haskell.org>> > >     _______________________________________________ >     ghc-steering-committee mailing list -- ghc-steering- > committee@haskell.org <mailto:committee@haskell.org> <mailto:ghc- steering-committee@haskell.org <mailto:ghc-steering- committee@haskell.org>> >     To unsubscribe send an email to ghc-steering-committee- > leave@haskell.org <mailto:leave@haskell.org> <mailto: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>

-- Adam Gundry, Haskell Consultant Well-Typed LLP, https://www.well-typed.com/ <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 <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>

-- 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

On 28/05/2026 10:37, Simon Peyton Jones wrote:

Yes I like that way forward. Thanks for summarising.

And yes, I think we should explicitly list out all the constructs to which the proposal applies; not just give a general principle.

What about guards? f x y | p x, q y = e g x | , p x,,, q y ,, = e

I assume the latter would be allowed, under the general principle, unless there's some parsing issue I'm not seeing? Indeed one might well want to allow extra commas in guards for something like this: foo x | -- p x -- commenting out p doesn't need more changes , q x , r x = e

I suppose the same question arises for semicolons, doesn't it? In do- notation and declarations?

Extra semicolons are already allowed (leading, trailing or repetitive), e.g. this is a valid declaration today: ; ;; foo True = False ; ; foo False = True ;; ; I think that's an argument for the proposal to be accepted, and perhaps implies repetitive commas should be allowed for consistency. Though I don't feel strongly about this as they don't seem that useful, and others seem more opposed to allowing them. Adam [Apologies Simon for the duplicate message, as I neglected to CC the committee list when replying to you at first.]

On Thu, 28 May 2026 at 09:26, Adam Gundry <adam@well-typed.com <mailto:adam@well-typed.com>> wrote:

Having thought about this some more, I think we should accept this proposal in principle, subject to the following revisions:

  - Rename the extension ExtraCommas.

  - Define the extension to work for all comma-separated syntax using a specification along the lines Sebastian proposes, including allowing list expressions, but with a specific exception for tuple syntax (including type-level tuples and constraint contexts).

- Have the proposal explicitly set out the consequences of that specification given GHC's current grammar (i.e. set out all the syntactic forms that are affected, and those that are excluded by the tuple syntax exception).

How does that sound?

I think if we agree this, one of the committee should offer to help Viktor with the final revisions. (I'm willing to do this, but if someone else would be willing I don't feel strongly, e.g. Jaro you are the shepherd and I believe you looked at prototyping an implementation so you may have a clearer view?)

Cheers,

Adam

On 25/05/2026 12:44, Sebastian Graf wrote: > 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 <http://typed.com> <mailto:adam@well-typed.com <mailto: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> <mailto:jmy6342@gmail.com <mailto:jmy6342@gmail.com>> >      > <mailto:jmy6342@gmail.com <mailto:jmy6342@gmail.com> <mailto: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> >     <mailto:simon.peytonjones@gmail.com <mailto:simon.peytonjones@gmail.com>> >     <mailto:simon.peytonjones@gmail.com <mailto:simon.peytonjones@gmail.com> >     <mailto: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> >     <mailto:ghc-steering-committee@haskell.org <mailto:ghc- steering-committee@haskell.org>> <mailto:ghc- <mailto:ghc-> <mailto:ghc- <mailto:ghc->> >      > steering-committee@haskell.org <mailto:steering- committee@haskell.org> <mailto:steering- <mailto:steering-> > committee@haskell.org <mailto: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- <https://github.com/ghc-proposals/ghc-> >     proposals/ <https://github.com/ghc-proposals/ghc-proposals/ <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:committee@haskell.org> <mailto:committee@haskell.org <mailto:committee@haskell.org>> <mailto:ghc- <mailto:ghc-> >     steering- <mailto:ghc-steering- <mailto:ghc-steering->> >      > committee@haskell.org <mailto:committee@haskell.org> <mailto:committee@haskell.org <mailto:committee@haskell.org>>> >      >             To unsubscribe send an email to ghc-steering- committee- >      > leave@haskell.org <mailto:leave@haskell.org> <mailto:leave@haskell.org <mailto:leave@haskell.org>> <mailto:ghc- <mailto:ghc-> >     steering-committee- <mailto:ghc-steering-committee- <mailto:ghc-steering-committee->> >      > leave@haskell.org <mailto:leave@haskell.org> <mailto:leave@haskell.org <mailto:leave@haskell.org>>> >      > >      >         _______________________________________________ >      >         ghc-steering-committee mailing list -- ghc-steering- >      > committee@haskell.org <mailto:committee@haskell.org> <mailto:committee@haskell.org <mailto:committee@haskell.org>> <mailto:ghc- <mailto:ghc-> > steering-committee@haskell.org <mailto:steering- committee@haskell.org> <mailto:ghc-steering- <mailto:ghc-steering-> > committee@haskell.org <mailto:committee@haskell.org>>> >      >         To unsubscribe send an email to ghc-steering- committee- >      > leave@haskell.org <mailto:leave@haskell.org> <mailto:leave@haskell.org <mailto:leave@haskell.org>> <mailto:ghc- <mailto:ghc-> > steering-committee-leave@haskell.org <mailto:steering-committee- leave@haskell.org> <mailto:ghc-steering-committee- <mailto:ghc- steering-committee-> > leave@haskell.org <mailto:leave@haskell.org>>> >      > >      >     _______________________________________________ >      >     ghc-steering-committee mailing list -- ghc-steering- >      > committee@haskell.org <mailto:committee@haskell.org> <mailto:committee@haskell.org <mailto:committee@haskell.org>> <mailto:ghc- <mailto:ghc-> > steering-committee@haskell.org <mailto:steering- committee@haskell.org> <mailto:ghc-steering- <mailto:ghc-steering-> > committee@haskell.org <mailto:committee@haskell.org>>> >      >     To unsubscribe send an email to ghc-steering-committee- >      > leave@haskell.org <mailto:leave@haskell.org> <mailto:leave@haskell.org <mailto:leave@haskell.org>> <mailto:ghc- <mailto:ghc-> > steering-committee-leave@haskell.org <mailto:steering-committee- leave@haskell.org> <mailto:ghc-steering-committee- <mailto:ghc- steering-committee-> > leave@haskell.org <mailto:leave@haskell.org>>> >      > >      > >      > _______________________________________________ >      > ghc-steering-committee mailing list -- ghc-steering- > committee@haskell.org <mailto:committee@haskell.org> <mailto:ghc- steering-committee@haskell.org <mailto:ghc-steering- committee@haskell.org>> >      > To unsubscribe send an email to ghc-steering-committee- > leave@haskell.org <mailto:leave@haskell.org> <mailto:ghc- steering-committee-leave@haskell.org <mailto:ghc-steering-committee- leave@haskell.org>> > >     -- >     Adam Gundry, Haskell Consultant >     Well-Typed LLP, https://www.well-typed.com/ <https:// www.well-typed.com/> <https://www.well- <https://www.well-> > typed.com/ <http://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 <mailto:committee@haskell.org> <mailto:ghc- steering-committee@haskell.org <mailto:ghc-steering- committee@haskell.org>> >     To unsubscribe send an email to ghc-steering-committee- > leave@haskell.org <mailto:leave@haskell.org> <mailto:ghc- steering-committee-leave@haskell.org <mailto:ghc-steering-committee- leave@haskell.org>> >

-- Adam Gundry, Haskell Consultant Well-Typed LLP, https://www.well-typed.com/ <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 <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>

-- 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

On 29/05/2026 01:10, Malte Ott wrote:

Just to be clear, the proposal had until now (amongst others) excluded list syntax because of the collision with a potential list-sections extension.

When we go in the proposed direction we are effectively closing the door on that one. Are we fine with that? I think I wouldn't be opposed. I rarely miss list-sections.

Yes, I wondered about this as well. However my sense is that list sections would be unreasonably confusing (especially if extra commas are allowed in other list-like syntactic forms), so I think it's more useful to allow extra commas in lists than to reserve the syntax for a possible future extension that is unlikely to arise. (There were some ideas in the discussion about coming up with a new syntax for sections, like \centerdot in Lean, so one could write a tuple section as `(1, ·, 3)` or a list section as `[1, ·, 3]`. I'm not sure that is really justified, but it seems like a more promising direction if we actually wanted list sections.) Cheers, Adam

Am 28. Mai 2026 11:52:03 MESZ schrieb Adam Gundry <adam@well-typed.com>:

On 28/05/2026 10:37, Simon Peyton Jones wrote:

Yes I like that way forward. Thanks for summarising.

And yes, I think we should explicitly list out all the constructs to which the proposal applies; not just give a general principle.

What about guards? f x y | p x, q y = e g x | , p x,,, q y ,, = e

I assume the latter would be allowed, under the general principle, unless there's some parsing issue I'm not seeing? Indeed one might well want to allow extra commas in guards for something like this:

foo x | -- p x -- commenting out p doesn't need more changes , q x , r x = e

I suppose the same question arises for semicolons, doesn't it? In do- notation and declarations?

Extra semicolons are already allowed (leading, trailing or repetitive), e.g. this is a valid declaration today:

; ;; foo True = False ; ; foo False = True ;; ;

I think that's an argument for the proposal to be accepted, and perhaps implies repetitive commas should be allowed for consistency. Though I don't feel strongly about this as they don't seem that useful, and others seem more opposed to allowing them.

Adam

[Apologies Simon for the duplicate message, as I neglected to CC the committee list when replying to you at first.]

On Thu, 28 May 2026 at 09:26, Adam Gundry <adam@well-typed.com <mailto:adam@well-typed.com <mailto:adam@well-typed.com>>> wrote:

Having thought about this some more, I think we should accept this proposal in principle, subject to the following revisions:

  - Rename the extension ExtraCommas.

  - Define the extension to work for all comma-separated syntax using a specification along the lines Sebastian proposes, including allowing list expressions, but with a specific exception for tuple syntax (including type-level tuples and constraint contexts).

- Have the proposal explicitly set out the consequences of that specification given GHC's current grammar (i.e. set out all the syntactic forms that are affected, and those that are excluded by the tuple syntax exception).

How does that sound?

I think if we agree this, one of the committee should offer to help Viktor with the final revisions. (I'm willing to do this, but if someone else would be willing I don't feel strongly, e.g. Jaro you are the shepherd and I believe you looked at prototyping an implementation so you may have a clearer view?)

Cheers,

Adam

On 25/05/2026 12:44, Sebastian Graf wrote:

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 <http://typed.com <http://typed.com>> <mailto:adam@well-typed.com <mailto:adam@well-typed.com>

<mailto:adam@well-typed.com <mailto: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 <mailto:jmy6342@gmail.com>>

<mailto:jmy6342@gmail.com <mailto:jmy6342@gmail.com> <mailto:jmy6342@gmail.com <mailto:jmy6342@gmail.com>>>

      > <mailto:jmy6342@gmail.com <mailto:jmy6342@gmail.com> <mailto:jmy6342@gmail.com <mailto:jmy6342@gmail.com>>

<mailto:jmy6342@gmail.com <mailto:jmy6342@gmail.com> <mailto: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 <mailto:simon.peytonjones@gmail.com>>

     <mailto:simon.peytonjones@gmail.com <mailto:simon.peytonjones@gmail.com>

<mailto:simon.peytonjones@gmail.com <mailto:simon.peytonjones@gmail.com>>>

     <mailto:simon.peytonjones@gmail.com <mailto:simon.peytonjones@gmail.com>

<mailto:simon.peytonjones@gmail.com <mailto:simon.peytonjones@gmail.com>>

     <mailto:simon.peytonjones@gmail.com <mailto:simon.peytonjones@gmail.com>

<mailto: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 <mailto:ghc-steering- committee@haskell.org>>

     <mailto:ghc-steering-committee@haskell.org <mailto:ghc-steering-committee@haskell.org> <mailto:ghc- <mailto:ghc->

steering-committee@haskell.org>> <mailto:ghc- <mailto:ghc-> <mailto:ghc- <mailto:ghc->> <mailto:ghc- <mailto:ghc-> <mailto:ghc- <mailto:ghc->>>

      > steering-committee@haskell.org <mailto:steering- <mailto:steering->

committee@haskell.org> <mailto:steering- <mailto:steering-> <mailto:steering- <mailto:steering->>

committee@haskell.org <mailto:committee@haskell.org <mailto: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- <https://github.com/ghc-proposals/ghc->

<https://github.com/ghc-proposals/ghc- <https://github.com/ghc- proposals/ghc->>

     proposals/ <https://github.com/ghc-proposals/ghc- proposals/ <https://github.com/ghc-proposals/ghc-proposals/>

<https://github.com/ghc-proposals/ghc-proposals/ <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:committee@haskell.org <mailto:committee@haskell.org>>

<mailto:committee@haskell.org <mailto:committee@haskell.org> <mailto:committee@haskell.org <mailto:committee@haskell.org>>> <mailto:ghc- <mailto:ghc-> <mailto:ghc- <mailto:ghc->>

     steering- <mailto:ghc-steering- <mailto:ghc-steering-> <mailto:ghc-steering- <mailto:ghc-steering->>>       > committee@haskell.org <mailto:committee@haskell.org <mailto:committee@haskell.org>>

<mailto:committee@haskell.org <mailto:committee@haskell.org> <mailto:committee@haskell.org <mailto:committee@haskell.org>>>>

      >             To unsubscribe send an email to ghc- steering-

committee-

      > leave@haskell.org <mailto:leave@haskell.org <mailto:leave@haskell.org>>

<mailto:leave@haskell.org <mailto:leave@haskell.org> <mailto:leave@haskell.org <mailto:leave@haskell.org>>> <mailto:ghc- <mailto:ghc-> <mailto:ghc- <mailto:ghc->>

     steering-committee- <mailto:ghc-steering-committee- <mailto:ghc-steering-committee->

<mailto:ghc-steering-committee- <mailto:ghc-steering-committee->>>

      > leave@haskell.org <mailto:leave@haskell.org <mailto:leave@haskell.org>>

<mailto:leave@haskell.org <mailto:leave@haskell.org> <mailto:leave@haskell.org <mailto:leave@haskell.org>>>>

      >       >         _______________________________________________       >         ghc-steering-committee mailing list -- ghc- steering-       > committee@haskell.org <mailto:committee@haskell.org <mailto:committee@haskell.org>>

<mailto:committee@haskell.org <mailto:committee@haskell.org> <mailto:committee@haskell.org <mailto:committee@haskell.org>>> <mailto:ghc- <mailto:ghc-> <mailto:ghc- <mailto:ghc->>

steering-committee@haskell.org <mailto:steering- <mailto:steering->

committee@haskell.org> <mailto:ghc-steering- <mailto:ghc- steering-> <mailto:ghc-steering- <mailto:ghc-steering->>

committee@haskell.org <mailto:committee@haskell.org <mailto:committee@haskell.org>>>>       >         To unsubscribe send an email to ghc-steering-

committee-

      > leave@haskell.org <mailto:leave@haskell.org <mailto:leave@haskell.org>>

<mailto:leave@haskell.org <mailto:leave@haskell.org> <mailto:leave@haskell.org <mailto:leave@haskell.org>>> <mailto:ghc- <mailto:ghc-> <mailto:ghc- <mailto:ghc->>

steering-committee-leave@haskell.org <mailto:steering- committee- <mailto:steering-committee->

leave@haskell.org> <mailto:ghc-steering-committee- <mailto:ghc- steering-committee-> <mailto:ghc- <mailto:ghc-> steering-committee->

leave@haskell.org <mailto:leave@haskell.org <mailto:leave@haskell.org>>>>       >       >     _______________________________________________       >     ghc-steering-committee mailing list -- ghc- steering-       > committee@haskell.org <mailto:committee@haskell.org <mailto:committee@haskell.org>>

<mailto:committee@haskell.org <mailto:committee@haskell.org> <mailto:committee@haskell.org <mailto:committee@haskell.org>>> <mailto:ghc- <mailto:ghc-> <mailto:ghc- <mailto:ghc->>

steering-committee@haskell.org <mailto:steering- <mailto:steering->

committee@haskell.org> <mailto:ghc-steering- <mailto:ghc- steering-> <mailto:ghc-steering- <mailto:ghc-steering->>

committee@haskell.org <mailto:committee@haskell.org <mailto:committee@haskell.org>>>>       >     To unsubscribe send an email to ghc-steering- committee-       > leave@haskell.org <mailto:leave@haskell.org <mailto:leave@haskell.org>>

<mailto:leave@haskell.org <mailto:leave@haskell.org> <mailto:leave@haskell.org <mailto:leave@haskell.org>>> <mailto:ghc- <mailto:ghc-> <mailto:ghc- <mailto:ghc->>

steering-committee-leave@haskell.org <mailto:steering- committee- <mailto:steering-committee->

leave@haskell.org> <mailto:ghc-steering-committee- <mailto:ghc- steering-committee-> <mailto:ghc- <mailto:ghc-> steering-committee->

leave@haskell.org <mailto:leave@haskell.org <mailto:leave@haskell.org>>>>       >       >       > _______________________________________________       > ghc-steering-committee mailing list -- ghc-steering- committee@haskell.org <mailto:committee@haskell.org <mailto:committee@haskell.org>> <mailto:ghc- <mailto:ghc->

steering-committee@haskell.org <mailto:ghc-steering- <mailto:ghc-steering-> committee@haskell.org>>

      > To unsubscribe send an email to ghc-steering-committee- leave@haskell.org <mailto:leave@haskell.org <mailto:leave@haskell.org>> <mailto:ghc- <mailto:ghc->

steering-committee-leave@haskell.org <mailto:ghc-steering- committee- <mailto:ghc-steering-committee-> leave@haskell.org>>

     --      Adam Gundry, Haskell Consultant      Well-Typed LLP, https://www.well-typed.com/ <https:// www.well-typed.com/> <https://

www.well-typed.com/> <https://www.well <https://www.well>- <https://www.well <https://www.well>->

typed.com/ <http://typed.com/ <http://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 <mailto:committee@haskell.org <mailto:committee@haskell.org>> <mailto:ghc- <mailto:ghc->

steering-committee@haskell.org <mailto:ghc-steering- <mailto:ghc-steering-> committee@haskell.org>>

     To unsubscribe send an email to ghc-steering-committee- leave@haskell.org <mailto:leave@haskell.org <mailto:leave@haskell.org>> <mailto:ghc- <mailto:ghc->

steering-committee-leave@haskell.org <mailto:ghc-steering- committee- <mailto:ghc-steering-committee-> leave@haskell.org>>

-- Adam Gundry, Haskell Consultant Well-Typed LLP, https://www.well-typed.com/ <https://www.well- typed.com/> <https://www.well <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 <mailto: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 <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

On Mon, 25 May 2026 at 08:14, Adam Gundry <adam@well-typed.com> wrote:

As I'm still standing in for Simon as secretary, I'll update the website accordingly. (Simon, please do let me know if you'd like to take back up the reins.)

I'm gradually coming back up to speed but I'm going to be away on holiday for 2 weeks from 6 July. I'm happy to take over again but just bear in mind there will be a gap in service for those two weeks. Cheers Simon

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

I am leaning towards doing nothing, because the minimalist option does not seem worth adding yet another language extension. I just don't think the sublists are usually that long and leading commas are just a stylistic difference. I think we should take the maximalist approach if we want a language extension which allows more commas. So I'm 0 > 2 > 1.

On 22 Jun 2026, at 22: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

My vote is 2 > 1 > 0 (except that I would not allow extra commas in constraint contexts, in order to minimize their difference with type-level tuples). Rationale: extra commas seem useful in cases such as list expressions, record syntax and deriving clauses, just as much as import/export lists. Allowing them in every comma-separated list, including future extensions, seems more consistent than merely allowing them in import/export lists (especially since semicolon-separated lists already allow extra semicolons). The interaction with TupleSections is unfortunate but not that difficult to live with. Cheers, Adam On 24/06/2026 13:29, Rodrigo Mesquita wrote:

OK. To be clear, I’m 0 > 1 > 2

...

On 24 Jun 2026, at 13:10, Jaro Reinders via ghc-steering-committee <ghc-steering-committee@haskell.org> wrote:

I am leaning towards doing nothing, because the minimalist option does not seem worth adding yet another language extension. I just don't think the sublists are usually that long and leading commas are just a stylistic difference.

I think we should take the maximalist approach if we want a language extension which allows more commas.

So I'm 0 > 2 > 1.

...

On 22 Jun 2026, at 22: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 -- 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

It's 2 > 1 > 0 for me. Simon Marlow <marlowsd@gmail.com> schrieb am Do., 25. Juni 2026, 12:14:

(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

_______________________________________________ ghc-steering-committee mailing list -- ghc-steering-committee@haskell.org To unsubscribe send an email to ghc-steering-committee-leave@haskell.org

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

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

I vote to accept. A welcome proposal. On Fri, 24 Jul 2026 at 15:48, Jaro Reinders via ghc-steering-committee < ghc-steering-committee@haskell.org> wrote:

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

_______________________________________________ ghc-steering-committee mailing list -- ghc-steering-committee@haskell.org To unsubscribe send an email to ghc-steering-committee-leave@haskell.org

-- -- Matthías Páll Gissurarson <http://mpg.is/>

(2) was my least favourite option, but I'm not strongly against it. +0 Cheers, Simon On Fri, 24 Jul 2026 at 14:48, Jaro Reinders via ghc-steering-committee < ghc-steering-committee@haskell.org> wrote:

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

_______________________________________________ ghc-steering-committee mailing list -- ghc-steering-committee@haskell.org To unsubscribe send an email to ghc-steering-committee-leave@haskell.org

Thanks Jaro! I'm happy to accept modulo a couple of points I raised on GitHub: - Naming. I suggest we pick something simpler than `ExtraNonTupleCommas`, e.g. just `ExtraCommas`. - I'm not happy with quietly deprecating a valid Haskell 2010 program (`import (,)`). Can we just drop this? (The proposal doesn't actually specify what deprecation is envisaged.) Cheers, Adam On 13/08/2026 16:06, Jaro Reinders via ghc-steering-committee wrote:

Dear fellow committee members,

First, during the latest round of review a minor point surfaced about whether a comma should be allowed in an empty list. I have expressed my preference for disallowing commas in empty lists, because of possible confusion and lack of motivation. See the GitHub discussion for more information.

Second, this is a reminder that this proposal is waiting for review. As far as I can tell, I am still waiting for a final judgment from *Adam*, *Erik*, and *Jacob*. Please respond at your earliest convenience, but no later than *August 23.*

Cheers,

Jaro

On 7/24/26 15:48, Jaro Reinders via ghc-steering-committee 'ghc- steering-committee at haskell.org' wrote:

...

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

-- 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