Hello Simon, You might want to check out the documentation on BufferedTreeNodeStream, you could use methods like seek(..), index() etc. A long time ago on the Java side there was a bug in it, I do not know what the current state is (let alone the C target).
Another way is to walk the AST yourself (visitor), then you can easily walk your expression and take action on the result of it (that is skipping or not skipping code). Regards, Martijn On Mon, Nov 22, 2010 at 3:00 AM, <[email protected]> wrote: > Hello, a friend and I have been working on implementing an > interpreter for a small DSL using the ANTLR C-target. He has > constructed an AST and is using a tree grammar to generate the code > for the walker. Our problem can best be explained by way of example. > Take the following snippet of code from our tree grammar: > : ^(IF iex=nexpr[defer] ^(THEN {iStart=INDEX()+1;} > blockstar[true] > { > if ( !defer ) > { > if ( $iex.value.toBool() ) > { > foundPath = true; > Memory::getI()->enterScope(false); > ANTLR3_MARKER next = INDEX(); > SEEK(iStart); > ctx->blockstar(ctx,false); > SEEK(next); > Memory::getI()->exitScope(); > } > } > blockstar is a statement block that should only be executed if the > nexpr condition evaluates to true. To avoid the walker performing > all of the code in blockstar regardless of whether or not the > condition evaluated to true or false we've added a defer parameter to > the blockstar rule, and when the walker is initially parsing blockstar > we pass defer==true. This causes the walker to do a 'dummy' recursion > down through blockstar where no actions are actually executed because > all actions are inside an if (!defer) { ... } statement. Having > recorded the start of blockstar in the token stream in the iStart > variable we then check if the condition has evaluated to true, and if > it has we position the walker at the start of blockstar and walk it > but this time with defer==false. > I presume we could prevent the 'dummy' walk of the AST by inserting > action code immediately after the nexpr condition along the lines of > {executeBody==true;} and then put an if (executeBody) statement in > blockstar? > We have used a similar pattern in our WHILE statement and even in > our FOR loop since the counting expression shouldn't be executed when > it's initially parsed. > I'm sure we must have missed something and there must be a simpler > way to implement such common functionality. I'd be most appreciative > if someone could suggest an alternative solution. > Simon > > List: http://www.antlr.org/mailman/listinfo/antlr-interest > Unsubscribe: > http://www.antlr.org/mailman/options/antlr-interest/your-email-address > List: http://www.antlr.org/mailman/listinfo/antlr-interest Unsubscribe: http://www.antlr.org/mailman/options/antlr-interest/your-email-address -- You received this message because you are subscribed to the Google Groups "il-antlr-interest" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/il-antlr-interest?hl=en.
