- Author / Uploaded
- Robert Harper
Practical Foundations for Programming Languages 1.19
Practical Foundations for Programming Languages Robert Harper Carnegie Mellon University Spring, 2011 [Version 1.19 of 1
1,253 232 2MB
Pages 590 Page size 612 x 792 pts (letter) Year 2011
Recommend Papers
File loading please wait...
Citation preview
Practical Foundations for Programming Languages Robert Harper Carnegie Mellon University Spring, 2011 [Version 1.19 of 10.03.2011.]
c 2011 by Robert Harper. Copyright All Rights Reserved.
The electronic version of this work is licensed under the Creative Commons Attribution-Noncommercial-No Derivative Works 3.0 United States License. To view a copy of this license, visit http://creativecommons.org/licenses/by-nc-nd/3.0/us/ or send a letter to Creative Commons, 171 Second Street, Suite 300, San Francisco, California, 94105, USA.
Preface This is a working draft of a book on the foundations of programming languages. The central organizing principle of the book is that programming language features may be seen as manifestations of an underlying type structure that governs its syntax and semantics. The emphasis, therefore, is on the concept of type, which codifies and organizes the computational universe in much the same way that the concept of set may be seen as an organizing principle for the mathematical universe. The purpose of this book is to explain this remark. Being in many ways a consolidation of many ideas from the literature on programming languages, I make no attempt to give an exhaustive account of the history or sources of many of the ideas. The notes at the end of each chapter provide some guidance for further reading and background, but are not intended as a complete guide to the literature. For further back¨ (1984), Mitchell (1996), Pierce ground please see Girard (1989), Martin-Lof (2002, 2004), and Reynolds (1998). Comments should be sent to the author at [email protected]. I am grateful to the following people for their corrections and suggestions: Arbob Ahmad, Andrew Appel, Zena Ariola, Guy E. Blelloch, William Byrd, Luis Caires, Luca Cardelli, Iliano Cervesato, Manuel Chakravarti, Lin Chase, Richard C. Cobbe, Karl Crary, Daniel Dantas, Anupam Datta, Jake Donham, Derek Dreyer, Matthias Felleisen, Dan Friedman, Maia Ginsburg, Kevin Hely, Cao Jing, Gabriele Keller, Danielle Kramer, Akiva Leffert, Ruy LeyWild, Dan Licata, Karen Liu, Dave MacQueen, Chris Martens, Greg Morrisett, Tom Murphy, Aleksandar Nanevski, Georg Neis, David Neville, Doug Perkins, Frank Pfenning, Benjamin C. Pierce, Andrew M. Pitts, Gordon D. Plotkin, David Renshaw, John C. Reynolds, Carter T. Schonwald, Dale Schumacher, Dana Scott, Zhong Shao, Robert Simmons, Pawel Sobocinski, Daniel Spoonhower, Paulo Tanimoto, Bernardo Toninho, Michael Tschantz, Kami Vaniea, Carsten Varming, David Walker, Dan Wang, Jack Wileden, Todd Wilson, Roger Wolff, Luke Zarko, Yu Zhang.
This material is based on work supported by the National Science Foundation under Grant Nos. 0702381 and 0716469. Any opinions, findings, and conclusions or recommendations expressed in this material are those of the author(s) and do not necessarily reflect the views of the National Science Foundation. This work was supported in part by the Max Planck Institute for Software Systems in Germany, whose help I gratefully acknowledge. I thank Espresso a Mano in Pittsburgh, CB2 Cafe in Cambridge, and Thonet Cafe in Saarbruecken for providing a steady supply of coffee and a conducive atmosphere for writing.
Contents Preface
I
Judgements and Rules
1
Syntactic Objects 1.1 Strings . . . . . . . . . 1.2 Abstract Syntax Trees . 1.3 Abstract Binding Trees 1.4 Notes . . . . . . . . . .
2
3
iii
1 . . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
3 4 4 7 12
Inductive Definitions 2.1 Judgements . . . . . . . . . . . . . . . . . . . . . 2.2 Inference Rules . . . . . . . . . . . . . . . . . . . 2.3 Derivations . . . . . . . . . . . . . . . . . . . . . . 2.4 Rule Induction . . . . . . . . . . . . . . . . . . . . 2.5 Iterated and Simultaneous Inductive Definitions 2.6 Defining Functions by Rules . . . . . . . . . . . . 2.7 Modes . . . . . . . . . . . . . . . . . . . . . . . . 2.8 Notes . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
13 13 14 15 17 19 20 22 23
Hypothetical and General Judgements 3.1 Hypothetical Judgements . . . . . 3.1.1 Derivability . . . . . . . . . 3.1.2 Admissibility . . . . . . . . 3.2 Hypothetical Inductive Definitions 3.3 General Judgements . . . . . . . . 3.3.1 Generic Derivability . . . . 3.3.2 Parametric Derivability . . 3.4 Generic Inductive Definitions . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
25 25 25 27 29 31 31 31 32
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
vi
CONTENTS 3.5
II 4
5
III 6
7
8
Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Levels of Syntax
34
35
Concrete Syntax 4.1 Lexical Structure . . . . 4.2 Context-Free Grammars 4.3 Grammatical Structure . 4.4 Ambiguity . . . . . . . . 4.5 Notes . . . . . . . . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
37 37 41 42 43 45
Abstract Syntax 5.1 Hierarchical and Binding Structure . 5.2 Parsing Into Abstract Syntax Trees . 5.3 Parsing Into Abstract Binding Trees . 5.4 Notes . . . . . . . . . . . . . . . . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
47 47 49 51 53
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
Statics and Dynamics
55
Statics 6.1 Syntax . . . . . . . . 6.2 Type System . . . . . 6.3 Structural Properties 6.4 Notes . . . . . . . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
57 57 58 60 62
Dynamics 7.1 Transition Systems . 7.2 Structural Dynamics 7.3 Contextual Dynamics 7.4 Equational Dynamics 7.5 Notes . . . . . . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
63 63 64 67 69 72
. . . .
75 76 76 78 79
Type Safety 8.1 Preservation . . 8.2 Progress . . . . 8.3 Run-Time Errors 8.4 Notes . . . . . .
V ERSION 1.19
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
D RAFT
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
R EVISED 10.03.2011
CONTENTS 9
IV
vii
Evaluation Dynamics 9.1 Evaluation Dynamics . . . . . . . . . . . . . . 9.2 Relating Structural and Evaluation Dynamics 9.3 Type Safety, Revisited . . . . . . . . . . . . . . 9.4 Cost Dynamics . . . . . . . . . . . . . . . . . 9.5 Notes . . . . . . . . . . . . . . . . . . . . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
Function Types
81 81 82 83 85 86
87
10 Function Definitions and Values 10.1 First-Order Functions . . . . . . . . . . . . . . . . . . 10.2 Higher-Order Functions . . . . . . . . . . . . . . . . 10.3 Evaluation Dynamics and Definitional Equivalence 10.4 Dynamic Scope . . . . . . . . . . . . . . . . . . . . . 10.5 Notes . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
11 Godel’s ¨ System T 11.1 Statics . . . . . 11.2 Dynamics . . 11.3 Definability . 11.4 Undefinability 11.5 Notes . . . . .
. . . . .
. . . . .
. . . . .
. . . . .
97 . 98 . 99 . 100 . 102 . 104
. . . . .
105 107 108 110 112 113
. . . . .
. . . . .
. . . . .
. . . . .
12 Plotkin’s PCF 12.1 Statics . . . . . . . . . 12.2 Dynamics . . . . . . 12.3 Definability . . . . . 12.4 Co-Natural Numbers 12.5 Notes . . . . . . . . .
V
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
Finite Data Types
115
13 Product Types 13.1 Nullary and Binary Products . . 13.2 Finite Products . . . . . . . . . . 13.3 Primitive and Mutual Recursion 13.4 Notes . . . . . . . . . . . . . . . . R EVISED 10.03.2011
89 90 91 93 95 96
D RAFT
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
117 118 119 121 122
V ERSION 1.19
viii
CONTENTS
14 Sum Types 14.1 Binary and Nullary Sums 14.2 Finite Sums . . . . . . . . 14.3 Applications of Sum Types 14.3.1 Void and Unit . . . 14.3.2 Booleans . . . . . . 14.3.3 Enumerations . . . 14.3.4 Options . . . . . . 14.4 Notes . . . . . . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
123 123 125 126 126 127 127 128 129
15 Pattern Matching 15.1 A Pattern Language . . . . . . . . . . . . . . . . . . . 15.2 Statics . . . . . . . . . . . . . . . . . . . . . . . . . . . 15.3 Dynamics . . . . . . . . . . . . . . . . . . . . . . . . 15.4 Exhaustiveness and Redundancy . . . . . . . . . . . 15.4.1 Match Constraints . . . . . . . . . . . . . . . 15.4.2 Enforcing Exhaustiveness and Redundancy . 15.4.3 Checking Exhaustiveness and Redundancy . 15.5 Notes . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
131 132 132 134 136 136 138 139 141
16 Generic Programming 16.1 Introduction . . . 16.2 Type Operators . 16.3 Generic Extension 16.4 Notes . . . . . . .
. . . .
. . . .
. . . .
. . . .
. . . .
143 143 144 144 147
VI
. . . .
. . . .
. . . .
. . . .
. . . .
. . . . . . . .
. . . .
. . . . . . . .
. . . .
. . . . . . . .
. . . .
. . . . . . . .
. . . .
. . . . . . . .
. . . .
. . . . . . . .
. . . .
. . . . . . . .
. . . .
. . . . . . . .
. . . .
. . . . . . . .
. . . .
. . . . . . . .
. . . .
. . . . . . . .
. . . .
. . . . . . . .
. . . .
. . . . . . . .
. . . .
. . . . . . . .
. . . .
. . . .
Infinite Data Types
149
17 Inductive and Co-Inductive Types 17.1 Motivating Examples . . . . . 17.2 Statics . . . . . . . . . . . . . . 17.2.1 Types . . . . . . . . . . 17.2.2 Expressions . . . . . . 17.3 Dynamics . . . . . . . . . . . 17.4 Notes . . . . . . . . . . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
151 151 155 155 156 156 157
18 Recursive Types 159 18.1 Solving Type Isomorphisms . . . . . . . . . . . . . . . . . . . 160 18.2 Recursive Data Structures . . . . . . . . . . . . . . . . . . . . 161 V ERSION 1.19
D RAFT
R EVISED 10.03.2011
CONTENTS
ix
18.3 Self-Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . 163 18.4 Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165
VII
Dynamic Types
167
19 The Untyped λ-Calculus 19.1 The λ-Calculus . . . . . . . 19.2 Definability . . . . . . . . . 19.3 Scott’s Theorem . . . . . . . 19.4 Untyped Means Uni-Typed 19.5 Notes . . . . . . . . . . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
169 169 171 174 175 177
20 Dynamic Typing 20.1 Dynamically Typed PCF . . 20.2 Variations and Extensions . 20.3 Critique of Dynamic Typing 20.4 Notes . . . . . . . . . . . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
179 179 182 185 186
. . . . .
189 189 191 193 194 195
21 Hybrid Typing 21.1 A Hybrid Language . . . . . . . . 21.2 Optimization of Dynamic Typing 21.3 Static “Versus” Dynamic Typing 21.4 Reduction to Recursive Types . . 21.5 Notes . . . . . . . . . . . . . . . .
VIII
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
Variable Types
197
22 Girard’s System F 22.1 System F . . . . . . . . . . . . . . . 22.2 Polymorphic Definability . . . . . 22.2.1 Products and Sums . . . . . 22.2.2 Natural Numbers . . . . . . 22.3 Parametricity Overview . . . . . . 22.4 Restricted Forms of Polymorphism 22.4.1 Predicative Fragment . . . . 22.4.2 Prenex Fragment . . . . . . 22.4.3 Rank-Restricted Fragments 22.5 Notes . . . . . . . . . . . . . . . . . R EVISED 10.03.2011
D RAFT
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
199 200 203 203 204 205 206 206 207 209 210
V ERSION 1.19
x
CONTENTS
23 Abstract Types 23.1 Existential Types . . . . . . . . . 23.1.1 Statics . . . . . . . . . . . 23.1.2 Dynamics . . . . . . . . . 23.1.3 Safety . . . . . . . . . . . . 23.2 Data Abstraction Via Existentials 23.3 Definability of Existentials . . . . 23.4 Representation Independence . . 23.5 Notes . . . . . . . . . . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
211 212 212 213 214 214 216 217 219
24 Constructors and Kinds 24.1 Statics . . . . . . . . . . . 24.2 Higher Kinds . . . . . . 24.3 Hereditary Substitution 24.4 Canonization . . . . . . 24.5 Notes . . . . . . . . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
221 222 224 226 229 231
IX
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
Subtyping
233
25 Subtyping 25.1 Subsumption . . . . . . . 25.2 Varieties of Subtyping . 25.2.1 Numeric Types . 25.2.2 Product Types . . 25.2.3 Sum Types . . . . 25.3 Variance . . . . . . . . . 25.3.1 Product Types . . 25.3.2 Sum Types . . . . 25.3.3 Function Types . 25.3.4 Quantified Types 25.3.5 Recursive Types . 25.4 Safety . . . . . . . . . . . 25.5 Notes . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
235 236 236 236 237 238 239 239 240 240 241 242 244 246
26 Singleton Kinds 26.1 Overview . . . . . 26.2 Singletons . . . . 26.3 Dependent Kinds 26.4 Higher Singletons
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
247 248 249 251 255
V ERSION 1.19
. . . .
. . . .
. . . .
. . . .
D RAFT
R EVISED 10.03.2011
CONTENTS
xi
26.5 Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 256
X
Classes and Methods
257
27 Dynamic Dispatch 27.1 The Dispatch Matrix . . . . 27.2 Method-Based Organization 27.3 Class-Based Organization . 27.4 Self-Reference . . . . . . . . 27.5 Notes . . . . . . . . . . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
259 259 261 263 265 266
28 Inheritance 267 28.1 Subclassing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 268 28.2 Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 271
XI
Control Effects
273
29 Control Stacks 29.1 Machine Definition . . . . . . . . . . 29.2 Safety . . . . . . . . . . . . . . . . . . 29.3 Correctness of the Control Machine . 29.3.1 Completeness . . . . . . . . . 29.3.2 Soundness . . . . . . . . . . . 29.4 Notes . . . . . . . . . . . . . . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
275 275 277 278 280 280 282
30 Exceptions 30.1 Failures . . . . . 30.2 Exceptions . . . 30.3 Exception Type 30.4 Encapsulation . 30.5 Notes . . . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
283 283 285 286 288 290
. . . .
291 291 293 295 299
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
31 Continuations 31.1 Informal Overview . . . . . 31.2 Semantics of Continuations 31.3 Coroutines . . . . . . . . . . 31.4 Notes . . . . . . . . . . . . . R EVISED 10.03.2011
. . . . .
. . . .
. . . . .
. . . .
D RAFT
. . . . .
. . . .
. . . . .
. . . .
. . . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
V ERSION 1.19
xii
XII
CONTENTS
Types and Propositions
32 Constructive Logic 32.1 Constructive Semantics 32.2 Constructive Logic . . 32.2.1 Provability . . . 32.2.2 Proof Terms . . 32.3 Propositions as Types . 32.4 Notes . . . . . . . . . .
301 . . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
33 Classical Logic 33.1 Classical Logic . . . . . . . . . . . . 33.1.1 Provability and Refutability 33.1.2 Proofs and Refutations . . . 33.2 Deriving Elimination Forms . . . . 33.3 Proof Dynamics . . . . . . . . . . . 33.4 Law of the Excluded Middle . . . . 33.5 The Double-Negation Translation . 33.6 Notes . . . . . . . . . . . . . . . . .
XIII
. . . . . .
. . . . . . . .
. . . . . .
. . . . . . . .
. . . . . .
. . . . . . . .
. . . . . .
. . . . . . . .
. . . . . .
. . . . . . . .
. . . . . .
. . . . . . . .
. . . . . .
. . . . . . . .
. . . . . .
. . . . . . . .
. . . . . .
. . . . . . . .
. . . . . .
. . . . . . . .
. . . . . .
. . . . . . . .
. . . . . .
. . . . . . . .
. . . . . .
. . . . . . . .
. . . . . .
. . . . . . . .
. . . . . .
303 304 305 306 307 309 310
. . . . . . . .
311 312 312 314 317 318 320 322 323
Symbols
325
34 Symbols 34.1 Symbol Declaration . . . . . . 34.1.1 Scoped Dynamics . . . 34.1.2 Scope-Free Dynamics 34.2 Symbolic References . . . . . 34.2.1 Statics . . . . . . . . . 34.2.2 Dynamics . . . . . . . 34.2.3 Safety . . . . . . . . . . 34.3 Notes . . . . . . . . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
327 328 328 329 330 331 331 332 333
35 Fluid Binding 35.1 Statics . . . . . . 35.2 Dynamics . . . 35.3 Type Safety . . . 35.4 Some Subtleties 35.5 Fluid References 35.6 Notes . . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
335 335 336 337 338 340 342
V ERSION 1.19
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
D RAFT
R EVISED 10.03.2011
CONTENTS
xiii
36 Dynamic Classification 36.1 Dynamic Classes . . . . . . . . . 36.1.1 Statics . . . . . . . . . . . 36.1.2 Dynamics . . . . . . . . . 36.1.3 Safety . . . . . . . . . . . . 36.2 Class References . . . . . . . . . . 36.3 Definability of Dynamic Classes . 36.4 Classifying Secrets . . . . . . . . 36.5 Notes . . . . . . . . . . . . . . . .
XIV
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
Storage Effects
38 Mutable Data Structures 38.1 Free Assignables . . . . . . . . . . . . . . 38.2 Free References . . . . . . . . . . . . . . 38.3 Safety . . . . . . . . . . . . . . . . . . . . 38.4 Integrating Commands and Expressions 38.5 Notes . . . . . . . . . . . . . . . . . . . .
. . . . .
. . . . .
. . . . . . . . . .
. . . . .
. . . . . . . . . .
. . . . .
. . . . . . . . . .
. . . . .
. . . . . . . . . .
. . . . .
. . . . . . . . . .
. . . . .
. . . . . . . . . .
. . . . .
. . . . . . . . . .
. . . . .
. . . . . . . . . .
. . . . .
. . . . . . . . . .
. . . . .
. . . . . . . . . .
353 353 354 355 357 359 361 364 365 366 367
. . . . .
369 370 371 372 374 377
Laziness
39 Lazy Evaluation 39.1 Need Dynamics . . . 39.2 Safety . . . . . . . . . 39.3 Lazy Data Structures 39.4 Suspensions . . . . . R EVISED 10.03.2011
343 344 344 345 346 346 347 348 349
351
37 Modernized Algol 37.1 Basic Commands . . . . . . . . . . . . . . . 37.1.1 Statics . . . . . . . . . . . . . . . . . 37.1.2 Dynamics . . . . . . . . . . . . . . . 37.1.3 Safety . . . . . . . . . . . . . . . . . . 37.2 Some Programming Idioms . . . . . . . . . 37.3 Typed Commands and Typed Assignables . 37.4 Capabilities . . . . . . . . . . . . . . . . . . 37.5 References . . . . . . . . . . . . . . . . . . . 37.6 Aliasing . . . . . . . . . . . . . . . . . . . . 37.7 Notes . . . . . . . . . . . . . . . . . . . . . .
XV
. . . . . . . .
379 . . . .
. . . .
. . . .
. . . .
. . . .
. . . .
D RAFT
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
381 382 386 388 389
V ERSION 1.19
xiv
CONTENTS 39.5 Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 391
40 Polarization 40.1 Positive and Negative Types 40.2 Focusing . . . . . . . . . . . 40.3 Statics . . . . . . . . . . . . . 40.4 Dynamics . . . . . . . . . . 40.5 Safety . . . . . . . . . . . . . 40.6 Polarization . . . . . . . . . 40.7 Notes . . . . . . . . . . . . .
XVI
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
Parallelism
42 Futures and Speculation 42.1 Futures . . . . . . . . . . . . 42.1.1 Statics . . . . . . . . 42.1.2 Sequential Dynamics 42.2 Suspensions . . . . . . . . . 42.2.1 Statics . . . . . . . . 42.2.2 Sequential Dynamics 42.3 Parallel Dynamics . . . . . . 42.4 Applications of Futures . . . 42.5 Notes . . . . . . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . .
. . . . . . . . .
. . . . .
. . . . . . . . .
. . . . .
. . . . . . . . .
. . . . .
. . . . . . . . .
. . . . .
. . . . . . . . .
. . . . .
. . . . . . . . .
. . . . .
. . . . . . . . .
. . . . .
. . . . . . . . .
. . . . .
. . . . . . . . .
. . . . .
. . . . . . . . .
. . . . .
. . . . . . . . .
. . . . .
. . . . . . . . .
. . . . .
. . . . . . . . .
. . . . .
405 406 409 412 414 418
. . . . . . . . .
419 420 420 421 421 421 422 422 425 427
Concurrency
43 Process Calculus 43.1 Actions and Events . 43.2 Interaction . . . . . . 43.3 Replication . . . . . . 43.4 Allocating Channels 43.5 Communication . . . V ERSION 1.19
393 394 395 396 398 399 400 401
403
41 Nested Parallelism 41.1 Binary Fork-Join . . . . . . . . . . . . 41.2 Cost Dynamics . . . . . . . . . . . . 41.3 Multiple Fork-Join . . . . . . . . . . 41.4 Provably Efficient Implementations . 41.5 Notes . . . . . . . . . . . . . . . . . .
XVII
. . . . . . .
429 . . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
D RAFT
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
431 431 433 435 437 440
R EVISED 10.03.2011
CONTENTS
xv
43.6 Channel Passing . . . . . . . . . . . . . . . . . . . . . . . . . . 443 43.7 Universality . . . . . . . . . . . . . . . . . . . . . . . . . . . . 446 43.8 Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 448 44 Concurrent Algol 44.1 Concurrent Algol . . . . . . . 44.2 Broadcast Communication . . 44.3 Selective Communication . . 44.4 Free Assignables as Processes 44.5 Notes . . . . . . . . . . . . . . 45 Distributed Algol 45.1 Statics . . . . . 45.2 Dynamics . . 45.3 Safety . . . . . 45.4 Situated Types 45.5 Notes . . . . .
XVIII
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
449 449 452 454 458 460
. . . . .
461 462 464 465 466 470
Modularity
471
46 Components and Linking 473 46.1 Simple Units and Linking . . . . . . . . . . . . . . . . . . . . 474 46.2 Initialization and Effects . . . . . . . . . . . . . . . . . . . . . 475 46.3 Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 477 47 Type Abstractions and Type Classes 47.1 Type Abstraction . . . . . . . . 47.2 Type Classes . . . . . . . . . . . 47.3 A Module Language . . . . . . 47.4 First- and Second-Class . . . . . 47.5 Notes . . . . . . . . . . . . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
48 Hierarchy and Parameterization 48.1 Hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48.2 Parameterizaton . . . . . . . . . . . . . . . . . . . . . . . . . 48.3 Extending Modules with Hierarchies and Parameterization 48.4 Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . R EVISED 10.03.2011
D RAFT
. . . . .
479 481 483 486 491 493
. . . .
495 495 499 502 505
V ERSION 1.19
xvi
XIX
CONTENTS
Equivalence
507
49 Equational Reasoning for T 49.1 Observational Equivalence . . . . . . . . . . . . . 49.2 Logical Equivalence . . . . . . . . . . . . . . . . . 49.3 Logical and Observational Equivalence Coincide 49.4 Some Laws of Equivalence . . . . . . . . . . . . . 49.4.1 General Laws . . . . . . . . . . . . . . . . 49.4.2 Equivalence Laws . . . . . . . . . . . . . 49.4.3 Induction Law . . . . . . . . . . . . . . . 49.5 Notes . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
509 510 514 515 518 518 519 519 520
50 Equational Reasoning for PCF 50.1 Observational Equivalence . . . . . . . . . . . . . 50.2 Logical Equivalence . . . . . . . . . . . . . . . . . 50.3 Logical and Observational Equivalence Coincide 50.4 Compactness . . . . . . . . . . . . . . . . . . . . . 50.5 Co-Natural Numbers . . . . . . . . . . . . . . . . 50.6 Notes . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
521 521 522 523 526 529 531
51 Parametricity 51.1 Overview . . . . . . . . . . . . . . . . . . 51.2 Observational Equivalence . . . . . . . . 51.3 Logical Equivalence . . . . . . . . . . . . 51.4 Parametricity Properties . . . . . . . . . 51.5 Representation Independence, Revisited 51.6 Notes . . . . . . . . . . . . . . . . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
533 533 534 536 542 545 547
52 Process Equivalence 52.1 Process Calculus . . 52.2 Strong Equivalence 52.3 Weak Equivalence . 52.4 Notes . . . . . . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
549 549 552 555 557
XX
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
Appendices
. . . .
. . . .
. . . .
. . . .
. . . .
559
A Mathematical Preliminaries 561 A.1 Finite Sets and Maps . . . . . . . . . . . . . . . . . . . . . . . 561 A.2 Families of Sets . . . . . . . . . . . . . . . . . . . . . . . . . . 561
V ERSION 1.19
D RAFT
R EVISED 10.03.2011
Part I
Judgements and Rules
Chapter 1
Syntactic Objects Programming languages are languages, a means of expressing computations in a form comprehensible to both people and machines. The syntax of a language specifies the means by which various sorts of phrases (expressions, commands, declarations, and so forth) may be combined to form programs. But what sort of thing are these phrases? What is a program made of? The informal concept of syntax may be seen to involve several distinct concepts. The surface, or concrete, syntax is concerned with how phrases are entered and displayed on a computer. The surface syntax is usually thought of as given by strings of characters from some alphabet (say, ASCII or UniCode). The structural, or abstract, syntax is concerned with the structure of phrases, specifically how they are composed from other phrases. At this level a phrase is a tree, called an abstract syntax tree, whose nodes are operators that combine several phrases to form another phrase. The binding structure of syntax is concerned with the introduction and use of identifiers: how they are declared, and how declared identifiers are to be used. At this level phrases are abstract binding trees, which enrich abstract syntax trees with the concepts of binding and scope. In this chapter we prepare the ground for all of our later work by defining precisely what are strings, abstract syntax trees, and abstract binding trees. The definitions are a bit technical, but are fundamentally quite simple and intuitive. It is probably best to skim this chapter on first reading, returning to it only as the need arises.
4
1.1 Strings
1.1
Strings
An alphabet is a (finite or infinite) collection of characters. In practice the alphabet is a standardized set such as the UniCode character set. A string over an alphabet is either the null string, e, consisting of no characters, or the extension of a string by a single character, c · s. Strings are usually written as juxtapositions of characters, writing just abcd for the four-letter string a · (b · (c · (d · e))), for example. It follows from the definition of strings that to show that a property, P , holds of a string s, written P (s), it suffices to show two things: 1. P (e), and 2. if P (s) and c char, then P (c · s). This is called the principle of string induction. The concatenation, s1 ˆ s2 , of two strings over the same alphabet is defined in the obvious way. Concatentation is also denoted by juxtaposition, and individual characters are often identified with the corresponding unitlength string. This means that abcd can be thought of in many ways, for example as the concatenations ab cd, a bcd, or abc d, or even e abcd or abcd e, as may be convenient in a given situation. It does not matter, however, because string concatenation is associative: s1 ˆ (s2 ˆ s3 ) = (s1 ˆ s2 ) ˆ s3 . In Chapter 4 we will see that this innocuous-seeming fact is responsible for many of the complications in defining the concrete syntax of a language.
1.2
Abstract Syntax Trees
An abstract syntax tree, or ast for short, is an ordered tree whose leaves are variables, and whose interior nodes are operators whose arguments are its children. Abstract syntax trees are classified into a variety of sorts corresponding to different forms of syntax. A variable is an unknown, or indeterminate, standing for an unspecified, or generic, piece of syntax of a specified sort. Ast’s may be combined by an operator, which has both a sort and an arity, a finite sequence of sorts specifying the number and sorts of its arguments. An operator of sort s and arity s1 , . . . , sn combines n ≥ 0 ast’s of sort s1 , . . . , sn , respectively, into a compound ast of sort s. As a matter of terminology, a nullary operator is one that takes no arguments, a unary operator takes one, a binary operator two, and so forth. For example, consider a simple language of expressions built from numbers, addition, and multiplication. The abstract syntax of such a language V ERSION 1.19
D RAFT
R EVISED 10.03.2011
1.2 Abstract Syntax Trees
5
would consist of a single sort, Exp, and three operators that generate the forms of expression: num[n] is a nullary operator of sort Exp whenever n ∈ N; plus and times are binary operators of sort Exp whose arguments are both of sort Exp. The expression 2 + (3 × x ), which involves a variable, x, would be represented by the ast plus(num[2]; times(num[3]; x)) of sort Exp, under the assumption that x is also of this sort.1 Let S be a finite set of sorts. Let { Os }s∈S be a sort-indexed family of operators, o, of sort s with arity ar(o ) = (s1 , . . . , sn ). Let { Xs }s∈S be a sort-indexed family of variables, x, of each sort s. The family A[X ] = { A[X ]s }s∈S of ast’s of sort s is defined as follows: 1. A variable of sort s is an ast of sort s: if x ∈ Xs , then x ∈ A[X ]s . 2. Operators combine ast’s: if o is an operator of sort s such that ar(o ) = (s1 , . . . , sn ), and if a1 ∈ A[X ]s1 , . . . , an ∈ A[X ]sn , then o(a1 ; . . . ;an ) ∈ A[X ]s . It follows from this definition that the principle of structural induction may be used to prove that some property, P , holds of every ast. To show P ( a) holds for every a ∈ A[X ], it is enough to show: 1. If x ∈ Xs , then Ps ( x ). 2. If o ∈ Os and ar(o ) = (s1 , . . . , sn ), then if a1 ∈ Ps1 and . . . and an ∈ Psn , then o(a1 ; . . . ;an ) ∈ Ps . For example, it is easy to prove by structural induction that if X ⊆ Y , then A[X ] ⊆ A[Y ]. If X is a sort-indexed family of variables, we write X , x, where x is a variable of sort s such that x ∈ / Xs , to stand for the family of sets Y such that Ys = Xs ∪ { x } and Ys0 = Xs0 for all s0 6= s. The family X , x, where x is a variable of sort s, is said to be the family obtained by adjoining the variable x to the family X . Variables are given meaning by substitution. If a ∈ A[X , x ] and b ∈ A[X ], then [b/x ] a ∈ A[X ] is defined to be the result of substituting b for every occurrence of x in a. The ast a is called the target, and x is called the subject, of the substitution. Substitution is defined by the following equations: 1 In
Part II we will discuss in more detail the passage from the informal to the formal representation of syntax.
R EVISED 10.03.2011
D RAFT
V ERSION 1.19
6
1.2 Abstract Syntax Trees 1. [b/x ] x = b and [b/x ]y = y if x 6= y. 2. [b/x ]o(a1 ; . . . ;an ) = o([b/x ] a1 ; . . . ;[b/x ] an ).
For example, we may check that
[num[2]/x ]plus(x; num[3]) = plus(num[2]; num[3]). We may prove by structural induction that substitution on ast’s is welldefined. Theorem 1.1. If b ∈ A[X , x ], then for every a ∈ A[X ] there exists a unique c ∈ A[X ] such that [b/x ] a = c Proof. By structural induction on a. If a = x, then c = b by definition, otherwise if a = y 6= x, then c = y, also by definition. Otherwise, a = o(a1 , . . . , an ), and we have by induction unique c1 , . . . , cn such that [b/x ] a1 = c1 and . . . [b/x ] an = cn , and so c is c = o(c1 ; . . . ;cn ), by definition of substitution. In addition to variables we will also have need of a stock of identifiers, called symbols or names or parameters, that are not themselves forms of ast, but which may be used to index a family of operators of a given sort and arity. For example, let Cls be a distinguished sort of classes and let UCls be a set of symbols that are to be thought of as class names. For each name u ∈ UCls , let inst[u] be an operator of sort Exp and arity (Exp). Any such operator may be used to construct an ast, inst[u](a), of sort Exp from an ast, a, of this sort. This expression may be thought of as standing for an instance of the class u with instance data a.2 The class name is written in square brackets to emphasize that it is merely an index for a family of operators, and is not itself to be thought of as a form of ast. Let U be a sort-indexed family of symbols, and let O be a sort-indexed family of operators, any of which may involve parameters from U . The family of sets A[U ; X ] is defined to be the ast’s generated by the operators O , the variables X , and the symbols U . Renaming is extended to symbols in the evident manner, but substitution is defined only for variables in X , and not for symbols. This is as it should be, because symbols are not themselves forms of abstract syntax, and hence it makes no sense to consider replacing a symbol by an ast. 2 See
Chapters 14 and 27 for a full development of this motivating example.
V ERSION 1.19
D RAFT
R EVISED 10.03.2011
1.3 Abstract Binding Trees
1.3
7
Abstract Binding Trees
Abstract binding trees, or abt’s, enrich abstract syntax trees with the means to introduce new variables and symbols, called a binding, with a specified range of significance, called its scope. The scope of a binding is an abt within which the bound identifier may be used, either as a placeholder (in the case of a variable declaration) or as the index of some operator (in the case of a symbol declaration). Thus the set of active identifiers may be larger within a subtree of an abt than it is within the surrounding tree. Moreover, different subtrees may introduce identifiers with disjoint scopes. The crucial principle is that any use of an identifier should be understood as a reference, or abstract pointer, to its binding. One consequence is that the choice of identifier names is immaterial, so long as one can always associate a unique binding with each use of an identifier. As a motivating example, consider the expression let x be a1 in a2 , which introduces a variable, x, for use within the expression a2 to stand for the expression a1 . The variable x is bound by the let expression for use within a2 ; any use of x within a1 refers to a different variable that happens to have the same name. For example, in the expression let x be 7 in x + x occurrences of x in the addition refer to the variable introduced by the let. On the other hand in the expression let x be x ∗ x in x + x, occurrences of x within the multiplication refer to a different variable than those occurring within the addition. The latter occurrences refer to the binding introduced by the let, whereas the former refer to some outer binding not displayed here. The names of bound variables are immaterial insofar as they determine the same binding. So, for example, the expression let x be x ∗ x in x + x could just as well have been written let y be x ∗ x in y + y without changing its meaning. In the former case the variable x is bound within the addition, and in the latter it is the variable y, but the “pointer structure” remains the same. On the other hand the expression let x be y ∗ y in x + x has a different meaning to these two expressions, because now the variable y within the multiplication refers to a different surrounding variable. Renaming of bound variables is constrained to the extent that it must not alter the reference structure of the expression. For example, the expression let x be 2 in let y be 3 in x + x has a different meaning than the expression let y be 2 in let y be 3 in y + y, because the y in the expression succ(y) in the second case refers to the inner declaration, not the outer one as before. The concept of an ast may be enriched to account for binding and scope of variable. These enriched ast’s are called abstract binding trees, or abt’s R EVISED 10.03.2011
D RAFT
V ERSION 1.19
8
1.3 Abstract Binding Trees
for short. Abt’s generalize ast’s by allowing an operator to bind any finite number (possibly zero) of variables in each argument position. An argument to an operator is called an abstractor, and has the form x1 , . . . , xk .a. The sequence of variables x1 , . . . , xk are bound within the abt a. (When k is zero, we elide the distinction between .a and a itself.) Written in the form of an abt, the expression let x be a1 in a2 has the form let(a1 ; x.a2 ), which more clearly specifies that the variable x is bound within a2 , and not within a1 . We often write ~x to stand for a finite sequence x1 , . . . , xn of distinct variables, and write ~x.a to mean x1 , . . . , xn .a. To account for binding, the arity of an operator is generalized to consist of a finite sequence of valences. The length of the sequence determines the number of arguments, and each valence determines the sort of the argument and the number and sorts of the variables that are bound within it. A valence of the form (s1 , . . . , sk )s specifies an argument of sort s that binds k variables of sorts s1 , . . . , sk within it. We often write ~s for a finite sequence s1 , . . . , sn of sorts, and we say that ~x is of sort ~s to mean that the two sequences have the same length and that each xi is of sort si . Thus, for example, the arity of the operator let is (Exp, (Exp)Exp), which indicates that it takes two arguments described as follows: 1. The first argument is of sort Exp and binds no variables. 2. The second argument is of sort Exp and binds one variable of sort Exp. The definition expression let x be 2 + 2 in x × x is represented by the abstract binding tree let(plus(num[2]; num[2]); x.times(x; x)). Let O be a sort-indexed family of operators, o, with arities, ar(o ). For a given sort-indexed family, X , of variables, the sort-indexed family of abt’s, B[X ], is defined similarly to A[X ], except that the set of active variables changes for each argument according to which variables are bound within it. A first cut at the definition is as follows: 1. If x ∈ Xs , then x ∈ B[X ]s . 2. If ar(o ) = ((~s1 )s1 , . . . , (~sn )sn ), and if, for each 1 ≤ i ≤ n, ~xi is of sort ~si and ai ∈ B[X , ~xi ]si , then o(~x1 .a1 ; . . . ;~xn .an ) ∈ B[X ]s . The bound variables are adjoined to the set of active variables within each argument, with the sort of each variable determined by the valence of the operator. V ERSION 1.19
D RAFT
R EVISED 10.03.2011
1.3 Abstract Binding Trees
9
This definition is almost correct, but fails to properly account for the behavior of bound variables. An abt of the form let(a1 ; x.let(a2 ; x.a3 )) is ill-formed according to this definition, because the first binding adjoins x to X , which implies that the second cannot also adjoin x to X , x without causing confusion. The solution is to ensure that each of the arguments is well-formed regardless of the choice of bound variable names. This is achieved by altering the second clause of the definition using renaming as follows:3 If ar(o ) = ((~x1 )s1 , . . . , (~xn )sn ), and if, for each 1 ≤ i ≤ n and for each renaming πi : ~xi ↔ ~xi0 , where ~xi0 ∈ / X , we have πi · ai ∈ 0 B[X , ~xi ], then o(~x1 .a1 ; . . . ;~xn .an ) ∈ B[X ]s . The renaming ensures that when we encounter nested binders we avoid collisions. This is called the freshness condition on binders since it ensures that all bound variables are “fresh” relative to the surrounding context. The principle of structural induction extends to abt’s, and is called structural induction modulo renaming. It states that to show that P ( a)[X ] holds for every a ∈ B[X ], it is enough to show the following: 1. if x ∈ Xs , then P [X ]s ( x ). 2. For every o of sort s and arity ((~s1 )s1 , . . . , (~sn )sn ), and if for each 1 ≤ i ≤ n, we have P [X , ~xi0 ]si (πi · ai ) for every renaming πi : ~xi ↔ ~xi0 , then P [X ]s (o(~x1 .a1 ; . . . ;~xn .an )). The renaming in the second condition ensures that the inductive hypothesis holds for all fresh choices of bound variable names, and not just the ones actually given in the abt. As an example let us define the judgement x ∈ a, where a ∈ B[X , x ], to mean that x occurs free in a. Informally, this means that x is bound somewhere outside of a, rather than within a itself. If x is bound within a, then those occurrences of x are different from those occurring outside the binding. The following definition ensures that this is the case: 1. x ∈ x. 2. x ∈ o(~x1 .a1 ; . . . ;~xn .an ) if there exists 1 ≤ i ≤ n such that for every fresh renaming π : ~xi ↔ ~zi we have x ∈ π · ai . 3 The
action of a renaming extends to abt’s in the obvious way by replacing every occurrence of x by π ( x ), including any occurrences in the variable list of an abstractor as well as within its body.
R EVISED 10.03.2011
D RAFT
V ERSION 1.19
10
1.3 Abstract Binding Trees
The first condition states that x is free in x, but not free in y for any variable y other than x. The second condition states that if x is free in some argument, independently of the choice of bound variable names in that argument, then it is free in the overall abt. This implies, in particular, that x is not free in let(zero; x.x). The relation a =α b of α-equivalence (so-called for historical reasons), is defined to mean that a and b are identical up to the choice of bound variable names. This relation is defined to be the strongest congruence containing the following two conditions: 1. x =α x. 2. o(~x1 .a1 ; . . . ;~xn .an ) =α o(~x10 .a10 ; . . . ;~xn0 .a0n ) if for every 1 ≤ i ≤ n, πi · ai =α πi0 · ai0 for all fresh renamings πi : ~xi ↔ ~zi and πi0 : ~xi0 ↔ ~zi . The idea is that we rename ~xi and ~xi0 consistently, avoiding confusion, and check that ai and ai0 are α-equivalent. If a =α b, then a and b are said to be α-variants of each other. Some care is required in the definition of substitution of an abt b of sort s for free occurrences of a variable x of sort s in some abt a of some sort, written [b/x ] a. Substitution is partially defined by the following conditions: 1. [b/x ] x = b, and [b/x ]y = y if x 6= y. 2. [b/x ]o(~x1 .a1 ; . . . ;~xn .an ) = o(~x1 .a10 ; . . . ;~xn .a0n ), where, for each 1 ≤ i ≤ n, we require that ~xi 6∈ b, and we set ai0 = [b/x ] ai if x ∈ / ~xi , and ai0 = ai otherwise. If x is bound in some argument to an operator, then substitution does not descend into its scope, for to do so would be to confuse two distinct variables. For this reason we must take care to define ai0 in the second equation according to whether or not x ∈ ~xi . The requirement that ~xi 6∈ b in the second equation is called capture avoidance. If some xi,j occurred free in b, then the result of the substitution [b/x ] ai would in general contain xi,j free as well, but then forming ~xi .[b/x ] ai would incur capture by changing the referent of xi,j to be the jth bound variable of the ith argument. In such cases substitution is undefined since we cannot replace x by b in ai without incurring capture. One way around this is to alter the definition of substitution so that the bound variables in the result are chosen fresh by substitution. By the principle of structural induction we know inductively that, for any renaming V ERSION 1.19
D RAFT
R EVISED 10.03.2011
1.3 Abstract Binding Trees
11
πi : ~xi ↔ ~xi0 with ~xi0 fresh, the substitution [b/x ](πi · ai ) is well-defined. Hence we may define
[b/x ]o(~x1 .a1 ; . . . ;~xn .an ) = o(~x10 .[b/x ](π1 · a1 ); . . . ;~xn0 .[b/x ](πn · an )) for some particular choice of fresh bound variable names (any choice will do). There is no longer any need to take care that x ∈ / ~xi in each argument, because the freshness condition on binders ensures that this cannot occur, the variable x already being active. Noting that o(~x1 .a1 ; . . . ;~xn .an ) =α o(~x10 .π1 · a1 ; . . . ;~xn0 .πn · an ), another way to avoid undefined substitutions is to first choose an α-variant of the target of the substitution whose binders avoid any free variables in the substituting abt, and then perform substitution without fear of incurring capture. In other words substitution is totally defined on α-equivalence classes of abt’s. To avoid all the bureaucracy of binding, we adopt the following identification convention throughout this book: Abstract binding trees are always to be identified up to α-equivalence. That is, we implicitly work with α-equivalence classes of abt’s, rather than abt’s themselves. We tacitly assert that all operations and relations on abt’s respect α-equivalence, so that they are properly defined on α-equivalence classes of abt’s. Whenever we examine an abt, we are choosing a representative of its α-equivalence class, and we have no control over how the bound variable names are chosen. On the other hand experience shows that any operation or property of interest respects α-equivalence, so there is no obstacle to achieving it. Indeed, we might say that a property or operation is legitimate exactly insofar as it respects α-equivalence! Symbols, as well as variables, may be bound within an argument. Operators indexed by such symbols come into existence within the scope of the symbol, and go out of existence outside of that scope. As an example, consider the family of nullary operators cls[a] of sort Exp indexed by symbols a. (Such an operator might represent a class of data; see Chapter 14 for further development of this idea.) The operator cls[a] is available only within the scope of the symbol, a, and is otherwise unavailable. To allow for symbol declaration the valence of an argument is generalized a bit further to specify the number and valences of its bound symbols, as well as of its bound names, (~r;~s)s. The sort-indexed family B[U ; X ] is R EVISED 10.03.2011
D RAFT
V ERSION 1.19
12
1.4 Notes
the set of abt’s determined by a fixed set of operators using the symbols, U , and the variables, X . We generally rely on naming conventions to distinguish symbols from variables, reserving u and v for generic symbols, and x and y for generic variables.
1.4
Notes
The concept of abstract syntax has its orgins in the pioneering work of ¨ Church, Turing, and Godel, who first considered the possibility of writing programs that act on representations of programs. Originally programs were represented by natural numbers, using encodings, now called G¨odelnumberings, based on the prime factorization theorem. Any standard text on mathematical logic, such as Kleene (1952), contains a thorough account of such representations. The Lisp language (McCarthy, 1965; Allen, 1978) introduced a much more practical and direct representation of syntax as symbolic expressions. These ideas were developed further in the language ML (Gordon et al., 1979), which featured a type system capable of expressing abstract syntax trees. The AUTOMATH project (Nederpelt et al., 1994) introduced the idea of using Church’s λ notation (Church, 1941) to account for the binding and scope of variables. These ideas were developed further in LF (Harper et al., 1993).
V ERSION 1.19
D RAFT
R EVISED 10.03.2011
Chapter 2
Inductive Definitions Inductive definitions are an indispensable tool in the study of programming languages. In this chapter we will develop the basic framework of inductive definitions, and give some examples of their use. An inductive definition consists of a set of rules for deriving judgements, or assertions, of a variety of forms. Judgements are statements about one or more syntactic objects of a specified sort. The rules specify necessary and sufficient conditions for the validity of a judgement, and hence fully determine its meaning.
2.1
Judgements
We start with the notion of a judgement, or assertion, about a syntactic object. We shall make use of many forms of judgement, including examples such as these: n nat n is a natural number n = n1 + n2 n is the sum of n1 and n2 τ type τ is a type e:τ expression e has type τ e⇓v expression e has value v A judgement states that one or more syntactic objects have a property or stand in some relation to one another. The property or relation itself is called a judgement form, and the judgement that an object or objects have that property or stand in that relation is said to be an instance of that judgement form. A judgement form is also called a predicate, and the objects constituting an instance are its subjects. We write a J for the judgement asserting that J holds of a. When it is not important to stress the subject of
14
2.2 Inference Rules
the judgement, we write J to stand for an unspecified judgement. For particular judgement forms, we freely use prefix, infix, or mixfix notation, as illustrated by the above examples, in order to enhance readability.
2.2
Inference Rules
An inductive definition of a judgement form consists of a collection of rules of the form J1 . . . Jk (2.1) J in which J and J1 , . . . , Jk are all judgements of the form being defined. The judgements above the horizontal line are called the premises of the rule, and the judgement below the line is called its conclusion. If a rule has no premises (that is, when k is zero), the rule is called an axiom; otherwise it is called a proper rule. An inference rule may be read as stating that the premises are sufficient for the conclusion: to show J, it is enough to show J1 , . . . , Jk . When k is zero, a rule states that its conclusion holds unconditionally. Bear in mind that there may be, in general, many rules with the same conclusion, each specifying sufficient conditions for the conclusion. Consequently, if the conclusion of a rule holds, then it is not necessary that the premises hold, for it might have been derived by another rule. For example, the following rules constitute an inductive definition of the judgement a nat: (2.2a) zero nat a nat (2.2b) succ(a) nat These rules specify that a nat holds whenever either a is zero, or a is succ(b) where b nat for some b. Taking these rules to be exhaustive, it follows that a nat iff a is a natural number. Similarly, the following rules constitute an inductive definition of the judgement a tree: empty tree a1 tree a2 tree node(a1 ; a2 ) tree
(2.3a) (2.3b)
These rules specify that a tree holds if either a is empty, or a is node(a1 ; a2 ), where a1 tree and a2 tree. Taking these to be exhaustive, these rules state V ERSION 1.19
D RAFT
R EVISED 10.03.2011
2.3 Derivations
15
that a is a binary tree, which is to say it is either empty, or a node consisting of two children, each of which is also a binary tree. The judgement a = b nat defining equality of a nat and b nat is inductively defined by the following rules: zero = zero nat
(2.4a)
a = b nat (2.4b) succ(a) = succ(b) nat In each of the preceding examples we have made use of a notational convention for specifying an infinite family of rules by a finite number of patterns, or rule schemes. For example, Rule (2.2b) is a rule scheme that determines one rule, called an instance of the rule scheme, for each choice of object a in the rule. We will rely on context to determine whether a rule is stated for a specific object, a, or is instead intended as a rule scheme specifying a rule for each choice of objects in the rule. A collection of rules is considered to define the strongest judgement that is closed under, or respects, those rules. To be closed under the rules simply means that the rules are sufficient to show the validity of a judgement: J holds if there is a way to obtain it using the given rules. To be the strongest judgement closed under the rules means that the rules are also necessary: J holds only if there is a way to obtain it by applying the rules. The sufficiency of the rules means that we may show that J holds by deriving it by composing rules. Their necessity means that we may reason about it using rule induction.
2.3
Derivations
To show that an inductively defined judgement holds, it is enough to exhibit a derivation of it. A derivation of a judgement is a finite composition of rules, starting with axioms and ending with that judgement. It may be thought of as a tree in which each node is a rule whose children are derivations of its premises. We sometimes say that a derivation of J is evidence for the validity of an inductively defined judgement J. We usually depict derivations as trees with the conclusion at the bottom, and with the children of a node corresponding to a rule appearing above it as evidence for the premises of that rule. Thus, if J1
R EVISED 10.03.2011
... J D RAFT
Jk
V ERSION 1.19
16
2.3 Derivations
is an inference rule and ∇1 , . . . , ∇k are derivations of its premises, then
∇1
... J
∇k
is a derivation of its conclusion. In particular, if k = 0, then the node has no children. For example, this is a derivation of succ(succ(succ(zero))) nat: zero nat succ(zero) nat succ(succ(zero)) nat . succ(succ(succ(zero))) nat
(2.5)
Similarly, here is a derivation of node(node(empty; empty); empty) tree: empty tree empty tree node(empty; empty) tree empty tree . node(node(empty; empty); empty) tree
(2.6)
To show that an inductively defined judgement is derivable we need only find a derivation for it. There are two main methods for finding derivations, called forward chaining, or bottom-up construction, and backward chaining, or top-down construction. Forward chaining starts with the axioms and works forward towards the desired conclusion, whereas backward chaining starts with the desired conclusion and works backwards towards the axioms. More precisely, forward chaining search maintains a set of derivable judgements, and continually extends this set by adding to it the conclusion of any rule all of whose premises are in that set. Initially, the set is empty; the process terminates when the desired judgement occurs in the set. Assuming that all rules are considered at every stage, forward chaining will eventually find a derivation of any derivable judgement, but it is impossible (in general) to decide algorithmically when to stop extending the set and conclude that the desired judgement is not derivable. We may go on and on adding more judgements to the derivable set without ever achieving the intended goal. It is a matter of understanding the global properties of the rules to determine that a given judgement is not derivable. Forward chaining is undirected in the sense that it does not take account of the end goal when deciding how to proceed at each step. In V ERSION 1.19
D RAFT
R EVISED 10.03.2011
2.4 Rule Induction
17
contrast, backward chaining is goal-directed. Backward chaining search maintains a queue of current goals, judgements whose derivations are to be sought. Initially, this set consists solely of the judgement we wish to derive. At each stage, we remove a judgement from the queue, and consider all rules whose conclusion is that judgement. For each such rule, we add the premises of that rule to the back of the queue, and continue. If there is more than one such rule, this process must be repeated, with the same starting queue, for each candidate rule. The process terminates whenever the queue is empty, all goals having been achieved; any pending consideration of candidate rules along the way may be discarded. As with forward chaining, backward chaining will eventually find a derivation of any derivable judgement, but there is, in general, no algorithmic method for determining in general whether the current goal is derivable. If it is not, we may futilely add more and more judgements to the goal set, never reaching a point at which all goals have been satisfied.
2.4
Rule Induction
Since an inductive definition specifies the strongest judgement closed under a collection of rules, we may reason about them by rule induction. The principle of rule induction states that to show that a property P holds of a judgement J whenever J is derivable, it is enough to show that P is closed under, or respects, the rules defining J. Writing P ( J ) to mean that the property P holds of the judgement J, we say that P respects the rule J1
... J
Jk
if P ( J ) holds whenever P ( J1 ), . . . , P ( Jk ). The assumptions P ( J1 ), . . . , P ( Jk ) are called the inductive hypotheses, and P ( J ) is called the inductive conclusion of the inference. The principle of rule induction is simply the expression of the definition of an inductively defined judgement form as the strongest judgement form closed under the rules comprising the definition. This means that the judgement form defined by a set of rules is both (a) closed under those rules, and (b) sufficient for any other property also closed under those rules. The former means that a derivation is evidence for the validity of a judgement; the latter means that we may reason about an inductively defined judgement form by rule induction. R EVISED 10.03.2011
D RAFT
V ERSION 1.19
18
2.4 Rule Induction
When specialized to Rules (2.2), the principle of rule induction states that to show P ( a nat) whenever a nat, it is enough to show: 1. P (zero nat). 2. for every a, if a nat and P ( a nat), then (succ(a) nat and) P (succ(a) nat). This is just the familiar principle of mathematical induction arising as a special case of rule induction. Similarly, rule induction for Rules (2.3) states that to show P ( a tree) whenever a tree, it is enough to show 1. P (empty tree). 2. for every a1 and a2 , if a1 tree and P ( a1 tree), and if a2 tree and P ( a2 tree), then (node(a1 ; a2 ) tree and) P (node(a1 ; a2 ) tree). This is called the principle of tree induction, and is once again an instance of rule induction. We may also show by rule induction that the predecessor of a natural number is also a natural number. While this may seem self-evident, the point of the example is to show how to derive this from first principles. Lemma 2.1. If succ(a) nat, then a nat. Proof. It suffices to show that the property, P ( a nat) stating that a nat and that a = succ(b) implies b nat is closed under Rules (2.2). Rule (2.2a) Clearly zero nat, and the second condition holds vacuously, since zero is not of the form succ(−). Rule (2.2b) Inductively we know that a nat and that if a is of the form succ(b), then b nat. We are to show that succ(a) nat, which is immediate, and that if succ(a) is of the form succ(b), then b nat, and we have b nat by the inductive hypothesis. This completes the proof. Using rule induction we may show that equality, as defined by Rules (2.4) is reflexive. Lemma 2.2. If a nat, then a = a nat. Proof. By rule induction on Rules (2.2): V ERSION 1.19
D RAFT
R EVISED 10.03.2011
2.5 Iterated and Simultaneous Inductive Definitions
19
Rule (2.2a) Applying Rule (2.4a) we obtain zero = zero nat. Rule (2.2b) Assume that a = a nat. It follows that succ(a) = succ(a) nat by an application of Rule (2.4b).
Similarly, we may show that the successor operation is injective. Lemma 2.3. If succ(a1 ) = succ(a2 ) nat, then a1 = a2 nat. Proof. Similar to the proof of Lemma 2.1 on the facing page.
2.5
Iterated and Simultaneous Inductive Definitions
Inductive definitions are often iterated, meaning that one inductive definition builds on top of another. In an iterated inductive definition the premises of a rule J1 . . . Jk J may be instances of either a previously defined judgement form, or the judgement form being defined. For example, the following rules define the judgement a list stating that a is a list of natural numbers.
nil list a nat b list cons(a; b) list
(2.7a) (2.7b)
The first premise of Rule (2.7b) is an instance of the judgement form a nat, which was defined previously, whereas the premise b list is an instance of the judgement form being defined by these rules. Frequently two or more judgements are defined at once by a simultaneous inductive definition. A simultaneous inductive definition consists of a set of rules for deriving instances of several different judgement forms, any of which may appear as the premise of any rule. Since the rules defining each judgement form may involve any of the others, none of the judgement forms may be taken to be defined prior to the others. Instead one must understand that all of the judgement forms are being defined at once by the entire collection of rules. The judgement forms defined by these rules are, as before, the strongest judgement forms that are closed under the rules. R EVISED 10.03.2011
D RAFT
V ERSION 1.19
20
2.6 Defining Functions by Rules
Therefore the principle of proof by rule induction continues to apply, albeit in a form that requires us to prove a property of each of the defined judgement forms simultaneously. For example, consider the following rules, which constitute a simultaneous inductive definition of the judgements a even, stating that a is an even natural number, and a odd, stating that a is an odd natural number: (2.8a)
zero even
a odd (2.8b) succ(a) even a even (2.8c) succ(a) odd The principle of rule induction for these rules states that to show simultaneously that P ( a even) whenever a even and P ( a odd) whenever a odd, it is enough to show the following: 1. P (zero even); 2. if P ( a odd), then P (succ(a) even); 3. if P ( a even), then P (succ(a) odd). As a simple example, we may use simultaneous rule induction to prove that (1) if a even, then a nat, and (2) if a odd, then a nat. That is, we define the property P by (1) P ( a even) iff a nat, and (2) P ( a odd) iff a nat. The principle of rule induction for Rules (2.8) states that it is sufficient to show the following facts: 1. zero nat, which is derivable by Rule (2.2a). 2. If a nat, then succ(a) nat, which is derivable by Rule (2.2b). 3. If a nat, then succ(a) nat, which is also derivable by Rule (2.2b).
2.6
Defining Functions by Rules
A common use of inductive definitions is to define a function by giving an inductive definition of its graph relating inputs to outputs, and then showing that the relation uniquely determines the outputs for given inputs. For example, we may define the addition function on natural numbers as the V ERSION 1.19
D RAFT
R EVISED 10.03.2011
2.6 Defining Functions by Rules
21
relation sum( a; b; c), with the intended meaning that c is the sum of a and b, as follows: b nat (2.9a) sum(zero; b; b) sum( a; b; c) sum(succ(a); b; succ(c))
(2.9b)
The rules define a ternary (three-place) relation, sum( a; b; c), among natural numbers a, b, and c. We may show that c is determined by a and b in this relation. Theorem 2.4. For every a nat and b nat, there exists a unique c nat such that sum( a; b; c). Proof. The proof decomposes into two parts: 1. (Existence) If a nat and b nat, then there exists c nat such that sum( a; b; c). 2. (Uniqueness) If sum( a; b; c), and sum( a; b; c0 ), then c = c0 nat. For existence, let P ( a nat) be the proposition if b nat then there exists c nat such that sum( a; b; c). We prove that if a nat then P ( a nat) by rule induction on Rules (2.2). We have two cases to consider: Rule (2.2a) We are to show P (zero nat). Assuming b nat and taking c to be b, we obtain sum(zero; b; c) by Rule (2.9a). Rule (2.2b) Assuming P ( a nat), we are to show P (succ(a) nat). That is, we assume that if b nat then there exists c such that sum( a; b; c), and are to show that if b0 nat, then there exists c0 such that sum(succ(a); b0 ; c0 ). To this end, suppose that b0 nat. Then by induction there exists c such that sum( a; b0 ; c). Taking c0 = succ(c), and applying Rule (2.9b), we obtain sum(succ(a); b0 ; c0 ), as required. For uniqueness, we prove that if sum( a; b; c1 ), then if sum( a; b; c2 ), then c1 = c2 nat by rule induction based on Rules (2.9). Rule (2.9a) We have a = zero and c1 = b. By an inner induction on the same rules, we may show that if sum(zero; b; c2 ), then c2 is b. By Lemma 2.2 on page 18 we obtain b = b nat. Rule (2.9b) We have that a = succ(a0 ) and c1 = succ(c10 ), where sum( a0 ; b; c10 ). By an inner induction on the same rules, we may show that if sum( a; b; c2 ), then c2 = succ(c20 ) nat where sum( a0 ; b; c20 ). By the outer inductive hypothesis c10 = c20 nat and so c1 = c2 nat.
R EVISED 10.03.2011
D RAFT
V ERSION 1.19
22
2.7
2.7 Modes
Modes
The statement that one or more arguments of a judgement is (perhaps uniquely) determined by its other arguments is called a mode specification for that judgement. For example, we have shown that every two natural numbers have a sum according to Rules (2.9). This fact may be restated as a mode specification by saying that the judgement sum( a; b; c) has mode (∀, ∀, ∃). The notation arises from the form of the proposition it expresses: for all a nat and for all b nat, there exists c nat such that sum( a; b; c). If we wish to further specify that c is uniquely determined by a and b, we would say that the judgement sum( a; b; c) has mode (∀, ∀, ∃!), corresponding to the proposition for all a nat and for all b nat, there exists a unique c nat such that sum( a; b; c). If we wish only to specify that the sum is unique, if it exists, then we would say that the addition judgement has mode (∀, ∀, ∃≤1 ), corresponding to the proposition for all a nat and for all b nat there exists at most one c nat such that sum( a; b; c). As these examples illustrate, a given judgement may satisfy several different mode specifications. In general the universally quantified arguments are to be thought of as the inputs of the judgement, and the existentially quantified arguments are to be thought of as its outputs. We usually try to arrange things so that the outputs come after the inputs, but it is not essential that we do so. For example, addition also has the mode (∀, ∃≤1 , ∀), stating that the sum and the first addend uniquely determine the second addend, if there is any such addend at all. Put in other terms, this says that addition of natural numbers has a (partial) inverse, namely subtraction. We could equally well show that addition has mode (∃≤1 , ∀, ∀), which is just another way of stating that addition of natural numbers has a partial inverse. Often there is an intended, or principal, mode of a given judgement, which we often foreshadow by our choice of notation. For example, when giving an inductive definition of a function, we often use equations to indicate the intended input and output relationships. For example, we may re-state the inductive definition of addition (given by Rules (2.9)) using equations: a nat (2.10a) a + zero = a nat a + b = c nat a + succ(b) = succ(c) nat
(2.10b)
When using this notation we tacitly incur the obligation to prove that the mode of the judgement is such that the object on the right-hand side of the V ERSION 1.19
D RAFT
R EVISED 10.03.2011
2.8 Notes
23
equations is determined as a function of those on the left. Having done so, we abuse notation, writing a + b for the unique c such that a + b = c nat.
2.8
Notes
Aczel (1977) provides a thorough account of the theory of inductive defi¨ nitions. The formulation given here is strongly influenced by Martin-Lof’s ¨ 1983, 1987). development of the logic of judgements (Martin-Lof,
R EVISED 10.03.2011
D RAFT
V ERSION 1.19
24
V ERSION 1.19
2.8 Notes
D RAFT
R EVISED 10.03.2011
Chapter 3
Hypothetical and General Judgements A hypothetical judgement expresses an entailment between one or more hypotheses and a conclusion. We will consider two notions of entailment, called derivability and admissibility. Both enjoy the same structural properties expected of entailment, but they differ in that whereas derivability is stable under the addition of new rules, admissibility is, in general, not. A general judgement expresses the universality, or genericity, of a (basic or hypothetical) judgement. There are two forms of general judgement, the generic and the parametric. The generic judgement expresses generality with respect to all substitution instances for variables in a judgement. The parametric judgement expresses generality with respect to renamings of symbols.
3.1 3.1.1
Hypothetical Judgements Derivability
For a given set, R, of rules, we define the derivability judgement, written J1 , . . . , Jk `R K, where each Ji and K are basic judgements, to mean that we may derive K from the expansion R[ J1 , . . . , Jk ] of the rules R with the additional axioms J1
...
Jk
.
That is, we treat the hypotheses, or antecedents, of the judgement, J1 , . . . , Jn as temporary axioms, and derive the conclusion, or consequent, by composing
26
3.1 Hypothetical Judgements
rules in R. That is, evidence for a hypothetical judgement consists of a derivation of the conclusion from the hypotheses using the rules in R. We use capital Greek letters, frequently Γ or ∆, to stand for a finite collection of basic judgements, and write R[Γ] for the expansion of R with an axiom corresponding to each judgement in Γ. The judgement Γ `R K means that K is derivable from rules R[Γ], and the judgement `R Γ means that `R J for each J in Γ. An equivalent way of defining J1 , . . . , Jn `R J is to say that the rule J1 . . . Jn (3.1) J is derivable from R, which means that there is a derivation of J composed of the rules in R augmented by treating J1 , . . . , Jn as axioms. For example, consider the derivability judgement a nat `(2.2) succ(succ(a)) nat
(3.2)
relative to Rules (2.2). This judgement is valid for any choice of object a, as evidenced by the derivation a nat succ(a) nat succ(succ(a)) nat
(3.3)
which composes Rules (2.2), starting with a nat as an axiom, and ending with succ(succ(a)) nat. Equivalently, the validity of (3.2) may also be expressed by stating that the rule a nat succ(succ(a)) nat
(3.4)
is derivable from Rules (2.2). It follows directly from the definition of derivability that it is stable under extension with new rules. Theorem 3.1 (Stability). If Γ `R J, then Γ `R∪R0 J. Proof. Any derivation of J from R[Γ] is also a derivation from (R ∪ R0 )[Γ], since any rule in R is also a rule in R ∪ R0 . Derivability enjoys a number of structural properties that follow from its definition, independently of the rules, R, in question. Reflexivity Every judgement is a consequence of itself: Γ, J `R J. Each hypothesis justifies itself as conclusion. V ERSION 1.19
D RAFT
R EVISED 10.03.2011
3.1 Hypothetical Judgements
27
Weakening If Γ `R J, then Γ, K `R J. Entailment is not influenced by unexercised options. Transitivity If Γ, K `R J and Γ `R K, then Γ `R J. If we replace an axiom by a derivation of it, the result is a derivation of its consequent without that hypothesis. Reflexivity follows directly from the meaning of derivability. Weakening follows directly from the definition of derivability. Transitivity is proved by rule induction on the first premise.
3.1.2
Admissibility
Admissibility, written Γ |=R J, is a weaker form of hypothetical judgement stating that `R Γ implies `R J. That is, the conclusion J is derivable from rules R whenever the assumptions Γ are all derivable from rules R. In particular if any of the hypotheses are not derivable relative to R, then the judgement is vacuously true. An equivalent way to define the judgement J1 , . . . , Jn |=R J is to state that the rule J1
... J
Jn (3.5)
is admissible relative to the rules in R. This means that given any derivations of J1 , . . . , Jn using the rules in R, we may construct a derivation of J using the rules in R. For example, the admissibility judgement succ(a) nat |=(2.2) a nat
(3.6)
is valid, because any derivation of succ(a) nat from Rules (2.2) must contain a sub-derivation of a nat from the same rules, which justifies the conclusion. The validity of (3.6) may equivalently be expressed by stating that the rule succ(a) nat a nat (3.7) is admissible for Rules (2.2). In contrast to derivability the admissibility judgement is not stable under extension to the rules. For example, if we enrich Rules (2.2) with the axiom succ(junk) nat R EVISED 10.03.2011
D RAFT
(3.8) V ERSION 1.19
28
3.1 Hypothetical Judgements
(where junk is some object for which junk nat is not derivable), then the admissibility (3.6) is invalid. This is because Rule (3.8) has no premises, and there is no composition of rules deriving junk nat. Admissibility is as sensitive to which rules are absent from an inductive definition as it is to which rules are present in it. The structural properties of derivability ensure that derivability is stronger than admissibility. Theorem 3.2. If Γ `R J, then Γ |=R J. Proof. Repeated application of the transitivity of derivability shows that if Γ `R J and `R Γ, then `R J. To see that the converse fails, observe that there is no composition of rules such that succ(junk) nat `(2.2) junk nat, yet the admissibility judgement succ(junk) nat |=(2.2) junk nat holds vacuously. Evidence for admissibility may be thought of as a mathematical function transforming derivations ∇1 , . . . , ∇n of the hypotheses into a derivation ∇ of the consequent. Therefore, the admissibility judgement enjoys the same structural properties as derivability, and hence is a form of hypothetical judgement: Reflexivity If J is derivable from the original rules, then J is derivable from the original rules: J |=R J. Weakening If J is derivable from the original rules assuming that each of the judgements in Γ are derivable from these rules, then J must also be derivable assuming that Γ and also K are derivable from the original rules: if Γ |=R J, then Γ, K |=R J. Transitivity If Γ, K |=R J and Γ |=R K, then Γ |=R J. If the judgements in Γ are derivable, so is K, by assumption, and hence so are the judgements in Γ, K, and hence so is J. Theorem 3.3. The admissibility judgement Γ |=R J enjoys the structural properties of entailment. V ERSION 1.19
D RAFT
R EVISED 10.03.2011
3.2 Hypothetical Inductive Definitions
29
Proof. Follows immediately from the definition of admissibility as stating that if the hypotheses are derivable relative to R, then so is the conclusion.
If a rule, r, is admissible with respect to a rule set, R, then `R,r J is equivalent to `R J. For if `R J, then obviously `R,r J, by simply disregarding r. Conversely, if `R,r J, then we may replace any use of r by its expansion in terms of the rules in R. Admissiblity of a rule, r, of the form (3.5) means that any derivations of J1 ,. . . ,Jn with respect to rules R may be transformed into a derivation of J with respect to the same set of rules. It follows by rule induction on R, r that every derivation from the expanded set of rules, R, r, may be transformed into a derivation from R alone. Consequently, if we wish to show that P ( J ) whenever `R,r J, it is sufficient to show that P is closed under the rules R alone. That is, we need only consider the rules R in a proof by rule induction to derive P ( J ).
3.2
Hypothetical Inductive Definitions
It is useful to enrich the concept of an inductive definition to permit rules with derivability judgements as premises and conclusions. Doing so permits us to introduce local hypotheses that apply only in the derivation of a particular premise, and also allows us to constrain inferences based on the global hypotheses in effect at the point where the rule is applied. A hypothetical inductive definition consists of a collection of hypothetical rules of the following form: Γ Γ1 ` J1
. . . Γ Γn ` Jn . Γ`J
(3.9)
The hypotheses Γ are the global hypotheses of the rule, and the hypotheses Γi are the local hypotheses of the ith premise of the rule. Informally, this rule states that J is a derivable consequence of Γ whenever each Ji is a derivable consequence of Γ, augmented with the additional hypotheses Γi . Thus, one way to show that J is derivable from Γ is to show, in turn, that each Ji is derivable from Γ Γi . The derivation of each premise involves a “context switch” in which we extend the global hypotheses with the local hypotheses of that premise, establishing a new set of global hypotheses for use within that derivation. In most cases a rule is stated for all choices of global context, in which case it is said to be uniform. A uniform rule may be given in the implicit R EVISED 10.03.2011
D RAFT
V ERSION 1.19
30
3.2 Hypothetical Inductive Definitions
form
Γ1 ` J1
... J
Γn ` Jn
(3.10)
which stands for the collection of all rules of the form (3.9) in which the global hypotheses have been made explicit. A hypothetical inductive definition is to be regarded as an ordinary inductive definition of a formal derivability judgement Γ ` J consisting of a finite set of basic judgements, Γ, and a basic judgement, J. A collection of hypothetical rules, R, defines the strongest formal derivability judgement that is structural and closed under rules R. Structurality means that the formal derivability judgement must be closed under the following rules: (3.11a)
Γ, J ` J Γ`J Γ, K ` J
(3.11b)
Γ ` K Γ, K ` J Γ`J
(3.11c)
These rules ensure that formal derivability behaves like a hypothetical judgement. By a slight abuse of notation we write Γ `R J to indicate that the Γ ` J is derivable from rules R. The principal of hypothetical rule induction is just the principal of rule induction applied to the formal hypothetical judgement. So to show that P (Γ ` J ) whenever Γ `R J, it is enough to show that P is closed under both the rules of R and under the structural rules. Thus, for each rule of the form (3.10), whether structural or in R, we must show that if P (Γ Γ1 ` J1 ) and . . . and P (Γ Γn ` Jn ), then P (Γ ` J ). This is just a restatement of the principle of rule induction given in Chapter 2, specialized to the formal derivability judgement Γ ` J. In practice we usually dispense with the structural rules by the method described in Section 3.1.2 on page 27. By proving that the structural rules are admissible any proof by rule induction may restrict attention to the rules in R alone. If all of the rules of a hypothetical inductive definition are uniform, the structural rules (3.11b) and (3.11c) are readily seen to be admissible. However, it is typically necessary to include Rule (3.11a) explicitly to ensure reflexivity. V ERSION 1.19
D RAFT
R EVISED 10.03.2011
3.3 General Judgements
3.3 3.3.1
31
General Judgements Generic Derivability
The generic derivability judgement ~x | Γ `X R J states that for every fresh ,~x 0 renaming π : ~x ↔ ~x 0 , the judgement π · Γ `X π · J holds. The renaming R ensures that the variables serve only as placeholders; the meaning of the judgement is independent of how the variables are chosen. Evidence for the judgement ~x | Γ `X R J consists of a generic derivation, ∇~x , such that for every fresh renaming π : ~x ↔ ~x 0 , the derivation ∇~x0 is evidence for ,~x 0 π · Γ `X π · J. The renaming ensures that the meaning of the generic R derivability judgement does not depend on the choice of variable names. For example, the derivation ∇ x given by x nat succ(x) nat succ(succ(x)) nat is evidence for the generic judgement X x | x nat `(2.2) succ(succ(x)) nat.
The generic derivability judgement enjoys the following structural properties: Proliferation If ~x | Γ `X x, x | Γ `X R J, then ~ R J. 0 Renaming If ~x, x | Γ `X x, x 0 | [ x ↔ x 0 ] · Γ `X R J, then ~ R [ x ↔ x ] · J for any x0 ∈ / X , ~x.
Substitution If ~x, x | Γ `X x ], then ~x | [ a/x ]Γ `X R J and a ∈ B[X , ~ R [ a/x ] J. Proliferation is guaranteed by the interpretation of rule schemes as ranging over all expansions of the universe. Renaming is built into the meaning of the generic judgement. Substitution holds as long as the rules themselves are closed under substitution. This need not be the case, but in practice this requirement is usually met.
3.3.2
Parametric Derivability
U ;X The parametric derivability judgement ~u k ~x | Γ `R J states that the generic judgement holds uniformly for all choices of parameters ~u. That is, for all
R EVISED 10.03.2011
D RAFT
V ERSION 1.19
32
3.4 Generic Inductive Definitions 0
π : ~u ↔ ~u0 such that ~u0 ∩ U = ∅, the generic judgement ~x | π · Γ `UR,~u ;X π · J is derivable. The parametric judgement satisfies the following structural properties: U ;X U ;X Proliferation If ~u k ~x | Γ `R J, then ~u, u k ~x | Γ `R J. U ;X U ;X Renaming If ~u k ~x | Γ `R J and π : ~u ↔ ~u0 , then ~u0 k ~x | π · Γ `R π · J.
Proliferation states that parametric derivability is sensitive only to the presence, but not the absence, of parameters. Renaming states that parametric derivability is independent of the choice of parameters. (There is no analogue of the structural property of substitution for parameters.)
3.4
Generic Inductive Definitions
A generic inductive definition admits generic hypothetical judgements in the premises of rules, with the effect of augmenting the variables, as well as the rules, within those premises. A generic rule has the form
~x ~x1 | Γ Γ1 ` J1 . . . ~x ~xn | Γ Γn ` Jn . ~x | Γ ` J
(3.12)
The variables ~x are the global variables of the inference, and, for each 1 ≤ i ≤ n, the variables ~xi are the local variables of the ith premise. In most cases a rule is stated for all choices of global variables and global hypotheses. Such rules may be given in implicit form,
~x1 | Γ1 ` J1
... J
~xn | Γn ` Jn
.
(3.13)
A generic inductive definition is just an ordinary inductive definition of a family of formal generic judgements of the form ~x | Γ ` J. Formal generic judgements are identified up to renaming of variables, so that the latter judgement is treated as identical to the judgement ~x 0 | π · Γ ` π · J for any renaming π : ~x ↔ ~x 0 . If R is a collection of generic rules, we write ~x | Γ `R J to mean that the formal generic judgement ~x | Γ ` J is derivable from rules R. When specialized to a collection of generic rules, the principle of rule induction states that to show P (~x | Γ ` J ) whenever ~x | Γ `R J, it is enough to show that P is closed under the rules R. Specifically, for each rule in R of the form (3.12), we must show that if P (~x ~x1 | Γ Γ1 ` J1 ) . . . P (~x ~xn | Γ Γn ` Jn ) then P (~x | Γ ` J ). V ERSION 1.19
D RAFT
R EVISED 10.03.2011
3.4 Generic Inductive Definitions
33
By the identification convention (stated in Chapter 1) the property P must respect renamings of the variables in a formal generic judgement. To ensure that the formal generic judgement behaves like a generic judgement, we must always ensure that the following structural rules are admissible:
~x | Γ, J ` J
(3.14a)
~x | Γ ` J ~x | Γ, J 0 ` J
(3.14b)
~x | Γ ` J ~x, x | Γ ` J
(3.14c)
~x, x 0 | [ x ↔ x 0 ] · Γ ` [ x ↔ x 0 ] · J ~x, x | Γ ` J
(3.14d)
~x | Γ ` J ~x | Γ, J ` J 0 ~x | Γ ` J 0
(3.14e)
~x, x | Γ ` J a ∈ B[~x ] ~x | [ a/x ]Γ ` [ a/x ] J
(3.14f)
The admissibility of Rule (3.14a) is, in practice, ensured by explicitly including it. The admissibility of Rules (3.14b) and (3.14c) is assured if each of the generic rules is uniform, since we may assimilate the additional parameter, x, to the global parameters, and the additional hypothesis, J, to the global hypotheses. The admissibility of Rule (3.14d) is ensured by the identification convention for the formal generic judgement. Rule (3.14f) must be verified explicitly for each inductive definition. The concept of a generic inductive definition extends to parametric judgements as well. Briefly, rules are defined on formal parametric judgements of the form ~u k ~x | Γ ` J, with parameters ~u, as well as variables, ~x. Such formal judgements are identified up to renaming of both its variables and its parameters to ensure that the meaning is independent of the choice of names. Usually we segregate the hypotheses into two zones, written ~u k ~x | Σ Γ ` J, where Σ governs the parameters, ~u, and Γ governs the variables, ~x. Once separated into zones, it is natural to write this judgement in the form ~x | Γ `~ukΣ J, or even just Γ `Σ J, to reduce notational clutter. R EVISED 10.03.2011
D RAFT
V ERSION 1.19
34
3.5
3.5 Notes
Notes
The concepts of entailment and generality are fundamental to logic and ¨ programming languages. The formulation given here builds on Martin-Lof (1983, 1987) and Avron (1991). Hypothetical and general reasoning are consolidated into a single concept in the AUTOMATH languages (Nederpelt et al., 1994) and in the LF Logical Framework (Harper et al., 1993). These systems permit arbitrarily nested combinations of hypothetical and general judgements, whereas the present account considers only general hypothetical judgements over basic judgement forms.
V ERSION 1.19
D RAFT
R EVISED 10.03.2011
Part II
Levels of Syntax
Chapter 4
Concrete Syntax The concrete syntax of a language is a means of representing expressions as strings that may be written on a page or entered using a keyboard. The concrete syntax usually is designed to enhance readability and to eliminate ambiguity. While there are good methods for eliminating ambiguity, improving readability is, to a large extent, a matter of taste. In this chapter we introduce the main methods for specifying concrete syntax, using as an example an illustrative expression language, called L{num str}, that supports elementary arithmetic on the natural numbers and simple computations on strings. In addition, L{num str} includes a construct for binding the value of an expression to a variable within a specified scope.
4.1
Lexical Structure
The first phase of syntactic processing is to convert from a character-based representation to a symbol-based representation of the input. This is called lexical analysis, or lexing. The main idea is to aggregate characters into symbols that serve as tokens for subsequent phases of analysis. For example, the numeral 467 is written as a sequence of three consecutive characters, one for each digit, but is regarded as a single token, namely the number 467. Similarly, an identifier such as temp comprises four letters, but is treated as a single symbol representing the entire word. Moreover, many characterbased representations include empty “white space” (spaces, tabs, newlines, and, perhaps, comments) that are discarded by the lexical analyzer.1 1 In
some languages white space is significant, in which case it must be converted to symbolic form for subsequent processing.
38
4.1 Lexical Structure
The lexical structure of a language is usually described using regular expressions. For example, the lexical structure of L{num str} may be specified as follows: Item Keyword Identifier Numeral Literal Special Letter Digit Quote
itm kwd id num lit spl ltr dig qum
::= ::= ::= ::= ::= ::= ::= ::= ::=
kwd | id | num | lit | spl l·e·t·e | b·e·e | i·n·e ltr (ltr | dig)∗ dig dig∗ qum (ltr | dig)∗ qum +|*| ˆ |(|)|| a | b | ... 0 | 1 | ... "
A lexical item is either a keyword, an identifier, a numeral, a string literal, or a special symbol. There are three keywords, specified as sequences of characters, for emphasis. Identifiers start with a letter and may involve subsequent letters or digits. Numerals are non-empty sequences of digits. String literals are sequences of letters or digits surrounded by quotes. The special symbols, letters, digits, and quote marks are as enumerated. (Observe that we tacitly identify a character with the unit-length string consisting of that character.) The job of the lexical analyzer is to translate character strings into token strings using the above definitions as a guide. An input string is scanned, ignoring white space, and translating lexical items into tokens, which are specified by the following rules: s str ID[s] tok n nat NUM[n] tok s str LIT[s] tok
V ERSION 1.19
(4.1a) (4.1b) (4.1c)
LET tok
(4.1d)
BE tok
(4.1e)
IN tok
(4.1f)
ADD tok
(4.1g)
MUL tok
(4.1h)
CAT tok
(4.1i)
D RAFT
R EVISED 10.03.2011
4.1 Lexical Structure
39
LP tok
(4.1j)
RP tok
(4.1k)
VB tok
(4.1l)
Rule (4.1a) admits any string as an identifier, even though only certain strings will be treated as identifiers by the lexical analyzer. Lexical analysis is inductively defined by the following judgement forms: s charstr ←→ t tokstr
Scan input
s itm ←→ t tok
Scan an item
s kwd ←→ t tok
Scan a keyword
s id ←→ t tok
Scan an identifier
s num ←→ t tok
Scan a number
s spl ←→ t tok
Scan a symbol
s lit ←→ t tok
Scan a string literal
The definition of these forms, which follows, makes use of several auxiliary judgements corresponding to the classifications of characters in the lexical structure of the language. For example, s whs states that the string s consists only of “white space”, s lord states that s is either an alphabetic letter or a digit, and s non-lord states that s does not begin with a letter or digit, and so forth. (4.2a) e charstr ←→ e tokstr s = s1 ˆ s2 ˆ s3 str
s1 whs s2 itm ←→ t tok s3 charstr ←→ ts tokstr s charstr ←→ t · ts tokstr (4.2b) s kwd ←→ t tok (4.2c) s itm ←→ t tok s id ←→ t tok s itm ←→ t tok
(4.2d)
s num ←→ t tok s itm ←→ t tok
(4.2e)
s lit ←→ t tok s itm ←→ t tok
(4.2f)
s spl ←→ t tok s itm ←→ t tok s = l · e · t · e str s kwd ←→ LET tok R EVISED 10.03.2011
D RAFT
(4.2g) (4.2h) V ERSION 1.19
40
4.1 Lexical Structure
s = b · e · e str (4.2i) s kwd ←→ BE tok s = i · n · e str (4.2j) s kwd ←→ IN tok s = a · s0 str a ltr s0 lds (4.2k) s id ←→ ID[s] tok s = s1 ˆ s2 str s1 dig s2 dgs s num ←→ n nat (4.2l) s num ←→ NUM[n] tok s = s1 ˆ s2 ˆ s3 str s1 qum s2 lord s3 qum (4.2m) s lit ←→ LIT[s2 ] tok s = + · e str (4.2n) s spl ←→ ADD tok s = * · e str (4.2o) s spl ←→ MUL tok s = ˆ · e str (4.2p) s spl ←→ CAT tok s = ( · e str (4.2q) s spl ←→ LP tok s = ) · e str (4.2r) s spl ←→ RP tok s = | · e str (4.2s) s spl ←→ VB tok Rules (4.2) do not specify a deterministic algorithm. Rather, Rule (4.2b) applies whenever the input string may be partitioned into three parts, consisting of white space, a lexical item, and the rest of the input. However, the associativity of string concatenation implies that the partititioning is not unique. For example, the string insert may be partitioned as in ˆ sert or insert ˆ e, and hence tokenized as either IN followed by ID[sert], or as ID[insert] (or, indeed, as two consecutive identifiers in several ways). One solution to this problem is to impose some extrinsic control criteria on the rules to ensure that they have a unique interpretation. For example, one may insist that Rule (4.2b) apply only when the string s2 is chosen to be as long as possible so as to ensure that the string insert is analyzed as the identifier ID[insert], rather than as two consecutive identifiers, say ID[ins] and ID[ert]. Moreover, we may impose an ordering on the rules, so that Rule (4.2j) takes priority over Rule (4.2k) to avoid interpreting in as an identifier, rather than as a keyword. Another solution is to reformulate the rules so that they are deterministic, a technique that will be used in the next section to resolve a similar ambiguity at the level of the concrete syntax. V ERSION 1.19
D RAFT
R EVISED 10.03.2011
4.2 Context-Free Grammars
4.2
41
Context-Free Grammars
The standard method for defining concrete syntax is by giving a context-free grammar for the language. A grammar consists of three components: 1. The tokens, or terminals, over which the grammar is defined. 2. The syntactic classes, or non-terminals, which are disjoint from the terminals. 3. The rules, or productions, which have the form A ::= α, where A is a non-terminal and α is a string of terminals and non-terminals. Each syntactic class is a collection of token strings. The rules determine which strings belong to which syntactic classes. When defining a grammar, we often abbreviate a set of productions, A ::= α1 .. . A ::= αn , each with the same left-hand side, by the compound production A ::= α1 | . . . | αn , which specifies a set of alternatives for the syntactic class A. A context-free grammar determines a simultaneous inductive definition of its syntactic classes. Specifically, we regard each non-terminal, A, as a judgement form, s A, over strings of terminals. To each production of the form A ::= s1 A1 s2 . . . sn An sn+1 we associate an inference rule s10 A1 . . . s0n An . s1 s10 s2 . . . sn s0n sn+1 A
(4.3)
The collection of all such rules constitutes an inductive definition of the syntactic classes of the grammar. Recalling that juxtaposition of strings is short-hand for their concatenation, we may re-write the preceding rule as follows: s10 A1
...
R EVISED 10.03.2011
s0n An
s = s1 ˆ s10 ˆ s2 ˆ . . . sn ˆ s0n ˆ sn+1 . sA D RAFT
(4.4)
V ERSION 1.19
42
4.3 Grammatical Structure
This formulation makes clear that s A holds whenever s can be partitioned as described so that si0 A for each 1 ≤ i ≤ n. Since string concatenation is associative, the decomposition is not unique, and so there may be many different ways in which the rule applies.
4.3
Grammatical Structure
The concrete syntax of L{num str} may be specified by a context-free grammar over the tokens defined in Section 4.1 on page 37. The grammar has only one syntactic class, exp, which is defined by the following compound production: Expression
Number String Identifier
exp ::= num | lit | id | LP exp RP | exp ADD exp | exp MUL exp | exp CAT exp | VB exp VB | LET id BE exp IN exp num ::= NUM[n] (n nat) :: lit = LIT[s] (s str) id ::= ID[s] (s str)
This grammar makes use of some standard notational conventions to improve readability: we identify a token with the corresponding unit-length string, and we use juxtaposition to denote string concatenation. Applying the interpretation of a grammar as an inductive definition, we obtain the following rules:
V ERSION 1.19
s num s exp
(4.5a)
s lit s exp
(4.5b)
s id s exp s1 exp s2 exp s1 ADD s2 exp s1 exp s2 exp s1 MUL s2 exp s1 exp s2 exp s1 CAT s2 exp s exp VB s VB exp s exp LP s RP exp
(4.5c)
D RAFT
(4.5d) (4.5e) (4.5f) (4.5g) (4.5h) R EVISED 10.03.2011
4.4 Ambiguity
43
s1 id s2 exp s3 exp (4.5i) LET s1 BE s2 IN s3 exp n nat (4.5j) NUM[n] num s str (4.5k) LIT[s] lit s str (4.5l) ID[s] id To emphasize the role of string concatentation, we may rewrite Rule (4.5e), for example, as follows: s = s1 MUL s2 str s1 exp s exp
s2 exp .
(4.6)
That is, s exp is derivable if s is the concatentation of s1 , the multiplication sign, and s2 , where s1 exp and s2 exp.
4.4
Ambiguity
Apart from subjective matters of readability, a principal goal of concrete syntax design is to avoid ambiguity. The grammar of arithmetic expressions given above is ambiguous in the sense that some token strings may be thought of as arising in several different ways. More precisely, there are token strings s for which there is more than one derivation ending with s exp according to Rules (4.5). For example, consider the character string 1+2*3, which, after lexical analysis, is translated to the token string NUM[1] ADD NUM[2] MUL NUM[3]. Since string concatenation is associative, this token string can be thought of as arising in several ways, including NUM[1] ADD ∧ NUM[2] MUL NUM[3] and NUM[1] ADD NUM[2]∧ MUL NUM[3], where the caret indicates the concatenation point. One consequence of this observation is that the same token string may be seen to be grammatical according to the rules given in Section 4.3 on the facing page in two different ways. According to the first reading, the R EVISED 10.03.2011
D RAFT
V ERSION 1.19
44
4.4 Ambiguity
expression is principally an addition, with the first argument being a number, and the second being a multiplication of two numbers. According to the second reading, the expression is principally a multiplication, with the first argument being the addition of two numbers, and the second being a number. Ambiguity is a purely syntactic property of grammars; it has nothing to do with the “meaning” of a string. For example, the token string NUM[1] ADD NUM[2] ADD NUM[3], also admits two readings. It is immaterial that both readings have the same meaning under the usual interpretation of arithmetic expressions. Moreover, nothing prevents us from interpreting the token ADD to mean “division,” in which case the two readings would hardly coincide! Nothing in the syntax itself precludes this interpretation, so we do not regard it as relevant to whether the grammar is ambiguous. To avoid ambiguity the grammar of L{num str} given in Section 4.3 on page 42 must be re-structured to ensure that every grammatical string has at most one derivation according to the rules of the grammar. The main method for achieving this is to introduce precedence and associativity conventions that ensure there is only one reading of any token string. Parenthesization may be used to override these conventions, so there is no fundamental loss of expressive power in doing so. Precedence relationships are introduced by layering the grammar, which is achieved by splitting syntactic classes into several subclasses. Factor Term Expression Program
fct trm exp prg
::= ::= ::= ::=
num | lit | id | LP prg RP fct | fct MUL trm | VB fct VB trm | trm ADD exp | trm CAT exp exp | LET id BE exp IN prg
The effect of this grammar is to ensure that let has the lowest precedence, addition and concatenation intermediate precedence, and multiplication and length the highest precedence. Moreover, all forms are right-associative. Other choices of rules are possible, according to taste; this grammar illustrates one way to resolve the ambiguities of the original expression grammar. V ERSION 1.19
D RAFT
R EVISED 10.03.2011
4.5 Notes
4.5
45
Notes
The literature on parsing is extensive. Standard compiler textbooks, such as Aho et al. (2007), provide a thorough discussion of parsing programming languages. The present treatment provides a glimpse of what is involved, and provides good examples of inductive definitions.
R EVISED 10.03.2011
D RAFT
V ERSION 1.19
46
V ERSION 1.19
4.5 Notes
D RAFT
R EVISED 10.03.2011
Chapter 5
Abstract Syntax The concrete syntax of a language is concerned with the linear representation of the phrases of a language as strings of symbols—the form in which we write them on paper, type them into a computer, and read them from a page. But languages are also the subjects of study, as well as the instruments of expression. As such the concrete syntax of a language is just a nuisance. When analyzing a language mathematically we are only interested in the deep structure of its phrases, not their surface representation. The abstract syntax of a language exposes the hierarchical and binding structure of the language. Parsing is the process of translation from concrete to abstract syntax. It consists of analyzing the linear representation of a phrase in terms of the grammar of the language and transforming it into an abstract syntax tree or an abstract binding tree that reveals the deep structure of the phrase. Formatting is the inverse process of generating a linear representation of a given piece of abstract syntax.
5.1
Hierarchical and Binding Structure
For the purposes of analysis the most important elements of the syntax of a language are its hierarchical and binding structure. Ignoring binding and scope, the hierarchical structure of a language may be expressed using abstract syntax trees. Accounting for these requires the additional structure of abstract binding trees. We will define both an ast and an abt representation of L{num str} in order to compare the two and show how they relate to the concrete syntax described in Chapter 4. The purely hierarchical abstract syntax of L{num str} is generated by
48
5.1 Hierarchical and Binding Structure
the following operators and their arities: num[n] str[s] id[s] times plus len cat let[s]
() () () (Exp, Exp) (Exp, Exp) (Exp) (Exp, Exp) (Exp, Exp)
(n nat) (s str) (s str)
(s str)
There is one sort, Exp, generated by the above operators. For each n nat there is an operator num[n] of arity () representing the number n. Similarly, for each s str there is an operator str[s] of arity (), representing a string literal. There are several operators corresponding to functions on numbers and strings. Most importantly, there are two operators related to identifiers. The first, id[s], where s str, represents the identifier with name s thought of as an operator of arity (). The second, let[s], is a family of operators indexed by s str with two arguments, the binding of the identifier id[s] and the scope of that binding. These characterizations, however, are purely informal in that there is nothing in the “plain” abstract syntax of the language that supports these interpretations. In particular, there is no connection between any occurrences of id[s] and any occurrence of let[s] within an expression. To account for the binding and scope of identifiers requires the greater expressive power of abstract binding trees. An abt representation of L{num str} is defined by the following operators and their arities: num[n] str[s] times plus len cat let
() () (Exp, Exp) (Exp, Exp) (Exp) (Exp, Exp) (Exp, (Exp)Exp)
(n nat) (s str)
There is no longer an operator id[s]; we instead use a variable to refer to a binding site. Correspondingly, the family of operators let[s] is repalced replaced by a single operator, let, of arity (Exp, (Exp)Exp), which binds a variable in its second argument. V ERSION 1.19
D RAFT
R EVISED 10.03.2011
5.2 Parsing Into Abstract Syntax Trees
49
To illustrate the relationship between these two representations of the abstract syntax of L{num str}, we will first describe the translation from the concrete syntax, given in Chapter 4, to an abstract syntax tree. We will then alter this translation to account for binding and scope, yielding an abstract binding tree.
5.2
Parsing Into Abstract Syntax Trees
We will simultaneously define parsing and formatting as a binary judgement relating the concrete to the abstract syntax. This judgement will have the mode (∀, ∃≤1 ), which states that the parser is a partial function of its input, being undefined for ungrammatical token strings, but otherwise uniquely determining the abstract syntax tree representation of each wellformed input. It will also have the mode (∃, ∀), which states that each piece of abstract syntax has a (not necessarily unique) representation as a token string in the concrete syntax. The parsing judgements for L{num str} follow the unambiguous grammar given in Chapter 4: s prg ←→ e expr
Parse/format as a program
s exp ←→ e expr
Parse/format as an expression
s trm ←→ e expr
Parse/format as a term
s fct ←→ e expr
Parse/format as a factor
s num ←→ e expr
Parse/format as a number
s lit ←→ e expr
Parse/format as a literal
s id ←→ e expr
Parse/format as an identifier
These judgements relate a token string, s, to an expression, e, viewed as an abstract syntax tree. These judgements are inductively defined simultaneously by the following rules: n nat (5.1a) NUM[n] num ←→ num[n] expr s str (5.1b) LIT[s] lit ←→ str[s] expr s str (5.1c) ID[s] id ←→ id[s] expr s num ←→ e expr (5.1d) s fct ←→ e expr R EVISED 10.03.2011
D RAFT
V ERSION 1.19
50
5.2 Parsing Into Abstract Syntax Trees s lit ←→ e expr s fct ←→ e expr
(5.1e)
s id ←→ e expr s fct ←→ e expr s prg ←→ e expr LP s RP fct ←→ e expr
(5.1f) (5.1g)
s fct ←→ e expr s trm ←→ e expr
(5.1h)
s1 fct ←→ e1 expr s2 trm ←→ e2 expr s1 MUL s2 trm ←→ times(e1 ; e2 ) expr
(5.1i)
s fct ←→ e expr VB s VB trm ←→ len(e) expr s trm ←→ e expr s exp ←→ e expr s1 trm ←→ e1 expr s2 exp ←→ e2 expr s1 ADD s2 exp ←→ plus(e1 ; e2 ) expr s1 trm ←→ e1 expr s2 exp ←→ e2 expr s1 CAT s2 exp ←→ cat(e1 ; e2 ) expr s exp ←→ e expr s prg ←→ e expr s1 id ←→ id[s] expr s2 exp ←→ e2 expr s3 prg ←→ e3 expr LET s1 BE s2 IN s3 prg ←→ let[s](e2 ; e3 ) expr
(5.1j) (5.1k) (5.1l) (5.1m) (5.1n) (5.1o)
A successful parse implies that the token string must have been derived according to the rules of the unambiguous grammar and that the result is a well-formed abstract syntax tree. Theorem 5.1. If s prg ←→ e expr, then s prg and e expr, and similarly for the other parsing judgements. Proof. By a straightforward induction on Rules (5.1). Moreover, if a string is generated according to the rules of the grammar, then it has a parse as an ast. Theorem 5.2. If s prg, then there is a unique e such that s prg ←→ e expr, and similarly for the other parsing judgements. That is, the parsing judgements have mode (∀, ∃!) over well-formed strings and abstract syntax trees. Proof. By rule induction on the rules determined by reading Grammar (4.4) as an inductive definition. V ERSION 1.19
D RAFT
R EVISED 10.03.2011
5.3 Parsing Into Abstract Binding Trees
51
Finally, any piece of abstract syntax may be formatted as a string that parses as the given ast. Theorem 5.3. If e expr, then there exists a (not necessarily unique) string s such that s prg and s prg ←→ e expr. That is, the parsing judgement has mode (∃, ∀). Proof. By rule induction on Grammar (4.4). The string representation of an abstract syntax tree is not unique, since we may introduce parentheses at will around any sub-expression.
5.3
Parsing Into Abstract Binding Trees
In this section we revise the parser given in Section 5.2 on page 49 to translate from token strings to abstract binding trees to make explicit the binding and scope of identifiers in a program. The revised parsing judgement, s prg ←→ e expr, between strings s and abt’s e, is defined by a collection of rules similar to those given in Section 5.2 on page 49. These rules take the form of a generic inductive definition (see Chapter 3) in which the premises and conclusions of the rules involve hypothetical judgments of the form ID[s1 ] id ←→ x1 expr, . . . , ID[sn ] id ←→ xn expr ` s prg ←→ e expr, where the xi ’s are pairwise distinct variable names. The hypotheses of the judgement dictate how identifiers are to be parsed as variables, for it follows from the reflexivity of the hypothetical judgement that Γ, ID[s] id ←→ x expr ` ID[s] id ←→ x expr. To maintain the association between identifiers and variables when parsing a let expression, we update the hypotheses to record the association between the bound identifier and a corresponding variable: Γ ` s1 id ←→ x expr
Γ ` s2 exp ←→ e2 expr
Γ, s1 id ←→ x expr ` s3 prg ←→ e3 expr Γ ` LET s1 BE s2 IN s3 prg ←→ let(e2 ; x.e3 ) expr
(5.2a)
Unfortunately, this approach does not quite work properly! If an inner let expression binds the same identifier as an outer let expression, there is an ambiguity in how to parse occurrences of that identifier. Parsing such nested let’s will introduce two hypotheses, say ID[s] id ←→ x1 expr and R EVISED 10.03.2011
D RAFT
V ERSION 1.19
52
5.3 Parsing Into Abstract Binding Trees
ID[s] id ←→ x2 expr, for the same identifier ID[s]. By the structural property of exchange, we may choose arbitrarily which to apply to any particular occurrence of ID[s], and hence we may parse different occurrences differently. To rectify this we resort to less elegant methods. Rather than use hypotheses, we instead maintain an explicit symbol table to record the association between identifiers and variables. We must define explicitly the procedures for creating and extending symbol tables, and for looking up an identifier in the symbol table to determine its associated variable. This gives us the freedom to implement a shadowing policy for re-used identifiers, according to which the most recent binding of an identifier determines the corresponding variable. The main change to the parsing judgement is that the hypothetical judgement Γ ` s prg ←→ e expr is reduced to the basic judgement s prg ←→ e expr [S], where S is a symbol table. (Analogous changes must be made to the other parsing judgements.) The symbol table is now an argument to the judgement form, rather than an implicit mechanism for performing inference under hypotheses. The rule for parsing let expressions is then formulated as follows: s1 id ←→ x [S] 0
S = S [ s1 7 → x ]
s2 exp ←→ e2 expr [S] s3 prg ←→ e3 expr [S0 ]
(5.3)
LET s1 BE s2 IN s3 prg ←→ let(e2 ; x.e3 ) expr [S] This rule is quite similar to the hypothetical form, the difference being that we must manage the symbol table explicitly. In particular, we must include a rule for parsing identifiers, rather than relying on the reflexivity of the hypothetical judgement to do it for us. S(ID[s]) = x ID[s] id ←→ x [S]
(5.4)
The premise of this rule states that S maps the identifier ID[s] to the variable x. Symbol tables may be defined to be finite sequences of ordered pairs of the form (ID[s], x ), where ID[s] is an identifier and x is a variable V ERSION 1.19
D RAFT
R EVISED 10.03.2011
5.4 Notes
53
name. Using this representation it is straightforward to define the following judgement forms: S symtab
well-formed symbol table
S = S[ID[s] 7→ x ]
add new association
S(ID[s]) = x
lookup identifier
0
It is a straightforward, but unenlightening, exercise to give precise definitions of these judgements by a collection of rules.
5.4
Notes
The theory of translation from concrete syntax to abstract syntax trees is discussed in most compiler textbooks such as Aho et al. (2007). The translation to abstract binding trees discussed here extends this to account for the scopes of identifiers. This, too, is discussed in most texts, but in a different conceptual framework. The unified presentation of parsing and formatting was adapted from course materials prepared by Frank Pfenning.
R EVISED 10.03.2011
D RAFT
V ERSION 1.19
54
V ERSION 1.19
5.4 Notes
D RAFT
R EVISED 10.03.2011
Part III
Statics and Dynamics
Chapter 6
Statics Most programming languages exhibit a phase distinction between the static and dynamic phases of processing. The static phase consists of parsing and type checking to ensure that the program is well-formed; the dynamic phase consists of execution of well-formed programs. A language is said to be safe exactly when well-formed programs are well-behaved when executed. The static phase is specified by a statics comprising a collection of rules for deriving typing judgements stating that an expression is well-formed of a certain type. Types mediate the interaction between the constituent parts of a program by “predicting” some aspects of the execution behavior of the parts so that we may ensure they fit together properly at run-time. Type safety tells us that these predictions are accurate; if not, the statics is considered to be improperly defined, and the language is deemed unsafe for execution. In this chapter we present the statics of the language L{num str} as an illustration of the methodology that we shall employ throughout this book.
6.1
Syntax
When defining a language we shall be primarily concerned with its abstract syntax, specified by a collection of operators and their arities. The abstract syntax provides a systematic, unambiguous account of the hierarchical and binding structure of the language, and is therefore to be considered the official presentation of the language. However, for the sake of clarity, it is also useful to specify minimal concrete syntax conventions, without going through the trouble to set up a fully precise grammar for it.
58
6.2 Type System
We will accomplish both of these purposes with a syntax chart, whose meaning is best illustrated by example. The following chart summarizes the abstract and concrete syntax of L{num str}, which was analyzed in detail in Chapters 4 and 5. Typ τ ::= Exp e
::=
num str x num[n] str[s] plus(e1 ; e2 ) times(e1 ; e2 ) cat(e1 ; e2 ) len(e) let(e1 ; x.e2 )
num str x n ”s” e1 + e2 e1 ∗ e2 e1 ^ e2 |e| let x be e1 in e2
numbers strings variable numeral literal addition multiplication concatenation length definition
This chart defines two sorts, Typ, ranged over by τ, and Exp, ranged over by e. The chart defines a number of operators and their arities. For example, the operator let has arity (Exp, (Exp)Exp), which specifies that it has two arguments of sort Exp, and binds a variable of sort Exp in the second argument.
6.2
Type System
The role of a type system is to impose constraints on the formations of phrases that are sensitive to the context in which they occur. For example, whether or not the expression plus(x; num[n]) is sensible depends on whether or not the variable x is declared to have type num in the surrounding context of the expression. This example is, in fact, illustrative of the general case, in that the only information required about the context of an expression is the type of the variables within whose scope the expression lies. Consequently, the statics of L{num str} consists of an inductive definition of generic hypothetical judgements of the form
~x | Γ ` e : τ, where ~x is a finite set of variables, and Γ is a typing context consisting of hypotheses of the form x : τ, one for each x ∈ X . We rely on typographical conventions to determine the set of variables, using the letters x and y for variables that serve as parameters of the typing judgement. We write x ∈ / V ERSION 1.19
D RAFT
R EVISED 10.03.2011
6.2 Type System
59
dom(Γ) to indicate that there is no assumption in Γ of the form x : τ for any type τ, in which case we say that the variable x is fresh for Γ. The rules defining the statics of L{num str} are as follows: Γ, x : τ ` x : τ
(6.1a)
Γ ` str[s] : str
(6.1b)
(6.1c) Γ ` num[n] : num Γ ` e1 : num Γ ` e2 : num (6.1d) Γ ` plus(e1 ; e2 ) : num Γ ` e1 : num Γ ` e2 : num (6.1e) Γ ` times(e1 ; e2 ) : num Γ ` e1 : str Γ ` e2 : str (6.1f) Γ ` cat(e1 ; e2 ) : str Γ ` e : str (6.1g) Γ ` len(e) : num Γ ` e1 : τ1 Γ, x : τ1 ` e2 : τ2 (6.1h) Γ ` let(e1 ; x.e2 ) : τ2 In Rule (6.1h) we tacitly assume that the variable, x, is not already declared in Γ. This condition may always be met by choosing a suitable representative of the α-equivalence class of the let expression. It is easy to check that every expression has at most one type. Lemma 6.1 (Unicity of Typing). For every typing context Γ and expression e, there exists at most one τ such that Γ ` e : τ. Proof. By rule induction on Rules (6.1). The typing rules are syntax-directed in the sense that there is exactly one rule for each form of expression. Consequently it is easy to give necessary conditions for typing an expression that invert the sufficient conditions expressed by the corresponding typing rule. Lemma 6.2 (Inversion for Typing). Suppose that Γ ` e : τ. If e = plus(e1 ; e2 ), then τ = num, Γ ` e1 : num, and Γ ` e2 : num, and similarly for the other constructs of the language. Proof. These may all be proved by induction on the derivation of the typing judgement Γ ` e : τ. In richer languages such inversion principles are more difficult to state and to prove. R EVISED 10.03.2011
D RAFT
V ERSION 1.19
60
6.3 Structural Properties
6.3
Structural Properties
The statics enjoys the structural properties of the generic hypothetical judgement. Lemma 6.3 (Weakening). If Γ ` e0 : τ 0 , then Γ, x : τ ` e0 : τ 0 for any x ∈ / dom(Γ) and any type τ. Proof. By induction on the derivation of Γ ` e0 : τ 0 . We will give one case here, for rule (6.1h). We have that e0 = let(e1 ; z.e2 ), where by the conventions on parameters we may assume z is chosen such that z ∈ / dom(Γ) and z 6= x. By induction we have 1. Γ, x : τ ` e1 : τ1 , 2. Γ, x : τ, z : τ1 ` e2 : τ 0 , from which the result follows by Rule (6.1h). Lemma 6.4 (Substitution). If Γ, x : τ ` e0 : τ 0 and Γ ` e : τ, then Γ ` [e/x ]e0 : τ0. Proof. By induction on the derivation of Γ, x : τ ` e0 : τ 0 . We again consider only rule (6.1h). As in the preceding case, e0 = let(e1 ; z.e2 ), where z may be chosen so that z 6= x and z ∈ / dom(Γ). We have by induction and Lemma 6.3 that 1. Γ ` [e/x ]e1 : τ1 , 2. Γ, z : τ1 ` [e/x ]e2 : τ 0 . By the choice of z we have
[e/x ]let(e1 ; z.e2 ) = let([e/x ]e1 ; z.[e/x ]e2 ). It follows by Rule (6.1h) that Γ ` [e/x ]let(e1 ; z.e2 ) : τ, as desired. From a programming point of view, Lemma 6.3 allows us to use an expression in any context that binds its free variables: if e is well-typed in a context Γ, then we may “import” it into any context that includes the assumptions Γ. In other words the introduction of new variables beyond those required by an expression, e, does not invalidate e itself; it remains V ERSION 1.19
D RAFT
R EVISED 10.03.2011
6.3 Structural Properties
61
well-formed, with the same type.1 More significantly, Lemma 6.4 on the facing page expresses the concepts of modularity and linking. We may think of the expressions e and e0 as two components of a larger system in which the component e0 is to be thought of as a client of the implementation e. The client declares a variable specifying the type of the implementation, and is type checked knowing only this information. The implementation must be of the specified type in order to satisfy the assumptions of the client. If so, then we may link them to form the composite system, [e/x ]e0 . This may itself be the client of another component, represented by a variable, y, that is replaced by that component during linking. When all such variables have been implemented, the result is a closed expression that is ready for execution (evaluation). The converse of Lemma 6.4 on the preceding page is called decomposition. It states that any (large) expression may be decomposed into a client and implementor by introducing a variable to mediate their interaction. Lemma 6.5 (Decomposition). If Γ ` [e/x ]e0 : τ 0 , then for every type τ such that Γ ` e : τ, we have Γ, x : τ ` e0 : τ 0 . Proof. The typing of [e/x ]e0 depends only on the type of e wherever it occurs, if at all. This lemma tells us that any sub-expression may be isolated as a separate module of a larger system. This is especially useful when the variable x occurs more than once in e0 , because then one copy of e suffices for all occurrences of x in e0 . The statics of L{num str} given by Rules (6.1) exemplifies a recurrent pattern. The constructs of a language are classified into one of two forms, the introductory and the eliminatory. The introductory forms for a type determine the values, or canonical forms, of that type. The eliminatory forms determine how to manipulate the values of a type to form a computation of another (possibly the same) type. In L{num str} the introductory forms for the type num are the numerals, and those for the type str are the literals. The eliminatory forms for the type num are addition and multiplication, and those for the type str are concatenation and length. The importance of this classification will become apparent once we have defined the dynamics of the language in Chapter 7. Then we will see that 1 This
may seem so obvious as to be not worthy of mention, but, suprisingly, there are useful type systems that lack this property. Since they do not validate the structural principle of weakening, they are called sub-structural type systems.
R EVISED 10.03.2011
D RAFT
V ERSION 1.19
62
6.4 Notes
the eliminatory forms are inverse to the introductory forms in that they “take apart” what the introductory forms have “put together.” The coherence of the statics and dynamics of a language expresses the concept of type safety, the subject of Chapter 8.
6.4
Notes
The concept of the static semantics of a programming language was historically slow to develop, perhaps because the earliest languages had relatively few features and only very weak type systems. The concept of a static semantics in the sense considered here was introduced in the definition of the Standard ML programming language (Milner et al., 1997), building on much earlier work by Church and others on the typed λ-calculus (Barendregt, 1992). The concept of introduction and elimination, and the associated inversion principle, was introduced by Gentzen in his pioneering work on natural deduction (Gentzen, 1969). These principles were applied ¨ (1984, 1980). to the structure of programming languages by Martin-Lof
V ERSION 1.19
D RAFT
R EVISED 10.03.2011
Chapter 7
Dynamics The dynamics of a language is a description of how programs are to be executed. The most important way to define the dynamics of a language is by the method of structural dynamics, which defines a transition system that inductively specifies the step-by-step process of executing a program. Another method for presenting dynamics, called contextual dynamics, is a variation of structural dynamics in which the transition rules are specified in a slightly different manner. An equational dynamics presents the dynamics of a language equationally by a collection of rules for deducing when one program is definitionally equivalent to another.
7.1
Transition Systems
A transition system is specified by the following four forms of judgment: 1. s state, asserting that s is a state of the transition system. 2. s final, where s state, asserting that s is a final state. 3. s initial, where s state, asserting that s is an initial state. 4. s 7→ s0 , where s state and s0 state, asserting that state s may transition to state s0 . In practice we always arrange things so that no transition is possible from a final state: if s final, then there is no s0 state such that s 7→ s0 . A state from which no transition is possible is sometimes said to be stuck. Whereas all final states are, by convention, stuck, there may be stuck states in a transition system that are not final. A transition system is deterministic iff for
64
7.2 Structural Dynamics
every state s there exists at most one state s0 such that s 7→ s0 , otherwise it is non-deterministic. A transition sequence is a sequence of states s0 , . . . , sn such that s0 initial, and si 7→ si+1 for every 0 ≤ i < n. A transition sequence is maximal iff there is no s such that sn 7→ s, and it is complete iff it is maximal and, in addition, sn final. Thus every complete transition sequence is maximal, but maximal sequences are not necessarily complete. The judgement s ↓ means that there is a complete transition sequence starting from s, which is to say that there exists s0 final such that s 7→∗ s0 . The iteration of transition judgement, s 7→∗ s0 , is inductively defined by the following rules: (7.1a) s 7→∗ s s 7→ s0 s0 7→∗ s00 (7.1b) s 7→∗ s00 It is easy to show that iterated transition is transitive: if s 7→∗ s0 and s0 7→∗ s00 , then s 7→∗ s00 . When applied to the definition of iterated transition, the principle of rule induction states that to show that P(s, s0 ) holds whenever s 7→∗ s0 , it is enough to show these two properties of P: 1. P(s, s). 2. if s 7→ s0 and P(s0 , s00 ), then P(s, s00 ). The first requirement is to show that P is reflexive. The second is to show that P is closed under head expansion, or closed under inverse evaluation. Using this principle, it is easy to prove that 7→∗ is reflexive and transitive. The n-times iterated transition judgement, s 7→n s0 , where n ≥ 0, is inductively defined by the following rules. s 7 →0 s
(7.2a)
s 7→ s0 s0 7→n s00 s 7→n+1 s00
(7.2b)
Theorem 7.1. For all states s and s0 , s 7→∗ s0 iff s 7→k s0 for some k ≥ 0.
7.2
Structural Dynamics
A structural dynamics for L{num str} is given by a transition system whose states are closed expressions. All states are initial. The final states are the V ERSION 1.19
D RAFT
R EVISED 10.03.2011
7.2 Structural Dynamics
65
(closed) values, which represent the completed computations. The judgement e val, which states that e is a value, is inductively defined by the following rules: (7.3a) num[n] val (7.3b) str[s] val The transition judgement, e 7→ e0 , between states is inductively defined by the following rules: n1 + n2 = n nat plus(num[n1 ]; num[n2 ]) 7→ num[n]
(7.4a)
e1 7→ e10 plus(e1 ; e2 ) 7→ plus(e10 ; e2 )
(7.4b)
e1 val e2 7→ e20 plus(e1 ; e2 ) 7→ plus(e1 ; e20 )
(7.4c)
s1 ˆ s2 = s str cat(str[s1 ]; str[s2 ]) 7→ str[s] e1 7→ e10 cat(e1 ; e2 ) 7→ cat(e10 ; e2 ) e1 val e2 7→ e20 cat(e1 ; e2 ) 7→ cat(e1 ; e20 )
(7.4d) (7.4e) (7.4f)
(7.4g) let(e1 ; x.e2 ) 7→ [e1 /x ]e2 We have omitted rules for multiplication and computing the length of a string, which follow a similar pattern. Rules (7.4a), (7.4d), and (7.4g) are instruction transitions, since they correspond to the primitive steps of evaluation. The remaining rules are search transitions that determine the order in which instructions are executed. Rule (7.4g) specifies a by-name interpretation, in which the bound variable stands for the expression e1 itself.1 If x does not occur in e2 , the expression e1 is never evaluated. If, on the other hand, it occurs more than once, then e1 will be re-evaluated at each occurence. To avoid repeated work in the latter case, we may instead specify a by-value interpretation of binding by the following rules: e1 val let(e1 ; x.e2 ) 7→ [e1 /x ]e2
(7.5a)
1 The justification for the terminology “by name” is obscure, but the terminology is firmly
established and cannot be changed.
R EVISED 10.03.2011
D RAFT
V ERSION 1.19
66
7.2 Structural Dynamics e1 7→ e10 let(e1 ; x.e2 ) 7→ let(e10 ; x.e2 )
(7.5b)
Rule (7.5b) is an additional search rule specifying that we may evaluate e1 before e2 . Rule (7.5a) ensures that e2 is not evaluated until evaluation of e1 is complete. A derivation sequence in a structural dynamics has a two-dimensional structure, with the number of steps in the sequence being its “width” and the derivation tree for each step being its “height.” For example, consider the following evaluation sequence. let(plus(num[1]; num[2]); x.plus(plus(x; num[3]); num[4])) 7→ let(num[3]; x.plus(plus(x; num[3]); num[4])) 7→ plus(plus(num[3]; num[3]); num[4]) 7→ plus(num[6]; num[4]) 7→ num[10] Each step in this sequence of transitions is justified by a derivation according to Rules (7.4). For example, the third transition in the preceding example is justified by the following derivation: (7.4a) plus(num[3]; num[3]) 7→ num[6] (7.4b) plus(plus(num[3]; num[3]); num[4]) 7→ plus(num[6]; num[4]) The other steps are similarly justified by a composition of rules. The principle of rule induction for the structural dynamics of L{num str} states that to show P (e 7→ e0 ) whenever e 7→ e0 , it is sufficient to show that P is closed under Rules (7.4). For example, we may show by rule induction that structural dynamics of L{num str} is determinate, which means that an expression may transition to at most one other expression. The proof a simple lemma relating transition to values: Lemma 7.2. For no expression e do we have both e val and e 7→ e0 for some e0 . Proof. By rule induction on Rules (7.3) and (7.4). Lemma 7.3 (Determinacy). If e 7→ e0 and e 7→ e00 , then e0 and e00 are αequivalent. Proof. By rule induction on the premises e 7→ e0 and e 7→ e00 , carried out either simultaneously or in either order. Since only one rule applies to each form of expression, e, the result follows directly in each case. It is assumed that the primitive operators, such as addition, have a unique value when applied to values. V ERSION 1.19
D RAFT
R EVISED 10.03.2011
7.3 Contextual Dynamics
67
Rules (7.4) exemplify the inversion principle of language design, which states that the eliminatory forms are inverse to the introductory forms of a language. The search rules determine the principal arguments of each eliminatory form, and the instruction rules specify how to evaluate an eliminatory form when all of its principal arguments are in introductory form. For example, Rules (7.4) specify that both argument of addition are principal, and specify how to evaluate an addition once its principal arguments are evaluated to numerals. The inversion principle is central to ensuring that a programming language is properly defined, the exact statement of which is given in Chapter 8.
7.3
Contextual Dynamics
A variant of structural dynamics, called contextual dynamics, is sometimes useful. There is no fundamental difference between contextual and structural dynamics, rather one of style. The main idea is to isolate instruction steps as a special form of judgement, called instruction transition, and to formalize the process of locating the next instruction using a device called an evaluation context. The judgement, e val, defining whether an expression is a value, remains unchanged. The instruction transition judgement, e1 e2 , for L{num str} is defined by the following rules, together with similar rules for multiplication of numbers and the length of a string. m + n = p nat plus(num[m]; num[n]) s ˆ t = u str cat(str[s]; str[t]) let(e1 ; x.e2 )
num[p] str[u]
[e1 /x ]e2
(7.6a) (7.6b) (7.6c)
The judgement E ectxt determines the location of the next instruction to execute in a larger expression. The position of the next instruction step is specified by a “hole”, written ◦, into which the next instruction is placed, as we shall detail shortly. (The rules for multiplication and length are omitted for concision, as they are handled similarly.)
R EVISED 10.03.2011
◦ ectxt
(7.7a)
E1 ectxt plus(E1 ; e2 ) ectxt
(7.7b)
D RAFT
V ERSION 1.19
68
7.3 Contextual Dynamics e1 val E2 ectxt plus(e1 ; E2 ) ectxt
(7.7c)
The first rule for evaluation contexts specifies that the next instruction may occur “here”, at the point of the occurrence of the hole. The remaining rules correspond one-for-one to the search rules of the structural dynamics. For example, Rule (7.7c) states that in an expression plus(e1 ; e2 ), if the first argument, e1 , is a value, then the next instruction step, if any, lies at or within the second argument, e2 . An evaluation context is to be thought of as a template that is instantiated by replacing the hole with an instruction to be executed. The judgement e0 = E {e} states that the expression e0 is the result of filling the hole in the evaluation context E with the expression e. It is inductively defined by the following rules: (7.8a) e = ◦{e} e1 = E 1 { e } plus(e1 ; e2 ) = plus(E1 ; e2 ){e}
(7.8b)
e1 val e2 = E2 {e} plus(e1 ; e2 ) = plus(e1 ; E2 ){e}
(7.8c)
There is one rule for each form of evaluation context. Filling the hole with e results in e; otherwise we proceed inductively over the structure of the evaluation context. Finally, the contextual dynamics for L{num str} is defined by a single rule: e = E { e0 } e0 e00 e0 = E {e00 } (7.9) e 7→ e0 Thus, a transition from e to e0 consists of (1) decomposing e into an evaluation context and an instruction, (2) execution of that instruction, and (3) replacing the instruction by the result of its execution in the same spot within e to obtain e0 . The structural and contextual dynamics define the same transition relation. For the sake of the proof, let us write e 7→s e0 for the transition relation defined by the structural dynamics (Rules (7.4)), and e 7→c e0 for the transition relation defined by the contextual dynamics (Rules (7.9)). Theorem 7.4. e 7→s e0 if, and only if, e 7→c e0 . Proof. From left to right, proceed by rule induction on Rules (7.4). It is enough in each case to exhibit an evaluation context E such that e = E {e0 }, e0 = E {e00 }, and e0 e00 . For example, for Rule (7.4a), take E = ◦, and V ERSION 1.19
D RAFT
R EVISED 10.03.2011
7.4 Equational Dynamics
69
observe that e e0 . For Rule (7.4b), we have by induction that there exists e00 . an evaluation context E1 such that e1 = E1 {e0 }, e10 = E1 {e00 }, and e0 0 Take E = plus(E1 ; e2 ), and observe that e = plus(E1 ; e2 ){e0 } and e = e00 . plus(E1 ; e2 ){e00 } with e0 From right to left, observe that if e 7→c e0 , then there exists an evaluation e00 . We prove by induccontext E such that e = E {e0 }, e0 = E {e00 }, and e0 0 tion on Rules (7.8) that e 7→s e . For example, for Rule (7.8a), e0 is e, e00 is e0 , and e e0 . Hence e 7→s e0 . For Rule (7.8b), we have that E = plus(E1 ; e2 ), e1 = E1 {e0 }, e10 = E1 {e00 }, and e1 7→s e10 . Therefore e is plus(e1 ; e2 ), e0 is plus(e10 ; e2 ), and therefore by Rule (7.4b), e 7→s e0 . Since the two transition judgements coincide, contextual dynamics may be seen as an alternative way of presenting a structural dynamics. It has two advantages over structural dynamics, one relatively superficial, one rather less so. The superficial advantage stems from writing Rule (7.9) in the simpler form e0 e00 . (7.10) E {e0 } 7→ E {e00 } This formulation is superficially simpler in that it does not make explicit how an expression is to be decomposed into an evaluation context and a reducible expression. The deeper advantage of contextual dynamics is that all transitions are between complete programs. One need never consider a transition between expressions of any type other than the ultimate observable type. This simplifies certain arguments, notably the proof of Lemma 50.13 on page 528.
7.4
Equational Dynamics
Another formulation of the dynamics of a language is based on regarding computation as a form of equational deduction, much in the style of elementary algebra. For example, in algebra we may show that the polynomials x2 + 2 x + 1 and ( x + 1)2 are equivalent by a simple process of calculation and re-organization using the familiar laws of addition and multiplication. The same laws are sufficient to determine the value of any polynomial, given the values of its variables. So, for example, we may plug in 2 for x in the polynomial x2 + 2 x + 1 and calculate that 22 + 2 2 + 1 = 9, which is indeed (2 + 1)2 . This gives rise to a model of computation in which we may determine the value of a polynomial for a given value of its variable by R EVISED 10.03.2011
D RAFT
V ERSION 1.19
70
7.4 Equational Dynamics
substituting the given value for the variable and proving that the resulting expression is equal to its value. Very similar ideas give rise to the concept of definitional, or computational, equivalence of expressions in L{num str}, which we write as X | Γ ` e ≡ e0 : τ, where Γ consists of one assumption of the form x : τ for each x ∈ X . We only consider definitional equivalence of well-typed expressions, so that when considering the judgement Γ ` e ≡ e0 : τ, we tacitly assume that Γ ` e : τ and Γ ` e0 : τ. Here, as usual, we omit explicit mention of the parameters, X , when they can be determined from the forms of the assumptions Γ. Definitional equivalence of expressions in L{num str} is inductively defined by the following rules: (7.11a)
Γ`e≡e:τ Γ ` e0 ≡ e : τ Γ ` e ≡ e0 : τ Γ ` e ≡ e0 : τ Γ ` e0 ≡ e00 : τ Γ ` e ≡ e00 : τ Γ ` e1 ≡ e10 : num Γ ` e2 ≡ e20 : num Γ ` plus(e1 ; e2 ) ≡ plus(e10 ; e20 ) : num
(7.11b) (7.11c) (7.11d)
Γ ` e1 ≡ e10 : str Γ ` e2 ≡ e20 : str Γ ` cat(e1 ; e2 ) ≡ cat(e10 ; e20 ) : str
(7.11e)
Γ ` e1 ≡ e10 : τ1 Γ, x : τ1 ` e2 ≡ e20 : τ2 Γ ` let(e1 ; x.e2 ) ≡ let(e10 ; x.e20 ) : τ2
(7.11f)
n1 + n2 = n nat Γ ` plus(num[n1 ]; num[n2 ]) ≡ num[n] : num
(7.11g)
s1 ˆ s2 = s str Γ ` cat(str[s1 ]; str[s2 ]) ≡ str[s] : str
(7.11h)
Γ ` let(e1 ; x.e2 ) ≡ [e1 /x ]e2 : τ
(7.11i)
Rules (7.11a) through (7.11c) state that definitional equivalence is an equivalence relation. Rules (7.11d) through (7.11f) state that it is a congruence relation, which means that it is compatible with all expression-forming constructs in the language. Rules (7.11g) through (7.11i) specify the meanings of the primitive constructs of L{num str}. For the sake of concision, Rules (7.11) may be characterized as defining the strongest congruence closed under Rules (7.11g), (7.11h), and (7.11i). V ERSION 1.19
D RAFT
R EVISED 10.03.2011
7.4 Equational Dynamics
71
Rules (7.11) are sufficient to allow us to calculate the value of an expression by an equational deduction similar to that used in high school algebra. For example, we may derive the equation let x be 1 + 2 in x + 3 + 4 ≡ 10 : num by applying Rules (7.11). Here, as in general, there may be many different ways to derive the same equation, but we need find only one derivation in order to carry out an evaluation. Definitional equivalence is rather weak in that many equivalences that one might intuitively think are true are not derivable from Rules (7.11). A prototypical example is the putative equivalence x : num, y : num ` x1 + x2 ≡ x2 + x1 : num,
(7.12)
which, intuitively, expresses the commutativity of addition. Although we shall not prove this here, this equivalence is not derivable from Rules (7.11). And yet we may derive all of its closed instances, n1 + n2 ≡ n2 + n1 : num,
(7.13)
where n1 nat and n2 nat are particular numbers. The “gap” between a general law, such as Equation (7.12), and all of its instances, given by Equation (7.13), may be filled by enriching the notion of equivalence to include a principle of proof by mathematical induction. Such a notion of equivalence is sometimes called semantic, or observational, equivalence, since it expresses relationships that hold by virtue of the dynamics of the expressions involved. (Semantic equivalence is developed rigorously for a related language in Chapter 49.) Definitional equivalence is sometimes called symbolic execution, since it allows any subexpression to be replaced by the result of evaluating it according to the rules of the dynamics of the language. Theorem 7.5. e ≡ e0 : τ iff there exists e0 val such that e 7→∗ e0 and e0 7→∗ e0 . Proof. The proof from right to left is direct, since every transition step is a valid equation. The converse follows from the following, more general, proposition. If x1 : τ1 , . . . , xn : τn ` e ≡ e0 : τ, then whenever e1 : τ1 , . . . , en : τn , if [e1 , . . . , en /x1 , . . . , xn ]e ≡ [e1 , . . . , en /x1 , . . . , xn ]e0 : τ, then there exists e0 val such that
[e1 , . . . , en /x1 , . . . , xn ]e 7→∗ e0 R EVISED 10.03.2011
D RAFT
V ERSION 1.19
72
7.5 Notes
and
[e1 , . . . , en /x1 , . . . , xn ]e0 7→∗ e0 .
This is proved by rule induction on Rules (7.11). The formulation of definitional equivalence for the by-value dynamics of binding requires a bit of additional machinery. The key idea is motivated by the modifications required to Rule (7.11i) to express the requirement that e1 be a value. As a first cut one might consider simply adding an additional premise to the rule: e1 val Γ ` let(e1 ; x.e2 ) ≡ [e1 /x ]e2 : τ
(7.14)
This is almost correct, except that the judgement e val is defined only for closed expressions, whereas e1 might well involve free variables in Γ. What is required is to extend the judgement e val to the hypothetical judgement x1 val, . . . , xn val ` e val in which the hypotheses express the assumption that variables are only ever bound to values, and hence can be regarded as values. To maintain this invariant, we must maintain a set, Ξ, of such hypotheses as part of definitional equivalence, writing Ξ Γ ` e ≡ e0 : τ, and modifying Rule (7.11f) as follows: Ξ Γ ` e1 ≡ e10 : τ1 Ξ, x val Γ, x : τ1 ` e2 ≡ e20 : τ2 Ξ Γ ` let(e1 ; x.e2 ) ≡ let(e10 ; x.e20 ) : τ2
(7.15)
The other rules are correspondingly modified to simply carry along Ξ as an additional set of hypotheses of the inference.
7.5
Notes
The use of transition systems to specify the behavior of programs goes back to the early work of Church and Turing on computability. Turing’s approach emphasized the concept of an abstract machine consisting of a finite program together with unbounded memory. Computation proceeds by changing the memory in accordance with the instructions in the program. Much early work on the operational semantics of programming languages, such as the SECD machine (Landin, 1965), emphasized machine models. Church’s approach emphasized the language for expressing computations, V ERSION 1.19
D RAFT
R EVISED 10.03.2011
7.5 Notes
73
and defined execution in terms of the programs themselves, rather than in terms of auxiliary concepts such as memories or tapes. Plotkin’s elegant formulation of structural operational semantics (Plotkin, 1981), which we use heavily throughout this book, was inspired by Church’s and Landin’s ideas (Plotkin, 2004). Contextual semantics, which was introduced by Felleisen and Hieb (1992), may be seen as an alternative formulation of structural semantics in which “search rules” are replaced by “context matching”. Computation viewed as equational deduction goes back to the early work of ¨ Herbrand, Godel, and Church.
R EVISED 10.03.2011
D RAFT
V ERSION 1.19
74
V ERSION 1.19
7.5 Notes
D RAFT
R EVISED 10.03.2011
Chapter 8
Type Safety Most contemporary programming languages are safe (or, type safe, or strongly typed). Informally, this means that certain kinds of mismatches cannot arise during execution. For example, type safety for L{num str} states that it will never arise that a number is to be added to a string, or that two numbers are to be concatenated, neither of which is meaningful. In general type safety expresses the coherence between the statics and the dynamics. The statics may be seen as predicting that the value of an expression will have a certain form so that the dynamics of that expression is well-defined. Consequently, evaluation cannot “get stuck” in a state for which no transition is possible, corresponding in implementation terms to the absence of “illegal instruction” errors at execution time. This is proved by showing that each step of transition preserves typability and by showing that typable states are well-defined. Consequently, evaluation can never “go off into the weeds,” and hence can never encounter an illegal instruction. More precisely, type safety for L{num str} may be stated as follows: Theorem 8.1 (Type Safety).
1. If e : τ and e 7→ e0 , then e0 : τ.
2. If e : τ, then either e val, or there exists e0 such that e 7→ e0 . The first part, called preservation, says that the steps of evaluation preserve typing; the second, called progress, ensures that well-typed expressions are either values or can be further evaluated. Safety is the conjunction of preservation and progress. We say that an expression, e, is stuck iff it is not a value, yet there is no 0 e such that e 7→ e0 . It follows from the safety theorem that a stuck state is
76
8.1 Preservation
necessarily ill-typed. Or, putting it the other way around, that well-typed states do not get stuck.
8.1
Preservation
The preservation theorem for L{num str} defined in Chapters 6 and 7 is proved by rule induction on the transition system (rules (7.4)). Theorem 8.2 (Preservation). If e : τ and e 7→ e0 , then e0 : τ. Proof. We will consider two cases, leaving the rest to the reader. Consider rule (7.4b), e1 7→ e10 . plus(e1 ; e2 ) 7→ plus(e10 ; e2 ) Assume that plus(e1 ; e2 ) : τ. By inversion for typing, we have that τ = num, e1 : num, and e2 : num. By induction we have that e10 : num, and hence plus(e10 ; e2 ) : num. The case for concatenation is handled similarly. Now consider rule (7.4g), e1 val . let(e1 ; x.e2 ) 7→ [e1 /x ]e2 Assume that let(e1 ; x.e2 ) : τ2 . By the inversion lemma 6.2 on page 59, e1 : τ1 for some τ1 such that x : τ1 ` e2 : τ2 . By the substitution lemma 6.4 on page 60 [e1 /x ]e2 : τ2 , as desired. It is easy to check that the primitive operations are all type-preserving; for example, if a nat and b nat and a + b = c nat, then c nat. The proof of preservation is naturally structured as an induction on the transition judgement, since the argument hinges on examining all possible transitions from a given expression. In some cases one may manage to carry out a proof by structural induction on e, or by an induction on typing, but experience shows that this often leads to awkward arguments, or, in some cases, cannot be made to work at all.
8.2
Progress
The progress theorem captures the idea that well-typed programs cannot “get stuck”. The proof depends crucially on the following lemma, which characterizes the values of each type. V ERSION 1.19
D RAFT
R EVISED 10.03.2011
8.2 Progress
77
Lemma 8.3 (Canonical Forms). If e val and e : τ, then 1. If τ = num, then e = num[n] for some number n. 2. If τ = str, then e = str[s] for some string s. Proof. By induction on rules (6.1) and (7.3). Progress is proved by rule induction on rules (6.1) defining the statics of the language. Theorem 8.4 (Progress). If e : τ, then either e val, or there exists e0 such that e 7→ e0 . Proof. The proof proceeds by induction on the typing derivation. We will consider only one case, for rule (6.1d), e1 : num e2 : num , plus(e1 ; e2 ) : num where the context is empty because we are considering only closed terms. By induction we have that either e1 val, or there exists e10 such that e1 7→ e10 . In the latter case it follows that plus(e1 ; e2 ) 7→ plus(e10 ; e2 ), as required. In the former we also have by induction that either e2 val, or there exists e20 such that e2 7→ e20 . In the latter case we have that plus(e1 ; e2 ) 7→ plus(e1 ; e20 ), as required. In the former, we have, by the Canonical Forms Lemma 8.3, e1 = num[n1 ] and e2 = num[n2 ], and hence plus(num[n1 ]; num[n2 ]) 7→ num[n1 + n2 ].
Since the typing rules for expressions are syntax-directed, the progress theorem could equally well be proved by induction on the structure of e, appealing to the inversion theorem at each step to characterize the types of the parts of e. But this approach breaks down when the typing rules are not syntax-directed, that is, when there may be more than one rule for a given expression form. No difficulty arises if the proof proceeds by induction on the typing rules. Summing up, the combination of preservation and progress together constitute the proof of safety. The progress theorem ensures that well-typed expressions do not “get stuck” in an ill-defined state, and the preservation theorem ensures that if a step is taken, the result remains well-typed (with the same type). Thus the two parts work hand-in-hand to ensure that the statics and dynamics are coherent, and that no ill-defined states can ever be encountered while evaluating a well-typed expression. R EVISED 10.03.2011
D RAFT
V ERSION 1.19
78
8.3 Run-Time Errors
8.3
Run-Time Errors
Suppose that we wish to extend L{num str} with, say, a quotient operation that is undefined for a zero divisor. The natural typing rule for quotients is given by the following rule: e1 : num e2 : num . div(e1 ; e2 ) : num But the expression div(num[3]; num[0]) is well-typed, yet stuck! We have two options to correct this situation: 1. Enhance the type system, so that no well-typed program may divide by zero. 2. Add dynamic checks, so that division by zero signals an error as the outcome of evaluation. Either option is, in principle, viable, but the most common approach is the second. The first requires that the type checker prove that an expression be non-zero before permitting it to be used in the denominator of a quotient. It is difficult to do this without ruling out too many programs as ill-formed. This is because one cannot reliably predict statically whether an expression will turn out to be non-zero when executed (because this is an undecidable property). We therefore consider the second approach, which is typical of current practice. The general idea is to distinguish checked from unchecked errors. An unchecked error is one that is ruled out by the type system. No run-time checking is performed to ensure that such an error does not occur, because the type system rules out the possibility of it arising. For example, the dynamics need not check, when performing an addition, that its two arguments are, in fact, numbers, as opposed to strings, because the type system ensures that this is the case. On the other hand the dynamics for quotient must check for a zero divisor, because the type system does not rule out the possibility. One approach to modelling checked errors is to give an inductive definition of the judgment e err stating that the expression e incurs a checked run-time error, such as division by zero. Here are some representative rules that would appear in a full inductive definition of this judgement: e1 val div(e1 ; num[0]) err V ERSION 1.19
D RAFT
(8.1a) R EVISED 10.03.2011
8.4 Notes
79 e1 err plus(e1 ; e2 ) err
(8.1b)
e1 val e2 err plus(e1 ; e2 ) err
(8.1c)
Rule (8.1a) signals an error condition for division by zero. The other rules propagate this error upwards: if an evaluated sub-expression is a checked error, then so is the overall expression. Once the error judgement is available, we may also consider an expression, error, which forcibly induces an error, with the following static and dynamic semantics: Γ ` error : τ
(8.2a)
(8.2b) error err The preservation theorem is not affected by the presence of checked errors. However, the statement (and proof) of progress is modified to account for checked errors. Theorem 8.5 (Progress With Error). If e : τ, then either e err, or e val, or there exists e0 such that e 7→ e0 . Proof. The proof is by induction on typing, and proceeds similarly to the proof given earlier, except that there are now three cases to consider at each point in the proof.
8.4
Notes
The concept of type safety as it is understood today was first formulated by Milner (1978), who invented the slogan “well-typed programs do not go wrong.” Whereas Milner relied on an explicit notion of “going wrong” to express the concept of a type error, Wright and Felleisen (1994) observed that one can instead show that ill-defined states cannot arise in a well-typed program, giving rise to the slogan “well-typed programs do not get stuck.” However, their formulation relied on an analysis showing that no stuck state is well-typed. This analysis is replaced by the progress theorem given here, which relies on the concept of canonical forms introduced by Martin¨ (1980). Lof
R EVISED 10.03.2011
D RAFT
V ERSION 1.19
80
V ERSION 1.19
8.4 Notes
D RAFT
R EVISED 10.03.2011
Chapter 9
Evaluation Dynamics In Chapter 7 we defined the evaluation of expressions in L{num str} using the method of structural dynamics. This approach is useful as a foundation for proving properties of a language, but other methods are often more appropriate for other purposes, such as writing user manuals. Another method, called evaluation dynamics presents the dynamics as a relation between a phrase and its value, without detailing how it is to be determined in a step-by-step manner. Evaluation dynamics suppresses the step-by-step details of determining the value of an expression, and hence does not provide any useful notion of the time complexity of a program. Cost dynamics rectifies this by augmenting evaluation dynamics with a cost measure. Various cost measures may be assigned to an expression. One example is the number of steps in the structural dynamics required for an expression to reach a value.
9.1
Evaluation Dynamics
Another method for defining the dynamics of L{num str}, called evaluation dynamics, consists of an inductive definition of the evaluation judgement, e ⇓ v, stating that the closed expression, e, evaluates to the value, v. num[n] ⇓ num[n]
(9.1a)
str[s] ⇓ str[s]
(9.1b)
e1 ⇓ num[n1 ] e2 ⇓ num[n2 ] n1 + n2 = n nat plus(e1 ; e2 ) ⇓ num[n]
(9.1c)
82
9.2 Relating Structural and Evaluation Dynamics e1 ⇓ str[s1 ] e2 ⇓ str[s2 ] s1 ˆ s2 = s str cat(e1 ; e2 ) ⇓ str[s]
(9.1d)
e ⇓ str[s] |s| = n str len(e) ⇓ num[n]
(9.1e)
[e1 /x ]e2 ⇓ v2 let(e1 ; x.e2 ) ⇓ v2
(9.1f)
The value of a let expression is determined by substitution of the binding into the body. The rules are therefore not syntax-directed, since the premise of Rule (9.1f) is not a sub-expression of the expression in the conclusion of that rule. Since the evaluation judgement is inductively defined, we prove properties of it by rule induction. Specifically, to show that the property P (e ⇓ v) holds, it is enough to show that P is closed under Rules (9.1): 1. Show that P (num[n] ⇓ num[n]). 2. Show that P (str[s] ⇓ str[s]). 3. Show that P (plus(e1 ; e2 ) ⇓ num[n]), if P (e1 ⇓ num[n1 ]), P (e2 ⇓ num[n2 ]), and n1 + n2 = n nat. 4. Show that P (cat(e1 ; e2 ) ⇓ str[s]), if P (e1 ⇓ str[s1 ]), P (e2 ⇓ str[s2 ]), and s1 ˆ s2 = s str. 5. Show that P (let(e1 ; x.e2 ) ⇓ v2 ), if P ([e1 /x ]e2 ⇓ v2 ). This induction principle is not the same as structural induction on e exp, because the evaluation rules are not syntax-directed! Lemma 9.1. If e ⇓ v, then v val. Proof. By induction on Rules (9.1). All cases except Rule (9.1f) are immediate. For the latter case, the result follows directly by an appeal to the inductive hypothesis for the premise of the evaluation rule.
9.2
Relating Structural and Evaluation Dynamics
We have given two different forms of dynamics for L{num str}. It is natural to ask whether they are equivalent, but to do so first requires that we consider carefully what we mean by equivalence. The structural dynamics V ERSION 1.19
D RAFT
R EVISED 10.03.2011
9.3 Type Safety, Revisited
83
describes a step-by-step process of execution, whereas the evaluation dynamics suppresses the intermediate states, focussing attention on the initial and final states alone. This suggests that the appropriate correspondence is between complete execution sequences in the structural dynamics and the evaluation judgement in the evaluation dynamics. (We will consider only numeric expressions, but analogous results hold also for string-valued expressions.) Theorem 9.2. For all closed expressions e and values v, e 7→∗ v iff e ⇓ v. How might we prove such a theorem? We will consider each direction separately. We consider the easier case first. Lemma 9.3. If e ⇓ v, then e 7→∗ v. Proof. By induction on the definition of the evaluation judgement. For example, suppose that plus(e1 ; e2 ) ⇓ num[n] by the rule for evaluating additions. By induction we know that e1 7→∗ num[n1 ] and e2 7→∗ num[n2 ]. We reason as follows: plus(e1 ; e2 ) 7→∗ plus(num[n1 ]; e2 ) 7→∗ plus(num[n1 ]; num[n2 ]) 7→ num[n1 + n2 ] Therefore plus(e1 ; e2 ) 7→∗ num[n1 + n2 ], as required. The other cases are handled similarly. For the converse, recall from Chapter 7 the definitions of multi-step evaluation and complete evaluation. Since v ⇓ v whenever v val, it suffices to show that evaluation is closed under reverse execution. Lemma 9.4. If e 7→ e0 and e0 ⇓ v, then e ⇓ v. Proof. By induction on the definition of the transition judgement. For example, suppose that plus(e1 ; e2 ) 7→ plus(e10 ; e2 ), where e1 7→ e10 . Suppose further that plus(e10 ; e2 ) ⇓ v, so that e10 ⇓ num[n1 ], e2 ⇓ num[n2 ], n1 + n2 = n nat, and v is num[n]. By induction e1 ⇓ num[n1 ], and hence plus(e1 ; e2 ) ⇓ num[n], as required.
9.3
Type Safety, Revisited
Theorem 8.1 on page 75 states that a language is safe iff it satisfies both preservation and progress. This formulation depends critically on the use R EVISED 10.03.2011
D RAFT
V ERSION 1.19
84
9.3 Type Safety, Revisited
of a transition system to specify the dynamics. But what if we had instead specified the dynamics as an evaluation relation, instead of using a transition system? Can we state and prove safety in such a setting? The answer, unfortunately, is that we cannot. While there is an analogue of the preservation property for an evaluation dynamics, there is no clear analogue of the progress property. Preservation may be stated as saying that if e ⇓ v and e : τ, then v : τ. This can be readily proved by induction on the evaluation rules. But what is the analogue of progress? One might be tempted to phrase progress as saying that if e : τ, then e ⇓ v for some v. While this property is true for L{num str}, it demands much more than just progress — it requires that every expression evaluate to a value! If L{num str} were extended to admit operations that may result in an error (as discussed in Section 8.3 on page 78), or to admit non-terminating expressions, then this property would fail, even though progress would remain valid. One possible attitude towards this situation is to simply conclude that type safety cannot be properly discussed in the context of an evaluation dynamics, but only by reference to a structural dynamics. Another point of view is to instrument the dynamics with explicit checks for run-time type errors, and to show that any expression with a type fault must be ill-typed. Re-stated in the contrapositive, this means that a well-typed program cannot incur a type error. A difficulty with this point of view is that one must explicitly account for a form of error solely to prove that it cannot arise! Nevertheless, we will press on to show how a semblance of type safety can be established using evaluation dynamics. The main idea is to define a judgement e⇑ stating, in the jargon of the literature, that the expression e goes wrong when executed. The exact definition of “going wrong” is given by a set of rules, but the intention is that it should cover all situations that correspond to type errors. The following rules are representative of the general case: plus(str[s]; e2 )⇑
(9.2a)
e1 val (9.2b) plus(e1 ; str[s])⇑ These rules explicitly check for the misapplication of addition to a string; similar rules govern each of the primitive constructs of the language. Theorem 9.5. If e⇑, then there is no τ such that e : τ. Proof. By rule induction on Rules (9.2). For example, for Rule (9.2a), we observe that str[s] : str, and hence plus(str[s]; e2 ) is ill-typed. V ERSION 1.19
D RAFT
R EVISED 10.03.2011
9.4 Cost Dynamics
85
Corollary 9.6. If e : τ, then ¬(e⇑). Apart from the inconvenience of having to define the judgement e⇑ only to show that it is irrelevant for well-typed programs, this approach suffers a very significant methodological weakness. If we should omit one or more rules defining the judgement e⇑, the proof of Theorem 9.5 on the facing page remains valid; there is nothing to ensure that we have included sufficiently many checks for run-time type errors. We can prove that the ones we define cannot arise in a well-typed program, but we cannot prove that we have covered all possible cases. By contrast the structural dynamics does not specify any behavior for ill-typed expressions. Consequently, any ill-typed expression will “get stuck” without our explicit intervention, and the progress theorem rules out all such cases. Moreover, the transition system corresponds more closely to implementation—a compiler need not make any provisions for checking for run-time type errors. Instead, it relies on the statics to ensure that these cannot arise, and assigns no meaning to any ill-typed program. Execution is therefore more efficient, and the language definition is simpler.
9.4
Cost Dynamics
A structural dynamics provides a natural notion of time complexity for programs, namely the number of steps required to reach a final state. An evaluation dynamics, on the other hand, does not provide such a direct notion of complexity. Since the individual steps required to complete an evaluation are suppressed, we cannot directly read off the number of steps required to evaluate to a value. Instead we must augment the evaluation relation with a cost measure, resulting in a cost dynamics. Evaluation judgements have the form e ⇓k v, with the meaning that e evaluates to v in k steps. num[n] ⇓0 num[n]
(9.3a)
e1 ⇓k1 num[n1 ] e2 ⇓k2 num[n2 ] plus(e1 ; e2 ) ⇓k1 +k2 +1 num[n1 + n2 ]
(9.3b)
str[s] ⇓0 str[s]
(9.3c)
e1 ⇓ k 1 s 1 e2 ⇓ k 2 s 2 cat(e1 ; e2 ) ⇓k1 +k2 +1 str[s1 ˆ s2 ]
(9.3d)
R EVISED 10.03.2011
D RAFT
V ERSION 1.19
86
9.5 Notes
[e1 /x ]e2 ⇓k2 v2 let(e1 ; x.e2 ) ⇓k2 +1 v2
(9.3e)
Theorem 9.7. For any closed expression e and closed value v of the same type, e ⇓k v iff e 7→k v. Proof. From left to right proceed by rule induction on the definition of the cost dynamics. From right to left proceed by induction on k, with an inner rule induction on the definition of the structural dynamics.
9.5
Notes
The structural similarity between evaluation dynamics and typing rules was first developed in the definition of Standard ML (Milner et al., 1997). The advantage of evaluation semantics is that it directly defines the relation of interest, that between a program and its outcome. The disadvantage is that it is not as well-suited to metatheory as structural semantics, precisely because it glosses over the fine structure of computation. The concept of a cost dynamics was introduced by Blelloch and Greiner (1996b) in their study of parallelism (discussed further in Chapter 41).
V ERSION 1.19
D RAFT
R EVISED 10.03.2011
Part IV
Function Types
Chapter 10
Function Definitions and Values In the language L{num str} we may perform calculations such as the doubling of a given expression, but we cannot express doubling as a concept in itself. To capture the general pattern of doubling, we abstract away from the particular number being doubled using a variable to stand for a fixed, but unspecified, number, to express the doubling of an arbitrary number. Any particular instance of doubling may then be obtained by substituting a numeric expression for that variable. In general an expression may involve many distinct variables, necessitating that we specify which of several possible variables is varying in a particular context, giving rise to a function of that variable. In this chapter we will consider two extensions of L{num str} with functions. The first, and perhaps most obvious, extension is by adding function definitions to the language. A function is defined by binding a name to an abt with a bound variable that serves as the argument of that function. A function is applied by substituting a particular expression (of suitable type) for the bound variable, obtaining an expression. The domain and range of defined functions are limited to the types nat and str, since these are the only types of expression. Such functions are called first-order functions, in contrast to higher-order functions, which permit functions as arguments and results of other functions. Since the domain and range of a function are types, this requires that we introduce function types whose elements are functions. Consequently, we may form functions of higher type, those whose domain and range may themselves be function types.
90
10.1 First-Order Functions
Historically the introduction of higher-order functions was responsible for a mistake in language design that subsequently was re-characterized as a feature, called dynamic binding. Dynamic binding arises from getting the definition of substitution wrong by failing to avoid capture. This makes the names of bound variables important, in violation of the fundamental principle of binding stating that the names of bound variables are unimportant.
10.1
First-Order Functions
The language L{num str fun} is the extension of L{num str} with function definitions and function applications as described by the following grammar: Exp e ::=
call[ f ](e) f (e) call fun[τ1 ; τ2 ](x1 .e2 ; f .e) fun f (x1 :τ1 ):τ2 = e2 in e definition
The expression fun[τ1 ; τ2 ](x1 .e2 ; f .e) binds the function name f within e to the pattern x1 .e2 , which has parameter x1 and definition e2 . The domain and range of the function are, respectively, the types τ1 and τ2 . The expression call[ f ](e) instantiates the binding of f with the argument e. The statics of L{num str fun} defines two forms of judgement: 1. Expression typing, e : τ, stating that e has type τ; 2. Function typing, f (τ1 ) : τ2 , stating that f is a function with argument type τ1 and result type τ2 . The judgment f (τ1 ) : τ2 is called the function header of f ; it specifies the domain type and the range type of a function. The statics of L{num str fun} is defined by the following rules: Γ, x1 : τ1 ` e2 : τ2 Γ, f (τ1 ) : τ2 ` e : τ Γ ` fun[τ1 ; τ2 ](x1 .e2 ; f .e) : τ
(10.1a)
Γ ` f (τ1 ) : τ2 Γ ` e : τ1 Γ ` call[ f ](e) : τ2
(10.1b)
Function substitution, written [[ x.e/ f ]]e0 , is defined by induction on the structure of e0 much like the definition of ordinary substitution. However, a function name, f , is not a form of expression, but rather can only occur in V ERSION 1.19
D RAFT
R EVISED 10.03.2011
10.2 Higher-Order Functions
91
a call of the form call[ f ](e). Function substitution for such expressions is defined by the following rule:
[[ x.e/ f ]]call[ f ](e0 ) = let([[ x.e/ f ]]e0 ; x.e)
(10.2)
At call sites to f with argument e0 , function substitution yields a let expression that binds x to the result of expanding any further calls to f within e0 . Lemma 10.1. If Γ, f (τ1 ) : τ2 ` e : τ and Γ, x1 : τ2 ` e2 : τ2 , then Γ ` [[ x1 .e2 / f ]]e : τ. Proof. By induction on the structure of e0 . The dynamics of L{num str fun} is defined using function substitution:
fun[τ1 ; τ2 ](x1 .e2 ; f .e) 7→ [[ x1 .e2 / f ]]e
(10.3)
Since function substitution replaces all calls to f by appropriate let expressions, there is no need to give a rule for function calls. The safety of L{num str fun} may be obtained as an immediate corollary of the safety theorem for higher-order functions, which we discuss next.
10.2
Higher-Order Functions
The syntactic and semantic similarity between variable definitions and function definitions in L{num str fun} is striking. This suggests that it may be possible to consolidate the two concepts into a single definition mechanism. The gap that must be bridged is the segregation of functions from expressions. A function name f is bound to an abstractor x.e specifying a pattern that is instantiated when f is applied. To consolidate function definitions with expression definitions it is sufficient to reify the abstractor into a form of expression, called a λ-abstraction, written lam[τ1 ](x.e). Correspondingly, we must generalize application to have the form ap(e1 ; e2 ), where e1 is any expression, and not just a function name. These are, respectively, the introduction and elimination forms for the function type, arr(τ1 ; τ2 ), whose elements are functions with domain τ1 and range τ2 . R EVISED 10.03.2011
D RAFT
V ERSION 1.19
92
10.2 Higher-Order Functions
The language L{num str →} is the enrichment of L{num str} with function types, as specified by the following grammar: Typ τ ::= Exp e ::=
arr(τ1 ; τ2 ) τ1 → τ2 function lam[τ](x.e) λ (x:τ. e) abstraction ap(e1 ; e2 ) e1 (e2 ) application
Functions are now “first class” in the sense that a function is an expression of function type. The statics of L{num str →} is given by extending Rules (6.1) with the following rules: Γ, x : τ1 ` e : τ2 (10.4a) Γ ` lam[τ1 ](x.e) : arr(τ1 ; τ2 ) Γ ` e1 : arr(τ2 ; τ) Γ ` e2 : τ2 (10.4b) Γ ` ap(e1 ; e2 ) : τ Lemma 10.2 (Inversion). Suppose that Γ ` e : τ. 1. If e = lam[τ1 ](x.e), then τ = arr(τ1 ; τ2 ) and Γ, x : τ1 ` e : τ2 . 2. If e = ap(e1 ; e2 ), then there exists τ2 such that Γ ` e1 : arr(τ2 ; τ) and Γ ` e2 : τ2 . Proof. The proof proceeds by rule induction on the typing rules. Observe that for each rule, exactly one case applies, and that the premises of the rule in question provide the required result. Lemma 10.3 (Substitution). If Γ, x : τ ` e0 : τ 0 , and Γ ` e : τ, then Γ ` [e/x ]e0 : τ 0 . Proof. By rule induction on the derivation of the first judgement. The dynamics of L{num str →} extends that of L{num str} with the following additional rules: (10.5a)
lam[τ](x.e) val e1 7→ e10 ap(e1 ; e2 ) 7→ ap(e10 ; e2 )
(10.5b)
ap(lam[τ2 ](x.e1 ); e2 ) 7→ [e2 /x ]e1
(10.5c)
These rules specify a call-by-name discipline for function application. It is a good exercise to formulate a call-by-value discipline as well. V ERSION 1.19
D RAFT
R EVISED 10.03.2011
10.3 Evaluation Dynamics and Definitional . . .
93
Theorem 10.4 (Preservation). If e : τ and e 7→ e0 , then e0 : τ. Proof. The proof is by induction on rules (10.5), which define the dynamics of the language. Consider rule (10.5c),
ap(lam[τ2 ](x.e1 ); e2 ) 7→ [e2 /x ]e1
.
Suppose that ap(lam[τ2 ](x.e1 ); e2 ) : τ1 . By Lemma 10.2 on the preceding page e2 : τ2 and x : τ2 ` e1 : τ1 , so by Lemma 10.3 on the facing page [e2 /x ]e1 : τ1 . The other rules governing application are handled similarly. Lemma 10.5 (Canonical Forms). If e val and e : arr(τ1 ; τ2 ), then e = lam[τ1 ](x.e2 ) for some x and e2 such that x : τ1 ` e2 : τ2 . Proof. By induction on the typing rules, using the assumption e val. Theorem 10.6 (Progress). If e : τ, then either e is a value, or there exists e0 such that e 7→ e0 . Proof. The proof is by induction on rules (10.4). Note that since we consider only closed terms, there are no hypotheses on typing derivations. Consider rule (10.4b). By induction either e1 val or e1 7→ e10 . In the latter case we have ap(e1 ; e2 ) 7→ ap(e10 ; e2 ). In the former case, we have by Lemma 10.5 that e1 = lam[τ2 ](x.e) for some x and e. But then ap(e1 ; e2 ) 7→ [e2 /x ]e.
10.3
Evaluation Dynamics and Definitional Equivalence
An inductive definition of the evaluation judgement e ⇓ v for L{num str →} is given by the following rules: (10.6a)
lam[τ](x.e) ⇓ lam[τ](x.e) e1 ⇓ lam[τ](x.e) [e2 /x ]e ⇓ v ap(e1 ; e2 ) ⇓ v
(10.6b)
It is easy to check that if e ⇓ v, then v val, and that if e val, then e ⇓ e. Theorem 10.7. e ⇓ v iff e 7→∗ v and v val. R EVISED 10.03.2011
D RAFT
V ERSION 1.19
94
10.3 Evaluation Dynamics and Definitional . . .
Proof. In the forward direction we proceed by rule induction on Rules (10.6). The proof makes use of a pasting lemma stating that, for example, if e1 7→∗ e10 , then ap(e1 ; e2 ) 7→∗ ap(e10 ; e2 ), and similarly for the other constructs of the language. In the reverse direction we proceed by rule induction on Rules (7.1). The proof relies on a converse evaluation lemma, which states that if e 7→ e0 and e0 ⇓ v, then e ⇓ v. This is proved by rule induction on Rules (10.5). Definitional equivalence for the call-by-name dynamics of L{num str →} is defined by a straightforward extension to Rules (7.11). Γ ` ap(lam[τ](x.e2 ); e1 ) ≡ [e1 /x ]e2 : τ2
(10.7a)
Γ ` e1 ≡ e10 : τ2 → τ Γ ` e2 ≡ e20 : τ2 Γ ` ap(e1 ; e2 ) ≡ ap(e10 ; e20 ) : τ
(10.7b)
Γ, x : τ1 ` e2 ≡ e20 : τ2 Γ ` lam[τ1 ](x.e2 ) ≡ lam[τ1 ](x.e20 ) : τ1 → τ2
(10.7c)
Definitional equivalence for call-by-value requires a small bit of additional machinery. The main idea is to restrict Rule (10.7a) to require that the argument be a value. However, to be fully expressive, we must also widen the concept of a value to include all variables that are in scope, so that Rule (10.7a) would apply even when the argument is a variable. The justification for this is that in call-by-value, the parameter of a function stands for the value of its argument, and not for the argument itself. The call-byvalue definitional equivalence judgement has the form Ξ Γ ` e1 ≡ e2 : τ, where Ξ is the finite set of hypotheses x1 val, . . . , xk val governing the variables in scope at that point. We write Ξ ` e val to indicate that e is a value under these hypotheses, so that, for example, Ξ, x val ` x val. The rule of definitional equivalence for call-by-value are similar to those for call-by-name, modified to take account of the scopes of value variables. Two illustrative rules are as follows: Ξ, x val Γ, x : τ1 ` e2 ≡ e20 : τ2 Ξ Γ ` lam[τ1 ](x.e2 ) ≡ lam[τ1 ](x.e20 ) : τ1 → τ2
(10.8a)
Ξ ` e1 val . Ξ Γ ` ap(lam[τ](x.e2 ); e1 ) ≡ [e1 /x ]e2 : τ
(10.8b)
V ERSION 1.19
D RAFT
R EVISED 10.03.2011
10.4 Dynamic Scope
10.4
95
Dynamic Scope
The dynamics of function application given by Rules (10.5) is defined only for expressions without free variables. When a function is called, the argument is substituted for the function parameter, ensuring that the result remains closed. Moreover, since substitution of closed expressions can never incur capture, the scopes of variables are not disturbed by the dynamics, ensuring that the principles of binding and scope described in Chapter 1 are respected. This treatment of variables is called static scoping, or static binding, to contrast it with an alternative approach that we now describe. Another approach, called dynamic scoping, or dynamic binding, is sometimes advocated as an alternative to static binding. Evaluation is defined for expressions that may contain free variables. Evaluation of a variable is undefined; it is an error to ask for the value of an unbound variable. Function call is defined similarly to dynamic binding, except that when a function is called, the argument replaces the parameter in the body, possibly incurring, rather than avoiding, capture of free variables in the argument. (As we will explain shortly, this behavior is considered to be a feature, not a bug!) The difference between replacement and substitution may be illustrated by example. Let e be the expression λ (x:str. y + |x|) in which the variable y occurs free, and let e0 be the expression λ (y:str. f (y)) with free variable f . If we substitute e for f in e0 we obtain an expression of the form 0
0
λ (y :str. λ (x:str. y + |x|)(y )), where the bound variable, y, in e has been renamed to some fresh variable y0 so as to avoid capture. If we instead replace f by e in e0 we obtain λ (y:str. λ (x:str. y + |x|)(y)) in which y is no longer free: it has been captured during replacement. The implications of this seemingly small change to the dynamics of L{→} are far-reaching. The most obvious implication is that the language is not type safe. In the above example we have that y : nat ` e : str → nat, and that f : str → nat ` e0 : str → nat. It follows that y : nat ` [e/ f ]e0 : str → nat, but it is easy to see that the result of replacing f by e in e0 is ill-typed, regardless of what assumption we make about y. The difficulty, of course, is that the bound occurrence of y in e0 has type str, whereas the free occurrence in e must have type nat in order for e to be well-formed. One way around this difficulty is to ignore types altogether, and rely on run-time checks to ensure that bad things do not happen, despite the R EVISED 10.03.2011
D RAFT
V ERSION 1.19
96
10.5 Notes
evident failure of safety. (See Chapter 20 for a full exploration of this approach.) But even if we ignore worries about safety, we are still left with the serious problem that the names of bound variables matter, and cannot be altered without changing the meaning of a program. So, for example, to use expression e0 , one must bear in mind that the parameter, f , occurs within the scope of a binder for y, a fact that is not revealed by the type of e0 (and certainly not if one disregards types entirely!) If we change e0 so that it binds a different variable, say z, then we must correspondingly change e to ensure that it refers to z, and not y, in order to preserve the overall behavior of the system of two expressions. This means that e and e0 must be developed in tandem, violating a basic principle of modular decomposition. (For more on dynamic scope, please see Chapter 35.)
10.5
Notes
Nearly all programming languages provide some form of function definition mechanism of the kind illustrated here. The main point of the present account is to demonstrate that a more natural, and more powerful, approach is to separate the generic concept of a definition from the specific concept of a function. Function types codify the general notion in a systematic manner that encompasses function definitions as a special case, and moreover, admits passing functions as arguments and returning them as results without special provision. The essential contribution of Church’s λcalculus (Church, 1941) was to take the notion of function as primary, and to demonstrate that nothing more is needed to obtain a fully expressive programming language.
V ERSION 1.19
D RAFT
R EVISED 10.03.2011
Chapter 11
Godel’s ¨ System T
The language L{nat →}, better known as G¨odel’s System T, is the combination of function types with the type of natural numbers. In contrast to L{num str}, which equips the naturals with some arbitrarily chosen arithmetic primitives, the language L{nat →} provides a general mechanism, called primitive recursion, from which these primitives may be defined. Primitive recursion captures the essential inductive character of the natural numbers, and hence may be seen as an intrinsic termination proof for each program in the language. Consequently, we may only define total functions in the language, those that always return a value for each argument. In essence every program in L{nat →} “comes equipped” with a proof of its termination. While this may seem like a shield against infinite loops, it is also a weapon that can be used to show that some programs cannot be written in L{nat →}. To do so would require a master termination proof for every possible program in the language, something that we shall prove does not exist.
98
11.1
11.1 Statics
Statics
The syntax of L{nat →} is given by the following grammar: Typ τ ::= Exp e
::=
nat arr(τ1 ; τ2 ) x z s(e) natrec(e; e0 ; x.y.e1 ) lam[τ](x.e) ap(e1 ; e2 )
nat naturals τ1 → τ2 function x variable z zero s(e) successor natrec e {z ⇒ e0 | s(x) with y ⇒ e1 } recursion λ (x:τ. e) abstraction e1 (e2 ) application
We write n for the expression s(. . . s(z)), in which the successor is applied n ≥ 0 times to zero. The expression natrec(e; e0 ; x.y.e1 ) is called primitive recursion. It represents the e-fold iteration of the transformation x.y.e1 starting from e0 . The bound variable x represents the predecessor and the bound variable y represents the result of the x-fold iteration. The “with” clause in the concrete syntax for the recursor binds the variable y to the result of the recursive call, as will become apparent shortly. Sometimes iteration, written natiter(e; e0 ; y.e1 ), is considered as an alternative to primitive recursion. It has essentially the same meaning as primitive recursion, except that only the result of the recursive call is bound to y in e1 , and no binding is made for the predecessor. Clearly iteration is a special case of primitive recursion, since we can always ignore the predecessor binding. Conversely, primitive recursion is definable from iteration, provided that we have product types (Chapter 13) at our disposal. To define primitive recursion from iteration we simultaneously compute the predecessor while iterating the specified computation. The statics of L{nat →} is given by the following typing rules: Γ, x : nat ` x : nat
(11.1a)
Γ ` z : nat Γ ` e : nat Γ ` s(e) : nat Γ ` e : nat Γ ` e0 : τ Γ, x : nat, y : τ ` e1 : τ Γ ` natrec(e; e0 ; x.y.e1 ) : τ
(11.1b)
Γ, x : ρ ` e : τ Γ ` lam[ρ](x.e) : arr(ρ; τ) V ERSION 1.19
D RAFT
(11.1c) (11.1d) (11.1e)
R EVISED 10.03.2011
11.2 Dynamics
99 Γ ` e1 : arr(τ2 ; τ) Γ ` e2 : τ2 Γ ` ap(e1 ; e2 ) : τ
(11.1f)
As usual, admissibility of the structural rule of substitution is crucially important. Lemma 11.1. If Γ ` e : τ and Γ, x : τ ` e0 : τ 0 , then Γ ` [e/x ]e0 : τ 0 .
11.2
Dynamics
The dynamics of L{nat →} adopts a call-by-name interpretation of function application, and requires that the successor operation evaluate its argument (so that values of type nat are numerals). The closed values of L{nat →} are determined by the following rules: z val
(11.2a)
e val s(e) val
(11.2b) (11.2c)
lam[τ](x.e) val The dynamics of L{nat →} is given by the following rules: e 7→ e0 s(e) 7→ s(e0 )
(11.3a)
e1 7→ e10 ap(e1 ; e2 ) 7→ ap(e10 ; e2 )
(11.3b) (11.3c)
ap(lam[τ](x.e); e2 ) 7→ [e2 /x ]e e 7→ e0 natrec(e; e0 ; x.y.e1 ) 7→ natrec(e0 ; e0 ; x.y.e1 )
(11.3d) (11.3e)
natrec(z; e0 ; x.y.e1 ) 7→ e0 s(e) val natrec(s(e); e0 ; x.y.e1 ) 7→ [e, natrec(e; e0 ; x.y.e1 )/x, y]e1
(11.3f)
Rules (11.3e) and (11.3f) specify the behavior of the recursor on z and s(e). In the former case the recursor evaluates e0 , and in the latter case the variable x is bound to the predecessor, e, and y is bound to the (unevaluated) recursion on e. If the value of y is not required in the rest of the computation, the recursive call will not be evaluated. R EVISED 10.03.2011
D RAFT
V ERSION 1.19
100
11.3 Definability
Lemma 11.2 (Canonical Forms). If e : τ and e val, then 1. If τ = nat, then e = s(s(. . . z)) for some number n ≥ 0 occurrences of the successor starting with zero. 2. If τ = τ1 → τ2 , then e = λ (x:τ1 . e2 ) for some e2 . Theorem 11.3 (Safety).
1. If e : τ and e 7→ e0 , then e0 : τ.
2. If e : τ, then either e val or e 7→ e0 for some e0
11.3
Definability
A mathematical function f : N → N on the natural numbers is definable in L{nat →} iff there exists an expression e f of type nat → nat such that for every n ∈ N, e f (n) ≡ f (n) : nat. (11.4) That is, the numeric function f : N → N is definable iff there is an expression e f of type nat → nat such that, when applied to the numeral representing the argument n ∈ N, is definitionally equivalent to the numeral corresponding to f (n) ∈ N. Definitional equivalence for L{nat →}, written Γ ` e ≡ e0 : τ, is the strongest congruence containing these axioms: Γ ` ap(lam[τ](x.e2 ); e1 ) ≡ [e1 /x ]e2 : τ
(11.5a)
(11.5b)
Γ ` natrec(z; e0 ; x.y.e1 ) ≡ e0 : τ Γ ` natrec(s(e); e0 ; x.y.e1 ) ≡ [e, natrec(e; e0 ; x.y.e1 )/x, y]e1 : τ
(11.5c)
For example, the doubling function, d(n) = 2 × n, is definable in L{nat →} by the expression ed : nat → nat given by λ (x:nat. natrec x {z ⇒ z | s(u) with v ⇒ s(s(v))}). To check that this defines the doubling function, we proceed by induction on n ∈ N. For the basis, it is easy to check that ed (0) ≡ 0 : nat. V ERSION 1.19
D RAFT
R EVISED 10.03.2011
11.3 Definability
101
For the induction, assume that ed (n) ≡ d(n) : nat. Then calculate using the rules of definitional equivalence: ed (n + 1) ≡ s(s(ed (n)))
≡ s(s(2 × n)) = 2 × ( n + 1) = d ( n + 1). As another example, consider the following function, called Ackermann’s function, defined by the following equations: A(0, n) = n + 1 A(m + 1, 0) = A(m, 1) A(m + 1, n + 1) = A(m, A(m + 1, n)). This function grows very quickly. For example, A(4, 2) ≈ 265,536 , which is often cited as being much larger than the number of atoms in the universe! Yet we can show that the Ackermann function is total by a lexicographic induction on the pair of argument (m, n). On each recursive call, either m decreases, or else m remains the same, and n decreases, so inductively the recursive calls are well-defined, and hence so is A(m, n). A first-order primitive recursive function is a function of type nat → nat that is defined using primitive recursion, but without using any higher order functions. Ackermann’s function is defined so that it is not first-order primitive recursive, but is higher-order primitive recursive. The key to showing that it is definable in L{nat →} is to observe that A(m + 1, n) iterates n times the function A(m, −), starting with A(m, 1). As an auxiliary, let us define the higher-order function it : (nat → nat) → nat → nat → nat to be the λ-abstraction λ ( f :nat → nat. λ (n:nat. natrec n {z ⇒ id | s( ) with g ⇒ f ◦ g})), where id = λ (x:nat. x) is the identity, and f ◦ g = λ (x:nat. f (g(x))) is the composition of f and g. It is easy to check that it( f )(n)(m) ≡ f (n) (m) : nat, R EVISED 10.03.2011
D RAFT
V ERSION 1.19
102
11.4 Undefinability
where the latter expression is the n-fold composition of f starting with m. We may then define the Ackermann function ea : nat → nat → nat to be the expression λ (m:nat. natrec m {z ⇒ succ | s( ) with f ⇒ λ (n:nat. it( f )(n)( f (1)))}). It is instructive to check that the following equivalences are valid: ea (0)(n) ≡ s(n)
(11.6)
ea (m + 1)(0) ≡ ea (m)(1)
(11.7)
ea (m + 1)(n + 1) ≡ ea (m)(ea (s(m))(n)).
(11.8)
That is, the Ackermann function is definable in L{nat →}.
11.4
Undefinability
It is impossible to define an infinite loop in L{nat →}. Theorem 11.4. If e : τ, then there exists v val such that e ≡ v : τ. Proof. See Corollary 49.11 on page 516. Consequently, values of function type in L{nat →} behave like mathematical functions: if f : ρ → τ and e : ρ, then f (e) evaluates to a value of type τ. Moreover, if e : nat, then there exists a natural number n such that e ≡ n : nat. Using this, we can show, using a technique called diagonalization, that there are functions on the natural numbers that are not definable in L{nat →}. We make use of a technique, called G¨odel-numbering, that assigns a unique natural number to each closed expression of L{nat →}. This allows us to manipulate expressions as data values in L{nat →}, and hence permits L{nat →} to compute with its own programs.1 ¨ The essence of Godel-numbering is captured by the following simple construction on abstract syntax trees. (The generalization to abstract binding trees is slightly more difficult, the main complication being to ensure 1 The
¨ same technique lies at the heart of the proof of Godel’s celebrated incompleteness theorem. The undefinability of certain functions on the natural numbers within L{nat →} ¨ may be seen as a form of incompleteness similar to that considered by Godel.
V ERSION 1.19
D RAFT
R EVISED 10.03.2011
11.4 Undefinability
103
¨ that all α-equivalent expressions are assigned the same Godel number.) Recall that a general ast, a, has the form o(a1 , . . . , ak ), where o is an operator of arity k. Fix an enumeration of the operators so that every operator has an index i ∈ N, and let m be the index of o in this enumeration. Define the G¨odel number paq of a to be the number 2m 3n1 5n2 . . . pnk k , where pk is the kth prime number (so that p0 = 2, p1 = 3, and so on), and ¨ n1 , . . . , nk are the Godel numbers of a1 , . . . , ak , respectively. This assigns a natural number to each ast. Conversely, given a natural number, n, we may apply the prime factorization theorem to “parse” n as a unique abstract syntax tree. (If the factorization is not of the appropriate form, which can only be because the arity of the operator does not match the number of factors, then n does not code any ast.) Now, using this representation, we may define a (mathematical) function f univ : N → N → N such that, for any e : nat → nat, f univ (peq)(m) = n iff e(m) ≡ n : nat.2 The determinacy of the dynamics, together with Theorem 11.4 on the preceding page, ensure that f univ is a well-defined function. It is called the universal function for L{nat →} because it specifies the behavior of any expression e of type nat → nat. Using the universal function, let us define an auxiliary mathematical function, called the diagonal function, d : N → N, by the equation d(m) = f univ (m)(m). This function is chosen so that d(peq) = n iff e(peq) ≡ n : nat. (The motivation for this definition will become apparent in a moment.) The function d is not definable in L{nat →}. Suppose that d were defined by the expression ed , so that we have ed (peq) ≡ e(peq) : nat. Let e D be the expression λ (x:nat. s(ed (x))) of type nat → nat. We then have e D (pe D q) ≡ s(ed (pe D q))
≡ s(e D (pe D q)). 2 The
value of f univ (k)(m) may be chosen arbitrarily to be zero when k is not the code of any expression e.
R EVISED 10.03.2011
D RAFT
V ERSION 1.19
104
11.5 Notes
But the termination theorem implies that there exists n such that e D (pe D q) ≡ n, and hence we have n ≡ s(n), which is impossible. We say that a language L is universal if it is possible to write an interpreter for L in L itself. It is intuitively evident that f univ is computable in the sense that we can define it in a sufficiently powerful programming language. But the preceding argument shows that L{nat →} is not sufficiently powerful for this task. That is, L{nat →} is not universal. By demanding termination we sacrifice expressiveness. The preceding argument shows that this is an inescapable tradeoff. If you want universality, you have to give up termination, and if you want termination, then you must give up universality. There is no alternative.
11.5
Notes
¨ L{nat →} was introduced by Godel in his study of proofs of proving the ¨ ¨ consistency of arithmetic (Godel, 1980). Godel showed how to “compile” proofs in arithmetic into well-typed terms of the language L{nat →}, and to reduce the consistency problem for arithmetic to the termination of programs in L{nat →}. This was perhaps the first programming language whose design was directly influenced by the verification (of termination) of its programs.
V ERSION 1.19
D RAFT
R EVISED 10.03.2011
Chapter 12
Plotkin’s PCF The language L{nat *}, also known as Plotkin’s PCF, integrates functions and natural numbers using general recursion, a means of defining self-referential expressions. In contrast to L{nat →} expressions in L{nat *} might not terminate when evaluated: its definable functions are, in general, partial rather than total. Informally, the difference between L{nat *} and L{nat →} is that the former moves the proof of termination for an expression from the expression itself into the mind of the programmer. The type system no longer ensures termination, which permits a wider range of functions to be defined in the system, but at the cost of admitting infinite loops when the termination proof is either incorrect or absent. The crucial concept embodied in L{nat *} is the fixed point characterization of recursive definitions. In ordinary mathematical practice one may define a function f by recursion equations such as these: f (0) = 1 f ( n + 1) = ( n + 1) × f ( n ) These may be viewed as simultaneous equations in the variable, f , ranging over functions on the natural numbers. The function we seek is a solution to these equations—a function f : N → N such that the above conditions are satisfied. We must, of course, show that these equations have a unique solution, which is easily shown by mathematical induction on the argument to f . The solution to such a system of equations may be characterized as the fixed point of an associated functional (operator mapping functions to
106 functions). To see this, let us re-write these equations in another form: ( 1 if n = 0 f (n) = 0 n × f (n ) if n = n0 + 1 Re-writing yet again, we seek f such that ( 1 if n = 0 f : n 7→ 0 n × f (n ) if n = n0 + 1 Now define the functional F by the equation F ( f ) = f 0 , where ( 1 if n = 0 0 f : n 7→ 0 n × f (n ) if n = n0 + 1 Note well that the condition on f 0 is expressed in terms of the argument, f , to the functional F, and not in terms of f 0 itself! The function f we seek is then a fixed point of F, which is a function f : N → N such that f = F ( f ). In other words f is defined to the fix( F ), where fix is an operator on functionals yielding a fixed point of F. Why does an operator such as F have a fixed point? Informally, a fixed point may be obtained as the limit of a series of approximations of the desired solution obtained by iterating the functional F. This is where partial functions come into the picture. Let us say that a partial function, φ on the natural numbers, is an approximation to a total function, f , if φ(m) = n implies that f (m) = n. Let ⊥: N * N be the totally undefined partial function—⊥ (n) is undefined for every n ∈ N. Intuitively, this is the “worst” approximation to the desired solution, f , of the recursion equations given above. Given any approximation, φ, of f , we may “improve” it by considering φ0 = F (φ). Intuitively, φ0 is defined on 0 and on m + 1 for every m ≥ 0 on which φ is defined. Continuing in this manner, φ00 = F (φ0 ) = F ( F (φ)) is an improvement on φ0 , and hence a further improvement on φ. If we start with ⊥ as the initial approximation to f , then pass to the limit lim F (i) (⊥), i ≥0
we will obtain the least approximation to f that is defined for every m ∈ N, and hence is the function f itself. Turning this around, if the limit exists, it must be the solution we seek. This fixed point characterization of recursion equations is taken as a primitive concept in L{nat *}—we may obtain the least fixed point of any V ERSION 1.19
D RAFT
R EVISED 10.03.2011
12.1 Statics
107
functional definable in the language. Using this we may solve any set of recursion equations we like, with the proviso that there is no guarantee that the solution is a total function. Rather, it is guaranteed to be a partial function that may be undefined on some, all, or no inputs. This is the price we pay for expressive power—we may solve all systems of equations, but the solution may not be as well-behaved as we might like. It is our task as programmers to ensure that the functions defined by recursion are total— all of our loops terminate.
12.1
Statics
The abstract binding syntax of L{nat *} is given by the following grammar: Typ τ ::= Exp e
::=
nat parr(τ1 ; τ2 ) x z s(e) ifz(e; e0 ; x.e1 ) lam[τ](x.e) ap(e1 ; e2 ) fix[τ](x.e)
nat τ1 * τ2 x z s(e) ifz e {z ⇒ e0 | s(x) ⇒ e1 } λ (x:τ. e) e1 (e2 ) fix x:τ is e
naturals partial function variable zero successor zero test abstraction application recursion
The expression fix[τ](x.e) is called general recursion; it is discussed in more detail below. The expression ifz(e; e0 ; x.e1 ) branches according to whether e evaluates to z or not, binding the predecessor to x in the case that it is not. The statics of L{nat *} is inductively defined by the following rules: Γ, x : τ ` x : τ
(12.1a)
Γ ` z : nat
(12.1b)
Γ ` e : nat Γ ` s(e) : nat
(12.1c)
Γ ` e : nat Γ ` e0 : τ Γ, x : nat ` e1 : τ Γ ` ifz(e; e0 ; x.e1 ) : τ
(12.1d)
Γ, x : τ1 ` e : τ2 Γ ` lam[τ1 ](x.e) : parr(τ1 ; τ2 )
(12.1e)
R EVISED 10.03.2011
D RAFT
V ERSION 1.19
108
12.2 Dynamics Γ ` e1 : parr(τ2 ; τ) Γ ` e2 : τ2 Γ ` ap(e1 ; e2 ) : τ
(12.1f)
Γ, x : τ ` e : τ Γ ` fix[τ](x.e) : τ
(12.1g)
Rule (12.1g) reflects the self-referential nature of general recursion. To show that fix[τ](x.e) has type τ, we assume that it is the case by assigning that type to the variable, x, which stands for the recursive expression itself, and checking that the body, e, has type τ under this very assumption. The structural rules, including in particular substitution, are admissible for the static semantics. Lemma 12.1. If Γ, x : τ ` e0 : τ 0 , Γ ` e : τ, then Γ ` [e/x ]e0 : τ 0 .
12.2
Dynamics
The dynamic semantics of L{nat *} is defined by the judgements e val, specifying the closed values, and e 7→ e0 , specifying the steps of evaluation. We will consider a call-by-name dynamics for function application, and require that the successor evaluate its argument. The judgement e val is defined by the following rules: z val
(12.2a)
{e val} s(e) val
(12.2b)
lam[τ](x.e) val
(12.2c)
The bracketed premise on Rule (12.2b) is to be included for the eager interpretation of the sucessor operation, and omitted for the lazy interpretation. (See Section 12.4 on page 112 for more on this choice, which is further elaborated in Chapter 39). The transition judgement e 7→ e0 is defined by the following rules: e 7→ e0 (12.3a) s(e) 7→ s(e0 )
V ERSION 1.19
e 7→ e0 ifz(e; e0 ; x.e1 ) 7→ ifz(e0 ; e0 ; x.e1 )
(12.3b)
ifz(z; e0 ; x.e1 ) 7→ e0
(12.3c)
D RAFT
R EVISED 10.03.2011
12.2 Dynamics
109 s(e) val ifz(s(e); e0 ; x.e1 ) 7→ [e/x ]e1
(12.3d)
e1 7→ e10 ap(e1 ; e2 ) 7→ ap(e10 ; e2 )
(12.3e)
ap(lam[τ](x.e); e2 ) 7→ [e2 /x ]e
(12.3f)
fix[τ](x.e) 7→ [fix[τ](x.e)/x ]e
(12.3g)
The bracketed Rule (12.3a) is to be included for an eager interpretation of the successor, and omitted otherwise. Rule (12.3g) implements selfreference by substituting the recursive expression itself for the variable x in its body. This is called unwinding the recursion. Theorem 12.2 (Safety).
1. If e : τ and e 7→ e0 , then e0 : τ.
2. If e : τ, then either e val or there exists e0 such that e 7→ e0 . Proof. The proof of preservation is by induction on the derivation of the transition judgement. Consider Rule (12.3g). Suppose that fix[τ](x.e) : τ. By inversion and substitution we have [fix[τ](x.e)/x ]e : τ, from which the result follows directly by transitivity of the hypothetical judgement. The proof of progress proceeds by induction on the derivation of the typing judgement. For example, for Rule (12.1g) the result follows immediately since we may make progress by unwinding the recursion. Definitional equivalence for L{nat *}, written Γ ` e1 ≡ e2 : τ, is defined to be the strongest congruence containing the following axioms: Γ ` ifz(z; e0 ; x.e1 ) ≡ e0 : τ
(12.4a)
Γ ` ifz(s(e); e0 ; x.e1 ) ≡ [e/x ]e1 : τ
(12.4b)
Γ ` fix[τ](x.e) ≡ [fix[τ](x.e)/x ]e : τ
(12.4c)
Γ ` ap(lam[τ](x.e2 ); e1 ) ≡ [e1 /x ]e2 : τ
(12.4d)
These rules are sufficient to calculate the value of any closed expression of type nat: if e : nat, then e ≡ n : nat iff e 7→∗ n. R EVISED 10.03.2011
D RAFT
V ERSION 1.19
110
12.3
12.3 Definability
Definability
General recursion is a very flexible programming technique that permits a wide variety of functions to be defined within L{nat *}. The drawback is that, in contrast to primitive recursion, the termination of a recursively defined function is not intrinsic to the program itself, but rather must be proved extrinsically by the programmer. The benefit is a much greater freedom in writing programs. General recursive functions are definable from general recursion and non-recursive functions. Let us write fun x(y:τ1 ):τ2 is e for a recursive function within whose body, e : τ2 , are bound two variables, y : τ1 standing for the argument and x : τ1 → τ2 standing for the function itself. The dynamic semantics of this construct is given by the axiom fun x(y:τ1 ):τ2 is e(e1 ) 7→ [fun x(y:τ1 ):τ2 is e, e1 /x, y]e
.
That is, to apply a recursive function, we substitute the recursive function itself for x and the argument for y in its body. Recursive functions may be defined in L{nat *} using a combination of recursion and functions, writing fix x:τ1 * τ2 is λ (y:τ1 . e) for fun x(y:τ1 ):τ2 is e. It is a good exercise to check that the static and dynamic semantics of recursive functions are derivable from this definition. The primitive recursion construct of L{nat →} is defined in L{nat *} using recursive functions by taking the expression natrec e {z ⇒ e0 | s(x) with y ⇒ e1 } to stand for the application, e0 (e), where e0 is the general recursive function fun f (u:nat):τ is ifz u {z ⇒ e0 | s(x) ⇒ [ f (x)/y]e1 }. The static and dynamic semantics of primitive recursion are derivable in L{nat *} using this expansion. In general, functions definable in L{nat *} are partial in that they may be undefined for some arguments. A partial (mathematical) function, φ : N * N, is definable in L{nat *} iff there is an expression eφ : nat * nat such that φ(m) = n iff eφ (m) ≡ n : nat. So, for example, if φ is the totally undefined function, then eφ is any function that loops without returning whenever it is called. V ERSION 1.19
D RAFT
R EVISED 10.03.2011
12.3 Definability
111
It is informative to classify those partial functions φ that are definable in L{nat *}. These are the so-called partial recursive functions, which are defined to be the primitive recursive functions augmented by the minimization operation: given φ(m, n), define ψ(n) to be the least m ≥ 0 such that (1) for m0 < m, φ(m0 , n) is defined and non-zero, and (2) φ(m, n) = 0. If no such m exists, then ψ(n) is undefined. Theorem 12.3. A partial function φ on the natural numbers is definable in L{nat *} iff it is partial recursive. Proof sketch. Minimization is readily definable in L{nat *}, so it is at least as powerful as the set of partial recursive functions. Conversely, we may, with considerable tedium, define an evaluator for expressions of L{nat *} ¨ as a partial recursive function, using Godel-numbering to represent expressions as numbers. Consequently, L{nat *} does not exceed the power of the set of partial recursive functions. Church’s Law states that the partial recursive functions coincide with the set of effectively computable functions on the natural numbers—those that can be carried out by a program written in any programming language currently available or that will ever be available.1 Therefore L{nat *} is as powerful as any other programming language with respect to the set of definable functions on the natural numbers. The universal function, φuniv , for L{nat *} is the partial function on the natural numbers defined by φuniv (peq)(m) = n iff e(m) ≡ n : nat. In contrast to L{nat →}, the universal function φuniv for L{nat *} is partial (may be undefined for some inputs). It is, in essence, an interpreter that, given the code peq of a closed expression of type nat * nat, simulates the dynamic semantics to calculate the result, if any, of applying it to the m, obtaining n. Since this process may not terminate, the universal function is not defined for all inputs. By Church’s Law the universal function is definable in L{nat *}. In contrast, we proved in Chapter 11 that the analogous function is not definable in L{nat →} using the technique of diagonalization. It is instructive to examine why that argument does not apply in the present setting. As in Section 11.4 on page 102, we may derive the equivalence e D (pe D q) ≡ s(e D (pe D q)) 1 See
Chapter 19 for further discussion of Church’s Law.
R EVISED 10.03.2011
D RAFT
V ERSION 1.19
112
12.4 Co-Natural Numbers
for L{nat *}. The difference, however, is that this equation is not inconsistent! Rather than being contradictory, it is merely a proof that the expression e D (pe D q) does not terminate when evaluated, for if it did, the result would be a number equal to its own successor, which is impossible.
12.4
Co-Natural Numbers
The dynamics of the successor operation on natural numbers may be taken to be either eager or lazy, according to whether the predecessor of a successor is required to be a value. The eager interpretation represents the standard natural numbers in the sense that if e : nat and e val, then e evaluates to a numeral. The lazy interpretation, however, admits non-standard “natural numbers,” such as ω = fix x:nat is s(x). The “number” ω evaluates to s(ω). This “number” may be thought of as an infinite stack of successors, since whenever we peel off the outermost successor we obtain the same “number” back again. The “number” ω is therefore larger than any other natural number in the sense that one may reach zero by repeatedly taking the predecessor of a natural number, but any number of predecessors on ω leads back to ω itself. As the scare quotes indicate, it is stretching the terminology to refer to ω as a natural number. Instead one should distinguish a new type, called conat, of lazy natural numbers, of which ω is an element. The prefix “co-” indicates that the co-natural numbers are “dual” to the natural numbers in the following sense. The natural numbers are inductively defined as the least type such that if e ≡ z : nat or e ≡ s(e0 ) : nat for some e0 : nat, then e : nat. Dually, the co-natural numbers may be regarded as the largest type such that if e : conat, then either e ≡ z : conat, or e ≡ s(e0 ) : nat for some e0 : conat. The difference is that ω : conat, because ω is definitionally equivalent to its own successor, whereas it is not the case that ω : nat, according to these definitions. The duality between the natural numbers and the co-natural numbers is developed further in Chapter 17, wherein we consider the concepts of inductive and co-inductive types. Eagerness and laziness in general is discussed further in Chapter 39. V ERSION 1.19
D RAFT
R EVISED 10.03.2011
12.5 Notes
12.5
113
Notes
The language L{nat *} is derived from Plotkin (1977). Plotkin introduced PCF to study the relationship between its operational and denotational semantics, but many authors have used PCF as the subject of study for many issues in the design and semantics of languages. In this respect PCF may be thought of as the E. coli of programming languages.
R EVISED 10.03.2011
D RAFT
V ERSION 1.19
114
V ERSION 1.19
12.5 Notes
D RAFT
R EVISED 10.03.2011
Part V
Finite Data Types
Chapter 13
Product Types
The binary product of two types consists of ordered pairs of values, one from each type in the order specified. The associated eliminatory forms are projections, which select the first and second component of a pair. The nullary product, or unit, type consists solely of the unique “null tuple” of no values, and has no associated eliminatory form. The product type admits both a lazy and an eager dynamics. According to the lazy dynamics, a pair is a value without regard to whether its components are values; they are not evaluated until (if ever) they are accessed and used in another computation. According to the eager dynamics, a pair is a value only if its components are values; they are evaluated when the pair is created.
More generally, we may consider the finite product, ∏i∈ I τi , indexed by a finite set of indices, I. The elements of the finite product type are I-indexed tuples whose ith component is an element of the type τi , for each i ∈ I. The components are accessed by I-indexed projection operations, generalizing the binary case. Special cases of the finite product include n-tuples, indexed by sets of the form I = { 0, . . . , n − 1 }, and labelled tuples, or records, indexed by finite sets of symbols. Similarly to binary products, finite products admit both an eager and a lazy interpretation.
118
13.1 Nullary and Binary Products
13.1
Nullary and Binary Products
The abstract syntax of products is given by the following grammar: Typ τ ::= Exp e
::=
unit prod(τ1 ; τ2 ) triv pair(e1 ; e2 ) proj[l](e) proj[r](e)
unit τ1 × τ2 hi h e1 , e2 i e·l e·r
nullary product binary product null tuple ordered pair left projection right projection
There is no elimination form for the unit type, there being nothing to extract from the null tuple. The statics of product types is given by the following rules. (13.1a)
Γ ` triv : unit Γ ` e1 : τ1 Γ ` e2 : τ2 Γ ` pair(e1 ; e2 ) : prod(τ1 ; τ2 )
(13.1b)
Γ ` e : prod(τ1 ; τ2 ) Γ ` proj[l](e) : τ1
(13.1c)
Γ ` e : prod(τ1 ; τ2 ) Γ ` proj[r](e) : τ2
(13.1d)
The dynamics of product types is specified by the following rules: (13.2a)
triv val
{e1 val} {e2 val} pair(e1 ; e2 ) val
V ERSION 1.19
(13.2b)
e1 7→ e10 pair(e1 ; e2 ) 7→ pair(e10 ; e2 )
e1 val e2 7→ e20 pair(e1 ; e2 ) 7→ pair(e1 ; e20 )
(13.2c) (13.2d)
e 7→ e0 proj[l](e) 7→ proj[l](e0 )
(13.2e)
e 7→ e0 proj[r](e) 7→ proj[r](e0 )
(13.2f)
D RAFT
R EVISED 10.03.2011
13.2 Finite Products
119
{e1 val} {e2 val} proj[l](pair(e1 ; e2 )) 7→ e1
(13.2g)
{e1 val} {e2 val} proj[r](pair(e1 ; e2 )) 7→ e2
(13.2h)
The bracketed rules and premises are to be omitted for a lazy dynamics, and included for an eager dynamics of pairing. The safety theorem applies to both the eager and the lazy dynamics, with the proof proceeding along similar lines in each case. Theorem 13.1 (Safety).
1. If e : τ and e 7→ e0 , then e0 : τ.
2. If e : τ then either e val or there exists e0 such that e 7→ e0 . Proof. Preservation is proved by induction on transition defined by Rules (13.2). Progress is proved by induction on typing defined by Rules (13.1).
13.2
Finite Products
The syntax of finite product types is given by the following grammar: Typ τ ::= Exp e ::=
prod[I](i 7→ τi ) ∏i∈ I τi product tuple[I](i 7→ ei ) hei ii∈ I tuple proj[I][i](e) e·i projection
For I a finite index set of size n ≥ 0, the syntactic form prod[I](i 7→ τi ) specifies an n-argument operator of arity (0, 0, . . . , 0) whose ith argument is the type τi . When it is useful to emphasize the tree structure, such an abt is written in the form ∏ hi0 : τ0 , . . . , in−1 : τn−1 i. Similarly, the syntactic form tuple[I](i 7→ ei ) specifies an abt constructed from an n-argument operator whose i operand is ei . This may alternatively be written in the form hi0 : e0 , . . . , in−1 : en−1 i. The statics of finite products is given by the following rules:
(∀i ∈ I ) Γ ` ei : τi Γ ` tuple[I](i 7→ ei ) : prod[I](i 7→ τi )
(13.3a)
Γ ` e : prod[I](i 7→ ei ) j ∈ I Γ ` proj[I][j](e) : τj
(13.3b)
In Rule (13.3b) the index j ∈ I is a particular element of the index set I, whereas in Rule (13.3a), the index i ranges over the index set I. R EVISED 10.03.2011
D RAFT
V ERSION 1.19
120
13.2 Finite Products The dynamics of finite products is given by the following rules:
{(∀i ∈ I ) ei val} tuple[I](i 7→ ei ) val (
e j 7→ e0j
(13.4a)
(∀i 6= j) ei0 = ei
)
tuple[I](i 7→ ei ) 7→ tuple[I](i 7→ ei0 )
(13.4b)
e 7→ e0 proj[I][j](e) 7→ proj[I][j](e0 )
(13.4c)
tuple[I](i 7→ ei ) val proj[I][j](tuple[I](i 7→ ei )) 7→ e j
(13.4d)
Rule (13.4b) specifies that the components of a tuple are to be evaluated in some sequential order, without specifying the order in which they components are considered. It is straightforward, if a bit technically complicated, to impose a linear ordering on index sets that determines the evaluation order of the components of a tuple. Theorem 13.2 (Safety). If e : τ, then either e val or there exists e0 such that e0 : τ and e 7→ e0 . Proof. The safety theorem may be decomposed into progress and preservation lemmas, which are proved as in Section 13.1 on page 118. We may define nullary and binary products as particular instances of finite products by choosing an appropriate index set. The type unit may be defined as the product ∏ ∈∅ ∅ of the empty family over the empty index set, taking the expression hi to be the empty tuple, h∅i ∈∅ . Binary products τ1 × τ2 may be defined as the product ∏i∈{ 1,2 } τi of the two-element family of types consisting of τ1 and τ2 . The pair he1 , e2 i may then be defined as the tuple hei ii∈{ 1,2 } , and the projections e · l and e · r are correspondingly defined, respectively, to be e · 1 and e · 2. Finite products may also be used to define labelled tuples, or records, whose components are accessed by symbolic names. If L = { l1 , . . . , ln } is a finite set of symbols, called field names, or field labels, then the product type ∏ hl0 : τ0 , . . . , ln−1 : τn−1 i has as values tuples of the form hl0 : e0 , . . . , ln−1 : en−1 i in which ei : τi for each 0 ≤ i < n. If e is such a tuple, then e · l projects the component of e labeled by l ∈ L. V ERSION 1.19
D RAFT
R EVISED 10.03.2011
13.3 Primitive and Mutual Recursion
13.3
121
Primitive and Mutual Recursion
In the presence of products we may simplify the primitive recursion construct defined in Chapter 11 so that only the result on the predecessor, and not the predecessor itself, is passed to the successor branch. Writing this as natiter e {z⇒e0 | s(x)⇒e1 }, we may define primitive recursion in the sense of Chapter 11 to be the expression e0 · r, where e0 is the expression natiter e {z⇒hz, e0 i | s(x)⇒hs(x · l), [ x · l, x · r/x0 , x1 ]e1 i}. The idea is to compute inductively both the number, n, and the result of the recursive call on n, from which we can compute both n + 1 and the result of an additional recursion using e1 . The base case is computed directly as the pair of zero and e0 . It is easy to check that the statics and dynamics of the recursor are preserved by this definition. We may also use product types to implement mutual recursion, which allows several mutually recursive computations to be defined simultaneously. For example, consider the following recursion equations defining two mathematical functions on the natural numbers: E (0) = 1 O (0) = 0 E ( n + 1) = O ( n ) O ( n + 1) = E ( n ) Intuitively, E(n) is non-zero iff n is even, and O(n) is non-zero iff n is odd. If we wish to define these functions in L{nat *}, we immediately face the problem of how to define two functions simultaneously. There is a trick available in this special case that takes advantage of the fact that E and O have the same type: simply define eo of type nat → nat → nat so that eo(0) represents E and eo(1) represents O. (We leave the details as an exercise for the reader.) A more general solution is to recognize that the definition of two mutually recursive functions may be thought of as the recursive definition of a pair of functions. In the case of the even and odd functions we will define the labelled tuple, eEO , of type, τEO , given by
∏ heven : nat → nat, odd : nat → nati. From this we will obtain the required mutually recursive functions as the projections eEO · even and eEO · odd. R EVISED 10.03.2011
D RAFT
V ERSION 1.19
122
13.4 Notes To effect the mutual recursion the expression eEO is defined to be fix this:τEO is heven : eE , odd : eO i,
where eE is the expression λ (x:nat. ifz x {z ⇒ s(z) | s(y) ⇒ this · odd(y)}), and eO is the expression λ (x:nat. ifz x {z ⇒ z | s(y) ⇒ this · even(y)}). The functions eE and eO refer to each other by projecting the appropriate component from the variable this standing for the object itself. The choice of variable name with which to effect the self-reference is, of course, immaterial, but it is common to use this or self to emphasize its role.
13.4
Notes
Product types are the essence of structured data. Most languages have some form of product type, but frequently in a form that is mixed up with other features, such as arguments to functions, or with representation commitments, such as pointers or mutability. Objects, in the sense of objectoriented languages, are tuples of mutually recursive functions with shared state. Rather than confound issues, it seems preferable to separate the con¨ cept of product types from other aspects of structured data (Martin-Lof, 1980).
V ERSION 1.19
D RAFT
R EVISED 10.03.2011
Chapter 14
Sum Types Most data structures involve alternatives such as the distinction between a leaf and an interior node in a tree, or a choice in the outermost form of a piece of abstract syntax. Importantly, the choice determines the structure of the value. For example, nodes have children, but leaves do not, and so forth. These concepts are expressed by sum types, specifically the binary sum, which offers a choice of two things, and the nullary sum, which offers a choice of no things. Finite sums generalize nullary and binary sums to permit an arbitrary number of cases indexed by a finite index set. As with products, sums come in both eager and lazy variants, differing in how values of sum type are defined.
14.1
Binary and Nullary Sums
The abstract syntax of sums is given by the following grammar: Typ τ ::= Exp e
::=
void sum(τ1 ; τ2 ) abort[τ](e) in[l][τ](e) in[r][τ](e) case(e; x1 .e1 ; x2 .e2 )
void τ1 + τ2 abortτ e l·e r·e case e {l · x1 ⇒ e1 | r · x2 ⇒ e2 }
nullary sum binary sum abort left injection right injection case analysis
The nullary sum represents a choice of zero alternatives, and hence admits no introductory form. The eliminatory form, abort[τ](e), aborts the computation in the event that e evaluates to a value, which it cannot do. The elements of the binary sum type are labelled to indicate whether
124
14.1 Binary and Nullary Sums
they are drawn from the left or the right summand, either in[l][τ](e) or in[r][τ](e). A value of the sum type is eliminated by case analysis. The statics of sum types is given by the following rules. Γ ` e : void Γ ` abort[τ](e) : τ
(14.1a)
Γ ` e : τ1 τ = sum(τ1 ; τ2 ) (14.1b) Γ ` in[l][τ](e) : τ Γ ` e : τ2 τ = sum(τ1 ; τ2 ) (14.1c) Γ ` in[r][τ](e) : τ Γ ` e : sum(τ1 ; τ2 ) Γ, x1 : τ1 ` e1 : τ Γ, x2 : τ2 ` e2 : τ (14.1d) Γ ` case(e; x1 .e1 ; x2 .e2 ) : τ Both branches of the case analysis must have the same type. Since a type expresses a static “prediction” on the form of the value of an expression, and since a value of sum type could evaluate to either form at run-time, we must insist that both branches yield the same type. The dynamics of sums is given by the following rules: e 7→ e0 abort[τ](e) 7→ abort[τ](e0 )
(14.2a)
{e val} in[l][τ](e) val {e val} in[r][τ](e) val e 7→ e0 in[l][τ](e) 7→ in[l][τ](e0 ) e 7→ e0 in[r][τ](e) 7→ in[r][τ](e0 )
(14.2b) (14.2c) (14.2d) (14.2e)
e 7→ e0 case(e; x1 .e1 ; x2 .e2 ) 7→ case(e0 ; x1 .e1 ; x2 .e2 )
(14.2f)
{e val} case(in[l][τ](e); x1 .e1 ; x2 .e2 ) 7→ [e/x1 ]e1
(14.2g)
{e val} case(in[r][τ](e); x1 .e1 ; x2 .e2 ) 7→ [e/x2 ]e2
(14.2h)
The bracketed premises and rules are to be included for an eager dynamics, and excluded for a lazy dynamics. The coherence of the statics and dynamics is stated and proved as usual. V ERSION 1.19
D RAFT
R EVISED 10.03.2011
14.2 Finite Sums
125 1. If e : τ and e 7→ e0 , then e0 : τ.
Theorem 14.1 (Safety).
2. If e : τ, then either e val or e 7→ e0 for some e0 . Proof. The proof proceeds by induction on Rules (14.2) for preservation, and by induction on Rules (14.1) for progress.
14.2
Finite Sums
Just as we may generalize nullary and binary products to finite products, so may we also generalize nullary and binary sums to finite sums. The syntax for finite sums is given by the following grammar: Typ τ ::= Exp e ::=
sum sum(hi : τi ii∈ I ) ∑i∈ I τi in[hi : τi ii∈ I ][i](e) i·e injection case[I](e; hi : xi .ei ii∈ I ) case e {i · xi ⇒ ei }i∈ I case analysis
The general sum ∑i∈ I τi is sometimes written in the form ∑ hi : τi ii∈ I . The finite family of types hi : τi ii∈ I is often abbreviated to ~τ when the finite index set, I, is clear from context. The statics of finite sums is defined by the following rules: Γ ` e : τi i ∈ I Γ ` in[hi : τi ii∈ I ][i](e) : sum(hi : τi ii∈ I )
(14.3a)
Γ ` e : sum(hi : τi ii∈ I ) (∀i ∈ I ) Γ, xi : τi ` ei : τ Γ ` case[I](e; hi : xi .ei ii∈ I ) : τ
(14.3b)
These rules generalize to the finite case the statics for nullary and binary sums given in Section 14.1 on page 123. The dynamics of finite sums is defined by the following rules:
{e val} in[~τ ][i](e) val
e 7→ e0 in[~τ ][i](e) 7→ in[~τ ][i](e0 )
(14.4a) (14.4b)
e 7→ e0 case[I](e; hi : xi .ei ii∈ I ) 7→ case[I](e0 ; hi : xi .ei ii∈ I )
(14.4c)
in[~τ ][i](e) val case[I](in[~τ ][i](e); hi : xi .ei ii∈ I ) 7→ [e/xi ]ei
(14.4d)
These again generalize the dynamics of binary sums given in Section 14.1 on page 123. R EVISED 10.03.2011
D RAFT
V ERSION 1.19
126
14.3 Applications of Sum Types
Theorem 14.2 (Safety). If e : τ, then either e val or there exists e0 : τ such that e 7→ e0 . Proof. The proof is similar to that for the binary case, as described in Section 14.1 on page 123. As with products, nullary and binary sums are special cases of the finite form. The type void may be defined to be the sum type ∑ ∈∅ ∅ of the empty family of types. The expression abort(e) may corresponding be defined as the empty case analysis, case e {∅}. Similarly, the binary sum type τ1 + τ2 may be defined as the sum ∑i∈ I τi , where I = { l, r } is the two-element index set. The binary sum injections l · e and r · e are defined to be their counterparts, l · e and r · e, respectively. Finally, the binary case analysis, case e {l · xl ⇒ el | r · xr ⇒ er }, is defined to be the case analysis, case e {i · xi ⇒ τi }i∈ I . It is easy to check that the static and dynamics of sums given in Section 14.1 on page 123 is preserved by these definitions. Two special cases of finite sums arise quite commonly. The n-ary sum corresponds to the finite sum over an index set of the form { 0, . . . , n − 1 } for some n ≥ 0. The labelled sum corresponds to the case of the index set being a finite set of symbols serving as symbolic names for the injections.
14.3
Applications of Sum Types
Sum types have numerous uses, several of which we outline here. More interesting examples arise once we also have recursive types, which are introduced in Part VI.
14.3.1
Void and Unit
It is instructive to compare the types unit and void, which are often confused with one another. The type unit has exactly one element, triv, whereas the type void has no elements at all. Consequently, if e : unit, then if e evaluates to a value, it must be unit — in other words, e has no interesting value (but it could diverge). On the other hand, if e : void, then e must not yield a value; if it were to have a value, it would have to be a value of type void, of which there are none. This shows that what is called the void type in many languages is really the type unit because it indicates that an expression has no interesting value, not that it has no value at all! V ERSION 1.19
D RAFT
R EVISED 10.03.2011
14.3 Applications of Sum Types
14.3.2
127
Booleans
Perhaps the simplest example of a sum type is the familiar type of Booleans, whose syntax is given by the following grammar: Typ τ ::= Exp e ::=
bool tt ff if(e; e1 ; e2 )
bool tt ff if e then e1 else e2
booleans truth falsity conditional
The expression if(e; e1 ; e2 ) branches on the value of e : bool. We leave a precise formulation of the static and dynamics of this type as an exercise for the reader. The type bool is definable in terms of binary sums and nullary products: bool = sum(unit; unit)
(14.5a)
tt = in[l][bool](triv)
(14.5b)
ff = in[r][bool](triv)
(14.5c)
if(e; e1 ; e2 ) = case(e; x1 .e1 ; x2 .e2 )
(14.5d)
In the last equation above the variables x1 and x2 are chosen arbitrarily such that x1 ∈ / e1 and x2 ∈ / e2 . (We often write an underscore in place of a variable to stand for a variable that does not occur within its scope.) It is a simple matter to check that the evident static and dynamics of the type bool is engendered by these definitions.
14.3.3
Enumerations
More generally, sum types may be used to define finite enumeration types, those whose values are one of an explicitly given finite set, and whose elimination form is a case analysis on the elements of that set. For example, the type suit, whose elements are ♣, ♦, ♥, and ♠, has as elimination form the case analysis case e {♣ ⇒ e0 | ♦ ⇒ e1 | ♥ ⇒ e2 | ♠ ⇒ e3 }, which distinguishes among the four suits. Such finite enumerations are easily representable as sums. For example, we may define suit = ∑ ∈ I unit, where I = { ♣, ♦, ♥, ♠ } and the type family is constant over this set. The case analysis form for a labelled sum is almost literally the desired case R EVISED 10.03.2011
D RAFT
V ERSION 1.19
128
14.3 Applications of Sum Types
analysis for the given enumeration, the only difference being the binding for the uninteresting value associated with each summand, which we may ignore.
14.3.4
Options
Another use of sums is to define the option types, which have the following syntax: Typ τ ::= Exp e ::=
opt(τ) null just(e) ifnull[τ](e; e1 ; x.e2 )
τ opt option null nothing just(e) something check e {null ⇒ e1 | just(x) ⇒ e2 } null test
The type opt(τ) represents the type of “optional” values of type τ. The introductory forms are null, corresponding to “no value”, and just(e), corresponding to a specified value of type τ. The elimination form discriminates between the two possibilities. The option type is definable from sums and nullary products according to the following equations: opt(τ) = sum(unit; τ)
(14.6a)
null = in[l][opt(τ)](triv)
(14.6b)
just(e) = in[r][opt(τ)](e)
(14.6c)
ifnull[τ](e; e1 ; x2 .e2 ) = case(e; .e1 ; x2 .e2 )
(14.6d)
We leave it to the reader to examine the statics and dynamics implied by these definitions. The option type is the key to understanding a common misconception, the null pointer fallacy. This fallacy, which is particularly common in objectoriented languages, is based on two related errors. The first error is to deem the values of certain types to be mysterious entities called pointers, based on suppositions about how these values might be represented at run-time, rather than on the semantics of the type itself. The second error compounds the first. A particular value of a pointer type is distinguished as the null pointer, which, unlike the other elements of that type, does not designate a value of that type at all, but rather rejects all attempts to use it as such. To help avoid such failures, such languages usually include a function, say null : τ → bool, that yields tt if its argument is null, and ff otherwise. V ERSION 1.19
D RAFT
R EVISED 10.03.2011
14.4 Notes
129
This allows the programmer to take steps to avoid using null as a value of the type it purports to inhabit. Consequently, programs are riddled with conditionals of the form if null(e) then . . . error . . . else . . . proceed . . . .
(14.7)
Despite this, “null pointer” exceptions at run-time are rampant, in part because it is quite easy to overlook the need for such a test, and in part because detection of a null pointer leaves little recourse other than abortion of the program. The underlying problem may be traced to the failure to distinguish the type τ from the type opt(τ). Rather than think of the elements of type τ as pointers, and thereby have to worry about the null pointer, one instead distinguishes between a genuine value of type τ and an optional value of type τ. An optional value of type τ may or may not be present, but, if it is, the underlying value is truly a value of type τ (and cannot be null). The elimination form for the option type, ifnull[τ](e; eerror ; x.eok )
(14.8)
propagates the information that e is present into the non-null branch by binding a genuine value of type τ to the variable x. The case analysis effects a change of type from “optional value of type τ” to “genuine value of type τ”, so that within the non-null branch no further null checks, explicit or implicit, are required. Observe that such a change of type is not achieved by the simple Boolean-valued test exemplified by expression (14.7); the advantage of option types is precisely that it does so.
14.4
Notes
Heterogeneous data structures are ubiquitous. Sums codify heterogeneity, yet few languages properly support them. Much of object-oriented programming is concerned with heterogeneity. Although often confused with types, classes are run-time tags on data, and dispatch is case analysis on the class of a value. Sums correct Hoare’s “billion dollar mistake”, the null reference (Hoare, 2009).
R EVISED 10.03.2011
D RAFT
V ERSION 1.19
130
V ERSION 1.19
14.4 Notes
D RAFT
R EVISED 10.03.2011
Chapter 15
Pattern Matching Pattern matching is a natural and convenient generalization of the elimination forms for product and sum types. For example, rather than write let x be e in x · l + x · r to add the components of a pair, e, of natural numbers, we may instead write match e {h x1 , x2 i ⇒ x1 + x2 }, using pattern matching to name the components of the pair and refer to them directly. The first argument to the match expression is called the match value and the second argument consist of a finite sequence of rules, separated by vertical bars. In this example there is only one rule, but as we shall see shortly there is, in general, more than one rule in a given match expression. Each rule consists of a pattern, possibly involving variables, and an expression that may involve those variables (as well as any others currently in scope). The value of the match is determined by considering each rule in the order given to determine the first rule whose pattern matches the match value. If such a rule is found, the value of the match is the value of the expression part of the matching rule, with the variables of the pattern replaced by the corresponding components of the match value. Pattern matching becomes more interesting, and useful, when combined with sums. The patterns l · x and r · x match the corresponding values of sum type. These may be used in combination with other patterns to express complex decisions about the structure of a value. For example, the following match expresses the computation that, when given a pair of type (unit + unit) × nat, either doubles or squares its second component
132
15.1 A Pattern Language
depending on the form of its first component: match e {hl · hi, x i ⇒ x + x | hr · hi, yi ⇒ y ∗ y}.
(15.1)
It is an instructive exercise to express the same computation using only the primitives for sums and products given in Chapters 13 and 14. In this chapter we study a simple language, L{pat}, of pattern matching over eager product and sum types.
15.1
A Pattern Language
The abstract syntax of L{pat} is defined by the following grammar: Exp Rules Rule Pat
e rs r p
::= ::= ::= ::=
match(e; rs) rules[n](r1 ; . . . ; rn ) rule[k](p; x1 , . . . , xk .e) wild x triv pair(p1 ; p2 ) in[l](p) in[r](p)
match e {rs} case analysis r1 | . . . | r n ( n ≥ 0) p⇒e ( k ≥ 0) wild card x variable hi unit h p1 , p2 i pair l· p left injection r· p right injection
The operator match has arity (0, 0), specifying that it takes two operands, the expression to match and a series of rules. A sequence of rules is constructed using the operatator rules[n], which has arity (0, . . . , 0) specifying that it has n ≥ 0 operands. Each rule is constructed by the operator rule[k] of arity (0, k ) which specifies that it has two operands, binding k variables in the second.
15.2
Statics
The statics of L{pat} makes use of a special form of hypothetical judgement, written x1 : τ1 , . . . , xk : τk p : τ, with almost the same meaning as x1 : τ1 , . . . , xk : τk ` p : τ, except that each variable is required to be used at most once in p. When reading the judgement Λ p : τ it is helpful to think of Λ as an output, V ERSION 1.19
D RAFT
R EVISED 10.03.2011
15.2 Statics
133
and p and τ as inputs. Given p and τ, the rules determine the hypotheses Λ such that Λ p : τ. (15.2a) x:τ x:τ
Λ1 p1 : τ1
∅ :τ
(15.2b)
∅ hi : unit
(15.2c)
Λ2 p2 : τ2 dom(Λ1 ) ∩ dom(Λ2 ) = ∅ Λ1 Λ2 h p1 , p2 i : τ1 × τ2
(15.2d)
Λ1 p : τ1 Λ1 l · p : τ1 + τ2
(15.2e)
Λ2 p : τ2 Λ2 r · p : τ1 + τ2
(15.2f)
Rule (15.2a) states that a variable is a pattern of type τ. Rule (15.2d) states that a pair pattern consists of two patterns with disjoint variables. The typing judgments for a rule, p ⇒ e : τ > τ0, and for a sequence of rules, r1 | . . . | r n : τ > τ 0 , specify that rules transform a value of type τ into a value of type τ 0 . These judgements are inductively defined as follows: Λ p : τ Γ Λ ` e : τ0 Γ ` p ⇒ e : τ > τ0
(15.3a)
Γ ` r1 : τ > τ 0 . . . Γ ` r n : τ > τ 0 Γ ` r1 | . . . | r n : τ > τ 0
(15.3b)
Using the typing judgements for rules, the typing rule for a match expression may be stated quite easily: Γ ` e : τ Γ ` rs : τ > τ 0 Γ ` match e {rs} : τ 0 R EVISED 10.03.2011
D RAFT
(15.4) V ERSION 1.19
134
15.3
15.3 Dynamics
Dynamics
A substitution, θ, is a finite mapping from variables to values. If θ is the substitution h x1 : e1 i ⊗ · · · ⊗ h xk : ek i, we write θˆ(e) for [e1 , . . . , ek /x1 , . . . , xk ]e. The judgement θ : Λ is inductively defined by the following rules: (15.5a)
∅:∅ θ:Λ
θ (x) = e e : τ θ : Λ, x : τ
(15.5b)
The judgement θ p / e states that the pattern, p, matches the value, e, as witnessed by the substitution, θ, defined on the variables of p. This judgement is inductively defined by the following rules:
θ 1 p 1 / e1
h x : ei x / e
(15.6a)
∅ /e
(15.6b)
∅ hi / hi
(15.6c)
θ2 p2 / e2 dom(θ1 ) ∩ dom(θ2 ) = ∅ θ 1 ⊗ θ 2 h p 1 , p 2 i / h e1 , e2 i
(15.6d)
θ p/e θ l· p / l·e
(15.6e)
θ p/e θ r· p / r·e
(15.6f)
These rules simply collect the bindings for the pattern variables required to form a substitution witnessing the success of the matching process. The judgement e ⊥ p states that e does not match the pattern p. It is inductively defined by the following rules:
V ERSION 1.19
e1 ⊥ p 1 h e1 , e2 i ⊥ h p 1 , p 2 i
(15.7a)
e2 ⊥ p 2 h e1 , e2 i ⊥ h p 1 , p 2 i
(15.7b)
l·e ⊥ r· p
(15.7c)
e⊥p l·e ⊥ l· p
(15.7d)
D RAFT
R EVISED 10.03.2011
15.3 Dynamics
135 r·e ⊥ l· p
(15.7e)
e⊥p r·e ⊥ r· p
(15.7f)
Neither a variable nor a wildcard nor a null-tuple can mismatch any value of appropriate type. A pair can only mismatch a pair pattern due to a mismatch in one of its components. An injection into a sum type can mismatch the opposite injection, or it can mismatch the same injection by having its argument mismatch the argument pattern. Theorem 15.1. Suppose that e : τ, e val, and Λ p : τ. Then either there exists θ such that θ : Λ and θ p / e, or e ⊥ p. Proof. By rule induction on Rules (15.2), making use of the canonical forms lemma to characterize the shape of e based on its type. The dynamics of the match expression is given in terms of the pattern match and mismatch judgements as follows: e 7→ e0 match e {rs} 7→ match e0 {rs}
(15.8a)
e val match e {} err
(15.8b)
e val
θ p0 / e
(15.8c)
match e {p0 ⇒ e0 |rs} 7→ θˆ(e0 ) e val e ⊥ p0 match e {rs} 7→ e0 match e {p0 ⇒ e0 |rs} 7→ e0
(15.8d)
Rule (15.8b) specifies that evaluation results in a checked error once all rules are exhausted. Rules (15.8c) specifies that the rules are to be considered in order. If the match value, e, matches the pattern, p0 , of the initial rule in the sequence, then the result is the corresponding instance of e0 ; otherwise, matching continues by considering the remaining rules. Theorem 15.2 (Preservation). If e 7→ e0 and e : τ, then e0 : τ. Proof. By a straightforward induction on the derivation of e 7→ e0 . R EVISED 10.03.2011
D RAFT
V ERSION 1.19
136
15.4 Exhaustiveness and Redundancy
15.4
Exhaustiveness and Redundancy
While it is possible to state and prove a progress theorem for L{pat} as defined in Section 15.1 on page 132, it would not have much force, because the statics does not rule out pattern matching failure. What is missing is enforcement of the exhaustiveness of a sequence of rules, which ensures that every value of the domain type of a sequence of rules must match some rule in the sequence. In addition it would be useful to rule out redundancy of rules, which arises when a rule can only match values that are also matched by a preceding rule. Since pattern matching considers rules in the order in which they are written, such a rule can never be executed, and hence can be safely eliminated.
15.4.1
Match Constraints
To express exhaustiveness and irredundancy, we introduce a language of match constraints that identify a subset of the closed values of a type. With each rule we associate a constraint that classifies the values that are matched by that rule. A sequence of rules is exhaustive if every value of the domain type of the rule satisfies the match constraint of some rule in the sequence. A rule in a sequence is redundant if every value that satisfies its match contraint also satisfies the match constraint of some preceding rule. The language of match constraints is defined by the following grammar: Constr ξ ::=
all[τ] and(ξ 1 ; ξ 2 ) nothing[τ] or(ξ 1 ; ξ 2 ) in[l](ξ 1 ) in[r](ξ 2 ) triv pair(ξ 1 ; ξ 2 )
> ξ1 ∧ ξ2 ⊥ ξ1 ∨ ξ2 l · ξ1 r · ξ2 hi hξ 1 , ξ 2 i
truth conjunction falsity disjunction left injection right injection unit pair
It is easy to define the judgement ξ : τ specifying that the constraint ξ constrains values of type τ. The De Morgan Dual, ξ, of a match constraint, ξ, is defined by the folV ERSION 1.19
D RAFT
R EVISED 10.03.2011
15.4 Exhaustiveness and Redundancy
137
lowing rules:
> =⊥ ξ1 ∧ ξ2 = ξ1 ∨ ξ2
⊥=> ξ1 ∨ ξ2 = ξ1 ∧ ξ2 l · ξ1 = l · ξ1 ∨ r · > r · ξ1 = r · ξ1 ∨ l · >
hi =⊥ hξ 1 , ξ 2 i = hξ 1 , ξ 2 i ∨ hξ 1 , ξ 2 i ∨ hξ 1 , ξ 2 i Intuitively, the dual of a match constraint expresses the negation of that constraint. In the case of the last four rules it is important to keep in mind that these constraints apply only to specific types. The satisfaction judgement, e |= ξ, is defined for values e and constraints ξ of the same type by the following rules: e |= >
(15.9a)
e |= ξ 1 e |= ξ 2 e |= ξ 1 ∧ ξ 2
(15.9b)
e |= ξ 1 e |= ξ 1 ∨ ξ 2
(15.9c)
e |= ξ 2 e |= ξ 1 ∨ ξ 2
(15.9d)
e1 |= ξ 1 l · e1 |= l · ξ 1
(15.9e)
e2 |= ξ 2 r · e2 |= r · ξ 2
(15.9f)
hi |= hi
(15.9g)
e1 |= ξ 1 e2 |= ξ 2 he1 , e2 i |= hξ 1 , ξ 2 i
(15.9h)
The De Morgan dual construction negates a constraint. R EVISED 10.03.2011
D RAFT
V ERSION 1.19
138
15.4 Exhaustiveness and Redundancy
Lemma 15.3. If ξ is a constraint on values of type τ, then e |= ξ if, and only if, e 6|= ξ. We define the entailment of two constraints, ξ 1 |= ξ 2 to mean that e |= ξ 2 whenever e |= ξ 1 . By Lemma 15.3 we have that ξ 1 |= ξ 2 iff |= ξ 1 ∨ ξ 2 . We often write ξ 1 , . . . , ξ n |= ξ for ξ 1 ∧ . . . ∧ ξ n |= ξ so that in particular |= ξ means e |= ξ for every value e : τ.
15.4.2
Enforcing Exhaustiveness and Redundancy
To enforce exhaustiveness and irredundancy the statics of pattern matching is augmented with constraints that express the set of values matched by a given set of rules. A sequence of rules is exhaustive if every value of suitable type satisfies the associated constraint. A rule is redundant relative to the preceding rules if every value satisfying its constraint satisfies one of the preceding constraints. A sequence of rules is irredundant iff no rule is redundant relative to the rules that precede it in the sequence. The judgement Λ p : τ [ξ ] augments the judgement Λ p : τ with a match constraint characterizing the set of values of type τ matched by the pattern p. It is inductively defined by the following rules: x : τ x : τ [>]
(15.10a)
∅ : τ [>]
(15.10b)
∅ hi : unit [hi]
(15.10c)
Λ1 p : τ1 [ξ 1 ] Λ1 l · p : τ1 + τ2 [l · ξ 1 ]
(15.10d)
Λ2 p : τ2 [ξ 2 ] Λ2 r · p : τ1 + τ2 [r · ξ 2 ]
(15.10e)
Λ1 p1 : τ1 [ξ 1 ] Λ2 p2 : τ2 [ξ 2 ] Λ1 # Λ2 Λ1 Λ2 h p1 , p2 i : τ1 × τ2 [hξ 1 , ξ 2 i]
(15.10f)
Lemma 15.4. Suppose that Λ p : τ [ξ ]. For every e : τ such that e val, e |= ξ iff θ p / e for some θ, and e 6|= ξ iff e ⊥ p. The judgement Γ ` r : τ > τ 0 [ξ ] augments the formation judgement for a rule with a match constraint characterizing the pattern component of the rule. The judgement Γ ` rs : τ > τ 0 [ξ ] augments the formation judgement V ERSION 1.19
D RAFT
R EVISED 10.03.2011
15.4 Exhaustiveness and Redundancy
139
for a sequence of rules with a match constraint characterizing the values matched by some rule in the given rule sequence. Λ p : τ [ξ ] Γ Λ ` e : τ 0 Γ ` p ⇒ e : τ > τ 0 [ξ ]
(15.11a)
(∀1 ≤ i ≤ n) ξ i 6|= ξ 1 ∨ . . . ∨ ξ i−1 (15.11b) Γ ` r1 : τ > τ 0 [ ξ 1 ] ... Γ ` rn : τ > τ 0 [ξ n ] Γ ` r1 | . . . | r n : τ > τ 0 [ ξ 1 ∨ . . . ∨ ξ n ] Rule (15.11b) requires that each successive rule not be redundant relative to the preceding rules. The overall constraint associated to the rule sequence specifies that every value of type τ satisfy the constraint associated with some rule. The typing rule for match expressions demands that the rules that comprise it be exhaustive: Γ ` e : τ Γ ` rs : τ > τ 0 [ξ ] Γ ` match e {rs} : τ 0
|= ξ
(15.12)
Rule (15.11b) ensures that ξ is a disjunction of the match constraints associated to the constituent rules of the match expression. The requirement that ξ be valid amounts to requiring that every value of type τ satisfies the constraint of at least one rule of the match. Theorem 15.5. If e : τ, then either e val or there exists e0 such that e 7→ e0 . Proof. The exhaustiveness check in Rule (15.12) ensures that if e val and e : τ, then e |= ξ. The form of ξ given by Rule (15.11b) ensures that e |= ξ i for some constraint ξ i corresponding to the ith rule. By Lemma 15.4 on the preceding page the value e must match the ith rule, which is enough to ensure progress.
15.4.3
Checking Exhaustiveness and Redundancy
Checking exhaustiveness and redundacy reduces to showing that the constraint validity judgement |= ξ is decidable. We will prove this by defining a judgement Ξ incon, where Ξ is a finite set of constraints of the same type, with the meaning that no value of this type satisfies all of the constraints in Ξ. We will then show that either Ξ incon or not. The rules defining inconsistency of a finite set, Ξ, of constraints of the same type are as follows: Ξ incon (15.13a) Ξ, > incon R EVISED 10.03.2011
D RAFT
V ERSION 1.19
140
15.4 Exhaustiveness and Redundancy Ξ, ξ 1 , ξ 2 incon Ξ, ξ 1 ∧ ξ 2 incon
Ξ, ⊥ incon Ξ, ξ 1 incon Ξ, ξ 2 incon Ξ, ξ 1 ∨ ξ 2 incon
Ξ, l · ξ 1 , r · ξ 2 incon
(15.13b)
(15.13c)
(15.13d)
(15.13e)
Ξ incon l · Ξ incon
(15.13f)
Ξ incon r · Ξ incon
(15.13g)
Ξ1 incon hΞ1 , Ξ2 i incon
(15.13h)
Ξ2 incon hΞ1 , Ξ2 i incon
(15.13i)
In Rule (15.13f) we write l · Ξ for the finite set of constraints l · ξ 1 , . . . , l · ξ n , where Ξ = ξ 1 , . . . , ξ n , and similarly in Rules (15.13g), (15.13h), and (15.13i). Lemma 15.6. It is decidable whether or not Ξ incon. Proof. The premises of each rule involves only constraints that are proper components of the constraints in the conclusion. Consequently, we can simplify Ξ by inverting each of the applicable rules until no rule applies, then determine whether or not the resulting set, Ξ0 , is contradictory in the sense that it contains ⊥ or both l · ξ and r · ξ 0 for some ξ and ξ 0 . Lemma 15.7. Ξ incon iff Ξ |= ⊥. Proof. From left to right we proceed by induction on Rules (15.13). From right to left we may show that if Ξ incon is not derivable, then there exists a value e such that e |= Ξ, and hence Ξ 6|= ⊥. V ERSION 1.19
D RAFT
R EVISED 10.03.2011
15.5 Notes
15.5
141
Notes
Pattern-matching against heterogeneous structured data was first explored in the context of logic programming languages, such as Prolog (Kowalski, 1988; Colmerauer and Roussel, 1993), but with an execution model based on proof search. Pattern matching in the form described here is present in the functional languages Miranda (Turner, 1987), Hope (Burstall et al., 1980), Standard ML (Milner et al., 1997), Caml (Cousineau and Mauny, 1998), and Haskell (Jones, 2003).
R EVISED 10.03.2011
D RAFT
V ERSION 1.19
142
V ERSION 1.19
15.5 Notes
D RAFT
R EVISED 10.03.2011
Chapter 16
Generic Programming 16.1
Introduction
Many programs can be seen as instances of a general pattern applied to a particular situation. Very often the pattern is determined by the types of the data involved. For example, in Chapter 11 the pattern of computing by recursion over a natural number is isolated as the defining characteristic of the type of natural numbers. This concept will itself emerge as an instance of the concept of type-generic, or just generic, programming. Suppose that we have a function, f , of type ρ → ρ0 that transforms values of type ρ into values of type ρ0 . For example, f might be the doubling function on natural numbers. We wish to extend f to a transformation from type [ρ/t]τ to type [ρ0 /t]τ by applying f to various spots in the input where a value of type ρ occurs to obtain a value of type ρ0 , leaving the rest of the data structure alone. For example, τ might be bool × ρ, in which case f could be extended to a function of type bool × ρ → bool × ρ0 that sends the pairs h a, bi to the pair h a, f (b)i. This example glosses over a significant problem of ambiguity of the extension. Given a function f of type ρ → ρ0 , it is not obvious in general how to extend it to a function mapping [ρ/t]τ to [ρ0 /t]τ. The problem is that it is not clear which of many occurrences of ρ in [ρ/t]τ are to be transformed by f , even if there is only one occurrence of ρ. To avoid ambiguity we need a way to mark which occurrences of ρ in [ρ/t]τ are to be transformed, and which are to be left fixed. This can be achieved by isolating the type operator, t.τ, which is a type expression in which a designated variable, t, marks the spots at which we wish the transformation to occur. Given t.τ and f : ρ → ρ0 , we can extend f unambiguously to a function of type
144
16.2 Type Operators
[ρ/t]τ → [ρ0 /t]τ. The technique of using a type operator to determine the behavior of a piece of code is called generic programming. The power of generic programming depends on which forms of type operator are considered. The simplest case is that of a polynomial type operator, one constructed from sum and product of types, including their nullary forms. These may be extended to positive type operators, which also permit restricted forms of function types.
16.2
Type Operators
A type operator is a type equipped with a designated variable whose occurrences mark the positions in the type where a transformation is to be applied. A type operator is represented by an abstractor t.τ such that t type ` τ type. An example of a type operator is the abstractor t.unit + (bool × t) in which occurrences of t mark the spots in which a transformation is to be applied. An instance of the type operator t.τ is obtained by substituting a type, ρ, for the variable, t, within the type τ. We sometimes write Map[t.τ](ρ) for the substitution instance [ρ/t]τ. The polynomial type operators are those constructed from the type variable, t, the types void and unit, and the product and sum type constructors, τ1 × τ2 and τ1 + τ2 . It is a straightforward exercise to give inductive definitions of the judgement t.τ poly stating that the operator t.τ is a polynomial type operator.
16.3
Generic Extension
The generic extension primitive has the form map[t.τ](x.e0 ; e) with statics given by the following rule: t type ` τ type Γ, x : ρ ` e0 : ρ0 Γ ` e : [ρ/t]τ Γ ` map[t.τ](x.e0 ; e) : [ρ0 /t]τ
(16.1)
The abstractor x.e0 specifies a transformation from type ρ, the type of x, to type ρ0 , the type of e0 . The expression e of type [ρ/t]τ determines the value V ERSION 1.19
D RAFT
R EVISED 10.03.2011
16.3 Generic Extension
145
to be transformed to obtain a value of type [ρ0 /t]τ. The occurrences of t in τ determine the spots at which the transformation given by x.e is to be performed. The dynamics of generic extension is specified by the following rules. We consider here only polynomial type operators, leaving the extension to positive type operators to be considered later.
map[t.t](x.e0 ; e) 7→ [e/x ]e0 map[t.unit](x.e0 ; e) 7→ hi map[t.τ1 × τ2 ](x.e0 ; e)
7→ 0 hmap[t.τ1 ](x.e ; e · l), map[t.τ2 ](x.e0 ; e · r)i map[t.void](x.e0 ; e) 7→ abort(e)
(16.2a)
(16.2b)
(16.2c)
(16.2d)
map[t.τ1 + τ2 ](x.e0 ; e)
7→ case e {l · x1 ⇒ l · map[t.τ1 ](x.e ; x1 ) | r · x2 ⇒ r · map[t.τ2 ](x.e0 ; x2 )} (16.2e) Rule (16.2a) applies the transformation x.e0 to e itself, since the operator t.t specifies that the transformation is to be perfomed directly. Rule (16.2b) states that the empty tuple is transformed to itself. Rule (16.2c) states that to transform e according to the operator t.τ1 × τ2 , the first component of e is transformed according to t.τ1 and the second component of e is transformed according to t.τ2 . Rule (16.2d) states that the transformation of a value of type void aborts, since there can be no such values. Rule (16.2e) states that to transform e according to t.τ1 + τ2 , case analyze e and reconstruct it after transforming the injected value according to t.τ1 or t.τ2 . Consider the type operator t.τ given by t.unit + (bool × t). Let x.e be the abstractor x.s(x), which increments a natural number. Using Rules (16.2) we may derive that 0
map[t.τ](x.e; r · htt, ni) 7→∗ r · htt, n + 1i. R EVISED 10.03.2011
D RAFT
V ERSION 1.19
146
16.3 Generic Extension
The natural number in the second component of the pair is incremented, since the type variable, t, occurs in that position in the type operator t.τ. Theorem 16.1 (Preservation). If map[t.τ](x.e0 ; e) : τ 0 and map[t.τ](x.e0 ; e) 7→ e00 , then e00 : τ 0 . Proof. By inversion of Rule (16.1) we have 1. t type ` τ type; 2. x : ρ ` e0 : ρ0 for some ρ and ρ0 ; 3. e : [ρ/t]τ; 4. τ 0 is [ρ0 /t]τ. We proceed by cases on Rules (16.2). For example, consider Rule (16.2c). It follows from inversion that map[t.τ1 ](x.e0 ; e · l) : [ρ0 /t]τ1 , and similarly that map[t.τ2 ](x.e0 ; e · r) : [ρ0 /t]τ2 . It is easy to check that
hmap[t.τ1 ](x.e0 ; e · l), map[t.τ2 ](x.e0 ; e · r)i has type [ρ0 /t]τ1 × τ2 , as required. The positive type operators extend the polynomial type operators to admit restricted forms of function type. Specifically, t.τ1 → τ2 is a positive type operator, provided that (1) t does not occur in τ1 , and (2) t.τ2 is a positive type operator. In general, any occurrences of a type variable t in the domain a function type are said to be negative occurrences, whereas any occurrences of t within the range of a function type, or within a product or sum type, are said to be positive occurrences.1 A positive type operator is one for which only positive occurrences of the parameter, t, are permitted. The generic extension according to a positive type operator is defined similarly to the case of a polynomial type operator, with the following additional rule: map[t.τ1 → τ2 ](x.e0 ; e) 7→ λ (x1 :τ1 . map[t.τ2 ](x.e0 ; e(x1 )))
(16.3)
1 The
origin of this terminology seems to be that a function type τ1 → τ2 is analogous to the implication φ1 ⊃ φ2 , which is classically equivalent to ¬φ1 ∨ φ2 , so that occurrences in the domain are under the negation.
V ERSION 1.19
D RAFT
R EVISED 10.03.2011
16.4 Notes
147
Since t is not permitted to occur within the domain type, the type of the result is τ1 → [ρ0 /t]τ2 , assuming that e is of type τ1 → [ρ/t]τ2 . It is easy to verify preservation for the generic extension of a positive type operator. It is interesting to consider what goes wrong if we relax the restriction on positive type operators to admit negative, as well as positive, occurrences of the parameter of a type operator. Consider the type operator t.τ1 → τ2 , without restriction on t, and suppose that x : ρ ` e0 : ρ0 . The generic extension map[t.τ1 → τ2 ](x.e0 ; e) should have type [ρ0 /t]τ1 → [ρ0 /t]τ2 , given that e has type [ρ/t]τ1 → [ρ/t]τ2 . The extension should yield a function of the form 0
λ (x1 :[ρ /t]τ1 . . . .(e(. . .(x1 )))) in which we apply e to a transformation of x1 and then transform the result. The trouble is that we are given, inductively, that map[t.τ1 ](x.e0 ; −) transforms values of type [ρ/t]τ1 into values of type [ρ0 /t]τ1 , but we need to go the other way around in order to make x1 suitable as an argument for e. But there is no obvious way to obtain the required transformation. One solution to this is to assume that the fundamental transformation 0 x.e is invertible so that we may apply the inverse transformation on x1 to get an argument of type suitable for e, then apply the forward transformation on the result, just as in the positive case. Since we cannot invert an arbitrary transformation, we must instead pass both the transformation and its inverse to the generic extension operation so that it can “go backwards” as necessary to cover negative occurrences of the type parameter. So in the general case the generic extension applies only when we are given a type isomorphism (a pair of mutually inverse mappings between two types), and then results in another isomorphism pair. We leave the formulation of this as an exercise for the reader.
16.4
Notes
The concept of the functorial action of a type constructor has its roots in category theory (MacLane, 1998). Generic programming is essentially the application of this idea to programming (Hinze and Jeuring, 2003).
R EVISED 10.03.2011
D RAFT
V ERSION 1.19
148
V ERSION 1.19
16.4 Notes
D RAFT
R EVISED 10.03.2011
Part VI
Infinite Data Types
Chapter 17
Inductive and Co-Inductive Types The inductive and the coinductive types are two important forms of recursive type. Inductive types correspond to least, or initial, solutions of certain type isomorphism equations, and coinductive types correspond to their greatest, or final, solutions. Intuitively, the elements of an inductive type are those that may be obtained by a finite composition of its introductory forms. Consequently, if we specify the behavior of a function on each of the introductory forms of an inductive type, then its behavior is determined for all values of that type. Such a function is called a recursor, or catamorphism. Dually, the elements of a coinductive type are those that behave properly in response to a finite composition of its elimination forms. Consequently, if we specify the behavior of an element on each elimination form, then we have fully specified that element as a value of that type. Such an element is called an generator, or anamorphism.
17.1
Motivating Examples
The most important example of an inductive type is the type of natural numbers as formalized in Chapter 11. The type nat is defined to be the least type containing z and closed under s(−). The minimality condition is witnessed by the existence of the recursor, natiter e {z⇒e0 | s(x)⇒e1 }, which transforms a natural number into a value of type τ, given its value for zero, and a transformation from its value on a number to its value on the successor of that number. This operation is well-defined precisely because there are no other natural numbers. Put the other way around, the existence
152
17.1 Motivating Examples
of this operation expresses the inductive nature of the type nat. With a view towards deriving the type nat as a special case of an inductive type, it is useful to consolidate zero and successor into a single introductory form, and to correspondingly consolidate the basis and inductive step of the recursor. This following rules specify the statics of this reformulation: Γ ` e : unit + nat (17.1a) Γ ` foldnat (e) : nat Γ, x : unit + τ ` e1 : τ Γ ` e2 : nat Γ ` recnat [x.e1 ](e2 ) : τ
(17.1b)
The expression foldnat (e) is the unique introductory form of the type nat. Using this, the expression z is defined to be foldnat (l · hi), and s(e) is defined to be foldnat (r · e). The recursor, recnat [x.e1 ](e2 ), takes as argument the abstractor x.e1 that consolidates the basis and inductive step into a single computation that is given a value of type unit + τ yields a value of type τ. Intuitively, if x is replaced by the value l · hi, then e1 computes the base case of the recursion, and if x is replaced by the value r · e, then e1 computes the inductive step as a function of the result, e, of the recursive call. The dynamics of the consolidated representation of natural numbers is given by the following rules: (17.2a)
foldnat (e) val e2 7→ e20 recnat [x.e1 ](e2 ) 7→ recnat [x.e1 ](e20 )
(17.2b)
recnat [x.e1 ](foldnat (e2 )) 7→
(17.2c)
[map[t.unit + t](y.recnat [x.e1 ](y); e2 )/x ]e1 Rule (17.2c) makes use of generic extension (see Chapter 7) to apply the recursor to the predecessor, if any, of a natural number. The idea is that the result of extending the recursor from the type unit + nat to the type unit + τ is substituted into the inductive step, given by the expression e1 . If we expand the definition of the generic extension in place, we obtain the V ERSION 1.19
D RAFT
R EVISED 10.03.2011
17.1 Motivating Examples
153
following reformulation of this rule:
recnat [x.e1 ](foldnat (e2 ))
7→ [case e2 {l · ⇒ l · hi | r · y ⇒ r · recnat [x.e1 ](y)}/x ]e1 An illustrative example of a coinductive type is the type of streams of natural numbers. A stream is an infinite sequence of natural numbers such that an element of the stream can be computed only after computing all preceding elements in that stream. That is, the computations of successive elements of the stream are sequentially dependent in that the computation of one element influences the computation of the next. This characteristic of the introductory form for streams is dual to the analogous property of the eliminatory form for natural numbers whereby the result for a number is determined by its result for all preceding numbers. A stream is characterized by its behavior under the elimination forms for the stream type: hd(e) returns the next, or head, element of the stream, and tl(e) returns the tail of the stream, the stream resulting when the head element is removed. A stream is introduced by a generator, the dual of a recursor, that determines the head and the tail of the stream in terms of the current state of the stream, which is represented by a value of some type. The statics of streams is given by the following rules: Γ ` e : stream Γ ` hd(e) : nat Γ ` e : stream Γ ` tl(e) : stream Γ ` e : τ Γ, x : τ ` e1 : nat Γ, x : τ ` e2 : τ Γ ` strgen e : stream
(17.3a) (17.3b) (17.3c)
In Rule (17.3c) the current state of the stream is given by the expression e of some type τ, and the head and tail of the stream are determined by the expressions e1 and e2 , respectively, as a function of the current state. The dynamics of streams is given by the following rules:
strgen e val e 7→ e0 hd(e) 7→ hd(e0 ) R EVISED 10.03.2011
D RAFT
(17.4a) (17.4b) V ERSION 1.19
154
17.1 Motivating Examples
hd(strgen e ) 7→ [e/x ]e1 e 7→ e0 tl(e) 7→ tl(e0 )
(17.4c) (17.4d)
tl(strgen e )
7→ strgen [e/x ]e2
(17.4e)
Rules (17.4c) and (17.4e) express the dependency of the head and tail of the stream on its current state. Observe that the tail is obtained by applying the generator to the new state determined by e2 as a function of the current state. To derive streams as a special case of a coinductive type, we consolidate the head and the tail into a single eliminatory form, and reorganize the generator correspondingly. This leads to the following statics: Γ ` e : stream Γ ` unfoldstream (e) : nat × stream
(17.5a)
Γ, x : τ ` e1 : nat × τ Γ ` e2 : τ Γ ` genstream [x.e1 ](e2 ) : stream
(17.5b)
Rule (17.5a) states that a stream may be unfolded into a pair consisting of its head, a natural number, and its tail, another stream. The head, hd(e), and tail, tl(e), of a stream, e, are defined to be the projections unfoldstream (e) · l and unfoldstream (e) · r, respectively. Rule (17.5b) states that a stream may be generated from the state element, e2 , by an expression e1 that yields the head element and the next state as a function of the current state. The dynamics of streams is given by the following rules: (17.6a)
genstream [x.e1 ](e2 ) val e 7→ e0 unfoldstream (e) 7→ unfoldstream (e0 ) unfoldstream (genstream [x.e1 ](e2 )) 7→
(17.6b)
(17.6c)
map[t.nat × t](y.genstream [x.e1 ](y); [e2 /x ]e1 ) V ERSION 1.19
D RAFT
R EVISED 10.03.2011
17.2 Statics
155
Rule (17.6c) uses generic extension to generate a new stream whose state is the second component of [e2 /x ]e1 . Expanding the generic extension we obtain the following reformulation of this rule:
unfoldstream (genstream [x.e1 ](e2 ))
7→ h([e2 /x ]e1 ) · l, genstream [x.e1 ](([e2 /x ]e1 ) · r)i
17.2
Statics
We may now give a fully general account of inductive and coinductive types, which are defined in terms of positive type operators. We will consider the language L{µi µf }, which extends L{→×+} with inductive and co-inductive types.
17.2.1
Types
The syntax of inductive and coinductive types involves type variables, which are, of course, variables ranging over types. The abstract syntax of inductive and coinductive types is given by the following grammar: Typ τ ::=
t t self-reference ind(t.τ) µi (t.τ) inductive coi(t.τ) µf (t.τ) coinductive
Type formation judgements have the form t1 type, . . . , tn type ` τ type, where t1 , . . . , tn are type names. We let ∆ range over finite sets of hypotheses of the form t type, where t name is a type name. The type formation judgement is inductively defined by the following rules:
R EVISED 10.03.2011
∆, t type ` t type
(17.7a)
∆ ` unit type
(17.7b)
∆ ` τ1 type ∆ ` τ2 type ∆ ` prod(τ1 ; τ2 ) type
(17.7c)
∆ ` void type
(17.7d)
D RAFT
V ERSION 1.19
156
17.3 Dynamics
17.2.2
∆ ` τ1 type ∆ ` τ2 type ∆ ` sum(τ1 ; τ2 ) type
(17.7e)
∆ ` τ1 type ∆ ` τ2 type ∆ ` arr(τ1 ; τ2 ) type
(17.7f)
∆, t type ` τ type ∆ ` t.τ pos ∆ ` ind(t.τ) type
(17.7g)
∆, t type ` τ type ∆ ` t.τ pos ∆ ` coi(t.τ) type
(17.8)
Expressions
The abstract syntax of expressions for inductive and coinductive types is given by the following grammar: Exp e ::=
fold[t.τ](e) rec[t.τ][x.e1 ](e2 ) unfold[t.τ](e) gen[t.τ][x.e1 ](e2 )
fold(e) rec[x.e1 ](e2 ) unfold(e) gen[x.e1 ](e2 )
constructor recursor destructor generator
The statics for inductive and coinductive types is given by the following typing rules: Γ ` e : [ind(t.τ)/t]τ (17.9a) Γ ` fold[t.τ](e) : ind(t.τ)
17.3
Γ, x : [ρ/t]τ ` e1 : ρ Γ ` e2 : ind(t.τ) Γ ` rec[t.τ][x.e1 ](e2 ) : ρ
(17.9b)
Γ ` e : coi(t.τ) Γ ` unfold[t.τ](e) : [coi(t.τ)/t]τ
(17.9c)
Γ ` e2 : ρ Γ, x : ρ ` e1 : [ρ/t]τ Γ ` gen[t.τ][x.e1 ](e2 ) : coi(t.τ)
(17.9d)
Dynamics
The dynamics of these constructs is given in terms of the generic extension operation described in Chapter 16. The following rules specify a lazy dynamics for L{µi µf }: fold(e) val V ERSION 1.19
D RAFT
(17.10a) R EVISED 10.03.2011
17.4 Notes
157 e2 7→ e20 rec[x.e1 ](e2 ) 7→ rec[x.e1 ](e20 ) rec[x.e1 ](fold(e2 ))
7→ [map[t.τ](y.rec[x.e1 ](y); e2 )/x ]e1 gen[x.e1 ](e2 ) val e 7→ e0 unfold(e) 7→ unfold(e0 ) unfold(gen[x.e1 ](e2 ))
7→ map[t.τ](y.gen[x.e1 ](y); [e2 /x ]e1 )
(17.10b)
(17.10c)
(17.10d) (17.10e)
(17.10f)
Rule (17.10c) states that to evaluate the recursor on a value of recursive type, we inductively apply the recursor as guided by the type operator to the value, and then perform the inductive step on the result. Rule (17.10f) is simply the dual of this rule for coinductive types. Lemma 17.1. If e : τ and e 7→ e0 , then e0 : τ. Proof. By rule induction on Rules (17.10). Lemma 17.2. If e : τ, then either e val or there exists e0 such that e 7→ e0 . Proof. By rule induction on Rules (17.9).
17.4
Notes
The treatment of inductive and coinductive types is derived from Mendler (1987), which is based on the categorial analysis of these concepts (MacLane, 1998; Taylor, 1999). The functorial action of a type constructor (described in Chapter 16) plays a central role. Specifically, inductive types are initial algebras and coinductive types are final coalgebras for a functor given by a composition of type constructors. The positivity requirement imposed on well-formed inductive and coinductive types ensures that the action of the associated type constructor is properly functorial. R EVISED 10.03.2011
D RAFT
V ERSION 1.19
158
V ERSION 1.19
17.4 Notes
D RAFT
R EVISED 10.03.2011
Chapter 18
Recursive Types Inductive and coinductive types, such as natural numbers and streams, may be seen as examples of fixed points of type operators up to isomorphism. An isomorphism between two types, τ1 and τ2 , is given by two expressions 1. x1 : τ1 ` e2 : τ2 , and 2. x2 : τ2 ` e1 : τ1 that are mutually inverse to each other.1 For example, the types nat and unit + nat are isomorphic, as witnessed by the following two expressions: 1. x : unit + nat ` case x {l · ⇒ z | r · x2 ⇒ s(x2 )} : nat, and 2. x : nat ` ifz x {z ⇒ l · hi | s(x2 ) ⇒ r · x2 } : unit + nat. These are called, respectively, the fold and unfold operations of the isomorphism nat ∼ = unit + nat. Thinking of unit + nat as [nat/t](unit + t), this means that nat is a fixed point of the type operator t.unit + t. In this chapter we study the language L{+×*µ}, which provides solutions to all type isomorphism equations. The recursive type µt.τ is defined to be a solution to the type isomorphism µt.τ ∼ = [µt.τ/t]τ. This is witnessed by the operations x : µt.τ ` unfold(x) : [µt.τ/t]τ 1 To
make this precise requires a discussion of equivalence of expressions to be taken up in Chapter 49. For now we will rely on an intuitive understanding of when two expressions are equivalent.
160
18.1 Solving Type Isomorphisms
and x : [µt.τ/t]τ ` fold(x) : µt.τ, which are mutually inverse to each other. Requiring solutions to all type equations may seem suspicious, since we know by Cantor’s Theorem that an isomorphisms such as X ∼ = ( X → 2) is impossible. This negative result tells us not that our requirement is untenable, but rather that types are not sets. To permit solution of arbitrary type equations, we must take into account that types describe computations, some of which may not even terminate. Consequently, the function space does not coincide with the set-theoretic function space, but rather is analogous to it (in a precise sense that we shall not go into here).
18.1
Solving Type Isomorphisms
The recursive type µt.τ, where t.τ is a type operator, represents a solution for t to the isomorphism t ∼ = τ. The solution is witnessed by two operations, fold(e) and unfold(e), that relate the recursive type µt.τ to its unfolding, [µt.τ/t]τ, and serve, respectively, as its introduction and elimination forms. The language L{+×*µ} extends L{*} with recursive types and their associated operations. Typ τ ::= Exp e
::=
t rec(t.τ) fold[t.τ](e) unfold(e)
t µt.τ fold(e) unfold(e)
self-reference recursive constructor destructor
The statics of L{+×*µ} consists of two forms of judgement. The first, called type formation, is a general hypothetical judgement of the form ∆ ` τ type, where ∆ has the form t1 type, . . . , tk type. Type formation is inductively defined by the following rules:
∆, t type ` t type ∆ ` τ1 type ∆ ` τ2 type ∆ ` arr(τ1 ; τ2 ) type V ERSION 1.19
D RAFT
(18.1a)
(18.1b) R EVISED 10.03.2011
18.2 Recursive Data Structures
161
∆, t type ` τ type ∆ ` rec(t.τ) type
(18.1c)
The second form of judgement comprising the statics is the typing judgement, which is a hypothetical judgement of the form Γ ` e : τ, where we assume that τ type. Typing for L{+×*µ} is inductively defined by the following rules: Γ ` e : [rec(t.τ)/t]τ Γ ` fold[t.τ](e) : rec(t.τ)
(18.2a)
Γ ` e : rec(t.τ) Γ ` unfold(e) : [rec(t.τ)/t]τ
(18.2b)
The dynamics of L{+×*µ} is specified by one axiom stating that the elimination form is inverse to the introduction form.
{e val} fold[t.τ](e) val
e 7→ e0 fold[t.τ](e) 7→ fold[t.τ](e0 )
(18.3a) (18.3b)
e 7→ e0 (18.3c) unfold(e) 7→ unfold(e0 ) fold[t.τ](e) val (18.3d) unfold(fold[t.τ](e)) 7→ e The bracketed premise and rule are to be included for an eager interpretation of the introduction form, and omitted for a lazy interpretation. It is a straightforward exercise to prove type safety for L{+×*µ}. Theorem 18.1 (Safety).
1. If e : τ and e 7→ e0 , then e0 : τ.
2. If e : τ, then either e val, or there exists e0 such that e 7→ e0 .
18.2
Recursive Data Structures
One important application of recursive types is to the representation of inductive data types such as the type of natural numbers. We may think of the type nat as a solution (up to isomorphism) of the type equation nat ∼ = [z : unit, s : nat] R EVISED 10.03.2011
D RAFT
V ERSION 1.19
162
18.2 Recursive Data Structures
According to this isomorphism every natural number is either zero or the successor of another natural number. A solution is given by the recursive type µt.[z : unit, s : t]. (18.4) The introductory forms for the type nat are defined by the following equations: z = fold(z · hi) s(e) = fold(s · e). The conditional branch may then be defined as follows: ifz e {z ⇒ e0 | s(x) ⇒ e1 } = case unfold(e) {z · ⇒ e0 | s · x ⇒ e1 }, where the “underscore” indicates a variable that does not occur free in e0 . It is easy to check that these definitions exhibit the expected behavior. As another example, the type list of lists of natural numbers may be represented by the recursive type µt.[n : unit, c : nat × t] so that we have the isomorphism list ∼ = [n : unit, c : nat × list]. The list formation operations are represented by the following equations: nil = fold(n · hi) cons(e1 ; e2 ) = fold(c · he1 , e2 i). A conditional branch on the form of the list may be defined by the following equation: listcase e {nil ⇒ e0 | cons(x; y) ⇒ e1 } = case unfold(e) {n · ⇒ e0 | c · h x, yi ⇒ e1 }, where we have used an underscore for a “don’t care” variable, and used pattern-matching syntax to bind the components of a pair. As long as sums and products are evaluated eagerly, there is a natural correspondence between this representation of lists and the conventional “blackboard notation” for linked lists. We may think of fold as an abstract V ERSION 1.19
D RAFT
R EVISED 10.03.2011
18.3 Self-Reference
163
heap-allocated pointer to a tagged cell consisting of either (a) the tag n with no associated data, or (b) the tag c attached to a pair consisting of a natural number and another list, which must be an abstract pointer of the same sort. If sums or products are evaluated lazily, then the blackboard notation breaks down because it is unable to depict the suspended computations that are present in the data structure. In general there is no substitute for the type itself. Drawings can be helpful, but the type determines the semantics. We may also represent coinductive types, such as the type of streams of natural numbers, using recursive types. The representation is particularly natural in the case that fold(−) is evaluated lazily, for then we may define the type stream to be the recursive type µt.nat × t. This states that every stream may be thought of as a computation of a pair consisting of a number and another stream. If fold(−) is evaluated eagerly, then we may instead consider the recursive type µt.unit → (nat × t), which expresses the same representation of streams. In either case streams cannot be easily depicted in blackboard notation, not so much because they are infinite, but because there is no accurate way to depict the delayed computation other than by an expression in the programming language. Here again we see that pictures can be helpful, but are not adequate for accurately defining a data structure.
18.3
Self-Reference
In the general recursive expression, fix[τ](x.e), the variable, x, stands for the expression itself. This is ensured by the unrolling transition fix[τ](x.e) 7→ [fix[τ](x.e)/x ]e, which substitutes the expression itself for x in its body during execution. It is useful to think of x as an implicit argument to e, which is to be thought of as a function of x that it implicitly implied to the recursive expression itself whenever it is used. In many well-known languages this implicit argument has a special name, such as this or self, that emphasizes its self-referential interpretation. R EVISED 10.03.2011
D RAFT
V ERSION 1.19
164
18.3 Self-Reference
Using this intuition as a guide, we may derive general recursion from recursive types. This derivation shows that general recursion may, like other language features, be seen as a manifestation of type structure, rather than an ad hoc language feature. The derivation is based on isolating a type of self-referential expressions of type τ, written self(τ). The introduction form of this type is (a variant of) general recursion, written self[τ](x.e), and the elimination form is an operation to unroll the recursion by one step, written unroll(e). The statics of these constructs is given by the following rules: Γ, x : self(τ) ` e : τ (18.5a) Γ ` self[τ](x.e) : self(τ) Γ ` e : self(τ) (18.5b) Γ ` unroll(e) : τ The dynamics is given by the following rule for unrolling the self-reference: (18.6a)
self[τ](x.e) val e 7→ e0 unroll(e) 7→ unroll(e0 )
(18.6b)
unroll(self[τ](x.e)) 7→ [self[τ](x.e)/x ]e
(18.6c)
The main difference, compared to general recursion, is that we distinguish a type of self-referential expressions, rather than impose self-reference at every type. However, as we shall see shortly, the self-referential type is sufficient to implement general recursion, so the difference is largely one of technique. The type self(τ) is definable from recursive types. As suggested earlier, the key is to consider a self-referential expression of type τ to be a function of the expression itself. That is, we seek to define the type self(τ) so that it satisfies the isomorphism self(τ) ∼ = self(τ) → τ. This means that we seek a fixed point of the type operator t.t → τ, where t∈ / τ is a type variable standing for the type in question. The required fixed point is just the recursive type rec(t.t → τ), which we take as the definition of self(τ). V ERSION 1.19
D RAFT
R EVISED 10.03.2011
18.4 Notes
165
The self-referential expression self[τ](x.e) is then defined to be the expression fold(λ (x:self(τ). e)). We may easily check that Rule (18.5a) is derivable according to this definition. The expression unroll(e) is correspondingly defined to be the expression unfold(e)(e). It is easy to check that Rule (18.5b) is derivable from this definition. Moreover, we may check that unroll(self[τ](y.e)) 7→∗ [self[τ](y.e)/y]e. This completes the derivation of the type self(τ) of self-referential expressions of type τ. One consequence of admitting the self-referential type self(τ) is that we may use it to define general recursion at any type. To be precise, we may define fix[τ](x.e) to stand for the expression unroll(self[τ](y.[unroll(y)/x ]e)) in which we have unrolled the recursion at each occurrence of x within e. It is easy to check that this verifies the statics of general recursion given in Chapter 12. Moreover, it also validates the dynamics, as evidenced by the following derivation: fix[τ](x.e) = unroll(self[τ](y.[unroll(y)/x ]e))
7→∗ [unroll(self[τ](y.[unroll(y)/x ]e))/x ]e = [fix[τ](x.e)/x ]e. It follows that recursive types may be used to define a non-terminating expression of every type, namely fix[τ](x.x). Unlike many other type constructs we have considered, recursive types change the meaning of every type, not just those that involve recursion. Recursive types are therefore said to be a non-conservative extension of languages such as L{nat →}, which otherwise admits no non-terminating computations.
18.4
Notes
The systematic study of recursive types in programming was initiated by Scott (1976, 1982) to provide a mathematical model of the untyped λ-calculus. R EVISED 10.03.2011
D RAFT
V ERSION 1.19
166
18.4 Notes
The derivation of recursion from recursive types is essentially an application of Scott’s theory to find the interpretation of a fixed point combinator in a model of the λ-calculus given by a recursive type. The categorytheoretic view of recursive types was developed by Wand (1979) and Smyth and Plotkin (1982).
V ERSION 1.19
D RAFT
R EVISED 10.03.2011
Part VII
Dynamic Types
Chapter 19
The Untyped λ-Calculus Types are the central organizing principle in the study of programming languages. Yet many languages of practical interest are said to be untyped. Have we missed something important? The answer is no! The supposed opposition between typed and untyped languages turns out to be illusory. In fact, untyped languages are special cases of typed languages with a single, pre-determined recursive type. Far from being untyped, such languages are better understood as beinguni-typed.1 In this chapter we study the premier example of a uni-typed programming language, the (untyped) λ-calculus. This formalism was introduced by Church in the 1930’s as a universal language of computable functions. It is distinctive for its austere elegance. The λ-calculus has but one “feature”, the higher-order function. Everything is a function, hence every expression may be applied to an argument, which must itself be a function, with the result also being a function. To borrow a well-worn turn of phrase, in the λ-calculus it’s functions all the way down!
19.1
The λ-Calculus
The abstract syntax of L{λ} is given by the following grammar: Exp u ::=
x x variable λ(x.u) x. u λ-abstraction λ ap(u1 ; u2 ) u1 (u2 ) application
The statics of L{λ} is defined by general hypothetical judgements of the form x1 ok, . . . , xn ok ` u ok, stating that u is a well-formed expression 1 An
apt description of Dana Scott’s.
170
19.1 The λ-Calculus
involving the variables x1 , . . . , xn . (As usual, we omit explicit mention of the parameters when they can be determined from the form of the hypotheses.) This relation is inductively defined by the following rules: Γ, x ok ` x ok
(19.1a)
Γ ` u1 ok Γ ` u2 ok Γ ` ap(u1 ; u2 ) ok
(19.1b)
Γ, x ok ` u ok Γ ` λ(x.u) ok The dynamics is given by the following rules: λ(x.u) val ap(λ(x.u1 ); u2 ) 7→ [u2 /x ]u1 u1 7→ u10 ap(u1 ; u2 ) 7→ ap(u10 ; u2 )
(19.1c)
(19.2a) (19.2b) (19.2c)
In the λ-calculus literature this judgement is called weak head reduction. The first rule is called β-reduction; it defines the meaning of function application as substitution of argument for parameter. Despite the apparent lack of types, L{λ} is nevertheless type safe! Theorem 19.1. If u ok, then either u val, or there exists u0 such that u 7→ u0 and u0 ok. Proof. Exactly as in preceding chapters. We may show by induction on transition that well-formation is preserved by the dynamics. Since every closed value of L{λ} is a λ-abstraction, every closed expression is either a value or can make progress. Definitional equivalence for L{λ} is a judgement of the form Γ ` u ≡ where Γ = x1 ok, . . . , xn ok for some n ≥ 0, and u and u0 are terms having at most the variables x1 , . . . , xn free. It is inductively defined by the following rules: (19.3a) Γ, u ok ` u ≡ u u0 ,
Γ ` u ≡ u0 Γ ` u0 ≡ u Γ ` u ≡ u0 Γ ` u0 ≡ u00 Γ ` u ≡ u00 V ERSION 1.19
D RAFT
(19.3b) (19.3c) R EVISED 10.03.2011
19.2 Definability
171 Γ ` e1 ≡ e10 Γ ` e2 ≡ e20 Γ ` ap(e1 ; e2 ) ≡ ap(e10 ; e20 )
(19.3d)
Γ, x ok ` u ≡ u0 Γ ` λ(x.u) ≡ λ(x.u0 )
(19.3e)
Γ ` ap(λ(x.e2 ); e1 ) ≡ [e1 /x ]e2
(19.3f)
We often write just u ≡ u0 when the variables involved need not be emphasized or are clear from context.
19.2
Definability
Interest in the untyped λ-calculus stems from its surprising expressiveness. It is a Turing-complete language in the sense that it has the same capability to expression computations on the natural numbers as does any other known programming language. Church’s Law states that any conceivable notion of computable function on the natural numbers is equivalent to the λ-calculus. This is certainly true for all known means of defining computable functions on the natural numbers. The force of Church’s Law is that it postulates that all future notions of computation will be equivalent in expressive power (measured by definability of functions on the natural numbers) to the λ-calculus. Church’s Law is therefore a scientific law in the same sense as, say, Newton’s Law of Universal Gravitation, which makes a prediction about all future measurements of the acceleration in a gravitational field.2 We will sketch a proof that the untyped λ-calculus is as powerful as the language PCF described in Chapter 12. The main idea is to show that the PCF primitives for manipulating the natural numbers are definable in the untyped λ-calculus. This means, in particular, that we must show that the natural numbers are definable as λ-terms in such a way that case analysis, which discriminates between zero and non-zero numbers, is definable. The principal difficulty is with computing the predecessor of a number, which requires a bit of cleverness. Finally, we show how to represent general recursion, completing the proof. 2 Unfortunately,
it is common in Computer Science to put forth as “laws” assertions that are not scientific laws at all. For example, Moore’s Law is merely an observation about a near-term trend in microprocessor fabrication that is certainly not valid over the long term, and Amdahl’s Law is but a simple truth of arithmetic. Worse, Church’s Law, which is a proper scientific law, is usually called Church’s Thesis, which, to the author’s ear, suggests something less than the full force of a scientific law.
R EVISED 10.03.2011
D RAFT
V ERSION 1.19
172
19.2 Definability
The first task is to represent the natural numbers as certain λ-terms, called the Church numerals. 0 = λ b. λ s. b n + 1 = λ b. λ s. s(n(b)(s))
(19.4a) (19.4b)
It follows that n(u1 )(u2 ) ≡ u2 (. . . (u2 (u1 ))), the n-fold application of u2 to u1 . That is, n iterates its second argument (the induction step) n times, starting with its first argument (the basis). Using this definition it is not difficult to define the basic functions of arithmetic. For example, successor, addition, and multiplication are defined by the following untyped λ-terms: succ = λ x. λ b. λ s. s(x(b)(s)) plus = λ x. λ y. y(x)(succ)
(19.6)
times = λ x. λ y. y(0)(plus(x))
(19.7)
(19.5)
It is easy to check that succ(n) ≡ n + 1, and that similar correctness conditions hold for the representations of addition and multiplication. To define ifz(u; u0 ; x.u1 ) requires a bit of ingenuity. We wish to find a term pred such that pred(0) ≡ 0 pred(n + 1) ≡ n.
(19.8) (19.9)
To compute the predecessor using Church numerals, we must show how to compute the result for n + 1 as a function of its value for n. At first glance this seems straightforward—just take the successor—until we consider the base case, in which we define the predecessor of 0 to be 0. This invalidates the obvious strategy of taking successors at inductive steps, and necessitates some other approach. What to do? A useful intuition is to think of the computation in terms of a pair of “shift registers” satisfying the invariant that on the nth iteration the registers contain the predecessor of n and n itself, respectively. Given the result for n, namely the pair (n − 1, n), we pass to the result for n + 1 by shifting left and incrementing to obtain (n, n + 1). For the base case, we initialize the registers with (0, 0), reflecting the stipulation that the predecessor of zero be zero. To compute the predecessor of n we compute the pair (n − 1, n) by this method, and return the first component. V ERSION 1.19
D RAFT
R EVISED 10.03.2011
19.2 Definability
173
To make this precise, we must first define a Church-style representation of ordered pairs.
hu1 , u2 i = λ f . f (u1 )(u2 ) u · l = u(λ x. λ y. x) u · r = u(λ x. λ y. y)
(19.10) (19.11) (19.12)
It is easy to check that under this encoding hu1 , u2 i · l ≡ u1 , and that a similar equivalence holds for the second projection. We may now define the required representation, u p , of the predecessor function: u0p = λ x. x(h0, 0i)(λ y. hy · r, s(y · r)i)
(19.13)
u p = λ x. u(x) · l
(19.14)
It is easy to check that this gives us the required behavior. Finally, we may define ifz(u; u0 ; x.u1 ) to be the untyped term u(u0 )(λ . [u p (u)/x ]u1 ). This gives us all the apparatus of PCF, apart from general recursion. But this is also definable using a fixed point combinator. There are many choices of fixed point combinator, of which the best known is the Y combinator: Y = λ F. (λ f . F( f ( f )))(λ f . F( f ( f ))). It is easy to check that Y(F) ≡ F(Y(F)). Using the Y combinator, we may define general recursion by writing Y(λ x. u), where x stands for the recursive expression itself. While it is clear that Y as just defined computes a fixed point of its argument, it is probably less clear why it works or how one might have invented it in the first place. The main idea is actually quite simple: impose the convention that a recursive (self-referential) function takes an additional argument, and require that at each call site of a recursive function that argument is the function itself. If F is the function whose fixed point we seek, then the function λ f . F( f ( f )) is the function that imposes the calling convention on F in the sense that if f is the recursive function in question, then the application F( f ( f )) ensures that all call sites to f are properly selfapplied. To complete the construction, we simply ensure that the function λ f . F( f ( f )) itself adheres to the calling convention, so that Y(F) should be equivalent to λ f . F( f ( f ))(λ f . F( f ( f ))). But this is precisely what the definition of Y ensures! R EVISED 10.03.2011
D RAFT
V ERSION 1.19
174
19.3
19.3 Scott’s Theorem
Scott’s Theorem
Scott’s Theorem states that definitional equivalence for the untyped λ-calculus is undecidable: there is no algorithm to determine whether or not two untyped terms are definitionally equivalent. The proof uses the concept of inseparability. Any two properties, A0 and A1 , of λ-terms are inseparable if there is no decidable property, B , such that A0 u implies that B u and A1 u implies that it is not the case that B u. We say that a property, A, of untyped terms is behavioral iff whenever u ≡ u0 , then A u iff A u0 . The proof of Scott’s Theorem decomposes into two parts: 1. For any untyped λ-term u, we may find an untyped term v such that ¨ u(pvq) ≡ v, where pvq is the Godel number of v, and pvq is its representation as a Church numeral. (See Chapter 11 for a discussion of ¨ Godel-numbering.) 2. Any two non-trivial3 behavioral properties A0 and A1 of untyped terms are inseparable. Lemma 19.2. For any u there exists v such that u(pvq) ≡ v. Proof Sketch. The proof relies on the definability of the following two operations in the untyped λ-calculus: 1. ap(pu1 q)(pu2 q) ≡ pu1 (u2 )q. 2. nm(n) ≡ pnq. Intuitively, the first takes the representations of two untyped terms, and builds the representation of the application of one to the other. The second takes a numeral for n, and yields the representation of n. Given these, we may find the required term v by defining v = w(pwq), where w = λ x. u(ap(x)(nm(x))). We have v = w(pwq)
≡ u(ap(pwq)(nm(pwq))) ≡ u(pw(pwq)q) ≡ u(pvq). 3A
property of untyped terms is said to be trivial if it either holds for all untyped terms or never holds for any untyped term.
V ERSION 1.19
D RAFT
R EVISED 10.03.2011
19.4 Untyped Means Uni-Typed
175
The definition is very similar to that of Y(u), except that u takes as input the representation of a term, and we find a v such that, when applied to the representation of v, the term u yields v itself. Lemma 19.3. Suppose that A0 and A1 are two non-trivial behavioral properties of untyped terms. Then there is no untyped term w such that 1. For every u either w(puq) ≡ 0 or w(puq) ≡ 1. 2. If A0 u, then w(puq) ≡ 0. 3. If A1 u, then w(puq) ≡ 1. Proof. Suppose there is such an untyped term w. Let v be the untyped term λ x. ifz(w(x); u1 ; .u0 ), where A0 u0 and A1 u1 . By Lemma 19.2 on the facing page there is an untyped term t such that v(ptq) ≡ t. If w(ptq) ≡ 0, then t ≡ v(ptq) ≡ u1 , and so A1 t, since A1 is behavioral and A1 u1 . But then w(ptq) ≡ 1 by the defining properties of w, which is a contradiction. Similarly, if w(ptq) ≡ 1, then A0 t, and hence w(ptq) ≡ 0, again a contradiction. Corollary 19.4. There is no algorithm to decide whether or not u ≡ u0 . Proof. For fixed u, the property Eu u0 defined by u0 ≡ u is a non-trivial behavioral property of untyped terms. It is therefore inseparable from its negation, and hence is undecidable.
19.4
Untyped Means Uni-Typed
The untyped λ-calculus may be faithfully embedded in a typed language with recursive types. This means that every untyped λ-term has a representation as a typed expression in such a way that execution of the representation of a λ-term corresponds to execution of the term itself. This embedding is not a matter of writing an interpreter for the λ-calculus in L{+×*µ} (which we could surely do), but rather a direct representation of untyped λ-terms as typed expressions in a language with recursive types. The key observation is that the untyped λ-calculus is really the uni-typed λ-calculus! It is not the absence of types that gives it its power, but rather that it has only one type, namely the recursive type D = µt.t → t. R EVISED 10.03.2011
D RAFT
V ERSION 1.19
176
19.4 Untyped Means Uni-Typed
A value of type D is of the form fold(e) where e is a value of type D → D — a function whose domain and range are both D. Any such function can be regarded as a value of type D by “rolling”, and any value of type D can be turned into a function by “unrolling”. As usual, a recursive type may be seen as a solution to a type isomorphism equation, which in the present case is the equation D∼ = D → D. This specifies that D is a type that is isomorphic to the space of functions on D itself, something that is impossible in conventional set theory, but is feasible in the computationally-based setting of the λ-calculus. This isomorphism leads to the following translation, of L{λ} into L{+×*µ}: x† = x
(19.15a)
† † λ x. u = fold(λ (x:D. u )) †
u1 (u2 ) =
(19.15b)
unfold(u1† )(u2† )
(19.15c)
Observe that the embedding of a λ-abstraction is a value, and that the embedding of an application exposes the function being applied by unrolling the recursive type. Consequently, † † † λ x. u1 (u2 ) = unfold(fold(λ (x:D. u1 )))(u2 )
≡ λ (x:D. u1† )(u2† ) ≡ [u2† /x ]u1† = ([u2 /x ]u1 )† . The last step, stating that the embedding commutes with substitution, is easily proved by induction on the structure of u1 . Thus β-reduction is faithfully implemented by evaluation of the embedded terms. Thus we see that the canonical untyped language, L{λ}, which by dint of terminology stands in opposition to typed languages, turns out to be but a typed language after all! Rather than eliminating types, an untyped language consolidates an infinite collection of types into a single recursive type. Doing so renders static type checking trivial, at the expense of incurring substantial dynamic overhead to coerce values to and from the recursive type. In Chapter 20 we will take this a step further by admitting many different types of data values (not just functions), each of which is a component of a “master” recursive type. This shows that so-called dynamically typed languages are, in fact, statically typed. Thus a traditional distinction V ERSION 1.19
D RAFT
R EVISED 10.03.2011
19.5 Notes
177
can hardly be considered an opposition, since dynamic languages are but particular forms of static language in which (undue) emphasis is placed on a single recursive type.
19.5
Notes
The untyped λ-calculus was introduced by Church (1941) as a codification of the informal concept of a computable function. Unlike the wellknown machine models, such as the Turing machine or the random access machine, the λ-calculus directly codifies mathematical and programming practice. Barendregt (1984) is the definitive reference for all aspects of the untyped λ-calculus; the proof of Scott’s theorem is adapted from Barendregt’s account. Scott (1980) gave the first model of the untyped λ-calculus in terms of an elegant theory of recursive types.
R EVISED 10.03.2011
D RAFT
V ERSION 1.19
178
V ERSION 1.19
19.5 Notes
D RAFT
R EVISED 10.03.2011
Chapter 20
Dynamic Typing We saw in Chapter 19 that an untyped language may be viewed as a unityped language in which the so-called untyped terms are terms of a distinguished recursive type. In the case of the untyped λ-calculus this recursive type has a particularly simple form, expressing that every term is isomorphic to a function. Consequently, no run-time errors can occur due to the misuse of a value—the only elimination form is application, and its first argument can only be a function. Obviously this property breaks down once more than one class of value is permitted into the language. For example, if we add natural numbers as a primitive concept to the untyped λ-calculus (rather than defining them via Church encodings), then it is possible to incur a run-time error arising from attempting to apply a number to an argument, or to add a function to a number. One school of thought in language design is to turn this vice into a virtue by embracing a model of computation that has multiple classes of value of a single type. Such languages are said to be dynamically typed, in purported opposition to statically typed languages. But the supposed opposition is illusory. Just as the untyped λcalculus is really unityped, so dynamic languages are special cases of static languages.
20.1
Dynamically Typed PCF
To illustrate dynamic typing we formulate a dynamically typed version of L{nat *}, called L{dyn}. The abstract syntax of L{dyn} is given by the
180
20.1 Dynamically Typed PCF
following grammar: Exp d ::=
x num(n) zero succ(d) ifz(d; d0 ; x.d1 ) fun(λ x. d) dap(d1 ; d2 ) fix(x.d)
x variable n numeral zero zero succ(d) successor ifz d {zero ⇒ d0 | succ(x) ⇒ d1 } zero test λ(x.d) abstraction d1 (d2 ) application fix x is d recursion
There are two classes of values in L{dyn}, the numbers, which have the form n,1 and the functions, which have the form λ(x.d). The expressions zero and succ(d) are not in themselves values, but rather are operations that evaluate to classified values. The concrete syntax of L{dyn} is somewhat deceptive, in keeping with common practice in dynamic languages. For example, the concrete syntax for a number is a bare numeral, n, but in fact it is just a convenient notation for the classified value, num(n), of class num. Similarly, the concrete syntax for a function is a λ-abstraction, λ(x.d), which must be regarded as standing for the classified value fun(λ x. d) of class fun. The statics of L{dyn} is essentially the same as that of L{λ} given in Chapter 19; it merely checks that there are no free variables in the expression. The judgement x1 ok, . . . xn ok ` d ok states that d is a well-formed expression with free variables among those in the hypothesis list. The dynamics of L{dyn} checks for errors that would never arise in a safe statically typed language. For example, function application must ensure that its first argument is a function, signaling an error in the case that it is not, and similarly the case analysis construct must ensure that its first argument is a number, signaling an error if not. The reason for having classes labelling values is precisely to make this run-time check possible. The value judgement, d val, states that d is a fully evaluated (closed) expression: (20.1a) num(n) val (20.1b)
fun(λ x. d) val 1 The
numerals, n, are n-fold compositions of the form s(s(. . . s(z) . . .)).
V ERSION 1.19
D RAFT
R EVISED 10.03.2011
20.1 Dynamically Typed PCF
181
The dynamics makes use of judgements that check the class of a value, and recover the underlying λ-abstraction in the case of a function. num(n) is num n
(20.2a)
fun(λ x. d) is fun x.d
(20.2b)
The second argument of each of these judgements has a special status—it is not an expression of L{dyn}, but rather just a special piece of syntax used internally to the transition rules given below. We also will need the “negations” of the class-checking judgements in order to detect run-time type errors. num( ) isnt fun
(20.3a)
fun( ) isnt num
(20.3b)
The transition judgement, d 7→ d0 , and the error judgement, d err, are defined simultaneously by the following rules:2 zero 7→ num(z)
(20.4a)
d 7→ d0 succ(d) 7→ succ(d0 )
(20.4b)
d is num n succ(d) 7→ num(s(n))
(20.4c)
d isnt num succ(d) err
(20.4d)
d 7→ d0 ifz(d; d0 ; x.d1 ) 7→ ifz(d0 ; d0 ; x.d1 )
(20.4e)
d is num z ifz(d; d0 ; x.d1 ) 7→ d0
(20.4f)
d is num s(n) ifz(d; d0 ; x.d1 ) 7→ [num(n)/x ]d1
(20.4g)
d isnt num ifz(d; d0 ; x.d1 ) err
(20.4h)
d1 7→ d10 dap(d1 ; d2 ) 7→ dap(d10 ; d2 )
(20.4i)
2 The
obvious error propagation rules discussed in Chapter 8 are omitted here for the sake of concision.
R EVISED 10.03.2011
D RAFT
V ERSION 1.19
182
20.2 Variations and Extensions d1 is fun x.d dap(d1 ; d2 ) 7→ [d2 /x ]d
(20.4j)
d1 isnt fun dap(d1 ; d2 ) err
(20.4k)
fix(x.d) 7→ [fix(x.d)/x ]d
(20.4l)
Rule (20.4g) labels the predecessor with the class num to maintain the invariant that variables are bound to expressions of L{dyn}. The language L{dyn} enjoys essentially the same safety properties as L{nat *}, except that there are more opportunities for errors to arise at run-time. Theorem 20.1 (Safety). If d ok, then either d val, or d err, or there exists d0 such that d 7→ d0 . Proof. By rule induction on Rules (20.4). The rules are designed so that if d ok, then some rule, possibly an error rule, applies, ensuring progress. Since well-formedness is closed under substitution, the result of a transition is always well-formed.
20.2
Variations and Extensions
The dynamic language L{dyn} defined in Section 20.1 on page 179 closely parallels the static language L{nat *} defined in Chapter 12. One discrepancy, however, is in the treatment of natural numbers. Whereas in L{nat *} the zero and successor operations are introductory forms for the type nat, in L{dyn} they are elimination forms that act on separatelydefined numerals. The point of this representation is to ensure that there is a well-defined class of numbers in the language. It is worthwhile to explore an alternative representation that, superficially, is even closer to L{nat *}. Suppose that we eliminate the expression num(n) from the language, but retain zero and succ(d), with the idea that these are to be thought of as introductory forms for numbers in the language. We are faced with the problem that such an expression is well-formed for any well-formed d. So, in particular, the expression succ(λ(x.d)) is a value, as is succ(zero). There is no longer a welldefined class of numbers, but rather two separate classes of values, zero and successor, with no assurance that the successor is of a number. V ERSION 1.19
D RAFT
R EVISED 10.03.2011
20.2 Variations and Extensions
183
The dynamics of the conditional branch changes only slightly, as described by the following rules: d 7→ d0 ifz(d; d0 ; x.d1 ) 7→ ifz(d0 ; d0 ; x.d1 )
(20.5a)
d is zero ifz(d; d0 ; x.d1 ) 7→ d0
(20.5b)
d is succ d0 ifz(d; d0 ; x.d1 ) 7→ [d0 /x ]d1
(20.5c)
d isnt zero d isnt succ ifz(d; d0 ; x.d1 ) err
(20.5d)
The foregoing rules are to be augmented by the following rules that check whether a value is of class zero or successor: zero is zero
succ(d) isnt zero succ(d) is succ d
(20.6a)
(20.6b) (20.6c)
(20.6d) zero isnt succ A peculiarity of this formulation of the conditional is that it can only be understood as distinguishing zero from succ( ), rather than as distinguishing zero from non-zero. The reason is that if d is not zero, it might be either a successor or a function, and hence its “predecessor” is not well-defined. Similar considerations arise when enriching L{dyn} with structured data. The classic example is to enrich the language as follows: Exp d ::=
nil nil null cons(d1 ; d2 ) cons(d1 ; d2 ) pair ifnil(d; d0 ; x, y.d1 ) ifnil d {nil ⇒ d0 | cons(x; y) ⇒ d1 } conditional
The expression ifnil(d; d0 ; x, y.d1 ) distinguishes the null structure from the pair of two structures. We leave to the reader the exercise of formulating the dynamics of this extension. R EVISED 10.03.2011
D RAFT
V ERSION 1.19
184
20.2 Variations and Extensions
An advantage of dynamic typing is that the constructors nil and cons(d1 ; d2 ) are sufficient to build unbounded, as well as bounded, data structures such as lists or trees. For example, the list consisting of three zero’s may be represented by the value cons(zero; cons(zero; cons(zero; nil))). But what to make of this beast? cons(zero; cons(zero; cons(zero; λ(x)x))). It is a perfectly valid expression, but does not correspond to any natural data structure. The disadvantage of this representation becomes apparent as soon as one wishes to define operations on lists, such as the append function: fix a is λ(x.λ(y.ifnil(x; y; x1 , x2 .cons(x1 ; a(x2 )(y))))) What if x is the second list-like value given above? As it stands, the append function will signal an error upon reaching the function at the end of the list. If, however, y is this value, no error is signalled. This asymmetry may seem innocuous, but it is only one simple manifestation of a pervasive problem with dynamic languages: it is impossible to state within the language even the most rudimentary assumptions about the inputs, such as the assumption that both arguments to the append function ought to be genuine lists. The conditional expression ifnil(d; d0 ; x, y.d1 ) is rather ad hoc in that it makes a distinction between nil and all other values. Why not distinguish successors from non-successors, or functions from non-functions? A more systematic approach is to enrich the language with predicates and destructors. Predicates determine whether a value is of a specified class, and destructors recover the value labelled with a given class. Exp d ::=
cond(d; d0 ; d1 ) nil?(d) cons?(d) car(d) cdr(d)
cond(d; d0 ; d1 ) nil?(d) cons?(d) car(d) cdr(d)
conditional nil test pair test first projection second projection
The conditional cond(d; d0 ; d1 ) distinguishes d between nil and all other values. If d is not nil, the conditional evaluates to d0 , and otherwise evaluates to d1 . In other words the value nil represents boolean falsehood, V ERSION 1.19
D RAFT
R EVISED 10.03.2011
20.3 Critique of Dynamic Typing
185
and all other values represent boolean truth. The predicates nil?(d) and cons?(d) test the class of their argument, yielding nil if the argument is not of the specified class, and yielding some non-nil if so. The destructors car(d) and cdr(d)3 decompose cons(d1 ; d2 ) into d1 and d2 , respectively. As an example, the append function may be defined using predicates as follows: fix a is λ(x.λ(y.cond(x; cons(car(x); a(cdr(x))(y)); y))).
20.3
Critique of Dynamic Typing
The safety theorem for L{dyn} is often promoted as an advantage of dynamic over static typing. Unlike static languages, which rule out some candidate programs as ill-typed, essentially every piece of abstract syntax in L{dyn} is well-formed, and hence, by Theorem 20.1 on page 182, has a well-defined dynamics. But this can also be seen as a disadvantage, since errors that could be ruled out at compile time by type checking are not signalled until run time in L{dyn}. To make this possible, the dynamics of L{dyn} must enforce conditions that need not be checked in a statically typed language. Consider, for example, the addition function in L{dyn}, whose specification is that, when passed two values of class num, returns their sum, which is also of class num:4 fun(λ x. fix(p.fun(λ y. ifz(y; x; y0 .succ(p(y0 )))))). The addition function may, deceptively, be written in concrete syntax as follows: λ(x.fix p is λ(y.ifz y {zero ⇒ x | succ(y0 ) ⇒ succ(p(y0 ))})). It is deceptive, because the concrete syntax obscures the class tags on values, and obscures the use of primitives that check those tags. Let us now examine the costs of these operations in a bit more detail. First, observe that the body of the fixed point expression is labelled with class fun. The dynamics of the fixed point construct binds p to this function. This means that the dynamic class check incurred by the application of p in 3 This
terminology for the projections is archaic, but firmly established in the literature. specification imposes no restrictions on the behavior of addition on arguments that are not classified as numbers, but one could make the further demand that the function abort when applied to arguments that are not classified by num. 4 This
R EVISED 10.03.2011
D RAFT
V ERSION 1.19
186
20.4 Notes
the recursive call is guaranteed to succeed. But L{dyn} offers no means of suppressing this redundant check, because it cannot express the invariant that p is always bound to a value of class fun. Second, observe that the result of applying the inner λ-abstraction is either x, the argument of the outer λ-abstraction, or the successor of a recursive call to the function itself. The successor operation checks that its argument is of class num, even though this is guaranteed for all but the base case, which returns the given x, which can be of any class at all. In principle we can check that x is of class num once, and observe that it is otherwise a loop invariant that the result of applying the inner function is of this class. However, L{dyn} gives us no way to express this invariant; the repeated, redundant tag checks imposed by the successor operation cannot be avoided. Third, the argument, y, to the inner function is either the original argument to the addition function, or is the predecessor of some earlier recursive call. But as long as the original call is to a value of class num, then the dynamics of the conditional will ensure that all recursive calls have this class. And again there is no way to express this invariant in L{dyn}, and hence there is no way to avoid the class check imposed by the conditional branch. Classification is not free—storage is required for the class label, and it takes time to detach the class from a value each time it is used and to attach a class to a value whenever it is created. Although the overhead of classification is not asymptotically significant (it slows down the program only by a constant factor), it is nevertheless non-negligible, and should be eliminated whenever possible. But this is impossible within L{dyn}, because it cannot enforce the restrictions required to express the required invariants. For that we need a static type system.
20.4
Notes
The earliest dynamically typed language is Lisp (McCarthy, 1965), which continues to influence language design a half century after its invention. Dynamic PCF is essentially the core of Lisp, but with a proper treatment of variable binding, correcting what McCarthy himself has described as an error in the original design. Informal discussions of dynamic languages are often confused by the ellision of the dynamic checks that are made explicit here. While the surface syntax of dynamic PCF is essentially the same as that for PCF, minus the type annotations, the underlying dynamics is funV ERSION 1.19
D RAFT
R EVISED 10.03.2011
20.4 Notes
187
damentally different. It is for this reason that static PCF cannot be properly seen as a restriction of dynamic PCF by the imposition of a type system, contrary to what seems to be a widely held belief.
R EVISED 10.03.2011
D RAFT
V ERSION 1.19
188
V ERSION 1.19
20.4 Notes
D RAFT
R EVISED 10.03.2011
Chapter 21
Hybrid Typing A hybrid language is one that combines static and dynamic typing by enriching a statically typed language with a distinguished type, dyn, of dynamic values. The dynamically typed language considered in Chapter 20 may be embedded into the hybrid language by regarding a dynamically typed program as a statically typed program of type dyn. This shows that static and dynamic types are not opposed to one another, but may coexist harmoniously. The notion of a hybrid language, however, is itself illusory, because the type dyn is really a particular recursive type. This shows that there is no need for any special mechanisms to support dynamic typing. Rather, they may be derived from the more general concept of a recursive type. Moreover, this shows that dynamic typing is but a mode of use of static typing! The supposed opposition between dynamic and static typing is, therefore, a fallacy: dynamic typing can hardly be opposed to that of which it is but a special case!
21.1
A Hybrid Language
Consider the language L{nat dyn *}, which extends L{nat *} (defined in Chapter 12) with the following additional constructs: Typ τ ::= Exp e ::= Cls
l
::=
dyn new[l](e) cast[l](e) num fun
dyn l·e e·l num fun
dynamic construct destruct number function
190
21.1 A Hybrid Language
The type dyn is the type of dynamically classified values. The new operation attaches a classifier to a value, and the cast operation checks the classifier and returns the associated value. The statics of L{nat dyn *} extends that of L{nat *} with the following additional rules: Γ ` e : nat (21.1a) Γ ` new[num](e) : dyn Γ ` e : dyn * dyn Γ ` new[fun](e) : dyn
(21.1b)
Γ ` e : dyn Γ ` cast[num](e) : nat Γ ` e : dyn Γ ` cast[fun](e) : dyn * dyn
(21.1c) (21.1d)
The statics ensures that class labels are applied to objects of the appropriate type, namely num for natural numbers, and fun for functions defined over labelled values. The dynamics of L{nat dyn *} extends that of L{nat *} with the following rules: e val (21.2a) new[l](e) val e 7→ e0 new[l](e) 7→ new[l](e0 )
(21.2b)
e 7→ e0 cast[l](e) 7→ cast[l](e0 ) new[l](e) val cast[l](new[l](e)) 7→ e
(21.2c) (21.2d)
new[l 0 ](e) val l 6= l 0 (21.2e) cast[l](new[l 0 ](e)) err Casting compares the class of the object to the required class, returning the underlying object if these coincide, and signalling an error otherwise. Lemma 21.1 (Canonical Forms). If e : dyn and e val, then e = new[l](e0 ) for some class l and some e0 val. If l = num, then e0 : nat, and if l = fun, then e0 : dyn * dyn. Proof. By a straightforward rule induction on the statics of L{nat dyn *}. Theorem 21.2 (Safety). The language L{nat dyn *} is safe: V ERSION 1.19
D RAFT
R EVISED 10.03.2011
21.2 Optimization of Dynamic Typing
191
1. If e : τ and e 7→ e0 , then e0 : τ. 2. If e : τ, then either e val, or e err, or e 7→ e0 for some e0 . Proof. Preservation is proved by rule induction on the dynamics, and progress is proved by rule induction on the statics, making use of the canonical forms lemma. The opportunities for run-time errors are the same as those for L{dyn}—a well-typed cast might fail at run-time if the class of the cast does not match the class of the value.
21.2
Optimization of Dynamic Typing
The language L{nat dyn *} combines static and dynamic typing by enriching L{nat *} with the type, dyn, of classified values. It is, for this reason, called a hybrid language. Unlike a purely dynamic type system, a hybrid type system can express invariants that are crucial to the optimization of programs in L{dyn}. Let us examine this in the case of the addition function, which may be defined in L{nat dyn *} as follows: fun · λ (x:dyn. fix p:dyn is fun · λ (y:dyn. ex,p,y )), where x : dyn, p : dyn, y : dyn ` ex,p,y : dyn is defined to be the expression ifz (y · num) {zero ⇒ x | succ(y0 ) ⇒ num · (s((p · fun)(num · y0 ) · num))}. This is a reformulation of the dynamic addition function given in Section 20.3 on page 185 in which we have made explicit the checking and imposition of classes on values. We will exploit the static type system of L{nat dyn *} to optimize this dynamically typed implementation of addition in accordance with the specification given in Section 20.3 on page 185. First, note that the body of the fix expression is an explicitly labelled function. This means that when the recursion is unwound, the variable p is bound to this value of type dyn. Consequently, the check that p is labelled with class fun is redundant, and can be eliminated. This is achieved by rewriting the function as follows: fun · λ (x:dyn. fun · fix p:dyn * dyn is λ (y:dyn. e0x,p,y )), R EVISED 10.03.2011
D RAFT
V ERSION 1.19
192
21.2 Optimization of Dynamic Typing
where e0x,p,y is the expression ifz (y · num) {zero ⇒ x | succ(y0 ) ⇒ num · (s(p(num · y0 ) · num))}. We have “hoisted” the function class label out of the loop, and suppressed the cast inside the loop. Correspondingly, the type of p has changed to dyn * dyn, reflecting that the body is now a “bare function”, rather than a labelled function value of type dyn. Next, observe that the parameter y of type dyn is cast to a number on each iteration of the loop before it is tested for zero. Since this function is recursive, the bindings of y arise in one of two ways, at the initial call to the addition function, and on each recursive call. But the recursive call is made on the predecessor of y, which is a true natural number that is labelled with num at the call site, only to be removed by the class check at the conditional on the next iteration. This suggests that we hoist the check on y outside of the loop, and avoid labelling the argument to the recursive call. Doing so changes the type of the function, however, from dyn * dyn to nat * dyn. Consequently, further changes are required to ensure that the entire function remains well-typed. Before doing so, let us make another observation. The result of the recursive call is checked to ensure that it has class num, and, if so, the underlying value is incremented and labelled with class num. If the result of the recursive call came from an earlier use of this branch of the conditional, then obviously the class check is redundant, because we know that it must have class num. But what if the result came from the other branch of the conditional? In that case the function returns x, which need not be of class num because it is provided by the caller of the function. However, we may reasonably insist that it is an error to call addition with a non-numeric argument. This canbe enforced by replacing x in the zero branch of the conditional by x · num. Combining these optimizations we obtain the inner loop e00x defined as follows: fix p:nat * nat is λ (y:nat. ifz y {zero ⇒ x · num | succ(y0 ) ⇒ s(p(y0 ))}). This function has type nat * nat, and runs at full speed when applied to a natural number—all checks have been hoisted out of the inner loop. Finally, recall that the overall goal is to define a version of addition that works on values of type dyn. Thus we require a value of type dyn * dyn, but what we have at hand is a function of type nat * nat. This can be V ERSION 1.19
D RAFT
R EVISED 10.03.2011
21.3 Static “Versus” Dynamic Typing
193
converted to the required form by pre-composing with a cast to num and post-composing with a coercion to num: fun · λ (x:dyn. fun · λ (y:dyn. num · (e00x (y · num)))). The innermost λ-abstraction converts the function e00x from type nat * nat to type dyn * dyn by composing it with a class check that ensures that y is a natural number at the initial call site, and applies a label to the result to restore it to type dyn.
21.3
Static “Versus” Dynamic Typing
There are many attempts to distinguish dynamic from static typing, all of which are misleading or wrong. For example, it is often said that static type systems associate types with variables, but dynamic type systems associate types with values. This oft-repeated characterization appears to be justified by the absence of type annotations on λ-abstractions, and the presence of classes on values. But it is based on a confusion of classes with types—the class of a value (num or fun) is not its type. Moreover, a static type system assigns types to values just as surely as it does to variables, so the description fails on this account as well. Another way to differentiate dynamic from static languages is to say that whereas static languages check types at compile time, dynamic languages check types at run time. But to say that static languages check types statically is to state a tautology, and to say that dynamic languages check types at run-time is to utter a falsehood. Dynamic languages perform class checking, not type checking, at run-time. For example, application checks that its first argument is labelled with fun; it does not type check the body of the function. Indeed, at no point does the dynamics compute the type of a value, rather it checks its class against its expectations before proceeding. Here again, a supposed contrast between static and dynamic languages evaporates under careful analysis. Another characterization is to assert that dynamic languages admit heterogeneous collections, whereas static languages admit only homogeneous collections. For example, in a dynamic language the elements of a list may be of disparate classes, as illustrated by the expression cons(s(z); cons(λ(λ(x.x)); nil)). But they are nevertheless all of the same type! Put the other way around, a static language with a dynamic type is just as capable of representing a heterogeneous collection as is a dynamic language with only one type. R EVISED 10.03.2011
D RAFT
V ERSION 1.19
194
21.4 Reduction to Recursive Types
What, then, are we to make of the traditional distinction between dynamic and static languages? Rather than being in opposition to each other, we see that dynamic languages are a mode of use of static languages. If we have a type dyn in the language, then we have all of the apparatus of dynamic languages at our disposal, so there is no loss of expressive power. But there is a very significant gain from embedding dynamic typing within a static type discipline! We can avoid much of the overhead of dynamic typing by simply limiting our use of the type dyn in our programs, as was illustrated in Section 21.2 on page 191.
21.4
Reduction to Recursive Types
The type dyn codifies the use of dynamic typing within a static language. Its introduction form labels an object of the appropriate type, and its elimination form is a (possibly undefined) casting operation. Rather than treating dyn as primitive, we may derive it as a particular use of recursive types, according to the following definitions: dyn = µt.[num : nat, fun : t * t]
(21.3)
new[num](e) = fold(num · e)
(21.4)
new[fun](e) = fold(fun · e)
(21.5)
cast[num](e) = case unfold(e) {num · x ⇒ x | fun · x ⇒ error}
(21.6)
cast[fun](e) = case unfold(e) {num · x ⇒ error | fun · x ⇒ x}
(21.7)
One may readily check that the static and dynamics for the type dyn are derivable according to these definitions. This encoding readily generalizes to any number of classes of values: we need only consider additional summands corresponding to each class. For example, to account for the constructors nil and cons(d1 ; d2 ) considered in Chapter 20, the definition of dyn is expanded to the recursive type µt.[num : nat, fun : t * t, nil : unit, cons : t × t], with corresponding definitions for the new and cast operations. This exemplifies the general case: dynamic typing is a mode of use of static types in which classes of values are simply names of summands in a recursive type of dynamic values. V ERSION 1.19
D RAFT
R EVISED 10.03.2011
21.5 Notes
21.5
195
Notes
The concept of a hybrid type system is wholly artificial, serving only as an explanatory bridge between dynamic and static languages. Dynamic typing is but a mode of use of static typing, rather than being, as commonly thought, opposed to it. This point of view was introduced by Scott (1980), who also suggested glossing “untyped languages” as “unityped languages”.
R EVISED 10.03.2011
D RAFT
V ERSION 1.19
196
V ERSION 1.19
21.5 Notes
D RAFT
R EVISED 10.03.2011
Part VIII
Variable Types
Chapter 22
Girard’s System F The languages we have considered so far are all monomorphic in that every expression has a unique type, given the types of its free variables, if it has a type at all. Yet it is often the case that essentially the same behavior is required, albeit at several different types. For example, in L{nat →} there is a distinct identity function for each type τ, namely λ (x:τ. x), even though the behavior is the same for each choice of τ. Similarly, there is a distinct composition operator for each triple of types, namely
◦τ1 ,τ2 ,τ3 = λ ( f :τ2 → τ3 . λ (g:τ1 → τ2 . λ (x:τ1 . f (g(x))))). Each choice of the three types requires a different program, even though they all exhibit the same behavior when executed. Obviously it would be useful to capture the general pattern once and for all, and to instantiate this pattern each time we need it. The expression patterns codify generic (type-independent) behaviors that are shared by all instances of the pattern. Such generic expressions are said to be polymorphic. In this chapter we will study a language introduced by Girard under the name System F and by Reynolds under the name polymorphic typed λcalculus. Although motivated by a simple practical problem (how to avoid writing redundant code), the concept of polymorphism is central to an impressive variety of seemingly disparate concepts, including the concept of data abstraction (the subject of Chapter 23), and the definability of product, sum, inductive, and coinductive types considered in the preceding chapters. (Only general recursive types extend the expressive power of the language.)
200
22.1
22.1 System F
System F
System F, or the polymorphic λ-calculus, or L{→∀}, is a minimal functional language that illustrates the core concepts of polymorphic typing, and permits us to examine its surprising expressive power in isolation from other language features. The syntax of System F is given by the following grammar: Typ τ ::=
Exp e
::=
t arr(τ1 ; τ2 ) all(t.τ) x lam[τ](x.e) ap(e1 ; e2 ) Lam(t.e) App[τ](e)
t τ1 → τ2 ∀(t.τ) x λ (x:τ. e) e1 (e2 ) Λ(t.e) e[τ]
variable function polymorphic abstraction application type abstraction type application
A type abstraction, Lam(t.e), defines a generic, or polymorphic, function with type parameter t standing for an unspecified type within e. A type application, or instantiation, App[τ](e), applies a polymorphic function to a specified type, which is then plugged in for the type parameter to obtain the result. Polymorphic functions are classified by the universal type, all(t.τ), that determines the type, τ, of the result as a function of the argument, t. The statics of L{→∀} consists of two judgement forms, the type formation judgement, ~t | ∆ ` τ type, and the typing judgement,
~t ~x | ∆ Γ ` e : τ. These are generic judgements over type variables ~t and expression variables ~x. They are also hypothetical in a set ∆ of type assumptions of the form t type, where t ∈ T , and typing assumptions of the form x : τ, where x ∈ T and ∆ ` τ type. As usual we drop explicit mention of the parameter sets, relying on typographical conventions to determine them. The rules defining the type formation judgement are as follows:
V ERSION 1.19
∆, t type ` t type
(22.1a)
∆ ` τ1 type ∆ ` τ2 type ∆ ` arr(τ1 ; τ2 ) type
(22.1b)
D RAFT
R EVISED 10.03.2011
22.1 System F
201 ∆, t type ` τ type ∆ ` all(t.τ) type
(22.1c)
The rules defining the typing judgement are as follows: ∆ Γ, x : τ ` x : τ
(22.2a)
∆ ` τ1 type ∆ Γ, x : τ1 ` e : τ2 ∆ Γ ` lam[τ1 ](x.e) : arr(τ1 ; τ2 )
(22.2b)
∆ Γ ` e1 : arr(τ2 ; τ) ∆ Γ ` e2 : τ2 ∆ Γ ` ap(e1 ; e2 ) : τ
(22.2c)
∆, t type Γ ` e : τ ∆ Γ ` Lam(t.e) : all(t.τ)
(22.2d)
∆ Γ ` e : all(t.τ 0 ) ∆ ` τ type ∆ Γ ` App[τ](e) : [τ/t]τ 0
(22.2e)
Lemma 22.1 (Regularity). If ∆ Γ ` e : τ, and if ∆ ` τi type for each assumption xi : τi in Γ, then ∆ ` τ type. Proof. By induction on Rules (22.2). The statics admits the structural rules for a general hypothetical judgement. In particular, we have the following critical substitution property for type formation and expression typing. Lemma 22.2 (Substitution). ∆ ` [τ/t]τ 0 type.
1. If ∆, t type ` τ 0 type and ∆ ` τ type, then
2. If ∆, t type Γ ` e0 : τ 0 and ∆ ` τ type, then ∆ [τ/t]Γ ` [τ/t]e0 : [τ/t]τ 0 . 3. If ∆ Γ, x : τ ` e0 : τ 0 and ∆ Γ ` e : τ, then ∆ Γ ` [e/x ]e0 : τ 0 . The second part of the lemma requires substitution into the context, Γ, as well as into the term and its type, because the type variable t may occur freely in any of these positions. Returning to the motivating examples from the introduction, the polymorphic identity function, I, is written Λ(t.λ (x:t. x)); it has the polymorphic type
∀(t.t → t). R EVISED 10.03.2011
D RAFT
V ERSION 1.19
202
22.1 System F
Instances of the polymorphic identity are written I[τ], where τ is some type, and have the type τ → τ. Similarly, the polymorphic composition function, C, is written Λ(t1 .Λ(t2 .Λ(t3 .λ ( f :t2 → t3 . λ (g:t1 → t2 . λ (x:t1 . f (g(x)))))))). The function C has the polymorphic type
∀(t1 .∀(t2 .∀(t3 .(t2 → t3 ) → (t1 → t2 ) → (t1 → t3 )))). Instances of C are obtained by applying it to a triple of types, writing C[τ1 ][τ2 ][τ3 ]. Each such instance has the type (τ2 → τ3 ) → (τ1 → τ2 ) → (τ1 → τ3 ).
Dynamics The dynamics of L{→∀} is given as follows: lam[τ](x.e) val
(22.3a)
Lam(t.e) val
(22.3b)
ap(lam[τ1 ](x.e); e2 ) 7→ [e2 /x ]e
(22.3c)
e1 7→ e10 ap(e1 ; e2 ) 7→ ap(e10 ; e2 )
(22.3d)
App[τ](Lam(t.e)) 7→ [τ/t]e
(22.3e)
e 7→ e0 App[τ](e) 7→ App[τ](e0 )
(22.3f)
Rule (22.3d) endows L{→∀} with a call-by-name interpretation of application. One could easily define a call-by-value variant as well. It is a simple matter to prove safety for L{→∀}, using familiar methods. Lemma 22.3 (Canonical Forms). Suppose that e : τ and e val, then 1. If τ = arr(τ1 ; τ2 ), then e = lam[τ1 ](x.e2 ) with x : τ1 ` e2 : τ2 . 2. If τ = all(t.τ 0 ), then e = Lam(t.e0 ) with t type ` e0 : τ 0 . Proof. By rule induction on the statics. Theorem 22.4 (Preservation). If e : τ and e 7→ e0 , then e0 : τ. V ERSION 1.19
D RAFT
R EVISED 10.03.2011
22.2 Polymorphic Definability
203
Proof. By rule induction on the dynamics. Theorem 22.5 (Progress). If e : τ, then either e val or there exists e0 such that e 7→ e0 . Proof. By rule induction on the statics.
22.2
Polymorphic Definability
The language L{→∀} is astonishingly expressive. Not only are all finite products and sums definable in the language, but so are all inductive and coinductive types! This is most naturally expressed using definitional equivalence, which is defined to be the least congruence containing the following two axioms: ∆ Γ, x : τ1 ` e : τ2 ∆ Γ ` e1 : τ1 (22.4a) ∆ Γ ` λ (x:τ. e2 )(e1 ) ≡ [e1 /x ]e2 : τ2 ∆, t type Γ ` e : τ ∆ ` ρ type ∆ Γ ` Λ(t.e)[ρ] ≡ [ρ/t]e : [ρ/t]τ
(22.4b)
In addition there are rules omitted here specifying that definitional equivalence is reflexive, symmetric, and transitive, and that it is compatible with both forms of application and abstraction.
22.2.1
Products and Sums
The nullary product, or unit, type is definable in L{→∀} as follows: unit = ∀(r.r → r)
hi = Λ(r.λ (x:r. x)) The identity function plays the role of the null tuple, since it is the only closed value of this type. Binary products are definable in L{→∀} by using encoding tricks similar to those described in Chapter 19 for the untyped λ-calculus: τ1 × τ2 = ∀(r.(τ1 → τ2 → r ) → r)
he1 , e2 i = Λ(r.λ (x:τ1 → τ2 → r. x(e1 )(e2 ))) e · l = e[τ1 ](λ (x:τ1 . λ (y:τ2 . x))) e · r = e[τ2 ](λ (x:τ1 . λ (y:τ2 . y))) R EVISED 10.03.2011
D RAFT
V ERSION 1.19
204
22.2 Polymorphic Definability
The statics given in Chapter 13 is derivable according to these definitions. Moreover, the following definitional equivalences are derivable in L{→∀} from these definitions: he1 , e2 i · l ≡ e1 : τ1 and
he1 , e2 i · r ≡ e2 : τ2 . The nullary sum, or void, type is definable in L{→∀}: void = ∀(r.r) abort[ρ](e) = e[ρ] There is no definitional equivalence to be checked, there being no introductory rule for the void type. Binary sums are also definable in L{→∀}: τ1 + τ2 = ∀(r.(τ1 → r) → (τ2 → r) → r) l · e = Λ(r.λ (x:τ1 → r. λ (y:τ2 → r. x(e)))) r · e = Λ(r.λ (x:τ1 → r. λ (y:τ2 → r. y(e)))) case e {l · x1 ⇒ e1 | r · x2 ⇒ e2 } = e[ρ](λ (x1 :τ1 . e1 ))(λ (x2 :τ2 . e2 )) provided that the types make sense. It is easy to check that the following equivalences are derivable in L{→∀}: case l · d1 {l · x1 ⇒ e1 | r · x2 ⇒ e2 } ≡ [d1 /x1 ]e1 : ρ and case r · d2 {l · x1 ⇒ e1 | r · x2 ⇒ e2 } ≡ [d2 /x2 ]e2 : ρ. Thus the dynamic behavior specified in Chapter 14 is correctly implemented by these definitions.
22.2.2
Natural Numbers
As we remarked above, the natural numbers (under a lazy interpretation) are also definable in L{→∀}. The key is the representation of the iterator, whose typing rule we recall here for reference: e0 : nat e1 : τ x : τ ` e2 : τ . natiter(e0 ; e1 ; x.e2 ) : τ V ERSION 1.19
D RAFT
R EVISED 10.03.2011
22.3 Parametricity Overview
205
Since the result type τ is arbitrary, this means that if we have an iterator, then it can be used to define a function of type nat → ∀(t.t → (t → t) → t). This function, when applied to an argument n, yields a polymorphic function that, for any result type, t, if given the initial result for z, and if given a function transforming the result for x into the result for s(x), then it returns the result of iterating the transformer n times starting with the initial result. Since the only operation we can perform on a natural number is to iterate up to it in this manner, we may simply identify a natural number, n, with the polymorphic iterate-up-to-n function just described. This means that we may define the type of natural numbers in L{→∀} by the following equations: nat = ∀(t.t → (t → t) → t) z = Λ(t.λ (z:t. λ (s:t → t. z))) s(e) = Λ(t.λ (z:t. λ (s:t → t. s(e[t](z)(s))))) natiter(e0 ; e1 ; x.e2 ) = e0 [τ](e1 )(λ (x:τ. e2 )) It is a straightforward exercise to check that the static and dynamics given in Chapter 11 is derivable in L{→∀} under these definitions. This shows that L{→∀} is at least as expressive as L{nat →}. But is it more expressive? Yes! It is possible to show that the evaluation function for L{nat →} is definable in L{→∀}, even though it is not definable in L{nat →} itself. However, the same diagonal argument given in Chapter 11 applies here, showing that the evaluation function for L{→∀} is not definable in L{→∀}. We may enrich L{→∀} a bit more to define the evaluator for L{→∀}, but as long as all programs in the enriched language terminate, we will once again have an undefinable function, the evaluation function for that extension.
22.3
Parametricity Overview
A remarkable property of L{→∀} is that polymorphic types severely constrain the behavior of their elements. One may prove useful theorems about an expression knowing only its type—that is, without ever looking at the code! For example, if i is any expression of type ∀(t.t → t), then it must be the identity function. Informally, when i is applied to a type, τ, and R EVISED 10.03.2011
D RAFT
V ERSION 1.19
206
22.4 Restricted Forms of Polymorphism
an argument of type τ, it must return a value of type τ. But since τ is not specified until i is called, the function has no choice but to return its argument, which is to say that it is essentially the identity function. Similarly, if b is any expression of type ∀(t.t → t → t), then b must be either Λ(t.λ (x:t. λ (y:t. x))) or Λ(t.λ (x:t. λ (y:t. y))). For when b is applied to two arguments of some type, its only choice to return a value of that type is to return one of the two. What is remarkable is that these properties of i and b have been derived without knowing anything about the expressions themselves, but only their types! The theory of parametricity implies that we are able to derive theorems about the behavior of a program knowing only its type. Such theorems are sometimes called free theorems because they come “for free” as a consequence of typing, and require no program analysis or verification to derive (beyond the once-and-for-all proof of Theorem 51.8 on page 539). Free theorems such as those illustrated above underly the experience that in a polymorphic language, well-typed programs tend to behave as expected no further debugging or analysis required. Parametricity so constrains the behavior of a program that it is relatively easy to ensure that the code works just by checking its type. Free theorems also underly the principle of representation independence for abstract types, which is discussed further in Chapter 23.
22.4
Restricted Forms of Polymorphism
In this section we briefly examine some restricted forms of polymorphism with less than the full expressive power of L{→∀}. These are obtained in one of two ways: 1. Restricting type quantification to unquantified types. 2. Restricting the occurrence of quantifiers within types.
22.4.1
Predicative Fragment
The remarkable expressive power of the language L{→∀} may be traced to the ability to instantiate a polymorphic type with another polymorphic type. For example, if we let τ be the type ∀(t.t → t), and, assuming that e : τ, we may apply e to its own type, obtaining the expression e[τ] of type τ → τ. Written out in full, this is the type
∀(t.t → t) → ∀(t.t → t), V ERSION 1.19
D RAFT
R EVISED 10.03.2011
22.4 Restricted Forms of Polymorphism
207
which is larger (both textually, and when measured by the number of occurrences of quantified types) than the type of e itself. In fact, this type is large enough that we can go ahead and apply e[τ] to e again, obtaining the expression e[τ](e), which is again of type τ — the very type of e! This property of L{→∀} is called impredicativity1 ; the language L{→∀} is said to permit impredicative (type) quantification. The distinguishing characteristic of impredicative polymorphism is that it involves a kind of circularity in that the meaning of a quantified type is given in terms of its instances, including the quantified type itself. This quasi-circularity is responsible for the surprising expressive power of L{→∀}, and is correspondingly the prime source of complexity when reasoning about it (for example, in the proof that all expressions of L{→∀} terminate). Contrast this with L{→}, in which the type of an application of a function is evidently smaller than the type of the function itself. For if e : τ1 → τ2 , and e1 : τ1 , then we have e(e1 ) : τ2 , a smaller type than the type of e. This situation extends to polymorphism, provided that we impose the restriction that a quantified type can only be instantiated by an un-quantified type. For in that case passage from ∀(t.τ) to [ρ/t]τ decreases the number of quantifiers (even if the size of the type expression viewed as a tree grows). For example, the type ∀(t.t → t) may be instantiated with the type u → u to obtain the type (u → u) → (u → u). This type has more symbols in it than τ, but is smaller in that it has fewer quantifiers. The restriction to quantification only over unquantified types is called predicative2 polymorphism. The predicative fragment is significantly less expressive than the full impredicative language. In particular, the natural numbers are no longer definable in it.
22.4.2
Prenex Fragment
A rather more restricted form of polymorphism, called the prenex fragment, further restricts polymorphism to occur only at the outermost level — not only is quantification predicative, but quantifiers are not permitted to occur within the arguments to any other type constructors. This restriction, called prenex quantification, is often imposed for the sake of type inference, which permits type annotations to be omitted entirely in the knowledge that they can be recovered from the way the expression is used. We will not discuss type inference here, but we will give a formulation of the prenex fragment 1 pronounced 2 pronounced
im-PRED-ic-a-tiv-it-y PRED-i-ca-tive
R EVISED 10.03.2011
D RAFT
V ERSION 1.19
208
22.4 Restricted Forms of Polymorphism
of L{→∀}, because it plays an important role in the design of practical polymorphic languages. The prenex fragment of L{→∀} is designated L1 {→∀}, for reasons that will become clear in the next subsection. It is defined by stratifying types into two sorts, the monotypes (or rank-0 types) and the polytypes (or rank-1 types). The monotypes are those that do not involve any quantification, and may be used to instantiate the polymorphic quantifier. The polytypes include the monotypes, but also permit quantification over monotypes. These classifications are expressed by the judgements ∆ ` τ mono and ∆ ` τ poly, where ∆ is a finite set of hypotheses of the form t mono, where t is a type variable not otherwise declared in ∆. The rules for deriving these judgements are as follows: ∆, t mono ` t mono
(22.5a)
∆ ` τ1 mono ∆ ` τ2 mono ∆ ` arr(τ1 ; τ2 ) mono
(22.5b)
∆ ` τ mono ∆ ` τ poly
(22.5c)
∆, t mono ` τ poly ∆ ` all(t.τ) poly
(22.5d)
Base types, such as nat (as a primitive), or other type constructors, such as sums and products, would be added to the language as monotypes. The statics of L1 {→∀} is given by rules for deriving hypothetical judgements of the form ∆ Γ ` e : ρ, where ∆ consists of hypotheses of the form t mono, and Γ consists of hypotheses of the form x : ρ, where ∆ ` ρ poly. The rules defining this judgement are as follows:
V ERSION 1.19
∆ Γ, x : τ ` x : τ
(22.6a)
∆ ` τ1 mono ∆ Γ, x : τ1 ` e2 : τ2 ∆ Γ ` lam[τ1 ](x.e2 ) : arr(τ1 ; τ2 )
(22.6b)
∆ Γ ` e1 : arr(τ2 ; τ) ∆ Γ ` e2 : τ2 ∆ Γ ` ap(e1 ; e2 ) : τ
(22.6c)
∆, t mono Γ ` e : τ ∆ Γ ` Lam(t.e) : all(t.τ)
(22.6d)
∆ ` τ mono ∆ Γ ` e : all(t.τ 0 ) ∆ Γ ` App[τ](e) : [τ/t]τ 0
(22.6e)
D RAFT
R EVISED 10.03.2011
22.4 Restricted Forms of Polymorphism
209
We tacitly exploit the inclusion of monotypes as polytypes so that all typing judgements have the form e : ρ for some expression e and polytype ρ. The restriction on the domain of a λ-abstraction to be a monotype means that a fully general let construct is no longer definable—there is no means of binding an expression of polymorphic type to a variable. For this reason it is usual to augment L{→∀p } with a primitive let construct whose statics is as follows: ∆ ` τ1 poly ∆ Γ ` e1 : τ1 ∆ Γ, x : τ1 ` e2 : τ2 . ∆ Γ ` let[τ1 ](e1 ; x.e2 ) : τ2
(22.7)
For example, the expression let I:∀(t.t → t) be Λ(t.λ (x:t. x)) in I[τ → τ](I[τ]) has type τ → τ for any polytype τ.
22.4.3
Rank-Restricted Fragments
The binary distinction between monomorphic and polymorphic types in L1 {→∀} may be generalized to form a hierarchy of languages in which the occurrences of polymorphic types are restricted in relation to function types. The key feature of the prenex fragment is that quantified types are not permitted to occur in the domain of a function type. The prenex fragment also prohibits polymorphic types from the range of a function type, but it would be harmless to admit it, there being no significant difference between the type ρ → ∀(t.τ) and the type ∀(t.ρ → τ) (where t ∈ / ρ). This motivates the definition of a hierarchy of fragments of L{→∀} that subsumes the prenex fragment as a special case. We will define a judgement of the form τ type [k ], where k ≥ 0, to mean that τ is a type of rank k. Informally, types of rank 0 have no quantification, and types of rank k + 1 may involve quantification, but the domains of function types are restricted to be of rank k. Thus, in the terminology of Section 22.4.2 on page 207, a monotype is a type of rank 0 and a polytype is a type of rank 1. The definition of the types of rank k is defined simultaneously for all k by the following rules. These rules involve hypothetical judgements of the form ∆ ` τ type [k ], where ∆ is a finite set of hypotheses of the form ti type [k i ] for some pairwise distinct set of type variables ti . The rules defining these judgements are as follows: ∆, t type [k ] ` t type [k ] R EVISED 10.03.2011
D RAFT
(22.8a) V ERSION 1.19
210
22.5 Notes ∆ ` τ1 type [0] ∆ ` τ2 type [0] ∆ ` arr(τ1 ; τ2 ) type [0]
(22.8b)
∆ ` τ1 type [k ] ∆ ` τ2 type [k + 1] ∆ ` arr(τ1 ; τ2 ) type [k + 1]
(22.8c)
∆ ` τ type [k] ∆ ` τ type [k + 1]
(22.8d)
∆, t type [k ] ` τ type [k + 1] ∆ ` all(t.τ) type [k + 1]
(22.8e)
With these restrictions in mind, it is a good exercise to define the statics of Lk {→∀}, the restriction of L{→∀} to types of rank k (or less). It is most convenient to consider judgements of the form e : τ [k ] specifying simultaneously that e : τ and τ type [k ]. For example, the rank-limited rules for λ-abstractions is phrased as follows: ∆ ` τ1 type [0] ∆ Γ, x : τ1 [0] ` e2 : τ2 [0] ∆ Γ ` lam[τ1 ](x.e2 ) : arr(τ1 ; τ2 ) [0]
(22.9a)
∆ ` τ1 type [k ] ∆ Γ, x : τ1 [k] ` e2 : τ2 [k + 1] ∆ Γ ` lam[τ1 ](x.e2 ) : arr(τ1 ; τ2 ) [k + 1]
(22.9b)
The remaining rules follow a similar pattern. The rank-limited languages Lk {→∀} clarifies the requirement for a primitive let construct in L1 {→∀}. The prenex fragment of L{→∀} corresponds to the rank-one fragment L1 {→∀}. The let construct for rankone types is definable in L2 {→∀} from λ-abstraction and application. This definition only makes sense at rank two, since it abstracts over a rank-one polymorphic type.
22.5
Notes
System F was introduced by Girard (1972) in the context of proof theory and by Reynolds Reynolds (1974) in the context of programming languages. The concept of parametricity was originally isolated by Strachey, but was not fully developed until the work of Reynolds (1983).
V ERSION 1.19
D RAFT
R EVISED 10.03.2011
Chapter 23
Abstract Types Data abstraction is perhaps the most important technique for structuring programs. The main idea is to introduce an interface that serves as a contract between the client and the implementor of an abstract type. The interface specifies what the client may rely on for its own work, and, simultaneously, what the implementor must provide to satisfy the contract. The interface serves to isolate the client from the implementor so that each may be developed in isolation from the other. In particular one implementation may be replaced by another without affecting the behavior of the client, provided that the two implementations meet the same interface and are, in a sense to be made precise below, suitably related to one another. (Roughly, each simulates the other with respect to the operations in the interface.) This property is called representation independence for an abstract type. Data abstraction may be formalized by extending the language L{→∀} with existential types. Interfaces are modelled as existential types that provide a collection of operations acting on an unspecified, or abstract, type. Implementations are modelled as packages, the introductory form for existentials, and clients are modelled as uses of the corresponding elimination form. It is remarkable that the programming concept of data abstraction is modelled so naturally and directly by the logical concept of existential type quantification. Existential types are closely connected with universal types, and hence are often treated together. The superficial reason is that both are forms of type quantification, and hence both require the machinery of type variables. The deeper reason is that existentials are definable from universals — surprisingly, data abstraction is actually just a form of polymorphism! One consequence of this observation is that representation independence is just a use of the parametricity properties of polymorphic
212
23.1 Existential Types
functions discussed in Chapter 22.
23.1
Existential Types
The syntax of L{→∀∃} is the extension of L{→∀} with the following constructs: Typ τ ::= Exp e ::=
some(t.τ) ∃(t.τ) interface pack[t.τ][ρ](e) pack ρ with e as ∃(t.τ) implementation open[t.τ][ρ](e1 ; t, x.e2 ) open e1 as t with x:τ in e2 client
The introductory form for the existential type ∃(t.τ) is a package of the form pack ρ with e as ∃(t.τ), where ρ is a type and e is an expression of type [ρ/t]τ. The type ρ is called the representation type of the package, and the expression e is called the implementation of the package. The eliminatory form for existentials is the expression open e1 as t with x:τ in e2 , which opens the package e1 for use within the client e2 by binding its representation type to t and its implementation to x for use within e2 . Crucially, the typing rules ensure that the client is type-correct independently of the actual representation type used by the implementor, so that it may be varied without affecting the type correctness of the client. The abstract syntax of the open construct specifies that the type variable, t, and the expression variable, x, are bound within the client. They may be renamed at will by α-equivalence without affecting the meaning of the construct, provided, of course, that the names are chosen so as not to conflict with any others that may be in scope. In other words the type, t, may be thought of as a “new” type, one that is distinct from all other types, when it is introduced. This is sometimes called generativity of abstract types: the use of an abstract type by a client “generates” a “new” type within that client. This behavior is simply a consequence of identifying terms up to α-equivalence, and is not particularly tied to data abstraction.
23.1.1
Statics
The statics of existential types is specified by rules defining when an existential is well-formed, and by giving typing rules for the associated introductory and eliminatory forms. ∆, t type ` τ type ∆ ` some(t.τ) type V ERSION 1.19
D RAFT
(23.1a) R EVISED 10.03.2011
23.1 Existential Types
213
∆ ` ρ type ∆, t type ` τ type ∆ Γ ` e : [ρ/t]τ ∆ Γ ` pack[t.τ][ρ](e) : some(t.τ) ∆ Γ ` e1 : some(t.τ) ∆, t type Γ, x : τ ` e2 : τ2 ∆ ` τ2 type ∆ Γ ` open[t.τ][τ2 ](e1 ; t, x.e2 ) : τ2
(23.1b) (23.1c)
Rule (23.1c) is complex, so study it carefully! There are two important things to notice: 1. The type of the client, τ2 , must not involve the abstract type t. This restriction prevents the client from attempting to export a value of the abstract type outside of the scope of its definition. 2. The body of the client, e2 , is type checked without knowledge of the representation type, t. The client is, in effect, polymorphic in the type variable t. Lemma 23.1 (Regularity). Suppose that ∆ Γ ` e : τ. If ∆ ` τi type for each xi : τi in Γ, then ∆ ` τ type. Proof. By induction on Rules (23.1).
23.1.2
Dynamics
The (eager or lazy) dynamics of existential types is specified as follows:
{e val} pack[t.τ][ρ](e) val
e 7→ e0 pack[t.τ][ρ](e) 7→ pack[t.τ][ρ](e0 )
(23.2a) (23.2b)
e1 7→ e10 open[t.τ][τ2 ](e1 ; t, x.e2 ) 7→ open[t.τ][τ2 ](e10 ; t, x.e2 )
(23.2c)
{e val} open[t.τ][τ2 ](pack[t.τ][ρ](e); t, x.e2 ) 7→ [ρ, e/t, x ]e2
(23.2d)
It is important to observe that, according to these rules, there are no abstract types at run time! The representation type is propagated to the client by substitution when the package is opened, thereby eliminating the abstraction boundary between the client and the implementor. Thus, data abstraction is a compile-time discipline that leaves no traces of its presence at execution time. R EVISED 10.03.2011
D RAFT
V ERSION 1.19
214
23.1.3
23.2 Data Abstraction Via Existentials
Safety
The safety of the extension is stated and proved as usual. The argument is a simple extension of that used for L{→∀} to the new constructs. Theorem 23.2 (Preservation). If e : τ and e 7→ e0 , then e0 : τ. Proof. By rule induction on e 7→ e0 , making use of substitution for both expression- and type variables. Lemma 23.3 (Canonical Forms). If e : some(t.τ) and e val, then e = pack[t.τ][ρ](e0 ) for some type ρ and some e0 such that e0 : [ρ/t]τ. Proof. By rule induction on the statics, making use of the definition of closed values. Theorem 23.4 (Progress). If e : τ then either e val or there exists e0 such that e 7→ e0 . Proof. By rule induction on e : τ, making use of the canonical forms lemma.
23.2
Data Abstraction Via Existentials
To illustrate the use of existentials for data abstraction, we consider an abstract type of queues of natural numbers supporting three operations: 1. Formation of the empty queue. 2. Inserting an element at the tail of the queue. 3. Remove the head of the queue, which is assumed to be non-empty. This is clearly a bare-bones interface, but is sufficient to illustrate the main ideas of data abstraction. Queue elements may be taken to be of any type, τ, of our choosing; we will not be specific about this choice, since nothing depends on it. The crucial property of this description is that nowhere do we specify what queues actually are, only what we can do with them. This is captured by the following existential type, ∃(t.τ), which serves as the interface of the queue abstraction:
∃(t.hemp : t, ins : nat × t → t, rem : t → nat × ti). V ERSION 1.19
D RAFT
R EVISED 10.03.2011
23.2 Data Abstraction Via Existentials
215
The representation type, t, of queues is abstract — all that is specified about it is that it supports the operations emp, ins, and rem, with the specified types. An implementation of queues consists of a package specifying the representation type, together with the implementation of the associated operations in terms of that representation. Internally to the implementation, the representation of queues is known and relied upon by the operations. Here is a very simple implementation, el , in which queues are represented as lists: pack list with hemp = nil, ins = ei , rem = er i as ∃(t.τ), where
ei : nat × list → list = λ (x:nat × list. ei0 ),
and
er : list → nat × list = λ (x:list. er0 ).
Here the expression ei0 conses the first component of x, the element, onto the second component of x, the queue. Correspondingly, the expression er0 reverses its argument, and returns the head element paired with the reversal of the tail. These operations “know” that queues are represented as values of type list, and are programmed accordingly. It is also possible to give another implementation, e p , of the same interface, ∃(t.τ), but in which queues are represented as pairs of lists, consisting of the “back half” of the queue paired with the reversal of the “front half”. This representation avoids the need for reversals on each call, and, as a result, achieves amortized constant-time behavior: pack list × list with hemp = hnil, nili, ins = ei , rem = er i as ∃(t.τ). In this case ei has type nat × (list × list) → (list × list), and er has type (list × list) → nat × (list × list). These operations “know” that queues are represented as values of type list × list, and are implemented accordingly. The important point is that the same client type checks regardless of which implementation of queues we choose. This is because the representation type is hidden, or held abstract, from the client during type checking. R EVISED 10.03.2011
D RAFT
V ERSION 1.19
216
23.3 Definability of Existentials
Consequently, it cannot rely on whether it is list or list × list or some other type. That is, the client is independent of the representation of the abstract type.
23.3
Definability of Existentials
It turns out that it is not necessary to extend L{→∀} with existential types to model data abstraction, because they are already definable using only universal types! Before giving the details, let us consider why this should be possible. The key is to observe that the client of an abstract type is polymorphic in the representation type. The typing rule for open e1 as t with x:τ in e2 : τ2 , where e1 : ∃(t.τ), specifies that e2 : τ2 under the assumptions t type and x : τ. In essence, the client is a polymorphic function of type
∀(t.τ → τ2 ), where t may occur in τ (the type of the operations), but not in τ2 (the type of the result). This suggests the following encoding of existential types:
∃(t.τ) = ∀(u.∀(t.τ → u) → u) pack ρ with e as ∃(t.τ) = Λ(u.λ (x:∀(t.τ → u). x[ρ](e))) open e1 as t with x:τ in e2 = e1 [τ2 ](Λ(t.λ (x:τ. e2 ))) An existential is encoded as a polymorphic function taking the overall result type, u, as argument, followed by a polymorphic function representing the client with result type u, and yielding a value of type u as overall result. Consequently, the open construct simply packages the client as such a polymorphic function, instantiates the existential at the result type, τ, and applies it to the polymorphic client. (The translation therefore depends on knowing the overall result type, τ, of the open construct.) Finally, a package consisting of a representation type ρ and an implementation e is a polymorphic function that, when given the result type, t, and the client, x, instantiates x with ρ and passes to it the implementation e. It is then a straightforward exercise to show that this translation correctly reflects the statics and dynamics of existential types. V ERSION 1.19
D RAFT
R EVISED 10.03.2011
23.4 Representation Independence
23.4
217
Representation Independence
An important consequence of parametricity is that it ensures that clients are insensitive to the representations of abstract types. More precisely, there is a criterion, called bisimilarity, for relating two implementations of an abstract type such that the behavior of a client is unaffected by swapping one implementation by another that is bisimilar to it. This leads to a simple methodology for proving the correctness of candidate implementation of an abstract type, which is to show that it is bisimilar to an obviously correct reference implementation of it. Since the candidate and the reference implementations are bisimilar, no client may distinguish them from one another, and hence if the client behaves properly with the reference implementation, then it must also behave properly with the candidate. To derive the definition of bisimilarity of implementations, it is helpful to examine the definition of existentials in terms of universals given in Section 23.3 on the facing page. It is an immediate consequence of the definition that the client of an abstract type is polymorphic in the representation of the abstract type. A client, c, of an abstract type ∃(t.τ) has type ∀(t.τ → τ2 ), where t does not occur free in τ2 (but may, of course, occur in τ). Applying the parametricity property described informally in Chapter 22 (and developed rigorously in Chapter 51), this says that if R is a bisimulation relation between any two implementations of the abstract type, then the client behaves identically on both of them. The fact that t does not occur in the result type ensures that the behavior of the client is independent of the choice of relation between the implementations, provided that this relation is preserved by the operation that implement it. To see what this means requires that we specify what is meant by a bisimulation. This is best done by example. Consider the existential type ∃(t.τ), where τ is the labelled tuple type
hemp : t, ins : τ × t → t, rem : t → τ × ti. Theorem 51.8 on page 539 ensures that if ρ and ρ0 are any two closed types, R is a relation between expressions of these two types, then if any the implementations e : [ρ/x ]τ and e0 : [ρ0 /x ]τ respect R, then c[ρ]e behaves the same as c[ρ0 ]e0 . It remains to define when two implementations respect the relation R. Let e = hemp = em , ins = ei , rem = er i and
R EVISED 10.03.2011
0 e0 = hemp = em , ins = ei0 , rem = er0 i.
D RAFT
V ERSION 1.19
218
23.4 Representation Independence
For these implementations to respect R means that the following three conditions hold: 0 ). 1. The empty queues are related: R(em , em
2. Inserting the same element on each of two related queues yields related queues: if d : τ and R(q, q0 ), then R(ei (d)(q), ei0 (d)(q0 )). 3. If two queues are related, their front elements are the same and their back elements are related: if R(q, q0 ), er (q) ∼ = hd, r i, er0 (q0 ) ∼ = h d 0 , r 0 i, 0 0 then d is d and R(r, r ). If such a relation R exists, then the implementations e and e0 are said to be bisimilar. The terminology stems from the requirement that the operations of the abstract type preserve the relation: if it holds before an operation is performed, then it must also hold afterwards, and the relation must hold for the initial state of the queue. Thus each implementation simulates the other up to the relationship specified by R. To see how this works in practice, let us consider informally two implementations of the abstract type of queues specified above. For the reference implementation we choose ρ to be the type list, and define the empty queue to be the empty list, insert to add the specified element to the front of the list, and remove to remove the last element of the list. (A remove therefore takes time linear in the length of the list.) For the candidate implementation we choose ρ0 to be the type list × list consisting of two lists, hb, f i, where b represents the “back” of the queue, and f represents the “front” of the queue represented in reverse order of insertion. The empty queue consists of two empty lists. To insert d onto hb, f i, we simply return hcons(d; b), f i, placing it on the “back” of the queue as expected. To remove an element from hb, f i breaks into two cases. If the front, f , of the queue is non-empty, say cons(d; f 0 ), then return hd, hb, f 0 ii consisting of the front element and the queue with that element removed. If, on the other hand, f is empty, then we must move elements from the “back” to the “front” by reversing b and re-performing the remove operation on hnil, rev(b)i, where rev is the obvious list reversal function. To show that the candidate implementation is correct, we show that it is bisimilar to the reference implementation. This reduces to specifying a relation, R, between the types list and list × list such that the three simulation conditions given above are satisfied by the two implementations just described. The relation in question states that R(l, hb, f i) iff the list l is the list app(b)(rev( f )), where app is the evident append function V ERSION 1.19
D RAFT
R EVISED 10.03.2011
23.5 Notes
219
on lists. That is, thinking of l as the reference representation of the queue, the candidate must maintain that the elements of b followed by the elements of f in reverse order form precisely the list l. It is easy to check that the implementations just described preserve this relation. Having done so, we are assured that the client, c, behaves the same regardless of whether we use the reference or the candidate. Since the reference implementation is obviously correct (albeit inefficient), the candidate must also be correct in that the behavior of any client is unaffected by using it instead of the reference.
23.5
Notes
The connection between abstract types in programming languages and existential types in logic was made by Mitchell and Plotkin (1988). Closely relatd ideas were already present in Reynolds (1974), but the connection with existential types was not explicitly drawn there. The account of representation independence given here is derived from Mitchell (1986).
R EVISED 10.03.2011
D RAFT
V ERSION 1.19
220
V ERSION 1.19
23.5 Notes
D RAFT
R EVISED 10.03.2011
Chapter 24
Constructors and Kinds The types nat → nat and nat list may be thought of as being built from other types by the application of a type constructor, or type operator. These two examples differ from each other in that the function space type constructor takes two arguments, whereas the list type constructor takes only one. We may, for the sake of uniformity, think of types such as nat as being built by a type constructor of no arguments. More subtly, we may even think of the types ∀(t.τ) and ∃(t.τ) as being built up in the same way by regarding the quantifiers as higher-order type operators. These seemingly disparate cases may be treated uniformly by enriching the syntactic structure of a language with a new layer of constructors. To ensure that constructors are used properly (for example, that the list constructor is given only one argument, and that the function constructor is given two), we classify constructors by kinds. Constructors of a distinguished kind, T, are types, which may be used to classify expressions. To allow for multi-argument and higher-order constructors, we will also consider finite product and function kinds. (Later we shall consider even richer kinds.) The distinction between constructors and kinds on one hand and types and expressions on the other reflects a fundamental separation between the static and dynamic phase of processing of a programming language, called the phase distinction. The static phase implements the statics and the dynamic phase implements the dynamics. Constructors may be seen as a form of static data that is manipulated during the static phase of processing. Expressions are a form of dynamic data that is manipulated at run-time. Since the dynamic phase follows the static phase (we only execute welltyped programs), we may also manipulate constructors at run-time.
222
24.1 Statics
Adding constructors and kinds to a language introduces more technical complications than might at first be apparent. The main difficulty is that as soon as we enrich the kind structure beyond the distinguished kind of types, it becomes essential to simplify constructors to determine whether they are equivalent. For example, if we admit product kinds, then a pair of constructors is a constructor of product kind, and projections from a constructor of product kind are also constructors. But what if we form the first projection from the pair consisiting of the constructors nat and str? This should be equivalent to nat, since the elimination form if post-inverse to the introduction form. Consequently, any expression (say, a variable) of the one type should also be an expression of the other. That is, typing should respect definitional equivalence of constructors. There are two main ways to deal with this. One is to introduce a concept of definitional equivalence for constructors, and to demand that the typing judgement for expressions respect definitional equivalence of constructors of kind T. This means, however, that we must show that definitional equivalence is decidable if we are to build a complete implementation of the language. The other is to prohibit formation of awkward constructors such as the projection from a pair so that there is never any issue of when two constructors are equivalent (only when they are identical). But this complicates the definition of substitution, since a projection from a constructor variable is well-formed, until you substitute a pair for the variable. Both approaches have their benefits, but the second is simplest, and is adopted here.
24.1
Statics
The syntax of kinds is given by the following grammar: Kind κ ::=
Type Unit Prod(κ1 ; κ2 ) Arr(κ1 ; κ2 )
T 1 κ1 × κ2 κ1 → κ2
types nullary product binary product function
The kinds consist of the kind of types, T, the unit kind, Unit, and are closed under formation of product and function kinds. The syntax of constructors is divided into two syntactic sorts, the neutral V ERSION 1.19
D RAFT
R EVISED 10.03.2011
24.1 Statics
223
and the canonical, according to the following grammar: NCon a ::=
CCon c ::=
u proj[l](a) proj[r](a) app(a1 ; c2 ) atom(a) unit pair(c1 ; c2 ) lam(u.c)
u a·l a·r a1 [c2 ] b a hi hc1 ,c2 i λ u.c
variable first projection second projection application atomic null tuple pair abstraction
The reason to distinguish neutral from canonical constructors is to ensure that it is impossible to apply an elimination form to an introduction form, which demands an equation to capture the inversion principle. For example, the putative constructor hc1 ,c2 i · l, which would be definitionally equivalent to c1 , is ill-formed according to Grammar (24.1). This is because the argument to a projection must be neutral, but a pair is only canonical, not neutral. The canonical constructor b a is the inclusion of neutral constructors into canonical constructors. However, the grammar does not capture a crucial property of the statics that ensures that only neutral constructors of kind T may be treated as canonical. This requirement is imposed to limit the forms of canonical contructors of the other kinds. In particular, variables of function, product, or unit kind will turn out not to be canonical, but only neutral. The statics of constructors and kinds is specified by the judgements ∆`a⇑κ ∆`c⇓κ
neutral constructor formation canonical constructor formation
In each of these judgements ∆ is a finite set of hypotheses of the form u1 ⇑ κ 1 , . . . , u n ⇑ κ n for some n ≥ 0. The form of the hypotheses expresses the principle that variables are neutral constructors. The formation judgements are to be understood as generic hypothetical judgements with parameters u1 , . . . , un that are determined by the forms of the hypotheses. The rules for constructor formation are as follows: ∆, u ⇑ κ ` u ⇑ κ R EVISED 10.03.2011
D RAFT
(24.1a) V ERSION 1.19
224
24.2 Higher Kinds ∆ ` a ⇑ κ1 × κ2 ∆ ` a · l ⇑ κ1
(24.1b)
∆ ` a ⇑ κ1 × κ2 ∆ ` a · r ⇑ κ2
(24.1c)
∆ ` a1 ⇑ κ 2 → κ ∆ ` c2 ⇓ κ 2 ∆ ` a1 [c2 ] ⇑ κ
(24.1d)
∆`a⇑T ∆`b a⇓T
(24.1e)
∆ ` hi ⇓ 1
(24.1f)
∆ ` c1 ⇓ κ 1 ∆ ` c2 ⇓ κ 2 ∆ ` hc1 ,c2 i ⇓ κ1 × κ2
(24.1g)
∆, u ⇑ κ1 ` c2 ⇓ κ2 ∆ ` λ u.c2 ⇓ κ1 → κ2
(24.1h)
Rule (24.1e) specifies that the only neutral constructors that are canonical are those with kind T. This ensures that the language enjoys the following canonical forms property, which is easily proved by inspection of Rules (24.1). Lemma 24.1. Suppose that ∆ ` c ⇓ κ. 1. If κ = 1, then c = hi. 2. If κ = κ1 × κ2 , then c = hc1 ,c2 i for some c1 and c2 such that ∆ ` ci ⇓ κi for i = 1, 2. 3. If κ = κ1 → κ2 , then c = λ u.c2 with ∆, u ⇑ κ1 ` c2 ⇓ κ2 .
24.2
Higher Kinds
To equip a language, L, with constructors and kinds requires that we augment its statics with hypotheses governing constructor variables, and that we relate constructors of kind T (types as static data) to the classifiers of dynamic expressions (types as classifiers). To achieve this the statics of L must be defined to have judgements of the following two forms: ∆ ` τ type ∆Γ`e:τ V ERSION 1.19
type formation expression formation D RAFT
R EVISED 10.03.2011
24.2 Higher Kinds
225
where, as before, Γ is a finite set of hypotheses of the form x1 : τ1 , . . . , xk : τk for some k ≥ 0 such that ∆ ` τi type for each 1 ≤ i ≤ k. As a general principle, every constructor of kind T is a classifier: ∆`τ⇑T . ∆ ` τ type
(24.2)
In many cases this is the sole rule of type formation, so that every classifier is a constructor of kind T. However, this need not be the case. In some situations we may wish to have strictly more classifiers than constructors of the distinguished kind. To see how this might arise, let us consider two extensions of L{→∀} from Chapter 22. In both cases we extend the universal quantifier ∀(t.τ) to admit quantification over an arbitrary kind, written ∀ u :: κ.τ, but the two languages differ in what constitutes a constructor of kind T. In one case, the impredicative, we admit quantified types as constructors, and in the other, the predicative, we exclude quantified types from the domain of quantification. The impredicative fragment includes the following two constructor constants: (24.3a) ∆ ` → ⇑ T→T→T ∆ ` ∀κ ⇑ (κ → T) → T
(24.3b)
We regard the classifier τ1 → τ2 to be the application →[τ1 ][τ2 ]. Similarly, we regard the classifier ∀ u :: κ.τ to be the application ∀κ [λ u.τ]. The predicative fragment excludes the constant specified by Rule (24.3b) in favor of a separate rule for the formation of universally quantified types: ∆, u ⇑ κ ` τ type . ∆ ` ∀ u :: κ.τ type
(24.4)
The point is that ∀ u :: κ.τ is a type (as classifier), but is not a constructor of kind type. The significance of this distinction becomes apparent when we consider the introduction and elimination forms for the generalized quantifier, which are the same for both fragments: ∆, u ⇑ κ Γ ` e : τ ∆ Γ ` Λ(u::κ.e) : ∀ u :: κ.τ R EVISED 10.03.2011
D RAFT
(24.5a) V ERSION 1.19
226
24.3 Hereditary Substitution
∆ Γ ` e : ∀ u :: κ.τ ∆ ` c ⇓ κ (24.5b) ∆ Γ ` e[c] : [c/u]τ (Rule (24.5b) makes use of substitution, whose definition requires some care. We will return to this point in Section 24.3.) Rule (24.5b) makes clear that a polymorphic abstraction quantifies over the constructors of kind κ. When κ is T this kind may or may not include all of the classifiers of the language, according to whether we are working with the impredicative formulation of quantification (in which the quantifiers are distinguished constants for building constructors of kind T) or the predicative formulation (in which quantifiers arise only as classifiers and not as constructors). The main idea is that constructors are static data, so that a constructor abstraction Λ(u::κ.e) of type ∀ u :: κ.τ is a mapping from static data c of kind κ to dynamic data [c/u]e of type [c/u]τ. Rule (24.1e) tells us that every constructor of kind T determines a classifier, but it may or may not be the case that every classifier arises in this manner.
24.3
Hereditary Substitution
Rule (24.5b) involves substitution of a canonical constructor, c, of kind κ into a family of types u ⇑ κ ` τ type. This operation is is written [c/u]τ, as usual. Although the intended meaning is clear, it is in fact impossible to interpret [c/u]τ as the standard concept of substitution defined in Chapter 1. The reason is that to do so would risk violating the distinction between neutral and canonical constructors. Consider, for example, the case of the family of types u ⇑ T → T ` u[d] ⇑ T, where d ⇑ T. (It is not important what we choose for d, so we leave it abstract.) Now if c ⇓ T → T, then by Lemma 24.1 on page 224 we have that c is λ u0 .c0 . Thus, if interpreted conventionally, substitution of c for u in the given family yields the “constructor” (λ u0 .c0 )[d], which is not well-formed. The solution is to define a form of canonizing substitution that simplifies such “illegal” combinations as it performs the replacement of a variable by a constructor of the same kind. In the case just sketched this means that we must ensure that [λ u0 .c0 /u]u[d] = [d/u0 ]c0 . If viewed as a definition this equation is problematic because it switches from substituting for u in the constructor u[d] to substituting for u0 in the V ERSION 1.19
D RAFT
R EVISED 10.03.2011
24.3 Hereditary Substitution
227
unrelated constructor c0 . Why should such a process terminate? The answer lies in the observation that the kind of u0 is definitely smaller than the kind of u, since the former’s kind is the domain kind of the latter’s function kind. In all other cases of substitution (as we shall see shortly) the size of the target of the substitution becomes smaller; in the case just cited the size may increase, but the type of the target variable decreases. Therefore by a lexicographic induction on the type of the target variable and the structure of the target constructor, we may prove that canonizing substitution is well-defined. We now turn to the task of making this precise. We will define simultaneously two principal forms of substitution, one of which divides into two cases:
[c/u : κ ] a = a0 [c/u : κ ] a = c0 ⇓ κ 0 [c/u : κ ]c0 = c00
canonical into neutral yielding neutral canonical into neutral yielding canonical and kind canonical into canonical yielding canonical
Substitution into a neutral constructor divides into two cases according to whether the substituted variable u occurs in critical position in a sense to be made precise below. These forms of substitution are simultaneously inductively defined by the following rules, which are broken into groups for clarity. The first set of rules defines substitution of a canonical constructor into a canonical constructor; the result is always canonical.
[c/u : κ ] a0 = a00 [c/u : κ ] ab0 = ab00
(24.6a)
[c/u : κ ] a0 = c00 ⇓ κ 00 [c/u : κ ] ab0 = c00
(24.6b)
[u/hi : κ ]=hi
(24.6c)
[c/u : κ ]c10 = c100 [c/u : κ ]c20 = c200 [c/u : κ ]hc10 ,c20 i = hc100 ,c200 i
(24.6d)
[c/u : κ ]c0 = c00 (u 6= u0 ) (u0 ∈ / c) 0 0 0 00 [c/u : κ ]λ u .c = λ u .c
(24.6e)
The conditions on variables in Rule (24.6e) may always be met by renaming the bound variable, u0 , of the abstraction. R EVISED 10.03.2011
D RAFT
V ERSION 1.19
228
24.3 Hereditary Substitution
The second set of rules defines substitution of a canonical constructor into a neutral constructor, yielding another neutral constructor.
(u 6= u0 ) [c/u : κ ]u0 = u0
(24.7a)
[c/u : κ ] a0 = a00 [c/u : κ ] a0 · l = a00 · l
(24.7b)
[c/u : κ ] a0 = a00 [c/u : κ ] a0 · r = a00 · r
(24.7c)
[c/u : κ ] a1 = a10 [c/u : κ ]c2 = c20 [c/u : κ ] a1 [c2 ] = a10 (c20 )
(24.7d)
Rule (24.7a) pertains to a non-critical variable, which is not the target of substitution. The remaining rules pertain to situations in which the recursive call on a neutral constructor yields a neutral constructor. The third set of rules defines substitution of a canonical constructor into a neutral constructor, yielding a canonical constructor and its kind.
[c/u : κ ]u = c ⇓ κ
(24.8a)
[c/u : κ ] a0 = hc10 ,c20 i ⇓ κ10 × κ20 [c/u : κ ] a0 · l = c10 ⇓ κ10
(24.8b)
[c/u : κ ] a0 = hc10 ,c20 i ⇓ κ10 × κ20 [c/u : κ ] a0 · r = c20 ⇓ κ20
(24.8c)
[c/u : κ ] a10 = λ u0 .c0 ⇓ κ20 → κ 0 [c/u : κ ]c20 = c200 [c/u : κ ] a10 [c20 ] = c00 ⇓ κ 0
[c200 /u0 : κ20 ]c0 = c00
(24.8d) Rule (24.8a) governs a critical variable, which is the target of substitution. The substitution transforms it from a neutral constructor to a canonical constructor. This has a knock-on effect in the remaining rules of the group, which analyze the canonical form of the result of the recursive call to determine how to proceed. Rule (24.8d) is the most interesting rule. In the third premise, all three arguments to substitution change as we substitute the (substituted) argument of the application for the parameter of the (substituted) function into the body of that function. Here we require the type of the function in order to determine the type of its parameter. V ERSION 1.19
D RAFT
R EVISED 10.03.2011
24.4 Canonization
229
Theorem 24.2. Suppose that ∆ ` c ⇓ κ, and ∆, u ⇑ κ ` c0 ⇓ κ 0 , and ∆, u ⇑ κ ` a0 ⇑ κ 0 . There exists a unique ∆ ` c00 ⇓ κ 0 such that [c/u : κ ]c0 = c00 . Either there exists a unique ∆ ` a00 ⇑ κ 0 such that [c/u : κ ] a0 = a00 , or there exists a unique ∆ ` c00 ⇓ κ 0 such that [c/u : κ ] a0 = c00 , but not both. Proof. Simultaneously by a lexicographic induction with major component the structure of the kind κ, and with minor component determined by Rules (24.1) governing the formation of c0 and a0 . For all rules except Rule (24.8d) the inductive hypothesis applies to the premise(s) of the relevant formation rules. For Rule (24.8d) we appeal to the major inductive hypothesis applied to κ20 , which is a component of the kind κ20 → κ 0 .
24.4
Canonization
With hereditary substitution in hand, it is perfectly possible to confine our attention to constructors in canonical form. However, for some purposes it can be useful to admit a more relaxed syntax in which it is possible to form non-canonical constructors that can nevertheless be transformed into canonical form. The prototypical example is the constructor (λ u.c2 )[c1 ], which is malformed according to Rules (24.1), because the first argument of an application is required to be in atomic form, whereas the λ-abstraction is in canonical form. However, if c1 and c2 are already canonical, then the malformed application may be transformed into the well-formed canonical form [v1 /u]c2 , where substitution is as defined in Section 24.3 on page 226. If c1 or c2 are not already canonical we may, inductively, put them into canonical form before performing the substitution, resulting in the same canonical form. A constructor in general form is one that is well-formed with respect to Rules (24.1), but disregarding the distinction between atomic and canonical forms. We write ∆ ` c :: κ to mean that c is a well-formed constructor of kind κ in general form. The difficulty with admitting general form constructors is that they introduce non-trivial equivalences between constructors. For example, one must ensure that hint,booli · l is equivalent to int wherever the fomer may occur. With this in mind we will introduce a canonization procedure that allows us to define equivalence of general form constructors, written ∆ ` c1 ≡ c2 :: κ, to mean that c1 and c2 have identical canonical forms (up to α-equivalence). Canonization of general-form constructors is defined by these two judgements: R EVISED 10.03.2011
D RAFT
V ERSION 1.19
230
24.4 Canonization
1. Canonization: ∆ ` c :: κ ⇓ c: transform general-form constructor c of kind κ to canonical form c. 2. Atomization: ∆ ` c ⇑ c :: κ: transform general-form constructor c to obtain atomic form c of kind κ. These two judgements are defined simultaneously by the following rules. The canonization judgement is used to determine the canonical form of a general-form constructor; the atomization judgement is an auxiliary to the first that transforms constructors into atomic form. The canonization judgement is to be thought of as having mode (∀, ∀, ∃), whereas the atomization judgement is to be thought of as having mode (∀, ∃, ∃). ∆ ` c ⇑ c :: T ∆ ` c :: T ⇓ bc
(24.9a)
∆ ` c :: 1 ⇓ hi ∆ ` c · l :: κ1 ⇓ c1 ∆ ` c · r :: κ2 ⇓ c2 ∆ ` c :: κ1 × κ2 ⇓ hc1 ,c2 i ∆, u ⇑ κ1 ` c[u] :: κ2 ⇓ c2 ∆ ` c :: κ1 → κ2 ⇓ λ u.c2 ∆, u ⇑ κ ` u ⇑ u :: κ ∆ ` c ⇑ c :: κ1 × κ2 ∆ ` c · l ⇑ c · l :: κ1 ∆ ` c ⇑ c :: κ1 × κ2 ∆ ` c · r ⇑ c · r :: κ2 ∆ ` c1 ⇑ c1 :: κ1 → κ2 ∆ ` c2 :: κ1 ⇓ c2 ∆ ` c1 [c2 ] ⇑ c1 [c2 ] :: κ2
(24.9b) (24.9c) (24.9d) (24.9e) (24.9f) (24.9g) (24.9h)
The canonization judgement produces canonical forms, and the atomization judgement produces atomic forms. Lemma 24.3.
1. If ∆ ` c :: κ ⇓ c, then ∆ ` c ⇓ κ.
2. If ∆ ` c ⇑ c :: κ, then ∆ ` c ⇑ κ. Proof. By induction on Rules (24.9). Theorem 24.4. If Γ ` c :: κ, then there exists c such that ∆ ` c :: κ ⇓ c. Proof. By induction on the formation rules for general-form constructors, making use of an analysis of the general-form constructors of kind T. V ERSION 1.19
D RAFT
R EVISED 10.03.2011
24.5 Notes
24.5
231
Notes
The classical approach is to consider general-form constructors at the outset, for which substitution is readily defined, and then to test equivalence of general-form constructors by reduction to a common irreducible form. Two main lemmas are required for this approach. First, every constructor must reduce in a finite number of steps to an irreducible form; this is called normalization. Second, the relation “has a common irreducible form” must be shown to be transitive; this is called confluence. Here we have turned the development on its head by considering only canonical constructors in the first place, then defining substitution using the method of Watkins et al. (2008). It is then straightforward to decide equivalence of general-form constructors by canonization of both sides of a candidate equation.
R EVISED 10.03.2011
D RAFT
V ERSION 1.19
232
V ERSION 1.19
24.5 Notes
D RAFT
R EVISED 10.03.2011
Part IX
Subtyping
Chapter 25
Subtyping A subtype relation is a pre-order (reflexive and transitive relation) on types that validates the subsumption principle: if τ 0 is a subtype of τ, then a value of type τ 0 may be provided whenever a value of type τ is required. The subsumption principle relaxes the strictures of a type system to permit values of one type to be treated as values of another. Experience shows that the subsumption principle, while useful as a general guide, can be tricky to apply correctly in practice. The key to getting it right is the principle of introduction and elimination. To determine whether a candidate subtyping relationship is sensible, it suffices to consider whether every introductory form of the subtype can be safely manipulated by every eliminatory form of the supertype. A subtyping principle makes sense only if it passes this test; the proof of the type safety theorem for a given subtyping relation ensures that this is the case. A good way to get a subtyping principle wrong is to think of a type merely as a set of values (generated by introductory forms), and to consider whether every value of the subtype can also be considered to be a value of the supertype. The intuition behind this approach is to think of subtyping as akin to the subset relation in ordinary mathematics. But this can lead to serious errors, because it fails to take account of the operations (eliminatory forms) that one can perform on values of the supertype. It is not enough to think only of the introductory forms; one must also think of the eliminatory forms. Subtyping is a matter of behavior, rather than containment.
236
25.1
25.1 Subsumption
Subsumption
A subtyping judgement has the form τ 0