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.

2.a

Discussion: This Annotated Ada Reference Manual (AARM) contains the entire text of the Ada Reference Manual (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 and Ada 95 are listed. (The text you are reading now is an annotation.)

2.b

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

Text that is logically redundant is shown [in square brackets, like this]. Technically, such text could be written as a Note in the 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 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

Text under the following sub-headings does not appear in the 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

Wording Changes from Ada 83.

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

Discussion: In general, 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. {italics, like this} 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.

Contents Index Previous Next Legal