Abstract. Scheme and Smalltalk continuations may have unlimited extent. This means that a purely stack-based implementation of continuations, as suffices for most languages, is inadequate. We review several implementation strategies for continuations and compare their performance using instruction counts for the normal case and continuation-intensive synthetic benchmarks for other scenarios, including coroutines and multitasking. All of the strategies constrain a compiler in some way, resulting in indirect costs that are hard to measure directly. We use related measurements on a set of benchmarks to calculate upper bounds for these indirect costs.

Compilers for higher-order programming languages like Scheme, ML, and Lisp can be broadly characterized as either "direct compilers" or "continuation-passing style (CPS) compilers", depending on their main intermediate representation. Our central result is a precise correspondence between the two compilation strategies. Starting from

We present a formal and general specification of lambda lifting and prove its correctness with respect to a call-by-name operational semantics. We use this specification to prove the correctness of a lambda lifting algorithm similar to the one proposed by Johnsson. Lambda lifting is a program transformation that eliminates free variables from functions by introducing additional formal parameters to function definitions and additional actual parameters to function calls. This operation supports the transformation from a lexicallystructured functional program into a set of recursive equations. Existing results provide specific algorithms and only limited correctness results. Our work provides a more general specification of lambda lifting (and related operations) that supports flexible translation strategies, which may result in new implementation techniques. Our work also supports a simple framework in which the interaction of lambda lifting and other optimizations can be studied and from which new algorithms might be obtained.

Machine [21], is to pass the ith argument in register i: if the ith argument happens to be a variable (which typically corresponds to an output argument), the value passed is a pointer to the location of the variable (which may be either on the stack or on the heap). In effect, this policy passes output arguments by reference. The policy is motivated by the fact that, in general, Prolog procedures do not have any notion of input and output arguments, and a particular argument to a procedure can be an input argument in one invocation and an output argument in another. Returning outputs in memory allows a simple and uniform treatment of communication between procedure activations under these circumstances. The main advantage of a memory return policy, apart from simplicity, is that it never prevents tail call optimizations, since one memory location is as good as any other. Because of this, there is no need to insert code to move a value to a preferred location, as in Example 3.2. Thus, ...

The combination of intersection and union types with ow types gives the compiler writer unprecedented exibility in choosing data representations in the context of a typed intermediate language. We present the design of such a language and the design of a framework for exploiting the type system to support multiple representations of the same data type in a single program. The framework can transform the input term, in a type-safe way, so that dierent data representations can be used in the transformed term | even if they share a use site in the pre-transformed term. We have implemented a compiler using the typed intermediate language and instantiated the framework to allow specialized function representations. We test the compiler on a set of benchmarks and show that the compile-time performance is reasonable. We further show that the compiled code does indeed bene t from specialized function representations.