[antlr-interest] [v3] TreeParser capabilities

[Emond Papegaaij]

On Monday 20 November 2006 12:07, you wrote:
> On 20. Nov 2006, at 11:57 , Emond Papegaaij wrote:
> > I'm using a heterogeneous AST, which is generated by an external
> > tool. This
> > tree is strictly typed, with fields containing the various
> > subtrees. This
> > makes the Tree interface difficult to implement. All functionality
> > required
> > for the Tree interface is already part of the custom TreeAdaptor
> > (such as
> > getChildCount() and getChild(int)). Therefore, I'm wondering why the
> > CommonTreeNodeStream is based on the Tree interface, and not on a
> > TreeAdaptor. Especially because CommonTreeNodeStream can take a
> > TreeAdaptor
> > in its constructor, but it's not used.
>
> Ah, I see. I think the reason was to not place any burden on the tree
> nodes, i.e.
> you should be able to pass in everything, as long as it implements
> the basic Tree
> interface. At some point Terence has said that he wants to support
> heterogeneous
> trees again. It's just not done yet :(
> You can probably hack around for the time being, it all depends on
> how much custom
> code you are willing to invest at this point.

It seems, it should be fairly easy to convert CommonTreeNodeStream to use 
TreeAdaptor. I just tried a naive attempt to convert the class. It commes 
down to converting 'node.getChild(n)' to 'adaptor.getChild(node, n)'. There 
are however 2 problems: TreeAdaptor is missing a isNil method and the EOF, 
DOWN and UP nodes cannot be made static final. Another minor issue is that 
some methods are not implemented in CommonTreeAdaptor, such as getChild and 
getChildCount. But these methods are trivial to implement.

With these changes, the tree node stream can be implemented without any 
reliance on the Tree interface, just as the parser.

Best regards,
Emond