[antlr-interest] [C Target] How to skip a whole sub-tree (not just a token)

[Jim Idle]

Firstly, try to use the macros like LT() rather than following the pointers directly.

Secondly, have you tried the MARK, SEEK and REWIND macros - this kind of thing is what they are designed for.

If your imaginary tokens do not have the start and stop token indexes set, then you are probably rewriting them like this:

 

è ^(GOOONEWITHINDICES X Y ^(THISWONTGETINDICES A B))

 

Move the inner rewrite into a sub rule and it will get indices.

 

Jim

 

 

From: antlr-interest-bounces at antlr.org [mailto:antlr-interest-bounces at antlr.org] On Behalf Of Mohamed Yousef
Sent: Saturday, November 14, 2009 9:36 AM
To: antlr-interest at antlr.org
Subject: Re: [antlr-interest] [C Target] How to skip a whole sub-tree (not just a token)

 

i found a solution - more of a hack - to enable/make it easier to do control flow avoiding obscure act about token positions
before the real walk we make a small walk (not very expensive) to store those data

nodes    = antlr3CommonTreeNodeStreamNewTree(yatgAST.tree, ANTLR3_SIZE_HINT); 
pANTLR3_BASE_TREE p;
while(true)
{
            // this should/can be further optimized by adding data to certain nodes only
            p=nodes->tnstream->_LT(nodes->tnstream,1);
            p->savedIndex=nodes->tnstream->istream->index(nodes->tnstream->istream);
            if(p->getType(p)==nodes->EOF_NODE.token->getType(nodes->EOF_NODE.token))break;
            nodes->tnstream->istream->consume(nodes->tnstream->istream);
}

it enabled me to implement my IF statement in way i wanted

this is sure not the best way to do it , any ideas ?

Regards,
Mohammed Yousef

2009/11/13 Mohamed Yousef <harrrrpo at gmail.com>

Sorry , it seems i jumped to a wrong result
indices are calculated correctly and UP&Down are taken into consideration
the real problem that i discovered now 
is that during tree parsing nodes have no info about the real start and end positions till respective childs are parsed , so here :



if_expr
    :
      ^(EIF ^(EIF_COND c =expr_g)  { // examine c and selectively jump to e }  )

EIF would think and respond as c is the end of the world , it has no knowledge of EIF_THEN

so we have either two solutions :
1) go parse it by hand : tedious , inefficient , probably won't be generic
2) another idea i have now is to store node indices (e.g. for COND , THEN, ELSE in EIF ) either during parsing or in a separate walk to "flow control" nodes

i will try both and see
any better ideas ?

2009/11/13 Mohamed Yousef <harrrrpo at gmail.com>

 

Hello all,
i sent before regarding a bug in Control flow  in which a e=. won't define e , i was suggested by jim to walk tree my self using LT

now i have a problem , consider following 

if_expr
    :
      ^(EIF ^(EIF_COND c =expr_g) ^(EIF_THEN e=expr_g)  ) { // examine c and selectively jump to e }

must be changed to something like

if_expr
    :
      ^(EIF ^(EIF_COND c =expr_g)  { // examine c and selectively jump to e }  )

and we have a problem
how can we skip the whole EIF_THEN tree (when c is false ) ? , if we try to use the stopIndex of EIF to jump to it's end
we have the problem that all returned indices ,by all means , don't take UP & DOWN nodes into accout , where the SEEK macro
takes them into accout
any ideas ?

 

 



-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.antlr.org/pipermail/antlr-interest/attachments/20091114/935389ad/attachment.html