Multiple execution granularities.

[theodore-norvell]

We need:

• Run: Run until the bottom evaluation is done.
• Step to return: Run until the current evaluation is done.
• Step over: Run until the end of the current evaluation is done or until the current expression of some sequence is completed. In the latter case, execution should then continue until some node is ready.
• Step into: Like step over, but also stops when a new evaluation has been pushed. In the later case, execution continues until the top evaluation is ready.
• Single step: Advance until a step has been made (or the bottom evaluation is done). Then advance until the top evaluation is done or the top evaluation is ready.

Except for when execution is complete (i.e. the bottom evaluation is done). Each of the above should always do something, i.e. make at least one step.

We need infinite loop protection, so another reason to stop advancing is that some limit on steps has been reached. In this case we need to feed this information back to the user.

Another reason to stop is that input is required. (In the Teaching Machine, this is accomplished by setting a flag in the vms that says that input is required.)

[theodore-norvell]

Step over and step into should stop when one is about to call a lambda expression. They you can choose whether to step over or into each call on a case by case basis.

It would also be nice to step backwards out of a method call. This would mean making an implicit checkpoint just before a step of a call. This could be implemented by having multiple undo stacks. E.g. have one main undo stack (as now) but also substacks. A push onto a substack entails a push onto the main stack. A an undo from a substack means first undoing transactions on the main stack until the top of the substack is on top of the main stack and then undoing one more time. Each undo of the main stack also pops the transaction off the substacks.