Permitting trailing commas for record syntax ADT declarations

Richard Eisenberg eir at
Fri Sep 26 19:17:01 UTC 2014

A modest counter-proposal to this idea:

What if we just stopped requiring commas in import/export lists? As far as I can tell, they're not necessary for proper parsing.

This doesn't solve other problems, but I'm not convinced every problem in this domain needs the same solution.

In particular, I'm -1 on allowing a loose interpretation of commas in lists, as it seems very strange to have commas in lists and commas in tuples have a different meaning. (I'm +1 on fixing import/export lists, though.)


On Sep 25, 2014, at 8:06 AM, Herbert Valerio Riedel <hvriedel at> wrote:

> On 2014-09-25 at 13:34:16 +0200, Daniel Trstenjak wrote:
> [...]
>> One compromise could be, that additional commatas in literal lists
>> are only allowed at the beginning and at the end.
> ...another idea could be to make it a separate Pragma
> (e.g. ExtraCommasLists) if there's a chance of ListSections (which would
> conflict with this) becoming a reality.
>> Then your use case would work and also something like:
>>   abc = [ 
>>      -- a
>>      , a
>>      -- b
>>      , b
>>      -- c
>>      , c
>>      ]
> I'd probably prefer leading-comma over trailing-comma style anyway (as
> I've grown to like it over the years).
>> I think that are the main uses of additional commatas in literal lists
>> and I can't see that someone really wants a list literal like '[,3,,4,]',
>> so wrongly reading it as a list section shouldn't be an issue.
> Yeah, I don't care much about extra middle-commas either. Personally,
> I'd be already happy with just trailing & leading extra-comma support.
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at

More information about the ghc-devs mailing list