[antlr-interest] executing actions during backtrack

[Oliver Zeigermann]

I guess you need something like an inverse action that applies when
backtracking fails. So you might need a pair of actions. This way all
actions executed inside backtracking are undone when backtracking is
done. Maybe it is enough to add an inverse action to indicate it
should be executed inside backtracking?

OIiver

2006/5/9, Terence Parr <parrt at cs.usfca.edu>:
> Howdy,
>
> We need to discuss v3's behavior for executing actions during
> backtracking (guessing).  ANTLR must parse ahead to see if something
> matches.  If it fails, then ANTLR tries the next viable alt.  Upon
> failure, it's pretty hard to undo actions in general so ANTLR gates
> actions out with something like this:
>
> if ( backtracking==0 ) {
>       SymbolTable.getPredefinedType("void"), symtab.getDefaultPkg());
> }
>
> Labels are still defined, because semantic preds might need them:
>
>                              packageDefinition1=packageDefinition();
>
> AST actions are off during backtracking:
>
>                              if ( backtracking==0 )
> list_packageDefinition.add(packageDefinition1.tree);
>
> Upon success, antlr still rewinds the input and then does the same
> parse again "with feeling". ;)
>
> Clearly you don't want actions executed when that alt ultimately
> doesn't succeed.  Similarly, when the alt does succeed, you do not
> want actions executed twice.  This all makes sense.
>
> The problem arises when you want actions to execute *during*
> backtracking so that semantic predicates make sense during
> backtracking.  If you are combining backtracking (syntactic
> predicates) and semantic predicates for tough languages like C++ then
> you must execute actions during the backtrack but then avoid them
> during the parse.
>
> In v2, a quirk of implementation became a feature: init actions for
> rules, subrules were not gated out:
>
> ( {always do this} foo | bar )
>
> This was "wrong" in the sense that it executed the action twice.
>
> Anybody have a suggestion?  We have named actions now, perhaps
> instead of @init{...} or plain {...} we do @guessing{...} or something?
>
> Ter
>