Introduction

{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. Ada
95 Rationale. This Rationale
for the Ada Programming Language — 1995 edition, which gives an introduction to the new features of Ada incorporated in the 1995 edition of this Standard,
and explains the rationale behind them. Programmers unfamiliar
with Ada 95 should read this first.

Discussion: {AI05-0245-1}
As of this writing (December 2012), only five chapters
of the Ada 2012 Rationale have been published. Additional chapters are
in development and should be published during 2013.

{AI95-00387-01}
{AI05-0245-1}
Ada
2005 Rationale. This gives an introduction to the changes and new features
in Ada 2005 (compared with the 1995 edition), and explains the rationale
behind them. Programmers should read this rationale before reading this
Standard in depth.

{AI95-00387-01}
Ada was originally designed with three overriding concerns: program reliability
and maintenance, programming as a human activity, and efficiency. The
1995 This 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. This third
edition amended
version provides further flexibility
and adds 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.

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.

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.

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.

{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 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.

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.

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.

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.

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.

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).

{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, and 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.

{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, and
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.

{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.

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.

{AI95-00387-01}
Aspect Representation
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.

{AI95-00387-01}
The predefined environment of the language provides for input-output
and other capabilities (such as string manipulation
and random number generation) 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. Other standard library packages are defined
in annexes of the standard to support systems with specialized requirements.

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).

{AI95-00387-01}
This amended
International Standard updates
the edition of 1995 which replaced replaces the first edition of 1987. In the
1995 this edition, the following major language changes were have
been incorporated:

{AI95-00387-01}
The
type model was extended to include facilities for o Object-oriented
programming with dynamic run-time polymorphism. See the discussions of classes, derived types, tagged types,
record extensions, and private extensions in clauses 3.4,
3.9, and 7.3. Additional See
also the new forms of generic formal parameters
were that
are allowed as
described in clauses 12.5.1 and 12.7 by
12.5.1, “Formal
Private and Derived Types” and 12.7,
“Formal Packages”.

{AI95-00387-01}
Access types were have
been extended to allow an access value to
designate a subprogram or an object declared by an object declaration
(as opposed
to just an object
a heap-allocated
on a heap object).
See clause 3.10.

{AI95-00387-01}
This International
Standard replaces the second edition of 1995. It Amendment
1 modifies the previous
edition 1995
International Standard by making
changes and additions that improve the capability of the language and
the reliability of programs written in the language. This edition incorporates the changes from Amendment 1 (ISO/IEC 8652:1995:AMD
1:2007), which In
particular the changes were designed
to improve the portability of programs, interfacing to other languages,
and both the object-oriented and real-time capabilities.

Support for program text
is extended to cover the entire ISO/IEC 10646:2003 repertoire. Execution
support now includes the 32-bit character set. See subclauses clauses2.1, 3.5.2, 3.6.3,
A.1, A.3, and A.4.

The object-oriented model
has been improved by the addition of an interface facility which provides
multiple inheritance and additional flexibility for type extensions.
See subclauses clauses3.4, 3.9, and 7.3.
An alternative notation for calling operations more akin to that used
in other languages has also been added. See subclause clause4.1.3.

Access types have been further
extended to unify properties such as the ability to access constants
and to exclude null values. See clause 3.10.
Anonymous access types are now permitted more freely and anonymous access-to-subprogram
types are introduced. See subclauses clauses3.3, 3.6, 3.10,
and 8.5.1.

The control of structure
and visibility has been enhanced to permit mutually dependent references
between units and finer control over access from the private part of
a package. See subclauses clauses3.10.1 and 10.1.2.
In addition, limited types have been made more useful by the provision
of aggregates, constants, and constructor functions. See subclauses clauses4.3, 6.5, and 7.5.

The predefined environment
has been extended to include additional time and calendar operations,
improved string handling, a comprehensive container library, file and
directory management, and access to environment variables. See subclauses clauses9.6.1, A.4, A.16,
A.17, and A.18.

The Real-Time
Systems Annex now includes the Ravenscar profile for high-integrity systems,
further dispatching policies such as Round Robin and Earliest Deadline
First, support for timing events, and support for control of CPU time
utilization. See subclauses clausesD.2, D.13, D.14,
and D.15.

The overall reliability of
the language has been enhanced by a number of improvements. These include
new syntax which detects accidental overloading, as well as pragmas for
making assertions and giving better control over the suppression of checks.
See subclauses clauses6.1, 11.4.2, and
11.5.

{AI05-0245-1}
In addition, this third edition makes enhancements
to address two important issues, namely, the particular problems of multiprocessor
architectures, and the need to further increase the capabilities regarding
assertions for correctness. It also makes additional changes and additions
that improve the capability of the language and the reliability of programs
written in the language.

The concept of assertions
introduced in the 2005 edition is extended with the ability to specify
preconditions and postconditions for subprograms, and invariants for
private types. The concept of constraints in defining subtypes is supplemented
with subtype predicates that enable subsets to be specified other than
as simple ranges. These properties are all indicated using aspect specifications.
See subclauses 3.2.4, 6.1.1,
and 7.3.2.

New forms of expressions
are introduced. These are if expressions, case expressions, quantified
expressions, and expression functions. As well as being useful for programming
in general by avoiding the introduction of unnecessary assignments, they
are especially valuable in conditions and invariants since they avoid
the need to introduce auxiliary functions. See subclauses 4.5.7,
4.5.8, and 6.8.
Membership tests are also made more flexible. See subclauses 4.4
and 4.5.2.

A number of changes are made
to subprogram parameters. Functions may now have parameters of all modes.
In order to mitigate consequent (and indeed existing) problems of inadvertent
order dependence, rules are introduced to reduce aliasing. A parameter
may now be explicitly marked as aliased and the type of a parameter may
be incomplete in certain circumstances. See subclauses 3.10.1,
6.1, and 6.4.1.

The use of access types is
now more flexible. The rules for accessibility and certain conversions
are improved. See subclauses 3.10.2, 4.5.2,
4.6, and 8.6. Furthermore,
better control of storage pools is provided. See subclause 13.11.4.

The Real-Time Systems Annex
now includes facilities for defining domains of processors and assigning
tasks to them. Improvements are made to scheduling and budgeting facilities.
See subclauses D.10.1, D.14,
and D.16.

A number of important improvements
are made to the standard library. These include packages for conversions
between strings and UTF encodings, and classification functions for wide
and wide wide characters. Internationalization is catered for by a package
giving locale information. See subclauses A.3,
A.4.11, and A.19.
The container library is extended to include bounded forms of the existing
containers and new containers for indefinite objects, multiway trees,
and queues. See subclause A.18.

Finally, certain features
are added primarily to ease the use of containers, such as the ability
to iterate over all elements in a container without having to encode
the iteration. These can also be used for iteration over arrays, and
within quantified expressions. See subclauses 4.1.5,
4.1.6, 5.5.1,
and 5.5.2.

Informal
comments on this International Standard may be sent via e-mail to ada-comment@ada-auth.org ada-comment@sw-eng.falls-church.va.us.
If appropriate, the Project Editor will initiate the defect correction
procedure.

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:

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.

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.

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.

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.

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.

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.

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.

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.

This document has been revised
with the corrections specified in Technical Corrigendum 1 (ISO/IEC 8652:1995/COR.1:2001) and Amendment 1 (ISO/IEC 8652/AMD 1:2007),
along with changes specifically for this third edition.
In addition, more additional annotations have been added and a variety of editorial errors have been
corrected.

Changes to the original
8652:1995 can be identified by the version number /1
following the paragraph number. Paragraphs with a version number of /1 were changed by Technical Corrigendum
1 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 not so marked are unchanged by 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 original 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 original Ada Reference Manual. Similar markings and numbering are is used for changes to annotations.