Contents   Index   Search   Previous   Next

3.2 Types and Subtypes

Static Semantics

   {type} {primitive operation [partial]} A type is characterized by a set of values, and a set of primitive operations which implement the fundamental aspects of its semantics. {object [partial]} An object of a given type is a run-time entity that contains (has) a value of the type.
Glossary entry: {Type} Each object has a type. A type has an associated set of values, and a set of primitive operations which implement the fundamental aspects of its semantics. Types are grouped into classes. The types of a given class share a set of primitive operations. {closed under derivation} Classes are closed under derivation; that is, if a type is in a class, then all of its derivatives are in that class.
Glossary entry: {Subtype} A subtype is a type together with a constraint, which constrains the values of the subtype to satisfy a certain condition. The values of a subtype are a subset of the values of its type.
   {class (of types)} Types are grouped into classes of types, reflecting the similarity of their values and primitive operations. {language-defined class (of types)} There exist several language-defined classes of types (see NOTES below). {elementary type} Elementary types are those whose values are logically indivisible; {composite type} {component} composite types are those whose values are composed of component values. {aggregate: See also composite type}
Glossary entry: {Class} {closed under derivation} A class is a set of types that is closed under derivation, which means that if a given type is in the class, then all types derived from that type are also in the class. The set of types of a class share common properties, such as their primitive operations.
Glossary entry: {Elementary type} An elementary type does not have components.
Glossary entry: {Composite type} A composite type has components.
Glossary entry: {Scalar type} A scalar type is either a discrete type or a real type.
Glossary entry: {Access type} An access type has values that designate aliased objects. Access types correspond to ``pointer types'' or ``reference types'' in some other languages.
Glossary entry: {Discrete type} A discrete type is either an integer type or an enumeration type. Discrete types may be used, for example, in case_statements and as array indices.
Glossary entry: {Real type} A real type has values that are approximations of the real numbers. Floating point and fixed point types are real types.
Glossary entry: {Integer type} Integer types comprise the signed integer types and the modular types. A signed integer type has a base range that includes both positive and negative numbers, and has operations that may raise an exception when the result is outside the base range. A modular type has a base range whose lower bound is zero, and has operations with ``wraparound'' semantics. Modular types subsume what are called ``unsigned types'' in some other languages.
Glossary entry: {Enumeration type} An enumeration type is defined by an enumeration of its values, which may be named by identifiers or character literals.
Glossary entry: {Character type} A character type is an enumeration type whose values include characters.
Glossary entry: {Record type} A record type is a composite type consisting of zero or more named components, possibly of different types.
Glossary entry: {Record extension} A record extension is a type that extends another type by adding additional components.
Glossary entry: {Array type} An array type is a composite type whose components are all of the same type. Components are selected by indexing.
Glossary entry: {Task type} A task type is a composite type whose values are tasks, which are active entities that may execute concurrently with other tasks. The top-level task of a partition is called the environment task.
Glossary entry: {Protected type} A protected type is a composite type whose components are protected from concurrent access by multiple tasks.
Glossary entry: {Private type} A private type is a partial view of a type whose full view is hidden from its clients.
Glossary entry: {Private extension} A private extension is like a record extension, except that the components of the extension part are hidden from its clients.
   {scalar type} The elementary types are the scalar types (discrete and real) and the access types (whose values provide access to objects or subprograms). {discrete type} {enumeration type} Discrete types are either integer types or are defined by enumeration of their values (enumeration types). {real type} Real types are either floating point types or fixed point types.
   The composite types are the record types, record extensions, array types, task types, and protected types. {private type} {private extension} A private type or private extension represents a partial view (see 7.3) of a type, providing support for data abstraction. A partial view is a composite type.
To be honest: The set of all record types do not form a class (because tagged record types can have private extensions), though the set of untagged record types do. In any case, what record types had in common in Ada 83 (component selection) is now a property of the composite class, since all composite types (other than array types) can have discriminants. Similarly, the set of all private types do not form a class (because tagged private types can have record extensions), though the set of untagged private types do. Nevertheless, the set of untagged private types is not particularly ``interesting'' -- more interesting is the set of all nonlimited types, since that is what a generic formal (nonlimited) private type matches.
   {discriminant} Certain composite types (and partial views thereof) have special components called discriminants whose values affect the presence, constraints, or initialization of other components. Discriminants can be thought of as parameters of the type.
   {subcomponent} The term subcomponent is used in this International Standard in place of the term component to indicate either a component, or a component of another subcomponent. Where other subcomponents are excluded, the term component is used instead. {part (of an object or value)} Similarly, a part of an object or value is used to mean the whole object or value, or any set of its subcomponents.
Discussion: The definition of ``part'' here is designed to simplify rules elsewhere. By design, the intuitive meaning of ``part'' will convey the correct result to the casual reader, while this formalistic definition will answer the concern of the compiler-writer.
We use the term ``part'' when talking about the parent part, ancestor part, or extension part of a type extension. In contexts such as these, the part might represent an empty set of subcomponents (e.g. in a null record extension, or a nonnull extension of a null record). We also use ``part'' when specifying rules such as those that apply to an object with a ``controlled part'' meaning that it applies if the object as a whole is controlled, or any subcomponent is.
   {constraint [partial]} The set of possible values for an object of a given type can be subjected to a condition that is called a constraint {null constraint} (the case of a null constraint that specifies no restriction is also included)[; the rules for which values satisfy a given kind of constraint are given in 3.5 for range_constraints, 3.6.1 for index_constraints, and 3.7.1 for discriminant_constraints].
   {subtype} A subtype of a given type is a combination of the type, a constraint on values of the type, and certain attributes specific to the subtype. The given type is called the type of the subtype. Similarly, the associated constraint is called the constraint of the subtype. The set of values of a subtype consists of the values of its type that satisfy its constraint. {belong (to a subtype)} Such values belong to the subtype.
Discussion: We make a strong distinction between a type and its subtypes. In particular, a type is not a subtype of itself. There is no constraint associated with a type (not even a null one), and type-related attributes are distinct from subtype-specific attributes.
Discussion: We no longer use the term "base type." All types were "base types" anyway in Ada 83, so the term was redundant, and occasionally confusing. In the RM95 we say simply "the type of the subtype" instead of "the base type of the subtype."
Ramification: The value subset for a subtype might be empty, and need not be a proper subset.
To be honest: Any name of a class of types (such as ``discrete'' or ``real''), or other category of types (such as ``limited'' or ``incomplete'') is also used to qualify its subtypes, as well as its objects, values, declarations, and definitions, such as an ``integer type declaration'' or an ``integer value.'' In addition, if a term such as ``parent subtype'' or ``index subtype'' is defined, then the corresponding term for the type of the subtype is ``parent type'' or ``index type.''
Discussion: We use these corresponding terms without explicitly defining them, when the meaning is obvious.
   {constrained} {unconstrained} {constrained (subtype)} {unconstrained (subtype)} A subtype is called an unconstrained subtype if its type has unknown discriminants, or if its type allows range, index, or discriminant constraints, but the subtype does not impose such a constraint; otherwise, the subtype is called a constrained subtype (since it has no unconstrained characteristics).
Discussion: In an earlier version of Ada 9X, "constrained" meant "has a non-null constraint." However, we changed to this definition since we kept having to special case composite non-array/non-discriminated types. It also corresponds better to the (now obsolescent) attribute 'Constrained.
For scalar types, ``constrained'' means ``has a non-null constraint''. For composite types, in implementation terms, ``constrained'' means that the size of all objects of the subtype is the same, assuming a typical implementation model.
Class-wide subtypes are always unconstrained.
2  Any set of types that is closed under derivation (see 3.4) can be called a ``class'' of types. However, only certain classes are used in the description of the rules of the language -- generally those that have their own particular set of primitive operations (see 3.2.3), or that correspond to a set of types that are matched by a given kind of generic formal type (see 12.5). {language-defined class [partial]} The following are examples of ``interesting'' language-defined classes: elementary, scalar, discrete, enumeration, character, boolean, integer, signed integer, modular, real, floating point, fixed point, ordinary fixed point, decimal fixed point, numeric, access, access-to-object, access-to-subprogram, composite, array, string, (untagged) record, tagged, task, protected, nonlimited. Special syntax is provided to define types in each of these classes.
Discussion: {value} A value is a run-time entity with a given type which can be assigned to an object of an appropriate subtype of the type. {operation} An operation is a program entity that operates on zero or more operands to produce an effect, or yield a result, or both.
Ramification: Note that a type's class depends on the place of the reference -- a private type is composite outside and possibly elementary inside. It's really the view that is elementary or composite. Note that although private types are composite, there are some properties that depend on the corresponding full view -- for example, parameter passing modes, and the constraint checks that apply in various places.
Not every property of types represents a class. For example, the set of all abstract types does not form a class, because this set is not closed under derivation.
The set of limited types forms a class in the sense that it is closed under derivation, but the more interesting class, from the point of generic formal type matching, is the set of all types, limited and nonlimited, since that is what matches a generic formal ``limited'' private type. Note also that a limited type can ``become nonlimited'' under certain circumstances, which makes ``limited'' somewhat problematic as a class of types.
These language-defined classes are organized like this:
all types
               other enumeration
               signed integer
               modular integer
            floating point
            fixed point
               ordinary fixed point
               decimal fixed point
         other array
      untagged record
The classes ``numeric'' and ``nonlimited'' represent other classification dimensions and do not fit into the above strictly hierarchical picture.

Wording Changes from Ada 83

This clause and its subclauses now precede the clause and subclauses on objects and named numbers, to cut down on the number of forward references.
We have dropped the term "base type" in favor of simply "type" (all types in Ada 83 were "base types" so it wasn't clear when it was appropriate/necessary to say "base type"). Given a subtype S of a type T, we call T the "type of the subtype S."

Contents   Index   Search   Previous   Next   Legal