[antlr-interest] CommonTree & Tree grammar versus DIY

[Foust]

> Carter Cheng wrote:
> The difficulty I have been facing is how best to manipulate these trees
> during subsequent passed through them especially if multiple passes are
> needed to check for various properties, construct the symbol table and
> for type checking. Would this entail using multiple tree grammar files
> one for each pass?
> 
> It seems that it might be easier at present to DIY the AST construction
> using a tailored representation to the grammar in question as would be
> done if I was using something like YACC.

You could use the same tree walker (generated from one tree grammar file),
but just call it several times with a different action object for the pass
that you want it to execute. That part isn't automatic, but at least you
wouldn't have to duplicate your tree grammar for each pass. Just as a
homegrown walker could be written to be re-used by multiple passes, so could
the Antlr-generated one.

Otherwise, you'd have to duplicate your tree grammar (maybe with a few small
variations in the patterns being looked at) which seems like it could be a
maintenance headache. 

> 
> Is this really the case or are there compelling reasons for using the
> ^() syntax?

In theory, a tree grammar allows you to specify patterns you want matched in
a terse, easy-to-read manner; then it generates the tree walker for you,
executing any custom actions specified.

In practice, it may be a little time-consuming getting the grammar just
right and tracking down issues with what gets matched in what order and how
to manipulate the underlying tree. It feels more brittle than just placing
the actions right in the grammar, like is typically done with yacc, because
when the grammar changes, the tree grammar may have to be updated, too, to
keep functioning. But since your custom tree walker would have to be updated
in the same manner, a text representation of your tree walker is probably
easier to maintain. And since it allows EBNF notation, it's a lot easier to
write in the first place.
 
Brent