We were evaluating the first component of a pair; next, we should evaluate the second component which was saved in this frame (and push a FFst frame on the stack to save the first component).

We were evaluating the second component of a pair; when done, we should combine it with the value of the first component saved in this frame to construct a fully evaluated pair.

FArg t e says that we were evaluating the left-hand side of an application, so the next thing we should do is evaluate the term t (the right-hand side, i.e. argument of the application) in environment e. We will also push an FApp frame on the stack.

FVArg v says that we were evaluating the left-hand side of an application, and the next thing we should do is apply it to the given value. This does not normally occur as part of the usual evaluation process for applications, which instead uses FArg. However, it is sometimes useful when reducing other constructs---for example, the pair eliminator match.

FApp v says that we were evaluating the right-hand side of an application; once we are done, we should pass the resulting value as an argument to v.

FLet x ty t2 e says that we were evaluating a term t1 of type ty in an expression of the form let x = t1 in t2, that is, we were evaluating the definition of x; the next thing we should do is evaluate t2 in the environment e extended with a binding for x.

We are executing inside a Try block. If an exception is raised, we will execute the stored term (the "catch" block).

An FExec frame means the focused value is a command, which we should now execute.

We are in the process of executing the first component of a bind; once done, we should also execute the second component in the given environment (extended by binding the variable, if there is one, to the output of the first command).

Apply specific updates to the world and current robot.

The Const is used to track the original command for error messages.

Update the cell at a certain location in the store with the computed value.

Signal that we are done with an atomic computation.

We are in the middle of evaluating a record: some fields have already been evaluated; we are focusing on evaluating one field; and some fields have yet to be evaluated.

We are in the middle of evaluating a record field projection.

We should suspend with the given environment once we finish the current evaluation.

If an exception bubbles all the way up to this frame, then switch to Suspended mode with this saved top-level context.

Add copies of an entity to the robot's inventory.

Make the robot learn about an entity.

When we are on our way "in/down" into a term, we have a currently focused term to evaluate in the environment, a store, and a continuation. In this mode we generally pattern-match on the Term to decide what to do next.

Once we finish evaluating a term, we end up with a Value and we switch into "out" mode, bringing the value back up out of the depths to the context that was expecting it. In this mode we generally pattern-match on the Cont to decide what to do next.

Note that there is no Env, because we don't have anything with variables to evaluate at the moment, and we maintain the invariant that any unevaluated terms buried inside a Value or Cont must carry along their environment with them.

An exception has been raised. Keep unwinding the continuation stack (until finding an enclosing Try in the case of a command failure or a user-generated exception, or until the stack is empty in the case of a fatal exception).

The machine is waiting for the game to reach a certain time to resume its execution.

The machine is suspended, i.e. waiting for another term to evaluate. This happens after we have evaluated whatever the user entered at the REPL and we are waiting for them to type something else. Conceptually, this is like a combination of Out and In: we store a Value that was just yielded by evaluation, and otherwise it is just like In with a hole for the Term we are going to evaluate.