What Not to Do When Writing an Interpreter for Specialisation

  • Neil D. Jones
  • Published 1996 in Dagstuhl Seminar on Partial Evaluation

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.

DOI: 10.1007/3-540-61580-6_11

Extracted Key Phrases

Cite this paper

@inproceedings{Jones1996WhatNT, title={What Not to Do When Writing an Interpreter for Specialisation}, author={Neil D. Jones}, booktitle={Dagstuhl Seminar on Partial Evaluation}, year={1996} }