[antlr-interest] Minor suggestion re. Java output

Jim Idle jimi at temporal-wave.com
Tue Feb 5 08:09:49 PST 2008


As I was intimating in my last over-reaction ;-), I think that if the 
target was changed to 1.5+, then it may not be unreasonable to expect a 
certain level of interface compatibility and so perhaps some of this 
could be changed. However CommonTree, while by its name intimating that 
it is expected to be what people will generally use, might be too high 
up. The C target expects that you have implemented the calls to base 
tree and therefore the internal pointers are all to that type. That type 
contains a pointer to the next higher type, which can be CommonTree or 
anything you like really. So, you never cast anything in C.

In generated code, smaller is still good of course but the generating of 
the casts and so on isn't a big deal. In your own custom code you can 
derive from the existing classes and create the method signatures you 
need. The cast involves a runtime check to be sure, but I think it 
unlikely that you could measure its effects on the average tree parser.

I also believe that Ter has been contemplating targeting 1.5 for a while 
because of the use of generics and I think that 3.1 may in fact be 1.5 
dependant. At some point, another look at the situation is warranted. 
There are also plenty of other elements that can be improved for code 
generation and will be addressed over time I am sure. For now, it is 
faster than the v2 system and so is heading in the right direction.

Jim

> -----Original Message-----
> From: Guntis Ozols [mailto:guntiso at latnet.lv]
> Sent: Tuesday, February 05, 2008 6:36 AM
> To: Jim Idle
> Cc: antlr-interest at antlr.org
> Subject: Re: [antlr-interest] Minor suggestion re. Java output
> 
> >  - Remember that the Java code target is 1.4;
> >  - The code is put together by the string template hence it is a 
view
> > and cannot know anything about the model;
> >  - All the elements of the output can be derived from, hence these
> > questions are about being lazy. I am all for development tools
> allowing
> > one to be lazy, but only as lazy as possible. There is a bigger view
> to
> > consider here;
> >
> > Jim
> 
> It is also about less memory/cycles for each node and smaller/simpler
> code.
> 
> The question that is puzzling me is:
>   if java code target was 1.5 or later
>   would then it be possible for CommonTree to return CommonTree
> children?
> 
> I think the typical use cases are (no casting necessary, covariance
> ok):
>   - use default ast
>   - extend TreeAdaptor and extend Tree/BaseTree/CommonTree
> 
> How typical do you think is to create a tree with nodes that are
> instances of CommonTree having children that are not? (btw,
> BaseTree.children
> is protected, can be accessed anyway)
> 
> Guntis
> 




More information about the antlr-interest mailing list