Section 1: General
Ada is a programming language designed to support
the construction of long-lived, highly reliable software systems. The
language includes facilities to define packages of related types, objects,
and operations. The packages may be parameterized and the types may be
extended to support the construction of libraries of reusable, adaptable
software components. The operations may be implemented as subprograms
using conventional sequential control structures, or as entries that
include synchronization of concurrent threads of control as part of their
invocation. The language treats modularity in the physical sense as well,
with a facility to support separate compilation.
The language includes a complete facility for the
support of real-time, concurrent programming. Errors can be signaled
as exceptions and handled explicitly. The language also covers systems
programming; this requires precise control over the representation of
data and access to system-dependent properties. Finally, a predefined
environment of standard packages is provided, including facilities for,
among others, input-output, string manipulation, numeric elementary functions,
and random number generation.
Discussion: This Annotated Ada Reference
Manual (AARM) contains the entire text of the Ada Reference Manual with
Amendment 1 (the Ada 2005 RM), plus certain annotations. The annotations
give a more in-depth analysis of the language. They describe the reason
for each non-obvious rule, and point out interesting ramifications of
the rules and interactions among the rules (interesting to language lawyers,
that is). Differences between Ada 83, Ada 95, and Ada 2005 are listed.
(The text you are reading now is an annotation.)
The AARM stresses detailed correctness and uniformity
over readability and understandability. We're not trying to make the
language “appear” simple here; on the contrary, we're trying
to expose hidden complexities, so we can more easily detect language
bugs. The Ada 2005 RM, on the other hand, is intended to be a more readable
document for programmers.
The annotations
in the AARM are as follows:
Text that is logically redundant is shown
[in square brackets, like this]. Technically, such text could be written
as a Note in the Ada 2005 RM (and the Ada 95 RM before it), since it
is really a theorem that can be proven from the non-redundant rules of
the language. We use the square brackets instead when it seems to make
the Ada 2005 RM more readable.
The rules of the language (and some AARM-only
text) are categorized, and placed under certain
sub-headings that
indicate the category. For example, the distinction between Name Resolution
Rules and Legality Rules is particularly important, as explained in
8.6.
Text under the following sub-headings appears
in both documents:
The unlabeled text at the beginning
of each clause or subclause,
Syntax,
Name Resolution Rules,
Legality Rules,
Static Semantics,
Post-Compilation Rules,
Dynamic Semantics,
Bounded (Run-Time) Errors,
Erroneous Execution,
Implementation Requirements,
Documentation Requirements,
Metrics,
Implementation Permissions,
Implementation Advice,
NOTES,
Examples.
Text under the following sub-headings does
not appear in the Ada 2005 RM:
Language Design Principles,
Inconsistencies With Ada 83,
Incompatibilities With Ada
83,
Extensions to Ada 83,
Wording Changes from Ada 83,
Inconsistencies With Ada 95,
Incompatibilities With Ada
95,
Extensions to Ada 95,
Wording Changes from Ada 95.
The AARM also includes the following kinds
of annotations. These do not necessarily annotate the immediately preceding
rule, although they often do.
Reason: An explanation of why a certain
rule is necessary, or why it is worded in a certain way.
Ramification: An obscure ramification
of the rules that is of interest only to language lawyers. (If a ramification
of the rules is of interest to programmers, then it appears under NOTES.)
Proof: An informal proof explaining how
a given Note or [marked-as-redundant] piece of text follows from the
other rules of the language.
Implementation Note: A hint about how
to implement a feature, or a particular potential pitfall that an implementer
needs to be aware of.
Change: Change annotations are not used
in this version. Changes from previous versions have been removed. Changes
in this version are marked with versioned paragraph numbers, as explained
in the “Corrigendum Changes” clause of the “Introduction”.
Discussion: Other annotations not covered
by the above.
To be honest: A rule that is considered
logically necessary to the definition of the language, but which is so
obscure or pedantic that only a language lawyer would care. These are
the only annotations that could be considered part of the language definition.
Glossary entry: The text of a Glossary
entry — this text will also appear in
Annex
N, “
Glossary”.
Discussion: In general, the Ada 2005
RM text appears in the normal font, whereas AARM-only text appears in
a smaller font. Notes also appear in the smaller font, as recommended
by ISO/IEC style guidelines. Ada examples are also usually printed in
a smaller font.
If you have trouble finding things, be sure
to use the index. {
italics, like this}
Each
defined term appears there, and also in
italics, like this. Syntactic
categories defined in BNF are also indexed.
A definition marked “[distributed]”
is the main definition for a term whose complete definition is given
in pieces distributed throughout the document. The pieces are marked
“[partial]” or with a phrase explaining what cases the partial
definition applies to.
Sponsored by Ada-Europe