Hi Thomas, I suspected that might be the explanation. If it's intended for use in declaring local variables, putting it inside an if would break it, at least in Java.
I do need a local variable declaration (I record the stack depth at the start to ensure the stack pop at the end is to the right level) so I can't just move it into an action at the start of each rule. I know I could leave the variable declaration in the @init, and do the push in an action. But the solution I have now of checking for backtracking within the method that does the push works well, and keeps the grammar simpler. Thanks, Ron [email protected] wrote: > Hi Ron, > > I think this behavior is as intended. The @init block is intended to declare > local variables. Therefore, it will always be executed. > You could move the action, manipulating your stack, out of the @init block > into an action inside the rule. Then, it would not get executed during > lookahead. > I don't know if it is favorable, but if this manipulation of the stack is > required in the subrules to correctly decide on alternatives, you could leave > the action in @init and put the cleanup action (form @after) to the "finally" > block, which will always get executed, regardless of the backtracking state. > > I hope this helps. > Thomas > > > ________________________________________ > Von: [email protected] [[email protected]] im > Auftrag von Ron Hunter-Duvar [[email protected]] > Gesendet: Samstag, 17. April 2010 00:59 > An: [email protected] > Betreff: [antlr-interest] @init actions executed during lookahead, > @after actions not > > Hi, > > I just ran into something a little odd. I'm using @init actions in some > parser rules to stack some information and @after to pop it again. In > the generated Java code, the @after action gets wrapped in an "if ( > state.backtracking==0 ) {...}", so that it only gets executed when other > actions are being executed, not during lookahead. This is what I > expected. But I noticed that the @init actions are executed > unconditionally, including during lookahead. I didn't expect this. The > result was a lot of junk on the stack when it went into a dfa. The fix > was easy enough, just checking state.backtracking myself. But I was > wondering if this is an Antlr bug or if it's supposed to work this way. > > Ron > > -- > Ron Hunter-Duvar | Software Developer V | 403-272-6580 > Oracle Service Engineering > Gulf Canada Square 401 - 9th Avenue S.W., Calgary, AB, Canada T2P 3C5 > > All opinions expressed here are mine, and do not necessarily represent > those of my employer. > > > 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 > > -- Ron Hunter-Duvar | Software Developer V | 403-272-6580 Oracle Service Engineering Gulf Canada Square 401 - 9th Avenue S.W., Calgary, AB, Canada T2P 3C5 All opinions expressed here are mine, and do not necessarily represent those of my employer. 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.
