I'm personally of the "it should be a language extension like everything else" mindset. Sure, it is a pain, but then so is working with EmptyCase, TupleSections, DoRec, EmptyDataDecls, ImplicitParams, KindSignatures, MultiWayIf, TypeOperators, UnicodeSyntax, etc. All of which just make a few more programs compile in the same sense, and fit into the gaps in the existing grammar.

The conflict with TupleSections came up the last time this was proposed.

If we limit it to record-like notions, and import/export lists, then we don't have to deal with conflicts with TupleSections and while it is inconsistent to have tuples behave differently, than other comma-separated lists, I'd really rather retain tuple sections, which I use somewhat heavily, than lose them to mindless uniformity over how we handle comma-separated lists.

I use TupleSections a fair bit, whereas I've adopted prefixed comma-lists in Haskell to avoid the need for an extension like this one, so it'd be quite a shift in my programming style to get to where this helps me. The one place I'd really want something like this proposal is for the first line of my export list, where adopting the prefixed ',' convention + haddock sections makes for an annoying visual asymmetry.

-Edward

On Tue, Sep 23, 2014 at 4:55 AM, Simon Peyton Jones <simonpj@microsoft.com> wrote:
PS I have to admit that GHC already fails to adhere to H-2010 by accepting trailing commas in module import lists, *without* a language extension.  That is naughty, but I suppose it is a foot in the door.   What to others think?

Incidentally, trailing commas in tuples have quite a different meaning. With TupleSections,  (a,,b,) means \x y -> (a,x,b,y).

Simon

| -----Original Message-----
| From: Simon Peyton Jones
| Sent: 23 September 2014 08:32
| To: 'Alexander Berntsen'; Johan Tibell
| Cc: ghc-devs@haskell.org
| Subject: RE: Permitting trailing commas for record syntax ADT
| declarations
|
| | > have a language extension TrailingCommas (or something) to enable
| | > the extension
| | For clarification: are you overruling the "do we sneak it in HEAD or
| | use pragma(s)"-vote and telling me to do the latter?
|
| Well, it *is* a language extension, exactly like lots of other language
| extensions, isn't it? (E.g. UnicodeSyntax.)  What alternative action,
| exactly, are you proposing?   Why do you propose to treat it differently
| to other language extensions?  I would be reluctant to simply add it
| without any indication; then GHC would accept non-Haskell 2010 programs.
| And we have not done that with other extensions.
|
| Simon
|
| |
| | If we can sneak it into HEAD (this is @ you Johan, too), I suggest
| | that someone applies my patches to make import and export lists
| | support leading commas (presently they only support trailing commas,
| | per the report) -- and following this I can just send a bunch of
| | "Permit leading/trailing ',' in Foo" patches to Phabricator, and you
| | guys can bikeshed over there about which ones you actually want to
| | commit. ;-)
| |
| | If I am to go down the pragma route, I guess I can make a
| | RudundantCommas pragma or something like that, that implements
| | trailing commas for imports/exports, and leading/trailing commas for
| | the suggestions in this thread.
| |
| | I'm +1 on the GHC HEAD route, but I'm not exactly violently opposed to
| | the pragma route either.
| | - --
| | Alexander
| | alexander@plaimi.net
| | https://secure.plaimi.net/~alexander
| | -----BEGIN PGP SIGNATURE-----
| | Version: GnuPG v2
| | Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
| |
| | iF4EAREIAAYFAlQhHRoACgkQRtClrXBQc7U0WAD+Ixdah2pHMoeLiTGQJf0JLwDR
| | I2dxYS7yaKyOHuHcUuEBAKh6RQmmpztz82yt/KCw0n2md3pf4n8yc5tt9s9k3FW3
| | =FfHX
| | -----END PGP SIGNATURE-----
_______________________________________________
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs