[antlr-interest] Re: #( root children ) syntax change proposal?

[lgcraymer]

--- In antlr-interest at yahoogroups.com, Terence Parr <parrt at c...> wrote:
> 
> On Tuesday, November 18, 2003, at 01:40 PM, lgcraymer wrote:
> 
> > Ter--
> >
> > There would not be any ambiguity between ^ as a suffix and ^( as a 
> > tree notation--"^(" can be interpreted as a token by the lexer.
> > However, the current semantics of ^ is "root", not tree or AST 
> > node--that's #.  I can see the ^( as a construction syntax, but would
> > prefer to keep # as a tree matching prefix.  In fact, I'd be willing 
> > to change my tree construction syntax from "#{" to "^{" and "#(" to 
> > "^("
> > to emphasize the construct versus match differential.
> 
> Interesting.  Verrrrry interesting.  So to add an imaginary node you'd 
> say:
> 
> a : A^ ^{IMAG} B ;

Not quite--you'd do an ^[ IMAG, ... ] to add an imaginary node.  A more complete example would be

a :  A^ b:B!  ^[ IMAG, "imag" ] C ^{ b } ;

to be matched by

a : #( A IMAG C B )

in a tree walker.

> To make a tree like this
> 
>    A
>    |
> IMAG -- B
> 
> ??  Looks a bit weird, the ^{...} constructor.  Is this what you were 
> thinking?

That may just be unfamiliarity.  Think of ^[ or ^{ as "insert a tree element here"--with the left binding suggesting construct downward 
("root here") and the terminating ] or } as "return to the original construction depth".  Right now, I use #[ .. ] within tree actions #{ ... }, 
but there is an advantage to promoting ^[ ... ].  Also consider ^[ IMAG, "imag"]^ as "insert an IMAG node here and make it the root of 
the current tree".  It does look a little weird, but would be a useful shorthand.

> I do like this for the matching:
> 
> expr : ^(PLUS expr expr) | INT ;
> 
> rather than
> 
> expr : #(PLUS expr expr) | INT ;

I don't, but that's because I tend to view construction and matching as distinct "phases".  Matching is passive (follow the tree), while 
construction is active.  With my tree grammar generation to automatically generate the #( .. )'s, I think that it makes even more sense 
to differentiate the machine generated matching structure from the construction syntax since the construction annotation will be edited 
in by the developer.

> Ter
> --
> Professor Comp. Sci., University of San Francisco
> Creator, ANTLR Parser Generator, http://www.antlr.org
> Co-founder, http://www.jguru.com
> Co-founder, http://www.knowspam.net enjoy email again!
> Co-founder, http://www.peerscope.com pure link sharing


 

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/