next up previous
Next: Digression on staticness and Up: Static versus dynamic behavioral Previous: Partial evaluation based models

   
Characterizing staticness in the lookup  apply model

To help clarify things, we now characterize static behavioral reflection in the lookup  apply model. Coarsely speaking, we have made explicit the lookup  apply reflective towers by the following equation [MDC96]:



baf(applyn,...(applyi,...(apply1,(m,a))...)...)


which says that the basic apply function from the implementation (baf) executes the apply method at level n (applyn), which in turn executes the apply method at level n-1 and so on. The level 1 apply method (apply1) executes the method m on the arguments a. Consider the two-level tower:



baf apply (m,a)



In this equation, each of apply, m or a can be either static or dynamic, but if the apply is dynamic, there is little interest in knowing if m or a is static. There are two major ways to know that something is static in a program: syntactically or by a binding-time analysis. For example, the syntax of applications in first-order functional languages forces the applied function to be known at compile-time. In higher-order languages, the applied function is the result of an expression, but a closure analysis [JGS93, §15.2] can show that, in particular cases, the result of this expression is in fact known at compile time. In general, syntactic staticness is much easier to deal with than the one brought to the fore by analysis, but it is also more restrictive.

Figure 4 illustrates the different interesting combinations of static and dynamic values in the above equation and gives a quite general ``least upper bound'' on the necessary compiler technology in each case. When everything is known statically, the result of the whole computation can be obtained at compile time, but this ideal case is indeed very rare. When both the interpreter (baf) and the method are known, we can partially evaluate the interpreter with respect to the method or statically generate a compiler from the interpreter and compile the method. In the third case, where only the interpreter is known, we can generate the compiler statically, but this compiler will have to be used at run-time to compile methods. In the last and most challenging case, the interpreter is not known until run-time, which means that even the generation of a compiler must be done at run-time. They are least upper bounds because specific apply methods may necessitate much simpler implementation techniques. These observations scale up to the more general case of n-level reflective towers.



 
next up previous
Next: Digression on staticness and Up: Static versus dynamic behavioral Previous: Partial evaluation based models
Matt Hurlbut
1998-07-02