[antlr-interest] Re: AST enhancements

[lgcraymer]

--- In antlr-interest at yahoogroups.com, "Eric Mahurin"
<eric_mahurin at y...> wrote:
> While I'm thinking about it, here is a list of things that would be
> nice to have regarding AST's:
> 
> 1. Allow for sub-rules to have there own root rather than always
> rooting the super-rule.  This is described in the documentation as
> labeled sub-rules, but apparently is not implemented.  Right now to
> get the right AST struture you have to partition the rules to get the
> right roots.
> 

Labeled subrules may or may not be supported in ANTLR 3.  I have
machinery that could support that (if our intellectual property office
ever gets around to giving me permission to release an ANTLR 2.8), but
my rewrite syntax provides an alternative which Ter thought he
preferred at the cabal.

> 2. Allow rule references in addtion to token references to be rooted.
>  This feature was described in my previous message.  Right now you may
> have to flatten the rules to get the right roots.
> 
> 3. Have a standard interface for separating/storing/retrieving
> children to the left vs. right of the root so that token order can be
> easily preserved.  Right now with the way ASTFactory does things, the
> current interface can be used to get the token order correct, but the
> "addChild" definition must be changed (insert child at beginning
> instead of end).  Instead, I think the interface and ASTFactory should
> assume that the AST's keep order, but the implementation wouldn't have
> to.  Maybe all that is needed is a redefinition of addChild (insert to
> the left of the left children), and a few methods which return
> separate left and right children lists (non-ordered ASTs would return
> the whole list or nothing for these).

That's a major interface change which ain't going to happen.  A better
alternative is provided by Ter's TokenStreamRewriteEngine

> 
> 4. Consider using a more generic "List" like interface storing sibling
> lists.  This way you can have implementations other than linked lists
> and you can get easy random access.
> 

Why would you need random access as a generic capability?  Besides,
this can be done on a custom basis already.  Consider having AST nodes
with List and index fields (getNextSibling and getFirstChild would set
the index values).

> 5. Add some symbol table stuff.  It would be nice to be able to easily

Under consideration, as is an attribute syntax.  I, personally, am not
in favor of direct symbol table support--it adds to the work of
supporting a new target language--but think that an attribute syntax
makes sense.

--Loring

> store symbol table data in the AST.  I haven't thought through the
> details yet, but I was thinking you'd have some suffix to say you
> wanted something to be a key in a symbol table and the "children" ASTs
> would be the value for this entry.  This could work similar to the "^"
>  AST operator, but instead of making a root with children, it would
> make a map entry.
> 
> Eric



 
Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/antlr-interest/

<*> To unsubscribe from this group, send an email to:
    antlr-interest-unsubscribe at yahoogroups.com

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