Permitting trailing commas for record syntax ADT declarations
Richard Eisenberg
eir at cis.upenn.edu
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.)
Richard
On Sep 25, 2014, at 8:06 AM, Herbert Valerio Riedel <hvriedel at gmail.com> 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 haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
More information about the ghc-devs
mailing list