A SURVEY OF THE USE OF TYPE 265
Thus each variable, constant, and expression has one of the types integer, real or Boolean, meaning that its value is integral, rea~ or Boolean. Although it was noticed that type had a mathematical definition, Alan Perlis, one of the authors of ALGOL 60, has informed me that type was used in ALGOL 60 in a nontechnical sense-it was simply a word, roughly equivalent to kind, used to aid in distinguishing different classes of objects. Note that in ALGOL 60 an array identifier does not name a variable, and its value has no type. Instead, an ALGOL 60 identifier b (say) declared as integer array [1: 10] is viewed simply as a convenient notational device for manipulating individuals in the collection of subscripted variables b[ 1 ], ... ,b[1 0]. The concept array allowed the use of one name for represent• ing ma'V' variables, but it did not allow an array to be considered as a value in itself, to be referred to as a whole. This view was carried over to extensions of ALGOL-for example, in the Perlis-Ituriaga-Standish definition of FOR• MULA-ALGOL in 1966. The designers of FORTRAN also used type in a nontechnical sense. For example, one early text (McCracken'S Guide to FORTRAN Programming), considers "two kinds of numbers that can be used in FORTRAN" but discusses "four types of functions ... ". COBOL did not and does not use the mathematical term variable; instead, data is associated with data names. The use of type as a formal programming language term is perhaps due (more than to a'V'thing else) to the fact that the syntax of ALGOL 60 was defined rigorously in a formal (BNF) grammar; the use of the rule
Problems with programmer-defined types introduced the need for defining the term type more precisely. The first notion seems to have been that a type simply is, or defines, a set of values, and this view corresponded closely with Russell's. Thus, in [Wirth 66*] we find:
Every value is said to be of a certain type. The types of simple values are: integer: the value is an integer; .. .;bits; the value is a linear sequence of bits.
The Pascal report [Wirth 71 c*] says that "the data type essentially defines the set of values which may be assumed ... . " ALGOL 68 also seems to consider "modes," i.e., generalizations of the concept "type," as sets of structured values. Indeed, the paper [Lewis 73], which extends and formalizes the ALGOL 68 approach to data types, says that "a data type in this system is a'V' of certain sets of values." In the same Proceedings [Fischer 73] says that "abstractly, a data type T can be characterized as a set of objects, ... , all identifiable as members of T. " But note how almost all these quotes secure their position by using a word (basically, essentially, abstractly) to indicate that there may be more to a type than a set, but that the exact meaning of type is not of interest. The monograph [Hoare 72d*] contains a good description of the salient characteristics of type as used in a programming language, which we quote here:
(l) A type determines the class of values which may be assumed by a variable or expression. (2) Every value belongs to one and only one type. [This is open to debate. An early text with two of the ALGOL 60 authors as coauthors [Baumann 64] states that "type real, in accordance with standard mathematical usage, includes type integer. " One also has problems in this regard with subrange types in Pascal.] (3) The type of a value denoted by any constant, variable, or expression may be deduced from its form or context, without any knowledge of its value as computed at runtime. (4) Each operator expects operands of some fixed type, and delivers a result of some fixed type ... Where the same symbol is applied to several different types ... this symbol may be regarded as ambiguous, denoting several different actual operators. The resolution of such systematic ambiguity can always be made at compile time. (5) The properties of the values of a type and of the primitive operations defined over them are specified by means of a set of axioms. (6) Type information is used in a high-level language both to prevent or detect meaningless construction in a program, and to determine the method of representing and manipulating data on a computer. (7) The types in which we are interested are those already familiar to mathematicians; namely Cartesian Products, Discriminated Union, Sets, Functions, Sequences, and Recursive Structures. A SURVEY OF THE USE OF TYPE 267
While not providing us with a precise definition of type that can be used in developing type-defining mechanisms, Hoare has explained very well what we would like to gain from having types in a language. Note that Hoare does not say that a type is a class of values, or that a class of values determines a type, but that a type determines a class of values. This leaves open the possibility that the type may determine other things as well, such as the primitive operations on those values (as implied by characteristic (5) above). Jim Morris, in a paper entitled Types are not sets [Morris 73], provides an interesting viewpoint. He says that there must be more to a type than a set, but instead oj defining type he Jocuses on the role oj type checking. After discussing two purposes oj type checking~uthentication and secrecy-he says that whether a value belongs to a type should not turn on what the value is, but rather where it came Jrom and who created it / Currently, one finds at least the Jollowing interpretations of type, with interpretation (3) being the prevalent informal one. The interpretation one chooses Jor a language will have a marked effect on the language.
1. Type is a syntactic concept associated with constants, variables, and expressions, but not with values. 2. A type is a set oj values. 3. A type is a set oj values together with a set oj primitive operations. 4. A type is defined by the definition of a set of operators, but there may be many models (implementations, in terms oj set oj values and operators) consistent with the deJinition. 5. A type is determined by the representation oj its values in terms oj more primitive types. 6. A type is determined by the representation oj its values and a set oj procedures operating on the representation. 7. Types are defined as equivalence classes oj variables and constants. It is interesting to speculate when and where primitive operations became part oj a type. The earliest reJerence I could Jind oj this view is [Laski 68]. In it, John Laski says:
Briefly, the type oj an object is defined by describing the operators that may be applied to it. An operator may be applied to object(s) oj appropriate types. It may produce as a result an object oj specified type, and it may alter values oj the objects to which it is applied ... Finally, and most importantly, equivalences exist between various sequences oj operator application, and these may be expressed by axioms.
And Laski gives the necessary axioms Jor the types integer and set. Laski's view oj types does appear implicitly in a 1968-vintage language: SIMULA 67. The SIMULA class declaration can be used to define a set oj values and primitive operations on them, and the first article in this section uses the class notation with a minimum oj changes Jor precisely this purpose. 268 IV DATA TYPES
The SIMULA 67 designers were not concerned with the issue of type, and this is why the class declaration is not described in terms of programmer-defined types. Instead, they concentrated on power and flexibility, and wanted to be able to describe "patterns of data and actions" with the class declaration. In designing SIMULA 67, little attention was paid to a topic that was on few people's minds at the time: the need for protection from ma1V' types (kinds) of errors that a programming language should provide.
The Articles in Part IV
The three articles contained here discuss different aspects of types. The first is by C.A.R. (Tony) Hoare. Using the notation of the SIMULA 67 class to specify the association between an abstract type and its concrete representa• tion, Hoare discusses proof of correctness of data representations in terms of the axiomatic semantics developed in Part II. This article contributes funda• mental ideas that are used in current research in programming language design, e.g., ALPHARD [Wulf 77], CLU [Liskov 76], and EUCLID [Horning 77c*]. The second article, by John Guttag and Jim Horning, develops an approach to the specification of abstract data types. Instead of describing each primitive operation by a "proof rule," they suggest giving a set of axioms that specifies the interrelationship between the primitive operations (in much the same way as [Laski 68] does.) The paper, based on formal work dealing with heteroge• neous algebras, shows how abstract theory can be applied to yield insight into the solution of practical problems. John Reynold's article looks at two complementary approaches to data abstraction: the conventional programmer-defined type mechanism and "proce• dural data abstraction". Through an example, the advantages and disadvan• tages of both methods are discussed and compared This paper appeared in the Proceedings of the IFIP WG2.3 meeting held in Munich, Germany, in September 1975; it has not been formally published.