Abstract. This tutorial shows how to rewrite an interpreter written in a higher-order functional language, so that it will become more similar to a compiler, thereby eliminating the overhead due to interpretation. 1 Defining a language by means of an interpreter When writing programs in a functional language, it is fairly easy to “extend” the language by defining an interpreter run, which will take a program prog, and some input data d, and return the result of applying prog to d: run prog d Hence, in this way the programmer can include in his program pieces written in the language implemented by run. run is usually said to give an operational semantics for the language thus defined. Unfortunately, an interpreter written in a straightforward way is likely to introduce a considerable overhead. However, the overhead can be reduced by refactoring a naïve interpreter in such a way that it becomes more similar to a compiler. The refactoring is based on replacing some first-order functions with higher-order ones. 2 An example interpreter For the user to feel comfortable, run should accept programs written in humanoriented form, which can be achieved with the aid of quotation/antiquotation mechanism as usually implemented by Standard ML implementations. The techniques of translating programs from the “concrete ” syntax into the abstract syntax are well known, and will not be considered in this paper. Hence, for the sake