[antlr-interest] ANTLR 3.0 tree construction proposal
parrt at cs.usfca.edu
Mon Jan 31 13:52:07 PST 2005
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,
> Token structure is a barrier to an "educated" user. Maybe this is a
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:
> 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
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
> Assume I have actions on "a", "b", and "c". These must get executed in
> 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
> 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
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
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) ;
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.
> 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
It is very useful. Thanks!
CS Professor & Grad Director, University of San Francisco
Creator, ANTLR Parser Generator, http://www.antlr.org
Cofounder, http://www.knowspam.net enjoy email again!
More information about the antlr-interest