Topic: Question concerning AST tree rewriting

Question concerning AST tree rewriting

1 posts in topic

Flat View

Thread View

Older Post First | Reply to Topic

TOPIC ACTIONS:

Print Topic

Posted By: Jonathan_Shapiro
Posted On: Tuesday, December 18, 2001 04:55 AM

This has to be a FAQ, but I cannot locate it. I have a production that looks like: enumDecl : "enum"^ nameDef LCURLY! enumConst ( COMMA! enumConst )* RCURLY! SEMI! ; The nameDef node is currently a singleton identifier, which I wish to rewrite for reasons of tree consistency, to get: #(ND_NAMEDEF, DUMMYTYPE_enumTag, #nameDef) That is, I want to inject a subtree that wraps the original nameDef node. I'm having trouble with the rewrite, because (a) I don't understand how to reach in and do the rewrite on the one element of the AST that is already built, and (b) given the * pattern I don't know how to c More>>

This has to be a FAQ, but I cannot locate it.

I have a production that looks like:

			

			enumDecl
			

			: "enum"^ nameDef LCURLY!
			

			enumConst
			

			( COMMA! enumConst )*
			

			RCURLY! SEMI!
			

			;

The nameDef node is currently a singleton identifier, which I wish to rewrite for reasons of tree consistency, to get:

#(ND_NAMEDEF, DUMMYTYPE_enumTag, #nameDef)

That is, I want to inject a subtree that wraps the original nameDef node.

I'm having trouble with the rewrite, because (a) I don't understand how to reach in and do the rewrite on the one element of the AST that is already built, and (b) given the * pattern I don't know how to construct the desired output AST by hand. I tried labeling the internal enumConsts as e1 and e2 and using (... , #e1, #e2), but the #e2 only gets expanded once even if that part of the pattern matches multiple times.

I'ld be willing to separate out the enumConsts as a subproduction, but if I do that I really need a way to splice the subordinate AST members into the middle of the parent AST.

Given the number of questions I see along similar lines to these, I'm struck by the thought that the AST pattern matching language really needs to be generalized. Providing list manipulation built-ins cons, nth, nthcdr and list splicing would go a very long way here toward addressing the kinds of things that seem to be confusing people.

In any case, can what I want be done within the AST synthesis language? How?

<<Less

Report | Quote This | Send private message | Reply | Print

Re: Question concerning AST tree rewriting

Posted By: Monty_Zukowski
Posted On: Wednesday, December 19, 2001 11:03 AM

Try this:


enumDecl
  : "enum"^ name:nameDef! {##=#(##, #(ND_NAMEDEF, DUMMYTYPE_enumTag, #name));}
    LCURLY!
    enumConst
    ( COMMA! enumConst )*
    RCURLY! SEMI!
  ;

You should end up with a tree like this:


#(LITERAL_enum, #(ND_NAMEDEF, DUMMYTYPE_enumTag, #name), enumConst1, enumConst2, etc...  )

Is this what you want? You had a question about the enumConsts--these will be tacked onto the end of the tree as I showed above. It is unusual to muck with the tree after it has been generated. Much easier to not generate for that piece, construct what you need, then tack it onto the end.

## is shorthand for the current AST.

Note that the more common idiom would be to wrap such a beast in the nameDef rule:


nameDef
  : (all of your rule here)
    { ## = #(ND_NAMEDEF, DUMMYTYPE_enumTag, ##);}
  ;

That keeps the AST structure the same for everyone referencing that rule. Except of course you have that DUMMYTYPE_enumTag, making the nameDef context specific to the enum, and that doesn't make sense if nameDefs are used elsewhere, as I suspect they are...

I haven't addressed some of your other stated concerns in the hopes that this example will either set you straight or give us a better vocabulary of idioms to address your points. Please continue this discussion, it will make a good FAQ.

Report | Quote This | Send private message | Reply | Print