Section 1: General
1
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.
2
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.
2.a/3
Discussion: This Annotated Ada Reference
Manual (AARM) contains the entire text of the third
edition of the Ada Reference Manual (the
Ada 2012 RM with Amendment 1 (the Ada 2005 RM(RM95),
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,
and Ada 2012 and Ada 95 are listed. (The text you are reading now is an annotation.)
2.b/3
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 2012 2005 RM RM95, on the other hand, is intended
to be a more readable document for programmers.
2.c
The annotations
in the AARM are as follows:
2.d/3
Text that is logically redundant is shown
[in square brackets, like this]. Technically, such text could be written
as a Note in the Ada 2012 2005 RM (and the Ada 95 and 2005 RMs RM before it) RM95, 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
2012 2005 RM RM95 more readable.
2.e
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.
2.f
Text under the following sub-headings appears
in both documents:
2.g
The unlabeled text at the beginning
of each clause or subclause,
2.h
Syntax,
2.i
Name Resolution Rules,
2.j
Legality Rules,
2.k
Static Semantics,
2.l
Post-Compilation Rules,
2.m
Dynamic Semantics,
2.n
Bounded (Run-Time) Errors,
2.o
Erroneous Execution,
2.p
Implementation Requirements,
2.q
Documentation Requirements,
2.r
Metrics,
2.s
Implementation Permissions,
2.t
Implementation Advice,
2.u
NOTES,
2.v
Examples.
2.w/3
Text under the following sub-headings does
not appear in the Ada 2012 2005 RM RM95:
2.x
Language Design Principles,
2.y
Inconsistencies With Ada 83,
2.z
Incompatibilities With Ada
83,
2.aa
Extensions to Ada 83,
2.bb/2
Wording Changes from Ada 83,.
2.bb.1/2
Inconsistencies
With Ada 95,
2.bb.2/2
Incompatibilities
With Ada 95,
2.bb.3/2
Extensions
to Ada 95,
2.bb.4/3
Wording
Changes from Ada 95,.
2.bb.5/3
Inconsistencies
With Ada 2005,
2.bb.6/3
Incompatibilities
With Ada 2005,
2.bb.7/3
Extensions
to Ada 2005,
2.bb.8/3
Wording
Changes from Ada 2005.
2.cc
The AARM also includes the following kinds
of annotations. These do not necessarily annotate the immediately preceding
rule, although they often do.
2.dd
Reason: An explanation of why a certain
rule is necessary, or why it is worded in a certain way.
2.ee
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.)
2.ff
Proof: An informal proof explaining how
a given Note or [marked-as-redundant] piece of text follows from the
other rules of the language.
2.gg
Implementation Note: A hint about how
to implement a feature, or a particular potential pitfall that an implementer
needs to be aware of.
2.hh
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”.
2.ii
Discussion: Other annotations not covered
by the above.
2.jj
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.
2.kk
Glossary entry: The text of a Glossary
entry — this text will also appear in
Annex
N, “
Glossary”.
2.ll/3
Discussion: In general, the
Ada 2012 2005 RM RM95 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.
2.mm
If you have trouble finding things, be sure
to use the index.
Each defined term appears there,
and also in
italics, like this. Syntactic categories defined in
BNF are also indexed.
2.nn
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.
Ada 2005 and 2012 Editions sponsored in part by Ada-Europe
