[antlr-interest] On trees and JavaBeans, part 2: tree creation

[Micheal J]

Scott,

> 4) You're thinking of a single-pass *program*, which seems to 
> be the same box Ter is thinking in. (This is for all of your 
> "the garbage collector is reasonably optimized" lines. I'm 
> talking about scenarios where the garbage collector will run 
> hundreds or more times while the program is running)

Regardless of how often the GC runs, Loring's statement regarding GC
performance (and the effect that having Carriers has on it) remains
relevant. 

The "overhead of carriers" as you put it is similar between the current
Carrier/Payload model and any other tree representation you propose that
also separates navigation and data. It's worth remembering that Carrier and
Payload are abstractions (i.e. interfaces).

> There's no way I'd propose making eclipse ASTs implement 
> ANTLR's AST interface. I'd be laughed out of the mailing 
> list, because everyone there knows adapters are the right 
> approach, and that this is only feasible if ANTLR trees work 
> the same way Swing trees do.

Adapters are NOT *always* the right approach as you seem to be suggesting
but, in the particular case of ANTLR trees, it can be argued that the use of
a TreeModel-like tree abstraction is a better option that 2.x's AST
interface (or 3.x's Carrier interface). This is because it allows ANTLR to
be used with [almost] any tree representation. And it supports ANTLR v3's
Carrier/Payload model very capably. And I've yet to see any performance
demons...

> Ter -- please look at the example I posted. I hope you "get 
> it" and implement this for 3.0. Otherwise I'll need to 
> maintain a mod to ANTLR that I'd really rather not.

As I mentioned in another message, this can probably be implemented as an
alternative codegen template in v3 but, ANTLR v3 would be much better if it
were a part of the standard package. We did something similar with a v2.x
fork and for our use cases there were no adverse performance issues.

> This is no extra cost to ANTLR or use of ANTLR ASTs, but it 
> opens up ANTLR a whole new realm of application.

Actually there is a cost as it involves at least an extra level of
indirection on each access. True, it's a minor cost in most cases but, it
exists nonetheless. I'd argue however that the benefits to ANTLR and it's
users of this flexibility outweigh the cost.

Cheers,

Micheal