Standard ML-NJ Weak Polymorphism and Imperative Constructs · 2016. 12. 28. · In Standard ML of...

File: 643J 257001 . By:MB . Date:06:08:96 . Time:18:06 LOP8M. V8.0. Page 01:01Codes: 7263 Signs: 5187 . Length: 60 pic 11 pts, 257 mm

Information and Computation � IC2570

information and computation 127, 102�116 (1996)

Standard ML�NJ Weak Polymorphism and Imperative Constructs

John Mitchell* and Ramesh Viswanathan*

Department of Computer Science, Stanford University, Stanford, California 94305

E-mail: [mitchell, vramesh]�cs.stanford.edu

Standard ML of New Jersey (SML�NJ) uses ``weak type variables''to restrict the polymorphic use of functions that may allocate referencecells, manipulate continuations, or use exceptions. However, the typesystem used in the SML�NJ compiler has not previously been pre-sented in a form other than source code nor proved correct. We presenta set of typing rules, based on analysis of the concepts underlying``weak polymorphism'', that appears to subsume the implemented algo-rithm and uses type variables of only a slightly more general nature thanthe compiler. One insight in the analysis is that allowing a variable tooccur both ``ordinarily'' and ``weakly'' in a type permits a simpler andmore flexible formulation of the typing rules. In particular, we are ableto treat applications of polymorphic functions to imperative argumentswith greater flexibility than SML�NJ. The soundness of the type systemis proved for imperative code using operational semantics, by showingthat evaluation preserves typability. By incorporating assumptionsabout memory addresses in the type system, we avoid proofs by co-induction. ] 1996 Academic Press, Inc.

1. INTRODUCTION

In the absence of side effects and so-called control effects(continuations and exceptions), the type inference methodsdeveloped by Curry, Hindley, and Milner [CF58, Hind69,Mil78] provide an effective and useful method for detectingtype errors at compile time. For any typable expression, thetype inference algorithm computes a single most generaltype, from which all other types of the expression may bederived easily. Although the worst-case complexity is high[KMM91, KTU90], the algorithm has been found efficientin practice. More importantly, experience suggests that it ispossible for a programmer to predict, with relative ease, thetype that the algorithm will produce. In addition, typeinference allows a form of error detection that is unfamiliarto explicitly-typed programming. Even when a declarationis typable, the programmer may detect an error by noticingthat the type inferred by the compiler differs from the typeexpected by the programmer (cf. [Koe92]).

Unfortunately, the straightforward, predictable poly-morphic typing algorithm fails for programs with side-effects or control effects. To illustrate the problems involved,we use a lambda calculus extended with let-expressions (for

polymorphism) and imperative operators ref, ! and :=.Briefly, ref x allocates a new cell, initialized to x, r :=xupdates the contents of reference r to the value of x, and !rreturns the current contents of reference r. The incorrectnessof the naive polymorphic typing of side-effects is illustratedby the program

let r=ref(*x .x) in r :=*x .x+1; !r true

where ; is the usual sequencing operator (definable bylambda abstraction under call-by-value). If we apply theMilner typing algorithm, we give r type \: . [(: � :) ref ],where { ref is the type of references to values of type {.Intuitively, this means that for any type _, : can be instan-tiated to _ to give r the type (_ � _) ref. Both expressions inthe body of the declaration are well-typed, under thisassumption, since we can take the instances (int � int) refand (bool � bool ) ref for the two occurrences of r, respec-tively. However, since the assignment changes the value ofr from a polymorphic function to an integer function, theapplication of !r to true results in a run-time type error.Thus, a naive polymorphic treatment of side-effects does notprevent run-time type errors in the presence of assignment.

We can view solutions to this problematic interaction ofpolymorphism and side-effects from a general perspective,by understanding the way polymorphic type inferenceworks. In typing an expression of the form let x=e1

in e2 , the most general type { of e1 is calculated. Certaintype variables in { are determined to be ``generic'' or``polymorphic''. If :1 , ..., :n is a list of all the genericvariables in {, we write the type of e1 as \:1 } } } \:n .{. Intyping e2 , all the generic�polymorphic type variables maythen be replaced by types, independently chosen for eachoccurrence of x. For example, if e1 has type \: .: � int, ande2 is the expression x x, then e2 may be typed by replacing: by int � int in the first occurrence of x and int in thesecond occurrence. If a type variable is determined to benon-polymorphic, it can only be replaced by the same typein all occurrences of the let-bound variable x. Thus a criticalaspect of polymorphic type inference is the method for iden-tifying the type variables that may be safely be treated aspolymorphic. In the absence of side-effects or control effects,there is a simple condition depending on the types of free

article no. 0054

1020890-5401�96 �18.00

Copyright � 1996 by Academic Press, Inc.All rights of reproduction in any form reserved.

* Supported in part by an NSF Grant CCR-9303099.


variables of e1 . The main topic of this paper, and previousstudies of polymorphism and imperative constructs, is thesafe and flexible extension of the condition for pure terms toterms with side-effects. Over the past decade, a number ofrestrictions on the polymorphic uses of references have beenproposed. Some of these have been implemented and othershave been analyzed and proved correct, as described below.Our main contribution is a precise definition of a typesystem that appears to subsume the algorithm used inSML�NJ and a correctness proof for it. Although similarproblems occur with continuations and exceptions, asillustrated in [HL91, WF91], we restrict our attention toside effects, in this paper.

In Standard ML of New Jersey [AM87, AM91], so-called ``weak type variables'' are used to characterize func-tions that may create reference cells after some number ofapplications. Since the type of a polymorphic function maybecome more specialized with each application (as, forexample, when a polymorphic function is applied to amonomorphic argument), many functions that createreferences could create polymorphic references for someactual parameters, and monomorphic references for others.For example, the function

*f .*x .ref( fx)

creates a reference to the result of applying the first actualparameter to the second. This function is unproblematic forcreating references to integers or booleans, but we cannotallow the result of application to two arguments to be usedpolymorphically because of the phenomenon describedabove. The most restrictive solution to the problem oftyping references would be to require some fixed, non-polymorphic type for this function. A more flexibleapproach might be to force every argument to this functionto be non-polymorphic. However, this too is overly restric-tive since the reference cell is not created until the secondactual parameter is supplied. For example, we may safelyobtain a polymorphic function by applying to the poly-morphic identity, provided any eventual second argument isnon-polymorphic. The main innovation of SML�NJ weaktyping, over previous approaches, is to use numeric indiceson each type variable to count the number of functionapplications required to produce a reference cell of thattype. Although this system has seen widespread and largelysuccessful use in recent years, the SML�NJ algorithm hasnever been presented in a form other than relatively com-plicated source code, and consequently has never beenanalyzed or proved sound.

We present our type system as a set of typing rules, usinga mild extension of the weak type variables of SML�NJ.These rules were derived from experiments with the algo-rithm implemented in Standard ML of New Jersey, Version75 (November 11, 1991) and perusal of the source code.

Although our original intention was to formalize theimplemented algorithm exactly, we found it easier and moreinformative to define a more general type system withsimpler typing rules and fewer apparent special cases. (Aformulation which adheres more closely to the implementedalgorithm appears in [Gre96].) One insight came as a resultof examining the way that the type of an expression dependson the types of its non-polymorphic free variables. InSML�NJ, every weak type variable appears throughout thetype of an expression with the same strength. For example,the expression ref has the type :1 � :1 ref. Such a restric-tion forces the numeric superscripts in the type of a freevariable to characterize two sources of storage allocation.They must simultaneously give a lower bound on the num-ber of applications of the variable itself and a lower boundon the number of applications of the expression containingthe variable that may result in a reference cell being created.Thus, in typing an expression, the type assumption of a freevariable needs to be modified according to the sub-expres-sion that one is typing. We avoid this by allowing both``ordinary'' and ``weak'' occurrences of a type variable in atype. This leads to the formulation of a stronger typing rulefor application than the compiler output indicates. Conse-quently, our typing rules appear to subsume the implementedalgorithm, particularly for applications of purely functionalexpressions to potentially imperative arguments. We showthat our typing rules are sound, using an operationalsemantics of ML with references, implying the semanticsoundness of any algorithm that decides a conservativeapproximation to these rules.

More expressive type systems have been developed byLeroy and Weis [LW91], and, independently, by Talpin,Jouvelot and others [TJ92, Wri92], partly based on theframework of Gifford's FX system [JG91]. In contrast tothe SML�NJ algorithm and preceding ML compilers,which keep track of the types of all values in the store, theseapproaches approximately identify the values in the storethat are accessible in a particular context. This additionalaccessibility information leads to type systems that arecapable of giving functions which use references only locallythe same types as their corresponding applicative versions.However, to be able to maintain this information, morecomplicated type expressions are required. While the morecomplex systems are promising, it is more difficult to predictthe types of certain functions. Since we believe that the suc-cess of ML typing lies not only in its correctness, but theease with which it may be understood in programming, anyadded complication to the type system deserves carefulscrutiny. Consequently, it seems worthwhile to exploresystems using only weak type variables and determine thelimits of this approach.

A solution along different lines appears in [Wri95],where it is argued that in practice one rarely needs any moreexpressiveness than that of the simplest type systems, such

103IMPERATIVE CONSTRUCTS AND POLYMORPHISM


as [Tof90]. The argument is based on studying existing MLcode to show that either the simplest type systems wouldallow them to be used polymorphically or that the MLprograms can be transformed in simple ways so that theycould be treated polymorphically by the simple typesystems. However, with enhancements to the language suchas object-oriented features, it is not immediately clearwhether future imperative ML programs would share thischaracter.

2. WEAK POLYMORPHISM

In the approach we refer to as weak polymorphism, eachtype variable has an associated degree of strength, or degreefor short. In the SML�NJ implementation, a degree may bea nonnegative integer, or �. Variables of infinite degree areprinted without any degree designation. Intuitively, thedegree of a type variable :, occurring in the typing of someexpression e, indicates how many applications of e arerequired to produce a reference to a value whose type con-tains :. Functions that do not produce references at all aretyped using variables of infinite degree. For example, thetype of ref itself is

ref : :1 � :1 ref,

where the superscript indicates that :1 is a weak typevariable of degree 1. This type implies that when the func-tion ref is applied, : may appear in the type of a storedvalue, and should not be treated polymorphically. However,the : in the type of ref is polymorphic, as is any typevariable of non-zero degree in the type of a closed expres-sion. This means that ref may be applied to an argumentof any type, but the result cannot be used polymorphically.Another example is the list-producing function *x .ref[x],which has type :1 � :1 list ref since it takes one applicationof this function to produce a reference to a value whose typecontains :, or some type substituted for :. Since each appli-cation weakens the type of a function, each surroundinglambda abstraction strengthens every type variable inthe type. As another interesting example, the expression*f .*x .ref( fx) has the type (: � ;2) � (: � ;2 ref ), wherethe reader may note that it is only the result of the functionf which is constrained to be weak and of strength 2.

We may put the SML�NJ type system in perspective byreviewing the history of polymorphic type systems forimperative constructs. Early implementations of ML onlyallowed references to values of monomorphic, staticallyknown types. This approach guarantees soundness, butmakes it impossible to write polymorphic functions thatcreate or use references. In his thesis, Damas introduced thefirst type system to allow polymorphic use of functions thatcreate references [Dam85]. Unfortunately, although hissystem has not been shown to be unsound, his claimed

soundness proof is incorrect. Tofte was the first to give atype discipline for polymorphic references together with acorrect soundness proof [Tof88, Tof90]. The central ideaof Tofte's solution is to partition the types into `ìmperative''and `àpplicative'' types, requiring all type variables thatoccur in an imperative type to be imperative. Values ofimperative type can be stored, but only applicative typevariables are treated polymorphically, successfully avoidingthe creation of references to polymorphic values. Mac-Queen's system, implemented in the Standard ML of NewJersey ML compiler, is largely derived from Tofte's, usingthe numeric ``degree'' of a weak type variable to count howmany function applications it takes for a type variable tobecome `ìmperative.''

The power of weak polymorphism may be understood bycomparison with Tofte's system. In Tofte's system, any typevariable that appears in the type of a value that could poten-tially be stored has to be imperative and hence cannot beused polymorphically, even if the value does not actuallyappear in the store yet. Technically, imperative typevariables are treated non-polymorphically only in the typesof so-called `èxpansive'' expressions, which include letexpressions. Therefore, we illustrate the limitations ofTofte's system using the following expression, rid, which isa version of the identity function using side-effects:

rid # let z=dummy in *x . ! (ref x).

Since x is stored, its type must be imperative. Consequently,in Tofte's system, the expression rid is given a type u � u,where u is an imperative type variable that cannot begeneralized. With weak polymorphism, however, we cantake into account the fact that rid must be applied oncebefore the reference to x is created. This allows us to give ridthe type :1 � :1, where the type variable :1 can now begeneralized. Since rid may be used polymorphically usingweak polymorphism, but not in Tofte's system, the expres-sion

let f=rid in f 1; f true

is typable in SML�NJ but not in Tofte's system.In our typing rules, we generalize the SML�NJ type

expressions slightly to associate numeric indices withordinary type variables. In addition, a type variable canhave both `òrdinary'' and ``weak'' occurrences, as well asoccur with different strengths in a type. Aside from theserelatively minor changes, which allow us to express the rela-tionship between degrees of various type variables moreclearly, our type expressions are identical to the those usedin Standard ML of New Jersey. It seems that significantlymore complicated typing rules are needed if only theSML�NJ type expresions are used. In fact, we were not ableto devise a sound system with SML�NJ type expressions

104 MITCHELL AND VISWANATHAN


using ordinary proof rules without excessively complicatedside conditions.

3. LANGUAGE

3.1. Syntax

In describing our typing rules and proving them correct,we use an untyped call-by-value language with ML-styleimperative features. In writing the expressions of ourlanguage we allow arbitrary term constructors of specifiedarity. More formally, the language is parameterized by a setC of pairs, ( f, n) , where n�0 gives the arity of the termconstructor f. Having term constructors, as opposed to termconstants, allows one to represent non-strict operators inthe call-by-value language. The expressions are given by thegrammar

e ::=x | f (e1 , ..., en) |e1e2 | let x=e1 in e2 |

l | ref | !e | e1 :=e2

where ( f, n) # C, x # Var, l # Loc, Var is a denumerable setof variables, and Loc is a denumerable set of location con-stants. The location constants do not appear in userprograms (this would be tantamount to allowing the user topick addresses), but help in defining the operational seman-tics. We thus define programs to be closed expressions notcontaining any location constants.

In defining the operational semantics, it is useful todistinguish a subset of closed expressions that cannot befurther evaluated. These are called values. Besides someexpressions that depend on the particular choice of termconstructors, the set of values always includes *-abstrac-tions, location constants, and the constant ref:

v ::= } } } |*x .e | l | ref.

The additional values that depend on the term constructorsare specified in a set V. Each element of V is of the formf (d1 , ..., dn), where ( f, n) # C and each di is an expressionor a value.

3.2. Operational Semantics

We use a rewriting semantics to specify operationalbehavior. In defining the operational semantics, we use asyntactic form wrong to represent run-time errors.

We begin by defining a relation, � , with e � r indi-cating that e is a purely functional redex reducing directlyto r, i.e., without any side-effects. The result, r, of the reduc-tion is either another expression or wrong. The behavior ofthe functional term constructors is given by a set F of pairsof the form (e, r), indicating that e reduces to r, where e isan expression of the form f (e1 , ..., en) and r is another

expression or wrong. The purely functional reduction rela-tion, � , is defined by

(*x .e)v � [v�x]e

let x=v in e � [v�x]e

v1v2 � wrong if v1 not a *-abstraction, ref

e � r if (e, r) # F.

To impose an order on the evaluation of subexpressions, weuse the notion of an evaluation context [WF91]. Theevaluation contexts E[ ] are defined by the grammar

E[ ] ::=[ ] |Ee| vE |let x=E in e|

} } } |ref E | !E |E :=e| v :=E,

where the unspecified productions are used to reflect theorder of evaluation of the arguments of term constructorsand are of the form f (d1 , ..., dn), where exactly one of the di 'sis an evaluation context E and the others are values v orexpressions e; these are specified in a set EV. Intuitively, thehole in an evaluation context specifies the next subexpres-sion to be evaluated.

To handle imperative features, our operational rules willmanipulate ``stores'' in addition to terms, where a store is afinite partial map from location constants to values. Thebasic one-step evaluation relation [ is defined in Table 1,with (e, s) [ (r, s$) indicating that the expression e in stores evaluates in one step to the result r resulting in new stores$. The result r is either another expression or the run-timeerror wrong. The reduction relation is parameterized by thechoice of V, F, and EV, which we collect in a signature(V, F, EV).

The result of execution of any program, obtained byevaluating it in the initial empty store, is captured by a par-tial function Eval. Writing [� for the reflexive and trans-itive closure of [, Eval(e)=a iff (e, init) [� (a, s$) forsome store s$, where the answer a is either a value or wrongand init is the empty store that is undefined on all locations.A program e is said to diverge if there is an infinite reductionsequence from e, i.e., for every expression e$ such thate [� e$, there is an expression e" such that e$ [ e". If a

TABLE 1

One-Step Evaluation Relation

(E[e], s) [ (E[e$], s) if e � e$, e${wrong(E[ref v], s) [ (E[l], s[l [ v]) where l � dom(s)

(E[! l], s) [ (E[s(l)], s)(E[l :=v], s) [ (E[v], s[l [ v])

(E[e], s) [ (wrong, s) if e � wrong(E[!v], s) [ (wrong, s) if v � Loc

(E[v1 :=v2], s) [ (wrong, s) if v1 � Loc



program e diverges, Eval(e) is undefined. We say that aproblem e does not lead to a run-time error if Eval(e){wrong.

In the description of the previous paragraph, we havemade two implicit assumptions: (i) if (e, init) [� (a, s) and(e, init) [� (a$, s$), where a and a$ are values or wrong,then a and a$ are identical, and (ii) it is impossible that(e, init) [� (e$, s) and e$ is not a value or wrong and thereis no e", s$ such that (e$, s) [ (e", s$). The first property isneeded for Eval to define a function and the second propertyis needed to ensure that all run-time errors are capturedaccurately by reduction to the expression wrong in oursystem. It is worth mentioning however that our proof ofsoundness does not rely on any of these properties. Boththese properties depend on the choice of V, F, and EV usedto express the behavior of the term constructors. In thefollowing, we identifying one sufficient condition on themthat ensures that we have properties (i) and (ii).

Definition 3.1. Let e# f (e1 , ..., en) be any closed term,where ( f, n) # C. Consider the following three possibilitiesfor the expression e :

(i) The expression e is a value, i.e., e # V.

(ii) There is an f (d1 , ..., dn) # EV and integer i suchthat di is an evaluation context E, ei � V, and e#

f (d1 , ..., ei , ..., dn).

(iii) For some r, we have that (e, r) # F.

We say that the signature (V, F, EV ) is

v deterministic, if for every closed expression e#

f (e1 , ..., en) at most one of (i), (ii), (iii) is true with thechoice of i, f (d1 , ..., dn) unique in case (ii), and the choice ofr unique in case (iii).

v complete, if for every closed expression e#f (e1 , ..., en)at least one of (i), (ii), or (iii) is true of e.

If the signature is deterministic then we can show thatproperty (i) holds, i.e., that the result of evaluation isunique. And if it is complete then we can show that property(ii) holds, i.e., that evaluation never results in ``stuck''expressions.

Lemma 3.2. Assume that a signature (V, F, EV ) isdeterministic and complete. Then, for every closed expressione, either e diverges, or (e, init) [� (v, s) for a unique value v,or (e, init) [� (wrong, s).

4. TYPE SYSTEM

4.1. Type Expressions and Instances

Our type expressions are built from type variables usingthe constructor � for function types, and ref for referencecells, in addition to type constructors for other datatypes.

To incorporate weak polymorphism, every ``weak'' typevariable will have an index which is its degree of strength.However, unlike ML, an ordinary type variable will alsohave an associated index in our type system.

We start with a set B of type constructors for datatypessuch as integers, lists etc. Each element of B is a pair of theform (b, n) , where n�0 gives the arity of the type con-structor b. Let TVars be an infinite set of type variableswhose elements will be indicated by metavariables :, :1 , ...,;, ;1 , ... . A ``weak'' occurrence of a type variable will besignified by underlining it. As mentioned before, every``weak'' and `òrdinary'' occurrence of a type variable has anassociated index, which will be a natural number. We thusarrive at the following grammar for generating pre-types,some of which will be deemed to be well-formed types:

\ ::=: j | :�

j | \1 � \2 | \1 ref | |b(\1 , ..., \n).

In this grammar we assume that (b, n) # B and j # N.Intuitively, a pre-type of the form \1 � \2 can be used as thetype of some expression only if any type variable occurring`ìmperatively'' in \1 does not occur `àpplicatively'' in \2 andany type variable occurring `ìmperatively'' in \2 does notoccur `àpplicatively'' in \1 . We now elaborate the precisecondition distinguishing types from pre-types.

For any pre-type \, we define its free type variables,FTV(\), to be the set of variable names appearing in it,without regard to their index or whether they are under-lined. More precisely,

FTV(: j) = [:]

FTV(:�

j) = [:]

FTV( \1 � \2) = FTV( \1) _ FTV( \2)

FTV( \1ref ) = FTV( \1)

FTV(b( \1 , ..., \n)) = FTV( \1) _ } } } _ FTV( \n).

Intuitively, a weak occurrence of a type variable : indicatesthat : appears in the type of a value to which a referencemay potentially be created. The index j in a weak occurrence:�

j indicates that at least j applications of the relevant expres-sion are needed before the reference to the type containing: is actually created. Thus, only :

�0 is deemed to be an

imperative occurrence and indicates that : is imperative, i.e.,appears in the type of a stored value. On the other handordinary type variables never appear in the type of a storedvalue. Thus the applicative variables, ATV(\), i.e., thosevariables that do not appear in the store typing can bedefined by

ATV(: j) = [:]

ATV(:�

j) = [:] if j>0



ATV(:�

0) = ,

ATV( \1 � \2) = ATV( \1) _ ATV( \2)

ATV( \1 ref ) = ATV( \1)

ATV(b( \1 , ..., \n)) = ATV( \1) _ } } } _ ATV( \n)

The imperative type variables are the free type variables thatdo not occur applicatively:

ITV( \)=FTV( \)"ATV( \)

We say that a pre-type \ is imperative if all its free variablesoccur imperatively, i.e., ITV(\)=FTV(\).

Since the index in a weak occurrence indicates thenumber of applications needed before it becomes imperative,we would intuitively expect every application to decrementthe strength in every occurrence by 1. We will also decre-ment the index in ordinary occurrences after an application.All this is formally captured by the weakening map Wdefined on indexed variables as

W(: j)={: j&1

undefinedif j>0otherwise

W(:�

j)={:�

j&1

:�0

if j>0otherwise

and extended to all pre-types in the obvious way using thetype constructors, �, ref, b. If ordinary occurrences of typevariables were allowed to have negative indices then we canavoid having W(:0) undefined. However, we prefer thepresent framework as it allows us to define substitutionsmore elegantly.

We can now give some intuition for the indices inordinary occurrences of a type variable. These are used tokeep track of any applications and abstractions occurringin the body of an expression. The weakening map W isused in typing an application to decrease the index inevery ordinary occurrence by 1. Analogously, in typing anabstraction, we will increase the indices in ordinaryoccurrences by 1. Thus if an there is an ordinary occurrenceof a type variable : in the type \ of an expression e, its indexrelative to the indices of other occurrences of : in \ gives usinformation about any applications and abstractions withinthe body of e. This allows a more uniform treatment whena type containing weak occurrences of type variables issubstituted for an ordinary occurrence of a type variable.This arises, for example, when a purely functional expres-sion is applied to an expression using imperative features, asis further discussed in Section 5.

The main property guaranteed by the type system is thatwhen a type variable : appears in the type of a stored valueafter evaluation of an expression e, all occurrences of : in

the type of e must be imperative. This requires some restric-tions on the pre-types that can be used as types of expres-sions. The well-formed monotypes, indicated by metavariables {, {$, {", ..., {1 , {2 , ... are defined as follows:

v For any : # TVars, j # N, : j, :�

j are monotypes.

v If {1 , {2 are well-formed monotypes then {1 � {2 is awell-formed monotype, provided

(i) For all : # FTV({1) & FTV({2), : # ITV({1) iff: # ITV({2).

(ii) W({2) is defined and is a well-formed monotype.

v {1 ref is a well-formed monotype, if {1 is a well-formedmonotype.

v b({1 , ..., {n) is a well-formed monotype, if {1 , ..., {n arewell-formed monotypes.

Condition (i) on a type {1 � {2 forces any imperative typevariable of {1 to also occur only imperatively in {2 and anyimperative type variable of {2 to occur only imperatively in{1 . When an expression of type {1 � {2 is applied to anexpression of type {1 , the type of the resulting expression isW({2), which is why we require condition (ii). An exampleof a pre-type not satisfying condition (i) is :

�0 � :2, and

one not satisfying condition (ii) is :1 � :0. However,:�

1 � :2, :�

0 � ;1, :2 � :1 are well-formed monotypes.The polymorphic types, also referred to as polytypes,

indicated by _, _1 , ..., are given by the grammar

_ ::={ | \: ._

where { is a monotype and : # TVars. The variables:1 , ..., :n are bound in the polymorphic type \:1 } } } :n .{. Weconsider polymorphic types which differ only by a consis-tent renaming of bound variables equivalent. We definethe set of free type variables, FTV(_), of a polytypeas FTV(\:1 } } } :n .{)=FTV({)"[:1 , ..., :n] and similarlyITV(_) as the set of free variables in _ that occurimperatively.

The instances of a polytype are defined using substitu-tions. A substitution S with domain T�TVars is a mapfrom T to the well-formed monotypes. We often use[{1�:1 , ..., {n�:n] to denote the substitution S with domain[:1 , ..., :n] defined by S(:i)={i , for i=1, ..., n. Intuitively,if S(:)={, then in applying the substitution S to a type,we replace all ordinary occurrences of : with index 0 (:0)with {, and replace other occurrences of : (:

�j; :i, for i>0)

by types determined systematically from {. To state thetypes to use for other occurrences of a type variable, we willdefine maps Seti , i�0 and Inc on monotypes. We willspecify the behavior of these maps on indexed variables,with the obvious extension to monotypes. The map Seti sets



all occurrences of a type variable, except those that areimperative, to a weak occurrence with strength i.

Seti (: j) = :�

i

Seti (:�j)={:

�i

:�

0

if j>0otherwise

The following map, Inc, increments the indices in alloccurrences of type variables, except the imperative ones.

Inc(: j) = : j+1

Inc(:�

j) = {:�

j+1

:�

0

if j>0otherwise

The effect of a substitution S with domain T on an indexedtype variable is given by S(:j)=Inc j (S(:)) and S(:

�j)=

Setj (S(:)), for : # T, where Incn denotes the n-fold composi-tion of Inc. If S has domain T, then S leaves any variable notin T unchanged. The type S({) and S(_) for monotype { andpolytype _ can then be defined in the usual way, withpossible renaming of bound variables. In more detail,

S(:0) = S(:) if : # T

S(: j) = Inc j(S(:)) if : # T, j>0

S(:�

j) = Setj (S(:)) if : # T

S(: j) = : j if : � T

S(:�

j) = :�

j if : � T

S({1 � {2) = S({1) � S({2)

S({ ref ) = S({) ref

S(b({1 , ..., {n)) = b(S({1), ..., S({n))

S(\: ._) = \; .S([;0�:](_))

where ; � T _ [FTV(S(:)) | : # T ]

Note that for a monotype {, S({) may not necessarily be awell-formed monotype.

We say that a well-formed monotype {$ is an instanceof a polymorphic type _ = \:1 } } } :n .{, written \:1 } } } :n .{o{$, if there exists a finite substitution S with domain[:1 , ..., :n] such that S{={$.

4.2. Typing Rules

The type system is given by a set of axioms and inferencerules. The formulas that are derivable in this proof systemare judgements of the form 1, Ri e: {, where 1 is avariable context, R is a location context, e an expression,and { a monotype. The variable context 1 states assump-tions about the free variables of e and is a set of pairs x : _,where _ is a polytype, and no variable x appears twice in 1.

The location context R gives the types of values stored inthe location constants that may appear in e. It is a set ofpairs l : {, where { is an imperative monotype, with no loca-tion constant l appearing twice. A provable judgement1, Ri e: { can thus be read as ``the expression e has type {in context 1, R.'' Since expressions that appear in MLprograms never contain location constants, we never needassumptions about location constants in typing them.However, since expressions containing location constantscould be the result of an evaluation step, and our proof ofsoundness proceeds by showing that evaluation preservestypability, we include location contexts, R, in ourjudgements. A type system for ML program expressions canbe obtained by letting R be empty in all the axioms andinference rules.

Just as for pre-types, we will place some restrictions onvalid typing judgements for expressions. Define theimperative type variables of a context to be the set of typevariables that are imperative in any type appearing in thecontext, i.e.,

ITV(1, R)= .x : _ # 1

ITV(_) _ .l : { # R

ITV({).

To motivate the restrictions that we will place on typingjudgements, consider a store s with domain [l1 , ..., lm] suchthat the value s(li) stored in location li has type {i . Lete1 , ..., en be closed expressions with ei having type _i . Infor-mally, a judgement

[x1 : _1 , ..., xn : _n], [l1 : {1 , ..., lm : {m]i e: {

asserts that if, starting in store s, we evaluate expressionse1 , ..., en and substitute the resulting values for x1 , ..., xn

in e, the resulting expression evaluates to a value of type {.In this case, we want any type variable free in the type of avalue in the final store to be imperative in {. Any variablethat is imperative in one of the _i 's or {i 's may be free in thetype of a stored value after evaluation of the ei 's or in theinitial store, and will therefore be free in the type of a storedvalue in the final store obtained after evaluation of e. Wetherefore say that a judgement 1, Ri e: { is a well-formedtyping judgement iff

v { is a well-formed monotype, and

v For all : # ITV(1, R) & FTV({), : # ITV({).

The type system depends on a set of typings for term con-structors. These are given by a function TypeOf defined onall term constructors f, where if ( f, n) # C, then TypeOf ( f )is an expression of the form ({1 , ..., {n O {). We use thefollowing notational conventions in the presentation of thetype system. We write 1(x) (and similarly R(l )) for theunique _ with x : _ in 1, if it exists, and 1, x : _ for1 _ [x : _], assuming x � 1. For any set of type variables,



T, we define the substitution ImpT with domain T byImpT (:)=:

�0. The closure of { with respect to 1, written

Clos1{ is the polytype \:1 , ..., :n .{, where [:1 , ..., :n]=ATV({)"FTV(1 ) and FTV(1) is the set of all free typevariables in the types appearing in 1. The restriction on onlybinding applicative type variables keeps variables thatmight appear in the types of stored values from being usedpolymorphically.

(var) 1, Ri x : ImpT ({) if 1(x)O{

(loc) 1, Ri l : R(l) ref

(const)1, Ri e1 : S{1 } } } 1, Ri en : S{n

1, Ri f (e1 , ..., en) : S{

ifTypeOf ( f )=({1 , ..., {n O {),

ITV(S{i) & ATV(S{)=,

(abs)1, x : {1 , Ri e : W({2)1, Ri *x .e : {1 � {2

(app) 1, Ri e1 : {1 � {2 1, Ri e2 : {1

1, Ri e1e2 : W({2)

(let)1, Ri e1 : {1 1, x : Clos1{1 , Ri e2 : {

1, Ri let x=e1 in e2 : {

(ref ) 1, Ri ref: { � Set1({) ref

(deref )1, Ri e : { ref

1, Ri !e : {

(assign)1, Ri e1 : { ref 1, Ri e2 : {

1, Ri e1 :=e2 : {

Note that in the rule (var), T can be any arbitrary set oftype variables. An implicit side-condition on all the axiomsand typing rules is that the type judgement in the conse-quent is a well-formed typing judgement. This condition isnon-trivial only for (var), (const), (ref ), and (abs). In otherwords, for all the remaining rules, if the premises are well-formed typing judgements, so is the consequent.

The typing rule for ref enforces the restriction that anyvalue placed in the store must have a type in which all typevariables are imperative. Thus, while ref can be applied toan expression of unrestricted type {, the resulting referencecell would have an imperative type, since W(Set1({)) is animperative type for any type {. Since applicative variablesdo not appear in the type of a stored value, the (let) rulegeneralizes all applicative type variables that are not free inthe variable-context. Further, by our restriction on well-formed typing judgements, these applicative variables alsocannot occur free in R, since all the free variables of R areimperative.

To understand the (abs) rule, we can give an alternativebut equivalent formulation. For any set T of type variables,we define the map Up"T on monotypes, increasing thestrength of all variables except imperative occurrences ofvariables from T, by

Up"T (:�

0)=:�

0 if : # T

Up"T (;�

i)=;�

i+1 if ; � T or i>0

Up"T (:i)=:i+1

Then the (abs) rule, together with the side-condition that theresulting judgement is well-formed, is equivalent to the rule

1, x : {1 , Ri e : {2

1, Ri *x .e : {1 � Up"T ({2)

with T$ITV(1, x : {1 , R), T�ATV({1) and for any: # ITV(1, R) & FTV({1), : # ITV({1). Focussing only onthe condition that T$ITV(1, x : {1 , R), this rule has theeffect of permitting any of the imperative variables of {2 ,except those occurring imperatively in 1, x : {1 , R, to bemade applicative. The variables that are imperative in {2 butnot in 1, x : {1 , R are those that appear in a stored value asa result of the evaluation of e. Since the evaluation of *x .edoes not evaluate e, the references that e creates would notresult from the evaluation of *x .e and hence can be safelymade applicative.

Since stores are defined using values, which are syntacticexpressions, we can use the type system to define storetypings for stores. We say that a store s has store typing R,written s : R, if Dom(s)=Dom(R) and for all l # Dom(s) wecan derive the judgement ,, Ri s(l ): R(l ).

5. RELATION TO SML�NJ

In the absence of a simple presentation of the algorithmused by the New Jersey implementation of Standard ML,it is difficult to prove that all the expressions typable inSML�NJ are typable in our type system. Such a resultcoupled with our soundness proof would establish thesoundness of SML�NJ. However, by allowing mixed``ordinary'' and ``weak'' occurrences of a type variable andassociating indices with ``ordinary'' occurrences as well,and a more careful accounting of the strengths duringapplication and abstraction we are able to type-check manyexpressions which SML�NJ rejects. In this section, we giveexamples of such expressions. Along with demonstrating theexpressive power of our type system, these examples helpunderstand how the type system works. In passing, we notethat it can be shown that all expressions typable in StandardML [MTH90, Tof90] are typable in our type system;however, since the proof requires precise detailing of thetype system of [Tof90], we omit it from this paper.



In [LW91], Leroy and Weis give examples of variousbenchmark expressions to type-check. Their expressions fallinto two categories. One class of expressions is those whichuse references only locally and which are given the sametypes in their type system as the corresponding applicativeexpressions. The other class of expressions are those whichexercise the compatibility between functions that createmutable data and higher-order functions, all of which arerejected by SML�NJ. Leroy and Weis take this to bestrong evidence that SML�NJ does not handle full func-tionality correctly. However, our type system acceptssuch examples of expressions given in [LW91, TJ92]. Oneexample is the expression (*x .x) ref. With our abstractionand application rules it can be seen that ,i *x .x:(:0 � :

�1 ref) � (:1 � :

�2 ref) and hence ,i (*x .x) ref:

:0 � :�

1 ref which is the same type as ref. However,SML�NJ rejects this expression. A more complicatedexample in the same vein is map ref, where map is thefamiliar functional that when applied to a function f returnsa function that maps any list l to the list resulting fromapplying f to each element of the list l. While map ref isrejected by SML�NJ, in our type system it can be given thetype list(:0) � list(:

�1 ref ), where list is a unary type-

constructor representing the type of lists. Thus our typesystem demonstrates that weak polymorphism, if for-mulated carefully, can indeed work well when applicativeand imperative functions are mingled.

A concept in our system that is different from SML�NJ isthe association of indices with ordinary type variables,which allows us to infer any applications in the body ofexpressions, including purely functional ones. Thus *x .xhas the type :0 � :1, while *x .x nil has the type(list(:0) � ;1) � ;1. The increase in the index of : in theresult type of *x .x relative to its index in the argumenttype indicates the lack of any applications , while the indexof ; remaining the same in both argument and result typesof *x .x nil indicates the application inside its body.(Since the occurrences of ; are all ordinary, we also have*x .x nil : (list(:0) � ;6) � ;6, for example.) On the otherhand SML�NJ gives these expressions the types : � : and(: list � ;) � ;, with : and ; implicitly considered to be ofstrength �. However, since such a type gives no informa-tion about applications inside the body, SML�NJ is forcedto be conservative when such expressions are applied to say,ref. Hence, SML�NJ rejects (*x .x nil) ref correctly,but is also forced to reject (*x .x) ref. Using indices onordinary type variables, we correctly deal with both theseexpressions as shown below:

(*x .x nil) : \:; . (list(:0) � ;1) � ;1

o (list(:0) � list(:�

1) ref ) � list(:�

1) ref.

Hence, (*x .x nil) ref : list(:�

0) ref.

On the other hand,

(*x .x) : \: .:0 � :1o (:0 � :�

1 ref ) � (:1 � :�

2 ref )

and thus, (*x .x) ref : :0 � :�

1 ref.

6. SOUNDNESS

In this section, we prove the soundness of the type system.The main lemma is a weaker form of the subject reductionproperty which shows the preservation of typability, forclosed expressions, under evaluation. Since wrong, the run-time error, is not typable and only closed expressions arecompiled, this is sufficient to prove the correctness of ourtype system. Since store typings were defined in Section 4.2using derivability in the type system, rather than as maximalfixed points, we do not have to use co-induction in ourproofs. This makes our soundness proof simpler than theone given in [Tof90].

We begin by proving some syntactic properties of the typesystem. In the following we use |&1, Ri e : { to indicatethat the judgement 1, Ri e : { is derivable. Our first lemmais a generalization of the standard property of closure oftyping derivations under substitution. It shows that by sub-stituting for variables in a provable typing judgement,adding assumptions to the context, and making any numberof variables in the type of the expression imperative, we stillobtain provable typing judgements. To make the lemmaeasier to state, we first define the notion of an ``instance'' ofa typing judgement.

Definition 6.1. Let 1, Ri e : { and 1 $, R$i e : {$ bewell-formed typing judgements. We say that 1 $, R$i e : {$is an instance of 1, Ri e : { if there is a substitution S suchthat \x # Dom(1 ), 1 $(x)=ImpTx(S1(x)) for some set Tx ,\l # Dom(R), R$(l )=SR(l ), and {$=ImpT (S{) for someset T.

Lemma 6.2. If 1 $, R$i e : {$ is an instance of 1,Ri e : { and |&1, Ri e : {, then |&1 $, R$i e : {$.

Proof. The proof proceeds by induction on the proof of1, Ri e : { and case analysis on the last axiom or proof ruleused. We describe the representative cases of (var) and(abs). The latter case is particularly illustrative since it usesthe restrictions on well-formed types and well-formedtyping judgements. In each case, assume that 1 $, R$i e : {$is an instance of 1, Ri e : { via substitution S and sets Tx ,for each x # Dom(1 ), and set T.

(var) The axiom has the form

1, Ri x : ImpT1({1)

with {=ImpT1({1). Let 1(x)=\:1 } } } :n .\ and let S1 be the

substitution with domain [:1 , ..., :n] such that {1=S1 \.



We need to find substitution S$ and variable-set T $, so that{$ is the result of making the variables of T $ imperativein an instance of 1 $(x) via substitution S$. Let 1 $(x)=\;1 } } } ;n .\$. Consider the substitution S$ with domain[;1 , ..., ;n] given by S$(;i)=S(S1(:i)). Then, {$ =ImpITV({$)(S$ 1 $(x)) and hence 1 $, Ri x : {$ is a validapplication of the (var) axiom.

(abs) The last step is of the form

1, x : {1 , Ri e$ : W({2)1, Ri *x .e$ : {1 � {2

with {={1 � {2 . Consider 1 $$=1 $, x : ImpT (S {1), {"=W(ImpT (S{2)). We prove that |&1 $$, R$i e${", from whichit follows using the (abs) rule that |&1 $, R$i *x .e : ${$. Wefirst see that 1", R$i e$ : {" is a well-formed judgement.Since, {$=ImpT (S{1) � ImpT (S{2) is a well-formed typeexpression, we must have that {" is a well-formed typeexpression. Now, suppose that : # ITV(1", R$) & FTV({").If : # ITV(1 $, R$) then since 1 $, R$i e$ : {$ is a well-formedtyping judgment we have that : # ITV(ImpT(S{2)) andhence : # ITV({"). And, if : # ITV(ImpT (S{1)) then since{$ is a well-formed type expression we get that : #ITV(ImpT (S{2)) and hence : # ITV({"). We next observethat {"=ImpT (S(W({2))), since for any substitution S,S(W({))=W(S({)) if W({) is defined. Hence using substitu-tion S, Tx=T, we can obtain 1", R$i e$ : {" as an instanceof 1, x : {1 , Ri e$ : W({1) which is therefore derivable bythe induction hypothesis. K

As corollaries of Lemma 6.2, we obtain statementsdescribing the behavior of derivable type judgements undersubstitutions, and adding variables and locations to thecontext. In our type system adding assumptions to the con-text may have the effect of forcing some additional variablesin the type of the expression to be imperative.

Corollary 6.3 (Type Substitution). Suppose |&1,Ri e : {. Let S be any substitution and T any set of typevariables such that S1, SRi e : ImpT (S{) is a well-formedtyping judgement. Then, |& S1, SRi e : ImpT (S{).

Corollary 6.4 (Adding Variables and Locations).Suppose |&1, Ri e : {. Let 1 $$1, R$$R. Then |&1 $,R$i e: ImpITV(1 $, R$) {.

Proof. For any well-formed monotype { and any setof type variables T, ImpT ({) is still a well-formedmonotype. K

We now establish a term-substitution property whichis crucial to proving the subject reduction property for;-reduction and the reduction of let-expressions. Theproperty we are interested in is Corollary 6.6 which is notprovable directly by induction. We therefore prove a

stronger statement in the following lemma. The statement ofthe lemma also provides formal justification for allowingtype variables to be made imperative in the (var) axiom.

Lemma 6.5. Assume that |&1, x : \:1 } } } :n .{, Ri e : {$and [:1 , ..., :n] & FTV(1, R) = <. If |&1, Ri v:ImpITV(1, R ) { then |& 1, Ri [v�x] e : {$.

Proof. By induction on the structure of e. We show thecases when e is a variable, *-abstraction, and let-expres-sion��the last two cases illustrate our choice of inductionhypothesis.

Case. e=x$. If x${x then the lemma is trivially true.Otherwise, there is a substitution S with domain [:1 , ..., :n]such that {$=ImpT (S{). By the definition of well-formedtyping judgements, we can assume that T$ITV(1, R).Since [:1 , ..., :n] & FTV(1, R)=< we have that S1,SR=1, R. Thus, applying Lemma 6.2 to 1, Ri v:ImpITV(1, R ) {, we can derive the judgment

1, Ri v : ImpT (S(ImpITV(1, R ) {))

And, since T$ITV(1, R), ImpT (S(ImpITV(1, R ) {))={$.Hence |&1, Ri [v�x] x : {$.

Case. e=*x$.e1 . Then,

1, x : \:1 } } } :n .{, x$ : {1 , Ri e1 : W({2)1, x : \:1 } } } :n .{, Ri *x$ .e1 : {1 � {2

Let [;1 , ..., ;n] be distinct variables such that ;i �FTV(1, R) _ [:1 ,..., :n]. Let S be the substitution definedby S(:i)=;0

i , 1 $=1, x$ : S{1 . By the definition of well-formed typing judgements and the nature of S, allimperative variables of 1 $, x : \:1 , ..., :n .{, R can onlyappear imperatively in S(W({2)). Hence, using Lemma 6.2,and substitution S on the premise of the (abs) rule, we canderive

1 $, x : \:1 } } } :n .{, Ri e1 : S(W({2)),

since S1, SR=1, R. By the choice of S, [:1 , ..., :n] &

FTV(1 $, R)=<. We have that |&1, Ri v : {", where{"=ImpITV(1, R ) {. Using Corollary 6.4, |&1 $, Ri v:ImpITV(1 $, R ) {". Since ITV(1 $, R)$ITV(1, R), we thushave that |&1 $, Ri v : ImpITV(1 $, R ) {. Hence, by inductionhypothesis, we can derive

1 $, Ri [v�x] e1 : S(W({2)).

Let S$(;i)=:0i . Using S$ with Corollary 6.4, we can derive

1, x$ : {1 , Ri [v�x] e1 : W({2).

Now, using the (abs) rule, we can get the desired judgement.



Case. e=let x$=e1 in e2 . Then,

1, x : \:1 } } } :n .{, Ri e1 : {1

1, x: \:1 } } } :n .{, x$: Clos1, x:\:1 } } } :n .{{1 , Ri e2 : {$1, x: \:1 } } } :n .{, Ri let x$=e1 in e2 : {$

Let [:i1 , ..., :im] = ITV({1) & [:1 , ..., :n], with m � 0,i1< } } } <im . Let ;1 , ..., ;m be distinct variables such that;i � FTV(1, R) _ FTV({1) _ [:1 , ..., :n] and let S be thesubstitution defined by S(:ij)=;0

j . Using Lemma 6.2,and substitution S on the left premise of the (let) rule, wecan derive 1, x : \:1 } } } :n .{, Ri e1 : S({1), since S1,SR=1, R. Thus, by the induction hypothesis applied to e1 ,we have that

|&1, Ri [v�x] e1 : S({1) (1)

Since ;i � FTV({1) and since the :ij 's occur imperatively in{1 , it follows that

S(Clos1, x:\:1 } } } :n .{{1)=Clos1,x:\:1 } } } :n .{ (S{1).

Thus, applying substitution S to the second premise of the(let), we can derive

1$, x: \:1 } } } :n .{, Ri e2 : S{$,

where 1$=1, x$: Clos1, x:\:1 } } } :n .{(S{1). We have that

|&1, Ri v : {"

where {"=ImpITV(1, R) {. By an argument, similar to the*-abstraction case we can show that

|&1$, Ri v: ImpITV(1$, R ){.

Thus, by induction hypothesis applied to e2 , we can derive1$, Ri [v�x] e2 : S{$. By Proposition 6.7, we have that

|&1, x$: Clos1S{1 , Ri [v�x] e2 : S{$. (2)

From (1), (2), using the (let) rule, we get

|&1, Ri [v�x] e : S{$.

Now applying the substitution S$(;j)=:0ij , we get the

desired judgment. K

Corollary 6.6 (Term Substitution). If |&1, x :\:1 } } } :n .{, Ri e : {$ and |&1, Ri v : { with [:1 , ..., :n] &

FTV(1)=< then |&1, Ri [v�x] e : {$.

Proof. We have that 1, Ri v : { is derivable. By therestriction on well-formed typing judgements, ImpITV(1, R ) {={. Hence, by Lemma 6.5, we have the desired result.

Proposition 6.7. If |&1, x : \:1 } } } :n .{, Ri e : {$ then|&1, x : \:1 } } } :n } } } :n+m .{, Ri e : {$, for any m�0 andvariables :n+1, ..., :n+m .

Proof. A straightforward induction on the structure of e.The only important cases are when e is the variable x or alet-expression, which we show below.

Case. e=x. Then {$=ImpT (S{) for some substitution Swith domain [:1 , ..., :n]. Consider the substitution S$with S$(:n+i)=:0

n+i for i�m and S$(:i)=S(:i) for i�n.Clearly, S${=S{ and we get the desired conclusion using(var) with substitution S$ and set T.

Case. e=let x$=e1 in e2. Then, we have

1, x: \:1 } } } :n .{, Ri e1 : {1

1, x: \:1 } } } :n .{, x$: Clos1, x:\:1 } } } :n .{ {1 , Ri e2 : {$1, x: \:1 } } } :n .{, Ri let x$=e1 in e2 : {$

By induction hypothesis applied to the left premise, we get

|&1, x : \:1 } } } :n } } } :n+m .{, Ri e1 : {1 . (3)

By induction hypothesis applied to the second premise, weget

1, x: \:1 } } } :n } } } :n+m .{, x$: Clos1,x:\:1 } } } :n .{ {1 , Ri e2 : {$.

Since FTV(1, x: \:1 } } } :n } } } :n+m .{)�FTV(1, x: \:1 } } }:n .{), we can apply the induction hypothesis to e2 again toobtain

|&1, x: \:1 } } } :n .{, x$: Clos1,x:\:1 } } } :n } } } :n+m .{ {1 , Ri e2 : {$

(4)

Applying the (let) rule to (3), (4) we get the desiredconclusion. K

Using the above lemmas, we are now ready to connect thetype system with the operational semantics. To establish thecorrespondence with the semantics, we need to assumesome properties of the typings for the term constructors,since our proof system depends on them. The followingdefinition states what we require of the typings for the termconstructors.

Definition 6.8. The typing for term-constructors givenby TypeOf is admissible if the resulting proof system forderiving typing judgments has the following properties:



(i) For all values v # V (i.e., other than *-abstractions,ref, and location constants), if |&,, Ri v : { for any storetyping R and type {, then { is of the form b({1 , ..., {n) forsome type constructor b.

(ii) Let (e1 , e2) # F. For any R, {, if |&,, Ri e1 : {then |&,, Ri e2 : {.

It is a consequence of (i) that the only functional valuesare *-abstractions and ref, and the only values that arereference cells are location constants. (Indeed, we couldhave eliminated ref from being a value as well, by havingthe redex ref ^ *x .ref x). Condition (ii) requires thetypings for term constructors to be consistent with theiroperational properties as given by their functional reduc-tions. We assume in the following lemmas that the giventypings for term-constructors is admissible.

Our operational semantics was described by defining thenotions of redexes, evaluation contexts, and evaluationsteps, in that order. The presentation of the lemmas forestablishing the soundness of our type system follows thesame order. First, we prove subject reduction for the purelyfunctional reductions.

Lemma 6.9 (Subject Reduction for Functional Reduc-tions). If |&,, Ri e1 : { and e1 ^ e2 then |&,, Ri e2 : {.

Proof. By case analysis on e1 ^ e2 .

Case. (*x .e) v ^ [v�x]e. Assume |&,, Ri (*x .e) v{.Then |& ,, R i *x .e : {1 � {2, |& ,, Ri v : {1 and {=W({2). From |&,, R d *x .e : {1 � {2, we have |&x : {1 ,Ri e : W({2). Using Corollary 6.6 we get |&,, Ri

[v�x] e : {.

Case. (let x=v in e) ^ [v�x]e. Assume |&,,Ri let x=v in e : {. Then

|&,, Ri v : {1, |&x : Clos,{1 , Ri e : {

Since ,, Ri v : {1 is a well-formed typing judgement, if: # ATV({1) then : � FTV(R). Hence, using Corollary 6.6we get |&,, Ri [v�x] e : {.

Case. v1v2 ^ wrong. Since v1 is not a *-abstraction orref, it must be a location constant or a value in V. Theformer can only have a type of the form {$ ref and the lattercan only have a type of the form b({1 , ..., {n) by condition (i)of admissibility. Hence, |&% ,, Rv1 {1 � {2 for any R, {1 , {2 .Hence |&% ,, Ri v1 v2 : { for any R, { and the statement istrue vacuously.

Otherwise e1 ^ e2 is a redex involving term-construc-tors and the statement is true by condition (ii) ofadmissibility. K

We might expect a proof of soundness to proceed byextending Lemma 6.9 to establish subject reduction forevaluation. In more detail, suppose that (e, s) [ (e$, s$). Wewould like to establish that if e has type {, then so does e$.Note that because of the possibility of creation of referencecells, e$ may mention location constants that do not appearin e. For this reason, the typing of e$ must involve assump-tions about additional location constants. By our restrictionon typing judgements, e$ can then have type { only if thetype variables in the types of the new location constantsappearing in e$ all appear imperatively in {. Unfortunatelythis condition on type variables may not be true, since thereis nothing in our type system to force ``new'' type variablesto be used whenever possible. As a result, an applicativetype variable in { could ``accidentally'' be the same as one inthe type of a new reference cell created. However, as (iii) ofthe following lemma shows, such applicative variables in {can be suitably renamed so that e$ can be given the renamedtype. The form of the renaming is the crucial formaljustification for allowing all applicative variables to betreated polymorphically in the (let) rule. It is also in theproof of (iii) that we see the formal origin of our restrictionson the syntactic form of types and typing judgements. Parts(i) and (ii) express obvious properties, but have been statedexplicitly merely for ease of reference in the proof of Lemma6.11.

Lemma 6.10. Let E[ ] be any evaluation context andsuppose that |&,, Ri E[e] : {. Then,

(i) |&,, Ri e : {1 for some type {1 .

(ii) If |&,, Ri e$ : {1 , then |&,, Ri E[e$] : {.

(iii) Suppose that for some R$$R and some expressione$, we have that |&,, R$i e$ : {1. Let [:1 , ..., :n]=ATV({).Then for some distinct variables ;1 , ..., ;n such that;i � FTV(R$) we have that |&,, R$i E[e$] : SE{ whereSE=[;0

1�:1 , ..., ;0n �:n].

Proof. By induction on the structure of E[ ].Statements (i) and (ii) can be proved trivially, so we onlyshow details for (iii). Note that for any distinct ;1 , ..., ;n

such that ;i � FTV(R$) we have that ,, Ri E[e$] :[;0

1 �:1 , ..., ;0n�:n]{ is a well-formed judgment since

ATV([;01 �:1 , ..., ;0

n �:n] {)=[;1 , ..., ;n].

v E[ ]#[ ]. Let [:1 , ..., :n]=ATV({1). Choose any;1 , ..., ;n such that ;i � FTV(R$). Since ,, R$i e$ : {1 is awell-formed judgment and FTV(R$)=ITV(R$) we havethat :i � FTV(R$). Hence for S[ ]=[;0

1�:1 , ..., ;0n�:n],

S[ ]R$=R$. Hence using Lemma 6.2, |&,, R$i e$ : S[ ]{1 .

v E[ ]#E1 e2 . Then we can derive

,, Ri E1 [e] : {$ � {2 (5)

,, Ri e2 : {$ (6)



and {=W({2). Let [:1 , ..., :n]=ATV({). Clearly ITV({2)�ITV({). Hence ATV({) � ATV({2) � ATV({$ � {2).Thus, ATV({$ � {2)=[:1 , ..., :n , :n+1 , ..., :p] for somevariables :n+1 , ..., :p . By inductive hypothesis about E1 [ ],

|&,, R$i E1[e$] : SE1({$) � SE1

({2),

where SE1(:i)=;0

i , 1�i� p for some variables ;1 , ..., ;n

such that ;i � FTV(R$). Since (5) is a well-formed judgment,Dom(SE1

) & FTV(R$)=<. Hence SE1R=R. Note that ,,

R$i e2 : SE1{$ is a well-formed judgment since ATV(SE1

{$)�[;1 , ..., ;p] and [;1 , ..., ;p] & FTV(R$)=,. Henceusing Lemma 6.2 on (6) with substitution SE1

, we getthat |&,, R$i e2 : SE1

{$. Thus using (app), |&,, R$iE[e$] : SE1

(W({2)), i.e.,

|&,, R$i E[e$] : SE1(W({2)) (7)

since W(SE1{2) = SE1

(W({2)), as W{2 is defined. LetS$ = [:0

n+1�;n+1, ..., :0p�;p]. Take SE = S$ b SE1

. SinceDom(S$) & R$=,, using substitution S$ and Corollary 6.3on (7) we get |&,, R$i E[e$] : SE ({).

v E[ ]#vE1 . Then we can derive

,, Ri v : {$ � {2

,, Ri E1 [e] : {$

and {=W({2). Let ATV({$)=[:1 , ..., :n]. By the induc-tive hypothesis about E1 , we have variables ;1 , ..., ;n �FTV(R$) such that

,, R$i E1[e$] : SE1({$)

with SE1=[;1

0�:1 , ..., ;n0�:n]. Since ATV({$)�ATV({$ � {2),

we have ATV({$ � {2)=[:1 , ..., :n , :n+1, ..., :p] for somevariables :n+1 , ..., :p . Choose any distinct variables;n+1 , ..., ;p such that ;j � FTV(R$), n+1�j�p. ConsiderS$=[;1

0�:1 , ..., ;p0�:p].

We claim that S${$=SE1{$. For consider any : # FTV({$).

If : # ATV({$) then clearly S$(:)=SE1(:). Otherwise

: # ITV({$) whence : # ITV({2) by our restriction on thewell-formed type {$ � {2 . This is the formal origin of ourrestriction on well-formed types. Hence : # Dom(S$) andS$(:)=SE1

(:). Then we use reasoning similar to that in theprevious case.

v E[ ]#let xE1 in e2. Then we can derive

,, Ri E1[e] : {$ (8)

x : Clos, {$, Ri e2 : {. (9)

By induction hypothesis,

|&,, R$i E1[e$] : SE1{$ (10)

for some suitable SE1. By the form of substitution SE1

,Clos,{1=Clos,SE1

({1), which was precisely the purpose ofthe inductive statement in (iii).

Let [:1 , ..., :n]=ATV({). Choose any distinct ;1 , ..., ;n

such that ;i � FTV(R$) _ ITV({$). Let SE=[;10�:1 , ...,

;n0�:n]. Then clearly

x : Clos, {1 , R$i e2 : SE{

is a well-formed judgement. Also since FTV(Clos,{1)=ITV(Clos, {1) and since (9) is a well-formed judgment,:i � FTV(Clos,{1). Thus using Lemma 6.2 on (9) withsubstitution SE we have

|&x : Clos,(SE1{$), R$i e2 : SE{.

Combining with (10),

|&,, R$i E[e$] : SE{.

Other cases of evaluation contexts are similar. K

Under suitable assumptions about the store in which anexpression is evaluated, we can now establish that evalua-tion of typable expressions leads to typable expressions.

Lemma 6.11 (Preservation of Typability). Suppose(e, s) [ (e$, s$) and R is a store typing such that s : R and|&,, Ri e : {. Then there is a store typing R$ such thats$ : R$ and for some type {$, |&,, R$i e$ : {$.

Proof. By case analysis on [ .

v (E[e], s) [ (E[e$], s) with e ^ e$. Assume that|&,, Ri E[e] : {. From Lemma 6.10(i), we have that|&,, Ri e : {1 for some type {1 . By Lemma 6.9, |&,, Ri

e$ : {1. Now, using Lemma 6.10(ii), |&,, Ri E[e$] : {. And,by assumption s : R.

v (E[ref v], s) [ (E[l], s[l [ v]). By Lemma 6.10 (i),|&,, Ri ref v : {1 for some type {1 . Hence |&,, Ri v : {1$and {1=W(Set1({$1)) ref.

Consider R$=R, l : Set0({1$). For l ${l, since |&,, Ri

s(l $) : R(l $) and R(l $) is imperative, we have by Corollary6.4, |&,, R$i s(l $): R(l $), i.e., |&,, R$i s$(l $): R$(l $) wheres$=s[l [ v]. And, since |&,, Ri v : {1 $, by Corollary 6.4,|&,, R$i v: ImpITV(R$) {1$. Clearly, ImpITV(R$) {1$=Set0({1$).Hence, |&,, R$i s$(l ): R$(l ) and thus s$ : R$. Trivially, |&,,R$i l : {1, since W(Set1({1)$)=Set0({1$). Thus, by Lemma6.10 (iii), |&,, R$i E[l] : {$ for {$=SE ({).



v (E[!l], s) [ (E[s(l)], s). By Lemma 6.10(i), |&,, Ri

!l : {1. Hence, |&,, Ri l : {1 ref, i.e., R(l )={1 . Since s : R,we have that |&,, Ri s(l ) : R(l ), i.e., |&,, Ri s(l ) : {1.Now, using Lemma 6.10(ii), we get that |&,, Ri E[s(l)] : {.

v (E[l :=v], s) [ (E[v], s[l [ v]). Then |&,,Ri l : {1 ref, |&,, Ri v : {1. Hence s[l [ v] : R. Andsince |&,, Rv{1, by Lemma 6.10 (ii), |&,, Ri E[v] {1 .

v (E[e], s) [ (wrong, s), where e ^ wrong. ByLemma 6.9, since wrong is not typable, there is no R, {1

such that |&,, Ri e : {1. By Lemma 6.10(i), this impliesthat _% R, { such that |&,, Ri E[e] : { and the lemma isthus true vacuously.

v (E[!v], s) [ (wrong, s), where v � Loc. By admis-sibility condition (i) and the abs rule, |&% ,, Ri v : {1 ref forany R, {1 . Hence |&% ii ,:, R: !v{1 for any R, {1 . Thensimilar to previous case.

v (E[v1 :=v2], s) [ (wrong, s), where v1 � Loc. This issimilar to previous case. K

As a corollary of Lemma 6.11, we can now establish thatstarting in the initial store, evaluation of any typable userprogram leads to typable expressions.

Corollary 6.12. Let e be a program, i.e., a closedexpression with no location constants. If e is typable, i.e.,|&,, ,i e : { for some type { then for any e$, s$ such that(e, init) [� (e$, s$) we have that e$ is typable.

Proof. The store init has the empty store typing, i.e.,init : ,. Now the statement follows from Lemma 6.11. K

Finally, we can establish our main theorem, that well-typed programs do not lead to run-time errors. And, byLemma 3.2, under suitable assumptions about the specifica-tion of the operational behavior of the term constructorsthis implies that every typable program either diverges orresults in a value.

Theorem 6.13. Let e be a typable program. ThenEval(e){wrong, i.e., e does not lead to a run-time error.

Proof. There is no R$, {$ such that |&,, R$i wrong : {$.Hence, by Corollary 6.12 we cannot have (e, init) [�(wrong, s$), for any store s$. K

Thus, by Theorem 6.13 and Lemma 3.2, every typableprogram either yields a value or diverges, i.e., evaluation oftypable programs cannot get ``stuck'' at a non-answerexpression from which no further evaluation is possible.

7. CONCLUSION

We present a type system, in the form of typing rules,using weak type variables. Intuitively, a weak type variableis a variable with a numeric index, indicating the number of

function applications needed to produce a reference cellcontaining a value of this type. Although the Standard MLof New Jersey source code is sufficiently complex to makedirect proof difficult, extensive experiments with the com-piler and examination of the source code suggest that ourtype system strictly subsumes the implemented type system.Moreover, as noted in Section 5, our type system is suf-ficiently flexible to accept all the benchmark examples listedin [LW91] with more readable and compact expressionsthan those in [LW91, TJ92, Wri92]. In light of the com-ments on the limitations of SML�NJ in [LW91] and[TJ92], our type system shows that simple indexed typevariables allow more flexible typing of imperative programsthan previously believed. To the extent that our type systemsubsumes the implemented algorithm, Theorem 6.13 showsnot only the semantic soundness of our typing rules, butalso the soundness of the SML�NJ algorithm that has beenused for several years. Since our type system is more flexiblethan the one used in the SML�NJ, but requires very littlechange in displayed type expressions, we believe it is a goodcandidate for later implementations of ML and otherpolymorphic programming languages that have imperativeor control constructs.

With a minor modification, our type system does admit atype-inference algorithm which infers the most general typeof any term. This modification consists in allowing theindices of type variables to be variables, in addition tonatural numbers. This makes it possible to express mostgeneral typings for terms. The type inference algorithm thenuses a generalization of unification for indexed variables.We defer the details of the type-inference algorithm to aseparate paper.

Received August 2, 1993; final manuscript received January 18, 1996

REFERENCES

[AM87] Appel, A. W., and MacQueen, D. B. (1987), A Standard MLcompiler, in ``Functional Programming Languages and Com-puter Architecture,'' Lecture Notes in Computer Science,Vol. 274, pp. 301, 324, Springer-Verlag, Berlin�New York.

[AM91] Appel, A. W., and MacQueen, D. B. (1991), Standard ML ofNew Jersey, in ``Int'l Symp. Prog. Lang. Implementation andLogic,'' pp. 1�13, Springer-Verlag, Berlin�New York.

[CF58] Curry, H. B., and Feys, R. (1958), ``Combinatory Logic I,''North-Holland, Amsterdam.

[Dam85] Damas, L. (1985), ``Type Assignment in ProgrammingLanguages,'' Ph.D. thesis, Edinburgh University CST-33-85.

[Gre96] Greiner, John, Weak polymorphism can be sound, J. Funct.Programming, to appear.

[Hin69] Hindley, J. R. (1969), The principal type-scheme of an objectin combinatory logic, Trans. Amer. Math. Soc. 146, 29�60.

[HL91] Harper, R., and Lillibridge, M. (1991), A brug in SMLpolymorphic typing for continuations, E-mail to types�theory.lcs,mit.edu .



[JG91] Jouvelot, P., and Gifford, D. (1991), Algebraic reconstructionof types and effects, in ``18th ACM Symposium on Principlesof Programming Languages,'' pp. 303�310.

[KMM91] Kanellakis, P. C., Mairson, H. G., and Mitchell, J. C. (1991),Unification and ML type reconstruction, in ``ComputationalLogic, Essays in Honor of Alan Robinson,'' pp. 444�478, MITPress, Cambridge, MA.

[Koe92] Koenig, A. (1992), An anecdote about ML type inference,unpublished manuscript.

[KTU90] Kfoury, A. J., Tiuryn, J., and Urzyczyn, P. (1990), MLtypability is Dexptime-complete, in ``Proc. 15th Colloq. onTrees in Algebra and Programming,'' Lecture Notes in Com-puter Science, Vol. 431, pp. 206�220, Springer-Verlag, Berlin�New York; to appear in J. Assoc. Comput. Mach. under title`Àn Analysis of ML Typability.''

[LW91] Leroy, X., and Weis, P. (1991), Polymorphic type inferenceand assignment, in ``18th ACM Symposium on Principles ofProgramming Languages,'' pp. 291�302.

[Mil78] Milner, R. (1978), A theory of type polymorphism in

programming, J. Comput. System Sci. 17, 348�375.[MTH90] Milner, Robin, Tofte Mads, and Harper Robert (1990), ``The

Definition of Standard ML,'' MIT Press, Cambridge, MA.[TJ92] Talpin, J.-P., and Jouvelot, P. (1992), The type and effect dis-

cipline, in ``Proc. IEEE Symp. on Logic in Computer Science,''pp. 162�173.

[Tof88] Tofte, M. (1988), `Òperational Semantics and PolymorphicType Inference,'' Ph.D. thesis, Edinburgh University; avail-able as Edinburgh University Laboratory for Foundations ofComputer Science Technical Report ECS-LFCS-88-54.

[Tof90] Tofte, M. (1990), Type inference for polymorphic references,Inform. and Comput. 89, 1�34.

[WF91] Wright, A. K., and Felleisen, M. (1991), `À SyntacticApproach to Type Soundness,'' Technical Report TR91-160,Rice University.

[Wri92] Wright, A. K. (1992), Typing references by effect inference, in``Proceedings of the European Symposium on Programming.''

[Wri95] Wright, A. K. (1995), Simple imperative polymorphism, LispSymbolic Comput., to appear.


Standard ML-NJ Weak Polymorphism and Imperative Constructs · 2016. 12. 28. · In Standard ML of...

Documents

Transcript of Standard ML-NJ Weak Polymorphism and Imperative Constructs · 2016. 12. 28. · In Standard ML of...