[antlr-interest] executing actions during backtrack

[Jeff Barnes]

To the list this time...


> What if we could auto unroll any
> object/data-structured you  
> identified somehow as transactional?  

Like perhaps with a checkpoint.

> You would give
> me an undo()  
> method for each object, like a hashtable. 

Or just a way to serialize it. Make a copy of the
model (or portion of the model) for each Command so
ConcreteCommand could undo itself. And if you want to
get fancy have an accessor for a ConstraintSolver that
encapsulates the sem pred (would it work for a syn
pred?) that prompted the decision. 

>  How can I know what to track? 
> Impossible.  Users will  
> have to provide a specific undo action that I can
> execute:

Not sure why... a checkpoint would manage that for
you. A redo "log" would provide snapshots of the state
along with the Command object that caused that change
of state. Command would by its nature change the state
of the model. Nothing else matters.

> 
> Where would the undo action get executed though? 

Not an action. Just restore the model to its
serialized state at the decision point.

> 
> Ok, taking the cue from Jeff Barnes, perhaps the
> undo action actually  
> creates an object that parameterizes the action and
> executes it  
> during rollback in reverse order:
> 
> @undo(Scope s=scope, String id=$ID.text)
> {s.remove(id);}

Scope would need an isVisible() function wouldn't it?
I'm kinda scared of a first class Scope object without
it.



Jeff Barnes