Eval

There are three different ways in which eval might occur, depending on the binding times of the argument and the context. Consider the expression ³ where C is an arbitrary context.

1.

If the binding times of the context and E are both static, the specializer must execute eval at specialization time.

2.

If both binding times are dynamic, the specializer generates code for eval.

3.

  If the value of E is available earlier than the context demands it, the specializer omits the eval altogether and pastes the computed value of E in the dynamic context.

The context cannot possess an earlier binding time than E, because it cannot receive the value of E before it is computed.

In the interesting case 3 we have to avoid a name capture problem: (eval E) mandates that all identifiers occurring free in E must have a top-level binding. If we inline the value of E in the residual program, these free identifiers might be captured. However, all identifiers in a residual program are ``fresh'' identifiers produced by a symbol generator, so this problem does not arise in practice.

In summary, the binding time of the expression must be less than (earlier, more static) or equal to that of the context. If the binding times differ, the specializer can treat it similarly to quoted values. It simply inserts the static value (a piece of program text) in the dynamic residual code. Furthermore, we must insist that values produced by eval must be uniform in their binding time and that no memoization is performed on them because of the representation problem.