[antlr-interest] What's coming for 2.8 (was Re: Build Questio n)

[lgcraymer]

--- In antlr-interest at y..., mzukowski at b... wrote:
> > Additionally, "COPY" (duplicate 
> > and insert duplicate into tree and "REUSE" (insert "as 
is"--usually 
> > used as an optimization to avoid the overhead of AST node 
allocation) 
> > are keywords which precede AST node descriptors.  
> 
> Wow, this means we won't always rebuild the entire tree when 
buildAST=true
> is on?  Very nice for multi-pass translators.

Yes, and you can recognize it with a wildcard (.) to shortcut the 
parsing.  This is a first cut at optimizing AST generation.  The next 
is to disallow tree construction in actions (construct trees "only" at 
the grammar level) so that a list of AST nodes to be allocated and 
tree structuring ops so that only nodes used in the constructed tree 
are allocated--that will have to wait for 3.0.

> Have you given any thought to emitting a tree back to source code?  
Most of
> the ignored elements of the parser grammar are things like ";".  
Seems like
> there might be a way to specialize your tree grammar generator into 
a tree
> grammar emitter generator which would insert actions to output the 
ignored
> tokens as the tree is walked.  Warnings if you are ignoring 
something like
> ID which can't be reconstructed.  Between that and keeping a stack 
of output
> tokens to push and pop inversely to the ^ operator in the parser 
would be
> most of what you need.  The final thing would be an annotation for 
indenting
> or dedenting (in the parser) which would be propagated to the tree 
emitter.

Yes, but only in passing.  Ter has some ideas (some incomplete, and 
some implemented in the jGuru site) on code generation, and I think 
that they need to be implemented before we (the community) tackle 3.0 
just to make it easy.  Bug him for the details.

> 
> > #( ROOT! A B )
> > led to the output tree
> >	#( A B )
> > rather than the A B list that might have been expected.
> 
> Hmmm, I'm not sure I would expect the list.  But I guess if I wanted 
the
> tree I would do #( ROOT! A^ B), right?  I can see that the inverse 
(assuming
> a tree) could be problematic.

Right--you need some way to flatten the tree.  In fact,
     #( r:ROOT! #{ r } A B )
does a conversion of tree to list.

> Monty

--Loring


 

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