[antlr-interest] Deciphering the TreeWalker error message ...

[srinivasan karthikeyan pitchai]

Hi Folks,
I take on board the unanimous input that the tree grammar rule should 
start with TOKEN.

However what keeps me puzzled is that, inspite of having all my rules 
intact and just slightly rejigging my alternatives make the tree grammar 
parse the input tree perfectly fine.  I am able to parse huge SQL of 
about 160 lines with many many expressions fine!

Also  wouldn't the following expression

^(^(SUB_EXPR A) B)

simply mean that we have a simple list of subtree followed by a node B 
that is rooted at a nil node?

I was under the impression that the above syntax is valid as

1.  There is a mention of tree simulation  like
^( nil ^(VARDEF int i) ^(VARDEF int j) )

in page 167/372  in the chapter "Proper AST Structure" in Definitive 
ANTLR Reference.

2. ANTLR doesn't report any error while compiling.

3. The grammar works for most test cases involving expression.

Thanks,
Vasan



On 7/21/2011 10:06 PM, Kevin J. Cummings wrote:
> On 07/21/2011 02:48 AM, Gary Miller wrote:
>> 3.
>> rule :
>>    ^(subrule otherrule)
>> ;
>> Just looks wrong.
> I am under the impression that a treewalker rule should be rooted in a
> TOKEN, not a subtree.  The few treewalker grammars I have written always
> have rules that look like ^(TOKEN some other rules or TOKENS)
> If a subrule reference is not allowed to be the root of the tree being
> parsed, I would have thought that ANTLR would have issued an error when
> the tree grammar was run through ANTLR....
>
> I could be wrong with my assumption here, but I have never gotten into
> trouble by assuming it (so far).
>
> Often this involves me collapsing my treewalker rules together.  For
> example, if I have 12 parse rules to accurately describe precidence in
> an expression, my treegrammar might have 12 alternations, one for each
> possibly different rooted TOKEN when walking them.  This makes my
> treegrammars (much) smaller than my parser grammars.
>
>> If you inline (expand) out what you have written you would get
>> compoundExpression
>> : ^((SUB_EXPR ^(PAREN_SCLAR_EXPRESSION sclarExpression+) conversion_clause )
>> ;
>> The ^(( is impossible
>> Make all you start tree look like ^(TOKEN ...)
>> ^(sign sse=sclarSubExpression) therefore also look wrong.
> Yes, treegrammar rules can refer to other rules, but the rooted
> expressions: ^() should be rooted with TOKENs.
>