[antlr-interest] ANTLR 3.0 tree construction proposal

[Terence Parr]

On Jan 31, 2005, at 8:27 AM, Jim O'Connor wrote:
> 1. What is the learning cost to using Antlr?
>
> 	I use as example "How do I get line numbers from my AST?" In version
> 2.7.4 and earlier, the necessity of understanding the CommonAST, 
> BaseAST,
> Token structure is a barrier to an "educated" user.  Maybe this is a 
> good
> thing.

Hi Jim :)

Nah, getting line numbers should be easy.  In the new AST node 
structure, the payload will usually be the token (which is up to you 
and you can do it w/o ever seeing the AST class def) and you can say:

((Token)node.payload).getLine()

or whatever.

> 	What is my point?  Tree construction syntax is already a barrier to
> overcome to reading Antlr grammars.

Do you mean the ^ and ! operators or the #(a,b,c,d) syntax?

>  To what point is "new/better"
> functionality increasing the "learning barrier" for doing simple 
> things?

My goal is to make it easier to understand.

> Note 1: I haven't used String Template.  Will that be a necessity to
> understand Antlr 3.0?

Nope...it will not be included in the initial release most likely.  If 
you want to build a new target back end then you need ST. :)

> Note 2: I like the effect of ^^.

me too.  It fills lots of current deficiencies.

> 2. Predicates, Tree construction and actions.
> 	To use old/current terminology, guessing = 0 means execute an
> action.  Consider a rule
>
> Oldstylepredicate :
> 	a b c => a b c
> 	| blah blah ;

I'm wondering if I want to use '->' instead of '=>' as '=>' means 
syntactic predicate.

> Assume I have actions on "a", "b", and "c".  These must get executed in
> order.
>
> Newstyletree :
> 	a b c => c c a a b b
> 	| blah blah ;
>
> The actions on rules "a", "b", and "c" will get executed out of order 
> and
> multiple times.  This comment may reveal some strange kind of 
> ignorance.  I
> have to be intelligent enough to realize the effect, but stupid enough 
> to do
> it.

Yep, i've not made this clear.  It only calls a b c once.  The c c a a 
b b is the rewrite portion and is generated not matched.  The 
generation happens with the *result* of calling a b c on the left side.

> 3. Predicates, Tree construction and actions, again.
>
> 	Would it be useful to change the designator from "=>" to something
> else?

I'm thinking -> not => :)

> 4. Missing the whole point.
> 	The desired effect is to produce a tree that is in the "correct"
> order.  This leads to more efficient tree traversal and better ordered
> actions in the tree grammar.  The proposal addresses these issues.  
> Does it
> do away with the manual manipulation of the trees?

Hopefully in all but the weirdest cases.

>  The imaginary nodes
> appears to be a stumbling block.  Or can a 
> @attribute.Imaginary.THISTHING be
> created in a header section be used anywhere?

Actually imaginary nodes are handled particularly nicely.  Imagine 
adding a DECL imaginary node:

decl : "int" ID ';' => ^(DECL "int" ID) ;

or

decl : "int" ID ';' -> ^(DECL "int" ID) ;

using the -> instead.

With just my operators you cannot add the imaginary node.  Loring's 
stuff could easily add the imaginary node I believe.

> Jim
> P.S. Sorry, this is what you get when you're supposed to be doing 
> other work
> and "waste" the time considering theoretical Antlr issues.  Hope this 
> is
> useful.

It is very useful.  Thanks!

Ter
--
CS Professor & Grad Director, University of San Francisco
Creator, ANTLR Parser Generator, http://www.antlr.org
Cofounder, http://www.jguru.com
Cofounder, http://www.knowspam.net enjoy email again!