Advanced topics in types and programming languages

Advanced Topics in Types and Programming Languages Advanced Topics in Types and Programming Languages Benjamin C. Pi...

Author: Benjamin C. Pierce

71 downloads 1020 Views 9MB Size Report

This content was uploaded by our users and we assume good faith they have the permission to share this book. If you own the copyright to this book and it is wrongfully on our website, we offer a simple DMCA procedure to remove your content from our site. Start by pressing the button below!
Report copyright / DMCA form

DOWNLOAD PDF

Advanced Topics in Types and Programming Languages

Advanced Topics in Types and Programming Languages

Benjamin C. Pierce, editor

The MIT Press Cambridge, Massachusetts London, England

©2005 Massachusetts Institute of Technology All rights reserved. No part of this book may be reproduced in any form by any electronic of mechanical means (including photocopying, recording, or information storage and retrieval) without permission in writing from the publisher. This book was set in Lucida Bright by the editor and authors using the LATEX document preparation system. Printed and bound in the United States of America. Library of Congress Cataloging-in-Publication Data Advanced topics in types and programming languages / Benjamin C. Pierce, editor. p. cm. Includes bibliographical references and index. ISBN 0-262-16228-8 (hc.: alk. paper) 1. Programming languages (Electronic computers). I. Pierce, Benjamin C. QA76.7.A36 2005 005.13—dc22 200457123

10 9 8 7

6 5 4 3 2 1

Contents

Preface

ix

I Precise Type Analyses 1

Substructural Type Systems

1 3

David Walker 1.1 1.2 1.3 1.4 1.5 1.6 2

Structural Properties 4 A Linear Type System 6 Extensions and Variations 17 An Ordered Type System 30 Further Applications 36 Notes 40

Dependent Types

45

David Aspinall and Martin Hofmann 2.1 2.2 2.3 2.4 2.5 2.6 2.7 2.8 2.9 2.10

Motivations 45 Pure First-Order Dependent Types 50 Properties 54 Algorithmic Typing and Equality 56 Dependent Sum Types 61 The Calculus of Constructions 64 Relating Abstractions: Pure Type Systems Programming with Dependent Types 74 Implementation of Dependent Types 83 Further Reading 86

71

vi

Contents

3

Effect Types and Region-Based Memory Management

87

Fritz Henglein, Henning Makholm, and Henning Niss 3.1 3.2 3.3 3.4 3.5 3.6 3.7 3.8

Introduction and Overview 87 Value Flow by Typing with Labels 90 Effects 102 Region-Based Memory Management 106 The Tofte–Talpin Type System 114 Region Inference 123 More Powerful Models for Region-Based Memory Management 127 Practical Region-Based Memory Management Systems

II Types for Low-Level Languages 4

Typed Assembly Language

137

141

Greg Morrisett 4.1 4.2 4.3 4.4 4.5 4.6 4.7 4.8 5

TAL-0: Control-Flow-Safety 142 The TAL-0 Type System 146 TAL-1: Simple Memory-Safety 155 TAL-1 Changes to the Type System 161 Compiling to TAL-1 164 Scaling to Other Language Features 167 Some Real World Issues 172 Conclusions 175

Proof-Carrying Code

177

George Necula 5.1 5.2 5.3 5.4 5.5 5.6 5.7 5.8

Overview of Proof Carrying Code 177 Formalizing the Safety Policy 182 Verification-Condition Generation 187 Soundness Proof 199 The Representation and Checking of Proofs Proof Generation 214 PCC beyond Types 216 Conclusion 219

204

133

vii

Contents

III Types and Reasoning about Programs 6

221

Logical Relations and a Case Study in Equivalence Checking Karl Crary 6.1 6.2 6.3 6.4 6.5 6.6 6.7 6.8 6.9 6.10

7

The Equivalence Problem 224 Non-Type-Directed Equivalence Checking Type-Driven Equivalence 227 An Equivalence Algorithm 228 Completeness: A First Attempt 232 Logical Relations 233 A Monotone Logical Relation 236 The Main Lemma 237 The Fundamental Theorem 239 Notes 243

Typed Operational Reasoning

225

245

Andrew Pitts 7.1 7.2 7.3 7.4 7.5 7.6 7.7 7.8

Introduction 245 Overview 246 Motivating Examples 247 The Language 253 Contextual Equivalence 261 An Operationally Based Logical Relation Operational Extensionality 279 Notes 288

IV Types for Programming in the Large 8

266

291

Design Considerations for ML-Style Module Systems Robert Harper and Benjamin C. Pierce 8.1 8.2 8.3 8.4 8.5 8.6 8.7 8.8 8.9 8.10 8.11

Basic Modularity 294 Type Checking and Evaluation of Modules 298 Compilation and Linking 302 Phase Distinction 305 Abstract Type Components 307 Module Hierarchies 317 Signature Families 320 Module Families 324 Advanced Topics 338 Relation to Some Existing Languages 341 History and Further Reading 343

293

223

viii

Contents

9

Type Definitions

347

Christopher A. Stone 9.1 9.2 9.3 9.4

Definitions in the Typing Context Definitions in Module Interfaces Singleton Kinds 367 Notes 384

V Type Inference

351 358

387

10 The Essence of ML Type Inference

389

François Pottier and Didier Rémy 10.1 10.2 10.3 10.4 10.5 10.6 10.7 10.8 A

What Is ML? 389 Constraints 407 HM(X) 422 Constraint Generation 429 Type Soundness 434 Constraint Solving 438 From ML-the-Calculus to ML-the-Language Rows 460

Solutions to Selected Exercises

References Index

567

535

491

451

Preface

Overview Work in type systems for programming languages now touches many parts of computer science, from language design and implementation to software engineering, network security, databases, and analysis of concurrent and distributed systems. The aim of this book, together with its predecessor, Types and Programming Languages (Pierce [2002]—henceforth TAPL) is to offer a comprehensive and accessible introduction to the area’s central ideas, results, and techniques. The intended audience includes graduate students and researchers from other parts of computer science who want get up to speed in the area as a whole, as well as current researchers in programming languages who need comprehensible introductions to particular topics. Unlike TAPL, the present volume is conceived not as a unified text, but as a collection of more or less separate articles, authored by experts on their particular topics.

Required Background Most of the material should be accessible to readers with a solid grasp of the basic notations and techniques of operational semantics and type systems— roughly, the first half of TAPL. Some chapters depend on more advanced topics from the second half of TAPL or earlier chapters of the present volume; these dependencies are indicated at the beginning of each chapter. Interchapter dependencies have been kept to a minimum to facilitate reading in any order.

Topics Precise Type Analyses The first three chapters consider ways of extending simple type systems to give them a better grip on the run time behavior of

x

Preface

programs. The first, Substructural Type Systems, by David Walker, surveys type systems based on analogies with “substructural” logics such as linear logic, in which one or more of the structural rules of conventional logics— which allow dropping, duplicating, and permuting assumptions—are omitted or allowed only under controlled circumstances. In substructural type systems, the type of a value is not only a description of its “shape,” but also a capability for using it a certain number of times; this refinement plays a key role in advanced type systems being developed for a range of purposes, including static resource management and analyzing deadlocks and livelocks in concurrent systems. The chapter on Dependent Types, by David Aspinall and Martin Hofmann, describes a yet more powerful class of type systems, in which the behavior of computations on particular run-time values (not just generic “shapes”) may be described at the type level. Dependent type systems blur the distinction between types and arbitrary correctness assertions, and between typechecking and theorem proving. The power of full dependent types has proved difficult to reconcile with language design desiderata such as automatic typechecking and the “phase distinction” between compile time and run time in compiled languages. Nevertheless, ideas of dependent typing have played a fruitful role in language design and theory over the years, offering a common conceptual foundation for numerous forms of “indexed” type systems. Effect Types and Region-Based Memory Management, by Fritz Henglein, Henning Makholm, and Henning Niss, introduces yet another idea for extending the reach of type systems: in addition to describing the shape of an expression’s result (a static abstraction of the possible values that the expression may yield when evaluated), its type can also list a set of possible “effects,” abstracting the possible computational effects (mutations to the store, input and output, etc.) that its evaluation may engender. Perhaps the most sophisticated application of this idea has been in memory management systems based on static “region inference,” in which the effects manipulated by the typechecker track the program’s ability to read and write in particular regions of the heap. For example, the ML Kit Compiler used a region analysis internally to implement the full Standard ML language without a garbage collector. Types for Low-Level Languages The next part of the book addresses another research thrust that has generated considerable excitement over the past decade: the idea of adapting type system technologies originally developed for high-level languages to low-level languages such as assembly code and virtual machine bytecode. Typed Assembly Language, by Greg Morrisett, presents a low-level language with a type system based on the parametric polymorphism of System F and discusses how to construct a type-preserving

Preface

xi

compiler from a high-level language, through a series of typed intermediate languages, down to this typed assembly code. Proof-Carrying Code, by George Necula, presents a more general formulation in a logical setting with close ties to the dependent types described in Aspinall and Hofmann’s chapter. The strength of this presentation is that it offers a natural transition from conventional type safety properties, such as memory safety, to more general security properties. A driving application area for both approaches is enforcing security guarantees when dealing with untrusted mobile code. Types and Reasoning about Programs One attraction of rich type systems is that they support powerful methods of reasoning about programs—not only by compilers, but also by humans. One of the most useful, the technique of logical relations, is introduced in the chapter Logical Relations and a Case Study in Equivalence Checking, by Karl Crary. The extended example— proving the correctness of an algorithm for deciding a type-sensitive behavioral equivalence relation on terms in the simply typed lambda-calculus with a Unit type—foreshadows ideas developed further in Christopher Stone’s chapter on type definitions. Typed Operational Reasoning, by Andrew Pitts, develops a more general theory of typed reasoning about program equivalence. Here the examples focus on proving representation independence properties for abstract data types in the setting of a rich language combining the universal and existential polymorphism of System F with records and recursive function definitions. Types for Programming in the Large One of the most important projects in language design over the past decade and more has been the use of typetheory as a framework for the design of sophisticated module systems— languages for assembling large software systems from modular components. One highly developed line of work is embodied in the module systems found in modern ML dialects. Design Considerations for ML-Style Module Systems, by Robert Harper and Benjamin C. Pierce, offers an informal guided tour of the principal features of this class of module systems—a “big picture” introduction to a large but highly technical body of papers in the research literature. Type Definitions, by Christopher A. Stone, addresses the most critical and technically challenging feature of the type systems on which ML-style module systems are founded: singleton kinds, which allow type definitions to be internalized rather than being treated as meta-level abbreviations. Type Inference The ML family of languages—including Standard ML, Objective Caml, and Moscow ML, as well as more distant relatives such as Haskell—

xii

Preface

has for decades been a showcase for advances in typed language design and compiler implementation, and for the advantages of software construction in richly typed languages. One of the main reasons for the success of these languages is the combination of power and convenience offered by their type inference (or type reconstruction) algorithms. Basic ML type inference has been described in many places, but descriptions of the more advanced techniques used in production compilers for full-blown languages have until now been widely dispersed in the literature, when they were available at all. In The Essence of ML Type Inference, François Pottier and Didier Rémy offer a comprehensive, unified survey of the area.

Exercises Most chapters include numerous exercises. The estimated difficulty of each exercise is indicated using the following scale: « «« ««« ««««

Quick check Easy Moderate Challenging

30 seconds to 5 minutes ≤ 1 hour ≤ 3 hours > 3 hours

Exercises marked « are intended as real-time checks of important concepts. Readers are strongly encouraged to pause for each one of these before moving on to the material that follows. Some of the most important exercises are labeled Recommended. Solutions to most of the exercises are provided in Appendix A. To save readers searching for solutions to exercises for which solutions are not available, these are marked 3.

Electronic Resources Additional materials associated with this book can be found at: http://www.cis.upenn.edu/~bcpierce/attapl Resources available on this site will include errata for the text, pointers to supplemental material contributed by readers, and implementations associated with various chapters.

Acknowledgments Many friends and colleagues have helped to improve the chapters as they developed. We are grateful to Amal Ahmed, Lauri Alanko, Jonathan Aldrich,

Preface

xiii

Derek Dreyer, Matthias Felleisen, Robby Findler, Kathleen Fisher, Nadji Gauthier, Michael Hicks, Steffen Jost, Xavier Leroy, William Lovas, Kenneth MacKenzie, Yitzhak Mandelbaum, Martin Müller, Simon Peyton Jones, Norman Ramsey, Yann Régis-Gianas, Fermin Reig, Don Sannella, Alan Schmitt, Peter Sewell, Vincent Simonet, Eijiro Sumii, David Swasey, Joe Vanderwaart, Yanling Wang, Keith Wansbrough, Geoffrey Washburn, Stephanie Weirich, Dinghao Wu, and Karen Zee for helping to make this a much better book than we could have done alone. Stephanie Weirich deserves a particularly warm round of thanks for numerous and incisive comments on the whole manuscript. Nate Foster’s assistance with copy editing, typesetting, and indexing contributed enormously to the book’s final shape. The work described in many chapters was supported in part by grants from the National Science Foundation. The opinions, findings, conclusions, or recommendations expressed in these chapters are those of the author(s) and do not necessarily reflect the views of the NSF.

Part I

Precise Type Analyses

1

Substructural Type Systems David Walker

Advanced type systems make it possible to restrict access to data structures and to limit the use of newly-defined operations. Oftentimes, this sort of access control is achieved through the definition of new abstract types under control of a particular module. For example, consider the following simplified file system interface. type file val val val val val

open read append write close

: : : : :

string → file option file → string * file file * string → file file * string → file file → unit

By declaring that the type file is abstract, the implementer of the module can maintain strict control over the representation of files. A client has no way to accidentally (or maliciously) alter any of the file’s representation invariants. Consequently, the implementer may assume that the invariants that he or she establishes upon opening a file hold before any read, append, write or close. While abstract types are a powerful means of controlling the structure of data, they are not sufficient to limit the ordering and number of uses of functions in an interface. Try as we might, there is no (static) way to prevent a file from being read after it has been closed. Likewise, we cannot stop a client from closing a file twice or forgetting to close a file. This chapter introduces substructural type systems, which augment standard type abstraction mechanisms with the ability to control the number and order of uses of a data structure or operation. Substructural type systems are particularly useful for constraining interfaces that provide access to system

4

1 Substructural Type Systems

resources such as files, locks and memory. Each of these resources undergoes a series of changes of state throughout its lifetime. Files, as we have seen, may be open or closed; locks may be held or not; and memory may be allocated or deallocated. Substructural type systems provide sound static mechanisms for keeping track of just these sorts of state changes and preventing operations on objects in an invalid state. The bulk of this chapter will focus on applications of substructural type systems to the control of memory resources. Memory is a pervasive resource that must be managed carefully in any programming system so it makes an excellent target of study. However, the general principles that we establish can be applied to other sorts of resources as well.

1.1

Structural Properties Most of the type systems in this book allow unrestricted use of variables in the type checking context. For instance, each variable may be used once, twice, three times, or not at all. A precise analysis of the properties of such variables will suggest a whole new collection of type systems. To begin our exploration, we will analyze the simply-typed lambda calculus, which is reviewed in Figure 1-1. In this discussion, we are going to be particularly careful when it comes to the form of the type-checking context Γ . We will consider such contexts to be simple lists of variable-type pairs. The "," operator appends a pair to the end of the list. We also write (Γ1 , Γ2 ) for the list that results from appending Γ2 onto the end of Γ1 . As usual, we allow a given variable to appear at most once in a context and to maintain this invariant, we implicitly alpha-convert bound variables before entering them into the context. We are now in position to consider three basic structural properties satisfied by our simply-typed lambda calculus. The first property, exchange, indicates that the order in which we write down variables in the context is irrelevant. A corollary of exchange is that if we can type check a term with the context Γ , then we can type check that term with any permutation of the variables in Γ . The second property, weakening, indicates that adding extra, unneeded assumptions to the context, does not prevent a term from type checking. Finally, the third property, contraction, states that if we can type check a term using two identical assumptions (x2 :T1 and x3 :T1 ) then we can check the same term using a single assumption.

1.1.1 1.1.2

Lemma [Exchange]: If Γ1 , x1 :T1 , x2 :T2 , Γ2 ` t : T then Γ1 , x2 :T2 , x1 :T1 , Γ2 ` t : T

2

Lemma [Weakening]: If Γ1 , Γ2 ` t : T then Γ1 , x1 :T1 , Γ2 ` t : T

2

5

1.1 Structural Properties

Syntax b ::= true false t ::= x b if t then t else t λx:T.t tt T ::= Bool T→T Γ

Γ `t:T

Typing booleans: true false

::= ∅ Γ , x:T

terms: variable boolean conditional abstraction application types: booleans type of functions

(T-Var)

Γ1 , x:T, Γ2 ` x : T

(T-Bool)

Γ ` b : Bool Γ ` t1 : Bool

Γ ` t2 : T

Γ ` t3 : T

Γ ` if t1 then t2 else t3 : T (T-If) Γ , x:T1 ` t2 : T2 Γ ` λx:T1 .t2 : T1 →T2 Γ ` t1 : T11 →T12

Γ ` t2 : T11

Γ ` t1 t2 : T12

(T-Abs) (T-App)

contexts: empty context term variable binding

Figure 1-1: Simply-typed lambda calculus with booleans

1.1.3

1.1.4

Lemma [Contraction]: If Γ1 , x2 :T1 , x3 :T1 , Γ2 ` t : T2 then Γ1 , x1 :T1 , Γ2 ` [x2 , x1 ][x3 , x1 ]t : T2

2

Exercise [Recommended, «]: Prove that exchange, weakening and contraction lemmas hold for the simply-typed lambda calculus. 2 A substructural type system is any type system that is designed so that one or more of the structural properties do not hold. Different substructural type systems arise when different properties are withheld. • Linear type systems ensure that every variable is used exactly once by allowing exchange but not weakening or contraction. • Affine type systems ensure that every variable is used at most once by allowing exchange and weakening, but not contraction. • Relevant type systems ensure that every variable is used at least once by allowing exchange and contraction, but not weakening. • Ordered type systems ensure that every variable is used exactly once and in the order in which it is introduced. Ordered type systems do not allow any of the structural properties.

6


The picture below can serve as a mnemonic for the relationship between these systems. The system at the bottom of the diagram (the ordered type system) admits no structural properties. As we proceed upwards in the diagram, we add structural properties: E stands for exchange; W stands for weakening; and C stands for contraction. It might be possible to define type systems containing other combinations of structural properties, such as contraction only or weakening only, but so far researchers have not found applications for such combinations. Consequently, we have excluded them from the diagram.

unrestricted (E,W,C)

affine (E,W)

relevant (E,C)

linear (E)

ordered (none)

The diagram can be realized as a relation between the systems. We say system q1 is more restrictive than system q2 and write q1 vq2 when system q1 exhibits fewer structural rules than system q2 . Figure 1-2 specifies the relation, which we will find useful in the coming sections of this chapter.

1.2

A Linear Type System In order to safely deallocate data, we need to know that the data we deallocate is never used in the future. Unfortunately, we cannot, in general, deduce whether data will be used after execution passes a certain program point: The problem is clearly undecidable. However, there are a number of sound, but useful approximate solutions. One such solution may be implemented using a linear type system. Linear type systems ensure that objects are used exactly once, so it is completely obvious that after the use of an object, it may be safely deallocated.

7

1.2 A Linear Type System

system: ordered linear relevant affine unrestricted

q ::= ord lin rel aff un

ord v lin

(Q-OrdLin)

lin v rel

(Q-LinRel)

lin v aff

(Q-LinAff)

rel v un

(Q-RelUn)

aff v un

(Q-AffUn)

qvq

(Q-Reflex)

q1 v q2

q2 v q3

q1 v q3

(Q-Trans)

Figure 1-2: A relation between substructural type systems

Syntax Figure 1-3 presents the syntax of our linear language, which is an extension of the simply-typed lambda calculus. The main addition to be aware of, at this point, are the type qualifiers q that annotate the introduction forms for all data structures. The linear qualifier (lin) indicates that the data structure in question will be used (i.e., appear in the appropriate elimination form) exactly once in the program. Operationally, we deallocate these linear values immediately after they are used. The unrestricted qualifier (un) indicates that the data structure behaves as in the standard simply-typed lambda calculus. In other words, unrestricted data can be used as many times as desired and its memory resources will be automatically recycled by some extra-linguistic mechanism (a conventional garbage collector). Apart from the qualifiers, the only slightly unusual syntactic form is the elimination form for pairs. The term split t1 as x,y in t2 projects the first and second components from the pair t1 and calls them x and y in t2 . This split operation allows us to extract two components while only counting a single use of a pair. Extracting two components using the more conventional projections π 1 t1 and π 2 t1 requires two uses of the pair t1 . (It is also possible, but a bit tricky, to provide the conventional projections.) To avoid dealing with an unnecessarily heavy syntax, we adopt a couple abbreviations in our examples in this section. First, we omit all unrestricted qualifiers and only annotate programs with the linear ones. Second, we freely use n-ary tuples (triples, quadruples, unit, etc.) in addition to pairs and also allow multi-argument functions. The latter may be defined as single-argument functions that take linear pairs (triples, etc) as arguments and immediately split them upon entry to the function body. Third, we often use ML-style type

8


Syntax q ::= lin un b ::= true false t ::= x qb if t then t else t q

qualifiers: linear unrestricted booleans: true false terms: variable boolean conditional pair

split t as x,y in t q λx:T.t tt P ::= Bool T*T T→T T ::= qP Γ

::= ∅ Γ , x:T

split abstraction application pretypes: booleans pairs functions

types: qualified pretype contexts: empty context term variable binding

Figure 1-3: Linear lambda calculus: Syntax

declarations, value declarations and let expressions where convenient; they all have the obvious meanings.

Typing To ensure that linear objects are used exactly once, our type system maintains two important invariants. 1. Linear variables are used exactly once along every control-flow path. 2. Unrestricted data structures may not contain linear data structures. More generally, data structures with less restrictive type may not contain data structures with more restrictive type. To understand why these invariants are useful, consider what could happen if either invariant is broken. When considering the first invariant, assume we have constructed a function free that uses its argument and then deallocates it. Now, if we allow a linear variable (say x) to appear twice, a programmer might write , or, slightly more deviously, (λz.λy.) x x.

In either case, the program ends up attempting to use and then free x after it has already been deallocated, causing the program to crash. Now consider the second invariant and suppose we allow a linear data structure (call it x) to appear inside an unrestricted pair (un <x,3>). We can

9


Context Split ∅ =∅◦∅

Γ = Γ1 ◦ Γ2

Γ = Γ1 ◦ Γ2

(M-Empty)

Γ , x:lin P = (Γ1 , x:lin P) ◦ Γ2

Γ = Γ1 ◦ Γ2 Γ , x:un P = (Γ1 , x:un P) ◦ (Γ2 , x:un P)

(M-Un)

Γ = Γ1 ◦ Γ2 Γ , x:lin P = Γ1 ◦ (Γ2 , x:lin P)

(M-Lin1) (M-Lin2)

Figure 1-4: Linear lambda calculus: Context splitting

get exactly the same effect as above by using the unrestricted data structure multiple times: let z split split in z as x1,_ in z as x2,_ in x1,free x2>

Fortunately, our type system ensures that none of these situations can occur. We maintain the first invariant through careful context management. When type checking terms with two or more subterms, we pass all of the unrestricted variables in the context to each subterm. However, we split the linear variables between the different subterms to ensure each variable is used exactly once. Figure 1-4 defines a relation, Γ = Γ1 ◦ Γ2 , which describes how to split a single context in a rule conclusion (Γ ) into two contexts (Γ1 and Γ2 ) that will be used to type different subterms in a rule premise. To check the second invariant, we define the predicate q(T) (and its extension to contexts q(Γ )) to express the types T that can appear in a q-qualified data structure. These containment rules state that linear data structures can hold objects with linear or unrestricted type, but unrestricted data structures can only hold objects with unrestricted type. • q(T) if and only if T = q0 P and qvq0 • q(Γ ) if and only if (x:T) ∈ Γ implies q(T) Recall, we have already defined qvq0 such that it is reflexive, transitive and linvun. Now that we have defined the rules for containment and context splitting, we are ready for the typing rules proper, which appear in Figure 1-5. Keep in mind that these rules are constructed anticipating a call-by-value operational semantics. It is often the case when designing a type system that the rules for the base cases, variables and constants, are hardly worth mentioning. However,

10


Γ 1 ` t1 : T1 q(T1 )

Γ `t:T

Typing un (Γ1 , Γ2 ) Γ1 , x:T, Γ2 ` x : T un (Γ ) Γ ` q b : q Bool Γ1 ` t1 : q Bool Γ 2 ` t2 : T Γ 2 ` t3 : T Γ1 ◦ Γ2 ` if t1 then t2 else t3 : T

(T-Var)

Γ2 ` t2 : T2 q(T2 )

Γ1 ◦ Γ2 ` q : q (T1 *T2 ) Γ1 ` t1 : q (T1 *T2 ) Γ2 , x:T1 , y:T2 ` t2 : T

(T-Bool)

Γ1 ◦ Γ2 ` split t1 as x,y in t2 : T q(Γ ) (T-If)

Γ , x:T1 ` t2 : T2 Γ2 ` t2 : T11

Γ1 ◦ Γ2 ` t1 t2 : T12

(T-Split) (T-Abs)

Γ ` q λx:T1 .t2 : q T1 →T2 Γ1 ` t1 : q T11 →T12

(T-Pair)

(T-App)

Figure 1-5: Linear lambda calculus: Typing

in substructural type systems these cases have a special role in defining the nature of the type system, and subtle changes can make all the difference. In our linear system, the base cases must ensure that no linear variable is discarded without being used. To enforce this invariant in rule (T-Var), we explicitly check that Γ1 and Γ2 contain no linear variables using the condition un (Γ1 , Γ2 ). We make a similar check in rule (T-Bool). Notice also that rule (TVar) is written carefully to allow the variable x to appear anywhere in the context, rather than just at the beginning or at the end. 1.2.1

Exercise [«]: What is the effect of rewriting the variable rule as follows? un (Γ ) Γ , x:T ` x : T

(T-BrokenVar)

The inductive cases of the typing relation take care to use context splitting to partition linear variables between various subterms. For instance, rule (TIf) splits the incoming context into two parts, one of which is used to check subterm t1 and the other which is used to check both t2 and t3 . As a result, a particular linear variable will occur once in t2 and once in t3 . However, the linear object bound to the variable in question will be used (and hence deallocated) exactly once at run time since only one of t2 or t3 will be executed. The rules for creation of pairs and functions make use of the containment rules. In each case, the data structure’s qualifier q is used in the premise of the typing rule to limit the sorts of objects it may contain. For example, in the rule (T-Abs), if the qualifier q is un then the variables in Γ , which will inhabit the function closure, must satisfy un (Γ ). In other words, they must all have


11

unrestricted type. If we omitted this constraint, we could write the following badly behaved functions. (For clarity, we have retained the unrestricted qualifiers in this example rather than omitting them.) type T = un (un bool → lin bool) val discard = lin λx:lin bool. (lin λf:T.lin true) (un λy:un bool.x) val duplicate = lin λx:lin bool. (lin λf:T.lin )) (un λy:un bool.x)

The first function discards a linear argument x without using it and the second duplicates a linear argument and returns two copies of it in a pair. Hence, in the first case, we fail to deallocate x and in the second case, a subsequent function may project both elements of the pair and use x twice, which would result in a memory error as x would be deallocated immediately after the first use. Fortunately, the containment constraint disallows the linear variable x from appearing in the unrestricted function (λy:bool. x). Now that we have defined our type system, we should verify our intended structural properties: exchange for all variables, and weakening and contraction for unrestricted variables. 1.2.2

1.2.3

1.2.4

Lemma [Exchange]: If Γ1 , x1 :T1 , x2 :T2 , Γ2 ` t : T then Γ1 , x2 :T2 , x1 :T1 , Γ2 ` t : T.

2

Lemma [Unrestricted Weakening]: If Γ ` t : T then Γ , x1 :un P1 ` t : T.

2

Lemma [Unrestricted Contraction]: If Γ , x2 :un P1 , x3 :un P1 ` t : T3 then Γ , x1 :un P1 ` [x2 , x1 ][x3 , x1 ]t : T3 .

2

Proof: The proofs of all three lemmas follow by induction on the structure of the appropriate typing derivation. 2

Algorithmic Linear Type Checking The inference rules provided in the previous subsection give a clear, concise specification of the linearly-typed programs. However, these rules are also highly non-deterministic and cannot be implemented directly. The primary difficulty is that to implement the non-deterministic splitting operation,

12


Γin ` t : T;Γout

Algorithmic Typing

Γ1 , x:un P, Γ2 ` x : un P;Γ1 , x:un P, Γ2 (A-UVar) Γ1 , x:lin P, Γ2 ` x : lin P;Γ1 , Γ2

(A-LVar)

Γ ` q b : q Bool;Γ

(A-Bool)

Γ1 ` t1 : q Bool;Γ2 Γ2 ` t2 : T;Γ3 Γ2 ` t3 : T;Γ3 Γ1 ` if t1 then t2 else t3 : T;Γ3 Γ1 ` t1 : T1 ;Γ2 q(T1 )

Γ2 ` t2 : T2 ;Γ3 q(T2 )

Γ1 ` q : q (T1 *T2 );Γ3

(A-If)

Γ1 ` t1 : q (T1 *T2 );Γ2 Γ2 , x:T1 , y:T2 ` t2 : T;Γ3 Γ1 ` split t1 as x,y in t2 : T;Γ3 ÷ (x:T1 , y:T2 )

(A-Split)

q=un ⇒ Γ1 = Γ2 ÷ (x:T1 ) Γ1 , x:T1 ` t2 : T2 ;Γ2 Γ1 ` q λx:T1 .t2 : q T1 →T2 ;Γ2 ÷ (x:T1 ) (A-Abs) Γ1 ` t1 : q T11 →T12 ;Γ2 Γ2 ` t2 : T11 ;Γ3 Γ1 ` t1 t2 : T12 ;Γ3

(A-Pair)

(A-App)

Figure 1-6: Linear lambda calculus: Algorithmic type checking

Γ = Γ1 ◦ Γ2 , we must guess how to split an input context Γ into two parts. Fortunately, it is relatively straightforward to restructure the type checking rules to avoid having to make these guesses. This restructuring leads directly to a practical type checking algorithm. The central idea is that rather than splitting the context into parts before checking a complex expression composed of several subexpressions, we can pass the entire context as an input to the first subexpression and have it return the unused portion as an output. This output may then be used to check the next subexpression, which may also return some unused portions of the context as an output, and so on. Figure 1-6 makes these ideas concrete. It defines a new algorithmic type checking judgment with the form Γin ` t : T;Γout , where Γin is the input context, some portion of which will be consumed during type checking of t, and Γout is the output context, which will be synthesized alongside the type T. There are several key changes in our reformulated system. First, the base cases for variables and constants allow any context to pass through the judgment rather than restricting the number of linear variables that appear. In order to ensure that linear variables are used, we move these checks to the rules where variables are introduced. For instance, consider the rule (A-Split). The second premise has the form Γ2 , x:T1 , y:T2 ` t2 : T;Γ3 If T1 and T2 are linear, then they should be used in t2 and should not appear in Γ3 . Conversely, T1 and T2 are unrestricted, then they will always appear

13


in Γ3 , but we should delete them from the final outgoing context of the rule so that the ordinary scoping rules for the variables are enforced. To handle both the check that linear variables do not appear and the removal of unrestricted variables, we use a special “context difference” operator (÷). Using this operator, the final outgoing context of the rule (A-Split) is defined to be Γ3 ÷ (x:T1 , y:T2 ). Formally, context difference is defined as follows. Γ ÷∅=Γ Γ1 ÷ Γ2 = Γ3

(x:lin P) 6∈ Γ3

Γ1 ÷ (Γ2 , x:lin P) = Γ3 Γ1 ÷ Γ2 = Γ3

Γ3 = Γ4 , x:un P, Γ5

Γ1 ÷ (Γ2 , x:un P) = Γ4 , Γ5 Notice that this operator is undefined when we attempt to take the difference of two contexts, Γ1 and Γ2 , that contain bindings for the same linear variable (x:lin P). If the undefined quotient Γ1 ÷ Γ2 were to appear anywhere in a typing rule, the rule itself would not be considered defined and could not be part of a valid typing derivation. The rule for abstraction (A-Abs) also introduces a variable and hence it also uses context difference to manipulate the output context for the rule. Abstractions must also satisfy the appropriate containment conditions. In other words, rule (A-Abs) must check that unrestricted functions do not contain linear variables. We perform this last check by verifying that when the function qualifier is unrestricted, the input and output contexts from checking the function body are the same. This equivalence check is sufficient because if a linear variable was used in the body of an unrestricted function (and hence captured in the function closure), that linear variable would not show up in the outgoing context. It is completely straightforward to check that every rule in our algorithmic system is syntax directed and that all our auxiliary functions including context membership tests and context difference are easily computable. Hence, we need only show that our algorithmic system is equivalent to the simpler and more elegant declarative system specified in the previous section. The proof of equivalence can be a broken down into the two standard components: soundness and completeness of the algorithmic system with respect to the declarative system. However, before we can get to the main results, we will need to show that our algorithmic system satisfies some basic structural properties of its own. In the following lemmas, we use the notation L(Γ ) and U(Γ ) to refer to the list of linear and unrestricted assumptions in Γ respectively.

14


1.2.5

Lemma [Algorithmic Monotonicity]: If Γ ` t : T;Γ 0 then U(Γ 0 ) = U(Γ ) and L(Γ 0 ) ⊆ L(Γ ). 2

1.2.6

Lemma [Algorithmic Exchange]: If Γ1 , x1 :T1 , x2 :T2 , Γ2 ` t : T;Γ3 then Γ1 , x2 :T2 , x1 :T1 , Γ2 ` t : T;Γ30 and Γ3 is the same as Γ30 up to transposition of the bindings for x1 and x2 . 2

1.2.7

Lemma [Algorithmic Weakening]: If Γ ` t : T;Γ 0 then Γ , x:T0 ` t : T; Γ 0 , x:T0 . 2

1.2.8

Lemma [Algorithmic Linear Strengthening]: If Γ , x:lin P ` t : T; Γ 0 , x:lin P then Γ ` t : T;Γ 0 . 2 Each of these lemmas may be proven directly by induction on the initial typing derivation. The algorithmic system also satisfies a contraction lemma, but since it will not be necessary in the proofs of soundness and completeness, we have not stated it here.

1.2.9

Theorem [Algorithmic Soundness]: If Γ1 ` t : T;Γ2 and L(Γ2 ) = ∅ then Γ1 ` t : T. 2 Proof: As usual, the proof is by induction on the typing derivation. The structural lemmas we have just proven are required to push through the result, but it is mostly straightforward. 2

1.2.10

Theorem [Algorithmic Completeness]: If Γ1 ` t : T then Γ1 ` t : T;Γ2 and L(Γ2 ) = ∅. 2 Proof: The proof is by induction on the typing derivation.

2

Operational Semantics To make the memory management properties of our language clear, we will evaluate terms in an abstract machine with an explicit store. As indicated in Figure 1-7, stores are a sequence of variable-value pairs. We will implicitly assume that any variable appears at most once on the left-hand side of a pair so the sequence may be treated as a finite partial map. A value is a pair of a qualifier together with some data (a prevalue w). For the sake of symmetry, we will also assume that all values are stored, even base types such as booleans. As a result, both components of any pair will be pointers (variables). We define the operation of our abstract machine using a context-based, small-step semantics. Figure 1-7 defines the computational contexts E, which

15


w ::= b <x,y> λx:T.t v ::= qw S ::= ∅ S, x , v

prevalues: boolean pair abstraction values: qualified prevalue

E ::=

stores: empty context store binding

evaluation contexts: [] context hole if E then t else t if context q <E,t> fst context q <x,E> snd context split E as x,y in t split context Et fun context xE arg context

Figure 1-7: Linear lambda calculus: Run-time data

are terms with a single hole. Contexts define the order of evaluation of terms— they specify the places in a term where a computation can occur. In our case, evaluation is left-to-right since, for example, there is a context with the form E t indicating that we can reduce the term in the function position before reducing the term in the argument position. However, there is no context with the form t E. Instead, there is only the more limited context x E, indicating that we must reduce the term in the function position to a pointer x before proceeding to evaluate the term in the argument position. We use the notation E[t] to denote the term composed of the context E with its hole plugged by the computation t. The operational semantics, defined in Figure 1-8, is factored into two relations. The first relation, (S;t) -→ (S0 ;t0 ), picks out a subcomputation to evaluate. The second relation, (S;t) -→β (S0 ;t0 ), does all the real work. In order to avoid creation of two sets of operational rules, one for linear data, which is deallocated when used, and one for unrestricted data, which is never q deallocated, we define an auxiliary function, S ∼ x, to manage the differences. lin

(S1 ,x , v,S2 ) ∼ x un S∼x

= =

S1 ,S2 S

Aside from these details, the operational semantics is standard.

Preservation and Progress In order to prove the standard safety properties for our language, we need to be able to show that programs are well-formed after each step in evaluation. Hence, we will define typing rules for our abstract machine. Since these typing rules are only necessary for the proof of soundness, and have no place in an

16


(S;t) -→ (S0 ;t0 )

Top-level Evaluation

q

(S;t) -→β (S;t0 )

(E-Ctxt)

(S;E[t]) -→ (S;E[t0 ])

(S;t) -→β (S0 ;t0 )

Evaluation

S(x) = q false

(S;q b) -→β (S, x , q b;x)

(S;if x then t1 else t2 ) -→β (S ∼ x;t2 ) (E-If2) (S;q ) -→β (S, x , q ;x) (E-Pair) S(x) = q

(E-Bool)

(S;split x as y,z in t) -→β

(E-Split)

q

S(x) = q true

(S ∼ x;[y , y1 ][z , z1 ]t) q

(S;if x then t1 else t2 ) -→β (S ∼ x;t1 ) (E-If1)

(S;q λy:T.t) -→β (S, x , q λy:T.t;x) (E-Fun) S(x1 ) = q λy:T.t (E-App) q (S;x1 x2 ) -→β (S ∼ x1 ;[y , x2 ]t)

Figure 1-8: Linear lambda calculus: Operational semantics

implementation, we will extend the declarative typing rules rather than the algorithmic typing rules. Figure 1-9 presents the machine typing rules in terms of two judgments, one for stores and the other for programs. The store typing rules generate a context that describes the available bindings in the store. The program typing rule uses the generated bindings to check the expression that will be executed. With this new machinery in hand, we are able to prove the standard progress and preservation theorems. (S0 ;t0 ) then 2

1.2.11

Theorem [Preservation]: If ` ` (S0 ;t0 ).

1.2.12

Theorem [Progress]: If ` (S;t) then (S;t) -→ (S0 ;t0 ) or t is a value.

1.2.13

Exercise [Recommended, «]: You will need a substitution lemma to complete the proof of preservation. Is the following the right one? Conjecture: Let Γ3 = Γ1 ◦ Γ2 . If Γ1 , x:T ` t1 : T1 and Γ2 ` t : T then Γ3 ` [x , t]t1 : T1 . 2

1.2.14

Exercise [«««, 3]: Prove progress and preservation using TAPL, Chapters 9 and 13, as an approximate guide. 2

(S;t) and (S;t)

-→

2

17

1.3 Extensions and Variations

` S : Γ1 ◦ Γ2

`S:Γ

Store Typing `∅:∅ ` S : Γ1 ◦ Γ2

Γ1 ` lin w : T

` S,x , lin w : Γ2 , x:T

` S,x , un w : Γ2 , x:T

(T-EmptyS) (T-NextlinS)

Γ1 ` un w : T

` (S;t)

Program Typing `S:Γ

(T-NextunS)

Γ `t:T

` (S;t)

(T-Prog)

Figure 1-9: Linear lambda calculus: Program typing

1.3

Extensions and Variations Most features found in modern programming languages can be defined to interoperate successfully with linear type systems, although some are trickier than others. In this section, we will consider a variety of practical extensions to our simple linear lambda calculus.

Sums and Recursive Types Complex data structures, such as the recursive data types found in ML-like languages, pose little problem for linear languages. To demonstrate the central ideas involved, we extend the syntax for the linear lambda calculus with the standard introduction and elimination forms for sums and recursive types. The details are presented in Figure 1-10. Values with sum type are introduced by injections q inlP t or q inrP t, where P is T1 +T2 , the resulting pretype of the term. In the first instance, the underlying term t must have type T1 , and in the second instance, the underlying term t must have type T2 . The qualifier q indicates the linearity of the argument in exactly the same way as for pairs. The case expression will execute its first branch if its primary argument is a left injection and its second branch if its primary argument is a right injection. We assume that + binds more tightly that → but less tightly than *. Recursive types are introduced with a rollP t expression, where P is the recursive pretype the expression will assume. Unlike all the other introduction forms, roll expressions are not annotated with a qualifier. Instead, they take on the qualifier of the underlying expression t. The reason for this distinction is that we will treat this introduction form as a typing coercion that has no real operational effect. Unlike functions, pairs or sums, recursive data types have no data of their own and therefore do not need a separate qualifier to control their allocation behavior. To simplify the notational overhead

18


terms: ... as before q inlP t left inj. q inrP t right inj. case t (inl x ⇒ t | inr y ⇒ t) case rollP t roll into rec type unroll t unroll from rec type fun f(x:T1 ):T2 .t recursive fun P ::= pretypes: ... as before a pretype variables T1 +T2 sum types rec a.T recursive types t ::=

Γ `t:T

Typing Γ ` t : T1

q(T1 )

q(T2 )

(T-Inl)

Γ ` q inlT1 +T2 t : q (T1 +T2 ) Γ ` t : T2

q(T1 )

q(T2 )

(T-Inr)

Γ ` q inrT1 +T2 t : q (T1 +T2 )

Γ1 ` t : q (T1 +T2 ) Γ2 , x:T1 ` t1 : T Γ2 , y:T2 ` t2 : T Γ1 ◦ Γ2 ` case t (inl x ⇒ t1 | inr y ⇒ t2 ) : T (T-Case) Γ ` t : [a , P]q P1 P = rec a.q P1 Γ ` rollP t : q P (T-Roll) Γ `t:P

P = rec a.q P1

Γ ` unroll t : [a , P]q P1 un (Γ )

(T-Unroll)

Γ , f:un T1 →T2 , x:T1 ` t : T2

Γ ` fun f(x:T1 ):T2 .t : un T1 →T2 (T-TFun) Figure 1-10: Linear lambda calculus: Sums and recursive types

of sums and recursive types, we will normally omit the typing annotations on their introduction forms in our examples. In order to write computations that process recursive types, we add recursive function declarations to our language as well. Since the free variables in a recursive function closure will be used on each recursive invocation of the function, we cannot allow the closure to contain linear variables. Hence, all recursive functions are unrestricted data structures. A simple but useful data structure is the linear list of Ts: type T llist = rec a.lin (unit + lin (T * lin a)) Here, the entire spine (aside from the terminating value of unit type) is linear while the underlying T objects may be linear or unrestricted. To create a fully unrestricted list, we simply omit the linear qualifiers on the sum and pairs that make up the spine of the list: type T list = rec a.unit + T * a


19

After defining the linear lists, the memory conscious programmer can write many familiar list-processing functions in a minimal amount of space. For example, here is how we map an unrestricted function across a linear list. Remember, multi-argument functions are abbreviations for functions that accept linear pairs as arguments. fun nil(_:unit) : T2 llist = roll (lin inl ()) fun cons(hd:T2 , tl:T2 llist) : T2 llist = roll (lin inr (lin )) fun map(f:T1 →T2 , xs:T1 llist) : T2 llist = case unroll xs ( inl _ ⇒ nil() | inr xs ⇒ split xs as hd,tl in cons(f hd,map lin ))

In this implementation of map, we can observe that on each iteration of the loop, it is possible to reuse the space deallocated by split or case operations for the allocation operations that follow in the body of the function (inside the calls to nil and cons). Hence, at first glance, it appears that map will execute with only a constant space overhead. Unfortunately, however, there are some hidden costs as map executes. A typical implementation will store local variables and temporaries on the stack before making a recursive call. In this case, the result of f hd will be stored on the stack while map iterates down the list. Consequently, rather than having a constant space overhead, our map implementation will have an O(n) overhead, where n is the length of the list. This is not too bad, but we can do better. In order to do better, we need to avoid implicit stack allocation of data each time we iterate through the body of a recursive function. Fortunately, many functional programming languages guarantee that if the last operation in a function is itself a function call then the language implementation will deallocate the current stack frame before calling the new function. We name such function calls tail calls and we say that any language implementation that guarantees that the current stack frame will be deallocated before a tail call is tail-call optimizing. Assuming that our language is tail-call optimizing, we can now rewrite map so that it executes with only a constant space overhead. The main trick involved is that we will explicitly keep track of both the part of the input list we have yet to process and the ouput list that we have already processed. The

20


output list will wind up in reverse order, so we will reverse it at the end. Both of the loops in the code, mapRev and reverse are tail-recursive functions. That is, they end in a tail call and have a space-efficient implementation. fun map(f:T1 →T2 , input:T1 llist) : T2 llist = reverse(mapRev(f,input,nil()),nil()) and mapRev(f:T1 →T2 , input:T1 llist, output:T2 llist) : T2 llist = case unroll input ( inl _ ⇒ output | inr xs ⇒ split xs as hd,tl in mapRev (f,tl,cons(f hd,output))) and reverse(input:T2 llist, output:T2 llist) case unroll input ( inl _ ⇒ output | inr xs ⇒ split xs as hd,tl in reverse(tl,cons(hd,output)))

This link reversal algorithm is a well-known way of traversing a list in constant space. It is just one of a class of algorithms developed well before the invention of linear types. A similar algorithm was invented by Deutsch, Schorr, and Waite for traversing trees and graphs in constant space. Such constant space traversals are essential parts of mark-sweep garbage collectors— at garbage collection time there is no extra space for a stack so any traversal of the heap must be done in constant space. 1.3.1

Exercise [«««]: Define a recursive type that describes linear binary trees that hold data of type T in their internal nodes (nothing at the leaves). Write a constant-space function treeMap that produces an identically-shaped tree on output as it was given on input, modulo the action of the function f that is applied to each element of the tree. Feel free to use reasonable extensions to our linear lambda calculus including mutually recursive functions, n-ary tuples and n-ary sums. 2

Polymorphism Parametric polymorphism is a crucial feature of almost any functional language, and our linear lambda calculus is no exception. The main function of polymorphism in our setting is to support two different sorts of code reuse.


21

1. Reuse of code to perform the same algorithm, but on data with different shapes. 2. Reuse of code to perform the same algorithm, but on data governed by different memory management strategies. To support the first kind of polymorphism, we will allow quantification over pretypes. To support the second kind of polymorphism, we will allow quantification over qualifiers. A good example of both sorts of polymorphism arises in the definition of a polymorphic map function. In the code below, we use a and b to range over pretype variables as we did in the previous section, and p to range over qualifier variables. type (p1 ,p2 ,a) list = rec a.p1 (unit + p1 (p2 a * (p1 ,p2 ,a) list)) map : ∀a,b. ∀pa ,pb . lin ((pa a → pb b)*(lin,pa ,a) list)→(lin,pb ,b) list

The type definition in the first line defines lists in terms of three parameters. The first parameter, p1 , gives the usage pattern (linear or unrestricted) for the spine of the list, while the second parameter gives the usage pattern for the elements of the list. The third parameter is a pretype parameter, which gives the (pre)type of the elements of list. The map function is polymorphic in the argument (a) and result (b) element types of the list. It is also polymorphic (via parameters pa and pb ) in the way those elements are used. Overall, the function maps lists with linear spines to lists with linear spines. Developing a system for polymorphic, linear type inference is a challenging research topic, beyond the scope of this book, so we will assume that, unlike in ML, polymorphic functions are introduced explicitly using the syntax Λa.t or Λp.t. Here, a and p are the type parameters to a function with body t. The body does not need to be a value, like in ML, since we will run the polymorphic function every time a pretype or qualifier is passed to the function as an argument. The syntax t0 [P] or t0 [q] applies the function t0 to its pretype or qualifier argument. Figure 1-11 summarizes the syntactic extensions to the language. Before we get to writing the map function, we will take a look at the polymorphic constructor functions for linear lists. These functions will take a pretype parameter and two qualifier parameters, just like the type definition for lists.

22


q ::= ... p t ::= ... q Λa.t t [P]

qualifiers: as before polymorphic qualifier terms: as before pretype abstraction pretype application

q Λp.t t [q] P ::= ... ∀a.T ∀p.T

qualifier abstraction qualifier application pretypes: as before pretype polymorphism qualifier polymorphism

Figure 1-11: Linear lambda calculus: Polymorphism syntax

val nil : ∀a,p2 .(lin,p2 ,a) list = Λ a,p2 .roll (lin inl ()) val list : ∀a,p2 .lin (p2 a * (lin,p2 ,a) list)→(lin,p2 ,a) list = Λ a,p2 . λcell : lin (p2 a * (lin,p2 ,a) list). roll (lin inr (lin cell))

Now our most polymorphic map function may be written as follows. val map = Λ a,b. Λ pa ,pb . fun aux(f:(pa a → pb b), xs:(lin,pa ,a) list)) : (lin,pb ,b) list = case unroll xs ( inl _ ⇒ nil [b,pb ] () | inr xs ⇒ split xs as hd,tl in cons [b,pb ] (pb ))

In order to ensure that our type system remains sound in the presence of pretype polymorphism, we add the obvious typing rules, but change very little else. However, adding qualifier polymorphism, as we have done, is a little more involved. Before arriving at the typing rules themselves, we need to adapt some of our basic definitions to account for abstract qualifiers that may either be linear or unrestricted. First, we need to ensure that we propagate contexts containing abstract qualifiers safely through the other typing rules in the system. Most importantly, we add additional cases to the context manipulation rules defined in the previous section. We need to ensure that linear hypotheses are not duplicated and therefore we cannot risk duplicating unknown qualifiers, which might turn out to be linear. Figure 1-12 specifies the details.

23


Γ = Γ1 ◦ Γ2

Γ = Γ1 ◦ Γ2

Context Split Γ = Γ1 ◦ Γ2 Γ , x:p P = (Γ1 , x:p P) ◦ Γ2

(M-Abs1)

Γ , x:p P = Γ1 ◦ (Γ2 , x:p P)

(M-Abs2)

Figure 1-12: Linear context manipulation rules

type contexts: empty pretype var. qualifier var.

∆ ::= ∅ ∆, a ∆, p

∆; Γ ` t : T

Typing q(Γ )

∆, a; Γ ` t : T

∆; Γ ` q Λa.t : q ∀a.T

∆; Γ ` t : q ∀a.T

FV(P) ⊆ ∆

∆; Γ ` t [P] : [a , P]T q(Γ )

∆, p; Γ ` t : T

∆; Γ ` q Λp.t : q ∀p.T ∆; Γ ` t : q1 ∀p.T

FV(q) ⊆ ∆

∆; Γ ` t [q] : [p , q]T

(T-PAbs)

(T-PApp) (T-QAbs) (T-QApp)

Figure 1-13: Linear lambda calculus: Polymorphic typing

Second, we need to conservatively extend the relation on type qualifiers q1 vq2 so that it is sound in the presence of qualifier polymorphism. Since the linear qualifier is the least qualifier in the current system, the following rule should hold. lin v p

(Q-LinP)

Likewise, since un is the greatest qualifier in the system, we can be sure the following rule is sound. p v un

(Q-PUn)

Aside from these rules, we will only be able to infer that an abstract qualifier p is related to itself via the general reflexivity rule. Consequently, linear data structures can contain abstract ones; abstract data structures can contain unrestricted data structures; and data structure with qualifier p can contain other data with qualifier p. In order to define the typing rules for the polymorphic linear lambda calculus proper, we need to change the judgment form to keep track of the type variables that are allowed to appear free in a term. The new judgment uses the type context ∆ for this purpose. The typing rules for the introduction and elimination forms for each sort of polymorphism are fairly straightforward now and are presented in Figure 1-13.

24


The typing rules for the other constructs we have seen are almost unchanged. One relatively minor alteration is that the incoming type context ∆ will be propagated through the rules to account for the free type variables. Unlike term variables, type variables can always be used in an unrestricted fashion; it is difficult to understand what it would mean to restrict the use of a type variable to one place in a type or term. Consequently, all parts of ∆ are propagated from the conclusion of any rule to all premises. We also need the occasional side condition to check that whenever a programmer writes down a type, its free variables are contained in the current type context ∆. For instance the rules for function abstraction and application will now be written as follows. q(Γ ) FV(T1 ) ⊆ ∆ ∆; Γ , x:T1 ` t2 : T2 (T-Abs) ∆; Γ ` q λx:T1 .t2 : q T1 →T2 ∆; Γ1 ` t1 : q T1 →T2

∆; Γ2 ` t2 : T1

∆; Γ1 ◦ Γ2 ` t1 t2 : T2

(T-App)

The most important way to test our system for faults is to prove the type substitution lemma. In particular, the proof will demonstrate that we have made safe assumptions about how abstract type qualifiers may be used. 1.3.2

Lemma [Type Substitution]: 1. If ∆, p; Γ ` t : T and FV(q) ∈ ∆ then ∆; [p , q]Γ ` [p , q]t : [p , q]T 2. If ∆, a; Γ ` t : T and FV(P) ∈ ∆ then ∆; [a , P]Γ ` [a , P]t : [a , P]T 2

1.3.3

Exercise [«]: Sketch the proof of the type substitution lemma. What structural rule(s) do you need to carry out the proof? 2 Operationally, we will choose to implement polymorphic instantiation using substitution. As a result, our operational semantics changes very little. We only need to specify the new computational contexts and to add the evaluation rules for polymorphic functions and application as in Figure 1-14.

Arrays Arrays pose a special problem for linearly typed languages. If we try to provide an operation fetches an element from an array in the usual way, perhaps using an array index expression a[i], we would need to reflect the fact that the ith element (and only the ith element) of the array had been “used.” However, there is no simple way to reflect this change in the type of an array as the usual form of array types (array(T)) provides no mechanism to distinguish between the properties of different elements of the array.

25


E ::= E [P] E [q]

evaluation contexts: pretype app context qualifier app context

(S;q Λa.t) -→β (S, x , q Λa.t;x)

(E-PFun)

S(x) = q Λa.t q

(S;x [P]) -→β (S ∼ x;[a , P]t)

(E-PApp)

(S;q Λp.t) -→β (S, x , q Λp.t;x) (E-QFun) S(x) = q Λp.t q

(S;x [q1 ]) -→β (S ∼ x;[p , q1 ]t)

(E-QApp)

Figure 1-14: Linear lambda calculus: Polymorphic operational semantics

We dodged this problem when we constructed our tuple operations by defining a pattern matching construct that simultaneously extracted all of the elements of a tuple. Unfortunately, we cannot follow the same path for arrays because in modern languages like Java and ML, the length of an array (and therefore the size of the pattern) is unknown at compile time. Another non-solution to the problem is to add a special built-in iterator to process all the elements in an array at once. However, this last prevents programmers from using arrays as efficient, constant-time, random-access data structures; they might as well use lists instead. One way out of this jam is to design the central array access operations so that, unlike the ordinary “get” and “set” operations, they preserve the number of pointers to the array and the number of pointers to each of its elements. We avoid our problem because there is no change to the array data structure that needs to be reflected in the type system. Using this idea, we will be able to allow programmers to define linear arrays that can hold a collection of arbitrarily many linear objects. Moreover, programmers will be able to access any of these linear objects, one at a time, using a convenient, constant-time, random-access mechanism. So, what are the magic pointer-preserving array access operations? Actually, we need only one: a swap operation with the form swap (a[i],t). The swap replaces the ith element of the array a (call it t0 ) with t and returns a (linear) pair containing the new array and t0 . Notice the number of pointers to t and t0 does not change during the operation. If there was one pointer to t (as an argument to swap) before the call, then there is one pointer to t afterward (from within the array a) and vice versa for t0 . If, in addition, all of the elements of a had one pointer to them before the swap, then they will all have one pointer to them after the swap as well. Consequently, we will find it easy to type the swap operation, even when it works over linear arrays of linear objects.

26


In addition to swap, we provide functions to allocate an array given its list of elements (array), to determine array length (length) and to deallocate arrays (free). The last operation is somewhat unusual in that it takes two arguments a and f, where a is an array of type lin array(T) and f is a function with type T→unit that is run on each element of T. The function may be thought of as a finalizer for the elements; it may be used to deallocate any linear components of the array elements, thereby preserving the single pointer property. Our definition of arrays is compatible with the polymorphic system from the previous subsection, but for simplicity, we formalize it in the context of the simply-typed lambda calculus (see Figure 1-15). 1.3.4

Exercise [Recommended, «]: The typing rule for array allocation (T-Array) contains the standard containment check to ensure that unrestricted arrays cannot contain linear objects. What kinds of errors can occur if this check is omitted? 2

1.3.5

Exercise [««, 3]: With the presence of mutable data structures, it is possible to create cycles in the store. How should we modify the store typing rules to take this into account? 2 The swap and free functions are relatively low-level operations. Fortunately, it is easy to build more convenient, higher-level abstractions out of them. For instance, the following code defines some simple functions for manipulating linear matricies of unrestricted integers. type iArray = lin array(int) type matrix = lin array(iArray) fun dummy(x:unit):iArray = lin array() fun freeElem(x:int):unit = () fun freeArray(a:iArray):unit = free(a,freeElem) fun freeMatrix(m:matrix):unit = free(m,freeArray) fun get(a:matrix,i:int,j:int):lin (matrix * int) = split swap(a[i],dummy()) as a,b in split swap(b[j],0) as b,k in split swap(b[j],k) as b,_ in split swap(a[i],b) as a,junk in freeArray(junk); lin

27


P ::= ... array(T) t ::= ... q array(t, . . . ,t) swap(t[t],t) length(t) free(t,t) w ::= ... array[n,x, . . . ,x] E ::=

pretypes: as before array pretypes terms: as before array creation swap length deallocate prevalues: as before array

evaluation contexts: ... as before q array(v, . . . ,v,E,t, . . . ,t) array context swap(E(t),t) swap context swap(v(E),t) swap context swap(v(v),E) swap context length(E) length context free(E,t) free context free(v,E) free context

Γ `t:T

Typing q(T)

Γ ` ti : T

(for 1 ≤ i ≤ n)

Γ ` q array(t1 , . . . ,tn ) : q array(T) (T-Array) Γ ` t1 : q1 array(T1 ) Γ ` t2 : q2 int Γ ` t3 : T1 (T-Swap) Γ ` swap(t1 [t2 ],t3 ) : lin (q1 array(T1 ) * T1 ) Γ ` t : q array(T) Γ ` length(t) : lin (q array(T) * int) (T-Length) Γ ` t1 : q array(T) Γ ` t2 : T → unit Γ ` free(t1 ,t2 ) : unit (T-Free) (S;t) -→β (S0 ;t0 )

Evaluation

(S;q array(x0 , . . . ,xn−1 )) -→β ((S, x , q array[n,x0 , . . . ,xn−1 ];x) (E-Array) S(xi ) = qi j S = S1 , xa , q array[n, . . . ,xj , . . . ], S2 S0 = S1 , xa , q array[n, . . . ,xe , . . . ], S2 (S; swap(xa [xi ],xe )) qi

-→β (S0 ∼ xi ;lin <xa ,xj >) (E-Swap) S(x) = q array[n,x0 , . . . ,xn−1 ] (S;length(x)) -→β (S;lin <x,un n>) (E-Length) S(xa ) = q array[n,x0 , . . . ,xn−1 ] (S;free(xa ,xf )) q

-→β (S ∼ xa ;App(xf ,x0 , . . . ,xn−1 )) (E-Free) where App(xf ,·) = () App(xf ,x0 ,. . . ) = xf x0 ;App(xf ,. . . ) Figure 1-15: Linear lambda calculus: Arrays

28


fun set(a:matrix,i:int,j:int,e:int):matrix = split swap(a[i],dummy()) as a,b in split swap(b[j],e) as b,_ in split swap(a[i],b) as a,junk in freeArray(junk); a

1.3.6

Exercise [««, 3]: Use the functions provided above to write matrix-matrix multiply. Your multiply function should return an integer and deallocate both arrays in the process. Use any standard integer operations necessary. 2 In the examples above, we needed some sort of dummy value to swap into an array to replace the value we wanted to extract. For integers and arrays it was easy to come up with one. However, when dealing with polymorphic or abstract types, it may not be possible to conjure up a value of the right type. Consequently, rather than manipulating arrays with type q array(a) for some abstract type a, we may need to manipulate arrays of options with type q array(a + unit). In this case, when we need to read out a value, we always have another value (inr ()) to swap in in its place. Normally such operations are called destructive reads; they are a common way to preserve the single pointer property when managing complex structured data.

Reference Counting Array swaps and destructive reads are dynamic techniques that can help overcome a lack of compile-time knowledge about the number of uses of a particular object. Reference counting is another dynamic technique that serves a similar purpose. Rather than restricting the number of pointers to an object to be exactly one, we can allow any number of pointers to the object and keep track of that number dynamically. Only when the last reference is used will the object be deallocated. There are various ways to integrate reference counts into the current system. Here, we choose the simplest, which is to add a new qualifier rc for reference-counted data structures, and operations that allow the programmer to explicitly increment (inc) and decrement (dec) the counts (see Figure 1-16). More specifically, the increment operation takes a pointer argument, increments the reference count for the object pointed to, and returns two copies of the pointer in a (linear) pair. The decrement operation takes two arguments, a pointer and a function, and works as follows. In the case the object pointed to (call it x) has a reference count of 1 before the decrement, the function is executed with x as a linear argument. Since the function treats x

29


Syntax q ::=

Qualifier Relations ... rc

t ::= ... inc(t) dec(t,t)

qualifiers: as before ref. count terms: as before increment count decrement count

rc v un

(Q-RCUn)

lin v rc

(Q-LinRC) Γ `t:T

Typing Γ ` t : rc P

(T-Inc)

Γ ` inc(t) : lin (rc P * rc P) Γ ` t1 : rc P

Γ ` t2 : lin P → unit

Γ ` dec(t1 ,t2 ) : unit (T-Dec) Figure 1-16: Linear lambda calculus: Reference counting syntax and typing

linearly, it will deallocate x before it completes. In the other case, when x has a reference count greater than 1, the reference count is simply decremented and the function is not called; unit is returned as the result of the operation. The main typing invariant in this system is that whenever a referencecounted variable appears in the static type-checking context, there is one dynamic reference count associated with it. Linear typing will ensure the number of references to an object is properly preserved. The new rc qualifier should be treated in the same manner as the linear qualifier when it comes to context splitting. In other words, a referencecounted variable should be placed in exactly one of the left-hand context or the right-hand context (not both). In terms of containment, the rc qualifier sits between unrestricted and linear qualifiers: A reference-counted data structure may not be contained in unrestricted data structures and may not contain linear data structures. Figure 1-16 presents the appropriate qualifier relation and typing rules for our reference counting additions. In order to define the execution behavior of reference-counted data structures, we will define a new sort of stored value with the form rc(n) w. The integer n is the reference count: it keeps track of the number of times the value is referenced elsewhere in the store or in the program. The operational semantics for the new commands and reference-counted pairs and functions are summarized in Figure 1-17. Several new bits of notation show up here to handle the relatively complex computation that must go on to increment and decrement reference counts. First, in a slight abuse of notation, we allow q to range over static qualifiers un, lin and rc as well as dynamic qualifiers un, lin and rc(n). Context will disambiguate the two

30

1 Substructural Type Systems q

different sorts of uses. Second, we extend the notation S∼x so that q may rc(n)

be rc(n) as well as lin and un. If n is 1 then S ∼ x removes the binding rc(n)

x,rc(n) w from S. Otherwise, S ∼ x replaces the binding x,rc(n) w with x,rc(n-1) w. Finally, given a store S and a set of variables X, we define the function incr(S;X), which produces a new store S0 in which the reference count associated with any reference-counted variables x∈X is increased by 1. To understand how the reference counting operational semantics works, we will focus on the rules for pairs. Allocation and use of linear and unrestricted pairs stays unchanged from before as in rules (E-Pair’) and (E-Split’). Rule (E-PairRC) specifies that allocation of reference-counted pairs is similar to allocation of other data, except for the fact that the dynamic reference count must be initialized to 1. Use of reference-counted pairs is identical to use of other kinds of pairs when the reference count is 1: We remove the rc(n)

pair from the store via the function S ∼ x as shown in rule and substitute the two components of the pair in the body of the term as shown in (E-Split’). When the reference count is greater than 1, rule (E-SplitRC) shows there are additional complications. More precisely, if one of the components of the pair, say y1 , is reference-counted then y1 ’s reference count must be increased by 1 since an additional copy of y1 is substituted through the body of t. We use the incr function to handle the possible increase. In most respects, the operational rules for reference-counted functions follow the same principles as reference-counted pairs. Increment and decrement operations are also relatively straightforward. In order to state and prove the progress and preservation lemmas for our reference-counting language, we must generalize the type system slightly. In particular, our typing contexts must be able specify the fact that a particular reference should appear exactly n times in the store or current computation. Reference-counted values in the store are described by these contexts and the context-splitting relation is generalized appropriately. Figure 1-18 summarizes the additional typing rules. 1.3.7

1.4

Exercise [«««, 3]: State and prove progress and preservation lemmas for the simply-typed linear lambda calculus (functions and pairs) with reference counting. 2

An Ordered Type System Just as linear type systems provide a foundation for managing memory allocated on the heap, ordered type systems provide a foundation for managing memory allocated on the stack. The central idea is that by controlling the

31

1.4 An Ordered Type System

values: as before ref-counted value

v ::= ... rc(n) w E ::= ... inc(E) dec(E,t) dec(x,E) Evaluation

evaluation contexts: as before inc context dec context dec context 0

0

(S;t) -→β (S ;t ) (q ∈ {un,lin})

(S;q ) -→β (S, x , q ;x) (E-Pair’) (S;rc ) -→β (S, x , rc(1) ;x) S(x) = q (q ∈ {un,lin,rc(1)}) (S;split x as y,z in t) -→β

(E-PairRC)

(E-Split’)

(S;q λy:T.t) -→β (S, x , q λy:T.t;x) (E-Fun’) (S;rc λy:T.t) -→β (E-FunRC) (S, x , rc(1) λy:T.t;x) S(x1 ) = q λy:T.t (q ∈ {un,lin,rc(1)}) q

(S;x1 x2 ) -→β (S ∼ x1 ;[y , x2 ]t)

(E-App’)

S(x1 ) = rc(n) λy:T.t (n > 1 and X = FV(λy:T.t)) incr(S;X) = S0 (S;x1 x2 ) -→β (S0

rc(n)

∼ x1 ;[y , x2 ]t) (E-AppRC) 0 incr(S;{x}) = S (E-Inc) (S;inc(x)) -→β (S0 ;lin <x,x>) (S(x) = rc(n) w)

(n > 1) rc(n)

q

(S;dec(x,xf )) -→β (S ∼ x;un ()) (E-Dec1) S = S1 ,x , rc(1) w,S2 S0 = S1 ,x , lin w,S2 (E-Dec2) (S;dec(x,xf )) -→β (S0 ;xf x)

(S ∼ x;[y , y1 ][z , z1 ]t) S(x) = rc(n) (n > 1) incr(S;{y1 ,z1 }) = S0 (S;split x as y,z in t) -→β ((S0

(q ∈ {un,lin})

rc(n)

∼ x);[y , y01 ][z , z01 ]t) (E-SplitRC)

Figure 1-17: Linear lambda calculus: Reference counting operational semantics

exchange property, we are able to guarantee that certain values, those values allocated on the stack, are used in a first-in/last-out order. To formalize this idea, we organize the store into two parts: a stack, which is a sequence of locations that can be accessed on one end (the “top”) and a heap, which is like the store described in previous sections of this chapter. Pairs, functions and other objects introduced with unrestricted or linear qualifiers are allocated on the heap as before. And as before, when a linear pair or function is used, it is deallocated. Also, we allow programmers to allocate simple data structures on the stack. Without the exchange property, an ordered object can only be used when it is at the top of the stack. When this happens, the ordered object is popped off the top of the stack.

32


Syntax Γ ::= ... Γ , x:rc(n)P Store Typing ` S : Γ1 ◦ Γ2

typing contexts: as before rc(n) context

Γ1 ` rc w : rc P

` S,x , rc(n) w : Γ2 , x:rc(n) P

Context Splitting Γ = Γ1 ◦ Γ2

n=i+j

Γ , x:rc(n)P = (Γ1 , x:rc(i)P) ◦ (Γ2 , x:rc(j)P)

(M-RC)

(when i or j is 0, the corresponding binding is removed from the context) (T-NextrcS) Variable Typing un (Γ1 , Γ2 ) Γ1 , x:rc(1)P, Γ2 ` x : rc P

(T-RCVar)

Figure 1-18: Linear lambda calculus: Reference counting run-time typing

Syntax The overall structure and mechanics of the ordered type system are very similar to the linear type system developed in previous sections. Figure 1-19 presents the syntax. One key change from our linear type system is that we have introduced an explicit sequencing operation let x = t1 in t2 that first evaluates the term t1 , binds the result to x, and then continues with the evaluation of t2 . This sequencing construct gives programmers explicit control over the order of evaluation of terms, which is crucial now that we are introducing data that must be used in a particular order. Terms that normally can contain multiple nested subexpressions such as pair introduction and function application are syntactically restricted so that their primary subterms are variables and the order of evaluation is clear. The other main addition is a new qualifier ord that marks data allocated on the stack. We only allow pairs and values with base type to be stack-allocated; functions are allocated on the unordered heap. Therefore, we declare types ord T1 → T2 and terms ord λx:T.t to be syntactically ill-formed. Ordered assumptions are tracked in the type checking context Γ like other assumptions. However, they are not subject to the exchange property. Moreover, the order that they appear in Γ mirrors the order that they appear on the stack, with the rightmost position representing the stack’s top.

Typing The first step in the development of the type system is to determine how assumptions will be used. As before, unrestricted assumptions can be used

33


Syntax q ::= ord lin un t ::= x qb if t then t else t q <x,y> split t as x,y in t q λx:T.t

qualifiers: ordered linear unrestricted terms: variable Boolean conditional pair split abstraction

xy let x = t in t P ::= Bool T*T T→T T ::= qP Γ

::= ∅ Γ , x:T

application sequencing pretypes: booleans pairs functions types: qualified pretype contexts: empty context term variable binding

Figure 1-19: Ordered lambda calculus: Syntax

as often as the programmer likes but linear assumptions must be used exactly once along every control flow path. Ordered assumptions must be used exactly once along every control flow path,in the order in which they appear. As before, the context splitting operator (Γ = Γ1 ◦ Γ2 ) helps propagate assumptions properly, separating the context Γ into Γ1 and Γ2 . Some sequence of ordered assumptions taken from the left-hand side of Γ are placed in Γ1 and the remaining ordered assumptions are placed in Γ2 . Otherwise, the splitting operator works the same as before. In the typing rules, the context Γ2 is used by the first subexpression to be evaluated (since the top of the stack is at the right) and Γ1 is used by the second subexpression to be evaluated. Formally, we define the "=" relation in terms of two subsidiary relations: "=1 ," which places ordered assumptions in Γ1 , and "=2 ," which places ordered assumptions in Γ2 . See Figure 1-20. The second step in the development of the type system is to determine the containment rules for ordered data structures. Previously, we saw that if an unrestricted object can contain a linear object, a programmer can write functions that duplicate or discard linear objects, thereby violating the central invariants of the system. A similar situation arises if linear or unrestricted objects can contain stack objects; in either case, the stack object might be used out of order, after it has been popped off the stack. The typing rules use the qualifier relation q1 vq2 , which specifies that ordvlinvun, to ensure such problems do not arise. The typing rules for the ordered lambda calculus appear in Figure 1-21. For the most part, the containment rules and context splitting rules encapsulate

34


Γ =1 Γ1 ◦ Γ2

Γ = Γ1 ◦ Γ2

Context Split Γ =2 Γ1 ◦ Γ2 Γ = Γ1 ◦ Γ2 ∅ =1 ∅ ◦ ∅ Γ =1 Γ1 ◦ Γ2 Γ , x:ord P =1 (Γ1 , x:ord P) ◦ Γ2 Γ =2 Γ1 ◦ Γ2 Γ , x:ord P =2 Γ1 ◦ (Γ2 , x:ord P)

Γ =2 Γ1 ◦ Γ2

(M-Top) (M-Empty) (M-Ord1) (M-Ord2)

Γ =1,2 Γ1 ◦ Γ2 Γ , x:lin P =1,2 (Γ1 , x:lin P) ◦ Γ2 Γ =1,2 Γ1 ◦ Γ2 Γ , x:lin P =1,2 Γ1 ◦ (Γ2 , x:lin P)

(M-1to2) (M-LinA) (M-LinB)

Γ =1,2 Γ1 ◦ Γ2 Γ , x:un P =1,2 (Γ1 , x:un P) ◦ (Γ2 , x:un P) (M-Un)

Figure 1-20: Ordered lambda calculus: Context splitting

the tricky elements of the type system. The rules for pairs illustrate how this is done. The rule for introducing pairs (T-OPair) splits the incoming context into two parts, Γ1 and Γ2 ; any ordered assumptions in Γ2 will represent data closer to the top of the stack than Γ1 . Therefore, if the pair (x) and its two components x1 and x2 are all allocated on the stack, then the pointer x will end up on top, x2 next and x1 on the bottom. The elimination rule for pairs (T-OSplit) is careful to maintain the proper ordering of the context. As above, the rule splits the context into Γ1 and Γ2 , where Γ2 , which represents data on top of the stack, is used in a computation t1 that generates a pair. The context Γ1 , x1 :T1 , x2 :T2 is used to check t2 . Notice that if both components of the pair, x1 and x2 , were allocated on the stack when the pair was introduced, they reappear back in the context in the appropriate order. Consider the following function, taking a boolean and a pair allocated sequentially at the top of the stack. The boolean is at the very top of the stack and the integer pair is next (the top is to the right). If the boolean is true, it leaves the components of the pair (two unrestricted integers) in the same order as given; otherwise, it swaps them. λx:ord (ord (int * int) * bool). split x as p,b in if b then p else split p as i1,i2 in ord

35


Γ2 ` t1 : q (T1 *T2 ) Γ1 , x1 :T1 , x2 :T2 ` t2 : T

Γ `t:T

Typing un (Γ1 , Γ2 )

(T-OVar)

Γ1 , x:T, Γ2 ` x : T un (Γ )

(T-OBool)

Γ ` q b : q Bool Γ2 ` t1 : q Bool Γ1 ` t2 : T Γ 1 ` t3 : T

Γ1 ` x1 : q T11 →T12

Γ 2 ` x2 : T2 q(T2 )

Γ1 ◦ Γ2 ` q <x1 ,x2 > : q (T1 *T2 )

Γ2 ` x2 : T11

Γ1 ◦ Γ2 ` x1 x2 : T12

(T-OIf)

Γ1 ◦ Γ2 ` if t1 then t2 else t3 : T Γ 1 ` x1 : T1 q(T1 )

Γ1 ◦ Γ2 ` split t1 as x1 ,x2 in t2 : T (T-OSplit) q(Γ ) Γ , x:T1 ` t2 : T2 (T-OAbs) Γ ` q λx:T1 .t2 : q T1 →T2

Γ 2 ` t1 : T1 Γ1 , x:T1 ` t2 : T2 (T-OPair)

Γ1 ◦ Γ2 ` let x = t1 in t2 : T2

(T-OApp)

(T-OLet)

Figure 1-21: Ordered lambda calculus: Typing

Operational Semantics To define the operational semantics for our new ordered type system, we will divide our previous stores into two parts, a heap H and a stack K. Both are just a list of bindings as stores were before (see Figure 1-22). We also define a couple of auxiliary functions. The first says what it means to add a binding to the store. This is straightforward: unrestricted and linear bindings are added to the heap and ordered bindings are added to the top of the stack. (H;K),x , ord w (H;K),x , lin w (H;K),x , un w

= = =

(H;K,x , ord w) (H,x , lin w;K) (H,x , un w;K)

The second function specifies how to remove a binding from the store. Notice that ordered deallocation will only remove the object at the top of the stack. ord

(H;K,x , v) ∼ x lin

(H1 ,x , v,H2 ;K) ∼ x un (H;K) ∼ x

=

H;K

= =

H1 ,H2 ;K H;K

With these simple changes, the evaluation rules from previous sections can be reused essentially unchanged. However, we do need to add the evaluation context for sequencing (let x = E in t) and its evaluation rule: (S;let x = x1 in t2 ) -→β (S;[x , x1 ]t1 )

(E-Let)

36


stores: complete store H ::= heap: ∅ empty heap H, x , lin w linear heap binding H, x , un w unrestricted heap binding S ::=

K ::=

H;K

∅ K, x , ord w

stack: empty stack stack binding

Figure 1-22: Ordered lambda calculus: Operational semantics

1.4.1

Exercise [Recommended, «]: Write a program that demonstrates what can happen if the syntax of pair formation is changed to allow programmers to write nested subexpressions (i.e., we allow the term ord rather than the term ord <x,y>). 2

1.4.2

Exercise [Recommended, ««]: Demonstrate the problem with allowing ordered functions (i.e., admitting the syntax ord λx:T1 .t and ord T1 → T2 ) by writing a well-typed program that uses ordered functions and gets stuck. 2

1.4.3

Exercise [«««]: Modify the language so that programmers can use stackallocated, ordered functions. There are many solutions to this problem, some more sophisticated than others. 2

1.5

Further Applications Memory management applications make good motivation for substructural type systems and provides a concrete framework for studying their properties. However, substructural types systems, and their power to control the number and order of uses of data and operations, have found many applications outside of this domain. In the following paragraphs, we informally discuss a few of them.

Controlling Temporal Resources We have studied several ways that substructural type systems can be used to control physical resources such as memory and files. What about controlling the temporal resources? Amazingly, substructural type systems can play a role here as well: Careful crafting of a language with an affine type system, where values are used at most once, can ensure that computations execute in polynomial time.

37

1.5 Further Applications

To begin, we will allow our polynomial time language to contain affine booleans, pairs and (non-recursive) functions. In addition, to make things interesting, we will add affine lists to our language, which have constructors nil and cons and a special iterator to recurse over objects with list type. Such iterators have the following form. iter (stop ⇒ t1 | x with y ⇒ t2 )

If t1 has type T and t2 also has type T (under the assumption that x has type T1 and y has type T1 list), our iterator defines a function from T1 lists to objects with type T. Operationally, the iterator does a case to see whether its input list is nil or cons(hd,tl) and executes the corresponding branch. We can define the operation of iterators using two simple rules.1 iter (stop ⇒ t1 | hd with rest ⇒ t2 ) nil -→β t1 iter (stop ⇒ t1 | hd with rest ⇒ t2 )

v2 -→∗ β

v02

iter (stop ⇒ t1 | hd with rest ⇒ t2 ) cons(v1 ,v2 ) -→β [hd , v1 ][rest , v02 ]t2

(E-IterNil) (E-IterCons)

In the second rule, the iterator is invoked inductively on v2 , giving the result v02 , which is used in term t2 . The familar append function below illustrates the use of iterators. val append : T list→T list→T list = iter ( stop ⇒ λ(l:T list).l | hd with rest ⇒ λ(l:T list).cons(hd,rest l))

When applied to a list l1 , append builds up a function that expects a second list l2 and concatenates l2 to the end of l1 . Clearly, append is a polynomial time function, a linear-time one in fact, but it is straightforward to write exponential time algorithms in the language as we have defined it so far. For instance: val double : T list→T list = iter (stop ⇒ nil | hd with rest ⇒ cons(hd,cons(hd,rest))) val exp : T list→T list = iter (stop ⇒ nil | hd with rest ⇒ double (cons(hd,rest))) 1. Since we are not interested in memory management here, we have simplified our operational semantics from previous parts of this chapter by deleting the explicit store and using substitution instead. The operational judgment has the form t -→β t0 and, in general, is defined similarly to the operational systems in TAPL.

38


The key problem here is that it is trivial to write iterators like double that increase the size of their arguments. After constructing one of these, we can use it as the inner loop of another, like exp, and cause an exponential blowup in running time. But this is not the only problem. Higher-order functions make it even easier to construct exponential-time algorithms: val compose = λ(fg:(T list→T list) * (T list→T list)). λ(x:T list). split fg as f,g in f (g x) val junk : T val exp2 : T list→T list→T list = iter ( stop ⇒ λ(l:T list).cons(junk,l) | hd with rest ⇒ λ(l:T list).compose l)

Fortunately, a substructural type system can be used to eliminate both problems by allowing us to define a class of non-size-increasing functions and by preventing the construction of troublesome higher-order functions, such as exp2 . The first step is to demand that all user-defined objects have affine type. They can be used zero or one times, but not more. This restriction immediately rules out programs such as exp2 . System defined operators like cons can be used many times. The next step is to put mechanisms in place to prevent iterators from increasing the size of their inputs. This can be achieved by altering the cons constructor so that it can only be applied when it has access to a special resource with type R. operator cons : (R,T,T list) → T list

There is no constructor for resources with type R so they cannot be generated out of thin air; we can only apply fcons as many times as we have resources. We also adapt the syntax for iterators as follows. iter (stop ⇒ t1 | hd with tl and r ⇒ t2 )

Inside the second clause of the iterator, we are only granted a single resource (r) with which to allocate data. Consequently, we can allocate at most one cons cell in t2 . This provides us with the power to rebuild a list of the same size, but we cannot write a function such as double that doubles the length of the list or exp that causes an exponential increase in size. To ensure that

1.5 Further Applications

39

a single resource from an outer scope does not percolate inside the iterator and get reused on each iteration of the loop, we require that iterators be closed, mirroring the containment rules for recursive functions defined in earlier sections of this chapter. Although restricted to polynomial time, our language permits us to write many useful functions in a convenient fashion. For instance, we can still write append much like we did before. The resource we acquire from destructing the list during iteration can be used to rebuild the list later. val append : T list → T list → T list = iter ( stop ⇒ λ(l:T list).l | hd with rest and r ⇒ λ(l:T list). cons(r,hd,rest l))

We can also write double if our input list comes with appropriate credits, in the form of unused resources. val double : (T*R) list → T list = iter ( stop ⇒ nil | hd with rest and r1 ⇒ split hd as x,r2 in cons(r1,hd,cons(r2,hd,rest)))

Fortunately, we will never be able to write exp, unless, of course, we are given an exponential number of credits in the size of the input list. In that case, our function exp would still only run in linear time with respect to our overall input (list and resources included). The proof that all (first-order) functions we can define in this language run in polynomial time uses some substantial domain theory that lies outside the scope of this book. However, the avid reader should see Section 1.6 for references to the literature where these proofs can be found.

Compiler Optimizations Many compiler optimizations are enabled when we know that there will be at most one use or at least one use of a function, expression or data structure. If there is at most one use of an object then we say that object has affine type. If there is at least one use then we say the object has relevant (or strict) type. The following sorts of optimizations employ usage information directly; several of them have been implemented in the Glasgow Haskell Compiler. • Floating in bindings. Consider the expression let x = e in (λy....x...). Is it a good idea to float the binding inside the lambda and create the new

40


expression λy.let x = e in (...x...)? The answer depends in part on how many times the resulting function is used. If it is used at most once, the optimization might be a good one: we may avoid computing e and will never compute it more than once. • Inlining expressions. In the example above, if we have the further information that x itself is used at most once inside the body of the function, then we might want to substitute the expression e for x. This may give rise to further local optimizations at the site where e is used. Moreover, if it turns out that e is used zero times (as opposed to one time) we will have saved ourselves the trouble of computing it. • Thunk update avoidance. In lazy functional languages such as Haskell, evaluation of function parameters is delayed until the parameter is actually used in the function body. In order to avoid recomputing the value of the parameter each time it is used, implementers make each parameter a thunk—a reference that may either hold the computation that needs to be run or the value itself. The first time the thunk is used, the computation will be run and will produce the necessary result. In general, this result is stored back in the thunk for all future uses of the parameter. However, if the compiler can determine that the data structure is used as most once, this thunk update can be avoided. • Eagerness. If we can tell that a Haskell expression is used at least once, then we can evaluate it right away and avoid creating a thunk altogether. The optimizations described above may be implemented in two phases. The first phase is a program analysis that may be implemented as affine and/or relevant type inference. After the analysis phase, the compiler uses the information to transform programs. Formulating compiler optimizations as type inference followed by type-directed translation has a number of advantages over other techniques. First, the language of types can be used to communicate optimization information across modular boundaries. This can facilitate the process of scaling intra-procedural optimizations to inter-procedural optimizations. Second, the type information derived in one optimization pass can be maintained and propagated to future optimization passes or into the back end of the compiler where it can be used to generate Typed Assembly Language or Proof-Carrying Code, as discussed in Chapters 4 and 5.

1.6

Notes Substructural logics are very old, dating back to at least Orlov (1928), who axiomatized the implicational fragment of relevant logic. Somewhat later, Moh

1.6 Notes

41

(1950) and Church (1951) provided alternative axiomatizations of the relevant logic now known as R. In the same time period, Church was developing his theory of the lambda calculus at Princeton University, and his λI calculus (1941), which disallowed abstraction over variables that did not appear free in the body of the term, was the first substructural lambda calculus. Lambek (1958) introduced the first “ordered logic,” and used it to reason about natural language sentence structure. More recently, Girard (1987) developed linear logic, which gives control over both contraction and weakening, and yet provides the full power of intuitionistic logic through the unrestricted modality “!”. O’Hearn and Pym (1999) show that the logic of bunched implications provides another way to recapture the power of intuitionistic logic while giving control over the structural rules. For a comprehensive account of the history of substructural logics, please see Došen (1993), who is credited with coining the phrase “substructural logic,” or Restall (2005). Restall’s textbook on substructural logics (2000) provides good starting point to those looking to study the technical details of either the proof theory or model theory for these logics. Reynolds pioneered the study of substructural type systems for programming languages with his development of syntactic control of interference (1978; 1989), which prevents two references from being bound to the same variable and thereby facilitates reasoning about Algol programs. Later, Girard’s development of linear logic inspired many researchers to develop functional languages with linear types. One of the main applications of these new type systems was to control effects and enable in-place update of arrays in pure functional languages. Lafont (1988) was the one of the first to study programming languages with linear types, developing a linear abstract machine. He was soon followed by many other researchers, including Baker (1992) who informally showed how to compile Lisp into a linear assembly language in which all allocation, deallocation and pointer manipulation is completely explicit, yet safe. Another influential piece of work is due to Chirimar, Gunter, and Riecke (1996) who developed an interpretation of linear logic based on reference counting. The reference counting scheme described here is directly inspired by the work of Chirimar et al., but the technical setup is slightly different; we have explicit operations to increment and decrement reference counts whereas incrementing and decrementing counts in Chirimar’s system is done implicitly. Stephanie Weirich suggested the invariant for proving our reference counting system sound. Turner and Wadler (1999) summarize two computational interpretations that arise directly through the Curry-Howard isomorphism from Girard’s linear logic. They differ from the account given in this chapter as neither account has both shared, usable data structures and deallocation. Unfortunately, these two features together appear incompatible with a type

42


system derived directly from linear logic and its single unrestricted modality. The development of practical linear type systems with two classes of type, one linear and one unrestricted, began with Wadler’s work (1990) in the early nineties. The presentation given in this chapter is derived from Wadler’s work and is also inspired by work from Wansbrough and Peyton Jones (1999) and Walker and Watkins (2001). Wansbrough and Peyton Jones included qualifier subtyping and bounded parametric polymorphism in their system in addition to many of the features described here. Walker and Watkins added reference counting features to a language with linear types and also memory regions. The idea of formulating the system with a generic context splitting operator was taken from Cervesato and Pfenning’s presentation of Linear LF (2002). The algorithmic type system described in section 1-5 solves what is commonly known in the linear logic programming and theorem proving literature, as the resource management problem. Many of the ideas for the current presentation came from work by Cervesato, Hodas, and Pfenning (2000), who solve the more general problem that arises when linear logic’s additive connectives are considered. Hofmann takes a related approach when solving the type inference problem for a linearly-typed functional language (1997a). The ordered type system developed here is derived from Polakow and Pfenning’s ordered logic (1999), in the same way that the practical linear type systems mentioned above emerged from linear logic. It was also inspired by the ordered lambda calculus of Petersen, Harper, Crary, and Pfenning (2003), though there are some technical differences. Ahmed and Walker (2003) and Ahmed, Jia, and Walker (2003) use an ordered, modal logic to specify memory invariants and have integrated the logical specifications into a low-level typed language. Igarashi and Kobayashi (2002) have used ordered types to explore the more general problem of resource usage analysis. In addition, they have developed effective type inference algorithms for their type systems. Recently, O’Hearn (2003) has proposed bunched typing, a new form of substructural typing, to control interference between mutable variables, generalizing Reynolds’s earlier work on syntactic control of interference. These bunched types were derived from earlier work by O’Hearn and Pym (1999) on bunched logic. Together, Reynolds, Ishtiaq, and O’Hearn (Reynolds, 2000; Ishtiaq and O’Hearn, 2001) have used bunched logic to develop a system for verifying programs that explicitly allocate and deallocate data. Analysis and reasoning about the time and space complexity of programs has always been an important part of computer science. However, the use of programming language technology, and type systems in particular, to automatically constrain the complexity of programs is somewhat more recent. For instance, Bellantoni and Cook (1992) and Leivant (1993) developed predicative systems that control the use and complexity of recursive functions.

1.6 Notes

43

It is possible to write all, and only, the polynomial-time functions in their system. However, it is not generally possible to compose functions and therefore many “obviously” polynomial-time algorithms cannot be coded naturally in their system. Girard (1998), Hofmann (2000; 1999), and Bellantoni, Niggl, and Schwichtenberg (2000) show how linear type systems can be used to alleviate some of these difficulties. The material presented in this chapter is derived from Hofmann’s work. One of the most successful and extensive applications of substructural type systems in programming practice can be found in the Concurrent Clean programming language (Nöcker, Smetsers, van Eekelen, and Plasmeijer, 1991). Clean is a commercially developed, pure functional programming language. It uses uniqueness types (Barendsen and Smetsers, 1993), which are a variant of linear types, and strictness annotations (Nöcker and Smetsers, 1993) to help support concurrency, I/O and in-place update of arrays. The implementation is fast and is fully supported by a wide range of program development tools including an Integrated Development Environment for project management and GUI libraries, all developed in Clean itself. Substructural type systems have also found gainful employment in the intermediate languages of the Glasgow Haskell Compiler. For instance, Turner, Wadler, and Mossin (1995) and Wansbrough and Peyton Jones (1999) showed how to use affine types and affine type inference to optimize programs as discussed earlier in this chapter. They also use extensive strictness analysis to avoid thunk creation. Recently, researchers have begun to investigate ways to combine substructural type systems with dependent types and effect systems such as those described in Chapters 2 and 3. The combination of both dependent and substructural types provides a very powerful tool for enforcing safe memory management and more general resource-usage protocols. For instance, DeLine and Fähndrich developed Vault (2001; 2002), a programming language that uses static capabilities (Walker, Crary, and Morrisett, 2000) (a hybrid form of linear types and effects) to enforce a variety of invariants in Microsoft Windows device drivers including locking protocols, memory management protocols and others. Cyclone (Jim et al., 2002; Grossman et al., 2002), a completely type-safe substitute for C, also uses linear types and effects to grant programmers fine-grained control over memory allocation and deallocation. In each of these cases, the authors do not stick to the pure linear types described here. Instead, they add coercions to the language to allow linearlytyped objects to be temporarily aliased in certain contexts, following a long line of research on this topic (Wadler, 1990; Odersky, 1992; Kobayashi, 1999; Smith, Walker, and Morrisett, 2000; Aspinall and Hofmann, 2002; Foster, Terauchi, and Aiken, 2002; Aiken, Foster, Kodumal, and Terauchi, 2003).

2

Dependent Types David Aspinall and Martin Hofmann

In the most general sense, dependent types are type-valued functions. This definition includes, for example, the type operators of F ω such as Pair. When applied to two types S and T, this yields the type Pair S T whose elements are pairs (s, t) of elements s from S and t from T (see TAPL, Chapter 29). However, the terminology “dependent types” is usually used to indicate a particular class of type-valued functions: those functions which send terms to types. In this chapter we study this kind of dependency.

2.1

Motivations We begin the chapter by looking at a few representative examples of where type-term dependency occurs naturally.

Programming with Vectors and Format Strings The prototypical example of programming with dependent types is introduced by the type family of vectors (one-dimensional arrays): Vector :: Nat → ∗ This kinding assertion states that Vector maps a natural number k:Nat to a type. The idea is that the type Vector k contains vectors of length k of elements of some fixed type, say data. To use vectors, we need a way of introducing them. A useful initialization function takes a length n, a value t of type data, and returns a vector with n The system studied in this chapter is the dependently typed lambda-calculus, λLF (Figures 2-1, 2-2), extended with Σ-types (Figure 2-5) and the Calculus of Constructions (Figure 2-7). The associated OCaml implementation, called deptypes, can be found on the book’s web site.

46

2 Dependent Types

elements all set to t. The typing of such an init function is written like this, init : Πn:Nat. data → Vector n and the application init k t has type Vector k. The type of init introduces the dependent product type (or “Pi type”), written Πx:S.T. This type generalizes the arrow type of the simply typed lambdacalculus. It is the type of functions which map elements s:S to elements of [x , s]T. In contrast to the simply-typed case, the result type of a function with a Π-type can vary according to the argument supplied. According to Seldin (2002), the Π-type goes back to Curry and is thus almost as old as the lambda calculus itself. A more interesting way of building up vectors is given by the constant empty vector empty : Vector 0 and a constructor for building longer vectors: cons : Πn:Nat. data → Vector n → Vector (n+1). The typing of cons expresses that cons takes three arguments: a natural number n, an element of type data, and a vector of length n. The result is a vector of length n+1. This means that, for example, if v : Vector 5 and x : data, then cons 5 x v : Vector 6. The dependent product type Πx:S.T is somewhat analogous to the universal type ∀X.T of System F. The type of a term t with type ∀X.T also varies with the argument supplied; but in the case of a type abstraction, the argument is a type rather than a term. If A is a type, then t A:[X , A]T. In System F (and F ω ), type variation occurs only with type arguments, whereas in dependent type theory it may occur with term-level arguments. The reader familiar with programming with ordinary arrays will have realized that by using a type of arrays instead of vectors we could avoid dependent typing. The initialization function for one-dimensional arrays could be given the simple type Nat → data → Array, where Array is the type of arrays with entries of type data. The point of the dependent typing is that it reveals more information about the behavior of a term, which can be exploited to give more precise typings and exclude more of the badly behaved terms in a type system. For example, with the dependent type of vectors, we can type a function that returns the first element of a non-empty vector: first : Πn:Nat.Vector(n+1) → data The function first can never be applied to an empty vector—non-emptiness is expressed within the type system itself! This is a useful gain. With ordinary arrays instead of dependently-typed vectors, we would need some special way to deal with the case when first is applied to the empty array. We could return an ad-hoc default element, or we might use a language-based

47

2.1 Motivations

exception mechanism to indicate the error. Either mechanism is more clumsy than simply prohibiting illegal applications of first from being written. We suggested that Πx:S.T generalizes the function space S→T of simply typed lambda calculus. In fact, we can treat S→T simply as an abbreviation: S→T

=

where x does not appear free in T

Πx:S.T

For example, Πx:Nat.Nat is exactly equivalent to Nat → Nat. We will continue to write the arrow → whenever possible, to increase readability. Another favorite example of a function with a useful dependent typing is sprintf of the C language.1 Recall that sprintf accepts a format string and list of arguments whose types must correspond to the declarations made in the format string. It then converts the given arguments into a string and returns it. A simplified form of sprintf might have the typing: sprintf : Πf:Format. Data(f) → String where we suppose that Format is a type of valid print formats (for example, considered as character lists) and that Data(f) is the type of data corresponding to format f. The function Data(f) evaluates the type that the format string describes, which might include clauses like these: Data([]) Data("%d"::cs) Data("%s"::cs) Data(c::cs)

= = = =

Unit Nat * Data(cs) String * Data(cs) Data(cs)

This example is rather different to the case of vectors. Vectors are uniform: we introduce operations that are parametric in the length n, and the family of types Vector n is indexed by n. In the case of format strings, we use case analysis over values to construct the type Data(f) which depends on f in an arbitrary way. Unsurprisingly, this non-uniform kind of dependent type is more challenging to deal with in practical type systems for programming. 2.1.1

Exercise [«]: Suggest some dependent typings for familiar data types and their operations. For example, consider matrices of size n * m and the typing of matrix multiplication, and a type of dates where the range of the day is restricted according to the month. 2 1. A sprintf-like formating function can also be typed in ML without dependent types if formats are represented as appropriate higher-order functions rather than strings. For details see Danvy (1998).

48

2 Dependent Types

The Curry-Howard Correspondence A rather different source for dependent typing is the Curry-Howard correspondence, also known by the slogan propositions-as-types (Howard, 1980). Under this correspondence simple types correspond to propositions in the implicational fragment of constructive logic. A formula has a proof if and only if the corresponding type is inhabited. For instance, the formula ((A→B) → A) → (A→B) → B is valid in constructive logic and at the same time is inhabited, namely by λf.λu.u(f u). The underlying philosophical idea behind this correspondence is that a constructive proof of an implication A =⇒ B ought to be understood as a procedure that transforms any given proof of A into a proof of B. If propositions are types, then proofs are terms. We can introduce a type constructor Prf which maps a formula A (understood as a type) into the type of its proofs Prf A, and then a proof of A =⇒ B becomes a λ-term of type Prf A → Prf B. Often the type constructor Prf is omitted, notationally identifying a proposition with the type of its proofs. In that case, a proof of A =⇒ B is simply any term of type A→B. Generalizing the correspondence to first-order predicate logic naturally leads to dependent types: a predicate B over type A is viewed as a typevalued function on A; a proof of the universal quantification ∀x:A.B(a) is—constructively—a procedure that given an arbitrary element x of type A produces a proof of B(x). Hence under the Curry-Howard correspondence we should identify universal quantification with dependent product: a proof of ∀x:A.B(x) is a member of Πx:A.B(x). Indeed, Per Martin-Löf, one of the protagonists of dependent typing (1984), was motivated by this extension. In particular, he introduced type-theoretic equivalents to existential quantification (Σ-types) and equality (identity types), used in the next example. An important application of the Curry-Howard correspondence is that it allows one to freely mix propositions and (programming language) types. For example, an indexing function ith(n) to access elements of vectors of length n could be given the type Πn:Nat.Πl:Nat.Lt(l,n)→Vector(n)→T where Lt(l,n) is the proposition asserting that l is less than n. Perhaps more interestingly, we can package up types with axioms restricting their elements. For instance, the type of binary, associative operations on some type T may be given as Σm:T→T→T.Πx:T.Πy:T.Πz:T.Id (m(x,m(y,z))) (m(m(x,y),z))

2.1 Motivations

49

Here Σx:A.B(x) is the type of pairs (a,b) where a:A and b:B(a) and Id t1 t2 is the type of proofs of the equality t1 =t2 . In Martin-Löf’s type theory existential quantification is rendered with Σ-types, the idea being that a constructive proof of ∃x:A.B(x) would consist of a member a of type A and a proof, thus a member, of B(a)—in other words, an element of Σa:A.B(a). 2.1.2

Exercise [«]: Write down a type which represents a constructive version of the axiom of choice, characterised by: if for every element a of a type A there exists an element b of B such that P(a,b) then there exists a function f mapping an arbitrary x:A to an element of B such that P(x, f x). 2

2.1.3

Exercise [«]: Suppose that f : A→C, g : B→C are two functions with equal target domain. Using set-theoretic notation we can form their pullback as {(a, b) ∈ A × B | f a = g b}. Define an analogous type using Σ and Id. 2

Logical Frameworks Dependent types have also found application in the representation of other type theories and formal systems. Suppose that we have an implementation of dependent types and want to get a rough-and-ready typechecker for simply typed lambda calculus. We may then make the following declarations: Ty :: ∗ Tm :: Ty → ∗ base : Ty arrow : Ty → Ty → Ty app : ΠA:Ty.ΠB:Ty.Tm(arrow A B) → Tm A →Tm B lam : ΠA:Ty.ΠB:Ty.(Tm A → Tm B) → Tm(arrow A B) Here Ty represents the type of simple type expressions and for A:Ty the type Tm A represents the type of lambda terms of type A. We have a constant base:Ty representing the base type and a function arrow representing the formation of arrow types. As for terms we have a function app that accepts to types A,B, a term of type arrow A B, a term of type A and yields a term of type B: the application of the two. Somewhat intriguingly, the function corresponding to lambda abstraction takes a “function” mapping terms of type A to terms of type B and returns a term of type arrow A B. This way of using functions at one level to represent dependencies at another level is particularly useful for representing syntax with binders, and the technique is known as higher-order abstract syntax. We can now represent familiar terms such as the identity on A:Ty by idA = lam A A (λx:Tm A.x)

50

2 Dependent Types

or the Church numeral 2 on type A by two = λA:Ty.lam A (arrow (arrow A A) A) (λx:Tm A.lam _ _ (λf:Tm(arrow A A). app _ _ f (app _ _ f x)))

(replacing some obvious type arguments by underscores to aid readability). Logical frameworks are systems which provide mechanisms for representing syntax and proof systems which make up a logic. The exact representation mechanisms depend upon the framework, but one approach exemplified in the Edinburgh Logical Framework (Harper, Honsell, and Plotkin, 1993) is suggested by the slogan judgments-as-types, where types are used to capture the judgments of a logic.2 2.1.4

2.2

Exercise [«]: Write down some typing declarations which introduce a judgment expressing an evaluation relation for the representation of simply typed terms shown above. You should begin with a type family Eval which is parameterized on a simple type A and two terms of type Tm A, and declare four terms which represent the rules defining the compatible closure of one-step beta-reduction. 2

Pure First-Order Dependent Types In this section we introduce one of the simplest systems of dependent types, in a presentation called λLF. As the name suggests, this type system is based on a simplified variant of the type system underlying the Edinburgh LF, mentioned above. The λLF type theory generalizes simply typed lambda-calculus by replacing the arrow type S→T with the dependent product type Πx:S.T and by introducing type families. It is pure, in the sense that it has only Πtypes; it is first-order, in the sense that it does not include higher-order type operators like those of F ω . Under the Curry-Howard correspondence, this system corresponds to the ∀,→-fragment of first-order predicate calculus.

Syntax The main definition of λLF appears in Figure 2-1 and 2-2. The terms are the same as those of the simply typed lambda calculus λ→ . The types include type variables X which can be declared in the context but never appear bound. Type variables range over proper types as well as type familes such as 2. Judgments are the statements of a logic or a type system. For example, well-formedness, derivability, well-typedness. In LF these judgments are represented as types and derivations of a judgment are represented as members.

51

2.2 Pure First-Order Dependent Types

λLF Syntax t ::=

X Πx:T.T Tt ∗ Πx:T.K

kinds: kind of proper types kind of type families

x λx:T.t tt T ::=

K ::=

Γ

Γ ` T :: K

Kinding terms: variable abstraction application types: type/family variable dependent product type type family application

contexts: empty context term variable binding type variable binding

::= ∅ Γ , x:T Γ , X::K

Γ `K

Well-formed kinds Γ `∗ Γ ` T :: ∗

Γ , x:T ` K

Γ ` Πx:T.K

(Wf-Star) (Wf-Pi)

X :: K ∈ Γ

Γ `K

Γ ` X :: K Γ ` T1 :: ∗

Γ , x:T1 ` T2 :: ∗

Γ ` Πx:T1 .T2 :: ∗ Γ ` S :: Πx:T.K

Γ `t:T

Γ ` S t : [x , t]K Γ ` K≡K0

Γ ` T :: K

Γ ` T :: K0

(K-Var) (K-Pi) (K-App) (K-Conv) Γ `t:T

Typing x:T ∈ Γ

Γ ` T :: ∗

Γ `x:T Γ ` S :: ∗

Γ , x:S ` t : T

Γ ` λx:S.t : Πx:S.T Γ ` t1 : Πx:S.T

Γ ` t2 : S

Γ ` t1 t2 : [x , t2 ]T Γ `t:T

Γ ` T ≡ T0 :: ∗ Γ ` t : T0

(T-Var) (T-Abs) (T-App) (T-Conv)

Figure 2-1: First-order dependent types (λLF)

Vector :: Nat → *. We may use type and term variables declared in a fixed initial context to simulate the built-in types and operators of a programming language.3 Apart from variables, types may be dependent products or type family applications. The latter allow us to instantiate families, for example, to give types such as Vector k for k:Nat. Kinds allow us to distinguish between proper types and type families. Proper types have kind ∗ while type families have dependent product kinds of the form Πx:T.K. Contexts may bind term variables and type variables. 3. Strictly speaking, we should consider a signature as a special form of context and consider the term and type variables declared in it to be the constants of the language. This isn’t necessary when we move to richer type theories in which it is possible to define data types.

52

2 Dependent Types

λLF Γ ` K ≡ K0

Kind Equivalence Γ ` T1 ≡ T2 :: ∗

Γ , x:T1 ` K1 ≡ K2

Γ ` Πx:T1 .K1 ≡ Πx:T2 .K2 Γ `K Γ ` K1 ≡ K2

(QK-Sym)

Γ ` K2 ≡ K1 Γ ` K1 ≡ K3

Γ ` S1 ≡ T1 :: ∗

Γ ` λx:S1 .t1 ≡ λx:S2 .t2 : Πx:S1 .T (Q-Abs) Γ ` t1 ≡ s1 : Πx:S.T Γ ` t2 ≡ s2 : S (Q-App) Γ , x:S ` t : T

Γ ` Πx:S1 .S2 ≡ Πx:T1 .T2 :: ∗ (QT-Pi) Γ ` t1 ≡ t2 : T

Γ `t:T Γ `t≡t:T

(QT-App) Γ ` T ≡ T :: K Γ ` T ≡ S :: K Γ ` S ≡ T :: K

Γ `s:S

Γ ` (λx:S.t) s ≡ [x , s]t : [x , s]T (Q-Beta) Γ ` t : Πx:S.T x 6∈ FV(t) (Q-Eta) Γ ` λx:T.t x ≡ t : Πx:S.T

Γ ` S1 t1 ≡ S2 t2 : [x , t1 ]K Γ `T:K

Γ , x:S1 ` t1 ≡ t2 : T

Γ ` t1 t2 ≡ s1 s2 : [x , t2 ]T

Γ , x:T1 ` S2 ≡ T2 :: ∗

Γ ` S1 ≡ S2 :: Πx:T.K

Γ ` S1 ≡ S2 :: ∗

(QT-Trans)

Γ ` t1 ≡t2 : T

(QK-Trans) Γ ` S ≡ T :: K

Type Equivalence

Γ ` S ≡ T :: K

(QK-Pi)

(QK-Refl)

Γ ` K2 ≡ K3

Γ ` U ≡ T :: K

Term Equivalence

Γ `K≡K

Γ ` K1 ≡ K2

Γ ` S ≡ U :: K

Γ `t≡s:T

(QT-Refl)

Γ `s≡t:T Γ `s≡u:T

(QT-Sym)

Γ ù≡t:T

Γ `s≡t:T

(Q-Refl) (Q-Sym) (Q-Trans)

Figure 2-2: First-order dependent types (λLF)—Equivalence rules

Typechecking Rules The rules in Figure 2-1 define three judgment forms, for checking kind formation, kinding, and typing. The characteristic typing rules of the system are the abstraction and application rules for terms, altered to use Π-types. The abstraction introduces a dependent product type, checking that the domain type S is well-formed: Γ ` S :: ∗

Γ , x:S ` t : T

Γ ` λx:S.t : Πx:S.T

(T-Abs)

The term application rule eliminates a term with this type, substituting the operand in the Π-type: Γ ` t1 : Πx:S.T

Γ ` t2 : S

Γ ` t1 t2 : [x , t2 ]T

(T-App)

2.2 Pure First-Order Dependent Types

53

The well-formedness check in T-Abs uses the kinding rules to ensure that S is a type. Notice that this check may again invoke the typing rules, in the rule K-App, which checks the instantiation of a type family. The kind formation judgment also invokes the well-formedness of types (in the first premise of Wf-Pi), so the three judgment forms are in fact mutually defined. One consequence is that proofs of properties in this system typically proceed by simultaneous proofs for the different judgment forms, using derivation height as an overall measure or alternatively simultaneous structural induction. There are two conversion rules, K-Conv and T-Conv, which allow us to replace a kind or type with another one that is equivalent. Kinds have the general form Πx1 :T1 . . . . xn :Tn .∗ but in the typing rules we only ever need to check for proper types with kind ∗. Nevertheless, we include the K-Conv to ensure that kinding is closed under conversion within the Ti . There is no mechanism for forming kinds by abstraction, so the only way to construct an object of a kind other than ∗ is by declaring it in the context.

Equivalence Rules One of the main questions in any type system is when two types should be considered equivalent. Type equivalence is in particular needed in the application rules T-App and K-App. To show that some actual argument has an acceptable type for a function or type family, we may need to use the rule T-Conv to convert the type. In fact, the algorithmic typing rules introduced later on show that this is the only place where type equivalence is needed. But what should our notion of type equivalence be? Without adding special equality axioms, we can consider natural notions of equality which arise from the type structure. With dependent types, a natural notion is to equate types that differ only in their term components, when those term components themselves should be considered equal. So the question is reduced to considering notions of term equality. A first example is a type-family application containing a β-redex, since we consider β-equivalent λ-terms to be equal: T ((λx:S.x) z) ≡ T z. A slightly different and more concrete example is two different applications of the Vector family: Vector (3 + 4) ≡ Vector 7. It seems reasonable that a typechecker should accept each of these pairs of types as being equivalent. But we quickly come across more complex equivalences involving more computation, or even, requiring proof in the general case. For example, supposing x is an unknown value of type Nat and f:Nat → Nat is a function whose behavior is known. If it happens that f x=7 for all x then we have Vector (f x) ≡ Vector 7, but this equality could be more difficult to add to an automatic typechecker.

54

2 Dependent Types

The question of what form of type equivalence to include in a system of dependent types is therefore a central consideration in the design of the system. Many different choices have been studied, leading to systems with fundamentally different character. The most notable distinction between systems is whether or not typechecking is decidable. In the first case, we may choose to include only basic equalities which are manifestly obvious. This is the viewpoint favored by Martin-Löf, who considers definitional equality to be the proper notion of equivalence. The first two equalities above are definitional: 3 + 4 is definitionally equal to 7 by the rules of computation for addition. Alternatively, one may prefer to include as many equalities as possible, to make the theory more powerful. This is the approach followed, for example, in the type theory implemented by the NuPrl system (1986). This formulation of type theory includes type equivalences like the third example above, which may require arbitrary computation or proof to establish. In such a type system, typechecking is undecidable. For λLF, we axiomatize definitional equality based on the type structure, which includes β and η equality on lambda terms. It is possible to define this using a relation of equality defined via compatible closure of untyped reduction (this is the approach followed by Pure Type Systems, see Section 2.7). Instead, we give a declarative, typed definition of equivalence, using rules which follow the same pattern as the typing rules. The advantage of this approach is that it is more extensible than the “untyped” approach and avoids the need to establish properties of untyped reduction. See Chapter 6 in this volume for further explanation of the issues here. The rules for equivalence are shown in Figure 2-2. Again there are three judgments, for equivalence of each of the syntactic categories of terms, types, and kinds. The only interesting rules are Q-Beta and Q-Eta which introduce β and η-equivalence on terms; the remaining rules are purely structural and express that equivalence is a congruence.

2.3

Properties In this section we mention some basic properties of λLF. We don’t go very far: in Section 2.4 we introduce an algorithmic presentation of λLF which allows us to establish further properties indirectly but rather more easily.

Basic Properties The following properties use some additional notation. Inclusion is defined between contexts as Γ ⊆ ∆ iff x:T ∈ Γ implies x:T ∈ ∆, in other words,

55

2.3 Properties

Γ ⊆ ∆ means that ∆ is a permutation of an extension of Γ . We write Γ ` J for an arbitrary judgment, amongst the six defined in Figures 2-1 and 2-2. We write Γ ` K, K 0 to stand for both Γ ` K and Γ ` K 0 , and similarly for other judgments. 2.3.1

Lemma [Permutation and Weakening]: Suppose Γ ⊆ ∆. Then Γ ` J implies ∆ ` J. 2

2.3.2

Lemma [Substitution]: If Γ , x:S, ∆ ` J and Γ ` s : S, then Γ , [x , s]∆ ` [x , s]J. 2

2.3.3

Lemma [Agreement]: Judgments in the system are in agreement, as follows: 1. If Γ ` T :: K then Γ ` K. 2. If Γ ` t : T then Γ ` T :: ∗. 3. If Γ ` K ≡ K0 then Γ ` K, K0 . 4. If Γ ` T ≡ T0 :: K then Γ ` T, T0 :: K.

2.3.4

5. If Γ ` t ≡ t0 : T then Γ ` t, t0 : T.

2

Exercise [««, 3]: Prove the lemmas above.

2

Strong Normalization As an auxiliary device for the soundness and completeness of algorithmic typechecking we will now introduce general beta reduction which permits reductions within the scope of abstractions. We define beta reduction on λLF terms by the four rules: t1 -→β t01 λx:T1 .t1 -→β λx:T1 .t01 t1 -→β t01 t1 t2 -→β t01 t2 t2 -→β t02 t1 t2 -→β t1 t02 (λx:T1 .t1 ) t2 -→β [x , t2 ]t1

(Beta-Abs)

(Beta-App1)

(Beta-App2) (Beta-AppAbs)

Notice that this reduction does not go inside the type labels of λ abstractions. The following central result is required to ensure completeness and termination of typechecking, proved in the next section.

56

2 Dependent Types

2.3.5

Theorem [Strong normalization]: The relation -→β is strongly normalizing on well-typed terms. More precisely, if Γ ` t:T then there is no infinite sequence of terms (ti )i≥1 such that t = t1 and ti -→β ti+1 for i ≥ 1. 2 Proof: This can be proved by defining a reduction-preserving translation from λLF to the simply-typed lambda-calculus as follows. First, for every type variable X, no matter of what kind, we introduce a simple type variable X\ . Second, for each type expression T, no matter of what kind, we define a simple type expression T\ by Πx:S.T\ = S\ →T\ and (T t)\ = T\ . Finally, the mapping −\ is extended to terms and contexts by applying it to all type expressions occurring within. Now we can show by induction on typing derivations in λLF that Γ ` t:T implies Γ \ ` t\ :T\ , from which the result follows by the strong normalization theorem for β-reduction of the simply typed lambda calculus. 2 Since -→β is finitely branching, this implies that for each term t there exists a number µ(t) such that if (ti )1≤i≤k is a reduction sequence starting from t, that is, t=t1 and ti -→β ti+1 for 1 ≤ i < k then k ≤ µ(t). A term t0 such that t -→β ∗ t0 and t0 6 -→β is called a (β) normal form of t. Since -→β is confluent, see below, normal forms are unique and we may write t0 = nf(t).

2.3.6

Theorem: The relation -→β is confluent.

2.3.7

Exercise [«««, 3]: Prove the theorem in the following way: first show that -→β is locally confluent in the sense that if t -→β t1 and t -→β ∗ t2 then t1 -→β ∗ t0 and t2 -→β t0 for some t0 . Then conclude confluence using the fact that -→β is strongly normalizing. This last part is a standard result from term rewriting known as Newman’s Lemma. Alternatively, you can prove confluence directly using Tait–Martin-Löf’s method of parallel reduction, see TAPL, Chapter 30. 2

2.4

2

Algorithmic Typing and Equality To implement λLF, we need to find a formulation of the system that is closer to an algorithm. As usual, we follow the strategy of reformulating the rules to be syntax-directed, so that they can be used to define an algorithm going from premises to conclusion (see the description of the implementation in Section 2.9) . We also need an algorithm for deciding type equivalence. The algorithmic presentation of λLF is shown in Figures 2-3 and 2-4. The judgments mirror the defining presentation, with the addition of a context checking judgment. (This is used only to check an initial context: the rules otherwise maintain context well-formation when extending contexts going from conclusions to premises.)

57

2.4 Algorithmic Typing and Equality

The non-syntax-directed rules K-conv and T-conv are removed. To replace T-conv, we add equivalence testing in the algorithmic rules for applications, KA-app and TA-app. The equivalence testing rules in Figure 2-4 assume that they are invoked on well-typed phrases. We show these rules with contexts Γ to facilitate extensions to type-dependent equalities or definitions in the context (used in the implementation), although in the rules for pure λLF, the context plays no role in equivalence testing. The equivalence testing algorithm on terms that is suggested by these rules is similar to the one described in Chapter 6, but we do not make use of type information. (Similarly, the type equivalence rules do not record kinds.) The algorithmic judgment Γ `ñ s ≡ t for arbitrary terms is defined mutually with Γ `ñ s ≡wh t which is defined between weak head normal forms. Weak head reduction is a subset of the β reduction -→β , defined by the rules: t1 -→wh t01 t1 t2 -→wh t01 t2 (λx:T1 .t1 ) t2 -→wh [x , t2 ]t1

(WH-App1) (WH-AppAbs)

Weak head reduction only applies β-reduction in the head position. The implementation described in Section 2.9 adds expansion of definitions to this reduction; see Chapter 9 for a thorough treatment of how to do this. 2.4.1

Theorem [Weak head normal forms]: If Γ ` t:T then there exists a unique term t0 = whnf(t) such that t -→wh ∗ t0 6 -→wh . 2 The theorem is a direct consequence of Theorem 2.3.5 and of the fact that -→wh is deterministic (a partial function).

Correctness of the Algorithm We will now show that the typechecking algorithm defined by the algorithmic rules is sound, complete, and terminates on all inputs. Since the algorithm checks the context only as it is extended, and (for efficiency) does not check the type of variables in the leaves, we can only expect to show soundness for contexts which are well-formed. The soundness lemma makes use of an auxiliary algorithmic judgment for context formation: `ñ ∅ `ñ Γ

Γ `ñ T :: ∗ `ñ Γ , x:T

`ñ Γ

Γ `ñ K

` Γ , X::K ñ

(WFA-Empty) (WFA-Tm) (WFA-Ty)

58

2 Dependent Types

Γ `ñ K

Algorithmic kind formation Γ `∗

(WFA-Star)

ñ

Γ ` T :: ∗

Γ , x:T ` K

ñ

Γ `ñ S t : [x , t]K

ñ

Γ `ñ Πx:T.K

(WFA-Pi)

X :: K ∈ Γ Γ `ñ X :: K

x:T ∈ Γ

Γ , x:T1 `ñ T2 :: ∗

Γ `ñ Πx:T1 .T2 :: ∗

(TA-Var)

Γ `ñ x : T (KA-Var)

Γ `ñ S :: ∗

Γ , x:S `ñ t : T

Γ `ñ λx:S.t : Πx:S.T (KA-Pi)

(KA-App) Γ `ñ t : T

Algorithmic typing

Γ `ñ T :: K

Algorithmic kinding

Γ `ñ T1 :: ∗

Γ `ñ S :: Πx:T1 .K Γ `ñ t : T2 Γ `ñ T1 ≡ T2

Γ `ñ t1 : Πx:S1 .T Γ `ñ t2 : S2 ñ Γ ` S1 ≡ S2 Γ `ñ t1 t2 : [x , t2 ]T

(TA-Abs)

(TA-App)

Figure 2-3: Algorithmic presentation of λLF

Algorithmic kind equivalence Γ `ñ ∗ ≡ ∗ Γ `ñ T1 ≡ T2

Γ , x:T1 `ñ K1 ≡ K2

Γ `ñ Πx:T1 .K1 ≡ Πx:T2 .K2 Algorithmic type equivalence Γ `ñ X ≡ X Γ `ñ S1 ≡ T1

Γ , x:T1 `ñ S2 ≡ T2

Γ `ñ Πx:S1 .S2 ≡ Πx:T1 .T2 Γ `ñ S1 ≡ S2

Γ `ñ t1 ≡ t2

Γ `ñ S1 t1 ≡ S2 t2

Γ `ñ K ≡ K0 (QKA-Star)

Algorithmic term equivalence Γ `ñ whnf(s) ≡wh whnf(t) Γ `ñ s ≡ t

(QKA-Pi)

Γ `ñ x ≡wh x

Γ `ñ S ≡ T

Γ , x:S `ñ t1 ≡ t2

(QTA-Var)

Γ ` λx:S.t1 ≡wh λx:S.t2 ñ

Γ `ñ s1 ≡wh s2 (QTA-Pi)

Γ `ñ s1 t1 ≡wh s2 t2 Γ , x:S `ñ s x ≡ t

(QTA-App)

Γ `ñ t1 ≡wh t2 s not a λ

Γ `ñ s ≡wh λx:S.t Γ , x:S `ñ s ≡ t x

t not a λ

Γ ` λx:S.s ≡wh t ñ

Figure 2-4: Algorithmic presentation of λLF—Equivalence rules

Γ `ñ s ≡ t (QA-WH) (QA-Var) (QA-Abs) (QA-App) (QA-Nabs1) (QA-Nabs2)

2.4 Algorithmic Typing and Equality

2.4.2

59

Lemma [Soundness of algorithmic λLF]: Each of the algorithmic judgments is sound, in the following sense: 1. If Γ `ñ K then Γ ` K. 2. If Γ `ñ T :: K then Γ ` T :: K. 3. If Γ `ñ t : T then Γ ` t : T. 4. If Γ `ñ K, K0 and Γ `ñ K ≡ K0 , then Γ ` K ≡ K0 . 5. If Γ `ñ T, T0 :: K and Γ `ñ T ≡ T0 then Γ ` T ≡ T0 :: K. 6. If Γ `ñ t, t0 : T and Γ `ñ t ≡ t0 then Γ ` t ≡ t0 :: K. where in each case, we additionally assume `ñ Γ .

2

Proof: By induction on algorithmic derivations.

2

To establish completeness of algorithmic subtyping and later on termination we need to induct on the length of normalization sequences which we formalize as follows. Recall that µ(s) denotes an upper bound on the length of any -→β reduction sequence starting from s. We write |s| for the size of the term s. 2.4.3

Definition: We associate an ω2 -valued weight to each judgment arising in a possible derivation of an equality judgment by w (∆ `ñ s1 ≡ s2 ) = w (∆ `ñ s1 ≡wh s2 ) + 1 w (∆ `ñ s1 ≡wh s2 ) = ω · (µ(s1 ) + µ(s2 )) + |s1 | + |s2 | + 1.

2.4.4

2

Lemma [Completeness of algorithmic λLF]: Each of the algorithmic judgments is complete, in the following sense: 1. If Γ ` K then Γ `ñ K. 2. If Γ ` T : K then for some K0 , we have Γ `ñ T : K0 and Γ `ñ K ≡ K0 and Γ `ñ K0 . 3. If Γ ` t : T then for some T0 , we have Γ `ñ t : T0 and Γ `ñ T ≡ T0 and Γ `ñ T0 :: ∗. 4. If Γ ` t1 ≡ t2 : T then Γ `ñ t1 ≡ t2 . 5. If Γ ` T1 ≡ T2 :: K then Γ `ñ T1 ≡ T2 .

2

60

2 Dependent Types

Proof: One first proves that each of the declarative rules is admissible in the algorithmic system. The result then follows by induction on derivations in the declarative system. The only rules that are not immediately obvious are the transitivity rules for equivalence of kinds, types, and terms, and the rule Q-App. These two are left as exercises with solutions. 2 2.4.5

Exercise [«««]: Show that rule QT-Trans is admissible for the algorithmic system in the sense that whenever Γ ` ti :T for i = 1, 2, 3 and Γ `ñ t1 ≡ t2 and Γ `ñ t2 ≡ t3 then Γ `ñ t1 ≡ t3 . 2

2.4.6

Exercise [«««]: Show that rule Q-App is admissible for the algorithmic system in the sense that whenever Γ ` t1 t2 : T and Γ ` s1 s2 : T and Γ `ñ t1 ≡ s1 and Γ `ñ t2 ≡ s2 then Γ `ñ t1t 2 ≡ s1s 2 . 2 Given soundness and completeness, we also want to know that our algorithm terminates on all inputs. This also demonstrates the decidability of the original judgments.

2.4.7

Theorem [Termination of typechecking]: The algorithmic presentation yields a terminating algorithm for typechecking. 2 We highlight the crucial ideas of the proof of Theorem 2.4.7 here; the details are left to the diligent reader (Exercise 2.4.9 below). The equivalence judgment Γ `ñ t1 ≡ t2 introduces a possible source of nontermination when invoked on non-well-typed terms (for example, Ω = ∆∆ where ∆ = λx:A.x x). Here, computation of weak head normal form runs into an infinite loop. We must be careful that equivalence testing is called only on well-typed terms. The crucial termination property for term equality that we need is captured by the following lemma.

2.4.8

Lemma: Suppose that Γ ` t1 :T1 and Γ ` t2 :T2 . Then the syntax-directed backwards search for a derivation of Γ `ñ t1 ≡ t2 always terminates. Equivalently, there is no infinite derivation ending in Γ `ñ t1 ≡ t2 . 2 Proof: We claim that the weight of any premise of a rule is always less than the weight of the conclusion which excludes any infinite derivation tree. In other words we argue by induction on the length of reduction sequences and, subordinately, on the size of terms. This property is obviously satisfied for QA-WH, QA-Abs, QA-App. To deal with rule QA-Nabs1 (and similarly, QA-Nabs2) note that s must be of the form y u1 ... un whereby µ(s x) = µ(s). The size, however, goes down, as the λ-symbol has disappeared. 2

2.4.9

Exercise [«««, 3]: Complete the proof of 2.4.2, 2.4.4, and 2.4.7.

2

61

2.5 Dependent Sum Types

Properties of λLF We can use the algorithmic presentation of λLF to prove additional properties enjoyed by the main definition. We just mention one example: type preservation under β-reduction. 2.4.10

Theorem [Preservation]: If Γ ` t : T and t -→β t0 , then Γ ` t0 : T also. 2 Proof: We show a slightly restricted form of the theorem, for well-formed contexts Γ . More precisely, well-formed contexts are those which can be built using the same rules as for `ñ Γ (page 57), but in the declarative system; the corresponding assertion is written ` Γ . It is easy to extend the completeness lemma to show that ` Γ implies `ñ Γ . The crucial case is that of an outermost β-reduction (Beta-AppAbs), when t = (λx:T1 .t1 ) t2 for some T1 , t1 , t2 . By Lemma 2.4.4, we know that Γ `ñ (λx:T1 .t1 ) t2 : T0 for some T0 with Γ `ñ T≡T0 and Γ `ñ T0 :: ∗. The first judgment must have been derived with TA-App preceded by TA-Abs, so we have the derivability of Γ `ñ T1 :: ∗

Γ `ñ T1 ≡ S1

Γ , x:T1 `ñ t1 : S2

Γ `ñ t2 : S1

in the algorithmic system, with T0 = [x , t2 ]S2 . By the above and the assumptions about Γ , we have `ñ Γ , x:T1 . Hence by Lemma 2.4.2, we can go back to get analogs of the statements above in the declarative system. For the last case, to establish the equivalence Γ ` T1 ≡ S1 :: ∗ we use Lemma 2.3.3 to get Γ ` S1 :: ∗ and then Γ `ñ S1 :: ∗. Now by T-Conv we have Γ ` t2 :S2 and so with substitution, Lemma 2.3.2, we get Γ ` [x , t2 ]t1 : [x , t2 ]S2 and then the result follows using T-Conv again, with another hop between the systems and Lemma 2.3.3, to show the equivalence Γ ` [x , t2 ]S2 ≡ T :: ∗. 2 2.4.11

2.5

Exercise [«««, 3]: Generalize the proof above to arbitrary contexts Γ .

2

Dependent Sum Types Figure 2-5 shows extensions to λLF to add dependent sum (or “Sigma”) types, written Σx:T1 .T2 . Dependent sums were motivated briefly in the introduction. They generalize ordinary product types in a similar way to the way that dependent products generalize ordinary function spaces. The degenerate non-dependent case, when x does not appear free in T2 , amounts to the ordinary product, written as T1 × T2 . We extend the terms and types of λLF given in Figure 2-1 with pairs, projection operations, and the type constructor itself. Notice that the pair (t1 ,t2 )

62

2 Dependent Types

Extends λLF (2-1 and 2-2) New syntax t ::= . . . (t, t:Σx:T.T) t.1 t.2

Γ ` t : Σx:S.T terms: typed pair first projection second projection types: dependent sum type

T ::= . . . Σx:T.T

Γ ` T :: K

Kinding Γ ` S :: ∗

Γ , x:S ` T :: ∗

Γ ` Σx:S.T :: ∗

(K-Sigma) Γ `t:T

Typing Γ ` Σx:S.T :: ∗ Γ ` t1 : S Γ ` t2 : [x , t1 ]T Γ ` (t1 ,t2 :Σx:S.T) : Σx:S.T Γ ` t : Σx:S.T Γ ` t.1 : S

(T-Pair)

(T-Proj2)

Γ ` t.2 : [x , t.1]T Term Equivalence

Γ ` t1 ≡t2 : T

Γ ` Σx:S.T :: ∗ Γ ` t1 : S Γ ` t2 : [x , t1 ]T Γ ` (t1 ,t2 :Σx:S.T).1 ≡ t1 : S

(Q-Proj1)

Γ ` Σx:S.T :: ∗ Γ ` t1 : S Γ ` t2 : [x , t1 ]T Γ ` (t1 ,t2 :Σx:S.T).2 ≡ t2 : [x , t1 ]T (Q-Proj2) Γ ` t : Σx:S.T Γ ` (t.1, t.2:Σx:S.T) ≡ t : Σx:S.T (Q-SurjPair)

(T-Proj1)

Figure 2-5: Dependent sum types

is annotated explicitly with a type Σx:T1 .T2 in the syntax. The reason for this is that the type of such a pair cannot be reconstructed from the types of t1 and t2 alone. For example, if S:T→∗ and x:T and y:S x the pair (x,y) could have both Σz:T.S z and Σz:T.S x as a type. The most cluttered typing rule is the one which introduces a dependent pair, T-Pair. It must check first that the Σ-type itself is allowed, and then that each component has the requested type. The projection rules are straightforward: compare the second projection with the rule T-App in Figure 2-1. The equality relation on terms is extended to Σ-types by three rules. The first two define the elimination behavior of projections on a pair (compare with the beta rule for Π-types). The third rule, Q-SurjPair, is known as surjective pairing. This rule is a form of eta rule for Σ-types: it states that every pair can be formed using the pair constructor.

Algorithmic Typing with Dependent Sum Types To extend the algorithm to deal with Σ-types, we first extend the notions of beta and weak-head reduction. In both, the main clause is projection on a

63

2.5 Dependent Sum Types

Extends λLF algorithm (2-3 and 2-4) Γ `ñ T :: K

Algorithmic kinding Γ ` T1 :: ∗

Γ , x:T1 ` T2 :: ∗

ñ

Γ ` Σx:T1 .T2 :: ∗ ñ

(KA-Sigma)

Γ `ñ S1 ≡ T1

Γ `ñ t : T

Γ ` Σx:S1 .S2 ≡ Σx:T1 .T2

Γ `ñ ti ≡ t0 i Γ `ñ (t1 ,t2 :T) ≡wh (t0 1 ,t0 2 :T0 ) Γ `ñ ti ≡ t.i

Γ `ñ (t1 ,t2 :Σx:T1 .T2 ) : Σx:T1 .T2

Γ `ñ t : Σx:T1 .T2 Γ `ñ t.2 : [x , t.1]T2

(TA-Proj1)

t not a pair

Γ `ñ (t1 ,t2 :T) ≡wh t

(TA-Pair) Γ ` t.1 : T1

(QTA-Sigma) Γ `ñ t ≡wh t0

Algorithmic term equivalence

Γ `ñ Σx:T1 .T2 :: ∗ Γ `ñ t1 : T01 Γ `ñ T01 ≡ T1 0 Γ `ñ t2 : T2 Γ `ñ T02 ≡ [x , t1 ]T2

ñ

Γ , x:T1 `ñ S2 ≡ T2

ñ

Algorithmic typing

Γ `ñ t : Σx:T1 .T2

Γ `ñ S ≡ T

Algorithmic type equivalence

ñ

Γ `ñ t.i ≡ ti

t not a pair

Γ ` t ≡wh (t1 ,t2 :T) ñ

(QA-Pair)

(QA-Pair-NE) (QA-NE-Pair)

(TA-Proj2)

Figure 2-6: Algorithmic typing for Σ-types

pair. Beta reduction also allows reduction inside the components of a pair. (t1 ,t2 :T).i -→β ti t -→β

t0

t.i -→β t0 .i t1 -→β t01 (t1 ,t2 :T) -→β (t01 ,t2 :T) t2 -→β t02 (t1 ,t2 :T) -→β (t1 ,t02 :T)

(Beta-ProjPair) (Beta-Proj)

(Beta-Pair1)

(Beta-Pair2)

Weak head reduction just has two new cases: (t1 ,t2 :T).i -→wh ti t -→wh

t0

t.i -→wh t0 .i

(WH-ProjPair) (WH-Proj)

Using the weak head reduction, the algorithmic typing and equality judgments are extended with the rules in Figure 2-6 to deal with Σ-types. 2.5.1

Exercise [«««, 3]: Extend Lemmas 2.4.2, 2.4.4 and 2.4.7 to Σ-types. (No surprises are to be expected.) 2

64

2 Dependent Types

Extends λLF (2-1 and 2-2) New syntax t ::= . . . all x:T.t

Γ `t:T

Typing terms: universal quantification types: propositions family of proofs

T ::= . . . Prop Prf

Γ ` T :: K

Kinding Γ ` Prop :: ∗ Γ ` Prf :: Πx:Prop. ∗

(K-prop)

Γ ` T :: ∗

Γ , x : T ` t : Prop

Γ ` all x:T.t : Prop Type Equivalence Γ ` T :: ∗

(T-All)

Γ ` S ≡ T :: K Γ , x:T ` t : Prop

Γ ` Prf (all x:T.t) ≡ Πx:T.Prf t :: ∗ (QT-All)

(K-prf)

Figure 2-7: The Calculus of Constructions (CC)

2.6

The Calculus of Constructions The Calculus of Constructions (CC), one of the most famous systems of dependent types, was introduced by Coquand and Huet (1988) as a setting for all of constructive mathematics. While it has turned out that CC needs to be extended with certain features (in particular inductive types [Mohring, 1986]), its simplicity in relationship to its expressivity is unprecedented. In our framework CC can be formulated as an extension of λLF which has a new basic type Prop and a new type family Prf. Elements of the type Prop represent propositions, and also “datatypes” such as the type of natural numbers (we use the term “datatype” to refer to usual programming language types, as opposed to types of proofs of a proposition). Propositions and datatypes are identified in CC by taking the Curry-Howard isomorphism as an identity. The type family Prf assigns to each proposition or datatype p : Prop the type Prf p of its proofs, or, in the case of datatypes, its members. CC has one new term former all x:T.t, and two rules which relate it to Prf. The additions to λLF are shown in Figure 2-7. In most presentations and implementations of CC the type Prf t is notationally identified with the term t. This is convenient and enhances readability, however, we will not adopt it for the sake of compatibility. The original formulation of CC went as far as using the same notation, namely (x:A) for all three binders: Π,all,λ. That did not enhance readability at all and was thus given up after some time! CC contains F ω as a subsystem by an obvious translation. For example, here is the type of an encoding of natural numbers in CC:

2.6 The Calculus of Constructions

65

nat = all a:Prop.all z:Prf a.all s:Prf a →Prf a. a

Recall that A→B abbreviates Πx:A.B. Notice that nat is a member of type Prop. The natural numbers inhabit the type Prf nat. Accordingly, we have zero = λa:Prop.λz:Prf a.λs:Prf a → Prf a.z : Prf nat succ = λn:Prf nat.λa:Prop.λz:Prf a. λs:Prf a → Prf a.s(n a z s) : Prf nat → Prf nat add = λm:Nat.λn:Nat.m nat n succ : Prf nat → Prf nat → Prf nat

Regarding higher-order polymorphism here is how we define existential types in CC: exists = λf:A→Prop.all c:Prop.all m:(Πx:Prop.Prf (f x)→Prf c).c

Here A is any type; we obtain System F’s existential types with A=Prop; we obtain existential quantification over natural numbers with A=Nat. 2.6.1

Exercise [«, 3]: Define the term corresponding to existential introduction of type: Πf:A→Prop.Πa:Prop.Πi:Prf (f a).Prf (exists f). 2 Conversely, existential elimination corresponds to applying a term of type exists f to an appropriately typed argument.

2.6.2

Exercise [«««, 3]: Formalize the translation from F ω into CC.

2

The combination of type dependency and impredicativity à la System F yields an astonishing expressive power. For example, we can define Leibniz equality as follows: eq = λa:Prop.λx:Prf a.λy:Prf a. all p:Prf a→Prop.all h:Prf (p x).p y : Πa:Prop.Prf a → Prf a → Prop

We can now prove reflexivity of equality by exhibiting an inhabitant of the type Πa:Prop. Πx:Prf a. Prf (eq a x x). Indeed, eqRefl = λa:Prop. λx:Prf a. λp:Prf a → Prop. λh:Prf (p x).h

is such a term. 2.6.3

Exercise [««, 3]: State and prove symmetry and transitivity of equality.

2

In a similar way, we can define other logical primitives such as boolean connectives and quantifiers and then prove mathematical theorems. Occasionally we have to assume additional axioms. For example, induction for the natural numbers can be stated, but not proved; it is thus convenient to work under the assumption:

66

2 Dependent Types

natInd : Πp:Prf nat →Prop.Prf (p zero) → (Πx:Prf nat.Prf (p x) → Prf (p(succ x))) → Πx:Prf nat.Prf (p x)

With that assumption in place we can for example prove associativity of addition in the form of a term of type: Πx:Prf nat.Πy:Prf nat.Πz:Prf nat. Prf (eq nat (add x (add y z)) (add (add x y) z))

2.6.4

Exercise [«««]: Find such a term.

2

The task of finding proof terms inhabiting types is greatly simplified by an interactive goal-directed theorem prover such as LEGO (Luo and Pollack, 1992; Pollack, 1994) or Coq (Barras et al., 1997), or a structure-driven text editor for programming, such as Agda or Alfa (Coquand, 1998; Hallgren and Ranta, 2000).

Algorithmic Typing and Equality for CC We will now consider algorithmic typechecking for the pure CC. The beta reduction relation is extended with a clause for all: t -→β t0 (Beta-All) all x:T.t -→β all x:T.t0 2.6.5

Theorem: The relation -→β is strongly normalizing on well-typed terms of CC. 2 Proof: One can prove this directly using Tait’s reducibility method; see, for example, Coquand and Huet (1988) or Luo and Pollack (1992). Alternatively, we can define a reduction-preserving mapping from CC into F ω by “forgetting” type dependency—e.g., by mappingeq a t1 t2 to ∀P .P → P . Therefore, an alleged infinite reduction sequence in CC would entail an infinite reduction sequence in F ω . The details are beyond the scope of this survey. 2 With this result in place it is now possible to establish soundness, completeness, and termination of algorithmic typing. The additional rules for the algorithm (extending those for λLF) are presented in Figure 2-8.

The Calculus of Inductive Constructions The fact that induction cannot be proved is a flaw of the impredicative encoding of datatypes. Not only is it aesthetically unappealing to have to make

67


Extends λLF algorithm (2-3 and 2-4) Γ `ñ T :: K

Algorithmic kinding Γ ` Prop :: ∗ ñ

Γ `ñ t:Prop Γ `ñ Prf t :: ∗

(KA-Prf) Γ `ñ t : T

Algorithmic typing Γ `ñ T :: ∗

(KA-Prop)

Γ , x:T `ñ t : Prop

Γ `ñ all x:T.t : Prop

(QT-All-E)

Algorithmic type equivalence

Γ `ñ S ≡ T

t -→wh all x:T1 .t2 Γ `ñ S1 ≡ T1 Γ , x:S1 `ñ S2 ≡ Prf t2 Γ `ñ Πx:S1 .S2 ≡ Prf t (QKA-Pi-Prf) Γ `ñ Πx:S1 .S2 ≡ Prf t Γ `ñ Prf t ≡ Πx:S1 .S2 Γ `ñ s ≡ t Γ `ñ Prf s ≡ Prf t Algorithmic term equivalence Γ `ñ S1 ≡ T1

Γ , x:S1 `ñ s ≡ t

Γ `ñ all x:S.s ≡wh all x:T.t

(QKA-Prf-Pi) (QKA-Prf) Γ `ñ t ≡wh t0 (QA-All-E)

Figure 2-8: Algorithmic typing for CC

assumptions on an encoding; more seriously, the assumption of natInd destroys the analog of the progress theorem (see TAPL, §8.3). For example, the following term does not reduce to a canonical form: natInd (λx:Prf nat.nat) zero (λx:Prf nat.λy:Prf nat.zero) zero

For these reasons, Mohring (1986) and subsequent authors (Werner, 1994; Altenkirch, 1993) have combined CC with inductive definitions as originally proposed (for a predicative system) by Martin-Löf (1984). In the thus obtained Calculus of Inductive Constructions (CIC) as implemented in the Coq theorem prover (Barras et al., 1997) we can declare the type nat:Prop as an inductive type with constructors zero:Prf nat and succ:Prf nat→Prf nat. This generates a constant: natInd : Πp:Prf nat→Prop.Prf (p zero) → (Πx:Prf nat.Prf (p x) → Prf (p(succ x))) → Πx:Prf nat.Prf (p x)

which obeys the following equality rules: natInd p hz hs zero ≡ hz natInd p hz hs (succ n) ≡ hs n (natInd p hz hs n) This clearly provides induction, but it also allows us to define primitive recursive functions such as addition by

68

2 Dependent Types

add = λx:Prf nat.λy:Prf nat.natInd (λx:nat.nat) y (λy:nat.λr:nat.succ r) x

Notice that we instantiated natInd with the constant “predicate” λx:nat.nat. The mechanism of inductive definitions is not restricted to simple inductive types such as nat. CIC, as well as Martin-Löf’s predicative systems (as implemented in ALF [Magnusson and Nordström, 1994]) admit the inductive definition of type families as well. For example, with nat already in place we may define an inductive family vector : Prf nat → Prop

with constructors nil : Prf (vector zero) and cons : Πx:Prf nat. Prf nat → Prf (vector x) → Prf (vector(succ x))

The (automatically generated) induction principle then has the typing vecInd : Πp:Πx:nat.Prf (vector x) → Prop. Prf (p zero nil) → (Πx:Prf nat.Πy:Prf (vector x). Πa:Prf nat.Prf (p y)→Prf (cons x a y)) → Πx:Prf nat.Πy:Prf (vector x).Prf (p x y)

2.6.6

Exercise [««, 3]: What are the equality rules for this induction principle by analogy with the equations for natInd? 2 Let us see how we can define the exception-free first function from the introduction for these vectors. We first define an auxiliary function first0 that works for arbitrary vectors by first’ = vecInd (λx:Prf nat.λv:Prf (vector x).nat) zero (λx:Prf nat.λy:Prf (vector x). λa:Prf nat.λprev:Prf nat.a) : Πx:Prf nat.Πv:Prf (vector x).Prf nat

This function obeys the equations: first’ zero nil = zero first’ (succ x) (cons x a y) = a

We obtain the desired function first by instantiation first = λx:Prf nat.λy:Prf (vector (succ x)). first’ (succ x) y


69

The default value zero can be omitted in a system like ALF which allows the definition of dependently-typed functions by pattern matching. In that system one would merely declare the type of first and write down the single pattern first x (cons x a y) = a

ALF can then work out that this defines a total function. The extension of pattern matching to dependent types was introduced in Coquand (1992) which also contains beautiful examples of proofs (as opposed to programs) defined by pattern matching. McBride (2000) has studied translations of such pattern matching into traditional definitions using recursion/induction principles like vecInd. 2.6.7

Exercise [«««, 3]: Define using vecInd a function concat : Πx:Prf nat.Πy:Prf nat.Prf (vector x) → Prf (vector y) → Prf (vector (add x y))

How does it typecheck?

2

As a matter of fact, the CIC goes beyond the type system sketched here in that it allows quantification over kinds, so, for example, the “predicate” p in natInd may be an arbitrary type family. This means that using the constant family p = λx:nat.Prop we can define a function eqZero: Prf nat → Prop which equals true when applied to zero and false on all other arguments. This facility turns out to be useful to define the exception-free first function on vectors which was presented in the introduction. Another additional feature of the CIC is the separation of propositions and datatypes into two disjoint universes Prop and Set. Both behave like our Prop, the difference lies in a program extraction feature that maps developments in the CIC to programs in an extension of F ω with inductive types and general recursion. Types and terms residing in Prop are deleted by this translation; only types and terms in Set are retained. In this way, it is possible to extract correct programs from formal correctness proofs. Details can be found in Paulin-Mohring (1989).

Sigma Types in CC It is unproblematic and useful to combine CC with Σ-types as described in Section 2.5 and Figure 2-5. This allows one to form types of algebraic structures, for instance

70

2 Dependent Types

Semigrp = Σa:Prop.Σop:Prf a → Prf a → Prf a. Πx:Prf a.Πy:Prf a.Πz:Prf a. Prf (eq a (op x (op y z)) (op (op x y) z));

This system is contained in Luo’s Extended Calculus of Constructions (ECC) (1994) which additionally permits Π and Σ quantification over kinds. For consistency reasons which we will briefly describe next this requires an infinite hierarchy of ever higher kinds ∗0 , ∗1 , ∗2 , .... For instance, in ECC one has ΣX:∗3 . X : ∗4

ECC has been implemented in the LEGO system (Luo and Pollack, 1992). It is quite another matter to ask for a reflection of Σ-types into the universe Prop of datatypes and propositions, by analogy with the way all is treated. The temptation is to introduce a term former ex y:T.t : Prop when x:T ` t:Prop, together with an equality rule asserting that Pr (ex y:T.t) ≡ Σy:T.Prf t. Coquand (1986) has shown that the resulting system is unsound in the sense that all types are inhabited and strong normalization fails. Intuitively, the reason is that in this system we are able to define prop = ex x:Prop.nat

and now have a mapping i:Prop→Prf prop defined by i = λx:Prop.(x,zero:prop)

as well as a left inverse j:Prf prop →Prop given by j = λx:Prf prop.x.1.

Thus, we have reflected the universe Prop into one of its members, which allows one to encode (after some considerable effort) one of the set-theoretic paradoxes showing that there cannot be a set of all sets. This must be contrasted with the impredicative existential quantifier exists defined on page 65. The difference between exists and the hypothetical term former ex is that exists does not allow one to project out the existential witness in case it is of type Prop. An existential quantifier which does not provide first and second projections, but only the impredicative elimination rule known from System F is called a weak sum, weak Σ-type, or existential. In contrast, the Σ-types with projections are sometimes called strong. We conclude this section by remarking that it is unproblematic to have “small” strong Σ-types in the CC, that is, if t1 :Prop and x:Prf t1 ` t2 :Prop then σ x:Prf t1 .t2 :Prop with the equivalence Prf(σ x:Prf t1 .t2 ) ≡ Σx:Prf t1 .Prf t2 .

71

2.7 Relating Abstractions: Pure Type Systems

2.6.8

Exercise [«««, 3]: An “approximation” for σ x:Prf t1 .t2 is given by exists = all c:Prop.all b:Πx:Prf t1 .Prf t2 → Prf c.c.

Define pairing and first projection for exists. Unfortunately, it is not possible to define a second projection. 2

2.7

Relating Abstractions: Pure Type Systems The Calculus of Constructions is a very expressive system, but at first sight, somewhat difficult to understand because of the rich mix of different “levels” of typing (especially in its original formulation with Prf implicit). Given a lambda term λx : S.t, we cannot tell without (possibly lengthy) further analysis of S and t whether this is a term-level function, a type abstraction, a type family, a type operator, or something else. Partly as an attempt to explain the fine structure of CC, Barendregt introduced the lambda cube of typed calculi (briefly introduced in TAPL, Chapter 30), illustrated below: CC Fω

·

F

·

·

λ→

λP

The cube relates previously known typed lambda calculi (recast within a uniform syntax) to CC, by visualizing three “dimensions” of abstraction. In the bottom left corner, we have λ→ with ordinary term-term abstraction. Moving rightwards, we add the type-term abstraction characteristic of dependent types: λP is the Lambda Cube’s version of our λLF. Moving upwards, we add the term-type abstraction of System F, capturing polymorphism. Finally, moving towards the back plane of the cube, we add the higher-order type-type abstraction characteristic of F ω .

Pure Type Systems The type systems of the Lambda Cube, and many others besides, can be described in the setting of pure type systems (Terlouw, 1989; Berardi, 1988; Barendregt, 1991, 1992; Jutting, McKinna, and Pollack, 1994; McKinna and Pollack, 1993; Pollack, 1994). There is an simple and elegant central definition of Pure Type System (PTS) using just six typing rules, which captures a

72

2 Dependent Types

λP Syntax t ::= s x λx:t.t tt Πx:t.t s ::= ∗

2 Γ

Γ `t:T

Typing

::= ∅ Γ , x:T

terms: sort variable abstraction application dependent product type sorts: sort of proper types sort of kinds contexts: empty context variable binding

Γ ` ∗: 2

(T-Star)

x:T ∈ Γ

(T-Var)

Γ `x:T Γ `S:∗

Γ , x:S ` t : T

Γ ` λx:S.t : Πx:S.T Γ ` t1 : Πx:S.T

Γ ` t2 : S

Γ ` t1 t2 : [x , t2 ]T Γ ` S : si

Γ , x:S ` T : sj

Γ ` Πx:S.T : sj Γ `t:T

T ≡ T0

Γ ` T0 : s

Γ ` t : T0

(T-Abs) (T-App) (T-Pi) (T-Conv)

where (si , sj ) ∈ {(∗, ∗), (∗, 2)}. Figure 2-9: First-order dependent types, PTS-style (λP)

large family of systems constructed using Π-types. This uniform presentation allows one to establish basic properties for many systems at once, and also to consider mappings between type systems (so-called PTS morphisms). A presentation of λLF as a Pure Type System is given in Figure 2-9. The first thing to notice about PTSs is that there is a single syntactic category of terms, used to form types, terms, and abstractions and applications of different varieties. Although formally there is a single syntactic category, we use the same meta-variables as before, to aid intuition. (So the letters T and K and also range over the syntactic category of terms, but the system will determine that they are types and kinds, respectively). To allow levels of types and kinds to be distinguished, the PTS framework uses tokens called sorts to classify different categories of term, within the formal system itself. The system λP requires two sorts: first, ∗, which is the kind of all proper types, as used before, and second, 2, which is the sort that classifies well-formed kinds. Judgments of the form Γ ` T : ∗ replace Γ ` T :: ∗ from Figure 2-1, and judgments Γ ` K : 2 replace Γ ` K. The rule T-Pi controls formation of Π-types, by restricting which sorts we are allowed to quantify over. In turn, this restricts which λ-abstractions can be introduced by T-Abs. For λLF, there are two instances of λ-abstraction and

73

2.7 Relating Abstractions: Pure Type Systems

two instances of Π-formation. In the PTS presentation, these are captured by the two pairs of sorts allowed in T-Pi. When si = sj = ∗, we have the firstorder dependent product type, and when sj = 2 we have the kind of type families, corresponding respectively to K-Pi and Wf-Pi in Figure 2-1. The conversion rule is the main point of departure. The equivalence relation s ≡ t in Pure Type Systems is defined between untyped terms, as the compatible closure of β-reduction. This has a strong effect on the metatheory. 2.7.1

Exercise [««««]: Using the obvious mapping from the syntax of λLF into the syntax of λP, give a proposition stating a connection between the two presentations. Try to prove your proposition. 2

Systems of the Lambda-Cube and Beyond The other systems of the Lambda Cube can be expressed using the same rules as in Figure 2-9, with the single difference of changing the combinations of pairs of sorts (si , sj ) allowed in T-Pi. This controls which kind of abstractions we can put into the context. The table below characterises the systems of the Lambda Cube: System

PTS formation rules

λ→ λP F Fω CC

{ (∗,∗) { (∗,∗), { (∗,∗), { (∗,∗), { (∗,∗),

(∗,2)

(∗,2),

(2,∗) (2,∗), (2,∗),

(2, 2) (2, 2)

} } } } }

Further PTSs are given by adjusting the axiom T-Star of Figure 2-9, which is another parameter in the formal definition of PTS. For example, if we take the axiom to be Γ ` ∗: ∗

(T-TypeType)

(together with the T-Pi restriction of {(∗, ∗)}), we obtain a system where ∗ is the sort of all types including itself. In this system, all types are inhabited and there are non-normalizing terms (as in the result of Coquand, 1986 mentioned on page 70). Though this renders the logical interpretation of the system meaningless, it is debatable whether such systems may nonetheless be useful in some situations as type systems for programming languages. For further details of Pure Type Systems, we refer the reader to the references given at the end of the chapter.

74

2 Dependent Types

2.8

Programming with Dependent Types The task of building practical programming languages with dependent types is a topic of current research. Early languages include Pebble (Lampson and Burstall, 1988) and Cardelli’s Quest (Cardelli and Longo, 1991). Programming in Martin-Löf’s type theory is described in the monograph (Smith, Nordström, and Petersson, 1990). More recently, Augustsson introduced a language called Cayenne (1998), with a syntax based on the functional programming language Haskell, and Xi and Pfenning studied the language Dependent ML, based around a fragment of Standard ML (1998; 1999). The difference between Cayenne and Dependent ML goes beyond the choice of underlying language, and serves to illustrate a fundamental design decision for practical programming with dependent types.

Languages with Undecidable Typechecking Given the expressivity of dependent types as illustrated in previous sections it is natural and tempting to add them to a programming language. The price for this expressivity is, however, the complexity of typechecking. As we have explained, typechecking dependent types requires deciding equality of terms as a subtask which in turn requires the underlying term language to be strongly normalizing. On the other hand, most practical programming languages provide general recursion with possible nontermination. Simply adding dependent types to a Turing-complete term language invariably leads to undecidable typechecking. Of course, typechecking remains semi-decidable, so one can simply wait for an answer for a reasonable amount of time before giving up and turning the typechecker off. This is basically the (surprisingly successful) approach undertaken in Cayenne. Another example is the theorem prover PVS (1996) which includes a dependently-typed programming language (at the time of writing, in an experimental stage), and also has semi-decidable typechecking. In PVS, however, it is possible to resort to interactive theorem proving to aid the type checker. Undecidablef typechecking is not to the taste of all programming language designers, and for reasons such as scalability, may not be suitable for general application. The alternative is to consider dependently typed languages built around standard programming language features, yet with low-complexity typechecking algorithms. To achieve this one must sacrifice some of the generality of dependent types. Dependent ML (DML) is a proposal which follows this approach, which we will investigate in more detail in the remainder of

75

2.8 Programming with Dependent Types

this section. A type system closely related to that of DML, but aimed at Haskell, was studied by Zenger, under the name indexed types (1997). Exactly because this class of type systems have the desirable feature that they provide “static” typechecking independently from execution or equivalence checking of terms, some authors prefer not to call them “dependent” at all. The definition of dependent types given in Chapter 8 is slightly stricter than ours, and contrasts statically typed languages like DML and Indexed Types with languages where there is a lack of phase distinction between the compilation and execution of a program (see page 305).

A Simplified Version of Dependent ML The crucial idea behind DML is that type dependency on terms is not allowed for arbitrary types, but only for certain index sorts. Typechecking gives rise to well-behaved constraint systems on terms belonging to index sorts. Typechecking and even (to an extent) type inference can then be reduced to a constraint-solving problem over the index sorts, which is decidable. In this presentation we fix the index sorts to be integer numbers and linear subsets thereof, although Pfenning and Xi consider richer possibilities. We also base the language on the lambda-calculi we have studied so far, rather than a form of Standard ML. Before going into details we will look at some simple examples concerning vectors. We write int for the index sort of integers and assume a basic type data and a basic type family Vector : int→∗ where Vector[n] denotes arrays over data of length n as usual. Note that, for example, Vector[-1] will be empty. Next, we introduce the constants nil : Vector[0] cons : Πn:int.data → Vector[n] → Vector[n+1]

and a construct for pattern matching obeying the following typing rule: Γ ` t1 : Vector[i] Γ , i=0 ` t2 : T Γ , n:int, x:data, l:Vector[n], i=n+1 ` t3 :T Γ ` match t1 with nil → t2 | cons[n](x,l) → t3 : T

(Match-Vector)

There are several things to notice here. Types distinguish between ordinary non-dependent function spaces T1 →T2 and type families indexed by index sorts, Πx:I.T. Application for Π-types is written using square brackets. Contexts contain bindings of index variables to index sorts, type variables to types, and constraints over terms of index sort. Here the constraints are equations; in general they may be propositions of some restricted form so as to retain decidability.

76

2 Dependent Types

In our setting, nil, cons, and match are just interesting for their typing behaviors. We might postulate the obvious conversion rules for instances of match, to define a term equality judgment as studied earlier. But it is important to realize that we needn’t do this for the purpose of typechecking, since for DML-style systems term equality is completely decoupled from typing. In examples we will allow the definition of recursive functions by first declaring them with their type and then giving an accordingly typed implementation which may involve calls to the function being defined.4 Example: Appending Vectors We want to define a function for appending two vectors. It should obey the following typing: append : Πm:int.Πn:int.Vector[m] → Vector[n] → Vector[m+n]

To do this we define the body of append as follows: append-body = λm:int.λn:int.λl:Vector[m].λt:Vector[n]. match l with nil → t | cons[r](x,y) → cons[r+n](x,append[r][n](y,t)

We should prove that append-body has the same type as append. Let Γ = m:int, n:int, l:Vector[m], t:Vector[n]. After applying the rule Match-Vector backwards we are required to show that Γ , m=0 ` t : Vector[m+n] and Γ , r:int, x:data, y:Vector[r], m=r+1 ` cons[r+n](x,append[r][n](y,t) : Vector[m+n] For the first requirement, we notice that Γ , m=0 ` n=m+n:int from which the claim will follow by the type conversion rule and the obvious type equivalence which equates instances of Vector indexed by equal index terms: Γ ` i=j Γ ` Vector[i]=Vector[j] This rule is an instance of QT-App for DML families. For the second requirement, we first notice that, given the purported typing of append, the append-subterm has type Vector[r+n], thus, by the typing of cons the term itself has type Vector[r+n+1], but in the given context, this is equal to Vector[m+n] hence the required typing follows by type conversion again. 4. One can achieve this effect with a constant fixT : (T→T) → T for any type T.


77

Example: Splitting a Vector This example illustrates DML’s restricted form of Σ-types. Again, we have both dependent sums indexed by index sorts, and non-dependent sums (i.e., ordinary cartesian products). We will use the following type abbreviation: T(m) = Σp:int.Σq:{ i | p+i=m }.Vector[p] * Vector[q]

The type T(m) has elements of the form (p,(q,(k,l))), which we shall write as (p,q,k,l) to avoid excessive parentheses. The terms p and q are integer indices, obeying the constraint p + q = m. Now we can define a split function that partitions a vector into two pieces of given lengths: split : Πm:int.Vector[m] → T(m) split-body = λm:int.λl:Vector[m]. match l with nil ⇒ (0,0,nil,nil) : T(0) | cons[r](x,y) ⇒ let (p,q,u,v) = split[r](y) in if test(x) then (p+1, q, cons[p](x,u), v) : T(r+1) else (p, q+1, u, cons[q](x,v)) : T(r+1)

where test(x) is some unspecified boolean-valued term. The typing of split guarantees that the result vectors could be appended to form a vector with the same length as the input. Notice that we can say that there is some pair p and q such that p+q=m where m is the length of the input, but with the restricted form of predicates in DML, we cannot say that p is equal to the number of elements x from the input for which test(x) is true. To see how split is typed, let Γ = m:int, l:Vector[m]. We have Γ , m=0 ` T(0)=T(m) which deals with the first case of the match. For the second case, we need to show Γ , p:int, q:int, p+q=r, u:Vector[p], v:Vector[q], r+1=m ` (p+1, q, cons[p](x,u), v) : T(r+1) = T(m) and similarly for the else-branch of the if statement. Again this follows from trivial equational reasoning, and the expected rules for sum types.

Definition of Simplified DML Figure 2-10 summarizes the syntax of our simplified form of DML. Most of the typing rules are routine, so we leave completing the system to exercises. The definition of DML is closely related to λLF with Σ-types, except that dependencies are restricted to special terms of index sorts, so there is a partitioning of the syntax. Index sorts comprise the integers and subsets of index

78

2 Dependent Types

DML I ::= int {x:I | P} P ::= P∧P i= 13 The judgments can be defined formally using the obvious interpretation of the index syntax in Z (see Exercise 2.8.1). In practice we are of course interested an algorithm for deriving the two judgments. In our simplified version of DML, both judgments Γ |= P and Γ |= i:I are decidable, and there are well-known methods which we can use for handling linear equalities over the integers. In the case of a more complicated index language the judgments might both be undecidable; for instance, if we allow multiplication of index terms and existential quantification in propositions then undecidability follows from the undecidability of Hilbert’s 10th problem. In the typing rules, the semantic judgment is used whenever we need to check that an index term belongs to an index sort. For example, the rule for type family application becomes: Γ ` S :: Πx:I.K

Γ |= i : I

Γ ` S[i] : [x , i]K

(DML-K-App)

The typing rules for the remainder of the language are defined similarly to λLF and the simply-typed lambda calculus. For instance, we have the following rule for index abstraction: Γ , x:I ` t : T Γ ` λx:I.t : Πx:I.T

(DML-I-Abs)

but for ordinary abstraction we introduce the arrow: Γ , x:S ` t : T Γ ` λx:S.t : S → T

(DML-T-Abs)

There are similarly two rules for pairing and for projections. For the projection of an indexed pair, we have the dependent case: Γ ` t : Σx:I.T

Γ , x:I, y:T ` t0 : T0

Γ ` let (x,y)=t in t0 : T0

(DML-I-Proj)

80

2 Dependent Types

We can also follow the same procedure as for λLF to formulate an algorithmic version of typing; the difference is that algorithmic type equality amounts to checking of index constraints which can be performed semantically by constraint solving, without any normalization. In particular, equality of terms is not intertwined with typechecking at all. The crucial rule for algorithmic equality is Γ `ñ S1 ≡ S2

Γ |= i1 = i2

Γ `ñ S1 i1 ≡ S2 i2

(DML-QIA-App)

where the second judgment is an instance of the semantic consequence judgment Γ |= P. 2.8.1

Exercise [««]: Give a semantic interpretation of DML index syntax. Considering only the index variables in Γ , an index environment η is a function from index variables to integers. Given this notion, we can define Γ |= P as ∀η. η |= Γ . =⇒ η |= P. Complete the definition. 2

2.8.2

Exercise [«««, 3]: Complete the presentation of DML by defining the typechecking judgments and give an algorithm for typechecking. 2 Closing Example: Certifying Parameters Several motivating application examples have been given for DML in the literature, including eliminating array bounds checks and unnecessary cases from pattern matches. Rather than repeat those examples, we give a slightly different kind of example to illustrate the use of DML-style typing to certify that constraints are met on parameters of functions.5 The scenario is that we are programming for an embedded system which is providing safety features for an onboard computer in an automobile. We are provided with a system call: brake : int * int → unit

where it is safety critical that whenever brake is called with parameters (x,y) then some proposition P (x, y) must be satisfied, for example, a conjunction of linear inequalities describing some “safe window.” To guarantee this, we should try to type our main program under the following assumed typing for brake. Notice that brake is provided as a system call, so we can assume an arbitrary typing for it. brake : {(x,y) : int * int | P} → unit 5. This example is taken from the project Mobile Resource Guarantees (EU IST-2001-33149); see http://www.lfcs.inf.ed.ac.uk/mrg.


81

where P encodes P (x, y). Unfortunately, this typing does not quite fit into the DML-framework since it unduly mixes index sorts and ordinary types. To repair this, we introduce a type family Int : int → ∗ with the intuition that Int(x) is a singleton type containing just the integer x, as a “run-time” integer rather than an index term. We also need special typings for run-time integers: 0 : Int(0) 1 : Int(1) plus : Πx,y:int.Int(x) → Int(y) → Int(x+y) timesq : Πx:int.Int(x) → Int(qx)

where q is a fixed integer. These typings allow us to reflect the index terms in ordinary terms. Moreover, we need a type family Bool:int→∗ with the intuition that Bool(x) contains true if 1 x] : T value declaration

T ::= . . . m.X

types: type selection

t ::= . . . m.x

terms: value selection

Γ

::= ∅ Γ, D

D ::= m:I

typing contexts: empty declaration declarations: module declaration

Figure 8-1: Basic module syntax

variable to a module expression, perhaps with a specified signature. A signature binding binds a signature variable to a signature. The scope of a binding in a program is the remainder of the program following that binding. The final module binding is the root module. Signature bindings are used to give names to signatures: a bound signature variable is simply an abbreviation for the right-hand side of its binding. A basic module consists of a sequence of component bindings, which are either type bindings or value bindings. A type binding is a binding of a type variable to a type expression. A value binding binds a run-time entity to a term variable. These entities may include procedures, classes, objects, mutable reference cells, and other structures from the core language. Each component binding has both a label, which is underlined, and a variable, which is not. The variable governs references to that binding within the module; the label governs reference from outside of the module. For this reason the label is sometimes called the external name of the component, and the variable its internal name. The use of a label from outside of a module to designate one of its components is called an external reference; the use of a variable from inside the module to designate a preceding binding is called an internal reference. If m is a module variable, then m.X is an external reference to the type component of m labeled X, and m.X is an external reference to the value component of m labeled x.

8.1 Basic Modularity

297

Internal names are bound variables whose scope is the rest of the module in which they occur. As such, internal names may be chosen (and renamed) arbitrarily without affecting the meaning of the module, subject only to the usual requirement that distinct bound variables not be confused in a given scope. In contrast the external name of a component of a module cannot be renamed without affecting the entire program in which that module occurs. This distinction between external and internal names is necessary for both conceptual and technical reasons (detailed in §8.6). In most cases, however, it is not important to emphasize the distinction, so we take the liberty of providing a single name for each component binding with the understanding that it plays a dual role as both the external and internal name of that component. A basic signature consists of a sequence of component declarations, either a type declaration or a value declaration. A type declaration is a labeled type binding, with the same syntactic form as a type binding in a module. A value declaration defines the type of a term variable, but does not give its actual binding. As with bindings, we usually assign a single name to each declaration with the understanding that it serves as both the internal and external name of that component.

Examples Here is a simple module binding: module m = mod { type X = Nat val x = 5 }

The module bound to m includes one type binding and one value binding. These components are designated, externally, by m.X and m.x. Note that these are, respectively, core-language type and value expressions: the grammar of the core language is enriched to include external references to components of modules. Here is a more interesting module binding: module n = mod { type X = λW:*. W × W val f = λy:X(Nat). plus y.1 y.2 }

The right-hand side of the type binding X has kind *→* (i.e., this module is exporting a type operator). The right-hand side of the term binding f uses the previously bound operator X. This illustrates the impact of the module language on core-language type checking: in order to check that the core-

298

8 Design Considerations for ML-Style Module Systems

language expression λy:X(Nat). plus y.1 y.2 is well typed, we need to use the module-level information that X is definitionally equal to λW:*. W × W. The signature I introduced by the binding signature I = sig { type X = Nat val x : X }

describes the module m above, in a sense to be made precise shortly. Similarly, signature J = sig { type X = λW:*. W × W val f : X(Nat) → Nat }

binds J to a signature corresponding to the module n.

8.2

Type Checking and Evaluation of Modules To avoid getting bogged down in formalities, we describe type checking and evaluation throughout the chapter in English prose rather than giving precise, formal definitions. §8.11 offers a number of pointers into the literature for readers interested in a more technical treatment.

Type Checking Signatures are used to describe modules. If a signature I accurately describes a module M, then we say that M implements I. This relation may be defined in one of two ways. The direct method simply defines a correspondence between a module and any signature that it may implement. An indirect method is to associate with each module M a unique (up to suitable equivalences) principal signature|seesignatures, which is the “most precise” (least in the subtyping ordering) signature implemented by M. The latter method, though elegant, applies only in languages where every module actually has a principal signature. We start by defining the implementation relation directly and later discuss conditions under which it may be reduced to subtyping. We say that a basic module M implements a basic signature I if M contains at least the type and value components specified by I, up to type equivalence. That is, each type component declared in I must be bound in M with the same kind and an equivalent definition. (A type definition in a signature is an equational constraint that must be satisfied by any implementation of that signature.) Moreover, each value component declared in I must be matched by a value binding in M with a subtype of the type specified in I. The subtyping relation here is inherited from the core language, enriched to include the

8.2 Type Checking and Evaluation of Modules

299

expansion of definitions introduced by type bindings in modules and signatures. When a module binding specifies a signature, the type checker ensures that its right-hand side implements this signature. For example, the following bindings are well-formed because the module bound to m implements the signature I: signature I = sig { type T = Int type U = Int × Int val x : U } module m : I = mod { type T = Int type U = T × T val x : T × T = (3,4) }

Since I provides definitions for the types T and U and declares the value x, it follows that m.T and m.U are valid type expressions (equal, respectively, to Int and Int × Int), and m.x is a valid value expression (of type m.T × m.T, which is equivalent to m.U). To account for external references during type checking, each module variable is assigned a signature by a typing context. The assignment of a signature to a module variable amounts to the assumption that it will be bound to a module implementing that signature. This is enforced during linking, which is described in more detail in §8.3.

Signature Matching Since signatures are descriptions of modules, it is natural to consider a subtyping relation between signatures, called signature matching and written II. (Note the similarity to the term-level ascription operator described in TAPL, Chapter 11.) A sealed module expression M:>I is well-formed only if M implements I; the sealed module is considered to implement I (and, by subsumption, the supertypes of I). A sealed module is evaluated by stripping off the seal and evaluating the underlying module. This reflects the informal idea that data abstraction is relevant only during type checking and has no significance at run time. For example, consider the signature, I, given in the preceding subsection, and the following module expression, M: mod { type X = Nat type Y = X→Nat val c = 5 val f = λx:X. succ x }

It is easy to check that M implements I, so that M:>I is a well-formed module expression with signature I. Since X is held abstract by I, no use of the sealed module may rely on its identity. A “decorated” module binding of the form module m : I = M may be seen as syntactic sugar for the “bare” binding module m = (M:>I)—that is, the module M is implicitly sealed with signature I by the binding. For example, if M and I are as in the preceding example, then the module binding module m = M:>I

assigns to m the signature I. Since I holds X abstract, m.X is opaque, whereas m.Y is equivalent to m.X→Int.

311

8.5 Abstract Type Components

M, N ::= . . . M!I

modules: sealing

T, U ::= . . . M .X

type: type selection

t, u ::= . . . M .x

term: value selection

Figure 8-3: Mechanisms for abstraction

The formalization of abstract types considered here differs from conventional existential types (as described in TAPL, Chapter 24) by separating the imposition of abstraction on a module from any means of binding that module or its components to variables. In the existential framework abstraction is imposed through a binding construct that holds the representation type of the abstract type abstract within a specified scope, which is a single core language expression. For this reason existential types are sometimes said to impose a closed scope abstraction discipline. However, in the presence of translucent sums, it is also necessary to make direct reference to abstract types within types, as well as terms. Achieving this using existential types requires that the abstract type binding be “extruded” to encompass essentially the region of a program in which it is used. In practice this means that the lowest-level, and most widely used, abstract types must be given the largest scope, thereby everting the natural structure of the program. In contrast the present framework is based on an open scope mechanism in which abstraction is imposed without specifying the scope in which it may be used. This avoids the complex re-structuring required in the pure existential framework, and, moreover, scales naturally to support later extensions to the language. To support open-scope abstraction we extend the grammar of module expressions to permit sealing, remove signatures from module bindings, and permit type and value selection from an arbitrary module expression. (See Figure 8-3 for the revised grammar.) One consequence of sealing modules with abstract type components is that signatures may now contain unavoidable dependencies on modules. For example, consider the following bindings: signature I = sig { type X val c : X val f : X→X }

312


module m : I = mod { type X = Int val c = 0 val f = succ } signature J = sig { type Y val d : m.X } module n : J = mod { type Y = m.X val d = m.f(m.f(m.c)) }.

Since J contains a reference to m.X, which is opaque, the signature J is only sensible within the scope of the binding for m. The meaning of the signature J is tied to the binding of the module variable m. In particular, any module implementing J must define Y to be equivalent to m.X.

Determinacy and Abstraction Any adequate abstraction mechanism must ensure representation independence, which ensures that the behavior of clients are insulated from the details of the implementation of an abstraction. We will not attempt to give a precise definition of independence here (but see work by Reynolds (1974) and Mitchell (1986)). At a minimum, though, it should ensure that if the modules M and N implement the interface I, then replacing M:>I by N:>I should not disturb the type correctness of a program. In particular, if the type X is abstract in I, then the definition of X must not “leak” from M:>I so as to affect the type correctness of client code. For if it did, then we could choose N to conflict with M on the definition of X and violate even this minimum requirement for abstraction. This suggests that representation independence is closely tied up with type equivalence—when is one abstract type equivalent to another? In particular, when is (M:>I).X equivalent to (N:>I).X? To ensure that type equality is reflexive (as surely it ought to be), we must ensure that this equivalence hold whenever M and N are equivalent. But module equivalence is, in general, undecidable and, moreover, conflicts with the phase distinction, both undesirable. To avoid this, we simply prohibit type selection from sealed modules so that embarrassing questions such as these never arise. Another strong reason to limit type selection is to ensure type safety in the presence of first-class modules. Since type expressions may be compared


313

for equality with other types during type checking, it is important to ensure that every type expression stand for a fixed type at compile time. Surprisingly, first-class modules violate this seemingly innocent requirement. For example, if M is the conditional module expression if ... moon-is-full ... then mod { type X = Int } else mod { type X = Bool }

then M.X might turn out to be either Int or Bool, but we cannot tell which at compile time. Consequently, it makes no sense to compare M.X for equality with another type. The following exercise shows that permitting such type expressions is, in fact, unsound. 8.5.3

Exercise [«««]: Devise an expression t involving unrestricted selection from the first-class module expression M that incurs a type error at run time. 2 Now a first-class module expression such as this can only be well-formed if we seal it with an interface that hides the identity of the type component X. This establishes a close connection between first-class modules and sealing that provides further support for the prohibition of type selection from sealed modules. More generally, since a sealed module may, in fact, be first-class, its abstract type components may or may not be statically welldetermined. Consequently, we must “assume the worst” of it, and prohibit type selection. At the present stage of development, only sealing poses any problems for type selection, but, as we enrich the language, further constructs (such as application of a generative functor) raise similar concerns. It is therefore useful to isolate a subset of module expressions, the determinate ones, whose type components are statically known and can be selected without fear of violating safety or representation independence. The remaining module expressions are said to be indeterminate; they do not permit type selection. Basic module expressions, including module values, are determinate because they provide explicit definitions for their type components. For example, the module expression (call it M) mod { type X = Bool type Y = X→X val x = false val f = not }

is determinate because we can see immediately that M.X is equivalent to Bool and M.Y is equivalent to Bool→Bool.

314


By forcing evaluation of its right-hand side, a module binding resolves any indeterminacy before the module variable is bound to the resulting value. Consequently, module variables are also determinate. For example, consider the following module binding: module m = if ... moon-is-full ... then mod { type X = Int } else mod { type X = Bool }

Even though the conditional is indeterminate, the variable m is determinate. In fact, the only way (so far) to make use of an indeterminate module expression is to bind it to a variable and refer to that variable to access its components. This sheds light on the informal idea that abstract types are “new” in the sense of being distinct from all other types in a program, regardless of any coincidences of representation. By α-conversion the name of a bound variable is automatically changed so as to avoid clashes with any other module variable in scope at that point in the program, thereby ensuring that its abstract type components are “new.” 8.5.4

Exercise [«]: What would go wrong if we changed the evaluation of module bindings to call-by-name? 2 For the time being, module values and variables are the only determinate module expressions. Sealed modules are indeterminate, for the reasons outlined above.

8.5.5

Exercise [«]: Show that if sealed modules were determinate, then representation independence could be violated. That is, find a well-typed term t whose type correctness is destroyed by replacing one implementation of an abstract type with another. 2

8.5.6

Exercise [«]: Why would it be bad for two copies of M:>I to induce interchangeable abstract type components? 2 This same observation also accounts for the informal idea that data abstraction ties a type to a particular set of operations that interpret it: any non-trivial computation with a value of that type must be through these operations. This greatly facilitates maintaining a representation invariant on the data structure, since those, and only those, operations may potentially violate it. Moreover, by insisting that sealed modules are indeterminate, we ensure that the operations from two different abstract types are not interchangeable, even if the underlying representations of values of those types are the same.


8.5.7

315

Exercise [Recommended, ««]: Devise an example of two implementations of an abstract signature that share a common representation type but differ in the operations used to interpret it. Assuming that these two implementations give rise to the same (but hidden) abstract type, give a program (using sealing as a determinate construct) that incurs an error that would otherwise be avoided. 2 An important special case of this arises when the implementation of an abstraction involves private state. In that case two instances of the abstract type must be kept distinct, even though both the representation type and the code of the associated operations are identical! The following exercise explores one example of what can go wrong.

8.5.8

Exercise [Recommended, ««]: Devise an implementation of a hash table involving state, and show that, if two instances of the hash table were to determine equivalent abstract types, then errors could arise that would otherwise be avoided. 2

The Avoidance Problem Consider a local module binding construct of the form let module m = M in M’.

This expression implements the signature I0 provided that (1) M implements some signature I, and (2) M0 implements some signature I0 under the assumption that m implements I. At first glance, it would seem reasonable to say that the principal signature for a let expression would simply be the principal signature (I0 ) of its body. But what if the principal signature of the body involves an abstract type component from M? For example, consider the following the module expression: let module m = M :> I in mod { val z = m.y }

where I is the signature sig { type X val y : X }.

316


Clearly, the principal signature of the body of the let is sig { val z : m.X }. But this signature cannot be the type of N, because it involves an essential reference to the locally bound module variable m. (An analogous observation for the unpack form for existential types motivates the scoping restrictions discussed in TAPL, §28.7.) It is tempting to consider N to be ill-formed, since it attempts to export the type m.X outside of its scope. But this neglects the possibility that N has some signature that does not involve m.X. For example, if the core language subtype relation has a maximal type Top, then another possible signature for the body of the let is sig { val z : Top }. Indeed, this may even be the principal signature for N. In general, the principal signature of a let expression of the form let module m = M in M0 is the least signature for M0 that does not involve the bound module variable m. The problem of finding such a signature is called the avoidance problem. First reported by Ghelli and Pierce (1992) in the context of System F≤ , the avoidance problem is a central design issue for module systems that support data abstraction. Unfortunately, it does not appear to admit a completely satisfactory solution. In some languages (including ML), there exists a signature I involving a module variable m with more than one minimal super-signature avoiding m, none of which is least. In such cases the occurrence of m cannot be avoided without losing valuable type information. 8.5.9

Exercise [«««]: Consider a signature I sig { type X = λW:*. m.Z type Y = m.Z }

containing a free module variable m whose signature has an abstract type component Z. Show that I has infinitely many super-signatures that avoid m, but none that is a sub-signature of all the others Assume, for this exercise, that the core language is just F ω , with no subtyping between core-language types. (For substantial extra credit, find a similar example where the core language is full F≤ .) 2 What to do? A fallback position is to admit as well formed those let expressions for which there is a principal signature avoiding the bound module variable, and to reject all others. The trouble is that there is no simple characterization of which modules admit principal signatures and which do not. Reliance on a particular algorithm for detecting cases for which a principal signature exists ruins the declarative nature of the type system. An al-

317

8.6 Module Hierarchies

CB ::= . . . component bindings: module m [> m] = M module binding

M ::= . . . M.m

modules: module selection

CD ::= . . . component declarations: module m [> m] : I module declaration Figure 8-4: Mechanisms for hierarchy

ternative is to require the programmer to specify the signatures of all let expressions. Rather than solving the problem, this approach simply shifts the burden to the programmer. Another possibility is to prohibit leaving the scope of a module variable whose signature has an abstract type component. This means that all abstract types must be global, rather than local. To soften the blow we may rename locally declared abstract types with special names that indicate that they are “hidden,” relying on a programming convention to avoid using types with such names. Such a convention may be systematically imposed by “name mangling” during elaboration of the source language program into internal form. Using this approach, hiding abstract types can be handled in much the same manner as type inference, pattern compilation, and overloading resolution (Dreyer, Crary, and Harper, 2003).

8.6

Module Hierarchies To avoid name clashes, it is useful to organize a collection of module bindings into “clusters” of closely related bindings with more limited cross-cluster dependencies. This may be achieved by permitting module bindings to occur as components of other modules (with the usual distinction between its internal and external names). Correspondingly, we introduce a new form of module expression, the selection of a module component from another module. The additional syntax to support module hierarchies is given in Figure 8-4. A module that is bound within another is called a submodule of the surrounding module. Most of the properties and relations associated with modules are extended recursively to sub-modules. For example, if all of the submodules of a module are determinate, then so is the module itself. Equivalently, if any sub-module is indeterminate (in particular, if it is sealed), then the module itself is indeterminate. The implementation relation between modules and signatures is extended recursively to submodules so that the module

318


module q = mod { module m = mod { val x = 5 val y = 6 } module n = mod { val z = 7 } }

implements this signature: signature Q = sig { module m : sig { val x:Nat val y:Nat } module n : sig { val z:Nat } }

The signature matching relation is extended covariantly to submodules. For example, the signature Q above matches the signature signature Q’ = sig { module m : sig { val y:Nat } }

(among others). Besides simple namespace management, hierarchical modularity is also useful in representing compound abstractions. A familiar example is the dictionary abstraction, which builds on the concept of a linearly ordered type of keys. The layering of dictionaries atop keys is naturally expressed using a module hierarchy. signature Ordered = sig { type X val leq : X × X → Bool } signature Dict = sig { module key : Ordered type Dict : *→* val new : ∀V. Dict V val add : ∀V. Dict V → key.X → V → Dict V val member : ∀V. Dict V → key.X → Bool val lookup : ∀V. Dict V → key.X → V }

The Ordered signature specifies a type equipped with a binary operation that is intended to be a total ordering of that type. The Dict signature specifies a sub-module key implementing an ordered type.

319

8.6 Module Hierarchies

The types of the operations declared in the signature Dict make reference to the type key.X, the type of keys. This illustrates the dependence of the “rest” of a signature on (the type components of) a preceding sub-module declaration. Strictly speaking, the type selections key.X occurring within the signature Dict refer to the internal name of the sub-module key, whereas any selections from a module implementing Dict refer to the external name, or label, of that sub-module. To distinguish these two aspects of the sub-module declaration we may write the Dict signature as follows: signature Dict = sig { module key > k : Ordered type Dict : *→* val new : ∀V. Dict V val add : ∀V. Dict V → k.X → V → Dict V val member : ∀V. Dict V → k.X → Bool val lookup : ∀V. Dict V → k.X → V }

In most cases it is not necessary to make explicit the distinction between the internal and external name of a sub-module, and we rarely do. However, there are situations in which the distinction is critical, as in the following example. Consider the following module expression (call it M): mod { type X = Int module m = mod { type X = Bool val f = λa:X. 3 } }

We wish to assign a signature to M that specifies M.m.f to be a function of type M.m.X→M.X. Without distinguishing internal from external names, there is no way to write such a signature while holding M.m.X and M.X abstract. The only possible attempt sig { type X module m : sig { type X },

val f : X → X }

fails because of shadowing of the outer declaration of X by the inner one. However, by distinguishing the internal from the external name, we may write the desired signature as follows:

320


sig { type X > X’ module m : sig { type X > X” }.

val f : X” → X’ }

Since the internal name is a bound variable, it may be renamed at will, thereby avoiding problems of shadowing. Returning to the Dict signature, the declaration of the sub-module key indicates that any module implementing Dict comes equipped with its own ordered type of keys. At first glance this may seem unnatural, since we do not ordinarily expect a dictionary abstraction to provide an ordered type of keys, but rather to require one. The distinction is largely a matter of perspective. Even though the key sub-module is a component of an implementation of Dict, it would ordinarily be obtained “off the shelf” by reference to another module such as the type of integers ordered by magnitude, or the type of strings ordered lexicographically. However, nothing precludes defining the key module “in place,” for example in the case that there is precisely one dictionary in use in an entire program. Conversely, we would ordinarily expect the type constructor Dict to be constructed as part of the implementation of Dict, but this need not be the case. We might, in fact, copy this type from another module, say a generic implementation of balanced binary search trees. Or we may choose to construct a suitable data structure “on the spot.” Thus, the components of a module may sometimes play the role of an “argument” to that module, yet at other times play the role of a “result.” This flexibility is of particular importance when considering families of signatures and modules, to which we now turn.

8.7

Signature Families To support code re-use, it is important to isolate repeated patterns in both modules and signatures so that we may consolidate what is common to many instances, allowing only the essential differences to vary. This is achieved by introducing families of signatures and modules that isolate the pattern and that may be specialized to recover a specific instance of the pattern. In this section we consider families of signatures; families of modules are discussed in §8.8. A good example of the need for signature families is provided by the Dict abstraction in the preceding section. An implementation of the Dict signature for an ordered type of keys takes the following form:

8.7 Signature Families

321

module dict1 = mod { module key = key1 type Dict = λX:* . ... ... }

Here key1 is some module implementing the signature Ordered. The principal signature for dict1 specifies the type of keys: signature Dict1 = sig { module key : sig { type X = key1 .X val leq : X × X → Bool } type Dict : *→* ... }

We may seal the module dict1 with the signature Dict1 to ensure that the type constructor Dict is held abstract. Note that it would not make sense to seal dict1 with the signature Dict. 8.7.1

Exercise [«]: Why?

2

Now suppose that we wish to implement a second dictionary whose keys are drawn from the module key2 . As matters stand, we have no choice but to replicate the same text, replacing key1 by key2 wherever it occurs. signature Dict2 = sig { module key : sig { type X = key2 .X val leq : X × X → Bool } type Dict : *→* ... } module dict2 :> Dict2 = mod { module key = key2 type Dict : *→* = ... ... }

Doing this makes the code unnecessarily difficult to modify—any change to the signature Dict must be replicated for dict1 and dict2 .

322


Clearly, what is needed is some means of isolating the common pattern as a family of modules implementing a corresponding family of signatures, both indexed by the type of keys. That way we may obtain each dictionary signature and module as an instance of the family for the corresponding ordered type of keys. We turn first to the representation of families of signatures; families of modules are considered in the next section.

Representing Families There are two main ways of representing families, parameterization and fibration.6 Using parameterization, we explicitly abstract the type of keys from the Dict signature using a form of λ-abstraction. signature DictP = λY:*. sig { module key : sig { type X = Y val leq : X × X → Bool } type Dict : *→* ... }

Instances are obtained by application, writing signature Dict1 = DictP(key1 .X) signature Dict2 = DictP(key2 .X)

to obtain the signatures Dict1 and Dict2 that we wrote out explicitly above. Using fibration, on the other hand, we simply specify the type of keys by “patching” the generic Dict signature using a “where clause” as follows: signature Dict1 = Dict where key.X = key1 .X signature Dict2 = Dict where key.X = key2 .X

As with parameterization, the result of these declarations is the same as the explicit definitions of Dict1 and Dict2 given earlier. Observe that Dict1 and Dict2 both match Dict.7 6. This terminology is borrowed from category theory, which considers two methods for representing families of categories F indexed by a category I. An indexed category is a functor IndF : I op → Cat mapping I into the “category of categories”—roughly, a function from I to categories. A fibration is a functor (satisfying some conditions) FibF : F → I assigning to each family in F its index in I. Our use of this terminology is analogical, not technically precise. 7. These where clauses can be thought of as a form of “signature inheritance,” analogous to the “code inheritance” found in object-oriented languages. The fact that where clauses give rise to subtypes is a natural corollary.

8.7 Signature Families

323

In both representations, the family of signatures is indexed by a type. While theoretically sufficient, it is pragmatically unfortunate that, in both representations, the indexing type is separated from its interpretation in terms of operations. For example, since a type can be ordered in several different ways—for example, strings might be ordered lexicographically or by the prefix ordering—it is preferable to maintain the association of a type with its ordering operation. This may be achieved by generalizing type-indexed families to module-indexed families. In the present case this would amount to parameterization or fibration over a module implementing the signature Ordered. In parameterized form this would be written signature DictP’ = λkey : Ordered. sig { module key = key type Dict = ... ... }

with instances signature Dict1 = DictP’(key1 ) signature Dict2 = DictP’(key2 ).

In fibered form we would write signature Dict1 = Dict where key = key1 signature Dict2 = Dict where key = key2 .

In either case, instantiation of a signature family by a module may be viewed as a convenient form of type indexing, since it is only the type components of the instantiating module that affect the result. This is particularly useful in situations where the indexing module contains several type components, possibly nested within sub-modules. 8.7.2

Exercise [«««]: Give a formal definition of the operation I where m = M, making explicit any restrictions that must be made for this operation to be sensible. 2

Parameterization vs. Fibration The chief advantage of parameterization over fibration is familiarity. It is natural (especially for functional programmers) to consider a family of signatures indexed over implementations of a signature I as a “function” mapping implementations of I to signatures. Representing signature families by

324


parameterization requires a modest enrichment of the syntax to permit λabstractions and applications of signatures, an extension of signature equivalence to account for instantiation by substitution, and an extension of the type system to classify parameterized signatures as a kind of function. Fibering, on the other hand, avoids the need for a new form of signature family by exploiting submodule declarations, which are useful for other reasons. A more important difference is that the parameterized approach requires the programmer to anticipate the patterns of abstraction and instantiation that may arise in any future use of a given signature. When several (type or module) components are involved, it can be difficult to anticipate which are to be thought of as parameters and which are to be thought of as constructed components of the module. Indeed, the context may dictate one choice in one situation, and another in another. The fibered approach avoids the need to anticipate the future, because it affords a kind of “after the fact” parameterization—any module or abstract type component may be considered to be the “argument” in a given situation without prior arrangement. Taken in isolation, one may argue the advantages and disadvantages of either representation as compared to the other, with neither coming out a clear winner. However, when examined in the larger context of modular programming, a distinct advantage for fibration over parameterization emerges. To explain why this is the case, we must first consider families of modules.

8.8

Module Families Needless to say, the justifications for introducing families of signatures apply just as well to implementations. Continuing with the example from §8.7, we might well require, in the same program, several different dictionary modules, differing only in the choice of key type. We would then like to abstract the common pattern by forming a family of modules indexed by modules satisfying a particular signature (Ordered). A natural representation of a family of modules is as a λ-abstraction of a module expression over a module variable of a specified signature. Such an abstraction is called a parameterized module, or functor.8 Instances of the family are obtained by functor application.9 The syntax required to support functors is given in Figure 8-5. (This grammar permits higher-order functors, but for now we concentrate on the first8. Rod Burstall once remarked that if we do not call the factorial function a “parameterized integer,” then we should not call a functor a “parameterized module”! 9. We adopt here an indexed approach to module families, but it is worth noticing that a fibered approach also makes sense and has been explored under the name mixin modules; we discuss these briefly on page 343 below.

325

8.8 Module Families

M, F ::= . . . λ( m:I) N F(M) I ::= . . .

modules: functor application signatures:

Π ( m:I1 )I2 functor signature λm:I1 .I2 parameterized signature I1 I2 application I where X=T where signature

Figure 8-5: Mechanisms for functors

order case, in which only basic modules may be provided as functor arguments. See §8.9 for a discussion of the higher-order case.) The metavariables F and G range over functors. In §8.7 we noted that it would be useful to define a family of dictionary modules indexed by the type of keys. Using the notation of Figure 8-5, a dictionary functor might be written module dictFun = λkey:Ordered. mod { ... }

where ... represents some implementation of the dictionary type and operations. The dictionary module dict1 (with signature Dict1 , defined on page 320) would then be obtained by applying dictFun to the key module key1 : module dict1 = dictFun(key1 )

If a functor is a kind of function, then its signature should be like a function type—for example, the signature of the dictFun functor should be something like this: signature DictFun = Ordered → sig { type Dict : *→* val new : ∀V. Dict V val add : ∀V. Dict V → key.X → V → Dict V val member : ∀V. Dict V → key.X → Bool val lookup : ∀V. Dict V → key.X → V }

However, the arrow notation does not quite give us what we need because it does not express the dependency between the argument and the result of the dictionary functor—i.e., the fact that the module key appearing in the result signature is precisely the functor’s argument. To capture this dependency, we need an additional form of signature, called a functor signature, of the

326


form Πm:I.J. Such a signature binds the module variable m in the signature J, permitting the dependency of the result signature on the argument to be expressed. The signature I is the called the domain, and J is called the range. (The signature Πm:I.J is a form of dependent function type; see Chapter 2 for background.) The type of the dictionary functor given above may now be written as follows: signature DictFun = Πkey:Ordered. sig { type Dict : *→* val new : ∀V. Dict V val add : ∀V. Dict V → key.X → V → Dict V val member : ∀V. Dict V → key.X → Bool val lookup : ∀V. Dict V → key.X → V }

Instantiating DictFun by a module M implementing the domain signature Ordered yields a module whose type is the instance of the range signature obtained by replacing key by M throughout. 8.8.1

Exercise [«]: One might guess that a family of modules would have a family of signatures, but, instead of this, we introduced a new notion of functor signatures. Why? 2

8.8.2

Exercise [«]: Note that DictFun can be written more concisely in terms of the parameterized signature family DictP, as Πkey:Ordered. DictP(key). Can DictFun also be expressed using the fibered signature family Dict? 2 Functor arguments are required to be determinate because the range signature may involve type selections from the domain parameter (as in the example above). Substitution of the argument for the parameter results in a specialization of the range signature. Rather than use substitution, we may also formulate the typing rule for functor application using subsumption. Just as for ordinary function types, functor signatures are contravariant in the domain and covariant in the range. This implies that we may weaken a functor signature by strengthening its domain type. In particular, if F is a functor with signature Πm:I.J, and M is a determinate module with transparent signature I0 setFunInt = λA m : sig { type X }. mod { type Set = ... val insert = ... }

338


Notice that the functor itself is sealed with an applicative functor type to ensure that the Set type in the result is abstract. One consequence of restricting an applicative functor to have a determinate body is that neither its body nor any of its sub-modules may be sealed. (Were we to do so, the body would be indeterminate, forcing the functor to be generative.) This explains why we sealed the setFun functor itself, rather than writing it in the form module setFun = λm:sig { type X (mod { type Set = val insert } :> sig { type Set val insert ... }).

}. ... = ...

: m.X * Set → Set

While sealing the functor itself can be used to impose abstraction on its instances, it cannot be used to impose abstraction within the body of the functor. One way to remedy this deficiency is to distinguish two forms of sealing, static sealing and dynamic sealing, and two associated forms of indeterminacy, static indeterminacy and dynamic indeterminacy. The dynamic forms of sealing and indeterminacy are just those considered up to now. The static forms are added solely to enrich the class of applicative functors. A statically sealed module is statically indeterminate, which ensures representation independence. An applicative functor body is permitted to be statically indeterminate, but not dynamically indeterminate (which would force generativity). The terminology stems from considering that, for an applicative functor, abstraction is imposed once when the functor is type-checked, rather than each time the functor is applied; the abstraction effect is “static,” rather than “dynamic.”

8.9

Advanced Topics First-Class Modules The framework developed here is compatible with treating modules as firstclass values, by which we mean that we may readily enrich the language to permit modules to be manipulated as ordinary values in the core language. For example, we may store a module in a data structure, then retrieve it and

8.9 Advanced Topics

339

reconstitute it as a module-level expression, without violating representation independence or type safety. We need only ensure that any means of creating a module from a core language computation is considered indeterminate so as to preserve safety and representation independence. Why not just do away with the distinction between the core and module languages entirely? While this would seem to simplify matters by collapsing a distinction, it complicates the type theory significantly, requiring that the core language be enriched with the mechanisms required to support modularity. These include types for submodules and functors, a subtyping relation, and the means to ensure static type checking in their presence. These complications are not insurmountable. One such formalism was developed by Harper and Lillibridge (1994), who also showed that the type checking problem for this language is undecidable, due to complex interactions between subtyping, impredicative polymorphism, and type sharing specifications. Dreyer, Crary, and Harper’s formalism (Dreyer, Crary, and Harper, 2003), on the other hand, achieves adequate expressiveness, including support for first-class modules, without incurring undecidability. Finally, even if we were to attempt to consolidate the module and core levels, we would find ourselves facing the same questions at a higher level. For, as the development of this chapter makes clear, once we introduce separate compilation (as surely we must), we once again face the same questions of modularity, at the level of compilation units. Module arise even when you try to avoid them!

Higher-Order Modules Higher-order modules—i.e., functors taking functors as parameters—present some interesting further difficulties. The classic (if somewhat contrived) motivating example is the apply functor, defined as follows: module apply = λf:(Πi:I.J). λi:I. f(i) module m :> I = ... module f :> Πi:I.J = ... module n = f(m) module p = apply(f)(m)

One might expect that n and p are equivalent, since both apply f to m. But this need not be so, at least if we wish to give a single type for apply that governs all of its uses. For then we must specify whether the argument, f, to apply

340


is applicative or generative. If it is required to be applicative, we may ascribe the following type to apply: ΠA f:(ΠA i:I.J). ΠA i:I. (J where X=f(i).X).

This expresses the dependence of the result type X on the two arguments consistent with the definition of apply. Indeed, apply(f)(a).X is equivalent to f(a).X, as desired. On the other hand the functor argument to apply might be taken to be generative, in which case the best typing for apply is ΠG f:(ΠG i:I.J). ΠG i:I. J

Since f is taken to be generative, we lose type sharing information in the result, because the application f(a) is indeterminate, and hence the “type” f(a).X is ill-formed. Consequently, the abstract type X in n and p are not known by the type checker to be the same. It has been suggested that there should only be one apply functor that covers both cases illustrated above. To do so requires that we employ a form of intersection type (at the level of signatures) that captures the two forms of behavior just described. An alternative, suggested by MacQueen and Tofte (1994), is to refrain from assigning types to functors, in effect re-typechecking the body on each use. This means that the code, and not just the type, of the functor must be available to all clients, which precludes separate compilation.

Static and Dynamic Equivalence There are two main choices for module equivalence: static equivalence and dynamic equivalence. Static equivalence deems two modules to be equivalent whenever their static parts are equivalent. This is the coarsest equivalence between modules that conservatively extends core language type equivalence, and is therefore the most permissive choice. The alternative, dynamic equivalence, considers both the static and dynamic parts of modules in the definition of equivalence. Dynamic equivalence is, in general, undecidable, so some conservative approximation must be used in practice. However, dynamic equivalence makes it possible to distinguish two different interpretations of the same type without generativity. For example, if f is a module variable of functor type, and M and N are determinate modules of its domain type, then f(M).X is equivalent to f(N).X iff M and N are equivalent modules. Static equivalence ignores the dynamic part of these two modules, whereas dynamic equivalence would distinguish these types if M and N differ only in their dynamic components.

8.10

Relation to Some Existing Languages

341

Recursive Modules The model of linking discussed in §8.1 requires that the dependency relation among modules be acyclic—that there be a linear ordering of the modules consistent with their dependencies. It is natural to consider whether this restriction might be lifted to permit a more general form of “cross-linking” of modules. Since cyclic dependencies amount to (direct or indirect) selfreference, one approach to modelling such a generalization is via recursive modules (Crary, Harper, and Puri, 1999; Russo, 2001). Another approach is to devise a linking formalism that permits cyclic dependencies (Ancona and Zucca, 1998; Hirschowitz and Leroy, 2002; Flatt and Felleisen, 1998). Cyclic dependencies raise some significant problems that must be addressed in any satisfactory solution. Most importantly, permitting recursive modules should not disrupt the semantics of the underlying language. Without restriction, cyclic dependencies among modules can introduce a type A satisfying the equation A = A → Int, or a value v of type Int satisfying the equation v=v+1. In most languages such equations have no solution, and should not be permitted. Another issue is the interaction with effects. Permitting cyclic dependencies conflicts with the need for a linear initialization order consistent with dependencies. Care must be taken to ensure that values are not referenced before they are defined (or, at a minimum, that such references are caught at run time). Finally, for maximum flexibility, mutually recursive modules should be separately compilable. This requires some form of “forward” declaration to cut cycles in the dependency graph. It also requires a linking formalism that can support mutually cross-referencing modules, even in the presence of type declarations.

8.10

Relation to Some Existing Languages The design issues discussed in this chapter are largely motivated by the ML module system. There are two closely related realizations of the ML module system, the Standard ML module system and the Objective Caml module system. Basic modules are called structures, signatures are called signatures, and functors are so-called in both cases. Both designs provide for hierarchy and parameterization using essential the same mechanisms as described here, and both adopt the approach to sharing by specification described in §8.8. The designs differ significantly in their treatment of separate compilation, the avoidance problem, and higher-order modularity. The two languages are based on rather different foundations. Standard ML is defined by an elaboration relation that constitutes an algorithmic specification of the well-formed programs. Objective Caml lacks a formal definition, but the design follows quite closely a type theory of the general kind considered here.

342


Standard ML, as officially defined (Milner, Tofte, Harper, and MacQueen, 1997), permits only first-order, generative functors, provides no support for separate or incremental compilation, and handles the avoidance problem by a technical device that sacrifices principality. To amplify the last point first, the elaboration relation that defines the static semantics of Standard ML relies on an internal notion of “type names” that are generated during elaboration. Hidden abstract types are represented by type names that cannot be designated by any Standard ML type expression, and hence internal “signatures” are not expressible by any signature in the language. Consequently, the Standard ML module system does not in general admit principal (source language) signatures. As to separate compilation, the formal definition of Standard ML does not address it, so each implementation provides its own mechanisms. The most widely used implementation, Standard ML of New Jersey (SML/NJ), has a well-developed compilation manager (Blume and Appel, 1999; Blume, 2002) that supports incremental and cut-off compilation. SML/NJ also provides extensions to permit higher-order modularity that rely on elaborate internal representations of functors that cannot be written in any source language signature, and is therefore incompatible with separate compilation. Moscow/ML (Sestoft, 2003; Russo, 1998) is an implementation of Standard ML based on a type-theoretic interpretation of the language. It provides recursive and firstclass structures, and both applicative and generative functors. Objective Caml permits higher-order, applicative functors, supports separate and incremental compilation, and handles the avoidance problem by sacrificing principality. Again taking the last point first, Objective Caml rejects certain well-formed programs (in the sense of the underlying type theory of the language) when the implementation does not succeed in weakening a signature to avoid the occurrence of an abstract type (Dreyer, Crary, and Harper, 2003). The commitment to applicative functors stems from a desire to permit type selections of the form f(m).X in sharing specifications. The Haskell (Peyton Jones, 2003) module system is rather weak, providing only rudimentary namespace management. This deficiency is ameliorated by type classes. Viewed in terms of the framework of this chapter, the Haskell type class system amounts to a stylized use of modules. Polymorphic abstraction is generalized to functor abstraction—expressions take not only types, but associated operations, as arguments. The functor arguments are generated automatically during type inference based on a significant methodological restriction: no type may admit more than one interpretation by a given set of operations. (For example, in conjunction with type classes no type may be partially ordered in more than one way in a given program.) These interpretations are specified by type class declarations that amount to functor definitions. The type checker implicitly instantiates these functors (through

8.11

History and Further Reading

343

a process of backchaining) to determine the required implicit arguments. Experimental designs for richer modularity mechanisms have been proposed in the literature. For example, Jones (1996) regards modules as polymorphic records, which forces the programmer to manage explicitly the separation of the static from the dynamic parts of a module. Flatt and Felleisen’s units (1998) provide a form of modularity for Scheme programs (and other languages) that emphasizes separate compilation and recursive linking. Their language does not consider type abstraction or the associated problems of type sharing. In their realization, units are first-class values, amounting to records in the underlying language. In other formulations, units are used to structure existing C code to provide namespace management and a flexible linking formalism (Reid et al., 2000). Ancona and Zucca’s mixin modules (1998; 2002) isolate a variety of combinators for combining modules into programs. As suggested by Bracha and Cook (1990), mixins provide a basis for modelling inheritance, as well as supporting cyclic dependency relationships among modules. Mixins may be seen as fibered representations of families of modules in which instantiation is represented by “mixing in” one module with another. 8.10.1

Exercise [«««]: The C language lacks an internal notion of module, preferring instead to exploit the ambient file system to provide most of the requisite mechanisms. Discuss. 2

8.10.2

Exercise [«««]: The Java language also lacks direct analogs of most of the mechanisms we have introduced. However, Java does offer a rich collection of program structuring mechanisms, some of which can be used to achieve effects similar to the ones illustrated here. Discuss. 2

8.11

History and Further Reading The development of the linguistic and methodological foundations of data abstraction and modularity dates back to the earliest days of academic computer science (Parnas, 1972). Seminal work by Wirth (1973) and Hoare (1972) (among many others) was influential on the development of languages in the Algol family such as Pascal (Jensen and Wirth, 1975), Modula-2 (Wirth, 1983), CLU (Liskov, 1993), and Modula-3 (Cardelli, Donahue, Jordan, Kalsow, and Nelson, 1989). The Lisp family of languages (Steele, 1990) influenced the design of ML (Gordon, Milner, and Wadsworth, 1979), which introduced type inference, polymorphism, and abstract types. This sparked the development of several languages, such as Hope (Burstall, MacQueen, and Sannella, 1980), Standard ML (Milner, Tofte, Harper, and MacQueen, 1997), Objective Caml

344


(Leroy, 2000), and Haskell (Peyton Jones, 2003), founded on these ideas. The ML module system, originally proposed by MacQueen (1984), further developed in the design of Standard ML and Objective Caml, forms the conceptual basis for much of the material presented in this chapter. The theoretical framework employed in this chapter (and in TAPL) is the typed λ-calculus. One important topic was to develop type systems to support data abstraction. A fundamental first step was taken by Mitchell and Plotkin (1988) who related abstract types to second-order existential quantification, extending the connection between type polymorphism and second-order universal quantification discovered by Girard (1972) and Reynolds (1974). MacQueen (1986) pointed out that existential types are not adequate for expressing modular structure, suggesting instead a formalism based on dependent types. These initial steps provided the impetus for further research into type systems for modularity with the overall goal of providing the abstraction guarantees afforded by existential types and the flexible modular programming mechanisms afforded by dependent types. One strand of research focused on enriching the existential framework to support controlled propagation of type sharing information in a program. Three important developments were Harper and Lillibridge’s translucent sum types (1994; Lillibridge, 1997), Cardelli and Leroy’s “dot notation” (1990) and Leroy’s manifest types (1994; 1996), and Stone and Harper’s singleton kinds (2000; Stone, 2000). These type systems support hierarchy and parameterization with control over the propagation of type sharing relationships, even in the presence of first-class modules. Another strand focused on developing the mechanisms of dependent types to support higher-order modules. Building on MacQueen’s suggestions, Harper and Mitchell proposed a calculus of dependent types suitable for modelling many aspects of the ML module system (1993). This framework was further refined by Harper, Mitchell, and Moggi (1990) to ensure respect for the phase distinction in a fully expressive higher-order module system. Further work by Russo (1999) further underscored the point that the apparent dependencies are not really dependencies at all, by performing a “manual” form of phase-splitting during elaboration in the setting of a type-theoretic semantics for Standard ML. This formalism also provided the foundation for compiling modules into typed intermediate languages (Shao, League, and Monnier, 1998). Shao (1999) considered a type system that ensures the existence of principal signatures, at the expense of ruling out some programs that are expressible in ML. The abstract-type formalisms provided only weak support for higher-order modules, and the dependent-type formalisms provided no support for abstraction. Leroy introduced applicative functors (1995) in an effort to enrich

8.11

History and Further Reading

345

the abstract type formalism with richer higher-order constructs, but in the process sacrificed generative type abstraction. A fully comprehensive formalism was introduced by Dreyer, Crary, and Harper (2003), based on interpreting type abstraction as a pro forma computational effect. A rather different approach to the semantics of modularity is the elaboration framework of The Definition of Standard ML (Milner, Tofte, Harper, and MacQueen, 1997). The type checking rules for modular programming are given by an algorithm (expressed in inference rule format) for computing an internal representation of the signature of a module. A weakness of this approach is that it lacks any connection with the typed λ-calculus formalisms that form the foundation for the semantics and implementation of programming languages. This deficiency was addressed by Russo (1998), who re-formulated The Definition using constructs from type theory. Harper and Stone (2000) provided an alternative definition for Standard ML based on a separation between elaboration, which included type inference, overloading resolution, pattern compilation, and semantics, which was based on a foundational type theory for modularity. Garcia et al. (2003) make an interesting comparison of the modularity mechanisms found in several popular languages, from the point of view of supporting a particular style of “generic programming.”

9

Type Definitions Christopher A. Stone

Practical uses of interesting type systems often involve large and complex types, and it is useful to have methods for abbreviating these types. The simplest idea is to treat these definitions purely as meta-level constructs (derived forms), an approach with few theoretical complications. For example, in a language with recursive and variant types (e.g., λµ in TAPL, Chapter 20), we could define Nat NatList

def

=

µY.

def

µX.

=

after which the cons function for lists could be described as having the type Nat → NatList → NatList rather than the much larger type (µY. ) → (µX. ) → (µX. ).

As long as these definitions are non-circular, they are convenient but inessential syntactic sugar. In principle the symbolic names can all be replaced by their definitions, and so we can ignore them when reasoning about the language itself: we may write types such as Nat → NatList → NatList informally, but “officially” we always mean the corresponding expanded type. It is not always possible or practical, however, to omit type definitions from the language being studied. In some instances type definitions are explicitly part of the language itself. For example, the ML language permits type definitions by the user using the type keyword. C and C++ allow similar definitions with the typedef keyword. Alternatively, a language implementation might preserve definitions rather than substituting them away; expanding all definitions can lead to signifi-

348

9 Type Definitions

cantly larger types. Techniques such as DAG representations and hash consing (Shao, League, and Monnier, 1998) can ameliorate this problem but the results can be significantly less readable: if a type is originally written using abbreviations, it is often desirable to retain them for displaying the type (e.g., when reporting errors during type checking, as discussed in TAPL, §11.4). If type definitions are included in the language or its implementation, we would still like to know that properties such as type safety continue to hold, and that our algorithms (e.g., for type checking or code transformations) are correct. However, the addition of definitional mechanisms can change the properties of type systems in ways that are not immediately obvious. For example, suppose X is an operator mapping types to types. In F ω , the type equivalence X T1 ≡ X T2 holds if and only if T1 ≡ T2 . But if X is defined as the constant operator λY::*.Int, then suddenly X T1 ≡ X T2 holds for arbitrary T1 and T2 . As definitional mechanisms become more sophisticated, ensuring a proper implementation can be more difficult. For example, after the module definition (using roughly the syntax of Chapter 8) module n = mod type t = Nat val x : t = 3 end

we can use n.t as a synonym for Nat. In this case we have a definition not for the simple name t, but for the entire projection n.t. Moreover, module components can be referenced indirectly; we cannot eliminate the type definition just by replacing n.t by Nat. For example, the further definitions module n’ = n module diag = λ(p : sig type t val x : t end). mod type u = p.t × p.t val y : u = {p.x, p.x} end module nn = diag(n’)

nowhere mention the projection n.t, yet a correct type checker must nevertheless conclude both that n0 .t is a synonym for int (by definition the components of n0 are the same as the components of n) and that nn.u is

9 Type Definitions

349

equal to the type int × int (guaranteed by the definition of diag). Additionally, the definition for u in the functor’s result, which depends on the specific functor argument, must be retained in order to type check further uses of diag. It is therefore useful to study type definitions as primitive concepts. The focus here is definitions for types because these have the most significant effect on type equivalence and type checking and hence on language properties such as safety. Very similar approaches are used, however, to study term-level definitions and their effects upon term equivalence. We look at three approaches to adding type definitions to a language. Section 9.1 defines the language λlet , which adds primitive definitions of type variables to the typing context. The context can record X::K if X is an unknown type variable of kind K, and can record X::K=T if X is known to be equal to the type T of kind K. This mechanism directly allows definitions analogous to NatList above. Section 9.2 formalizes parts of Chapter 8 by considering a calculus λL M of second-class modules based on translucent sums. Again we have the choice between specifying either just a kind or both a kind and a definition, but now here all type definitions appear in module interfaces. This requires specifying a language of modules and interfaces, and also introduces a limited form of dependent type (since modules, which contain terms, can appear in types). Finally, Section 9.3 defines λS , a generalization of λlet that incorporates definitions into the kind system itself. The kind * classifies all ordinary types, while the new, more-precise singleton kind S(T) classifies only those ordinary types equivalent to T. This allows definitions at any point where a kind is specified. We then relate λL M to λS by showing that modules can be translated away using a phase-splitting transformation. ω , the higher-order polyAll three systems are described as variants of F×η morphic lambda calculus extended with product types and with extensionality (eta). The types and kinds of this base language are shown in Figure 9-1, and the terms are shown in Figure 9-2. Although not formally part of the system, many examples will assume the existence of familiar base types (e.g., Nat or Bool) and terms (e.g., numeric constants and addition). ω is the use of the judgment The least usual aspect of the formulation of F×η Γ ` , which formalizes the notion of Γ being a well-formed context (see TAPL, 30.3.18). A typing context is well-formed if all bound variables are distinct, and if each type within the context is well-formed with respect to the preceding portion of the context. For convenience in working with the system, all judgments are designed to require (directly or indirectly) that their typing context be well-formed. The evaluation rules for terms are standard and have been omitted.

350

9 Type Definitions

ω F×η

types: type variable type of functions type of pairs universal type type operator abstraction type operator application

T ::= X T→T T×T ∀X::K.T λX::K.T TT

kinds: kind of proper types kind of type operators

K ::= * K⇒K

Γ `

Context Validity ·` Γ ` T :: *

(CTX-Empty)

x 6∈ dom(Γ )

(CTX-Type)

Γ , x:T ` Γ `

X 6∈ dom(Γ )

Γ , X::K `

(CTX-Kind)

Γ `

Γ ` X :: K Γ , X::K1 ` T2 :: K2 Γ ` λX::K1 .T2 :: K1 ⇒K2 Γ ` T2 :: K11

Γ ` T1 T2 :: K12 Γ ` T1 :: *

Γ ` T2 :: *

Γ ` T1 →T2 :: * Γ ` T1 :: *

(Q-Refl)

Γ ` T ≡ S :: K

(Q-Sym)

Γ ` S ≡ T :: K Γ ` S ≡ U :: K

Γ ` U ≡ T :: K

Γ ` S ≡ T :: K Γ ` S1 ≡ T1 :: *

(Q-Trans)

Γ ` S2 ≡ T2 :: *

Γ ` S1 → S2 ≡ T1 → T2 :: * (Q-Arrow) Γ ` S2 ≡ T2 :: * (Q-Times) Γ ` S1 × S2 ≡ T1 × T2 :: *

Γ ` S1 ≡ T1 :: *

Γ ` T2 :: *

Γ ` T1 × T2 :: * Γ , X::K1 ` T2 :: * Γ ` ∀X::K1 .T2 :: * ω Figure 9-1: Types and kinds of F×η

Γ ` ∀X::K1 .S2 ≡ ∀X::K1 .T2 :: * Γ , X::K1 ` S2 ≡ T2 :: K2

Γ ` T :: K

Γ ` T1 :: K11 ⇒K12

Γ ` T :: K Γ ` T ≡ T :: K

Γ , X::K1 ` S2 ≡ T2 :: *

Kinding X::K ∈ Γ

Γ ` S ≡ T :: K

Type Equivalence

(K-Var) (K-Abs) (K-App) (K-Arrow) (K-Times) (K-All)

Γ ` λX::K1 .S2 ≡ λX::K1 .T2 :: K1 ⇒K2 Γ ` S1 ≡ T1 :: K11 ⇒K12 Γ ` S2 ≡ T2 :: K11 Γ ` S1 S2 ≡ T1 T2 :: K12

(Q-All) (Q-Abs)

(Q-App)

Γ , X::K11 ` S12 ≡ T12 :: K12 Γ ` S2 ≡ T2 :: K11 Γ ` (λX::K11 .S12 )S2 ≡ [X , T2 ]T12 :: K12 (Q-Beta) Γ , X::K1 ` S X ≡ T X : K2 (Q-Ext) Γ ` S ≡ T : K1 →K2

351

9.1 Definitions in the Typing Context

terms: variable abstraction application type abstraction type application pair first projection second projection

t ::= x λx:T.t tt λX::K.t t [T] {t,t} t.1 t.2

Γ , X::K1 ` t2 : T2 Γ ` λX::K1 .t2 : ∀X::K1 .T2 Γ ` t1 : ∀X::K11 .T12

x:T ∈ Γ

Γ `

Γ `x:T Γ , x:T1 ` t2 :: T2

(T-TApp) Γ ` t1 : T1

Γ ` λx:T1 .t2 :: T1 →T2 Γ ` t1 : T11 ⇒T12

Γ ` t2 : T11

Γ ` t1 t2 : T12

Γ ` t2 : T2

Γ ` {t1 ,t2 } : T1 × T2 Γ ` t1 : T11 × T12 Γ ` t1 .1 : T11 Γ ` t1 : T11 × T12

(T-Var) (T-Abs)

Γ ` T2 :: K11

Γ ` t1 [T2 ] : [X , T2 ]K12

Γ `t:T

Typing

(T-TAbs)

Γ ` t1 .2 : T12 Γ `t:S

Γ ` S ≡ T :: * Γ `t:T

(T-Pair) (T-Proj1) (T-Proj2) (T-Eq)

(T-App)

ω Figure 9-2: Terms of F×η

9.1

Definitions in the Typing Context In a language with eager evaluation, side-effects prevent us from eliminating term-level definitions by replacing variables by their definitions. As an alternative, therefore, closed-scope term-level definitions are often treated as derived forms involving applications, namely def

let x=t1 in t2 = (λx:T1 .t2 ) t1 where T1 is the type of t1 . In languages with type operators a similar approach can be used at the level of types, putting def

let X=T1 in T2 = (λX::K1 .T2 ) T1 where K1 is the kind of the type T1 . However, a type definition used within a term does not correspond to an instantiation of a polymorphic abstraction as one might expect. Although let X=Nat in (λx:X.x+1)(4)

is semantically reasonable, the polymorphic instantiation

352

9 Type Definitions ω Extends F×η

λlet New syntactic forms

Γ `

Γ ` X ≡ T :: K

X 6∈ dom(Γ )

Γ , X::K=T `

Γ `

Γ ` X :: K Typing Rules Γ ` T1 :: K1 Γ ` T2 :: * Γ , X::K1 =T1 ` t2 : T2

(Q-Def) Γ `

Context Validity Γ ` T :: K

X::K=T ∈ Γ

Γ ` S ≡ T :: K

Type Equivalence X::K=T ∈ Γ

Γ ` T :: K

Kinding

::= . . . contexts: Γ , X::K=T open-scope definition t ::= . . . terms: let X = T in t closed-scope definition Γ

Γ ` let X=T1 in t2 : T2 Evaluation rules let X=T in t -→ [X , T]t

(K-Def) Γ `t:T

(T-TLet) t -→ t0 (E-TLet)

(CTX-Def)

Figure 9-3: Adding definitions to the context

(λX::*. (λx:X.x+1)(4))[Nat]

is ill-typed because its sub-term λX::*. (λx:X.x+1)(4) is ill-typed. ω We therefore extend F×η by making definitions of type variables into a primitive notion, resulting in the language λlet shown in Figure 9-3. The syntax of contexts is broadened to permit defined type variables, and the new rule Q-Def equates type variables with their definitions. Equivalence of wellformed types therefore depends upon definitions in the typing context. In λlet we can prove X::*=Int ` Int→X ≡ X→Int :: * but not X::*=Bool ` Int→X ≡ X→Int :: * or X::* ` Int→X ≡ X→Int :: *. ω , where type equivalence This is an immediate difference from ordinary F×η can be determined by looking only at the two types involved (in this case, ω ). Int→X and X→Int, which are never equal in F×η Context validity is extended by the rule CTX-Def, which requires that definitions make sense in the preceding context. Consequently, type definitions

353


.. .

.. .

Γ , x:X ` x : X

Γ , x:X ` X ≡ Nat

Γ , x:X ` x : Nat

` ` Nat :: *

.. .

.. . .. .

Γ , x:X ` 1 : Nat

Γ ` X ≡ Nat

Γ , x:X ` x+1 : Nat

Γ ` 4 : Nat Γ ` Nat ≡ X

Γ ` λx:X. x+1 : X→Nat

Γ `4:X

Γ ` (λx:X. x+1)(4) : Nat ` (let X=Nat in (λx:X. x+1)(4)) : Nat

def

Figure 9-4: Typing of let X=Nat in (λx:X.x+1)(4), using Γ = X::*=Nat

in well-formed contexts are never circular, which will ensure that all definitions can in principle be substituted away.1 The new kinding rule K-Def looks up the kind of a defined type variable, ω rule K-Var for type variables without definitions. paralleling the F×η Definitions in the context are open-scope; they can be considered ambient and usable anywhere. We can also use this mechanism to describe the typing of primitive closed-scope (local) type definitions; the type checking rule T-TLet puts the definition into the context for use while type checking a specific term. Thus, for example, the code let X=Nat in (λx:X.x+1)(4) would be well-typed in the presence of natural numbers and addition; a proof appears in Figure 9-4, where the omitted leaf proofs are uninteresting contextvalidity checks. The following propositions collect a number of useful properties of λlet . They are all provable via induction on derivations. 9.1.1

Proposition [Weakening]: 1. If Γ1 , Γ3 ` T :: K and Γ1 , Γ2 , Γ3 ` then Γ1 , Γ2 , Γ3 ` T :: K. 2. If Γ1 , Γ3 ` S ≡ T :: K and Γ1 , Γ2 , Γ3 ` then Γ1 , Γ2 , Γ2 ` S ≡ T :: K.

2

1. The non-circularity requirement for context validity would not prevent T itself from being a recursive type, as in the Nat and NatList examples, assuming recursive types were added to the language.

354

9 Type Definitions

9.1.2

Proposition [Validity]: 1. If Γ ` J for any judgment form J then Γ ` . 2. If Γ1 , Γ2 ` then Γ1 ` and dom(Γ1 ) ∩ dom(Γ2 ) = ∅. 3. If Γ ` T :: K then FV(T) ⊆ dom(Γ ). 4. If Γ ` S ≡ T :: K then Γ ` S :: K and Γ ` T :: K.

9.1.3

2

Proposition [Substitution]: 1. If Γ1 , X::K, Γ2 ` J for any judgment form J and Γ1 ` T :: K then Γ1 , [X , T]Γ2 ` [X , T]J. 2. If Γ1 , X::K=S, Γ2 ` J for any judgment form J and Γ1 ` S ≡ T :: K then Γ1 , [X , T]Γ2 ` [X , T]J. 3. If Γ1 , X::K, Γ2 ` S :: L and Γ1 ` T ≡ T0 :: K then Γ1 , [X , T]Γ2 ` [X , T]S ≡ [X , T0 ]S :: L. 2

9.1.4

Exercise [««, Recommended]: Explain why the type system would be unsound if the premise Γ ` T2 :: * were omitted from T-TLet. 2

9.1.5

Exercise [««, Recommended]: Suppose we wanted to add primitive type definitions to the simply-typed calculus λ→ . What changes to that language would be appropriate? 2

Deciding Equivalence The hardest part of type checking in λlet , as in F ω , is deciding type equivalence. There are multiple ways to approach this. For example, we could define a notion of reduction (and/or parallel reduction) that allows beta-reduction and allows a variable to be replaced by its definition, a step known as deltareduction.2 Such notions of reduction can be shown to be confluent and normalizing (Severi and Poll, 1994), which provides a method for determining type equivalence: compute normal forms and check for equality up to bound variables. 2. Some authors (e.g., Barendregt, 1984) instead use the name delta-reduction to refer to the slightly different process of executing built-in primitive operators, e.g., replacing 3+4 by 7 in a language where addition and integer constants are taken as primitive.


355

If explicit definitions are being used to keep the representation small, however, then computing normal forms can be an expensive way to determine type equivalence. For example, if we had definitions such as Pair List

def

=

λY::*.(Y × Y)

def

λY::*. (µX. )

=

we would like to be able to determine that List(List(Pair(Nat))) and List(List(Nat × Nat)) are equivalent without expanding them to their common (but noticeably larger) normal form. Although for arbitrary types we might not be able to do any better, in practice code reuses the same defined names and so simple short-circuiting heuristics can help. One approach to avoiding explicit construction of normal forms involves simultaneous reduction and comparison of the types using weak head reduction, as discussed in Chapter 6. Instead of fully normalizing the types, only the “outermost” applications or definitions are reduced. If the resulting types turn out to have the same shape, then corresponding sub-components of the types can be recursively compared. Conversely, if the two types are weak head normalized but fail to have the same structure then the types are not equivalent and the algorithm can short-circuit and report inequivalence. Figure 9-5 presents an algorithmic version of equivalence in this fashion. The weak head normalization relation Γ ` T1 ⇓ Tn specifies that there is a finite sequence of types T1 , . . . , Tn with n ≥ 1 such that each weak head reduces to the next, and such that Tn is weak head normal. Given Γ and S there is at most one T such that Γ ` S ⇓ T. The algorithmic type equivalence judgment Γ ` S a T :: K holds if the weak head normal forms of T1 and T2 are structurally equivalent; this is the algorithmic equivalent to type equivalence for well-formed types. As in Chapter 6, extensional equivalence is implemented here for types with arrow kinds by applying both sides to a fresh variable and checking for equivalent results. Finally, the structural equivalence judgment Γ ` T1 ↔ T2 ↑ K implements equivalence for weak head-normal types only; T1 and T2 must have the same shape and their subcomponents must be algorithmically equivalent. Then K will be the common kind of T1 and T2 . Given Γ , S, and T, there is at most one rule that can apply. Conveniently, the correctness of this comparison algorithm can be shown using the same logical relations proof as in Chapter 6 with only minor modifications. We here are interested in equivalence of types that are classified by kinds, but this corresponds exactly to the problem considered in Chapter 6 of equivalence of terms classified by types. In particular, the kind * here corresponds to the base type b from Chapter 6. Rewriting the logical equivalence

356

9 Type Definitions

Γ `ñ T ; T0

Weak Head Reduction

Structural type equivalence

Γ ` (λX::K11 .T12 )T2 ; [X , T2 ]T12 X::K=T ∈ Γ

Γ `ñ X ↔ X ↑ K

Γ `ñ X ; T

Γ ` S1 a T1 ↑ * ñ

Γ `ñ T1 ;

T0

1

Γ `ñ T1 T2 ;

T0

1

T2

Γ `ñ S1 a T1 ↑ *

Γ `ñ S2 a T2 ↑ *

Γ `ñ S1 × S2 ↔ T1 × T2 ↑ *

Γ `ñ T ⇓ T0

Γ , X::K1 `ñ S2 a T2 ↑ *

Γ `ñ S ⇓ T0

Γ `ñ T ⇓

Γ `ñ S2 a T2 ↑ *

Γ `ñ S1 →S2 ↔ T1 →T2 ↑ *

Weak head normalization Γ `ñ T ; S

Γ `ñ S ↔ T ↑ K

X::K ∈ Γ

ñ

X 6∈ dom(Γ )

Γ ` ∀X::K1 .S2 ↔ ∀X::K1 .T2 ↑ *

T0

ñ

Γ `ñ S1 ↔ T1 ↑ K1 ⇒K2 Γ `ñ S2 a T2 :: K1

Γ `ñ T 6; Γ `ñ T ⇓ T Algorithmic type equivalence

Γ `ñ S a T :: K

Γ `ñ S1 S2 ↔ T1 T2 ↑ K2

Γ `ñ S ⇓ S0 Γ `ñ T ⇓ T0 Γ `ñ S0 ↔ T0 ↑ * Γ `ñ S a T :: * Γ , X::K1 `ñ S X a T X :: K2

X 6∈ dom(Γ )

Γ ` S a T :: K1 ⇒K2 ñ

Figure 9-5: Algorithmic equivalence with definitions

relation to refer to types and kinds (and simplifying it a bit, as we have no “unit kind”) yields: 9.1.6

Definition [Logical Equivalence]: Logical equivalence is defined as follows: Γ ` S is T :: K if and only if either: K=* and Γ ` S a T :: *, or K=K1 ⇒K2 and for all S0 , T0 , and for all Γ 0 ⊇ Γ , if Γ 0 ` S0 is T0 :: K1 then Γ 0 ` S S0 is T T0 :: K2 .

2

Similarly, γ or δ will now represent a substitutions mapping type variables to types. Recall that γ[X , T] is the substitution that agrees with γ except that it maps X to the type T. The biggest difference from Chapter 6 is that we must be more careful about substitutions. The proof of the Fundamental Theorem of Logical Rela-


357

tions will not go through if we allow substitutions that replace a defined type variable by an unrelated type. (Specifically, the Q-Def case would fail.) The following definition builds in this restriction, while still being easy to show symmetric and transitive: 9.1.7

Definition: Γ 0 ` γ is δ :: Γ if and only if • For every X::K ∈ Γ we have Γ 0 ` γ(X) is δ(X) :: K. • For every X::K=T ∈ Γ we have Γ 0 ` γ(X) is δ(X) :: K, Γ 0 ` γ(X) is δ(T) :: K, and Γ 0 ` γ(T) is δ(X) :: K. 2

9.1.8

Exercise [«««, Recommended]: Show how to adapt the methods of Chapter 6 to prove that if Γ ` S :: K and Γ ` T :: K then it is decidable whether Γ ` S ≡ T :: K in λlet . 2 A major advantage of this variant algorithm is that it allows further refinements. For example, an implementation might check for alpha-equivalence of corresponding components before reducing. Thus, a request to compare List(T1 ) with List(T2 ) could directly check whether T1 and T2 are equivalent without expanding the definition of List. One must be careful in trying to optimize, though, since the addition of ω definitions alters usual properties of type equivalence. In F×η the equivalence let X T1 ≡ X T2 holds if and only if T1 ≡ T2 . In a λ -style language, however, we can prove X::(*⇒*)=(λY::*.Nat) ` X Nat ≡ X Bool even though Nat and Bool are not equivalent—both applications are provably equal to Nat. Therefore, although comparing X T1 with X T2 by showing that T1 and T2 are equivalent may often be faster than expanding out a definition for X, if the arguments are inequivalent we may need to consider the expansion anyway.3 One might think to special-case variables like X above whose definitions completely ignore their arguments, but similar behavior can arise more generally.

9.1.9

Exercise [Recommended, ««]: Find a typing context and pairwise inequivalent T1 , T2 , and T3 such that X T1 ≡ X T2 but X T2 6≡ X T3 (and so X cannot completely ignore its argument). 2 3. The presence of definitions has consequences for unification as well (e.g., in implementations of ML type inference): the most general substitution making X T1 and X T2 equal might not make T1 and T2 unify.

358

9 Type Definitions

If the simultaneous comparison process finds no short-cuts, it will do work equivalent to entirely normalizing and comparing the two types. It may still be more memory-efficient, however, than separate normalizations. Full normal forms are not explicitly computed and stored; when two subcomponents of the types are found to be equal their reduced forms can be immediately discarded, freeing up memory for the rest of the comparison. 9.1.10

9.2

Exercise [«««, 3]: Extend the fullomega checker to include definitions, and make type equivalence checking as efficient as possible. 2

Definitions in Module Interfaces In the presence of modules, type definitions are often permitted to appear within interfaces. The most interesting aspect of the theory of ML-style module systems involves tracking information about the types involved, given that type components in modules may have definitions that are not syntactically apparent. One line of research in formalizing the type theory of ML-like module systems (as discussed in Chapter 8) led to the calculi known as translucent sums (Harper and Lillibridge, 1994) and manifest types (Leroy, 1994). These similar systems largely correspond to the module systems of Revised Standard ML (Milner, Tofte, Harper, and MacQueen, 1997) and (with some extensions—see Leroy [1995]) of Objective Caml.

The Language λL M Figure 9-6 defines a minimalist language λL M with second-class modules, based on the calculus of Lillibridge (1997). Modules are not first-class values able to be passed to term-level functions, and similarly interfaces are not types. Though simpler than any module system usable in practice, λL M is still complex enough to demonstrate many issues discussed in Chapter 8. In ML, modules can contain any combination of named value, type, and sub-module components in any order. λL M instead builds up modules starting with two primitives: modules that contain a single unnamed term, written LtM, and modules that contain a single unnamed type, written LT::KM. The contents of primitive modules can be extracted by using the ! operator. For each sort of module, there are corresponding interfaces. The interface LTM classifies primitive modules containing a value of type T, while the opaque interface LKM classifies modules containing a type of kind K. Modules containing types may also have a transparent interface LK=TM if they contain just the type T (or a provably equivalent type) of kind K.

359

9.2 Definitions in Module Interfaces

ω extends F×η

λL M Syntax Γ ::= . . . m:I W ::= m LvM LT::KM LW,WM W.1 W.2 λm:I.M Wv

::=

LvM LT::KM LWv ,Wv M λm:I.M M ::= W LtM LM,MM M.1 M.2 MM M :> I I ::=

LTM LKM LK=TM Σm:I.I Πm:I.I t ::= . . . !M T ::= . . . !W

contexts: module variable determinate modules: variable term module type module pairing first projection second projection functor

Derived Forms def I1 × I2 = Σm:I1 .I2 def

I1 → I2 = Πm:I1 .I2

interfaces: term interface opaque interface transparent interface pair interface functor interface terms: module projection types: module projection

Figure 9-6: Syntax, typing, and semantics for λL M

(m 6∈ FV(I2 )) Γ `

Context Validity Γ Ì

m 6∈ dom(Γ )

Γ , m:I ` Well-Formed Interface Γ ` T :: * Γ ` LTM Γ `

module values: term module type module pairing functor modules: determinates term module pairing first projection second projection application generative sealing

(m 6∈ FV(I2 ))

Γ ` LKM Γ ` T :: K Γ ` LK=TM Γ , m:I1 ` I2 Γ ` Σm:I1 .I2 Γ , m:I1 ` I2 Γ ` Πm:I1 .I2

(CTX-Mod) Γ Ì (I-Term) (I-Opaque) (I-Transp) (I-Sigma) (I-Pi) Γ ` I

Advanced topics in types and programming languages

Advanced Topics in Types and Programming Languages

Advanced Topics in Types and Programming Languages

Types and Programming Languages

Types and Programming Languages

Types and Programming Languages

Types and Programming Languages

Types and Programming Languages

Types and Programming Languages

Types and Programming Languages

Programming Languages: Principles and Paradigms (Undergraduate Topics in Computer Science)

Programming Languages: Principles and Paradigms (Undergraduate Topics in Computer Science)

Concepts in Programming Languages

Topics in C Programming

Design Concepts in Programming Languages

Advanced topics in applied mathematics

Domination in Graphs: Advanced Topics

Advanced Topics in Database Research

Advanced topics in difference equations

Advanced Topics in Information Retrieval

Advanced Topics in Difference Equations

Programming Languages: Principles and Practices

Programming Languages: Principles and Practices

Programming languages: principles and practice

Essentials of programming languages

Understanding Programming Languages

History of programming languages

Essentials of Programming Languages

Concepts of programming languages

Object-Oriented Programming Languages

Concepts of programming languages

Advanced topics in types and programming languages