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