[antlr-interest] Tree parser eats up DOWN node when navigating optional child node

[Gerald Rosenberg]

------ Original Message (Thursday, August 05, 2010 11:50:07 
AM) From: Junkman ------
Subject: Re: [antlr-interest] Tree parser eats up DOWN node when navigating
optional child node
> Gerald Rosenberg wrote:
>>   ------ Original Message (Wednesday, August 04, 2010 5:21:33 PM) From:
>> Junkman ------
>> Subject: Re: [antlr-interest] Tree parser eats up DOWN node when navigating
>> optional child node
>>> You wrote "AST ^( ^( PARENT A ) B )".  Can you describe the tree this
>>> notates?  I can see it as a node sequence, but I don't know what tree
>>> structure it is describing.
>>>
>>> Thanks for the reply.
>>>
>>> Jay
>>>
>> The AST
>>
>> ^( ^( PARENT A? ) B? )
>>
>> should implement as
>>
>> ( ( PARENT Token.DOWN A? Token.UP ) Token.DOWN B? Token.UP )
>>
>> but is actually
>>
>> ( PARENT Token.DOWN A? B? Token.UP )
>>
>> Because parent_a is the root of parent, the parser is (for some reason)
>> not actually generating the middle Token.UP Token.DOWN sequence.
> It's because the parser generates trees, not node streams.
>
> UP and DOWN nodes are marker nodes injected while flattening a tree, and
> the resulting node stream naturally will contain neither empty DOWN-UP
> sequence (edges to non-existing node) nor empty UP-DOWN sequence between
> sibling nodes (duplicate edges).
Yet it does validly produce

( ( M Token.DOWN PARENT A? Token.UP ) Token.DOWN B? Token.UP )

As pointed out by Jim, the "sub-rule as root" is the source of the problem you are encountering.