The last years have witnessed a flurry of new results in the area of partial evaluation. These tutorial notes survey the field and present a critical assessment of the state of the art. 1 Introduction Partial evaluation is a source-to-source program transformation technique for specializing programs with respect to parts of their input. In essence, partial evaluation removes layers of interpretation. In the most general sense, an interpreter can be defined as a program whose control flow is determined by its input data. As Abelson points out, [43, Foreword], even programs that are not themselves interpreters have important interpreter-like pieces. These pieces contain both compile-time and run-time constructs. Partial evaluation identifies and eliminates the compile-time constructs. 1.1 A complete example We consider a function producing formatted text. Such functions exist in most programming languages (e.g., format in Lisp and printf in C). Figure 1 displays a formatting functio...

Abstract. Type-directed partial evaluation stems from the residualization of arbitrary static values in dynamic contexts, given their type. Its algorithm coincides with the one for coercing asubtype value into a supertype value, which itself coincides with the one of normalization in the-calculus. Type-directed partial evaluation is thus used to specialize compiled, closed programs, given their type. Since Similix, let-insertion is a cornerstone of partial evaluators for callby-value procedural programs with computational e ects. It prevents the duplication of residual computations, and more generally maintains the order of dynamic side e ects in residual programs. This article describes the extension of type-directed partial evaluation to insert residual let expressions. This extension requires the userto annotate arrowtypes with e ect information. It is achieved by delimiting and abstracting control, comparably to continuation-based specialization in direct style. It enables type-directed partial evaluation of e ectful programs (e.g.,ade nitional lambda-interpreter for an imperative language) that are in direct style. The residual programs are in A-normal form. 1

Partial evaluators can be separated into two classes: offline specializers, which make all of their reduce/residualize decisions before specialization, and online specializers, which make such decisions during specialization. The choice of which method to use is driven by a tradeoff between the efficiency of the specializer and the quality of the residual programs that it produces. Existing research describes some of the inefficiencies of online specializers, and how these are avoided using offline methods, but fails to address the price paid in specialization quality. This paper motivates research in online specialization by describing two fundamental limitations of the offline approach, and explains why the online approach does not encounter the same difficulties.

Binding-time analysis determines when variables and expressions in a program can be bound to their values, distinguishing between early (compile-time) and late (run-time) binding. Binding-time information can be used by compilers to produce more efficient target programs by partially evaluating programs at compile-time. Binding-time analysis has been formulated in abstract interpretation contexts and more recently in a type-theoretic setting. In a type-theoretic setting binding-time analysis is a type inference problem: the problem of inferring a completion of a λ-term e with binding-time annotations such that e satisfies the typing rules. Nielson and Nielson and Schmidt have shown that every simply typed λ-term has a unique completion ê that minimizes late binding in TML, a monomorphic type system with explicit binding-time annotations, and they present exponential time algorithms for computing such minimal completions. 1 Gomard proves the same results for a variant of his two-level λ-calculus without a so-called “lifting ” rule. He presents another algorithm for inferring completions in this somewhat restricted type system and states that it can be implemented in time O(n 3). He conjectures that the completions computed are minimal.

This paper presents a step forward in the use of partial evaluation for interpreting and compiling programs, as well as for automatically generating a compiler from denotational definitions of programming languages. We determine the static and dynamic semantics of a programming language, reduce the expressions representing the static semantics, and generate object code by instantiating the expressions representing the dynamic semantics. By processing the static semantics of the language, programs get compiled. By processing the static semantics of the partial evaluator, compilers are generated. The correctness of a compiler is guaranteed by the correctness of both the executable specification and our partial evaluator. The results reported in this paper improve on previous work in the domain of compiler generation [16, 30], and solves several open problems in the domain of partial evaluation [15]. In essence: ffl Our compilation goes beyond a mere syntax-tosemantics mapping since the ...

. A partial evaluator, given a program and a known "static" part of its input data, outputs a specialised or residual program in which computations depending only on the static data have been performed in advance. Ideally the partial evaluator would be a "black box" able to extract nontrivial static computations whenever possible; which never fails to terminate; and which always produces residual programs of reasonable size and maximal efficiency, so all possible static computations have been done. Practically speaking, partial evaluators often fall short of this goal; they sometimes loop, sometimes pessimise, and can explode code size. A partial evaluator is analogous to a spirited horse: while impressive results can be obtained when used well, the user must know what he/she is doing. Our thesis is that this knowledge can be communicated to new users of these tools. This paper presents a series of examples, concentrating on a quite broad and on the whole quite successful application ...

A partial evaluator is an automatic program transformation tool. Given as input a general program and part of its input, it can produce a specialized version. If the partial evaluator is self-applicable, program generators can be made. The goal is efficiency: the specialized program often runs an order of magnitude faster than the general one. We consider partial evaluation of the pragmatic oriented imperative C programming language. New problems studied includes partially static data structures, non-local static side-effects under dynamic control, and a restricted use of pointers. We define a Core C language, derive a two-level Core C language with explicit binding times, and formulate well-annotatedness conditions. Function specialization and code generation is described in terms of the two-level Core C language. An implementation of the C partial evaluator has been made. Some experimental results are given. 1

We propose a new method for improving the specialization of programs by inserting an interpreter between a subject program and a specializer. We formulate three specializer projections which enable us to generate specializers from interpreters. The goal is to provide a new way to control the specialization of programs, and we report the first practical results. This is a step towards the automatic production of specializers. Using an existing, self-applicable partial evaluator we succeeded in generating a stand-alone specializer for a first-order functional language which is stronger than the partial evaluator used for its generation. The generated specializer corresponds to a simple supercompiler. As an example we show that the generated specializer can achieve the same speed-up effect as the Knuth, Morris & Pratt algorithm by specializing a naïve matcher with respect to a fixed pattern. The generated specializer is also strong enough to handle bounded static variation, a case which partial evaluators usually can not handle.

Introduction: What is partial evaluation? Partial evaluation is a technique to partially execute a program, when only some of its input data are available. Consider a program p requiring two inputs, x 1 and x 2 . When specific values d 1 and d 2 are given for the two inputs, we can run the program, producing a result. When only one input value d 1 is given, we cannot run p, but can partially evaluate it, producing a version p d1 of p specialized for the case where x 1 = d 1 . Partial evaluation is an instance of program specialization, and the specialized version p d1 of p is called a residual program. For an example, consider the following C function p

Compiler generation is often emphasized as being the most important application of partial evaluation. But most of the larger practical applications have, to the best of our knowledge, been outside this field. Especially, no one has generated compilers for languages other that small languages. This paper describes a large application of partial evaluation where a realistic compiler was generated for a strongly typed lazy functional language. The language, that was called BAWL, was modeled after the language in Bird and Wadler [BW88] and is a combinator language with pattern matching, guarded alternatives, local definitions and list comprehensions. The paper describes the most important techniques used, especially the binding time improvements needed in order to get small and efficient target programs. Finally, the performance of the compiler is compared with two compilers for similar languages: Miranda and LML. Keywords Compiler generation, partial evaluation, binding time improvemen...