[antlr-interest] V3: Clarification parser vs tree grammer, and a question

Kay Roepke kroepke at classdump.org
Thu Dec 28 00:49:37 PST 2006

Hi Mark!

On 28. Dec 2006, at 4:43 , Mark Mandel wrote:

> The way I'm seeing it at the moment is that the job of the Parser is
> to build the AST tree.  It defines the tokens, explains where the root
> of the tree should be, and defines the structure of the children.

Very correct, if you have output=AST, of course ;)

> The tree grammer is how to DO something with that tree (I believe in
> v2, it was a tree walker?).  Basically it parses the AST Tree that is
> built in the Parser grammer.


> It's almost like it is the parser's parser ... if that remotely  
> makes any sense.
> So that means that the rule structure of the tree grammer should match
> the tree structure that is generated by the parser grammer.

Yes, very much like a parser recognizes token sequences from a  
stream, a tree parser
recognizes tree/subtree sequences. Internally, it is pretty much the  
same, a tree node
stream just has support for extra (special) tokens in there. Those  
are UP and DOWN
and mark the spots where a substree begins and ends.

> Onto a second question -
> If my treeParser requires other Java objects to evaluate the tree it
> has been passed, is there some way to add that to the Constructor of
> the generated TreeParser, OR is the best way simply to make a
> setMyLib(myLib) function via the @members section, and call that prior
> to evaluating the tree?

What do you mean by evaluating the tree? Normally, you would use a  
tree parser for evaluation.
You'd specify the evaluation code in actions in your (sub)rules. If  
you need to have several
passes, you'd normally have several tree parsers.
Aside from that, if you want to avoid putting a lot of code into  
@members you can use the
superClass option (I hope the spelling is right, check the wiki!).  
That's not for grammar
inheritance, but only influences the code generated, i.e. that  
'superClass' must inherit
from TreeParser. It allows you to put common code into a .java file  
and gives you the benefit of
being able to use your favorite Java IDE for that code. At the same  
time it keeps
your grammar file size down, which might make it easier to read.

<shameless plug>
Of course, if you'd be using Objective-C, you could just define the  
methods/messages in
categories and be done with it ;)
</shameless plug>


Kay Röpke

More information about the antlr-interest mailing list