[antlr-interest] What's coming for 2.8 (was Re: Build Questio n)
lgcraymer
lgc at mail1.jpl.nasa.gov
Wed Mar 13 11:29:50 PST 2002
--- 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/
More information about the antlr-interest
mailing list