NORSK REGNESENTRAL NORWEGIAN COMPUTING CENTER OSLO 3 - NORWAY SIMULA information COMMON BASE LANGUAGE by Ole-Johan Dahl, Bjørn Myhrhaug and Kristen Nygaard NORWEGIAN COMPUTING CENTER Forskningsveien 1 B Oslo 3, Norway. Publication No. S-22 (Revised edition of publication S-2) October 1970 Authorized by SIMULA Standards Group as the Common Base from May 19th 1970. COMMON BASE LANGUAGE by Ole-Johan Dahl, Bjørn Myhrhaug and Kristen Nygaard SIMULA TM is trademark of Norwegian Computing Center c Copyright 1968, 1970, Norwegian Computing Center PREFACE TO THE 1968 EDITION SIMULA 67 is a general purpose programming language developed by the authors at the Norwegian Computing Center. Compilers for this language are now imple- mented on a number of different computers. The Norwegian Computing Center regards the SIMULA 67 language as its own property. The implementations have taken place under contracts with the NCC for professional assistance. A main characteristic of SIMULA is that it is easily structured towards specialized problem areas, and hence can be used as a basis for Special Application Languages. This report is a reference document for the SIMULA 67 Common Base. The Common Base comprises the language features required in every SIMULA 67 compiler. The "Introduction" highlights some features of the language. The following sections are intended as a precise language definition. Users manuals and textbooks will appear later. During our development of SIMULA 67 we have benefited from ideas and suggestions from a number of colleagues. First of all we should like to mention C.A.R. Hoare whose ideas on referencing have been used and extended, S. Kubosch who has been an important source of useful comments and criticism and Mrs. I. Siguenza whose help in the typing of this report has been indispensable. We should also like to express our gratitude to D. Belsnes, P. Blunden, J. Buxton, J.V. Garwick, Ø. Hjartøy, Ø. Hope, P. M. Kjeldaas, D. Knuth, J. Laski, A. Lunde, J. Newey, T. Noodt, K. S. Skog, C. Strachey and N. Wirth, as well as SIMULA I users who have given advice based upon their experience. Finally, the authors feel that they benefited very much from the SIMULA 67 Common Base Conference in Oslo, June 1967, and would like to thank the participants. Oslo, May 1968 Ole-Johan Dahl Bjørn Myhrhaug Kristen Nygaard PREFACE TO THE 1970 EDITION This revised version contains the modifications and clarifi- cations passed by the SIMULA Standards Group at their meeting in May 1970. Several minor errors have also been corrected. Compilers are now available on a wide range of computers, including CD 3300, CD 3600, CD 6600, UNIVAC 1108 and IBM 360/370. The authors would like to thank the members of the SIMULA Standards Group for their interest and help, and the typing pool and printing shop of the Norwegian Computing Center for their efficient work. We would also like to extend our list of acknowledgements in the original preface by K. Babcicky, G. M. Birtwistle, R. Kerr and M. Woodger. Oslo, October 1970 Ole-Johan Dahl Bjørn Myhrhaug Kristen Nygaard - 1 - 1. Introduction 1.1 General purpose programming languages High level languages, like FORTRAN, ALGOL 60 and COBOL were originally regarded as useful for two purposes: - to provide concepts and statements allowing a precise formal description of computing processes and also making communication between programmers easier. - to provide the non-specialist with a tool making it possible for him to solve small and medium-sized problems without specialist help. High level languages have succeeded in these respects. However, strong new support for these languages is developing from a fresh group: those who are confronted with the task of organizing and implementing very com- plex, highly interactive programs, e.g. large simulation programs. These tasks put new requirements on a language: - in order to decompose the problem into natural, easily conceived components, each part should be describable as an individual program. The language should provide for this and also contain means for describing the joint interactive execution of these sub-programs. - in order to relate and operate a collection of programs, the language should have the necessary powerful list processing and sequencing capabilities. - 2 - - in order to reduce the already excessive amount of debugging trouble associated with present day methods, the language should give "reference security". That is, the language and its compiler should spot and not execute invalid use of data through data referencing based on wrong assumptions. Even if the organizational aspects of complex programming are becoming more and more important, the computational aspects must, of course, be taken care of at least as well as in the current high-level languages. It is also evident that such a general language should be oriented towards a very wide area of use. The market cannot for long accommodate the present proliferation of languages. 1.2 Special application languages Until now, the computer has been a powerful but frightening tool to most people. This should be changed in the years to come, and the computer should be regarded as an obvious part of the human environment. More and more people should get their capabilities, increased through the availability of the "know-how" and data they need. A condition for this development is that the demands on the computer user are reduced, which implies that communication between man and computer is made easier. Know-how is today to a large extent made operative through "application packages" covering various fields of knowledge and methods. But these packages are in general not sufficiently flexible and expandable, and also often require specialist st assistance for their use. - 3 - The future seems to be "application languages" which are problem-oriented, perhaps in the extreme. Such languages may provide the basic concepts and methods associated with the field in question and allow the user to formulate his specific problem in accordance with his own earlier training. At the same time, such languages should be flexible in the sense that new knowledge acquired should be easily incorporated, even by the individual user. The need for application languages is apparently in conflict with the desire for the non-proliferation of languages and for general purpose programming languages. A solution is to design a general purpose programming language to serve as a "substrate" for the application languages by making it easy to orient towards special- ized fields, and to augment it by the introduction of additional aggregated concepts useful as "building blocks" for programming. By making the general purpose language highly standardized and available on many types of computers, the application languages also become easily transferable, and at the same time the software development costs for the computer manufacturers may be retarded from the present rapid increase. - 4 - 1.3 The basic characteristics of SIMULA 67 1.3.1 Algorithmic capability SIMULA 67 contains most features of the general algorithmic language ALGOL 60 as a subset. The reason for choosing ALGOL 60 as starting point was that its basic structure lent itself to extension. It was felt that it would be impractical for the users to base SIMULA 67 on yet another new algorithmic language, and ALGOL 60 already had a user basis, mainly in Europe. 1.3.2. Decomposition In dealing with problems and systems containing a large number of details, decomposition is of prime importance. The human mind must concentrate; it is a requirement for precise and coherent thinking that the number of concepts involved is small. By decomposing a large problem, one can obtain component problems of manageable size to be dealt with one at a time, and each containing a limited number of details. Suitable decomposition is an absolute requirement if more than one person takes part in the analysis and programming. The fundamental mechanism for decomposition in ALGOL 60 is the block concept. As far as local quantities are concerned, a block is completely independent of the rest of the program. The locality principle ensures that any reference to a local quantity is correctly interpreted regardless of the environment of the block. The block concept corresponds to the intuitive notion of "sub-problem" or "sub-algorithm" which is a useful unit of decomposition in orthodox application areas. - 5 - A block is a formal description, or "pattern", of an aggregated data structure and associated algorithms and actions. When a block is executed, a dynamic "instance" of the block is generated. In a computer, a block instance may take the form of a memory area containing the necessary dynamic block information and including space for holding the contents of variables local to the block. A block instance can be thought of as a textual copy of its formal description, in which local variables identify pieces of memory allocated to the block instance. Any inner block of a block instance is still a "pattern", in which occurrences of non-local identifiers, however, identify items local to textually enclosing block instances. Such "bindings" of identifiers non-local to an inner block remain valid for any subsequent dynamic instance of that inner block. The notion of block instances leads to the possibility of generating several instances of a given block which may co-exist and interact, such as, for example, instances of a recursive procedure. This further leads to the concept of a block as a "class" of "objects", each being a dynamic instance of the block, and there- fore conforming to the same pattern. An extended block concept is introduced through a "class" declaration and associated interaction mechanism such as "object references" (pointers), "remote accessing", "quasi-parallel" operation, and block "concatenation". - 6 - Whereas ALGOL 60 program execution consists of a sequence of dynamically nested block instances, block instances in SIMULA 67 may form arbitrary list structures. The interaction mechanisms which are introduced, serve to increase the power of the block concept as a means for decomposition and classification. 1.3.3 Classes A central new concept in SIMULA 67 is the "object". An object is a self-contained program (block instance), having its own local data and actions defined by a "class declaration". The class declaration defines a program (data and action) pattern, and objects conforming to that pattern are said to "belong to the same class". If no actions are specified in the class declaration, a class of pure data structures is defined. Example class order (number); integer number; begin integer number of units, arrival date; real processing time; end; A new object belonging to the class "order" is generated by an expression such as "new order (103)" and as many "orders" may be introduced as desired. - 7 - The need for manipulating objects and relating objects to each other makes it necessary to introduce list processing facilities (as described below). A class may be used as "prefix" to another class declaration, thereby building the properties defined by the prefix into the objects defined by the new class declaration. Examples: order class batch order; begin integer batch size; real setup time; end; order class single order; begin real setup time, finishing time,weight; end; single order class plate; begin real length, width; end; New objects belonging to the "sub-classes" - "batch order" "single order" and "plate" all have the data defined for "order", plus the additional data defined in the various class declarations. Objects belonging to the class "plate" will, for example, comprise the following pieces of information: "number", "number of units", "arrival date", "processing time", "setup time", "finishing time", "weight", "length" and "width". - 8 - If actions are defined in a class declaration, actions conforming to this pattern may be executed by all objects belonging to that class. The actions belonging to one object may all be executed in sequence, as for a procedure. But these actions may also be executed as a series of separate subsequences, or "active phases". Between two active phases of a given object, any number of active phases of other objects may occur. SIMULA 67 contains basic features necessary for organ- izing the total program execution as a sequence of active phases belonging to objects. These basic features may be the foundation for aggregated sequencing principles, of which the class SIMULATION is an example. 1.3.4 Application language capability SIMULA 67 may be oriented towards a special application area by defining a suitable class containing the necessary problem-oriented concepts. This class can then be used as prefix to the program by the user interested in this problem area. The unsophisticated user may restrict himself to using the aggregated, problem-oriented and familiar concepts as constituent "building blocks" in his programming. He may not need to know the full SIMULA 67 language, whereas the experienced programmer at the same time has the general language available, and he may extend the "application language" by new concepts defined by himself. As an example, in discrete event system simulation, the concept of "simulated system time" is commonly used. SIMULA 67 is turned into a simulation language by pro- viding the class "SIMULATION" as a part of the language, - 9 - (in this case provided with the compilers). In the class declaration class SIMULATION; begin ......................... end; a "time axis" is defined, as well as two-way lists (which may serve as queues), and also the class "process" which gives an object the property of having its active phases organized through the "time axis". A user wanting to write a simulation program starts his program by SIMULATION begin ............... in order to make all the simulation capabilities available in his program. If he himself wants to generate a special-purpose simulation language to be used in job-shop analysis, he may write: SIMULATION class JOBSHOP; begin ....................... end; and between "begin" and "end" define the building blocks he needs, such as process class crane; begin ...................... end; process class machine; begin procedure datacollection; ..... .............. end; etc. - 10 - The programmer now compiles this class, and whenever he or his colleagues want to use SIMULA 67 for jobshop simulation, they may write in their program JOBSHOP begin ................. thereby making available the concepts of both "SIMULATION" and "JOBSHOP". This facility requires that a mechanism for the incorporation of separately compiled classes is available in the compiler (see section 15). 1.3.5 List processing capability When many objects belonging to various classes do co-exist as parts of the same total program, it is necessary to be able to assign names to individual objects, and also to relate objects to each other, e.g. through binary trees and various other types of list structures. A system class, "SIMSET", introducing circular two-way lists is a part of the language. Hence basic new types, "references", are introduced. References are "qualified", which implies that a given reference only may refer to objects belonging to the class mentioned in the qualification (or belonging to subclasses of the qualifying class). Example: ref(order)next, previous; - 11 - The operation of making a reference denote a specified object is written ":-" and read "denotes". Example: next :- new order (101); previous :- next; or (also valid since "plate" is a subclass of "order") next :- new plate(50); Data belonging to other objects may be referred to and used by "remote accessing", utilizing a special "dot notation". Example: if next.number > previous.number then .....; comparing the "number" of the "order" named "next" with the "number"of the "order" named "previous". The "dot notation" gives access to individual pieces of information. "Group access" is achieved through "connection statements". Example: inspect next when plate do begin ..... end; In the statement between begin and end all pieces of information contained in the "plate" referenced by "next" may be referred to directly. - 12 - 1.3.6 String handling SIMULA 67 contains the new basic type "character". The representation of characters is implementation defined. In order to provide the desired flexibility in string handling, a compound type called "text" is introduced, The "text" concept is closely associated with input/ output facilities. 1.3.7 Input/output ALGOL 60 has been seriously affected by the lack of standardized input/output and string handling. Clearly a general purpose programming language should have great flexibility in these areas. Consequently, input/ output are defined and made a standardized part of SIMULA 67. 1.4 Standardization For a general purpose programming language it is of paramount importance that while the language is uniquely defined and at the same time under strict control, it may be extended in the future. This is achieved by the SIMULA Standard Group, consisting of representatives for firms and organizations having responsibility for SIMULA 67 compilers. The statutes lay down rigid rules to provide for both standardization and future extensions. The SIMULA definition which is required to be a part of any SIMULA 67 system is named the "SIMULA 67 Common Base Definition". - 13 - 1.5 Language definition The language definition given in the following sections must be supplemented by the formal definition of ALGOL 60 [1]. The syntactic definitions given in this report are to be understood in the following way. 1) Syntactic classes referred to, but not defined in this report, refer to syntactic definitions given in [1]. 2) Definitions in this report of syntactic classes defined in [1] replace the corresponding definitions given in [1]. 3) Any construction of the form stands for the list of alternative direct productions of according to the definition given in [1]. 4) The comment conventions given in [l] is extended in that the convention for "end-comment" is replaced by: > --> - 14 - - 15 - 2. Class declarations 2.1 Syntax ::= | | ::= ::== | ::= | virtual: ::= | ::= begin | ; | ; ::= end | ; ::= inner ::=
::= class ; 2.2 Semantics A class declaration serves to define the class associated with a class identifier. The class consists of "objects" each of which is a dynamic instance of the class body. An object is generated as the result of evaluating an object generator, which is the analogy of the "call" of a function designator, see section 4.3.2.2. - 16 - A class body always acts like a block. If it takes the form of a statement which is not an unlabelled block, the class body is identified with a block of the form begin; S end when S is the textual body. A split body acts as a block in which the symbol "inner" represents a dummy statement. For a given object the formal parameters, the quantities specified in the virtual part, and the quantities declared local to the class body are called the "attributes" of the object. A declaration or specification of an attribute is called an "attribute definition". Specification (in the specification part) is necessary for each formal parameter. The parameters are treated as variables local to the class body. They are initialized according to the rules of parameter trans- mission, (see section 8.2). Call by name is not avail- able for parameters of class declarations. The follow- ing specifiers are accepted: , array, and array. Attributes defined in the virtual part are called "virtual quantities". They do not occur in the formal parameter list. The virtual quantities have some properties which resemble formal parameters called by name. However, for a given object the environment of the corresponding "actual parameters" is the object itself, rather than that of the generating call. See section 2.2.3. - 17 - Identifier conflicts between formal parameters and other attributes defined in a class declaration are illegal. The declaration of an array attribute may in a con- stituent subscript bound expression make reference to the formal parameters of the class declaration. Example: The following class declaration expresses the notion of "n-point Gauss integration" as an aggregated concept. class Gauss (n); integer n; begin array W,X[1:n]; real procedure integral(F,a,b); real procedure F; real a,b; begin real sum, range; integer i; range := (b-a) ×0.5; for i := 1 step 1 until n do sum := sum + F(a+range ×(X[i]+1))× W[i]; integral := range × sum; end integral; comment compute the values of the elements of W and X as functions of n; ................. end Gauss; The optimum weights W and abcissae X can be computed as functions of n. By making the algorithm part of the class body, the evaluation and assignment of these values can be performed at the time of object generation. Several "Gauss" objects with different values of n may co-exist. Each object has a local procedure "integral" for the evaluation of the corresponding n-point formula. See also examples of section 6.1.2.2 and section 7.1.2. - 18 - 2.2.1 Subclasses A class declaration with the prefix "C" and the class identifier "D" defines a subclass D of the class C. An object belonging to the subclass consists of a "prefix part", which is itself an object of the class C, and a "main part" described by the main part of the class declaration. The two parts are "concatenated" to form one compound object. The class C may itself have, a prefix. Let C1, C2, ...., Cn be classes such that Ci has no prefix and Ck has the prefix Ck-1 (k = 2, 3, ....., n). Then C1, C2, ....., Ck-1 is called the "prefix sequence" of Ck (k = 2, 3,....., n). The subscript k of Ck (k = 1, 2, ......, n) is called the "prefix level" of the class. Ci is said to "include" Cj if i <= j, and Ci is called a "subclass" of Cj if i > j (i, j = 1, 2, ....., n). The prefix level of a class D is said to be "inner' to that of a class C if D is a subclass of C, and "outer" to that of C if C is a subclass of D. The figure 2.1 depicts a class hierarchy consisting of five classes, A, B, C, D and E: class A ......; A class B ......; B class C ......; B class D ......; A class E ......; A capital letter denotes a class. The corresponding lower case letter represents the attributes of the main part of an object belonging to that class. In an implementation of the language, the object structures shown in Fig. 2.2 may indicate the allocation in memory of the values of those attributes which are simple variables. - 19 - A | +---+---+ | | B E | +--+--+ | | C D Fig. 2.1 +-----+ +-----+ +-----+ +-----+ +-----+ | a | | a | | a | | a | | a | +-----+ +-----+ +-----+ +-----+ +-----+ | b | | b | | b | | e | +-----+ +-----+ +-----+ +-----+ | c | | d | +-----+ +-----+ Fig. 2.2 - 20 - The following restrictions must be observed in the use of prefixes: 1) A class must not occur in its own prefix sequence. 2) A class can be used as prefix only at the block level at which it is declared. A system class is considered to be declared in the smallest block enclosing its first textual occurrence. An implementation may restrict the number of different block levels at which such prefixes may be used. See sections 11, 14 and 15. 2.2.2 Concatenation Let Cn be a class with the prefix sequence C1, C2, ......, Cn-1, and let X be an object belonging to Cn, Informally, the concatenation mechanism has the following consequences. 1) X has a set of attributes which is the union of those defined in C1, C2, ......, Cn. An attribute defined in Ck (1<=k<=n) is said to be defined at prefix level k. 2) X has an "operation rule" consisting of statements from the bodies of these classes in a prescribed order. A statement from Ck is said to belong to prefix level k of X. 3) A statement at prefix level k of X has access to all attributes of X defined at prefix levels equal to or outer to k, but not directly to attributes "hidden" by conflicting definitions at levels <=k. These "hidden" attributes may be accessed through use of procedures or this). - 21 - 4) A statement at prefix level k of X has no immediate access to attributes of X defined at prefix levels inner to k, except through virtual quantities. (See section 2.2.3.) 5) In a split body at prefix level k, the symbol "inner" represents those statements in the operation rule of X which belong to prefix levels inner to k, or a dummy statement if k = n. If none of C1, ....., Cn-1 has a split body the statements in operation rule of X are ordered according to ascending prefix levels. A compound object could be described formally by a "concatenated" class declaration. The process of concatenation is considered to take place prior to program execution. In order to give a precise description of that process, we need the following definition. An occurrence of an identifier which is part of a given block is said to be "uncommitted occurrence in that block", except if it is the attribute identifier of a remote identifier (see section 7.1), or is part of an inner block in which it is given a local significance. In this context a "block" may be a class declaration not including its prefix and class identifier, or a procedure declaration not including its procedure identifier. (Notice that an uncommitted identifier occurrence in a block may well have a local significance in that block.) The class declarations of a given class hierarchy are processed in an order of ascending prefix levels. A class declaration with a non-empty prefix is replaced by a concatenated class declaration obtained by first modifying the given one in two steps. - 22 - 1. If the prefix refers to a concatenated class declaration, in which identifier substitutions have been carried out, then the same substitutions are effected for uncommitted identifier occurrences within the main part. 2. If now identifiers of attributes defined within the main part have uncommitted occurrences within the prefix class, then all uncommitted occurrences within the main part of these identifiers are systematically changed to avoid name conflicts. Identifiers corresponding to virtual quantities defined in the prefix class are not changed. The concatenated class declaration is defined in terms of the given declaration, modified as above, and the concatenated declaration of the prefix class. 1. Its formal parameter list consists of that of the prefix class followed by that of the main part. 2. Its value part, specification part, and virtual part are the unions (in an informal but obvious sense) of those of the prefix class and those of the main part. If the resulting virtual part contains more than one occurrence of some identifier, the virtual part of the given class declaration is illegal. 3. Its class body is obtained from that of the main part in the following way, assuming the body of the prefix class is a split body. The begin of the block head is replaced by a copy of the block head of the prefix body, a copy of the initial operations of the prefix body is inserted after the block head of the main part and the end of the - 23 - compound tail of the main part is replaced by a copy of the compound tail of the prefix body. If the prefix class body is not a split body, it is interpreted as if the symbols ";inner" were inserted in front of the end of its compound tail. If in the resulting class body two matching declara- tions for a virtual quantity are given (see section 2.2.3), the one copied from the prefix class body is deleted. The declaration of a label is its occurrence as the label of a statement. Examples: class point (x,y); real x,y; begin ref (point) procedure plus (P); ref (point) P; plus :- new point (x+P.x, y+P.y); end point; An object of the class point is a representation of a point in a Cartesian plane. Its attributes are x,y and plus, where plus represents the operation of vector addition. point class polar; begin real r,v; ref (polar) procedure plus (P); ref (point) P; plus :- new polar (x+P.x, y+P.y); r:= sqrt (x^2+y^2); v:= arctg (x,y); end polar; An object of the class polar is a "point" object with the additional attributes r,v and a redefined plus operation. The values of r and v are computed and assigned at the time of object generation. ("arctg" is a suitable non-local procedure.) - 24 - 2.2.3 Virtual quantities Virtual quantities serve a double purpose: 1) to give access at one prefix level of an object to attributes declared at inner prefix levels, and 2) to permit attribute redeclarations at one prefix level valid at outer prefix levels. The following specifiers are accepted in a virtual part: label, switch, procedure and procedure. A virtual quantity of an object is either "unmatched" or is identified with a "matching" attribute, which is an attribute whose identifier coincides with that of the virtual quantity, declared at the prefix level of the virtual quantity or at an inner one. The matching attribute must be of the same kind as the virtual quantity. At a given prefix level, the type of the matching quantity must coincide with or be subordinate to (see Section 3.2.5) that of the virtual specification and that of any matching quantity declared at any outer prefix level. It is a consequence of the concatenation mechanism that a virtual quantity of a given object can have at most one matching attribute. If matching declarations have been given at more than one prefix level of the class hierarchy, then the one is valid which is given at the innermost prefix level outer or equal to that of the main part of the object. The match is valid at all prefix levels of the object equal or inner to that of the virtual specification. - 25 - Example: The following class expresses a notion of "hashing", in which the "hash" algorithm itself is a "replaceable part". "error" is a suitable non-local procedure. class hashing (n); integer n; virtual: integer procedure hash; begin integer procedure hash (T); value T; text T; begin integer i; L: if T.more then begin i := i+rank (T.getchar); go to L; end; hash := i - (i ÷ n × n); end hash; text array table [O:n-1]; integer entries; integer procedure lookup (T,old); name old; value T; Boolean old; text T; begin integer i; i:= hash(T); L: if table[i] == notext then begin table[i] :- T; entries := entries+1; end else if table [i] = T then old := true else if entries = n then error("hash table filled completely") else begin i := i+1; if i= n then i := 0; go to L end; lookup := i; end lookup; end hashing; - 26 - hashing class ALGOL hash; begin integer procedure hash(T); value T; text T; begin integer i; character c; L: if T.more then begin c := T.getchar; if c <> '_' then i := i + rank(c); go to L; end; hash := i-(i ÷ n × n); end hash; end ALGOL hash; - 27 - 3. Types and variables 3.1 Syntax ::= ::= array | array ::= | ::= integer| real| Boolean| character ::= | text ::= ref () ::= 3.2 Semantics The syntax for type declaration represents a deviation from ALGOL 60, in that own is not a part of SIMULA 67. A "value" is a piece of information interpreted at run time to represent itself. Examples of values are: an instance of a real number, an object, or a piece of text. A "reference" is a piece of information which identifies a value, called the "referenced" value. The distinction between a reference and the referenced value is determined by context. The reference concept corresponds to the intuitive notion of a "name" or a "pointer". It'also reflects the addressing capability of computers: in certain simple cases a reference could be implemented as the memory address of a stored value. - 28 - For computer efficiency the reference concept is not introduced in its full generality. In particular, there is no reference concept associated with any value type. A variable local to a block instance is a memory device whose "contents" is either a value or a reference, according to the type of the variable. A value type variable has a value which is the contents of the variable. A reference type variable is said to have a value which is the one referenced by the contents of the variable. The contents of a variable may be changed by an appropriate assignment operation, see section 6.1. 3.2.1 Object references Associated with an object there is a unique "object reference" which identifies the object. And for any class C there is an associated reference type ref (C). A quantity of that type is said to be qualified by the class C. Its value is either an object, or the special value none which represents "no object". The qualifi- cation restricts the range of values to objects of classes included in the qualifying class. The range of values includes the value none regardless of the qualification. 3.2.2 Characters A character value is an instance of an "internal character". For any given implementation there is a one-one mapping between a subset of internal characters and external ("printable") characters. The character sets (internal and external) are implementation defined. - 29 - 3.2.2.1 Collating sequence The set of internal characters is ordered according to an implementation defined collating sequence. The collating sequence defines a one-one mapping between internal characters and integers expressed by the function procedures: integer procedure rank(c); character c; whose value is in the range [0,N-1], where N is the number of internal characters, and character procedure char(n); integer n; The parameter value must be in the range [0,N-1], otherwise a run time error is caused. Example: Most character codes are such that the digits (0-9) are character values which are consecutive and in ascending order with respect to the collating sequence. Under this assumption, the expressions "rank(c) - rank('0')" and "char(rank('0')+i)" provide implementation independent conversion between digits and their arithmetic values. 3.2.2.2 Character subsets Two character subsets are defined by the standard non-local procedures: Boolean procedure digit(c); character c; which is true if c is a digit, and Boolean procedure letter(c); character c; which is true if c is a letter. - 30 - 3.2.3 Text A text value is an ordered sequence, possibly empty, of internal characters. The number of characters is called the "length" of the text. A non-empty text value is either a "text object", or it is part of a longer character sequence which is a text object. A text reference identifies a text value. Certain properties of a text reference are represented by procedures accessible through remote accessing (the dot notation). The text concept is further described in section 10. 3.2.4 Initialization Any declared variable is initialized at the time of entry into the block to which the variable is local. The initial contents depends on the type of the variable. real 0.0 integer 0 Boolean false character implementation defined object reference none text notext (see section 10) 3.2.5 Subordinate types An object reference is said to be "subordinate" to a second object reference if the qualification of the former is a subclass of the class which qualifies the latter. A proper procedure is said to be of "type universal". Any type is subordinate to the universal type. (Cf. sections 2.2.3, 8.2.2 and 8.2.3.) - 31 - 4. Expressions 4.1 Syntax