[antlr-interest] CommonTree & Tree grammar versus DIY

Terence Parr parrt at cs.usfca.edu
Fri Aug 22 14:02:12 PDT 2008


Hi Andy,
I think we are again saying the same thing but don't realize it :)

I agree, if all you care about is one construct, why waste the time  
building a complete tree grammar. This is the approach of my filter  
mode for lexers. If you look at my fuzzy Java example, it pulls out  
Java declarations without providing a full grammar. Works great.  
Similarly, ANTLRMorph is doing the same thing but at a grammatical  
level. Further, it will also know how to rewrite trees so that you can  
morph one tree to another. It has an option called conforms so that  
you can tell the rewrite engine whether or not it should enforce valid  
structure on the rewritten text. It also indicates whether it should  
reapply the rules for that construct looking for more to rewrite. for  
example, x+0+0 should apply the following rule twice:

"x + 0" -> "<x>"

So, yes, my goal is to delineate the translation rules in a manner  
similar to what you do but hopefully in a slightly more formal manner.  
I will do this at the text or tree level :)  Rather, Leon Su's  
ANTLRMorph will do this :)

one final note: tree walking is great for computations. For example,  
computing the type of a large expression is best done with a recursive  
tree walk. You can either build one by hand or use a grammar. Up to  
you, but there is no escaping that the  computation must do a bottom- 
up walk. Given the recursive nature of the problem:

type(operatorsubtree) = resultType(type(e.operand[0]),  
operatorsubtree, type(e.operand[1]);

a recursive tree walker/visitor seems the most natural means of  
specifying. I happen to use a grammar for this as grammars are  
naturally recursive as well. Further, sometimes the same node type in  
different contexts results in a different type; grammars are good at  
that context stuff.

Ter


More information about the antlr-interest mailing list