=====================================================================
INTERNATIONAL STANDARD ISO/IEC 8652:2007(E),
Ed. 3
=====================================================================
Information technology - Programming
Languages - Ada
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.
1.1 Scope
1 This International Standard specifies the form and meaning of programs
written in Ada. Its purpose is to promote the portability of Ada programs to a
variety of data processing systems.
1.1.1 Extent
1 This International Standard specifies:
2 * The form of a program written in Ada;
3 * The effect of translating and executing such a program;
4 * The manner in which program units may be combined to form Ada programs;
5 * The language-defined library units that a conforming implementation is
required to supply;
6 * The permissible variations within the standard, and the manner in
which they are to be documented;
7 * Those violations of the standard that a conforming implementation is
required to detect, and the effect of attempting to translate or
execute a program containing such violations;
8 * Those violations of the standard that a conforming implementation is
not required to detect.
9 This International Standard does not specify:
10 * The means whereby a program written in Ada is transformed into object
code executable by a processor;
11 * The means whereby translation or execution of programs is invoked and
the executing units are controlled;
12 * The size or speed of the object code, or the relative execution speed
of different language constructs;
13 * The form or contents of any listings produced by implementations; in
particular, the form or contents of error or warning messages;
14 * The effect of unspecified execution.
15 * The size of a program or program unit that will exceed the capacity of
a particular conforming implementation.
1.1.2 Structure
1 This International Standard contains thirteen sections, fourteen annexes,
and an index.
2 The core of the Ada language consists of:
3 * Sections 1 through 13
4 * Annex A, "Predefined Language Environment"
5 * Annex B, "Interface to Other Languages"
6 * Annex J, "Obsolescent Features"
7 The following Specialized Needs Annexes define features that are needed by
certain application areas:
8 * Annex C, "Systems Programming"
9 * Annex D, "Real-Time Systems"
10 * Annex E, "Distributed Systems"
11 * Annex F, "Information Systems"
12 * Annex G, "Numerics"
13 * Annex H, "High Integrity Systems"
14 The core language and the Specialized Needs Annexes are normative, except
that the material in each of the items listed below is informative:
15 * Text under a NOTES or Examples heading.
16 * Each clause or subclause whose title starts with the word "Example" or
"Examples".
17 All implementations shall conform to the core language. In addition, an
implementation may conform separately to one or more Specialized Needs Annexes.
18 The following Annexes are informative:
19 * Annex K, "Language-Defined Attributes"
20 * Annex L, "Language-Defined Pragmas"
21 * M.2, "Implementation-Defined Characteristics"
22 * Annex N, "Glossary"
23 * Annex P, "Syntax Summary"
24 Each section is divided into clauses and subclauses that have a common
structure. Each section, clause, and subclause first introduces its subject.
After the introductory text, text is labeled with the following headings:
Syntax
25 Syntax rules (indented).
Name Resolution Rules
26 Compile-time rules that are used in name resolution, including overload
resolution.
Legality Rules
27 Rules that are enforced at compile time. A construct is legal if it obeys
all of the Legality Rules.
Static Semantics
28 A definition of the compile-time effect of each construct.
Post-Compilation Rules
29 Rules that are enforced before running a partition. A partition is legal
if its compilation units are legal and it obeys all of the
Post-Compilation Rules.
Dynamic Semantics
30 A definition of the run-time effect of each construct.
Bounded (Run-Time) Errors
31 Situations that result in bounded (run-time) errors (see 1.1.5).
Erroneous Execution
32 Situations that result in erroneous execution (see 1.1.5).
Implementation Requirements
33 Additional requirements for conforming implementations.
Documentation Requirements
34 Documentation requirements for conforming implementations.
Metrics
35 Metrics that are specified for the time/space properties of the execution
of certain language constructs.
Implementation Permissions
36 Additional permissions given to the implementer.
Implementation Advice
37 Optional advice given to the implementer. The word "should" is used to
indicate that the advice is a recommendation, not a requirement. It is
implementation defined whether or not a given recommendation is obeyed.
NOTES
38 1 Notes emphasize consequences of the rules described in the
(sub)clause or elsewhere. This material is informative.
Examples
39 Examples illustrate the possible forms of the constructs described. This
material is informative.
1.1.3 Conformity of an Implementation with the Standard
Implementation Requirements
1 A conforming implementation shall:
2 * Translate and correctly execute legal programs written in Ada,
provided that they are not so large as to exceed the capacity of the
implementation;
3 * Identify all programs or program units that are so large as to exceed
the capacity of the implementation (or raise an appropriate exception
at run time);
4 * Identify all programs or program units that contain errors whose
detection is required by this International Standard;
5 * Supply all language-defined library units required by this
International Standard;
6 * Contain no variations except those explicitly permitted by this
International Standard, or those that are impossible or impractical to
avoid given the implementation's execution environment;
7 * Specify all such variations in the manner prescribed by this
International Standard.
8 The external effect of the execution of an Ada program is defined in terms
of its interactions with its external environment. The following are defined
as external interactions:
9 * Any interaction with an external file (see A.7);
10 * The execution of certain code_statements (see 13.8); which
code_statements cause external interactions is implementation defined.
11 * Any call on an imported subprogram (see Annex B), including any
parameters passed to it;
12 * Any result returned or exception propagated from a main subprogram
(see 10.2) or an exported subprogram (see Annex B) to an external
caller;
13 * Any read or update of an atomic or volatile object (see C.6);
14 * The values of imported and exported objects (see Annex B) at the time
of any other interaction with the external environment.
15 A conforming implementation of this International Standard shall produce
for the execution of a given Ada program a set of interactions with the
external environment whose order and timing are consistent with the
definitions and requirements of this International Standard for the semantics
of the given program.
16 An implementation that conforms to this Standard shall support each
capability required by the core language as specified. In addition, an
implementation that conforms to this Standard may conform to one or more
Specialized Needs Annexes (or to none). Conformance to a Specialized Needs
Annex means that each capability required by the Annex is provided as
specified.
17 An implementation conforming to this International Standard may provide
additional attributes, library units, and pragmas. However, it shall not
provide any attribute, library unit, or pragma having the same name as an
attribute, library unit, or pragma (respectively) specified in a Specialized
Needs Annex unless the provided construct is either as specified in the
Specialized Needs Annex or is more limited in capability than that required by
the Annex. A program that attempts to use an unsupported capability of an
Annex shall either be identified by the implementation before run time or
shall raise an exception at run time.
Documentation Requirements
18 Certain aspects of the semantics are defined to be either implementation
defined or unspecified. In such cases, the set of possible effects is
specified, and the implementation may choose any effect in the set.
Implementations shall document their behavior in implementation-defined
situations, but documentation is not required for unspecified situations. The
implementation-defined characteristics are summarized in M.2.
19 The implementation may choose to document implementation-defined behavior
either by documenting what happens in general, or by providing some mechanism
for the user to determine what happens in a particular case.
Implementation Advice
20 If an implementation detects the use of an unsupported Specialized Needs
Annex feature at run time, it should raise Program_Error if feasible.
21 If an implementation wishes to provide implementation-defined extensions
to the functionality of a language-defined library unit, it should normally do
so by adding children to the library unit.
NOTES
22 2 The above requirements imply that an implementation conforming to
this Standard may support some of the capabilities required by a
Specialized Needs Annex without supporting all required capabilities.
1.1.4 Method of Description and Syntax Notation
1 The form of an Ada program is described by means of a context-free syntax
together with context-dependent requirements expressed by narrative rules.
2 The meaning of Ada programs is described by means of narrative rules
defining both the effects of each construct and the composition rules for
constructs.
3 The context-free syntax of the language is described using a simple
variant of Backus-Naur Form. In particular:
4 * Lower case words in a sans-serif font, some containing embedded
underlines, are used to denote syntactic categories, for example:
5 case_statement
6 * Boldface words are used to denote reserved words, for example:
7 array
8 * Square brackets enclose optional items. Thus the two following rules
are equivalent.
9/2 simple_return_statement ::= return [expression];
simple_return_statement ::= return; | return expression;
10 * Curly brackets 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.
11 term ::= factor {multiplying_operator factor}
term ::= factor | term multiplying_operator factor
12 * A vertical line separates alternative items unless it occurs
immediately after an opening curly bracket, in which case it stands
for itself:
13 constraint ::= scalar_constraint | composite_constraint
discrete_choice_list ::= discrete_choice {| discrete_choice}
14 * 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 subtype_name and task_name are both equivalent to name alone.
14.1/2 The delimiters, compound delimiters, reserved words, and
numeric_literals are exclusively made of the characters whose code position is
between 16#20# and 16#7E#, inclusively. The special characters for which names
are defined in this International Standard (see 2.1) belong to the same range.
For example, the character E in the definition of exponent is the character
whose name is "LATIN CAPITAL LETTER E", not "GREEK CAPITAL LETTER EPSILON".
14.2/2 When this International Standard mentions the conversion of some
character or sequence of characters to upper case, it means the character or
sequence of characters obtained by using locale-independent full case folding,
as defined by documents referenced in the note in section 1 of ISO/IEC
10646:2003.
15 A syntactic category is a nonterminal in the grammar defined in BNF under
"Syntax." Names of syntactic categories are set in a different font,
like_this.
16 A construct is a piece of text (explicit or implicit) that is an instance
of a syntactic category defined under "Syntax".
17 A constituent of a construct is the construct itself, or any construct
appearing within it.
18 Whenever the run-time semantics defines certain actions to happen in an
arbitrary order, this means that the implementation shall arrange for these
actions to occur in a way that is equivalent to some sequential order,
following the rules that result from that sequential order. When evaluations
are defined to happen in an arbitrary order, with conversion of the results to
some subtypes, or with some run-time checks, the evaluations, conversions, and
checks may be arbitrarily interspersed, so long as each expression is
evaluated before converting or checking its value. Note that the effect of a
program can depend on the order chosen by the implementation. This can happen,
for example, if two actual parameters of a given call have side effects.
NOTES
19 3 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:
20 if_statement ::=
if condition then
sequence_of_statements
{elsif condition then
sequence_of_statements}
[else
sequence_of_statements]
end if;
21 4 The line breaks and indentation in the syntax rules indicate the
recommended line breaks and indentation in the corresponding
constructs. The preferred places for other line breaks are after
semicolons.
1.1.5 Classification of Errors
Implementation Requirements
1 The language definition classifies errors into several different
categories:
2 * Errors that are required to be detected prior to run time by every Ada
implementation;
3 These errors correspond to any violation of a rule given in this
International Standard, other than those listed below. In particular,
violation of any rule that uses the terms shall, allowed, permitted,
legal, or illegal belongs to this category. Any program that contains
such an error is not a legal Ada program; on 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.
4 The rules are further classified as either compile time rules, or post
compilation rules, depending on whether a violation has to be detected
at the time a compilation unit is submitted to the compiler, or may be
postponed until the time a compilation unit is incorporated into a
partition of a program.
5 * Errors that are required to be detected at run time by the execution
of an Ada program;
6 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 such an error situation
is certain to arise in every execution of a construct, then an
implementation is allowed (although not required) to report this fact
at compilation time.
7 * Bounded errors;
8 The language rules define certain kinds of errors that need not be
detected either prior to or during run time, but if not detected, the
range of possible effects shall be bounded. The errors of this
category are called bounded errors. The possible effects of a given
bounded error are specified for each such error, but in any case one
possible effect of a bounded error is the raising of the exception
Program_Error.
9 * Erroneous execution.
10 In addition to bounded errors, the language rules define certain kinds
of errors as leading to erroneous execution. Like bounded errors, the
implementation need not detect such errors either prior to or during
run time. Unlike bounded errors, there is no language-specified bound
on the possible effect of erroneous execution; the effect is in
general not predictable.
Implementation Permissions
11 An implementation may provide nonstandard modes of operation. Typically
these modes would be selected by a pragma or by a command line switch when the
compiler is invoked. When operating in a nonstandard mode, the implementation
may reject compilation_units that do not conform to additional requirements
associated with the mode, such as an excessive number of warnings or violation
of coding style guidelines. Similarly, in a nonstandard mode, the
implementation may apply special optimizations or alternative algorithms that
are only meaningful for programs that satisfy certain criteria specified by
the implementation. In any case, an implementation shall support a standard
mode that conforms to the requirements of this International Standard; in
particular, in the standard mode, all legal compilation_units shall be
accepted.
Implementation Advice
12 If an implementation detects a bounded error or erroneous execution, it
should raise Program_Error.
1.2 Normative References
1 The following standards contain provisions which, through reference in
this text, constitute provisions of this International Standard. At the time
of publication, the editions indicated were valid. All standards are subject
to revision, and parties to agreements based on this International Standard
are encouraged to investigate the possibility of applying the most recent
editions of the standards indicated below. Members of IEC and ISO maintain
registers of currently valid International Standards.
2 ISO/IEC 646:1991, Information technology - ISO 7-bit coded character set
for information interchange.
3/2 ISO/IEC 1539-1:2004, Information technology - Programming languages -
Fortran - Part 1: Base language.
4/2 ISO/IEC 1989:2002, Information technology - Programming languages - COBOL.
5 ISO/IEC 6429:1992, Information technology - Control functions for coded
graphic character sets.
5.1/2 ISO 8601:2004, Data elements and interchange formats - Information
interchange - Representation of dates and times.
6 ISO/IEC 8859-1:1987, Information processing - 8-bit single-byte coded
character sets - Part 1: Latin alphabet No. 1.
7/2 ISO/IEC 9899:1999, Programming languages - C, supplemented by Technical
Corrigendum 1:2001 and Technical Corrigendum 2:2004.
8/2 ISO/IEC 10646:2003, Information technology - Universal Multiple-Octet
Coded Character Set (UCS).
9/2 ISO/IEC 14882:2003, Programming languages - C++.
10/2 ISO/IEC TR 19769:2004, Information technology - Programming languages,
their environments and system software interfaces - Extensions for the
programming language C to support new character data types.
1.3 Definitions
1/2 Terms are defined throughout this International Standard, indicated by
italic type. Terms explicitly defined in this International Standard are not
to be presumed to refer implicitly to similar terms defined elsewhere.
Mathematical terms not defined in this International Standard are to be
interpreted according to the CRC Concise Encyclopedia of Mathematics, Second
Edition. Other terms not defined in this International Standard are to be
interpreted according to the Webster's Third New International Dictionary of
the English Language. Informal descriptions of some terms are also given in
Annex N, "Glossary".
Generated by dwww version 1.15 on Sat May 18 08:01:18 CEST 2024.