Introduction
This is the Ada Reference Manual.
Other available Ada
documents include:
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.
This paragraph
was deleted.
The Annotated Ada Reference Manual (AARM).
The AARM contains all of the text in this International
Standard, plus various annotations. It is intended primarily for compiler
writers, validation test writers, and others who wish to study the fine
details. The annotations include detailed rationale for individual rules
and explanations of some of the more arcane interactions among the rules.
Design
Goals
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.
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.
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.
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.
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
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.
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.
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.
Program Units
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.
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.
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.
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.
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.
Declarations and Statements
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.
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.
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).
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.
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.
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.
A block statement comprises a sequence of statements
preceded by the declaration of local entities used by the statements.
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.
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.
Data Types
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).
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.
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.
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.
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.
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.
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.
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.
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.
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.
Other Facilities
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.
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.
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.
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.
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.
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).
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.
Significant changes
in this edition are:
Improved support for parallel execution is provided
via the introduction of parallel loops, parallel blocks, parallel container
iteration, and parallel reduction.
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.
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.
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.
More flexible uses of static expressions are supported
via the introduction of static expression functions along with fewer
restrictions on static strings.
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.
This
paragraph was deleted.
This
paragraph was deleted.
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.
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.
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.
A shorthand is provided, using the token '@', to
refer to the target of an assignment statement in the expression defining
its new value.
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.
Support for lightweight iteration is added via
the introduction of procedural iterators.
Support for the map-reduce programming strategy
is added via the introduction of reduction expressions.
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.
Predefined packages supporting arbitrary-precision
integer and real arithmetic are provided.
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
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.
Comments should use the following format:
!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
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.
Please use a descriptive “Subject” in
your e-mail message, and limit each message to a single comment.
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:
!topic [c]{C}haracter
!topic it[']s meaning is not defined
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
Ada is the result of a collective effort to design
a common language for programming large scale and real-time systems.
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.
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.
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.
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.
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.
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.
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.
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.
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
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.
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).
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).
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.
Special thanks go to R. Mathis, Convenor of ISO/IEC
JTC 1/SC 22 Working Group 9.
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
The editor [R. Brukardt (USA)] would like to thank
the many people whose hard work and assistance has made this update possible.
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.
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
The editor [R. Brukardt (USA)] would like to thank
the many people whose hard work and assistance has made this update possible.
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).
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
The editor [R. Brukardt (USA)] would like to thank
the many people whose hard work and assistance has made this revision
possible.
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).
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
The editor [R. Brukardt (USA)] would like to thank
the many people whose hard work and assistance has made this update possible.
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).
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
The editor [R. Brukardt] would like to thank the
many people whose hard work and assistance has made this revision possible.
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
The International Standard
is the same as this version of the Reference Manual, except:
This list of Changes is not included in the International
Standard.
The “Acknowledgements” page is not
included in the International Standard.
The text in the running headers and footers on
each page is slightly different in the International Standard.
The title page(s) are different in the International
Standard.
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.
The “Foreword ” clause is different
in the International Standard.
The “Using this version of the Ada Reference
Manual” subclause is not included in the International Standard.
Paragraph numbers are not included in the International
Standard.
Using
this version of the Ada Reference Manual
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, a variety of editorial
errors have been corrected.
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 for Ada 95, or editorial
corrections. Paragraph numbers of unchanged paragraphs are the same as
in the 1995 edition of the Ada Reference Manual. In addition, some versions
of this document include revision bars near the paragraph numbers. 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.
Ada 2005 and 2012 Editions sponsored in part by Ada-Europe