[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