What not to do when writing an interpreter for specialisation

Abstract

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 area: using specialisation to remove interpretational overhead. It presents both positive and negative examples, to illustrate the effects of program style on the efficiency and size of the of target programs obtained by specialising an interpreter with respect to a known source program. It concludes with a checklist summarising what was learned from the examples, discussions, and problem analyses.