[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"?
Ter
--
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