Dec 052017
Complete description of the ADA language as provided by the Government.
File ADAREF.ZIP from The Programmer’s Corner in
Category Miscellaneous Language Source Code
Complete description of the ADA language as provided by the Government.
File Name File Size Zip Size Zip Type
LRM-01.DOC 31049 10200 deflated
LRM-02.DOC 28040 8783 deflated
LRM-03.DOC 148383 34123 deflated
LRM-04.DOC 94348 24591 deflated
LRM-05.DOC 33134 9842 deflated
LRM-06.DOC 39838 11419 deflated
LRM-07.DOC 42420 11645 deflated
LRM-08.DOC 43892 12352 deflated
LRM-09.DOC 63417 17291 deflated
LRM-10.DOC 37363 10147 deflated
LRM-11.DOC 40421 11010 deflated
LRM-12.DOC 47099 11946 deflated
LRM-13.DOC 54072 14933 deflated
LRM-14.DOC 100210 21711 deflated

Download File ADAREF.ZIP Here

Contents of the LRM-01.DOC file

The Ada Joint Program Office does not guarantee the accuracy of this
file, as compared with the contents of ANSI/MIL-STD-1815A-1983,
the Reference Manual for the Ada* Programming Language. If errors or
discrepancies are found in this machine-readable version, please
forward comments via the Defense Data Network (DDN) to

[email protected]

or via conventional mail to

Ada Information Clearinghouse
3D139 (1211 S. Fern, C-107)
The Pentagon
Washington, D.C. 20301-3081.


Copyright 1980, 1982, 1983 owned by the United States Government as
represented by the Under Secretary of Defense, Research and
Engineering. All rights reserved. Provided that notice of copyright
is included on the first page, this document may be copied in its
entirety without alteration or as altered by (1) adding text that is
clearly marked as an insertion; (2) shading or highlighting existing
text; (3) deleting examples. Permission to publish other excerpts
should be obtained from the Ada Joint Program Office, OUSDRE (R&AT),
The Pentagon, Washington, DC 20301-2081, U.S.A.

Ada* is a registered trademark of the United States Government,
Department of Defense, Under Secretary for Research and Engineering.
Its use is administered by the Ada Joint Program Office (AJPO). In
all contexts, use of the term "Ada" should indicate conformance to the
standard. In keeping with policies on voluntary conformance, use of
the term Ada is equivalent to a voluntary statement of conformance to
the standard.

The use of the trademarked term Ada will be made freely available to
those who use it to indicate conformance to the standard and in
accordance with the following guidelines:

In any published material the first appearance of the term Ada
must be properly acknowledged and include the statement "Ada
is a registered trademark of the U.S. Government (Ada Joint
Program Office)."

Describing, advertising, or promoting a language processor
as an "Ada" processor is equivalent to making a voluntary
statement of conformance to ANSI/MIL-STD-1815A.

The term Ada may be used in describing language processors
which are not completely conforming or are not making a claim
of conformance provided that there is a precise, easily
visible statement of their non-conformance at the same
time and in the same context.

Uses of the term Ada other than those described above, including all
organizations, companies and product names incorporating or utilizing
the term Ada, need written authorization from the AJPO. Those persons
advertising or otherwise promoting a language processor asserted as
being a standard Ada processor for sale or public use are required to
provide the AJPO with evidence sufficient to demonstrate conformance
to the Ada standard.

Use of the trademark does not imply any endorsement or warranty of the
product by either U.S. DoD or ANSI.

The Department of Defense (DoD), as the trademark owner, will allow
others to use the Ada trademark free of charge and will not take
action to prevent use of the Ada trademark so long as the trademark is
used properly according to the above policy. Misuse of the trademark
may lead to legal action.

In the interest of information interchange, all users of this standard
are encouraged to contact the Ada Joint Program Office, Department of
Defense, OUSD(R&E), Washington, D.C. 20301, U.S.A. Users of the
trademark and those reprinting the standard are required to notify the

*Ada is a registered trademark of the U.S. Government
(Ada Joint Program Office).

1. Introduction
Ada is a programming language designed in accordance with requirements
defined by the United States Department of Defense: the so-called Steelman
requirements. Overall, these requirements call for a language with
considerable expressive power covering a wide application domain. As a
result, the language includes facilities offered by classical languages
such as Pascal as well as facilities often found only in specialized
languages. Thus the language is a modern algorithmic language with the
usual control structures, and with the ability to define types and
subprograms. It also serves the need for modularity, whereby data, types,
and subprograms can be packaged. It treats modularity in the physical
sense as well, with a facility to support separate compilation.
In addition to these aspects, the language covers real-time programming,
with facilities to model parallel tasks and to handle exceptions. It also
covers systems programming; this requires precise control over the
representation of data and access to system-dependent properties. Finally,
both application-level and machine-level input-output are defined.
1.1 Scope of the Standard
This standard specifies the form and meaning of program units written in
Ada. Its purpose is to promote the portability of Ada programs to a
variety of data processing systems.
1.1.1 Extent of the Standard
This standard specifies:
(a) The form of a program unit written in Ada.
(b) The effect of translating and executing such a program unit.
(c) The manner in which program units may be combined to form Ada
(d) The predefined program units that a conforming implementation must
(e) The permissible variations within the standard, and the manner in
which they must be specified.
1 - 1
(f) Those violations of the standard that a conforming implementation is
required to detect, and the effect of attempting to translate or
execute a program unit containing such violations.
(g) Those violations of the standard that a conforming implementation is
not required to detect.
1 - 2
This standard does not specify:
(h) The means whereby a program unit written in Ada is transformed into
object code executable by a processor.
(i) The means whereby translation or execution of program units is invoked
and the executing units are controlled.
(j) The size or speed of the object code, or the relative execution speed
of different language constructs.
(k) The form or contents of any listings produced by implementations; in
particular, the form or contents of error or warning messages.
(l) The effect of executing a program unit that contains any violation
that a conforming implementation is not required to detect.
(m) The size of a program or program unit that will exceed the capacity of
a particular conforming implementation.
Where this standard specifies that a program unit written in Ada has an
exact effect, this effect is the operational meaning of the program unit
and must be produced by all conforming implementations. Where this
standard specifies permissible variations in the effects of constituents of
a program unit written in Ada, the operational meaning of the program unit
as a whole is understood to be the range of possible effects that result
from all these variations, and a conforming implementation is allowed to
produce any of these possible effects. Examples of permissible variations are:
- The represented values of fixed or floating numeric quantities, and
the results of operations upon them.
- The order of execution of statements in different parallel tasks, in
the absence of explicit synchronization.
1.1.2 Conformity of an Implementation With the Standard
A conforming implementation is one that:
(a) Correctly translates and executes legal program units written in Ada,
provided that they are not so large as to exceed the capacity of the
(b) Rejects all program units that are so large as to exceed the capacity
of the implementation.
(c) Rejects all program units that contain errors whose detection is
required by the standard.
(d) Supplies all predefined program units required by the standard.
1 - 3
(e) Contains no variations except where the standard permits.
(f) Specifies all such permitted variations in the manner prescribed by
the standard.
1 - 4
1.2 Structure of the Standard
This reference manual contains fourteen chapters, three annexes, three
appendices, and an index.
Each chapter is divided into sections that have a common structure. Each
section introduces its subject, gives any necessary syntax rules, and
describes the semantics of the corresponding language constructs. Examples
and notes, and then references, may appear at the end of a section.
Examples are meant to illustrate the possible forms of the constructs
described. Notes are meant to emphasize consequences of the rules
described in the section or elsewhere. References are meant to attract the
attention of readers to a term or phrase having a technical meaning defined
in another section.
The standard definition of the Ada programming language consists of the
fourteen chapters and the three annexes, subject to the following
restriction: the material in each of the items listed below is
informative, and not part of the standard definition of the Ada programming
- Section 1.3 Design goals and sources
- Section 1.4 Language summary
- The examples, notes, and references given at the end of each section
- Each section whose title starts with the word "Example" or "Examples"
1.3 Design Goals and Sources
Ada was designed with three overriding concerns: program reliability and
maintenance, programming as a human activity, and efficiency.
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 the language as small as possible,
given the ambitious nature of the application domain. We have attempted to
1 - 5
cover this domain with a small number of underlying concepts integrated in
a consistent and systematic way. Nevertheless we have tried to avoid the
pitfalls of excessive involution, and in the constant search for simpler
designs we have tried to provide language constructs that correspond
intuitively to what the users will normally expect.
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 has been
a central idea in this 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.
1 - 6
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
None of the above design goals was considered as achievable after the fact.
The design goals drove the entire design process from the beginning.
A perpetual difficulty in language design is that one must both identify
the capabilities required by the application domain and design language
features that provide these capabilities. The difficulty existed in this
design, although to a lesser degree than usual because of the Steelman
requirements. These requirements often simplified the design process by
allowing it to concentrate on the design of a given system providing a well
defined set of capabilities, rather than on the definition of the
capabilities themselves.
Another significant simplification of the design work resulted from earlier
experience acquired by several successful Pascal derivatives developed with
similar goals. These are the languages Euclid, Lis, Mesa, Modula, and Sue.
Many of the key ideas and syntactic forms developed in these languages have
counterparts in Ada. Several existing languages such as Algol 68 and
Simula, and also recent research languages such as Alphard and Clu,
influenced this language in several respects, although to a lesser degree
than did the Pascal family.
Finally, the evaluation reports received on an earlier formulation (the
Green language), and on alternative proposals (the Red, Blue, and Yellow
languages), the language reviews that took place at different stages of
this project, and the thousands of comments received from fifteen different
countries during the preliminary stages of the Ada design and during the
ANSI canvass, all had a significant impact on the standard definition of
the language.
1.4 Language Summary
An Ada program is composed of one or more program units. These program
units can be compiled separately. Program units may be subprograms (which
define executable algorithms), package units (which define collections of
entities), task units (which define parallel computations), or generic
units (which define parameterized forms of packages and subprograms).
Each 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.
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.
1 - 7
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. 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.
1 - 8
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 common pool of
data and types, a collection of related subprograms, or 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.
A task unit is the basic unit for defining a task whose sequence of actions
may be executed in parallel 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.
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, 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 an exit,
return, or goto statement, or the raising of an exception, 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 only applicable to tasks. A delay statement delays
the execution of a task for a specified duration. An entry call statement
is written as a procedure call statement; it specifies that the task
issuing the call is ready for a rendezvous with another task that has this
1 - 9
entry. The called task is ready to accept the entry call when its
execution reaches a corresponding accept statement, which specifies the
actions then to be performed. After completion of the rendezvous, both the
calling task and the task having the entry may continue their execution in
parallel. 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.
1 - 1 4
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
scalar types (comprising enumeration and numeric types), composite types,
access types, and private 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 and 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 provide for 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.
The array type STRING is predefined.
A record may have special components called discriminants. Alternative
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 created by
the evaluation of allocators. They allow several variables of an access
type to designate the same object, and components of one object to
designate the same or other objects. Both the elements in such a linked
data structure and their relation to other elements can be altered during
program execution.
Private types can be defined in a package that conceals structural details
that are externally irrelevant. Only the logically necessary properties
(including any discriminants) are made visible to the users of such types.
The concept of a type is 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
1 - 11
Other Facilities
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.
Input-output is defined in the language by means of predefined library
packages. Facilities are provided for input-output of values of
user-defined as well as of predefined types. Standard means of
representing values in display form are also provided.
1 - 12
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 so allow general algorithms
to be applied to all types of a given class.
1.5 Method of Description and Syntax Notation
The form of Ada program units is described by means of a context-free
syntax together with context-dependent requirements expressed by narrative
The meaning of Ada program units is described by means of narrative rules
defining both the effects of each construct and the composition rules for
constructs. This narrative employs technical terms whose precise
definition is given in the text (references to the section containing the
definition of a technical term appear at the end of each section that uses
the term).
All other terms are in the English language and bear their natural meaning,
as defined in Webster's Third New International Dictionary of the English
The context-free syntax of the language is described using a simple variant
of Backus-Naur-Form. In particular,
(a) Lower case words, some containing embedded underlines, are used to
denote syntactic categories, for example:
Whenever the name of a syntactic category is used apart from the
syntax rules themselves, spaces take the place of the underlines
(thus: adding operator).
(b) Boldface words are used to denote reserved words, for example:
(c) Square brackets enclose optional items. Thus the two following rules
are equivalent.
return_statement ::= return [expression];
return_statement ::= return; | return expression;
(d) Braces enclose a repeated item. The item may appear zero or more
times; the repetitions occur from left to right as with an equivalent
left-recursive rule. Thus the two following rules are equivalent.
1 - 13
term ::= factor {multiplying_operator factor}
term ::= factor | term multiplying_operator factor
1 - 14
(e) A vertical bar separates alternative items unless it occurs
immediately after an opening brace, in which case it stands for
letter_or_digit ::= letter | digit
component_association ::= [choice {| choice} =>] expression
(f) If the name of any syntactic category starts with an italicized part,
it is equivalent to the category name without the italicized part.
The italicized part is intended to convey some semantic information.
For example type_name and task_name are both equivalent to name alone. Note:
The syntax rules describing structured constructs are presented in a form
that corresponds to the recommended paragraphing. For example, an if
statement is defined as
if_statement ::=
if condition then
{elsif condition then
end if;
Different lines are used for parts of a syntax rule if the corresponding
parts of the construct described by the rule are intended to be on
different lines. Indentation in the rule is a recommendation for
indentation of the corresponding part of the construct. It is recommended
that all indentations be by multiples of a basic step of indentation (the
number of spaces for the basic step is not defined). The preferred places
for other line breaks are after semicolons. On the other hand, if a
complete construct can fit on one line, this is also allowed in the
recommended paragraphing.
1.6 Classification of Errors
The language definition classifies errors into several different
(a) Errors that must be detected at compilation time by every Ada
These errors correspond to any violation of a rule given in this
reference manual, other than the violations that correspond to (b) or
(c) below. In particular, violation of any rule that uses the terms
must, allowed, legal, or illegal belongs to this category. Any
program that contains such an error is not a legal Ada program; on
1 - 15
the other hand, the fact that a program is legal does not mean, per
se, that the program is free from other forms of error.
(b) Errors that must be detected at run time by the execution of an Ada
The corresponding error situations are associated with the names of
the predefined exceptions. Every Ada compiler is required to generate
code that raises the corresponding exception if such an error
situation arises during program execution. If an exception is certain
to be raised in every execution of a program, then compilers are
allowed (although not required) to report this fact at compilation
1 - 16
(c) Erroneous execution.
The language rules specify certain rules to be obeyed by Ada programs,
although there is no requirement on Ada compilers to provide either a
compilation-time or a run-time detection of the violation of such
rules. The errors of this category are indicated by the use of the
word erroneous to qualify the execution of the corresponding
constructs. The effect of erroneous execution is unpredictable.
(d) Incorrect order dependences.
Whenever the reference manual specifies that different parts of a
given construct are to be executed in some order that is not defined
by the language, this means that the implementation is allowed to
execute these parts in any given order, following the rules that
result from that given order, but not in parallel. Furthermore, the
construct is incorrect if execution of these parts in a different
order would have a different effect. Compilers are not required to
provide either compilation-time or run-time detection of incorrect
order dependences. The foregoing is expressed in terms of the process
that is called execution; it applies equally to the processes that
are called evaluation and elaboration.
If a compiler is able to recognize at compilation time that a construct is
erroneous or contains an incorrect order dependence, then the compiler is
allowed to generate, in place of the code otherwise generated for the
construct, code that raises the predefined exception PROGRAM_ERROR.
Similarly, compilers are allowed to generate code that checks at run time
for erroneous constructs, for incorrect order dependences, or for both.
The predefined exception PROGRAM_ERROR is raised if such a check fails.
1 - 17

 December 5, 2017  Add comments

Leave a Reply