Permitting trailing commas for record syntax ADT declarations

[Edward Kmett]

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 at 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 at 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 at 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 at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140924/35e631d6/attachment.html>