You imply that this generalizes to rolling back over function calls. Perhaps a function can have a property that states it is undoable and returns an undo closure corresponding to the call.

You can't reliably push back data on file handles, nor can you reliably undo writes to file handles, nor can you take back accesses to tied data. That's where things get tough, and you don't need function calls involved, at least not explicitly--you just need to access some external resource or active data and hypothetical variables fall flat. Which is a shame, as it's a nifty idea.

The way PRECC does it (parse a nondeterministic grammar) is to not execute the code associated with the production, but to figure out how the grammar parses first, and then trigger all the code blocks.

It works by sticking the closure in a list, rather than performing it. That can be "undone" during backtracking.

When reading this stuff on the new regex, I was thinking that this would be needed and maybe could be better directly supported in the grammar class...then came to the secion on hypotheticals, and it's not a general solution and has the nits I mentioned earlier.

So to do that ourselves, in the grammer we would code our own speculative execution when needed. If the side-effects are not needed to continue parsing, just push @list, {code} instead of {code}, where @list is a hypothetical variable as described. For things that must actually be done and undone, there is no code block associated with a backtrack through this node, so we have to keep track of where we are with code fragments at the beginning of each branch. Then our program knows when we go down a different branch, and can clean up first.

Be better if there was a backtrack stack we could push code blocks onto.