

                                  Foreword


0.1/4 The International Standard for the programming language Ada is ISO/IEC
8652:2012(E).

0.2/4 The Ada Working Group ISO/IEC JTC 1/SC 22/WG 9 is tasked by ISO with the
work item to interpret and maintain the International Standard and to produce
Technical Corrigenda, as appropriate. The technical work on the International
Standard is performed by the Ada Rapporteur Group (ARG) of WG 9. In June 2015,
WG 9 approved and forwarded Technical Corrigendum 1 to SC 22 for ISO approval,
which was granted in December 2015. Technical Corrigendum 1 was published in
February 2016.

0.3/5 In June 2016, WG 9 approved a tentative schedule for the preparation of
an Amendment or Revision to the International Standard, with a delivery no
earlier than 2018. In July 2019, WG 9 approved an additional review and
prototyping period for this revision, extending the delivery no earlier than
late 2020. For the purposes of this document, we'll call this Ada 202x, even
though the final timing and form has not yet been determined.

0.4/4 The Technical Corrigendum lists the individual changes that need to be
made to the text of the International Standard to correct errors, omissions or
inconsistencies. The corrections specified in Technical Corrigendum 1 are part
of the International Standard ISO/IEC 8652:2012(E).

0.6/5 It is not known whether ISO will publish a document that merges the
changes of Ada 202x into the text of the International Standard. However, ISO
rules require that the project editor for the International Standard be able
to produce such a document on demand.

0.7/5 This version of the Ada Reference Manual is what the project editor
would provide to ISO in response to such a request. It incorporates the
changes specified in the Technical Corrigendum and Ada 202x into the text of
ISO/IEC 8652:2012(E). It should be understood that the publication of any ISO
document involves changes in general format, boilerplate, headers, etc., as
well as a review by professional editors that may introduce editorial changes
to the text. This version of the Ada Reference Manual is therefore neither an
official ISO document, nor a version guaranteed to be identical to an official
ISO document, should ISO decide to reprint the International Standard
incorporating an approved Technical Corrigendum and the Amendment. It is
nevertheless a best effort to be as close as possible to the technical content
of such an updated document. In the case of a conflict between this document
and Ada 202x (or between this document and Technical Corrigendum 1 as approved
by ISO in the case of paragraphs not changed by the Corrigendum; or between
this document and the original 8652:2012 in the case of paragraphs not changed
by Technical Corrigendum 1), the other documents contain the official text of
the International Standard ISO/IEC 8652:2012(E).

0.8/5 As it is very inconvenient to have the Reference Manual for Ada
specified in three documents, this consolidated version of the Ada Reference
Manual is made available to the public.


                                Introduction


1   This is the Annotated Ada Reference Manual.

1.a/5       Discussion: This document is the Annotated Ada Reference Manual
            (AARM). It contains the entire text of the Ada 202x standard
            (ISO/IEC 8652:202x), plus various annotations. It is intended
            primarily for compiler writers, validation test writers, and other
            language lawyers. The annotations include detailed rationale for
            individual rules and explanations of some of the more arcane
            interactions among the rules.

2   Other available Ada documents include:

3/3   * {AI95-00387-01} {AI05-0245-1} Ada 2012 Rationale. This gives an
        introduction to the changes and new features in Ada 2012, and explains
        the rationale behind them. Programmers should read this rationale
        before reading this Standard in depth. Rationales for Ada 83, Ada 95,
        and Ada 2005 are also available.

4/1   * This paragraph was deleted.

5/3   * The Ada Reference Manual (RM). This directly corresponds to the
        International Standard - ISO/IEC 8652:2012.

Design Goals

6/5 {AI95-00387-01} {AI12-0313-1} Ada was originally designed with three
overriding concerns: program reliability and maintenance, programming as a
human activity, and efficiency. The 1995 revision to the language was designed
to provide greater flexibility and extensibility, additional control over
storage management and synchronization, and standardized packages oriented
toward supporting important application areas, while at the same time
retaining the original emphasis on reliability, maintainability, and
efficiency. Subsequent editions, including this fourth edition, have provided
further flexibility and added more standardized packages within the framework
provided by the 1995 revision.

7   The need for languages that promote reliability and simplify maintenance
is well established. Hence emphasis was placed on program readability over
ease of writing. For example, the rules of the language require that program
variables be explicitly declared and that their type be specified. Since the
type of a variable is invariant, compilers can ensure that operations on
variables are compatible with the properties intended for objects of the type.
Furthermore, error-prone notations have been avoided, and the syntax of the
language avoids the use of encoded forms in favor of more English-like
constructs. Finally, the language offers support for separate compilation of
program units in a way that facilitates program development and maintenance,
and which provides the same degree of checking between units as within a unit.

8   Concern for the human programmer was also stressed during the design.
Above all, an attempt was made to keep to a relatively small number of
underlying concepts integrated in a consistent and systematic way while
continuing to avoid the pitfalls of excessive involution. The design
especially aims to provide language constructs that correspond intuitively to
the normal expectations of users.

9   Like many other human activities, the development of programs is becoming
ever more decentralized and distributed. Consequently, the ability to assemble
a program from independently produced software components continues to be a
central idea in the design. The concepts of packages, of private types, and of
generic units are directly related to this idea, which has ramifications in
many other aspects of the language. An allied concern is the maintenance of
programs to match changing requirements; type extension and the hierarchical
library enable a program to be modified while minimizing disturbance to
existing tested and trusted components.

10/5 {AI12-0313-1} No language can avoid the problem of efficiency. Languages
that require over-elaborate compilers, or that lead to the inefficient use of
storage or execution time, force these inefficiencies on all machines and on
all programs. Every construct of the language was examined in the light of
present implementation techniques. Any proposed construct whose implementation
was unclear or that required excessive machine resources was rejected.
Parallel constructs were introduced to simplify making safe and efficient use
of modern multicore architectures.

Language Summary

11  An Ada program is composed of one or more program units. Program units may
be subprograms (which define executable algorithms), packages (which define
collections of entities), task units (which define concurrent computations),
protected units (which define operations for the coordinated sharing of data
between tasks), or generic units (which define parameterized forms of packages
and subprograms). Each program unit normally consists of two parts: a
specification, containing the information that must be visible to other units,
and a body, containing the implementation details, which need not be visible
to other units. Most program units can be compiled separately.

12  This distinction of the specification and body, and the ability to compile
units separately, allows a program to be designed, written, and tested as a
set of largely independent software components.

13  An Ada program will normally make use of a library of program units of
general utility. The language provides means whereby individual organizations
can construct their own libraries. All libraries are structured in a
hierarchical manner; this enables the logical decomposition of a subsystem
into individual components. The text of a separately compiled program unit
must name the library units it requires.

14  Program Units

15  A subprogram is the basic unit for expressing an algorithm. There are two
kinds of subprograms: procedures and functions. A procedure is the means of
invoking a series of actions. For example, it may read data, update variables,
or produce some output. It may have parameters, to provide a controlled means
of passing information between the procedure and the point of call. A function
is the means of invoking the computation of a value. It is similar to a
procedure, but in addition will return a result.

16  A package is the basic unit for defining a collection of logically related
entities. For example, a package can be used to define a set of type
declarations and associated operations. Portions of a package can be hidden
from the user, thus allowing access only to the logical properties expressed
by the package specification.

17  Subprogram and package units may be compiled separately and arranged in
hierarchies of parent and child units giving fine control over visibility of
the logical properties and their detailed implementation.

18  A task unit is the basic unit for defining a task whose sequence of
actions may be executed concurrently with those of other tasks. Such tasks may
be implemented on multicomputers, multiprocessors, or with interleaved
execution on a single processor. A task unit may define either a single
executing task or a task type permitting the creation of any number of similar
tasks.

19/2 {AI95-00114-01} A protected unit is the basic unit for defining protected
operations for the coordinated use of data shared between tasks. Simple mutual
exclusion is provided automatically, and more elaborate sharing protocols can
be defined. A protected operation can either be a subprogram or an entry. A
protected entry specifies a Boolean expression (an entry barrier) that must be
True before the body of the entry is executed. A protected unit may define a
single protected object or a protected type permitting the creation of several
similar objects.

20  Declarations and Statements

21  The body of a program unit generally contains two parts: a declarative
part, which defines the logical entities to be used in the program unit, and a
sequence of statements, which defines the execution of the program unit.

22  The declarative part associates names with declared entities. For example,
a name may denote a type, a constant, a variable, or an exception. A
declarative part also introduces the names and parameters of other nested
subprograms, packages, task units, protected units, and generic units to be
used in the program unit.

23  The sequence of statements describes a sequence of actions that are to be
performed. The statements are executed in succession (unless a transfer of
control causes execution to continue from another place).

24  An assignment statement changes the value of a variable. A procedure call
invokes execution of a procedure after associating any actual parameters
provided at the call with the corresponding formal parameters.

25  Case statements and if statements allow the selection of an enclosed
sequence of statements based on the value of an expression or on the value of
a condition.

26  The loop statement provides the basic iterative mechanism in the language.
A loop statement specifies that a sequence of statements is to be executed
repeatedly as directed by an iteration scheme, or until an exit statement is
encountered.

27  A block statement comprises a sequence of statements preceded by the
declaration of local entities used by the statements.

28/5 {AI12-0119-1} Certain statements are associated with concurrent
execution. A delay statement delays the execution of a task for a specified
duration or until a specified time. An entry call statement is written as a
procedure call statement; it requests an operation on a task or on a protected
object, blocking the caller until the operation can be performed. A called
task may accept an entry call by executing a corresponding accept statement,
which specifies the actions then to be performed as part of the rendezvous
with the calling task. An entry call on a protected object is processed when
the corresponding entry barrier evaluates to true, whereupon the body of the
entry is executed. The requeue statement permits the provision of a service as
a number of related activities with preference control. One form of the select
statement allows a selective wait for one of several alternative rendezvous.
Other forms of the select statement allow conditional or timed entry calls and
the asynchronous transfer of control in response to some triggering event.
Various parallel constructs, including parallel loops and parallel blocks,
support the initiation of multiple logical threads of control designed to
execute in parallel when multiple processors are available.

29  Execution of a program unit may encounter error situations in which normal
program execution cannot continue. For example, an arithmetic computation may
exceed the maximum allowed value of a number, or an attempt may be made to
access an array component by using an incorrect index value. To deal with such
error situations, the statements of a program unit can be textually followed
by exception handlers that specify the actions to be taken when the error
situation arises. Exceptions can be raised explicitly by a raise statement.

30  Data Types

31  Every object in the language has a type, which characterizes a set of
values and a set of applicable operations. The main classes of types are
elementary types (comprising enumeration, numeric, and access types) and
composite types (including array and record types).

32/2 {AI95-00285-01} {AI95-00387-01} An enumeration type defines an ordered
set of distinct enumeration literals, for example a list of states or an
alphabet of characters. The enumeration types Boolean, Character,
Wide_Character, and Wide_Wide_Character are predefined.

33  Numeric types provide a means of performing exact or approximate numerical
computations. Exact computations use integer types, which denote sets of
consecutive integers. Approximate computations use either fixed point types,
with absolute bounds on the error, or floating point types, with relative
bounds on the error. The numeric types Integer, Float, and Duration are
predefined.

34/2 {AI95-00285-01} {AI95-00387-01} Composite types allow definitions of
structured objects with related components. The composite types in the
language include arrays and records. An array is an object with indexed
components of the same type. A record is an object with named components of
possibly different types. Task and protected types are also forms of composite
types. The array types String, Wide_String, and Wide_Wide_String are
predefined.

35  Record, task, and protected types may have special components called
discriminants which parameterize the type. Variant record structures that
depend on the values of discriminants can be defined within a record type.

36  Access types allow the construction of linked data structures. A value of
an access type represents a reference to an object declared as aliased or to
an object created by the evaluation of an allocator. Several variables of an
access type may designate the same object, and components of one object may
designate the same or other objects. Both the elements in such linked data
structures and their relation to other elements can be altered during program
execution. Access types also permit references to subprograms to be stored,
passed as parameters, and ultimately dereferenced as part of an indirect call.

37  Private types permit restricted views of a type. A private type can be
defined in a package so that only the logically necessary properties are made
visible to the users of the type. The full structural details that are
externally irrelevant are then only available within the package and any child
units.

38  From any type a new type may be defined by derivation. A type, together
with its derivatives (both direct and indirect) form a derivation class.
Class-wide operations may be defined that accept as a parameter an operand of
any type in a derivation class. For record and private types, the derivatives
may be extensions of the parent type. Types that support these object-oriented
capabilities of class-wide operations and type extension must be tagged, so
that the specific type of an operand within a derivation class can be
identified at run time. When an operation of a tagged type is applied to an
operand whose specific type is not known until run time, implicit dispatching
is performed based on the tag of the operand.

38.1/2 {AI95-00387-01} Interface types provide abstract models from which
other interfaces and types may be composed and derived. This provides a
reliable form of multiple inheritance. Interface types may also be implemented
by task types and protected types thereby enabling concurrent programming and
inheritance to be merged.

39  The concept of a type is further refined by the concept of a subtype,
whereby a user can constrain the set of allowed values of a type. Subtypes can
be used to define subranges of scalar types, arrays with a limited set of
index values, and records and private types with particular discriminant
values.

40  Other Facilities

41/2 {AI95-00387-01} Aspect clauses can be used to specify the mapping between
types and features of an underlying machine. For example, the user can specify
that objects of a given type must be represented with a given number of bits,
or that the components of a record are to be represented using a given storage
layout. Other features allow the controlled use of low level, nonportable, or
implementation-dependent aspects, including the direct insertion of machine
code.

41.1/5 {AI12-0313-1} Aspect clauses can also be used to specify more abstract
properties of program entities, such as the pre- and postconditions of a
subprogram, or the invariant for a private type. Additional aspects are
specifiable to allow user-defined types to use constructs of the language,
such as literals, aggregates, or indexing, normally reserved for particular
language-defined categories of types, such as numeric types, record types, or
array types.

42/2 {AI95-00387-01} The predefined environment of the language provides for
input-output and other capabilities by means of standard library packages.
Input-output is supported for values of user-defined as well as of predefined
types. Standard means of representing values in display form are also provided.

42.1/2 {AI95-00387-01} The predefined standard library packages provide
facilities such as string manipulation, containers of various kinds (vectors,
lists, maps, etc.), mathematical functions, random number generation, and
access to the execution environment.

42.2/2 {AI95-00387-01} The specialized annexes define further predefined
library packages and facilities with emphasis on areas such as real-time
scheduling, interrupt handling, distributed systems, numerical computation,
and high-integrity systems.

43  Finally, the language provides a powerful means of parameterization of
program units, called generic program units. The generic parameters can be
types and subprograms (as well as objects and packages) and so allow general
algorithms and data structures to be defined that are applicable to all types
of a given class.

Language Changes

Paragraphs 44 through 57 have been removed as they described differences from
the first edition of Ada (Ada 83).

57.1/5 {AI95-00387-01} {AI12-0313-1} This International Standard replaces the
third edition of 2012. It modifies the previous edition by making changes and
additions that improve the capability of the language and the reliability of
programs written in the language.

57.2/5 {AI95-00387-01} {AI05-0299-1} {AI12-0313-1} Significant changes in this
edition are:

57.3/5   * {AI12-0313-1} Improved support for parallel execution is provided
        via the introduction of parallel loops, parallel blocks, parallel
        container iteration, and parallel reduction.

57.4/5   * {AI12-0313-1} More precise specification of subprogram interfaces
        is supported via the new aspects Global, Global'Class, and
        Nonblocking. The Global aspects, in particular, help to determine
        whether two constructs can safely execute in parallel.

57.5/5   * {AI12-0313-1} Pre and Post aspects may now be specified for
        access-to-subprogram types and for generic formal subprograms; a
        postcondition for the default initialization of a type may be
        specified using the new Default_Initial_Condition aspect.

57.6/5   * {AI12-0313-1} The behavior of many predefined container operations
        is now more precisely specified by using pre- and postcondition
        specifications instead of English descriptions; a stable view for most
        containers is introduced to support more efficient iteration.

57.7/5   * {AI12-0313-1} More flexible uses of static expressions are
        supported via the introduction of static expression functions along
        with fewer restrictions on static strings.

57.8/5   * {AI12-0313-1} The Image attribute is supported for nonscalar types,
        and a user-specifiable attribute Put_Image is provided, which
        determines the value of the Image attribute for a user-defined type.

57.9/5    * This paragraph was deleted.

57.10/5   * This paragraph was deleted.

57.11/5   * {AI12-0313-1} The use of numeric and string literals is
        generalized to support other sorts of types, via the new
        Integer_Literal, Real_Literal, and String_Literal aspects.

57.12/5   * {AI12-0313-1} Array and record aggregates are made more flexible:
        index parameters are allowed in an array aggregate to define the
        components as a function of their array index; discriminants can be
        defined more flexibly within an aggregate for a variant record type.

57.13/5   * {AI12-0313-1} New types of aggregates are provided: delta
        aggregates to allow the construction of a new object by incremental
        updates to an existing object; container aggregates to allow
        construction of an object of a container type by directly specifying
        its elements.

57.14/5   * {AI12-0313-1} A shorthand is provided, using the token '@', to
        refer to the target of an assignment statement in the expression
        defining its new value.

57.15/5   * {AI12-0313-1} Declare expressions are provided which permit the
        definition and use of local constants or renamings, to allow an
        expression used within an aspect specification to be more concise and
        readable.

57.16/5   * {AI12-0313-1} Support for lightweight iteration is added via the
        introduction of procedural iterators.

57.17/5   * {AI12-0313-1} Support for the map-reduce programming strategy is
        added via the introduction of reduction expressions.

57.18/5   * {AI12-0313-1} For constructs that use iterators of any sort, a
        filter may be specified that restricts the elements produced by the
        iteration to those that satisfy the condition of the filter.

57.19/5   * {AI12-0313-1} Predefined packages supporting arbitrary-precision
        integer and real arithmetic are provided.

57.20/5   * {AI12-0313-1} The Jorvik profile is introduced to support hard
        real-time applications that need to go beyond the restrictions of the
        Ravenscar profile.



Instructions for Comment Submission

58/1 Informal comments on this International Standard may be sent via e-mail
to ada-comment@ada-auth.org. If appropriate, the Project Editor will initiate
the defect correction procedure.

59  Comments should use the following format:

60/5         !topic Title summarizing comment
             !reference Ada 202x RMss.ss(pp)
             !from Author Name yy-mm-dd
             !keywords keywords related to topic
             !discussion
        
             text of discussion

61/3 where ss.ss is the clause or subclause number, pp is the paragraph number
where applicable, and yy-mm-dd is the date the comment was sent. The date is
optional, as is the !keywords line.

62/1 Please use a descriptive "Subject" in your e-mail message, and limit each
message to a single comment.

63  When correcting typographical errors or making minor wording suggestions,
please put the correction directly as the topic of the comment; use square
brackets [ ] to indicate text to be omitted and curly braces { } to indicate
text to be added, and provide enough context to make the nature of the
suggestion self-evident or put additional information in the body of the
comment, for example:

64           !topic [c]{C}haracter
             !topic it[']s meaning is not defined

65  Formal requests for interpretations and for reporting defects in this
International Standard may be made in accordance with the ISO/IEC JTC 1
Directives and the ISO/IEC JTC 1/SC 22 policy for interpretations. National
Bodies may submit a Defect Report to ISO/IEC JTC 1/SC 22 for resolution under
the JTC 1 procedures. A response will be provided and, if appropriate, a
Technical Corrigendum will be issued in accordance with the procedures.



Acknowledgements for the Ada 83 edition

65.1/3 Ada is the result of a collective effort to design a common language
for programming large scale and real-time systems.

65.2/3 The common high order language program began in 1974. The requirements
of the United States Department of Defense were formalized in a series of
documents which were extensively reviewed by the Services, industrial
organizations, universities, and foreign military departments. The Ada
language was designed in accordance with the final (1978) form of these
requirements, embodied in the Steelman specification.

65.3/3 The Ada design team was led by Jean D. Ichbiah and has included Bernd
Krieg-Brueckner, Brian A. Wichmann, Henry F. Ledgard, Jean-Claude Heliard,
Jean-Loup Gailly, Jean-Raymond Abrial, John G.P. Barnes, Mike Woodger, Olivier
Roubine, Paul N. Hilfinger, and Robert Firth.

65.4/3 At various stages of the project, several people closely associated
with the design team made major contributions. They include J.B. Goodenough,
R.F. Brender, M.W. Davis, G. Ferran, K. Lester, L. MacLaren, E. Morel, I.R.
Nassi, I.C. Pyle, S.A. Schuman, and S.C. Vestal.

65.5/3 Two parallel efforts that were started in the second phase of this
design had a deep influence on the language. One was the development of a
formal definition using denotational semantics, with the participation of V.
Donzeau-Gouge, G. Kahn, and B. Lang. The other was the design of a test
translator with the participation of K. Ripken, P. Boullier, P. Cadiou, J.
Holden, J.F. Hueras, R.G. Lange, and D.T. Cornhill. The entire effort
benefitted from the dedicated assistance of Lyn Churchill and Marion Myers,
and the effective technical support of B. Gravem, W.L. Heimerdinger, and P.
Cleve. H.G. Schmitz served as program manager.

65.6/3 Over the five years spent on this project, several intense week-long
design reviews were conducted, with the participation of P. Belmont, B.
Brosgol, P. Cohen, R. Dewar, A. Evans, G. Fisher, H. Harte, A.L. Hisgen, P.
Knueven, M. Kronental, N. Lomuto, E. Ploedereder, G. Seegmueller, V. Stenning,
D. Taffs, and also F. Belz, R. Converse, K. Correll, A.N. Habermann, J.
Sammet, S. Squires, J. Teller, P. Wegner, and P.R. Wetherall.

65.7/3 Several persons had a constructive influence with their comments,
criticisms and suggestions. They include P. Brinch Hansen, G. Goos, C.A.R.
Hoare, Mark Rain, W.A. Wulf, and also E. Boebert, P. Bonnard, H. Clausen, M.
Cox, G. Dismukes, R. Eachus, T. Froggatt, H. Ganzinger, C. Hewitt, S. Kamin,
R. Kotler, O. Lecarme, J.A.N. Lee, J.L. Mansion, F. Minel, T. Phinney, J.
Roehrich, V. Schneider, A. Singer, D. Slosberg, I.C. Wand, the reviewers of
Ada-Europe, AdaTech, Afcet, those of the LMSC review team, and those of the
Ada Tokyo Study Group.

65.8/3 These reviews and comments, the numerous evaluation reports received at
the end of the first and second phase, the nine hundred language issue reports
and test and evaluation reports received from fifteen different countries
during the third phase of the project, the thousands of comments received
during the ANSI Canvass, and the on-going work of the IFIP Working Group 2.4
on system implementation languages and that of the Purdue Europe LTPL-E
committee, all had a substantial influence on the final definition of Ada.

65.9/3 The Military Departments and Agencies have provided a broad base of
support including funding, extensive reviews, and countless individual
contributions by the members of the High Order Language Working Group and
other interested personnel. In particular, William A. Whitaker provided
leadership for the program during the formative stages. David A. Fisher was
responsible for the successful development and refinement of the language
requirement documents that led to the Steelman specification.

65.10/3 The Ada 83 language definition was developed by Cii Honeywell Bull and
later Alsys, and by Honeywell Systems and Research Center, under contract to
the United States Department of Defense. William E. Carlson and later Larry E.
Druffel served as the technical representatives of the United States
Government and effectively coordinated the efforts of all participants in the
Ada program.

Acknowledgements for the Ada 95 edition

66  This International Standard was prepared by the Ada 9X Mapping/Revision
Team based at Intermetrics, Inc., which has included: W. Carlson, Program
Manager; T. Taft, Technical Director; J. Barnes (consultant); B. Brosgol
(consultant); R. Duff (Oak Tree Software); M. Edwards; C. Garrity; R.
Hilliard; O. Pazy (consultant); D. Rosenfeld; L. Shafer; W. White; M. Woodger.

67  The following consultants to the Ada 9X Project contributed to the
Specialized Needs Annexes: T. Baker (Real-Time/Systems Programming - SEI,
FSU); K. Dritz (Numerics - Argonne National Laboratory); A. Gargaro
(Distributed Systems - Computer Sciences); J. Goodenough (Real-Time/Systems
Programming - SEI); J. McHugh (Secure Systems - consultant); B. Wichmann
(Safety-Critical Systems - NPL: UK).

68  This work was regularly reviewed by the Ada 9X Distinguished Reviewers and
the members of the Ada 9X Rapporteur Group (XRG): E. Ploedereder, Chairman of
DRs and XRG (University of Stuttgart: Germany); B. Bardin (Hughes); J. Barnes
(consultant: UK); B. Brett (DEC); B. Brosgol (consultant); R. Brukardt (RR
Software); N. Cohen (IBM); R. Dewar (NYU); G. Dismukes (TeleSoft); A. Evans
(consultant); A. Gargaro (Computer Sciences); M. Gerhardt (ESL); J. Goodenough
(SEI); S. Heilbrunner (University of Salzburg: Austria); P. Hilfinger
(UC/Berkeley); B. Källberg (CelsiusTech: Sweden); M. Kamrad II (Unisys); J.
van Katwijk (Delft University of Technology: The Netherlands); V. Kaufman
(Russia); P. Kruchten (Rational); R. Landwehr (CCI: Germany); C. Lester
(Portsmouth Polytechnic: UK); L. Månsson (TELIA Research: Sweden); S. Michell
(Multiprocessor Toolsmiths: Canada); M. Mills (US Air Force); D. Pogge (US
Navy); K. Power (Boeing); O. Roubine (Verdix: France); A. Strohmeier (Swiss
Fed Inst of Technology: Switzerland); W. Taylor (consultant: UK); J. Tokar
(Tartan); E. Vasilescu (Grumman); J. Vladik (Prospeks s.r.o.: Czech Republic);
S. Van Vlierberghe (OFFIS: Belgium).

69  Other valuable feedback influencing the revision process was provided by
the Ada 9X Language Precision Team (Odyssey Research Associates), the Ada 9X
User/Implementer Teams (AETECH, Tartan, TeleSoft), the Ada 9X Implementation
Analysis Team (New York University) and the Ada community-at-large.

70  Special thanks go to R. Mathis, Convenor of ISO/IEC JTC 1/SC 22 Working
Group 9.

71  The Ada 9X Project was sponsored by the Ada Joint Program Office.
Christine M. Anderson at the Air Force Phillips Laboratory (Kirtland AFB, NM)
was the project manager.

Acknowledgements for the Corrigendum version

71.1/3 The editor [R. Brukardt (USA)] would like to thank the many people
whose hard work and assistance has made this update possible.

71.2/1 Thanks go out to all of the members of the ISO/IEC JTC 1/SC 22/WG 9 Ada
Rapporteur Group, whose work on creating and editing the wording corrections
was critical to the entire process. Especially valuable contributions came
from the chairman of the ARG, E. Ploedereder (Germany), who kept the process
moving; J. Barnes (UK) and K. Ishihata (Japan), whose extremely detailed
reviews kept the editor on his toes; G. Dismukes (USA), M. Kamrad (USA), P.
Leroy (France), S. Michell (Canada), T. Taft (USA), J. Tokar (USA), and other
members too numerous to mention.

71.3/1 Special thanks go to R. Duff (USA) for his explanations of the previous
system of formatting of these documents during the tedious conversion to more
modern formats. Special thanks also go to the convenor of ISO/IEC JTC 1/SC
22/WG 9, J. Moore (USA), without whose help and support the Corrigendum and
this consolidated reference manual would not have been possible.

Acknowledgements for the Amendment 1 version

71.4/3 The editor [R. Brukardt (USA)] would like to thank the many people
whose hard work and assistance has made this update possible.

71.5/2 Thanks go out to all of the members of the ISO/IEC JTC 1/SC 22/WG 9 Ada
Rapporteur Group, whose work on creating and editing the wording corrections
was critical to the entire process. Especially valuable contributions came
from the chairman of the ARG, P. Leroy (France), who kept the process on
schedule; J. Barnes (UK) whose careful reviews found many typographical
errors; T. Taft (USA), who always seemed to have a suggestion when we were
stuck, and who also was usually able to provide the valuable service of
explaining why things were as they are; S. Baird (USA), who found many obscure
problems with the proposals; and A. Burns (UK), who pushed many of the
real-time proposals to completion. Other ARG members who contributed were: R.
Dewar (USA), G. Dismukes (USA), R. Duff (USA), K. Ishihata (Japan), S. Michell
(Canada), E. Ploedereder (Germany), J.P. Rosen (France), E. Schonberg (USA),
J. Tokar (USA), and T. Vardanega (Italy).

71.6/2 Special thanks go to Ada-Europe and the Ada Resource Association,
without whose help and support the Amendment and this consolidated reference
manual would not have been possible. M. Heaney (USA) requires special thanks
for his tireless work on the containers packages. Finally, special thanks go
to the convenor of ISO/IEC JTC 1/SC 22/WG 9, J. Moore (USA), who guided the
document through the standardization process.

Acknowledgements for the Ada 2012 edition

71.7/3 The editor [R. Brukardt (USA)] would like to thank the many people
whose hard work and assistance has made this revision possible.

71.8/3 Thanks go out to all of the members of the ISO/IEC JTC 1/SC 22/WG 9 Ada
Rapporteur Group, whose work on creating and editing the wording changes was
critical to the entire process. Especially valuable contributions came from
the chairman of the ARG, E. Schonberg (USA), who guided the work; T. Taft
(USA), whose insights broke many logjams, both in design and wording; J.
Barnes (UK) whose careful reviews uncovered many editorial errors; S. Baird
(USA), who repeatedly found obscure interactions with the proposals that the
rest of us missed. Other ARG members who substantially contributed were: A.
Burns (UK), J. Cousins (UK), R. Dewar (USA), G. Dismukes (USA), R. Duff (USA),
P. Leroy (France), B. Moore (Canada), E. Ploedereder (Germany), J.P. Rosen
(France), B. Thomas (USA), and T. Vardanega (Italy).

71.9/3 Special thanks go to Ada-Europe and the Ada Resource Association,
without whose help and support this third edition of the Ada Standard would
not have been possible. A special mention has to go to A. Beneschan (USA) for
his efforts in eliminating sloppiness in our wording. M. Heaney (USA) also
deserves a mention for his efforts to improve the containers packages.
Finally, special thanks go to the convenor of ISO/IEC JTC 1/SC 22/WG 9, J.
Tokar (USA), who guided the document through the standardization process.

Acknowledgements for the Ada 2012 Corrigendum 1 version

71.10/4 The editor [R. Brukardt (USA)] would like to thank the many people
whose hard work and assistance has made this update possible.

71.11/4 Thanks go out to all of the members of the ISO/IEC JTC 1/SC 22/WG 9
Ada Rapporteur Group, whose work on creating and editing the wording changes
was critical to the entire process. Especially valuable contributions came
from the chairman of the ARG, J. Cousins (UK), who guided the work; T. Taft
(USA), who seems to have the ability to cut any Gordian knot we encounter in
wording; ; J. Barnes (UK) who continues to be able to find editorial errors
invisible to most; S. Baird (USA), who so frequently finds obscure
interactions that we now have named such things for him. Other ARG members who
substantially contributed were: A. Burns (UK), R. Dewar (USA), G. Dismukes
(USA), R. Duff (USA), B. Moore (Canada), E. Ploedereder (Germany), J.P. Rosen
(France), E. Schonberg (USA), and T. Vardanega (Italy).

71.12/4 Finally, special thanks go to the convenor of ISO/IEC JTC 1/SC 22/WG
9, J. Tokar (USA), who guided the document through the standardization
process.

Acknowledgements for the Ada 202x version

71.13/5 The editor [R. Brukardt] would like to thank the many people whose
hard work and assistance has made this revision possible.

71.14/5 Thanks go out to all of the members of the ISO/IEC JTC 1/SC 22/WG 9
Ada Rapporteur Group, whose work in all steps of the process, from determining
problems to address, reviewing feature designs, and creating and editing
wording changes, was critical to the entire process. Especially valuable
contributions came from the chairman of the ARG through June 2018, J. Cousins
who guided the work and ensured we followed defined procedures; his
replacement as chairman, S. Baird who ably powered through obstacles to
complete the work while continuing to find obscure interactions; T. Taft, who
often solved difficult problems that had stumped others; B. Moore, whose
frequent suggestions for parallel constructs greatly improved the result.
Other ARG members who substantially contributed were: R. Amiard, J. Barnes, A.
Burns, G. Dismukes, R. Duff, E. Fish, E. Ploedereder, J.P. Rosen, F. Schanda,
E. Schonberg, J. Squierk, T. Vardanega, and R. Wai.



Changes

72  The International Standard is the same as this version of the Reference
Manual, except:

73    * This list of Changes is not included in the International Standard.

74    * The "Acknowledgements" page is not included in the International
        Standard.

75    * The text in the running headers and footers on each page is slightly
        different in the International Standard.

76    * The title page(s) are different in the International Standard.

77    * This document is formatted for 8.5-by-11-inch paper, whereas the
        International Standard is formatted for A4 paper (210-by-297mm); thus,
        the page breaks are in different places.

77.1/4   * The "Foreword " clause is different in the International Standard.

77.2/3   * {AI05-0299-1} The "Using this version of the Ada Reference
        Manual" subclause is not included in the International Standard.

77.3/3   * Paragraph numbers are not included in the International Standard.

Using this version of the Ada Reference Manual

77.4/5 This document has been revised with the corrections specified in
Technical Corrigendum 1 (ISO/IEC 8652:2012/COR.1:2016) and other changes
specifically for Ada 202x. In addition, more annotations have been added and a
variety of editorial errors have been corrected.

77.5/4 Changes to the original 8652:1995 can be identified by the version
number following the paragraph number. Paragraphs with a version number of /1
were changed by Technical Corrigendum 1 for Ada 95 or were editorial
corrections at that time, while paragraphs with a version number of /2 were
changed by Amendment 1 or were more recent editorial corrections, and
paragraphs with a version number of /3 were changed by the third (2012)
edition of the Standard or were still more recent editorial corrections.
Paragraphs with a version number of /4 are changed by Technical Corrigendum 1
for Ada 2012 or were editorial corrections at that time. Paragraphs with a
version number of /5 are changes or editorial corrections for Ada 202x.
Paragraphs not so marked are unchanged by Ada 202x, Technical Corrigendum 1
for Ada 2012, the third edition, Amendment 1, Technical Corrigendum 1, or
editorial corrections. Paragraph numbers of unchanged paragraphs are the same
as in the 1995 edition of the Ada Reference Manual. Inserted text is indicated
by underlining, and deleted text is indicated by strikethroughs. Some versions
also use color to indicate the version of the change. Where paragraphs are
inserted, the paragraph numbers are of the form pp.nn, where pp is the number
of the preceding paragraph, and nn is an insertion number. For instance, the
first paragraph inserted after paragraph 8 is numbered 8.1, the second
paragraph inserted is numbered 8.2, and so on. Deleted paragraphs are
indicated by the text This paragraph was deleted. Deleted paragraphs include
empty paragraphs that were numbered in the 1995 edition of the Ada Reference
Manual. Similar markings and numbering are used for changes to annotations.

77.a/3      To be honest: The paragraph number is considered part of the
            paragraph; when a paragraph is moved to a different paragraph
            number, it is marked as changed even if the contents have not
            changed.

