[antlr-interest] Re: tree parser rule referencing other parts of the tree

[excel_robot]

Thanks for your comments Guys,
I'm definitely warming up to the scoped namespace idea.
I could have a scope for each statement.
I would use the first AST pass to build a scope tree. In each scope I
hold references to parts of the tree I really need for that scope. 
Like the INTO node. 

If the following imaginary input was allow
SELECT @var1 = (SELECT @var2=col2 FROM TABLE2)
FROM TABLE1

My first AST pass would build the following scope tree
<SELECT>
|-<SELECT>

Each <SELECT> scope would hold a reference to the new INTO node.
Then while recognizing the SELECT_LIST again in a second pass I would
reference my scope tree which contains a reference to the INTO node or
other important parts of the entire SELECT tree.

In this way I don't have to worry about writing my own tree
walkers(getChild, getAncestor(withThisType),...). I utilise the power
of Antlr in the first pass to save references to important pieces of
the tree for future use. And the handy way to save these references is
 to use a scope tree. 

Each scope in the scope tree should be able to access its parent or
children. Therefore allowing me to access all the important parts of
the tree and not just the important parts of the current scope.

This stuff gets really handy when you tackle a procedural language as
you would create a scope for at the block level as well. Handy for
variable declarations at the block level and being able to decipher
control flow.

I think this is the right idea anyway ;)
Thanks again,
Dermot.




--- In antlr-interest at yahoogroups.com, Monty Zukowski <monty at c...> wrote:
> 
> On May 19, 2004, at 1:49 AM, Adrian Tineo wrote:
> 
> > Hi everyone
> >
> >> Hi Guys,
> >> I finished a small example of writing a source to source translator.
> >> You can find it at
> >> http://www.wumpa.com/antlr/antlr_example.html
> >> I still have more questions than answers but the 1 big question is.
> >> How do you reference other parts of the tree while in a certain rule.
> >
> > I had that same question not long ago. In short, I would say that you 
> > really
> > can't move freely in the tree with grammar based tree-parsers.
> >
> > As far as I know (and I don't know that much so please correct if
this 
> > is
> > wrong) you can only reference parts of the subtree that results from 
> > the
> > subrule you are in. If you want to work on a fairly big subtree with 
> > quite
> > some nodes to operate with, you need to go up in the rules. This
can be
> > inconvenient, and besides it doesn't solve all your problems. 
> > Sometimes you
> > need to touch the tree in another place outside of the subrule.
> >
> > In my case, I am working with Mr Zukowski's C grammar to 
> > source-to-source
> > translate some input C code. One of the things I have to do is expand 
> > some
> > pointer expresssions like
> >
> > struct t1 {
> > 	int data;
> > 	struct t1 *nxt;
> > }*ptr;
> > [...]
> > ptr=ptr->nxt;
> >
> > in
> >
> > struct t1{
> > 	int data;
> > 	struct t1 *nxt;
> > }*ptr, *tmp;	
> > [...]
> > tmp=ptr->nxt;
> > ptr=tmp;
> >
> > where not only I have to act on the assign expression subrule but I 
> > need to go
> > up the tree and declare the new tmp variable in order to have a valid
> > output . This can't be easily done with antlr-built treeparser
because 
> > it
> > can't be easily described with actions within the grammar.
> >
> > Of course we could have a symbol table defined and work with it in the
> > subrule, but overall as I realized the changes that needed to be
made, 
> > I
> > opted for a hand-built treeparser where I take an input tree and 
> > modify it as
> > I need with total freedom to move between the nodes. For that I 
> > extended the
> > nodes provided by Mr. Zukowsky to add some useful operations for
moving
> > around in the tree.
> 
> This was a big topic of discussion at the latest cabal -- how to manage 
> those out of rule references.  Basically we decided to create our own 
> scoped namespace and shove special labels in there pointing to the tree 
> node.  Easy enough to do manually, in fact Ter did that in half an hour 
> or so while we sat there.
> 
> ANTLR 3 will incorporate that with more sophistication as it forms the 
> basis of some really cool tree building stuff that Loring came up with.
> 
> Monty Zukowski
> 
> ANTLR & Java Consultant -- http://www.codetransform.com
> ANSI C/GCC transformation toolkit -- 
> http://www.codetransform.com/gcc.html
> Embrace the Decay -- http://www.codetransform.com/EmbraceDecay.html



 
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/