CHAPTER 4: Types

4.1 Introduction

There are several important reasons why it is found desirable to associate a type with constants and variables:

Factorization of Properties, Maintainability

Knowledge about common properties of objects should be described and collected in one place and a name should be associated with that description. A type declaration serves that purpose. Subsequently, the type name may be used to refer to the common properties in object declarations. This factorization improves program maintainability: if later a given property is to be changed, then the type declaration will be the only part of the program text to be affected by the change.

Reliability

Objects with distinct properties should be clearly distinguished in a program, and the distinction should be enforced by the compiler. Requiring that all objects be typed thus contributes to program reliability. Experience has shown that a well-written program in Pascal can be recognized easily by the use made of the typing facility to increase the reliability, readability, and security of the program.

Abstraction, Hiding of Implementation Details

Abstract or external properties of objects and operations should be separated from underlying and internal implementation-dependent properties, such as the physical representation on a specific machine. The abstract properties of an object are the only ones that need to be known for its use. Implementation details should therefore be hidden from the user. The need for such a separation is particularly strong in the case of disjoint sections of a program text, produced and maintained by different programmers, and presumably separately compiled.

(a) Static versus Dynamic Properties

Should both the static properties - those which are determinable from an analysis of the program text at compilation time - and the dynamic properties - those which may depend on the dynamic execution of a program, such as reading from an input device - be covered by a single notion of type?

(b) Type Equivalence

Should the language provide some form of equivalence or compatibility among types with logically related properties?

(c) Parameterization

Should the language provide some form of parameterization for types and their associated properties? Should the evaluation of type parameters be performed at translation time or should it be deferred until execution time?

(a) Static versus Dynamic Properties

Two notions are distinguished: the notion of type and the notion of subtype. A type characterizes a distinct set of values and its static properties, such as the applicable operations.

Constraints may be imposed on named types: for example a range constraint for a scalar type, or an index constraint for an array type. In general, constraints define certain requirements whose satisfaction is to be checked dynamically. A subtype name serves as an abbreviation for a type name together with a constraint associated with the type. Several difficulties in the types of Pascal that have been noted by Habermann and others [Hab 73, WSH 77] are overcome in Ada by the notion of subtype.

(b) Type Equivalence

Each type declaration defines a distinct type. In consequence, each type name denotes a distinct type. Values of a given type can be assigned only to objects that have this type. Values of different types cannot be intermixed.

In contrast, objects that have different subtypes of the same type are compatible: the value of an object may be assigned to a variable that has the same type, whether or not the object and the variable have the same subtype. Constraints are normally checked at execution time, although in many cases these checks can be done at compilation time, in anticipation.

Certain explicit conversions are allowed between closely related types. Such explicit conversions are defined among numeric types, among sufficiently similar array types, and among derived types of the same family. Being explicit, these conversions are safe. On the other hand, no implicit conversion is possible among user-defined types.

(c) Parameterization

Parameterization at execution time is closely associated with the notion of constraint. In particular this applies to array and record types:

• An unconstrained array type declaration has unspecified index bounds. These are subsequently specified by an index constraint for a given array object so that different array objects of the same type may have different numbers of components. If such an array is a formal parameter of a subprogram, its bounds are obtained from the actual parameter for each call.

• A record type may have special components which are called discriminants and whose values are used at execution time to discriminate among alternative variants of the record type. For example, the value of a discriminant may be used to determine a bound of a record component that is itself an array. It is possible to constrain a record by a discriminant constraint, which imposes (and establishes) certain values for the discriminants. As in the case of arrays, it is possible to write subprograms of general utility which operate on records with arbitrary discriminant values.

Parameterization at compilation time is achieved by the very powerful mechanism of generic units. Whereas parameterization at execution time by index bounds and discriminants is limited to scalar values, the parameters of generic units can even be subprograms and types. For example, we could model the length of a stack by a discriminant; but, to allow for different types of elements, we would need to define stacks within a generic package and have the element type be a generic parameter. We could then create several instances of the generic package, for example one for stacks of integers, one for stacks of characters, and so on.