Partial evaluation

This article includes a list of general references, but it lacks sufficient corresponding inline citations. Please help to improve this article by introducing more precise citations. (May 2013) (Learn how and when to remove this template message)

In computing, partial evaluation is a technique for several different types of program optimization by . The most straightforward application is to produce new programs that run faster than the originals while being guaranteed to behave in the same way.

A computer program prog is seen as a mapping of input data into output data:

${\displaystyle prog:I_{\text{static}}\times I_{\text{dynamic}}\to O,}$

where ${\displaystyle I_{\text{static}}}$, the static data, is the part of the input data known at compile time.

The partial evaluator transforms ${\displaystyle \langle prog,I_{\text{static}}\rangle }$ into ${\displaystyle prog^{*}:I_{\text{dynamic}}\to O}$ by precomputing all static input at compile time. ${\displaystyle prog^{*}}$ is called the "residual program" and should run more efficiently than the original program. The act of partial evaluation is said to "residualize" ${\displaystyle prog}$ to ${\displaystyle prog^{*}}$.

Futamura projections[]

A particularly interesting example of the use of partial evaluation, first described in the 1970s by Yoshihiko Futamura,^[1] is when prog is an interpreter for a programming language.

If I_static is source code designed to run inside that interpreter, then partial evaluation of the interpreter with respect to this data/program produces prog*, a version of the interpreter that only runs that source code, is written in the implementation language of the interpreter, does not require the source code to be resupplied, and runs faster than the original combination of the interpreter and the source. In this case prog* is effectively a compiled version of I_static.

This technique is known as the first Futamura projection, of which there are three:

1. Specializing an interpreter for given source code, yielding an executable.
2. Specializing the specializer for the interpreter (as applied in #1), yielding a compiler.
3. Specializing the specializer for itself (as applied in #2), yielding a tool that can convert any interpreter to an equivalent compiler.

They were first described by Futamura in 1983.^[2]

See also[]

• Compile-time function execution
• Memoization
• Partial application
• Run-time algorithm specialisation
• s_mn theorem
• Strength reduction
• Template metaprogramming

References[]

General references[]

External links[]