The notion of statically known information in programs is central to compilers. Compilers serve two main purposes. First, they translate a computation expressed in a high-level source language (or model of computation) into an equivalent computation expressed in a (usually) lower-level language. The lower-level language is usually more efficient because it is directly implemented in hardware. Second, compilers process the static semantics of the computation, that is code that can be executed at compile time because it is known and it processes statically known data (it typically ranges from compile time checks for contextual properties to constant folding).
If the source and the target languages cannot be determined at compile time, compiling itself is indeed pointless. In behavioral reflection, none of them can be considered as known at compile time. In particular, it is perfectly conceivable, and even legitimate to be able to dynamically change the target language. This would be interesting for example when processes are migrated across a network of perhaps statically unpredictable heterogeneous processors, a typical application of behavioral reflection.
A legitimate question to ask is whether compiling behavioral reflection is of any interest. A first answer is efficiency. Unless we want to write programs in some reflective extension of assembler, or to produce hardware implementation of high-level reflective programming languages, acceptable performance can only be achieved by translation of reflective programs into assembly code. A more insightful answer is expressed in the following hypothesis:
Static behavioral reflection hypothesis
In as much as standard languages, by the virtue of their design, provide
their programs with enough statically known information to be translated to
some target language (i.e., source code, source language syntax and sematics,
target language syntax and sematics as well as the transformation between the
high-level abstract machine of the source language and a low-level abstract
machine written in the target language), languages with static behavioral
reflection, by the virtue of their design, provide their programs with enough
statically known information to enable their translation to some target
non-reflective language.
The major point here is that languages with static behavioral reflection can be both powerful and efficient. Moreover, in a language allowing dynamic behavioral reflection, programs can still exhibit static reflective computations that can be compiled.
The above hypothesis is purposely vague about what exactly we mean by ``information'' and ``known at compile time''. Both heavily depend on the language itself. To illustrate the point, consider the following example about functional programming languages. The essential characteristic of functional languages is functions as first-class values, i.e., the ability to create functions at run-time, to pass them as actuals and to return them as results. In early Lisps, functions were represented as lists and could be constructed at run-time. Today, Scheme also provides first-class functions but insists (through its syntax) that their code is known at compile time. Though more restrictive, a large number of applications advocated for functional programming can be implemented in Scheme. Moreover, Lisp compilers have adapted to the presence of functions as lists, although some amount of interpretation may be needed to deal with dynamically constructed functions.
The static behavioral reflection hypothesis adopts a similar idea. And, we propose to explore both the different models of static behavioral reflection and the implementation techniques that could serve to compile programs in static models and to take care of the static reflection that appear in less restrictive (dynamic) models.