Typ ed Closure Conversion



Yasuhiko Minamide Greg Morrisett Rob ert Harp er

Research Institute for Mathematical Sciences Scho ol of Computer Science Scho ol of Computer Science

Kyoto University Carnegie Mellon University Carnegie Mellon University

Kyoto 606{01, Japan Pittsburgh, PA 15213{3891 Pittsburgh, PA 15213{3891

[email protected] [email protected] [email protected]

ronments and is thus exploited to go o d advantage byShao Abstract

and App el [31] and Wand and Steckler [38].

We study the typing prop erties of closureconversion for

Most accounts consider closure conversion as a transfor-

simply-typ ed and p olymorphic -calculi . Unlikemostac-

mation to untyped terms, irresp ective of whether or not the

counts of closure conversion, which only treat the untyp ed

source term is typ ed [35, 16, 2, 38]. This is adequate for com-

-calculus, we translate well-typ ed source programs to well-

pilers that make little or no use of typ es in the backendor

typ ed target programs. This allows later compiler phases to

at run time. However, when compiling typ ed languages, it is

take advantage of typ es for representation analysis and tag-

often advantageous to propagate typ e information through

free garbage collection, and it facilitates correctness pro ofs.

each stage of the compiler, and to make use of typ es at link

Our account of closure conversion for the simply-typ ed lan-

or even run time. For example, Leroy's representation analy-

guage takes advantage of a simple mo del of ob jects bymap-

sis [18, 32 ] uses typ es to determine pro cedure calling conven-

ping closures to existentials. Closure conversion for the

tions, and Ohori's record compilation [26] uses a representa-

p olymorphic language requires additional typ e machinery,

tion of typ es at run time to access comp onents of a record.

namely translucency in the style of Harp er and Lillibri dg e's

In current compilers, these phases must o ccur before closure

mo dule calculus, to express the typ e of a closure.

conversion b ecause the output of closure conversion is un-

typ ed. Compilation strategies for p olymorphic languages,

such as those prop osed by Morrison et al. [25] and Harp er

1 Intro duction

and Morrisett [13], rely on analyzing typ es at run time to

supp ort unboxed representations and non-parametric op er-

Closureconversion [30, 35 , 6, 16, 15, 2, 38, 8] is a program

ators, including printing and structural equality.Tag-free

transformation that achieves a separation b etween co de and

garbage collection [4, 37, 24 ] for b oth monomorphic and

data. Functions with free variables are replaced bycode

p olymorphic programming languages also relies up on typ es

abstracted on an extra environment parameter. Free vari-

at run time to determine the size and the p ointers of ob-

ables in the b o dy of the function are replaced by references

jects. To supp ort any of these implementation strategies, it

to the environment. The abstracted co de is \partially ap-

is necessary to propagate typ e information through closure

plied" to an explicitly constructed environmentproviding

conversion and into the generated co de. Consequently,the

the bindings for these variables. This \partial application"

purp ose of this pap er is to showhow closure conversion can

of the co de to its environment is in fact susp ended until the

b e formulated as a type-preserving transform.

function is actually applied to its argument; the susp ended

We are therefore interested in type-basedtransformations

application is called a \closure", a data structure containing

as a basis for compiling p olymorphic languages. The crucial

pure co de and a representation of its environment.

idea is to de ne a compiler as a series of transformations on

A critical decision in closure conversion is the choice of

b oth the program and its typ e, p ossibly relying on typ e in-

representation of the environment as a data structure |

formation to guide the transformation itself. Each stage of

for example, whether to use a \ at", \linked", or hybrid

the compiler is thus viewed as a typ e-preserving translation

representation. This decision is in uenced by a desire to

between typ ed intermediate languages. Examples of such

minimize closure creation time, the space consumed byan

translations are given by Leroy [18], Ohori [26], Harp er and

environment, and the time to access a given variable in an

Lillibri dge [9], and Harp er and Morrisett [13]. In addition

environment [38, 31]. An imp ortant prop erty of closure con-

to the practical advantages of propagating typ e information

version is that the representation of the environmentispri-

through the stages of a compiler, typ e-directed translation

vate to the closure, and is not visible from the outside. This

also facilitates correctness pro ofs by de ning the invariants

a ords considerable exibili ty in the representation of envi-

of the transformation as a typ e-indexed family of logical re-



This researchwas p erformed while the author was visiting the

lations [36, 7, 28, 33, 34].

Fox Pro ject at Carnegie Mellon University.

We describ e closure conversion in two stages. The rst

stage, abstract closureconversion,isa typ e-based transla-

tion from the source language into a target language with

To app ear POPL '96.

explicit closures. The translation is describ ed as a deductive

system in which the representation of the environmentmay

be chosen indep endently for each closure. In this wayvari-

ous environment representations, such as those used bythe p ossible to nd and eliminate compiler bugs since we can au-

CAM [6] and the FAM [5], as wellashybrid strategies, such tomatically typ e-check the output of each compiler phase.

as those suggested by Shao and App el [31] can b e explained Some compilers for ML based on representation analysis

in a uniform framework. [18, 32] also propagate typ e information through closure

The second stage, closurerepresentation,isa typ e-based conversion. However, their information is not enough to

translation in which the implementation of closures is de- typ e-check the resulting programs b ecause p olymorphism

termined. The main idea is to represent closures as objects is implemented by co ercions and all p olymorphic typ es are

(in contrast to the prop osed representation of objects as clo- represented byasingletyp e.

sures [29]). Following Pierce and Turner [27] we consider The remainder of this pap er is organized as follows: In

ob jects to b e packages of existential typ e consisting of a sin- Section 2, we giveanoverview of closure conversion and

gle metho d (the co de part of the closure) together with a the typing issues involved for the simply-typ ed -calculus.

single instance variable (the environment part) whose typ e In Section 3, we provide the details of our typ e-preserving

(the environment representation) is held abstract. This cap- transform for the simply-typ ed case. In Section 4, wegivean

tures the critical \privacy" prop ertyofenvironment repre- overview of closure conversion and the typing issues involved

sentations for closures. In the simply-typ ed case wemake for the predicative fragment of the p olymorphic -calculus.

direct use of Pierce and Turner's mo del of ob jects. In the The formal development of this conversion is given in Section

p olymorphic case wemust in addition exploit the notion of 5.

translucency [10] (or manifest types [19]) to express the typ e

of a p olymorphic closure.

2 Overview of Simply-Typ ed Closure Conversion

The correctness of b oth the abstract closure conversion

and the closure representation stages are proved using the

The main ideas of closure conversion may b e illustrated by

metho d of logical relations. The main idea is to de ne a

considering the following ML program:

typ e-indexed family of simulation relations that establish a

let val x = 1

corresp ondence b etween the source and target terms of the

val y = 2

translation. Once a suitable system of relations has b een

val z = 3

de ned, it is relatively straightforward to proveby induction

val f = w. x + y + w

on the de nition of the compilation relation that the source

in

and target of the translation are related, from whichwemay

f 100

conclude that a closed program and its compilation evaluate

end

to the same result. Due to a lack of space, the pro ofs of

correctness are omitted here. However, full details are given

The function f contains free variables x and y,butnotz.

in the companion technical rep ort [22].

Wemay eliminate the references to these variables from the

Closure conversion is discussed in descriptions of various

body of f by abstracting on an environment env, and replac-

functional language compilers [35, 16 , 3, 2 , 31]. It is closely

ing x and y by references to the environment. In comp en-

related to -lifting [14] in that it eliminates free variables in

sation a suitable environmentcontaining the bindings for x

the b o dies of -abstractions but di ers by making the rep-

and y must b e passed to f b efore it is applied. This leads

resentation of the environment explicit as a data structure.

to the following translation:

Making the environment explicit is imp ortant b ecause it ex-

p oses environment construction and variable lo okup to an

let val x = 1

optimizer. Furthermore, Shao and App el show that not all

val y = 2

environment representations are \safe for space" [31], and

val z = 3

thus cho osing a go o d environment representation is an im-

val f = (env. w. (#x env) + (#y env) + w)

p ortant part of compilation. Wand and Steckler [38] have

fx=x, y=yg

consider two optimizations of the basic closure conversion

in

strategy, called selective and lightweight closure conversion,

f 100

and provide a correctness pro of for each of these in an un-

end

typ ed setting. Hannan [8] re-casts Wand's work into a typ ed

References to x and y in the b o dy of f are replaced by

setting, and provides correctness pro ofs for Wand's opti-

pro jections ( eld selections) #x and #y that access the corre-

mizations. Hannan's translation is given, like ours, as a de-

sp onding comp onent of the environment. Since the co de for

ductive system, but like -lifting, he do es not consider the

f is closed, it may b e hoisted out of the enclosing de nition

imp ortant issue of environment representation (preferring an

and de ned at the top-level. We ignore this \hoisting" phase

abstract account), nor do es he consider the typing prop er-

and instead concentrate on the pro cess of closure conversion.

ties of the closure-converted co de. Finally, neither Wand nor

These simple translations fail to delay the application of

Hannan consider closure conversion under a typ e-passing in-

the co de to its environment under call-by-value evaluation.

terpretation of p olymorphis m.

A natural representation of a delayed application or closure

Wehave put the ideas in this pap er to practical use in

is an ordered pair (code, env) consisting of the co de to-

two separate compilers for ML: one compiler is b eing used

gether with its environment. Application of a closure to

to study novel approaches to tag-free garbage collection and

an argument pro ceeds by pro jecting the co de part from the

the other compiler provides a general framework for analyz-

closure and applying it simultaneousl y to the environment

ing typ es at run time to determine the shap es of ob jects.

and the argument according to some calling convention. For

Propagating typ es through closure conversion is necessary

example:

for b oth compilers so that typ es can b e examined at run

time. Wehave also found that typ ed closure conversion,

along with our other typ e-preserving translations, made it 2

let val x = 1 Since the typ es of the arms of the if-expression agree, the

val y = 2 target co de is well-typ ed with typ e 9t :(t ! int ! int) 

ve ve

val z = 3 t .

ve

val code = env. w. #x(env) + #y(env) + w An application ee'is corresp ondingl y translated to the

val env = fx=x, y=yg expression

val f = (code, env)

open e as t with z : (t !  !  )  t

ve ve 1 2 ve

in

in

(#1 f) (#2 f) 100

(#1 z) (#2 z) e'

end

end

But since code has a typ e of the form  !  !  , where

ve 1 2

 is the typ e of the environment env, the closure as a

ve which opens the package, extracts the co de and environ-

whole would havetyp e ( !  !  )   , showing

ve 1 2 ve

ment, and applies the co de to the environment and the ar-

the typ e of the environment explicitl y. That violates the

gument.

\privacy" of the environment representation. As a result,

This representation of closures b ears a striking resem-

using this translation on a well-typ ed source program will

blance to the mo del of ob jects suggested byPierceand

not, in general, result in a well-typ ed target program. For

Turner [27]. In their mo del an ob ject has a typ e of the form

example, consider the following ML source program with

9t:t   [t], where t is the typ e of the instance variable(s) and

typ e int ! int:

 [t] is the typ e of the metho d(s). According to the forego-

ing account, closures may b e thought of as ob jects with one

let val y = 1

instance variable (the environment) and one metho d (the

in

co de).

if true then

x. x+y

else

3 AFormal Account of Simply-Typ ed Closure Conversion

z. z

end

In this section we present the details of closure conversion for

Performing the translation ab ove yields:

the call-by-value, simply-typ ed -calculus. The conversion

let val y = 1

is describ ed in increasing detail by three stages: The rst

in

stage, abstract closureconversion,converts each function to

if true then

a closure but holds the representation of the closure abstract.

(env. x. x + #y(e), fy=yg)

To simplify the presentation, some freedom is allowed in the

else

construction of environments, but no shared environments

(env. z. z, fg)

are used. The second stage, environment sharing, adds more

end

structure to the translation thereby allowing environments

This program fails to typ e-check b ecause the then-arm of to b e shared. The third stage, closurerepresentation, makes

the representation of closures explicit through the use of

the if-expression has typ e (fy:intg!int ! int) fy:intg

translucent sums. Each stage is de ned as a typ e-directed

while the else-arm has typ e (fg ! int ! int) fg.

translation and the correctness of the translations is estab-

In order to preservetyp es in the target language, the

lished using logical relations.

representation of the environmentmay b e hidden using ex-

The syntax of the source language is de ned as follows:

istential typ es [23]. Figure 1 gives the typing rules for exis-

tentials. A pack op eration pairs a typ e  with a value e as

Types  ::= b j  ! 

1 2

an existential, holding  abstract as a typ e variable, t.An

Expressions e ::= c j x j x:: e j e e

1 2

open op eration takesapackage e and op ens it, binding the

1

Values v ::= c j x:: e

abstract typ e to t and the value of the package to x within

the scop e of e . The abstract typ e t is constrained so that

2

1

Typ es ( ) consist of base typ es (b) and function typ es (!) .

it cannot leave the scop e of the open construct, hence the

Expressions (e) consist of constants (c) of base typ e, vari-

restriction that t not app ear in the free typ e variables of  .

ables, abstractions, and application s. Weusetodenote

Using pack,we can hide the typ e of the environment for

a sequence of typ e bindings of the form fx : ;::: ;x : g,

a closure value as follows: 1 1 n n

(n  0) where the x are distinct. The judgement` e : 

i

pack  with (code; env) as 9t :(t !  !  )  t :

ve ve ve 1 2 ve

asserts that the expression e has typ e  under the typ e as-

signment , and is derived from the standard typing rules of

A closure of typ e  !  is represented as a package of typ e

1 2

the simply-typ ed -calculus. We de ne the dynamic seman-

9t :(t !  !  )  t where the typ e of the environment

ve ve 1 2 ve

tics of the language using a judgement of the form e,! v (e

( ) is held abstract as t . Under this translation, the

ve ve

evaluates to v ). The judgement is derived from the following

example ab ovewould b e translated to:

standard inference rules for call-by-value evaluation:

let val y = 1

in

e ,! x: :e e ,! v e[v =x] ,! v

1 1 2 2 2

if true then

v,! v

e e ,! v

1 2

pack fy:intg with (env. x. x+#y(env),fy=yg)

1

as 9t :(t ! int ! int)  t

ve ve ve

The results of this pap er easily extended to other source typ es

else

including pro ducts and sums.

pack fg with (env. z. z, fg)

as 9t :(t ! int ! int)  t

ve ve ve

end 3

0

; ` e : 9t:

1

; ` e :  [=t]

0

]ftg; ]fx: g`e : 

(t 62 FTV ( );t 62
)

2

; ` pack  with e as 9t:

; ` open e as t with x in e : 

1 2

Figure 1: Typing Rules for Existentials

0 0 0

is an expression that eval- asserts that e ; x:. ; e 3.1 Abstract Closure Conversion

ve ve

0

uates to the environment corresp onding to under the as-

cl

The target language for abstract closure conversion,  ,is

0

sumption that each binding in o ccurs in ]fx: g. Note

de ned as follows:

that the order of bindings in is imp ortant, and thus it is

considered to b e a sequence and not a set.

Types  ::= b j  !  jh  :::   ijcode( ; ; )

1 2 1 n ve 1 2

In a translated expression, x is always used to hold the

ve

Exp's e ::= c j x j e e jhe ;:::; e ij  (e) j

1 2 1 n i

currentlocalenvironment. Consequently, the translation

x : :x: :e jhhe ;e ii

ve ve 1 1 2

th

rule (env) maps a source variable x found in the i p osition

i

Values v ::= c j x : :x: :e jhv ;:::;v ij hhv ;v ii

ve ve 1 1 n 1 2

th

of typ e assignment to the i pro jection of the environment

In the intro duction we informally presented closures as par-

variable x , while the rule (arg) translates the argument

ve

tial applicati ons. As noted, we wish to delay this partial ap-

variable x to itself.

plication until the closure is applied to an argument, so that

The translation of an abstraction pro duces a closure con-

the co de and environment remain separate and the co de can

sisting of co de and an environment. To construct the envi-

0 0 0

b e shared among each instantiatio n of the closure. There-

ronment, wecho ose a typ e assignment suchthat;x : .

0 0

fore, in this account of closure conversion, we representthe

; e is derivable via the (context) rule and ; x:.

ve

0

delayed partial application as an abstract closure of the form

e ; e .Thesetwo constraints can b e summarized bysaying

0 0 0

hhe; e ii where e is the co de and e is the environment. This

ve ve

that every binding in can also b e found in ]fx : g.

0

allows us to distingui sh b etween delayed partial applications

In a more detailed formulation, would b e obtained from

0 0

(closures) and closure application (e e ). Co de expressions,

1 2

]fx : g via the application of strengthening and exchange

0

x : :x: :e, are a restricted form of closed -expressions

ve ve 1

rules. Furthermore, is required to contain bindings for all

that abstract b oth an environment(x ) and an argument

ve

of the free variables in the original function x:: e.The

(x). The typ es of co de expressions are also distingui shed

environment itself is constructed via the (context)ruleby

0

from the typ es of closures and are written as code( ; ; )

ve 1 2

translating eachofthevariables o ccurring in (namely

where  ,  , and  are the typ es of the environment, the

ve 1 2

x ;


;x ) to the target expressions e ;


;e . The result-

1 n 1 n

argument, and the return value resp ectively.

ing expressions are placed in a tuple (he ;:::;e i) to form

1 n

cl

The typing rules for  are standard except for co de and

the environment data structure of the closure. The environ-

closures, which are de ned as follows:

ment has typ e h 


 i whichwe summarize by writing

1 n

0

j j.

fx : ;x: g`e : 

ve ve 1 2

To pro duce the co de of the closure, we translate the

` x : :x: :e : code( ; ; )

ve ve 1 ve 1 2

b o dy of the source function under the strengthened assump-

` e : code( ; ; )` e : 

0 0

ve 1 2 ve ve

tions ; x : , pro ducing the b o dy of the co de, e , and then

`hhe; e ii :  ! 

ve 1 2

we abstract the environment and argument, resulting in

0 0

x :j j:x:: e .

ve

Since we require co de to b e closed in order that it maybe

Using a dummy argument(x:b) to translate an entire

hoisted to the top level, only x : (the environment) and

ve ve

closed program, it is easy to proveby induction on the

x: (the argument) can b e assumed when typing the b o dy

1

derivation of the translation that the translation preserves

of the co de.

the typ e of a program.

Evaluation of closures and applicati on pro ceeds as fol-

0 0

lows:

Theorem 1 If ;`e: and ;; x:b.e; e ,then;`e :  .

e ,! v e ,! v

1 1 2 2

hhe ;e ii ,!hhv ;v ii

1 2 1 2

Toprove the op erational correctness of the translation,

weuseatyp e-indexed family of logical relations relating

e ,!hhx : :x: :e; v ii e ,! v e[v =x ;v =x] ,! v

1 ve ve 1 ve 2 2 ve ve 2

closed source expressions to closed target expressions ( )

e e ,! v

1 2

and closed source values to closed target values ( ). The

We de ne abstract closure conversion as a typ e-directed

relations are de ned by induction on source typ es as follows:

cl

translation from the source language to  in Figure 2. The

0 0 0 0

e  e i e,! v and e ,! v and v  v

translation is formulated as a deductive system with judge-

 

0 0 0

c  c ments of the form ; x:.e; e ,and;x:. ; e

b

ve

0 0 0 0 0

v  v i for all v  v , vv  v v . where and are source typ e assignments,  is a source

 ! 1  1 

1 1

1 2 1 2

0 0

typ e, e is a source expression, and e and e are target

ve

We extend the relation to nite source ( ) and target sub-

expressions. The variable x is considered as the current ar-

0

stitutions ( ) mapping variables to their resp ectiveclassof gument while the other free variables in a source expression

values. These relations are de ned as follows:

should b e in and accessed through the currentenviron-

0

ment in the translation. The judgement;x:.e; e

0

 [hv ;:::;v i=x ;v=x]

1 n ve

fx : ;::: ;x : g;x:

n n

1 1

asserts that e is the translation of e under the assump-

0 0

i (x )  v for 1  i  n and (x)  v .

i  i 

i

tion that ]fx: g` e :  for some  . The judgement 4

(const);x:.c; c (arg);x:.x; x (env) fx : ;:::;x : g; x:.x ;  (x )

1 1 n n i i ve

0 0 0 0 0 0 0

; x:.e ; e ; x:.e ; e ; x : . ; e ; x:.e; e

2 1 ve

2 1

(app) (abs)

0 0 0 0 0 0

; x : .x::e ; hhx :j j:x:: e ;e ii ; x:.e e ; e e

ve ve 1 2

1 2

; x:.x ; e ::: ; x:.x ; e

1 1 n n

( ]fx: g`x :  ) (context)

i i

; x:.fx : ;:::;x : g ; he ;:::;e i

1 1 n n 1 n

Figure 2: Simply-Typ ed Abstract Closure Conversion

0

0 0

Theorem 2 (Op erational Correctness) Let  . The (env) rule gives us the currentenvironment directly as

;x :

0 0 0 0 0

If ]fx : g` e :  and ; x : .e; e , then (e)  x allowing us to avoid creating a copy. This rule, coupled

 ve

0 0

(e ). with the (env-tuple) rule allows us to construct shared envi-

ronments as nested tuples. If we translate  to e under the

This theorem and the de nition of the relations imply

typ e assignment, then the (subenv) rule lets us translate

i

that for a closed program with a base typ e, the results of

toe[ (x )=x ]undera typ e assignmentwhich contains

i ve ve

th

evaluation of the original program and its translation are

 as the i comp onent. Variable x is translated as a nested

i

the same.

typ e assignment fx: g by(var).

Nested typ e assignments are exible enough to repre-

sentvarious environment representations used in practice.

3.2 Sharing Environments

For example, the Categorical Abstract Machine or CAM [6]

Some implementations of functional programming languages

uses linked lists to representenvironments. This is re ected

use environments with nested structures that may share

in our framework by restricting the shap e of nested typ e as-

some p ortions of the environment with other closures. Shar-

signments and by restricting the (env-tuple) rule to \cons"

ing environments decreases the amount of space consumed

the current argumentonto the currentenvironment:

by a closure and decreases the time to construct the closure's

environment. However, sharing can also require extra in-

(CAM context)  ::= fx: gjhfx: g;  i

c c

structions to access a variable's binding in the environment.

(env-tuple)  ; x:.hx:;  i ; hx; x i

c c ve

Furthermore, sharing environments naively can lead to space

problems in the presence of a standard tracing garbage col-

The advantage of the CAM strategy is that the cost of the

lector. In this section we extend our closure conversion to

construction of a new environment is constant. However,

allow for but not require shared environments. Wedosoby

in the worst case accessing values in the environmenttakes

adding extra structure to the typing contexts of the trans-

time prop ortional to the length of the environment.

lation judgement and use this extra structure to guide the

In contrast, the FAM [5] uses at environments with no

construction of [p ossibly] shared environments. Wethen

sharing. The closure conversion of Figure 2 accurately mo d-

showhow the resulting translation subsumes a wide variety

els the environment strategy of the FAM if wecho ose a sp e-

of environment representations used in practice.

ci c strengthening strategy in the (abs) rule where only the

In the previous section, translation judgements were of

free variables of the function are preserved in the resulting

0

the form ; x:.e; e where was a at typ e assign-

closure's environment. The advantage of the FAM environ-

ment of the form fx : ;:: :;x : g. Here, we add extra

1 1 n n

ment representation is that the cost of variable lo okup is

structure to the translation judgementbyusing nested typ e

always constant and the representation is \safe for space"

assignments de ned as follows:

[2] according to App el's de nition. However, constructing

the environment for a closure takes time prop ortional to the

::=fx: gjh ;:::; i

1 m

numb er of free variables in the function and closures cannot

share p ortions of their environment.

A nested typ e assignment is either a single typ e binding

Clearly, there are a variety of other strategies for form-

or a sequence of nested typ e assignments. The environ-

ing environments. For example, the shared closure strat-

ment corresp onding to the typ e assignment  is represented

egy describ ed by App el and Shao [31] that is also safe for

in the target language bytyp e jj where jfx: gj =  and

space can also b e formulated in our framework. However,

jh ;:::; ij = hj j:::j ji. Clearly,we can obtain

1 m 1 m

to determine a go o d representation for each closure's envi-

a non-nested typ e assignment () from a nested typ e assign-

ronment requires a go o d deal more information including

ment () simply by dropping the extra structure. Hence,

an estimate as to howmany times eachvariable is accessed,

we consider  to representanestedtyp e assignmentaswell

when garbage collection can o ccur, what garbage collection

as its corresp onding at typ e assignment.

algorithm is used, etc.

The relevant translation rules for closure conversion with

nested environments are given in Figure 3. The other trans-

3.3 Closure Representation

lation rules are the same as in Figure 2, replacing with

.

Abstract closure conversion cho oses an environment repre-

The (arg) rule translates a nested typ e assignmentcon-

sentation for each closure and makes the construction of clo-

sisting of only the current argumenttothevariable itself.

sures explicit. However, abstract closure conversion makes 5

0 0

; x : . fx: g ; e

0 0 0 0 0

(arg) fx: g; x : . fx : g ; x (env);x:. ; x (var)

ve

0 0

; x : .x; e

; x:. ; e


; x:. ; e  ; x:. ; e

1 1 n n i

(env-tuple) (subenv)

h ;:::; i; x:. ; e[ (x )=x ] ; x:.h ;:::; i ; he ;:: :;e i

1 n i ve ve 1 n 1 n

Figure 3: Simply-Typ ed Closure Conversion using Nested Environments

0

the extraction of the co de and environment in an application Theorem 3 If ` e :  and .e:  ; e , then ;; jj`

0

implicit in the op erational semantics. Ideally, these extrac- e : j j.

tion op erations should b e explicit so that an optimizer can

Op erational correctness of the translation is proven using

eliminate redundant pro jections. For instance, if the same

cl 9 cl

logical relations b etween  and  expressions,  and

closure is rep eatedly applied to some arguments in a lo op,

9 cl 9

 values, and  and  substitutions. The de nition of

we should b e able to extract the co de and environmentof

relations and the pro of of the op erational correctness are

the closure one time, name these values, and then use these

found in the technical rep ort [22].

names within the lo op.

9

We therefore de ne a target language  with existential

typ es as follows:

4 Overview of Polymorphic Closure Conversion

Types  ::= b j t jh  :::   ijcode( ; ; ) j9t:

1 n ve 1 2 Closure conversion for a language with ML-style (i.e.,pred-

Exp's e ::= c j e (e ;e ) j x : :x: :e jhe ;:::;e ij

1 2 3 ve ve 1 1 n icative [12]), explicit p olymorphi sm follows a similar pattern

 (e) j pack  with e as  j

i to the simply-typ ed case, but with the additional complica-

open e as t with x: in e

1 2 tion that wemust account for free typ e variables as well

as free value variables in the co de of an abstraction, and

cl

This language is the same as  except for the addition b oth value abstractions (-terms) and typ e abstractions (-

of package values of typ e 9t: that pair an abstract typ e (t) terms) induce the creation of closures. In this section, we

with a value of typ e  .Function typ es (!) are no longer giveanoverview of the typing diculties encountered when

necessary b ecause they can b e represented using other typ e closure converting value abstractions. The treatmentoftyp e

constructors (namely 9 and code( ; ; )). In order to abstractions is similar (see Section 5 for details).

ve 1 2

prevent the partial applicatio n of the co de to its environ- To eliminate free o ccurrences of typ e variables and or-

ment, we restrict applicatio ns to the form e (e ;e ). The dinary variables from the co de, we abstract with resp ect to

1 2 3

typing rules and evaluation of pack and open expressions atyp e environment and a value environment, replacing free

are standard (see [23] and Figure 1). variables by references to the appropriate environment. By

cl 9

abstracting b oth free typ e variables and free value variables,

We b egin by de ning a translation from  to  typ es,

the co de b ecomes closed and can b e hoisted to the top level.

denoted j j and de ned as follows:

The abstracted co de is then \partially applied" to suitable

representations of the typ e and value environments to form a

jbj = b

p olymorphic closure. As in the simply-typ ed case, we need a

jh  :::   ij = hj j::: j ji

1 n 1 n

data structure to representthedelayed partial application of

jcode( ; ; )j = code(j j; j j; j j)

ve 1 2 ve 1 2

the co de to its environments. Also, we need to abstract b oth

j !  j = 9t :hcode(t ; j j; j j)  t i:

1 2 ve ve 1 2 ve

the kind of the typ e environment and the type of the value

The translation of an arrowtyp e is a pair consisting of co de

environment so that their representations remain private to

and an environment, with the environmenttyp e (t ) held

the closure. Without the abstraction, weruninto the same

ve

abstract using an existential.

typing problems that we encountered with the simply-typ ed

cl 9

The translation mapping  terms to  terms is sum- case.

marized in Figure 4. The translation de nes judgements of

As a running example, consider the expression:

0 cl

the form .e:  ; e where , e,and  are a  typ e

0 9

x:t .(x:t ,y:t , z:int)

1 1 2

assignment, expression, and typ e resp ectively, and e is a 

expression. The interesting rules are (closure)and(app).

of typ e t ! (t  t  int)wheret and t are free typ e

1 1 2 1 2

cl

The other rules (not shown), simply map the other  con-

variables and y and z are free value variables of typ e t and

2

9

structs to their  counterparts. A closure is translated to a

int resp ectively. After closure conversion, this expression is

pair of the co de and the environmentpacked with the typ e

translated to the partial application

of the environment. The translation of an application ex-

let val code =

tracts from a package the pair of a co de and an environment

tenv :: ft :: , t :: g.

and applies the co de to the environment and the argument.

1 2

venv : fy:#t tenv, z:intg.

It is easy prove that the translation preserves the typ e

2

x:(#t tenv).(x, #y venv, #z venv)

of a program up to the translation of the typ e. Wedoso

1

in

by rst extending the typ e translation to typ e assignments,

code ft =t , t =t gfy=y, z=zg

writing:

1 1 2 2

end

jfx : ;:::;x : gj = fx :j j;:::;x :j jg

1 1 n n 1 1 n n 6

0 0

.e: code( ; ; ) ; e .e :  ; e

ve 1 2 ve ve

ve

(closure)

0 0

i as j !  j . hhe; e ii :  !  ; pack j j with he ;e

1 2 ve 1 2 ve

ve

0 0

.e :  !  ; e .e :  ; e

1 1 2 2 1

1 2

(app) .e e :  ; (x 62 Dom())

1 2 2

0 0

open e as t with x:hcode(t ; j j; j j)  t i in ( x)( x; e )

ve ve 1 2 ve 1 2

1 2

Figure 4: Imp ortant Rules of Simply-Typ ed Closure Representation

The code abstracts typ e environment(tenv) and value en- The problem is that existentials provide a certain kind

vironment(venv) arguments. The actual typ e environment, of mixed-phase data structure where the typ e p ortion must

ft =t ,t =t g, is a constructor record with kind ft :: ,t :: g b e abstract. We can use this to hide representations but

1 1 2 2 1 2

where is the kind of monotyp es. The actual value envi- here, we need to know what the typ e environment actually

ronment, fy=y, z=zg is a record with typ e fy:t , z:intg. is in order to determine the typ e of the closure. In short,

2

However, to keep the co de closed so that it may b e hoisted, we need a mixed-phase data structure that do es not hide its

all references to free typ e variables in the typ e of venv must typ e comp onent.

come from tenv.Thus, we give venv the typ e fy:#t tenv, This same problem has b een encountered in the study

2

z:intg. Similarly, the co de's argument x is given the typ e of the ML-like mo dule systems [11, 20 , 21 ]. Recentsolu-

#t tenv. Consequently,thecode part of the closure is a tions are based on the idea of translucent sums [10 ] or man-

1

closed expression of closed typ e  ,where ifest types [19], whichprovide the p ower of b oth existentials

(weak sums), and transparent sums (strong sums). By as-

 = 8tenv::ft :: , t :: g.

1 2

cribing the translucent sum typ e

fy:#t tenv, z:intg!

2

9t =ft =t ,t =t g.  

te 1 1 2 2 ve

(#t tenv)!((#t tenv)(#t tenv)int)

1 1 2

to the closure, the equation t =ft =t ,t =t g is propagated

te 1 1 2 2

It is easy to check that the entire expression has typ e

into the scop e of the abstraction so that in particular #t

1

t ! (t  t  int), and thus the typ e of the original function

1 1 2

t = #t ft =t ,t =t g = t , and thus the translation of

te 1 1 1 2 2 1

is preserved.

application is typ e correct.

Wemust now translate the partial applicatio n of the code

The next step is to hide the representation of the value

to it environments into a data structure. The structure must

environmentaswe did in the simply-typ ed case. If wesimply

b e \mixed-phased" b ecause it needs to hold a typ e (the typ e

abstract the typ e  from the ab ovetyp e expression we

ve

environment) as well as values (the co de and value environ-

obtain

ment). A rst attempt is to represent the data structure as

a package e, where

9t =ft =t ,t =t g.9t :: .  t

te 1 1 2 2 ve ve

e = pack ft =t , t =t g with (code, fy=y, z=zg)

1 1 2 2

where t is the abstract typ e of the value environment.

ve

as 9t :: .  

te te ve

However, this fails to maketyp e sense b ecause wehave ab-

stracted the typ e of the value environment in the closure,

and code is the co de of the closure ab ove and

but not the corresp onding argumenttyp e of the co de of the

closure. The translation of application is ill-typ ed b ecause

 = ft :: , t :: g

te 1 2

the value environment has abstract typ e t , but the domain

ve

 = fy:#t t , z:intg

ve 2 te

typ e of (#1 z) t is fy:t , z:intg.Sincet is abstract,

te 2 ve

It is easy to verify that e is well-typ ed under the typing rule these twotyp es are considered distinct. In order to simul-

for pack. taneously abstract the typ e of the value environmentand

Unfortunately, there is a problem with this approach: the corresp onding argumenttyp e in the co de, weneedto

0

an application of e to some argument e : t mustopenthe replace b oth typ es with the same abstract typ e t .Todo

1 ve

package to extract the co de, typ e, and value environments this, wemust show that the twotyp es are equivalent. This

prior to the call: can b e accomplished by requiring that the formal typ e envi-

ronment argument(tenv) is only instantiated with the typ e

open e as t :: with z:  

te te ve

environment t . One waytoachieve this is to p erform the

te

in

application of the co de to t , but the goal of closure con-

te

0

(#1 z) t (#2 z) e

te

version is to delay such partial application s. An alternative

end

approach is to use translucency again and coerce the co de

0

so that it has the typ e  , where:

Although this is the \obvious" translation of application , it

0

0

failstobewell-typ ed! The diculty is that e is of typ e t ,

1

 = 8tenv= t :: .

te te

whereas the expression (#1 z) t (#2 z) has typ e:

te

fy:#t tenv, z:intg!

2

(#t tenv)!((#t tenv)(#t tenv)int)

1 1 2

(#t t )!((#t t )(#t t )int).

1 te 1 te 2 te

Adding the constraint tenv= t to the typ e of the co de

te

Since t is abstract, t is not provably equivalentto#t t ,

te 1 1 te

has the e ect of p erforming the typ e application at the type-

and this translation of application fails to typ echeck.

level, but delays the applicati on at the term-level. Note that 7

0

 is a sup er-typ e of the original co de typ e  according to 5 AFormal Account of Polymorphic Closure Conversion

the rules of the translucent sum calculus. Consequently,

In this section, we present closure conversion for the predica-

the co de remains the same (i.e., closed) and can still b e

tive subset of the second order -calculus. It has b een argued

hoisted to the top level. In contrast, if we had p erformed

that the predicative fragment captures the \essence" of ML-

the typ e application , the resulting co de would not b e closed

style p olymorphi sm, since there is a strati cation b etween

(containing free references to t ).

te

monotyp es (typ es not involving a quanti er) and p olytyp es,

Since tenv= t and t =ft =t ,t =t g, it follows that

te te 1 1 2 2

and instantiatio n of typ e variables is restricted to mono-

tenv=ft =t ,t =t g and thus (#t tenv)= t . Consequently,

1 1 2 2 i i

typ es [12]. These restrictions make it easy to use logical

the data structure holding the comp onents of the closure can

relations to argue correctness in the same fashion as wedid

b e co erced to the equivalenttyp e:

for the simply-typ ed -calculus.

00

8

9t =ft =t ,t =t g. fy:t ,z:intg

te 1 1 2 2 1

The syntax of our source language  is de ned as fol-

lows:

00

where  is

Kinds  ::=

00

 = 8tenv= t :: .fy:t ,z:intg!

te te 1

Constructors  ::= b j t j  ! 

1 2

t !(t  t int)

1 1 2

Types  ::=  j  !  j8t:::

1 2

Expressions e ::= c j x j x: :e j t:::e j e e j e

1 1 2

Since this equivalenttyp e makes no mention of the typ e

Values v ::= c j x: :e j t:::e

1

environment t except in the constraintfortenv,wemay

te

drop the constraintont , abstract the typ e of the value

te

The typ e constructors ( ) are describ ed by kinds (). There

environment(fy:t ,z:intg), and abstract the kind of the

1

8

is only one kind ( ) for  , but subsequent languages havea

typ e environment  to obtain the closure typ e:

te

richer kind structure, so weintro duce kinds here for unifor-

000

mity. Closed constructors of kind corresp ond to a subset 9k :9t ::k :9t :: .  t

te te te ve ve

of typ es (the monotyp es), in particular the typ es that do

where

not include quanti ers. Thus, constructors of kind can

b e injected into typ es. Weleave this injection implicit and 000

 = 8tenv= t ::k .t ! t !(t  t int)

te te ve 1 1 2

treat  as b oth a constructor and a typ e.

A kind assignment
is a sequence that maps typ e vari-

It is easy to deriveatyp e-preserving translation of appli-

ables to kinds and is of the form ft :: ;:::;t :: g,(n  0).

cation corresp onding to this representation of closures. We

1 1 n n

Typing judgements are of the form
; ` e :  where the

simply open all of the existentials, and pass the typ e envi-

free typ e variables of , e,and  are contained in the do-

ronment, value environment, and argument to the co de.

main of
, and the free value variables of e are contained

Careful consideration of the foregoing discussion reveals

in the domain of . A typing judgement is derived from the

that only limited use is made of translucency. The equa-

standard typing rules of the second-order -calculus (see for

tional constraintont is dropp ed from the existential (to

te

example [12 , 13]).

ensure privacy of environment representation), and the uni-

versally quanti ed variable tenv do es not o ccur in the scop e

of the abstraction. This suggests that a substantiall y sim-

5.1 Abstract Closures

pler mechanism than the full translucent sum calculus is

As in the simply typ ed case, we break closure conversion

more appropriate for closure conversion. Hence, weintro-

into abstract closure conversion and closure representation

duce a sp ecial typ e, written  )  , of functions that must

2 8

stages . The abstract closure conversion stage for  con-

b e applied to the constructor  to yield a value of typ e  .

verts b oth -abstractions and -abstractions into abstract

The following two rules govern this new typ e constructor:

closures consisting of co de, a typ e environmentandavalue

environment.

; ` e :  ) 
`  :: 
; ` e : 8t:::

8;cl

The syntax of the target language  is de ned as fol-

; ` e :  )  [=t]
; ` e : 

lows:

The rst rule restricts the domain of typ e applicatio n to the

Kinds  ::= jh  :::   i

1 2

sp eci c constructor  . This corresp onds to restricting the

Con's  ::= b j t j  !  jh  :::   ij

1 2 1 n

typ e to 8t = : and propagating the equivalence t =  into

h ;:::; ij  j

1 n i

 . The actual typ e application for  )  is p ermitted only

Types  ::=  j  !  j8t::: jh  :::   ij

1 2 1 n

for constructors equivalentto . These two rules naturally

vcode(t :: ; ; ; ) j

te te ve 1 2

come from the necessity of delaying typ e application s for

tcode(t :: ; ;t::;  )

te te ve

closure conversion. Using this notation, the typ e translation

Exp's e ::= c j x j e e j e jhe ;:::;e ij e j

1 2 1 n i

of  !  b ecomes

1 2

t :: :x : :x: :e j

te te ve ve 1

t :: :x : :t:::e jhhe ;;e ii

te te ve ve 1 2

9k :9t ::k :9t :: :(t ) t !  !  )  t :

te te te ve te ve 1 2 ve

A pro duct kind h  :::   i is used to sp ecify the

1 n

The typ e of closures abstracts the kind of the typ e en-

shap e of typ e environments just as a pro duct typ e sp eci es

vironment and the typ e of the value environment, ensuring

the shap e of value environments. Given constructors  with

i

that these maybechosen separately for each closure in the

kind  , the constructor h ;:::;  i has kind h  :::  i

i 1 n 1 n

system. As in the simply-typ ed case wehave obtained an

and is used as a typ e environment consisting of  ;:::; in

1 n

\ob ject oriented" representation of p olymorphic closures by

a translated program.

exploiting a combination of the typ e systems prop osed by

2

Pierce and Turner [27] for ob jects and by Harp er and Lil-

The material on environment sharing carries over in a straight-

forward manner. libridge [10] for mo dules. 8

0

There are twotyp es of co des: the co de for ordinary ab- must b e chosen as subsets of the current assignments

env

straction, t :: :x : :x: :e, and the co de for typ e
]
and ] resp ectively. These assignments

te te ve ve 1 env arg env arg

abstraction, t :: :x : :t:::e. Co des takeatyp e must b e chosen so that all of the free value variables of the

te te ve ve

0

environment, a value environment, and a typ e or value argu- term are contained in and further, all of the free typ e

env

ment resp ectively.Weintro duce the typ es vcode and tcode, variables of the term and the value environmentmust b e

0

to distinguish the typ es of co des from the typ es of closures contained in
.

env

and to avoid partial application s of co des. Intuitively,they The primary subtlety in these rules is that weneed two

0 00

corresp ond to standard typ es as follows: typ e assignments and to describ e the value envi-

env env

0

ronment of the closure, dep ending up on the context.

env

vcode(t :: ; ; ; )  8t :: : !  ! 

te te ve 1 2 te te ve 1 2

is constructed from the context
;
; ; and is

env arg env arg

tcode(t :: ; ;t::;  )  8t :: : !8t:::

te te ve te te ve

used to build the environment e in the context where we

ve

00

are constructing the closure. In contrast, is obtained

env

Only typ es excluding 8, vcode, and tcode can b e named

00 0 0 0

and cor- ; ; ; . via the translation
from

env env env env

as a constructor. An abstract closure hhe ;;e ii consists of

1 2

resp onds to the typ e of the value environment in the context

acodee ,atyp e environment constructor  ,andavalue

1

of the closure itself.

environment e .

2

8;cl

The typ e correctness of the translation is proved byin-

For the typing of  , kind assignments (
) map typ e

duction on the derivation of the translation.

variables to kinds while typ e assignments () map value

variables to typ es. The judgements of the static semantics

Theorem 4 (Typ e Correctness) If
;
; ; .

env arg env arg

are as follows:

0

e ; e and
]
; ] ` e :  ,thenft ::j
jg]

env arg env arg te env

0 0 0 0 0

; fx :j jg ] ` e :  where
;
. ;  ,

`  ::   is a well-formed constructor of kind .

arg ve env arg

env arg

0 0

. ,and
;
. ;
;
. ;

`   is a well-formed typ e.

env arg arg env arg env

arg env

`    ::   and  are equivalent constructors.

1 2 1 2

We can prove the op erational correctness of the trans-

`     and  are equivalenttyp es.

1 2 1 2

lation using logical relations in the same fashion as wedid

; ` e :  e is a well-formed expression of typ e  .

for the simply typ ed case b ecause the source language is

The formation rules of typ es are standard. Wehavetoin-

restricted to the predicative p olymorphism.

tro duce de nitional equality of constructors and typ es to

account for pro jections of constructors from pro duct kinds.

5.2 Closure Representation

They consist of the equivalence rules for pro jections b elow

In this section we present closure representation for the sec-

as well as the standard rules for equivalence and congruence.

ond order language. Weusetyp es with existential kinds to

`  h ;:::; i :: 

i 1 n i i

abstract the representation of typ e environments and exis-

`h ( );:::; ( )i :: h  :::   i

1 n 1 n

tential typ es to abstract the representation of value environ-

0

ments. Further, weintro duce the typ e  )  , derived from

The typing rules for expressions are standard except for the

translucenttyp es, to solvethetyping problems discussed in

rules for co des and closures. They are de ned in Figure 5.

the overview.

We require that co de values b e closed with resp ect to b oth

The target language for p olymorphic closure representa-

typ e variables as well as value variables. This allows us to

8;9

tion, called  , is de ned as follows:

hoist co de out of inner de nitions to the top level.

8

Abstract closure conversion for  is formulated as a

Kinds  ::= k j jh  :::   i

1 n

8;cl

typ e-directed translation to  by the deductivesystemin

Types  ::= b j t jh  :::   ijh ;:::;  ij   j

1 n 1 n i

0

Figures 6 and 7. The judgement
;
. ;  means

env arg

8t::: j  )  j  !  j9t::: j9k:

1 2 1 2

0

that  is the translation of  where
is a kind assign-

env

Exp's e ::= x j c j x::e j e e j t:::e j ej

1 2

ment corresp onding to a typ e environment and
is a

arg

he ;:::;e ij e j

1 n i

kind assignment corresp onding to a typ e argument(ifany).

0

pack  with e as  j

This judgement also implicitl y de nes a translation from

0

open e as t:: with x: in e

constructors to constructors, since source-level constructors

pack  with e as  j

( ) are a subset of typ es ( ) and the translation maps con-

0

open e as k with x: in e

structors to constructors. In translated programs, the typ e

variable t is used for typ e environments.

te

There is no distinction b etween typ es and constructors for

0

The judgement
;
; ; .e; e means

8;9

env arg env arg

 because typ e application is no longer restricted to just

0

e is a translation of e where
and
are as in the

8;9

env arg

monotyp es.  needs this impredicativi ty b ecause some

typ e translation, and and are typ e assignments

env arg

monotyp es from the source language are translated into typ es

corresp onding to the value environment and value argument

with quanti ers. To simplify the language, weprovide full

resp ectively.Atyp e environment corresp onding to
and

env

abstractions ( and ) instead of co des which abstract more

avalue environment corresp onding to are implemented

env

than one argument at a time.

in the target language bytyp es of the form j
j and j j

env env

Toprovide typ es with existential kinds, we need to in-

resp ectively, de ned b elow.

tro duce kind variables k and kind contexts for the typing

8;9

judgements of  . A kind context K is simply a sequence

jft :: ;:::;t :: gj = h  :::   i

1 1 n n 1 n

of kind variables, fk ;:::;k g,(n  0). The typing judge-

1 n

jfx : ;:::;x : gj = h  :: :   i

1 1 n n 1 n

ments of the language consist of the following:

The most interesting rules are the term translations of

value and typ e abstractions. In each case, an appropri- K;
`  ::   has kind .

ate typ e environment and value environmentmust b e con- K;
`    ::   and  are equal typ es of kind .

1 2 1 2

0

structed as part of the closure. Thus, assignments
and K;
; ` e :  e has typ e  .

env 9

ft :: g; fx : ;x: g`e : 

te te ve ve 1 2

; ` t :: :x : :x: :e : vcode(t :: ; ; ; )

te te ve ve 1 te te ve 1 2

ft :: ;t:: g; fx : g`e : 

te te ve ve

; ` t :: :x : :t:: :e : tcode(t :: ; ;t;)

te te ve ve te te ve

; ` e : vcode(t :: ; ; ; )
`  : 
; ` e :  [=t ]

1 te te ve 1 2 te 2 ve te

; `hhe ;;e ii :( !  )[=t ]

1 2 1 2 te

; ` e : tcode(t :: ; ;t;)
`  : 
; ` e :  [=t ]

1 te te ve te 2 ve te

; `hhe ;;e ii :(8t: )[=t ]

1 2 2 te

Figure 5: Typing Rules for Co de and Closures

;
.b; b ft :: ;:::;t :: g;
.t ;  t

env arg 1 n arg i i te

;
.t; t (t 2 Dom(
))

env arg arg

0 0 0

;
]ft:: g . ; 
;
. ; 
;
. ; 

env arg env arg 2 env arg 1

2 1

0 0 0

! 
;
. !  ; 
;
. 8t:::  ; 8t::: 

env arg 1 2 env arg

2 1

0 0

;
.t ; 



;
.t ; 

env arg 1 env arg n

n

1

0 0

;
. ft :: ;:::;t :: g ; h ;:::; i

env arg 1 n

1 n

0 0

;
. ; 
;
. ; 

env arg n env arg 1

n 1

0 0

;
. fx : ;::: ;x : g ; fx : ;:::;x : g

env arg 1 1 n n 1 n

1 n

Figure 6: Polymorphic Abstract Closure Conversion: Typ es and Typ e Assignments

(const)
;
; ; .c; c

env arg env arg

(env)
;
; fx : ;:::;x : g; .x ;  x

env arg 1 1 n n arg i i ve

(arg)
;
; ; .x; x (x 2 Dom( ))

env arg env arg arg

0 0

;
; ; .
; 
;
; ; . ; e

env arg env arg te env arg env arg ve

env env

0 0 00 0 0

; ; . ;
; ; . ; 

1

env env env env 1

(abs)

0 0 0

; ;; ; fx: g .e; e

1

env env

0 0 00 0

:e ; ;e ii j:x: j:x :j
;
; ; .x: :e ; hht ::j

te ve ve env arg env arg 1 te

1 env env

0 0

; e ; 
;
; ; .
;
; ; .

ve te env arg env arg env arg env arg

env env

0 0 00 0 0 0

; ; . ;
; ft:: g; ; ; .e ; e

(tabs)

env env env env env

0 00 0

;
; ; . t:: :e ; hht ::j
j:x :j j:t:: :e ; ;e ii

env arg env arg te ve te ve

env env

0 0

;
; ; .e ; e
;
; ; .e ; e

env arg env arg 1 env arg env arg 2

1 2

(app)

0 0

;
; ; .e e ; e e

env arg env arg 1 2

1 2

0 0

;
; ; .e ; e
;
. ; 

env arg env arg env arg

(tapp)

0 0

;
; ; .e ; e 

env arg env arg

0

;
; ; .x ; e

env arg env arg i

i

(context)

0 0

i ;:::;e
;
; ; . fx : ;:::;x : g ; he

env arg env arg 1 1 n n

n 1

Figure 7: Polymorphic Abstract Closure Conversion: Terms 10

The de nition of the formation rules, de nitional equal- to study novel approaches to tag-free garbage collection and

ityoftyp es, and typing rules are standard except that p oly- the other compiler provides a general framework for analyz-

morphic typ e 8t :: : can b e instantiated to  )  [=t] for ing typ es at run time to determine the shap es of ob jects.

typ e  with kind  as describ ed in the overview. The details Propagating typ es through closure conversion is necessary

of the typing rules are found in the technical rep ort [22]. for b oth compilers so that typ es can b e examined at run

We de ne the closure representation stage as a typ e- time. For simplicity, the current implementations of our

8;cl 8;9

directed translation from  to  .We b egin by de ning compilers use abstract closure conversion. As many com-

a translation from source constructors and typ es to target pilers, our compilers avoid creation of closures for known-

typ e as follows: functions. Such optimization do es not intro duce any prob-

lem.

jtj = t

Lightweight closure conversion prop osed byWand and

jbj = b

Steckler [38] may also b e formulated as typ e-preserving trans-

jh ;:::; ij = hj j;:::;j ji

1 n 1 n

lation as our closure conversions. However, the de nition of

j  j =  j j

i i

translation may b ecome complicated b ecause the typeofthe

jh  :: :   ij = hj j::: j ji

1 n 1 n

closure as well as the translation of abstraction dep ends on

jvcode(t::;  ; ; )j = 8t:::j j!j j! j j

ve 1 2 ve 1 2

which free variables passed directly.

0 0

jtcode(t::;  ;s:: ; )j = 8t:::j j!8s:: :j j

ve 2 ve 2

In some implementation, a closure is represented by fold-

j !  j = 9k:9t::k:9t :: :h(t ) t !j j! j j)  t i

1 2 0 0 1 2 0

ing co de p ointer into the environment record [2]. Such repre-

j8s::: j = 9k:9t::k:9t :: :h(t ) t !8s:::j j)  t i

2 0 0 2 0

sentation maybeformulated as abstract closure conversion

with some mo di cations. However, closure representation

The co de typ es are translated to the corresp onding typ es

for such closures seems to need more p owerful typ e system.

describ ed in the previous section. The translation of a func-

tion typ e abstracts the kind of the typ e environment, k , and

7 Acknowledgements

the typ e of the value environment, t .Thetyp e environment

0

t is paired with the co de by using an existential typ e. Since

Wewould like to thank Andrzej Filinski, Mark Leone, Ben-

the typ e of a co de is instantiated by t, only the typ e envi-

jamin Pierce, and David Tarditi for their comments and

ronment of the closure can b e given to the co de. The co de

suggestions.

and the value environment are paired as in the simply-typ ed

case. The translation of 8 has the same structure as that of

References

an arrowtyp e.

The translation of expressions is summarized in Figure 8.

[1] M. Abadi, L. Cardelli, P.-L. Curien, and J.-J.Levy. Explicit

The kind of the typ e environment, the typ e environment,

substitutions. In ACM Symp. on Principles of Programming

and the typ e of the value environment are packed with the

Languages, 1990.

pair of the co de and the value environment. In the transla-

[2] A. W. App el. Compiling with Continuations.Cambridge

tion of application s, the typ e environment is obtained from

University Press, 1992.

a closure byanopen expression and the co de and the value

[3] A. W. App el and T. Jim. Continuation-passing, closure-

environment are obtained by pro jections. Then the typ e

passing style. In ACM Symp. on Principles of Programming

environment, the value environment, and the argumentof

Languages, 1989.

application are passed to the co de.

The typ e correctness of the translation is proven byin- [4] D. E. Britton. Heap storage management for the program-

ming language Pascal. Master's thesis, University of Arizona,

duction on the derivation of the translation. The typing

0

1975.

rules for  )  are essential to prove the cases for the

translations of closures.

[5] L. Cardelli. The functional abstract machine. Polymorphism,

1(1), 1983.

0

Theorem 5 (Typ e Correctness) If
; .e:  ; e ,

0

[6] C. Cousineau, P.-L. Curien, and M. Mauny. The categorical

then ;;
;jj` e : j j.

abstract machine. In Functional Programming Languages

and Computer Architecture, pages 50{64, 1985.

The op erational correctness of the translation can b e

proven using logical relations as in the simply typ ed case.

[7] H. Friedman. Equalitybetween functionals. In R. Parikh,

However, the de nition of the relations is more complicated

editor, Logic Col loquium '75. Norh-Holland, 1975.

b ecause of the presence of p olymorphic typ es and typ es of

[8] J. Hannan. A typ e system for closure conversion. In The

8;cl

the form  ( ) in the language  . The relations and the

i

Workshop on Types for Program Analysis,1995.

pro of app ear in the technical rep ort [22].

[9] R. Harp er and M. Lillibridge. Explicit p olymorphism and

CPS conversion. In ACM Symp. on Principles of Program-

6 Summary and Conclusions

ming Languages,1993.

[10] R. Harp er and M. Lillibridge. A typ e-theoretic approach

Wehave presented a typ e-theoretic account of closure con-

to higher-order mo dules. In ACM Symp. on Principles of

version for the simply-typ ed and p olymorphic -calculi. Our

Programming Languages, pages 123{137, 1994.

translations are unique in that they map well-typ ed source

[11] R. Harp er, D. MacQueen, and R. Milner. Standard

terms to well-typ ed target terms. This facilitates correctness

ML. Technical Rep ort ECS{LFCS{86{2, Lab oratory for

pro ofs, allows other typ e-directed transforms suchasCPS

the Foundations of Computer Science, Edinburgh University,

conversion or unboxing to b e applied after closure conver-

Mar. 1986.

sion, and supp orts run-time examination of typ es for tag-free

[12] R. Harp er and J. C. Mitchell. On the typ e structure of Stan-

garbage collection.

dard ML. ACM Transaction on Programming Languages

Wehave put the ideas in this pap er to practical use in

and Systems, 15(2), 1993.

two separate compilers for ML: one compiler is b eing used 11

0 0 0 0 0

; .e: vcode(t :: ; ; ; ) ; e
; .e :  ; e

te te ve ve

ve 1 2 ve

(vcl)

0 0

i as j !  j
; . hhe;  ; e ii :  !  ; pack  ; j j; j j with he ;e

1 2 ve 1 2 te ve

ve

0 0

; .e :  ; e
; .e :  !  ; e

2 1 1 1 2

2 1

0

; .e e :  ; open e as k ;t ;t

1 2 2 te te ve

1

(app)

with y : ht ) t !j j!j jt i

te ve 1 2 ve

0

in ( y ) t ( y ) e

1 te 2

2

0 0 0 0

;t::;  ) ; e
; .e :  ; e
; .e: tcode(t :: ;

ve ve te te

ve ve

(tcl)

0 0

i as j8t::: j
; . hhe;  ; e ii : 8t::: ; pack  ; j j; j j with he ;e

ve 2 te ve

ve

0

; .e: 8t::: ; e

0

; .e  :  [=t] ; open e as k ;t ;t

te te ve

(tapp)

with y : ht ) t !8t:::j jt i

te ve ve

in ( y ) t ( y ) j j

1 te 2

Figure 8: Closure Representation

[13] R. Harp er and G. Morrisett. Compiling p olymorphism using [27] B. C. Pierce and D. N. Turner. Simple typ e-theoretic foun-

intensional typ e analysis. In ACM Symp. on Principles of dations for ob ject-oriented programming. Journal of Func-

Programming Languages, pages 130{141, 1995. tional Programming, 4(2):207{247, Apr. 1994. A preliminary

version app eared in Principles of Programming Languages,

[14] T. Johnsson. Lamb da lifting: Transforming programs to re-

1993, and as UniversityofEdinburgh technical rep ort ECS-

cursive equations. In Functional Programming Language and

LFCS-92-225, under the title \Ob ject-Oriented Program-

Computer Architecture, LNCS 201, pages 190{203. Springer-

ming Without RecursiveTyp es".

Verlag, 1985.

[28] G. D. Plotkin. Lamb da-de nability in the full typ e hierarchy.

[15] R. Kelsey and P. Hudak. Realistic compilation by program

In To H.B.Curry: Essays on Combinatory Logic, Lambda

translation {detailed summary {. In ACM Symp. on Prin-

Calculus and Formalism. Academic Press, 1980.

ciples of Programming Languages, pages 281{292, 1989.

[29] U. S. Reddy. Ob jects as closures. In Proc. ACM Conf. Lisp

[16] D. Kranz et al. Orbit: An optimizing compiler for Scheme.

and Functional Programming, 1988.

In Proc. of the SIGPLAN '86 Symp. on Compiler Construc-

tion, 1986. [30] J. C. Reynolds. De nitional interpreters for higher-order

programming languages. In Proceedings of the Annual ACM

[17] P. Landin. The mechanical evaluation of expressions. Com-

Conference, pages 717{740, 1972.

puter Journal, 6:308{320, 1964.

[31] Z. Shao and A. W. App el. Space-ecient closure represen-

[18] X. Leroy.Unboxed ob jects and p olymorphic typing. In ACM

tations. In Proc. ACM Conf. Lisp and Functional Program-

Symp. on Principles of Programming Languages, 1992.

ming, 1994.

[19] X. Leroy. Manifest typ es, mo dules, and separate compila-

[32] Z. Shao and A. W. App el. A typ e-based compiler for Stan-

tion. In ACM Symp. on Principles of Programming Lan-

dard ML. In Programming Language Design and Its imple-

guages, pages 109{122, 1994.

menation, pages 116{129, 1995.

[20] D. MacQueen. Mo dules for Standard ML. In Proc. ACM

[33] R. Statman. Completeness, invariance, and lambda-

Conf. Lisp and Functional Programming, pages 198{207,

de nability. Journal of Symbolic Logic, 47:17{26, 1982.

1984. Revised version app ears in [11].

[34] R. Statman. Logical relations and the typ ed -calculus. In-

[21] R. Milner, M. Tofte, and R. Harp er. The De nition of Stan-

formation and Control, 65, 1985.

dardML. MIT Press, 1990.

[35] G. L. Steele Jr. Rabbit: A compiler for Scheme. Master's

[22] Y. Minamide, G. Morrisett, and R. Harp er. Typ ed closure

thesis, MIT, 1978.

conversion. Technical Rep ort CMU{CS{95{171, Scho ol of

Computer Science, Carnegie Mellon University, July 1995. [36] W. W. Tait. Intensional interpretation of functionals of nite

typ e. Journal of Symbolic Logic, 32(2), 1967.

[23] J. C. Mitchell and G. D. Plotkin. Abstract typ es haveexis-

tential typ e. ACM Transaction on Programming Languages [37] A. Tolmach. Tag-free garbage collection using explicit typ e

and Systems, 10(3), 1988. parameters. In Proc. ACM Conf. Lisp and Functional Pro-

gramming, pages 1{11, June 1994.

[24] G. Morrisett, M. Felleisen, and R. Harp er. Abstract mo dels

of memory management. In Functional Programming Lan- [38] M. Wand and P. Steckler. Selective and lightweight closure

guages and Computer Architecture, pages 66{77, June 1995. conversion. In ACM Symp. on Principles of Programming

Languages, 1994.

[25] R. Morrison, A. Dearle, R. Connor, and A. L. Brown. An

ad ho c approach to the implementation of p olymorphism.

ACM Transaction on Programming Languages and Systems,

13(3), 1991.

[26] A. Ohori. A compilation metho d for ML-style p olymorphic

record calculi. In ACM Symp. on Principles of Programming

Languages, 1992. 12