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

[Jim Idle]

Your grammar is doing what you are telling it to do. If the node PARENT can
have zero children, an A node, or an A node with a B node, then you need to
specify that:

n: PARENT  // No children at all
  | ^(PARENT
             A 
             B?
     )
  ;

Jim
                 

> -----Original Message-----
> From: antlr-interest-bounces at antlr.org [mailto:antlr-interest-
> bounces at antlr.org] On Behalf Of Junkman
> Sent: Tuesday, August 03, 2010 7:48 PM
> To: antlr-interest at antlr.org
> Subject: [antlr-interest] Tree parser eats up DOWN node when navigating
> optional child node
> 
> Greetings,
> 
> I am seeing an interesting behavior in generated tree parsers.
> 
> This is an example grammar fragment:
> 
> --------------------------------------------
> tree grammar TTreeParser;
> 
> ...
> 
> parent: ^(parent_a B?) ;
> parent_a: ^(PARENT A?) ;
> --------------------------------------------
> 
> The intent is for parent_a to match a PARENT node optionally with the
child
> node A, while parent is to match a PARENT node that can also have child
> node B as well as child node A.
> 
> But parent rule throws up recognition exception when fed this tree:
> 
> ^(PARENT B)
> 
> The problem is parent_a consumes the DOWN node before B instead of
> skipping it.
> 
> The following tree also causes the exception for parent:
> 
> ^(PARENT A B)
> 
> In this case, parent_a, after consuming A, expects <UP> when there is
still
> another sibling node - B.
> 
> It looks like a discrepancy in the rewrite rule interpretation - when used
to
> produce tree, the rules work as expected/intended.
> 
> I am looking for insight/suggestion to get the tree parser work as
intended.
> Attached are example grammars and generated code plus test driver to
> demonstrate the issue I'm having.
> 
> Thanks for any help,
> 
> Jay
>