The Glasgow Haskell compiler a technical overview

Simon L Peyton Jones Cordy Hall Kevin Hammond Will Partain

Phil Wadler

Department of Computing Science University of Glasgow G QQ

email simonpjdcsglasgowacuk

December

This paper appears in the Proceedings of the UK Joint systems We hop e that this pap er serves to substantiate

Framework for Information Technology JFIT Technical this p oint

Conference Keele

The compiler work describ ed in this pap er is one of the

two strands of the SERCfunded GRASP pro ject The

other concerns parallel functional programming on the

Abstract

GRIP multiprocessor but space precludes coverage of

b oth

We give an overview of the Glasgow Haskell compiler

fo cusing esp ecially on way in which we have b een able

to exploit the rich theory of functional languages to give

Goals

very practical improvements in the compiler

Haskell is a purely functional nonstrict language de

The compiler is p ortable mo dular generates go o d co de

signed by an international group of researchers Hudak

and is freely available

et al It has now b ecome a de facto standard for

the nonstrict or lazy functional programming commu

nity with at least three compilers available

Introduction

Our goals in writing a new compiler were these

Computer Science is b oth a scientic and an engineering

discipline As a scientic discipline it seeks to establish

 To make freely available a robust and portable com

generic principles and theories that can b e used to ex

piler for Haskel l that generates good quality code

plain or underpin a variety of particular applications As

This goal is more easily stated than achieved Haskell

an engineering discipline it constructs substantial arte

is a rather large language incorp orating a rich syn

facts of software and hardware sees where they fail and

tax a new type system that supp orts systematic

where they work and develops new theory to underpin

overloading using socalled type classes Wadler

areas that are inadequately supp orted Milner elo

Blott a wide variety of builtin data types

quently argues for this dual approach in Computer Sci

including arbitraryprecision integers rationals and

ence

arrays a mo dule system and an inputoutput sys

Functional programming is a research area that oers an

tem

unusually close interplay b etween these two asp ects Pey

 To provide a modular foundation that other re

ton Jones b Theory often has immediate practical

searchers can extend and develop In our exp erience

application and practice often leads directly to new de

researchers are often unable to evaluate their ideas

mands on theory This pap er describ es our exp erience of

b ecause the sheer eort of building the framework re

building a substantial new compiler for the purely func

quired is to o great We have tried very hard to build

tional language Haskell We discuss our motivations ma

our compiler in a welldocumented and mo dular way

jor design decisions and achievements paying particular

so that others will nd it relatively easy to mo dify

attention to the interaction of theory and practice

Scaling prototypes up into large real systems app ears  To learn what real programs do The intuition of

to b e less valued in the academic community than small an implementor is a notoriously p o or basis for tak

systems that demonstrate concepts b eing sometimes b e ing critical design decisions The RISC revolution in

ing dismissed as just development work Nevertheless computer architecture was based partly on the sim

we b elieve that many research problems can only b e ex ple idea of measuring what real programs actually do

p osed during the act of constructing large and complex most often and implementing those op erations very

Mo dule Lines

well Hennessy Patterson Lazy functional

Major passes

programs execute in a particularly nonintuitive fash

Main

ion and we plan to make careful quantitative mea

Parser

surements of their b ehaviour

Renamer

Type inference

An overview of the compiler

Desugaring

Corelanguage transformation

The compiler and its runtime system have the following

STGlanguage transformation

ma jor characteristics

Co de generation

Data type denition and manipulation

 It is written almost entirely in Haskell The only

Haskell abstract syntax

exception is that the parser is written in Yacc and

Core language

C

STG language

Abstract C

 It generates C as its target co de This has now b e

Identier representations

come relatively common conferring as it do es wide

Type representations

p ortability The big question is of course what ef

Prelude denitions

ciency p enalty is paid a matter we discuss in Sec

Utility modules

tion

Utilities

Proling

 We have extended the language to allow mixed

TOTAL

language programming by supp orting arbitrary in

line statements written in C It is of course not p os

Figure Breakdown of mo dule sizes

sible to do this in a completely secure way for ex

ample the C pro cedure could overwrite the Haskell

heap but our technique is referentially transparent

parser the compiler itself the C compiler the Unix as

that is all the usual program transformations remain

sembler and the Unix linker The main passes of the

valid

compiler itself are shown in Figure They are as follows

Figure summarises their sizes

This mixedlanguage working allows us to extend

Haskell easily for example to provide access to ex

A simple recursivedescent parser recognises the sim

isting pro cedure libaries Without a general way of

ple syntax output by the separate main parser pro

calling C each such extension would require a sepa

cess The abstract syntax tree pro duced by this

rate mo dication to the co de generator

parser faithfully represents every construct in the

 Haskells monolithic arrays are fully implemented

Haskell source language even where a distinction is

with O access time In addition we have ex

purely syntactic This improves the readability of

tended the language with incrementallyupdatable

error messages from the type checker

arrays indeed the monolithic arrays are imple

The renamer resolves scoping and naming issues es

mented using these mutable arrays

p ecially those concerned with mo dule imp orts and

exp orts

 The interface b etween the storage manager and the

compiler is carefully dened and highly congurable

The type inference pass annotates the program with

For example the storage manager comes with no

type information and transforms out all the over

fewer than four dierent garbage collectors including

loading The details of the latter transformation are

a generational one

given by Wadler Blott we do not discuss it

further here

 The compiler and its runtime system also supp ort

comprehensive runtime proling of b oth space and

The desugarer converts the rich Haskell abstract syn

time at b oth the user level and the evaluationmodel

tax into a very much simpler functional language we

level Sansom Peyton Jones

call the Core language Notice that desugaring fol

lows type inference As a result type error messages

Organisation

are expressed in terms of the original source and

they also app ear more quickly

The overall organisation of the compiler is quite conven

tional A driver program runs a sequence of Unix pro A variety of optional Corelanguage transformation

cesses namely a literatescript prepro cessor the main passes improve the co de Other front ends Haskell source

Lex/Yacc parser CoreSyntax Transform

Prefix form CoreToStg

Reader StgSyntax Transform

AbsSyntax CodeGen

Renamer Abstract C

AbsSyntax Other code Flatten generators

Typechecker C

AbsSyntax C compiler

Desugarer Native code

Figure Overview of the Glasgow Haskell Compiler

 Copy propagation is a sp ecial case of inlining a A simple pass then converts Core to the Shared Term

1

letb ound variable Graph STG language an even simpler but still

purely functional language

let v w in e  e w =v

A variety of optional STGlanguage transformation

passes improve the STG co de

where v and w are variables It is a sp ecial case

b ecause the rule remains valid even if w is an arbi

The code generator converts the STG language to Ab

trary expression which is certainly not true in an

stract C Abstract C is no more than an internal data

imp erative language

type that can b e printed in C syntax or if preferred

though we have not done this in assemblylanguage

 Pro cedure inlining is an example of b eta reduction

syntax for a particular machine

If f is dened like this

The targetcode printer prints Abstract C in a form

f xy b

acceptable to a C compiler

then an expression with a call of f such as f a a

1 2

can b e transfomed to b a =x ; a =y

1 2

Compilation by transformation

 Lifting invariant expressions out of lo ops corresp onds

A consistent theme runs through all our design deci

to a simple transformation called the full laziness

sions namely that most of the compilation process is

transformation Hughes Peyton Jones

expressed as correctnesspreserving transformations of a

Lester

purelyfunctional program A wide variety of conventional

imp erativeprogram optimisations have simple counter

parts as functionallanguage transformations each of

This idea of compilation by transformation is not new

which replaces equals by equals Here are just three

App el Fradet Metayer Kelsey

examples

but it is particularly applicable in a nonstrict language

Although nonstrict semantics carries an implementation

1

The STG language was originally short for Spineless Tagless

cost it also means that transformation rules such as those

Gmachine language but in fact the language is entirely indep en

ab ove can b e applied globally and in a wholesale fashion dent of the abstract machine mo del used to implement it

without side conditions This is not true of a strict lan compose whose type is

guage let alone a language with side eects Supp ose

compose 8 : ! ! ! ! !

for example that b ab ove did not mention x and that the

evaluation of a did not terminate In a strict language

1

The function might b e dened like this in an untyped

the semantics of the original call is nontermination while

Core language

after inlining f it may not b e

compose f g x

In short we have tried to gain the maximum leverage

let y g x in f y

from the purity of the language we are compiling In

We have written the denition a little curiously using a

deed we have gone further and developed several new

let expression for reasons which will b ecome apparent

techniques to express within a purelyfunctional notation

Now supp ose that we wished to unfold a particular call

a number of matters that are more commonly left im

to compose say compose show double v where v is

plicit Expressing them in this way exp oses them to co de

an Int double doubles it and show converts the result

improving transformations In particular

to a String The result of unfolding the call to compose

is an instance of the b o dy of compose thus

 We developed the idea of unboxed data types in order

let y double v in show y

to exp ose the degree of evaluation of a value to the

transformation system Peyton Jones Launchbury

Now we want to b e able to identify the type of every

variable and subexpression so must calculate the type

of y In this case it has type Int but in another appli

 We developed the STG language so that a number

cation of compose it may have a dierent type All this

of usually implicit matters such as just when a clo

is b ecause its type in the b o dy of compose itself is just a

sure is constructed and whether it is up dated can b e

type variable It is clear that in a p olymorphic world it

exp osed Peyton Jones a

is insucient merely to tag every variable of the original

program with its type b ecause this information do es not

 We developed the use of monads to supp ort in

survive across program transformations Indeed no other

putoutput calling C pro cedures with side eects

compiler known to us for a p olymorphicallytyped lan

and incrementallyupdatable arrays Peyton Jones

guage preserves type information across arbitrary trans

Wadler This formulation allows arbitrary

formations

transformation of sideeecting computations to b e

p erformed without aecting their meaning

What then is to b e done Clearly the program must

b e decorated with type information in some way and

We have now completed an overview of the compiler The

every program transformation must b e sure to preserve

rest of the pap er gives more details ab out some selected

it Deciding exactly how to decorate the program and

asp ects

how to maintain these decorations correct during trans

formation seemed rather dicult until we realised that

a welldeveloped otheshelf solution was available from

The Core language and the second

computer science theory namely the secondorder lambda

order lambda calculus

calculus

The Core language is meant to b e just large enough to The idea is that every p olymorphic function such as

express eciently the full range of Haskell programs and compose receives a type argument for each universally

no larger The obvious choice for such a language is the quantied p olymorphic variable in its type ; ; and

lambda calculus augmented with let letrec and case in the case of compose and whenever a p olymorphic

expressions function is called it is passed extra type arguments to in

dicate the types to which its p olymorphic type variables

However a prime consideration for us is to preserve type

are to b e instantiated The denition of compose now

information through the entire compiler right up to the

b ecomes

co de generator despite the wholesale transformation that

we exp ected to b e applied to the program There are var compose abc

ious ways in which type information is either desirable or fbc

essential to the later stages of compilation for example gab

a higherorder strictness analyser may need accurate type xa

information in order to construct correct xed p oints let yb g x in f y

The trouble is that program transformation involves The function takes three type arguments a b and c

type manipulation Consider for example the function as well as its value arguments f g and x The types of

The type of tcExpr is as follows the latter can now b e given explicitly as can the type of

the lo cal variable y A call of compose is now given three

tcExpr Expr TcM UniType

extra type arguments which instantiate a b and c just

as the normal arguments instantiate f g and x For

One might have though that tcExpr would have type

example the call of compose we lo oked at earlier is now

Expr UniType a function from expressions to types

written like this

but quite a lot of plumbing is required b ehind the

scenes Firstly if there is a type error in the program the

compose Int Int String show double v

typeinference pro cess can fail when typechecking fun or

arg or during the unication step Secondly there must It is now simple to unfold this call by instantiating the

b e a uniquename supply from which to manufacture a b o dy of compose with the supplied arguments to give the

new type variable Thirdly there must b e some way of expression

collecting and displaying error messages Fourthly the

let yInt double v in show y

unication pro cess works by incrementally augmenting a

substitution mapping type variables to types All of these

Notice that the letb ound variable y is now automati

would usually b e handled in an imp erative language by

cally attributed the correct type

side eects or by some sort of exceptionhandling mech

In short the secondorder lambda calculus provides us

anism We handle them all using a monad

with a wellfounded notation in which to express and

The TcM type constructor encapsulates all this plumbing

transform p olymorphicallytyped programs The type in

This is most easily seen by lo oking at the denition of

ference pass pro duces a translated program in which the

TcM

extra type abstractions and applications are made ex

plicit

type TcM a Uniq Subst Maybe a Uniq Subst

data Maybe a Nothing Just a

Monads

That is a value of type TcM a is a function that takes

a uniquename supply and a substitution and delivers

Monads are an idea from category theory for which we

either Nothing indicating failure or Just v where v is

have found a number of fruitful applications b oth in writ

a triple of a value of type a a depleted name supply

ing the compiler itself and to encapsulate sideeecting

and an augmented substitution We have omitted the

op erations in the co de b eing compiled Moggi

gathering of error messages from this denition of TcM to

Wadler We fo cus here on the use of monads in

reduce clutter

the compiler

Benets of monadic programming

Monads in the compiler

Programming using monads has a number of b enets

To take a particular example here is the slightly simpli

Firstly the plumbing is implicit which makes the program ed co de from the compiler for typechecking an appli

cation

much easier to read and write

tcExpr Ap fun arg

Secondly because the plumbing is al l encapsulated in one

tcExpr fun thenTc funty

place it is very easy to modify For example well over a

tcExpr arg thenTc argty

year after the type checker was working we added an error

newTyVar thenTc resty

recovery mechanism so that a single type error would not

cause the entire typechecker to halt It is now p ossible

unify funty argty arrow resty

to recover from the error and gather several accurate

thenTc

type error messages in one run of the compiler This

was achieved in a single afterno ons work mo difying very

returnTc resty

lo calised parts of the type checker

At an informal level this co de should b e legible even by

readers with no exp erience of type inference It can b e

Using C as a target language

read like this To typecheck an application Ap fun arg

We generate co de in the C language as our primary target rst typecheck fun inferring the type funty then

rather than generating native co de direct In this way typecheck arg inferring the type argty Now invent

we gain instant p ortability b ecause C is implemented a fresh type variable resty and unify funty with

on such a wide variety of architectures and we b enet argty resty Finally return resty as the type

directly from others improvements in C co de generation of the application

code that appears to be signicantly better than we could This approach of using C as a highlevel assembler

generate using any handbuilt code generator unless we has gained p opularity recently Bartlett Miranda

2

were prepared to lavish an enormous amount of eort on In particular the work of Tarditi et al on com

it piling SML to C developed indep endently and concur

rently with ours addresses essentially the same problems

For each architecture for which we want fast co de we

Tarditi Acharya Lee

provide a header le dening a handful of C macros that

customise the compilation to that particular architecture One approach to compiling into C is to translate the entire

The two really imp ortant things to get right are these program into a giant C pro cedure This turns out to

b e utterly impractical Not only do most C compilers

have trouble in compiling millionline pro cedures but the

 Register mapping gcc allows one to sp ecify that a

approach also defeats separate compilation

particular global variable is to b e kept in a register

which allows us to keep say the heap p ointer p er

Instead we simply compile each extended basic blo ck into

manently in a register

a parameterless C pro cedure giving rise to a large num

b er of easilycompiled pro cedures The registers of the

 Jumps Rather than returning to the interpreter as

evaluation mo del such as the heap p ointer stack p ointer

discussed ab ove jumps are compiled to genuine jump

environment p ointer and so on are mapp ed to global

machine instructions using GNU Cs inline assembly

C variables Temporary variables are mapp ed to lo cal

facility This eliminates entirely the overhead of the

C variables whose scop e is the pro cedure for that basic

interpreter

blo ck The latter are in turn usually mapp ed to registers

by the compiler

Debugging

There is one ma jor problem with this approach we need

We originally used C as our target to confer p ortability

to b e able to jump to an extended basic blo ck but since

and to reduce co degeneration eort The design decision

such a block is implemented as a C procedure we can

had one ma jor unexp ected b enet it made debugging

only call it Unfortunately every such call would make

the co de generator much easier in two particular ways

Cs return stack grow by one more word which is certain

to cause stack overow

 We made extensive use of the Clanguage gdb source

We solve this problem using a neat and completely

level debugger for stepping through compiled co de

p ortable trick Each parameterless function represent

 Since the interpreter is executed at every jump

ing an extended basic blo ck returns the co de p ointer to

it is easy to add co de to record a trail of the most

which it would like to jump rather than calling it The

recent few dozen jumps and to p erform hygiene

execution of the entire program is controlled by the fol

checks on the state of the system eg do es the stack

lowing oneline interpreter

contents lo ok reasonable at every jump This simple

while TRUE cont cont

technology often catches a heap corruption as it hap

pens rather than millions of instructions later when

That is cont is the address of the co de blo ck that is C

it causes a crash

function to b e executed next The function to which it

p oints is called and returns the address of the next one

It is dicult to convey the imp ortance of this matter

and so on It turns out that this idea is actually very old

Finding obscure co degeneration errors has to b e done

and that we only reinvented it Like several other clever

and can b e enormously time consuming Using Clevel de

and oftreinvented ideas Steele seems to have b een its

bugging together with regular hygienechecking has made

inventor he called it the UUO handler in his Rabbit

a huge contribution to the development of the co de gen

compiler for Scheme Steele

erator

Eciency

Proling

The remaining big question is of course eciency What

price is paid for going via C If we were restricted to a

Everyone knows that it is often p ossible to make sub

completely standard C compiler the answer would cer

stantial improvements in the p erformance of a program

tainly b e considerable But by exploiting some lan

by changing only a small prop ortion of its co de The

guage extensions provided by the GNU C compiler gcc

trick of course is to know just which part of the co de to

which is available on a wide range of architectures we get

pay attention to This question can b e particularly di

2

cult to answer in a lazy functional program b ecause the

Here Miranda is not a trade mark It is the last name of a

researcher at Queen Mary and Westeld College London demanddriven evaluation mechanism leads to a rather

nonintutive execution order Until recently there have collecting young generations more often than old ones

b een essentially no proling to ols for lazy functional lan

Generational collectors b ehave badly if there are many

guages but recent work by ourselves and by Runciman

write op erations into old generations Unfortunately im

and Wakeling at York has b egun to change the situation

plementations of lazy functional languages tend to p er

Runciman and Wakelings space proling to ol displays a form lots write op erations as they up date susp ended

regular census of the contents of the heap which can often computations or thunks with their values so it lo oks as

lead directly to the discovery of a space leak Runciman if they might interact badly with generational collectors

Wakeling Perhaps as a result garbage collectors for lazy functional

languages have tended to b e a variant of the classic Baker

We have developed a related technique called cost cen

twospace collector Indeed apart from Seward

tres which enables the time consumption of the program

there is esentially no literature on generational garbage

to b e proled as well as its space consumption Sansom

collection for lazy languages

Peyton Jones Briey the idea is this The

programmer identies the expressions against which costs We have b egun investigation of a variety of garbage

should b e accumulated with a call to scc set cost cen collection technology for lazy languages including gen

tre for example the call erational schemes Some of our ndings are surprising

to us at least and we summarise them briey here to

scc sorting sort xs

give their avour Fuller details can b e found in Sansom

Peyton Jones

would attribute the costs of evaluating sort xs to the

cost centre sorting Only the costs of doing the sort

ing are so attributed in particular the costs of evaluating

 With a little care it is p ossible to build a onespace in

xs are not even though its evaluation may o ccur inter

place compacting garbage collector that is as ecient

leaved with the sorting pro cess

or b etter than a twospace collector unless the live

data is a very small fraction ab out of the heap

Furthermore al l the costs of the call to sort are so at

size A onespace collector has the big advantage that

tributed including the costs of executing calls made by

it can allow a heap almost twice as large as that of

sort to separatelycompiled library functions This ap

a twospace collector b efore the paging system starts

plies even if those library functions are also called from

to thrash

elsewhere which is esp ecially common in a p olymorphic

functional language only the cost of the calls from sort

 Most ob jects die even younger than in Lisp systems

are attributed to sorting

For example typically of ob jects die b efore

a further kbytes of heap have b een allo cated

The implementation is simple Every heapallo cated

thunk that is susp ended computation has an extra

 Similarly ob jects are also up dated young typically

eld which identies the cost centre for the computa

more than of all up dates are for ob jects which

tion which allo cated the thunk The cost centre for the

are less than kbytes old

currentlyexecuting computation is identied by a global

 A large ma jority around of all up dates are

register which is stored in each thunk as the latter is

unnecessary that is the thunk which is up dated is

constructed When a thunk is evaluated the costcentre

never again referenced This indicates substantial

register is saved and its value is set from that in the

scop e for program analyses that detect and avoid un

thunk when evaluation is complete the costcentre regis

necessary up dates

ter is restored to its previous value

 Even with the simple generational schemes we have

Prolers for lazy functional languages are in their in

implemented so far and even without considering

fancy but we regard them as extremely imp ortant for

paging eects the generational garbage collecter out

the widespread use of functional languages

p erforms b oth onespace and twospace collectors

when the live data exceeds ab out of the heap

size

Generational garbage collection

 When paging is taken into account the improved

Like all other systems for symbolic computation our

lo cality of the generational collector makes it degrade

Haskell implementation is built on top of a garbage

much more gracefully as the heap size is increased

collected heap Over the last decade generational garbage

collection has b ecome widespread in the symbolic compu

tation community Lieb erman Hewitt Gener In short contrary to p opular b elief it seems that lazy

ational collectors exploit the fact that most ob jects die functional language implementations are rather go o d sub

young by dividing the heap into several generations and jects for generational garbage collection

animalcschalmersse

Benchmarks and test suites

ftpdcsglasgowacuk

The lack of a standard language has long hindered the

nebulacsyaleedu

development of a serious b enchmark suite for lazy func

tional languages There are a number of obvious reasons

Summary successes and failures

why such a suite is desirable

What lessons have we learned from our exp erience Here

is a selection

 It encourages implementors to improve asp ects of

their compiler that give b enets to real applica

tions rather than merely improving the p erformance

 The act of building a large system has forced us into

of toy programs

addressing research issues that we could not other

wise have addressed This has resulted in a collection

of new ideas that are applicable far more widely than

 It give a concrete basis for comparing dierent im

our implementation alone unboxed values monads

plementations

use of the secondorder lambda calculus the STG

language up date analysis and so on

As part of our work we have developed the nofib b ench

mark suite Partain a collection of application

 The Haskell typeclass system caused us an enormous

programs written by p eople other than ourselves mostly

amount of extra work b eyond simple HindleyMilner

with a view to getting a particular task done The range

types and we are still far from satised with the

of applications is wide including for example a theorem

eciency of the resulting programs The compiler

prover a particleincell simulation a solid geometry ap

technology required to recover an acceptably ecient

plication and a strictness analyser Their size ranges from

implementation is very considerable

a few hundred lines of Haskell to several thousand

 We consistently underestimated how long it would

A quite separate question from that of b enchmarking is

take us to do the job largely b ecause of the scale of

that of whether a particular Haskell implementation is

the compiler Apparentlysmall changes would cause

complete or whether it correctly implements some of the

a chain of eects all of which would have to b e chased

more obscure corners of the language We have also devel

through b efore the compiler could b e rebuilt

op ed a test suite consisting of a large number of mostly

 If we were b eginning again we would almost certainly

tiny programs Every time we found a bug in the com

write a Corelanguage lint pass to check the type

piler we added a new program to the test suite that shows

consistency of Core programs Several of our more

up the bug

obscure compiler bugs turned out to b e caused by

Each night an automated system rebuilds the compiler

a Core transformation which failed to maintain type

from its source co de compiles the test suite and b ench

information prop erly

mark suite and runs the resulting programs This simple

 Our attempt to build the compiler in such a way

technology catches a large number of errors and ensures

that it can form a framework for other researchers

that no bug can b e inadvertently reintroduced

work has b een quite successful Even prior to the

This pro cess is surprisingly compute and discintensive

compilers ocial release researchers in Manchester

Every program is compiled and run with several dierent

Imp erial and Queen Mary Westeld College are

combinations of options proling enabled or not optimi

using it in just this way as well as several PhD stu

sation enabled or not and so on and we usually retain

dents at Glasgow Their work has in turn directly

the debugging symbol tables in the binaries A full run

b enetted ours For example the storage manage

takes the whole weekend for a Mbyte Sparc work

ment system the proling technology and much of

station using the whole of a lo cal Gbyte disc

the program transformation system have b een con

tributed by students

Availability

Acknowledgement

The Glasgow Haskell Compiler its proling to ols its

This pro ject could not have b een carried out without test suite and the nofib b enchmark suite are all avail

funding from SERC for the GRASP pro ject GRF able free by FTP You can use anonymous FTP user

and GRF Our partner pro ject FLARE is jointly name anonymous password your email address to

funded by DTI and SERC We b enet enormously from these hosts where you will nd things in pubhaskell

interaction with the Functional Programming Group at and its sub directories

Glasgow esp ecially John Launchbury Our gallant b eta SL Peyton Jones Apr a Implementing lazy func

site users Denis Howe Jon Hill and Julian Seward also tional languages on sto ck hardware the Spineless

deserve particular thanks Tagless Gmachine Journal of Functional Pro

gramming

References

SL Peyton Jones Autumn b UK research in func

tional programming SERC Bulletin

AW App el Compiling with continuations Cam

bridge University Press

SL Peyton Jones J Launchbury Sept Unboxed

values as rst class citizens in Functional Pro

JF Bartlett Jan SCHEME to C a p ortable

gramming Languages and Computer Architec

SchemetoC compiler DEC WRL RR

ture Boston Hughes ed LNCS Springer

Verlag

P Fradet D Le Metayer Jan Compilation

of functional languages by program transforma

SL Peyton Jones D Lester May A mo dular

tion ACM Transactions on Programming Lan

fullylazy lambda lifter in Haskell Software

guages and Systems

Practice and Exp erience

JL Hennessy DA Patterson Feb Computer Ar

SL Peyton Jones PL Wadler Jan Imp erative

chitecture A Quantitative Approach Morgan

functional programming in th ACM Symp o

Kaufman ISBN

sium on Principles of Programming Languages

Charlotte ACM

P Hudak SL Peyton Jones PL Wadler Arvind B Boutel

J Fairbairn J Fasel M Guzman K Hammond J

C Runciman D Wakeling Proling a com

Hughes T Johnsson R Kieburtz RS Nikhil W

piler in Functional Programming Glasgow

Partain J Peterson May Rep ort on the

J Launchbury ed Workshops in Comput

functional programming language Haskell Ver

ing Springer Verlag

sion SIGPLAN Notices

P Sansom SL Peyton Jones Proling Lazy Fuc

RJM Hughes July The design and implemen

tional Languages in Functional Programming

tation of programming languages PhD thesis

Glasgow J Launchbury ed Workshops in

Programming Research Group Oxford

Computing Springer Verlag

R Kelsey May Compilation by program transfor

PM Sansom SL Peyton Jones Dec Genera

mation YALEUDCSRR PhD thesis De

tions of lazy functional languages Department

partment of Computer Science Yale University

of Computing Science University of Glasgow

H Lieb erman C Hewitt June A realtime

J Seward March Generational garbage collection

garbage collector based on the lifetimes of ob

for lazy graph reduction Department of Com

jects CACM

puter Science University of Manchester

R Milner June Computer Science The Core IT

GL Steele Rabbit a compiler for Scheme AI

Research Discipline Lab for the Foundations of

TR MIT Lab for Computer Science

Computer Science Edinburgh

D Tarditi A Acharya P Lee July No assembly

E Miranda Apr How to do machineindependent

required compiling Standard ML to C School

fast threaded co de Dept of Computer Science

of Computer Science Carnegie Mellon Univer

Queen Mary and Westeld College London

sity

E Moggi June Computational lambda calculus

PL Wadler June Comprehending monads in

and monads in Logic in Computer Science Cal

Pro c ACM Conference on Lisp and Functional

ifornia IEEE

Programming Nice ACM

WD Partain The nob Benchmark Suite of

PL Wadler S Blott Jan How to make adho c

Haskell Programs in Functional Programming

p olymorphism less ad ho c in Pro c th ACM

Glasgow J Launchbury ed Workshops in

Symp osium on Principles of Programming Lan

Computing Springer Verlag

guages Austin Texas ACM