[antlr-interest] Rewrite a list to a set of trees

Gary R. Van Sickle g.r.vansickle at att.net
Fri May 22 03:39:31 PDT 2009


> At 17:58 22/05/2009, Gary R. Van Sickle wrote:
>  >var_decl_list
>  >	: TYPENAME ids+=IDENTIFIER (',' ids+=IDENTIFIER)* -> ^(VAR_DECL
>  >TYPENAME IDENTIFIER)+
>  >	;
>  >
>  >If your rule can't be reduced to a one-liner like that though (e.g.
>  >C declarations), things quickly get complicated, and I've yet to 
> 
>  >determine a good, general way of handling it.  You'll 
> probably  >want to look into ANTLR's rule parameters and 
> return values in  >that case.
> 
> I haven't actually tested this, but another way I think you 
> could do that would be something like this:
> 
> var_decl_list
>    : t=TYPENAME! var_decl[$t] (','! var_decl[$t])*
>    ;
> 
> var_decl[CommonToken typename]
>    : IDENTIFIER -> ^(VAR $typename IDENTIFIER)
>    ;
> 

Right, that's the other of the two main classes of solutions that I've been
able to come up with:

1.  Emit the tree at the very top level (i.e. what I wrote above).
2.  Emit the tree at the very bottom level (what you wrote).

The trouble in general is that you have to explicitly move information up or
down the tree in either case.  Maybe var_decl is used by more than one
higher-level rule - then you have to tell it which one it's being called
from, or else duplicate the rule, making your grammar larger.  Rules scopes
don't help because you don't know which rule you were called from in the
first place, and if you did you wouldn't need the scope.  You can also
simply punt it to the tree parser, but then it starts looking like a big
switch/case statement and it's not clear to me that you've gained anything.
In my current project (a C parser), I'm using a mix of all those techniques
in various places.  They all can be made to work, but none are what you'd
call "slick".  One thing I have yet to try is tree parser->tree parser, that
might help.

-- 
Gary R. Van Sickle
 



More information about the antlr-interest mailing list