On Thu, Mar 17, 2011 at 5:54 PM, The Researcher <[email protected]>wrote:
> > > On Thu, Mar 17, 2011 at 8:56 AM, Stephen Tuttlebee < > [email protected]> wrote: > >> Hi Eric >> >> I don't know if I understand your question completely (I haven't read >> the previous questions you mentioned), but are you simply asking how you >> rewrite a tree using ANTLR? Or were you actually asking how ANTLR >> actually IMPLEMENTS this rewriting under the hood (i.e. what code does >> it generate to do the rewriting)? Or something else? >> >> If you were asking the first question, then I can provide a fairly >> simple example from a couple of grammars I have been working on recently >> (I don't know if the example is too simple since it only alters the tree >> in a very minor way, and maybe you're thinking along the lines of larger >> and more substantial changes to the tree). >> >> I have the 'phase 1 grammar' (JavaBPhase1Parser.g) that does the parsing >> and has tree rewrite rules to build an AST. This grammar has the >> following options: >> options { >> language = Java; >> output = AST; >> tokenVocab = JavaBLexer; >> } >> >> This grammar just builds a tree in the normal way. >> >> My 'phase 2 grammar' (JavaBPhase2WalkerSem1.g) is a tree grammar that >> reads that AST, performs some semantic analysis of the input and spits >> out an almost identical AST. It has similar options as before but the >> really important one here is the rewrite=true option: >> options { >> language = Java; >> output = AST; // since we are performing a tree rewrite, as well as >> reading in an AST, I will also be outputting an AST >> rewrite = true; // <---- this is the key option here >> tokenVocab = JavaBPhase1Parser; >> ASTLabelType = CommonTree; // this option here because we're >> reading in a tree and ANTLR would like to know the type of the nodes >> } >> >> The rewrite=true causes the tree to be spat out just the same as the >> input tree except where you specify otherwise. For example, in one rule >> I perform some semantic analysis that informs me on how to rewrite the >> tree: >> >> compositionExpression >> @init { >> boolean compositionComponent = false; // this is only here rather >> than further below where I would want to use it because in the code >> generated by ANTLR the variable is out of scope if I declare it down there >> } >> : ... // other tree rule >> | ... // other tree rule >> | ^(PLAIN_OR_COMPOSITION_COMPONENT ^(IDENT IDENTIFIER)) >> { .... some actions that perform semantic analysis (look up in >> the symbol table) to decide if compositionComponent is true or false } >> -> {compositionComponent}? ^(COMPOSITION_COMPONENT ^(IDENT >> IDENTIFIER)) >> -> >> ^(PLAIN_COMPONENT ^(IDENT IDENTIFIER)) >> >> >> In this example I am performing a very simple tree rewrite by simply >> changing the imaginary token of a subtree's root node, but you could >> change the entire subtree by changing the rewrite rule(s) to produce a >> completely different subtree. >> >> For larger, more 'structural' changes to the tree, I would imagine you >> need to do a fair amount of passing subtrees around as parameters / >> return values between rules so that you have access to the subtrees in >> the rules that need them. p170 of the ANTLR reference book has an >> example of this kind of thing (example is used in doing tree >> construction in a *parser* grammar but you can do exactly the same in a >> tree grammar). >> >> You can also have semantic predicates (I think that's the proper name) >> before multiple rewrite rules to rewrite the tree in different ways >> depending on what the boolean expression in the semantic predicates >> evaluates to. See page 181 of ANTLR reference for an example in the >> variableDefinition rule: >> variableDefinition >> : modifiers type ID ('=' expression)? ';' >> -> {inMethod}? ^(VARIABLE ID modifier* type expression?) // >> semantic predicate used here >> -> ^(FIELD ID modifier* type expression?) >> ; >> Again, that example is used in doing tree construction in a parser >> grammar but you can do exactly the same in a tree grammar. >> >> Bear in mind though (at least I think this is the case...), that with >> these semantic predicates you have to ensure that there is a default >> case which specifies the tree to be built if all the other previous >> semantic predicates evaluate to false. >> >> Hope this helps. >> > > Stephen, > > Thanks for the big road sign. I tried this originally but failed. I am > working on it again but am sure to have more questions. > > Thanks, Eric > > >> >> Stephen >> >> List: http://www.antlr.org/mailman/listinfo/antlr-interest >> Unsubscribe: >> http://www.antlr.org/mailman/options/antlr-interest/your-email-address >> > > Stephen, It now works. My problem was in my driver/test harness and not the rewrite rules. For others with similar problems; the best example of this can be found on the tree construction wiki page which I just now read. http://www.antlr.org/wiki/display/ANTLR3/Tree+construction Yes I spent to much time focused on the books and just needed to look at the wiki. Thanks, Eric List: http://www.antlr.org/mailman/listinfo/antlr-interest Unsubscribe: http://www.antlr.org/mailman/options/antlr-interest/your-email-address -- You received this message because you are subscribed to the Google Groups "il-antlr-interest" 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/il-antlr-interest?hl=en.
