[antlr-interest] ANTLR3 AST construction withoptionsandalternatives

[Foolish Ewe]

Thanks Dave:

That does help.  I didn't undersand the examples so well and I did not
interpret the examples the way you did (I got a bit confused since I
thought it was mandatory to create attributes separate from
the tokens, i.e. a: b=B->(A $b); was required, not a: B->(A B); ).
I managed to get one part of the grammar working, I'll need to revisit
the remaining parts of the grammar, where I will try the approach you 
recomend.

I'm on to walking the tree next, but that might wait till I get a nights 
sleep.

Thanks Again, I'll give it a try.

Bill M.


>From: David Holroyd <dave at badgers-in-foil.co.uk>
>To: antlr-interest at antlr.org
>Subject: Re: [antlr-interest] ANTLR3 AST construction 
>withoptionsandalternatives
>Date: Mon, 13 Nov 2006 20:24:52 +0000
>
>On Mon, Nov 13, 2006 at 06:40:05PM +0000, Foolish Ewe wrote:
> > I'm not sure about what the ANTLR folks call these things so just
> > to be clear, if we have a rule like the one I originally suggested,
> > b and c+ are what I'll call atributes.  I'm guessing that Dave
> > refers to the + suffix as the cardinality of the attribute.
>
>Yes.  (I hope it's the right term.)
>
> > I wasn't sure, it isn't clear to me what the + suffix implies for
> > attributes, my gut reaction was that it was intended for attributes
> > that occur a variable number of times.  If + means one or more 
>repetitions,
> > like it does for parsing and lexing, and if (from your the remainder of
> > your reply)
> > we can use '?' for zero or one times, does that mean we can use other
> > cardinalities,
> > i.e.  '*' for zero or more times as well?   Are empty/uninitialized
> > attributes (assuming * or ?
> > cardinality) omitted from the tree if they are listed in the right hand
> > side of the ->
> > operator in an AST rule?
>
>I took my cues from this page,
>
>   http://www.antlr.org/wiki/display/ANTLR3/Tree+construction
>
>
>Where I saw stuff like,
>
>   compilationUnit
>     :   packageDefinition? importDefinition* typeDefinition+
>         -> ^(UNIT packageDefinition? importDefinition* typeDefinition*)
>     ;
>
>   ['packageDefinition' has a '?' on the left and on the right;
>   'typeDefinition' doesn't match - maybe a typo, or doesn't matter?]
>
>and
>
>   compoundStatement
>       :   lc='{' statement* '}' -> ^(SLIST[$lc] statement*)
>       ;
>
>   ['statement' has a '*' on the left and the right]
>
>Now, to be honest, I don't know *why* I'm doing this, but following the
>established pattern seems to work :)
>
>It is the case that in the above compoundStatement example, if there are
>zero 'statement' matches, then the result tree will just be an SLIST
>node with no children (i.e. the appearence of 'statement*' on the r.h.s.
>doesn't add anything to the result tree if there's nothing to add).
>
>
>does that help?
>dave

_________________________________________________________________
Try the next generation of search with Windows Live Search today!  
http://imagine-windowslive.com/minisites/searchlaunch/?locale=en-us&source=hmtagline