Re: Permitting trailing commas for record syntax ADT declarations
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 22/09/14 22:02, Johan Tibell wrote: > 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. I already have it for records. It seems to be working fine. I thought I'd spend the day adding it for some of the other suggestions as well. It seems to be quite easy, and it's a neat learning experience for getting intimate with the parser. - -- Alexander alexan...@plaimi.net https://secure.plaimi.net/~alexander -BEGIN PGP SIGNATURE- Version: GnuPG v2 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iF4EAREIAAYFAlQhG7oACgkQRtClrXBQc7WDFQD+IuS5t+jeiZzNY57QIzbN9g0Q iSvtDST3dMX1X3Ielq4A/idQ7NdyBewJGMG2DKrxu7ZFqhxeP/kQmjpeVUnRszzL =7w7H -END PGP SIGNATURE- ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Permitting trailing commas for record syntax ADT declarations
-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 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 http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Permitting trailing commas for record syntax ADT declarations
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 A piece of information which might be relevant: if we play the pragma game, be prepared for patches that are much more involved. Sneaking into HEAD means applying a few 2-5 line patches (from what I can tell presently), whilst requiring a pragma means either making the parser code really messy "everywhere" there's a comma, or having lots of duplication there. 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 alexan...@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- ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
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 | 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
Re: Permitting trailing commas for record syntax ADT declarations
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 | 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 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
Re: Permitting trailing commas for record syntax ADT declarations
-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 alexan...@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- ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Permitting trailing commas for record syntax ADT declarations
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 23/09/14 09:39, Andreas Abel wrote: > If you want to do it only for commas, I suggest ExtraCommas It's only going to be commas, I think. I don't care about the name. ExtraCommas is fine by me. - -- Alexander alexan...@plaimi.net https://secure.plaimi.net/~alexander -BEGIN PGP SIGNATURE- Version: GnuPG v2 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iF4EAREIAAYFAlQhJAYACgkQRtClrXBQc7XeIAD/em/K42ZxittTiDT5vU+p607I RJAhM5ZIHZDXbzKkV14BALQLxhuVX17Tsa4mWSQZ9vqTllwu0DMe+Atea6MxbGcj =vRVV -END PGP SIGNATURE- ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Permitting trailing commas for record syntax ADT declarations
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 signature.asc Description: OpenPGP digital signature ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
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 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 > > ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Permitting trailing commas for record syntax ADT declarations
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 23/09/14 10:03, 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. 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.) It makes it a *lot* more involved. And your reasoning of "hey, it doesn't break anything" was that of my own. Staring at the parser code this morning I've decided that if there's a pragma, I will add a Wiki page and Trac ticket and have everyone vote on what they want to go in, and then make *one* commit, "Add ExtraCommas" that does it all. It will be a gigantic mess to do it in small commits. - -- Alexander alexan...@plaimi.net https://secure.plaimi.net/~alexander -BEGIN PGP SIGNATURE- Version: GnuPG v2 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iF4EAREIAAYFAlQhKeYACgkQRtClrXBQc7U4twD8D/Z1Ae0AeBlmALwCj/UMbeJH Oa8d535Ce3qzyrU68xgBAJnjJJOYT2IScsfMiUDv7cwRGQisPBujHIedohmFUjT3 =WtsL -END PGP SIGNATURE- ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
RE: Permitting trailing commas for record syntax ADT declarations
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.tib...@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:r...@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 ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Permitting trailing commas for record syntax ADT declarations
Note that there's another dimension to this question: whether this pragma is switched on by default. We already have precedents like NondecreasingIndentation. So, if you mean heavy-weigth to use, not to implement, then this may address your concern. Now, with my haskell-src-exts maintainer hat on, things like this tend to be problematic for us, because users assume that if ghc compiles a program without any pragmas, so should HSE, which it currently doesn't. Perhaps we should try to replicate GHC's default behavior in terms of the default accepted language, too. But as a GHC user, I agree that this extension is innocent enough to be turned on by default. Still, Haskell 98 and Haskell 2010 should remain immutable, in my opinion. PS I just remembered that newer Cabals ask you to specify either Haskell98 or Haskell2010, so that might make a turned-on-by-default extension less useful and more confusing. On 23/09/14 11:03, 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. 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 >> >> > ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Permitting trailing commas for record syntax ADT declarations
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 ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
RE: Permitting trailing commas for record syntax ADT declarations
| 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 | alexan...@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- ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
RE: Permitting trailing commas for record syntax ADT declarations
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 | | 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 http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Permitting trailing commas for record syntax ADT declarations
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
See the diff/excerpt below. If it were a pragma, I think this might get
ugly quick (consider that this patch only adds leading/trailing commas
for record declarations).
If you think I should be changing things elsewhere/employing a different
approach, please let me know. This was just the place that seemed most
relevant to me.
diff --git a/compiler/parser/Parser.y.pp b/compiler/parser/Parser.y.pp
index fcc21e1..a9267bb 100644
- --- a/compiler/parser/Parser.y.pp
+++ b/compiler/parser/Parser.y.pp
@@ -1370,7 +1370,7 @@ constr_stuff :: { Located (Located RdrName,
HsConDeclDetails RdrName) }
| btype conop btype { LL ($2, InfixCon $1 $3) }
fielddecls :: { [ConDeclField RdrName] }
- -: {- empty -} { [] }
+: ',' fielddecls1 { $2 }
| fielddecls1 { $1 }
fielddecls1 :: { [ConDeclField RdrName] }
@@ -1378,6 +1378,7 @@ fielddecls1 :: { [ConDeclField RdrName] }
{ [ addFieldDoc f $4 | f <- $1 ] ++ addFieldDocs $5 $2 }
-- This adds the doc $4 to each field separately
| fielddecl { $1 }
+| {- empty -} { [] }
fielddecl :: { [ConDeclField RdrName] }-- A list because of f,g :: Int
: maybe_docnext sig_vars '::' ctype maybe_docprev { [
ConDeclField fld $4 ($1 `mplus` $5)
- --
Alexander
alexan...@plaimi.net
https://secure.plaimi.net/~alexander
-BEGIN PGP SIGNATURE-
Version: GnuPG v2
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iF4EAREIAAYFAlQhNrQACgkQRtClrXBQc7UfPQD/ThiruhidjdSHLBHz/cryR30V
l6SOdJ1ToExAE0Uv1JcA/RmkMOgi69JnfGrM0Fo6JLyXOIekjyuKLnA4Nm6ASQFk
=P5W7
-END PGP SIGNATURE-
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs
user001 failure
I'm getting a testsuite failure on Linux ../../libraries/unix/tests user001 [bad stdout] (normal) The error message is below. Does anyone have any ideas? Simon Actual stdout output differs from expected: --- ../../libraries/unix/tests/user001.stdout 2014-09-11 08:38:41.0 +0100 +++ ../../libraries/unix/tests/user001.run.stdout 2014-09-23 11:06:06.300082329 +0100 @@ -3,11 +3,11 @@ getEffectiveUserID: OK getEffectiveGroupID: OK getGroups: OK -getLoginName: OK +getLoginName: ERROR: getLoginName: does not exist (No such file or directory) getEffectiveUserName: OK getGroupEntryForID: OK getGroupEntryForName: OK getAllGroupEntries: OK getUserEntryForID: OK -getUserEntryForName: OK +getUserEntryForName: ERROR: getLoginName: does not exist (No such file or directory) getAllUserEntries: OK *** unexpected failure for user001(normal) ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: user001 failure
> > I’m getting a testsuite failure on Linux > >../../libraries/unix/tests user001 [bad stdout] (normal) > > > > The error message is below. Does anyone have any ideas? > ezyang reported the same problem, see: https://ghc.haskell.org/trac/ghc/ticket/1487 Thomas ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: ghc-devs Digest, Vol 133, Issue 40
Simon Peyton Jones wrote: > 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 > If we're going to go to the trouble of supporting extra leading and trailing commas, why not also support extra commas in the middle? That way, #include "theseexports" , #include "thoseexports" doesn't have to worry about how these and those exports are listed. David ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: GHC AST Annotations
I have created https://ghc.haskell.org/trac/ghc/ticket/9628 for this, and
have decided to first tackle adding a type parameter to the entire AST, so
that tool writers can add custom information as required.
My first stab at this is to do is as follows
```
data HsModule r name
= HsModule {
ann :: r, -- ^ Annotation for external tool writers
hsmodName :: Maybe (Located ModuleName),
-- ^ @Nothing@: \"module X where\" is omitted (in which case the
next
-- field is Nothing too)
hsmodExports :: Maybe [LIE name],
```
Salient points
1. It comes as the first type parameter, and is called r
2. It gets added as the first field of the syntax element
3. It is always called ann
Before undertaking this particular change, I would appreciate some feedback.
Regards
Alan
On Thu, Aug 28, 2014 at 8:34 PM, Alan & Kim Zimmerman
wrote:
> This does have the advantage of being explicit. I modelled the initial
> proposal on HSE as a proven solution, and I think that they were trying to
> keep it non-invasive, to allow both an annotated and non-annoted AST.
>
> I thiink the key question is whether it is acceptable to sprinkle this
> kind of information throughout the AST. For someone interested in
> source-to-source conversions (like me) this is great, others may find it
> intrusive.
>
> The other question, which is probably orthogonal to this, is whether we
> want the annotation to be a parameter to the AST, which allows it to be
> overridden by various tools for various purposes, or fixed as in Richard's
> suggestion.
>
> A parameterised annotation allows the annotations to be manipulated via
> something like for HSE:
>
> -- |AST nodes are annotated, and this class allows manipulation of the
> annotations.
> class Functor ast => Annotated ast where
>
>-- |Retrieve the annotation of an AST node.
> ann :: ast l -> l
>
> -- |Change the annotation of an AST node. Note that only the annotation
> of the node itself is affected, and not
> -- the annotations of any child nodes. if all nodes in the AST tree are
> to be affected, use fmap.
> amap :: (l -> l) -> ast l -> ast l
>
> Alan
>
>
> On Thu, Aug 28, 2014 at 7:11 PM, Richard Eisenberg
> wrote:
>
>> For what it's worth, my thought is not to use SrcSpanInfo (which, to me,
>> is the wrong way to slice the abstraction) but instead to add SrcSpan
>> fields to the relevant nodes. For example:
>>
>> | HsDoSrcSpan -- of the word "do"
>> BlockSrcSpans
>> (HsStmtContext Name) -- The parameterisation is
>> unimportant
>> -- because in this context we never
>> use
>> -- the PatGuard or ParStmt variant
>> [ExprLStmt id] -- "do":one or more stmts
>> PostTcType -- Type of the whole expression
>>
>> ...
>>
>> data BlockSrcSpans = LayoutBlock Int -- the parameter is the indentation
>> level
>> ... -- stuff to track the appearance of
>> any semicolons
>>| BracesBlock ... -- stuff to track the braces and
>> semicolons
>>
>>
>> The way I understand it, the SrcSpanInfo proposal means that we would
>> have lots of empty SrcSpanInfos, no? Most interior nodes don't need one, I
>> think.
>>
>> Popping up a level, I do support the idea of including this info in the
>> AST.
>>
>> Richard
>>
>> On Aug 28, 2014, at 11:54 AM, Simon Peyton Jones
>> wrote:
>>
>> > In general I’m fine with this direction of travel. Some specifics:
>> >
>> > ·You’d have to be careful to document, for every data
>> constructor in HsSyn, what the association between the [SrcSpan] in the
>> SrcSpanInfo and the “sub-entities”
>> > ·Many of the sub-entities will have their own SrcSpanInfo
>> wrapped around them, so there’s some unhelpful duplication. Maybe you only
>> want the SrcSpanInfo to list the [SrcSpan]s for the sub-entities (like the
>> syntactic keywords) that do not show up as children in the syntax tree?
>> > Anyway do by all means create a GHC Trac wiki page to describe your
>> proposed design, concretely.
>> >
>> > Simon
>> >
>> > From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of Alan
>> & Kim Zimmerman
>> > Sent: 28 August 2014 15:00
>> > To: ghc-devs@haskell.org
>> > Subject: GHC AST Annotations
>> >
>> > Now that the landmines have hopefully been cleared from the AST via [1]
>> I would like to propose changing the location information in the AST.
>> >
>> > Right now the locations of syntactic markers such as do/let/where/in/of
>> in the source are discarded from the AST, although they are retained in the
>> rich token stream.
>> >
>> > The haskell-src-exts package deals with this by means of using the
>> SrcSpanInfo data type [2] which contains the SrcSpan as per the current GHC
>> Located type but also has a list of SrcSpan s for the syntactic markers,
>> depending on the particular AST
Re: Permitting trailing commas for record syntax ADT declarations
i think this should be behind a pragma,
On Tue, Sep 23, 2014 at 5:00 AM, Alexander Berntsen
wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> See the diff/excerpt below. If it were a pragma, I think this might get
> ugly quick (consider that this patch only adds leading/trailing commas
> for record declarations).
>
> If you think I should be changing things elsewhere/employing a different
> approach, please let me know. This was just the place that seemed most
> relevant to me.
>
>
> diff --git a/compiler/parser/Parser.y.pp b/compiler/parser/Parser.y.pp
> index fcc21e1..a9267bb 100644
> - --- a/compiler/parser/Parser.y.pp
> +++ b/compiler/parser/Parser.y.pp
> @@ -1370,7 +1370,7 @@ constr_stuff :: { Located (Located RdrName,
> HsConDeclDetails RdrName) }
> | btype conop btype { LL ($2, InfixCon $1 $3) }
>
> fielddecls :: { [ConDeclField RdrName] }
> - -: {- empty -} { [] }
> +: ',' fielddecls1 { $2 }
> | fielddecls1 { $1 }
>
> fielddecls1 :: { [ConDeclField RdrName] }
> @@ -1378,6 +1378,7 @@ fielddecls1 :: { [ConDeclField RdrName] }
>{ [ addFieldDoc f $4 | f <- $1 ] ++ addFieldDocs $5
> $2 }
> -- This adds the doc $4 to each field
> separately
> | fielddecl { $1 }
> +| {- empty -} { [] }
>
> fielddecl :: { [ConDeclField RdrName] }-- A list because of f,g ::
> Int
> : maybe_docnext sig_vars '::' ctype maybe_docprev { [
> ConDeclField fld $4 ($1 `mplus` $5)
>
> - --
> Alexander
> alexan...@plaimi.net
> https://secure.plaimi.net/~alexander
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v2
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iF4EAREIAAYFAlQhNrQACgkQRtClrXBQc7UfPQD/ThiruhidjdSHLBHz/cryR30V
> l6SOdJ1ToExAE0Uv1JcA/RmkMOgi69JnfGrM0Fo6JLyXOIekjyuKLnA4Nm6ASQFk
> =P5W7
> -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
Re: Permitting trailing commas for record syntax ADT declarations
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 > | | 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 > http://www.haskell.org/mailman/listinfo/ghc-devs > ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
