A Common Intermediate Language for ML and Haskell

Home , Standard ML

Bridging the gulf a common intermediate language for ML and Haskell

Simon Peyton Jones John Launchbury

University of Glasgow and Oregon Graduate Institute Oregon Graduate Institute

Mark Shields Andrew Tolmach

University of Glasgow and Oregon Graduate Institute Portland State University

ML compiler might well p erform a global analysis that iden Abstract

ties pure subexpressions though in practice few do How

ever one might wonder whether the analysis would discover

Compilers for ML and Haskell use intermediate languages

all the pure subexpressions in a Haskell program translated

that incorp orate deeplyemb edded assumptions ab out order

into the IL In the same way if an ML program were trans

of evaluation and side eects We prop ose an intermediate

lated into a Haskell compilers IL the latter might not dis

language into which one can compile b oth ML and Haskell

cover all the o ccasions in which a function argument was

thereby facilitating the sharing of ideas and infrastructure

guaranteed to b e already evaluated This thought motivates

and supp orting language developments that move each lan

the following question could we design a common compiler

guage in the direction of the other Achieving this goal with

intermediate language IL that would serve equal ly wel l for

out compromising the ability to compile as go o d co de as a

both strict and lazy languages The purp ose of this pap er is

more direct route turned out to b e much more subtle than

to explore the design space for just such a language

we exp ected We address this challenge using monads and

unp ointed typ es identify two alternative language designs

We restrict our attention to higher order polymorphical ly

and explore the choices they emb o dy

typed intermediate languages There is considerable interest

at the moment in typ edirected compilation for p olymorphic

languages in which typ e information is maintained accu

rately right through compilation and even on to run time

Intro duction

Harp er Morrisett Shao App el Tarditi et

al Hence we fo cus on higher order statically typ ed

Functional programmers are typically split into two camps

source languages represented in this pap er by ML Milner

the strict or callbyvalue camp and the lazy or callby

Tofte and Haskell Peterson et al

need camp As the discipline has matured though each

At rst we exp ected the design to b e relatively straight

camp has come more and more to recognise the merits of the

forward but we discovered that it was not In particular

other and to recognise the huge areas of common interest

making sure that the IL has go o d operational prop erties for

It is hard these days to nd anyone who b elieves that lazi

b oth strict and lazy languages turns out to b e rather subtle

ness is never useful or that strictness is always bad While

Identifying these subtleties is the main contribution of the

there are still p ervasive stylistic dierences b etween strict

pap er

and lazy programming it is now often p ossible to adopt lazy

evaluation at particular places in a strict language Okasaki

We employ monads to express and delimit state in

or strict evaluation at particular p oints in a lazy one

putoutput and exceptions Section Using mon

for example Haskells strictness annotations Peterson et

ads in this way is now well known to theorists Moggi

and to language designers Launchbury Pey

This rappro chement has not yet however propagated to

ton Jones Peyton Jones Wadler

1 our implementations The insides of an ML compiler lo ok

Wadler a but with one exception no compiler

p ervasively dierent to those of a Haskell compiler Notably

that we know has monads built into its intermediate

sequencing and supp ort for side eects and exceptions are

language

usually implicit in an ML compilers intermediate language

We employ unpointed types to express the idea that

IL but explicit where they o ccur in a Haskell compiler

an expression cannot diverge Section We show

Launchbury Peyton Jones On the other hand

that the straightforward use of unp ointed typ es do es

thunk formation and forcing are implicit in a Haskell com

not lead to a go o d implementation Section This

pilers intermediate language but explicit in an ML com

leads us to explore two distinct language designs The

piler These p ervasive dierences make it imp ossible to

rst L is mathematically simple but cannot b e com

share co de and hard to share results and analyses b etween

piled well Section An alternative design L adds

the two styles

op erational signicance to unp ointed typ es by guar

To say that supp ort for side eects are implicit in an ML

anteeing that a variable of unp ointed typ e is evaluated

compilers IL for example is not to say that an ML com

Section this means L can b e compiled well but

piler will take no notice of side eects on the contrary an

weakens its theory

We identify an interaction b etween unp ointed typ es

p olymorphism and recursion in L Section In

To app ear in the ACM Symp osium on Principles of

terestingly the problem turns out to b e more easily

Programming Languages POPL

solved in L than L Section

2 1

Personal communication Nick Benton Persimmon IT Ltd

None of these ingredients are new Our contribution is to ex a less ecient basic evaluation mo del esp ecially when

plore the interactions of mixing them together We emerge starting from ML Indeed our hop e is that we may

with the core of a practical IL that has something to oer ultimately b e able to generate better co de through this

b oth the strict and lazy community in isolation as well as new route

oering them a common framework Our longterm goal is

to establish an intermediate language that will enable the

two communities to share b oth ideas analyses transforma

L a totally explicit language

tions and systems optimisers co de generators runtime

systems prolers etc more eectively than hitherto

It is clear that the IL must b e explicit ab out things that are

implicit in traditional compiler ILs Where are these im

plicit asp ects of a traditional IL currently made explicit

The ground rules

Answer in the denotational semantics of the IL For ex

ample the denotational semantics of a callbyvalue lamb da

We seek an intermediate language IL with the following

calculus lo oks something like this

prop erties

E e e E e b if a b

1 2 1

if a

It must be possible to translate both core ML and

where a E e

Haskel l into the IL Extensions that add laziness to

ML or strictness to Haskell should b e readily incor

Here the two cases in the righthand side deal with the p os

p orated We make no attempt to treat MLs mo dule

sible nontermination of the argument What is implicit in

system though that would b e a desirable extension

the IL the evaluation of the argument in this case b e

comes explicit in the semantics An obvious suggestion is

In order to accommo date ML and Haskell the ILs

therefore to make the IL reect the denotational semantics

type system must support polymorphism This ground

of the source language directly so that everything is explicit

rule turns out to have very signicant and rather

in the IL and nothing remains to b e explicated by the se

unfortunate impact up on our language designs Sec

mantics This is our rst design L

tion but it seems quite essential Nearly all exist

ing compilers generate p olymorphic target co de and

Figure gives the syntax and typ e rules for L We note

although researchers have exp erimented with compil

the following features

ing away p olymorphism by typ e sp ecialisation Jones

Tolmach Oliva problems with sepa

As a compromise in the interest of brevity all our

rate compilation and p otential co de explosion remain

formal material describ es only a simplytyp ed calcu

unresolved

lus although supp orting p olymorphism is one of our

The IL should be explicitly typed Harper Mitchel l

ground rules The extensions to add p olymorphism

We have in mind a variant of System F Gi

complete with explicit typ e abstractions and applica

rard with its explicit typ e abstractions and

tions in the term language are fairly standard Harp er

applications The expressiveness of System F really

Mitchell Peyton Jones Tarditi et al

is required For example there are several reasons

However p olymorphism adds some extra com

for wanting p olymorphic arguments to functions the

plications Section

translation of Haskell typ e classes creates dictionar

We omit recursive data typ es constructors and case

ies with p olymorphic comp onents we would like to b e

expressions for the sake of simplicity b eing content

able to simulate mo dules using records Jones

with pairs and selectors

rank p olymorphism is required to express encap

sulated state Launchbury Peyton Jones

let is simply very convenient syntactic sugar It is not

and datastructure fusion Gill Launchbury Pey

there to intro duce p olymorphism even in the p olymor

ton Jones

phic extension of the language explicit typing removes

IL programs can readily b e typ echecked but there

this motivation for let

is no requirement that one could infer typ es from a

letrec intro duces recursion Though we only give it

typ eerased IL program

one binding here our intention is that it should ac

The IL should have a single wel ldened semantics On

commo date multiple bindings We use it rather than

the face of it compilers for b oth strict and lazy lan

a constant fix b ecause the latter requires heavy en

guages already use a common language namely the

co ding for mutual recursion that is not reected in

lamb da calculus But this similarity is only at the

an implementation We discuss recursion in detail in

level of syntax the semantics of the two calculi dier

Section including the unsp ecied side condition

considerably In particular the co de generator from

mentioned in the rule

a strictlanguage compiler would b e completely unus

Following Moggi we express computational ef

able in a lazylanguage compiler and vice versa Our

fects such as nontermination assignment excep

goal is to have a single neutral semantics and hence

tions and inputoutput in monadic form The typ e

a single optimiser and co de generator

M is the typ e of M computations returning a value

ML or Haskel l programs thus compiled should be

of typ e where M is drawn from a xed family of

as ecient as those compiled by a good ML resp

monads The syntactic forms let and ret are

M M

Haskel l compiler In other words compiling through

We use the following standard notation If T is a complete partial

the common IL should not imp ose any unavoidable e

order CPO then the CPO T pronounced T lifted is dened

ciency p enalty either by way of loss of transformations

thus T fa j a T g fg with the obvious ordering

? ?

esp ecially when starting from Haskell or by way of

T y pes Int j j j T T y pe CPO

1 2 1 2

j Ref j M T Int Z

T T T

1 2 1 2

T er ms e x j k j e e j x e j e e T T T

1 2 1 2 1 2 1 2

j let x e in e T

1 2

j letrec x e in e T Lift T

1 2

j let x e in e j ret e T ST State T State

M 1 2 M

T Ref N

C onstants k fst j snd j new j rd j wr j liftToST

T State N

j j j j j j j

M onads M Lift j ST

E T er m E nv T

E x x

E k k

E e e E e E e

1 2 1 2

V AR

E xe y E ex y

E e e E e E e

1 2 1 2

E let x e in e E e x E e

e e

1 2 2 1

1 1 2 2

P AI R

E letrec x e in e E e r ecx e

e e

1 2 2 1

1 2 1 2

E let x e in e bind E e

M 1 2 M 1

y E e x y

e e

1 2

AP P

E ret e unit E e

M M

e e

1 2

0 0

r ecx e f ix x E e

x e 1 1

LAM

x e

fst a b a

snd a b b

e x e

1 2

LE T

let x e in e

1 2

bind m k if m

Lif t

k a if m a

x e x e

1 2

unit x x

Lif t ?

plus a side condition

REC

letrec x e in e

1 2

bind m k s if m s

0 0

k r s if m s r s

e M x e M

1 1 1 2 2

LE T M

unit m s m s

let x e in e M

M 1 1 2 2

new v s r sr v where r doms

rd r s s r s if r doms

RET

otherwise

ret e M

wr r v s sr v if r doms

otherwise

FST fst

1 2 1

liftToST m s r s if m r

? ?

SND snd

1 2 2

otherwise

P LU S Int Int Int

NEW new ST Ref

RD rd Ref ST

Figure Semantics of L

WR wr Ref ST

LI F T liftToST Lift ST

unlifted pro duct and integers are interpreted by the inte

gers If L were expanded to have sum typ es they would

b e interpreted by categorical separated sums Lastly

Figure Syntax and typ e rules for L

each monad is sp ecied by an interpretation The monad

of lifting is interpreted by lifting while a state transformer

is interpreted by a function from the current state to a

the bind and unit combinators of the monad M The

result and the new state The state is a nite mapping

only two monads we consider for now are the lifting

from lo cation identiers mo deled by the natural numb ers

monad Lift and the combination of lifting with the

N to their contents

state transformer monad ST It is a straightforward

extension to include the monads of exceptions and in

The semantic function E gives the meaning of expressions

putoutput as well

Again many of its equations are rather dull application

is interpreted by application in the underlying category

This use of monads app ears to contradict our goal that

lamb da abstraction by functional abstraction and so on

L should have a trivial semantics We discuss the

The semantics of the two monads is given by their bind and

reasons for this decision in Section

unit functions From the semantics one can prove that b oth

and are valid with resp ect to the semantics and that

Figure gives the semantics of L The semantic function

monadic expressions admit a numb er of standard transfor

T gives the meaning of typ es If it lo oks somewhat b oring

mations given in Figure

that is the p oint The function arrow in L is interpreted by

function arrow in the underlying category of complete par

tial orders CPO pro duct is interpreted by categorical ie

M let x ret e in b let x e in b

M M

M let x let y e in e in b let y e in let x e in b y f v b

M M 1 2 M 1 M 2

M let x let y e in e in b let y e in let x e in b y f v b

M 1 2 1 M 2

M let x letrec y e in e in b letrec y e in let x e in b y f v b

M 1 2 1 M 2

M let x e in ret x e

M M

M let x e in ret b ret let x e in b

M M

Figure Monad transformations

Termination and nontermination

Typ es S T Int j j S T j S T j Ref S

As we have mentioned the interpretation of a typ e in L

Haskel l only j ST S

is a complete partial order CPO However the interpreta

tion of a typ e is not necessarily a pointed CPO that is the

Terms M N x j i j M N j x T M j M N

CPO do es not necessarily contain a b ottom element For

j letrec x T M in N

example the data typ e of integers Int is interpreted by

j let x T M in N

the unpointed CPO of integers Z That is if an expression

j pair M N j fst M j snd M

has typ e Int then it denotes an integer and cannot denote

j new M j rd M j wr M N

a nonterminating computation How then do we express

Haskel l only j let x T M in N j ret M

ST ST

the typ e of p ossiblydiverging integervalued computations

As we have seen L has an explicit typ e constructor for

Integers i j j j

each monadic ie computation typ e of which lifting is

one To express the typ e of a p ossiblydiverging integer we

use the lifting monad A p ossiblydiverging integervalued

ML constants

expression therefore has typ e Lift Int

new Ref

rd Ref

So L s typ e system can distinguish surelyterminating ex

wr Ref

pressions from p ossiblydiverging ones The main reason

for making this distinction in the type system is so that we

can express the idea that a function takes an evaluated argu

Haskell constants

ment The L lamb da abstraction xInt e expresses that

new ST Ref

x cannot p ossibly b e and so is a suitable translation of a

rd Ref ST

lamb da abstraction from a callbyvalue language On the

wr Ref ST

other hand xLift Int e expresses that x might p erhaps

b e which ts a callbyname or callbyneed language

A second motivation for distinguishing p ointed typ es from

Figure Syntax of S

unp ointed ones is that some useful program transforma

tions that are not valid in general hold unconditionally

when one has more control over p ointedness Several re

community has b een using monads very eectively to isolate

searchers have explored languages that employ a distinc

and encapsulate stateful computations and inputoutput

tion b etween p ointed and unp ointed typ es Howard

within pure lazy programs Launchbury Peyton Jones

Launchbury Paterson and others have explored

Peyton Jones Gordon Finne Peyton Jones

pure languages without p ointed typ es altogether Co ckett

Wadler Wadler b Nevertheless there are

Fukushima Hagino Turner The

surprisingly subtle design choices to make as we discuss in

presence of unp ointed typ es has consequences for recursion

Section

as we discuss in Section

Translating ML and Haskell into L

Stateful computations

Before discussing its design any further we rst emphasise

In a similar way we use the ST monad to express in the typ e

L s role as a target for b oth strict stateful and pure lazy

system the distinction b etween pure and stateful computa

languages by giving translations from b oth into L Figure

tions For example an expression of typ e Lift Int denotes

gives the syntax of a tiny generic source language S We

a pure sideeect free alb eit p ossiblydivergent computa

regard S as a prototyp e for either ML or Haskell by giving

tion on the other hand and expression of typ e ST Int de

it a strict or lazy interpretation resp ectively In either case

notes a computation that might diverge or might p erform

S is assumed to have b een explicitly annotated with typ e

some side eects on a global state and deliver an integer

information by a typ e inference pass

Further monads can readily b e added to mo del exceptions

or continuations or inputoutput

The constants pair fst snd have the same obvious S

typ es in b oth interpretations The constants new rd wr

This use of monads is well known Moggi pioneered the

create read and write a mutable variable Unlike pair

idea of using monads to encapsulate computations Moggi

their typ es dier in the two interpretations as Figure

Wadler a The lazy functional programming

shows In the lazy interpretation their typ es explicitly in

ST combines lifting with state It would b e p ossible to separate

volve the sourcelanguage ST monad and S also includes

the two as we discuss in Section

lated by M is a computation in the ST monad and

functions also return computations in ST That is if

MInt Int

the ML typ e system considers that e then

MS T MS MT

M Me ST M

MS T MS ST MT

The rule for application uses let to evaluate b oth

MRef S Ref MS

the function and its argument and to sequence any

state changes they contain b efore applying the func

Mx ret x

tion to the argument In expressions pro duced by

Mi ret i

the M translation each variable is b ound to a non

MM N let f MM in

monadic typ e that is any eects state or non

let a MN in

termination are p erformed b efore binding the vari

f a

able When a variable lamb da or pair is translated

Mx T M ret xMT MM

we simply return the value using ret Lastly a re

Mlet x T M in N

cursive ML declaration can only bind a function hence

let xMT MM in MN

the rule for letrec

Mletrec f S T x SM in N

The Haskell translation H gives the source lan

letrec f MS T xMS MM in MN

guage minus the statechanging op erations a pure

Mpair M N let a MM in

nonstrict semantics A key dierence from the ML

let b MN in

translation is that the Haskell translation of data

ret ab

typ es such as integers pairs and lists are lifted b e

and similarly wr

cause Haskell allows values of these typ es to b e recur

Mfst M let a MM in

sively dened Unlike the ML translation the transla

ret fst a

tion of Haskells function typ e do es not need to have

and similarly snd new rd

an explicit Lift on the co domain Nor do es the trans

lation H necessarily return a Lift computation if the

Haskell typ e system concludes that e then

H He H

HInt Lift Int

HS T Lift HS HT

H translates Haskells STmonad computations di

H Lift

rectly into L s ST monad just as you would hop e

HS T HS HT

The only tiresome p oint is that the rst argument of

HST T ST HT

wr has sourcelanguage typ e Ref and hence has

HRef S Lift Ref HS

L typ e Lift Ref H It must therefore b e lifted

into the ST monad using liftToST so that it can b e

Hx x

evaluated in the ST monad

Hi ret i

Lift

HM N HM HN

It is interesting to compare the two typ e translations M

Hx T M xHT HM

uses exactly the callbyvalue translation of Wadler a

Hlet x T M in N let xHT HM in HN

with the computational eect at the end of the function

Hletrec x T M in N

arrow On the other hand H do es not use Wadlers callby

letrec xHT HM in HN

name translation as one might otherwise exp ect Indeed

Hpair M N ret HM HN

Lift

there is no monadic eect in the translation of function typ es

HM N let a HM in

Lift

at all instead the Lift monad shows up in the translation

let b HN in

Lift

of data typ es

ret a b

Lift

This translation of Haskell function typ es assumes that

Hfst M let a HM in fst a

Lift

xbot and bot where bot has value denote the same

similarly snd

value in Haskell Recent changes to Haskell are likely to al

Hwr M N let a liftToST HM in

low these values to b e distinguished forcing a lifting of func

wr a HN

tion typ es and hence a more gruesome enco ding of function

similarly new rd

application

Hlet x T M in N

let xHT HM in HN

Hret M ret HM

Why not enco de the monads

We have said that L is meant to make everything explicit

Figure Translations of ML and Haskell into L

so that there is nothing to b e said when giving its semantics

In apparent contradiction we made the semantics of the

monads implicit that is explained only by the semantics

let and ret the unit and bind op erations for ST Mo d

ST ST

of L Why for example did we not make the ST monad

ulo syntax this is precisely how Haskell expresses stateful

explicit by representing a value of typ e ST as a state

computation Launchbury Peyton Jones

transforming function in L and representing let and

Then Figure gives two translations of S into L

redexes a slightly more complex translation can avoid them Sabry

Wadler

The ML translation M gives the source language

We do not treat the runST encapsulator of Launchbury Pey

a stateful strict semantics The result of a term trans

ton Jones here but it is easy to do so

The translation given here intro duces quite a few administrative

ret using the other L forms For example instead of

the L term

Lift p ointed

let x e in b

we could write the L term

ST p ointed

bindST e xb

p ointed

where bindST is dened directly in L as follows

p ointed

2 1

bindST m k slet p m s in k fst p snd p

p ointed p ointed

1 2

p ointed

1 2

Here the state passing is made explicit but the state itself

is still abstract supp orting the new read and write op er

ations This is the approach advo cated by Launchbury

Figure Rules for p ointed typ es

Peyton Jones Section It has the notable advantage

that we can simplify L by getting rid of let and ret

1 M M

entirely

letrec can b e constructed at any typ e But that is not so

We do not adopt that approach here for three reasons

Consider

letrec xInt x in

Enco ding the monad in purely functional terms is a

Such a recursive denition is plainly nonsense b ecause Int

reasonable way of giving its semantics but it may not

is an unp ointed typ e and has no b ottom element so there

b e a reasonable way of giving its implementation Con

might b e no solution or many solutions to the recursive

sider for example the monad of exceptions in a strict

denition We can only do recursion over pointed CPOs

language The functional enco ding would p erform a

conditional test whenever a p ossiblyexceptional value

How then can we make sense of recursion One solution

was b ound but the exp ected implementation is stack

is to link recursion to the Lift monad since Lift adds a

based with no tests Instead a whole chunk of stack

b ottom to its argument domain

is p opp ed when an exception is raised Keeping the

monad explicit in L allows the co de generator to gen

x Lift e Lift x Lift e

1 2

R E C a

erate ecient co de

letrec x e in e

1 2

Even where an ecient co degeneration strategy do es

This solution is not very satisfactory For a start it cannot

exist its correctness may b e fragile For exam

typ e

ple Launchbury Peyton Jones describ es an

letrec f x in

up dateinplace implementation of the primitive op

b ecause the typ e of a lamb da abstraction has the form

erations read and write in the state monad How

not Lift and lifting all functions raises the sp ec

ever that implementation is only correct if the state

tre of having to force the denition on each recursive call

is singlethreaded That is certainly the case in the

Nor can it typ e recursive denitions of ST computations

terms pro duced by M but it might not remain the

Furthermore this loss of expressiveness is completely un

case after performing L transformations For exam

necessary since a function typ e whose result typ e is p ointed

ple a expansion might duplicate the state

is itself p ointed and any ST computation is p ointed The

It may b e p ossible to preserve the singlethreadedness

right solution is to x REC by adding a side condition that

of the state by limiting the transformations p erformed

must b e p ointed

on the L program For example we b elieve that

using only transformations that are correct in a call by

x e

need calculus is sucient Sabry Even where

x e

R E C b

this is true it creates a complicated pro of obligation

p ointed

letrec x e in e

1 2

There may b e useful transformations available that are

sp ecic to a particular monad for example swapping

Figure gives rules for determining when a typ e is p ointed

the order of noninterfering assignments but which

Unfortunately the extension to a p olymorphic typ e system

b ecome inaccessible or hard to sp ot when expressed

is problematic is the type pointed or not There are three

in a purelyfunctional enco ding of the monad

p ossible choices

We nd these reasons comp elling On the other hand we

We could decide that typ e variables can only range

were concerned that by not translating the monadic co de

over p ointed typ es This is precisely the restriction

into a core of L we might lose valuable transformations So

prop osed by Peyton Jones Launchbury but

far however we have found no transformation that cannot

it is unacceptable in our IL b ecause we exp ect the

b e expressed in the monadic version of L providing the

translations of most ML data typ es to b e unp ointed

standard monad laws are implemented Figure

For example an ordinary nonrecursive p olymorphic

function such as the identity function could not b e

applied to b oth and ret b ecause one has a

Lift

Recursion in L

lifted typ e and one do es not

There is a substantial literature on the categorical treatment of

One consequence of our decision to allow a typ e to b e mo d

recursion for example Pitts but the discussion of this section

eled by an unp ointed CPO is that we have to take care

fo cuses on the sp ecic setting of CPO

with recursion The rule REC in Figure suggests that a

We could allow typ e variables to range over all typ es We regard these complications as a very serious and far

but prohibit recursion at a typ e variable This would from obvious ob jection to using L for op erational pur

irritatingly reject recursive functions whose result typ e p oses

is a typ e variable such as the function nth that selects

the nth element from a list

Summary

nth Int List

We exp ected it to b e a routine matter to translate b oth

Alternatively we could employ qualied universal

Haskell and ML into a common language built directly on

quantication where typ e variables at which xp oints

top of the standard mathematics for programminglanguage

are taken are explicitly qualied

semantics To our surprise it was not as Sections

nth Pointed Int List

describ e

L may still b e quite useful as a kernel language for rea

Launchbury Paterson elab orate on this idea

soning ab out programs However as Section has shown

it is unsuitable as a compiler intermediate language Thus

Since the rst two choices are untenable we conclude that

motivated we now turn our attention to a second design

adding p olymorphism to a language with b oth recursion and

that is more suitable as an IL

unp ointed typ es requires the use of qualied universal quan

tication

L a language of partial functions

Controlling evaluation in L

Our second design starts from the problem we describ ed in

While L seems to b e quite suitable from a theoretical p oint

Section Op erationally it is essential to b e able to con

of view it suers from a serious practical drawback L is

trol exactly when evaluation takes place so that the recipi

vague ab out the timing and degree of evaluation Consider

ent of a value knows for sure whether or not it is evaluated

the L expression

Since we want to control what evaluation is done when the

let x e in f x

obvious thing to do is to make let and of course function

application eager That is to evaluate let x e in b

What co de should the co de generator pro duce for such an

one evaluates e binds it to x and then evaluates b We

expression

use the operational term eager rather than the semantic

term strict b ecause the latter do es not mean anything if

An ML compiler writer would probably exp ect the

the typ e of e has no b ottom element How then are we to

co de to evaluate the righthand side of the let and

translate the let s and function applications of a lazy lan

then call f passing the value thus computed But this

guage There is a standard way to do so namely by making

eager strategy is incorrect in general if e diverges and

the construction and forcing of thunks explicit Friedman

f do es not evaluate its argument as a quick glance at

Wise This is what we do in L

Figure will conrm

Figure gives the syntax and extra typ e rules for L There

A safe strategy is to build a thunk susp ension for

is now only one monad ST the Lift monad is now implicit

the righthand side bind x to this thunk and call f

in the semantics of L so that let and function application

passing the thunk to it That is precisely what the

can b e eager There is a new syntactic form e that sus

co de generator for a lazy language would do

p ends the evaluation of e and a new constant force that

forces the susp ension returned by its argument There is

Now supp ose that we are compiling co de for f and that

one new typ e which is the typ e of e if e has typ e

f has typ e Int Int The ma jor motivation for distin

The two new typ e rules D E LAY and FORCE are just

guishing Int from Lift Int was to allow the compiler to

as you would exp ect

treat values of typ e Int as certainlyevaluated just as a

Another new feature is that typ es are divided into value

strictlanguage compiler would assume Section It is

types and computation types Intuitively an expression

unacceptable for f to test whether its argument is evaluated

has a computation typ e while a variable is always b ound to

such a choice would guarantee that no ML compiler would

a value typ e Another way to say this is that the typing

use this intermediate language Alas the safe strategy for

judgement now has the form

preparing the fs argument do es indeed pass an unevaluated

thunk so f must b e prepared for this eventuality

fx x g e

1 1 n n

Can we instead use a hybrid strategy

The typ e rules of Figure apply unchanged b ecause we

A hybrid strategy for compiling let expressions might carefully used and in the right places although they were

use the typ e of the b ound variable to decide what to synonymous in L Function arguments and the righthand

do for typ es whose values are sure to converge such sides of letrec expressions all have value typ es and are

as Int it can evaluate the righthand side eagerly oth evaluated eagerly This separation of value typ es from com

erwise it can build a thunk This strategy works for putation typ es neatly nesses the awkward question of what

a simplytyp ed language but fails again when we it means to evaluate an argument computation without

intro duce p olymorphism What is the co de generator also p erforming it which caused us some heartsearching

to do with a let that binds a value of typ e Either in earlier unstratied versions of L For example the ex

the instantiating typ e must b e passed as an argument pression f read r is illtyp ed and hence we do not

or we must have two versions of the co de one for ter have to evaluate read r without also p erforming its state

minating typ es and one for p ossiblydiverging ones changes Indeed expressions of typ e ST can only o ccur as

is that L s function typ e arrow is now interpreted as the

CPO of partial functions denoted and the semantic

Computation types M j

evaluation function E takes an expression to a partial func

Value types Int j j j

1 2

tion from environments to values Many of the equations

j j Ref

are dened conditionally For example the equation for

E e e says that if b oth E e and E e are dened

1 2 1 2

T er ms e x j k j e e j xe j e e j e

1 2 1 2

then the result is just the application of those two values

j let x e in e

1 2

otherwise there is no equation that applies for E e e so

1 2

j letrec x pv in e

it to o is undened

j let x e in e j ret e

M 1 2 M

The typ e constructor is mo deled using lifting the se

mantics of force and move to and fro b etween lifted

C onstants k j force

CPOs and partial functions It may seem o dd that we use

M onads M ST

two dierent notations Lift in L and in L with

1 2

V al ues v x j k j x e j e j v v

1 2

the same underlying semantic mo del namely lifting The

P V al ues pv x e j e

reason is that in L we use lifting as a monad with a bind

op eration for example whereas in L we use it to mo del

thunks with a force op eration but no bind

The entire semantics of L could instead b e presented in the

The typ e rules from Figure plus

CPO of total functions using the isomorphism

D E LAY

S T S T

Which to cho ose is just a matter of taste What we like

FORCE force

ab out our presentation is that each L typ e constructor cor

resp onds directly to a single categorical typ e constructor

whereas in the alternative presentation the L function typ e

gets a more enco ded translation Launchbury Baraki

Figure Extra syntax and typ e rules for L

use partial functions in essentially the same way

The translation of ML into L is exactly the same as the

translation of L The translation of Haskell is dier

The translation M from ML to L

ent however b ecause we now have to b e explicit ab out the

is textually the same as in Figure

intro duction of thunks Figure Concerning typ es no

tice the use of the typ e constructor on the arguments

HInt Int

of functions and data constructors Concerning terms the

HS T HS HT

thunkformer is used for function arguments and the

righthand side of all let and letrec denitions Thunks

HS T HS HT

are evaluated explicitly using force when returning a vari

HST T ST HT

able or the result of fst or snd

HRef S Ref HS

Hx force x

Controlling evaluation in L

Hi i

HM N HM HN

Hx T M xHT HM The main b enet of using L is that its semantics p ermit

Hlet x T M in N let xHT HM in an eager interpretation of vanilla let namely evaluate the

HN righthand side bind the value to the variable and then

Hletrec x T M in N letrec xHT HM evaluate the b o dy A consequence is that any variable of

in HN type other than or a type variable which might be in

Hfst M force fst HM stantiated to is sure to be ful ly evaluated just as in

Hpair M N HM HN any ML implementation

HM N HM HN

Hwr M N wr HM HN

similarly new rd

Recursion in L

Hlet x T M in N let xHT HM

in HN

Another advantage of L is that we can solve our earlier

Hret M ret HM

diculties with recursion Section without requiring

b ounded quantication

Firstly we more or less have to restrict letrec s to bind

Figure Translations of ML and Haskell into L

only syntactic values b ecause we cannot eagerly evaluate

the righthand side Why not Because we cannot con

struct the environment in which to evaluate it That in

the right hand side of a let the b o dy of a function or

turn means that the meaning of the righthand side is al

as the value of the whole program Finally when p olymor

ways dened which is why there is no side condition in the

phism is intro duced typ e variables range over value typ es

semantics of letrec

only

But Figure further restricts the righthand side of a letrec

Figure gives the semantics of L in full The crucial p oint

to b e a particular sort of syntactic value a pointed value or

T T y pe CPO

T Int Z

T T T

1 2 1 2

T T T

1 2 1 2

T ST State T State

T Ref N

E T er m E nv T

E x x

E k k

E e e E e E e if E e and E e are dened

1 2 1 2 1 2

E xe y E ex y

E e e E e E e if E e and E e are dened

1 2 1 2 1 2

E let x e in e E e x E e if E e is dened

1 2 2 1 1

0 0

E letrec x pv in e E e f ix x E pv

E let x e in e bind E e y E e x y if E e is dened

M 1 2 M 1 2 1

E ret e unit E e if E e is dened

M M

E e E e if E e is dened

otherwise

fst a b a

snd a b b

f or ce a a

0 0

bind m k s k r s if m s r s

unit m s m s

new v s r sr v where r doms

rd r s s r s if r doms

wr r v s sr v if r doms

Figure Semantics of L

PV al ue The syntactic category of P V al ues is chosen so computations in ST must b e maintained whereas let bind

that it can only denote a value from a p ointed domain and ings can b e reordered freely Changing the order of evalua

hence a letrec denition always has a least xp oint To see tion is fundamental to several useful transformations in

this consider the forms that a PV al ue can take cluding common subexpression lo op invariant computa

tions all kinds of co de motion Peyton Jones Partain

Santos inlining and strictness analysis rememb er

A lamb da abstraction denotes a partial function and

we may b e compiling a lazy language into L To take a

the CPO of partial functions is always p ointed its least

simple example the following transformation is not in gen

element is the everywhere undened function

eral valid for let but is valid for vanilla let assuming

A thunk e where e is drawn from the p ointed

there are no name clashes

CPO T

let x e in let x e in b

1 1 2 2

Fortunately the syntactic restriction of letrec do es not lose

let x e in let x e in b

2 2 1 1

any useful expressiveness ML insists that letrec s bind only

functions which are PV al ues while Haskell binds thunks

Of course one could do an eects analysis to determine

which are also PV al ues So there is no diculty with

which subexpressions were pure as go o d ML compilers do

translating the recursion arising in b oth ML and Haskell

but that is eectively just what the monadic typ e system

into L

records

Why not have just one monad

Assessment

Now that we have eliminated the Lift monad and made

vanilla let eager there is another question we should ask

L vs L

why not give vanilla let the semantics of let and elimi

nate the latter altogether To put it another way we have

What have we lost in the transition from L to L apart

1 2

made eager evaluation implicit in the semantics of let why

from a somewhat more complicated semantics One loss is

not add implicit side eects as well After all the co de gen

L s ability to describ e typ es whose values are sure to termi

erated for let x e in b will b e something like the co de

nate If a L function has typ e IntInt then a call to the

for e followed by the co de for b and that is just the same

function cannot diverge but the same is not true of L This

as the co de we now exp ect to generate for let x e in b

do es not have much impact on a compiler but it make pro

grammer reasoning ab out L programs more complicated

However if we have just one form of let we lose valuable

optimising transformations In particular the sequence of

Another imp ortant dierence is that L has a weaker rule pression to simplify to

L has full conversion That is for any expressions e and

f ret x let a x in

let a fst a in

let x e in b bex

ret fst a

A similar rule holds for application of course In L how

ever do es not hold in general A particular case of this is

Now the ret can b e oated outwards to give

that if x is not mentioned in b then in L the binding can

b e discarded in L the binding can only b e discarded if the

f ret xret fst fst x

ST ST

righthand side is a value

In this form the inner ret makes it apparent that f has

However a restricted version form of that allows

no side eects We have in eect p erformed a sort of incre

only values to b e substituted is valid in L Values are

mental eects analysis The same idea can b e taken further

dened in Figure and include variables constants and

If f is inlined at its call sites then the ret may cancel

lamb da abstractions as usual However values also include

with let there and so on Even if fs b o dy is big we

thunks Hence any Haskel l reduction has a corresponding

can use the workerwrapp er technique of Peyton Jones

reduction in its L translation Thus the restriction to

V 2

Launchbury to split f into a small inlinable wrapper

will not prevent a Haskell compiler from doing anything

and a large noninlinable worker fw thus

it can do in an implicitly lazy language with a full rule

f ret xret fw x

Thus far we have assumed a callbyname semantics in

ST ST

fw x body of f

which we are content to duplicate arbitrary amounts of work

provided we do not change the overall result In practice no

Blume App el describ e a similar technique that they

compiler would b e so lib eral we desire a callbyneed se

call lamb dasplitting

mantics in which work is not duplicated As Ariola et al

describ es we can give a callbyneed semantics to

The p oint of all this is that there is a real payo for an

L by weakening to and adding a garbagecollection

1 V

ML compiler from making the ST monad explicit Easy in

rule that allows an unused let binding to b e discarded An

cremental transformations p erform a lo cal eects analysis

analogous result holds in L we can obtain callbyneed se

at each stage the state of the analysis is recorded in the

mantics by replacing e by v in the denition of values

program itself rather than in some ad hoc auxiliary data

in Figure

structures and all other program transformations will au

tomatically preserve or exploit the analysis

L vs Haskell and ML ILs

Parametricity

Our main theme is the search for an IL that can serve for

b oth ML and Haskelllike languages However we b elieve

Polymorphic functions have certain parametricity prop erties

that a language like L is attractive in its own right to either

that may b e derived purely from their typ es Mitchell

community in isolation b ecause one might get b etter co de

Meyer Reynolds Wadler For example

from an L based compiler

in the pure p olymorphic lamb da calculus a function f with

typ e satises the theorem

For the Haskell compiler writer L oers the ability to ex

press in its typ e that a value is certainly evaluated This

A B h A B x y A h f x y f h x h y

gives a nice way to express the results of strictness analysis

a function argument of unp ointed typ e must b e passed by

In fact f satises something even stronger in which the

value Flat arrays and strict data structures also b ecome

function h can b e an arbitrary relation b etween A and B

expressible

When we add p olymorphic constants to the pure calculus

For the ML compiler writer L oers the ability to express

the eect is that the choice of functions h b ecomes restricted

the fact that a computation is free from side eects which

For example adding a x p oint op erator x

is a precondition for a raft of useful transformations Sec

forces the restriction that the h functions b e strict map

tion While this information can b e gleaned from an

to and inductive ie continuous This is the situation

eects analysis maintaining this information for every sub

in Haskell for example

expression across substantial program transformations is

not easy In L however lo cal transformations can p er

Adding p olymorphic sequencing say through an op erator

form and record the results of a simple incremental eects

seq or by building it into the seman

analysis For example consider the following ML function

tics of function application forces the restriction that the

h functions b e b ottomreecting ie dened on all dened

fun f x fst fst x

arguments This is the basic situation in pure ML

If we translate this into L we obtain

Adding p olymorphic equality forces the h functions to b e

at least onetoone and adding p olymorphic state op era

f ret x let a let a ret x in

ST ST ST ST

tions like r seems to remove any last shreds of interesting

ret fst a

parametricity

ret fst a

What then are the parametricity prop erties of L and L

1 2

If parametricity prop erties are weakened by claiming various

Simple application of the rules of Figure allows this ex

primitives to b e more p olymorphic than they really are then

by b eing more cautious in the typ es we assign them we may

hop e to restrengthen parametricity

In L for example recursion is only done either at a func ML thunks

tion typ e or at a susp ension typ e Recursion is never p er

mitted as a fully p olymorphic typ e unlike in Haskell This

One of the advantages of a language that supp orts b oth

has the eect of allowing the strictness side condition to

strict and lazy evaluation is that it can accommo date source

b e dropp ed though inductiveness or continuity is still re

languages that have such a mixture Indeed it is quite

quired The same is achieved in L through the use of the

straightforward to map Haskells strictness annotations Pe

pointed restriction see Launchbury Paterson for a

terson et al onto L Coming from the other direc

comparable situation Furthermore since all state op era

tion it has long b een known that thunks can b e enco ded

tions are explicitly typ ed within the state monad they also

explicitly in a strict imp erative language For the sake of

do not interfere with parametricity in a negative way

concreteness we use the notation prop osed for ML in Okasaki

In this prop osal delayed ML expressions are prexed

The main dierence b etween L and L is to do with forcing

1 2

by a thus

evaluation L has no p olymorphic forcing op eration so has

no consequent weakening of its parametricity prop erty L

let val x f y in b end

do es however it is built into its eager function applica

Here assuming f y has typ e int x is b ound to a thunk

tion Thus for L the parametricity theorem demands the

of typ e int susp that when forced evaluates f y and

h functions to b e everywhere dened

overwrites the thunk with its value

To see an example of this consider the function K

We exp ected that these ML thunks would map directly

which selects its rst argument discarding

onto L s thunks but that turned out not to b e the case

its second The parametricity theorem is

The semantics of ML thunks is considerably more compli

0 0 0 0

cated than that of L s thunks b ecause of the interaction

A A B B h A A h B B x A y B

1 2

with state Consider the following ML expression

h K x y K h x h y

1 1 2

let val rec x let val y r in

Clearly this holds only if h is total dened everywhere

otherwise the right hand side may not b e dened when the

if y then

left hand side is

else force x force x

end

There is a practical implication to this A class of techniques

in end

for removing intermediate lists called foldrbuild relies on

parametricity for its correctness Gill Launchbury Pey

This denes x recursively which is not p ossible in ML but

ton Jones While a strictness side condition is not

essentially the same thing can b e done using another refer

damaging a totality condition is to o restrictive The tech

ence to tie the knot We use the recursive form to reduce

nique can no longer rely on the typ es to provide sucient

clutter When x is evaluated it decrements the contents of

guidance for correctness This is disapp ointing although

the reference cell r but then if the new value is nonzero

unsurprising The compiler can still recover the shortcut

x evaluates itself In eect there can be multiple simulta

deforestation technique by rening L s typ e system to use

neous activations of x rather like the multiple activations

qualied typ es along the lines of Launchbury Paterson

of a recursive function Indeed a nonmemoising imple

mentation of ML thunks can b e obtained by representing e

by e Furthermore these multiple activations can each

have a dierent value b ecause they each read the state

Side eects and p olymorphism

L s thunks have a much simpler semantics A thunk has

only one value and there can b e at most one activation

It is well known that the ability to create p olymorphic ref

of the thunk The key insight is that evaluation of a L

erences can lead to unsoundness in the typ e system Tofte

thunk has no side eects unlike the ML thunk ab ove But

For example if we are able to create a reference

what if the contents of the thunk p erforms side eects For

r with typ e Ref then we would b e able to write the

example

following erroneous co de

let x let v Int rd r in wr v in e

let wr r Int in

let fIntInt rd r IntInt in

Here if r Ref Int then x has typ e ST not

ret f

Forcing the thunk with force causes no side eects apart

from up dating the thunk itself and yields a computation

However in b oth L and L any expression of typ e Ref

1 2

that when subsequently p erformed by a let will incre

is undened in any environment The only way to construct

ment the lo cation r The computation x may b e p erformed

a value of Ref typ e is with new which returns a value of typ e

many times for example e might b e

ST Ref The only way to strip o the ST constructor is

with let Lo oking at the typing rule for let we can

ST ST

let a force x in let a force x in

ST ST

see that b ound variable must have typ e Ref

What this means though is that the more complicated se

SMLs socalled value restriction conservatively restricts

mantics of ML thunks have to b e expressed explicitly in L

generalisation in let bindings precisely to avoid the con

presumably by co ding them up using explicit references

struction of such p olymorphic references We conjecture

though we have not proved that L and L are b oth sound

1 2

More precisely if there is more than one then the thunks value

without any such side conditions

dep ends on its own value so its value is undened This prop erty

justies the wellknown technique of blackholing a thunk b oth

to avoid space leaks and to rep ort certain nontermination Jones

pap er We gratefully acknowledge the supp ort of the Ore Related work

gon Graduate Institute funded by a contract with US Air

Force Material Command FC

The FLINT language has rather similar ob jectives to the

work describ ed here in that it aims to serve as a common

infrastructure for a variety of higherorder typ ed source lan

References

guages Shao b However FLINT has not so far

concentrated much on the issue of strictness and laziness

which is the main fo cus of this pap er The ideas describ ed

Z Ariola M Felleisen J Maraist M Odersky P Wadler

here could readily b e incorp orated in FLINT

A call by need lamb da calculus in nd

Both the Glasgow Haskell Compiler and the TIL ML com

ACM Symp osium on Principles of Programming

piler use a p olymorphic stronglytyp ed internal language

Languages San Francisco ACM Jan

though the latter is considerably more sophisticated and

complex Peyton Jones Tarditi et al Nei

ther however seriously attempt to compile the others main

N Benton PL Wadler Linear logic monads and

evaluationorder paradigm

the lamb da calculus in Pro ceedings of the th

IEEE Symp osium on Logic in Computer Science

Brunswick New Jersey IEEE Press July

Further work

M Blume AW App el Lamb dasplitting a higher

order approach to crossmo dule optimization in

In this pap er we have concentrated on a core calculus Some

Pro c International Conference on Functional Pro

work remains to extend it to a practical IL

gramming Amsterdam ACM June

R Co ckett T Fukushima Ab out Charity TR

Recursive data typ es and case expressions must b e

Department of Computer Science Uni

added we anticipate no diculty here

versity of Calgary June

A pro of of typ e soundness is needed As we note in

DP Friedman DS Wise CONS should not eval

Section its soundness is not obvious

uate its arguments Automata Languages and

We have a simple op erational semantics for L we are

Programming July

condent that it is sound and adequate but have yet

to do the pro ofs

A Gill J Launchbury SL Peyton Jones A short cut

to deforestation in Pro c Functional Programming

We are studying whether is is p ossible to combine L s

Languages and Computer Architecture Cop en

ability to describ e certainlyterminating computations

hagen ACM June

with L s op erational mo del

JY Girard The System F of variable typ es fteen

years later in Logical Foundations of Functional

Accommo dating the ML mo dule system is likely to involve

Programming G Huet ed AddisonWesley

a signicant extension of the typ e system Harp er Stone

we have not yet studied such extensions

T Hagino A Categorical Programming Language

In a separate pap er we discuss how to use the framework of

PhD thesis Department of Computer Science Uni

Pure Typ e Systems to allow the language of terms typ es

versity of Edinburgh

and kinds to b e merged into a single language and compiler

data typ e Peyton Jones Meijer We hop e to merge

R Harp er JC Mitchell On the typ e structure of

the results of that pap er and this one into a single IL

Standard ML ACM Transactions on Program

ming Languages and Systems April

We have made no attempt to address the tricky problem

of how to combine monads For example ML includes the

monad of state and exceptions Is it advantageous to sepa

R Harp er G Morrisett Compiling p olymorphism

rate them into the comp osition of two monads or is it b etter

using intensional typ e analysis in nd ACM

to have a single combined monad In the former case what

Symp osium on Principles of Programming Lan

transformations hold

guages San Francisco ACM Jan

An imp ortant op erational question is that of the represen

R Harp er C Stone A typ etheoretic semantics for

tation of values esp ecially numb ers Quite a few pap ers

Standard ML Department of Computer Sci

have discussed how to use unb oxed representations for data

ence Carnegie Mellon University

values and it would b e interesting to translate their work

into the framework of L Leroy Peyton Jones

BT Howard Inductive coinductive and p ointed

Launchbury Shao a

typ es in Pro c International Conference on Func

tional Programming Philadelphia ACM May

Acknowledgements

MP Jones Dictionaryfree overloading by partial

evaluation in ACM SIGPLAN Workshop on Par

We would like to thank the POPL referees Nick Benton

tial Evaluation and SemanticsBased Program Ma

Bob Harp er Andrew Kennedy Je Lewis Erik Meijer

nipulation PEPM Orlando Florida ACM June

Chris Okasaki Ross Paterson Amr Sabry and Tim Sheard

for helpful feedback on earlier discussion and drafts of this

SL Peyton Jones WD Partain A Santos Let MP Jones Using parameterized signatures to express

oating moving bindings to give faster programs mo dular structure in rd ACM Symp osium on

in Pro c International Conference on Functional Principles of Programming Languages St Peters

Programming Philadelphia ACM May burg Beach Florida ACM Jan

SL Peyton Jones PL Wadler Imp erative func

R Jones Tail recursion without space leaks Journal

tional programming in th ACM Symp osium on

of Functional Programming Jan

Principles of Programming Languages POPL

J Launchbury G Baraki Representing Demand

Charleston ACM Jan

by Partial Pro jections Journal of Functional Pro

AM Pitts Relational prop erties of domains Infor

gramming

mation and Computation

J Launchbury R Paterson Parametricity and un

JC Reynolds Typ es abstraction and paramet

b oxing with unp ointed typ es in Europ ean Symp o

ric p olymorphism in Information Pro cessing

sium on Programming ESOP Linkoping Swe

REA Mason ed NorthHolland

den Springer Verlag LNCS Jan

A Sabry What is a purely functional language

J Launchbury SL Peyton Jones State in Haskell

Journal of Functional Programming to app ear

Lisp and Symb olic Computation Dec

A Sabry PL Wadler A reection on callbyvalue

X Leroy Unb oxed ob jects and p olymorphic typing

in Pro c International Conference on Functional

in th ACM Symp osium on Principles of Program

Programming Philadelphia ACM May

ming Languages Albuquerque ACM Jan

R Milner M Tofte The denition of Standard ML

Z Shao a Flexible representation analysis in Pro c

MIT Press

International Conference on Functional Program

ming Amsterdam ACM June

JC Mitchell AR Meyer Secondorder logical re

lations in Logics of Programs R Parikh ed

Z Shao b An Overview of the FLINTML compiler

Springer Verlag LNCS

in ACM Workshop on Typ es in Compilation Am

sterdam R Harp er R Muller eds June

E Moggi Notions of computation and monads In

formation and Computation

Z Shao AW App el A typ ebased compiler for

Standard ML in SIGPLAN Symp osium on Pro

C Okasaki Purely functional data structures PhD

gramming Language Design and Implementation

thesis CMUCS Department of Computer

PLDI La Jolla ACM June

Science Carnegie Mellon University Sept

D Tarditi G Morrisett P Cheng C Stone R Harp er

J Peterson K Hammond L Augustsson B Boutel W Bur

P Lee TIL A Typ eDirected Optimizing

ton J Fasel AD Gordon RJM Hughes P Hudak T

Compiler for ML in SIGPLAN Symp osium on

Johnsson MP Jones E Meijer SL Peyton Jones A

Programming Language Design and Implementa

Reid PL Wadler Haskell a nonstrict

tion PLDI Philadelphia ACM May

purely functional language Available at http

haskellorg April

M Tofte Typ e inference for p olymorphic references

Information and Computation Nov

SL Peyton Jones Compilation by transformation a

A Tolmach D Oliva From ML to Ada De

rep ort from the trenches in Europ ean Symp osium

partment of Computer Science and Engineering

on Programming ESOP Linkoping Sweden

Oregon Graduate Institute and submitted to Jour

Springer Verlag LNCS Jan

nal of Functional Programming

SL Peyton Jones AJ Gordon SO Finne Concur

DA Turner Elementary strong functional program

rent Haskell in rd ACM Symp osium on Prin

ming in Functional Programming Languages in

ciples of Programming Languages St Petersburg

Education Nigmegen Springer Verlag LNCS

Beach Florida ACM Jan

Dec

SL Peyton Jones J Launchbury Unb oxed val

PL Wadler Theorems for free in Fourth Interna

ues as rst class citizens in Functional Pro

tional Conference on Functional Programming and

gramming Languages and Computer Architec

Computer Architecture London MacQueen ed

ture FPCA Boston Hughes ed LNCS

Addison Wesley

Springer Verlag Sept

PL Wadler a Comprehending monads Mathemat

SL Peyton Jones E Meijer Henk a typ ed inter

ical Structures in Computer Science

mediate language in ACM Workshop on Typ es in

Compilation Amsterdam R Harp er R Muller

eds June

PL Wadler b The essence of functional program

ming in th ACM Symp osium on Principles of

Programming Languages Albuquerque ACM Jan