[antlr-interest] Composite Tree Grammars are things of beauty, but ...

Gary Miller miller.garym at gmail.com
Tue Mar 15 17:57:20 PDT 2011


Hey Jim,

Thanks for the wishes, the Sumwise is coming along nicely. I'm bashing
my head against an optimization problem at the moment, maybe due to a
monolithic code I wrote before I really knew what I was doing.

I'll got a test project up and running using your archetype.
As you know the 3.3 archetype an issue, but it get in the way of using
3.2 and created a project is a real b!t@#.
It would be nice if the archetype contained example unit tests, I
understand this might be a problem as you'll get complaints about
which unit test framework to use.
A small point the example command line on
http://www.antlr.org/wiki/display/ANTLR3/Building+ANTLR+Projects+with+Maven
contains
  "-Dpackage=com.yourcompany.package.path",
can you change it to valid Java e.g.
  "-Dpackage=com.yourcompany.pkg.path"

I like a lot of what you've done, the AbstractTLexer/Parser is nice
for the things I currently have in my @member block.
General I prefer delegation to inheritance and I tend to pass in an
object to the top rule. This delegate would be better passed into the
constructor of the abstract. One question, does this play nicely with
ANTLRWorks?

None of this address the reasons for tree grammar importing and the
desire to be able to refer to imported rules in a polymorphic way (if
that is the correct terminology).

I think a common pattern is to have multiple walkers that are
basically the same except for the actions, laziness, starting rule,
exception handling ....

It would be better to have one walker that specifies the complete tree
grammar and then tree grammars that customize this with overridden
rules and add actions.

Particularly with prototyping and new grammars that AST structure
changes frequently and having to update the multiple walkers is a
significant overhead. This is where the ability to refer to an import
(super) rule really comes in to it's own, as it gives the ability to
effectively do an action oriented style cross cut before and after a
rule. There are alternatives, e.g. are filtered walkers.

Probably the biggest benefit of pure tree walkers is maintainability.
Antlr without the actions and anys is extremely readable and what a
win if a sub tree grammar only has to implements the smallest set of
differences. Terence what about adding a "pure tree grammar" option
where @header, @member, scopes actions etc. and maybe even anys aren't
legal ?-)

Regards
Gary

P.S.
By laziness I mean a rule like
   if : ^(IF a=bool b=. c=. ) { $a.result ? walk( this, $b ) : walk(
this, $c ) ;   };
   bool : returns[ boolean result ] some rules with actions;

> Gary,
>
> Hope things are good and that your product is coming along nicely!
>
> The best way to deal with this to have your main including grammar
> implement a superclass, then all the other grammars will inherit it. That
> is where all your extra code and variables go and it works better that
> way. If you use Maven, my archetype will create this structure for you out
> of the box. Don’t put anything in the .g files that you can put in the
> super class.
>
> Jim


More information about the antlr-interest mailing list