Don't worry about supporting trailing/leading commas everywhere for now. Have it work for records first. We can always add support in more places later. On Mon, Sep 22, 2014 at 9:07 PM, Simon Peyton Jones wrote:

I’m all for it. To progress it you need to

· open a Trac ticket,

· start a wiki page to describe the design specifically (e.g give all the changed syntax rules)

· have a language extension TrailingCommas (or something) to enable the extension

· perhaps suggest switching on the extension if the program parses with it, but fails without

· develop a patch

Easy really! I doubt it’s controversial.

Simon

*From:* ghc-devs [mailto:ghc-devs-bounces@haskell.org] *On Behalf Of *Johan Tibell *Sent:* 22 September 2014 14:28 *To:* Alexander Berntsen *Cc:* ghc-devs@haskell.org *Subject:* Re: Permitting trailing commas for record syntax ADT declarations

+1

I think this makes sense and we should allow trailing commas wherever the syntax allows it without adding ambiguity (e.g. tuple sections prevent trailing commas for tuple declarations.)

P.S. Last time we tried to discuss something like this (on libraries@ I believe) the whole discussion devolved into a "lets rewrite all of Haskell". Lets not do that here. Thanks!

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 22/09/14 21:07, Simon Peyton Jones wrote:

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?

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-----

| presently), whilst requiring a pragma means either making the parser | code really messy "everywhere" there's a comma, or having lots of | duplication there. I don't understand this at all. The standard way is simply to parse the comma(s) always, record the presence of trailing comma(s) in the syntax tree, and then complain/reject in the renamer if the extension is not enabled. That does not make the parser really messy anywhere, I think. You might want a new HsSyn data type for "list with possible leading or trailing commas": data HsCommadList a = HCL Int -- Number of leading commas [a] Int -- Number of trailing commas Simon | | And giving it some thought, I'd argue for going more or less the same | route with regards to patches for a pragma. I.e. add an initial patch | that adds the pragma itself & leading commas for imports/exports, and | then submit a bunch of small commits to augment the pragma to | phabricator, and update the Wiki accordingly. | | | In any event, I'll have to get everything working, so you'll have | plenty of time meanwhile to decide on this issue. | - -- | Alexander | alexander@plaimi.net | https://secure.plaimi.net/~alexander | -----BEGIN PGP SIGNATURE----- | Version: GnuPG v2 | Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ | | iF4EAREIAAYFAlQhIZQACgkQRtClrXBQc7V2AwD/SkAHL0fIXhP3DDmI0i7IipeJ | 8Z1JT0k8YqyssJtq6YgBAIB4betQXTHMDt0IGu+OLty6A6iGp2WZQ4kRNlx1lVWa | =1xbA | -----END PGP SIGNATURE-----

To account for all forms of leading/trailing separators, I suggest to call the pragma SpuriousSeparators or ExtraSeparators If you want to do it only for commas, I suggest ExtraCommas (not the proper latin plural, which would be ExtraCommata, but certainly preferable :-)). On 23.09.2014 09:31, Simon Peyton Jones wrote:

| > 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

-- Andreas Abel <>< Du bist der geliebte Mensch. Department of Computer Science and Engineering Chalmers and Gothenburg University, Sweden andreas.abel@gu.se http://www2.tcs.ifi.lmu.de/~abel/

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 23/09/14 09:31, Simon Peyton Jones wrote:

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. If this policy has been followed that firmly then I too am reluctant to go against it. A pragma it is then.

Alexander alexander@plaimi.net https://secure.plaimi.net/~alexander -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iF4EAREIAAYFAlQhI9gACgkQRtClrXBQc7X4kAEAn5XrGTFZa0AR372xPEKS2ddE vt5DYJ+wU+xjYW6HYSYBAKMqdL3bO7Q8GNNQmX4OQhcrwvpQcSov17F2E5FyFrI/ =BGZA -----END PGP SIGNATURE-----

I must say that requiring a language pragma makes the feature quite a bit more heavy weight. We're not changing the meaning of any existing programs, just allowing some new ones. One could argue that perhaps the HaskellXX standard might pick up this new pragma and thus making it unnecessary eventually, but the standardization process is dead (and even when it was alive, it was lagging actual practice enough that it was largely ignored.) On Tue, Sep 23, 2014 at 9:41 AM, Roman Cheplyaka wrote:

On 23/09/14 10:11, Alexander Berntsen wrote:

...

On 22/09/14 21:07, Simon Peyton Jones wrote:

...

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?

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.

Here's my reasoning:

If you invoke ghc with -XHaskell2010, then trailing commas shouldn't be accepted, because they do not belong to Haskell 2010.

Which means that you do need an extension to identify this difference in behavior.

Roman

We're not changing the meaning of any existing programs, just allowing some new ones. Yes, that’s true of quite a few other extensions too, notably UnicodeSyntax. Even GADTs!! It’s hard to know where to draw the line. There is, in theory at least, the point that the language extension signals that this module might not work with some other Haskell compiler. My instinct is to treat it uniformly, like other language extensions. But strong sentiment to the contrary from GHC users would persuade me. It’s not that big a deal. Simon From: Johan Tibell [mailto:johan.tibell@gmail.com] Sent: 23 September 2014 09:03 To: Roman Cheplyaka Cc: Alexander Berntsen; Simon Peyton Jones; ghc-devs@haskell.org Subject: Re: Permitting trailing commas for record syntax ADT declarations I must say that requiring a language pragma makes the feature quite a bit more heavy weight. We're not changing the meaning of any existing programs, just allowing some new ones. One could argue that perhaps the HaskellXX standard might pick up this new pragma and thus making it unnecessary eventually, but the standardization process is dead (and even when it was alive, it was lagging actual practice enough that it was largely ignored.) On Tue, Sep 23, 2014 at 9:41 AM, Roman Cheplyaka mailto:roma@ro-che.info> wrote: On 23/09/14 10:11, Alexander Berntsen wrote:

On 22/09/14 21:07, Simon Peyton Jones wrote:

...

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?

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.

Here's my reasoning: If you invoke ghc with -XHaskell2010, then trailing commas shouldn't be accepted, because they do not belong to Haskell 2010. Which means that you do need an extension to identify this difference in behavior. Roman

On Tue, Sep 23, 2014 at 10:03:11AM +0200, Johan Tibell wrote:

I must say that requiring a language pragma makes the feature quite a bit more heavy weight. We're not changing the meaning of any existing programs, just allowing some new ones.

Without using a new language pragma you will get more or less telling error messages if you're trying to compile code using this new syntax with older ghcs. Using a new language pragma will give you quite telling error messages. Greetings, Daniel

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 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

That also lets me somehow question the whole proposal if you can get rid of most problems by just changing your coding style:

module A ( a , b , c ) where ...

data A = A { a :: Int , b :: Int , c :: Int }

abc = [ a , b , c ] During hacking sessions I often find myself in the need of commenting out the first import /record field/list element. With the proposed change I can just:

   module A       ( --a       , b       , c       ) where ...    data A = A       { --a :: Int       , b :: Int       , c :: Int       }    abc = [ --a          , b          , c          ] As things are now I am forced to edit the second line as well. (And when I'm uncommenting things I need to edit the second line again). This is mostly irritating and that's why I think implementing this proposal will be a Good Thing. Janek

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 mailto: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 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 | | alexander@plaimi.net mailto: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 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.abel@gu.se http://www2.tcs.ifi.lmu.de/~abel/

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 24/09/14 08:50, Edward Kmett wrote:

I'm personally of the "it should be a language extension like everything else" mindset Yeah, I'm going the Pragma route.

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'm implementing it for things where I 100% subjectively feel it makes sense. This does *not* include tuples, for the reason you mention.

When I get the time, I will make a Wiki page outlining what I'm changing and my motivation for doing it. We can then have a discussion about where to draw the line. I need to figure out a more elegant solution than tweaking the parser for each individual item. If someone knows their way around this code, please talk to me on IRC/SIP/XMPP/whatever. Just email me for contact info. I'll be busy today with a haskell workshop, but I plan on spending the rest of the week on this business. - -- Alexander alexander@plaimi.net https://secure.plaimi.net/~alexander -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iF4EAREIAAYFAlQinw4ACgkQRtClrXBQc7VL4gD6Ao12HqH1Mjl30n/1Mwlby7W6 /2+JeUOF9ui959xh1QkBAIdTA6km9gDvgCQ1nBQ5juZFNF79C1Fezk2yEpOvF7Fe =l/sh -----END PGP SIGNATURE-----

Ah, just look at all these brace-and-semicolon languages, and how they thrive, and how many beginners have mastered them... #include int main () { ; /* It is sunny today, so I am in the mood for a leading semi. */ ; /* Still not in the mood to start work. */ int i; ; for (i=0; i < 5; i++) { printf("%d", i); }; /* Mmh, do you need to put a semi after the closing brace? */ /* Let's put one, just to be sure. */ /* TODO: more code */; } import Data.Foldable (forM_) main = do { ; -- It is sunny today, so I am in the mood for a leading semi. ; -- Still not in the mood to start work. ; forM_ [0..4] $ \ i -> do { print i ;} ;} -- Mmh, do you need to put a semi befor the closing brace? -- Let's put one, just to be sure. On 25.09.2014 09:13, Iavor Diatchki wrote:

Hello,

My 2c: I don't think that supporting trailing commas is worth the additional complexity to the compiler and the language.

I work with Haskell on a daily basis, and I honestly don't think that this is going to simplify my job in any way. On the other hand, it seems like it it will make it more complex to write tools that process Haskell, and to explain the syntax of the language to beginners.

-Iavor

On Wed, Sep 24, 2014 at 12:38 PM, Alexander Berntsen mailto:alexander@plaimi.net> wrote:

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256

On 24/09/14 08:50, Edward Kmett wrote: > I'm personally of the "it should be a language extension like > everything else" mindset Yeah, I'm going the Pragma route.

> 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'm implementing it for things where I 100% subjectively feel it makes sense. This does *not* include tuples, for the reason you mention.

When I get the time, I will make a Wiki page outlining what I'm changing and my motivation for doing it. We can then have a discussion about where to draw the line.

I need to figure out a more elegant solution than tweaking the parser for each individual item. If someone knows their way around this code, please talk to me on IRC/SIP/XMPP/whatever. Just email me for contact info. I'll be busy today with a haskell workshop, but I plan on spending the rest of the week on this business. - -- Alexander alexander@plaimi.net mailto:alexander@plaimi.net https://secure.plaimi.net/~alexander -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iF4EAREIAAYFAlQinw4ACgkQRtClrXBQc7VL4gD6Ao12HqH1Mjl30n/1Mwlby7W6 /2+JeUOF9ui959xh1QkBAIdTA6km9gDvgCQ1nBQ5juZFNF79C1Fezk2yEpOvF7Fe =l/sh -----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.abel@gu.se http://www2.tcs.ifi.lmu.de/~abel/

I agree with Iavor on this one. I use Haskell professionally as well, and I'm actually quite fond of what it leaves out in terms of both syntax and semantics, as opposed to what it adds. Whether it's pragma protected or not, I just don't see the point of complicating the language with such a seemingly minor feature. Also, as pointed out before, the tuple-sections feature interact badly with this, and the treatment of commas in lists and tuples being different is a source of concern. If it's added, however, it should definitely be pragma protected as I'm pretty sure if I ever have extra commas lying around it's because I inadvertently deleted something or made some other cut-paste error. I'd like GHC to keep telling me about those in perpetuity. -Levent. On Thu, Sep 25, 2014 at 1:10 AM, Alexander Berntsen wrote:

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256

On 25/09/14 09:13, Iavor Diatchki wrote:

...

I work with Haskell on a daily basis, and I honestly don't think that this is going to simplify my job in any way. I too work with Haskell every day, and I *know* this will make my job easier.

...

On the other hand, it seems like it it will make it more complex to write tools that process Haskell, and to explain the syntax of the language to beginners. Not sure how it will make tools more complicated as a pragma. & they can always just not support the pragma if it's that hard.

---

Alexander alexander@plaimi.net https://secure.plaimi.net/~alexander -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iF4EAREIAAYFAlQjzfcACgkQRtClrXBQc7WO8wEAndhjRsCkVXp2mJWSW1steQYT 1C9P6pzzntViDQS9tHsA/09GSKO0lHlmU1B5PWKkGkNmiCFV8hJUzTEYAo1363E8 =0Db/ -----END PGP SIGNATURE----- _______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs

There’s a danger of disappearing into a bikeshed here. I think it’s clear that: · If we have it at all, ExtraCommas should be a {-# LANGUAGE ExtraCommas #-} extension, like any other. · ExtraCommas should leave tuples alone (always) Provided there is that LANGUAGE extension, I have no objection to having it in GHC if Alexander wants to implement it. It has low impact, and some people like it a lot. People who don’t like it don’t have to switch on the extension. It’s unclear whether extra commas in literal lists [a,,b,,] should behave like TupleSections or like ExtraCommas. My instinct is the former, because the only difference is round vs square parens. That would suggest continuing to make extra commas illegal in literal lists, for now anyway. That’s a conservative choice, which is usually the side to err on when it’s a toss-up. OK? Simon From: Iavor Diatchki [mailto:iavor.diatchki@gmail.com] Sent: 25 September 2014 08:14 To: Alexander Berntsen Cc: Edward Kmett; Simon Peyton Jones; ghc-devs@haskell.org Subject: Re: Permitting trailing commas for record syntax ADT declarations Hello, My 2c: I don't think that supporting trailing commas is worth the additional complexity to the compiler and the language. I work with Haskell on a daily basis, and I honestly don't think that this is going to simplify my job in any way. On the other hand, it seems like it it will make it more complex to write tools that process Haskell, and to explain the syntax of the language to beginners. -Iavor On Wed, Sep 24, 2014 at 12:38 PM, Alexander Berntsen mailto:alexander@plaimi.net> wrote: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 24/09/14 08:50, Edward Kmett wrote:

I'm personally of the "it should be a language extension like everything else" mindset Yeah, I'm going the Pragma route.

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'm implementing it for things where I 100% subjectively feel it makes sense. This does *not* include tuples, for the reason you mention.

When I get the time, I will make a Wiki page outlining what I'm changing and my motivation for doing it. We can then have a discussion about where to draw the line. I need to figure out a more elegant solution than tweaking the parser for each individual item. If someone knows their way around this code, please talk to me on IRC/SIP/XMPP/whatever. Just email me for contact info. I'll be busy today with a haskell workshop, but I plan on spending the rest of the week on this business. - -- Alexander alexander@plaimi.netmailto:alexander@plaimi.net https://secure.plaimi.net/~alexander -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iF4EAREIAAYFAlQinw4ACgkQRtClrXBQc7VL4gD6Ao12HqH1Mjl30n/1Mwlby7W6 /2+JeUOF9ui959xh1QkBAIdTA6km9gDvgCQ1nBQ5juZFNF79C1Fezk2yEpOvF7Fe =l/sh -----END PGP SIGNATURE----- _______________________________________________ ghc-devs mailing list ghc-devs@haskell.orgmailto:ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs

Sounds good to me. On Thu, Sep 25, 2014 at 11:18 AM, Simon Peyton Jones wrote:

There’s a danger of disappearing into a bikeshed here. I think it’s clear that:

· If we have it at all, ExtraCommas should be a {-# LANGUAGE ExtraCommas #-} extension, like any other.

· ExtraCommas should leave tuples alone (always)

Provided there is that LANGUAGE extension, I have no objection to having it in GHC if Alexander wants to implement it. It has low impact, and some people like it a lot. People who don’t like it don’t have to switch on the extension.

It’s unclear whether extra commas in literal lists [a,,b,,] should behave like TupleSections or like ExtraCommas. My instinct is the former, because the only difference is round vs square parens. That would suggest continuing to make extra commas illegal in literal lists, for now anyway. That’s a conservative choice, which is usually the side to err on when it’s a toss-up.

OK?

Simon

*From:* Iavor Diatchki [mailto:iavor.diatchki@gmail.com] *Sent:* 25 September 2014 08:14 *To:* Alexander Berntsen *Cc:* Edward Kmett; Simon Peyton Jones; ghc-devs@haskell.org *Subject:* Re: Permitting trailing commas for record syntax ADT declarations

Hello,

My 2c: I don't think that supporting trailing commas is worth the additional complexity to the compiler and the language.

I work with Haskell on a daily basis, and I honestly don't think that this is going to simplify my job in any way. On the other hand, it seems like it it will make it more complex to write tools that process Haskell, and to explain the syntax of the language to beginners.

-Iavor

On Wed, Sep 24, 2014 at 12:38 PM, Alexander Berntsen wrote:

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256

On 24/09/14 08:50, Edward Kmett wrote:

...

I'm personally of the "it should be a language extension like everything else" mindset Yeah, I'm going the Pragma route.

...

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'm implementing it for things where I 100% subjectively feel it makes sense. This does *not* include tuples, for the reason you mention.

When I get the time, I will make a Wiki page outlining what I'm changing and my motivation for doing it. We can then have a discussion about where to draw the line.

I need to figure out a more elegant solution than tweaking the parser for each individual item. If someone knows their way around this code, please talk to me on IRC/SIP/XMPP/whatever. Just email me for contact info. I'll be busy today with a haskell workshop, but I plan on spending the rest of the week on this business. - -- Alexander alexander@plaimi.net https://secure.plaimi.net/~alexander -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iF4EAREIAAYFAlQinw4ACgkQRtClrXBQc7VL4gD6Ao12HqH1Mjl30n/1Mwlby7W6 /2+JeUOF9ui959xh1QkBAIdTA6km9gDvgCQ1nBQ5juZFNF79C1Fezk2yEpOvF7Fe =l/sh

-----END PGP SIGNATURE----- _______________________________________________ ghc-devs mailing list 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

On Thu, Sep 25, 2014 at 12:03:13PM +0200, Herbert Valerio Riedel wrote:

I'd just like to point out, that lists are something that you may want to tweak regularily in code (while tuple are rather fixed-size entities whose size is extended less frequently)

Consider the following JSON example:

foo = object [ "key1" .= True, "key2" .= 123, "key3" .= (), ]

This is code where I often tend to add/remove lines, and ExtraCommas would greatly reduce the diff-noise, and which I really miss from languages such as Python which allow me to use trailing commas.

One compromise could be, that additional commatas in literal lists are only allowed at the beginning and at the end. Then your use case would work and also something like: abc = [ -- a , a -- b , b -- c , c ] 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. Greetings, Daniel

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 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@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs

+1 to leading and trailing separators. On 22.09.2014 16:01, Johan Tibell wrote:

On Mon, Sep 22, 2014 at 3:57 PM, Herbert Valerio Riedel

https://github.com/tibbe/haskell-style-guide/blob/master/haskell-style.md

Nice, style guide. I'll probably fork it for the Agda project... -- Andreas Abel <>< Du bist der geliebte Mensch. Department of Computer Science and Engineering Chalmers and Gothenburg University, Sweden andreas.abel@gu.se http://www2.tcs.ifi.lmu.de/~abel/