The Spineless Tagless G-machine is an abstract machine designed to support nonstrict higher-order functional languages. This presentation of the machine falls into three parts. Firstly, we give a general discussion of the design issues involved in implementing non-strict functional languages. Next, we present the STG language, an austere but recognisably-functional language, which as well as a denotational meaning has a well-defined operational semantics. The STG language is the "abstract machine code" for the Spineless Tagless G-machine. Lastly, we discuss the mapping of the STG language onto stock hardware. The success of an abstract machine model depends largely on how efficient this mapping can be made, though this topic is often relegated to a short section. Instead, we give a detailed discussion of the design issues and the choices we have made. Our principal target is the C language, treating the C compiler as a portable assembler. Version 2.5 of this paper (minus appendix) appe...

We describe the design, implementation and use of a new kind of profiling tool that yields valuable information about the memory use of lazy functional programs. The tool has two parts: a modified functional language implementation which generates profiling information during the execution of programs, and a separate program which converts this information to graphical form. With the aid of profile graphs, one can make alterations to a functional program which dramatically reduce its space consumption. We demonstrate this in the case of a genuine example --- the first to which the tool was applied --- for which the results are strikingly successful.

Some modern superscalar microprocessors provide only imprecise exceptions. That is, they do not guarantee to report the same exception that would be encountered by a straightforward sequential execution of the program. In exchange, they offer increased performance or decreased chip area (which amount to much the same thing). This performance/precision tradeoff has not so far been much explored at the programming language level. In this paper we propose a design for imprecise exceptions in the lazy functional programming language Haskell. We discuss several designs, and conclude that imprecision is essential if the language is still to enjoy its current rich algebra of transformations. We sketch a precise semantics for the language extended with exceptions. The paper shows how to extend Haskell with exceptions without crippling the language or its compilers. We do not yet have enough experience of using the new mechanism to know whether it strikes an appropriate balance between expressiveness and pwrformance.

. We describe the design and implementation of a system for tracing computations in a lazy functional language. The basis of our tracing method is a program transformation carried out by the compiler: transformed programs compute the same values as the original, but embedded in functional data structures that also include redex trails showing how the values were obtained. A special-purpose display program enables detailed but selective exploration of the redex trails, with cross-links to the source program. Keywords: debugging, graph reduction, Haskell, program transformation. 1 Introduction 1.1 Why trace functional computations? Functional programming languages have many advantages over the conventional alternative of procedural languages. For example, program construction is more rapid, more modular and less error-prone. Programs themselves are more concise. Yet functional programming systems are not very widely used. There are various reasons for this, but one that crops up time ...

We present a comprehensive analysis of all the components of creation, access, and disposal of heap-allocated and stack-allocated activation records. Among our results are: . Although stack frames are known to have a better cache read-miss rate than heap frames, our simple analytical model (backed up by simulation results) shows that the di#erence is too trivial to matter. . The cache write-miss rate of heap frames is very high; we show that a variety of miss-handling strategies (exemplified by specific modern machines) can give good performance, but not all can. . Stacks restrict the flexibility of closure representations (for higher-order functions) in important (and costly) ways. . The extra load placed on the garbage collector by heap-allocated frames is small. . The demands of modern programming languages make stacks complicated to implement e#ciently and correctly. Overall, the execution cost of stack-allocated and heap-allocated frames is similar; but heap frames are s...

Abstract not found

We present a method, adapted to polymorphically typed functional languages, to detect and collect more garbage than existing GCs. It can be applied to strict or lazy higher order languages and to several garbage collection schemes. Our GC exploits the information on utility of arguments provided by polymorphic types of functions. It is able to detect garbage that is still referenced from the stack and may collect useless parts of otherwise useful data structures. We show how to partially collect shared data structures and to extend the type system to infer more precise information. We also present how this technique can plug several common forms of space leaks.

. Of late it has become very common for research compilers to emit C as their target code, relying on a C compiler to generate machine code. In effect, C is being used as a portable compiler target language. It offers a simple and effective way of avoiding the need to re-implement effective register allocation, instruction selection, and instruction scheduling, and so on, all for a variety of target architectures. The trouble is that C was designed as a programming language not as a compiler target language, and is not very suitable for the latter purpose. The obvious thing to do is to define a language that is designed as a portable target language. This paper describes C--, a portable compiler target language, or assembler. C-- has to strike a balance between being high-level enough to allow the back end a fair crack of the whip, while being low level enough to give the front end the control it needs. It is not clear that a path exists between these two rocks; the ghos...

We describe a debugger for the lazy functional language Haskell. The basic idea is to transform a Haskell program into a program that evaluates to the same result as the original program but also produces an evaluation dependence tree describing how the result was obtained. If an error is detected while running the program, the programmer can browse the evaluation dependence tree, or use algorithmic debugging, in order to try to find the erroneous definition. The method is compared to other ways of debugging lazy functional programs. Some ideas for improvements are also presented.

. Interrupt handling is a tricky business in lazy functional languages: we have to make sure that thunks that are being evaluated can be halted and later restarted if and when they are required. This is a particular problem for implementations which use black-holing. Black-Holing deliberately makes it impossible to revert such thunks to their original state to avoid a serious space leak. Interactive Haskell implementations such as Hugs and hbi catch interrupts and avoid the problem by omitting or disabling black-holing. Batch mode Haskell implementations such as HBC and the Glasgow Haskell Compiler (GHC) avoid this problem by disabling black-holing or by providing no way to catch interrupts. This paper describes a modification to GHC's abstract machine (the Spineless Tagless G-Machine) which simultaneously supports both interrupts and black-holing. 1 Introduction Black-Holing [6] is an important technique for avoiding space leaks in lazy functional languages. When a program starts to ...