next up previous
Next: Ubiquitous reflective towers Up: Implementing behavioral reflection Previous: Implementing behavioral reflection

   
Reflective towers

From the above definition, we know that behavioral reflection implies the ability of any program p to observe and modify the data structures actually used to run p itself. This may lead to inconsistencies if updates made by the reflective code come in conflict with updates made by the interpreter. This phenomenon, known as introspective overlap, is tackled in Smith's 3-Lisp [Smi82,Smi84] by making a distinction between the interpreter running p and the interpreter running the reflective code. Smith then takes the argument to its limit by allowing introspective code in the interpreter , which needs another interpreter to be run, and so on, giving rise to a potentially infinite number of interpreters. In fact, in his design, the interpreter is used to run the code of the interpreter , and so on, with the interpreter running the base program. This stack of interpreters is called a reflective tower, and it is illustrated in Figure 1. Because the levels in the tower need not be based on interpretive techniques, Smith and des Rivières purposely use the term reflective processor program (RPP) instead of interpreter.

Although the 3-Lisp reflective tower is potentially infinite, in any single program p and input i, only a finite number of levels n are needed to run the program; this number of levels is called the degree of introspection of p. In the same way well-defined recursions never require an infinite number of recursive calls, a well-defined reflective program never uses an infinite number of embedded reflective procedure calls. Hence, given n, we can replace the level n+1 interpreter by an ultimate non-reflective machine to run p on i.

To summarize, the reflective system proposed by 3-Lisp is described as follows:


  
Figure 1: Reflective tower

Because 3-Lisp assumes that all the interpreters are the same (process the same language), a reflective procedure can be called at any level n in the tower, without having to care about the language in which it is written. When invoked at level n-1, a reflective procedure is run at level n, i.e., by the level n+1 interpreter to avoid the introspective overlap. It is as though the reflective procedure actually inserts lines of code into the interpreter one level up in the tower.

The reflective procedure call is shown in Figure 2. A reflective procedure is called at level 0. Normally, such a procedure call would generates a new activation record , but because the procedure is reflective, it is run by level 2, and thus generate a new activation record of the RPP at level 2. The reflective procedure is passed a reification of the argument structure of the call, the current environment and the current continuation, as shown by the values in 4.


  
Figure 2: Stacks (continuations & environments) of P1 and P2 just after the execution of a reflective procedure call at level 0.


next up previous
Next: Ubiquitous reflective towers Up: Implementing behavioral reflection Previous: Implementing behavioral reflection
Matt Hurlbut
1998-07-02