THE MACHINEASSISTED PROOF OF PROGRAMMING

LANGUAGE PROPERTIES

MYRA VANINWEGEN

A DISSERTATION

in

COMPUTER AND INFORMATION SCIENCE

Presented to the Faculties of the UniversityofPennsylvania in Partial Fulllment of the

Requirements for the Degree of Do ctor of Philosophy

August

Carl Gunter

Sup ervisor of Dissertation

Peter Buneman Graduate Group Chairp erson

ABSTRACT

The MachineAssisted Proof of Properties

Myra VanInwegen

Advisor Carl Gunter

The goals of the pro ject describ ed in this thesis are twofold First wewanted to demon

strate that if a programming language has a semantics that is complete and rigorous

mathematical but not to o complex then substantial theorems can b e proved ab out it

Second wewanted to assess the utility of using an automated theorem prover to aid in such

pro ofs Wechose SML as the language ab out which to prove theorems it has a published

semantics that is complete and rigorous and while not exactly simple is comprehensible

We enco ded the semantics of Core SML into the theorem prover HOL creating new deni

tional packages for HOL in the pro cess Weproved imp ortant theorems ab out evaluation

and ab out the typ e system We also proved the typ e preservation theorem which relates

evaluation and typing for a go o d p ortion of the language Wewere not able to complete

the pro of of typ e preservation b ecause it is not true we found counterexamples These

pro ofs demonstrate that a go o d semantics will allow the pro of of programming language

prop erties and allowtheidentication of trouble sp ots in the language The use of HOL

had its plusses and minuses On the whole the b enets greatly outweigh the drawbacks

enough so that we b elieve that these theorems could not b een proved in amount of time

taken by this pro ject had we not used automated help ii

Contents

Intro duction

Related Work

Programming Language Sp ecications

A Brief History

SML and its Sp ecication

Automated Theorem Provers and HOL

A Brief Description of HOL

Enco ding HOLSML in HOL

Enco ding the Syntax

Enco ding the Semantic Ob jects

Enco ding the Typing Relations

Proving Prop erties of Evaluation

Inversion Theorems

Determinism

Relating Static and Dynamic Semantics

Metho ds of Proving Typ e Soundness

WhyProveTyp e Preservation

Towards Proving Typ e Preservation

HowtoGiveaTypetoaValue

The Typ e Preservation Theorem iii

Substitution

Typ echecking under Substitution

Problems with the Formulation

Assessment

What HaveWe Learned Ab out SML

Was HOL Useful

A Semantics of HOLSML

A Grammar

A Static Semantics

A Dynamic Semantics

Bibliography iv

List of Tables

HOL Basic Inference Rules

Denition of Basic Logical Constants

Basic Axioms

exp pred Part of tych

Enco ding into HOL

PrimitiveFunctions for val has typ e

Rules for j

v

Rules for j j j j j

c e r f vp

Rules for Environments and Store Typ es

Full StatementofTyp echecking Under Substitution

A Grammar Expressions Matches Declarations and Bindings

A Grammar Patterns and Typ e Expressions v

Chapter

Intro duction

As computer hardware and software systems come to play a larger role in our lives

it b ecomes increasingly imp ortanttomake sure that these systems op erate as intended

While no metho d can guarantee that a system will work p erfectly there are several ways

to increase condence that a system will p erform as exp ected when used in the setting for

whichitwas designed

A system specication is a precise statement of what the system must do without saying

how it is to b e done The sp ecication must also include a description of the environment

in which the system will op erate Engineers use validation vericationand testing to help

ensure correctness of systems Validation is the pro cess of checking that the sp ecication

is correct that is that the assumptions ab out the environment are valid and that the

system designers and the customer agree on what the system should do Testing involves

running the system with a collection of inputs and checking that the outputs conform to

the sp ecication Verication consists of lo oking at the system itself in order to determine

if it meets the sp ecication without actually running it Verication usually involves the

use of mathematical logic to prove that an algorithm or circuit meets its sp ecication or

satises some given prop erties

The problem with testing is that in complex systems there are to o many cases to test

them all Occasionally one can prove that the input can b e divided up into a small number

of classes and that it is sucient to test one input from each class This is often not the

case When only a few of the inputs can b e tested testing do es not ensure the correctness of

the system This is what gives verication its app eal When a system or some abstraction

ofitisveried it has b een proved to b e correct at that level of abstraction

There are two big obstacles to verifying systems The rst is that one needs to have

precise mathematical descriptions of what the system is supp osed to do the sp ecication

and of what the system actually do es An example of the rst is a nite state automata that

gives the action of the system in each state and indicates how the system go es from state

to another An example of the second sp ecication is a mathematical mo del of a circuit

Creating these mathematical descriptions is a bigger problem than one might guess Much

of the work in formal metho ds which is the use of logicbased mathematics to increase

condence in systems has b een in formulating these mathematical descriptions

The second obstacle is that even if one has a rigorous mathematical description of

the desired prop erties and actual function of the system pro ofs of correctness are usually

large and complex This not only makes the pro ofs long and tedious but also increases

the chances that they will contain mistakes Thus one would liketohave some kind of

automated help in doing the pro ofs Not only can an automated pro of to ol help organize

and carry out the pro of but it acts as a pro of checker preventing errors

Automated pro of to ols can b e roughly divided into two classes The rst is used to

check prop erties of systems that can b e mo deled as nite state automata These systems

called model checkers are fully autonomous when given an input consisting of a nite state

automata and a prop ertytobechecked they will after some computation rep ort either

that the system satises the prop erty or return a state for which prop erty fails A go o d

reference for the use of mo del checkers in verifying prop erties of systems is McMillan

Mo del checkers do not work in all situations Sometimes the system is not easily

describable as a nite state automaton either b ecause one would need an innite number

of states or b ecause a more complex mathematical mo del is needed For instance a

system that can b e congured in an varietyofways or can haveanynumb er of comp onents

cannot b e easily describ ed as a nite state automaton An example of this would b e a cache

coherence proto col where mo del checking can only b e used to verify the proto col in certain

xed congurations

The other class of pro of to ols are semiautomated generalpurp ose theorem provers

For the rest of this thesis the term theorem prover will refer to this second class

of pro of to ols Theorem provers implement a logic for example rstorder logic and

provide some automated supp ort for proving theorems in the logic One would likeitto

b e the case that when the theorem prover is given a statement if the statement is true

then a pro of is returned and if it is not true then some pro of of its falseness p erhaps

a counterexample is returned However the logics implemented by theorem provers are

usually p owerful enough that it is imp ossible for theoretical not just practical reasons

to give an algorithm that will do this Thus these theorem provers can only nd pro ofs

for a limited numb er of statements and they often require a great deal of human input to

guide them in the pro of

The human eort required can make using a theorem prover a tedious pro cess One of

the annoyances with using a theorem prover is that it demands that everything b e proved

in great detail Statements that are obviously true to the mathematicallyknowledgeable

human are not obvious to the theorem prover it must b e convinced with a detailed pro of

Theorem provers can b e augmented with decision pro cedures to help with this problem

Decision pro cedures are programs that when given a statement of a certain form sayin

a restricted subset of the logic will determine whether or not it is true and if it is true

return a pro of There is still muchwork to b e done b efore theorem provers are suciently

powerful that they can b e feasibly applied to prove correctness of large realworld systems

It is useful to note that even if verication b ecomes more easily applicable to real

world problems it will never completely supplant testing Mathematics is sometimes

not completely convincing or understandable An analogy can b e drawn b etween formal

verication of systems and formal denitions of mathematical concepts It is often the case

that a denition is not fully understo o d until several examples have b een given For the

same reason p eople will never b e contented with seeing a mathematical pro of of correctness

of a systemthere is always the p ossibilit y that there is something wrong with the theorem

prover or it may b e the case that the mathematical description of the functionality of the

system fails to match the actual implementation of the system They will need to lo ok at

some of the pro ofs to read them and understand them and they will want to plug some

real inputs into the system and check the results

We are interested in formal verication of software Our approach is to prove prop erties

of programming languages The motivation for doing this is that if one proves a prop erty

of a language then this prop erty is true of any program written in the language Examples

of prop erties that one mightlike to prove include determinism for any program if it is

run twice with the same input it will return the same result and that certain language

This is one of its advantages as well Often statements thought to b e obviously true turn out to b e

subtly false



Verications have b een done for large realworld systems but only at a relatively high level of

abstraction

constructs cannot cause side eects Some languages have a strong notion of typ e each

phrase in the language can b e given a typ e and the typ e system determines how these

typ es t together in order for the program to b e legal A typ echecker lo oks over the co de to

make sure that the rules of the typ e system are satised by the program The typ echecker

thus do es a consistency check on the program This check can catchmany common errors

such as mistakenly using a comp osite data item in a place where a comp onent of the item

is needed or passing arguments to functions in the wrong order if the arguments b eing

reversed have dierenttyp es

A prop erty that one would like to b e satised by a programming language with a

typ echecker is type soundness for any program if the program passes the typ echecker

then it will not havea typ e error when it is executed Typ e errors include the attempted

use of a nonfunction as if it were a function such as applying the numb er to an argument

and the use of a function with the wrong typ e of argumentsuch as the addition of and

false This is not trivial a great deal of pro cessing can take place in computing the value

of a function or an argument and there are many opp ortunities for things to go wrong

The most common sources of error in programming languages are constructs that allow

avalue such as a function to have dierenttyp es in dierent situations An example

of such a function is a list reverse function that can b e used on any sort of list Proving

prop erties ab out typ echecking in a language with such constructs can b e tricky

In order to prove prop erties of a language one needs to have a mathematical sp eci

cation of the language that is a mathematical description of the form of programs the

grammar of the language a sp ecication of program evaluation and if the language has

atyp echecker a description of how one conrms that the typ es are consistent If the

semantics of a language is not given in a mathematical form one will have to b e created

for it The diculty of formalizing the semantics dep ends on the precision clarityand

complexity of the existing sp ecication

Pro ofs of programming language prop erties have b een accomplished for languages with

mathematical semantics for example see CW Tofte WF but these have

almost always b een for toy languages they were formulated for the purp ose of demon

strating programming language concepts and pro of techniques To the authors knowledge

up to the present there has b een only one pro ject involving pro ofs of programming lan

guage prop erties for real in the sense of having a user community and a go o d compiler

programming languages

Programming language sp ecications have b een with us for over three decades roughly

since the publication of the original Algol rep ort Naur Perhaps the most imp ortant

lesson to b e learned from studying the history of programming language sp ecications is

that they are dicult to get right where getting it right can b e taken to mean that the

language constructs are unambiguously describ ed and that the description is understand

able Chapter gives some examples of programming language sp ecications in various

styles and p oints out their advantages and deciencies

Standard ML SML is a real language with a complete published mathematical

semantics The Denition of StandardMLMTH SML is a mostlyfunctional language

with a strong notion of typ e and all implementations of SML provide a typ echecker SML

has features that make it not only pleasant for programming but also a go o d ob ject of

study for programming language instruction The semantics is phrased in mathematical

terms making it precise but the techniques used are not so deep as to b e imp enetrable

The evaluation and typ e system of the language are given by pro of rules that state when a

program can b e given a certain typ e and determine the value to which a program evaluates

Because of the size of SML the numb er of phrases in the grammar and the complication

of some of the rules it is natural to try to use a theorem prover to help with proving

prop erties of the language HOL for Higher Order Logic is a go o d choice for sucha

theorem prover It is typ ed and has sound easilyextensible denitional principles which

allow the enco ding of the syntax and semantics of SML In addition its higher order

features enable the denition of relations such as the evaluation relations as the smallest

relations satisfying a set of rules

The pro ject pro ceeded in this manner First we enco ded the dynamic semantics of

Core SML as given in the Denition In order to do this we needed to dene a mutually

recursivetyp es denition package for HOL The metho d we used for enco ding semantics

is describ ed in Chapter We then prov ed some theorems ab out evaluation the most

imp ortantofwhichwas that evaluation is deterministic This pro of is describ ed in Section

We decided that in order to give the pro ject a goal to aim at wewould try to prove

typ e preservation for Core SML Typ e preservation is liketyp e soundness a prop erty

that relates the static typ e system and dynamic evaluation semantics of the language

a pro of of typ e preservation is usually one of steps used in a pro of of typ e soundness



This is the work of Donald Syme describ ed in Chapter

Typ e preservation says that if a program is given a typ e by the typ e system and the

program evaluates to a value v then v has typ e Typ e preservation and our eorts

to prove it are describ ed in detail in Chapters and In order to allow a pro of of

typ e preservation wechanged the semantics of evaluation to x some well known bugs

Kahrs Kahrs and enco ded the static semantics also xing known bugs In addition

we wrote a package to automate the denition of mutually recursive relations in HOL

This package is describ ed by example in Section We set ab out trying to provetyp e

preservation and we succeeded in completing the pro of for most of the language Section

When we tried to provetyp e preservation for the part of the language including ex

pressions weraninto problems with substitution That is we found that we had to prove

a large numb er of lemmas ab out substitution in order to pro ceed with the pro of The

diculties we exp erienced with substitution are describ ed in Sections During the

course of proving substitution lemmas the close examination of the semantics uncovered

some problems describ ed in Section with the semantics of SML that would prevent

a pro of of typ e preservation We did not see any clear way to x these problems and

e decided to having sp ent already a year since b eginning the pro of of typ e preservation w

wrap up the pro ject We had done enough work to demonstrate that given a go o d not

to o complex mathematical semantics for a language one can prove signicant prop erties

of the language and nd mistakes and p otential trouble sp ots in its denition We also

felt that we had enough exp erience with HOL to assess its utility in this situation Our

conclusions ab out SML and HOL are in Chapter

In the pro cess of proving theorems we found that some parts of the language were

causing a great deal of diculty b ecause of their complexity The most prominentof

these were imp erativetyp es equalitytyp es and the sp ecial rules for scoping explicit typ e

variables We eliminated these parts of the language in order to allow the pro ofs to b e

accomplished in a reasonable amount of time A complete list of changes is in App endix

A and a discussion of why they are reasonable is in Section We refer to the changed

version of the language as HOLSML

Chapter

Related Work

In this chapter we briey describ e several pro jects that are similar to this one The rst

two are pro jects at Computational Logic Inc involving the programming language Gypsy

The other two are MLrelated One is an enco ding of the syntax and dynamic semantics of

Core SML in HOL by Donald Syme The other is the enco ding of the syntax and static

and dynamic semantics of MiniML a functional MLlike language in Typ ol

Gypsy is an imp erative language with many constructs including supp ort for concur

rency and data abstraction It is designed to supp ort program verication A Gypsy

program includes along with the instructions to b e executed to compute its result the

sp ecication of what that result should b e One of the ways in which Gypsy supp orts

reasoning ab out programs is that it disallows aliasing no nonlo cal variables are allowed

in pro cedures there is no construct allowing a variable access to another variables value

say through a p ointer assignment and structure sharing is not allowed among callby

reference pro cedure parameters The Gypsy Verication Environment Cohenallows a

user to develop sp ecify and prove correctness of Gypsy programs

Here we discusses two asp ects of Computational Logics Gypsy work The rst is

the work of Donald Go o d Ann Sieb ert and William Young on the Middle Gypsy

Denition a mathematical description of most of the Gypsy language in the logic of the

BoyerMo ore theorem prover The second is the work of William Young on a veried co de

generator for the language MicroGypsy

The language Middle Gypsy diers little from the language obtained by removing con

currency and data abstraction from Gypsy The Middle Gypsy Denition GSY

presents a mathematical sp ecication of this language in the logic of the BoyerMo ore

theorem prover The denition is given via two functions F and P which describ e the

mathematical and computational asp ects of programs P the computer program mech

anism mo dels the computational parts of the program including the change of state

o ccurring as the program executes It is allowed to reect the limitations of a machine

running the program such as a nite amountofmemory F the mathematical expressions

part of the language mo dels the application of mathematical functions The mathematical

expressions are used for checking that the pro cedural interpretation satises the op erating

constraints such as the entry and exit sp ecications

The functions F and P can b e compared to the evaluation relations we dened for

HOLSML Our relations cannot b e enco ded as HOL functions whichmust b e everywhere

dened b ecause SML programs are not guaranteed to terminate and b ecause evaluation

is not dened for all programs that can b e constructed from SML syntax Their language

denition can b e expressed using functions even in the presence of recursive pro cedures

by the inclusion of parameters that state the maximum numb er of recursive calls allowed

during the course of evaluation As with SML there are some programs that b ecause of

problems suchastyp e errors do not evaluate correctly This problem is handled in the

Gypsy denition by dening the result of the evaluation to b e a marked ob ject whichis

a pair m o of a mark m and an ob ject o The mark is used to indicate errors that o ccur

during the evaluation of the phrase If the mark is nil then no errors have o ccurred during

the evaluation of the phrase Both F and P take as arguments a phrase to b e evaluated

an expression or program segment an environment giving v alues for the free variables in

the phrase and an integer stating the maximum of steps to b e taken which ensures that

the functions terminate F returns a marked typ ed value and P returns a marked typ ed

store

Several things should b e noted ab out this denition First a quote from the Preface

says something ab out the complexity and utility of this denition

b ecause the denition is in rigorous mathematical form it is p ossible to

state and proveinvariant prop erties ab out the denition However rigorous

formulation and pro of of these prop erties was not p ossible within the scop e of

this eort However doing these pro ofs would have increased substantially our

b elief that the pages of BoyerMo ore logic do es say the right thing

The fact that the denition indeed lls pages with BoyerMo ore logic will make proving

theorems ab out the denition very hard

Second the expression or pro cedure to b e evaluated is expressed as a sequence of ASCI I

characters whichmay not even b e legitimate Gypsy program phrases If there are syntax

errors or typing errors these are indicated by the mark in the evaluation result Evaluation

is similar to LISP evaluation in the sense that errors are rep orted only if they o ccur in the

section of co de that actually gets evaluated This is not part of the Gypsy denition the

static and dynamic semantics can b e checked separately if so desired While it do es not

seem to b e useful to evaluate ASCI I sequences that are not even generated by the Gypsy

grammar the way the evaluator is expressed enables a pro of of a stronger theorem than

the typ e preservation theorem Typ e preservation can b e phrased roughly as if a phrase

P has typ e and it evaluates to a value v then v has typ e For this system if there were

a separate static semantics one could try to prove a result something like if a program P

typ echecks then either a there do es not exist an n such that P terminates after n steps

or b there exists an n such that P terminates after n steps with a marked store m s

and either m is nil and for eachvariable x if x is declared to havetyp e then the value

yp e or else m is one of a restricted class of asso ciated with x in the resulting store has t

runtime errors such as divide by zero This is analogous to the statement of strong typ e

soundness for SML if the phrase passes the typ echecker that is it elab orates to some

typ e then either the program gets into some sort of innite lo op or else it evaluates to

avalue that has typ e

The MicroGypsy work is part of a CLI eort called the Short Stack which consists of

the highlevel language MicroGypsy the assembly language Piton the FM pro cessor

and a gatelevel design for the pro cessor The connections b etween the levelsthe co de

generator translating MicroGypsy to Piton an assembler that translates Piton to machine

co de for the FM and the design of the FMhave b een formally veried allowing

trusted programs to b e written in MicroGypsy

Youngs work the formally veried MicroGypsy co de generator is the top of the

stack MicroGypsy is a small subset of Gypsy including simple data typ es arrays and

pro cedural abstraction The op erational semantics of MicroGypsy is an interpreter written

as a recursive function called MGMEANING in the BoyerMo ore theorem prover As

the fo cus of this pap er was on the co de generator and its verication the MGMEANING

function is taken for granted and is not describ ed in depth however it is indicated in

GSY that the semantics of MicroGypsy is similar to the mathematical semantics for

Middle Gypsy

The co de generator is implemented by a function in the BoyerMo ore logic called MAP

DOWN which not only translates MicroGypsy statements into Piton but also translates

the background against which these statements are executed called an mgstate into

equivalent structures for Piton a pstate The mgstate includes the binding of variables

to values the combination of SMLs environment and memory and current condition

analogous to SMLs exceptions MAPUP is a mapping from a pstate to an mgstate

that given information on the exp ected typ es of the variables reconstructs the bindings for

an mgstate from the temp orary stack of a pstate The correctness of the co de generator

is phrased in terms of the functions MAPDOWN MAPUP MGMEANING and Piton

interpretation which is not given a name Theideaistoprove that MGMEANING

MAPUP Pitoninterp MAPDOWN that is the mgstate resulting from applying

MAPDOWN running the Piton interpreter on the resulting pstate and then applying

MAPUP is the same as MGMEANING applied to the initial mgstate The actual pro of

eliminates MAPUP by showing that it is a left inverse of MAPDOWN and then showing

that MAPDOWN MGMEANING Pitoninterp MAPDOWN This is done by

induction on the evaluation dened by MGMEANING

Donald Symes enco ding of Core SML uses HOL an older version of HOL than

HOL the version used for our work His enco ding has many similarities to ours as

well as some signicant dierences The enco ding of the reduced syntax is similar to ours

However instead of developing a mutually recursivetyp e denition package of his own he

tic ob jects needed used one develop ed by Claudio Russo of Edinburgh To enco de the seman

for evaluation he also develop ed a nite map theory for HOL however as Russos package

did not allow the nesting of typ e denitions under constructors he used an axiomatization

to express the prop erties that the typ es needed to satisfy As noted in Section axioms

should b e avoided in HOL since it is easy to intro duce inconsistency

The evaluation relations were dened in a somewhat dierentway than ours As

explained in Chapter we dened our relations as the smallest relations satisfying the

evaluation rules Syme rst dened inferencetrees structures in which eachnodeisa

statement ab out the evaluation of an SML phrase An inference tree is valid if the statement

in each no de can b e inferred from its children via one of the evaluation rules Then a

sentence is dened to b e inferable if there exists a valid inference tree with that sentence

as the conclusion Syme notes that he used an enco ding of addresses and the reference

creation rule Rule that eliminates nondeterminism in the choice of the new address

Syme then dened HOL inference rules and tactics based on the evaluation relations

and rules These rules and tactics allow him to prove prop erties of evaluation in a manner

similar to that describ ed in Chapter for our system Using these tactics he proved

determinacy of SML evaluation and the pattern matching theorem

He then implemented a symb olic evaluator that helps signicantly in proving prop erties

of sp ecic prop erties Syme realized that he could not prove correctness of programs with

out some notion of the typ es of the values involved However his approach is primitivehe

attempts to select out subsets of the SML values that satisfy simple structural prop erties

This approach only can provide a crude approximation to typ es a list is dened as any

thing that is constructed with a backb one of conses and a pair is dened as value

that is a record with lab els and As explained in Section this idea will work for

verifying only a few functions Using this technology Syme proved the correctness of the

app end function and an interpreter for a tiny expression language

MiniML is a small applicative language includin g mutually recursive higherorder

functions function denition via pattern matching and p olymorphism In CDDK

Dominique Clement Joelle Desp eyroux Thierry Desp eyroux and Gilles Kahn describ e

the static and dynamic semantics of the language and give a translation to an abstract

machine the Categorical Abstract Machine CAM The pap er rst presents the syntax of

the language and then shows two dierent natural semantics formulations of static seman

tics for the language and proves them equivalent One of these forms of static seman tics is

deterministic allowing typ e inference The dynamic semantics are also shown in a natural

semantics formulation The CAM is describ ed and a translation from MiniML co de to

CAM co de is given This translation has b een proved correct by Thierry Desp eyroux

The static and dynamic semantics of this language the CAM and the translation from

MiniML to CAM co de were all were enco ded into Typ ol which is a system that allows

natural semantics sp ecications to b e rapidly entered into a computer and then allows

these sp ecications to b e executed

Chapter

Programming Language

Sp ecications

This chapter describ es ve programming language sp ecications for Algol LISPScheme

Algol and Standard ML in order to give some examples of dierent sp ecication styles

and the diculties involved in describing the meaning of program constructs in a clear

accurate and understandable way The rst section which examines the sp ecications of

the rst four languages listed may b e skipp ed without much loss as its main goal is to

provide examples of sp ecications that can b e contrasted with that of SML

A Brief History

A programming language sp ecication consists of descriptions of the syntax of the lan

guage and a precise description of the eects or values of the denitions expressions and

commands of the language Occasionally there are constraints other than the syntax that

need to b e satised in order for the program to b e considered prop er One suchsetof

constraints is a typ e system whichischecked byatyp echecker

Usually there are some general concepts that need to b e explained such as the scop e

of variables and the dierent forms of formal parameters to pro cedures Programming

language sp ecications usually servetwo audiences users and implementors The sp eci

cation should include everything a user needs to know in order to program in the language

and everything that an implementor needs to know in order to create a compiler or in

terpreter for the language Often language sp ecications leave op en some details ab out

implementation particularly in areas such as real arithmetic or inputoutput and b oth

users and implementors need to know the guidelines that implementations must follow

It is dicult to sp ecify exactly what a programming language construct do es The

confusion comes from two sources The rst is that the designers mayhave had some

concept in mind that they did not describ e clearly in the semantics This leads to confusion

in the mind of the reader while there was none in the mind of the designer These issues

are not hard to resolve at least in theory one can ask the designers An example of this

problem describ ed b elow is the incorrect sp ecication of Algol s ifthenelse forms for

b oth expressions and statements The second source of confusion is that the designers may

not have had a clear idea of exactly what they wanted the programming language construct

to do or even worse dierent designers had dierent ideas as to what the construct should

do These issues can b e dicult to resolve An example of this is the question of whether

Algol functions can have side eects

In this section one of the issues addressed is determinism Recall that a deterministic

program is one that gives the same answer every time it is evaluated on the same input

A programming language is deterministic if every program written in the language is de

terministic Many mo dern programming languages are not intended to have this prop erty

For example the semantics of a language that supp orts multiple threads of computation

often sp ecies that any thread that is currently ready for execution can b e chosen to run In

contrast one exp ects that a classic singlethreaded language should b e deterministic and

although determinism of a language is not often stated it is implicit in the presentation

of the constructssp ecications refer to the result of a computation However many

informal nonmathematical programming language sp ecications can b e interpreted in

suchaway that the language is nondeterministic We will examine instances of this b elow

The Rep ort on the Algorithmic Language ALGOL Naurisconsideredtohave

founded the eld of programming language sp ecication It was the rst rep ort to use the

BackusNaur Form named after two of the authors of the rep ort of grammar sp ecication

and the meanings of programming language constructs were explained more carefully than

in previous language rep orts The language was not based on an existing implementation

but w as designed byaninternational committee In fact the authors stress that the choice

of constructs and their semantics were chosen without regard to how easily they could b e

implemented

The Algol rep ort is exemplary in its organization giving a clear syntax a semantics

a description of what the construct is intended to do and examples for each construct

The semantics is written informally that is using prose rather than mathematics to ex

press the meaning of the constructs The language is sp ecied well enough that a user

familiar with programming languages could write substantial programs in the language

Yet despite its overall quality there are many mistakes and ambiguities in the rep ort It

is worth lo oking at some of these problems as they are typical of the informal descriptions

of programming languages These problems are discussed in detail byDonaldKnuth in

his pap er The Remaining Trouble Sp ots in ALGOL Knuth

The rst ambiguity that b ecomes apparent to the reader is that errors are not well

describ ed writes Wirth that the real challenge in compiling is not

the detection of correct sentential forms but coping with illformed erroneous programs

in diagnosing the mistakes and in b eing able to pro ceed in a sensible way Thus the

programming language sp ecication must b e sp ecic ab out what constitutes an error and

what ranges of options the implementor has in dealing with the error Questions that must

b e answered are which errors are supp osed to b e detected at compiletime Which errors

must b e rep orted at runtime What errors are allowed to go undetected

The Algol rep ort fails miserably in this In Section on subscripts we nd

The value of the subscripted variable is dened only if the value of the subscript

expression is within the subscript b ounds of the array

In Section on real arithmetic we nd

Numb ers and values of typ e real must b e interpreted in the sense of numerical

analysis ie as entities dened inherently with only a nite accuracy No

exact arithmetic will b e sp ecied however and it is understo o d that dierent

hardware representations mayevaluate arithmetic expressions dierently

What exactly do undened and unsp ecied mean There is a fo otnote in Section

on this but it is not helpful

Whenever the precision of arithmetic is stated as b eing unsp ecied or the out

come of a certain pro cess is said to b e undened this is to b e interpreted in

the sense that a program only fully denes a computational pro cess if the ac

companying information sp ecies the precision assumed the kind of arithmetic

assumed and the course of action to b e taken in all such cases as may o ccur

during the course of the execution of the instruction

It is a mistake to lump together actions that should pro duce an error for example

subscripts out of range with actions whose eects are allowed to vary b etween implemen

tations In fact Knuth p oints out that b ecause of this lumping together of two dierent

concepts and the observation that if a program do es not terminate its result is surely

undened and the wording of the semantics of a go to statement applied to an undened

lab el one can interpret the rep ort as saying that the implementation of the language must

solve the halting problem Another problem is that if a result of a computation is unsp ec

ied it can return a dierentvalue for dierent executions of the program resulting in

nondeterminism

The explanations of what is meantbytheifthenelse construct provide examples

mentioned byKnuth of unclear or misleading explanations in language sp ecications

One of the problems concerns the syntax and semantics of the ifthenelse construct

When this construct is used with expressions the else part is mandatory

hif clause i if hBo olean expressioni then

harithmetic expression i hsimple arithmetic expression ij

hif clause ihsimple arithmetic expression i else harithmetic expression i

Yet in the explanation of the result pro duced by an arithmetic expression formed with a

succession of if clauses we nd

The construction

else hsimple arithmetic expression i

is equivalent to the construction

else if true then hsimple arithmetic expression i

us rendering this expla However the second construction is not allowed by the syntax th

nation useless

Another mistake is asso ciated with ifthenelse constructs for statements It is stated

in Section that there are two forms of the statement with and without the else

and the eects of each when there are multiple if clauses is given One of the sentences in

this section is

If none of the Bo olean expression of the if clauses is true then the eect of the

whole conditional statement will b e equivalent to that of a dummy statement

Knuth p oints out that either this sentence should b e either deleted or it should b e made

clear that it refers only to the form of the conditional in which there is no else part He

then says

This wellknown error would have b een xed in the Revised Rep ort except

for the fact that these prop osals were tied to other ones involving side eects

in the heated discussions which to ok place the less controversial issues were

overlo oked

One of the controversial issues for Algol was that of side eects and the consequent

questions over order of evaluation There are two forms of Algol pro cedures One form is

essentially shorthand for a set of statements and is used only for the changes it eects on

the program state the values of variables The other form a function returns values that

can b e used in expressions If a function in addition to returning a value also changes

the state then it is said to have side eects The rep ort is not clear as to whether side

eects are allowed Because functions can do everything that pro cedures can one might

think that functions can have side eects However parts of the rep ort assume that no side

eects o ccurfor example the quote from Section indicates that if all Bo olean

expressions evaluate to false and there is no else clause then either no side eects have

o ccurred in the evaluation of the Bo olean expressions or if they have then they must b e

undone

Thus the debate arose should side eects b e allowed Arguments were made on b oth

sides On the one hand side eects can b e useful for example in a function that returns

a random real number On the other hand side eects can obscure the execution

of a program a reader of a program usually do es not exp ect that a function will have

side eects If side eects are allowed then there is go o d reason to sp ecify the order of

evaluation In Section on arithmetic expressions the rep ort reads The sequence of

op erations within one expression is generally from left to right but this means that for

example ab c is to b e interpreted at ab c rather than ab c In evaluating ab

it is not sp ecied whether a or b should b e evaluated rst The problem is that if a or b

are expressions containing calls to functions with side eects the result can b e dierent

dep ending on whichisevaluated rst If an order of evaluation is not sp ecied then an

implementation is allowed to cho ose a dierent order of evaluation for dierentrunsof

a program and the language is nondeterministic Thus allowing side eects implies that

the order of evaluation should b e sp ecied However there is a reason to leave order of

evaluation unsp ecied implementors mightwanttoevaluate expressions in a certain way

in order to sp eed up the execution This conict was never resolved for Algol

The original LISP rep ort McCarthywas published in the same year as the rst

Algol rep ort but the metho d of language description is very dierent the LISP pap er

app ears to b e more a pap er in mathematics than in This pap er gives a

formal description for the meaning of programs through the use of an interpreter for the

language written in a language of mathematical concepts

The structure of the pap er is as follows First general mathematical notions suchas

conditional expressions and Churchs notation are discussed Then symb olic expressions

Sexpressions the syntactic mechanism that describ es the form of all LISPs co de and

data structures are dened Then the basic functions on them atom eq car cdr and

cons are describ ed mathematically Then several other functions such as subst and

app end are dened using the mathematical notions and the basic functions Then it is

shown how to represent as Sexpressions the basic mathematical notions and functions on

Sexpressions Then comes the most interesting part the description of howtoevaluate a

program whichisgiven via the denition of a function eval Eval takes two arguments an

expression to b e evaluated and a list of pairs that acts as an environment for the evaluation

Eval is one of several functions along with evcon and evlist that dene the evaluation of

LISP programs

The LISP rep ort while mathematically precise ab out what correct programs ought

to do do es not make clear what an implementation should do with incorrect programs

For example the description of car sp ecies that carx is dened if and only if x is

not atomic car e e e here e e is an ordered pair This sp ecies the

mathematical meaning of car it is a partial function whose domain is the nonatomic

ob jects but it do es not say what happ ens if the ob ject to which it is applied is atomic

which is imp ortant computationally The description of the implementation on the IBM

do es not help car is implemented by a machine instruction that assumes that the

address of the cell containing the pair is in the appropriate machine register This do es

not say whether or not the compiler should do anychecks as to whether the argumentis

nonatomic b efore issuing the car instruction

Some questions ab out the implementation are answered only by a careful lo ok through

the co de for the interpreter For example is the language callbyvalue the expres

sions for the actual parameters are evaluated b efore b eing paired with the formal pa

rameters or callbyname the expressions for the actual parameters are used without

b eing evaluated rst The English description of the interpreter says the evaluation of

LAMBDAx x E e e is accomplished byevaluating E with the list of pairs

n n

x e x e put on front of the previous list a This suggests that the interpreter is

n n

callbyname However examining the co de for the interpreter one nds a dierentstory

It is clear from the co de that eval is mapp ed over the list of arguments b efore they are

paired with the formal parameters and put into the environment a

A confusing asp ect of this rep ort is the lack of an explicit statement as to what the

allowed forms of programs are For example

x eq x y car y T y cdr y

is in the mathematical language presented in the pap er and thus can b e translated into

LISPs Sexpressions Yet ev al will not evaluate this term the cases the eval function

provides for the application of an expression F to a collection of arguments do not include

the p ossibility that F is itself an application

Algol vWwas the ocial successor to Algol The designers hop ed that it

would b e the language of the future it would include everything that a programmer could

need and would have a precise syntax and semantics To this end all debates over Algol

were resolved and many features were added to the language while some of the more prob

lematic features such as callbyname pro cedure parameters were ab olished The precise

semantics was provided by a new form of grammar the vW grammar after its inventor

and the main author of the Algol rep ort A van Wijngaarden This grammar allowed a

precise and complete sp ecication of the syntax of the language and included many asp ects

of the typ e system such as ensuring that a variable is dened consistently with its use

Unfortunately this p ower and precision came at the exp ense of comprehensibili ty This

twolevel contextsensitive grammar was dicult to understand To make matters worse

the authors invented new terminology for many familiar features For example multiple

value and denotation were used instead of array and constant This was done to

avoid preconceived notions of what the comp onents of a programming language should do

but the eect was to make the sp ecication nearly unreadable

The combination of a complicated grammar and new terminology proved to b e the

undoing of Algol its programming language innovations were overwhelmed by a nearly

inscrutable sp ecication However some of these ideas such as co ercions b etween dierent

typ es and the ability to create and manipulate p ointers app eared later in other languages

suchasCKR

Scheme a version of LISPwas rst describ ed in The Revised Rep ort on the

Algorithmic Language Scheme RC shows how far informal sp ecications of program

ming languages had come since the original Algol rep ort It has the same general format

as the Algol rep ort In addition in a section Section towards the end of the pap er

the formal syntax and semantics are given The syntax in Section is given using BNF

notation and the semantics for a large p ortion of the language is given using a form of

denotational semantics It is clear that this programming language sp ecication owes much

to its predecessor in fact the Scheme rep ort is Dedicated to the Memory of ALGOL

The Scheme sp ecication is much more complete than that of Algol but it is also much

longer pages as opp osed to for Algol A go o d p ortion of its additional length

comes from describing p ortions of the language left completely up to implementations by

the Algol rep ort such as inputoutput routines and real arithmetic

The biggest improvementover the Algol rep ort is that the Scheme rep ort is sp ecic

ab out what constitutes an error and errors are distinguished from what is left op en to the

choice of the implementor In addition requirements are established for those parts of the

language that are allowed to vary with the implementation

There are still some questions left op en by the sp ecication Order of evaluation is not

unambiguously describ ed Furthermore it is treated dierently in the informal and formal

parts of the rep ort In a note in Section it is state that In contrast to other dialects

of Lisp the order of evaluation is unsp ecied Since Scheme functions are allowed to have

side eects if a dierent order of ev aluation is chosen in dierent runs of a program then

Scheme is nondeterministic Thus one wonders do es unsp ecied allow a dierentchoice

of evaluation order on dierent runs of a program

In Section we nd

The order of evaluation within a call is unsp ecied We mimic that here by

applying arbitrary p ermutations permute and unpermute whichmust b e in

verses to the arguments in a call b efore and after they are evaluated This

still requires that the order of evaluation b e constant throughout a program

for any given numb er of arguments but it is a closer approximation to the

intended semantics that a lefttorightevaluation would b e

This paragraph not only do es not clarify what the intended semantics of unsp ecied

order of evaluation are but it calls into question the relationship b etween the formal

and informal semantics The wording in the quote ab ove suggests that this is just one

interpretation of the informal description However at the b eginning of Section we nd

This chapter provides formal descriptions of what has already b een describ ed informally

in previous chapters of the rep ort which indicates that this is the ocial explanation of

what is meantby an unsp ecied order of evaluation

The question Is Scheme nondeterministic was recently p osed to a collection of

Scheme exp erts The answer supplied by most including Matthias Blume Jim Miller

and Morry Katz was that Scheme is in fact a nondeterministic language This however

is not a commonly known fact Mitchell Wand was under the impression that dierent

executions of the same pro cedure call must have the same order of evaluation and thus

the language was deterministic

One nal asp ect of the denotational semantics in the Scheme rep ort will b e mentioned

it is hard to read It relies on notations that are only summarized in the rep ort These

notations make the resulting semantics nearly incomprehensible to someone new to this

typ e of semantics It is dicult to understand even for those who have studied denotational

semantics b ecause it is somewhat involved and b ecause the denitions of some of the

meaning functions have b een omitted As an example of the mathematical complication

of this semantics this the clause for an if without an else branch is one of the shortest

in the semantics

E if E E E E singletruish EE send unspecied

The problems with Algol and Scheme semantics mentioned ab ove illustrate some of

the ambiguities inherent in informal programming language sp ecications These ambigu

ities combined with complicated constructs can make it dicult to formulate a mathe

matical semantics for a languages

We examined three mathematical sp ecications ab ove the Algol rep ort the LISP

rep ort and the section on denotational semantics in the Scheme rep ort While these sp ec

ications have the advantage of b eing more precise than their informal counterparts they

This p oll was conducted by the author over email in Septemb er

are also decient in some regards Not only the mathematical but also the computational

asp ects of programs need to b e sp ecied in particular errors and the ways in which they

are dealt with need to b e clearly describ ed The mathematical notation used needs to b e

as clear and as simple as p ossible completely explained within the sp ecication and in

addition there needs to b e some informal discussion of the formal semantics The LISP

semantics fails to provide information regarding the computational prop erties of the lan

guage The denotational semantics in the Scheme rep ort fails to dene and explain the

metho ds used Finally the Algol rep ort fails b ecause of the inherent complexityofits

sp ecication and b ecause of the new terminology employed

SML and its Sp ecication

The sp ecication of SML is given by a small b o ok called The Denition of StandardML

MTH Since its publication in it has b een widely recognized as setting the

standard for the rigorous sp ecication of a real programming language as opp osed to

atoy language suchasFun in CW A companion volume Commentary on Standard

ML MT provides explanations and examples for the material covered mathematically

in the Denition These publications are referred to in the rest of this do cument as the

Denition and the Commentary resp ectively

This section consists of two parts The rst describ es the features that distinguish SML

from other languages The second gives an overview of how SML is sp ecied by explaining

a few of the typ echecking and evaluation rules Some of the ideas is this presentation were

claried by App el This section can b e skipp ed by readers familiar with SML and its

sp ecication

SML The Language SML is divided into two levelsthe Core and Mo dules The Core

is essentially the programming part of the language while the Mo dules system is used

to provide structure and extra generality to large and complex programming tasks by

collecting together related typ es functions and data items In order to make the task of

enco ding and proving prop erties ab out the language more manageable wehave only dealt

ork to enco de and prove with the Core language Gunter and Mahara j have built on this w

prop erties ab out the Mo dules MG As the work describ ed in this thesis concerns the

Core language the following description will concentrate on the Core

Before a program is compiled or is executed byaninterpreter it is checked for typ e

correctness The typ echecker can catch a large p ortion of simple errors for example calling

a function with the wrong numb er of arguments or putting the arguments in the wrong

order In languages without a typ echecker programs with obvious aws can b e compiled

or interpreted and will work neuntil the defective section of co de is encountered The

eects of not catching such mistakes early on dep end on the programming language With

LISPlike languages suchasScheme these problems are detected at runtime as the bad

co de is ab out to b e executed and an error message is printed out With C there is no run

time checking and the compiled co de is executed exactly as programmed which often

results in corrupting the program memory This may result in the program crashing while

executing co de entirely unrelated to the section of co de containing the problem which

makes tracking down the bug extremely dicult

SMLs close interaction b etween typ echecking and evaluation results in runtime safety

Runtime safety means that a program will execute without encountering errors that result

in the program b ehaving unpredictablyScheme and SML are b oth safe C is not and

strange things can happ en when program errors corrupt the stack Runtime safety for

Scheme is accomplished by runtime checking while for SML it is ensured by type sound

nessTyp e soundness means that if a program passes the typ echecker then it will not

havea typ e error when it is executed Typ e soundness is achieved by another prop erty

which means that if the typ echecker veries that a program has a cer typepreservation

tain typ e then when it is executed the result is a value that has the same typ e Thus

compiled co de can assume that data ob jects really are what they are supp osed to b e and

runtime checks can b e disp ensed with Thus in addition to catching errors earlier during

typ echecking SML can p otentially execute faster than Scheme

Typ e preservation ensures typ e soundness by catching during typ echecking errors that

could cause the program to go wrong such as trying to add an integer to a b o olean

However there are some errors that cannot b e caught b efore execution such as division by

zero These errors are dealt with by the exception mechanism This mechanism captures

information p ertaining to the error in a packetwhichispassedback in place of a value as

the result of the computation These packets can b e caught and handled by the user and

if they are not caught the program terminates In addition users can declare and raise

their own exceptions thus allowing more control over the ow of programs As exceptions



The C sp ecication KR do es not require such runtime checking However there are a varietyof

quality C implementation s that have runtime checking and some even ensure complete runtime safety



Of course many C gurus see this as a feature not a bug

are part of SMLs language denition and typ e system they provide a carefully sp ecied

way of dealing with errors that o ccur during execution

Despite its p ower in nding program errors a typ e system might b e considered to o

much of a b other if it gets in the way of programming Consider Pascal in whichevery

variable and function has to b e given a typ e explicitly This results in a signicant amount

of program text b eing dedicated to supplying typ e information There are two ma jor

problems with this The rst is that much of this information is not needed For example

in the line of co de byitmust b e the case the b is a b o olean Thus with some

form of type inferencethe pro cess of inferring the typ es of variables and functions from

their contextsmany of these declarations could b e omitted The second problem is that

sometimes the typ es of functions end up b eing to o sp ecic The co de for inserting an item

in a list is essentially the same no matter what typ e of data the list contains yet with

languages suchasPascal these functions must b e reimplemented every time a new list

typ e is created

SML gets around these diculties by using p olymorphic typ e inference Polymorphism

means that the same ob ject can havemany dierenttyp es There are many dierent

forms of p olymorphism the kind used in SML is parametric polymorphism A function is

parametrically p olymorphic if its arguments can haveany of a usuallyinnite number of

typ es all having the same general structure and the result is computed in a uniform way

yp e of argument See CW for a discussion of the forms of p olymorphism and for eacht

go o d descriptions of each

List pro cessing functions are the typical example of p olymorphic functionsonce the

generic typ e of lists has b een dened functions that do not dep end on the typ e of element

in the list will b e applicable to all lists For example a function that reverses the elements

in a list can b e given the typ e list listforanytyp e

Typ e inference involves using rules of program structure to determine the typ es of

variables and functions For example if a function is applied to the argument and

returns a value that is then concatenated to a string then the typ e of the function must

be int string It is imp ortant to distinguish typ e inference from the typ e system The

typ e system is given by a set of rules that sp ecify the typ e that a phrase can b e given based



Lists are so useful that they along with some basic listpro cessin g functions have b een sp ecied in

the Denition However the typ es and functions that result from these sp ecication s are no dierent from

those that users can program themselves and reimplementing list typ es and functions is often given as an

example in SML b o oks and classes

on the typ es of the subphrases Typ e inference is an algorithm the gures out that typ es of

phrases based on program structure When the term typ echecker was intro duced in this

thesis it was dened as an algorithm that veries that the typ e system rules are satised

by a program A typ e inference algorithm if it is to b e of anyusemust also agree with

the typ e system in the sense that typ es of a phrase and its subphrases determined by the

typ e inference algorithm must b e related according to the rules of the typ e system In this

do cument the term typ echecker is used with SML to mean an algorithm that do es typ e

inference as well as verifying that the typ e rules are satised

In SML the typ e inference algorithm must satisfy an additional constraint it must

return the most general type for a phrase For example the identity function fn x x

which returns whatever argumentwas given it can b e given the typ e for anytyp e

Thus it can b e given the typ es for example int intorbool list bool list

or for a typ e variable Its most general typ e is the last one since any other

p ermissible typ e can b e obtained from it by replacing the with some other typ e

Despite p owerful typ e inference explicit typ es in the syntax are o ccasionally necessary

Sometimes they are needed to resolveoverloaded functions suchas which can b e used

with b oth integers and reals or to sp ecify the complete typ e of a record argumenttoa

function However only a few typ e annotations suce to guide the typ echecker in nding

the typ e for a function

In SML functions are rstclass data ob jects This means that they can b e used in the

same sorts of situations as the basic data typ es such as b o oleans or integers In particular

functions can b e created on the y and passed back as the return values of functions and

can b e used as arguments to functions This allows quite a bit of exibility in programming

For example the ability to create and return functions with lo cal state can b e used for

ob jectoriented programming

While SML includes nonfunctional features suchasreferencesmutable values and

exceptions it emphasizes functional programming by segregating the functional part of

the language from the nonfunctional part Reference cells variables whose values can

be changed via assignment have dierenttyp es than other values a reference cell that

contains an integer has typ e int ref Assignment and dereference op erations work only on

values with ref typ e This is unlikeScheme which while mainly considered a functional

language allows the value of anyvariable to b e changed The segregation of nonfunctional

asp ects of the language by SML simplies reasoning ab out programsif a variable do es

not have reference typ e then its value will not change over the course of evaluation that

is within the scop e of a variable the entityreferredtoby the variable do es not change

SML is usually run under a readevalprint lo op This interactive metho d of compilation

helps facilitate the development and testing of small pieces of co de

The nal feature that distinguishes SML from other languages is the use of pattern

matching for dening functions This is easiest to explain with an example Belowisa

function that adds up the elements in an integer list

fun add bbs b add bs

add

The pattern bbs matches a value that is the constructor SMLs inx equivalentto

Schemes cons applied to twovalues that match b and bs The pattern matches only

the empty list This denition says that the function add applied to a nonemptylistis

the value of the rst item in the list added to the sum of the rest of the list and the sum

of an empty list is

It is informative to see how one could infer the typ e of the function in the paragraph

ab ove The argumentmust b e of typ e list for some since the constructor is a

constructor for the list typ e and is the empty list The function must return an integer

since the returned value for an argument that is the emptylistisThus wehave pinned

down the typ e of the function to list intNowwe only need to determine what

is The variable b must b e of typ e and bs must b e of typ e list b ecause the typ e of

here is list list represents the pair typ e Now b is an argumentto sob

must b e either an integer or a real Weknow that the return value of add is intthus add

bs has typ e int and since the two arguments of must have the same typ e then b must

alsobeaninteger Thus is int and the typ e of the function is int list int The

typ e inference algorithm called algorithm W Milner works by assigning typ e variables

as the typ es of all unknown identiers and then uses rules typied by the reasoning ab o ve

in conjunction with unication in order to determine the typ es of functions and variables

SMLs specication The syntax of Core SML is given in Chapter of MTH using a

mo died BNF style that uses line breaks instead of j to indicate alternatives For example

the syntax of expressions exp is

exp atexp atomic expressions

exp atexp application L

exp id exp inxed application

exp ty typ ed L

exp handle match handle exceptions

raise exp raise exception

fn match function

where an L in the rightmost column means that the construct is left asso ciative This little

section of syntax mentions three of the sixteen phrase classes there is Exp ranged over

by expAtExp atomic expressions ranged over by atexp and Match matches whichare

clauses that use patternmatching to sp ecify a function ranged over by match Itisworth

noting that the syntax sp ecication is a mutually recursive denition of the phrase classes

in the language

Note the absence of the forms that one would exp ect to see such as an ifthenelse

clause This is b ecause the grammar presented here is the bare language a subset of the

full grammar The rest of the constructs are derived forms that can b e expressed in terms

of the bare language

As mentioned ab ove the dynamic semantics evaluation and static semantics typ e

system are dened by sets of rules The Denition gives the following overview of the use

of rules to dene these relations

The job of a languagedener is twofold Firstas wehave already suggested

he must create a world of meanings appropriate for the language and m ust nd

awayofsaying precisely what these meanings are

The second part of the deners job is to dene evaluation precisely This

means that he must dene at least what meaning M results from evaluating

any phrase P of his language

We shall now explain the keystone of our semantic metho d First weneed

aslight but imp ortant renement A phrase P is never evaluated in vacuo to

a meaning M but always against a background this backgroundcall it B is



These derived forms are given in the Denitions App endix A

itself a semantic ob ject b eing a distillation of the meanings preserved from

evaluation of earlier phrases

The keystone of this metho d then is a certain kind of assertion ab out

evaluation it takes the form

B P M

and may b e pronounced Against the background B the phrase P evaluates

to the meaning M The formal purpose of this Denition is no more and no

less than to decree exactly which assertions of this form are true This could

be achieved in manyways Wehavechosen to do it in a structured wayas

others have by giving rules whichallow assertions ab out a compound phrase

P to b e inferred from assertions ab out its constituent phrases P P

n

Later it is claried that the rules for elab oration the typ e system rules as well as

evaluation are expressed using assertions involving a background a phrase and a result

The assertions for elab oration are of the form B P M and can b e pronounced Against

the background B the phrase P has typ e M

While the rules dening typ echecking and evaluation can lo ok obscure this is due to

the complexity of the meaning of the sp ecic language constructs b eing describ ed not due

to the inherent complexity of the metho d of sp ecication see Tofteformuch simpler

rules in the same style In addition while descriptive material is somewhat scarce in the

Denition the Commentary gives explanations of the rules and examples of how they are

used Armed with these two b o oks one can rapidly b ecome acquainted with the general

idea of how the rules sp ecify the language although it takes a long time and careful study

to fully understand the rules and their implications

Chapter of the Denition gives the static semantics typ e rules for the Core This

chapter of the Denition follows the plan set out in the overview Thus it b egins with

the denition of the meanings for the static semantics that is the ob jects called the

semantic objects that are the results and backgrounds for the typing assertions The most

imp ortant denitions are various forms of typ es record typ es function typ es constructed



In the Denition the symbol is used for evaluates to or has the typ e however we use the

symbols  and resp ectively This avoids conict with the use of in prop ositions as logical implication

and the use of dierentsymb ols for dynamic and static semantics help avoid confusion b etween the two



To b e more exact it gives the rules of a subset of the bare language that is obtained by the removal of

all references to inx op erators The directives that establish inx functions and later revoke them and

the syntax forms for inxed application s are used only for parsing

typ es typ e schemes p olymorphic typ estyp es that have some of their typ e variables

universally quantied and variable environments maps from variables to typ e schemes

Variable environments are one of the comp onents of environments which in turn are one of

the comp onents of a context Typ es and environments are the meanings to which programs

elab orate and contexts are the background against which program phrases are elab orated

Section A gives the dierences b etween the static semantics for Core SML and those for

HOLSML

The next step according to the outline is to give rules that precisely dene which

meanings result from elab orating SML phrases Each rule is of the form

C P A C P A SC SC

n n n m

C P A

Here each C is a context and each A is either a typ e or an environment Generally

i i

expressionlike phrases including expressions and expression rows elab orate to typ es

while declarationlike phrases including declarations and value bindings elab orate to en

vironments Eachsentence C P A sp ecies the elab oration of some subphrase of P

i i i

Usually each C is C with some additional assumptions and the nal result A is some

i

combination of the intermediate results A A The SC are side conditions They

n i

are used to put constraints on the semantic ob jects app earing in the rule for example

sp ecifying that a variable is in the domain of the environment The form as shown here is

slightly inaccurate as the side conditions are actually mixed in with the hyp otheses that

are elab orations which are called premises

In order to giveaavor of the elab oration rules the following paragraphs explain two

of the rules The static and dynamic rules are numb ered and it is easiest to refer to them

bynumb er Rule applies to atomic expressions of the form let dec in exp end The rule

is

C dec E C E exp

C let dec in exp end

Here C is a context E is an environment and is a typ e The op eration is the

mo dication of C by E the bindings in E augment or if there are conicts replace the

bindings in the environment comp onentofC and other comp onents in C can b e aected

as well This rule says if the declarations in dec elab orate to an environment E and in

the context created by mo difying C by E exp elab orates to then the entire let phrase

elab orates to

As mentioned b efore SML implementations havetyp echeckers that p erform typ e in

ference This algorithm uses the typing rules in a more activeway than that suggested

ab ove The wayRulewould b e interpreted is more like the following to nd the typ e of

let dec in exp endinthecontext C we rst elab orate the declarations in dec to get an

environment E consisting of bindings for variables constructors etc Then we add these

new bindings to C and elab orate exp yielding a typ e which is the typ e of the entire let

expression

Polymorphic typ es enter the typing system through the use of the Clos op eration in

Rules and Rule generalizes the typ e of variables declared with value bindings

while Rule generalizes the typ e of value constructors like the SML equivalentof

LISPs cons Rule is

C valbind VE VE Clos VE

Cvalbind

C val valbind VE in Env

See page for the denition of Clos

An example of a value declaration is

val third fn lst hd tl tl lst

where hd and tl are SML functions that take the head and tail resp ectively of a list This

function will return the third element of its argument assuming the list has at least three

elements if there are less than three elements then one of the applications of hd or tl will

raise an exception and we exp ect that the declaration will elab orate to the typ e scheme

list Rule shows that the value binding elab orates to this typ e by b eing

instantiated as follows where vb is short for third fn lst hd tl tl lst

C third fn lst hd tl tl lst fthird list g

fthird list g Clos fthird list g

C vb



C val third fn lst hd tl tl lst

fthird list g in Env

C here is the initial context whichcontains in its environment comp onent bindings for

hd and tl These are mapp ed to list and list list resp ectively

Briey third fn lst hd tl tl lst elab orates to fthird list g

The Rule examined here is essentially the HOLSML version which is simplied from the Denition

SML syntax will b e written in typ ewriter font The program variables when shown on their own will

b e written in italics

b ecause of the rule for variables which sp ecies that a variable can haveanytyp e that is

a sp ecialization of its typ e scheme as given by the context thus the typ e of hd in valbind

is list and the rule for application whichsays that if one applies a function of

typ e to an argumentoftyp e then the result has typ e

The op eration Clos generalizes the typ e of third The expression that binds third is fn

lst hd tl tl lst This is nonexpansive see page b ecause it is a function

expression and therefore the typ e asso ciated with it in the variable environment can b e

generalized there are no free typ e variables in the initial context Thus the result of

elab orating the declaration is the environment whose variable environment comp onentis

fthird list g and whose other comp onents are empty

Chapter in the Denition gives the dynamic semantics evaluation rules for the

tax is that Core First the reduced syntax is describ ed The idea b ehind the reduced syn

the typ es are largely dealt with in the static semantics so a great deal of typ erelated

information can b e eliminated from the language b efore executing it The Denition

however eliminates to o much datatyp e declarations need to b e retained in order to provide

information concerning value constructors for the dened typ es see Kahrs In HOL

SML essentially only the typ e tags on terms is removed in going to the reduced syntax

The dierences the dynamic semantics for HOLSML and that for Core SML is given in

Section A

The semantic ob jects for evaluation are values including sp ecial values basic values

closures records packets and addresses environments in this chapter of the Denition

environments are maps from program variables to values and the comp onents of the

state including the memory which is a map from addresses to values Some of the values

deserve some explanation Sp ecial values are ob jects suchasnumb ers and strings atomic

values that can b e represented explicitly in a program Basic values are SMLs built

in functions such as arithmetic and inputoutput op erations A closure is the value to

which a function evaluates The three comp onents of a closure are the match that sp ecies

the arguments and b o dy of the function an environmentthatcontains bindings for the

free variables in the match and another environment used for implementing recursive

denitions A packet is a raised exception

It is interesting to note how the segregation of the nonfunctional asp ects of the language

are reected in the structure and use of the state For most languages with nonfunctional

t to mo del addresses features an environment maps variables to locations which are mean

in the computer memory and a store then maps these lo cations to values as in the deno

tational semantics of Scheme Section of RC Thus to nd the value asso ciated with

a given variable one must access b oth the environment and the store This abstraction

is needed b ecause the values of all variables can b e changed and b ecause there maybe

aliasing Aliasing o ccurs when a value in the store can b e accessed and changed through

more than one variable One way this can come ab out is if the same variable is used

twice as an actual parameter in a function call Lo cations mo del aliasing by placing the

value that can b e multiply accessed in the store and in the environment mapping all the

variables that can access it to the lo cation holding the value Then if an assignmentis

made to one of the variables the value in the store is changed and all variables mapp ed

to that lo cation will rep ort the new value as their value

However as noted ab ove SML segregates out its assignable variables from nonassignable

variables The assignable variables have reference typ e if a variable is a reference cell that

can contain a value of typ e then the typ e of the variable is ref An environment

for SML maps variables to values among which are addresses Assignable variables are

mapp ed to addresses and other variables are mapp ed to other forms of value Let us

consider why nonassignable variables need not b e mapp ed to addresses While a non

assignable variable can b e used twice as an actual parameter in a function call its value

cannot b e changed within the function so there is no need to share a lo cation in memory

If a language do es not allow assignment such as MiniML CDDK or allows assign

ment but forbids aliasing such as Gypsy Cohen GSY then lo cations can b e done

away with entirely and variables can b e mapp ed directly to values

The form of the evaluation rules is similar to that of the typing rules except that now

there is a state to deal with The general form is thus s A phrase A s where s is the

initial state and s is the nal state A is an environment except for patterns where there

is also a valuethe value against which the pattern is b eing matchedto the left of the

and A is either a value a packet an environment for declarations or FAIL indicating

a failed pattern match

There are suciently many cases for the p ossible results of evaluations that some

conventions are used to reduce the clutter in the sp ecication In order to describ e these

conventions the following paragraphs show their eect on Rule This rule was chosen

b ecause each of the conventions have some eect on the rule

The rst convention also used for typ echecking rules concerns angle brackets Some

phrases have optional parts and this is indicated by the use of angle brackets in the syntax

For example one of the forms that value bindings can takeis pat exp hand valbindiIn

the semantics of this phrase one rule is made to suce for phrases with or without this

optional part and the parts of the rule referring to the optional part of the phrase are put

into angle brackets Rule one of the rules for this form of value bindings is

E exp v E v pat VE hE valbind VE i

E pat exp hand valbindi VE hVE i

This rule is shorthand for the following two rules

E exp v E v pat VE

E pat exp VE

E exp v E v pat VE E valbind VE

E pat exp and valbind VE VE

The second convention is the state convention Note that the ab ove equations do not

mention state at all If the rule do es not explicitly alter the state it is left implicit The

state is put backinby replacing eachsentence in the rule of the form A phrase A with

one of the form s A phrase A s and ho oking the states together in a way suggested

by their arrangement in the rule This is b est illustrated with an example After applying

the state convention Equation b ecomes

s E exp v s s Ev pat VEs s E valbind VE s

s E pat exp and valbind VE VE s

The meaning of this now fully expanded rule can b e explained twoways The rst

is a topdown more pro oftheoretic way if we prove the hyp otheses of the rule then

using this rule wehave a pro of of the conclusion of the rule The other is a b ottomup

more active pro ofsearchway in order to nd what pat exp and valbindevaluates to

we rst evaluate the expression to get a value v and new state s Then using this new

state and environment E we match the pattern pat against the value in order to get a state

s and a variable environment map from variables to values VE that contains bindings

for the variables in the pattern Finally in state s and environment E weevaluate the

rest of the value bindings getting a new value environment VE Finally the result of

the entire value binding is the mo dication of VE by VE Note that these two dierent

interpretations corresp ond with those for the static semantics the topdown approachis

liketyp echecking and the b ottomup approachisliketyp e inference

The nal convention is the exception convention which generates yet more rules Ac

cording to this convention for eachhyp othesis of the form s A phrase A s if phrase

could evaluate to a packet a raised exception we add another rule where a this hyp oth

esis has b een transformed to s A phrase p s where p is a packet b this mo died

hyp othesis is the last hyp othesis in the rule and c the result and nal state are the packet

and state resulting from this last hyp othesis Again an example is the b est waytoexplain

this When the exception convention is applied to Equation we get the following two

additional rules according to the Denition the evaluation of patterns cannot result in

packets

s E exp p s

s E pat exp and valbind p s

s E exp v s s Ev pat VEs s E valbind p s

s E pat exp and valbind p s

The meaning of this rst additional rule is that the evaluation of exp resulted in an

exception so instead of trying to continue the evaluation we pass the packet on as the

result of the evaluation The meaning of the second additional rule is that the evaluation

of exp went ne but the evaluation of valbind resulted in an exception and this exception

is the result of the evaluation

The application of these conventions means that there are quite a few more rules than

is initially apparent For HOLSML there are rules written out in Section A After we

expand them according to the conventions and eliminate the duplicates we get rules

Together these rules sp ecify the evaluation of the thirteen phrase classes AtExp Exp

ExpRow AtPat Pat PatRow Match Mrule Dec ValBind DatBind ConBind ExBind

in the reduced syntax Note that these rules are sp ecifying thirteen mutually recursive

relations where each is a relation b etweenanenvironment an initial state p ossibly for

patterns a value a program phrase some kind of evaluation result and a nal state

Because of the numb er of dierent phrase classes and thus evaluation and typing

relations and the numb er of dierentevaluation rules involved any attempt to provea

nontrivial prop erty of the evaluation or typ echecking of SML programs will involve the

analysis of a great numb er of cases This suggests that SML is a language for whichan

enco ding in a theorem prover would provetobeworth the eort involved

Now that wehave seen examples of b oth evaluation and typ echecking rules it is sen

sible to draw some comparisons b etween them Although there are more evaluation rules

and the evaluation relations have more comp onents than the elab oration relations the

evaluation rules are generally more straightforward The main reason for this is that the

side conditions in the evaluation rules are simple functions such as lo oking up a variable

in an environmentorchecking that a value has a certain form The side conditions for

elab oration rules can however b e quite complicated such as the one involving the Clos

op eration in Rule describ ed ab ove

Chapter

Automated Theorem Provers and

HOL

There are quite a variety of theorem provers b eing used to dayThework describ ed here

was accomplished using HOL Belowseveral theorem provers Co q HFWHD HOL

GM and Nqthm BM are describ ed in brief in order to giveanoverview of the use

of theorem provers and to provide the means to assess HOLs suitability for the task

Each theorem prover implements a logic and provides metho ds for dening new data

typ es constants and axioms whichallow users to enco de their problems in the logic Co q

was develop ed byGerard Huet of INRIA Ro cquencourt Its logic is the Calculus of In

ductive Constructions which is similar to MartinLof s intuitionistic typ e theory ML

HOL as its name suggests implements higher order logic It was develop ed byMikeGor

don of the UniversityofCambridge Nqthm develop ed by Rob ert Boyer and J Strother

Mo ore at Computational Logic Inc is based on an untyp ed quantier free rstorder

theory of inductively dened data structures

All of these theorem provers require a great deal of human interaction in order to prove

theorems This interaction is accomplished in dierentways Some theorem provers for

example Co q and HOL are mainly used in a goaldirected fashion the user sets a goal

a statement to b e pro ved and uses tactics to break the goal down into smaller pieces

and to solve goals Goaldirected theorem proving will b e describ ed in detail in the next

section Co q has a nice windoworiented interface to help in goaldirected theorem proving

A similar interface is b eing develop ed for HOL Some goaldirected theorem provers for

example HOL allow the user to write new tactics while others Co q do not

Nqthm is highly automated the user presents a goal and it tries to prove the goal It

has a great deal of deductivemachinery at its disp osal including induction and rewriting

However Nqthm cannot prove complicated theorems on its own it must b e given hints in

the form of proved lemmas Thus in practice Nqthm do es not app ear to b e more p owerful

than goaldirected theorem provers For users who prefer goaldirected theorem proving

there is a goaldirected interface available for Nqthm

HOL was used in this worktoprove prop erties of SML It is wellsuited to this task

for several reasons The rst is that it is typ ed That is each HOL term has a typ e

and terms can only b e combined into larger terms if their typ es match up according to

certain rules This helps simplify the statement of theorems since it eliminates the need

to include hyp otheses that provide typ e information In addition HOL provides exible

constant and typ e denition packages that can b e extended to enable denition of even

more complicated constants and typ es The extensibility of these packages was needed in

order b e able to dene the syntax and semantics of SML

The higher order features of HOL enable us to dene relations such as the evaluation

relations and typing relations as the smallest relations satisfying a set of rules Weac

complish this by sp ecifying that a collection of terms representing an SML phrase and

some semantic ob jects is in the intersection of all relations satisfying the rules How this

works is explained in Section

Proving prop erties of SML evaluation or typing involves proving one case for each rule

that denes the relation The ability to write new tactics for HOL enables one to dene

tactics that can automatically satisfy many of the simpler goals leaving only the ones

requiring more involved treatment

The next section gives a brief description of HOL This can b e skipp ed by the reader

familiar with HOL

The typing rules for HOL are much simpler than those for SML b ecause HOL terms can have one of

only four forms constants variables applicatio ns and lamb daabstractions There are no typ e schemes

in HOL typ e variable are left free in terms A typ e variable in a theorem can b e instantiated to anytyp e

TYPE shown in Table to create a theorem ab out that typ e HOL has a typ e via the basic rule INST

inference mechanism so it is not necessary to explicitly givethetyp es of all variables used in HOL terms

However if the inferred typ e contains typ e variables HOL insists that the user provide names for them



In contrast statements of theorems proved in Nqthm are p epp ered with LISPlike predicates that

constrain the forms of variables

A Brief Description of HOL

The version of HOL used for this work HOL is implemented on top of SML the

implementation is SMLNJ Standard ML of New Jersey AM and SML is its meta

language Therefore every HOL term is an SML ob ject of typ e term It is easy to b ecome

confused ab out whether ob jects and typ es b eing manipulated b elong to the SML in which

HOL is implemented SMLNJ HOL itself or the SML that wehave enco ded into HOL

whichwe call HOLSML We will try to b e as unambiguous as p ossible in the following to

avoid these kinds of confusions

HOL provides a parser that allows users to enter HOL terms using ASCI I characters

that resemble the logical symb ols they are intended to represent However in order to

avoid inicting this notation on the reader all HOL terms presented here will b e written

using standard mathematical connectives rather than their HOL ASCI I equivalents

HOL prop ositions are HOL terms with HOL typ e bool There is no HOL ob ject for

a proof There are theorems represented by SML typ e thm but all an ob ject of typ e thm

says is what has b een proved not howitwas accomplished Pro ofs can b e done either

forwards backwards or a combination of the two Forward pro of starts from axioms

and inference rules without hyp otheses the two are distinguished b ecause HOL has a

sp ecic technical meaning for axiom and builds up the desired conclusion through the

application of inference rules Table shows HOLs basic inference rules out of whichall

other rules are constructed The name of the rule sho wn to the right is also the name of

the SML function that implements it See Section of GM for a detailed explanation

CONV and INST TYPEis of these rules The notion of substitution used in the rules BETA

imp ortant for the work accomplished here and is explained in detail in Section

Backwards pro of the goaldirected theorem proving mentioned ab ove involves setting

a goal which is essentially a statement of the desired theorem The hyp otheses of the

desired theorem form the assumptions of the goal and the conclusion of the desired theorem

forms the conclusion of the goal Tactics are used to break down the goal into smaller

goals subgoals that are more comprehensible and easier to solve and these subgoals can

b e further broken down and simplied until the user sees a waytosolve them Technically

a tactic is function that given a goal will return the subgoals and a validation function

Avalidation function tells how to reassemble theorems satisfying the subgoals to form a

theorem satisfying the goal A theorem satises a goal when the conclusion of the theorem

ASSUME

t t

REFL

t t

CONV BETA

xt t t t x

t t t t tt t

n n n

n

S S S

SUBST

tt t

n

n

t t

ABS

xt xt

t

TYPE INST

t

n n

t

DISCH

ft g t t

t t t

S

MP

t

Table HOL Basic Inference Rules

is the same as the conclusion of the goal and the hyp otheses of the theorem are included

in the assumptions of the goal Some tactics solve goals by returning an emptylistof

subgoals and a validation function that when applied to the empty list returns a theorem

satisfying the goal

Tactics can b e applied until the resulting subgoals are satised by axioms or inference

rules without hyp otheses but a more usual approach is a combination of forward and

backwards pro of Using this metho d one uses a series of tactics to break the goal up into

more manageable subgoals and then uses forward inference to build theorems that satisfy

these subgoals

One of the most useful asp ects of goaldirected theorem proving is that HOL manages

goal A the goals using its goalstack The initial goal is set using the function set

goal is displayed by the goalstack with the conclusion of the goal printed ab ovearowof

underscores and the assumptions of the goal printed b elow the underscores The expand

function applies its argument to the top goal and the subgoals are printed out and put on

the stack

The statementabove that there is no HOL ob ject for a pro of is correct but there

are proof scripts While proving a theorem either in a forwards or backwards fashion

users generally enter into a le the tactics or rules used to prove a theorem in the form

of SMLNJ co de that can b e rerun to prove the theorem This co de has many uses

First it can b e used to reprove the theorem in case the machine crashes b efore the theory

can b e saved see b elow Second it can b e used as a template to prove theorems with

a similar structure for example another theorem that must b e proved by induction over

lists Finally if the denitions of ob jects in the statement of the theorem change the co de

used to prove the theorem the rst time dramatically sp eeds up the pro cess of proving the

theorem ab out the mo died ob jects

One problem with pro of scripts is that they are close to unreadable if they are longer

than ab out ten lines This is b ecause for backwards pro of even if a user knows all the

tactics used in the script after a few lines of co de each of which transforms the goal in

some way she has lost track of the form of the goal b eing op erated on by the tactic This

is not an insurmountable problem however setting the goal and reentering the tactics a

few at a time allows the user to see the how the goals evolve and to again understand the

pro of

HOL is structured into the oriesEach theory consists of some typ e and term constants

T x x x x

bool bool

P PxT

bool

P PP

bool

F b b

bool

b b F

b b b b b b b

b b b b b b b b

One One f x x fx fx x x



Onto f yx y fx



Typ e Denition P rep

bool



One One rep xP x y x rep y

Table Denition of Basic Logical Constants

axioms denitions and proved theorems The same rules of inference are used for each

theory Some of the inference rules do not havehyp otheses but HOL distinguishes these

from axioms which are sp ecic to each theory

Axioms are strongly discouraged b ecause it is to o easy to intro duce inconsistency into

the logic Instead there are denitional principles for constants and typ es that ensure

that the resulting theory remains consistent Many of HOLs logical constants have b een

given via denitions see Table The basic HOL system including all the theories

loaded when a user starts up the system uses exactly ve axioms these are shown in

Table These axioms state facts ab out the settheoretic mo del that underlies HOL

so they do not intro duce inconsistency The axioms could have b een given as inference

rules without hyp otheses as REFL is but since they are most easily stated in terms of

the constants dened in Table they are presented as axioms in the same theory in

which these constants are dened There are manylayers of theories built up on top of

this theory and each includes denitions of typ es andor constants and theorems ab out

these new ob jects The theory that is loaded when the user starts up the system is already

quite sophisticated including list and tree typ es and a substantial numb er of denitions

and theorems ab out arithmetic on natural numb ers

The basic denitional principles are primitive They can b e extended through program

ming but these extensions must after rearranging terms and proving various theorems



The mathematical notion of theory includes al l theorems that are provable from the axioms and deni

tions Since these theorems are usually innite in numb er and b ecause HOL has no way of automatically

proving these theorems HOLs notion of theory includes only the theorems that have actually b een proved

BOOL CASES AX b b T b F

IMP ANTISYM AX b b b b b b b b

ETA AX f xf x f



SELECT AX P x P x P P

bool

AX f One One f Onto f INFINITY

indind

Table Basic Axioms

eventually invoke the basic principles to accomplish the denition

The typ e denition functions new type definition and define type are examples of a

basic denitional principle and an extension of it Both are SML functions that dene new

HOL typ es and return theorems ab out them The basic principle new type definition

allows a typ e to b e created from a nonempty subset of another typ e the representation

typ e The subset is sp ecied as a predicate over the representation typ e the elementis

in the subset if and only if predicate holds of the element In order to guarantee that the

subset is nonempty the user provides a theorem stating that there exists an elementofthe

representation typ e satisfying the predicate The result of invoking new type definition

is that the new typ e is dened and a theorem is proved and returned This theorem states

that there exists a bijective function called the representation function b etween the new

typ e and the subset of the representation typ e that satises the predicate

The extension define type allows simple typ es limited forms of recursivetyp es not

mutually recursivetyp es to b e sp ecied in a manner that lo oks somewhat like the SML

typ e denition An example is the easiest way to describ e it Below is the SML denition

of a datatyp e bar

datatype a bar BAR of a

BAR of bool BAR of a bar a bar

This is the denition via the SML function define type of the HOL typ e that corre

sp onds to it

definetype name barAxiom

fixities Prefix Prefix Prefix

typespec bar BAR of a

BAR of bool BAR of barbar

It is worth clarifying the dierence b etween the twotyp e denitions ab ove The rst is an

SML declaration that declares a new SML typ e barThisnewSMLtyp e can now b e used

in SML as in

let val b BAR false in BAR b b end

The second is the application of an SML function in order to create a new HOL typ e bar

This new HOL typ e can only b e used in HOL as for example in the HOL term

b bar x b BAR x

type reduces to new type definition is quite complicated The way in which define

It is explained fully in Melham

Chapter

Enco ding HOLSML in HOL

Enco ding HOLSML into HOL required dening several classes of mutually recursivetyp es

and mutually recursive relations To dene the typing system we rst needed to enco de

the syntax and the semantic ob jects the latter of which are the typ e environments and the

meanings to which phrases elab orate Both the syntax and semantic ob jects are represented

by a set of mutually recursive HOL typ es Then typing relations one for each phrase class

in the syntax are dened These relations link the syntax and semantic ob jects sp ecifying

the results of elab oration

A similar pro cess is needed for enco ding evaluation Since evaluation is dened over a

reduced syntax describ ed on page we dened a separate syntax for evaluation and a

function that translates the full syntax to the reduced syntax The semantic ob jects were

also dened and then the evaluation relations one for each phrase class in the reduced

syntax were dened The dierences b etween the evaluation semantic ob jects for HOL

SML and those of Core SML are given in Section A along with the entire set of evaluation

rules for HOLSML

This chapter describ es the enco ding of the static semantics The enco ding of the

dynamic semantics is similar

Enco ding the Syntax

Section A shows the complete syntax of HOLSML Section of the Denition lists

some syntactic restriction for the language We need these same restrictions for HOL

SML but as in the Denition we do not take account of these restrictions in the grammar

itself Instead they are incorp orated into a collection of predicates proper phrase for

each phrase in the grammar that ensure that the phrases satisfy the restrictions These

predicates will b e describ ed in more detail in Chapter

We encountered some technical diculties in enco ding the syntax the typ e denition

facilities of HOL describ ed briey in Section of this thesis and in detail in Chapter of

GM allow the denition of recursivetyp es but not mutual ly recursivetyp es while the

syntax of HOLSML is a denition of sixteen mutually recursive phrase classes One could

makemutually recursivetyp es by brute force but the brute force metho d did not work for

a denition as large as the syntax of SML Thus b efore we could pro ceed with the enco ding

we Elsa Gunter and the author dened a package for the denition of mutually recursive

data typ es A feature added later by Elsa Gunter and Healf Goguen was the ability

to allow the recursivetyp es b eing dened to b e nested within other typ e constructors

In addition to dening the typ es the package proves useful theorems ab out the resulting

typ es for example an induction theorem and theorems that assert the distinctness and

onetooneness of the constructors for the typ es and includes a mechanism for dening

primitive recursive functions over the typ es This package is now b eing distributed with

HOL

Note the presence in the grammar Section A of certain ho oks into the Mo dules

system such as long identiers whichmay b e quantied by a series of structure identiers

and open declarations Although the work describ ed here involves only the Core of SML

the ho oks into the Mo dules have b een preserv ed in HOLSML This enabled the enco ding

of the syntax and evaluation of the Mo dules to b e dened later MG

Another asp ect of the syntax worth noting is that the phrase classes can b e divided up

into several groups The syntactic typ e phrases Ty and TyRow are dened only in terms

of each other The pattern phrases AtPat Pat and PatRow are dened only in terms

of each other and the typ e phrases The expression phrases Exp AtExp and ExpRow

however dep end on themselves and all other phrases Because of this structure we dene

these groups of phrase classes separately rst the typ e phrases then the pattern phrases

and so on Ateach step the phrases in the group b eing dened dep end only on each other

and the phrases in the groups previously dened These separate denitions allow for mo d

ularity for example if a function needs to b e dened over typ e phrases we need not worry

ab out other phrases and the separate denitions run faster than would one denition

that denes all the phrases at once The increase in sp eed of denition is due to the fact

that the intermediate theorems that allow the denition to b e reduced to define type

and thence to new type definition are much smaller for smaller denitions

The grammar shown in Section A is the concrete syntax that is what would b e typ ed

into an implementation We enco ded a syntax that more resembles the abstract syntax that

is the output of a parser In the abstract syntax constructors are wrapp ed around ob jects

to create ob jects of another typ e As an example the abstract syntax for expressions is

exp ATEXPexp atexp

APPexp exp atexp

TYPEDexp exp ty

HANDLEexp exp match

RAISEexp exp

FNexp match

Here ATEXPexp APPexp etc are the constructors Note that each HOLSML phrase class

is an HOL typ e and the constructors are HOL functions For example the HOL typ e of

APPexp is exp atexp exp

The enco ding of the syntax for evaluation the reduced syntax is similar to that for

the elab oration grammar To distinguish elements of the reduced syntax e is tagged

onto the end of the phrase and constructor names For example the abstract syntax for

the reduced syntax for expressions is

exp e ATEXPexp e atexp e

e exp atexp e APPexp

HANDLEexp e exp ematch e

RAISEexp e exp e

e match e FNexp

Enco ding the SemanticObjects

HOLSMLs static semantic ob jects include basic ob jects suchastyp e variables and typ e

constructor names stamps that distinguish the typ es resulting from datatyp e declara

tions and comp ound ob jects suchastyp es typ e schemes and environments The seman

tic ob jects form a mutual recursion As with the grammar the enco ding of the semantic

ob jects uses HOL typ e constructors to construct elements of one class of semantic ob jects

from elements of other classes and the semantic ob jects can b e divided up into groups

allowing them to b e dened a group at a time with the later groups dep ending on the

former groups

The structure of this recursion is more complex than that of the grammar and presents

a few additional diculties Several of the semantic ob jects are describ ed as nite functions

between others whicharemutually recursive with them For example in the Denitions

Figure a record typ e in HOLSML is describ ed as a nite map from lab els to HOL

SML typ es while a typ e is describ ed as a disjoint sum of record typ es with other typ es

fin

RecTyp e Lab Typ e

Typ e RecTyp e

In order to enco de this we created a theory of nite maps nmap The internal repre

sentation of the nite maps are lists of pairs where the rst item in the pair is a member

of the domain of the nite map and the second item is the value of the map at that item

In order to simplify the denition of certain nmap manipulation functions such as the

mo dication of one map by another wekeep the domain items sorted Wehave a pred

finmap that checks that the domain is sorted according to some function icate proper

that op erates as a lessthan op erator and that this comparison function is in fact a total

order We could have created through the use of new type definition a new typ e of

maps whose domains are sorted say sortmap but due to the limitations of our mutually

recursivetyp e denition package sortmap could not b e used to dene the semantic ob jects

Thus we end up including in some of the statements of the theorems we proved hyp otheses

ab out the prop erness of nite maps

Another problem with dening the semantic ob jects arises from the fact that several of

them are left undersp ecied in the denition Both TyVar typ e variables and TyName

typ e constructor names are only sp ecied to b e sets with elements of TyName p ossess

ing an arity that indicates how many parameters the typ e constructor takes One could

parameterize by these typ es but wechose to use a concrete instance instead Werepre

sentTyVars by an HOL constructor wrapp ed around a string and TyNames byanHOL

constructor wrapp ed around two natural numb ers the rst representing the stamp that

distinguishes this HOLSML typ e from others and the second representing the arity

For example the typ e constructor name asso ciated with the typ e constructor list has arity one which

determines the typ e of the elements of the list

Enco ding the Typing Relations

After enco ding the syntax and static semantic ob jects of HOLSML into HOL the next

step was to dene the typing relations We created a package that given HOL terms

representing the rules automatically denes as HOL constants the mutually recursive

relations and proves two useful theorems The rst theorem states that the relations

satisfy the rules The second is an induction theorem allowing one to prove prop erties of

the ob jects in the relations byproving one case for each rule

Since this is the core of the enco ding of HOLSML into HOL and b ecause it is the

main use of the higher order features of HOL in this work we will explain how the package

go es ab out making the denitions using the typing relations as the example

For each phrase class phrase in the grammar the relation asso ciated with it will b e

called tych phrase the name is meanttobesuggestiveoftyp echecking Thus for ex

exp C exp type will enco de the relation C exp type Each relation is ample tych

an HOL function taking a collection of terms to bool The arguments of the functions

are the language phrase b eing elab orated and various semantic ob jects including p ossible

results typ es and environments and backgrounds contexts and for the elab oration of

constructor bindings a typ e The relation holds if against the background the phrase

elab orates to the result

The typing rules of HOLSML shown in Section A sp ecify the conditions under

which one can conclude that the typing relation holds of a phrase and some semantic

ob jects if the hyp otheses the terms ab ove the horizontal line are true then the conclusion

the term b elow the line is true However we do not want the elab oration relations to

b e just any set of relations that ob eys the rules Consider the relations that always return

true Then the rules are certainly satised since the conclusion which is an application of

one of the relations is true no matter what happ ens to the hyp otheses The problem with

this collection of relations is that we need to b e able to invert the rules if the conclusion

of the rule holds then we need to b e able to conclude that the hyp otheses of the rule also

hold What we need is that the relations are true only if they are can b e proved bya

chain of reasoning using the rules In other words we need the smallest in the sense of



This package is similar to one written byTom Melham CM but ours allows the denition of

mutually recursive inductive relations



Actuallythisinversion works only if the conclusions of the rules are distinct If this is not the case

then we can conclude only that the hyp otheses of one of the relevant rules hold

having as few tuples in the relations as p ossible relations that satisfy these rules

The challenge then is to express this idea that the elab oration relations are the small

est relations satisfying the rules in HOL The general outline is this rst we enco de the

rules as a predicate call it the typ erule predicate on relations if this predicate is true of

a collection of relations then the relations satisfy the typing rules We then dene the elab

oration relations as the smallest relations satisfying the typ erule predicate Sp ecically

using higher order logic the elab oration relations are dened as b eing the intersection of all

relations satisfying the typ erule predicate Then after dening the elab oration relations

weprove that the resulting relations actually do satisfy the elab oration rules The induc

tion theorem whichwe also prove is equivalent to stating that the elab oration relations

are the smallest such relations

The typerule predicate Examining the rules for elab oration in Section A carefully one

notes that there are several separate groups of relations given there corresp onding to the

groups of phrase classes Therefore the elab oration relations can b e dened in phases in

the same way that the phrase classes are dened in phases The reasons for doing this are

the same as those for breaking up the denitions of the phrases mo dularity if we wish

to prove a prop erty of the typing of a pattern we will not have to consider a collection of

irrelevant cases and sp eed of execution

Therefore to dene the elab oration relations we dene several separate typ erule pred

icates each of whichtakes as arguments p otential elab oration relations and returns true

if the relations satisfy the elab oration rules for those phrases To b e clearer ab out the

enco ding of the rules into predicates let us examine the most complicated predicate

tych exp pred which is the predicate for elab oration relations for phrases AtExp Ex

exp pred is dened so pRow Exp Match Mrule Dec and ValBind The predicate tych

that it is true of a set of relations if they satisfy the rules its general form can b e read

exp pred holds of this collection of relations if the relations satisfy the rst rule and tych

the relations satisfy the second rule and Thus each rule shows up in one conjunct

a conjunct is one of a collection of things that are anded together in the denition of

tych exp pred

In order to give the avor of what tych exp pred lo oks like we showhow one of the

rules Rule is reected in its conjuncts Rule refers to the typing of expression rows

tych atexp context atexp type bool

tych exprow context exprow rectype bool

tych exp context exp type bool

tych match context match type bool

mrule context mrule type bool tych

tych dec context dec env tyname set bool

valbind context valbind varenv statusmap bool tych

tych exp pred tych atexp tych exprow tych exp tych match tych mrule

dec tych valbind tych

C lab exp type

tych exp C exp type

exprow C EXPROW lab exp NONE tych

insert into rectype empty rectype lab type

C lab exp exprow typerec

exp C exp type tych exprow C exprow rec tych

tych exprow C EXPROW lab exp SOME exprow

rectype insert into rectype empty rectype lab type rec add

Table Part of tych exp pred

whichevaluate to records It is written in Section A as

C exp hC exprow i

C lab exp h exprow i flab ghi

When the optional parts of the rule have b een expanded out the result is the following

two rules

C exp

C lab exp flab g

C exp C exprow

C lab exp exprow flab g

Table shows the general form of the denition of tych exp pred and the two con

exprow and tych exp in this table are variables juncts corresp onding to Rule The tych

that have the same typ e and are named the same as the elab oration relations that will b e

dened as constants later tych exp pred can b e applied to any relations of the appropri

ate typ e and it will b e true of these relations only if they satisfy the rules enco ded in its

conjuncts For the rest of this pap er we will use typ ewriter font for constants and typ es

and italics for variables

Notation in rule Enco ding

lab exp EXPROW lab exp NONE

lab exp exprow EXPROW lab exp SOME exprow

C exprow tych exprow C exprow rec

flab g insert into rectype empty rectype lab type

r r add rectype r r

Table Enco ding into HOL

Each rule is enco ded as a conjunct in the following manner The rule is enco ded as

an implication where the antecedent the term b efore the is the conjunction of terms

representing the hyp otheses of the rule and the consequent the term after the is the

conclusion All the variables other than those for the elab oration relations in the rule are

universally quantied The Greek variables are replaced with English ones so b ecomes

type and b ecomes rec The mathematical notation is enco ded into HOL functions and

constructors the concrete syntax is replaced with abstract syntax variables representing

elab oration relations take the place of the mathematical notation and notation in the

results of the elab orations are replaced with HOL functions whichwe had to dened

Examples of each of these enco dings is given in Table

Dening the elaboration relations Note that tych exp pred only sp ecies when the p o

exp pred may tential elab oration relations must return true so functions satisfying tych

return true even when the rules do not justify it Thus wemust dene the elab oration

relations to b e the smallest relations satisfying tych exp pred that is the intersection of

exp predWe sp ecify that a tuple is in the relation if and all relations satisfying tych

only if it is in every p ossible elab oration relation satisfying tych exp predFor example

the term used to dene tych exp is

C exp type

tych exp C exp type

poss tych atexp poss tych exprow poss tych exp

tych match poss tych mrule poss tych dec poss

poss tych valbind

tych exp pred poss tych atexp poss tych exprow

tych exp poss tych match poss tych mrule poss

poss tych decposs tych valbind

poss tych exp C exp type

After dening the elab oration relations it remains to b e shown that the resulting

relations do indeed satisfy tych exp pred That is the elab oration relations satisfy the

rules Wehave written a tactic that do es this automatically This tactic works byrst

expanding out all the denitions then by acting like a miniature Prolog interpreter That

is it checks if the conclusion of the goal is among its hyp otheses If so then it is done and if

not it do es backchaining it nds among the assumptions an implication whose conclusion

matches the desired goal and replaces the goal with the antecedent of this implication and

then breaks up the conjunction in the new goal Only a few iterations need to b e done

b ecause of the common structure of our rules

Finallywe proved induction theorems for the elab oration relations These theorems

allow one to prove facts ab out the arguments of elab oration relations There is an induction

theorem for each phrase class The induction theorem for expressions is b elow and the

one for patterns is shown in Equation

atexp prop exprow prop exp prop match prop

mrule prop dec prop valbind prop

exp pred atexp prop exprow prop exp prop tych

match prop mrule prop dec prop valbind prop

C exp type tych exp C exp type

prop C exp type exp

Here each phrase prop is a prop erty for the phrase class phrase It has the same typ e

phrase and is thus is a prop erty of the arguments of tych phrase This theorem as tych

says that in order to show some prop erty exp prop holds of an expression and semantic

ob jects satisfying tych exp one must show that this prop erty along with corresp onding

exp pred applied prop erties for other phrase classes satises the rules the predicate tych

to the prop erties states that the prop erties satisfy the rules One maywonder whydo

the other prop erties enterinifweonlywanttoprove something ab out expressions The

answer is that the elab oration of expressions dep ends on the elab oration of other phrase

classes so if a prop erty is to hold of the elab oration of expressions then in general it must

b e the case that a similar prop erty holds for the elab oration of the other phrase classes

The induction theorem is almost a rewording of the denitions of the elab oration rela

prop atexp prop etc satisfy the tions as the smallest relations satisfying the rules If exp

rules and the arguments C exp and type are in the relation tych exp then since tych exp

prop as well is the smallest relation satisfying the rules then C exp and type are in exp

Because this statement is so close to the denition of the elab oration relations it is easy

to prove

As noted ab ove the induction theorems are proved automatically by the package we

created for dening mutually recursive relations The form shown for Equation is

unacceptable since the predicate tych exp pred is dened by the package not the user

exp pred is replaced by its denition that is the enco dings of Thus the constant tych

the rules for the phrases b efore b eing returned to the user The returned theorem has

this form

atexp prop exprow prop exp prop match prop

mrule prop dec prop valbind prop

hhatexp prop exprow prop exp prop match prop mrule prop

dec prop and valbind prop satisfy the rulesii

C exp type tych exp Cexptype

exp prop C exp type

prop exprow prop exp prop match prop mrule prop dec prop and val where hhatexp

bind prop satisfy the rulesii stands for a big conjunction of terms one for each rule with

each conjunct stating that the prop erties satisfy that rule For example the conjunct

corresp onding to the rule in Equation is

C lab exp type

exp prop C exp type

prop C EXPROW lab exp NONE exprow

insert into rectype empty rectype lab type

Note that this is the same as the rst conjunct in Table except that exp prop and

exprow prop take the place of tych exp and tych exprow

The form of the induction theorem for patterns is

atpat prop patrow prop pat prop

prop patrow prop and pat prop satisfy the rulesii hhatpat

pat Cpat VE SM type Cpat VE SM type tych

pat prop C pat VE SM type

Note that this induction theorem involves prop erties only of the other pattern phrases This

is b ecause the denition of pattern elab oration is mutually recursive only with elab orations

of pattern rows and atomic patterns Thus if wewant to prove a prop erty of patterns alone

wedonothave to deal with prop erties of other phrase classes

Although the form of these theorems may lo ok somewhat obscure it will b e shown in

Chapters and that many useful theorems can b e phrased in a form allowing pro of via

these induction theorems

Chapter

Proving Prop erties of Evaluation

In this chapter we demonstrate howtoprove prop erties ab out HOLSML by describing

several theorems we proved ab out evaluation One proves prop erties ab out evaluation

using the induction theorems for evaluation which are similar to those for elab oration

The rst dicultyinproving a prop erty is putting it into a form by which it can b e proved

via the induction theorems We start o with a theorem that is easy to prove the pattern

matching theorem Theorem from the Commentary MT This is

Theorem Pattern Matching is WellBehaved Let E V and pat be any envi

ronment value and pattern Suppose that

s E v pat rs

can beinferred for states s s and result r Then r is either a variable environment VE

or else the special result FAILit cannot beanexception packet p Moreover s s

This theorem is a bit misleading as the fact that the evaluation of patterns cannot result in

packets is sp ecied by the Denition The general form of the HOLSML relation in volving

pattern phrases see page is

s E v pat VEFAIL s

This states clearly that the only allowable results are a variable environment and FAIL so

there is nothing to prove

The pattern evaluation relation in HOLSML takes the same arguments as that for SML but the

Denition do es not mention the state in the general form shown in the heading for the pattern rules We

nd this omission confusing thus we include the state in the general form here

The assertion that s s remains to b e proved When translated according to our

enco ding the theorem wewanttoproveis

pat sEvpat r s s s sEvpat r s eval

The induction theorem for evaluation of patterns is

prop patrow prop pat prop atpat

hhatpat prop patrow prop pat prop satisfy the rulesii

pat sEvpat r s sE v pat r s eval

pat propsEvpat r s

where hhatpat prop patrow prop pat prop satisfy the rulesii stands for a big conjunction of

terms with each conjunct representing a pattern evaluation rule

In order to prove our theorem Equation we need to make the conclusion of the

induction theorem match the theorem wewant to prove Thus we see that weneedto

sp ecialize the variable pat prop to sEvpat r s s s Wemust also instantiate the

prop and patrow prop It is clear that these latter prop erties should assert prop erties atpat

that the nal state is the same as the initial state so they are s E v atpat r s s s

for atomic patterns and sE recpatrowrs s s for pattern rows

Thus in order to prove our theorem wemust prove that these three prop erties satisfy

the pattern evaluation rules We will showhow the prop erties satisfy one rule The rule is

one of the rules resulting from expanding out Rule shown on page It is

s E v pat VEs

s E v var as pat fvar v g VEs

This is enco ded as

s E v var pat VE s

prop s E v pat VARENVvef VE s pat

prop s E v LAYEREDpat e var pat pat

VARENVvef

add varenv e

into varenv eemptyvarenv e var v VE insert

s

Note that pat prop is used here instead of eval pat since the conjunct states that the

prop erties satisfy the rules not that the evaluation relations satisfy the rules The HOL

constructor VARENVvef indicates that the result is a variable environment rather than

FAIL

prop is replaced by sEvpat r s s s we are left with the following to When pat

prove

sEvvarpat VE s s s s s

This is easily proved After proving that the prop erties satisfy the rules yielding a theorem

T an application of the rule MP mo dus p onens to T and the induction theorem proves

the desired theorem

Note that b ecause the pattern evaluation relations were dened separately from the

relations for all other phrase classes this pro of which only involved prop erties of patterns

did not need to consider cases for other phrase classes

The next example is Theorem in the Commentary This is

Theorem For any phrase let the sentence

s A phrase A s

beinferred where s mem ens cns and s mem ens cns and A A are semantic

objects Then

Dommem Dommem and ens ens and cns cns

This is a more complicated theorem The rst complication is that it refers to all phrase

classes in the reduced syntax rather than just some of them Furthermore in order for the

prop erty to hold for one group of phrases it must hold for all groups of phrases up on which

the group dep ends For example the group including the expressions AtExp ExpRow

Exp Match Mrule Dec and ValBind dep ends on the pattern phrase group Rule

shown on page for value bindings refers to the execution of patterns In order to

prove the prop erty for expressions wemust rst prove it for patterns

Thus in order to prove this theorem wehave to dene prop erties for all the phrase

classes and then prove the theorem in separate steps one for each group of mutually

recursive phrases The exact order in whichwe prove the theorems do es not matter as



As wehave added a semantic ob ject for constructor names to HOLSML we include ConNameSet in

the state in our presentation of the theorem

long as the theorems for more basic phrase groups are proved b efore theorems for phrase

groups that dep end on them For example the pattern phrase group and exception binding

phrases do not dep end on each other so either one can b e proved rst

The second complication is that it takes a little bit of thoughttoseehow to enco de this

theorem into HOL The problem is howtoencodeDommem Dommem HOL has a

set theory and this provides the predicate SUBSET for testing set containment Then the

Dom function must b e enco ded in HOL This is easily done resulting in an HOL function

dom set that takes as an argument a nite map and returns the set of its domain elements

Then the statement of the theorem for expressions is

exp s E exp vp s s E exp vp s eval

dom set mem of state s SUBSET dom set mem of state s

exnames of state s SUBSET exnames of state s

of state s SUBSET connames of state s connames

of state exnames of state and connames of state are HOL functions that Here mem

return the memory exception name set and constructor name set comp onents of a state

Comparing with the induction theorem for expressions

atexp prop exprow prop exp prop match prop

mrule prop dec prop valbind prop

hhatexp prop exprow prop exp prop match prop mrule prop

prop and valbind prop satisfy the rulesii dec

s E exp vp s

eval exp s E exp vp s exp prop s E exp vp s

we see that the prop erty for expressions must b e

s E exp vp s

set mem of state s SUBSET dom set mem of state s dom

exnames of state s SUBSET exnames of state s

connames of state s SUBSET connames of state s

The prop erties for the other phrase classes are dened similarlyWe will not go describ e

how one would go ab out proving this theorem since the pro of of determinism whichisa

long and complicated pro of will b e explored carefully

Inversion Theorems

Inversion theorems are standard theorems to prove ab out inductivelyde ned relations In

Tom Melhams inductive relations denition package they are referred to as case analysis

theorems and are proved automatically that is he has written functions that given the

induction theorem for the relation and a theorem stating that the rules are satised proves

and returns the case theorem Our mutually recursive relations denition package also

automatically proves these theorems Since they are imp ortant theorems we will describ e

the theorems and how to phrase them in terms of the induction theorems

Inversion theorems can b e summarized this waySay relation R holds of some argu

ments v v v Then the inversion theorem for this relation gives the p ossible forms

n

that the arguments v v v can have and for eachcombination of p ermissible forms

n

indicates what prop erties they must have in order for it to b e the case that R holds of

those arguments Both the p ossible forms of arguments for the relation and the prop erties

for them are derived directly from the rules To explain this we will show the form for the

inversion theorem for atomic expression and showhow Rule ts into this form Rule

is

exp v E dec E E E

E let dec in exp end v

When the state conventions and exception conventions have b een applied to it the result

is the following three rules

s E dec E s s E E exp v s

s E let dec in exp end v s

s E dec p s

s E let dec in exp end p s

s E dec E s s E E exp p s

s E let dec in exp end p s

The inversion theorem for atomic expressions has the form

s E atexp vp s

atexp s E atexp vp s hhbig disjunctionii eval

where hhbig disjunctionii contains one disjunct for each rule for atomic expressions These

disjuncts state what form the arguments of eval atexp can have and the hyp othesis of the



A disjunction is a collection of terms that are ored together A disjunct is one of these terms

rule that allows one to conclude that eval atexp holds of those arguments The disjuncts

corresp onding to the three rules for are

decvE s

atexp LETatexp e decexp

vp VALvp v

eval dec s Edec ENVep E s

eval exp s add env e EE exp VALvp v s

dec exp p

atexp LETatexp e decexp

vp PACKvp p

eval dec s Edec PACKep p s

dec exp p E s

atexp LETatexp e decexp

vp PACKvp p

eval dec s Edec ENVep E s

exp s add env e EE exp PACKvp p s eval

As b efore the waywe prove prop erties is via the induction theorems The induction

theorem for atomic expressions is

atexp prop exprow prop exp prop match prop

mrule prop dec prop valbind prop

prop exprow prop exp prop match prop mrule prop hhatexp

dec prop and valbind prop satisfy the rulesii

s E atexp vp s

atexp s E atexp vp s atexp prop s E atexp vp s eval

Comparing this theorem against the statementofthematch theorem we see that the

prop erty asso ciated with atexp prop must b e

s E atexp vp s hhbig disjunctionii

In order to prove the inversion theorem for atomic expressions wemust dene similar

prop erties for the other phrase classes Exp ExpRow Match Mrule Dec and ValBind

and prove that these prop erties satisfy the rules All of this is done automatically by our

mutually recursive relations denition package

Note that similar theorems can b e proved for all groups of phrases for example the

pattern phrases However since the theorems only state that the rules that dene the

relations can b e inverted the prop erties for the dierent phrase groups are indep endent

This is in contrast to for example Theorem where the theorem for the group including

expressions dep ended on the theorem for the pattern phrase group

Determinism

The determinacy theorem is Theorem in the Commentary

Theorem Determinacy Let the two sentences

s A phrase A s s A phrase A s

both be inferred Then A s only diers from A s by a onetoone change of addresses

and exception names which do not occur in s A

As mentioned in Section A page the choice of next address and exception name

in HOLSML is deterministic Thus our nal states and results are the same instead of

diering by exact choice of addresses and exception names Therefore our determinacy

theorem is stated as follows this is the version for expressions

s E exp vp s vp s

eval exp s E exp vp s eval exp s E exp vp s

s s vp vp

This do es not quite t the form of the conclusion of the induction theorem for expressions

Equation However an equivalent statement of the theorem

s E exp vp s

exp s E exp vp s eval

s vp eval exp s E exp vp s s s vp vp

do es t the induction theorem Thus we see that exp prop must b e

vp s E exp vp s s

vp vp s s eval exp s E exp vp s

The prop erties for the other phrase classes are similar

As with Theorem the dep endencie s among the phrase groups give rise to dep en

dencies among the determinacy theorems for the phrase groups and thus must b e proved

in steps with the theorems for more basic phrase groups such as patterns and exception

bindings b eing proved b efore the theorems for the phrase groups that dep end on them

such as the group including the expressions

We will trace through the pro cess of proving determinacy for group including the

expressions We will showhowtoprove the case for one of the rules resulting from Rule

The rule is

s E dec E s s E E exp v s

s E let dec in exp end v s

The enco ding of this rule as a condition to b e satised by prop erties is

s E decexpvs

E s

dec prop s E dec ENVep E s

exp prop s add env e EE exp VALvp v s

atexp prop s E LETatexp e decexpVALvp v s

prop exp prop and atexp propwe nd that wemust prove When we instantiate dec

the following this is shown in a manner mimicking what one would see while doing goal

directed theorem proving in HOL that is the goal is shown ab ove a horizontal line and

the assumptionsstatements one can use in doing the pro ofare b elow the line

s E dec exp vs

E s

ep s

dec s E decep s s s ENVep E ep eval

vp s

eval exp s add env e EE exp vp s

s s VALvp v vp

vp s

atexp s E LETatexp e decexp vp s eval

s s VALvp v vp

After a bit of elementary pro cessing basically rearranging the terms and cho osing

instances for the existentially quantied variables in the antecedents of the goal weget

s s VALvp v vp

ep s

eval dec s E decep s s s ENVep E ep

vp s

exp s add env e EE exp vp s eval

s s VALvp v vp

atexp s E LETatexp e decexp vp s eval

This is where the inversion theorems come in Wehave

eval atexp s E LETatexp e decexp vp s

among the assumptions and this should tell us something ab out the evaluations of the dec

and exp within the let expression The inversion theorem is the agent that allows us to

draw these conclusions Using forward inference we instantiate the inversion theorem for

atomic expressions to the arguments of eval atexp ab ove and then using the fact that

dierent forms of atomic expressions are distinct we conclude that

dec exp vE s

dec dec exp exp vp VALvp v

dec s E dec ENVep E s eval

eval exp s add env e EE exp VALvp v s

dec exp p

dec dec exp exp vp PACKvp p

eval dec s E dec PACKep p s

dec exp pE s

dec dec exp exp vp PACKvp p

eval dec s E dec ENVep E s

eval exp s add env e EE exp PACKvp p s

When weuse STRIP ASSUME TAC with this information to add it to the assumptions

we get three subgoals We will showhowtosolvetwo of them The rst one is

s s VALvp v vp

ep s

dec s E decep s s s ENVep E ep eval

vp s

eval exp s add env e EE exp vp s

s s VALvp v vp

eval atexp s E LETatexp e decexp vp s

dec dec

exp exp

vp VALvp v

eval dec s E dec ENVep E s

eval exp s add env e EE exp VALvp v s

Tosolve this we take the assumption

eval dec s E dec ENVep E s

and combine it with

dec dec

to get

eval dec s E dec ENVep E s

and match this against the assumption

ENVep E ep s s ep eval dec s E decep s

to conclude that

s s ENVep E ENVepE

and from the second conjunct weget

E E

b ecause the constructor ENVep is onetoone Then using this information we conclude

from the assumptions

exp s add env e EE exp VALvp v s eval

and

exp exp

that

exp s add env e EE exp VALvp v s eval

Then wematch this against the assumption

vp s eval exp s add env EE exp vp s

s s VALvp v vp

getting the result that

s s VALvp v VALvp v

Nowwecombine this information with the assumption

vp VALvp v

and wehave proved the goal

The second goal we will slowhow to solveis

s s VALvp v vp

ep s

dec s E decep s s s ENVep E ep eval

vp s

eval exp s add env e EE exp vp s

s s VALvp v vp

atexp s E LETatexp e decexp vp s eval

dec dec

exp exp

vp PACKvp p

dec s E dec PACKep p s eval

Here when wematch

eval dec s E dec PACKep p s

against the assumption

dec s E decep s s s s ENVep E ep ep eval

we conclude that

s s ENVep E PACKep p

whichisacontradiction since the constructors for env pack ENVep and PACKep are among

these are distinct Thus when we rewrite this conclusion with the distinctness theorem

TAC and the subgoal wegetF from the assumptions wehaveproved false We use CONTR

is proved

Note that for the goals shown here the determinacy of subphrases was given by as

sumptions this is how the induction hyp othesis shows up in this pro of For phrases that

include subphrases from other groups like patterns or exception bindings the determi

nacy of subphrases is given by the theorems for determinacy for those phrase groups rather

than by induction hyp otheses This is why for example wemust prove the determinacy

for the pattern phrase group b efore proving it for the group including expressions

The numb er of cases to b e dealt with in proving this theorem is huge In our example

we started with a goal deriving from one rule and got three subgoals from the use of the

inversion theorem This results in roughly subgoals in the pro of It was obvious that

we needed some automation here We strove to write one tactic that would solveasmany

of these goals as p ossible The pro cess by which the tactic solved the goals is essentially

similar to that shown for the goals solved ab ove However there are many sp ecial cases

that show up in the subgoals a result of side conditions in the rules Unfortunatelyso

many subgoals are generated in the pro cess of proving this theorem that even the sp ecial

cases must b e included in the tactic in order for it to b e able to treat most of the subgoals

Thus the resulting tactic is ugly and unreadable but it works after applying this tactic

to the more than subgoals resulting from breaking up the rules according to the

cases presented by the inversion theorems there are only subgoals remaining These are

sup ersp ecial cases that need to b e handled by separate tactics

The pro cess of nding one tactic that works on all but of the or so subgoals

was an iterative pro cess rst all of the goals were printed into a le and we sampled

these randomly and wrote a tactic that would solve these goals Then we applied this

tactic to all the subgoals and found that it had solved ab out one third of them The

remaining subgoals were again examined and the tactic was rened to solve a sampling

of these subgoals After applying this only ab out subgoals remained After a bit more

tweaking the resulting tactic yielded remaining subgoals We decided that generalizing

the tactic enough to solve these remaining goals would complicate it far to o much and so

sp ecial tactics were written for these cases

Doing the pro of of determinacy allowed us to nd manymistakes in our enco ding

These mistakes would show up as subgoals that either were unsolvable or lo oked strange

When we traced them back weinvariably found that they were due to something likea

missing prime on a variable in our enco ding of the rules

One asp ect of using a theorem prover that b ecame apparent to the author during the

pro of of this theorem was that theorem provers do not let a user get away with anything

Often during the course of a pro of on pap er p eople will lo ok at a small basic lemma

and say this is obvious and not make a formal pro of of it However a theorem prover

demands that one actually work out a pro of of the lemma As an example a lemma that

we needed for the pro of of the determinacy theorem is

l l istl l istf

ONE f MAP fl MAP fl l l ONE

Chapter

Relating Static and Dynamic

Semantics

When an SML program is evaluated one of three things could p ossibly happ en The rst

p ossibility is that the evaluation do es not terminate b ecause it gets into an innite lo op

The second p ossibility isthatitdoesnotevaluate b ecause there is no rule that applies

to the phrase wesay that evaluation is stuck For example there is no rule for the

application of to an atomic expression The third p ossibility is that the evaluation could

succeed and pro duce some result which is for expressions either a value or a packet One

would hop e that SML has the prop ertyoftyp e soundness that is the second p ossibility

that the evaluation gets stuck b ecause no rule applies do es not o ccur

Unfortunately natural semantics for form of semantics used in the Denition is not

well suited to proving this sort of theorem The problem is that it is dicult to distinguish

between not b eing able to pro ceed at all there is no rule that applies to the phrase and

there b eing no end to the computation the evaluation gets into an innite lo op they are

b oth reected in there b eing no result A or nal state s such that s A phrase A s

is derivable However the reason for the lack of results is dierent Saywewantto

evaluate the program true This is an application of the expression to the atomic

expression true There are several rules that have as their conclusion a sentence of the

form s E exp atexp v p s for some vp and s Each of them has hyp otheses that

describ e the evaluation of exp saytov and atexp saytov and there are various side

conditions or further evaluations to represent the application of v to v There are no

rules for when v is a sp ecial value namely the integer Thus our attempt to evaluate

this phrase has stopp ed dead

On the other hand saywewanttoevaluate

letvalrecf fnxfx inf end

The declaration val rec f fn x f x will result in an environment where f is

b ound to the closure

xfxEff xf xEfgg

The rst comp onent is the match that forms the b o dy of the function The second com

p onent E is the environment in which the expression is evaluated The third comp onent

is a variable environment that allows for the function to b e applied recursively by giving a

value for the o ccurrence of f in the b o dy of the function

In the evaluation of fin the b o dy of the let f will evaluate to the closure ab ove

and evaluates to itself Two rules could apply here

s E exp match E VEs s E atexp v s

s E RecVEv match v s

s E exp atexp v s

s E exp match E VEs s E atexp v s

s E Rec VEv match FAILs

s E exp atexp Matchs

The rst is for normal function evaluation that is one of the clauses in match matches

the value v and the evaluation results in a value v The second rule is for when none of

the clauses in match matches v

It seems that we should use the rst rule since matches the pattern in xfx

which is just the variable xHowever in trying to evaluate the b o dy of the function with

x b ound to as required by Rule page we nd that we again need to evaluate f

which is the evaluation for whichwe are currently attempting to nd the result Thus

an innite lo op is represented byanneverending searchforaway to complete a pro of

tree

We remind the reader that concrete SML syntax that is not using the constructors with whichitis

enco ded into HOL will b e written in typ ewriter font The program variables when shown separately will

b e written in italics

Metho ds of Proving Typ e Soundness

Typ e soundness is usually proved as a corollary of a prop erty called strong type soundness

This prop erty states that if a program is welltyp ed and has typ e then its evaluation

either go es on forever or results in a value of typ e Since a welltyp ed value cannot result

from a typ e error this must b e proved this implies typ e soundness

Some ways of expressing the dynamic semantics of programs lend themselves more

easily to pro ofs of strong typ e soundness For example the syntactic reduction approach

used byWright and Felleisen in WF allows the theorem to b e stated and proved in

a straightforward way In this presentation of dynamic semantics evaluation pro ceeds a

step at a time Basic steps are written phrase phrase everything is syntax here

substitution is used instead of environments and an expression called a expression is

used instead of a separate state

Examples of the reduction steps phrased in SMLlikesyntax are

let x v in exp end exp vx

for reducing a let expression v is a syntactic representation of a value and exp vxis exp

with v substituted for x and

bv APPLYb v

for applying a basic value to another value Evaluation contexts K are used to determine

which reduction will b e done next The reductionincontext rule is

e e

K e K e

Evaluation contexts are given as follows

K j Kej vK j let x K in e

for e an expression This essentially says that if our expression is the application of an

expression to another expression then wemust reduce the expression that is acting as a

function rst until wegetavalue and only then can we start applying reductions to the

expression to which the function is b eing applied In let expression we rst reduce the

expression to which the variable is b ound until it is a value Then after a let reduction

the b o dy with the value substituted for the variable is reduced



Substitution is explained in Section

The relation is the reexive transitive closure of

This metho d can b e contrasted with the SML rule for the application of a basic value

s E exp b s s E atexp v s APPLYb v v

s E exp atexp v s

Here the expression is rst fully evaluated then the atomic expression is fully evaluated

and then the apply is done In syntactic reduction semantics the evaluations of the

expression and atomic expression is done step by step until values are gotten and then

the basic step bv APPLYb v is done The natural semantics incorp orates structure

which is given byevaluation contexts and the reductionincontext rule in the Wright

Felleisen semantics and op eration the reduction of bv to APPLYb v into one rule

A simple evaluation in the WrightFelleisen style is given as

let x succ in sq x let x in sq x sq

where succ is the successor function and sq is a squaring function The rst step is justied

by the following instance of the reductionincontext rule

succ

let x succ in sq x letxinsqx

and the other steps are justied by rules where the reduction context is the entire expres

sion

This metho d of dynamic semantics is more suited for pro ofs of strong typ e soundness

b ecause an innite evaluation is distinguished from a stuckevaluation An innite evalu

ation is represented as an innite chain of reductions A stuckevaluation is represented

byachain of reductions that ends in an expression that is not yet a value for whichno

next step can b e taken Faulty expressions are those with basic typ e errors the use of a

basic function like with the wrong typ e of argument or the use of a nonfunction as if

it were a function Faulty expressions are a sup erset of the stuck expressions they are a

prop er sup erset some expressions evaluate to a value even if they are faulty as the faulty

part of the expression may not b e evaluated

Strong typ e soundness for this system is proved byrstproving three other prop erties

typepreservation uniform evaluationanduntypability of faulty expressionsUntypability

of faulty expressions states that faulty expressions cannot b e given a typ e there is no C

and such that C e Typ e preservation says that for any expression eif e has typ e

e then e has typ e Uniform evaluation says that for any expression e and e

the evaluation of e either results in an innite lo op gets stuck or results in a value v

Strong typ e soundness is proved from these prop erties as follows Say e has typ e and

its evaluation is not innite Then by uniform evaluation e e where e is a stuck

expression or a value By untypability of faulty expressions if e were stuck then it would

b e faulty and thus it would not havea typ e By typ e preservation e has typ e which

eliminates this p ossibilityThus e isavalue v whichbytyp e preservation has typ e

Another form of dynamic semantics that is well suited to the statement and pro of

of strong typ e soundness is that used in Leroy Here an abstract machine is used

to sp ecify the evaluation of a language with references p olymorphism by name and

continuations The evaluation is done a step at a time using two relations that are dened

in terms of each other One relation breaks up the term placing structural information

in the continuation and doing reductions until a value is reached The other relation

determines howtoapplythecontinuation to a value Leroy has augmented the usual

semantics for programs in order to eliminate stuckevaluations if none of the evaluation

rules are matched the evaluation results in the distinguished answer wrong Like the

WrightFelleisen semantics programs that get into innite lo ops are expressed by an innite

sequence of reductions This dierentiates them from programs with typ e errors which

result in wrong Since there are two relations used here there are two parts to strong typ e

soundness First if an expression e has typ e and the continuation k accepts values of

typ e then if weevaluate e with continuation k the result is not wrong Second if a

value v has typ e and the continuation k accepts values of typ e thenifwe pass on v to

k the result is not wrong

SML is sp ecied using natural semantics so wemust take a dieren t route The

standard approach for proving strong typ e soundness in natural semantics is shown in

ACPP The idea is that as in Leroys semantics evaluation will b e dened for every

program whether or not it is typ ecorrect The ob ject wrong is returned whenever there

isatyp e error in the program so weaddwronggeneration rules such as

s E exp v s v is not applicable

s E exp atexp wrongs

Here is not applicable means that v is not one of the values that can b e used as a



Leroy refers to his semantics as b eing in a structural op erational style but a close examination shows

that this form of op erational semantics is similar to the CEK abstract machine as in FF

function Wealsoneedwrongpropagation rules suchas

s E exp v s v is applicable s E atexp wrongs

s E exp atexp wrongs

If the wrong rules are added in suchaway as to ensure that there is a rule that applies

to every syntactically correct program then an attempt to evaluate an expression will

either result in a innite search for a pro of tree reecting an evaluation that gets into

an innite lo op or the program will evaluate and the answer will either b e wrong or a

prop er result suchasavalue or a packet As with the WrightFelleisen semantics typ e

preservation if e has typ e and e evaluates to v then v has typ e isproved Since

wrong is not given a typ e if e has typ e and results in an answer a then a has typ e

and is thus not wrong

Thus once one has assured that there is a rule for every syntactic form the diculty

in this theorem lies in proving typ e preservation This is proved by induction on the length

of the inference that s E exp v s

Let us consider what would b e involv ed in taking this approach to proving strong typ e

soundness for Core SML Adding wrongpropagation rules one for eachhyp othesis and

wronggeneration rules would dramatically increase the number of evaluation rules at least

doubling it This would makeany pro of ab out the system large and dicult

Another approach given in GR uses the idea of a partial proof The idea here

is that logic variables can representanevaluation result that is as yet unknown If a

logic variable o ccurs as the result of an evaluation in the hyp otheses of a rule then other

hyp otheses may use this unknown result but the results of these evaluations are required

to b e unknown also If a pro of tree has logic variables in it then it can b e considered a

partial pro of This form of semantics has twotyp es of sentences exp and exp

where is either a value or a logic variable States are not present here b ecause there

are no references in GR and environments are not present b ecause substitution is used

instead The latter sentence exp is roughly analogous to the op eration in the

WrightFelleisen semantics although in addition to a single reduction step the evaluation

of the reduction is completely carried out The former exp roughly corresp onds to

that is the full evaluation of a term includin g man y steps taken within contexts

Examples of evaluation rules are

e e

applicationsearch

ee

evx v

applicationreduce

fn x e v v

where there would b e quite a few application reduction rules dep ending on the form of the

value b eing applied In addition wehave

v v value

far values v

The advantage of this approach is that again we can distinguish b etween phrases to

which no rule applies resulting in stuckevaluations and phrases that execute forever

Phrases to which no rule applies are represented by partial pro ofs in which no renements

extensions of the pro of towards the leaves in order to try to replace logic variables by

values can b e made and phrases that execute forever are represented by partial pro ofs in

which renements can always b e made An example of a stuckevaluation is the following

where X is a logic variable

true true

true true true X

true X

Evaluation for this system can b e describ ed as a series of pro ofs each of whichisa

renement of the previous one Evaluation ends when the sentence in the conclusion of

the pro of is exp v for some value v Strong typ e soundness for this system is stated as

follows Say e has typ e and P is a partial pro of with e as its conclusion Then if

there is no P that renes P then P is a total pro of it contains no logic variables is

avalue v and v has typ e A consequence of this theorem is that evaluation cannot get

stuck for lack of a rule that applies

We will not take this approach either It would require formulating partial pro ofs

in HOL and recasting the rules into the two forms of evaluation relation needed for this

system These seems to b e no theoretical dicultyinformulating partial pro ofs in HOL in

fact Syme Syme has formulated pro of trees but without logic variables in his enco ding

of SML in HOL However recasting SML evaluation rules into the two forms of evaluation

relation would b e a substantial departure from the rules given in the Denition and it

would b e more dicult to say that the enco ded language is close to that given in the

Denition

Therefore instead of proving typ e soundness we will aim toward proving typ e preser

vation When typ e preservation is proved for a system without wrong rules it do es not

ensure typ e soundness Consider the following rules for a let expression

e e x

let typing

let x e in e

e v e v x v

let evaluation

let x e in e v

If x do es not o ccur in e then a typ e error in e will not get caughtby the typ echecker

but it will cause a typ e error in the evaluation of the let expression Thus for this system

typ e preservation would not guarantee typ e soundness

To b e a bit more precise we will state typ e preservation as follows Say that C exp

and s E exp v p s where vp is a value or a packet In addition assume that E

agrees with C that is that the values asso ciated with variables in E can b e given the

typ es asso ciated with them in C Then if vp is a value v then v has typ e

This statement of the prop erty needs to b e rened For example we need constraints

on the typ es of the values in the range of the state we need to ensure that for each address

a in the domain of the memoryif E maps the variable v to the address a then sa has

typ e C v This prop erty will b e rened and the notions agrees with and has typ e

dened in Chapter

WhyProveTyp e Preservation

Neither typ e soundness nor typ e preservation for all of Core SML has b een proved Typ e

soundness has b een proved for various languages with some of Core SMLs key features

Wright and Felleisen WF proved typ e soundness for a language with p olymorphism

references exceptions and continuations using a syntactic reduction semantics Leroy

Leroyproved typ e soundness for a language with p olymorphism by name references

and continuations using an abstract machine semantics Abadi Cardelli Pierce and

Plotkin ACPP proved typ e soundness for a functional language with typ e dynamic

using natural semantics and wrong rules Tofte proved typ e preservation for a language

with p olymorphism and references using a semantics almost exactly like the one in the

Denition this is not a surprise he is one of the authors of the Denition



Thanks to Frank Pfenning for this example

Since we will not provetyp e soundness and thus will not demonstrate that evaluation

of typ ecorrect programs do es not result in a runtime typ e error one wonders why b other

trying to provetyp e preservation Furthermore few p eople doubt that SML at least SML

as implemented is actually typ esound it has b een in use long enough that one presumes

that anyerrorswould have b een caught and xed long ago Thus one might ask why

provetyp e preservation when no one doubts that a stronger theorem typ e soundness in

fact holds of the language There are several answers to this question

The rst is that implementations are a dierent sort of ob ject than a formal language

denition The fact that some version of SML has had all known bugs xed is no more than

a statement that it has b een extensively tested There maywell b e a program that no one

has written yet that will demonstrate that typ e soundness do es not hold This do es o ccur

o ccasionally esp ecially when ma jor changes have b een made to the compiler Furthermore

all implementations dier from the Denition In fact the rules in the Denition are not

typ esound The most obvious error which is explained by Kahrs in Kahrs is the

conicting treatment of constructors in the evaluation and typ echecking rules sp ecically

with resp ect to the ref constructor This is explained briey in Section A Thus it

would b e useful to have one language that we are certain satises a strong prop erty such

as typ e preservation

The second is that typ e preservation is a more basic prop erty than typ e soundness

Typ e preservation is what ensures that the typ e system and the op erational semantics t

together prop erly For example it is what ensures that if a program is giv en the typ e

int int bythetyp e system then if it is evaluated with an integer argument then

the result really is an integer Once typ e preservation is proved typ e soundness is then a

matter of checking that typ e system checks all subparts of the term and that the evaluation

system has a rule for each p ossible case for a correctlytyp ed term for example there is an

evaluation rule for the application of eachformofvalue that can b e given function typ e

A third answer is that as noted typ e preservation is a necessary and signicant step

towards proving typ e soundness Furthermore many if not most of the errors that would

prevent a pro of of typ e soundness are likely to show up in an attempt to provetyp e

preservation

Fourth there have b een manychanges prop osed to Standard ML suchasweak p oly

morphism a form of which has b een implemented in SMLNJ rstclass continuations

and p olymorphism by name There have b een pro ofs of typ e preservation or typ e sound

ness published for each of these extensions HMVWF Leroy HDM However

these pro ofs have b een done only in small subsets of SML and there is no guarantee that

they would not interact badly with some language feature not included in the studyThus

a pro of of the typ e preservation of SML if it were easily understo o d and extendible could

provide a framework into which researchers could investigate the eects of new language

features or extensions to the typ echecking rules

Fifth proving typ e preservation of Core SML would demonstrate the utility of math

ematical sp ecications of programming languages Informal language sp ecications are

often easier to understand than mathematical ones however they lack the precision re

quired to prove desirable prop erties ab out a language A mathematical sp ecication can

more accurately give the meanings of programming language constructs but if the mathe

matics is to o complicated it will b e useless A pro of of an imp ortant prop ertysuchastyp e

preservation then can act as a demonstration that the sp ecication is a sensible one

Sixth in addition to its theoretical imp ortance a pro of of typ e preservation would b e

useful to researchers working on verication of SML programs For example say that we

would like to prove the correctness of a list app end function Since we only need to show

that an app end function p erforms its duties correctly on values wewould like to factor

out the evaluation of the arguments of the function from the evaluation of the function

itself A p ossible statement of this theorem is then

Theorem Let hhlist exp ii and hhlist exp ii be list expressions that is

exp ii list s C hhlist

and

s C hhlist exp ii list

for some where C is the initial context Let E be such that

exp iival l hhlist exp ii E s s E val l hhlist

where E is the initial environment Say that

s E E let val append hhappend funii in append l l end v p s

Then vp is a value v and not a packet s s andvAPPEND El El where

APPEND is a mathematical description of the intendedeect of the append function

Typ e preservation would ensure that the values asso ciated with variables l and l are

in fact prop er list values

Chapter

Towards Proving Typ e

Preservation

The rst step in proving typ e preservation is precisely dening the notions used in the

statementoftyp e preservation at the end of Section In particular we need to dene

what E agrees with C and v has typ e means and we need to include a hyp othesis

that ensures that the state agrees with the context It is not at all clear how to phrase

these denitions and as they are crucial in the pro of we exp ound on them in the rst

section of this chapter

Then we restate the typ e preservation prop erty in a precise way and discuss the progress

made towards proving it The biggest accomplishment to date has b een the pro of of

typ echecking under substitution This theorem and its pro of are discussed in the last

section of this chapter

How to Givea TypetoaValue

The published pro of that is closest to a pro of of typ e preservation for SML is in Tofte

There Tofte uses a natural semantics that is close to that used in the Denition including

a similar treatment of state and environments in the evaluation rules Thus we used Toftes

denitions as a starting p ointforourown The idea is that b oiled down to the basics E

maps variables to values and C maps variables to typ e schemessoE agrees with C if

for every v ariable its value in E can have the typ e scheme asso ciated with it in C

We will start to describ e howtogiveatypetoavalue For simple semantic ob jects such

as integers and strings this is easy It is only slightly more complicated for basic values

such as addition and assignment the typ es for these values is given by the Denition so

we just check that the typ e matches the exp ected one For records and constructed values

suchasl for an integer list l this is straightforward the typ e is dened structurally

using the typ es given by the context for the value constructors For closures it is a bit

more complicated as the closure contains a match whichisasyntactic phrase along with

the evaluation environment at the time the matchwas put into the closure Togiveatyp e

for the closure then one must nd a context that agrees with the evaluation environment

and elab orate the matchinthiscontext

What do we do if the value is an address Nowwehave to consider the contents of

the store the store is the same as what is referred to in the Denition as the memorya

mapping from addresses to values Here weintro duce the notion of a store typinga

map from addresses to typ es This store typing is needed to take accountoftwofacets

of referencesaliasing twovariables can refer to one reference cell and the fact that the

contents of a reference cell can change over time The store typing ensures that if variables

refer to the same reference cell containing a value of typ e then they have the x and y

same typ e namely ref One might protest x and y do not need to have the same typ e if

the contents of the cell is a p olymorphic ob ject such as the identity function In this case

x could havetyp e int int ref while y could havetyp e bool bool refHowever

if the call is later assigned the successor function then ys typ e would then b e incorrect

Toavoid this problem typ es of items in reference cells are required to b e simple that is

not p olymorphic This is why a store typing is a map from addresses to types not typ e

schemes

The presence of reference cells means there are two relations to b e dened when a

store matches a store typing and when a value has a typ e Tofte combines these two

relations into one He writes m ST j v to mean that given a typ ed store m ST

value v has typ e As part of the denition he ensures that store m agrees with the store

typing STif v is an address a then must b e ST a ref and m ST j m aST a

The problem with this denition is that it cannot b e dened by regular induction as there

can b e circularities in the store Consider the following three SML statements

val f ref fn xint

val g ref fn x if x then else fx

f fn x if x then else gx

The result of this is a store in which f refers to g and vice versa Thus in trying to

determine that m ST j a int int ref where m is the resulting store ST is the

f

resulting store typing and a is the address to which f is mapp ed wemust check that

f

m ST j a int int ref which in turn requires showing that m ST j a int

g f

int ref

Because of the circularity present here Tofte must use maximal xed p oints to give

the meaning of this relation The principle of coinduction comes from this denition

just as our induction theorems for the evaluation relations come from the denition of the

relations as the least relations satisfying the rules Coinduction is an unfamiliar principle

and it would b e nice to disp ense with it if p ossible

Leroy Leroy denes these concepts in a dierentway resulting in a simpler deni

tion The key is that one do es not need to know the value at a given address in a store in

order to know its typ e one only has to lo ok up the address in the store typing Thus he

denes using Toftes terminology two dierent relations ST j v and j m ST The

rst determines when a value has a given typ e dep ending on the store typing and the

second determines that a store agrees with its store typing Using these denitions the

store resulting from the SML statements ab ove do es not present denitional circularities

despite the fact that the store itself is circular verifying that ST j a int int ref

f

involves only lo oking up the typ e of a in STVerifying that j m ST do es involve

f

checking that the contents of a and a b oth havetyp e int int but the check that

f g

the value at address a has typ e int int involves only checking the typ e of a not its

f g

contents The denitions given in the styleofLeroyavoid the use of maximal xed p oints

as a denitional metho d and thus avoid coinduction as a metho d of proving lemmas

The denitions of these relations must b e expanded considerably in order to account for

datatyp e declarations E and C must b e included in the valuehastyp e relation written

ab oveasST j v E is needed to determine which constructors are asso ciated with

the constructor names in the value and C is needed to nd the typ e of this constructor

Similarly E and C must b e included in the storehasstoretyp e relation written ab ove

as j m ST In addition we will use several mutually recursive relations in order to

clarify the presentation These relations match the structure of values There is b e a

valuehastyp e relation which will b e written j that covers the assignment op erator

v

sp ecial values integers and strings basic values builtin op erators likeanddiv and

See Section A for an discussion of constructor names

address values There are convalhastyp e j and exvalhastyp e j relations that

c e

sp ecify when ConVals and ExVals have a given typ e There is a closurehastyp e j

f

relation for closures and a recordhasrectyp e j relation that sp ecies when a record

r

has a given record typ e We will refer to the collection of these relations as the valtyp e

relations

Let VE be a variable environment for the static semantics that is a map from variables

s

to typ e schemes and VE be a variable environment for the dynamic semantics a map

d

from variables to values We need a relation that states that VE agrees with VE when

d s

the status of identiers in VE is given by SM status maps are explained in Section A

s

This relation is written C E ST j VE VE SMwhereC isacontext and E a dynamic

d d s d

vironment Werstcheck that the domains of VE and VE are the same For any i in en

d s

the domain of VE ifSMiisc stat or e stat we assume that this entry is the result of

d

the original denition of the constructor name or exception name and do not check further

If the status is of i is v stat then we need to determine that the value VE i agrees

d

with the typ e scheme VE i The natural way to do this which is the metho d used by

s

Tofte is to say that a value v agrees with a typ e scheme if v has typ e for any that is an

instantiation of Unfortunately these relations will have to b e dened with our mutually

recursive relations package and Toftes denition cannot b e formulated in the package

the hyp otheses of the rule can only b e single instances of the relations b eing dened or

side conditions that do not mention the relations We cannot havehyp otheses that are

universally quantied instances of the relations b eing dened Wesolve this dicultyby

including in the valtyp e relations yet another argument a set of typ e variables tvand

arrange so that the relation returns true if the value has the typ e and the typ e variables

in tv can b e substituted for The relationship for values is written C E ST j v tv

d v

The notion that a set of typ e variables in a t yp e can b e substituted for needs some

explanation Say the typ e scheme is The statementv has typ e for any that

is an instantiation of means that for any substitution S with domain v has typ e S

where S is the substitution S applied to Thus to show that C E ST j v tv

d v

wemust show that v has typ e and that for any substitution with domain tv v can also

havetyp e S

In order to describ e how to dene C E ST j v tv we rst note that the relation

d v

will b e dened inductively with the typ es of values dep ending on the subparts of the

values so tv maycontain variables not in the values Table shows the denitions of

mk var SM VE SM such that Dom SM Dom VE and

Rng SM fv statg

basval typ e b true i is the typ e of the basic value b

typ e of sval s int if the value is an integer

string if the value is a string

conname typ e CE cn longcon

d

E longcon cn and

d

C longcon and

typ e CE tv en longexcon exname

d

T

tv tyvars and

E longexcon en and C longexcon

d

closure VE C VE VE Dom VE Dom VE and

d s d s

i Dom VE match

d

reduce match match and C match and

d

T

tyvars C free

where VE i and

s

VE i match Efg

d d

constructors ok E C longcon longcon cn

d

E longcon cn and E longcon cn and

d d

C longcon and C longcon

and

longexcon longexcon en

E longexcon en and

d

E longexcon en and

d

C longexcon and C longexcon

env of str strnameE E

s s

of state mem es cs mem mem

Table PrimitiveFunctions for val has typ e

the basic relations and functions used bythevaltyp e relations The functions prex and

b o dy are dened so that if then b o dy and prex Table shows

the rules that dene the valuehastyp e relation Table shows the rules that dene the

other valtyp e relations those stating when an ExVal ConVal record and closure havea

given typ e

First we consider the base cases in the denition the simple noncomp ound values

Sp ecial values integers and strings and HOLSMLs basic values basic op erators suchas

plus can only have one typ e and so must b e that typ e Since in this case contains

no typ e variables for any substitution S S so the typ e variables in tv can b e

substituted for

The assignment op erator can haveany that is an instantiation of ref unit

Nowwehave to determine whether the typ e variables in tv can b e substituted for Let S

be any substitution with domain tvWehave to determine if the assignment op erator can

havetyp e S Now if is an instantiation of ref unit then there exists a

such that ref unit Then

ref unit S S

thus the assignment op erator has typ e S An example will help explain this Saywe

wanttoshow that the assignment op erator has typ e ref unit and can

b e substituted for The substitution the used ab ove that eects the instantiation of

the typ e scheme for assignment to this typ e is LetS be any substitution with

domain f g Then S for some typ e Then we need to show that the assignment

op erator has typ e

ref unit ref unit

The substitution shows this is the case

For addresses we lo ok up the address in the store typ e to nd the typ e it must have

and this must b e the same as Since the range of the store typ e consists of simple typ es

an address can only have one typ e and so none of its typ e variables if there are any can

b e substituted for Thus it must b e the case that there is no intersection b etween tv and

the typ e variables in

In order to dene the exvalhastyp e relation weneedtoknowwhattyp e an exception

name can have To nd whether an exception name has a typ e we need to makeuseof

b oth the dynamic environment and the context First we lo ok in the dynamic environment

to nd a longExCon longexcon such that E longexcon is the exception name Then we

get the typ e scheme by lo oking up the longExCon in the context In a prop er context this

typ e scheme will b e a simple typ enone of the typ e variables will b e quantied overso

yp e As with addresses we cannot substitute for any of the variables in must b e this t

this typ e so wecheck that none of the variables in tv are in the typ e

In order to dene the convalhastyp e relation weneedtoknowwhattyp e a construc

tor name can have In HOLSML wekeep information on constructors in the dynamic

environment see page If a dynamic environment E and context C agree with each

C E ST j tv ref unit

d v

basval typ e b

C E ST j b tv

d v

C E ST j conval tv

d c

C E ST j conval tv

d v

C E ST j exval tv

d e

C E ST j exval tv

d v

C E ST j r tv

d r

C E ST j r in Typ e tv in Val

d v

T

STa tv tyvars

C E ST j a tv ref

d v

ST j closure tv

f

C E ST j closure tv

d v

Table Rules for j

v

other for every longCon longcon C longcon returns its typ e scheme and E longconre

turns the constructor name Because of this the case for constructor names is similar to

that for exception names except that wemust takeinto consideration the fact that the

typ e schemes are not simple typ es First we lo ok in the dynamic environment to nd a

longCon longcon such that E longcon is the constructor name Then we lo ok up that

longCon in the context to get the typ e scheme Tocheck that a constructor name has typ e

wecheck that is an instantiation of the typ e scheme

If the constructor name has typ e then wemust check that the typ e variables in

tv can b e substituted for If there are free unquantied variables in the typ e scheme

then as with exception names those variables cannot b e substituted for If there are

no free variables then as with the assignment op erator the substitution that eects the

instantiation of the typ e sc heme to can b e mo died so that it eects an instantiation to

S where S is any substitution with domain tv As discussed in Section A page

typ e schemes that are returned by lo oking up a longCon are the results of the original

declaration of the constructor and wehave proved this these typ e schemes havenofree

variables Thus any of the typ e variables can b e substituted for

The case for closures needed for the closurehastyp e relation is complicated A clo

sure written match E VE consists of a match phrase match a dynamic environment

d d d d

E and a dynamic variable environment VE E is the environment at the time the func

d d d

tion expression containing the matchwas evaluated The match phrase is a phrase in the

syntax of the dynamic semantics that is in the reduced syntax The match match may

d

b e part of a mutually recursive collection of functions If it is the variable environment

VE gives declarations of any recursive functions that are referred to in the match If the

d

match is not part of a mutually recursive collection of functions VE is empty

d

E VE tvIfVE is empty Thus there are two cases for checking ST j match

d d d f d

then we need that there exists a context C and a match in the unreduced syntax match

such that E agrees with C match is the reduced version of match C match and

d d

none of the typ e variables in tv are free in C The idea b ehind this denition is that C is

the context in which the match was elab orated We need the fact that none of the typ e

variables in tv are free in C since the elab oration of the matchmayhave dep ended on the

typ e of these free variables For the same reason typ e variables that are free in C are not

generalized in the use of Clos in Rule

If VE is not empty then the variables in the domain of VE may app ear in match

d d d

and hence in match so weneedtocheck the typ e of match in a context in which these

variables are given typ es Thus in addition to match and C we need that there exists a

static variable environment VE with the same domain as VE thatgives the typ es for the

s d

mutually recursive functions and wecheckthetyp e of match against the context C VE

s

In addition wemust check that the closures in the range of VE have the typ e scheme

d

given them in VE

s

The comp ound values are comp ound exception values a form of ExVal shown in

the dynamic semantic ob jects in Figure in the Denition as ExName Val comp ound

constructor values a form of ConVal shown in Section A of this pap er as ConNameVal

and records A comp ound exception matches a typ e if the exception name has typ e

and the value with whichitispairedhastyp e A comp ound constructor value

matchesatyp e if the constructor name has typ e and the value with whichitis

paired has typ e In b oth cases wecheck that the typ e variables in tv can b e substituted

conname typ e CE cn

d

C E ST j cn tv

d c

conname typ e CE cn C E ST j v tv

d d v

C E ST j cnv tv

d c

exname typ e CE tv en

d

C E ST j en tv

d e

exname typ e CE tv en C E ST j v tv

d d v

C E ST j env tv

d e

Dom r Dom l Dom rCE ST j r l tvl

d v

C E ST j r tv

d r

reduce match match ST j E C

d

T

tyvars C C match tv free

ST j match E fg tv

f d

VE fg SM mk var SM VE

d

closure VE C VE SM VE VE reduce match match

s d s d

T

tyvars C ST j E C C VE SM match tv free

s

ST j match E VE tv

f d d

C E ST j v

d v

C E ST j v

d vp

C E ST j p

d vp

Table Rules for j j j j j

c e r f vp

ST j E E constructors ok E tynamesE

d s d s

ST j E tynamesE

d s

C E ST j SE SE C E ST j VE VE

d d s d d s

C E ST jSE VE EE SE TE VE EE SM

d d d d s s s s s

Dom VE DomVE Dom VE DomSM

d s s

i Dom VE SMi v stat

d

C E ST j VE i prexVE i b o dy VE i

d v d s s

C E ST j VE VE SM

d d s

Dom SE DomSE

d s

i Dom SE CE ST j SE ienv of str SE i

d d d s

C E ST j SE SE

d d s

mem mem of state s Dom mem DomST

a Dom memCE j memaSTa

d

C E j s ST

d

Table Rules for Environments and Store Typ es

for Forapropercontext if C longexcon is a function typ e the range typ e can only b e

exn so for a prop er context will b e exn

For record values wecheck that the lab els in the record are the same as the lab els in the

record typ e and that the value asso ciated with a lab el in the record has the typ e asso ciated

with it in the record typ e In Table the valuehastyp e relation is universally quantied

in a hyp othesis of the rule This is not a p ermissible form for a rule in our mutually recursive

relations package Thus the rule as written is not how it is actually enco ded Both record

values and record typ es are enco ded as nite maps which are actually lists of pairs with

eachpairhaving a lab el and a value for record values or typ e for record typ es The

lab els are sorted so we use an auxiliary relation that steps through the lists checking at

each step that the lab els are the same and that the value in the record has the typ e in the

record typ e The same trick is used for structure environments and variable environments

Other semantic ob jects that can b e returned as the result of an evaluation suchas

FAIL or packets can haveanytyp e Thus we dene yet another relation j withthe

vp

rules shown in Table

To dene ST j E C stating that dynamic environment E agrees with static

d d

context C we need twomutually recursive denitions E C ST j SE SE stating

d s

that a dynamic structure environment agrees with a static structure environment and

ST j E E saying that a dynamic environment agrees with a static environment

d s

The relation E C ST j SE SE is dened similarly to that for dynamic and static

d s

variable environments that is the domains must b e the same and for each structure id i

in the domain the dynamic environment asso ciated with i in SE must match the static

d

environmentin SE The relation ST j E E is satised if the dynamic and static

s d s

structure environments agree and the dynamic and static variable environments agree

Finally ST j E C if ST j E E whereE is the environment comp onentof

d d s s

the context and constructors ok is satised The predicate constructors ok is dened in

Table It checks that if a constructor or exception name is in the dynamic environment

in two dierent places represented bytwo dierent longCons or longExCons then the

ok is satised typ e schemes at these places in the context are identical If constructors

the denition of conname typ e do es not dep end on which longCon or longExCon is used

The rules for these relations are given in Table

With all these denitions b ehind us stating when a state matches a store typ e is easy

It is shown in Table

The Typ e Preservation Theorem

As shown in the previous section we need to use store typ es in order to state the typ e

preservation theorem Using Toftes terminologywe will refer to the pairing of a state and

a store typ e where the memory in the state and the store typ e have the same domain as a

typ ed store and will write this as s ST for a state s and store typ e STA typ ed store suc

ceeds another written s ST v s ST if s mem ens cnsand s mem ens cns

and and ens ens and cns cns and Dom mem Dom mem and ST ST

mem mem

Nowwe are prepared to formally state the typ e preservation theorem

Theorem Typ e Preservation Say the fol lowing hold

C E j s ST ST j E C

C exp s E reduce exp vp s



The inclusion on maps is meant to b e inclusion of the sets of pairs a STa or a mem a in the

graph of the map For example ST  ST means that the domain of ST is included in the domain of ST

and for each a in the domain of ST STaST a

Then there exists a store typing ST such that C E j s ST and

s ST v s ST and C E ST j vp

vp

Note that the theorem ab ove states the typ e preservation prop erty only for expressions

A similar prop ertywas formulated for each of the phrase classes and then we set ab out

trying to prove the theorems The pro of of these theorems pro ceeds by induction over the

elab oration rules We succeeded in proving typ e preservation for the phrase class groups

including the exceptions constructor bindings datatyp e bindings and pattern phrases In

short we proved the prop erty for all groups of phrases except for the group including the

expressions and declarations

The problem with proving the theorem for expressions is that substitutions must b e

dealt with Substitutions come into play for example in the case for variables Since

C longvar then byinversion of Rule C longvar and For evaluation if

the result is a packet it can havean ytyp e so the interesting case is that for a result that

is a value The reduced syntaxforavariable is just that variable and s E longvar v s

implies byinversion of Rule that E longvar v Say Since ST j E C

we know again byinversion of the dening rules that C E ST j v We need

v

to show that C E ST j v Since we end up showing that our

v

denition of C E ST j v tv prop erly captures the notion that the typ e variables in

v

tv can b e substituted for

eisSay C E ST j v tv The general statement of the theorem we need to prov

v

and S is a substitution with domain tvWeneedtoprove that C E ST j v S

v

This must b e proved by induction over the rules that dene the valtyp e relations The

most dicult case in this pro of is for closures Recall that a closure contains a match

phrase and in order for it to haveagiven typ e while tv can b e substituted for there must

T

b e a context C such that tv free tyvars C and C match In order to prove

that the closure has typ e S weneedtoshow that C match S

Thus we need a theorem that wecall typechecking under substitution This corresp onds

to Lemma in Tofte The ab ove paragraph describ es roughly what needs to b e

proved The details are as follows Saythatwehave closure value match E fg and we

d d

have that C E ST j v tvByinversion of the rst rule for closures in Table we

v



Wehave written whichisavector of typ e variables in a p osition that needs a set of typ e variables

In our HOL enco ding wehave to explicitly convert this to a set

have

match C

reduce match match and ST j E C and

d d

T

tyvars C C match and tv free

In order to prove C E ST j v S we need to show that

v

match C

reduce match match and ST j E C and

d d

C match S

Since wearegiven Equation wedonotgettocho ose the value for variables match and

C they are given to us We will refer to these values by the variable names So wecan

assume

reduce match match and ST j E C

d d

T

C match and tv free tyvars C

Wemust prove Equation so we get to cho ose the witness for the existential quantiers

We will cho ose C to b e the same context as in Equation that is C Wewould liketo

cho ose match to b e the same as match but this will not work Say match is the indentity

function with a typ e constraint fn xa x According to the typing rules this can only

elab orate to one typ e This is b ecause according to Rule a typ ed pattern the

formal argument xa can only have the typ e that is explicitly given whichisThus in

order to elab orate to a typ e for some typ e wemust change the match phrase

tags The easiest way to do this is to remove the typ e tags from the phrases Let strip

b e a function that do es this We let strip tags match b e the value for match Then

Equation b ecomes

tags match match and reduce strip

d

ST j E C and C strip tags match S

d



Note that a is used in the syntax while weuse to mean the same typ e variable in semantic ob jects

This is standard usage for SMLlike languages



We could try to substitute the typ e variables in the syntax with syntactic representations of the typ es

in the range of the substitution but this will not work In order to haveasyntactic representation of a

typ e we need that for eachtyp e name in the typ e the context has a typ e constructor that maps to that

typ e name see Rule There mayhave b een new datatyp es declared since the match was typ echecked

and the typ e names asso ciated with those declarations would not b e in the context C



tags must do something a bit dierent with exception declarations If we strip the The function strip

typ e tag from an exception declaration this means that the exception do es not carry a valuesee Rules

a and bThus instead of stripping o the typ e tag we replace the typ e in the typ e tag with a new

syntactic typ e genericty which can haveanytyp e see Rule

The rst conjunct reduce strip tags match match is easy to prove since reduce match

d

match and reduce removes typ e tags anywayWehave the second conjunct ST j E C

d d

already from Equation

We are left to prove C strip tags match S assuming that C match and

T

tv free tyvars C We call this theorem typechecking under substitution and it was the

largest and most complicated theorem weproved ab out HOLSML It is not surprising that

proving this theorem and all the lemmas it entailed should b e so complicated Substitution

has caused problems in mathematical logic from the b eginning One of Godels main

complaints ab out Russells Principia Mathematica is the lack of formality in the syntax

that in particular he did not prove needed substitution theorems see Godel

After completing the pro of of typ echecking under substitution wedidnotgoonto

try to nish the pro of of typ e substitution for the class of phrases containing expressions

During the course of proving these theorems we found some examples of expressions for

whichtyp e preservation do es not hold These are discussed in Section

Substitution

We use some slightly nonstandard notation here and as proving prop erties of substitutions

played such a large part in this pro ject we will explain it here For the purp oses of this

thesis substitutions are maps from typ e variables to typ es Occasionally we will use a

substitution that maps typ e variables to typ e variables it is to b e understo o d as a map to

typ es that are just typ e variables

Substitutions arise in the instantiation of typ e schemes We show explicitly the domain

and range of the substitution using the following notation pronounced for

means that is in the domain of the map and is the value of the map at that vari

able Simultaneous substitutions involving substitutions that have disjoint domains are

represented by splicing the substitutions together with commas as in If

is a collection of typ es and is a collection of typ e variables then the

n n

substitution is short for

n n

A substitution S applied to a typ e is written S Some examples will help explain

the concept

listintint list

listint list

list int int list

listint int list

Atyp e scheme is instantiated to a typ e with a substitution Let be a

collection of typ es the same length as If then wewrite and say

instantiates or is a generalization of Wesay that the substitution

eects the instantiation of to An example of instantiation is that list

list The substitution that eects the instantiation is int int

The typ e variables in are said to b e bound in and is said to b e the prex of

the typ e scheme while is said to b e the bodyWe often say that the typ e variables in

have b een generalized or quantied to make Typ e variables app earing in and not in

are said to b e free in

Twotyp e schemes and are alphaequivalent if there is some

rearrangement of the prex of suc h that Note that this means that

and must have the same length typ e schemes here are not allowed to havetyp e

variables in the prex that are not in the b o dy see the fo otnote on page The easy

way to think of alphaequivalen ce is to think of the variables in the prex as having b een

renamedthere is a one to one corresp ondence of the variables such that replacing one set

with the other in the b o dy of one typ e scheme results in the b o dy of the other and these

corresp onding variables must b e the contents of the prexes For example is

alphaequivalentto but is not alphaequivalentto

Alphaconversion involves picking new names for the b ound variables and applying

the transformation to a typ e scheme the new names must b e dierent from the free

variables in the typ e scheme resulting in a typ e scheme that is alphaequivalent to the

rst Typ e schemes are often considered equal up to alphaconversion that is an equal

sign may app ear b etween twot yp e schemes if they are not exactly the same but are alpha

equivalent We do not adopt this notion here when wewant to allowtyp e schemes to b e

alphaequivalenttoeach other we will state so

Twovariable environments VE and VE are alphaequivalent if they have the same

domain and for each identier i in the domain VE i is alphaequivalenttoVE i Sim

ilarlytwo structure environments SE and SE are alphaequivalent if they have the same

domain and for each s in the domain if SE sm E andSE s m E then

Twoenvironments SE TE VE EE SM m m and E is alphaequivalenttoE

and SE TE VE EE SM are alphaequivalent if SE is alphaequivalenttoSE

TE TE VE is alphaequivalent to VE EE EE andSM SM

We will need to substitute in typ e schemes Substituting in the presence of b ound

variables can b e complicated Two things can go wrong if we ignore the b ound variables

and just substitute on the b o dyWe could end up substituting for the b ound variables

An example of this is listint listint int list where

wehave clearly indicated what do es not happ en with a sign Another problem is that

avariable in the range of the substitution could b e captured An example of this is

list list list

In order to p erform a substitution S on typ e scheme correctly rst we alpha

convert the typ e scheme to where are chosen to b e dierent from the domain

and the typ e variables in the range of the substitution and from the free typ e variables

in Then we just p erform the substitution on the b o dy of the typ e scheme Thus

is alpha S S S For example

equivalentto and list list The function that

p erforms substitutions on typ e schemes cho oses new variable names deterministically based

on the original names and the domain and range of the substitution so if is the renaming

chosen for the equalityabove is in fact real equality not alphaequivalenc e

Typ echecking under Substitution

In addition to b eing an imp ortant lemma needed in an eventual pro of of typ e preservation

typ echecking under substitution is an imp ortant theorem in itself It demonstrates that

the SML formulation of p olymorphism makes sense it shows that the typ e variables that

are quantied by the Clos op eration in Rule can indeed b e generalized It accomplishes

this byshowing that the phrase can elab orate to anytyp e that is the result of applying a

substitution whose domain is those variables

The formal statement of the theorem is

Theorem Typ echecking under Substitution for Match Say C match

T

tyvarsC C strip tags match Then for any substitution S such that Dom S free

S

Note that the statement of the theorem ab oveisforMatch phrases As the theorem

must b e proved by induction over the typing rules whichinvolve all the phrases in the

grammar similar prop erties must b e dened for all phrases Declarations result in en

vironments These environments mighthavefreetyp e variables as in the result of the

declaration in the let in the phrase

val f fn x let val y x x in y y end

Thus we need to p erform substitution on the environments that result from elab orating

declarations This will lead to the complications mentioned in Section including alpha

conversion and renaming in order to avoid capture of free typ e variables Since lo cal and

let statements add environments into contexts wewillhave to do substitution on contexts

Thus in order to do the induction we will need to prove a stronger theorem we phrase it

for expressions this time

Theorem Typ echecking under Substitution Say C exp Thenforany

tags exp S substitution S C S strip

The pro of of most of the cases for this theorem were relatively straightforward if tedious

to prove Many lemmas had to b e proved For example consider the case for a variable

longvarWehave that C longvar and wewanttoshow that C S longvar S

since strip tags has no eect on a variable From the former statementwe conclude that

there exists a such that C longvar and Toprove the latter statement

we need that there exists a such that C S longvar and S Welet

equal S and then wemust provetwo lemmas showing that C S longvar S and

S S The pro of of the rst lemma is straightforward The second lemma is not

easy to prove It involves reasoning ab out renaming of b ound typ e variables exchanging

the order of substitutions and substituting in substitutions

The complicated case is Rule for value declarations It is not surprising that this

is the hard case since it is where typ e schemes are created It is also where Tofte had the

most diculty in pro ving his Lemma the equivalent theorem for his language

We are given that

C val valbind VE in Env SM

and must showthat

tags val valbind VE S inEnv SM C S strip

By the inversion of Rule applied to we get that C valbind VE SM and

equiv Clos VEVE In order to show Equation we need to show that alpha

Cvalbind

there exists a variable environment VE such that C S valbind VE SM and that

VE VE S where valbind is strip alpha equiv Clos tags valbind

C S valbind

The task then is to cho ose VE so that its closure with resp ect to valbind and C S

is alphaequivalent to VE S It would b e convenientifwe could set VE to VES But

this will not work One problem is that we could substitute for typ e variables that should

b e generalized An example will illustrate the problem Say VEi int for some

identier i VE i is in the domain of S andS Say is not free in C

so it will b e generalized when int is closed with resp ect to valbind and C Thus

will b e alphaequivalentto int Since there are no free typ e variables in this S

will also b e intHowever VES i intS int Unless happ ens

to b e another typ e variable that is not free in C S the closure of this with resp ect to

valbind and C S will not b e alphaequivalentto int The problem here was that

we substituted for a typ e variable that will b e generalized in the closure

Another thing that could go wrong is that clashes b etween the variables that should

b e generalized and the variables in the range of the substitution can prevent can prevent

the variables from b eing generalized Now say VEi that S list that

is not free in C but is free in C Again let VE i This time is alphaequiv alent

to Thus S list However S list Furthermore

when this is closed with resp ect to C S will not b e generalized the o ccurring free in

C will b e substituted for leaving free in C S This is a problem since listis

certainly not equivalentto list

The ab ovetwo paragraphs demonstrate whywe cannot set VE equal to VES What

we need to do is rename the variables in VE that will b e generalized so they do not conict

with the domain or range of the substitution nor with the free variables in the context

or the variables in the typ es in the range of VEWe also need to deal with the eect

ariables in the closure of the typ e There is another of the substitution S on the free v

complication as well if the expression that gives a typ e to an identier is expansive see

page then no typ e variables will b e generalized For such identiers then wedonot

havetoworry ab out renaming or ab out whichtyp e variables will b e free in the resulting

substituted typ e scheme and we can just apply the substitution to the typ e Thus we will

dene a function subs right vars such that the closure of subs right vars VE with resp ect



Note that we explicitly include alphaequival ence in Rule The Denition assumes that all typ e

schemes are equal up to alphaconversion but we found that this is the only place where alphaequivale nce

is needed This is explained on page

to valbind and C S is alphaequivalenttoVE S The function will take more arguments

than just VE but we will see exactly what arguments are needed as wedescribeit

Let us take a rst cut at determining howtodenesubs right vars Given an identier

i what should b e done with the typ e call it asso ciated with it in VE If the expression

right vars VEi should b e just giving a typ e to the identier is expansive then subs

VEiS since none of its typ e variables will b e generalized Note that in order to

determine whether or not the expression is expansive we need to include valbind as an

argument to subs right vars Also it is clear that S must b e an argumentaswell

If the expression is not expansive then wemust rename the typ e variables that will

b e b ound in order to avoid clashes with the substitution First we nd the typ e variables

that will b e generalized These are the typ e variables in the typ e that are not free in C

call them Then VE iis Wecho ose new typ e variables that are dierentfrom

all the typ e variables in the domain and range of S and the free typ e variables in C

Call these new typ e variables

We need to avoid substituting for the variables that will b e generalized Let S be

S with the typ e variables removed from the domain To b e precise let DS Dom S

Then S S j thatisS restricted to the typ e variables not in The result of this

DS 

restriction is that will not b e substituted for

Then subs right vars should for return S that is wesimultaneously rename

the typ e variables that would b e generalized and substitute for the typ e variables that

would not b e generalized Now let us see why this works We claim that when this typ e

is closed with resp ect to valbind and C S the typ e variables that are generalized are

First are among the typ e variables that are generalized since they are in S

and are not free in C S they were chosen to b e not free in C and they are not in the

range of S Furthermore they are the only suchtyp e variables Let us takeaninventory

of the variables in S Wehave already accounted for There are the variables

that were in that were unaected by the substitutions they are not among the and

ariables will not b e generalized b ecause they will also are not in the domain of S These v

b e free in C S they are not among the b ecause they are free in C Then there are

the typ e variables in the range of S Ifatyp e variable in the range of S shows up in

Note that stripping the typ e tags from an expression do es not change whether or not it is expansive

see the denition of expansive Thus whether or not the expression is lo oked up in valbind or valbind do es

not matter

Thus we see that one argument to subs right vars must b e C or at least the free typ e variables in C

S this is b ecause there was a typ e variable that was in and was free in C

and S contained But since was free in C the substitution will substitute for in

C so is free in C S so will not b e generalized Thus are typ e variables that are

generalized

Thus the closure of S with resp ect to valbind and C S will b e S

We need that this typ escheme is alphaequivalenttoVE S i which is alphaequivalent

S acts only on the variables free in That is it do es not substitute to S Here

for and so its eect is that of S whichisS with removed from the domain In addition

the typ e variables mayhave to b e renamed in order to avoid clashes with the substitution

This exactly what wehave done to get S and so this is the correct value of

subs right vars if is nonexpansive

Wehave shown that S willwork that is when it is generalized with resp ect

to valbind and C S it will b e alphaequivalenttoVE i But there is something else

to b e shown namely that C S valbind VE SM The problem with the description

ab ove is that new names for the b ound variables are chosen indep endently for eachtyp e

in VE Consider the following program

let val x as y fn z z in x end

In the elab oration against the initial context of the value binding in the let statement the

resulting variable environmentisfx y g for some The typ e variable

would b e generalized since it is not free in the context In order to provetyp echecking

under substitution here wewould ha vetorename to avoid clashes with the substitution

However in the denition of subs right vars ab ove nothing constrains to b e replaced by

the same typ e variable in the twotyp es in the range of the variable environment the new

typ e variables are chosen indep endentl y for eachtyp e Say that two dierentvariables

and are chosen Wewould like to show that

C S x as y fn z z fx y g SM

where SM fx v staty v statg but according to Rule for elab orating layered

patterns x and y must have the same typ e so the elab oration fails

Thus the renaming must b e done uniformly over the variable environment Let be

all the variables that could b e generalized that is the typ e variables in the range of VE

minus the free typ e variables in C LetS be S with the typ e variables removed from

the domain That is let DS DomS and S S j Let b e the renaming that

DS 



is new typ e variables that are not in the domain or range of S in the typ es in the range

right vars returns for each in the of VE nor free in C Let S S Then subs

range of VE S if the expression is expansive or S if the expression is nonexpansive

The same reasoning as ab ove shows that the closure of S with resp ect to valbind and

C S is alphaequivalenttoS applied to the closure of with resp ect to valbind and C

the extra variables in the domain of the substitution do not interfere with the eect of the

right vars are the free typ e variables in C substitution The arguments needed by subs

the typ e variables in VE valbind and of course VE

The complicated pro cess describ ed ab oveiswhywe need alphaequivalen ce in Rule

In the pro cess of proving typ echecking under substitution when we p erform a substitution

on VE the b ound typ e variables may b e renamed dierently for dierenttyp e schemes

VE VE S where the is exact equality not If wewere to show that Clos

C S valbind

equality up to alphaconversion then VE would havetocontain those renamed variables

However as wesaw in the program ab ove Equation the renaming of variables that

will b e b ound must b e done uniformly in order to ensure that C S valbind VE SM

Hence the need for alphaequivalence in Rule

The only remaining detail in the pro of for this case is by what mechanism do we pro ve

that C S valbind subs right vars SV V valbind VE SM where V is the set of typ e

C V C

variables free in the context and V is the set of typ e variables in variable environment

V

We proveitby induction along with the main substitution prop erty it is another fact to

prove for value bindings There is a complication here The value binding that weare

elab orating may b e just a part of the entire value binding see Rule and thus the

statement of this prop ertymust take account of the fact that there are twovalue bindings

b eing discussed one of which the one that is b eing elab orated is a part of the other

which is used to determine whether or not an expression is expansive and is the source of

V The formal statement for this prop ertyis

V

C VE valbind valbind SM SV

V

valbind valbind C valbind VE SM prop er

in varenv VE V subvalbind valbind valbind tyvars

V

tags valbind C S strip

right vars S free tyvars C V valbind VE SM subs

V

valbind checks that all the syntactic restrictions in Section of the The predicate prop er

Denition hold of the value binding and subvalbind valbind valbind checks that valbind is

a subpart of valbind

We will summarize briey the cases for proving this prop erty The case for Rule is

that if we are given

C pat exp hand valbindi VE hVE i SM hSM i

and all the other hyp otheses of Equation wemust show

C S strip tags pat exp hand valbindi

VE hVE i SM hSM i

right vars S free tyvars C V valbind VE and where we use the shorthand VE subs

V

VE subs right vars S free tyvars C V valbind VE

V

The induction hyp othesis applied to valbind takes care of the p ossible and valbindin

the phrase If exp is expansive then VE is just VES b ecause subs right vars will nd

that exp is the expression asso ciated with the variables in the pattern and so will cho ose the

same substitution for all typ es in the range of the variable environment The theorem for

tags pat VES SMS typ echecking under substitution of patterns gives C S strip

and the induction hyp othesis for typ echecking under substitution for expressions gives

C S strip tags exp S so we are done Note that we need that the value binding is

prop er in order for this to b e the caseif the value binding were allowed to bind variables

more than once exp might not b e the unique expression giving a typ e and value to the

variables in pat

If exp is not expansive then VE VES where S is a substitution that renames the

typ e variables that will b e b ound and substitutes for the other typ e variables in the domain

of S as describ ed ab ove Then by the theorem for typ echecking under substitution of pat

terns wegetC S strip tags pat VES SMS and by the induction hyp othesis

tags exp S for typ echecking under substitution for expressions wegetC S strip

Now C S is alphaequivalenttoC S it is not equal since dierentvariables mayhave

b een chosen for the renaming of b ound typ e variables Thus we needed to prove addi

tional lemmas stating that for expressions and patterns the results of elab oration are

the same in contexts that are alphaequivalenttoeach other Then we can conclude that

tags pat VES SMS and C S strip tags exp S and this C S strip

combined with the induction hyp othesis applied to the smaller value binding proves this

case

C atexp C atexp

S

prop er atexp atexp prop er context C prop er subs S

C S strip tags atexp S

Cexprow C exprow

S

exprow exprow prop er context C prop er subs S prop er

C S strip tags exprow S

Cexp C exp

S

prop er exp exp prop er context C prop er subs S

C S strip tags exp S

C match C match

S

prop er match match prop er context C prop er subs S

C S strip tags match S

C mrule C mrule

S

mrule mrule prop er context C prop er subs S prop er

C S strip tags mrule S

CdecEtnsC dec E tns

S

prop er dec dec prop er context C prop er subs S

C S strip tags dec E S tns

C valbind VE SMC valbind VE SM

valbind valbind prop er context C prop er

S prop er subs S

C S strip tags dec VES SM

S valbind V prop er subs S prop er valbind valbind

V

in varenv VE V subvalbind valbind valbind tyvars

V

tags valbind C S strip

subs right vars S free tyvars C V valbind VE SM

V

Table Full StatementofTyp echecking Under Substitution

The case for Rule is simpler Since each expression in a recursivevalue bind

ing must b e a function expression which is nonexpansive the resulting variable en

right vars is VES where S is as ab ove the substitu vironment returned by subs

tion that renames b ound variables and substitutes free variables Thus by the inductive

hyp othesis for typ echecking under substitution applied to value bindings we get that

C S strip tags valbind VES SM and as b efore since C S is alphaequivalentto

C S we get that C S strip tags valbind VES SM

Finally note the presence of prop er valbind in the prop erty in Equation In order

for us to use this prop ertytoprove the case for Rule for the pro of of the main theorem

for typ echecking under substitution weneedtoknow that the value binding is prop er

Because the pro of is by induction over the terms wethus need to know that all the phrases

are prop er This fact must b e added to the hyp otheses of Theorem

In order to clarify exactly what weproved we state in full the theorem for typ echecking

under substitution including the cases for all the phrases in the class with expressions

and the extra clause for value bindings stating that value bindings can elab orate to the

variable environment mo died by subs right vars This is given in Table In this

subs checks that all the typ es in the range of the substitution are prop er table prop er

typ es Keep in mind that this is not all weneededtoprove we needed to prove related

prop erties for all the phrase classes as well as multitudes of substitution lemmas

Problems with the Formulation

The rst problem is p ointed out by Stefan Kahrs in Kahrs Consider the program

let datatype ACofboolintin

fn C x x true

end

let datatype BCofintin

C

end

In this program the returned value of the rst let statement is a function which is applied

to the return value of the second let statement According to the semantics for HOLSML

given in Section A and also according to the semantics for Core SML in the Denition

this can elab orate with the typ e name given to typ e A b eing the same as that given to

B In the semantics given in the Denition evaluation will result in a runtime typ e error

since the constructor C for A will b e considered the same as the constructor C for BIn

the semantics for HOLSML given in Section A the evaluation will result in the packet

Match since the two constructors will b e given dierent constructor names Thus this

problem do es not break typ e soundness since no runtime typ e error o ccurs It do es not

even interfere with typ e preservation as describ ed in Section a packet can haveany

typ e However it do es something unintuitive the function in the rst let statementcovers

all the p ossibilitie s for typ e A so its application should not result in Match

The x for this problem describ ed in Kahrs is to include among the hyp otheses of

T

Rule the side condition tynames T where T is the set of typ e names generated

by the declaration in the let This ensures that lo cal typ e names do not escap e their

intended scop e This x was not included in the semantics presented here b ecause if it

were included in order to provetyp echecking under substitution wewould havetoprove

t yp echecking under renaming of lo cal typ e names This is b ecause these lo cal typ e names

mayhave b een reused in datatyp e denitions later and thus the range of the substitution

might contain these typ e names The new side condition prevents the substituted typ e of

the let expression from containing these typ e names Thus wewould have to prove that

dierenttyp e names could havebeenchosen as the lo cal typ e names and then the typ e

names in the range of the substitution would not clash with the lo cal typ e names Not

wanting to proveyet more theorems ab out substitution we did not include this x in our

semantics

The same motivation was the main reason we include a T eld in the elab oration of

declarations as describ ed in Section A If we adopt the use of as the Denition do es

then typ e names in the range of substitutions end up in the TyNameSet and then these

typ e names cannot b e used in lo cal typ e declarations they are considered to have b een

used already

There is a similar problem with Rule p ointed out in Kahrs The use of a

recursive function that takes a function as an argument can again result in a lo cal data

typ e escaping its exp ected scop e even though the typ e of the let expression using the lo cal

typ e declaration do es not contain lo cal typ e names The x suggested here is the use of

to prevent the use of typ e names in the arguments of the function as lo cal typ e names This

x was not included here for the same reason that the correction for Rule was omitted

it would require us to prove facts ab out the renaming of lo cal typ e names It is clear that

in order to provetyp e soundness for SML this pro of would have to b e made and the xes

for Rules and would have to b e included It is interesting to note that although the

more careful accounting of typ e names used bytheT parameter in declarations eliminates

the use of elsewhere in the semantics it seems that it would have to remain here

An alternative also mentioned in Kahrs to the suggestions ab oveistokeep track

of all typ e names generated not just the ones currently in use and to not try to reuse

lo cal typ e names This xes the problems with b oth Rules and as well as avoiding

problems in case there are any more rules with subtle problems like Rule A similar

approachistaken for example with addresses in the dynamic semantics This accounting

of typ e names is the approachtaken by all known implementations of SML It intro duces

a form of state into the static semantics thus complicating it However it prevents the

problems asso ciated with the escap e of supp osedly lo cal typ e names which is the ro ot

cause of the problems with Rules and

In Tofte Tofte suggests keeping the original way of dealing with typ e names that

is using to add all typ e names used to the context instead of keeping track of just those

typ e names generated by datatyp e declarations as we do for HOLSML To x Rule he

suggests adding side conditions tynames T of C which is also prop osed by Kahrs as

a p ossible solution For Rule the side condition prop osed is tynames VE T of C

The problem with this solution is that it complicates the pro of of typ echecking under

substitution bydisallowing the substituted typ e of a let statementtocontain new typ es

names One solution could b e to alter the denition of substituting a context such that the

typ e names in the range of the substitution are added to T of C This was the approach

we adopted at rst b efore we discovered that it would result in requiring a pro of of

substitutions under renaming of typ e names

A more serious problem in that a solution has not yet b een formulated is that con

structor and exception names are not adequately dealt with in the semantics presented

here or in the Denition Consider the following program

let exception hold int of int in hold int end

The result of executing this program call it P is an ExVal that is the pairing of an

exception name call it en with the integer Typ e preservation for this program states

that if C P exn and E P en and ST j E C then C E ST j en

d d d v

exnHowever since the exception declaration was a lo cal one there is no waytocheck

if the pairing of en with makes sense neither C nor E has any record of the exception

d

int or its exception name en The problem can also o ccur with constructor names hold

even if the problems with Rules and mentioned ab ove are resolved The x to Rule

prevents lo cal typ e names from o ccurring in the typ e of let declarations but constructor

names can escap e their lo cal bindings with the help of exceptions

let datatype foo D

exception myex of foo in

myex D

end

This problem do es not o ccur when exception or constructor names are used in functions

as in

let exception holdint of int in

fn x if x then x else raise holdint x

end

Here the closure will contain a dynamic environment giving a value for the exception

constructor and the denition of the valtyp e relation j ensures that there is a context

c

that agrees with the environment giving a typ e for the exception constructor

Another problem is that if an exception or value constructor is reused there remains no

record of the name of the rst use of the constructor in the dynamic semantics Consider

the following series of declarations

datatype foo A B

valxA

datatype foo A B

valyx

The last declaration for y is elab orated in an environment that includes the results of

the previous declarations Wewould liketoshow that evaluation and elab oration of the

last declaration results in static and dynamic environments such that the value of y in the

dynamic environmenthasthetyp e of y given in the static environment The typ e of y

is foo The value of y is a constructor name but that constructor name is not in the

environment in which the declaration is evaluatedit was present after the declaration of

typ e foo only as the value of constructor A but after the declaration of typ e fooit

was overwritten by the mapping of A to the new constructor name

A rst cut at trying to solve these problems mightbetohave the static semantics

generate constructor and exception names and thread environments containing information

on these names though the elab oration much as the state is threaded through the dynamic

semantics Then when wewanttoknow the typ e of an exception name or constructor

name we just lo ok up the name in the these environments The problem with this is

that lo cal declarations will only b e elab orated once while they maybeevaluated many

times Thus a straightforward generation of names would result in the names b eing chosen

diering b etween the static and dynamic semantics

Weleave the job of formulating a viable solution for future work

Chapter

Assessment

The work presented here demonstrates that it is p ossible to prove signicant prop erties

of programming languages given a denition that is b oth formal given in mathematical

terms and not to o complicated Belowwe discuss why the work describ ed here was useful

that is what it tells us ab out SML and programming languages in general and weight

the b enets and drawbacks of using a theorem prover namelyHOL

What HaveWe Learned Ab out SML

One maywonder whydowe b elieve that the pro ofs accomplished here are useful HOL

SML is dierent from that used in the Denition and is dierentfromany implementation

of SML What then do these pro ofs have to do with SML as in the Denition or as

implemented

The dierences b etween HOLSML and Core SML are discussed at length in App endix

A Some of the changes complicate the semantics while others are simplications None

of the changes are ma jor they preserve the key characterists of Core SML that is the

ability to dene new parameterized datatyp es and p olymorphic functions the use of pat

tern matching in functions functions as rstclass values and the presence of imp erative

features such as reference cells and exceptions

Some of the changes serve to bring the Denition closer to what is done by implemen

tations An example is the distinguishing of the ref constructor from other constructors

in the dynamic semantics whichwe accomplish here with constructor names

Other changes seem at rst glance to b e a departure not only from the Denition

but also from implementations An example of this is the use of the value restriction

in determining whichtyp e variables to generalize in creating p olymorphic typ es The

value restriction results in a simpler semantics than in the Denition while at least one

implementation Standard ML of New Jersey SMLNJ go es the other way SMLNJ

uses a metho d called weak typing which uses typ e variables with numb ers in them to

approximate howmany times a function can b e applied b efore a reference cell is generated

Wright in Wright shows that not only is the value restriction simple but it is also

useful in a study of a large b o dy of SML co de there are few instances of the use of value

in a way that takes advantage of applicativeimp erativetyp e variables muchlessweak

typing In even large programs a few tens of thousands of lines there were fewer than ten

instances of p olymorphic uses of expansive expressions There has b een talk of changing

SMLNJ to this simplied semantics

Furthermore Mads Tofte is working on a pro ject to dene a language called Simplied

SML Tofte which is a mo dication of SML that simplies the parts of the language

that cause the most problems b oth in the semantics and in implementations Mo dications

to the Core include the use of the value restriction inclusion of identier status in the

semantics a change we also made and clarication of the scop e of explicit typ e variables

We also eliminated equalitytyp es from the language We justify this b ecause it is

the single most complicated part of the denition of the Core The notions asso ciated

with equalitysuch as equality attributes and whether or not semantic ob jects admit or

resp ect equality are confusing and present great challenges for an automated theorem

prover Furthermore the system as presented in the Denition is undesirable for two

reasons First it is insucient in that it misses many legitimate application of equality

see GGM Second the resulting algorithm automatically dened for a datatyp e may

not b e what the user requires so she would b e b etter o writing her own Because of all

this we decided that preserving equalitytyp es in HOLSML was not worth the additional

complexity it presented

Thus although HOLSML is a departure from the semantics in the Denition future

versions of ML may lo ok more likemorelike HOLSML than the Denition One could

argue that future versions of ML should lo ok more like HOLSML in the sense that the

semantics should not contain features that are to o hard to describ e With the increasing

This was related to the author in conversation with Andrew App el



Toftes change regarding the scop e of explicit typ es variables is less drastic than our elimination of the

sp ecial rules but it also recognizes that these rules are confusing

imp ortance of verication of programs if one hop es to prove prop erties of a language and

programs written in a language the more complicated the semantics the easier it is for

a programmer to write subtly incorrect programs in the language and the harder it is to

implement and use verication to ols for the language

Another question ab out the validity of this work is that the pro ofs were accomplished

using an enco ding of the language into HOL The version of HOL we use HOL is written

in a version of SML Standard ML of New Jersey SMLNJ Thus it is conceivable that

a mistake in the Denition a prop ertythatwe exp ect to b e satised but do es not hold

of the language could result in a mistake in SMLNJ whichwould result in a mistakein

HOL whichwould lead to a mistake in the pro of of this prop ertyThus wewould havea

pro of of the prop erty when in fact the prop erty do es not hold of the language

There are several reasons why this apparent circularity is not a problem One is that

the chances that a problem in the Denition could work its way through an implementation

and a theorem prover and an enco ding of HOLSML into a false pro of of the prop ertyin

question without causing problems that would have b een caught somewhere along the way

is extremely unlikely The semantics of HOLSML is ultimately represented in SMLNJ

but a given asp ect of the semantics of HOLSML has no direct connection to corresp onding

asp ect of SMLNJ This is b ecause the semantics is enco ded in an abstract waythe

denitions for the grammar and semantic ob jects are the results of a mutually recursive

HOL typ e denition and the evaluation and elab oration relations are dened using a

mutually recursive relations denition package This mechanism is so dierent from how

the language is implemented in SMLNJ that the enco ding is largely indep endent of the

vior of SMLNJ sp ecic b eha

Another reason lies in the security of HOL As describ ed in Chapter HOL has a

simple core based on a few inference rules axioms and denitional principles HOL is set

up so that theorems can b e proved only from these basic pieces and other already proved

theorems Thus when traced back all theorems are based on this core This part of HOL

has b een co ded carefully and exercised a great deal It is exceptionally unlikely that a

mistake in SMLNJ could cause a mistake in HOL resulting in the pro of of theorems that

are not true for HOLSML or any other enco ded problem Mistakes in SMLNJ are far

more likely to result in core dumps

A nal reason why the fact that HOL is written in SMLNJ should not result in

incorrect theorems is that a bypro duct of a pro of with a goaldirected theorem prover like

HOL is a minute insp ection of every asp ect of the semantics involved in the pro of HOL

do es not go o and prove the theorem on its own coming back after a certain amountof

time with a pro of or dispro of It must b e lead carefully to a pro of Thus it is the user

who actually proves the theorem HOLs main task is to organize the pro of and prevent

mistakes and to automate some sp ecialpurp ose tasks such as dening typ es This

guidance by the user means that the user knows in detail howeach theorem is proved A

false theorem would app ear suspicious and would likely b e caughtby the user In fact this

close insp ection and contemplation of the problem resulting from the attempt to prove

facts ab out it is part of what makes verication with a theorem prover so useful for nding

errors

We will p oint out two instances where close insp ection of the rules broughttoour

attention details in the semantics requiring changes in the rules One is that although it is

p ointed out in Section of the Denition that typ e schemes will b e considered equal if

they are alphaequivalent we found only one place Rule where alphaequivalence is

needed this is describ ed on page Since our typ e schemes are enco ded as a list of typ e

variables and a typ e it is muchmoreconvenient to use HOLs equality which requires

that the prex contain the same typ e variables in the same order and that the b o dy

is the same rather than inserting many statements of alphaequivalence Thus we put

alphaequivalence explicitly in the rule only where it is needed and assume exact equality

elsewhere

Another dierence is in the enco ding of Rule As noted on page our enco ding

of semantic ob jects uses a theory of nite maps and we needed to ensure that the nite

maps are prop er that is their domains are sorted Thus wehave dened a collection

of predicates prop er object for eachsemantic ob ject object that constrain the structures

of the ob jects includin g that all nite maps are prop er Other constraints are included

as well such as for ConsTyp es that the number of typ es combined with a typ e name

matches the arityoftyp e name These prop erness constraints are present in almost every

theorem weproved ab out the evaluation and elab oration of HOLSML We proved that

if we start with prop er semantic ob jects contexts states environments then the results



The Denition also states that typ e schemes are equivalent if one can b e obtained from another by

deleting typ e variables from the prex that do not app ear in the b o dy However we noted that the

semantics only generates typ e schemes such that all variables in the prex o ccur in the b o dy and so we

included this in our denition for prop er typ e schemes



phrase for each HOLSML syntax phrase phrase that check Wehave also dened predicates prop er

that the phrases satisfy the syntactic restrictions in Section of the Denition

suchasvalues typ es and environments are also prop er ob jects For Rule we found

that due to the recursive nature of the rule elab orations resulting in improp er typ es could

result For example the elab oration of the declaration

val rec f fn x g x and g fn y f y

can result in a variable environment in which f and g are mapp ed to the typ e list where

the typ e name asso ciated with the list constructor has not b een given any arguments to

indicate what the typ e of the list items should b e

Thus in our enco ding we included in Rule a side condition stating that all the typ es

in the range of VE were prop er We did not include this side condition in the rule written

on page This was b ecause it was a result of the p eculiarities of our enco ding the

prop erties checked in the side condition are either inherent that the number of typ es in

aConsTyp e matches the arity of the typ e name or irrelevant that the lab els in a nite

map are sorted in the denition of Typ e in the Denition

Was HOL Useful

A prominent feature of this work was that it was accomplished with a theorem prover

HOL We did have a go o d idea of what would b e needed to prove the theorems b efore

starting the pro ofs with HOL We knew the general structure of the theorem that is

what forms of induction wewould use and what typ es of lemmas wewould need to prove

However we did not attempt to do any pro ofs on pap er b efore b eginning the pro ofs in

HOL Partly this was b ecause the task was so large that the idea of writing it all down

w as frightening There seemed to b e no use in simply selecting a few cases and proving

them something similar to this had b een done by others esp ecially in Tofte Partly

we needed the help of the HOLs goal directed theorem proving in order to see exactly

what needed to b e proved some of the rules were so complex that it was easier to let HOL

set up the induction to determine exactly what needed proving than to do it by hand

Part of the goal of this work was to determine if theorem provers are useful in proving

prop erties of large programming languages Thus a legitimate question to ask is was

HOL useful in this situation That is was it more of a hindrance or a help

Some background on the time this pro ject to ok will b e useful It to ok two months

to make the rst cut at the mutually recursivetyp es denition package to enco de the

syntax and semantic ob jects for the dynamic semantics and to enco de the evaluation

relations but not to create a general mutually recursive relations denition package

Then ab out one month was sp ent adding functionality to the typ es denition package and

creating a mutually recursive relations denition package Ab out three months was sp ent

proving inversion theorems and determinism for evaluation Less than one month was sp ent

enco ding the grammar semantic ob jects and rules for elab oration Ab out one year was

sp ent relating the static and dynamic semantics including dening the valtyp e relations

proving that evaluation and elab oration resulted in prop er semantic ob jects proving typ e

preservation for all phrase classes except for that including the expressions and proving

typ echecking under substitution

A great deal of time was sp ent on this pro ject We b elieve that without the help of

the theorem prover the task would not have b een accomplished at all Although there

are drawbacks in using HOL its abilitytocheck that denitions are sensible and used

consistently and the ability to mo dify pro of scripts to reprove theorems when denitions

havebeenchanged more than made up for the disadvantages its use imp osed

Wehave already mentioned page one of the drawbacks in using HOL it demands

complete pro ofs of all lemmas Some of these lemmas seemed to b e obviously true but

were annoyingly complicated to prove

as saywe are given a collection of typ e One of the most annoying obvious lemmas w

variables that are in a typ e Saywecho ose new names of the typ e variables Then it

should b e the case that which is the result of replacing the old typ e variables with

the new ones should contain all the variables in We needed to prove this to show that

the result of renaming the b ound variables of a prop er typ e scheme was another prop er

typ e scheme As mentioned in a fo otnote at the b ottom of page the typ e variables in

the prex of a prop er typ e scheme mustbecontained in the b o dy Proving this lemma was

mo derately involved since substitution is dened structurally and the subparts of do

not contain all the variables in Thus in doing the pro of by induction we had to restrict

the substitution to the typ e variables in the subparts prove that the result of substituting

the subparts with the restricted substitution was the same as the result of substituting

with the original substitution use the induction hyp othesis to conclude that the range of

the restricted substitutions was contained in the substituted subparts and then show that

the typ e variables in the substituted typ e which is the union of the typ e variables in the

substituted subparts is the same as the range of the original substitution

On the other hand this demand for detailed pro of can b e seen as an advantage of

HOL as well sometimes obvious lemmas turn out to b e false It was obvious that the

substitution S describ ed on page would suce as the denition of the eect of

subs right vars on a typ e asso ciated with a nonexpansive expression Of course we could

cho ose the new variables here dierently for eachtyp e in the variable environment

after all these are the variables that are going to b e generalized so there will b e no

connection b etween the typ e variables in the dierenttyp es However in doing the pro of

we discovered that typ e variables resulting from the elab oration of one pat exp pair must

b e renamed the same way as demonstrated by the program in Equation Thus the

fact that HOL forced us to thoroughly prove all facts prevented an incorrect denition of

right vars which mighthave resulted in an incorrect pro of subs

Another diculty with using HOL was that there were so many lemmas of all descrip

tions to b e proved that it was dicult to keep trackofwhich ones had and had not b een

proved Wegave long descriptive names to all theorems yet after a few months of steady

work it was imp ossible to rememb er the names of the theorems We resorted to using

emacs to search the les for the statements of the theorems Sometimes when welooked

for theorems using a slightly dierent phrasing than that used in the actual theorem we

did not nd them and we ended up proving a few theorems over again These theorems

were generally small usually little lemmas ab out sets and thus not much time was wasted

This problem is certainly not unique to goaldirected theorem provers It probably would

havebeenaneven worse problem for a pap er pro of Since with a more automated theorem

prover likeBoyerMo ore the pro of has to b e worked out in advance in order to lead the

prover to a solution there would b e just as much a problem there

The converse of this problem having two theorems with the same name o ccurred once

or twiceaswell when we neglected to check if a theorem with a certain name already

existed b efore giving that name to another theorem This was not to o hard to x as it

was easy to determine from the context which theorem was needed

The problems with keeping track of the names of the theorems seems to p oint to the

need for a b etter w ay of organizing pro ofs A great deal of attention has b een devoted to

structured programming that is how to organize a large program so that it can b e broken

down into indep endent steps that can b e accomplished on their own HOL theories help in

structuring the pro ofs since they gather together related denitions and proved theorems

but this is not useful for developing large pro ofs in one of the theories It seems that there

is more work to b e done in structuring large pro ofs

Another diculty with using HOL mentioned in Sections and was that b efore

we could enco de the semantics we had to create packages to allow us to automate de

nitions of mutually recursivetyp es and relations Even when these denitional packages

were up and running we could not enco de our denitions in the most straightforward way

The b est example of this is in Section where b ecause we could not universally quantify

over premises we had to include a set of typ e variables in the valtyp e relations in order to

check that these typ e variables could b e substituted for and as describ ed on page we

had to create auxiliary relations to check that semantic ob jects dened with nite maps

match up Thus our relations were not dened in the most intuitiveway however the

resulting relations had the same eect as the intuitiveversions

If wewere doing a pap er pro of we could dene our relations however wewanted

However using HOLs denitional packages has certain b enets even if do es force us to

make denitions in a dierentway One b enet is HOLs typ echecker It to ok several

iterations b efore we decided on nal denitions for the valtyp e relations and the HOL

typ es of the relations c hanged as we added more and more arguments As we revised the

denition the typ echecker p olitely informed us when we had neglected to up date a rule

to reect a new argument This forced us to consider carefully howeach new argument

should b e dealt with by each rule and thus resulted in a denition that was more likely to

b e correct than one written on pap er Another b enet of using HOLs denitions is the

automatic pro of of useful theorems like the induction and inversion theorems It is not

to o dicult to see from the rules dening the relations what these theorems should b e

but sometimes it can help a user to see them clearly stated

Another drawback to using HOL as mentioned in Section is that the pro of scripts

are unreadable They can however b e understo o d byreplaying them and thus the pro ofs

can b e describ ed in a clear fashion evidenced wehopeby the descriptions of pro ofs in

Sections and

One great b enet of HOL is that it allows one to keep track of exactly what conditions

are needed for a prop erty to hold For example on page wepoint out that we needed the

value binding to b e prop er that is to satisfy the syntactic restrictions of Section of the

Denition in order to prove that a value binding stripp ed of its typ e tags elab orates to

avariable binding mo died by subs right vars In order for this hyp othesis to b e available

to this smaller pro of which is proved along with typ echecking under substitution the

prop erness of the expressions must b e passed around as a condition in the theorem see

Table Thus it b ecame clear that a expression must satisfy the syntactic restrictions in

order for typ echecking under substitution to hold of it In writing such a pro of on pap er

it is easy to lose trackofassumptionswe had to make for pro ofs of lemmas to go through

By far the greatest advantage of using HOL was the abilitytochange denitions and

rapidly rerun pro ofs on the mo died denitions We started o with Core SML as mo died

by the simplest of Stefan Kahrs Kahrs Kahrs suggestions for xing the problems that

would have an eect on typ e preservation In the course of proving the theorems describ ed

here wewere constantly changing the denitions until we ended up with the semantics

describ ed here as HOLSML Eachchange had a denite purp ose For example status

maps were used in order to b e able to state prop erties ab out prop er contexts and to b e

able to use there prop erties to conclude facts ab out identiers lo oked up in the context

After each revision of the semantics we neededtogoback and reprove the theorems

relating to those denitions

With pap er pro ofs this would have b een a daunting task Wewould havehadto

examine closely each pro of to see if it used the denition and to determine exactly what

change if any the new denition made in the pro of Most likely only a sup ercial glance

would b e given to make sure that the theorem would still hold and many subtleties would

b e missed

Using HOL conrming that an old pro of still works for a new denition involves up

dating the statement of the theorem to accountforanychanges in the arguments to the

hecker helps with this and then rerunning the pro of script on the terms HOLs typ ec

statement of the theorem HOL will either rep ort that the pro of script works or it will

return an error If an error is returned tactics from the script can b e entered a piece at a

time until the error is reached and then the problem is apparent and can b e xed Usually

the xes are simple and if they are not simple it is b ecause the denition has changed

substantially enough that there is something signicant to b e proved

In our many episo des of doing these repro ofs we found that as exp ected lemmas

relating directly to the change to ok some time to change As the theorems related less

and less directly with the change then pro of scripts were easier to x until at a certain

level of abstraction the pro ofs went through unaltered HOLs ability to automatically

check these repro ofs and quickly lo cate places where changes needed to b e made in the

pro ofs was a tremendous time saver It meant that eectivelywe had to proveeverything

only once If the pro ofs were on pap er they would b e almost as dicult to check when

denitions were changed as they were to prove originally and would b e much less likely to

b e mo died correctly to account for the change

Proving theorems ab out substitutions and related op erations such as alphaconversion

required far more time and HOL co de than anyothervariety of theorems This is not a

surprise since lemmas ab out substitution ab ound in pap ers on pro ofs of programming

language prop erties In Tofte the pro of of Lemma the analogy of the theorem we

call typ echecking under substitution is one of the longest pro ofs in the pap er One would

like to nd a waytoavoid such complications

One p ossible solution for this problem would b e to write packages for HOL similar

to our typ e and relational denitions packages that will automatically dene and prove

theorems ab out substitutions If HOL is going to b e used for proving prop erties ab out

programming languages it will b e essential to do this to prevent these theorems from

b eing proved over and over

Another approach to solving the problems with substitution mightbetouse higher

order abstract syntax Higher order abstract syntax HOAS involves using the binding

and substitution prop erties of the language of the theorem prover here HOL terms to

handle the binding and substitution prop erties of the language b eing studied here SML

Since the semantics of SML uses b ound variables and substitution only in typ e schemes

wecontemplate using HOAS for this asp ect of the language

The rst problem we note is that we cannot use HOAS in typ e schemes in HOL In

yp e variables are represented by an HOL constructor wrapp ed around a our enco ding t

string and typ e variables are explicitly listed as one of the p ossibilitie s for an SML typ e

In an HOAS version there would not b e an explicit case for typ e variables Instead an

HOL variable of typ e type whichistheHOLtyp e of semantic ob jects representing SML

typ es would b e used instead Tomakeatyp e scheme from a typ e we need to quantify

over a collection of typ e variables This is done in our enco ding by wrapping a constructor

around a list of enco ded typ e variables the prex and a typ e the b o dy

In an HOAS enco ding for eachtyp e variable b eing quantied over wewould use the

HOL to abstract over the typ e variable an HOL variable and use a constructor to

inject the function into an HOL typ e for typ e schemes call it typescheme Since we

can quantify over several typ e variables the term to whichwe apply the abstraction

would need to b e a typeschemesowewould need the constructor to inject the function

typ e type typescheme into typescheme There is a theoretical diculty in doing

this the HOL function typ e contains al l functions from one typ e to another not just the

computable ones As a result the function typ e type typescheme has an uncountable

number of elements since the numb er of elements in type and in typescheme is each

countably innite Therefore the function typ e type typescheme cannot b e injected

into typescheme

Thus in order to enco de typ e schemes using HOAS wewould need to use a system

that handles function typ es dierently There are several systems that are designed to b e

used with HOAS suchasProlog NM and Elf Pfenning One mightcontemplate

enco ding SML in one of these systems and using this to prove prop erties of the language

There may b e diculties here as well In particular the way the function Clos discussed

in Section A is dened one needs to b e able to compute the typ e variables in a typ e

that are not free in the context Since there is no explicit enco ding for typ e variables it

may not b e p ossible to write in the language of the theorem prover a function that returns

the typ e variables in a typ e

Even if HOAS cannot b e used to avoid problems with b ound variables and substitution

in SML as describ ed in the Denition it may b e p ossible to reformulate the semantics in

aw ay that allows an ecient enco ding using HOAS Some preliminary work in this area

has b een done in Chirimar

App endix A

Semantics of HOLSML

HOLSML is the language ab out whichwe proved our theorems It started out as Core

SML mo died as p er Stefan Kahrs suggestions as to how to x the semantics to allowtyp e

preservationtobeproved Through the course of the work presented here that starting

language has b een changed substantially Most of these latter changes were simplications

in order to make the pro ofs more feasible This app endix gives the grammar and the static

and dynamic semantics after all the changes made In order for the semantics presented

here to b e most easily compared with that in the Denition the rules are presented in

astyle that closely mimics the style used there In addition some of the denitions of

functions used in the rules for example Abs used in Rule use a wording close to that

in the Denition

A Grammar

The grammar of HOLSML is describ ed b elow As noted in the Commentary and in

Kahrs identier status is not unambiguously explained in the Denition For HOL

SML wehave taken the following approach Var variables Con value constructors

ExCon exception constructors and a catchall Id are all separate semantic ob jects The

rst three are used in the syntax Id is the domain of VarEnvvariable environments

and thus elements of Var Con and ExCon are converted to Id to b e placed in a VarEnv

The domain of ConEnv constructor environments is also Id in order to makeconverting

them to VarEnvs as is done in Rule easier

The grammar is given in Tables A and A Only the parts of the grammar dealt with

atexp scon sp ecial constant

longvar value variable

longcon value constructor

longexcon exception constructor

hexprowi record

let dec in exp end lo cal declaration

exp parenthesized expression

exprow lab exp h exprowi expression row

exp atexp atomic expression

exp atexp application

exp ty typ ed expression

exp handle match handle exception

raise exp raise exception

fn match function

match mrule h match i

mrule pat exp

dec val valbind value declaration

type typbind typ e declaration

datatype datbind datatyp e declaration

abstype datbind with dec end abstyp e declaration

exception exbind exception declaration

local dec in dec end lo cal declaration

open longstrid longstrid op en declarationn

n

empty declaration

dec hidec sequential declaration

valbind pat exp hand valbindi

rec valbind recursive binding

typbind tyvarseqtycon ty hand typbind i

datbind tyvarseqtycon conbind hand datbind i

conbind con hof tyih conbindi

exbind excon hof tyihand exbindi

excon longexcon hand exbindi

Table A Grammar Expressions Matches Declarations and Bindings

atpat wildcard

scon sp ecial constant

var variable

longcon constant

longexcon exception constant

hpatrowi record pattern

pat parenthesized pattern

patrow wildcard

lab pat h patrow i pattern row

pat atpat atomic pattern

longcon atpat value construction

longexcon atpat exception construction

pat ty typ ed pattern

varh tyias pat layered pattern

ty tyvar typ e variable

htyrowi record typ e expression

tyvarseq tycon typ e construction

ty ty function typ e expression R

ty parenthesized typ e

genericty generic typ e

tyrow lab ty htyrow i typ eexpression rows

Table A Grammar Patterns and Typ e Expressions

by the semantics are shown derived forms and inx and precedence directives are omitted

Aside from the absence of these directives the only dierence b etween this grammar and

that for Core SML given in Section of the Denition is that one additional phrase

genericty has b een added to the typ e expressions Its use is describ ed on page All

the syntactic restrictions in Section of the Denition hold here as well

A Static Semantics

The static semantics of HOLSML has b een simplied signicantly from that of Core SML

The changes in the semantic ob jects and rules are listed b elow as well as the complete set

of rules for typ echecking HOLSML

Semantic Objects

Here we list the dierences b etween the semantic ob jects for Core SML and HOL

SML There is an additional simple semantic ob ject Stat that indicates the status of an

identier The p ossible values for Stat are v stat variable status c stat constructor sta

tus and e stat exception constructor status The simple semantic ob jects TyVar typ e

variables and TyName typ e constructor names dier only in that TyVars have neither

equality nor imp erative attributes and TyNames no longer have equality attributes An

other change is that wehave pared down the base typ es those whose typ e names app ear

in the initial static basis by omitting real instreamand outstream Consequently

we omit in the dynamic semantics all basic values op erating on these typ es The com

p ound semantic ob ject TyVarSet which is used in accounting for scop e of explicit typ e

variables has b een omitted The class StatMap of status maps and their place in the static

environment will b e describ ed b elow

These are the changes in the comp ound semantic ob jects

n

CE ConEnv Id Typ eScheme

n

VE VarEnv Id Typ eScheme

n

SM StatMap Stat Stat

TyEnv VarEnv E or SE TE VE EE SM Env StrEnv

StrEnv ExConEnv StatMap

C or T E Context TyVarSet Env

Changes in the Rules and Semantic Functions

In the rules for declarations b elow a set of typ e names is returned This is the set

of typ e names intro duced by datatype declarations Each use of in the Denition is

replaced here by an explicit addition of typ e names into the context The purp ose of this

is to account more carefully for the generation of typ e names and to include in T of C

only those typ e names that have b een generated by datatype declarations rather than

to attempt to include all typ e names currently in use The motivation for this is given in

Section

It is worth noting that two mistakes in the static semantics of the Denition remain

unxed in the semantics here The problems are are in Rules and and deal with the

scop e of typ e names This is describ ed in Section

The function Clos is used on constructor environments in Rule and on variable

environments in Rule If a constructor environment CE has the form fid i

i i

then Clos CE is fid tyvars i ng ng

i i i

The syntactic restrictions in Section of the Denition sp ecify that a value binding

bind may bind an identier only once Sayavalue environment VE has the form

fid i ng

i i

and results from the elab oration of a value binding valbind which has the form

pat exp j j pat exp

m m

Then for each i n id will b e mentioned in exactly one pattern in the value binding say

i

this is pat Then exp will b e the expression that binds id that is gives it its value and

i

k k

typ e Let get exp valbind id return the expression that binds id in valbind

exp valbind idcan In order to avoid generalizing the typ es of reference cells if get

create a reference cell we will not generalize its typ e Expressions whose evaluation cannot

create new reference cells are functions fn expressions value constructors and variables

these will b e called nonexpansive All other expressions will b e called expansive

The closure of VEClos VE is

Cvalbind

fid i ng

i i

where

tyvars ntyvars C if get expvalbind id is nonexpansive

i i

i

expvalbind id is expansive if get

i

This denition is considerably simpler than that given in the Denition In the Def

inition there are twovarieties of typ e variables applicative and imperative Imp erative

variables are those that could end up in reference cells while applicativevariables cannot

The idea in the semantics in the Denition is that an nonexpansive expression cannot

create new reference cells so all typ e variables that are not free in the context can b e

generalized Expansive expressions can create reference cells so only the applicativetyp e

variables can b e generalized The idea presented here that that all typ e variables are

generalized if the expression is nonexpansive and none are generalized if the expression is

expansive is called the value restriction and is describ ed in Wright

In Section of the Denition it is stated that twotyp e schemes are considered equal

if they are alphaequivalent Since HOL handles structural equalitymuch b etter than

Tofte in Tofte suggests allowing more expressions to b e nonexpansive including records if the ex

pression asso ciated with each lab el is nonexpansive and constructors applied to nonexpansive expressions

alphaequivalence we tried to do without alphaequivalenc e wherever p ossible For the

theorems weproved we found that we only needed to allow for alphaequivalence only in

Rule where generalization of free typ e variables in variable environments is done We

have mentioned alphaequivalen ce explicitly in the Rule b elow to indicate this This is

explained on page

In Rule in the Denition there is a quantity U that is the set of explicit typ e

variables scop ed at this value binding The side conditions involving U ensure that an

explicit typ e variable can b e quantied at the p oint at which it is scop ed The denition

of this concept is complex and easy to misinterpret The biggest argument against it is

that it can catch the user unaware as it imp oses a somewhat arbitrary scop e on top of

syntax with no scoping constructs Wehave therefore eliminated the sp ecial rules in order

to simplify the semantics and wetreatalltyp e variables equally whether or not they are

explicit in the syntax Tofte in Tofte takes another approach byintro ducing a binding

constructor for explicit typ e variables

The function rng tynames used in Rules and b elow collects the typ e names that

are given meaning in a typ e environment

tynamesTE ft j t CE Ran TE for some CEg rng

T

The side condition rng tynamesTE T of C in Rules and is equivalent to that

given in the Denition t CE RanTEt T of C

Rules and b elow are simplied from the Denition by the removal of the side

condition TE maximizes equality This reects the fact that equalitytyp es have b een done

away with Equality in HOLSML is only dened for the basic typ es int stringand

bool This is a ma jor simplication as the denition of when typ es and other semantic

ob jects do and do not admit equalityisinvolved and confusing Eliminating equalitytyp es

simplies the denition of Abs

For any TE of the form

TE ftycon t CE i k g

i i

i

to b e the environment where no CE is the empty map and for any E we dene AbsTE E

i

obtained from E and TE as follows First let AbsTE b e the typ e environment ftycon

i

t fg i k g in which all the constructor environments have b een replaced by the

i

empty map Then AbsTEE AbsTE E

Rule b elow for the typ e expression genericty is needed to allow the pro of of

typ echecking under substitution to go through It is used in the of ty qualications in

exception bindings to allow the typ e expression to matchanytyp e For a similar reason

weremove explicit typ e tags from expressions and patterns while doing this pro of The

function that executes this task is strip tags and is discussed in Section

App endix B of the Commentary describ es status maps which are nite maps from

identiers to a status indicating whether the identier is used as a value constructor an

exception constructor or a variable In the grammar used for HOLSML we presume

that the status of the identier in the syntax has b een resolved However we found that

we still needed to know the status of identiers to express wellformedness constraints on

contexts We needed to b e assured for example that if an identier can b e lo oked up as

avalue constructor then it was placed into a variable environmentasavalue constructor

and that if a lo okup of the constructor succeeded then the typ e scheme returned satised

certain prop erties particular to value constructors

The last paragraph of this app endix suggests that status maps can b e integrated into

the static semantics We found this to b e the most convenientway to handle status maps

Thus in the static enironments eachvariable environment has an asso ciated status map

which records the status of each identier These status maps are built up in the same

way the variable environments are see Rules aa and and when identiers are

lo oked up in contexts it is checked that the status under which they are lo oked up is the

same status with which they were put in the variable environment

Note that according to the elab oration rules b elow the only way an identier enters

stat for constructor is via Rules and or by avariable environment with status c

an open declaration and the only way an identier enters a variable environmentwith

status e stat for exception constructor is via Rule or byanopen declaration When

value or exception constructors enter static variable environments via Rules or these

are pro ducts of the original declarations of the ob jects and thus they are paired with the

original typ e schemes In Rules and constructor or exception names are put the

into an analogous lo cation in the dynamic environment

Later variables can b e assigned constructor values resulting in there b eing a longId

longid suchthatE longid is the name of the constructor and C longid is an instantiation

of the original typ e scheme However these secondary declarations can only b e lo oked



For example val elist aintlist

up as identiers so they are distinguishable from the originals Since open declarations

copy the values and typ e schemes in environments exactlyifE longcon E longcon

that is there are two longCons returning the same constructor name and C longcon

and C longcon that is b oth declarations entered the static environmentas

constructors then

Atomic Expressions C atexp

C scon typ escon

C longvar

C longvar

C longcon

C longcon

C longexcon

C longexcon

hC exprow i

C hexprow i fghi in Typ e

C dec E T C T E exp

C let dec in exp end

C exp

C exp

Expression Rows C exprow

C exp hC exprow i

C lab exp h exprow i flab ghi

C exp Expressions

C atexp

C atexp

C exp C atexp

C exp atexp

C exp C ty

C exp ty

C exp C match exn

C exp handle match

C exp exn

C raise exp

C match

C fn match

Matches C match

C mrule hC match i

C mrule h match i

Match Rules C mrule

C pat VE SM C VE SM exp

C pat exp

C dec E T Declarations

C valbind VE SM alpha equiv Clos VEVE

Cvalbind

C val valbind VE in Env SM

C typbind TE

C type typbind TE in Env fg

C rng tynamesTE TE datbind VE TE SM

T

rng tynamesTE T of C

C datatype datbind VE TEinEnv rng tynamesTE

C rng tynamesTE TE datbind VE TE SM

T

rng tynamesTE T of C

tynamesTE VE TE SM dec E T C rng

C abstype datbind with dec end

S

Abs TEE rng tynamesTE T

C exbind EE SM VE EE

C exception exbind VE EE SMinEnv fg

C dec E T C T E dec E T

S

T C local dec in dec end E T

C longstrid m E C longstrid m E

n n

n

C open longstrid longstrid E E fg

n

n

C fg in Env fg

C dec E T C T E dec E T

C dec hidec E E T T

Value Bindings C valbind VE SM

C pat VE SM C exp hC valbind VE i

C pat exp hand valbindi VE hVE i SM hSM i

C VE SM valbind VE SM

C rec valbind VE SM

Typ e Bindings C typbind TE

k

tyvarseq C ty hC typbind TE i

C tyvarseqtycon ty hand typbind i

k

ftycon fgghTE i

Data Typ e Bindings C datbind VE TE SM

k k

tyvarseq C t conbind CE SM

hC datbind VE TE SM t CE Ran TEt t i

C tyvarseqtycon conbind hand datbind i

Clos CE hVE i

ftycon t Clos CE ghTE i SMhSM i

C conbind CE SM Constructor Bindings

hC conbind CE SM i

a

C con h conbind i fcon ghCE i fcon c statghSM i

C ty hC conbind CE SM i

b

C con of ty h conbind i

statghSM i fcon ghCE i fcon c

Exception Bindings C exbind EE SM

hC exbind EE SMi

a

C excon hand exbind i

fexcon exnghEE i fexcon e statghSM i

C ty hC exbind EE SM i

b

C excon of ty hand exbind i

fexcon exnghEE i fexcon e statghSM i

C longexcon hC exbind EE SM i

C excon longexcon hand exbind i

fexcon ghEE i fexcon e statghSM i

Atomic Patterns C atpat VE SM

C fg fg

C scon fg fg typ escon

C var fvar g fvar v statg

k

C longcon t

k

C longcon fg fg t

C longexconexn

C longcon fg fg exn

hC patrow VE SMi

C hpatrowi fghVE i fghSM i fghi in Typ e

C pat VE SM

C pat VE SM

Pattern Rows C patrow VE SM

C fg fg

C pat VE SM

hC patrow VE SM patrow Dom i

C pat pat hpatrowi

VE hVE i SM hSM i flab ghi

Patterns C pat VE SM

C atpat VE SM

C atpat VE SM

C longcon C atpat VE SM

C longcon atpat VE SM

C longexcon exn C atpat VE SM

C longexcon atpat VE SM exn

C pat VE SM C ty

C pat ty VE SM

C var VE SM hC ty i C pat VE SM

C varh tyi as pat VE VE SM SM

Typ e Expressions C ty

tyvar

C tyvar

hC tyrow i

C htyrowi fghi in Typ e

tyseq ty ty C ty i k

k i i

C longtycon C E

k

C tyseq longtycon

C ty C ty

C ty ty

C ty

C ty

C genericty

Typ eexpression Rows C tyrow

C ty hC tyrow i

C lab ty h tyrowi flab ghi

A Dynamic Semantics

Reduced Syntax

Since typ es are for the most part dealt with in the static semantics the dynamic

semantics is dened over a reduced syntax that eliminates most of the typ e information

However the reduced syntax for HOLSML varies signicantly from that of Core SML in

that datatyp e bindings DatBind and constructor bindings ConBind are not eliminated

This allows constructor names see b elow to b e generated and placed into environments

The syntax for HOLSML is reduced by the following transformations

All explicit typ e ascriptions ty are omitted and qualications of ty are omitted

from exception and constructor bindings

Any declaration of the form type typbind is replaced by the empty declaration

The phrase classes TypBind Ty and TyRow are omitted

The function trans executes this transformation

Semantic Objects

Belowwe show only the parts of the semantic ob jects for HOLSML that are dierent

from that for Core SML The basic values are

size chr ord explode implode abs div mod neg

int str bool int str bool

times plus minus

Basic values suchasopen in have b een eliminated b ecause input and output are not b eing

considered in this pro ject Because equalitytyp es have b een eliminated the functions

and apply only to the base typ es int string and bool In order to avoid resolving

problems of overloading there are separate values for eachtyp e

The basic exceptions are

Abs Div Mod Prod Neg Sum Diff Ord Chr Match Bind

The basic exceptions corresp onding to op erations on real numb ers or inputoutput have

b een removed

There is one additional simple semantic ob ject the ConName

cn ConName constructor names

ConName is integrated into the values as follows

S S S S

v Val fg SVal BasVal ConVal

S S S

ExVal Record Addr Closure

S

cv ConVal ConName ConName Val

cns ConNameSet FinConName

mem ens cnsors State Mem ExNameSet ConNameSet

Changes in the Semantics

One of the most glaring errors in the Denition is that the ref constructor is used

explicitly in several of the evaluation rules for expressions and patterns the Denitions

Rules and to manipulate the state while in the static semantics

nothing prevents the ref from b eing used as a constructor for a userdeclared datatyp e

This obviously breaks typ e preservation the following program

datatype foo ref of int val x ref

will elab orate to the typ e foo but will evaluate to an address which can only havetyp e

ref for some There are several suggestions given in Kahrs for xing this including

making ref a reserved word The solution that seemed to involve the minimal change from

the semantics in the Denition was to retain datatyp e denitions in the reduced syntax used

for evaluation and to keep information on constructors in the variable environment This

requires the use of a semantic ob ject called a ConName for constructor name ConName

is treated similarly to ExName the names are generated by constructor bindings and would

b e stored in variable environments for evaluation as the values to which constructors are

b ound This would allow constructors for new datatyp es to b e distinguished from the

ref constructor as well as from eachother Then constructors no longer evaluate to

themselves but must b e lo oked up in the environment as in our Rule b elow

In the rules for the dynamic semantics in the Denition the presence of state in rules is

omitted except when explicitly involved in the rule Mention of state is also omitted from

the b oxed equations representing the general form of judgements for each phrase class

This leads to some confusion For example do es the evaluation of patterns return a new

state It is a simple pro of to show that pattern evaluation cannot change the state yet

Rule suggests that patterns do return a state but that this state must b e the same as

the initial state Toavoid this confusion we include the state in the general form of the

judgement

Rules for creating a new reference cell and for declaring a new exception con

structor in the Denition allow a semanticobjecttobechosen indeterminately The way

we enco ded the rules however makes the choice of next ExName and Addr deterministic

In HOLSML there is a linear order on these semantic ob jects making them isomorphic

to the natural numb ers and wecho ose the smallest unused one This is reected in our

version of those rules b elow A similar approach is taken with resp ect to cho osing Con

Names in Rule This simplies the pro of of determinism signicantly since wedo

not have to allow for the renaming of addresses exception names or constructor names in

the evaluation results

Rules and b elow dier slightly from those in the Denition in stating

explicitly that the result of lo oking an item an exception constructor or a lab el in an

environment or record succeeds This was needed b ecause due to the details of our deni

tions of how items are lo oked up unless it is sp ecically stated in the premises we could

not prove that the lo okup succeeded if w e only knew that the conclusion of the rule held

s E atexp v p s Atomic Expressions

E v scon valscon

E longvar v

E longvar v

E longcon cn

E longcon cn

E longexconen

E longexcon en

hE exprow r i

E hexprowi fghr i in Val

E dec E E E exp v

E let dec in exp end v

E exp v

E exp v

s E exprow r p s Expression Rows

E exp v hE exprow r i

E lab path exprowifpat v gh r i

Expressions s E exp v p s

E atexp v

E atexp v

E exp cn cn ref cn E atexp v

E exp atexp cnv

E exp en E atexp v

E exp atexp env

s E exp ref cns s E atexp v s a next addrs

s E exp atexp a s a v

s E exp s s E atexp f a v gs

s E exp atexp a s a v

E exp b E atexp v APPLYb v v p

E exp atexp v p

E exp match E VE E atexp v

E RecVEv match v

E exp atexp v

E exp match E VE E atexp v

E RecVEv match FAIL

E exp atexp Match

E exp v

E exp handle match v p

E exp e E e match v

E exp handle match v

E exp e E e match FAIL

E exp handle match e

E exp e

E raise exp e

E fn match matchEfg

Matches s E v match v pFAILs

E v mrule v

E v mruleh matchiv

E mrule FAIL

E mrule FAIL

E v mrule FAIL E v match v FAIL

E v mrule match v FAIL

s E v mrule v pFAILs Match Rules

E v pat VE E VE exp v

E v pat exp v

E v pat FAIL

E v pat exp FAIL

s E dec E p s Declarations

E valbind VE

E val valbind VE in Env

E datbind VE

E datatype datbind VE in Env

E datbind VE E VE dec E

E abstype datbind with dec end E

E exbind EE VE EE

E exception exbind VE EEinEnv

E dec E E E dec E

E local dec in dec end E

E longstrid E E longstrid E

n

n

E open longstrid longstrid E E

n

n

E fg in Env

E dec E E E dec E

E dec hidec E E

s E valbind VEp s Value Bindings

E exp v E v pat VE hE valbind VE i

E pat exphand valbind i VE hVE i

E exp v E v pat FAIL

E pat exphand valbind i Bind

E valbind VE

E rec valbind Rec VE

Datatyp e Bindings s datbind VEs

conbind VE h conbind VE i

conbind hand datbind iVE hVE i

Constructor Bindings s conbind VEs

cn next conname cns of s s s fcng

hs conbind VEs i

s con h conbind ifcon cnghVE is h i

Exception Bindings s E exbind EEp s

en next exname ens of s s s feng

hs E exbind EEs i

s E excon hand exbindifexcon enghEE is h i

E longexcon en hE exbind EE i

E excon longexcon hand exbind ifexcon enghEE i

Atomic Patterns s E v atpat VEFAIL s

E v fg

v val scon

E v scon fg

v val scon

E v scon FAIL

E v var fvar v g

E longcon v

E v longcon fg

E longcon cn v cn

E v longcon FAIL

E longexcon v

E v longexcon fg

E longexcon en v en

E v longcon FAIL

v fghr i in Val hE r patrow VEFAILi

E v hpatrow i fghVEFAIL i

E v pat VEFAIL

E v pat VEFAIL

Pattern Rows s E v patrow VEFAIL s

E r fg

r labv E v pat FAIL

E r lab pat h patrowiFAIL

r lab v E v pat VE hE r patrow VE FAILi

E r lab pat h patrow iVE hVE FAIL i

Patterns s E v pat VEFAIL s

E v atpat VEFAIL

E v atpat VEFAIL

cn v cn v E longcon cn cn ref

E v atpat VEFAIL

E v longcon atpat VEFAIL

E longcon cn cn ref cn v fcng Val

E v longcon atpat VEFAIL

E longexconen v en v

E v atpat VEFAIL

E v longexcon atpat VEFAIL

E longexcon en v feng Val

E v longexcon atpat FAIL

E longcon ref cn sav

s E v atpat VEFAIL s

s E v longcon pat VEFAIL

E v pat VEFAIL

E v var as pat fvar v g VEFAIL

Biblio graphy

ACPP Martin Abadi Benjamin Pierce and Gordon Plotkin Dynamic

Typing in a Statically Typ ed Language Digital Systems ResearchCenter Technical

rep ort No

App el A W App el A Critique of Standard ML Unpublished manuscript February

AM A W App el and D B MacQueen Standard ML of New JerseyInProgram

ming Language Implementation and Logic ProgrammingVol of Lecture Notes in

Computer Science pages SpringerVerlag August

BM Rob ert Boyer and J Strother Mo ore A Computational Logic Academic Press

CM Juanito Camilleri and Tom Melham Reasoning with Inductively Dened Relations

in the HOL Theorem Prover Technical Rep ort No University of Cambridge

Computer Lab oratory August

CW Luca Cardelli and Peter Wegner On Understanding Typ es Data Abstraction

and Polymorphism Computing Surveys

Chirimar Jawahar Lal Chirimar Proof Theoretic Approach to Specication Languages

PhD Thesis UniversityofPennsylvania

CDDK Dominique Clement Joelle Desp eyroux Thierry Desp eyroux Gilles Kahn A

Simple Applicative Language MiniML In Proce edings of ACM SymposiumonLISP

and Functional Programming pages

Cohen Richard Cohen Proving Gypsy Programs Computational Logic Incorp orated

Technical Rep ort No February

FF M Felleisen and D Friedman Control Op erators the SECD Machine and the

Calculus In Formal Description of Programming Concepts III pages North

Holland

Godel Kurt Godel Russells Mathematical Logic In Philosophy of Mathematics Se

lectedReadings Benacerraf and Putnam eds pages Cambridge University

Press

GSY Donald Go o d Ann Sieb ert and William Young Middle Gypsy Denition

Computational Logic Incorp orated Technical Rep ort No May

GM M J C Gordon and T F Melham Introduction to HOL A theorem proving en

vironment for higher order logicCambridge University Press Cambridge UK

GGM C A Gunter E L Gunter and D B MacQueen Using abstract interpretation

to compute ML equality kinds Information and Computation

GR Carl Gunter and Didier Remy A Pro ofTheoretic Assessment of Runtime Typ e Er

rors ATT Bell Lab oratories Technical Memo TM Novemb er

HDM Rob ert Harp er Bruce Duba and David MacQueen Typing FirstClass Contin

uations in ML Journal of Functional Programming Octob er

HMV My Hoang John Mitchell Remesh Viswanathan Standard ML weak p olymor

phism and imp erative constructs Unpublished manuscript Decemb er

erner H Herb elin Gilles Dowek Present HFWHD Gerard Huet AmyFeltyBW

ing the system Co q version In Proceedings of the Second Workshop on Logical

Frameworks Huet Plotkin and Jones eds Edinburgh

Kahrs Stefan Kahrs Mistakes and Ambiguities in the Denition of Standard ML Uni

versity of Edinburgh Lab oratory for Foundations of Computer Science Technical Re

p ort ECSLFCS April

Kahrs Stefan Kahrs Mistakes and Ambiguities in the Denition of Standard ML Ad

denda Unpublished manuscript June

KR B Kernighan and D M Ritchie The C Programming Language Prentice Hall

Knuth Donald Knuth The Remaining Trouble Sp ots in ALGOL Communications

of the ACM Octob er

Leroy Xavier LeroyPolymorphism by name for references and continuations Proceed

ings of th Principles of Programming Languages pages January

MG Savitry Mahara j and Elsa Gunter Studying the ML Mo dule System in HOL To

app ear in Proceedings of Higher Order Logic Theorem Proving and Its Applications

Sept

ML Per MartinLof Intuitionistic typetheory Bibliop oli s Nap oli

McCarthy John McCarthy RecursiveFunctions of Symb olic Expressions Communica

tions of the ACM April

McMillan KL McMillan Symbolic Model Checking AnApproach to the State Explo

sion Problem PhD Thesis Carnegie Mellon University

Melham T Melham Automating RecursiveTyp e Denitions in Higher Order Logic

University of Cambridge Computer Lab oratory Technical Rep ort No September

Melham T Melham Higher Order Logic and Har dwareVericationCambridge Tracts

in Theoretical Computer Science Volume

Milner Robin Milner A Theory of Typ e Polymorphism in Programming Journal of

Computer and System Sciences

MT Robin Milner Mads Tofte Commentary on StandardML The MIT Press Cam

bridge Mass

MTH Robin Milner Mads Tofte Rob ert Harp er The Denition of StandardML The

MIT Press Cambridge Mass

NM Gopalan Nadathur and Dale Miller An Overview of Prolog In Fifth International

Logic Programming Conference pages Seattle Washington August

MIT press

Naur P Naur Ed Rep ort on the Algorithmic Language ALGOL Communications

of the ACM May

Pfenning Frank Pfenning Logic programming in the LF logical framework In Logical

Frameworks pages Gerard Huet and Gordon Plotkin editors Cambridge

University Press

RC Jonathan Rees and William Clinger Eds Revised Rep ort on the Algorithmic

Language Scheme SIGPLAN Notices December

Reppy John H Reppy An Op erational Semantics of Firstclass Synchronous Op era

tions Cornell Tech Rep ort TR August

Syme Donald Syme Reasoning with the Formal Denition of Standard ML in HOL

Higher Order Logic Theorem Proving and Its Applications SpringerVerlag Lecture

Notes in Computer Science Vol August pages

Tofte Mads Tofte Typ e Inference and Polymorphic References Information and Com

putation

Tofte Mads Tofte ed Detailed list of dierences b etween Not the Denition of Standard

ML Version and The Denitions of StandardML Unpublished manuscript

March

vW A van Wijngaarden Revised Rep ort on the Algorithmic Language Algol Acta

Informatica

Wirth Niklaus Wirth On the Design of Programming Languages Proc IFIP Congress

pages NorthHolland Amsterdam

Wright Andrew Wright Polymorphism for Imp erative Languages without Imp erative

Typ es Rice UniversityTechnical Rep ort TR February

WF Andrew W right and Matthias Felleisen A Syntactic ApproachtoTyp e Soundness

Rice University Department of Computer Science Technical Rep ort TR June

Young William Young A Mechanically Veried Co de Generator Journal of Automated

Reasoning December