In Chapter 23, we demonstrated that dynamic typing is but a mode of use of static typing, one in which dynamically typed values are of type dyn, a particular recursive sum type. A value of type dyn is always of the form new[c](e), where c is its class and e is its underlying value. Importantly, the class c determines the type of the underlying value of a dynamic value. The type system of the hybrid language is rather weak in that every dynamically classified value has the same type, and there is no mention of the class in its type. To correct this shortcoming it is common to enrich the type system of the hybrid language to capture such information, for example, as described in Section 24.2.

In such a situation, subtyping is used to resolve a fundamental tension between structure and behavior in the design of type systems. On the one hand, types determine the structure of a programming language and, on the other, serve a behavioral specifications of expressions written in that language. Subtyping attempts to resolve this tension, unsuccessfully, by allowing certain forms of retyping. Although subtyping works reasonably well for small examples, things get far more complicated when we wish to specify the deep structure of a value, say, that it is of a class c and its underlying value is of another class d whose underlying value is a natural number. There is no limit to the degree of specificity one may wish in such descriptions, which gives rise to endless variations on type systems to accommodate various special situations.

Another resolution of the tension between structure and behavior in typing is to separate these aspects by distinguishing types from type refinements. Type refinements specify the execution behavior of an expression of a particular type using specifications that capture whatever properties are of interest, limited only by the difficulty of proving that a program satisfies the specification given by a refinement.

Certain limited forms of behavioral specifications can express many useful properties of programs while remaining mechanically checkable. These include the fundamental behavioral properties determined by the type itself but can be extended to include sharper conditions than just these structural properties. In this chapter, we will consider a particular notion of refinement tailored to the hybrid language of Chapter 23.

Types are the central organizing principle of the theory of programming languages. Language features are manifestations of type structure. The syntax of a language is governed by the constructs that define its types, and its semantics is determined by the interactions among those constructs. The soundness of a language design—the absence of ill-defined programs—follows naturally.

The purpose of this book is to explain this remark. A variety of programming language features are analyzed in the unifying framework of type theory.Alanguage feature is defined by its statics, the rules governing the use of the feature in a program, and its dynamics, the rules defining how programs using this feature are to be executed. The concept of safety emerges as the coherence of the statics and the dynamics of a language.

In this way, we establish a foundation for the study of programming languages. But why these particular methods? The main justification is provided by the book itself. The methods we use are both precise and intuitive, providing a uniform framework for explaining programming language concepts. Importantly, these methods scale to a wide range of programming language concepts, supporting rigorous analysis of their properties. Although it would require another book in itself to justify this assertion, these methods are also practical in that they are directly applicable to implementation and uniquely effective as a basis for mechanized reasoning. No other framework offers as much.

Being a consolidation and distillation of decades of research, this book does not provide an exhaustive account of the history of the ideas that inform it. Suffice it to say that much of the development is not original but rather is largely a reformulation of what has gone before. The notes at the end of each chapter signpost the major developments but are not intended as a complete guide to the literature. For further information and alternative perspectives, the reader is referred to such excellent sources as Constable (1986, 1998), Girard (1989), Martin-Löf (1984), Mitchell (1996), Pierce (2002, 2004), and Reynolds (1998).

The book is divided into parts that are, in the main, independent of one another. Parts I and II, however, provide the foundation for the rest of the book and must therefore be considered prior to all other parts.

It often arises that the values of a type are partitioned into a variety of classes, each classifying data with distinct internal structure. A simple example is provided by the type of points in the plane, which are classified according to whether they are represented in cartesian or polar form. Both are represented by a pair of real numbers, but in the cartesian case, these are the x and y coordinates of the point, whereas in the polar case, these are its distance r from the origin and its angle θ with the polar axis. A classified value is an object, or instance, of its class. The class determines the type of the classified data, the instance type of the class; the classified data itself is the instance data of the object.

Methods are functions that act on classified values. The behavior of a method is determined by the class of its argument. The method dispatches on the class of the argument. Because the selection is made at run-time, it is called dynamic dispatch. For example, the squared distance of a point from the origin is calculated differently according to whether the point is represented in cartesian or polar form. In the former case, the required distance is x2 + y2, whereas in the latter it is simply r2. Similarly, the quadrant of a cartesian point can be determined by examining the sign of its x and y coordinates, and the quadrant of a polar point can be calculated by taking the integral part of the angle θ divided by π/2.

Dynamic dispatch is often described in terms of a particular implementation strategy, which we will call the class-based organization. In this organization, each object is represented by a vector of methods specialized to the class of that object. We may equivalently use a method-based organization in which each method branches on the class of an object to determine its behavior. Regardless of the organization used, the fundamental idea is that (a) objects are classified and (b) methods dispatch on the class of an object. The class-based and method-based organizations are interchangeable and, in fact, related by a natural duality between sum and product types.We explain this symmetry by focusing first on the behavior of each method on each object, which is given by a dispatch matrix.

A reference to an assignable a is a value, written &a, of reference type that determines the assignable a. A reference to an assignable provides the capability to get or set the contents of that assignable, even if the assignable itself is not in scope when it is used. Two references can be compared for equality to test whether they govern the same underlying assignable. If two references are equal, then setting one will affect the result of getting the other; if they are not equal, then setting one cannot influence the result of getting from the other. Two references that govern the same underlying assignable are aliases. Aliasing complicates reasoning about programs that use references, because any two references may refer to the assignable.

Reference types are compatible with both a scoped and a scope-free allocation of assignables. When assignables are scoped, the range of significance of a reference type is limited to the scope of the assignable to which it refers. Reference types are therefore immobile, so that they cannot be returned from the body of a declaration, nor stored in an assignable. Although ensuring adherence to the stack discipline, this restriction precludes using references to create mutable data structures, those whose structure can be altered during execution. Mutable data structures have a number of applications in programming, including improving efficiency (often at the expense of expressiveness) and allowing cyclic (self-referential) structures to be created. Supporting mutability requires that assignables be given a scope-free dynamics, so that their lifetime persists beyond the scope of their declaration. Consequently, all types are mobile, so that a value of any type may be stored in an assignable or returned from a command.

Capabilities

The commands get[a] and set[a](e) in MA operate on statically specified assignable a. Even to write these commands requires that the assignable a be in scope where the command occurs. But suppose that we wish to define a procedure that, say, updates an assignable to double its previous value, and returns the previous value. We can write such a procedure for any given assignable, a, but what if we wish to write a generic procedure that works for any given assignable?