[antlr-interest] ANTLR 3.0 tree construction proposal

Terence Parr parrt at cs.usfca.edu
Mon Jan 31 14:57:08 PST 2005

On Jan 31, 2005, at 2:34 PM, Martin Probst wrote:

> Hi,
> I didn't have the time to really dig into that. Getting rid of #() and
> #[] sounds good to me. Also removing {} actions for tree construction
> etc. seems to be a good idea. ^^ on subrules is a thing I've been
> looking for several times too.
> I've never used tree rewriting though so I cannot be any help regarding
> that. I'm just feeling uneasy with my ANTLR code because every time I
> read it it takes me quite some time to figure out what the heck I'm
> doing in there ;-)

Agreed.  I'm trying hard to improve with a simpler approach :)

>> Do you think the new rewrite stuff would be easy to understand? Some 
>> of
>> surely would.  For example, build a flat tree with elements reordered:
>> r : A B => B A ;
> You really should use a different operator in this case. Parsers and
> Lexers share the same operators (as they are basically the same as far
> as I understand) so the user assumes this for tree parsers too.
> And this just looks like a wrong syntactic predicate.

I agree.  Ok, let's use -> instead.

> Loring's stuff looks a little bit more consistent - ^{ } for actions,
> ^() for trees, ^[] for nodes. I'm not enough into it to decide what's
> better.

First note that ^(..) and ^[...] are the things you say you didn't like 
(except with # instead of ^) ;)

Anyway, I use ^(...) for tree:

r : A B -> ^(A B) ;

is the same as:

r : A^ B ;

^[] for a node is useful when it's an operator; since I wouldn't allow 
that, i was thinking of using something similar in the tree rewrite:

r : A B -> ^(DECL[args] A B) ;

where DECL[args] is like a constructor call to a node with imaginary 
DECL as the type and args as the other args.

With luck you won't need ^{actions} as operators, though in the rewrite 
section I'm thinking they may prove useful as in:

r : A B -> ^(A B {an-expr-for-2nd-child} ) ;

> BTW is there currently a way of specifying that a (sub-)rule should 
> stop
> matching and exit? I've found myself trying to specify:
> ( A B => subruleB
> | A C => subruleC
> | else => return
> )

That should happen automatically right?  If it doesn't match the first 
two and you have a blank third, it should continue:

( A B =>
| A C =>

Stop matching? Or, do you mean "match a production only if not followed 
by blort"?

CS Professor & Grad Director, University of San Francisco
Creator, ANTLR Parser Generator, http://www.antlr.org
Cofounder, http://www.jguru.com

More information about the antlr-interest mailing list