The idea is inspired by the use of partial evaluation in optimising program translation. Many core operations in theorem provers exhibit the following pattern.Suppose that we need to execute some algorithm

alg(A,B)

in a situation where a value of

A

is fixed for potentially many different values of

B

. In order to do this efficiently, we can try to find a specialization of

alg

for every fixed

A

, i.e., such an algorithm

algA

, that executing

algA(B)

is equivalent to executing

alg(A,B)

.

The specialized algorithm may be more efficient than the generic one, since it can exploit some particular properties of the fixed value

A

. Typically,

algA(B)

can avoid some operations that

alg(A,B)

would have to perform, if they are known to be redundant for this particular parameter

A

. In particular, we can often identify some tests that are true or false for

A

, unroll loops and recursion, etc.

Difference from partial evaluation

The key difference between run-time specialization and partial evaluation is that the values of

A

on which

alg

is specialised are not known statically, so the specialization takes place at run-time.

There is also an important technical difference. Partial evaluation is applied to algorithms explicitly represented as codes in some programming language. At run-time, we do not need any concrete representation of

alg

. We only have to imagine

alg

when we program the specialization procedure.All we need is a concrete representation of the specialized version

algA

. This also means that we cannot use any universal methods for specializing algorithms, which is usually the case with partial evaluation. Instead, we have to program a specialization procedure for every particular algorithm

alg

. An important advantage of doing so is that we can use some powerful ad hoc tricks exploiting peculiarities of

alg

and the representation of

A

and

B

, which are beyond the reach of any universal specialization methods.

Specialization with compilation

The specialized algorithm has to be represented in a form that can be interpreted.In many situations, usually when

is compiled. Then the code itself can be additionally optimized by answer-preserving transformations that rely only on the semantics of instructions of the abstract machine.

Instructions of the abstract machine can usually be represented as records. One field of such a record stores an integer tag that identifies the instruction type, other fields may be used for storing additional parameters of the instruction, for example a pointer to anotherinstruction representing a label, if the semantics of the instruction requires a jump. All instructions of a code can be stored in an array, or list, or tree.

Interpretation is done by fetching instructions in some order, identifying their typeand executing the actions associated with this type. In C or C++ we can use a switch statement to associate some actions with different instruction tags. Modern compilers usually compile a switch statement with integer labels from a narrow range rather efficiently by storing the address of the statement corresponding to a value

i

in the

i

-th cell of a special array. One can exploit thisby taking values for instruction tags from a small interval of integers.

Data-and-algorithm specialization

There are situations when many instances of

A

are intended for long-term storage and the calls of

alg(A,B)

occur with different

B

in an unpredictable order.For example, we may have to check

alg(A1,B1)

first, then

alg(A2,B2)

, then

alg(A1,B3)

, and so on.In such circumstances, full-scale specialization with compilation may not be suitable due to excessive memory usage. However, we can sometimes find a compact specialized representation