On 7/11/08 18:43, Luke Kanies wrote:
> On Nov 6, 2008, at 4:32 PM, Brice Figureau wrote:
>
>> On 27/10/08 16:59, Luke Kanies wrote:
>>> On Oct 25, 2008, at 8:48 AM, Brice Figureau wrote:
>>>> I choose to push the comments on the stack on each LBRACE and pop on
>>>> each RBRACE. I also fetch a reset the current stack level on each
>>>> statement reduction. This way I can attach comment precisely to the
>>>> puppet statement they belong to.
>>> Seems reasonable. I did something similar when I had some code that
>>> needed to know whether it was in a define or not, and I think it's a
>>> pretty common pattern. It's clumsy, but then, LALR parses always
>>> are,
>>> it seems.
>> Except my proposed solution doesn't work all the time.
>>
>> This (simple) example fails:
>>
>> # comment
>> node test {
>> include klass
>> }
>>
>> When we read the comment we push "comment" on the comment stack.
>> When the parser calls the lexer to read the { we push a new stack
>> level.
>> When the parser calls the lexer to read the } we pop the stack.
>> Then the parser noticing the }, will reduce the include function, with
>> will fetch the current comment level as it documenation. Unfortunately
>> we already popped it, so the function include will get the #comment
>> comment as documenation instead of an empty level.
>>
>> Really, the only real fix is to push/pop on token shifting.
>> Unfortunately, this isn't possible with Racc at this time, except by
>> playing games (ie enable debug, override the methods that prints
>> when a
>> shift happens to push or pop our comment stack...arghhh...)
>>
>> The only other alternative I can think of is to change the grammar to
>> understand comments and deal with them directly in the parser
>> instead of
>> in the lexer (which has no knowledge of the language).
>>
>> If someone has a better idea, please speak up.
>> Otherwise, I'll start with the comment-enhanced parser grammar :-(
>
>
> The only other approaches I can think of involve keying off the
> tokens. E.g., you see a 'CLASS' token, and somehow associate the
> preceding comment with that token, either involving a hash table
> lookup in the lexer, or finding a way to pass the comment with the
> token and its value to the parser.
Yes, that can work. But see below for an alternative.
> Neither seems particularly fun, but then, neither does hte comment-
> enhanced parser.
Yes, I wasn't really motivated for the comment enhanced parser :-(
I found another solution during the night (not yet implemented) which I
find simpler and should work:
When the node/class (or any other block containing braces) is reduced we
know that we just closed a brace block. It is the perfect time to pop
the comment stack, and then associate the result with the AST node we're
building.
It just requires to add some lexer.commentpop code to the grammar rules
for the blocks statements (ie node, class, resources...), or
modification of Parser.ast()
What do you think about this?
--
Brice Figureau
Days of Wonder
http://www.daysofwonder.com
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Puppet Developers" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/puppet-dev?hl=en
-~----------~----~----~----~------~----~------~--~---
