. This paper identifies and solves a class of problems that arise in binding time analysis and more generally in partial evaluation of programs: the approximation and loss of static information due to dynamic expressions with static subexpressions. Solving this class of problems yields substantial binding time improvements and thus dramatically better results not only in the case of partial evaluation but also for static analyses of programs --- this last point actually is related to a theoretical result obtained by Nielson. Our work can also be interpreted as providing a solution to the problem of conditionally static data, the dual of partially static data. We point out which changes in the control flow of a source program may improve its static data flow. Unfortunately they require one to iterate earlier phases of partial evaluation. We show how these changes are subsumed by transforming the source program into continuation-passing style (CPS). The transformed programs get specializ...

In this thesis we present and analyse a set of automatic source-to-source program transformations that are suitable for incorporation in optimising compilers for lazy functional languages. These transformations improve the quality of code in many different respects, such as execution time and memory usage. The transformations presented are divided in two sets: global transformations, which are performed once (or sometimes twice) during the compilation process; and a set of local transformations, which are performed before and after each of the global transformations, so that they can simplify the code before applying the global transformations and also take advantage of them afterwards. Many of the local transformations are simple, well known, and do not have major effects on their own. They become important as they interact with each other and with global transformations, sometimes in non-obvious ways. We present how and why they improve the code, and perform extensive experiments wit...

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