INTERNATIONAL STANDARD ISO/IEC 8652:1995(E) CHANGES TO ADA -- 1987 TO 1995 Language and Standard Libraries Version 6.0 21 December 1994 Copyright (C) 1992,1993,1994,1995 Intermetrics, Inc. This copyright is assigned to the U.S. Government. All rights reserved. This document may be copied, in whole or in part, in any form or by any means, as is or with alterations, provided that (1) alterations are clearly marked as alterations and (2) this copyright notice is included unmodified in any copy. Compiled copies of standard library units and examples need not contain this copyright notice so long as the notice is included in all copies of source code and documentation. INTERNATIONAL ORGANIZATION FOR STANDARDIZATION INTERNATIONAL ELECTROTECHNICAL COMMISSION Copyright (C) 1992,1993,1994,1995 Intermetrics, Inc. This copyright is assigned to the U.S. Government. All rights reserved. This document may be copied, in whole or in part, in any form or by any means, as is or with alterations, provided that (1) alterations are clearly marked as alterations and (2) this copyright notice is included unmodified in any copy. Compiled copies of standard library units and examples need not contain this copyright notice so long as the notice is included in all copies of source code and documentation. Foreword This document lists in detail the changes introduced in the second (Ada 9X) edition of the Ada standard (ISO/IEC 8652:1995) with respect to the first (Ada 83) edition (ISO 8652:1987). ---------------------- INTERNATIONAL STANDARD ---------------------- Information technology -- Programming Languages -- Ada Section 1: General 1.1 Scope 1.1.1 Extent 1.1.2 Structure Inconsistencies With Ada 83 0.a This heading lists all of the upward inconsistencies between Ada 83 and Ada 9X. Upward inconsistencies are situations in which a legal Ada 83 program is a legal Ada 9X program with different semantics. This type of upward incompatibility is the worst type for users, so we only tolerate it in rare situations. 0.b (Note that the semantics of a program is not the same thing as the behavior of the program. Because of Ada's indeterminacy, the ``semantics'' of a given feature describes a set of behaviors that can be exhibited by that feature. The set can contain more than one allowed behavior. Thus, when we ask whether the semantics changes, we are asking whether the set of behaviors changes.) 0.c This is not part of the definition of the language, and does not appear in the RM9X. Incompatibilities With Ada 83 0.d This heading lists all of the upward incompatibilities between Ada 83 and Ada 9X, except for the ones listed under ``Inconsistencies With Ada 83'' above. These are the situations in which a legal Ada 83 program is illegal in Ada 9X. We do not generally consider a change that turns erroneous execution into an exception, or into an illegality, to be upwardly incompatible. 0.e This is not part of the definition of the language, and does not appear in the RM9X. Extensions to Ada 83 0.f This heading is used to list all upward compatible language changes; that is, language extensions. These are the situations in which a legal Ada 9X program is not a legal Ada 83 program. The vast majority of language changes fall into this category. 0.g This is not part of the definition of the language, and does not appear in the RM9X. 0.h As explained above, the next heading does not represent any language change: Wording Changes From Ada 83 0.i This heading lists some of the non-semantic changes between RM83 and the RM9X. It is incomplete; we have not attempted to list all wording changes, but only the ``interesting'' ones. 0.j This is not part of the definition of the language, and does not appear in the RM9X. 1.1.3 Conformity of an Implementation with the Standard 1.1.4 Method of Description and Syntax Notation 1.1.5 Classification of Errors Wording Changes From Ada 83 0.a Some situations that are erroneous in Ada 83 are no longer errors at all. For example, depending on the parameter passing mechanism when unspecified is possibly non-portable, but not erroneous. 0.b Other situations that are erroneous in Ada 83 are changed to be bounded errors. In particular, evaluating an uninitialized scalar variable is a bounded error. The possible results are to raise Program_Error (as always), or to produce a machine-representable value (which might not be in the subtype of the variable). Violating a Range_Check or Overflow_Check raises Constraint_Error, even if the value came from an uninitialized variable. This means that optimizers can no longer ``assume'' that all variables are initialized within their subtype's range. Violating a check that is suppressed remains erroneous. 0.c The ``incorrect order dependences'' category of errors is removed. All such situations are simply considered potential non-portabilities. This category was removed due to the difficulty of defining what it means for two executions to have a ``different effect.'' For example, if a function with a side-effect is called twice in a single expression, it is not in principle possible for the compiler to decide whether the correctness of the resulting program depends on the order of execution of the two function calls. A compile time warning might be appropriate, but raising of Program_ Error at run time would not be. 1.2 Normative References 1.3 Definitions Section 2: Lexical Elements 2.1 Character Set Extensions to Ada 83 0.a Ada 9X allows 8-bit and 16-bit characters, as well as implementation-specified character sets. Wording Changes From Ada 83 0.b The syntax rules in this clause are modified to remove the emphasis on basic characters vs. others. (In this day and age, there is no need to point out that you can write programs without using (for example) lower case letters.) In particular, character (representing all characters usable outside comments) is added, and basic_graphic_character, other_special_character, and basic_character are removed. Special_character is expanded to include Ada 83's other_special_character, as well as new 8-bit characters not present in Ada 83. Note that the term ``basic letter'' is used in A.3, ``Character Handling'' to refer to letters without diacritical marks. 0.c Character names now come from ISO 10646. 0.d We use identifier_letter rather than letter since ISO 10646 BMP includes many "letters' that are not permitted in identifiers (in the standard mode). 2.2 Lexical Elements, Separators, and Delimiters 2.3 Identifiers Wording Changes From Ada 83 0.a We no longer include reserved words as identifiers. This is not a language change. In Ada 83, identifier included reserved words. However, this complicated several other rules (for example, regarding implementation-defined attributes and pragmas, etc.). We now explicitly allow certain reserved words for attribute designators, to make up for the loss. 2.4 Numeric Literals 2.4.1 Decimal Literals Wording Changes From Ada 83 0.a We have changed the syntactic category name integer to be numeral. We got this idea from ACID. It avoids the confusion between this and integers. (Other places don't offer similar confusions. For example, a string_literal is different from a string.) 2.4.2 Based Literals Wording Changes From Ada 83 0.a The rule about which letters are allowed is now encoded in BNF, as suggested by Mike Woodger. This is clearly more readable. 2.5 Character Literals Wording Changes From Ada 83 0.a The definitions of the values of literals are in Sections 3 and 4, rather than here, since it requires knowledge of types. 2.6 String Literals Wording Changes From Ada 83 0.a The wording has been changed to be strictly lexical. No mention is made of string or character values, since string_literals are also used to represent operator_symbols, which don't have a defined value. 0.b The syntax is described differently. 2.7 Comments 2.8 Pragmas Incompatibilities With Ada 83 0.a In Ada 83, ``bad'' pragmas are ignored. In Ada 9X, they are illegal, except in the case where the name of the pragma itself is not recognized by the implementation. Extensions to Ada 83 0.b Implementation-defined pragmas may affect the legality of a program. Wording Changes From Ada 83 0.c Implementation-defined pragmas may affect the run-time semantics of the program. This was always true in Ada 83 (since it was not explicitly forbidden by RM83), but it was not clear, because there was no definition of ``executing'' or ``elaborating'' a pragma. Extensions to Ada 83 0.d The Optimize pragma now allows the identifier Off to request that normal optimization be turned off. 0.e An Optimize pragma may appear anywhere pragmas are allowed. Wording Changes From Ada 83 0.f We now describe the pragmas Page, List, and Optimize here, to act as examples, and to remove the normative material from Annex L, ``Language-Defined Pragmas'', so it can be entirely an informative annex. 2.9 Reserved Words Incompatibilities With Ada 83 0.a The following words are not reserved in Ada 83, but are reserved in Ada 9X: abstract, aliased, protected, requeue, tagged, until. Wording Changes From Ada 83 0.b The clause entitled ``Allowed Replacements of Characters'' has been moved to Annex J, ``Obsolescent Features''. Section 3: Declarations and Types 3.1 Declarations Wording Changes From Ada 83 0.a The syntax rule for defining_identifier is new. It is used for the defining occurrence of an identifier. Usage occurrences use the direct_name or selector_name syntactic categories. Each occurrence of an identifier (or simple_name), character_literal, or operator_ symbol in the Ada 83 syntax rules is handled as follows in Ada 9X: 0.b It becomes a defining_identifier, defining_character_ literal, or defining_operator_symbol (or some syntactic category composed of these), to indicate a defining occurrence; 0.c It becomes a direct_name, in usage occurrences where the usage is required (in Section 8) to be directly visible; 0.d It becomes a selector_name, in usage occurrences where the usage is required (in Section 8) to be visible but not necessarily directly visible; 0.e It remains an identifier, character_literal, or operator_ symbol, in cases where the visibility rules do not apply (such as the designator that appears after the end of a subprogram_body). 0.f For declarations that come in ``two parts'' (program unit declaration plus body, private or incomplete type plus full type, deferred constant plus full constant), we consider both to be defining occurrences. Thus, for example, the syntax for package_body uses defining_identifier after the reserved word body, as opposed to direct_name. 0.g The defining occurrence of a statement name is in its implicit declaration, not where it appears in the program text. Considering the statement name itself to be the defining occurrence would complicate the visibility rules. 0.h The phrase ``visible by selection'' is not used in Ada 9X. It is subsumed by simply ``visible'' and the Name Resolution Rules for selector_names. 0.i (Note that in Ada 9X, a declaration is visible at all places where one could have used a selector_name, not just at places where a selector_name was actually used. Thus, the places where a declaration is directly visible are a subset of the places where it is visible. See Section 8 for details.) 0.j We use the term ``declaration'' to cover _specifications that declare (views of) objects, such as parameter_specifications. In Ada 83, these are referred to as a ``form of declaration,'' but it is not entirely clear that they are considered simply ``declarations.'' 0.k RM83 contains an incomplete definition of "elaborated" in this clause: it defines "elaborated" for declarations, declarative_parts, declarative_items and compilation_units, but "elaboration" is defined elsewhere for various other constructs. To make matters worse, Ada 9X has a different set of elaborable constructs. Instead of correcting the list, it is more maintainable to refer to the term "elaborable," which is defined in a distributed manner. 0.l RM83 uses the term ``has no other effect'' to describe an elaboration that doesn't do anything except change the state from not-yet-elaborated to elaborated. This was a confusing wording, because the answer to ``other than what?'' was to be found many pages away. In Ada 9X, we change this wording to ``has no effect'' (for things that truly do nothing at run time), and ``has no effect other than to establish that so-and-so can happen without failing the Elaboration_Check'' (for things where it matters). 0.m We make it clearer that the term "execution" covers elaboration and evaluation as special cases. This was implied in RM83. For example, "erroneous execution" can include any execution, and RM83-9.4(3) has, "The task designated by any other task object depends on the master whose execution creates the task object;" the elaboration of the master's declarative_part is doing the task creation. 3.2 Types and Subtypes Wording Changes From Ada 83 0.a 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. 0.b 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." 3.2.1 Type Declarations Wording Changes From Ada 83 0.a The syntactic category full_type_declaration now includes task and protected type declarations. 0.b We have generalized the concept of first-named subtype (now called simply ``first subtype'') to cover all kinds of types, for uniformity of description elsewhere. RM83 defined first-named subtype in Section 13. We define first subtype here, because it is now a more fundamental concept. We renamed the term, because in Ada 9X some first subtypes have no name. 0.c We no longer elaborate discriminant_parts, because there is nothing to do, and it was complex to say that you only wanted to elaborate it once for a private or incomplete type. This is also consistent with the fact that subprogram specifications are not elaborated (neither in Ada 83 nor in Ada 9X). Note, however, that an access_definition appearing in a discriminant_part is elaborated when an object with such a discriminant is created. 3.2.2 Subtype Declarations Incompatibilities With Ada 83 0.a In Ada 9X, all range_constraints cause freezing of their type. Hence, a type-related representation item for a scalar type has to precede any range_constraints whose type is the scalar type. Wording Changes From Ada 83 0.b Subtype_marks allow only subtype names now, since types are never directly named. There is no need for RM83-3.3.2(3), which says a subtype_mark can denote both the type and the subtype; in Ada 9X, you denote an unconstrained (base) subtype if you want, but never the type. 0.c The syntactic category type_mark is now called subtype_mark, since it always denotes a subtype. 3.2.3 Classification of Operations Incompatibilities With Ada 83 0.a The attribute S'Base is no longer defined for non-scalar subtypes. Since this was only permitted as the prefix of another attribute, and there are no interesting non-scalar attributes defined for an unconstrained composite or access subtype, this should not affect any existing programs. Extensions to Ada 83 0.b The primitive subprograms (derivable subprograms) include subprograms declared in the private part of a package specification as well, and those that override implicitly declared subprograms, even if declared in a body. Wording Changes From Ada 83 0.c We have dropped the confusing term operation of a type in favor of the more useful primitive operation of a type and the phrase operates on a type. 0.d The description of S'Base has been moved to 3.5, ``Scalar Types'' because it is now defined only for scalar types. 3.3 Objects and Named Numbers Extensions to Ada 83 0.a There are additional kinds of objects (choice parameters and entry indices of entry bodies). 0.b The result of a function and of evaluating an aggregate are considered (constant) objects. This is necessary to explain the action of finalization on such things. Because a function_call is also syntactically a name (see 4.1), the result of a function_call can be renamed, thereby allowing repeated use of the result without calling the function again. Wording Changes From Ada 83 0.c This clause and its subclauses now follow the clause and subclauses on types and subtypes, to cut down on the number of forward references. 0.d The term nominal subtype is new. It is used to distinguish what is known at compile time about an object's constraint, versus what its "true" run-time constraint is. 0.e The terms definite and indefinite (which apply to subtypes) are new. They are used to aid in the description of generic formal type matching, and to specify when an explicit initial value is required in an object_declaration. 0.f We have moved the syntax for object_declaration and number_ declaration down into their respective subclauses, to keep the syntax close to the description of the associated semantics. 0.g We talk about variables and constants here, since the discussion is not specific to object_declarations, and it seems better to have the list of the kinds of constants juxtaposed with the kinds of objects. 0.h We no longer talk about indirect updating due to parameter passing. Parameter passing is handled in 6.2 and 6.4.1 in a way that there is no need to mention it here in the definition of read and update. Reading and updating now includes the case of evaluating or assigning to an enclosing object. 3.3.1 Object Declarations Extensions to Ada 83 0.a The syntax rule for object_declaration is modified to allow the aliased reserved word. 0.b A variable declared by an object_declaration can be constrained by its initial value; that is, a variable of a nominally unconstrained array subtype, or discriminated type without defaults, can be declared so long as it has an explicit initial value. In Ada 83, this was permitted for constants, and for variables created by allocators, but not for variables declared by object_declarations. This is particularly important for tagged class-wide types, since there is no way to constrain them explicitly, and so an initial value is the only way to provide a constraint. It is also important for generic formal private types with unknown discriminants. 0.c We now allow an unconstrained_array_definition in an object_ declaration. This allows an object of an anonymous array type to have its bounds determined by its initial value. This is for uniformity: If one can write ``X: constant array(Integer range 1..10) of Integer := ...;'' then it makes sense to also allow ``X: constant array(Integer range <>) of Integer := ...;''. (Note that if anonymous array types are ever sensible, a common situation is for a table implemented as an array. Tables are often constant, and for constants, there's usually no point in forcing the user to count the number of elements in the value.) Wording Changes From Ada 83 0.d We have moved the syntax for object_declarations into this subclause. 0.e Deferred constants no longer have a separate syntax rule, but rather are incorporated in object_declaration as constants declared without an initialization expression. 3.3.2 Number Declarations Extensions to Ada 83 0.a We now allow a static expression of any numeric type to initialize a named number. For integer types, it was possible in Ada 83 to use 'Pos to define a named number, but there was no way to use a static expression of some non-universal real type to define a named number. This change is upward compatible because of the preference rule for the operators of the root numeric types. Wording Changes From Ada 83 0.b We have moved the syntax rule into this subclause. 0.c AI-00263 describes the elaboration of a number declaration in words similar to that of an object_declaration. However, since there is no expression to be evaluated and no object to be created, it seems simpler to say that the elaboration has no effect. 3.4 Derived Types and Classes Inconsistencies With Ada 83 0.a When deriving from a (nonprivate, nonderived) type in the same visible part in which it is defined, if a predefined operator had been overridden prior to the derivation, the derived type will inherit the user-defined operator rather than the predefined operator. The work-around (if the new behavior is not the desired behavior) is to move the definition of the derived type prior to the overriding of any predefined operators. Incompatibilities With Ada 83 0.b When deriving from a (nonprivate, nonderived) type in the same visible part in which it is defined, a primitive subprogram of the parent type declared before the derived type will be inherited by the derived type. This can cause upward incompatibilities in cases like this: 0.c package P is type T is (A, B, C, D); function F( X : T := A ) return Integer; type NT is new T; -- inherits F as -- function F( X : NT := A ) return Integer; -- in Ada 9X only ... end P; ... use P; -- Only one declaration of F from P is use-visible in -- Ada 83; two declarations of F are use-visible in -- Ada 9X. begin ... if F > 1 then ... -- legal in Ada 83, ambiguous in Ada 9X Extensions to Ada 83 0.d The syntax for a derived_type_definition is amended to include an optional record_extension_part (see 3.9.1). 0.e A derived type may override the discriminants of the parent by giving a new discriminant_part. 0.f The parent type in a derived_type_definition may be a derived type defined in the same visible part. 0.g When deriving from a type in the same visible part in which it is defined, the primitive subprograms declared prior to the derivation are inherited as primitive subprograms of the derived type. See 3.2.3. Wording Changes From Ada 83 0.h We now talk about the classes to which a type belongs, rather than a single class. 0.i As explained in Section 13, the concept of "storage pool" replaces the Ada 83 concept of "collection." These concepts are similar, but not the same. 3.4.1 Derivation Classes 3.5 Scalar Types Incompatibilities With Ada 83 0.a S'Base is no longer defined for nonscalar types. One conceivable existing use of S'Base for nonscalar types is S'Base'Size where S is a generic formal private type. However, that is not generally useful because the actual subtype corresponding to S might be a constrained array or discriminated type, which would mean that S'Base'Size might very well overflow (for example, S'Base'Size where S is a constrained subtype of String will generally be 8 * (Integer'Last + 1)). For derived discriminated types that are packed, S'Base'Size might not even be well defined if the first subtype is constrained, thereby allowing some amount of normally required ``dope'' to have been squeezed out in the packing. Hence our conclusion is that S'Base'Size is not generally useful in a generic, and does not justify keeping the attribute Base for nonscalar types just so it can be used as a prefix. Extensions to Ada 83 0.b The attribute S'Base for a scalar subtype is now permitted anywhere a subtype_mark is permitted. S'Base'First .. S'Base'Last is the base range of the type. Using an attribute_definition_clause, one cannot specify any subtype-specific attributes for the subtype denoted by S'Base (the base subtype). 0.c The attribute S'Range is now allowed for scalar subtypes. 0.d The attributes S'Min and S'Max are now defined, and made available for all scalar types. 0.e The attributes S'Succ, S'Pred, S'Image, S'Value, and S'Width are now defined for real types as well as discrete types. 0.f Wide_String versions of S'Image and S'Value are defined. These are called S'Wide_Image and S'Wide_Value to avoid introducing ambiguities involving uses of these attributes with string literals. Wording Changes From Ada 83 0.g We now use the syntactic category range_attribute_reference since it is now syntactically distinguished from other attribute references. 0.h The definition of S'Base has been moved here from 3.3.3 since it now applies only to scalar types. 0.i More explicit rules are provided for nongraphic characters. 3.5.1 Enumeration Types Wording Changes From Ada 83 0.a The syntax rule for defining_character_literal is new. It is used for the defining occurrence of a character_literal, analogously to defining_identifier. Usage occurrences use the name or selector_ name syntactic categories. 0.b We emphasize the fact that an enumeration literal denotes a function, which is called to produce a value. 3.5.2 Character Types Inconsistencies With Ada 83 0.a The declaration of Wide_Character in package Standard hides use-visible declarations with the same defining identifier. In the unlikely event that an Ada 83 program had depended on such a use-visible declaration, and the program remains legal after the substitution of Standard.Wide_Character, the meaning of the program will be different. Incompatibilities With Ada 83 0.b The presence of Wide_Character in package Standard means that an expression such as 0.c 'a' = 'b' 0.d is ambiguous in Ada 9X, whereas in Ada 83 both literals could be resolved to be of type Character. 0.e The change in visibility rules (see 4.2) for character literals means that additional qualification might be necessary to resolve expressions involving overloaded subprograms and character literals. Extensions to Ada 83 0.f The type Character has been extended to have 256 positions, and the type Wide_Character has been added. Note that this change was already approved by the ARG for Ada 83 conforming compilers. 0.g The rules for referencing character literals are changed (see 4.2), so that the declaration of the character type need not be directly visible to use its literals, similar to null and string literals. Context is used to resolve their type. 3.5.3 Boolean Types 3.5.4 Integer Types Extensions to Ada 83 0.a An implementation is allowed to support any number of distinct base ranges for integer types, even if fewer integer types are explicitly declared in Standard. 0.b Modular (unsigned, wrap-around) types are new. Wording Changes From Ada 83 0.c Ada 83's integer types are now called "signed" integer types, to contrast them with "modular" integer types. 0.d Standard.Integer, Standard.Long_Integer, etc., denote con- strained subtypes of predefined integer types, consistent with the Ada 9X model that only subtypes have names. 0.e We now impose minimum requirements on the base range of Integer and Long_Integer. 0.f We no longer explain integer type definition in terms of an equivalence to a normal type derivation, except to say that all integer types are by definition implicitly derived from root_integer. This is for various reasons. 0.g First of all, the equivalence with a type derivation and a subtype declaration was not perfect, and was the source of various AIs (for example, is the conversion of the bounds static? Is a numeric type a derived type with respect to other rules of the language?) 0.h Secondly, we don't want to require that every integer size supported shall have a corresponding named type in Standard. Adding named types to Standard creates nonportabilities. 0.i Thirdly, we don't want the set of types that match a formal derived type "type T is new Integer;" to depend on the particular underlying integer representation chosen to implement a given user-defined integer type. Hence, we would have needed anonymous integer types as parent types for the implicit derivation anyway. We have simply chosen to identify only one anonymous integer type -- root_integer, and stated that every integer type is derived from it. 0.j Finally, the ``fiction'' that there were distinct preexisting predefined types for every supported representation breaks down for fixed point with arbitrary smalls, and was never exploited for enumeration types, array types, etc. Hence, there seems little benefit to pushing an explicit equivalence between integer type definition and normal type derivation. 3.5.5 Operations of Discrete Types Extensions to Ada 83 0.a The attributes S'Succ, S'Pred, S'Width, S'Image, and S'Value have been generalized to apply to real types as well (see 3.5, ``Scalar Types''). 3.5.6 Real Types Wording Changes From Ada 83 0.a The syntax rule for real_type_definition is modified to use the new syntactic categories floating_point_definition and fixed_point_ definition, instead of floating_point_constraint and fixed_point_ constraint, because the semantics of a type definition are significantly different than the semantics of a constraint. 0.b All discussion of model numbers, safe ranges, and machine numbers is moved to 3.5.7, 3.5.8, and G.2. Values of a fixed point type are now described as being multiples of the small of the fixed point type, and we have no need for model numbers, safe ranges, etc. for fixed point types. 3.5.7 Floating Point Types Inconsistencies With Ada 83 0.a No Range_Checks, only Overflow_Checks, are performed on variables (or parameters) of an unconstrained floating point subtype. This is upward compatible for programs that do not raise Constraint_ Error. For those that do raise Constraint_Error, it is possible that the exception will be raised at a later point, or not at all, if extended range floating point registers are used to hold the value of the variable (or parameter). Wording Changes From Ada 83 0.b The syntax rules for floating_point_constraint and floating_ accuracy_definition are removed. The syntax rules for floating_ point_definition and real_range_specification are new. 0.c A syntax rule for digits_constraint is given in 3.5.9, ``Fixed Point Types''. In J.3 we indicate that a digits_constraint may be applied to a floating point subtype_mark as well (to be compatible with Ada 83's floating_point_constraint). 0.d Discussion of model numbers is postponed to 3.5.8 and G.2. The concept of safe numbers has been replaced by the concept of the safe range of values. The bounds of the safe range are given by T'Safe_ First .. T'Safe_Last, rather than -T'Safe_Large .. T'Safe_Large, since on some machines the safe range is not perfectly symmetric. The concept of machine numbers is new, and is relevant to the definition of Succ and Pred for floating point numbers. 3.5.8 Operations of Floating Point Types 3.5.9 Fixed Point Types Inconsistencies With Ada 83 0.a In Ada 9X, S'Small always equals S'Base'Small, so if an implementation chooses a small for a fixed point type smaller than required by the delta, the value of S'Small in Ada 9X might not be the same as it was in Ada 83. Extensions to Ada 83 0.b Decimal fixed point types are new, though their capabilities are essentially similar to that available in Ada 83 with a fixed point type whose small equals its delta equals a power of 10. However, in the Information Systems Annex, additional requirements are placed on the support of decimal fixed point types (e.g. a minimum of 18 digits of precision). Wording Changes From Ada 83 0.c The syntax rules for fixed_point_constraint and fixed_accuracy_ definition are removed. The syntax rule for fixed_point_definition is new. A syntax rule for delta_constraint is included in the Obsolescent features (to be compatible with Ada 83's fixed_point_ constraint). 3.5.10 Operations of Fixed Point Types 3.6 Array Types Extensions to Ada 83 0.a The syntax rule for component_definition is modified to allow the reserved word aliased. 0.b The syntax rules for unconstrained_array_definition and constrained_array_definition are modified to use component_definition (instead of component_subtype_indication). The effect of this change is to allow the reserved word aliased before the component subtype_ indication. 0.c A range in a discrete_subtype_definition may use arbitrary universal expressions for each bound (e.g. -1 .. 3+5), rather than strictly "implicitly convertible" operands. The subtype defined will still be a subtype of Integer. Wording Changes From Ada 83 0.d We introduce a new syntactic category, discrete_subtype_ definition, as distinct from discrete_range. These two constructs have the same syntax, but their semantics are quite different (one defines a subtype, with a preference for Integer subtypes, while the other just selects a subrange of an existing subtype). We use this new syntactic category in for loops and entry families. 0.e The syntax for index_constraint and discrete_range have been moved to their own subclause, since they are no longer used here. 0.f The syntax rule for component_definition (formerly component_ subtype_definition) is moved here from RM83-3.7. 3.6.1 Index Constraints and Discrete Ranges Extensions to Ada 83 0.a We allow the declaration of a variable with a nominally unconstrained array subtype, so long as it has an initialization expression to determine its bounds. Wording Changes From Ada 83 0.b We have moved the syntax for index_constraint and discrete_ range here since they are no longer used in constrained_array_ definitions. We therefore also no longer have to describe the (special) semantics of index_constraints and discrete_ranges that appear in constrained_array_definitions. 0.c The rules given in RM83-3.6.1(5,7-10), which define the bounds of an array object, are redundant with rules given elsewhere, and so are not repeated here. RM83-3.6.1(6), which requires that the (nominal) subtype of an array variable be constrained, no longer applies, so long as the variable is explicitly initialized. 3.6.2 Operations of Array Types 3.6.3 String Types Inconsistencies With Ada 83 0.a The declaration of Wide_String in Standard hides a use-visible declaration with the same defining_identifier. In rare cases, this might result in an inconsistency between Ada 83 and Ada 9X. Incompatibilities With Ada 83 0.b Because both String and Wide_String are always directly visible, an expression like 0.c "a" < "bc" 0.d is now ambiguous, whereas in Ada 83 both string literals could be resolved to type String. Extensions to Ada 83 0.e The type Wide_String is new (though it was approved by ARG for Ada 83 compilers as well). Wording Changes From Ada 83 0.f We define the term string type as a natural analogy to the term character type. 3.7 Discriminants Extensions to Ada 83 0.a The syntax for a discriminant_specification is modified to allow an access discriminant, with a type specified by an access_ definition (see 3.10). 0.b Discriminants are allowed on all composite types other than array types. 0.c Discriminants may be of an access type. Wording Changes From Ada 83 0.d Discriminant_parts are not elaborated, though an access_ definition is elaborated when the discriminant is initialized. 3.7.1 Discriminant Constraints Inconsistencies With Ada 83 0.a Dependent compatibility checks are no longer performed on subtype declaration. Instead they are deferred until object creation (see 3.3.1). This is upward compatible for a program that does not raise Constraint_Error. Wording Changes From Ada 83 0.b Everything in RM83-3.7.2(7-12), which specifies the initial values for discriminants, is now redundant with 3.3.1, 6.4.1, 8.5.1, and 12.4. Therefore, we don't repeat it here. Since the material is largely intuitive, but nevertheless complicated to state formally, it doesn't seem worth putting it in a "NOTE." 3.7.2 Operations of Discriminated Types Extensions to Ada 83 0.a For consistency with other attributes, we are allowing the prefix of Constrained to be a value as well as an object of a discriminated type, and also an implicit dereference. These extensions are not important capabilities, but there seems no reason to make this attribute different from other similar attributes. We are curious what most Ada 83 compilers do with F(1).X'Constrained. 0.b We now handle in a general way the cases of erroneousness identified by AI-585, where the prefix of an indexed_component or slice is discriminant-dependent, and the evaluation of the index or discrete range changes the value of a discriminant. Wording Changes From Ada 83 0.c We have moved all discussion of erroneous use of names that denote discriminant-dependent subcomponents to this subclause. In Ada 83, it used to appear separately under assignment_statements and subprogram calls. 3.8 Record Types Extensions to Ada 83 0.a The syntax rule for component_declaration is modified to use component_definition (instead of component_subtype_definition). The effect of this change is to allow the reserved word aliased before the component_subtype_definition. 0.b A short-hand is provided for defining a null record type (and a null record extension), as these will be more common for abstract root types (and derived types without additional components). 0.c The syntax rule for record_type_definition is modified to allow the reserved words tagged and limited. Tagging is new. Limitedness is now orthogonal to privateness. In Ada 83 the syntax implied that limited private was sort of more private than private. However, limitedness really has nothing to do with privateness; limitedness simply indicates the lack of assignment capabilities, and makes perfect sense for nonprivate types such as record types. Wording Changes From Ada 83 0.d The syntax rules now allow representation_clauses to appear in a record_definition. This is not a language extension, because Legality Rules prevent all language-defined representation clauses from appearing there. However, an implementation-defined attribute_ definition_clause could appear there. The reason for this change is to allow the rules for representation_clauses and representation pragmas to be as similar as possible. 3.8.1 Variant Parts and Discrete Choices Extensions to Ada 83 0.a In Ada 83, the discriminant of a variant_part is not allowed to be of a generic formal type. This restriction is removed in Ada 9X; an others discrete_choice is required in this case. Wording Changes From Ada 83 0.b The syntactic category choice is removed. The syntax rules for variant, array_aggregate, and case_statement now use discrete_choice_ list or discrete_choice instead. The syntax rule for record_ aggregate now defines its own syntax for named associations. 0.c We have added the term Discrete Choice to the title since this is where they are talked about. This is analogous to the name of the subclause "Index Constraints and Discrete Ranges" in the clause on Array Types. 0.d The rule requiring that the discriminant denote a discriminant of the type being defined seems to have been left implicit in RM83. 3.9 Tagged Types and Type Extensions Extensions to Ada 83 0.a Tagged types are a new concept. 3.9.1 Type Extensions Extensions to Ada 83 0.a Type extension is a new concept. 3.9.2 Dispatching Operations of Tagged Types Extensions to Ada 83 0.a The concept of dispatching operations is new. 3.9.3 Abstract Types and Subprograms 3.10 Access Types Extensions to Ada 83 0.a The syntax for access_type_definition is changed to support general access types (including access-to-constants) and access-to- subprograms. The syntax rules for general_access_modifier and access_definition are new. Wording Changes From Ada 83 0.b We use the term "storage pool" to talk about the data area from which allocation takes place. The term "collection" is no longer used. ("Collection" and "storage pool" are not the same thing because multiple unrelated access types can share the same storage pool; see 13.11 for more discussion.) 3.10.1 Incomplete Type Declarations Extensions to Ada 83 0.a The full_type_declaration that completes an incomplete_type_ declaration may have a known_discriminant_part even if the incomplete_type_declaration does not. 0.b A discriminant_constraint may be applied to an incomplete type, even if it its completion is deferred to the package body, because there is no ``dependent compatibility check'' required any more. Of course, the constraint can be specified only if a known_discriminant_ part was given in the incomplete_type_declaration. As mentioned in the previous paragraph, that is no longer required even when the full type has discriminants. Wording Changes From Ada 83 0.c Dereferences producing incomplete types were not explicitly disallowed in RM83, though AI-00039 indicated that it was not strictly necessary since troublesome cases would result in Constraint_Error at run time, since the access value would necessarily be null. However, this introduces an undesirable implementation burden, as illustrated by Example 4 of AI-00039: 0.d package Pack is type Pri is private; private type Sep; type Pri is access Sep; X : Pri; end Pack; 0.e package body Pack is -- Could be separately compiled! type Sep is ...; X := new Sep; end Pack; 0.f pragma Elaborate(Pack); private package Pack.Child is I : Integer := X.all'Size; -- Legal, by AI-00039. end Pack.Child; 0.g Generating code for the above example could be a serious implementation burden, since it would require all aliased objects to store size dope, and for that dope to be in the same format for all kinds of types (or some other equivalently inefficient implemen- tation). On the contrary, most implementations allocate dope differently (or not at all) for different designated subtypes. 3.10.2 Operations of Access Types Extensions to Ada 83 0.a We no longer make things like 'Last and ".component" (basic) operations of an access type that need to be "declared" somewhere. Instead, implicit dereference in a prefix takes care of them all. This means that there should never be a case when X.all'Last is legal while X'Last is not. See AI-00154. 3.11 Declarative Parts Extensions to Ada 83 0.a The syntax for declarative_part is modified to remove the ordering restrictions of Ada 83; that is, the distinction between basic_declarative_items and later_declarative_items within declarative_parts is removed. This means that things like use_ clauses and variable_declarations can be freely intermixed with things like bodies. 0.b The syntax rule for proper_body now allows a protected_body, and the rules for elaboration checks now cover calls on protected operations. Wording Changes From Ada 83 0.c The syntax rule for later_declarative_item is removed; the syntax rule for declarative_item is new. 0.d RM83 defines ``elaborated'' and ``not yet elaborated'' for declarative_items here, and for other things in 3.1, ``Declara- tions''. That's no longer necessary, since these terms are fully defined in 3.1. 0.e In RM83, all uses of declarative_part are optional (except for the one in block_statement with a declare) which is sort of strange, since a declarative_part can be empty, according to the syntax. That is, declarative_parts are sort of ``doubly optional''. In Ada 9X, these declarative_parts are always required (but can still be empty). To simplify description, we go further and say (see 5.6, ``Block Statements'') that a block_statement without an explicit declarative_ part is equivalent to one with an empty one. 3.11.1 Completions of Declarations Wording Changes From Ada 83 0.a This subclause is new. It is intended to cover all kinds of completions of declarations, be they a body for a spec, a full type for an incomplete or private type, a full constant declaration for a deferred constant declaration, or a pragma Import for any kind of entity. Section 4: Names and Expressions 4.1 Names Extensions to Ada 83 0.a Type conversions and function calls are now considered names that denote the result of the operation. In the case of a type conversion used as an actual parameter or that is of a tagged type, the type conversion is considered a variable if the operand is a variable. This simplifies the description of "parameters of the form of a type conversion" as well as better supporting an important OOP paradigm that requires the combination of a conversion from a class-wide type to some specific type followed immediately by component selection. Function calls are considered names so that a type conversion of a function call and the function call itself are treated equivalently in the grammar. A function call is considered the name of a constant, and can be used anywhere such a name is permitted. See 6.5. 0.b Type conversions of a tagged type are permitted anywhere their operand is permitted. That is, if the operand is a variable, then the type conversion can appear on the left-hand side of an assignment_statement. If the operand is an object, then the type conversion can appear in an object renaming or as a prefix. See 4.6. Wording Changes From Ada 83 0.c Everything of the general syntactic form name(...) is now syntactically a name. In any realistic parser, this would be a necessity since distinguishing among the various name(...) constructs inevitably requires name resolution. In cases where the construct yields a value rather than an object, the name denotes the value rather than an object. Names already denote values in Ada 83 with named numbers, components of the result of a function call, etc. This is partly just a wording change, and partly an extension of functionality (see Extensions heading above). 0.d The syntax rule for direct_name is new. It is used in places where direct visibility is required. It's kind of like Ada 83's simple_name, but simple_name applied to both direct visibility and visibility by selection, and furthermore, it didn't work right for operator_symbols. The syntax rule for simple_name is removed, since its use is covered by a combination of direct_name and selector_name. The syntactic categories direct_name and selector_name are similar; it's mainly the visibility rules that distinguish the two. The introduction of direct_name requires the insertion of one new explicit textual rule: to forbid statement_identifiers from being operator_symbols. This is the only case where the explicit rule is needed, because this is the only case where the declaration of the entity is implicit. For example, there is no need to syntactically forbid (say) ``X: "Rem";'', because it is impossible to declare a type whose name is an operator_symbol in the first place. 0.e The syntax rules for explicit_dereference and implicit_ dereference are new; this makes other rules simpler, since dereferencing an access value has substantially different semantics from selected_components. We also use name instead of prefix in the explicit_dereference rule since that seems clearer. Note that these rules rely on the fact that function calls are now names, so we don't need to use prefix to allow functions calls in front of .all. 0.f We no longer use the term appropriate for a type since we now describe the semantics of a prefix in terms of implicit dereference. 4.1.1 Indexed Components 4.1.2 Slices 4.1.3 Selected Components Extensions to Ada 83 0.a We now allow an expanded name to use a prefix that denotes a rename of a package, even if the selector is for an entity local to the body or private part of the package, so long as the entity is visible at the place of the reference. This eliminates a preexisting anomaly where references in a package body may refer to declarations of its visible part but not those of its private part or body when the prefix is a rename of the package. Wording Changes From Ada 83 0.b The syntax rule for selector_name is new. It is used in places where visibility, but not necessarily direct visibility, is required. See 4.1, ``Names'' for more information. 0.c The description of dereferencing an access type has been moved to 4.1, ``Names''; name.all is no longer considered a selected_ component. 0.d The rules have been restated to be consistent with our new terminology, to accommodate class-wide types, etc. 4.1.4 Attributes Extensions to Ada 83 0.a We now uniformly treat X'Range as X'First..X'Last, allowing its use with scalar subtypes. 0.b We allow any integer type in the static_expression of an attribute designator, not just a value of universal_integer. The preference rules ensure upward compatibility. Wording Changes From Ada 83 0.c We use the syntactic category attribute_reference rather than simply "attribute" to avoid confusing the name of something with the thing itself. 0.d The syntax rule for attribute_reference now uses identifier instead of simple_name, because attribute identifiers are not required to follow the normal visibility rules. 0.e We now separate attribute_reference from range_attribute_ reference, and enumerate the reserved words that are legal attribute or range attribute designators. We do this because identifier no longer includes reserved words. 0.f The Ada 9X name resolution rules are a bit more explicit than in Ada 83. The Ada 83 rule said that the "meaning of the prefix of an attribute must be determinable independently of the attribute designator and independently of the fact that it is the prefix of an attribute." That isn't quite right since the meaning even in Ada 83 embodies whether or not the prefix is interpreted as a parameterless function call, and in Ada 9X, it also embodies whether or not the prefix is interpreted as an implicit_dereference. So the attribute designator does make a difference -- just not much. 0.g Note however that if the attribute designator is Access, it makes a big difference in the interpretation of the prefix (see 3.10.2). 4.2 Literals Incompatibilities With Ada 83 0.a Because character_literals are now treated like other literals, in that they are resolved using context rather than depending on direct visibility, additional qualification might be necessary when passing a character_literal to an overloaded subprogram. Extensions to Ada 83 0.b Character_literals are now treated analogously to null and string_literals, in that they are resolved using context, rather than their content; the declaration of the corresponding defining_ character_literal need not be directly visible. Wording Changes From Ada 83 0.c Name Resolution rules for enumeration literals that are not character_literals are not included anymore, since they are neither syntactically nor semantically "literals" but are rather names of parameterless functions. 4.3 Aggregates Extensions to Ada 83 0.a We now allow extension_aggregates. Wording Changes From Ada 83 0.b We have adopted new wording for expressing the rule that the type of an aggregate shall be determinable from the outside, though using the fact that it is nonlimited record (extension) or array. 0.c An aggregate now creates an anonymous object. This is necessary so that controlled types will work (see 7.6). 4.3.1 Record Aggregates Extensions to Ada 83 0.a Null record aggregates may now be specified, via "(null record)". However, this syntax is more useful for null record extensions in extension aggregates. Wording Changes From Ada 83 0.b Various AIs have been incorporated (AI-189, AI-244, and AI-309). In particular, Ada 83 did not explicitly disallow extra values in a record aggregate. Now we do. 4.3.2 Extension Aggregates Extensions to Ada 83 0.a The extension aggregate syntax is new. 4.3.3 Array Aggregates Extensions to Ada 83 0.a We now allow "named with others" aggregates in all contexts where there is an applicable index constraint, effectively eliminating what was RM83-4.3.2(6). Sliding never occurs on an aggregate with others, because its bounds come from the applicable index constraint, and therefore already match the bounds of the target. 0.b The legality of an others choice is no longer affected by the staticness of the applicable index constraint. This substantially simplifies several rules, while being slightly more flexible for the user. It obviates the rulings of AI-244 and AI-310, while taking advantage of the dynamic nature of the "extra values" check required by AI-309. 0.c Named array aggregates are permitted even if the index type is descended from a formal scalar type. See 4.9 and AI-00190. Wording Changes From Ada 83 0.d We now separate named and positional array aggregate syntax, since, unlike other aggregates, named and positional associations cannot be mixed in array aggregates (except that an others choice is allowed in a positional array aggregate). 0.e We have also reorganized the presentation to handle multidimensional and one-dimensional aggregates more uniformly, and to incorporate the rulings of AI-19, AI-309, etc. 4.4 Expressions Extensions to Ada 83 0.a In Ada 83, out parameters and their nondiscriminant subcomponents are not allowed as primaries. These restrictions are eliminated in Ada 9X. 0.b In various contexts throughout the language where Ada 83 syntax rules had simple_expression, the corresponding Ada 9X syntax rule has expression instead. This reflects the inclusion of modular integer types, which makes the logical operators "and", "or", and "xor" more useful in expressions of an integer type. Requiring parentheses to use these operators in such contexts seemed unnecessary and potentially confusing. Note that the bounds of a range still have to be specified by simple_expressions, since otherwise expressions involving membership tests might be ambiguous. Essentially, the operation ".." is of higher precedence than the logical operators, and hence uses of logical operators still have to be parenthesized when used in a bound of a range. 4.5 Operators and Expression Evaluation Wording Changes From Ada 83 0.a We don't give a detailed definition of precedence, since it is all implicit in the syntax rules anyway. 0.b The permission to reassociate is moved here from RM83-11.6(5), so it is closer to the rules defining operator association. 4.5.1 Logical Operators and Short-circuit Control Forms 4.5.2 Relational Operators and Membership Tests Extensions to Ada 83 0.a Membership tests can be used to test the tag of a class-wide value. 0.b Predefined equality for a composite type is defined in terms of the primitive equals operator for tagged components or the parent part. Wording Changes From Ada 83 0.c The term ``membership test'' refers to the relation "X in S" rather to simply the reserved word in or not in. 0.d We use the term ``equality operator'' to refer to both the = (equals) and /= (not equals) operators. Ada 83 referred to = as the equality operator, and /= as the inequality operator. The new wording is more consistent with the ISO 10646 name for "=" (equals sign) and provides a category similar to ``ordering operator'' to refer to both = and /=. 0.e We have changed the term ``catenate'' to ``concatenate''. 4.5.3 Binary Adding Operators Inconsistencies With Ada 83 0.a The lower bound of the result of concatenation, for a type whose first subtype is constrained, is now that of the index subtype. This is inconsistent with Ada 83, but generally only for Ada 83 programs that raise Constraint_Error. For example, the concatenation operator in 0.b X : array(1..10) of Integer; begin X := X(6..10) & X(1..5); 0.c would raise Constraint_Error in Ada 83 (because the bounds of the result of the concatenation would be 6..15, which is outside of 1..10), but would succeed and swap the halves of X (as expected) in Ada 9X. Extensions to Ada 83 0.d Concatenation is now useful for array types whose first subtype is constrained. When the result type of a concatenation is such an array type, Constraint_Error is avoided by effectively first sliding the left operand (if nonnull) so that its lower bound is that of the index subtype. 4.5.4 Unary Adding Operators 4.5.5 Multiplying Operators Extensions to Ada 83 0.a Explicit conversion of the result of multiplying or dividing two fixed point numbers is no longer required, provided the context uniquely determines some specific fixed point result type. This is to improve support for decimal fixed point, where requiring explicit conversion on every fixed-fixed multiply or divide was felt to be inappropriate. 0.b The type universal_fixed is covered by universal_real, so real literals and fixed point operands may be multiplied or divided directly, without any explicit conversions required. Wording Changes From Ada 83 0.c We have used the normal syntax for function definition rather than a tabular format. 4.5.6 Highest Precedence Operators Wording Changes From Ada 83 0.a We now show the specification for "**" for integer types with a parameter subtype of Natural rather than Integer for the exponent. This reflects the fact that Constraint_Error is raised if a negative value is provided for the exponent. 4.6 Type Conversions Incompatibilities With Ada 83 0.a A character_literal is not allowed as the operand of a type_ conversion, since there are now two character types in package Standard. 0.b The component subtypes have to statically match in an array conversion, rather than being checked for matching constraints at run time. 0.c Because sliding of array bounds is now provided for operations where it was not in Ada 83, programs that used to raise Constraint_ Error might now continue executing and produce a reasonable result. This is likely to fix more bugs than it creates. Extensions to Ada 83 0.d A type_conversion is considered the name of an object in certain circumstances (such a type_conversion is called a view conversion). In particular, as in Ada 83, a type_conversion can appear as an in out or out actual parameter. In addition, if the target type is tagged and the operand is the name of an object, then so is the type_conversion, and it can be used as the prefix to a selected_component, in an object_renaming_declaration, etc. 0.e We no longer require type-mark conformance between a parameter of the form of a type conversion, and the corresponding formal parameter. This had caused some problems for inherited subprograms (since there isn't really a type-mark for converted formals), as well as for renamings, formal subprograms, etc. See AI-245, AI-318, AI-547. 0.f We now specify ``deterministic'' rounding from real to integer types when the value of the operand is exactly between two integers (rounding is away from zero in this case). 0.g ``Sliding'' of array bounds (which is part of conversion to an array subtype) is performed in more cases in Ada 9X than in Ada 83. Sliding is not performed on the operand of a membership test, nor on the operand of a qualified_expression. It wouldn't make sense on a membership test, and we wish to retain a connection between subtype membership and subtype qualification. In general, a subtype membership test returns True if and only if a corresponding subtype qualification succeeds without raising an exception. Other operations that take arrays perform sliding. Wording Changes From Ada 83 0.h We no longer explicitly list the kinds of things that are not allowed as the operand of a type_conversion, except in a NOTE. 0.i The rules in this clause subsume the rules for "parameters of the form of a type conversion," and have been generalized to cover the use of a type conversion as a name. 4.7 Qualified Expressions 4.8 Allocators Incompatibilities With Ada 83 0.a The subtype_indication of an uninitialized allocator may not have an explicit constraint if the designated type is an access type. In Ada 83, this was permitted even though the constraint had no affect on the subtype of the created object. Extensions to Ada 83 0.b Allocators creating objects of type T are now overloaded on access types designating T'Class and all class-wide types that cover T. 0.c Implicit array subtype conversion (sliding) is now performed as part of an initialized allocator. Wording Changes From Ada 83 0.d We have used a new organization, inspired by the ACID document, that makes it clearer what is the subtype of the created object, and what subtype conversions take place. 0.e Discussion of storage management issues, such as garbage collection and the raising of Storage_Error, has been moved to 13.11, ``Storage Management''. 4.9 Static Expressions and Static Subtypes Extensions to Ada 83 0.a The rules for static expressions and static subtypes are generalized to allow more kinds of compile-time-known expressions to be used where compile-time-known values are required, as follows: 0.b Membership tests and short-circuit control forms may appear in a static expression. 0.c The bounds and length of statically constrained array objects or subtypes are static. 0.d The Range attribute of a statically constrained array subtype or object gives a static range. 0.e A type_conversion is static if the subtype_mark denotes a static scalar subtype and the operand is a static expression. 0.f All numeric literals are now static, even if the expected type is a formal scalar type. This is useful in case_ statements and variant_parts, which both now allow a value of a formal scalar type to control the selection, to ease conversion of a package into a generic package. Similarly, named array aggregates are also permitted for array types with an index type that is a formal scalar type. 0.g The rules for the evaluation of static expressions are revised to require exact evaluation at compile time, and force a machine number result when crossing from the static realm to the dynamic realm, to enhance portability and predictability. Exact evaluation is not required for descendants of a formal scalar type, to simplify generic code sharing and to avoid generic contract model problems. 0.h Static expressions are legal even if an intermediate in the expression goes outside the base range of the type. Therefore, the following will succeed in Ada 9X, whereas it might raise an exception in Ada 83: 0.i type Short_Int is range -32_768 .. 32_767; I : Short_Int := -32_768; 0.j This might raise an exception in Ada 83 because "32_768" is out of range, even though "-32_768" is not. In Ada 9X, this will always succeed. 0.k Certain expressions involving string operations (in particular concatenation and membership tests) are considered static in Ada 9X. 0.l The reason for this change is to simplify the rule requiring compile-time-known string expressions as the link name in an interfacing pragma, and to simplify the preelaborability rules. Incompatibilities With Ada 83 0.m An Ada 83 program that uses an out-of-range static value is illegal in Ada 9X, unless the expression is part of a larger static expression, or the expression is not evaluated due to being on the right-hand side of a short-circuit control form. Wording Changes From Ada 83 0.n This clause (and 4.5.5, ``Multiplying Operators'') subsumes the RM83 section on Universal Expressions. 0.o The existence of static string expressions necessitated changing the definition of static subtype to include string subtypes. Most occurrences of "static subtype" have been changed to "static scalar subtype", in order to preserve the effect of the Ada 83 rules. This has the added benefit of clarifying the difference between "static subtype" and "statically constrained subtype", which has been a source of confusion. In cases where we allow static string subtypes, we explicitly use phrases like "static string subtype" or "static (scalar or string) subtype", in order to clarify the meaning for those who have gotten used to the Ada 83 terminology. 0.p In Ada 83, an expression was considered nonstatic if it raised an exception. Thus, for example: 0.q Bad: constant := 1/0; -- Illegal! 0.r was illegal because 1/0 was not static. In Ada 9X, the above example is still illegal, but for a different reason: 1/0 is static, but there's a separate rule forbidding the exception raising. 4.9.1 Statically Matching Constraints and Subtypes Wording Changes From Ada 83 0.a This subclause is new to Ada 9X. Section 5: Statements Wording Changes From Ada 83 0.a The description of return_statements has been moved to 6.5, ``Return Statements'', so that it is closer to the description of subprograms. 5.1 Simple and Compound Statements - Sequences of Statements Extensions to Ada 83 0.a The requeue_statement is new. Wording Changes From Ada 83 0.b We define the syntactic category statement_identifier to simplify the description. It is used for labels, loop names, and block names. We define the entity associated with the implicit declarations of statement names. 0.c Completion includes completion caused by a transfer of control, although RM83-5.1(6) did not take this view. 5.2 Assignment Statements Extensions to Ada 83 0.a We now allow user-defined finalization and value adjustment actions as part of assignment_statements (see 7.6, ``User-Defined Assignment and Finalization''). Wording Changes From Ada 83 0.b The special case of array assignment is subsumed by the concept of a subtype conversion, which is applied for all kinds of types, not just arrays. For arrays it provides ``sliding.'' For numeric types it provides conversion of a value of a universal type to the specific type of the target. For other types, it generally has no run-time effect, other than a constraint check. 0.c We now cover in a general way in 3.7.2 the erroneous execution possible due to changing the value of a discriminant when the variable in an assignment_statement is a subcomponent that depends on discriminants. 5.3 If Statements 5.4 Case Statements Extensions to Ada 83 0.a In Ada 83, the expression in a case_statement is not allowed to be of a generic formal type. This restriction is removed in Ada 9X; an others discrete_choice is required instead. 0.b In Ada 9X, a function call is the name of an object; this was not true in Ada 83 (see 4.1, ``Names''). This change makes the following case_statement legal: 0.c subtype S is Integer range 1..2; function F return S; case F is when 1 => ...; when 2 => ...; -- No others needed. end case; 0.d Note that the result subtype given in a function renaming_ declaration is ignored; for a case_statement whose expression calls a such a function, the full coverage rules are checked using the result subtype of the original function. Note that predefined operators such as "+" have an unconstrained result subtype (see 4.5.1). Note that generic formal functions do not have static result subtypes. Note that the result subtype of an inherited subprogram need not correspond to any namable subtype; there is still a perfectly good result subtype, though. Wording Changes From Ada 83 0.e Ada 83 forgot to say what happens for ``legally'' out-of-bounds values. 0.f We take advantage of rules and terms (e.g. cover a value) defined for discrete_choices and discrete_choice_lists in 3.8.1, ``Variant Parts and Discrete Choices''. 0.g In the Name Resolution Rule for the case expression, we no longer need RM83-5.4(3)'s ``which must be determinable independently of the context in which the expression occurs, but using the fact that the expression must be of a discrete type,'' because the expression is now a complete context. See 8.6, ``The Context of Overload Resolution''. 0.h Since type_conversions are now defined as names, their coverage rule is now covered under the general rule for names, rather than being separated out along with qualified_expressions. 5.5 Loop Statements Wording Changes From Ada 83 0.a The constant-ness of loop parameters is specified in 3.3, ``Objects and Named Numbers''. 5.6 Block Statements Wording Changes From Ada 83 0.a The syntax rule for block_statement now uses the syntactic category handled_sequence_of_statements. 5.7 Exit Statements 5.8 Goto Statements Section 6: Subprograms 6.1 Subprogram Declarations Extensions to Ada 83 0.a The syntax for abstract_subprogram_declaration is added. The syntax for parameter_specification is revised to allow for access parameters (see 3.10) 0.b Program units that are library units may have a parent_unit_ name to indicate the parent of a child (see Section 10). Wording Changes From Ada 83 0.c We have incorporated the rules from RM83-6.5, ``Function Subprograms'' here and in 6.3, ``Subprogram Bodies'' 0.d We have incorporated the definitions of RM83-6.6, ``Parameter and Result Type Profile - Overloading of Subprograms'' here. 0.e The syntax rule for defining_operator_symbol is new. It is used for the defining occurrence of an operator_symbol, analogously to defining_identifier. Usage occurrences use the direct_name or selector_name syntactic categories. The syntax rules for defining_ designator and defining_program_unit_name are new. 6.2 Formal Parameter Modes Extensions to Ada 83 0.a The value of an out parameter may be read. An out parameter is treated like a declared variable without an explicit initial expression. Wording Changes From Ada 83 0.b Discussion of copy-in for parts of out parameters is now covered in 6.4.1, ``Parameter Associations''. 0.c The concept of a by-reference type is new to Ada 9X. 0.d We now cover in a general way in 3.7.2 the rule regarding erroneous execution when a discriminant is changed and one of the parameters depends on the discriminant. 6.3 Subprogram Bodies Extensions to Ada 83 0.a A renaming_declaration may be used instead of a subprogram_ body. Wording Changes From Ada 83 0.b The syntax rule for subprogram_body now uses the syntactic category handled_sequence_of_statements. 0.c The declarative_part of a subprogram_body is now required; that doesn't make any real difference, because a declarative_part can be empty. 0.d We have incorporated some rules from RM83-6.5 here. 0.e RM83 forgot to restrict the definition of elaboration of a subprogram_body to non-generics. 6.3.1 Conformance Rules Extensions to Ada 83 0.a The rules for full conformance are relaxed -- they are now based on the structure of constructs, rather than the sequence of lexical elements. This implies, for example, that "(X, Y: T)" conforms fully with "(X: T; Y: T)", and "(X: T)" conforms fully with "(X: in T)". 6.3.2 Inline Expansion of Subprograms Extensions to Ada 83 0.a A pragma Inline is allowed inside a subprogram_body if there is no corresponding subprogram_declaration. This is for uniformity with other program unit pragmas. 6.4 Subprogram Calls Wording Changes From Ada 83 0.a We have gotten rid of parameters ``of the form of a type conversion'' (see RM83-6.4.1(3)). The new view semantics of type_ conversions allows us to use normal type_conversions instead. 0.b We have moved wording about run-time semantics of parameter associations to 6.4.1. 0.c We have moved wording about raising Program_Error for a function that falls off the end to here from RM83-6.5. 6.4.1 Parameter Associations Extensions to Ada 83 0.a In Ada 9X, a program can rely on the fact that passing an object as an out parameter does not ``de-initialize'' any parts of the object whose subtypes have implicit initial values. (This generalizes the RM83 rule that required copy-in for parts that were discriminants or of an access type.) Wording Changes From Ada 83 0.b We have eliminated the subclause on Default Parameters, as it is subsumed by earlier clauses and subclauses. 6.5 Return Statements Incompatibilities With Ada 83 0.a In Ada 9X, if the result type of a function has a part that is a task, then an attempt to return a local variable will raise Program_Error. In Ada 83, if a function returns a local variable containing a task, execution is erroneous according to AI-00867. However, there are other situations where functions that return tasks (or that return a variant record only one of whose variants includes a task) are correct in Ada 83 but will raise Program_Error according to the new rules. 0.b The rule change was made because there will be more types (protected types, limited controlled types) in Ada 9X for which it will be meaningless to return a local variable, and making all of these erroneous is unacceptable. The current rule was felt to be the simplest that kept upward incompatibilities to situations involving returning tasks, which are quite rare. Wording Changes From Ada 83 0.c This clause has been moved here from chapter 5, since it has mainly to do with subprograms. 0.d A function now creates an anonymous object. This is necessary so that controlled types will work. 0.e We have clarified that a return_statement applies to a callable construct, not to a callable entity. 0.f There is no need to mention generics in the rules about where a return_statement can appear and what it applies to; the phrase ``body of a subprogram or generic subprogram'' is syntactic, and refers exactly to ``subprogram_body''. 6.6 Overloading of Operators Extensions to Ada 83 0.a Explicit declarations of "=" are now permitted for any combination of parameter and result types. 0.b Explicit declarations of "/=" are now permitted, so long as the result type is not Boolean. Section 7: Packages 7.1 Package Specifications and Declarations Incompatibilities With Ada 83 0.a In Ada 83, a library package is allowed to have a body even if it doesn't need one. In Ada 9X, a library package body is either required or forbidden -- never optional. The workaround is to add pragma Elaborate_Body, or something else requiring a body, to each library package that has a body that isn't otherwise required. Wording Changes From Ada 83 0.b We have moved the syntax into this clause and the next clause from RM83-7.1, ``Package Structure'', which we have removed. 0.c RM83 was unclear on the rules about when a package requires a body. For example, RM83-7.1(4) and RM83-7.1(8) clearly forgot about the case of an incomplete type declared in a package_declaration but completed in the body. In addition, RM83 forgot to make this rule apply to a generic package. We have corrected these rules. Finally, since we now allow a pragma Import for any explicit declaration, the completion rules need to take this into account as well. 7.2 Package Bodies Wording Changes From Ada 83 0.a The syntax rule for package_body now uses the syntactic category handled_sequence_of_statements. 0.b The declarative_part of a package_body is now required; that doesn't make any real difference, since a declarative_part can be empty. 0.c RM83 seems to have forgotten to say that a package_body can't stand alone, without a previous declaration. We state that rule here. 0.d RM83 forgot to restrict the definition of elaboration of package_bodies to nongeneric ones. We have corrected that omission. 0.e The rule about implicit bodies (from RM83-9.3(5)) is moved here, since it is more generally applicable. 7.3 Private Types and Private Extensions Extensions to Ada 83 0.a The syntax for a private_type_declaration is augmented to allow the reserved word tagged. 0.b In Ada 83, a private type without discriminants cannot be completed with a type with discriminants. Ada 9X allows the full view to have discriminants, so long as they have defaults (that is, so long as the first subtype is definite). This change is made for uniformity with generics, and because the rule as stated is simpler and easier to remember than the Ada 83 rule. In the original version of Ada 83, the same restriction applied to generic formal private types. However, the restriction was removed by the ARG for generics. In order to maintain the ``generic contract/private type contract analogy'' discussed above, we have to apply the same rule to package-private types. Note that a private untagged type without discriminants can be completed with a tagged type with discriminants only if the full view is constrained, because discriminants of tagged types cannot have defaults. Wording Changes From Ada 83 0.c RM83-7.4.1(4), ``Within the specification of the package that declares a private type and before the end of the corresponding full type declaration, a restriction applies....'', is subsumed (and corrected) by the rule that a type shall be completely defined before it is frozen, and the rule that the parent type of a derived type declaration shall be completely defined, unless the derived type is a private extension. 7.3.1 Private Operations Wording Changes From Ada 83 0.a The phrase in RM83-7.4.2(7), ``...after the full type declaration'', doesn't work in the presence of child units, so we define that rule in terms of visibility. 0.b The definition of the Constrained attribute for private types has been moved to ``Obsolescent Features.'' (The Constrained attribute of an object has not been moved there.) 7.4 Deferred Constants Extensions to Ada 83 0.a In Ada 83, a deferred constant is required to be of a private type declared in the same visible part. This restriction is removed for Ada 9X; deferred constants can be of any type. 0.b In Ada 83, a deferred constant declaration was not permitted to include a constraint, nor the reserved word aliased. 0.c In Ada 83, the rules required conformance of type marks; here we require static matching of subtypes if the deferred constant is constrained. 0.d A deferred constant declaration can be completed with a pragma Import. Such a deferred constant declaration need not be within a package_specification. 0.e The rules for too-early uses of deferred constants are modified in Ada 9X to allow more cases, and catch all errors at compile time. This change is necessary in order to allow deferred constants of a tagged type without violating the principle that for a dispatching call, there is always an implementation to dispatch to. It has the beneficial side-effect of catching some Ada-83-erroneous programs at compile time. The new rule fits in well with the new freezing-point rules. Furthermore, we are trying to convert undefined-value problems into bounded errors, and we were having trouble for the case of deferred constants. Furthermore, uninitialized deferred constants cause trouble for the shared variable / tasking rules, since they are really variable, even though they purport to be constant. In Ada 9X, they cannot be touched until they become constant. 0.f Note that we do not consider this change to be an upward incompatibility, because it merely changes an erroneous execution in Ada 83 into a compile-time error. 0.g The Ada 83 semantics are unclear in the case where the full view turns out to be an access type. It is a goal of the language design to prevent uninitialized access objects. One wonders if the implementation is required to initialize the deferred constant to null, and then initialize it (again!) to its real value. In Ada 9X, the problem goes away. Wording Changes From Ada 83 0.h Since deferred constants can now be of a nonprivate type, we have made this a stand-alone clause, rather than a subclause of 7.3, ``Private Types and Private Extensions''. 0.i Deferred constant declarations used to have their own syntax, but now they are simply a special case of object_declarations. 7.5 Limited Types Extensions to Ada 83 0.a The restrictions in RM83-7.4.4(4), which disallowed out parameters of limited types in certain cases, are removed. Wording Changes From Ada 83 0.b Since limitedness and privateness are orthogonal in Ada 9X (and to some extent in Ada 83), this is now its own clause rather than being a subclause of 7.3, ``Private Types and Private Extensions''. 7.6 User-Defined Assignment and Finalization Extensions to Ada 83 0.a Controlled types and user-defined finalization are new to Ada 9X. (Ada 83 had finalization semantics only for masters of tasks.) 7.6.1 Completion and Finalization Wording Changes From Ada 83 0.a Finalization depends on the concepts of completion and leaving, and on the concept of a master. Therefore, we have moved the definitions of these concepts here, from where they used to be in Section 9. These concepts also needed to be generalized somewhat. Task waiting is closely related to user-defined finalization; the rules here refer to the task-waiting rules of Section 9. Section 8: Visibility Rules Wording Changes From Ada 83 0.a We no longer define the term ``basic operation;'' thus we no longer have to worry about the visibility of them. Since they were essentially always visible in Ada 83, this change has no effect. The reason for this change is that the definition in Ada 83 was confusing, and not quite correct, and we found it difficult to fix. For example, one wonders why an if_statement was not a basic operation of type Boolean. For another example, one wonders what it meant for a basic operation to be ``inherent in'' something. Finally, this fixes the problem addressed by AI-00027/07. 8.1 Declarative Region Wording Changes From Ada 83 0.a It was necessary to extend Ada 83's definition of declarative region to take the following Ada 9X features into account: 0.b Child library units. 0.c Derived types/type extensions -- we need a declarative region for inherited components and also for new components. 0.d All the kinds of types that allow discriminants. 0.e Protected units. 0.f Entries that have bodies instead of accept statements. 0.g The choice_parameter_specification of an exception_ handler. 0.h The formal parameters of access-to-subprogram types. 0.i Renamings-as-body. 0.j Discriminated and access-to-subprogram type declarations need a declarative region. Enumeration type declarations cannot have one, because you don't have to say "Color.Red" to refer to the literal Red of Color. For other type declarations, it doesn't really matter whether or not there is an associated declarative region, so for simplicity, we give one to all types except enumeration types. 0.k We now say that an accept_statement has its own declarative region, rather than being part of the declarative region of the entry_declaration, so that declarative regions are properly nested regions of text, so that it makes sense to talk about "inner declarative regions," and "...extends to the end of a declarative region." Inside an accept_statement, the name of one of the parameters denotes the parameter_specification of the accept_ statement, not that of the entry_declaration. If the accept_ statement is nested within a block_statement, these parameter_ specifications can hide declarations of the block_statement. The semantics of such cases was unclear in RM83. 0.l Note that we can't generalize this to entry_bodies, or other bodies, because the declarative_part of a body is not supposed to contain (explicit) homographs of things in the declaration. It works for accept_statements only because an accept_statement does not have a declarative_part. 0.m To avoid confusion, we use the term ``local to'' only informally in Ada 9X. Even RM83 used the term incorrectly (see, for example, RM83-12.3(13)). 0.n In Ada 83, (root) library units were inside Standard; it was not clear whether the declaration or body of Standard was meant. In Ada 9X, they are children of Standard, and so occur immediately within Standard's declarative region, but not within either the declaration or the body. (See RM83-8.6(2) and RM83-10.1.1(5).) 8.2 Scope of Declarations Extensions to Ada 83 0.a The fact that the immediate scope of an overloadable declaration does not include its profile is new to Ada 9X. It replaces RM83-8.3(16), which said that within a subprogram specification and within the formal part of an entry declaration or accept statement, all declarations with the same designator as the subprogram or entry were hidden from all visibility. The RM83-8.3(16) rule seemed to be overkill, and created both implementation difficulties and unnecessary semantic complexity. Wording Changes From Ada 83 0.b We no longer need to talk about the scope of notations, identifiers, character_literals, and operator_symbols. 0.c The notion of "visible part" has been extended in Ada 9X. The syntax of task and protected units now allows private parts, thus requiring us to be able to talk about the visible part as well. It was necessary to extend the concept to subprograms and to generic units, in order for the visibility rules related to child library units to work properly. It was necessary to define the concept separately for generic formal packages, since their visible part is slightly different from that of a normal package. Extending the concept to composite types made the definition of scope slightly simpler. We define visible part for some things elsewhere, since it makes a big difference to the user for those things. For composite types and subprograms, however, the concept is used only in arcane visibility rules, so we localize it to this clause. 0.d In Ada 83, the semantics of with_clauses was described in terms of visibility. It is now described in terms of [immediate] scope. 0.e We have clarified that the following is illegal (where Q and R are library units): 0.f package Q is I : Integer := 0; end Q; 0.g package R is package X renames Standard; X.Q.I := 17; -- Illegal! end R; 0.h even though Q is declared in the declarative region of Standard, because R does not mention Q in a with_clause. 8.3 Visibility Extensions to Ada 83 0.a Declarations with the same defining name as that of a subprogram or entry being defined are nevertheless visible within the subprogram specification or entry declaration. Wording Changes From Ada 83 0.b The term ``visible by selection'' is no longer defined. We use the terms ``directly visible'' and ``visible'' (among other things). There are only two regions of text that are of interest, here: the region in which a declaration is visible, and the region in which it is directly visible. 0.c Visibility is defined only for declarations. 8.4 Use Clauses Extensions to Ada 83 0.a The use_type_clause is new to Ada 9X. Wording Changes From Ada 83 0.b The phrase ``omitting from this set any packages that enclose this place'' is no longer necessary to avoid making something visible outside its scope, because we explicitly state that the declaration has to be visible in order to be potentially use-visible. 8.5 Renaming Declarations Wording Changes From Ada 83 0.a The second sentence of RM83-8.5(3), ``At any point where a renaming declaration is visible, the identifier, or operator symbol of this declaration denotes the renamed entity.'' is incorrect. It doesn't say directly visible. Also, such an identifier might resolve to something else. 0.b The verbiage about renamings being legal ``only if exactly one...'', which appears in RM83-8.5(4) (for objects) and RM83-8.5(7) (for subprograms) is removed, because it follows from the normal rules about overload resolution. For language lawyers, these facts are obvious; for programmers, they are irrelevant, since failing these tests is highly unlikely. 8.5.1 Object Renaming Declarations Wording Changes From Ada 83 0.a The phrase ``subtype ... as defined in a corresponding object declaration, component declaration, or component subtype indica- tion,'' from RM83-8.5(5), is incorrect in Ada 9X; therefore we removed it. It is incorrect in the case of an object with an indefinite unconstrained nominal subtype. 8.5.2 Exception Renaming Declarations 8.5.3 Package Renaming Declarations 8.5.4 Subprogram Renaming Declarations 8.5.5 Generic Renaming Declarations Extensions to Ada 83 0.a Renaming of generic units is new to Ada 9X. It is particularly important for renaming child library units that are generic units. For example, it might be used to rename Numerics.Generic_Elementary_ Functions as simply Generic_Elementary_Functions, to match the name for the corresponding Ada-83-based package. Wording Changes From Ada 83 0.b The information in RM83-8.6, ``The Package Standard,'' has been updated for the child unit feature, and moved to Annex A, except for the definition of ``predefined type,'' which has been moved to 3.2.1. 8.6 The Context of Overload Resolution Incompatibilities With Ada 83 0.a The new preference rule for operators of root numeric types is upward incompatible, but only in cases that involved Beaujolais effects in Ada 83. Such cases are ambiguous in Ada 9X. Extensions to Ada 83 0.b The rule that allows an expected type to match an actual expression of a universal type, in combination with the new preference rule for operators of root numeric types, subsumes the Ada 83 "implicit conversion" rules for universal types. Wording Changes From Ada 83 0.c In Ada 83, it is not clear what the ``syntax rules'' are. AI-00157 states that a certain textual rule is a syntax rule, but it's still not clear how one tells in general which textual rules are syntax rules. We have solved the problem by stating exactly which rules are syntax rules -- the ones that appear under the ``Syntax'' heading. 0.d RM83 has a long list of the ``forms'' of rules that are to be used in overload resolution (in addition to the syntax rules). It is not clear exactly which rules fall under each form. We have solved the problem by explicitly marking all rules that are used in overload resolution. Thus, the list of kinds of rules is unnecessary. It is replaced with some introductory (intentionally vague) text explaining the basic idea of what sorts of rules are overloading rules. 0.e It is not clear from RM83 what information is embodied in a ``meaning'' or an ``interpretation.'' ``Meaning'' and ``inter- pretation'' were intended to be synonymous; we now use the latter only in defining the rules about overload resolution. ``Meaning'' is used only informally. This clause attempts to clarify what is meant by ``interpretation.'' 0.f For example, RM83 does not make it clear that overload resolution is required in order to match subprogram_bodies with their corresponding declarations (and even to tell whether a given subprogram_body is the completion of a previous declaration). Clearly, the information needed to do this is part of the ``interpretation'' of a subprogram_body. The resolution of such things is defined in terms of the ``expected profile'' concept. Ada 9X has some new cases where expected profiles are needed -- the resolution of P'Access, where P might denote a subprogram, is an example. 0.g RM83-8.7(2) might seem to imply that an interpretation embodies information about what is denoted by each usage name, but not information about which syntactic category each construct belongs to. However, it seems necessary to include such information, since the Ada grammar is highly ambiguous. For example, X(Y) might be a function_call or an indexed_component, and no context-free/syntactic information can tell the difference. It seems like we should view X(Y) as being, for example, ``interpreted as a function_call'' (if that's what overload resolution decides it is). Note that there are examples where the denotation of each usage name does not imply the syntactic category. However, even if that were not true, it seems that intuitively, the interpretation includes that information. Here's an example: 0.h type T; type A is access T; type T is array(Integer range 1..10) of A; I : Integer := 3; function F(X : Integer := 7) return A; Y : A := F(I); -- Ambiguous? (We hope so.) 0.i Consider the declaration of Y (a complete context). In the above example, overload resolution can easily determine the declaration, and therefore the entity, denoted by Y, A, F, and I. However, given all of that information, we still don't know whether F(I) is a function_call or an indexed_component whose prefix is a function_call. (In the latter case, it is equivalent to F(7).all(I).) 0.j It seems clear that the declaration of Y ought to be considered ambiguous. We describe that by saying that there are two interpretations, one as a function_call, and one as an indexed_ component. These interpretations are both acceptable to the overloading rules. Therefore, the complete context is ambiguous, and therefore illegal. 0.k It is the intent that the Ada 9X preference rule for root numeric operators is more locally enforceable than that of RM83-4.6(15). It should also eliminate interpretation shifts due to the addition or removal of a use_clause (the so called Beaujolais effect). 0.l RM83-8.7 seems to be missing some complete contexts, such as pragma_argument_associations, declarative_items that are not declara- tions or representation_clauses, and context_items. We have added these, and also replaced the ``must be determinable'' wording of RM83-5.4(3) with the notion that the expression of a case_statement is a complete context. 0.m Cases like the Val attribute are now handled using the normal type resolution rules, instead of having special cases that explicitly allow things like ``any integer type.'' Section 9: Tasks and Synchronization Wording Changes From Ada 83 0.a The introduction has been rewritten. 0.b We use the term "concurrent" rather than "parallel" when talking about logically independent execution of threads of control. The term "parallel" is reserved for referring to the situation where multiple physical processors run simultaneously. 9.1 Task Units and Task Objects Extensions to Ada 83 0.a The syntax rules for task declarations are modified to allow a known_discriminant_part, and to allow a private part. They are also modified to allow entry_declarations and representation_clauses to be mixed. Wording Changes From Ada 83 0.b The syntax rules for tasks have been split up according to task types and single tasks. In particular: The syntax rules for task_ declaration and task_specification are removed. The syntax rules for task_type_declaration, single_task_declaration, task_definition and task_item are new. 0.c The syntax rule for task_body now uses the nonterminal handled_ sequence_of_statements. 0.d The declarative_part of a task_body is now required; that doesn't make any real difference, because a declarative_part can be empty. 9.2 Task Execution - Task Activation Wording Changes From Ada 83 0.a We have replaced the term suspended with blocked, since we didn't want to consider a task blocked when it was simply competing for execution resources. "Suspended" is sometimes used more generally to refer to tasks that are not actually running on some processor, due to the lack of resources. 0.b This clause has been rewritten in an attempt to improve presentation. 9.3 Task Dependence - Termination of Tasks Wording Changes From Ada 83 0.a We have revised the wording to be consistent with the definition of master now given in 7.6.1, ``Completion and Finalization''. 0.b Tasks that used to depend on library packages in Ada 83, now depend on the (implicit) task_body of the environment task (see 10.2). Therefore, the environment task has to wait for them before performing library level finalization and terminating the partition. In Ada 83 the requirement to wait for tasks that depended on library packages was not as clear. 0.c What was "collective termination" is now "collective completion" resulting from selecting terminate_alternatives. This is because finalization still occurs for such tasks, and this happens after selecting the terminate_alternative, but before termination. 9.4 Protected Units and Protected Objects Extensions to Ada 83 0.a This entire clause is new; protected units do not exist in Ada 83. 9.5 Intertask Communication 9.5.1 Protected Subprograms and Protected Actions 9.5.2 Entries and Accept Statements Extensions to Ada 83 0.a The syntax rule for entry_body is new. 0.b Accept_statements can now have exception_handlers. 9.5.3 Entry Calls 9.5.4 Requeue Statements Extensions to Ada 83 0.a The requeue_statement is new. 9.6 Delay Statements, Duration, and Time Inconsistencies With Ada 83 0.a For programs that raise Time_Error on "+" or "-" in Ada 83,the exception might be deferred until a call on Split or Year_Number, or might not be raised at all (if the offending time is never Split after being calculated). This should not affect typical programs, since they deal only with times corresponding to the relatively recent past or near future. Extensions to Ada 83 0.b The syntax rule for delay_statement is modified to allow delay_ until_statements. 0.c The type Time may represent dates with year numbers outside of Year_Number. Therefore, the operations "+" and "-" need only raise Time_Error if the result is not representable in Time (or Duration); also, Split or Year will now raise Time_Error if the year number is outside of Year_Number. This change is intended to simplify the implementation of "+" and "-" (allowing them to depend on overflow for detecting when to raise Time_Error) and to allow local timezone information to be considered at the time of Split rather than Clock (depending on the implementation approach). For example, in a POSIX environment, it is natural for the type Time to be based on GMT, and the results of procedure Split (and the functions Year, Month, Day, and Seconds) to depend on local time zone information. In other environments, it is more natural for the type Time to be based on the local time zone, with the results of Year, Month, Day, and Seconds being pure functions of their input. 0.d We anticipate that implementations will provide child packages of Calendar to provide more explicit control over time zones and other environment-dependent time-related issues. These would be appropriate for standardization in a given environment (such as POSIX). 9.7 Select Statements Extensions to Ada 83 0.a Asynchronous_select is new. 9.7.1 Selective Accept Wording Changes From Ada 83 0.a The name of selective_wait was changed to selective_accept to better describe what is being waited for. We kept select_alternative as is, because selective_accept_alternative was too easily confused with accept_alternative. 9.7.2 Timed Entry Calls Wording Changes From Ada 83 0.a This clause comes before the one for Conditional Entry Calls, so we can define conditional entry calls in terms of timed entry calls. 9.7.3 Conditional Entry Calls Wording Changes From Ada 83 0.a This clause comes after the one for Timed Entry Calls, so we can define conditional entry calls in terms of timed entry calls. We do that so that an "expiration time" is defined for both, thereby simplifying the definition of what happens on a requeue-with-abort. 9.7.4 Asynchronous Transfer of Control Extensions to Ada 83 0.a Asynchronous_select is new. 9.8 Abort of a Task - Abort of a Sequence of Statements Wording Changes From Ada 83 0.a This clause has been rewritten to accommodate the concept of aborting the execution of a construct, rather than just of a task. 9.9 Task and Entry Attributes 9.10 Shared Variables 9.11 Example of Tasking and Synchronization Section 10: Program Structure and Compilation Issues Wording Changes From Ada 83 0.a The section organization mentioned above is different from that of RM83. 10.1 Separate Compilation Wording Changes From Ada 83 0.a The interactions between language issues and environmental issues are left open in Ada 9X. The environment concept is new. In Ada 83, the concept of the program library, for example, appeared to be quite concrete, although the rules had no force, since implementations could get around them simply by defining various mappings from the concept of an Ada program library to whatever data structures were actually stored in support of separate compilation. Indeed, implementations were encouraged to do so. 0.b In RM83, it was unclear which was the official definition of ``program unit.'' Definitions appeared in RM83-5, 6, 7, and 9, but not 12. Placing it here seems logical, since a program unit is sort of a potential compilation unit. 10.1.1 Compilation Units - Library Units Extensions to Ada 83 0.a The syntax rule for library_item is modified to allow the reserved word private before a library_unit_declaration. 0.b Children (other than children of Standard) are new in Ada 9X. 0.c Library unit renaming is new in Ada 9X. Wording Changes From Ada 83 0.d Standard is considered a library unit in Ada 9X. This simplifies the descriptions, since it implies that the parent of each library unit is a library unit. (Standard itself has no parent, of course.) As in Ada 83, the language does not define any way to recompile Standard, since the name given in the declaration of a library unit is always interpreted in relation to Standard. That is, an attempt to compile a package Standard would result in Standard.Standard. 10.1.2 Context Clauses - With Clauses Extensions to Ada 83 0.a The syntax rule for with_clause is modified to allow expanded name notation. 0.b A use_clause in a context_clause may be for a package (or type) nested in a library package. Wording Changes From Ada 83 0.c The syntax rule for context_clause is modified to more closely reflect the semantics. The Ada 83 syntax rule implies that the use_ clauses that appear immediately after a particular with_clause are somehow attached to that with_clause, which is not true. The new syntax allows a use_clause to appear first, but that is prevented by a textual rule that already exists in Ada 83. 0.d The concept of ``scope of a with_clause'' (which is a region of text) replaces RM83's notion of ``apply to'' (a with_clause applies to a library_item) The visibility rules are interested in a region of text, not in a set of compilation units. 0.e No need to define ``apply to'' for use_clauses. Their semantics are fully covered by the ``scope (of a use_clause)'' definition in 8.4. 10.1.3 Subunits of Compilation Units Extensions to Ada 83 0.a Subunits of the same ancestor library unit are no longer restricted to have distinct identifiers. Instead, we require only that the full expanded names be distinct. 10.1.4 The Compilation Process 10.1.5 Pragmas and Program Units 10.1.6 Environment-Level Visibility Rules Wording Changes From Ada 83 0.a The special visibility rules that apply within a parent_unit_ name or a context_clause, and within a pragma that appears at the place of a compilation_unit are clarified. 0.b Note that a context_clause is not part of any declarative region. 0.c We considered making the visibility rules within parent_unit_ names and context_clauses follow from the context of compilation. However, this attempt failed for various reasons. For example, it would require use_clauses in context_clauses to be within the declarative region of Standard, which sounds suspiciously like a kludge. And we would still need a special rule to prevent seeing things (in our own context_clause) that were with-ed by our parent, etc. 10.2 Program Execution Extensions to Ada 83 0.a The concept of partitions is new to Ada 9X. 0.b A main subprogram is now optional. The language-defined restrictions on main subprograms are relaxed. Wording Changes From Ada 83 0.c Ada 9X uses the term ``main subprogram'' instead of Ada 83's ``main program'' (which was inherited from Pascal). This is done to avoid confusion -- a main subprogram is a subprogram, not a program. The program as a whole is an entirely different thing. 10.2.1 Elaboration Control Extensions to Ada 83 0.a The concepts of preelaborability and purity are new to Ada 9X. The Elaborate_All, Elaborate_Body, Preelaborate, and Pure pragmas are new to Ada 9X. 0.b Pragmas Elaborate are allowed to be mixed in with the other things in the context_clause -- in Ada 83, they were required to appear last. Section 11: Exceptions Wording Changes From Ada 83 0.a We are more explicit about the difference between an exception and an occurrence of an exception. This is necessary because we now have a type (Exception_Occurrence) that represents exception occurrences, so the program can manipulate them. Furthermore, we say that when an exception is propagated, it is the same occurrence that is being propagated (as opposed to a new occurrence of the same exception). The same issue applies to a re-raise statement. In order to understand these semantics, we have to make this distinction. 11.1 Exception Declarations Inconsistencies With Ada 83 0.a The exception Numeric_Error is now defined in the Obsolescent features Annex, as a rename of Constraint_Error. All checks that raise Numeric_Error in Ada 83 instead raise Constraint_Error in Ada 9X. To increase upward compatibility, we also changed the rules to allow the same exception to be named more than once by a given handler. Thus, ``when Constraint_Error | Numeric_Error =>'' will remain legal in Ada 9X, even though Constraint_Error and Numeric_ Error now denote the same exception. However, it will not be legal to have separate handlers for Constraint_Error and Numeric_Error. This change is inconsistent in the rare case that an existing program explicitly raises Numeric_Error at a point where there is a handler for Constraint_Error; the exception will now be caught by that handler. Wording Changes From Ada 83 0.b We explicitly define elaboration for exception_declarations. 11.2 Exception Handlers Extensions to Ada 83 0.a The syntax rule for exception_handler is modified to allow a choice_parameter_specification. 0.b Different choices of the same exception_handler may cover the same exception. This allows for ``when Numeric_Error | Constraint_ Error =>'' even though Numeric_Error is a rename of Constraint_Error. This also allows one to ``with'' two different I/O packages, and then write, for example, ``when Ada.Text_IO.Data_Error | My_Seq_IO.Data_ Error =>'' even though these might both be renames of the same exception. Wording Changes From Ada 83 0.c The syntax rule for handled_sequence_of_statements is new. These are now used in all the places where handlers are allowed. This obviates the need to explain (in Sections 5, 6, 7, and 9) what portions of the program are handled by the handlers. Note that there are more such cases in Ada 9X. 0.d The syntax rule for choice_parameter_specification is new. 11.3 Raise Statements Wording Changes From Ada 83 0.a The fact that the name in a raise_statement has to denote an exception is not clear from RM83. Clearly that was the intent, since the italicized part of the syntax rules so indicate, but there was no explicit rule. RM83-1.5(11) doesn't seem to give the italicized parts of the syntax any force. 11.4 Exception Handling 11.4.1 The Package Exceptions Extensions to Ada 83 0.a The Identity attribute of exceptions is new, as is the package Exceptions. 11.4.2 Example of Exception Handling Wording Changes From Ada 83 0.a The sections labeled ``Exceptions Raised During ...'' are subsumed by this clause, and by parts of Section 9. 11.5 Suppressing Checks Extensions to Ada 83 0.a A pragma Suppress is allowed as a configuration pragma. A pragma Suppress without a name is allowed in a package_specification. 0.b Additional check names are added. We allow implementations to define their own checks. Wording Changes From Ada 83 0.c We define the checks in a distributed manner. Therefore, the long list of what checks apply to what is merely a NOTE. 0.d We have removed the detailed rules about what is allowed in a pragma Suppress, and allow implementations to invent their own. The RM83 rules weren't quite right, and such a change is necessary anyway in the presence of implementation-defined checks. 0.e We make it clear that the difference between a Range_Check and an Overflow_Check is fuzzy. This was true in Ada 83, given RM83-11.6, but it was not clear. We considered removing Overflow_ Check from the language or making it obsolescent, just as we did for Numeric_Error. However, we kept it for upward compatibility, and because it may be useful on machines where range checking costs more than overflow checking, but overflow checking still costs something. Different compilers will suppress different checks when asked to suppress Overflow_Check -- the non-uniformity in this case is not harmful, and removing it would have a serious impact on optimizers. 0.f Under Access_Check, dereferences cover the cases of selected_ component, indexed_component, slice, and attribute that are listed in RM83, as well as the new explicit_dereference, which was included in selected_component in RM83. 11.6 Exceptions and Optimization Wording Changes From Ada 83 0.a RM83-11.6 was unclear. It has been completely rewritten here; we hope this version is clearer. Here's what happened to each paragraph of RM83-11.6: 0.b Paragraphs 1 and 2 contain no semantics; they are merely pointing out that anything goes if the canonical semantics is preserved. We have similar introductory paragraphs, but we have tried to clarify that these are not granting any ``extra'' permission beyond what the rest of the document allows. 0.c Paragraphs 3 and 4 are reflected in the ``extra permission to reorder actions''. Note that this permission now allows the reordering of assignments in many cases. 0.d Paragraph 5 is moved to 4.5, ``Operators and Expression Evaluation'', where operator association is discussed. Hence, this is no longer an ``extra permission'' but is part of the canonical semantics. 0.e Paragraph 6 now follows from the general permission to store out-of-range values for unconstrained subtypes. Note that the parameters and results of all the predefined operators of a type are of the unconstrained subtype of the type. 0.f Paragraph 7 is reflected in the ``extra permission to avoid raising exceptions''. 0.g We moved clause 11.5, ``Suppressing Checks'' from after 11.6 to before 11.6, in order to preserve the famous number ``11.6'' (given the changes to earlier clauses in Section 11). Section 12: Generic Units 12.1 Generic Declarations Extensions to Ada 83 0.a The syntax rule for generic_formal_parameter_declaration is modified to allow the reserved words tagged and abstract, to allow formal derived types, and to allow formal packages. 0.b Use_clauses are allowed in generic_formal_parts. This is necessary in order to allow a use_clause within a formal part to provide direct visibility of declarations within a generic formal package. Wording Changes From Ada 83 0.c The syntax for generic_formal_parameter_declaration and formal_ type_definition is split up into more named categories. The rules for these categories are moved to the appropriate clauses and subclauses. The names of the categories are changed to be more intuitive and uniform. For example, we changed generic_parameter_ declaration to generic_formal_parameter_declaration, because the thing it declares is a generic formal, not a generic. In the others, we abbreviate ``generic_formal'' to just ``formal''. We can't do that for generic_formal_parameter_declaration, because of confusion with normal formal parameters of subprograms. 12.2 Generic Bodies 12.3 Generic Instantiation Inconsistencies With Ada 83 0.a In Ada 83, all explicit actuals are evaluated before all defaults, and the defaults are evaluated in the order of the formal declarations. This ordering requirement is relaxed in Ada 9X. Incompatibilities With Ada 83 0.b We have attempted to remove every violation of the contract model. Any remaining contract model violations should be considered bugs in the RM9X. The unfortunate property of reverting to the predefined operators of the actual types is retained for upward compatibility. (Note that fixing this would require subtype conformance rules.) However, tagged types do not revert in this sense. Extensions to Ada 83 0.c The syntax rule for explicit_generic_actual_parameter is modified to allow a package_instance_name. Wording Changes From Ada 83 0.d The fact that named associations cannot be used for two formal subprograms with the same defining name is moved to AARM-only material, because it is a ramification of other rules, and because it is not of interest to the average user. 0.e The rule that ``An explicit explicit_generic_actual_parameter shall not be supplied more than once for a given generic_formal_ parameter'' seems to be missing from RM83, although it was clearly the intent. 0.f In the explanation that the instance is a copy of the template, we have left out RM83-12.3(5)'s ``apart from the generic formal part'', because it seems that things in the formal part still need to exist in instances. This is particularly true for generic formal packages, where you're sometimes allowed to reach in and denote the formals of the formal package from outside it. This simplifies the explanation of what each name in an instance denotes: there are just two cases: the declaration can be inside or outside (where inside needs to include the generic unit itself). Note that the RM83 approach of listing many cases (see RM83-12.5(5-14)) would have become even more unwieldy with the addition of generic formal packages, and the declarations that occur therein. 0.g We have corrected the definition of the elaboration of a generic_instantiation (RM83-12.3(17)); we don't elaborate entities, and the instance is not ``implicit.'' 0.h In RM83, there is a rule saying the formal and actual shall match, and then there is much text defining what it means to match. Here, we simply state all the latter text as rules. For example, ``A formal foo is matched by an actual greenish bar'' becomes ``For a formal foo, the actual shall be a greenish bar.'' This is necessary to split the Name Resolution Rules from the Legality Rules. Besides, there's really no need to define the concept of matching for generic parameters. 12.4 Formal Objects Extensions to Ada 83 0.a In Ada 83, it is forbidden to pass a (nongeneric) formal parameter of mode out, or a subcomponent thereof, to a generic formal object of mode in out. This restriction is removed in Ada 9X. Wording Changes From Ada 83 0.b We make ``mode'' explicit in the syntax. RM83 refers to the mode without saying what it is. This is also more uniform with the way (nongeneric) formal parameters are defined. 0.c We considered allowing mode out in Ada 9X, for uniformity with (nongeneric) formal parameters. The semantics would be identical for modes in out and out. (Note that generic formal objects of mode in out are passed by reference. Note that for (nongeneric) formal parameters that are allowed to be passed by reference, the semantics of in out and out is the same. The difference might serve as documentation. The same would be true for generic formal objects, if out were allowed, so it would be consistent.) We decided not to make this change, because it does not produce any important benefit, and any change has some cost. 12.5 Formal Types Wording Changes From Ada 83 0.a RM83 has separate sections ``Generic Formal Xs'' and ``Matching Rules for Formal Xs'' (for various X's) with most of the text redundant between the two. We have combined the two in order to reduce the redundancy. In RM83, there is no ``Matching Rules for Formal Types'' section; nor is there a ``Generic Formal Y Types'' section (for Y = Private, Scalar, Array, and Access). This causes, for example, the duplication across all the ``Matching Rules for Y Types'' sections of the rule that the actual passed to a formal type shall be a subtype; the new organization avoids that problem. 0.b The matching rules are stated more concisely. 0.c We no longer consider the multiplying operators that deliver a result of type universal_fixed to be predefined for the various types; there is only one of each in package Standard. Therefore, we need not mention them here as RM83 had to. 12.5.1 Formal Private and Derived Types Incompatibilities With Ada 83 0.a Ada 83 does not have unknown_discriminant_parts, so it allows indefinite subtypes to be passed to definite formals, and applies a legality rule to the instance body. This is a contract model violation. Ada 9X disallows such cases at the point of the instantiation. The workaround is to add (<>) as the discriminant_ part of any formal subtype if it is intended to be used with indefinite actuals. If that's the intent, then there can't be anything in the generic body that would require a definite subtype. 0.b The check for discriminant subtype matching is changed from a run-time check to a compile-time check. 12.5.2 Formal Scalar Types 12.5.3 Formal Array Types Incompatibilities With Ada 83 0.a The check for matching of component subtypes and index subtypes or index ranges is changed from a run-time check to a compile-time check. The Ada 83 rule that ``If the component type is not a scalar type, then the component subtypes shall be either both constrained or both unconstrained'' is removed, since it is subsumed by static matching. Likewise, the rules requiring that component types be the same is subsumed. 12.5.4 Formal Access Types Incompatibilities With Ada 83 0.a The check for matching of designated subtypes is changed from a run-time check to a compile-time check. The Ada 83 rule that ``If the designated type is other than a scalar type, then the designated subtypes shall be either both constrained or both unconstrained'' is removed, since it is subsumed by static matching. Extensions to Ada 83 0.b Formal access-to-subprogram subtypes and formal general access types are new concepts. 12.6 Formal Subprograms 12.7 Formal Packages Extensions to Ada 83 0.a Formal packages are new to Ada 9X. 12.8 Example of a Generic Package Section 13: Representation Issues Wording Changes From Ada 83 0.a The clauses of this section have been reorganized. This was necessary to preserve a logical order, given the new Ada 9X semantics given in this section. 13.1 Representation Items Incompatibilities With Ada 83 0.a It is now illegal for a representation item to cause a derived by-reference type to have a different record layout from its parent. This is necessary for by-reference parameter passing to be feasible. This only affects programs that specify the representation of types derived from types containing tasks; most by-reference types are new to Ada 9X. For example, if A1 is an array of tasks, and A2 is derived from A1, it is illegal to apply a pragma Pack to A2. Extensions to Ada 83 0.b Ada 9X allows additional representation_clauses for objects. Wording Changes From Ada 83 0.c The syntax rule for type_representation_clause is removed; the right-hand side of that rule is moved up to where it was used, in representation_clause. There are two references to ``type representation clause'' in RM83, both in Section 13; these have been reworded. 0.d We have defined a new term ``representation item,'' which includes both representation_clauses and representation pragmas, as well as component_clauses. This is convenient because the rules are almost identical for all three. 0.e All of the forcing occurrence stuff has been moved into its own subclause (see 13.14), and rewritten to use the term ``freezing''. 0.f RM83-13.1(10) requires implementation-defined restrictions on representation items to be enforced at compile time. However, that is impossible in some cases. If the user specifies a junk (nonstatic) address in an address clause, and the implementation chooses to detect the error (for example, using hardware memory management with protected pages), then it's clearly going to be a run-time error. It seems silly to call that ``semantics'' rather than ``a restriction.'' 0.g RM83-13.1(10) tries to pretend that representation_clauses don't affect the semantics of the program. One counter-example is the Small clause. Ada 9X has more counter-examples. We have noted the opposite above. 0.h Some of the more stringent requirements are moved to C.2, ``Required Representation Support''. 13.2 Pragma Pack 13.3 Representation Attributes Wording Changes From Ada 83 0.a The intended meaning of the various attributes, and their attribute_definition_clauses, is more explicit. 0.b The address_clause has been renamed to at_clause and moved to Annex J, ``Obsolescent Features''. One can use an Address clause (``for T'Address use ...;'') instead. 0.c The attributes defined in RM83-13.7.3 are moved to Annex G, A.5.3, and A.5.4. Wording Changes From Ada 83 0.d The nonnegative part is missing from RM83 (for mod_clauses, nee alignment_clauses, which are an obsolete version of Alignment clauses). Wording Changes From Ada 83 0.e The requirement for a nonnegative value in a Size clause was not in RM83, but it's hard to see how it would make sense. For uniformity, we forbid negative sizes, rather than letting implementations define their meaning. Extensions to Ada 83 0.f The syntax rule for length_clause is replaced with the new syntax rule for attribute_definition_clause, and it is modified to allow a name (as well as an expression). Wording Changes From Ada 83 0.g The syntax rule for attribute_definition_clause now requires that the prefix of the attribute be a local_name; in Ada 83 this rule was stated in the text. 0.h In Ada 83, the relationship between a representation_clause specifying a certain aspect and an attribute that queried that aspect was unclear. In Ada 9X, they are the same, except for certain explicit exceptions. 13.4 Enumeration Representation Clauses Extensions to Ada 83 0.a As in other similar contexts, Ada 9X allows expressions of any integer type, not just expressions of type universal_integer, for the component expressions in the enumeration_aggregate. The preference rules for the predefined operators of root_integer eliminate any ambiguity. 0.b For portability, we now require that the default coding for an enumeration type be the ``obvious'' coding using position numbers. This is satisfied by all known implementations. 13.5 Record Layout 13.5.1 Record Representation Clauses Wording Changes From Ada 83 0.a The alignment_clause has been renamed to mod_clause and moved to Annex J, ``Obsolescent Features''. 0.b We have clarified that implementation-defined component names have to be in the form of an attribute_reference of a component or of the first subtype itself; surely Ada 83 did not intend to allow arbitrary identifiers. 0.c The RM83-13.4(7) wording incorrectly allows components in non-variant records to overlap. We have corrected that oversight. 13.5.2 Storage Place Attributes 13.5.3 Bit Ordering Extensions to Ada 83 0.a The Bit_Order attribute is new to Ada 9X. 13.6 Change of Representation 13.7 The Package System Wording Changes From Ada 83 0.a Much of the content of System is standardized, to provide more uniformity across implementations. Implementations can still add their own declarations to System, but are encouraged to do so via children of System. 0.b Some of the named numbers are defined more explicitly in terms of the standard numeric types. 0.c The pragmas System_Name, Storage_Unit, and Memory_Size are no longer defined by the language. However, the corresponding declarations in package System still exist. Existing implementations may continue to support the three pragmas as implementation-defined pragmas, if they so desire. 0.d Priority semantics, including subtype Priority, have been moved to the Real Time Annex. 13.7.1 The Package System.Storage_Elements 13.7.2 The Package System.Address_To_Access_Conversions 13.8 Machine Code Insertions Extensions to Ada 83 0.a Machine code functions are allowed in Ada 9X; in Ada 83, only procedures were allowed. Wording Changes From Ada 83 0.b The syntax for code_statement is changed to say ``qualified_ expression'' instead of ``subtype_mark'record_aggregate''. Requiring the type of each instruction to be a record type is overspecification. 13.9 Unchecked Type Conversions 13.9.1 Data Validity Wording Changes From Ada 83 0.a In order to reduce the amount of erroneousness, we separate the concept of an undefined value into objects with invalid representation (scalars only) and abnormal objects. 0.b Reading an object with an invalid representation is a bounded error rather than erroneous; reading an abnormal object is still erroneous. In fact, the only safe thing to do to an abnormal object is to assign to the object as a whole. 13.9.2 The Valid Attribute Extensions to Ada 83 0.a X'Valid is new in Ada 9X. 13.10 Unchecked Access Value Creation 13.11 Storage Management Extensions to Ada 83 0.a User-defined storage pools are new to Ada 9X. Wording Changes From Ada 83 0.b Ada 83 had a concept called a ``collection,'' which is similar to what we call a storage pool. All access types in the same derivation class shared the same collection. In Ada 9X, all access types in the same derivation class share the same storage pool, but other (unrelated) access types can also share the same storage pool, either by default, or as specified by the user. A collection was an amorphous collection of objects; a storage pool is a more concrete concept -- hence the different name. 0.c RM83 states the erroneousness of reading or updating deallocated objects incorrectly by missing various cases. 13.11.1 The Max_Size_In_Storage_Elements Attribute 13.11.2 Unchecked Storage Deallocation 13.11.3 Pragma Controlled Wording Changes From Ada 83 0.a Ada 83 used the term ``automatic storage reclamation'' to refer to what is known traditionally as ``garbage collection''. Because of the existence of storage pools (see 13.11), we need to distinguish this from the storage reclamation that might happen upon leaving a master. Therefore, we now use the term ``garbage collection'' in its normal computer-science sense. This has the additional advantage of making our terminology more accessible to people outside the Ada world. 13.12 Pragma Restrictions Extensions to Ada 83 0.a Pragma Restrictions is new to Ada 9X. 13.13 Streams Extensions to Ada 83 0.a Streams are new in Ada 9X. 13.13.1 The Package Streams 13.13.2 Stream-Oriented Attributes 13.14 Freezing Rules Incompatibilities With Ada 83 0.a RM83 defines a forcing occurrence of a type as follows: ``A forcing occurrence is any occurrence [of the name of the type, subtypes of the type, or types or subtypes with subcomponents of the type] other than in a type or subtype declaration, a subprogram specification, an entry declaration, a deferred constant declaration, a pragma, or a representation_clause for the type itself. In any case, an occurrence within an expression is always forcing.'' 0.b It seems like the wording allows things like this: 0.c type A is array(Integer range 1..10) of Boolean; subtype S is Integer range A'Range; -- not forcing for A 0.d Occurrences within pragmas can cause freezing in Ada 9X. (Since such pragmas are ignored in Ada 83, this will probably fix more bugs than it causes.) Extensions to Ada 83 0.e In Ada 9X, generic_formal_parameter_declarations do not normally freeze the entities from which they are defined. For example: 0.f package Outer is type T is tagged limited private; generic type T2 is new T with private; -- Does not freeze T -- in Ada 9X. package Inner is ... end Inner; private type T is ...; end Outer; 0.g This is important for the usability of generics. The above example uses the Ada 9X feature of formal derived types. Examples using the kinds of formal parameters already allowed in Ada 83 are well known. See, for example, comments 83-00627 and 83-00688. The extensive use expected for formal derived types makes this issue even more compelling than described by those comments. Unfortunately, we are unable to solve the problem that explicit_generic_actual_ parameters cause freezing, even though a package equivalent to the instance would not cause freezing. This is primarily because such an equivalent package would have its body in the body of the containing program unit, whereas an instance has its body right there. Wording Changes From Ada 83 0.h The concept of freezing is based on Ada 83's concept of ``forcing occurrences.'' The first freezing point of an entity corresponds roughly to the place of the first forcing occurrence, in Ada 83 terms. The reason for changing the terminology is that the new rules do not refer to any particular ``occurrence'' of a name of an entity. Instead, we refer to ``uses'' of an entity, which are sometimes implicit. 0.i In Ada 83, forcing occurrences were used only in rules about representation_clauses. We have expanded the concept to cover private types, because the rules stated in RM83-7.4.1(4) are almost identical to the forcing occurrence rules. 0.j The Ada 83 rules are changed in Ada 9X for the following reasons: 0.k The Ada 83 rules do not work right for subtype-specific aspects. In an earlier version of Ada 9X, we considered allowing representation items to apply to subtypes other than the first subtype. This was part of the reason for changing the Ada 83 rules. However, now that we have dropped that functionality, we still need the rules to be different from the Ada 83 rules. 0.l The Ada 83 rules do not achieve the intended effect. In Ada 83, either with or without the AIs, it is possible to force the compiler to generate code that references uninitialized dope, or force it to detect erroneousness and exception raising at compile time. 0.m It was a goal of Ada 83 to avoid uninitialized access values. However, in the case of deferred constants, this goal was not achieved. 0.n The Ada 83 rules are not only too weak -- they are also too strong. They allow loopholes (as described above), but they also prevent certain kinds of default_ expressions that are harmless, and certain kinds of generic_declarations that are both harmless and very useful. 0.o Ada 83 had a case where a representation_clause had a strong effect on the semantics of the program -- 'Small. This caused certain semantic anomalies. There are more cases in Ada 9X, because the attribute_representation_ clause has been generalized. THE STANDARD LIBRARIES Annex A (normative) Predefined Language Environment Wording Changes From Ada 83 0.a Many of Ada 83's language-defined library units are now children of Ada or System. For upward compatibility, these are renamed as root library units (see J.1). 0.b The order and lettering of the annexes has been changed. A.1 The Package Standard Extensions to Ada 83 0.a Package Standard is declared to be pure. Wording Changes From Ada 83 0.b Numeric_Error is made obsolescent. 0.c The declarations of Natural and Positive are moved to just after the declaration of Integer, so that "**" can refer to Natural without a forward reference. There's no real need to move Positive, too -- it just came along for the ride. A.2 The Package Ada Extensions to Ada 83 0.a This clause is new to Ada 9X. A.3 Character Handling Extensions to Ada 83 0.a This clause is new to Ada 9X. A.3.1 The Package Characters A.3.2 The Package Characters.Handling A.3.3 The Package Characters.Latin_1 A.4 String Handling Extensions to Ada 83 0.a This clause is new to Ada 9X. A.4.1 The Package Strings A.4.2 The Package Strings.Maps A.4.3 Fixed-Length String Handling A.4.4 Bounded-Length String Handling A.4.5 Unbounded-Length String Handling A.4.6 String-Handling Sets and Mappings A.4.7 Wide_String Handling A.5 The Numerics Packages Extensions to Ada 83 0.a Numerics and its children were not predefined in Ada 83. A.5.1 Elementary Functions Wording Changes From Ada 83 0.a The semantics of Numerics.Generic_Elementary_Functions differs from Generic_Elementary_Functions as defined in ISO/IEC DIS 11430 (for Ada 83) in the following ways: 0.b The generic package is a child unit of the package defining the Argument_Error exception. 0.c DIS 11430 specified names for the nongeneric equivalents, if provided. Here, those nongeneric equivalents are required. 0.d Implementations are not allowed to impose an optional restriction that the generic actual parameter associated with Float_Type be unconstrained. (In view of the ability to declare variables of subtype Float_Type'Base in implementations of Numerics.Generic_Elementary_Func- tions, this flexibility is no longer needed.) 0.e The sign of a prescribed zero result at the origin of the odd functions is specified, when Float_Type'Signed_Zeros is True. This conforms with recommendations of Kahan and other numerical analysts. 0.f The dependence of Arctan and Arccot on the sign of a parameter value of zero is tied to the value of Float_ Type'Signed_Zeros. 0.g Sqrt is prescribed to yield a result of one when its parameter has the value one. This guarantee makes it easier to achieve certain prescribed results of the complex elementary functions (see G.1.2, ``Complex Elementary Functions''). 0.h Conformance to accuracy requirements is conditional. A.5.2 Random Number Generation A.5.3 Attributes of Floating Point Types Incompatibilities With Ada 83 0.a The Epsilon and Mantissa attributes of floating point types are removed from the language and replaced by Model_Epsilon and Model_ Mantissa, which may have different values (as a result of changes in the definition of model numbers); the replacement of one set of attributes by another is intended to convert what would be an inconsistent change into an incompatible change. 0.b The Emax, Small, Large, Safe_Emax, Safe_Small, and Safe_Large attributes of floating point types are removed from the language. Small and Safe_Small are collectively replaced by Model_Small, which is functionally equivalent to Safe_Small, though it may have a slightly different value. The others are collectively replaced by Safe_First and Safe_Last. Safe_Last is functionally equivalent to Safe_Large, though it may have a different value; Safe_First is comparable to the negation of Safe_Large but may differ slightly from it as well as from the negation of Safe_Last. Emax and Safe_Emax had relatively few uses in Ada 83; T'Safe_Emax can be computed in the revised language as Integer'Min(T'Exponent(T'Safe_First), T'Exponent(T'Safe_Last)). 0.c Implementations are encouraged to eliminate the incom- patibilities discussed here by retaining the old attributes, during a transition period, in the form of implementation-defined attributes with their former values. Extensions to Ada 83 0.d The Model_Emin attribute is new. It is conceptually similar to the negation of Safe_Emax attribute of Ada 83, adjusted for the fact that the model numbers now have the hardware radix. It is a fundamental determinant, along with Model_Mantissa, of the set of model numbers of a type (see G.2.1). 0.e The Denorm and Signed_Zeros attributes are new, as are all of the primitive function attributes. A.5.4 Attributes of Fixed Point Types Incompatibilities With Ada 83 0.a The Mantissa, Large, Safe_Small, and Safe_Large attributes of fixed point types are removed from the language. 0.b Implementations are encouraged to eliminate the resulting incompatibility by retaining these attributes, during a transition period, in the form of implementation-defined attributes with their former values. Extensions to Ada 83 0.c The Machine_Radix attribute is now allowed for fixed point types. It is also specifiable in an attribute definition clause (see F.1). A.6 Input-Output Inconsistencies With Ada 83 0.a The introduction of Append_File as a new element of the enumeration type File_Mode in Sequential_IO and Text_IO, and the introduction of several new declarations in Text_IO, may result in name clashes in the presence of use clauses. Extensions to Ada 83 0.b Text_IO enhancements (Get_Immediate, Look_Ahead, Standard_ Error, Modular_IO, Decimal_IO), Wide_Text_IO, and the stream input-output facilities are new in Ada 9X. Wording Changes From Ada 83 0.c RM83-14.6, "Low Level Input-Output," is removed. This has no semantic effect, since the package was entirely implementation defined, nobody actually implemented it, and if they did, they can always provide it as a vendor-supplied package. A.7 External Files and File Objects A.8 Sequential and Direct Files A.8.1 The Generic Package Sequential_IO Incompatibilities With Ada 83 0.a The new enumeration element Append_File may introduce upward incompatibilities. It is possible that a program based on the assumption that File_Mode'Last = Out_File will be illegal (e.g., case statement choice coverage) or execute with a different effect in Ada 9X. A.8.2 File Management A.8.3 Sequential Input-Output Operations A.8.4 The Generic Package Direct_IO A.8.5 Direct Input-Output Operations A.9 The Generic Package Storage_IO A.10 Text Input-Output Extensions to Ada 83 0.a Append_File is new in Ada 9X. A.10.1 The Package Text_IO Incompatibilities With Ada 83 0.a Append_File is a new element of enumeration type File_Mode. Extensions to Ada 83 0.b Get_Immediate, Look_Ahead, the subprograms for dealing with standard error, the type File_Access and its associated subprograms, and the generic packages Modular_IO and Decimal_IO are new in Ada 9X. A.10.2 Text File Management A.10.3 Default Input, Output, and Error Files A.10.4 Specification of Line and Page Lengths A.10.5 Operations on Columns, Lines, and Pages A.10.6 Get and Put Procedures A.10.7 Input-Output of Characters and Strings A.10.8 Input-Output for Integer Types A.10.9 Input-Output for Real Types A.10.10 Input-Output for Enumeration Types A.11 Wide Text Input-Output Extensions to Ada 83 0.a Support for Wide_Character and Wide_String I/O is new in Ada 9X. A.12 Stream Input-Output A.12.1 The Package Streams.Stream_IO A.12.2 The Package Text_IO.Text_Streams A.12.3 The Package Wide_Text_IO.Text_Streams A.13 Exceptions in Input-Output A.14 File Sharing A.15 The Package Command_Line Extensions to Ada 83 0.a This clause is new in Ada 9X. Annex B (normative) Interface to Other Languages Extensions to Ada 83 0.a Much of the functionality in this Annex is new to Ada 9X. Wording Changes From Ada 83 0.b This Annex contains what used to be RM83-13.8. B.1 Interfacing Pragmas Extensions to Ada 83 0.a Interfacing pragmas are new to Ada 9X. Pragma Import replaces Ada 83's pragma Interface. Existing implementations can continue to support pragma Interface for upward compatibility. B.2 The Package Interfaces B.3 Interfacing with C B.3.1 The Package Interfaces.C.Strings B.3.2 The Generic Package Interfaces.C.Pointers B.4 Interfacing with COBOL B.5 Interfacing with Fortran Annex C (normative) Systems Programming Extensions to Ada 83 0.a This Annex is new to Ada 9X. C.1 Access to Machine Operations C.2 Required Representation Support C.3 Interrupt Support C.3.1 Protected Procedure Handlers C.3.2 The Package Interrupts C.4 Preelaboration Requirements C.5 Pragma Discard_Names C.6 Shared Variable Control Incompatibilities With Ada 83 0.a Pragma Atomic replaces Ada 83's pragma Shared. The name ``Shared'' was confusing, because the pragma was not used to mark variables as shared. C.7 Task Identification and Attributes C.7.1 The Package Task_Identification C.7.2 The Package Task_Attributes Annex D (normative) Real-Time Systems Extensions to Ada 83 0.a This Annex is new to Ada 9X. D.1 Task Priorities Extensions to Ada 83 0.a The priority of a task is per-object and not per-type. 0.b Priorities need not be static anymore (except for the main subprogram). Wording Changes From Ada 83 0.c The description of the Priority pragma has been moved to this annex. D.2 Priority Scheduling D.2.1 The Task Dispatching Model D.2.2 The Standard Task Dispatching Policy D.3 Priority Ceiling Locking D.4 Entry Queuing Policies D.5 Dynamic Priorities D.6 Preemptive Abort D.7 Tasking Restrictions D.8 Monotonic Time D.9 Delay Accuracy Wording Changes From Ada 83 0.a The rules regarding a timed_entry_call with a very small positive Duration value, have been tightened to always require the check whether the rendezvous is immediately possible. D.10 Synchronous Task Control D.11 Asynchronous Task Control D.12 Other Optimizations and Determinism Rules Annex E (normative) Distributed Systems Extensions to Ada 83 0.a This Annex is new to Ada 9X. E.1 Partitions E.2 Categorization of Library Units E.2.1 Shared Passive Library Units E.2.2 Remote Types Library Units E.2.3 Remote Call Interface Library Units E.3 Consistency of a Distributed System E.4 Remote Subprogram Calls E.4.1 Pragma Asynchronous E.4.2 Example of Use of a Remote Access-to-Class-Wide Type E.5 Partition Communication Subsystem Annex F (normative) Information Systems Extensions to Ada 83 0.a This Annex is new to Ada 9X. F.1 Machine_Radix Attribute Definition Clause F.2 The Package Decimal F.3 Edited Output for Decimal Types F.3.1 Picture String Formation F.3.2 Edited Output Generation F.3.3 The Package Text_IO.Editing F.3.4 The Package Wide_Text_IO.Editing Annex G (normative) Numerics Extensions to Ada 83 0.a This Annex is new to Ada 9X. G.1 Complex Arithmetic G.1.1 Complex Types Wording Changes From Ada 83 0.a The semantics of Numerics.Generic_Complex_Types differs from Generic_Complex_Types as defined in ISO/IEC CD 13813 (for Ada 83) in the following ways: 0.b The generic package is a child of the package defining the Argument_Error exception. 0.c The nongeneric equivalents export types and constants with the same names as those exported by the generic package, rather than with names unique to the package. 0.d Implementations are not allowed to impose an optional restriction that the generic actual parameter associated with Real be unconstrained. (In view of the ability to declare variables of subtype Real'Base in implementations of Numerics.Generic_Complex_Types, this flexibility is no longer needed.) 0.e The dependence of the Argument function on the sign of a zero parameter component is tied to the value of Real'Signed_Zeros. 0.f Conformance to accuracy requirements is conditional. G.1.2 Complex Elementary Functions Wording Changes From Ada 83 0.a The semantics of Numerics.Generic_Complex_Elementary_Functions differs from Generic_Complex_Elementary_Functions as defined in ISO/IEC CD 13814 (for Ada 83) in the following ways: 0.b The generic package is a child unit of the package defining the Argument_Error exception. 0.c The proposed Generic_Complex_Elementary_Functions stan- dard (for Ada 83) specified names for the nongeneric equivalents, if provided. Here, those nongeneric equivalents are required. 0.d The generic package imports an instance of Numerics.- Generic_Complex_Types rather than a long list of individual types and operations exported by such an instance. 0.e The dependence of the imaginary component of the Sqrt and Log functions on the sign of a zero parameter component is tied to the value of Complex_Types.Real'Signed_Zeros. 0.f Conformance to accuracy requirements is conditional. G.1.3 Complex Input-Output G.1.4 The Package Wide_Text_IO.Complex_IO G.2 Numeric Performance Requirements Extensions to Ada 83 0.a The choice between strict and relaxed numeric performance was not available in Ada 83. G.2.1 Model of Floating Point Arithmetic Wording Changes From Ada 83 0.a The Ada 9X model numbers of a floating point type that are in the safe range of the type are comparable to the Ada 83 safe numbers of the type. There is no analog of the Ada 83 model numbers. The Ada 9X model numbers, when not restricted to the safe range, are an infinite set. Inconsistencies With Ada 83 0.b Giving the model numbers the hardware radix, instead of always a radix of two, allows (in conjunction with other changes) some borderline declared types to be represented with less precision than in Ada 83 (i.e., with single precision, whereas Ada 83 would have used double precision). Because the lower precision satisfies the requirements of the model (and did so in Ada 83 as well), this change is viewed as a desirable correction of an anomaly, rather than a worrisome inconsistency. (Of course, the wider representation chosen in Ada 83 also remains eligible for selection in Ada 9X.) 0.c As an example of this phenomenon, assume that Float is represented in single precision and that a double precision type is also available. Also assume hexadecimal hardware with clean properties, for example certain IBM hardware. Then, 0.d type T is digits Float'Digits range -Float'Last .. Float'Last; 0.e results in T being represented in double precision in Ada 83 and in single precision in Ada 9X. The latter is intuitively correct; the former is counterintuitive. The reason why the double precision type is used in Ada 83 is that Float has model and safe numbers (in Ada 83) with 21 binary digits in their mantissas, as is required to model the hypothesized hexadecimal hardware using a binary radix; thus Float'Last, which is not a model number, is slightly outside the range of safe numbers of the single precision type, making that type ineligible for selection as the representation of T even though it provides adequate precision. In Ada 9X, Float'Last (the same value as before) is a model number and is in the safe range of Float on the hypothesized hardware, making Float eligible for the representation of T. Extensions to Ada 83 0.f Giving the model numbers the hardware radix allows for practical implementations on decimal hardware. Wording Changes From Ada 83 0.g The wording of the model of floating point arithmetic has been simplified to a large extent. G.2.2 Model-Oriented Attributes of Floating Point Types G.2.3 Model of Fixed Point Arithmetic Inconsistencies With Ada 83 0.a Since the values of a fixed point type are now just the integer multiples of its small, the possibility of using extra bits available in the chosen representation for extra accuracy rather than for increasing the base range would appear to be removed, raising the possibility that some fixed point expressions will yield less accurate results than in Ada 83. However, this is partially offset by the ability of an implementation to choose a smaller default small than before. Of course, if it does so for a type T then T'Small will have a different value than it previously had. 0.b The accuracy requirements in the case of incompatible smalls are relaxed to foster wider support for non-binary smalls. If this relaxation is exploited for a type that was previously supported, lower accuracy could result; however, there is no particular incentive to exploit the relaxation in such a case. Wording Changes From Ada 83 0.c The fixed point accuracy requirements are now expressed without reference to model or safe numbers, largely because the full generality of the former model was never exploited in the case of fixed point types (particularly in regard to operand perturbation). Although the new formulation in terms of perfect result sets and close result sets is still verbose, it can be seen to distill down to two cases: 0.d a case where the result must be the exact result, if the exact result is representable, or, if not, then either one of the adjacent values of the type (in some subcases only one of those adjacent values is allowed); 0.e a case where the accuracy is not specified by the language. G.2.4 Accuracy Requirements for the Elementary Functions Wording Changes From Ada 83 0.a The semantics of Numerics.Generic_Elementary_Functions differs from Generic_Elementary_Functions as defined in ISO/IEC DIS 11430 (for Ada 83) in the following ways related to the accuracy specified for strict mode: 0.b The maximum relative error bounds use the Model_Epsilon attribute instead of the Base'Epsilon attribute. 0.c The accuracy requirements are expressed in terms of result intervals that are model intervals. On the one hand, this facilitates the description of the required results in the presence of underflow; on the other hand, it slightly relaxes the requirements expressed in ISO/IEC DIS 11430. G.2.5 Performance Requirements for Random Number Generation G.2.6 Accuracy Requirements for Complex Arithmetic Wording Changes From Ada 83 0.a The semantics of Numerics.Generic_Complex_Types and Numerics.- Generic_Complex_Elementary_Functions differs from Generic_Complex_ Types and Generic_Complex_Elementary_Functions as defined in ISO/IEC CDs 13813 and 13814 (for Ada 83) in ways analogous to those identified for the elementary functions in G.2.4. In addition, we do not generally specify the signs of zero results (or result components), although those proposed standards do. Annex H (normative) Safety and Security Extensions to Ada 83 0.a This Annex is new to Ada 9X. H.1 Pragma Normalize_Scalars H.2 Documentation of Implementation Decisions H.3 Reviewable Object Code H.3.1 Pragma Reviewable The implementation shall provide control- and data-flow information, both within each compilation unit and across the compilation units of the partition. H.3.2 Pragma Inspection_Point H.4 Safety and Security Restrictions Annex J (normative) Obsolescent Features Wording Changes From Ada 83 0.a The following features have been removed from the language, rather than declared to be obsolescent: 0.b The package Low_Level_IO (see A.6). 0.c The Epsilon, Mantissa, Emax, Small, Large, Safe_Emax, Safe_Small, and Safe_Large attributes of floating point types (see A.5.3). 0.d The pragma Interface (see B.1). 0.e The pragmas System_Name, Storage_Unit, and Memory_Size (see 13.7). 0.f The pragma Shared (see C.6). 0.g Implementations can continue to support the above features for upward compatibility. J.1 Renamings of Ada 83 Library Units J.2 Allowed Replacements of Characters J.3 Reduced Accuracy Subtypes Wording Changes From Ada 83 0.a In Ada 83, a delta_constraint is called a fixed_point_ constraint, and a digits_constraint is called a floating_point_ constraint. We have adopted other terms because digits_constraints apply primarily to decimal fixed point types now (they apply to floating point types only as an obsolescent feature). J.4 The Constrained Attribute J.5 ASCII J.6 Numeric_Error J.7 At Clauses Extensions to Ada 83 0.a We now allow to define the address of an entity using an attribute_definition_clause. This is because Ada 83's at_clause is so hard to remember: programmers often tend to write ``for X'Address use...;''. Wording Changes From Ada 83 0.b Ada 83's address_clause is now called an at_clause to avoid confusion with the new term ``Address clause'' (that is, an attribute_definition_clause for the Address attribute). J.7.1 Interrupt Entries Wording Changes From Ada 83 0.a RM83-13.5.1 did not adequately address the problems associate with interrupts. This feature is now obsolescent and is replaced by the Ada 9X interrupt model as specified in the Systems Programming Annex. J.8 Mod Clauses Wording Changes From Ada 83 0.a Ada 83's alignment_clause is now called a mod_clause to avoid confusion with the new term ``Alignment clause'' (that is, an attribute_definition_clause for the Alignment attribute). J.9 The Storage_Size Attribute Annex K (informative) Language-Defined Attributes Annex L (informative) Language-Defined Pragmas Wording Changes From Ada 83 0.a Pragmas List, Page, and Optimize are now officially defined in 2.8, ``Pragmas''. Annex M (informative) Implementation-Defined Characteristics Annex N (informative) Glossary Annex P (informative) Syntax Summary SYNTAX CROSS REFERENCE 1 Index Index entries are given by paragraph number. A list of all language-defined library units may be found under Language-Defined Library Units. A list of all language-defined types may be found under Language-Defined Types. A 8.6(0), 13.14(0) Backus-Naur Form (BNF) cross reference P(0) Bad 4.9(0) Beaujolais effect [partial] 8.6(0) BNF (Backus-Naur Form) cross reference P(0) Constraint_Error raised by failure of run-time check 1.1.5(0) context free grammar cross reference P(0) extensions to Ada 83 1.1.2(0), 2.1(0), 2.8(0), 3.2.3(0), 3.3(0), 3.3.1(0), 3.3.2(0), 3.4(0), 3.5(0), 3.5.2(0), 3.5.4(0), 3.5.5(0), 3.5.9(0), 3.6(0), 3.6.1(0), 3.6.3(0), 3.7(0), 3.7.2(0), 3.8(0), 3.8.1(0), 3.9(0), 3.9.1(0), 3.9.2(0), 3.10(0), 3.10.1(0), 3.10.2(0), 3.11(0), 4.1(0), 4.1.3(0), 4.1.4(0), 4.2(0), 4.3(0), 4.3.1(0), 4.3.2(0), 4.3.3(0), 4.4(0), 4.5.2(0), 4.5.3(0), 4.5.5(0), 4.6(0), 4.8(0), 4.9(0), 5.1(0), 5.2(0), 5.4(0), 6.1(0), 6.2(0), 6.3(0), 6.3.1(0), 6.3.2(0), 6.4.1(0), 6.6(0), 7.3(0), 7.4(0), 7.5(0), 7.6(0), 8.2(0), 8.3(0), 8.4(0), 8.5.5(0), 8.6(0), 9.1(0), 9.4(0), 9.5.2(0), 9.5.4(0), 9.6(0), 9.7(0), 9.7.4(0), 10.1.1(0), 10.1.2(0), 10.1.3(0), 10.2(0), 10.2.1(0), 11.2(0), 11.4.1(0), 11.5(0), 12.1(0), 12.3(0), 12.4(0), 12.5.4(0), 12.7(0), 13.1(0), 13.3(0), 13.4(0), 13.5.3(0), 13.8(0), 13.9.2(0), 13.11(0), 13.12(0), 13.13(0), 13.14(0), A.1(0), A.2(0), A.3(0), A.4(0), A.5(0), A.5.3(0), A.5.4(0), A.6(0), A.10(0), A.10.1(0), A.11(0), A.15(0), B(0), B.1(0), C(0), D(0), D.1(0), E(0), F(0), G(0), G.2(0), G.2.1(0), H(0), J.7(0) F 3.4(0), 5.4(0), 8.6(0) grammar cross reference P(0) incompatibilities with Ada 83 1.1.2(0), 2.8(0), 2.9(0), 3.2.2(0), 3.2.3(0), 3.4(0), 3.5(0), 3.5.2(0), 3.6.3(0), 4.2(0), 4.6(0), 4.8(0), 4.9(0), 6.5(0), 7.1(0), 8.6(0), 12.3(0), 12.5.1(0), 12.5.3(0), 12.5.4(0), 13.1(0), 13.14(0), A.5.3(0), A.5.4(0), A.8.1(0), A.10.1(0), C.6(0) inconsistencies with Ada 83 1.1.2(0), 3.4(0), 3.5.2(0), 3.5.7(0), 3.5.9(0), 3.6.3(0), 3.7.1(0), 4.5.3(0), 9.6(0), 11.1(0), 12.3(0), A.6(0), G.2.1(0), G.2.3(0) Inner 13.14(0) library unit See also language-defined library units NT 3.4(0) Outer 13.14(0) P 3.4(0) Pack 3.10.1(0) Pack.Child 3.10.1(0) predefined library unit See language-defined library units predefined type See language-defined types Pri 3.10.1(0) Program_Error raised by failure of run-time check 1.1.5(0) Q 8.2(0) R 8.2(0) record_aggregate used 13.8(0) S 5.4(0), 13.14(0) Sep 3.10.1(0) Short_Int 4.9(0) subtype_mark used 13.8(0) syntax cross reference P(0) T 3.4(0), 8.6(0), 13.14(0), G.2.1(0) T2 13.14(0) type See also language-defined types wording changes from Ada 83 1.1.2(0) X 8.2(0) Contents Foreword................................................................ 0 1. General.............................................................. 0 1.1 Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 0 1.1.1 Extent . . . . . . . . . . . . . . . . . . . . . . . . . . 0 1.1.2 Structure . . . . . . . . . . . . . . . . . . . . . . . . . 0 1.1.3 Conformity of an Implementation with the Standard . . . . . 0 1.1.4 Method of Description and Syntax Notation . . . . . . . . . 0 1.1.5 Classification of Errors . . . . . . . . . . . . . . . . . 0 1.2 Normative References . . . . . . . . . . . . . . . . . . . . . . 0 1.3 Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . 0 2. Lexical Elements..................................................... 0 2.1 Character Set . . . . . . . . . . . . . . . . . . . . . . . . . . 0 2.2 Lexical Elements, Separators, and Delimiters . . . . . . . . . . 0 2.3 Identifiers . . . . . . . . . . . . . . . . . . . . . . . . . . . 0 2.4 Numeric Literals . . . . . . . . . . . . . . . . . . . . . . . . 1 2.4.1 Decimal Literals . . . . . . . . . . . . . . . . . . . . . 1 2.4.2 Based Literals . . . . . . . . . . . . . . . . . . . . . . 1 2.5 Character Literals . . . . . . . . . . . . . . . . . . . . . . . 1 2.6 String Literals . . . . . . . . . . . . . . . . . . . . . . . . . 1 2.7 Comments . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 2.8 Pragmas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 2.9 Reserved Words . . . . . . . . . . . . . . . . . . . . . . . . . 2 3. Declarations and Types............................................... 2 3.1 Declarations . . . . . . . . . . . . . . . . . . . . . . . . . . 2 3.2 Types and Subtypes . . . . . . . . . . . . . . . . . . . . . . . 2 3.2.1 Type Declarations . . . . . . . . . . . . . . . . . . . . . 2 3.2.2 Subtype Declarations . . . . . . . . . . . . . . . . . . . 2 3.2.3 Classification of Operations . . . . . . . . . . . . . . . 2 3.3 Objects and Named Numbers . . . . . . . . . . . . . . . . . . . . 2 3.3.1 Object Declarations . . . . . . . . . . . . . . . . . . . . 3 3.3.2 Number Declarations . . . . . . . . . . . . . . . . . . . . 3 3.4 Derived Types and Classes . . . . . . . . . . . . . . . . . . . . 3 3.4.1 Derivation Classes . . . . . . . . . . . . . . . . . . . . 3 3.5 Scalar Types . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3.5.1 Enumeration Types . . . . . . . . . . . . . . . . . . . . . 4 3.5.2 Character Types . . . . . . . . . . . . . . . . . . . . . . 4 3.5.3 Boolean Types . . . . . . . . . . . . . . . . . . . . . . . 4 3.5.4 Integer Types . . . . . . . . . . . . . . . . . . . . . . . 4 3.5.5 Operations of Discrete Types . . . . . . . . . . . . . . . 4 3.5.6 Real Types . . . . . . . . . . . . . . . . . . . . . . . . 4 3.5.7 Floating Point Types . . . . . . . . . . . . . . . . . . . 4 3.5.8 Operations of Floating Point Types . . . . . . . . . . . . 4 3.5.9 Fixed Point Types . . . . . . . . . . . . . . . . . . . . . 4 3.5.10 Operations of Fixed Point Types . . . . . . . . . . . . . 5 3.6 Array Types . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.6.1 Index Constraints and Discrete Ranges . . . . . . . . . . . 5 3.6.2 Operations of Array Types . . . . . . . . . . . . . . . . . 5 3.6.3 String Types . . . . . . . . . . . . . . . . . . . . . . . 5 3.7 Discriminants . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.7.1 Discriminant Constraints . . . . . . . . . . . . . . . . . 5 3.7.2 Operations of Discriminated Types . . . . . . . . . . . . . 5 3.8 Record Types . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.8.1 Variant Parts and Discrete Choices . . . . . . . . . . . . 6 3.9 Tagged Types and Type Extensions . . . . . . . . . . . . . . . . 6 3.9.1 Type Extensions . . . . . . . . . . . . . . . . . . . . . . 6 3.9.2 Dispatching Operations of Tagged Types . . . . . . . . . . 6 3.9.3 Abstract Types and Subprograms . . . . . . . . . . . . . . 6 3.10 Access Types . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.10.1 Incomplete Type Declarations . . . . . . . . . . . . . . . 6 3.10.2 Operations of Access Types . . . . . . . . . . . . . . . . 6 3.11 Declarative Parts . . . . . . . . . . . . . . . . . . . . . . . 6 3.11.1 Completions of Declarations . . . . . . . . . . . . . . . 6 4. Names and Expressions................................................ 7 4.1 Names . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 4.1.1 Indexed Components . . . . . . . . . . . . . . . . . . . . 7 4.1.2 Slices . . . . . . . . . . . . . . . . . . . . . . . . . . 7 4.1.3 Selected Components . . . . . . . . . . . . . . . . . . . . 7 4.1.4 Attributes . . . . . . . . . . . . . . . . . . . . . . . . 7 4.2 Literals . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 4.3 Aggregates . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 4.3.1 Record Aggregates . . . . . . . . . . . . . . . . . . . . . 7 4.3.2 Extension Aggregates . . . . . . . . . . . . . . . . . . . 8 4.3.3 Array Aggregates . . . . . . . . . . . . . . . . . . . . . 8 4.4 Expressions . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 4.5 Operators and Expression Evaluation . . . . . . . . . . . . . . . 8 4.5.1 Logical Operators and Short-circuit Control Forms . . . . . 8 4.5.2 Relational Operators and Membership Tests . . . . . . . . . 8 4.5.3 Binary Adding Operators . . . . . . . . . . . . . . . . . . 8 4.5.4 Unary Adding Operators . . . . . . . . . . . . . . . . . . 8 4.5.5 Multiplying Operators . . . . . . . . . . . . . . . . . . . 8 4.5.6 Highest Precedence Operators . . . . . . . . . . . . . . . 8 4.6 Type Conversions . . . . . . . . . . . . . . . . . . . . . . . . 8 4.7 Qualified Expressions . . . . . . . . . . . . . . . . . . . . . . 9 4.8 Allocators . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 4.9 Static Expressions and Static Subtypes . . . . . . . . . . . . . 9 4.9.1 Statically Matching Constraints and Subtypes . . . . . . . 9 5. Statements........................................................... 9 5.1 Simple and Compound Statements - Sequences of Statements . . . . 9 5.2 Assignment Statements . . . . . . . . . . . . . . . . . . . . . . 10 5.3 If Statements . . . . . . . . . . . . . . . . . . . . . . . . . . 10 5.4 Case Statements . . . . . . . . . . . . . . . . . . . . . . . . . 10 5.5 Loop Statements . . . . . . . . . . . . . . . . . . . . . . . . . 10 5.6 Block Statements . . . . . . . . . . . . . . . . . . . . . . . . 10 5.7 Exit Statements . . . . . . . . . . . . . . . . . . . . . . . . . 10 5.8 Goto Statements . . . . . . . . . . . . . . . . . . . . . . . . . 10 6. Subprograms.......................................................... 10 6.1 Subprogram Declarations . . . . . . . . . . . . . . . . . . . . . 10 6.2 Formal Parameter Modes . . . . . . . . . . . . . . . . . . . . . 10 6.3 Subprogram Bodies . . . . . . . . . . . . . . . . . . . . . . . . 10 6.3.1 Conformance Rules . . . . . . . . . . . . . . . . . . . . . 10 6.3.2 Inline Expansion of Subprograms . . . . . . . . . . . . . . 10 6.4 Subprogram Calls . . . . . . . . . . . . . . . . . . . . . . . . 11 6.4.1 Parameter Associations . . . . . . . . . . . . . . . . . . 11 6.5 Return Statements . . . . . . . . . . . . . . . . . . . . . . . . 11 6.6 Overloading of Operators . . . . . . . . . . . . . . . . . . . . 11 7. Packages............................................................. 11 7.1 Package Specifications and Declarations . . . . . . . . . . . . . 11 7.2 Package Bodies . . . . . . . . . . . . . . . . . . . . . . . . . 11 7.3 Private Types and Private Extensions . . . . . . . . . . . . . . 11 7.3.1 Private Operations . . . . . . . . . . . . . . . . . . . . 11 7.4 Deferred Constants . . . . . . . . . . . . . . . . . . . . . . . 11 7.5 Limited Types . . . . . . . . . . . . . . . . . . . . . . . . . . 12 7.6 User-Defined Assignment and Finalization . . . . . . . . . . . . 12 7.6.1 Completion and Finalization . . . . . . . . . . . . . . . . 12 8. Visibility Rules..................................................... 12 8.1 Declarative Region . . . . . . . . . . . . . . . . . . . . . . . 12 8.2 Scope of Declarations . . . . . . . . . . . . . . . . . . . . . . 12 8.3 Visibility . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 8.4 Use Clauses . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 8.5 Renaming Declarations . . . . . . . . . . . . . . . . . . . . . . 13 8.5.1 Object Renaming Declarations . . . . . . . . . . . . . . . 13 8.5.2 Exception Renaming Declarations . . . . . . . . . . . . . . 13 8.5.3 Package Renaming Declarations . . . . . . . . . . . . . . . 13 8.5.4 Subprogram Renaming Declarations . . . . . . . . . . . . . 13 8.5.5 Generic Renaming Declarations . . . . . . . . . . . . . . . 13 8.6 The Context of Overload Resolution . . . . . . . . . . . . . . . 13 9. Tasks and Synchronization............................................ 14 9.1 Task Units and Task Objects . . . . . . . . . . . . . . . . . . . 14 9.2 Task Execution - Task Activation . . . . . . . . . . . . . . . . 14 9.3 Task Dependence - Termination of Tasks . . . . . . . . . . . . . 14 9.4 Protected Units and Protected Objects . . . . . . . . . . . . . . 14 9.5 Intertask Communication . . . . . . . . . . . . . . . . . . . . . 14 9.5.1 Protected Subprograms and Protected Actions . . . . . . . . 14 9.5.2 Entries and Accept Statements . . . . . . . . . . . . . . . 14 9.5.3 Entry Calls . . . . . . . . . . . . . . . . . . . . . . . . 14 9.5.4 Requeue Statements . . . . . . . . . . . . . . . . . . . . 14 9.6 Delay Statements, Duration, and Time . . . . . . . . . . . . . . 14 9.7 Select Statements . . . . . . . . . . . . . . . . . . . . . . . . 14 9.7.1 Selective Accept . . . . . . . . . . . . . . . . . . . . . 14 9.7.2 Timed Entry Calls . . . . . . . . . . . . . . . . . . . . . 14 9.7.3 Conditional Entry Calls . . . . . . . . . . . . . . . . . . 14 9.7.4 Asynchronous Transfer of Control . . . . . . . . . . . . . 15 9.8 Abort of a Task - Abort of a Sequence of Statements . . . . . . . 15 9.9 Task and Entry Attributes . . . . . . . . . . . . . . . . . . . . 15 9.10 Shared Variables . . . . . . . . . . . . . . . . . . . . . . . . 15 9.11 Example of Tasking and Synchronization . . . . . . . . . . . . . 15 10. Program Structure and Compilation Issues............................ 15 10.1 Separate Compilation . . . . . . . . . . . . . . . . . . . . . . 15 10.1.1 Compilation Units - Library Units . . . . . . . . . . . . 15 10.1.2 Context Clauses - With Clauses . . . . . . . . . . . . . . 15 10.1.3 Subunits of Compilation Units . . . . . . . . . . . . . . 15 10.1.4 The Compilation Process . . . . . . . . . . . . . . . . . 15 10.1.5 Pragmas and Program Units . . . . . . . . . . . . . . . . 15 10.1.6 Environment-Level Visibility Rules . . . . . . . . . . . . 15 10.2 Program Execution . . . . . . . . . . . . . . . . . . . . . . . 16 10.2.1 Elaboration Control . . . . . . . . . . . . . . . . . . . 16 11. Exceptions.......................................................... 16 11.1 Exception Declarations . . . . . . . . . . . . . . . . . . . . . 16 11.2 Exception Handlers . . . . . . . . . . . . . . . . . . . . . . . 16 11.3 Raise Statements . . . . . . . . . . . . . . . . . . . . . . . . 16 11.4 Exception Handling . . . . . . . . . . . . . . . . . . . . . . . 16 11.4.1 The Package Exceptions . . . . . . . . . . . . . . . . . . 16 11.4.2 Example of Exception Handling . . . . . . . . . . . . . . 16 11.5 Suppressing Checks . . . . . . . . . . . . . . . . . . . . . . . 16 11.6 Exceptions and Optimization . . . . . . . . . . . . . . . . . . 16 12. Generic Units....................................................... 17 12.1 Generic Declarations . . . . . . . . . . . . . . . . . . . . . . 17 12.2 Generic Bodies . . . . . . . . . . . . . . . . . . . . . . . . . 17 12.3 Generic Instantiation . . . . . . . . . . . . . . . . . . . . . 17 12.4 Formal Objects . . . . . . . . . . . . . . . . . . . . . . . . . 17 12.5 Formal Types . . . . . . . . . . . . . . . . . . . . . . . . . . 17 12.5.1 Formal Private and Derived Types . . . . . . . . . . . . . 17 12.5.2 Formal Scalar Types . . . . . . . . . . . . . . . . . . . 17 12.5.3 Formal Array Types . . . . . . . . . . . . . . . . . . . . 17 12.5.4 Formal Access Types . . . . . . . . . . . . . . . . . . . 18 12.6 Formal Subprograms . . . . . . . . . . . . . . . . . . . . . . . 18 12.7 Formal Packages . . . . . . . . . . . . . . . . . . . . . . . . 18 12.8 Example of a Generic Package . . . . . . . . . . . . . . . . . . 18 13. Representation Issues............................................... 18 13.1 Representation Items . . . . . . . . . . . . . . . . . . . . . . 18 13.2 Pragma Pack . . . . . . . . . . . . . . . . . . . . . . . . . . 18 13.3 Representation Attributes . . . . . . . . . . . . . . . . . . . 18 13.4 Enumeration Representation Clauses . . . . . . . . . . . . . . . 18 13.5 Record Layout . . . . . . . . . . . . . . . . . . . . . . . . . 18 13.5.1 Record Representation Clauses . . . . . . . . . . . . . . 18 13.5.2 Storage Place Attributes . . . . . . . . . . . . . . . . . 18 13.5.3 Bit Ordering . . . . . . . . . . . . . . . . . . . . . . . 18 13.6 Change of Representation . . . . . . . . . . . . . . . . . . . . 18 13.7 The Package System . . . . . . . . . . . . . . . . . . . . . . . 19 13.7.1 The Package System.Storage_Elements . . . . . . . . . . . 19 13.7.2 The Package System.Address_To_Access_Conversions . . . . . 19 13.8 Machine Code Insertions . . . . . . . . . . . . . . . . . . . . 19 13.9 Unchecked Type Conversions . . . . . . . . . . . . . . . . . . . 19 13.9.1 Data Validity . . . . . . . . . . . . . . . . . . . . . . 19 13.9.2 The Valid Attribute . . . . . . . . . . . . . . . . . . . 19 13.10 Unchecked Access Value Creation . . . . . . . . . . . . . . . . 19 13.11 Storage Management . . . . . . . . . . . . . . . . . . . . . . 19 13.11.1 The Max_Size_In_Storage_Elements Attribute . . . . . . . 19 13.11.2 Unchecked Storage Deallocation . . . . . . . . . . . . . 19 13.11.3 Pragma Controlled . . . . . . . . . . . . . . . . . . . . 19 13.12 Pragma Restrictions . . . . . . . . . . . . . . . . . . . . . . 19 13.13 Streams . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 13.13.1 The Package Streams . . . . . . . . . . . . . . . . . . . 19 13.13.2 Stream-Oriented Attributes . . . . . . . . . . . . . . . 19 13.14 Freezing Rules . . . . . . . . . . . . . . . . . . . . . . . . 19 ANNEXES A. Predefined Language Environment...................................... 20 A.1 The Package Standard . . . . . . . . . . . . . . . . . . . . . . 20 A.2 The Package Ada . . . . . . . . . . . . . . . . . . . . . . . . . 20 A.3 Character Handling . . . . . . . . . . . . . . . . . . . . . . . 20 A.3.1 The Package Characters . . . . . . . . . . . . . . . . . . 20 A.3.2 The Package Characters.Handling . . . . . . . . . . . . . . 20 A.3.3 The Package Characters.Latin_1 . . . . . . . . . . . . . . 20 A.4 String Handling . . . . . . . . . . . . . . . . . . . . . . . . . 20 A.4.1 The Package Strings . . . . . . . . . . . . . . . . . . . . 20 A.4.2 The Package Strings.Maps . . . . . . . . . . . . . . . . . 20 A.4.3 Fixed-Length String Handling . . . . . . . . . . . . . . . 20 A.4.4 Bounded-Length String Handling . . . . . . . . . . . . . . 20 A.4.5 Unbounded-Length String Handling . . . . . . . . . . . . . 20 A.4.6 String-Handling Sets and Mappings . . . . . . . . . . . . . 20 A.4.7 Wide_String Handling . . . . . . . . . . . . . . . . . . . 20 A.5 The Numerics Packages . . . . . . . . . . . . . . . . . . . . . . 20 A.5.1 Elementary Functions . . . . . . . . . . . . . . . . . . . 20 A.5.2 Random Number Generation . . . . . . . . . . . . . . . . . 21 A.5.3 Attributes of Floating Point Types . . . . . . . . . . . . 21 A.5.4 Attributes of Fixed Point Types . . . . . . . . . . . . . . 21 A.6 Input-Output . . . . . . . . . . . . . . . . . . . . . . . . . . 21 A.7 External Files and File Objects . . . . . . . . . . . . . . . . . 21 A.8 Sequential and Direct Files . . . . . . . . . . . . . . . . . . . 21 A.8.1 The Generic Package Sequential_IO . . . . . . . . . . . . . 21 A.8.2 File Management . . . . . . . . . . . . . . . . . . . . . . 21 A.8.3 Sequential Input-Output Operations . . . . . . . . . . . . 21 A.8.4 The Generic Package Direct_IO . . . . . . . . . . . . . . . 21 A.8.5 Direct Input-Output Operations . . . . . . . . . . . . . . 21 A.9 The Generic Package Storage_IO . . . . . . . . . . . . . . . . . 21 A.10 Text Input-Output . . . . . . . . . . . . . . . . . . . . . . . 21 A.10.1 The Package Text_IO . . . . . . . . . . . . . . . . . . . 21 A.10.2 Text File Management . . . . . . . . . . . . . . . . . . . 21 A.10.3 Default Input, Output, and Error Files . . . . . . . . . . 21 A.10.4 Specification of Line and Page Lengths . . . . . . . . . . 21 A.10.5 Operations on Columns, Lines, and Pages . . . . . . . . . 21 A.10.6 Get and Put Procedures . . . . . . . . . . . . . . . . . . 21 A.10.7 Input-Output of Characters and Strings . . . . . . . . . . 21 A.10.8 Input-Output for Integer Types . . . . . . . . . . . . . . 21 A.10.9 Input-Output for Real Types . . . . . . . . . . . . . . . 22 A.10.10 Input-Output for Enumeration Types . . . . . . . . . . . 22 A.11 Wide Text Input-Output . . . . . . . . . . . . . . . . . . . . . 22 A.12 Stream Input-Output . . . . . . . . . . . . . . . . . . . . . . 22 A.12.1 The Package Streams.Stream_IO . . . . . . . . . . . . . . 22 A.12.2 The Package Text_IO.Text_Streams . . . . . . . . . . . . . 22 A.12.3 The Package Wide_Text_IO.Text_Streams . . . . . . . . . . 22 A.13 Exceptions in Input-Output . . . . . . . . . . . . . . . . . . . 22 A.14 File Sharing . . . . . . . . . . . . . . . . . . . . . . . . . . 22 A.15 The Package Command_Line . . . . . . . . . . . . . . . . . . . . 22 B. Interface to Other Languages......................................... 22 B.1 Interfacing Pragmas . . . . . . . . . . . . . . . . . . . . . . . 22 B.2 The Package Interfaces . . . . . . . . . . . . . . . . . . . . . 22 B.3 Interfacing with C . . . . . . . . . . . . . . . . . . . . . . . 22 B.3.1 The Package Interfaces.C.Strings . . . . . . . . . . . . . 22 B.3.2 The Generic Package Interfaces.C.Pointers . . . . . . . . . 22 B.4 Interfacing with COBOL . . . . . . . . . . . . . . . . . . . . . 22 B.5 Interfacing with Fortran . . . . . . . . . . . . . . . . . . . . 22 C. Systems Programming.................................................. 22 C.1 Access to Machine Operations . . . . . . . . . . . . . . . . . . 22 C.2 Required Representation Support . . . . . . . . . . . . . . . . . 22 C.3 Interrupt Support . . . . . . . . . . . . . . . . . . . . . . . . 22 C.3.1 Protected Procedure Handlers . . . . . . . . . . . . . . . 22 C.3.2 The Package Interrupts . . . . . . . . . . . . . . . . . . 22 C.4 Preelaboration Requirements . . . . . . . . . . . . . . . . . . . 22 C.5 Pragma Discard_Names . . . . . . . . . . . . . . . . . . . . . . 22 C.6 Shared Variable Control . . . . . . . . . . . . . . . . . . . . . 22 C.7 Task Identification and Attributes . . . . . . . . . . . . . . . 22 C.7.1 The Package Task_Identification . . . . . . . . . . . . . . 22 C.7.2 The Package Task_Attributes . . . . . . . . . . . . . . . . 22 D. Real-Time Systems.................................................... 22 D.1 Task Priorities . . . . . . . . . . . . . . . . . . . . . . . . . 22 D.2 Priority Scheduling . . . . . . . . . . . . . . . . . . . . . . . 22 D.2.1 The Task Dispatching Model . . . . . . . . . . . . . . . . 23 D.2.2 The Standard Task Dispatching Policy . . . . . . . . . . . 23 D.3 Priority Ceiling Locking . . . . . . . . . . . . . . . . . . . . 23 D.4 Entry Queuing Policies . . . . . . . . . . . . . . . . . . . . . 23 D.5 Dynamic Priorities . . . . . . . . . . . . . . . . . . . . . . . 23 D.6 Preemptive Abort . . . . . . . . . . . . . . . . . . . . . . . . 23 D.7 Tasking Restrictions . . . . . . . . . . . . . . . . . . . . . . 23 D.8 Monotonic Time . . . . . . . . . . . . . . . . . . . . . . . . . 23 D.9 Delay Accuracy . . . . . . . . . . . . . . . . . . . . . . . . . 23 D.10 Synchronous Task Control . . . . . . . . . . . . . . . . . . . . 23 D.11 Asynchronous Task Control . . . . . . . . . . . . . . . . . . . 23 D.12 Other Optimizations and Determinism Rules . . . . . . . . . . . 23 E. Distributed Systems.................................................. 23 E.1 Partitions . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 E.2 Categorization of Library Units . . . . . . . . . . . . . . . . . 23 E.2.1 Shared Passive Library Units . . . . . . . . . . . . . . . 23 E.2.2 Remote Types Library Units . . . . . . . . . . . . . . . . 23 E.2.3 Remote Call Interface Library Units . . . . . . . . . . . . 23 E.3 Consistency of a Distributed System . . . . . . . . . . . . . . . 23 E.4 Remote Subprogram Calls . . . . . . . . . . . . . . . . . . . . . 23 E.4.1 Pragma Asynchronous . . . . . . . . . . . . . . . . . . . . 23 E.4.2 Example of Use of a Remote Access-to-Class-Wide Type . . . 23 E.5 Partition Communication Subsystem . . . . . . . . . . . . . . . . 23 F. Information Systems.................................................. 23 F.1 Machine_Radix Attribute Definition Clause . . . . . . . . . . . . 23 F.2 The Package Decimal . . . . . . . . . . . . . . . . . . . . . . . 23 F.3 Edited Output for Decimal Types . . . . . . . . . . . . . . . . . 23 F.3.1 Picture String Formation . . . . . . . . . . . . . . . . . 23 F.3.2 Edited Output Generation . . . . . . . . . . . . . . . . . 23 F.3.3 The Package Text_IO.Editing . . . . . . . . . . . . . . . . 23 F.3.4 The Package Wide_Text_IO.Editing . . . . . . . . . . . . . 23 G. Numerics............................................................. 23 G.1 Complex Arithmetic . . . . . . . . . . . . . . . . . . . . . . . 23 G.1.1 Complex Types . . . . . . . . . . . . . . . . . . . . . . . 23 G.1.2 Complex Elementary Functions . . . . . . . . . . . . . . . 24 G.1.3 Complex Input-Output . . . . . . . . . . . . . . . . . . . 24 G.1.4 The Package Wide_Text_IO.Complex_IO . . . . . . . . . . . . 24 G.2 Numeric Performance Requirements . . . . . . . . . . . . . . . . 24 G.2.1 Model of Floating Point Arithmetic . . . . . . . . . . . . 24 G.2.2 Model-Oriented Attributes of Floating Point Types . . . . . 24 G.2.3 Model of Fixed Point Arithmetic . . . . . . . . . . . . . . 24 G.2.4 Accuracy Requirements for the Elementary Functions . . . . 24 G.2.5 Performance Requirements for Random Number Generation . . . 24 G.2.6 Accuracy Requirements for Complex Arithmetic . . . . . . . 24 H. Safety and Security.................................................. 24 H.1 Pragma Normalize_Scalars . . . . . . . . . . . . . . . . . . . . 25 H.2 Documentation of Implementation Decisions . . . . . . . . . . . . 25 H.3 Reviewable Object Code . . . . . . . . . . . . . . . . . . . . . 25 H.3.1 Pragma Reviewable . . . . . . . . . . . . . . . . . . . . . 25 H.3.2 Pragma Inspection_Point . . . . . . . . . . . . . . . . . . 25 H.4 Safety and Security Restrictions . . . . . . . . . . . . . . . . 25 J. Obsolescent Features................................................. 25 J.1 Renamings of Ada 83 Library Units . . . . . . . . . . . . . . . . 25 J.2 Allowed Replacements of Characters . . . . . . . . . . . . . . . 25 J.3 Reduced Accuracy Subtypes . . . . . . . . . . . . . . . . . . . . 25 J.4 The Constrained Attribute . . . . . . . . . . . . . . . . . . . . 25 J.5 ASCII . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 J.6 Numeric_Error . . . . . . . . . . . . . . . . . . . . . . . . . . 25 J.7 At Clauses . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 J.7.1 Interrupt Entries . . . . . . . . . . . . . . . . . . . . . 25 J.8 Mod Clauses . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 J.9 The Storage_Size Attribute . . . . . . . . . . . . . . . . . . . 25 K. Language-Defined Attributes.......................................... 25 L. Language-Defined Pragmas............................................. 25 M. Implementation-Defined Characteristics............................... 25 N. Glossary............................................................. 25 P. Syntax Summary....................................................... 25 Index................................................................... 27