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