
| What I think you are proposing is to capture commas in a different way | altogether before this stage, and I do not understand how or where No. I'm proposing this. Insetad of data HsRecFields id = HsRecFields { rec_flds :: [HsRecField id arg], rec_dotdot :: Maybe Int have this: data HsRecFields id = HsRecFields { rec_flds :: HsCommaList (HsRecField id arg), rec_dotdot :: Maybe Int data HsCommaList a = Empty | ExtraComma (HsCommaList a) | Cons a (HsCommaList a) So that HsCommaList a is very like [a] but can express precisely where the extra commas appear. Now adapt the parser to produce a (HsCommaList (HsRecField RdrName (LHsExpr RdrName))), rather than a list of those things. The renamer then complains if it finds any ExtraComma constructors, unless the -XExtraCommas is specified. Does that help? Simon | -----Original Message----- | From: Alexander Berntsen [mailto:alexander@plaimi.net] | Sent: 23 September 2014 10:40 | To: Simon Peyton Jones | Subject: Re: ExtraCommas | | -----BEGIN PGP SIGNED MESSAGE----- | Hash: SHA256 | | On 23/09/14 11:28, Simon Peyton Jones wrote: | > My advice was only: parse commas *always* as if they were part of | the | > language. (So the parser has no conditinoals.) Reject them later (in | > the renamer) if the language extension is not enabled. | I don't understand this. From my limited understanding commas are | lexed, and then I can, in the parser, pattern match on things. Here's | a very specific example, record field update/construction: | | fbinds :: { ([HsRecField RdrName (LHsExpr RdrName)], Bool) } | : fbinds1 { $1 } | | {- empty -} { ([], False) } | | fbinds1 :: { ([HsRecField RdrName (LHsExpr RdrName)], Bool) } | : fbind ',' fbinds1 { case $3 of (flds, dd) -> | ($1 : flds, dd) } | | fbind { ([$1], False) } | | '..' { ([], True) } | | What's happening here is that fbinds uses a helper fbinds1, to capture | both fbinds1 & emptys. So to add support for leading/trailing commas, | what I did is simply pattern match on them: | | fbinds :: { ([HsRecField RdrName (LHsExpr RdrName)], Bool) } | : ',' fbinds1 { $2 } | | fbinds1 { $1 } | | fbinds1 :: { ([HsRecField RdrName (LHsExpr RdrName)], Bool) } | : fbind ',' fbinds1 { case $3 of | (flds, dd) -> ($1 : flds, dd) | } | | fbind { ([$1], False) } | | '..' { ([], True) } | | {- empty -} { ([], False) } | | You can observe that I am now using fbinds to capture ',' fbinds1, and | have moved the empty match to fbinds1 itself. | | This is the general pattern I have used for all of my patches so far. | | | What I think you are proposing is to capture commas in a different way | altogether before this stage, and I do not understand how or where | this is meant to happen. And it also sounds like your suggestion will | mean I need to handle the case where extra commas are *not* supposed | to be handwaved, like tuples. So please elaborate, if you can. | | > Happy to talk. I'm simonpj0 on skype. | Do you happen to use any non-proprietary tool or at least protocol? | - -- | Alexander | alexander@plaimi.net | https://secure.plaimi.net/~alexander | -----BEGIN PGP SIGNATURE----- | Version: GnuPG v2 | Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ | | iF4EAREIAAYFAlQhP9sACgkQRtClrXBQc7U0+gD/TvT+9iVA6JqiopTfeYEc7NU2 | USD2bf+bKwhy9MNUjssA/3YUjA3PVYRpw1RFoRQF15zBFF6WDH5PQbS/8/5q7h+P | =saJc | -----END PGP SIGNATURE-----

Something else to throw into the mix, once the Located replacement by
Genlocated is done for hsSyn I intend to capture the locations of all
non-captured syntactic elements, such as commas.
So this proposed mechanism would help, provided the location of each comma
is also tracked.
Alan
On Fri, Sep 26, 2014 at 5:46 PM, Simon Peyton Jones
| What I think you are proposing is to capture commas in a different way | altogether before this stage, and I do not understand how or where
No. I'm proposing this. Insetad of
data HsRecFields id = HsRecFields { rec_flds :: [HsRecField id arg], rec_dotdot :: Maybe Int
have this:
data HsRecFields id = HsRecFields { rec_flds :: HsCommaList (HsRecField id arg), rec_dotdot :: Maybe Int
data HsCommaList a = Empty | ExtraComma (HsCommaList a) | Cons a (HsCommaList a)
So that HsCommaList a is very like [a] but can express precisely where the extra commas appear.
Now adapt the parser to produce a (HsCommaList (HsRecField RdrName (LHsExpr RdrName))), rather than a list of those things.
The renamer then complains if it finds any ExtraComma constructors, unless the -XExtraCommas is specified.
Does that help?
Simon
| -----Original Message----- | From: Alexander Berntsen [mailto:alexander@plaimi.net] | Sent: 23 September 2014 10:40 | To: Simon Peyton Jones | Subject: Re: ExtraCommas | | -----BEGIN PGP SIGNED MESSAGE----- | Hash: SHA256 | | On 23/09/14 11:28, Simon Peyton Jones wrote: | > My advice was only: parse commas *always* as if they were part of | the | > language. (So the parser has no conditinoals.) Reject them later (in | > the renamer) if the language extension is not enabled. | I don't understand this. From my limited understanding commas are | lexed, and then I can, in the parser, pattern match on things. Here's | a very specific example, record field update/construction: | | fbinds :: { ([HsRecField RdrName (LHsExpr RdrName)], Bool) } | : fbinds1 { $1 } | | {- empty -} { ([], False) } | | fbinds1 :: { ([HsRecField RdrName (LHsExpr RdrName)], Bool) } | : fbind ',' fbinds1 { case $3 of (flds, dd) -> | ($1 : flds, dd) } | | fbind { ([$1], False) } | | '..' { ([], True) } | | What's happening here is that fbinds uses a helper fbinds1, to capture | both fbinds1 & emptys. So to add support for leading/trailing commas, | what I did is simply pattern match on them: | | fbinds :: { ([HsRecField RdrName (LHsExpr RdrName)], Bool) } | : ',' fbinds1 { $2 } | | fbinds1 { $1 } | | fbinds1 :: { ([HsRecField RdrName (LHsExpr RdrName)], Bool) } | : fbind ',' fbinds1 { case $3 of | (flds, dd) -> ($1 : flds, dd) | } | | fbind { ([$1], False) } | | '..' { ([], True) } | | {- empty -} { ([], False) } | | You can observe that I am now using fbinds to capture ',' fbinds1, and | have moved the empty match to fbinds1 itself. | | This is the general pattern I have used for all of my patches so far. | | | What I think you are proposing is to capture commas in a different way | altogether before this stage, and I do not understand how or where | this is meant to happen. And it also sounds like your suggestion will | mean I need to handle the case where extra commas are *not* supposed | to be handwaved, like tuples. So please elaborate, if you can. | | > Happy to talk. I'm simonpj0 on skype. | Do you happen to use any non-proprietary tool or at least protocol? | - -- | Alexander | alexander@plaimi.net | https://secure.plaimi.net/~alexander | -----BEGIN PGP SIGNATURE----- | Version: GnuPG v2 | Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ | | iF4EAREIAAYFAlQhP9sACgkQRtClrXBQc7U0+gD/TvT+9iVA6JqiopTfeYEc7NU2 | USD2bf+bKwhy9MNUjssA/3YUjA3PVYRpw1RFoRQF15zBFF6WDH5PQbS/8/5q7h+P | =saJc | -----END PGP SIGNATURE----- _______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Just to let everyone know ExtraCommas is still alive: Alan and I just
had a pleasant chat as alluded to in the forwarded message below.
Despite being busy with other engagements lately, I am now picking up
the ExtraCommas work again. I will be operating on the same level as
Alan is in his work, and we'll be colliding a bit, no doubt. As such I
will make efforts to collaborate with Alan in making the merge process
nice before I submit any patches to phab.
My plan now is simply:
-hack around and get confident with the hsSyn code (I am quite
confident in the Happy code already),
-make a Wiki article with my idea and the details,
-hack hack hack,
-work with Alan to make sure merging is smooth,
-& finally, submit a patch (or several).
- -Alexander
- -------- Original Message --------
Subject: Re: Capturing commas in the GHC parser
Date: Mon, 13 Oct 2014 13:37:28 +0200
From: Alan & Kim Zimmerman
Hallo Alan,
I've been away for a week on a conference. In my absence I see you have made some posts about capturing commas in API annotations. Prior to leaving I was working on an ExtraCommas language pragma.
I had accomplished trailing & leading commas for signature variables, fixity declarations, list expressions, import & export declarations, record updates, record declaration & maybe more that I don't remember. The way I had accomplished this was by manually editing the happy code.
SPJ showed me that I should have been messing about a level up, like you are doing.
Consequently, I have a few questions. How much does your work overlap with what I am doing? How far have you come? Do you have some advice for what I want to do?
If we could schedule a little meeting for us to have a chat via instant messaging, that would be great. I am on irc.freenode.net as <bernalex>, on XMPP via
, and you can call me via SIP if you want to do audio/video chat using . Hi
I am alanz on freenode, and alan.zimm@gmail.com which may still come through on XMPP via hangouts. I actually did a large part of working a HsCommaList through the AST, including all the subsequent phases (renamer,typechecker etc), but have since backed it out as I was misusing the structure firstly, and I had come up with another means of doing it. My last commit with this in is https://github.com/alanz/ghc/tree/b970d42e1e6bc46077a60a602413d990615e3896 As you can see it is quite a far-reaching change, and mingled in with my annotations stuff too. I will be happy to talk to you about this, because it makes sense for our stuff to work together, otherwise it will be much harder to merge at a later date. I am hoping to get my annotation changes to the AST and parser firmed up this week, so that I can then just try to work with it to see that I have everything captured. Is there a place I can see what you have done? Regards Alan -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iF4EAREIAAYFAlQ72icACgkQRtClrXBQc7XtzwEAt2zTN8AVkY6Jox75TcyFG9Ks l26QndI+gvszGao89xEA/RfYpGMEarMB4tM2mtIZDI3dE53LC64zOnHfzE7N3G7f =FViZ -----END PGP SIGNATURE-----
participants (3)
-
Alan & Kim Zimmerman
-
Alexander Berntsen
-
Simon Peyton Jones