An Interpretation of Standard ML in Type Theory

Home , Syntactic sugar

An Interpretation of Standard ML in

Typ e Theory

Rob ert Harp er Christopher Stone

June 27, 1997

CMU-CS-97-147

Scho ol of Computer Science

Carnegie Mellon University

Pittsburgh, PA 15213

This rep ort also app ears as Fox Memorandum CMU-CS-FOX-97-01

This researchwas sp onsored in part by the Advanced Research Pro jects Agency CSTO under the title

\The Fox Pro ject: Advanced Languages for Systems Software", ARPA Order No. C533, issued by ESC/ENS

under Contract No. F19628-95-C-0050, in part by the National Science Foundation under Grant No. CCR-

9502674, and in part by the US Army Research Oce under Grant No. DAAH04-94-G-0289. The views and

conclusions contained in this do cument are those of the authors and should not b e interpreted as representing

ocial p olicies, either expressed or implied, of the Advanced Research Pro jects Agency, the U.S. Government

or the National Science Foundation.

Keywords: Standard ML, typ e theory, semantics, programming language design, com-

pilation, translation, elab oration, static semantics, dynamic semantics

Abstract

We de ne an interpretation of Standard ML into typ e theory. The interpretation takes the

form of a set of elab oration rules reminiscent of the static semantics given in The De nition

of StandardML. In particular, the elab oration rules are given in a relational style, exploiting

indeterminacy to avoid over-commitment to sp eci c implementation techniques. Elab oration

consists of identi er scop e resolution, typ e checking and typ e inference, expansion of derived

forms, pattern compilation, overloading resolution, equality compilation, and the co ercive

asp ects of signature matching.

The underlying typ e theory is an explicitly-typ ed -calculus with pro duct, sum, function,

and recursivetyp es, together with mo dule typ es derived from the translucent sum formalism

of Harp er and Lillibridge. Programs of the typ e theory are given a typ e-passing dynamic

semantics compatible with constructs such as p olymorphic equality that rely on typ e analysis

at run-time.

This do cument sup ercedes the previous CMU CS technical rep orts CMU-CS-96-136 and

CMU-CS-96-136R. The revision re ects our exp erience in implementing the sp eci ed elab o-

rator, and includes several essential corrections and simpli cations to the presentation.

Contents

1 Intro duction 3

1.1 Overview ...... 3

1.2 Notes on Implementation ...... 4

1.3 Ma jor Di erences from Standard ML ...... 6

1.3.1 Value Restriction ...... 6

1.3.2 Abstyp e ...... 6

1.3.3 Lo cal and Higher-Order Functors ...... 6

1.3.4 Top-level ...... 7

1.4 Ma jor Technical Di erences from Version 2 ...... 7

1.4.1 Internal Language ...... 7

1.4.2 Datatyp es ...... 7

1.4.3 Generativity ...... 7

1.4.4 Subtyping ...... 8

1.4.5 Syntactic concatenation ...... 8

2 Internal Language Abstract Syntax 9

2.1 Constructors and Kinds ...... 9

2.2 Expressions ...... 10

2.3 Mo dules and Signatures ...... 11

2.4 Useful Abbreviations and Notation ...... 11

2.5 Bindings and Scop e ...... 14

3 Static Semantics 16

3.1 Intro duction ...... 16

3.2 Notation ...... 16

3.3 Judgment Forms ...... 17

3.4 Inference Rules ...... 18

3.4.1 Well-formed Declarations ...... 18

3.4.2 Well-formed Bindings ...... 18

3.4.3 Well-formed Kinds ...... 19

3.4.4 Well-formed Constructors ...... 19

3.4.5 Constructor Equivalence ...... 20

3.4.6 Well-formed Expressions ...... 21

3.4.7 Well-formed Signatures ...... 24

3.4.8 Signature Subtyping ...... 24

3.4.9 Signature Equivalence ...... 25

3.4.10 Well-formed Mo dules ...... 26

3.4.11 Valuability...... 27

4 Dynamic Semantics 29

4.1 Intro duction ...... 29

4.2 Transition Relation ...... 30

4.2.1 Search for Next Redex ...... 30 1

4.2.2 Reduction ...... 32

5 External Language 34

5.1 Notation ...... 34

5.2 Grammar of the Abstract Syntax ...... 34

5.3 Syntactic Restrictions ...... 36

6 Elab oration 37

6.1 Intro duction ...... 37

6.2 Notation ...... 38

6.3 Initial Basis ...... 39

6.4 Derived Forms ...... 39

6.5 Judgment Forms ...... 41

6.6 Translation Rules ...... 41

6.6.1 Expressions ...... 41

6.6.2 Matches ...... 44

6.6.3 Declarations ...... 45

6.6.4 Structure Expressions ...... 47

6.6.5 Structure Bindings ...... 48

6.6.6 Functor Bindings ...... 49

6.6.7 Sp eci cations ...... 49

6.6.8 Signature Expressions ...... 51

6.6.9 Typ e Expressions ...... 51

6.6.10 Typ e De nitions ...... 52

6.6.11 Typ e Descriptions ...... 52

6.6.12 EqualityTyp e Descriptions ...... 52

6.6.13 Datatyp e De nitions ...... 52

6.7 Polymorphic Instantiation ...... 54

6.8 Equality Compilation ...... 54

6.9 Pattern Compilation ...... 56

6.10 Co ercion Compilation ...... 59

6.11 Signature Patching ...... 61

6.12 Lo okup Rules ...... 62

6.12.1 Context Lo okup ...... 62

6.12.2 Signature Lo okup ...... 63

6.13 Overloading ...... 64

7 Prop erties 64

7.1 Prop erties of the Internal Language ...... 64

7.1.1 Static Semantics ...... 64

7.1.2 Dynamic Semantics ...... 67

7.1.3 Soundness of the Internal Language ...... 68

7.2 Prop erties of the Elab orator ...... 70

8 Acknowledgments 72 2

1 Intro duction

1.1 Overview

This do cument consists of a typ e-theoretic account of a variant of (Revised) Standard ML

[MTHM97 ], hereafter referred to simply as Standard ML or SML. The approach taken here is

to elab orate SML abstract syntax (the external language,orEL) into an explicitly-typ ed -

calculus (the internal language, or IL). The internal language is designed to b e as simple and

orthogonal as p ossible while still b eing able to represent the entire Standard ML language.

The translation is presented by a set of inference rules reminiscent of the static se-

mantics given in The De nition of Standard ML, with the internal language playing the

role of the static semantic ob jects of The De nition. The translation rules typically de ne

the translation of a phrase in terms of the translation of its constituent phrases, sub ject

to context-sensitive constraints expressed by the internal language typ e system. Context-

sensitive formation constraints are expressed bytyp e checking constraints on the translation.

Typ e propagation is controlled by acombination of the translucent sum formalism together

with the representation of abstract typ es as mo dules with opaque typ e comp onents. The

internal language ensures that abstraction is resp ected, and, moreover, provides the requisite

asso ciation of the abstract typ e to its representation at run-time.

We b elieve that lo oking at Standard ML language features in terms of how they translate

into typ e theory clari es a number of issues in the design of SML. For example, the notion

of \typ e generativity" is replaced by explicit control of typ e propagation.

The internal language may be shared among many di erent language descriptions given

in the style presented here. In particular, we envision the p ossibility of using the IL given

here (with very minor mo di cations) for Scheme, Caml Sp ecial Light, or Haskell. A more

long-term goal would be to see what changes would be needed|esp ecially with regards to

ob ject-oriented features|in order to handle Java or Mo dula-3.

The elab oration has application to language implementation as well, as it may b e viewed

as a reference implementation of a front-end for an SML compiler. In particular, we are

using this translation as a guide to our re-implementation of the TIL/ML compiler [HM95,

Mor95, Tar96, TMC 96]. Compilers for other languages de ned by interpretation into the

internal language could share the back end of the TIL/ML compiler; only a front-end need

be written for each sp eci c language.

There are some disadvantages to our approach. The translation of some SML language

features is quite complex. To some extent this is a direct re ection of the intrinsic complex-

ity of mechanisms such as datatyp e de nitions (which intro duce several mutually recursive

abstract typ es, each a multinary sum of multinary pro duct typ es) and p olymorphic, recur-

sive function bindings. However, ensuring that the invariants of our enco dings are resp ected

everywhere in the do cumentcan be tedious and error-prone.

Furthermore, understanding the elab oration requires understanding the internal language

as well, though this may be mitigated if the same internal language can be used for several

di erent external languages.

The typ e-theoretic interpretation of Standard ML is divided into three main parts. 3

Typ e Structure of the Internal Language. The internal language is an explicitly-typ ed

-calculus, with a second-class mo dules system.

The core of the internal language is based on the XML and calculi [HM93 , HMM90 ].

The constructors of kind (where is the kind of typ es) include partial and total function

typ es, record typ es, sum typ es, reference typ es, recursive typ es, and a single extensible

sum. Additionally, the constructors are extended with (restricted) tuples of constructors and

functions at the constructor level. Note that there are no p olymorphic typ es (p olytyp es) in

our system.

The mo dules system is based on the translucent sum or manifest typ e mo dules cal-

culi [HL94, Ler94]. In addition to translucent signatures, we have total and partial functor

signatures. Our subtyping relation on signatures involves only forgetting of typ e de nitions

and totality, and not dropping or reordering comp onents. This means that subtyping has

no run-time e ect.

The two levels are connected by the abilitytode ne mo dules lo cal to a core expression.

Dynamic Semantics of the Internal Language. The dynamic semantics is essentially

a contextual semantics [WF91]. The handling of references and exceptions is similar to

Harp er's account of p olymorphic references [Har93].

Elab oration. The translation is de ned by a series of translation judgments of the general

form

` EL-phrase ; IL-phrase : IL-classi er

where is an internal-language context extended with information mapping EL identi ers

to IL variables.

1.2 Notes on Implementation

This do cumentisintended as an exp eriment in formally sp ecifying the rst stage of the TIL

compiler, and additionally to see if this generates a plausible de nition for a language. We

are not advo cating that a compiler should generate exactly the IL co de given here, nor even

that the internal language of the compiler should be exactly the IL we present. However,

any implementation of an elab orator should be essentially equivalent to what we present,

and we suggest the compiler's internal language should be de nable in terms of the IL we

present here. Di erences we would exp ect in an actual implementation include:

The internal language is likely b e extended to make our derived forms into primitives,

p ossibly along with other de nable forms.

A compiler is likely to use a much more complicated pattern compiler, generating much

more ecient pattern-matching co de (in particular, making b etter use case).

Clausal function de nitions would not be sequenced through uses of the exception

mechanism. 4

A compiler is likely to use a much more ecient implementation of elab oration contexts,

avoiding the the sequential search which we have formalized.

Equality functions would be cached, so that multiple equality tests for values of the

same typ e would not generate multiple equality functions.

In order to achieve SML's typing b ehavior, lo cally-de ned typ es at the mo dule level are

hidden through renaming rather than through use of internal-language lo cal bindings.

For simplicity, all mo dule-level lo cal de nitions (including values) are translated in this

fashion, though this is not required, and could cause wasted space at run-time. An

implementation would use a more sophisticated criterion for which lo cal bindings to

rename. 5

1.3 Ma jor Di erences from Standard ML

1.3.1 Value Restriction

The value restriction used in this translation is di erent than that sp eci ed in SML.

We treat

val hrec i pat = expr and ::: and pat = expr

1 1 n n

as a derived form for

val hreci ( pat , :::, pat ) = (expr , :::,expr ) :

1 n 1 n

When v is a value, we treat the binding val h::t = v as completely equivalent to

val h = hd v and val t = tl v. Since in the latter cases h and t will not be gen-

eralized (hd and tl may raise exceptions!), h and t are not made p olymorphic in the

former case.

The translation allows variables in a val binding to be generalized if the translations

of the bindings are \valuable." At the external language level, this is equivalenttothe

right-hand side b eing a value, and the variable not b e in the argument of a constructor

pattern, unless the constructor in for a single-constructor datatyp e. Note that tuple-

patterns p ose no problem, since pro jection is a total function.

This corresp onds to the notion of \p olymorphism as substitution," in which

let val id =expr in expr end

is considered equivalent to fexpr =id gexpr when expr is a value.

Because of this di erence, a few variables that would have b een p olymorphic according

to the SML sp eci cation will not be generalized in this treatment.

1.3.2 Abstyp e

We do not consider abstype declarations in this do cument b ecause abstract data typ es

can be easily created using the SML mo dule system instead. There would be no technical

diculties in including abstype , if desired.

1.3.3 Lo cal and Higher-Order Functors

Our external language p ermits structure and functor declarations within a let or local

declarations, and also within structure and functor declarations; this is a re ection of the

fact that the internal language has lo cal and higher-order mo dules.

These higher-order mo dules are based on the translucent sum formalism [HL94]. As

this is compatible with rst-class mo dules (which are not included in this de nition), our

higher-order functors propagate less typ e-sharing information than those in the system of

MacQueen and Tofte [MT94 ]. Finding a clean typ e-theoretic description of this latter system

is the sub ject of current research. 6

1.3.4 Top-level

Since we allow lo cally-de ned mo dules in our external language, it suces to consider pro-

grams to be closed expressions of typ e ans , where ans is a xed base typ e of answers. We

do not explicitly consider the translation of SML top-level declarations.

Note that this do es not require an implementation to accept only complete programs of

some xed typ e. For example, a batch compiler may exp ect a sequence of structure, functor,

and signature bindings (SML top-level declarations, p ossibly separately compiled), which

are then \logically" treated as a sequence of declarations in a wrapp er generated by the

compiler. For a UNIX system, for example, the wrapp er might b e along the lines of:

=> ~1 let in 0 end handle

where ans is chosen to b e the typ e int and a program returns either 0 for normal termination

or ~1 for an uncaught exception.

To enable this interpretation, weviewsignature declarations as simple \macros," de n-

ing abbreviations for signatures. The translation assumes abbreviations have previously b een

expanded out in the program b o dy.

1.4 Ma jor Technical Di erences from Version 2

1.4.1 Internal Language

Some minor changes have been made to the internal language, for purp oses of ecient im-

plementation (e.g., the unbundling of mutual recursion and pro jection op erations at the

constructor and expression levels), or for the purp oses of a cleaner elab oration or inter-

nal language (e.g., the generalization of the kind structure, and the replacement of partial

destructuring op erations with total versions at the expression level).

1.4.2 Datatyp es

The rule for datatyp es has b een simpli ed; additionally the internal language has been ex-

tended to allow all valid SML datatyp es to elab orate. However, certain datatyp es that SML

de nes as admitting equalitywould require p olymorphic recursion to implement this equality

function. Since our language do es not currently admit p olymorphic recursion (which would

corresp ond to recursive functors) these datatyp es do not admit equality in our formulation.

1.4.3 Generativity

A technical problem with our presentation caused us to reject some legal Standard ML

programs, b ecause of typ e information was not tracked prop erly. This problem involved

abstract typ es de ned in anonymous structure expressions, de ned lo cally in let or local

at the mo dule level, or hidden by SML's transparent ascription (strexp : sigexp). This

has been corrected by:

1. Restricting the EL to named form at the mo dule level, following Leroy [Ler96]. This

can always be achieved by a simple prepass over the program. (The grammar in

Section 5 shows what we mean by named form.) 7

2. In the case that let and local mo dule forms de ne abstract typ es lo cally, in the

translation we augment the b o dies of these forms with extra \hidden" elds containing

these abstract typ es. In conjunction with the restriction to named form, this has the

e ect of causing typ es concealed by transparent ascription to be renamed rather than

dropp ed entirely.

Although the internal language mo dule system presented here do es not have most-sp eci c

signatures in general, we also ensure that all mo dules generated by the elab orator do have

most-sp eci c signatures. This means that the elab orator never requires \guessing" of signa-

tures for mo dules such as functor applications.

1.4.4 Subtyping

We have dropp ed the implicit subsumption between total and partial function typ es; every

expression now has a unique most-sp eci c typ es up to equivalence. Unfortunately this means

datatyp e and exception constructors must now be handled sp ecially when used as function

values. However, a full subtyping relation would seem to be overkill|at least until features

such as ob jects are added to the internal language.

1.4.5 Syntactic concatenation

Rather than using the starred structure convention for general concatenation of mo dules, we

use a syntactic concatenation of structure eld bindings. This includes renaming to prevent

ill-formed constructions where two elds share the same lab el.

For simplicity, the rules essentially augment the bodies of let and local with al l the lo cally-de ned

quantities. Most of these|including all value comp onents and transparenttyp e comp onents|are obviously

unnecessary and undesirable in an actual implementation. 8

2 Internal Language Abstract Syntax

2.1 Constructors and Kinds

con ::= var typ e variables

j Int j Float j Char j base typ es

j frdecs g record typ e

j con Ref reference typ e

j con *con partial function typ e

j con !con total function typ e

j Tagged extensible sum typ e

j con Tag exception-tag typ e

j (lab 7!con ;:::;lab 7!con ) (lab elled) sum typ e

hlab i 1 1 n n

j mod :lab mo dule pro jection

j var :knd :con constructor-level nonrecursive function

j con constructor-level xp oint

j con con constructor application

j flab =con ;:::;lab =con g records of constructors

1 1 n n

j con record pro jection

lab

rdecs ::= empty

j rdecs ; rdec sequence

rdec ::= lab :con record eld typ e

knd ::= kind of typ es

j flab :knd ;:::;lab :knd g constructor tuple kinds

1 1 n n

j knd )knd constructor function kinds

Figure 1: Constructors and Kinds

The syntax h i denotes a phrase which may optionally app ear. 9

2.2 Expressions

exp ::= scon constants

j var variables

j loc memory lo cations

j tag exception tags

j x fbnds end mutually-recursive functions

j exp exp application

j frbnds g record expression

j exp record pro jection

lab

j handle exp with exp handle exception

con

j raise exp raise exception

con

j ref exp allo cate new ref cell

j get exp dereference

j set (exp ; exp ) assignment

con

j roll exp co erce into typ e

j unroll exp co erce from typ e

j @ exp co erce from partial to total function

con

j inj exp injection into sum

lab

con

j proj exp total pro jection from sum

lab

con

j case exp of exp ;:::;exp end sum case analysis

1 n

tag [con ] extend typ e Tagged j new

j tag (exp ; exp ) injection into typ e Tagged

0 00 000

j iftagof exp is exp then exp else exp exception tag case analysis

j mod :lab mo dule pro jection

j exp = exp ; exp = exp ;::: equalities at base typ es

Int Float

1 2 1 2

rbnds ::= empty

j rbnds ; rbnd sequence

rbnd ::= lab =exp record eld binding

fbnds ::= empty

j fbnds ; fbnd sequence

0 0

fbnd ::= var (var :con ):con 7!exp function binding

labs ::= lab j labs :lab sequence of lab els

path ::= var j var :labs path (quali ed variable)

Figure 2: Expressions 10

2.3 Mo dules and Signatures

mod ::= var mo dule variable

j [ sbnds ] structure

j var :sig :mod functor

j modmod functor application

j mod :lab pro jection from structure

j mod :sig signature ascription

sbnds ::= structure eld bindings

j sbnds ; sbnd

sbnd ::= lab .bnd

bnd ::= var =con constructor binding

j var =exp expression binding

j var =mod mo dule binding

sig ::= [ sdecs ] structure signature

j (var :sig )*sig partial functor signature

j (var :sig )!sig total functor signature

sdecs ::= structure eld declarations

j sdecs ; sdec

sdec ::= lab .dec

decs ::= declaration lists

j decs; dec

dec ::= var :con expression variable declaration

j var :sig mo dule variable declaration

j var :knd opaque typ e declaration

j var :knd =con transparent typ e declaration

j loc :con typ ed lo cations

j tag :con typ ed exception tag

Figure 3: Mo dules and Signatures

2.4 Useful Abbreviations and Notation

For readability,we often elide the internal names (var 's) when writing out sbnds (and

sdecs ). In all cases it should b e immediately obvious how to consistently restore these

with fresh variables.

0 0 0 0

Weuse sig *sig and sig !sig to abbreviate (var :sig )*sig and (var :sig )!sig resp ec-

tively, where var is not free in sig .

Many grammatical classes (labs , decs , rdecs , rbnds , fbnds , sdecs , sbnds , etc.) sp ecify

lists of elements. For each of these classes we de ne a binary app end op eration, written 11

with a comma. For example, we de ne

decs ; := decs

0 0 0 0

decs ; (decs ; dec ) := (decs ; decs ); dec

with analogous de nitions for all the other classes listed ab ove.

It is useful to de ne the following very general syntactic categories of program phrases

and program phrase classi ers:

phrase ::= exp class ::= con

j mod j sig

j con j knd

The notation fphrase =var gphrase denotes the capture-free substitution of phrase for

free o ccurrences of var within phrase .

For consision, we often abbreviate structure bindings lab .var =phrase as lab =phrase ,

(and similarly signature bindings lab .var :class as lab : class ) when the lo cal name is

not used. In all cases it should b e obvious how to consistently insert fresh variables to

correct these omissions.

as shorthand for phrase ; ; phrase We o ccasionally use the abbreviation (phrase )

1 n i

i=1

(where the phrases are comma-separated).

The syntactic values of the language are de ned in Figure 4. We view each class of

syntactic values (class ) as subsets of the corresp onding class in the abstract syntax

(class ). 12

exp ::= scon mod ::= path

v v

j loc j [sbnds ]

j tag j var :sig :mod

j path

j frbnds g bnd ::= var =exp

v v v

j x fbnds end j var =mod

j x fbnds end j var =con

con

j inj exp

lab

) sbnds ::= j tag (exp ; exp

v v v

con

j roll exp j sbnds ; sbnd

v v v

j @ exp

rbnds ::= sbnd ::= lab :bnd

v v v

j rbnds ; rbnd

v v

rbnd ::= lab =exp

v v

val ::= exp

j mod

j con

Figure 4: IL values 13

2.5 Bindings and Scop e

We de ne the functions BV () and dom() for various bindings, declarations, and lists thereof:

Function De nition

BV (dec ) BV (var : con ) = var

BV (var : knd ) = var

BV (var : knd =con ) = var

BV (var : sig ) = var

BV (loc :con ) = loc

BV (tag :con ) = tag

BV (decs ) BV (dec ; ; dec ) = fBV (dec ); ; BV (dec )g

1 n 1 n

BV (sdecs ) BV (lab .dec ; ; lab .dec ) = fBV (dec ); ; BV (dec )g

1 1 n n 1 n

BV (bnd ) BV (var =exp ) = var

BV (var =con ) = var

BV (var =mod ) = var

BV (sbnds ) BV (lab .bnd ; ; lab .bnd ) = fBV (bnd ); ; BV (bnd )g

1 1 n n 1 n

dom(sdecs ) dom(lab .dec ; ; lab .dec ) = flab ; ; lab g

1 1 n n 1 n

dom(rdecs ) dom(lab :con ; ; lab :con ) = flab ; ; lab g

1 1 n n 1 n 14

The scop es of b ound variables are given by the following table:

Binding Phrase Bound Vars Scope

0 0

x fbnds ; var (var :con ):exp 7!; fbnds end var entire phrase

" var exp

var :knd :con var con

sbnd ; sbnds BV (sbnd ) sbnds

var :sig :mod var mod

sdec ; sdecs BV (sdec ) sdecs

0 0

var :sig *sig var sig

0 0

var :sig !sig var sig

We follow standard practice and identify all phrases which di er only with resp ect to

bound variables, lo cations, and exception names. We use the notation FV (phrase ) to denote

the set of free variables in phrase. A phrase is said to be closed if it has no free variables

(though it may contain free lo cations or tags). 15

3 Static Semantics

3.1 Intro duction

In this section we de ne the well-formedness and typing judgments for the internal language.

Points of interest include:

There are no metatsyntactic \semantic ob jects" in the sense of the De nition.

The rules are explicitly formulated so that a judgment holds only if its constituents

(declaration lists, etc.) are well-formed.

The valuable expressions always evaluate to a value without side-e ects, referencing

the store, or raising exceptions. Similarly, valuable mo dules evaluate without side-

e ects, referencing the store, or raising exceptions. The purp ose of distinguishing

total and partial functions, as well as total and partial functors, is to sp ecify which

function/functor applications are valuable.

3.2 Notation

Within the static semantics, optional elements are enclosed by single brackets hi.

Within a single rule, either all such optional elements must o ccur, or none. 16

3.3 Judgment Forms

Section Judgment... Meaning...

3:4:1 ` decs ok decs is well-formed

decs ` dec ok dec is well-formed

3:4:2 decs ` bnd : dec bnd has declaration dec

3:4:3 decs ` knd : Kind knd is well-formed

3:4:4 decs ` con : knd con has kind knd

3:4:5 decs ` con con : knd constructor equivalence at kind knd

3:4:6 decs ` exp : con exp has typ e con

3:4:7 decs ` sdecs ok sdecs is well-formed

decs ` sig : Sig sig is well-formed

3:4:8 decs ` sdecs sdecs comp onent-wise subtyping

decs ` sig sig : Sig signature subtyping

3:4:9 decs ` sdecs sdecs comp onent-wise equivalence

decs ` sig sig : Sig signature equivalence

3:4:10 decs ` sbnds : sdecs sbnds has declaration list sdecs

decs ` mod : sig mod has signature sig

3:4:11 decs ` exp # con exp is valuable with typ e con

decs ` mod # sig mod is valuable with signature sig

decs ` exp #

decs ` sbnds #

decs ` mod # 17

3.4 Inference Rules

3.4.1 Well-formed Declarations

` decs ok

(1)

` ok

decs ` dec ok

(2)

` decs ; dec ok

decs ` dec ok

decs ` knd : Kind var 62 BV (decs )

(3)

decs ` var :knd ok

decs ` con : knd var 62 BV (decs )

(4)

decs ` var :knd =con ok

decs ` con : var 62 BV (decs )

(5)

decs ` var :con ok

decs ` sig : Sig var 62 BV (decs )

(6)

decs ` var :sig ok

decs ` con con Ref : loc 62 BV (decs )

(7)

decs ` loc :con ok

decs ` con con Tag : tag 62 BV (decs )

(8)

decs ` tag :con ok

3.4.2 Well-formed Bindings

decs ` bnd : dec

decs ` con : knd

(9)

decs ` var =con : var :knd

decs ` con con : knd

(10)

decs ` var =con : var :knd =con

decs ` exp : con

(11)

decs ` var =exp : var :con

0 0

decs ` mod : sig decs ` sig sig : Sig

(12)

decs ` var =mod : var :sig 18

3.4.3 Well-formed Kinds

decs ` knd : Kind

(13)

decs ` :Kind

lab ;:::;lab distinct n 0

1 n

(14)

decs `flab :knd ;:::;lab : knd g : Kind

1 1 n n

decs ` knd : Kind decs ` knd : Kind

(15)

decs ` knd )knd : Kind

3.4.4 Well-formed Constructors

decs ` con : knd

` decs ok

0 00

decs = decs ; var : knd h=con i; decs

(16)

decs ` var : knd

(17)

decs ` Tagged :

decs ` con :

(18)

decs ` con Ref :

decs ` con :

(19)

decs ` con Tag :

decs ` con : decs ` con :

(20)

decs ` con *con :

decs ` con : decs ` con :

(21)

decs ` con !con :

lab ;:::;lab distinct

1 n

decs ` con : decs ` con :

1 n

(22)

decs `flab :con ;:::;lab :con g :

1 1 n n

hi 2 1::ni

lab ;:::;lab distinct

1 n

decs ` con : decs ` con :

1 n

(23)

decs ` (lab 7!con ;:::;lab 7!con ):

1 1 n n

hlab i

lab ;:::;lab distinct n 0

1 n

decs ` con : knd decs ` con : knd

1 1 n n

(24)

decs `flab =con ;:::;lab =con g : flab : knd ;:::;lab :knd g

1 1 1 n 1 1 1 n 19

i 2 1::n

decs ` con : flab : knd ;:::;lab :knd g

1 1 n n

(25)

decs ` con : knd

lab i

decs ; var :knd ` con : knd

(26)

decs ` var :knd :con : knd )knd

decs ` con : knd )knd

(27)

decs ` con : knd

0 0

decs ` con : knd )knd decs ` con : knd

(28)

decs ` con con : knd

decs ` mod :[sdecs ; lab .var :knd ; sdecs ]

(29)

decs ` mod :lab : knd

3.4.5 Constructor Equivalence

decs ` con con : knd

` decs ok

0 00

decs = decs ; var :knd =con ; decs

(30)

decs ` var con : knd

Rule 30: The well-formedness judgment ` decs ok guarantees that FV (con ) \ BV (decs )=;.

decs ` mod :[sdecs ; lab :knd =con ; sdecs ]

BV (sdecs ) \ FV (con )= ;

(31)

decs ` mod :lab con : knd

Rule 31: The pro jection must yield a valid constructor with resp ect to the ambient context,

decs . This can always b e arranged through use of the self rules (Rules 101 and 102).

0 0

decs ` con con : decs ` con con :

1 2

(32)

0 0

decs ` con *con con *con :

1 2

0 0

decs ` con con : decs ` con con :

1 2

(33)

0 0

decs ` con !con con !con :

1 2

decs ` con con :

(34)

decs ` con Ref con Ref :

decs ` con con :

(35)

decs ` con Tag con Tag :

lab ;:::;lab distinct

1 n

: 8i 2 1::n : decs ` con con

(36)

decs `flab : con ; ; lab :con g flab :con ; ; lab :con g :

1 1 n n 1 n

1 n 20

Rule 36: To b e equivalent, two IL record typ es must have equivalent comp onents with the same

lab els in the same order.

i 2 1::n

decs ` con con : flab :knd ;:::;lab :knd g

1 1 n n

(37)

decs ` con con : knd

lab lab i

i i

i 2 1::n

decs ` con flab :con ;:::;lab :con g : flab :knd ;:::;lab : knd g

1 1 n n 1 1 n n

(38)

decs ` con con : knd

lab i i

decs ` con con : knd )knd

(39)

decs ` con con : knd

hi 2 1::ni

0 0

decs ` con con : decs ` con con :

1 n

(40)

decs ` (lab 7!con ;:::;lab 7!con )

hlab i 1 1 n n

0 0

(lab 7!con ;:::;lab 7!con ):

1 n

hlab i

1 n

decs ` con con : knd )knd

1 2

0 0

decs ` con con : knd

1 2

(41)

0 0

decs ` con con con con : knd

1 2

0 0

decs ; var : knd ` con : knd decs ` con : knd

(42)

0 0

decs ` (var :knd :con ) con fcon =var gcon : knd

decs ` con : knd

(43)

decs ` con con : knd

(44)

decs ` con con : knd

0 00

decs ` con con : knd

(45)

decs ` con con : knd

3.4.6 Well-formed Expressions

decs ` exp : con

` decs ok

0 00

decs = decs ; var :con ; decs

(46)

decs ` var : con

` decs ok

0 00

decs = decs ; loc :con ; decs

(47)

decs ` loc : con 21

` decs ok

0 00

decs = decs ; tag :con ; decs

(48)

decs ` tag : con

0 0 0

decs ` exp : con *con decs ` exp : con

(49)

decs ` exp exp : con

0 0 0

decs ` exp : con !con decs ` exp : con

(50)

decs ` exp exp : con

0 0 n 0

8i 2 1::n : decs ; (var :con *con ) ; var :con ` exp : con

j i i

j j j =1 i

Rule 52 do es not apply.

(51)

0 0 n

decs ` x (var (var :con ):con 7!exp ) end :

i i

i i i=1

0 0

f1:con *con ;:::;n:con *con g

1 n

var 62 FV exp

decs ; var :con ` exp # con

(52)

0 0 0

decs ` x var (var :con ):con 7!exp end : f1:con !con g

lab ; ; lab distinct

1 n

decs ` exp : con decs ` exp : con

1 n

(53)

decs `flab =exp ; ; lab =exp g : flab :con ; ; lab :con g

1 n 1 1 n n

1 n

Rule 53: For the record bindings to b e well-typ ed with resp ect to the declarations, they must

have the same lab els in the same order (with no duplicate lab els) and comp onents must be

well-typ ed elementwise.

decs ` exp : frdecs ; lab :con ; rdecs g

(54)

decs ` exp : con

lab

decs ` exp : con decs ` exp : Tagged*con

(55)

decs ` handle exp with exp : con

decs ` exp : Tagged decs ` con :

(56)

con

decs ` raise exp : con

decs ` con :

(57)

decs ` new tag [con ]:con Tag

decs ` exp : con

(58)

con

decs ` ref exp : con Ref

decs ` exp : con Ref

(59)

decs ` get exp : con

decs ` exp : con Ref

decs ` exp : con

(60)

decs ` set (exp ; exp ):Unit 22

0 00

decs ` con ( ( con )) hcon i :

lab

0 0 00

decs ` exp :( (con ( con ))) hcon i

lab

(61)

con

decs ` roll exp : con

0 00

decs ` con ( ( con )) hcon i :

lab

decs ` exp : con

(62)

0 0 00

decs ` unroll exp :( (con ( con ))) hcon i

lab

decs ` exp : con !con

(63)

decs ` @ exp : con *con

i 2 1::n

con = (lab 7!con ;:::;lab 7!con )

lab 1 1 n n

decs ` exp : con

(64)

con

exp : con decs ` inj

lab

i 2 1::n

decs ` exp : (lab 7!con ;:::;lab 7!con )

lab 1 1 n n

(65)

( lab 7!con ;:::;lab 7!con )

n n

1 1

lab

exp : con decs ` proj

lab

n 1

con =(lab 7!con ;:::;lab 7!con )

1 1 n n

decs ` exp : con

8i 2 1::n : decs ` exp : (lab 7!con ;:::;lab 7!con )*con

lab 1 1 n n

(66)

con 0

decs ` case exp of exp ;:::;exp end : con

1 n

decs ` exp : con Tag decs ` exp : con

(67)

decs ` tag (exp ; exp ):Tagged

decs ` exp : Tagged decs ` exp : con Tag

00 0 000 0

decs ` exp : con *con decs ` exp : con

(68)

0 00 000 0

decs ` iftagof exp is exp then exp else exp : con

decs ` mod :[sdecs ; lab :con ; sdecs ]

BV (sdecs ) \ FV (con )= ;

(69)

decs ` mod :lab : con

Rule 69: A pro jection is only well-formed if the result is typable. If mod is a value, the

pro jection is always well-formed.

0 0

decs ` exp : con decs ` con con :

(70)

decs ` exp : con 23

3.4.7 Well-formed Signatures

decs ` sdecs ok

` decs ok

(71)

decs ` ok

decs ` dec ok

decs ; dec ` sdecs ok

lab 62 dom(sdecs )

(72)

decs ` lab .dec ; sdecs ok

decs ` sig : Sig

decs ` sdecs ok

(73)

decs ` [sdecs ]:Sig

decs ; var :sig ` sig : Sig

(74)

decs ` var : sig *sig : Sig

decs ; var :sig ` sig : Sig

(75)

decs ` var : sig !sig : Sig

3.4.8 Signature Subtyping

decs ` sdecs sdecs

(76)

decs `

decs ; var :knd =con ` sdecs sdecs

(77)

decs ` lab .var :knd =con ; sdecs lab .var :knd ; sdecs

decs ` sig sig : Sig

decs ; var :sig ` sdecs sdecs

(78)

decs ` lab .var :sig ; sdecs lab .var :sig ; sdecs

decs ` lab :dec lab : dec

decs ; dec ` sdecs sdecs

(79)

0 0

decs ` lab .dec ; sdecs lab .dec ; sdecs 24

decs ` sig sig : Sig

decs ` sdecs sdecs

(80)

decs ` [sdecs ] [sdecs ]:Sig

0 0

decs ` sig sig : Sig decs ; var :sig ` sig sig : Sig

2 1 2

1 2

(81)

0 0

decs ` var :sig *sig var : sig *sig : Sig

1 2

0 0

decs ` sig sig : Sig decs ; var :sig ` sig sig : Sig

2 1 2

1 2

(82)

0 0

decs ` var :sig !sig var : sig *sig : Sig

1 2

0 0

decs ` sig sig : Sig decs ; var :sig ` sig sig : Sig

2 1 2

1 2

(83)

0 0

decs ` var :sig !sig var : sig !sig : Sig

1 2

3.4.9 Signature Equivalence

decs ` sdecs sdecs

(84)

decs `

decs ; var :knd ` sdecs sdecs

(85)

decs ` lab .var :knd ; sdecs lab .var :knd ; sdecs

decs ` con con : knd decs ; var :knd =con ` sdecs sdecs

(86)

decs ` lab .var :knd =con ; sdecs lab .var :knd =con ; sdecs

decs ` con con : decs ; var :con ` sdecs sdecs

(87)

decs ` lab .var :con ; sdecs lab .var :con ; sdecs

decs ` sig sig : knd decs ; var :sig ` sdecs sdecs

(88)

decs ` lab .var :sig ; sdecs lab .var :sig ; sdecs

decs ` sig sig : Sig

decs ` sdecs sdecs

(89)

decs ` [sdecs ] [sdecs ]:Sig

0 0

decs ` sig sig : Sig decs ; var :sig ` sig sig : Sig

1 2 1

1 2

(90)

0 0

decs ` var :sig *sig var : sig *sig : Sig

1 2

0 0

decs ` sig sig : Sig decs ; var :sig ` sig sig : Sig

1 2 1

1 2

(91)

0 0

decs ` var :sig !sig var : sig !sig : Sig

1 2

1 2 25

3.4.10 Well-formed Mo dules

decs ` sbnds : sdecs

(92)

decs ` :

decs ` bnd : dec decs ; dec ` sbnds : sdecs

(93)

decs ` lab .bnd ; sbnds : lab .dec ; sdecs

decs ` mod : sig

` decs ok

decs = decs ; var :sig ; decs

(94)

decs ` var : sig

decs ` sbnds : sdecs

(95)

decs ` [sbnds ]: [sdecs ]

decs ; var :sig ` mod : sig

(96)

decs ` var :sig :mod : var :sig *sig

decs ; var :sig ` mod # sig

(97)

decs ` var :sig :mod : var :sig !sig

0 0

decs ` mod : sig *sig decs ` mod : sig

(98)

decs ` modmod : sig

Rule 98: Only functors with non-dep endenttyp es may b e applied. Dep endencies can b e elimi-

nated by uses of the subtyping and equivalence rules. If the argumentisa value, dep endencies

can always b e eliminated.

decs ` mod :[sdecs ; lab :sig ; sdecs ]

BV (sdecs ) \ FV (sig )=;

(99)

decs ` mod :lab : sig

Rule 99: A pro jection is only well-formed if the result can b e given a signature in the ambient

context. If mod is a value, this can always o ccur.

decs ` mod : sig

(100)

decs ` mod :sig : sig

Rule 100: Ascription of a signature to a mo dule can maketyp es in mod abstract by forgetting

equations.

decs ` mod :[sdecs ; lab .var :knd ; sdecs ]

(101)

decs ` mod :[sdecs ; lab .var :knd =mod :lab ; sdecs ]

v v 26

Rule 101: The \self " rule. If mod :labs sp eci es a typ e and mod has a well-de ned value then

mod :labs mod :labs ;we add this fact to the signature.

decs ` mod :[sdecs ; lab .var :sig ; sdecs ]

decs ` mod :lab : sig

(102)

decs ` mod :[sdecs ; lab .var :sig ; sdecs ]

Rule 102: The \self " rule can b e recursively applied.

decs ` mod : sig decs ` sig sig : Sig

(103)

decs ` mod : sig

3.4.11 Valuability

decs ` exp # con

decs ` exp : con decs ` exp #

(104)

decs ` exp # con

decs ` mod # sig

decs ` mod : sig decs ` mod #

(105)

decs ` mod # sig

decs ` exp #

(106)

decs ` exp #

decs ` mod #

(107)

decs ` mod :lab #

decs ` exp # con !con decs ` exp #

1 2

(108)

decs ` exp exp #

1 2

decs ` exp # decs ` exp #

1 n

(109)

decs `flab =exp ; ; lab =exp g#

1 n

decs ` exp #

(110)

decs ` exp #

lab

decs ` exp #

(111)

con

decs ` roll exp #

decs ` exp #

(112)

decs ` unroll exp # 27

decs ` exp #

(113)

con

decs ` inj exp #

lab

(114)

con

decs ` proj exp #

lab

decs ` exp # decs ` exp #

(115)

decs ` tag (exp ; exp ) #

decs ` exp #

decs ` exp # decs ` exp #

1 n

(116)

con

decs ` case exp of exp ;:::;exp end #

1 n

decs ` sbnds #

(117)

decs `#

decs ` exp # con decs ; var :con ` sbnds #

(118)

decs ` lab .var =exp ; sbnds #

decs ` con : knd decs ; var :knd =con ` sbnds #

(119)

decs ` lab .var =con ; sbnds #

decs ` mod # sig decs ; var :sig ` sbnds #

(120)

decs ` lab .var =mod ; sbnds #

decs ` mod #

(121)

decs ` mod #

decs ` sbnds #

(122)

decs ` [sbnds ] #

decs ` mod # sig !sig decs ` mod #

(123)

decs ` modmod #

decs ` mod #

(124)

decs ` mod :lab #

decs ` mod #

(125)

decs ` mod :sig # 28

4 Dynamic Semantics

4.1 Intro duction

The dynamic semantics of the internal language is a call-by-value op erational semantics

presented as a rewriting system on states of an abstract machine. The presentation is

strongly in uenced by the work of Plotkin [Plo81] and Wright and Felleisen [WF91], and is

a signi cant departure from the framework employed in The De nition. In particular we

employ a smal l step semantics in which transitions represent basic evaluation steps of an

abstract machine. We rely on substitution, rather than environments; values are particular

expressions of the language. Exception propagation is handled by explicitly maintaining

the evaluation context, rather than relying on implicit rules for exception propagation. We

maintain a store for assignable cells, as in The De nition,anda typing context whichtyp es

lo cations and dynamically-created tags asso ciated with valuesoftyp e Tagged; these are the

only extra-linguistic constructs in the formalism. As WrightandFelleisen have demonstrated

these could b e made part of the language by intro ducing a letref construct.

Each state of the abstract machine is a four-tuple of the form

(;;E;phrase );

where

isatyping context (decs ) for lo cations and tags created at run-time. This maintains

a record of what exception tags and lo cations have b een allo cated, and is also used in

our soundness pro ofs.

is a nite mapping from lo cations (loc 's) typ ed in to expression values (exp ). The

syntax for all internal language values app eared in Figure 4.

E is a stack of evaluation frames (see Figure 5). This represents an implementa-

tion's control stack, or equivalently, the current continuation. App ending two stacks

corresp onds to comp osition of continuations; accordingly,we write E E for the con-

catenation of E and E , de ned in the obvious way. The meta-variable R ranges over

control stacks that do not contain a frame of the form \handle [] with exp ".

phrase is an expression, mo dule, or constructor.

We let range over the set of terminal states, where a state is called terminal if it has

one of the forms:

(;; []; val ) normal termination

con

(;; []; raise exp ) uncaught exception

All other states are called nonterminal.

The dynamic semantics is a transition relation ,! between states. As usual, we

denote the re exive, transitive closure of ,! by ,! . 29

F ::= [] exp

j exp []

j frbnds ; lab =[]; rbnds g

j []

lab

j handle [] with exp

con

j raise []

con

j ref []

j get []

j set ([]; exp )

j set (exp ; [])

con

j roll []

j unroll []

j @ []

con

[] j inj

con

j proj []

con

j case [] of exp ;:::;exp end

1 n

j tag (exp ; [])

0 00 000

j iftagof [] is exp then exp else exp

00 000

j iftagof exp is [] then exp else exp

j []:lab

j [sbnds ; lab .var =[] ; sbnds ]

j [] mod

j mod []

j []: sig

E ::= []

j E F

Figure 5: Evaluation Frames

4.2 Transition Relation

4.2.1 Search for Next Redex

0 0

(;;E;exp exp ) ,! (;;E ([] exp ); exp ) (126)

(;;E ([] exp ); exp ) ,! (;;E (exp []); exp ) (127)

v v

(;;E;frbnds ; lab =exp ; rbnds g) ,!

(;;E frbnds ; lab =[]; rbnds g; exp )

(128)

if exp is not a value

0 0

g) (129) g; exp ) ,! (;;E;frbnds ; lab =exp ; rbnds (;;E frbnds ; lab =[]; rbnds

v v v v v v 30

0 0

; lab =exp ; rbnds g; exp ) ,! (;;E frbnds ; lab =[]; rbnds

v v v

0 0

; lab =[]; rbnds g; exp ) (;;E frbnds ; lab =exp ; rbnds

(130)

v v v

if exp is not a value

(;;E; exp ) ,! (;;E ( []); exp )

lab lab

(131)

if exp is not a x value

0 0

(;;E;handle exp with exp ) ,! (;;E (handle [] with exp ); exp ) (132)

con con

(;;E;raise exp ) ,! (;;E (raise []); exp )

(133)

if exp is not a value

con con

(;;E (raise []); exp ) ,! (;;E;raise exp ) (134)

v v

con con

(;;E;ref exp ) ,! (;;E (ref []); exp ) (135)

(;;E;get exp ) ,! (;;E (get []); exp ) (136)

0 0

(;;E;set (exp ; exp )) ,! (;;E (set ([]; exp )); exp ) (137)

(;;E (set ([]; exp )); exp ) ,! (;;E (set (exp ; [])); exp ) (138)

v v

con con

(;;E;roll exp ) ,! (;;E (roll []); exp )

(139)

if exp is not a value

con con

(;;E (roll []); exp ) ,! (;;E;roll exp ) (140)

v v

(;;E;unroll exp ) ,! (;;E (unroll []); exp ) (141)

(;;E;@ exp ) ,! (;;E (@ []); exp )

(142)

if exp isnotavalue

(;;E (@ []); exp ) ,! (;;E;@ exp ) (143)

v v

con con

(;;E;inj exp ) ,! (;;E (inj []); exp )

lab lab

(144)

if exp is not avalue

con con

(;;E (inj []); exp ) ,! (;;E;inj exp ) (145)

v v

lab lab

con con

(;;E;proj exp ) ,! (;;E (proj []); exp ) (146)

lab lab 31

0 0

(;;E;tag (exp ; exp )) ,! (;;E (tag ([]; exp )); exp )

(147)

if exp or exp is not a value

(;;E tag ([] ; exp ); exp ) ,! (;;E (tag (exp ; [])); exp )

(148)

v v

0 0

)) (149) ) ,! (;;E;tag (exp ; exp (;;E (tag (exp ; [])); exp

v v v v

0 00 000

(;;E;iftagof exp is exp then exp else exp ) ,!

(150)

0 00 000

(;;E (iftagof [] is exp then exp else exp ); exp )

0 00 000

(;;E (iftagof [] is exp then exp else exp ); exp ) ,!

(151)

00 000 0

(;;E (iftagof exp is [] then exp else exp ); exp )

(;;E;[lab .var =phrase ; sbnds ]) ,!

(152)

(;;E [lab .var =[]; sbnds ]; phrase )

(;;E [sbnds ; lab .var =[] ;

lab .var =phrase ; sbnds ]; val ) ,!

(153)

(;;E [sbnds ; lab .var =val ;

lab .var =[]; fval =var gsbnds ]; fval =var gphrase )

(;;E [sbnds ; lab .var =[]]; val ) ,! (;;E;[sbnds ; lab .var =val ]) (154)

v v

(;;E;mod :lab ) ,! (;;E []:lab ; mod ) (155)

0 0

(;;E;modmod ) ,! (;;E ([] mod ); mod ) (156)

(;;E ([] mod ); mod ) ,! (;;E (mod []); mod ) (157)

v v

(;;E;mod :sig ) ,! (;;E []:sig ; mod ) (158)

4.2.2 Reduction

(;;E (exp []); exp ) ,!

v v

1 0 n 0

(;;E;fexp =var gfexp =var gfexp =var gexp )

v v v j

1 n

(159)

where 8k 2 1::n :

k 0 0 n

exp = h@ i x (var (var :con ):con 7!exp ) end

v i i

i i i=1

(;;E ( []); frbnds ; lab =exp ; rbnds g) ,! (;;E;exp ) (160)

lab v v v v

(;;E (handle [] with exp ); exp ) ,! (;;E;exp ) (161)

v v 32

con

(;;E (ref []); exp ) ,! ([loc :con ];[loc 7!exp ];E;loc )

v v

(162)

if loc 62 BV ()

(;;E (get []); loc ) ,! (;;E;exp )

(163)

if (loc )= exp

(;;E (set (loc ; [])); exp ) ,! (;[loc 7!exp ];E;fg) (164)

v v

con

exp ) ,! (;;E;exp ) (165) (;;E (unroll []); roll

v v

(;;E;new tag [con ]) ,! ([tag :con Tag ];;E;tag )

(166)

if tag 62 BV ()

con con

exp ) ,! (;;E;exp ) (167) (;;E (proj []); inj

v v

lab

(lab 7!con ;:::;lab 7!con )

n n

1 1

con

(;;E (case [] of exp ;:::;exp end); inj exp ) ,!

1 n

lab

(168)

(;;E;exp exp )

00 000

(;;E (iftagof tag (tag ; exp ) is [] then exp else exp ); tag ) ,!

(169)

(;;E;exp exp )

00 000 0

(;;E (iftagof tag (tag ; exp ) is [] then exp else exp ); tag ) ,!

000

(;;E;exp ) (170)

if tag 6= tag

(;;E ((var :sig :mod )[]); mod ) ,!

(171)

(;;E;fmod =var gmod )

(;;E []:sig ; mod ) ,! (;;E;mod ) (172)

v v

con

(;;E (handle [] with exp ) R ; raise exp ) ,!

(173)

(;;E;exp exp )

con ans

(;; R ; raise exp ) ,! (;; []; raise exp ) (174)

v v 33

5 External Language

5.1 Notation

As in the De nition, optional elements are enclosed by single brackets hi or double brackets

hh ii. For the purp oses of this grammar, all optional choices are completely indep endent.

5.2 Grammar of the Abstract Syntax

The (disjoint) base syntax classes include scon (syntactic constants), tyvar (typ e variables),

id (core-level identi ers), tycon (typ e constructors), strid (structure identi ers), and funid

(functor identi ers). As in The De nition of Standard ML, all but the rst two have corre-

sp onding \long" forms, containing a nite sequence of structure identi ers as as pre x.

expr ::= scon

j longid

j { lab = expr , ,lab = expr }

1 n

j let strdec in expr end

j expr expr

j expr : ty

j expr handle match

j raise expr

j fn match

j expr = expr

1 2

mrule ::= pat => expr

match ::= mrule

j mrule | match

strdec ::=

j val (tyvar , , tyvar ) pat = exp

1 n

j val (tyvar , , tyvar ) rec pat = exp

1 n

j strdec strdec

1 2

j open longid longid

1 n

j exception id

j exception id of ty

j exception id = longid

j local strdec in strdec end

1 2

j type tybind

j datatype datbind

j datatype (tyvar , ,tyvar ) tycon =

1 n

datatype (tyvar , ,tyvar ) longtycon

1 n

j structure strbind

j functor funbind 34

tybind ::= (tyvar , , tyvar ) tycon = ty hand tybind i

1 n

datbind ::= (tyvar , , tyvar ) tycon = conbind

1 n

hand datbind i

conbind ::= id hof ty ihh| conbind ii

strexp ::= longstrid

j struct strdec end

j longfunid (longstrid )

j longstrid : sigexp

j longstrid :> sigexp

j let strdec in strexp end

spec ::=

j val id : ty

j type typdesc

j eqtype etypdesc

j datatype datbind

j datatype ( tyvar , ,tyvar ) tycon =

1 n

datatype (tyvar , ,tyvar ) longtycon

1 n

j exception id

j exception id of ty

j structure strid : sigexp

j functor funid (strid : sigexp ) : sigexp

j include sigexp

j spec spec

1 2

j spec sharing type longid = longid

1 2

typdesc ::= (tyvar , , tyvar ) tycon hand typdesc i

1 n

j (tyvar , , tyvar ) tycon = ty hand typdesc i

1 n

etypdesc ::= (tyvar , , tyvar ) tycon hand etypdesc i

1 n

sigexp ::= sig spec end

j sigexp where type (tyvar , , tyvar ) longtycon = ty

1 n

pat ::= scon

j longid

j pat : ty

j longid pat

j {lab = pat , ,lab = pat h,... i}

1 n

j pat as pat

1 2

j ref pat 35

ty ::= base

j tyvar

j {lab : ty , , lab : ty }

1 n

j (ty , ,ty ) longtycon

1 n

j ty -> ty

strbind ::= strid = strexp hand strbind i

funbind ::= funid (strid : sigexp ) = strexp hand funbind i

5.3 Syntactic Restrictions

No record expression, record pattern, or record typ e maycontain duplicate eld lab els.

No tyvar may app ear more than once in a single sequence.

Any typ e variable o ccuring in a conbind must also app ear in the enclosing datbind .

Anytyp e variable app earing in the ty of a where type must app ear in the typ e variable

sequence.

No val, type , datatype , exception , structure , signature or functor strdec or

spec may bind the same identi er twice; this applies also to value constructors within

a datbind .

In a val rec declaration, the pattern must b e of the form

{ lab =id , ,lab =id }

1 1 n n

and the expression must be of the form

{lab =fn match , ,lab =fn match }:

1 1 n n

The \... " EL-notation may not app ear in the pattern. 36

6 Elab oration

6.1 Intro duction

In addition to typ e-checking and typ e-reconstruction, the elab orator p erforms the following

tasks:

1. Datatyp es are expanded into structures and signatures whose comp onents include

an abstract typ e (implemented as a recursive sum typ e);

op erations corresp onding to datatyp e constructors as values (those datatyp e con-

structors which carry values are total functions, while non value-carrying con-

structors are constants of the abstract typ e);

an \exp ose" op eration which presents datatyp e values as elements of a (tagged)

sum typ e.

The \generativity" of datatyp es is handled via signature ascription; the typ e is made

opaque and is therefore inequivalenttoany previous typ e. The matching of datatyp es

in signatures reduces to the matching of substructures.

2. Polymorphism (including equality p olymorphism) is enco ded as a use of the mo dules

system. Polymorphic values are translated into functors, which can be explicitly in-

stantiated with structures of typ es (and equality functions). More precisely, the functor

takes a structure containing typ e constructors of kind (for typ es which the p olymor-

phic value requires to b e equalitytyp es, the structure also contains equality functions

for the instantiating typ es); the functor returns a structure whose single comp onent

(with lab el \it") is the p olymorphic value made monomorphic by instantiating it with

the given typ es.

3. Equality p olymorphism, as just mentioned, and equalitytyp es are handled by explicitly

constructing and passing equality functions as needed. We do not explicitly distinguish

typ es that admit equality; rather, atyp e admits equality i the equality compiler can

create an equality function for this typ e.

4. Wemake explicit the propagation of abstract typ es de ned lo cally to mo dule-level let

and local constructors, or hidden through the use of transparent signature ascription.

In particular, the \hiding" e ect of these constructs on typ es is implemented as renam-

ing rather than simple scoping. This is necessary to obtain the same typ e propagation

b ehavior as the stamp-based semantics of The De nition.

5. Patterns are expanded into uses of the appropriate record pro jections and datatyp e

deconstructors. Thus the elab oration sp eci es a reference pattern compiler.

6. Each series of external language bindings (strdec ) elab orates into a structure, contain-

ing a comp onentforevery variable b ound in the external language. External language

identi ers corresp ond to internal language labels. 37

7. Some structure lab els are explicitly marked with an asterisk (lab ). This indicates that

the structure is \op en" for the purp oses of identi er lo okup. (See the lo okup rules for

more details.)

8. All co ercive asp ects of the signature matching relation (the reordering and forgetting

of comp onents) are handled by intro ducing explicit co ercion functors witnessing the

relation. This makes the order and number of comp onents of a structure apparent

from its signature, though there is a run-time cost to signature ascription.

6.2 Notation

The overbar function maps each EL identi er to an IL lab el. We assume that

this function is injective, that the range is coin nite in the set of IL lab els, and that

identi ers of di erent classes map to di erent lab els. In particular, we assume that

the parser distinguishes b etween the classes of expression variables, typ e constructors,

typ e variables, structure identi ers, signature identi ers, and functor identi ers. How-

ever, wedonotdistinguish b etween an identi er b eing used as an expression variable,

datatyp e constructor, or exception constructor.

The distinguished lab els \eq ", \exp ose ", \it", and \tag " used by the elab orator are not

in the range of the overbar mapping, and other lab els chosen to b e fresh are similarly

not in the range of the mapping.

We extend the overbar mapping comp onent-wise to long identi ers, which thus map

to sequences of lab els.

Optional elements are enclosed in single or double angle brackets. For each rule, either

all or none of the elements in single angle brackets must be present, and similarly all

or none of the elements in double angle brackets must be present. Single and double

angle brackets in the same rule represent two independent choices.

In some cases, the optional element notation is insucient. Therefore, we have the

additional notation

9 8

element

= <

; :

element

which means that either element or element must be present. If there are multiple

1 2

such choices in a single rule, this means that either the rst element should always be

chosen in all cases, or the second element must be chosen in all cases.

An extension of this notation gives the choices subscripts. Then all choices with the

same subscript must agree (all rst element or all second element) but twochoices with

di erent subscripts are completely indep endent.

The elab oration maintains an elab oration context , which is simply a list of structure

declarations (sdecs ) except that we allow duplicate lab els. When app ears in an IL

judgment where decs is exp ected, there is an implicit co ercion which drops all top-level 38

lab els and all signature declarations. We extend the notion of variable bindings from

Section 2.5 with the following:

Function De nition

BV () BV (sdec ; ) = fBV (sdec )g[BV ()

dom() dom(sdec ; ) = fdom(sdec )g[ dom()

Binding Phrase Bound Vars Scope

sdec ; BV (sdec )

We use an op eration of \syntactic concatenation with renaming" for sbnds and, in

parallel, for sdecs . This is de ned by:

0 0 0 0

(++sbnds ):(++sdecs ):= sbnds : sdecs

h i 0 h i 0

(lab .bnd ; sbnds ++sbnds ):(lab .bnd ; sdecs ++sdecs ):=

h i 00 h i 00 h i 00

lab .bnd ; sbnds : lab .dec ; sdecs if lab 62 dom(sbnds )

h i hi hi

00 00 0 00 0 0

62 dom(sbnds ) .dec ; sdecs otherwise, where lab .bnd ; sbnds : lab lab

0 0 00 00

where sbnds ++sbnds : sdecs ++sdecs = sbnds : sdecs

6.3 Initial Basis

The elab orator assumes the presence of a structure basis :sig serving as the initial basis

basis

for the internal language. It must contain at least the following elds which de ne three

exceptions:

[ Bind : [tag: Unit Tag; Bind :Tagged];

Match : [tag: Unit Tag; Match :Tagged];

fail : [tag: Unit Tag; fail:Tagged]]:

6.4 Derived Forms

The translation also makes use of a number of derived forms of kinds, constructors, and

expressions. These are shown in Figure 6.

The representation of tuples as records with numb ered elds is copied from SML. The

enco ding of multi-argument functions as single-argument functions is also very standard, as

is the enco ding of b o oleans as a sum typ e.

The purp ose of the catch form is to serve as a sp ecial handler for the \fail" exception,

and to propagate all other exceptions. The fail exception is only used by the elab orator to

signal a failure in pattern-matching. 39

knd knd 7!f1:knd ;:::;n:knd g

1 n 1 n

knd 7!f1:knd ;:::;n:knd g

Unit 7!fg

17!Unit; 27!Unit Bo ol 7!

hlab i hlab i

con con 7!f1=con ; ; n=con g

1 n 1 n

(var ;:::;var ):con 7! var : :(f var =var gf var =var gcon )

1 n 1 1 n n

(con ;:::;con ) 7!f1=con ;:::;n=con g

1 n 1 n

(exp ; ; exp ) 7!f 1=exp ; ; n=exp g

1 n 1 n

0 0 0

x var (var :con ):con 7!exp end (var :con ):con :exp 7!

var 62 FV (exp )

(var :con ;:::;var :con ):con :exp 7! (var :con con ):con :

1 1 n n 1 n

f var =var gf var =var gexp

1 1 n n

var 62 FV (exp )

let bnd ;:::;bnd in exp end 7! [1=bnd ;:::;n=bnd ; (n + 1)=exp ]:(n +1)

1 n 1 n

con

fail 7! raise basis :fail :fail

con

catch exp with exp 7! handle exp with (var :Tagged:

con

iftagof var is basis :fail :tag then var :Unit :exp else raise var

var 62 FV (exp )

( con ;:::;con )

0 con

(exp ; exp ) 7! case exp of pproj

lab

con

0 0

:raise exp ;:::; var :con

lab

con

lab

var :con :proj var ;:::

lab

con

0 0

:raise var :con exp end

lab

= (lab 7!con ;:::;lab 7!con ) where con

hlab i 1 1 n n

hlab i

Bo ol

false 7! inj fg

Bo ol

true 7! inj fg

Bo ol

if exp then exp else exp 7! case exp of v ar :Bo ol :exp ;var:Bo ol :exp end

1 2 3 1 1 3 2 2

var 62 FV (exp ; exp 3)

exp and exp 7! if exp then exp else false

1 2 1 2

heq i heq i

(var ;:::;var ):exp 7! (var :[1 :[1.var : h; eq:var var *Bo oli ];:::;

1 1 1 1

n :[n.var : h; eq :var var *Bo oli ]]):

n n n n

[it=fvar :1 :1=var gfvar :n :n=var gexp ]

1 n

heq i heq i

8(var ;:::;var ):con 7! (var :[1 :[1.var : h; eq:var var *Bo oli ];:::;

1 1 1 1

n :[n.var : h; eq :var var *Bo oli ]]) !

n n n n

[it:fvar :1 :1=var gfvar :n :n=var gcon ]

1 n

Figure 6: Derived Forms 40

6.5 Judgment Forms

Judgment... Meaning...

` expr ; exp : con expression

` match ; exp : con pattern match

` strdec ; sbnds : sdecs declaration

` strexp ; mod : sig structure expression

` spec ; sdecs signature sp eci cation

` sigexp ; sig : Sig signature expression

` ty ; con : typ e expression

` tybind ; sbnds : sdecs type de nition

` datbind ; sbnds : sdecs datatype de nition

` labs ; path : class lo okup in

ctx

` labs ; path

ctx

decs ; path :sig ` labs ; labs : class lo okup in signature

sig

sig ` lab ; labs

sig

decs ` ; [sbnds ]: [sdecs ] p olymorphic instantiation

inst v

` pat ( exp : con else exp ; sbnds : sbnds pattern compilation

decs ` con ; exp equality compilation

eq v

decs ` path : sig sig ; mod : sig co ercion compilation

sub

decs ; path :sig ` sdec ; sbnd : sdec

sub

sig ` labs := con : knd ; sig : Sig imp ose de nition

sig ` labs := labs : knd ; sig : Sig imp ose sharing

6.6 Translation Rules

6.6.1 Expressions

` expr ; exp : con

(175)

` scon ; scon :typ e (scon )

Rule 175: We assume a meta-level function typ e whichgives the IL typ e of each constant.

longid ; path : con `

ctx

Rule 177 do es not apply.

(176)

` longid ; path : con

Rule 176: Monomorphic variables. 41

` longid ; path : con !con

ctx

(177)

` longid ; @ (path ): con *con

Rule 176: Monomorphic datatyp e or exception constructors. Because the IL has no sub-

sumption, these must b e co erced to a partial function typ e when used as function values (not

immediately applied).

longid ; path : sig ![it:con ] `

ctx

` ; mod : sig

inst

Rule 179 do es not apply.

(178)

` longid ; path (mod ):it : con

Rule 178: Instantiation of p olymorphic variables. All p olymorphic functions are translated

into total functors whose b o dy contains a single comp onent with the lab el \it". The mo dule

mod is the structure of typ es (and equality functions, if needed) that are used to instantiate

the p olymorphic function.

longid ; path : sig ![it:con !con ] `

ctx

` ; mod : sig

inst

(179)

` longid ; @ (path (mod ):it):con *con

Rule 179: Instantitaion of p olymorphic datatyp e constructors. As in Rule 176, wecoercetoa

partial function typ e.

a p ermutation of 1::n

var ; ; var 62 BV ()

1 n

lab < < lab

(1) (n)

` expr ; exp : con ` expr ; exp : con

1 n

1 1 n n

(180)

` { lab = expr ; ; lab = expr } ;

1 n

let var =exp ;:::;var =exp in f lab =var ; ; var =var g end :

1 n

(1) (1) (n) (n)

1 n

lab :con ; ; lab : con g f

(1) (1) (n) (n)

Rule 180: The order in which lab els app ear in the record typ e is signi cant for the IL but not

the EL, so in the translation we normalize record values and typ es by sorting the lab els with

some xed ordering <. The order in which e ects o ccur, however, is determined by the order

of the expressions in the EL.

` strdec ; sbnds : sdecs

var 62 BV () ; 1 .var :[sdecs ] ` expr ; exp : con

; var :[sdecs ] ` con con : ` con :

(181)

` let strdec in expr end ; let var =[mod ] in exp end : con 42

Rule 181: The \starred lab el" convention is used here to make the lo cally-de ned bindings

accessible while translating expr . The elab orator veri es that the translated expression can

be given a a typ e, whichmust not dep end on any abstract typ es (e.g., datatyp es) de ned in

strdec .

` expr ; exp : con *con

0 0 0

` expr ; exp : con

0 00

` con con :

(182)

0 0

` expr expr ; exp exp : con

Rule 182: General application.

` longid ; path : con !con

ctx

0 0 0

` expr ; exp : con

(183)

0 0

` longid expr ; exp exp : con

Rule 183: Application of a monomorphic datatyp e constructor, which is valuable if expr is

valuable.

` longid ; path : sig ![it:con !con ]

ctx

` ; mod : sig

inst

0 0 0

` expr ; exp : con

(184)

0 0

` longid expr ; (path (mod ):it) exp : con

Rule 184: Application of a p olymorphic datatyp e constructor, which is valuable if expr is

valuable.

` expr ; exp : con

0 0

` ty ; con : ` con con :

(185)

` expr : ty ; exp : con

Rule 185: Typ e constraints on expressions are veri ed, but do not app ear in the translation.

` expr ; exp : con

0 0

` match ; exp : Tagged*con

` con con :

var 62 BV ()

(186)

` expr handle match ;

handle exp with

con

(var :Tagged):con :(catch exp var with raise var ):

con

Rule 186: The handling expression exp var will fail if the handler pattern do es not matchthe

exception caughtby the IL handle,inwhich case we re-raise the exception. 43

` expr ; exp : Tagged ` con :

(187)

con

` raise expr ; raise exp : con

Rule 187: raise expressions can b e given any(valid) typ e. To preserve the prop erty that every

IL expression has a unique typ e up to equivalence, we annotate the IL raise with this typ e.

` match ; exp : con *con var 62 BV ()

1 2

(188)

` fn match ;

con

(var :con ):con :(catch Match :Match ): exp var with raise basis :

1 2

con *con

1 2

Rule 188: The application exp var will fail if the matchfails;we turn the failure into a match

exception. The resulting function has a partial typ e b ecause it can (syntactically) raise an

exception.

` expr ; exp : con ` expr ; exp : con

1 2

1 1 2 2

` con con : ` con ; exp

1 2 eq 1

(189)

` expr = expr ; exp (exp ; exp ): Bo ol

1 2 1 2

Rule 189: Translation of equality comparison; exp is the equality function generated by the

equality compiler and has typ e con con *Bo ol.

6.6.2 Matches

` match ; exp : con

0 0

var ; var 62 BV () ` con :

0 0

` pat ( var : con else basis :fail :fail ; sbnds : sdecs

; 1 .var :[sdecs ] ` expr ; exp : con

(190)

0 0 0

` pat => expr ; (var :con ):con :let var =[sbnds ] in exp end : con *con

Rule 190: The result of translating a match is a function that may fail if the match fails. The

IL let expression is well-formed b ecause the pattern compiler returns no typ e comp onents in

sbnds .

var 62 BV ()

` mrule ; exp : con *con

1 2

0 0 0

` match ; exp : con *con

1 2

0 0

` con *con con *con :

1 2

(191)

con

0 0

` mrule | match ; (var :con ):con :catch exp var with exp var : con *con

1 2

Rule 191: The failure of pattern matching in the rst clause is caught, and we try again with

the next clause. 44

6.6.3 Declarations

` strdec ; sbnds : sdecs

var 62 BV ()

` expr ; exp : con

; var :con ` pat ( var : con else basis : Bind :Bind ; sbnds : sdecs

(192)

` val () pat = expr ; 1.var =exp ; sbnds :1.var :con ; sdecs

Rule 192: Monomorphic, non-recursivevariable bindings.

sig =[heq i tyvar :[heq i tyvar .var : ;h; eq :var var *Bo oli ]; ;

1 1 1

p 1 1

heq i tyvar :[heq i tyvar .var : ; h; eq:var var *Bo oli ];

n n n

n n

]; ; :[1.var : h; eq:var var *Bo oli 1

m :[m.var : h; eq:var var *Bo oli ]]

; 1 .var :sig ` expr ; exp : con

; 1 .var :sig ` exp # con

Bind :Bind ( exp : con else pat ; sbnd ;:::;sbnd : sdec ;:::;sdec ; 1 .var :sig ` basis :

1 n 1 n p

8i 2 1::n :

sbnd = lab =exp

i i

sdec = lab :con

i i i

lab =(var :sig )![it=exp ] if ; var :sig ` sbnd # sdec

i p p i i

p i p

sbnd =

lab =exp if ` exp : con

i i

lab :(var :sig )![it:con ] if ; var :sig ` sbnd # sdec

i p i p i i

p p

sdec =

lab :con if ` exp : con

i i i

` val (heq i tyvar ; ; heq i tyvar ) pat = expr ;

1 n

0 0 0 0

sbnd ;:::;sbnd : sdec ;:::;sdec

1 n 1 n

(193)

Rule 193: Polymorphic, non-recursive val bindings. We assume a prepass which annotates

val declarations with the explicit typ e variables implicitly scop ed by that declaration. Typ e

inference mayintro duce m new typ e (or equalitytyp e) variables which not mentioned in the

source (as in val f = fn x => x or val f = fn x => (x=x)). In this formulation, some

variables in the pattern may b ecome p olymorphic while others may remain monomorphic.

0 0

Therefore, for each i, either sbnd and sdec must b oth cho ose the rst option (p olymorphic)

i i

or must b oth cho ose the second option (monomorphic). 45

sig =[heq i tyvar :[heq i tyvar .var : h; eq:var var *Bo oli ]; ;

1 1 1

p 1 1

heq i tyvar :[heq i tyvar .var : h; eq :var var *Bo oli ]

m m m

m m

]; ; 1 :[1.var : h; eq :var var *Bo oli

k :[k.var : h; eq:var var *Bo oli ]]

0 0 0 0 0

=; lab .var : sig ; id .var : con *con ; ; id .var :con *con

p 1 1 n n

1 1 n n

8i 2 1::n :

0 0 0

` match ; (var :con ):con :exp : con *con

i i i i

i i

00 00 00

If ` id ; path : con then path :exp ose ; path :tag aren't well-formed.

ctx i

0 0 0 0

exp = x var (var :con ):con 7!exp ; ; var (var :con ):con 7!exp end

1 1 m m

1 m

1 1 m m

n n

` val (heq i tyvar ; ; heq i tyvar )rec f(lab = id ) g = f(lab =fn match ) g ;

1 m i i i i

1 m

i=1 i=1

id =var :sig :[it= exp ];:::;id =var : sig :[it= exp ]:

1 p n p n

p 1 p

0 0

id :(var : sig )![it:con *con ];:::;id :(var :sig )![it:con *con ]

1 p 1 n p n

p p

1 n

(194)

Rule 194: This rule handles recursive val bindings. As in Rule 193, we assume that the implicit

scoping of explicit typ e variables has b een made explicit by a prepass over the EL. We also

assume that val rec ... and ... is syntactic sugar for a single val rec binding of a record

of functions. Since this rule do es not use the pattern compiler, wemust explicitly check that

we're do not rede ne datatyp e or exception constructors.

` strdec ; sbnds : sdecs

1 1 1

; sdecs ` strdec ; sbnds : sdecs

1 2 2 2

(195)

` strdec strdec ; sbnds ++sbnds : sdecs ++sdecs

1 2 1 2 1 2

Rule 195: We use the syntactic-concatenation-with-renaming op eration de ned in Section 6.2.

8i 2 1::n : ` longstrid ; path : sig

ctx

i i i

(196)

` open longstrid longstrid ;

1 n

1 =path ; ;n =path :1 :sig ; ;n : sig

1 n 1 n

` ty ; con : var 62 BV ()

(197)

` exception id of ty ;

0 0

id =[tag .var =new tag [con ]; id =(var : con ): Tagged:tag (var ; var )] :

id :[tag .var :con Tag; id :con !Tagged]

(198)

` exception id ;

id =[tag .var =new tag [Unit ]; id =tag (var ; fg)] :

id :[tag .var :Unit Tag ; id :Tagged]

` longid ; path :lab : con

ctx

` path :tag : con

(199)

` exception id = longid ;

id =[tag =path :tag ; id =path :lab ]:id :[tag:con ; id :con ] 46

Rule 199: Structures containing a \tag" comp onent are created by EL exception declrations

only.

var 62 BV ()

` strdec ; sbnds : sdecs

1 1 1

; 1 .var :[ sdecs ] ` strdec ; sbnds : sdecs

1 2 2

(200)

` local strdec in strdec end ;

1.var =[sbnds ]; sbnds :1.var :[sdecs ]; sdecs

1 2 1 2

Rule 200: We create bindings for all of the declarations, but the lo cal bindings are segregated

into a substructure inaccessible from the EL.

` tybind ; sbnds : sdecs

(201)

` type tybind ; sbnds : sdecs

` longtycon ; path :tycon : )

ctx

tycon .var : ) ; lab .dec ; ; lab .dec ] ` path :[

1 1 n n

lab = exp ose

(202)

` datatype (tyvar , ,tyvar ) tycon ;

1 m

= datatype ( tyvar , ,tyvar ) longtycon

1 m

0 0

=[ tycon tycon .var =path :tycon ; lab =path :lab ; ; lab =path :lab ]:

1 1 n n

0 0

=[ tycon tycon .var : ) =path :tycon ; lab =dec ; ; lab =dec ]

1 1 n n

Rule 202: SML '96 adds the ability to copydatatyp es. Only structures which are the transla-

tions of EL datatyp e declarations have an initial typ e comp onent and a nal comp onent named

\exp ose".

` datbind ; sbnds : sdecs

(203)

` datatype datbind ; sbnds : sdecs

` strbind ; sbnds : sdecs

(204)

` structure strbind ; sbnds : sdecs

` funbind ; sbnds : sdecs

(205)

` functor funbind ; sbnds : sdecs

6.6.4 Structure Expressions

` strexp ; mod : sig

` longstrid ; path : sig

ctx

(206)

` longstrid ; path : sig

` strdec ; sbnds : sdecs

(207)

` struct strdec end ; sbnds : sdecs 47

` longfunid ; path :(var :sig )*sig

ctx 1

f 1 2

` longstrid ; path : sig

ctx

` path : sig sig ; mod : sig

sub

0 00

` (var :sig )*sig sig *sig : Sig

(208)

0 00 00

` longfunid (longstrid ) ; (path : sig *sig ) mod : sig

Rule 208: We insert an explicit co ercion to drop and reorder comp onents of the argument

structure (which has signature sig ), in order to match the domain signature of the functor

(sig ). The signature sig is the most-sp eci c (and fully transparent) signature of the co erced

structure, whichmay exp ose more typ es (is a sub-signature of ) sig .

` longstrid ; path : sig ` sigexp ; sig : Sig

ctx

0 00

` path : sig sig ; mod : sig

sub

(209)

` longstrid : sigexp ; mod : sig

Rule 209: As in SML, ascribing a signature to a structure using \:" hides comp onents (this

hiding b eing accomplished here via an explicit co ercion), but allows the identity of the remain-

ing typ e comp onents to leak through. The rules for co ercions ensure that sig will be fully

transparent, maximizing propagation of typ e information.

` longstrid ; path : sig ` sigexp ; sig : Sig

ctx

0 00

` path : sig sig ; mod : sig

sub

(210)

0 0

` longstrid : sigexp ; (mod :sig ): sig

Rule 210: Ascribing a signature to a structure with :> not only hides comp onents, but restricts

information ab out typ es to that which app ears in the signature.

var 62 BV ()

` strdec ; sbnds : sdecs

; 1 .v ar :[sdecs ] ` strexp ; mod : sig

(211)

` let strdec in strexp end ;

[1.var =[sbnds ]; 2 =mod ]:[1.var :[sdecs ] ; 2 : sig ]

6.6.5 Structure Bindings

` strbind ; sbnds : sdecs

` strexp ; mod : sig h ` strexp ; mod : sig i

1 n

1 1 n n

(212)

` strid = strexp hand and strid = strexp i ;

1 n

strid =mod h; ; strid =mod i : strid :sig h; ; strid :sig i

1 1 n n 1 n

1 n 48

6.6.6 Functor Bindings

` funbind ; sbnds : sdecs

var 62 BV ()

` sigexp ; sig : Sig ; strid .var :sig ` strexp ; mod : sig

1 1

1 1 1 1

.i h

h ` sigexp ; sig : Sig ; strid .var :sig ` strexp ; mod : sig i

n n

n n n n

(213)

` funid ( strid : sigexp ) = strexp

1 1 1

hand and funid (strid : sigexp ) = strexp i ;

n 1 n

(funid =var :sig :mod : var :sig *sig ) :

1 1 1

1 i=1

(funid :var :sig *sig )

1 1

1 i=1

Rule 213: As for functions at the expression level, user-de ned functors are given partial functor

typ es.

6.6.7 Sp eci cations

` spec ; sdecs

(214)

` ;

TV (ty )=;

` ty ; con :

(215)

` val id : ty ; id :con

Rule 215: Avalue sp eci ation is monomorphic if the EL typ e contains no typ e variables. (The

set of typ e variables of the EL typ e ty is denoted byTV(ty ).)

TV (ty )= fheq i tyvar ; ; heq i tyvar g 6= ;

1 n

sig =[heq i tyvar :[heq i tyvar .var : h; eq:var var *Bo oli ]; ;

1 1 1

p 1 1

heq i tyvar heq i tyvar .var : h; eq:var var *Bo oli ]] :[

n n n

n n

; lab .var :sig ` ty ; con :

(216)

` val id : ty ; id :(var : sig )![it:con ]

Rule 216: Sp eci cation of a p olymorphic value.

` typdesc ; sdecs

(217)

` type typdesc ; sdecs

` etypdesc ; sdecs

(218)

` eqtype etypdesc ; sdecs

` ty ; con :

(219)

` exception id of ty ; id :[ tag: con Tag; id :con !Tagged] 49

(220)

` exception id ; id :[tag :con Tag; id :Tagged]

` datbind ; sbnd :1 :[sdecs ]

(221)

` datatype datbind ; sdecs

longtycon ; path :tycon : ) `

ctx

` path :[ tycon : ) ; sdecs ]

(222)

; ` datatype (tyvar , , tyvar ) tycon

1 n

= datatype (tyvar , ,tyvar ) longtycon

1 n

0 0

:[ tycon tycon .var : ) =path :tycon ; sdecs ]

` sigexp ; sig : Sig

(223)

` structure strid : sigexp ; strid : sig

` sigexp ; sig : Sig

var 62 BV ()

0 0

strid .var :sig ` sigexp ; sig : Sig ;

(224)

0 0

` functor funid (strid : sigexp ) : sigexp ; funid :(var :sig *sig )

` sigexp ; [sdecs ]: Sig

(225)

` include sigexp ; sdecs

` spec ; sdecs ; sdecs ` spec ; sdecs

1 1 2

1 2

` sdecs ; sdecs ok

1 2

(226)

` spec spec ; sdecs ; sdecs

1 2

Rule 226: We disallow redeclaring EL identi ers in a signature. In the presence of include,

we cannot syntactically restrict the EL to guarantee the syntactic concatenation of sdecs and

sdecs will b e well-formed.

` spec ; sig : Sig

var 62 BV ()

longid ; labs : knd ; var :sig `

1 sig

; var :sig ` longid ; labs : knd

sig 2

; var :sig ` var :labs var :labs : knd

8 9

0 0

sig ` labs := labs : knd ; sig : Sig

< =

1 2

: ;

0 0

sig ` labs := labs : knd ; sig : Sig

2 1

(227)

` spec sharing type longid = longid ; sig : Sig

1 2

Rule 227: Atyp e comp onent in a signature is considered abstract, and hence eligible to app ear

in a sharing constraint, if it is equivalenttoanopaquetyp e (typ e comp onentthatisnotatyp e

abbreviation) in the spec .

We nd the two opaque typ es to which the given comp onents are equivalent, and patch the

signature such that the opaque typ e with the smaller scop e b ecomes a typ e abbreviation for

the other opaque typ e. 50

6.6.8 Signature Expressions

` sigexp ; sig : Sig

` spec ; sig : Sig

(228)

` sig spec end ; sig : Sig

var ; var ; ; var 62 BV ()

1 n

` sigexp ; sig : Sig

; tyvar .var : ; ; tyvar .var : ` ty ; con :

1 n

; var :sig ` longtycon ; labs : )

sig

; var :sig ` var :labs var :labs : )

sig ` labs := (var ; ; var ):con : ) ; sig : Sig

wt 1 n

(229)

` sigexp where type (tyvar , ,tyvar ) longtycon = ty ; sig : Sig

1 n

Rule 229: Note that typ e EL typ e expression ty is evaluated using the ambient scop e.

6.6.9 Typ e Expressions

` ty ; con :

(230)

` int ; Int :

Rule 230: There are analogous rules for the other base typ es (Float, Bo ol, Unit, String ,andso

on), and the base typ e constructors (ref).

(231)

` exn ; Tagged :

` tyvar ; path :

ctx

(232)

` tyvar ; path :

` ty ; con : ` ty ; con :

1 n

a p ermutation of 1::n

lab < < lab

(1) (n)

(233)

` {lab :ty ; ; lab :ty } ; flab :con ; ; lab : con g :

1 n

(1) (1) (n) (n)

1 n

longtycon ; path : ) `

ctx

8i 2 1::n : ` ty ; con :

(234)

` (ty , ,ty ) longtycon ; path (con ; ; con ):

1 n

0 0

` ty ; con : ` ty ; con :

(235)

` ty -> ty ; con *con :

Rule 235: There is no way to express total (!)typ es in the external language. 51

6.6.10 Typ e De nitions

` tybind ; sbnds : sdecs

var ; ; var 62 BV ()

1 n

tyvar .var : ; ; tyvar .var : ` ty ; con : ;

1 n

con = (var ; ; var ):con

1 n

h ` tybind ; sbnds : sdecs var 62 FV (sdecs )i

(236)

` (tyvar , ,tyvar ) tycon = ty hand tybind i ;

1 n

tycon .var =con h; sbnds i : tycon .var : ) = con h; sdecs i

6.6.11 Typ e Descriptions

` typdesc ; [sdecs ]

h ` typdesc ; sdecs i

(237)

` type (tyvar ; ; tyvar ) id h and typdesc i ; id : ) h; sdecs i

1 n

var ; ; var 62 BV ()

1 n

; tyvar .var : ; ; tyvar .var : ` ty ; con :

1 n

con := (var ; ; var ):con

1 n

h ` typdesc ; sdecs var 62 FV sdecs i

(238)

` type (tyvar ; ; tyvar ) id = ty hh and typdesc ii ; id : ) =con h; sdecs i

1 n

6.6.12 Equality Typ e Descriptions

` etypdesc ; sdecs

The p olymorphic equality functions de ned by this judgment the same as the default \struc-

tural" equality supplied by SML. Essentially,atyp e is an equalitytyp e if and only if wecan

use this judgmentto create the equality function at that typ e.

tyvar :[ tyvar .var : ; eq :var var *Bo ol]; ; sig =[

1 1 1

1 1

tyvar :[tyvar .var : ; eq :var var *Bo ol]]

n n n

n n

0 0

con = var (var : : : tyvar tyvar ; ; var :tyvar tyvar )

1 1 n n

h ` etypdesc ; sdecs i

(239)

` (tyvar ; ; tyvar ) id hand etypdesc i ;

1 n

n 0

id :[id .var : ) ; eq: (var :sig )![it:con con *Bo ol]]h; sdecs i

6.6.13 Datatyp e De nitions

` datbind ; sbnds : sdecs

Without loss of generality, we may assume that there are no duplicate tyvar 's among the

bindings. 52

0 dt n dt n

:= ; tycon .var : ) ; tycon .var : )

1 p

00 0

:= ; .var : ; tyvar .var : ; ; tyvar

pn 11

p 11 pn

var ;:::;var 62 BV ( )

1 n

9 8

unit

= <

; con : `

; :

sum

con := id 7!con ; ; id 7!con

i1 i1 im im

i i

0 dt dt sum n

con := ((var ;:::;var ):(((var ;:::;var ): con ) ))

i j 1 jn

i 1 p j j j =1

con := con (var ;:::;var )

i i1 in

i i

heq i

(in )

(i1)

):exp h ` 8(var ;:::;var ):con ; (var ;:::;var i

eq i1 in i i

in i i1 i

dt 0

tycon .var =con ; mod := [

i i

heq i

(in )

(i1)

i ):exp heq=(var ;:::;var

i in i1

9 8

sum

con

(inj roll fg)

> >

= <

; (for j 2 1::m ) id =(var ;:::;var ):

i ij i1 in

sum

> >

con

; :

var ) (var :con ):con :roll (inj

ij i

sum

exp ose =(var ;:::;var ):(var:con ):con :unroll var ]: sig

i1 in i

n dt

sig := [ tycon .var : ) = var ;

i i

heq i

(in )

(i1)

; ):var var *Bo oli heq :8(var ;:::;var

i i i

i1 in

9 8

con

= <

; (for j 2 1::m ) id :8(var ;:::;var ):

i ij i1 in

; :

con !con

ij i

sum

exp ose :8(var ;:::;var ):con !con ]

i1 in i

i i

dt 0 dt 0

mod := [ =mod ;:::; =mod ] tycon .var tycon .var tycon tycon =con ; ; =con ;

1 p

1 p 1 p

1 1 p p

dt n dt n

tycon .var : tycon .var : tycon :sig ;:::;tycon :sig ] ) ;:::; ) ; sig := [

1 p 1 1 p p

1 p

8 9 8 9

< = < =

or or

` (tyvar , ,tyvar ) tycon = id | |id

11 1m

11 1n 1 1

: ; : ;

of ty of ty

11 1m

and and

8 9 8 9

< = < =

(tyvar , ,tyvar ) tycon =id | |id ;

p1 pm

p1 pn p p

: ; : ;

of ty

1 =(mod :sig ):1 :sig

(240) 53

6.7 Polymorphic Instantiation

decs ` ; [sbnds ] : [sdecs ]

inst v

decs ` con :

hdecs ` con ; exp i

eq v

hhdecs ` ; [sbnds ]:[sdecs ]ii

inst v

(241)

decs ` ; [lab =[lab .var =con h; eq=exp i]hh; sbnds ii]:

inst v v

[lab :[ lab .var : =con h; eq:var var *Bo oli]]hh; sdecs ii

Rule 241 Nondeterministically cho ose typ es and the corresp onding equality functions so as to

match a fully-transparent signature.

6.8 Equality Compilation

decs ` con ; exp

(242)

decs ` Int ; (var :Int; var :Int:):Bo ol(var = var )

eq 1 2 1 Int 2

Rule 242: We assume primitive equality op erations already exist at typ e Int, with similar rules

for the other base typ es.

con = flab :con ;:::;lab :con g

1 1 n n

decs ` con ; exp decs ` con ; exp

eq 1 eq n

1 n

(243)

decs ` con ;

(var :con ; var :con ):Bo ol:exp ( var ; var ) and

1 2 lab 1 lab 2

1 1

and exp ( var ; var )

lab 1 lab 2

n n n

Rule 243: Records are compared comp onent-wise for equality.

8i 2 1::n : con := (con ;:::;con )

hlab i hlbl i 1 n

decs ` con ; exp

eq i

con con

0 0 0

exp = var :con :exp (proj var ; pproj (var ; ))

lab 2

i i lab lab

i i

(244)

decs ` con ;

con 0 0

(var :con ; var :con ):Bo ol:catch case var of exp ;:::;exp end with false

1 2 1

1 n

Rule 244: Values of a sum typ e are equal if they have the same tag and the tagged values are

equal. 54

k 2 1::n

0 00

con =( ( con )) con

i i

8i 2 1::n :

0 0 0 00

con := ( (con ( con ))) con

decs = decs ; var :[1.var : = con ; eq:var var *Bo ol] ;:::;

1 1

var :[1.var : =con ; eq: var var *Bo ol]

n n

decs ` Unroll con ; exp

eq eq

0 eq 0

exp =(fvar =var :eq gfvar =var :eq gexp )

8i 2 1::n :

1 1 n n

(unroll ( var ); unroll ( var ))

1 2

(245)

eq eq eq

decs ` con ; x (var (var :con con ): Bo ol7!exp ) end var

eq k i i

i i i=1 j

Rule 245: A recursivetyp e generates recursively-de ned equality functions.

decs ` path :eq : path :lab path :lab *Bo ol

(246)

decs ` path :lab ; path :eq

Rule 246: If the constructor is simply a path|the name of an abstract typ e|we lo ok for an

equality function for that typ e in the same structure.

con = path :lab (con ;:::;con )

1 n

decs ` ; mod : sig

inst p

decs ` path :eq : sig ![it:con con *Bo ol]

(247)

decs ` con ; (path :eq (mod )):it

eq v

Rule 247: Same as Rule 246, except here we deal with the application of an abstract typ e to

a tuple of typ es. The instantiation judgmentmay recursively invoke the equality compiler, in

order to create equality functions for con ;:::;con .

1 n

decs ` con con :

decs ` con ; exp

(248)

decs ` con ; exp

decs ` sig ; mod

sig =[1 :[1.var : ];:::;n :[n.var : ]]

1 n

sig := [1 :[1.var : h; eq :var var *Bo oli ];:::;n :[n.var : h; eq:var var *Bo oli ]]

1 1 1 1 n n n n

decs ; var : sig ` con ; exp

decs ` var :sig ![it: con ] ; var :sig :[it=exp ]

(249) 55

6.9 Pattern Compilation

` pat ( exp : con else exp ; sbnds : sdecs Patterns

The judgment should b e read as \the bindings of the result of matching exp to the pattern pat

are sbnds ."

Rules 255, 257, and 259 do not apply.

` exp : con

(250)

` id ( exp : con else exp ; id =exp : id :con

Rule 250: Pattern match against an variable (which is not a datatyp e or exception constructor).

lab fresh typ e (scon )= con

` exp : con

(251)

` scon ( exp : con else exp ;

Unit

lab =if exp = scon then fg else raise exp : lab :Unit

con

Rule 251: Pattern match against a constant. We need primitive equality functions for constants

which can app ear in patterns.

lab fresh ` exp : con

(252)

` ( exp : con else exp ; lab =exp : lab :con

Rule 252: Pattern match against a wildcard.

0 0

` ty ; con : ` con con :

` pat ( exp : con else exp ; sbnds : sdecs

(253)

` pat : ty ( exp : con else exp ; sbnds : sdecs

Rule 253: Pattern match against an explicitly-typ ed pattern.

` longid ; path :lab : con !con

ctx i i

` path :exp ose : con !(lab 7!con ;:::;lab 7!con )

1 1 n n

( lab 7!con ;:::;lab 7!con )

n n

1 1

0 0

((path :exp ose exp ); exp ): con else exp ; sbnds : sdecs ` pat ( pproj

lab

` longid pat ( exp : con else exp ; sbnds : sdecs

(254)

Rule 254: Pattern match against a monomorphic datatyp e constructor which carries a value. 56

` longid ; path :lab : con lab fresh

ctx i

` exp : con

` path :exp ose : con !( lab 7!con ;:::;lab 7!con )

1 1 n n

(255)

` longid ( exp : con else exp ;

(lab 7!con ;:::;lab 7!con )

n n

1 1

((path :exp ose exp ); exp ):lab :Unit lab =pproj

lab

Rule 255: Pattern match against a constant, monomorphic datatyp e constructor.

` longid ; path :lab : sig

ctx i

` path :exp ose : sig ![it:con !(lab 7!con ;:::;lab 7!con )]

1 1 n n

` ; mod : sig

inst p

( lab 7!con ;:::;lab 7!con )

n n

1 1

0 0

` pat ( pproj (((path :exp ose mod ):it exp ); exp ): con else exp ;

p i

lab

sbnds : sdecs

` longid pat ( exp : con else exp ; sbnds : sdecs

(256)

Rule 256: Pattern match against a p olymorphic datatyp e constructor carrying a value.

longid ; path :lab : sig `

i ctx

` exp : con

` path :exp ose : sig ![it:con !(lab 7!con ;:::;lab 7!con )]

1 1 n n

` ; mod : sig lab fresh

inst p

(257)

` longid ( exp : con else exp ;

( lab 7!con ;:::;lab 7!con )

n n

1 1

lab =pproj ((path :exp ose mod ):it exp ; exp ):lab :Unit

lab

Rule 257: Pattern match against a constant p olymorphic constructor.

` longid ; path :lab : con !Tagged

ctx

` path :tag : con Tag

con

0 0

` pat ( (iftagof exp is path :tag then var :con :var else raise exp ) else exp ;

sbnds : sdecs

(258)

` longid pat ( exp : con else exp ; sbnds : sdecs

Rule 258: Pattern match against value-carrying exception constructor.

` longid ; path :lab : Tagged lab fresh

ctx

` exp : con

` path :tag : Unit Tag

(259)

` longid ( exp : con else exp ;

Unit

lab =iftagof exp is path :tag then var :Unit:fg else raise exp : lab :Unit 57

Rule 259: Pattern match against constant exception constructor.

0 0

g : :con :con ; ; lab ` con flab

k 1 1

0 0

g ; ; lab lab ; ; lab g flab f

1 n

n 1

8i 2 1::n : ; lab .var :con ` pat ( exp : con else exp ; sbnds : sdecs

i i i

lab

(260)

` { lab = pat ;:::;lab = pat h,...i} ( exp : con else exp ;

1 n

sbnds ;:::;sbnds : sdecs ;:::;sdecs

1 n 1 n

Rule 260: Pattern match against a record of patterns. Because we disallow rep eated variables

in patterns, the syntactic concatenation of structure here is well-formed.

` pat ( exp : con else exp ; sbnds : sdecs

1 1

` pat ( exp : con else exp ; sbnds : sdecs

2 2

(261)

` pat as pat ( exp : con else exp ; sbnds ; sbnds : sdecs ; sdecs

1 2 1 2

1 2

Rule 261: Pattern match against two patterns simultaneously.

` pat ( get exp : con else exp ; sbnds : sdecs

(262)

` ref pat ( exp : con Ref else exp ; sbnds : sdecs

Rule 262: Pattern matchinvolving implicit dereferencing of a ref cell.

0 0

` pat ( exp : con else exp ; sbnds : sdecs

` con con :

(263)

` pat ( exp : con else exp ; sbnds : sdecs 58

6.10 Co ercion Compilation

decs ; path :sig ` sdec ; sbnd : sdec

sub

decs ; var :sig ` lab ; labs : con

0 sig

(264)

decs ; path :sig ` lab .var : con ; lab .var =var :labs : lab .var :con

sub 0

Rule 264: Co ercion of a monomorphic value sp eci cation to a monomorphic value sp eci cation.

decs ; var :sig ` lab ; labs : con !con

0 sig

(265)

0 0

decs ; path :sig ` lab .var :con *con ; lab .var =@ var :labs : lab .var :con *con

sub 0

decs ; var :sig ; var :sig ` lab ; labs : sig ![it:con ]

0 sig

0 p

p p

decs ; var :sig ; var :sig ` ; mod : sig

0 inst p

0 p

p p

(266)

decs ; path :sig ` lab .var :(var :sig )![it:con ] ;

sub

p p

lab .var =var : sig :(var :labs mod ):

0 p

p p

lab .var :(var :sig )![it: con ]

p p

Rule 266: Co ercion of a p olymorphic value sp eci cation to a p olymorphic value sp eci cation;

this mayinvolve implicit p olymorphic instantiation. (The rule also handles matching p olymor-

need not have the phic datatyp e constructors to val sp eci cations.) Note that sig and sig

p p

same lab els, so this rule also handles alpha-conversion of EL typ e variables.

0 0

decs ; var :sig ; var :sig ` lab ; labs : sig ![it:con !con ]

0 sig

0 p

p p

decs ; var :sig ; var :sig ` ; mod : sig

0 inst p

0 p

p p

(267)

0 0

decs ; path :sig ` lab .var :(var :sig )![it:con *con ] ;

sub

p p

lab .var =var :sig :[it=@ ((var :labs mod ):it)] :

0 p

p p

0 0

lab .var :(var :sig )![it:con *con ]

p p

decs ; var :sig ` lab ; labs : var :sig ![it:con ]

0 sig p

decs ` ; mod : sig

inst

(268)

decs ; path :sig ` lab .var :con ; lab .var =(var :labs mod ):it : lab .var :con

sub 0

Rule 268: Co ercion of a p olymorphic value (or datatyp e constructor) to match a monomorphic

value sp eci cation.

decs ; var :sig ` lab ; labs : var :sig ![it: con !con ]

0 sig p

decs ` ; mod : sig

inst

0 0

decs ; path :sig ` lab .var :con *con ; lab .var =@ ((var :labs mod ):it):lab .var :con *con

sub 0

(269)

decs ; var :sig ` lab ; labs : knd

0 sig

hdecs ; var :sig ` var :labs con : knd i

0 0

decs ; path :sig ` lab .var :knd h=con i ; lab .var =var :labs : lab .var :knd =var :labs

sub 0 0

(270) 59

Rule 270: Co ercion of a typ e comp onenttoatype sp eci cation.

decs ; var :sig ` lab ; labs :

0 sig

hdecs ; var :sig ` var :labs con : i

0 0

decs ; var :sig ` var :labs ; exp

0 eq 0

(271)

decs ; path :sig ` lab :[lab .var : h=con i; eq :var var *Bo ol] ;

sub

lab :[lab .var =var :labs ; eq:exp ]:

lab :[lab .var : = var :labs ; eq :var var *Bo ol]

Co ercion of a typ e declaration corresp onding to an eqtype signature sp eci cation involving

no typ e variables. Weinvoke the equality compiler to create an equality function for the typ e

b eing copied.

decs ; var :sig ` lab ; labs : )

0 sig

0 0

con = var (var :lab :lab ; ; var :lab :lab )

p 1 p n

1 n

decs ; var :sig ; var :sig ` con ; exp

0 p eq

0 p

(272)

n 0 0

:[ lab .var : ) ; eq :var :sig ![it:con con *Bo ol]] ; decs ; path :sig ` lab

p sub

p 0

lab :[ lab .var =var :labs ; eq :var :sig :[it=exp ]] :

0 p

n 0 0

lab :[ lab .var : ) h=var :labs i; eq :var :sig ![it:con con *Bo ol]]

0 p

Co ercion of a typ e declaration corresp ond to a eqtype signature sp eci cation involving typ e

variables (i.e., eqtype ('a,'b) foo).

decs ; var :sig ` lab ; labs : sig

0 sig

decs ; var :sig ` path :labs : sig sig ; mod : sig

0 sub c

0 c

(273)

decs ; path :sig ` lab .var :sig ; lab .var =mod : lab .var :sig

sub c

0 c

Rule 273: Co ercion of a mo dule comp onent.

decs ` path : sig sig ; mod : sig

sub

decs ; path :sig ` lab .dec ; sbnd : sdec

sub 1 1 1 1

decs ; dec ; path :sig ` lab .dec ; sbnd : sdec

1 sub 2 2 2 2

decs ; dec ;:::;dec ; path : sig ` lab .dec ; sbnd : sdec

1 n1 sub n n n n

(274)

decs ` path : sig [lab .dec ;:::;lab .dec ] ;

sub 1 1 n n

[sbnd ;:::;sbnd ]:[sdec ;:::;sdec ]

1 n 1 n

decs ` var : sig sig ; mod : sig

sub 2 3

2 1 3

0 0

decs ; var :sig ` var : sig sig ; mod : sig

2 sub 4

2 4

1 1 2

decs ; var :sig ` mod : sig

2 4

(275)

0 0

decs ` path :(var :sig *sig ) (var :sig *sig ) ;

sub 1 2

1 2

var :sig :let var =path mod in mod end :

2 3 4

var :sig *sig

2 4 60

Rule 275: Co ercions for functor subtyping. We also need the same rule for subtyping of total

functors (not shown here).

6.11 Signature Patching

where typ e sig ` labs := con : knd ; sig : Sig

This judgment should b e read \By adding to the signature sig the fact that the abstract typ e

comp onent selected by labs is equal to con : knd ,we get the signature sig ."

FV (con ) \ BV (sdecs )= ;

sig =[sdecs ; lab .var :knd ; sdecs ]

(276)

sig ` lab := con : knd ; [ sdecs ; lab .var :knd =con ; sdecs ]: Sig

FV (con ) \ BV (sdecs )= ;

sig =[sdecs ; lab .var :sig ; sdecs ]

0 00

sig ` labs := con : knd ; sig : Sig

(277)

sig ` lab :labs := con : knd ; [sdecs ; lab .var :sig ; sdecs ]:Sig

sharing sig ` labs := labs : knd ; sig : Sig

sh 1 2

This judgment should b e read \By adding to the signature sig the fact that the (abstract) typ e

comp onents of kind knd selected by labs and labs are equal, we get the signature sig ."

1 2

0 0 00

sig =[sdecs ; lab .var :knd ; sdecs ; lab .var :knd ; sdecs ]

(278)

sig ` lab := lab : knd ;

0 0 0

0 0

[sdecs ; lab .var :knd ; sdecs ; lab .var :knd =var ; sdecs ]:Sig

0 0 00

sig =[sdecs ; lab .var :knd ; sdecs ; lab .var :sig ; sdecs ]

sig ` labs := var : knd ; sig : Sig

(279)

sig ` lab :labs := lab : knd ;

0 0 0

[sdecs ; lab .var : knd ; sdecs ; lab .var :sig ; sdecs ]: Sig

0 0 00

0 00

sig =[sdecs ; lab .var :sig ; sdecs ; lab .var :sig ; sdecs ]

00 000

sig ` labs := var :labs : knd ; sig : Sig

(280)

0 0

sig ` lab :labs := lab :labs : knd ;

0 0 00

0 000

[sdecs ; lab .var :sig ; sdecs ; lab .var :sig ; sdecs ]: Sig

sig =[sdecs ; lab .var :sig ; sdecs ]

0 00

sig ` labs := labs : knd ; sig : Sig

(281)

0 0

sig ` lab :labs := lab :labs : knd ; [sdecs ; lab .var :sig ; sdecs ]:Sig

sh 61

6.12 Lo okup Rules

The lo okup rules sp ecify the order in which translation contexts and IL signatures are

searched.

To prevent an explosion of rules, the metavariable class is used to denote a typ e,

signature, or kind as appropriate.

Any IL structure lab el starred with an asterisk (e.g., lab ) is treated sp ecially by the

lo okup, which checks inside the structure. That is, when lo oking for an identi er in

a context, we also lo ok inside starred structure declarations. If the identi er is found

inside such a structure, the full path to the identi er through the op en structure is

returned.

Any typ e or signature returned by a lo okup will b e valid with resp ect to the ambient

context.

6.12.1 Context Lo okup

` labs ; path : class

ctx

Main rules for lo oking up identi ers in a translation context.

` labs ; path ` path : con

ctx

(282)

` labs ; path : con

ctx

` labs ; path ` path : knd

ctx

(283)

` labs ; path : knd

ctx

` labs ; path ` path : sig

ctx

(284)

` labs ; path : sig

ctx

` labs ; path

ctx

\Utility" rules used to lo ok up identi ers in a translation context.

lab = lab

(285)

; lab .var :con ` lab ; var

ctx

0 0

lab 6= lab ` lab ; path

ctx

(286)

; lab .var :con ` lab ; path

ctx

lab = lab

(287)

; lab .var :knd h=con i` lab ; var

ctx

0 0

lab 6= lab ` lab ; path

ctx

(288)

; lab .var :knd h=con i` lab ; path

ctx 62

lab = lab

(289)

; lab .var :sig ` lab ; var

ctx

0 0

lab 6= lab ` lab ; path

ctx

(290)

; lab .var :sig ` lab ; path

ctx

sig ` lab ; path

sig

(291)

; lab .var :sig ` lab ; var :path

ctx

0 0

sig ` lab ;6 ` lab ; path

sig ctx

(292)

; lab .var :sig ` lab ; path

ctx

` lab ; path : sig ; path :sig ` labs ; labs : class

ctx sig

(293)

` lab :labs ; path :labs

ctx

6.12.2 Signature Lo okup

decs ; path :sig ` labs ; labs : class

sig

Main rules for lo oking up identi ers in a signature.

0 0

decs ` sig : Sig sig ` lab ; labs decs ` path :labs : con

sig

(294)

decs ; path :sig ` lab ; labs : con

sig

0 0

decs ` sig : Sig sig ` lab ; labs decs ` path :labs : sig

sig

(295)

decs ; path :sig ` lab ; labs : sig

sig

0 0

decs ` sig : Sig sig ` lab ; labs decs ` path :labs : knd

sig

(296)

decs ; path :sig ` lab ; labs : knd

sig

decs ` sig : Sig

decs ; path :sig ` lab ; labs : sig

sig

0 00

decs ; path :labs :sig ` labs ; labs : class

sig

(297)

0 00

decs ; path :sig ` lab :labs ; labs :labs : class

sig

sig ` lab ; labs

sig

\Utility" rules used to lo ok up identi ers in a signature.

lab = lab

(298)

[sdecs ; lab .var :con ] ` lab ; lab

sig

0 0

lab 6= lab [sdecs ] ` lab ; labs

sig

(299)

[sdecs ; lab .var :con ] ` lab ; labs

sig 63

lab = lab

(300)

[sdecs ; lab .var :knd h=con i] ` lab ; lab

sig

0 0

lab 6= lab [sdecs ] ` lab ; labs

sig

(301)

[sdecs ; lab .var :knd h=con i] ` lab ; labs

sig

lab = lab

(302)

[sdecs ; lab .var :sig ] ` lab ; lab

sig

0 0

lab 6= lab [sdecs ] ` lab ; labs

sig

(303)

[sdecs ; lab .var :sig ] ` lab ; labs

sig

sig ` lab ; labs

sig

(304)

[sdecs ; lab .var :sig ] ` lab ; lab :labs

sig

0 0

sig ` lab ;6 [ sdecs ] ` lab ; labs

sig sig

(305)

[sdecs ; lab .var :sig ] ` lab ; labs

sig

6.13 Overloading

For eachoverloaded identi er we wish to add to the EL, we add one translation rule for each

overloaded typ e. For example, we may want to overload the EL identi er + for addition at

typ es int and real . In this case, we would add two rules along the lines of:

` + ; + : Int Int*Int

Int

and

;

` + ; + : Float Float*Float

Float

where + and + are the two IL primitive addition functions.

Int Float

7 Prop erties

The pro ofs presented here are only sketches; the Standard ML language is far to o large

to check every case by hand in a reasonable amount of time. Future work may involve

attempting to check these pro ofs with an automated system.

7.1 Prop erties of the Internal Language

7.1.1 Static Semantics

Lemma 1 (Well-formedness)

The following prop ositions hold:

1. If decs ` dec ok then ` decs ok . 64

2. If decs ` bnd : dec then decs ` dec ok.

3. If decs ` knd : Kind then ` decs ok.

4. If decs ` con : knd then decs ` knd : Kind.

0 0

5. If decs ` con con : knd then decs ` con : knd and decs ` con : knd .

6. If decs ` exp : con then decs ` con : .

7. If decs ` sdecs ok then ` decs ok .

8. If decs ` sig : Sig then ` decs ok .

0 0

9. If decs ` sdecs sdecs then decs ` sdecs ok and decs ` sdecs ok .

0 0

10. If decs ` sig sig : Sig then decs ` sig : Sig and decs ` sig : Sig .

0 0

11. If decs ` sdecs sdecs then decs ` sdecs ok and decs ` sdecs ok .

0 0

12. If decs ` sig sig : Sig then decs ` sig : Sig and decs ` sig : Sig .

13. If decs ` sbnds : sdecs then decs ` sdecs ok.

14. If decs ` mod : sig then decs ` sig : Sig .

15. If decs ` exp # con then decs ` exp : con . If in addition decs ` exp : con , then

decs ` exp # con .

16. If decs ` mod # sig then decs ` mod : sig . If in addition decs ` mod : sig , then

decs ` mod # sig .

The following lemma states that internal language judgments are preserved under substi-

tution of values for free variables in a typing judgment, where a value is de ned syntactically

in Figure 4 to b e a phrase in evaluated form.

Prop osition 2 (Substitution)

1. If decs ; var :class ; decs ` con con : knd and decs ` val : class then

1 2

decs ; fval =var gdecs `fval =var gcon fval =var gcon : knd :

1 2

2. If decs ; var :class ; decs ` sig sig : Sig and decs ` val : class then

1 2

decs ; fval =var gdecs `fval =var gsig fval =var gsig : Sig .

1 2

3. If decs ; var :class ; decs ` sig sig : Sig and decs ` val : class then

1 2

decs ; fval =var gdecs `fval =var gsig fval =var gsig : Sig .

1 2

4. If decs ; var :class ; decs ` exp : con and decs ` val : class then

decs ; fval =var gdecs `fval =var gexp : fval =var gcon .

5. If decs ; var :class ; decs ` mod : sig and decs ` val : class then

decs ; fval =var gdecs `fval =var gmod : fval =var gsig . 65

6. If decs ; var :class ; decs ` con : knd and decs ` val : sig then

decs ; fval =var gdecs `fval =var gcon : knd .

7. If decs ; var :class ; decs ` exp # con and decs ` val : class then

decs ; fval =var gdecs `fval =var gexp #fval =var gcon .

8. If decs ; var :class ; decs ` mod # sig and decs ` val : class then

decs ; fval =var gdecs `fval =var gmod #fval =var gsig .

Pro of (sketch): [By induction on the derivation of the rst premises; due to space

constraints we show only two sample cases]

Case: The derivation ends with Typing Rule 49:

decs ; var :class ; decs ` exp : con *con

decs ; var :class ; decs ` exp : con

decs ; var : class ; decs ` exp exp : con

and decs ` val : class . By the inductivehyp otheses,

decs ; fval =var gdecs `fval =var gexp :

(fval =var gcon )*(fval =var gcon )

and

decs ; fval =var gdecs `fval =var gexp : fval =var gcon :

Therefore from Typing Rule 49, we can conclude

decs ; fval =var gdecs `fexp =var g(exp exp ): con :

Case: the derivation ends with Typing Rule 31:

decs ; var :class ; decs ` mod :[lab :dec ; ; lab :dec ;

v 1 1 m m

lab :var :knd =con ; sdecs ]

decs ; var :class ; decs ; dec ; ; dec ` con con : knd

1 m 2

decs ; var :class ; decs ` con : knd

decs ; var :class ; decs ` mod :lab con : knd

and decs ` val : class . By the using prop erties 5, 1, and 6ofthe induction

hyp othesis, and Typing Rule 31, we have

decs ; fval =var gdecs `fval =var gmod :lab fval =var gcon : knd :

Claim 3 (Decidability)

All internal language judgments considered by the elab orator are decidable. 66

Pro of (sketch): Because all internal-language mo dule expressions generated by the elab-

orator have most-sp eci c signatures, the decidability of the static semantics can b e reduced

in a straightforward fashion to the decidability of constructor equivalence. Of the construc-

tor equivalence judgments, Rules 32{45 describ e a familiar simply-typ ed lambda calculus

with records and constants. Even allowing the use of simple abbreviations in the context

(Rule 30) can b e seen to preserve decidability. Roughly sp eaking one can always rst \inline"

the abbreviations and then test for equivalence as in the previous case.

It is not obvious how to extend the pro of to include Rule 31 in a simple fashion. Lil-

libridge [Lil97] gives a complex argument for the decidability of constructor equivalence in

a related system (without records of constructors). We conjecture an analogous argument

would apply for our system.

7.1.2 Dynamic Semantics

We de ne two states to b e equivalent, written

0 0 0 0

( ; ;E ; phrase ); (;;E;phrase )

if the two states are equal comp onentwise up to consistent renaming of the lo cations and

exception tags app earing in and normal renaming of b ound-variables. This is clearly an

equivalence relation on states which preserves the prop erty of b eing a terminal state.

Lemma 4 (Determinacy of Evaluation)

The following prop erties hold:

0 0

1. If is terminal and , then is also terminal.

0 0 0 0

such that ,! . 2. If ,! and , then there exists a state

= =

1 1

0 0 0 0

. 3. If ,! , ,! and then

= =

1 2 1 2

2 1 2 1

0 0

. then 4. If ,! and ,!

t t

A context C is a phrase with a single hole, written []. We write C [phrase ] for the result

of lling the hole in C with phrase , p ossibly incurring variable capture. A stack of frames

E determines a context E in the obvious way: [] is the context [], and E F is the context

E [F ].

Prop osition 5 (Decomp osition & Replacement)

0 0

1. If decs ` E [exp ] : con and exp is closed, then decs ` exp : con for some typ e con .

0 0 0 0

Furthermore, if decs ` exp : con where exp is closed, then decs ` E [exp ]: con .

2. If decs ` E [mod ] : con and mod is closed, then decs ` mod : sig for some signature

0 0 0

sig . Furthermore, if decs ` mod : sig where mod is closed, then decs ` E [mod ]:con .

0 0

3. If decs ` E [con ] : con and con is closed, then decs ` con : knd for some kind knd .

00 00 00

Furthermore, if decs ` con : knd where con is closed, then decs ` E [con ]: con . 67

Pro of (sketch): [By induction on E ]

If E = [] then the prop osition is trivial, since E [phrase ] = phrase . Hence, assume

E = E F . Due to space constraints, we show just one typical case.

b c

Case: F =[]exp . Then E [exp ]= E [exp exp ]. By the inductive hyp othesis, we have

2 2

0 0

decs ` exp exp : con for some con . Insp ection of the typing rules shows that this

derivation must contain an application of Rule 49 or Rule 50; we show here only the

former case, the other is similar. By inversion decs ` exp : con *con and decs `

0 0

exp : con for some typ e con . Furthermore, if decs ` exp : con *con then decs `

2 2 2

0 0 0

exp exp : con and by the inductivehyp othesis wehave decs ` E [exp exp ]:con ;that

is, decs ` E [exp ]:con .

7.1.3 Soundness of the Internal Language

Following Harp er [Har93], wesay that a store is well-formed with resp ect to a context ,

written ` , if

8loc 2 BV (); if ` loc : con Ref then ` (x):con :

This formulation of store typing avoids the need for complex maximal xed point construc-

tions [Tof90]. (An essentially similar observation was made byWrightandFelleisen [WF91].)

Fix a base typ e ans of answers to which a complete, closed program might evaluate.

We can say that a machine state is well-formed, written

` (;;E;phrase );

if and only if ` E [phrase ] : ans , phrase is closed, and ` . An imp ortant prop erty of

the internal language semantics is that well-formedness of a state is preserved byevaluation.

Prop osition 6 (Preservation)

If ` (;;E;phrase ) and

0 0 0

(;;E;phrase ) ,! ( ; ;E ; phrase )

0 0 0

then ` ( ; ;E ; phrase ).

Pro of (sketch):

0 0

If the transition is a search rule then preservation follows trivially,for =, = ,and

b c

E [phrase ]=E [phrase ]. Hence we need only consider the reduction rules. We show only

one sample case here.

A reasonable choice mightbe String ,orUnit if we mo del all I/O by up dating the store; the particular

choice do es not a ect our results. 68

Case: Transition Rule 160:

g) ,! (;;E ( []); frbnds ; lab =exp ; rbnds

lab v v v

(;;E;exp )

0 0

g]. g]=E [ frbnds ; lab =exp ; rbnds Then E ( [])[frbnds ; lab =exp ; rbnds

lab v v v lab v v v

By the well-formedness assumption and Decomp osition,

0 0

g : con for some typ e con . Since this judgement decs ` frbnds ; lab =exp ; rbnds

lab v v v

must be proven using Typing Rules 54 and 53, by inversion we have that

decs ` exp : con . Since exp is must by closed by the well-formedness assumption

v v

and decs ` E [exp ]:ans by Replacement, well-formedness is preserved.

Furthermore, evaluation of a well-typ ed program can never \get stuck": if a well-formed

state is not terminal, there is always an applicable transition to another (well-formed) state.

The pro of relies on acharacterization of the shap es of closed values of each typ e.

Lemma 7 (Canonical Forms)

0 0 0

1. Assume ` exp : con where exp is closed.

v v

0 0

is of the form::: If con is of the form::: then exp

x fbnds end con *con

1 2

con !con x fbnd end

1 2

flab =exp ; ; lab =exp g

1 v n v

1 n

flab :con ; ; lab :con g

1 1 n n

x fbnds end

( lab 7!con ;:::;lab 7!con )

n n

1 1

exp (lab 7!con ;:::;lab 7!con ) inj

v hlab i 1 1 n n

lab

( ( con )) con

( ( con )) con roll exp

i v

Tagged tag (tag ; exp )

con Ref loc

base type scon

0 0

2. Assume ` mod : sig where mod is closed.

v v

If sig is of the form::: then mod is of the form:::

[sdecs ] [sbnds ]

var :sig *sig var :sig :mod

var :sig !sig var :sig :mod

Pro of: By insp ection of the applicable typing rules for values. For example, consider the

0 0 0

: con where con is a record typ e. There are numerous rules that case in which ` exp

allow the conclusion that an expression has a record typ e (application, record pro jection,

etc.) but only one|the rule for record expressions|applies in the case of a closed value.

This is the only p ossible form for exp . The other cases are analogous.

v 69

Prop osition 8 (Progress)

0 0

If ` then either is terminal or there exists a state such that ,! .

Pro of (sketch):

There are three cases:

1. is terminal.

2. =(;;;E;phrase ) where phrase is not avalue. By insp ection, for every p ossible

phrase syntax there is an applicable rule in the dynamic semantics (a reduction rule

tag [con ] and search rules otherwise). for new

3. =(;;;E F; val ). This has one sub case for each p ossible frame F . We show

one such case:

Case: F =(get []). By well-formedness and Decomp osition, ` get val : con for

0 0

some typ e con . By inversion of Rule 59 we have that ` val : con Ref . By

Canonical Forms, val is a lo cation, and by well-formedness val 2 BV ( ).

Therefore, Transition Rule 163 applies.

7.2 Prop erties of the Elab orator

The minimal requirement for the elab orator is that the elab oration of EL co de yields well-

formed IL co de:

Prop osition 9 (Well-formed translation)

Assume ` ok. Then the following prop ositions hold:

1. If ` expr ; exp : con then ` exp : con .

2. If ` match ; exp : con then ` exp : con .

3. If ` strdec ; sbnds : sdecs then ` sbnds : sdecs .

4. If ` strexp ; mod : sig then ` mod : sig .

5. If ` strbind ; sbnds : sdecs then ` sbnds : sdecs .

6. If ` funbind ; sbnds : sdecs then ` sbnds : sdecs .

7. If ` spec ; sdecs then ` sdecs ok.

8. If ` sigexp ; sig : Sig then ` sig : Sig .

9. If ` ty ; con : then ` con : .

10. If ` tybind ; sbnds : sdecs then ` sbnds : sdecs . 70

11. If ` typdesc ; sbnds : sdecs then ` sbnds : sdecs .

12. If ` etypdesc ; sbnds : sdecs then ` sbnds : sdecs .

13. If ` datbind ; sbnds : sdecs then ` sbnds : sdecs .

14. If decs ` ; mod : sig then decs ` mod : sig . Furthermore, mod is a syntactic value

inst

and sig is the most-sp eci c signature of mod .

15. If decs ` con ; exp then decs ` exp : con con *Bo ol. Furthermore, exp is

a syntactic value. If decs ` (var ;:::;var ):con ; mod then decs ` mod :

eq 1 n

heq i heq i

8var ;:::;var :con con *Bo ol.

16. If ` pat ( exp : con else sbnds ; sdecs :, ` exp : Tagged and ` exp : con , then

` sbnds : sdecs .

17. If decs ; path :sig ` sdec ; sbnd : sdec then decs ` path : sig , decs ` sdec ok , and

sub

0 0

decs ` sbnd : sdec .

18. If decs ` path : sig sig ; mod : sig then decs ` path : sig , decs ` sig sig : Sig ,

sub

0 0 0

0 0

decs ` mod : sig , and decs ` sig sig : Sig .

19. If ` labs ; path : class then ` path : class . Furthermore, ` path : class if and

ctx

only if ` labs ; path : class .

ctx

20. If ; path :sig ` labs ; labs : class then ` path :labs : class . Furthermore, if

sig

0 0

` path :labs : class then ; path :sig ` labs ; labs : class .

sig

0 0

21. If sig ` labs := con : knd ; sig : Sig , ` sig : Sig ,and ` con : knd ,then ` sig :

Sig .

0 0

22. If sig ` labs := labs : knd ; sig : Sig and ` sig : Sig then ` sig : Sig .

Pro of: This follows by induction on the derivation of the rst premises.

To claim that wehave de ned a language, we need elab oration to b e a \function" in the

sense that all p ossible elab orations of an EL program yield \equivalent" IL programs. We

argue that such coherence is plausible, also we have not attempted a formal pro of.

Claim 10 (Coherence)

basis .basis :sig ` expr ; exp : ans

basis

and

basis .basis :sig ` expr ; exp : ans

basis

and

(; ; let basis =mod in exp end) ,!

basis t

, then for some terminal state

0 0

(; ; let basis =mod in exp end ) ,! :

basis

t 71

Pro of (sketch): We enumerate the instances of non-determinism in the elab orator, and

argue that these should not cause incoherence.

1. The elab orator may \guess" typ es for bound variables (in fn expressions) and when

instantiating p olymorphism. Typ es in \dead" co de maybe underconstrained, as in

(fn x => 3)(fn y => y)

where there are in nitely many choices for the typ e of the identity fn y => y. How-

ever, the dynamic semantics is suciently abstract that choices of typ es do not a ect

the course of evaluation.

2. Similarly, the elab orator mayhaveachoice regarding how to resolveoverloading. The

simplest argument is that eachoverloaded op erator corresp onds to a single op erator in

the dynamic semantics, so that again evaluation do es not dep end on the resolved typ e.

(A more sophisticated argument should be able to show that in a complete program,

whenever there is a choice of how to resolve overloading, the op erator will never be

applied.)

3. The elab orator must decide whether valuable expressions should be monomorphic or

p olymorphic, and in the latter case, on how many typ e variables to generalize. This

turns expressions into functor abstractions, which in general causes incoherence by

changing the order of evaluation|an expression wrapp ed by a functor will not be

evaluated until the functor is applied. However, we only generalize valuable expressions,

which have no e ects, so that these choices will not a ect observable behavior.

4. There is nondeterminism in the creation of equality functions: there may be di er-

ent de nitions of equality at the same typ e. However, we maintain the invariant that

equality functions always p erform structural equality on the underlying values regard-

less of abstraction. Any two candidate de nitions then have the same behavior, and

no incoherence can arise.

8 Acknowledgments

We would like to thank Perry Cheng and Martin Elsman for their particularly helpful com-

ments on the work presented here.

References

[Har93] Rob ert Harp er. A simpli ed account of p olymorphic references. Technical Re-

p ort CMU-CS-93-169, Scho ol of Computer Science, Carnegie Mellon University,

1993. 72

[HL94] Rob ert Harp er and Mark Lillibridge. Atyp e-theoretic approach to higher-order

mo dules with sharing. In 21st Symposium on Principles of Programming Lan-

guages,pages 123{137, 1994.

[HM93] Rob ert Harp er and John C. Mitchell. On the typ e structure of Standard ML.

ACM Transactions on Programming Languages and Systems, 15(2):211{252,

1993.

[HM95] Rob ert Harp er and Greg Morrisett. Compiling p olymorphism using intensional

typ e analysis. In 22nd Symposium on Principles of Programming Languages,

pages 130{141, 1995.

[HMM90] Rob ert Harp er, John C. Mitchell, and Eugenio Moggi. Higher-order mo dules

and the phase distinction. In 17th Symposium on Principles of Programming

Languages, pages 341{354, 1990.

[Ler94] Xavier Leroy. Manifest typ es, mo dules, and separate compilation. In 21st Sym-

posium on Principles of Programming Languages,pages 109{122, 1994.

[Ler96] Xavier Leroy. A syntactic theory of typ e generativity and sharing. Journal of

Functional Programming, 6(5):667{698, 1996.

[Lil97] Mark Lillibridge. Translucent Sums: A Foundation for Higher-Order Module

Systems. PhD thesis, Scho ol of Computer Science, Carnegie Mellon University,

1997. Available as CMU Technical Rep ort CMU-CS-97-122.

[Mor95] Greg Morrisett. Compiling with Types. PhD thesis, Scho ol of Computer Science,

Carnegie Mellon University, 1995. Available as CMU Technical Rep ort CMU-

CS-95-226.

[MT94] David B. MacQueen and Mads Tofte. A semantics for higher-order functors. In

European Symposium on Programming, pages 409{423. Springer-Verlag, LNCS

788, April 1994.

[MTH90] Robin Milner, Mads Tofte, and Rob ert Harp er. The De nition of StandardML.

MIT Press, 1990.

[MTHM97] Robin Milner, Mads Tofte, Rob ert Harp er, and Dave MacQueen. The De nition

of Standard ML (Revised). MIT Press, 1997.

[Plo81] Gordon D. Plotkin. A structural approach to op erational semantics. Technical

Rep ort DAIMI FN{19, Aarhus University, September 1981.

[Tar96] David Tarditi. Design and Implementation of Code Optimizations for a Type-

Directed Compiler for Standard ML. PhD thesis, Scho ol of Computer Science,

Carnegie Mellon University, 1996. 73

[TMC 96] David Tarditi, Greg Morrisett, Perry Cheng, Chris Stone, Rob ert Harp er, and

Peter Lee. TIL: A typ e-directed optimizing compiler for ML. In Proceedings

of the ACM SIGPLAN '96 Conference on Programming Language Design and

Implementation, pages 181{192, 1996.

[Tof90] Mads Tofte. Typ e inference for p olymorphic references. Information and Com-

putation, 89(1):1{34, November 1990.

[WF91] Andrew Wright and Matthias Felleisen. A syntactic approachtotyp e soundness.

Technical Rep ort TR91-160, Department of Computer Science, Rice University,

1991. 74