I agree with Edward that TupleSections are too useful to trade for more
convenience to write large tuples on the *expression* level.
(If you habitually write write large tuple expressions instead of using
records, you should revisit your coding style, seriously!)
However, I see no problem to allow extra commas in *administrative*
tuples like in import/export lists. Thus, I see no problem if these two
kinds of tuples adhere to different syntax rules.
In previous discussions, there was a caveat raised that extra commata in
lists and tuples mean something else.
[,a,b,] is [a,b]
(,a,b,) is a tuple section
However, I never felt like having list sections would see abundant
usage. Thus, this discrepancy is ok, imho.
Cheers,
Andreas
On 24.09.2014 08:50, Edward Kmett wrote:
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
<simo...@microsoft.com <mailto:simo...@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 <mailto: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
| | alexan...@plaimi.net <mailto:alexan...@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 <mailto:ghc-devs@haskell.org>
http://www.haskell.org/mailman/listinfo/ghc-devs
_______________________________________________
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs
--
Andreas Abel <>< Du bist der geliebte Mensch.
Department of Computer Science and Engineering
Chalmers and Gothenburg University, Sweden
andreas.a...@gu.se
http://www2.tcs.ifi.lmu.de/~abel/
_______________________________________________
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs
