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

[Junkman]

Gerald Rosenberg wrote:
>  As best I understand your questions, the answers are no, no, and no . . .
> 
> Given an input "PAB", your given parser will construct an AST  ^( ^(
> PARENT A ) B ) and your given tree grammar will likewise match that.
> 

I think you have that wrong.

When fed the input "PAB", the parser/rewrite rule:

parent: P A? B? -> ^( ^( PARENT A? ) B? )

generates ^(PARENT A B), a PARENT node with two children, A and B, and
produces the following sequence when flattened:

PARENT DOWN A B UP

This is as documented in TDAR.  You can try it yourself with the demo
codes (attached again).

> If you somehow feed the tree grammar an AST ^( PARENT A B) or ^( PARENT
> B ), the rule will fail - both structure and content of the AST must
> match for the tree rule to match.
> 

That seems to be the case in tree parser.  It's this discrepancy between
tree generation and tree parsing I've tripped over.

I am wondering if the discrepancy is intentional and consistent through
all tree parser rules, or only the rules that match a node with optional
children.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: TreeParserDemo.zip
Type: application/x-zip-compressed
Size: 4789 bytes
Desc: not available
Url : http://www.antlr.org/pipermail/antlr-interest/attachments/20100804/da085296/attachment.bin