Advanced debugging systems sometimes provide some form of backtracking to states earlier in the execution of the program, thus allowing the effect of program statements to be undone. This can be provided either by resetting the system state to that saved by a snapshot taken at some previous moment, or by allowing the reverse execution of individual statements. For single-thread procedural languages, this is moderately straightforward; for those involving any form of more complicated control structures, such as the coroutines provided in SIMULA with their related scheduling statements, the issues are considerably more complicated. The authors consider in detail program statements which can cause changes to the list of events scheduled to occur at future times, such as HOLD, ACTIVATE, PASSIVATE, and WAIT. They establish what information must be stacked since these statements are obeyed normally in the forwards direction in order that the effects of the statements can be undone at some later time. In particular, they show that only three different inverse operations must be provided in order to have the power to undo the effect of any of the different scheduling operations executed in the forwards direction. A clear example is given showing this in practice.

In normal execution, activation records for procedures can be discarded when the procedure terminates. In contrast, a coroutine activation record can be reclaimed by garbage collection only when there are no longer any references to it which might later be used to reactivate it. If, in addition, reversible execution is to be allowed, what is apparently garbage may yet revert to its earlier state of being active. The implications of this for the storage management of activation records are briefly explored. Having elegantly established the logical prerequisites for reverse execution, the paper concludes with a few tantalizingly short comments on their implementation and use in a real debugging system.