Reflection

Or the philosophy behind interpretation. However, it can also be a property of a language implementation in varying degrees. The base defintions are:

Simple Reflection:

is the means by which a program can inspect and modify the state of its interpretation mechanism.

Tower Reflection:

is the means by which a program can inspect and modify the state its interpreter, and its interpreter's interpreter etc.

Reification:

is the operation by which objects in the state of the level above (by convention the level interpreting is considered to be above that being interpreted) are made into objects manipulable at the level being interpreted.

In concrete terms a C program is interpreted by the compiler, and the machine code is interpreted by the microcode and the microcode is interpreted by the hardware. The only defined means of reification in C is setjmp which reifies the continuation of the setjmp function call. It is arguable whether longjmp is reflective. A non-portable kind of reflection would be to overwrite the saved return adddress in the stack frame.

Whilst this helps to explain reflection by relating it to a familiar scenario, it is not the usual way of viewing it. Consider tower reflection: that is not realisable in C, for instance. To support tower reflection we need a fuly reflective architecture, in which every aspect of interpretation can be reified and reflected.

Tower reflection requies that every element can be reified (for example, ``stack'' frames, continuations, bindings, closures, functions).

Motivation: systems which can reason about themselves and can modify themselves sensibly, for example self-configuring code, self-migrating code, self-verifying code. Clearly there are philosophical and logical limits to this! Full reflection is not necessary in general, but is useful for prototyping, after which the unncessary components can be evaluated out (note relationship with compilation and with partial evaluation). More immediately, it is relevant to writing interactive debuggers.