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. 1. If e : τ and e ⟼ e', then e': τ.

2. 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': τ.