Book contents
- Frontmatter
- Contents
- Preface to the Second Edition
- Preface to the First Edition
- Part I Judgments and Rules
- Part II Statics and Dynamics
- 4 Statics
- 5 Dynamics
- 6 Type Safety
- 7 Evaluation Dynamics
- Part III Total Functions
- Part IV Finite Data Types
- Part V Types and Propositions
- Part VI Infinite Data Types
- Part VII Variable Types
- Part VIII Partiality and Recursive Types
- Part IX Dynamic Types
- Part X Subtyping
- Part XI Dynamic Dispatch
- Part XII Control Flow
- Part XIII Symbolic Data
- Part XIV Mutable State
- Part XV Parallelism
- Part XVI Concurrency and Distribution
- Part XVII Modularity
- Part XVIII Equational Reasoning
- Part XIX Appendices
- References
- Index
6 - Type Safety
from Part II - Statics and Dynamics
Published online by Cambridge University Press: 05 March 2016
- Frontmatter
- Contents
- Preface to the Second Edition
- Preface to the First Edition
- Part I Judgments and Rules
- Part II Statics and Dynamics
- 4 Statics
- 5 Dynamics
- 6 Type Safety
- 7 Evaluation Dynamics
- Part III Total Functions
- Part IV Finite Data Types
- Part V Types and Propositions
- Part VI Infinite Data Types
- Part VII Variable Types
- Part VIII Partiality and Recursive Types
- Part IX Dynamic Types
- Part X Subtyping
- Part XI Dynamic Dispatch
- Part XII Control Flow
- Part XIII Symbolic Data
- Part XIV Mutable State
- Part XV Parallelism
- Part XVI Concurrency and Distribution
- Part XVII Modularity
- Part XVIII Equational Reasoning
- Part XIX Appendices
- References
- Index
Summary
Most 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 E states that it will never arise that a number is added to a string, or that two numbers are concatenated, neither of which is meaningful.
In general, type safety expresses the coherence between the statics and the dynamics. The staticsmay 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. Safety 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.
Type safety for the language E is stated precisely as follows:
Theorem 6.1 (Type Safety).
1. If e : τ and e ⟼ e', then e': τ.
2. If e : τ, then either e val, or there exists e' such that e ⟼ e'.
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 e' such that e ⟼ e'. It follows from the safety theorem that a stuck state is necessarily ill–typed. Or, putting it the other way around, that well–typed states do not get stuck.
Preservation
The preservation theorem for E defined in Chapters 4 and 5 is proved by rule induction on the transition system (rules (5.4)).
Theorem 6.2 (Preservation). If e : τ and e ⟼ e', then e': τ.
- Type
- Chapter
- Information
- Practical Foundations for Programming Languages , pp. 48 - 52Publisher: Cambridge University PressPrint publication year: 2016