10 Program Structure and Compilation Issues
1/3 {AI05-0299-1} [The overall structure of programs and the facilities for
separate compilation are described in this clause. A program is a set of
partitions, each of which may execute in a separate address space, possibly on
a separate computer.
1.a Glossary entry: A program is a set of partitions, each of which
may execute in a separate address space, possibly on a separate
computer. A partition consists of a set of library units.
1.b Glossary entry: A partition is a part of a program. Each partition
consists of a set of library units. Each partition may run in a
separate address space, possibly on a separate computer. A program
may contain just one partition. A distributed program typically
contains multiple partitions, which can execute concurrently.
2 As explained below, a partition is constructed from library units.
Syntactically, the declaration of a library unit is a library_item, as is the
body of a library unit. An implementation may support a concept of a program
library (or simply, a "library"), which contains library_items and their
subunits. Library units may be organized into a hierarchy of children,
grandchildren, and so on.]
3/3 {AI05-0299-1} This clause has two subclauses: 10.1, "
Separate Compilation" discusses compile-time issues related to separate
compilation. 10.2, "Program Execution" discusses issues related to what is
traditionally known as "link time" and "run time" - building and executing
partitions.
Language Design Principles
3.a We should avoid specifying details that are outside the domain of
the language itself. The standard is intended (at least in part)
to promote portability of Ada programs at the source level. It is
not intended to standardize extra-language issues such as how one
invokes the compiler (or other tools), how one's source is
represented and organized, version management, the format of error
messages, etc.
3.b The rules of the language should be enforced even in the presence
of separate compilation. Using separate compilation should not
make a program less safe.
3.c It should be possible to determine the legality of a compilation
unit by looking only at the compilation unit itself and the
compilation units upon which it depends semantically. As an
example, it should be possible to analyze the legality of two
compilation units in parallel if they do not depend semantically
upon each other.
3.d On the other hand, it may be necessary to look outside that set in
order to generate code - this is generally true for generic
instantiation and inlining, for example. Also on the other hand,
it is generally necessary to look outside that set in order to
check Post-Compilation Rules.
3.e See also the "generic contract model" Language Design Principle of
12.3, "Generic Instantiation".
Wording Changes from Ada 83
3.f/3 {AI05-0299-1} The clause organization mentioned above is different
from that of RM83.
10.1 Separate Compilation
1 [ A program unit is either a package, a task unit, a protected unit, a
protected entry, a generic unit, or an explicitly declared subprogram other
than an enumeration literal. Certain kinds of program units can be separately
compiled. Alternatively, they can appear physically nested within other
program units.
2 The text of a program can be submitted to the compiler in one or more
compilations. Each compilation is a succession of compilation_units. A
compilation_unit contains either the declaration, the body, or a renaming of a
program unit.] The representation for a compilation is implementation-defined.
2.a Implementation defined: The representation for a compilation.
2.b Ramification: Some implementations might choose to make a
compilation be a source (text) file. Others might allow multiple
source files to be automatically concatenated to form a single
compilation. Others still may represent the source in a nontextual
form such as a parse tree. Note that the RM95 does not even define
the concept of a source file.
2.c Note that a protected subprogram is a subprogram, and therefore a
program unit. An instance of a generic unit is a program unit.
2.d A protected entry is a program unit, but protected entries cannot
be separately compiled.
3 A library unit is a separately compiled program unit, and is always a
package, subprogram, or generic unit. Library units may have other (logically
nested) library units as children, and may have other program units physically
nested within them. A root library unit, together with its children and
grandchildren and so on, form a subsystem.
Implementation Permissions
4 An implementation may impose implementation-defined restrictions on
compilations that contain multiple compilation_units.
4.a Implementation defined: Any restrictions on compilations that
contain multiple compilation_units.
4.b Discussion: For example, an implementation might disallow a
compilation that contains two versions of the same compilation
unit, or that contains the declarations for library packages P1
and P2, where P1 precedes P2 in the compilation but P1 has a
with_clause that mentions P2.
Wording Changes from Ada 83
4.c The interactions between language issues and environmental issues
are left open in Ada 95. The environment concept is new. In Ada
83, the concept of the program library, for example, appeared to
be quite concrete, although the rules had no force, since
implementations could get around them simply by defining various
mappings from the concept of an Ada program library to whatever
data structures were actually stored in support of separate
compilation. Indeed, implementations were encouraged to do so.
4.d In RM83, it was unclear which was the official definition of "
program unit." Definitions appeared in RM83-5, 6, 7, and 9, but
not 12. Placing it here seems logical, since a program unit is
sort of a potential compilation unit.
10.1.1 Compilation Units - Library Units
1 [A library_item is a compilation unit that is the declaration, body, or
renaming of a library unit. Each library unit (except Standard) has a parent
unit, which is a library package or generic library package.] A library unit
is a child of its parent unit. The root library units are the children of the
predefined library package Standard.
1.a Ramification: Standard is a library unit.
Syntax
2 compilation ::= {compilation_unit}
3 compilation_unit ::=
context_clause library_item
| context_clause subunit
4 library_item ::= [private] library_unit_declaration
| library_unit_body
| [private] library_unit_renaming_declaration
5 library_unit_declaration ::=
subprogram_declaration | package_declaration
| generic_declaration | generic_instantiation
6 library_unit_renaming_declaration ::=
package_renaming_declaration
| generic_renaming_declaration
| subprogram_renaming_declaration
7 library_unit_body ::= subprogram_body | package_body
8 parent_unit_name ::= name
8.1/2 {AI95-00397-01} An overriding_indicator is not allowed in a
subprogram_declaration, generic_instantiation, or
subprogram_renaming_declaration that declares a library unit.
8.a.1/2 Reason: All of the listed items syntactically include
overriding_indicator, but a library unit can never override
anything. A majority of the ARG thought that allowing not
overriding in that case would be confusing instead of helpful.
9 A library unit is a program unit that is declared by a library_item. When
a program unit is a library unit, the prefix "library" is used to refer to it
(or "generic library" if generic), as well as to its declaration and body, as
in "library procedure", "library package_body", or "generic library package".
The term compilation unit is used to refer to a compilation_unit. When the
meaning is clear from context, the term is also used to refer to the
library_item of a compilation_unit or to the proper_body of a subunit [(that
is, the compilation_unit without the context_clause and the separate
(parent_unit_name))].
9.a Discussion: In this example:
9.b with Ada.Text_IO;
package P is
...
end P;
9.c the term "compilation unit" can refer to this text: "with
Ada.Text_IO; package P is ... end P;" or to this text: "package P
is ... end P;". We use this shorthand because it corresponds to
common usage.
9.d We like to use the word "unit" for declaration-plus-body things,
and "item" for declaration or body separately (as in
declarative_item). The terms "compilation_unit," "compilation
unit," and "subunit" are exceptions to this rule. We considered
changing "compilation_unit," "compilation unit" to "
compilation_item," "compilation item," respectively, but we
decided not to.
10 The parent declaration of a library_item (and of the library unit) is the
declaration denoted by the parent_unit_name, if any, of the defining_program_-
unit_name of the library_item. If there is no parent_unit_name, the parent
declaration is the declaration of Standard, the library_item is a root
library_item, and the library unit (renaming) is a root library unit
(renaming). The declaration and body of Standard itself have no parent
declaration. The parent unit of a library_item or library unit is the library
unit declared by its parent declaration.
10.a Discussion: The declaration and body of Standard are presumed to
exist from the beginning of time, as it were. There is no way to
actually write them, since there is no syntactic way to indicate
lack of a parent. An attempt to compile a package Standard would
result in Standard.Standard.
10.b Reason: Library units (other than Standard) have "parent
declarations" and "parent units". Subunits have "parent bodies".
We didn't bother to define the other possibilities: parent body of
a library unit, parent declaration of a subunit, parent unit of a
subunit. These are not needed, and might get in the way of a
correct definition of "child."
11 [The children of a library unit occur immediately within the declarative
region of the declaration of the library unit.] The ancestors of a library
unit are itself, its parent, its parent's parent, and so on. [(Standard is an
ancestor of every library unit.)] The descendant relation is the inverse of
the ancestor relation.
11.a Reason: These definitions are worded carefully to avoid defining
subunits as children. Only library units can be children.
11.b We use the unadorned term "ancestors" here to concisely define
both "ancestor unit" and "ancestor declaration."
12 A library_unit_declaration or a library_unit_renaming_declaration is
private if the declaration is immediately preceded by the reserved word
private; it is otherwise public. A library unit is private or public according
to its declaration. The public descendants of a library unit are the library
unit itself, and the public descendants of its public children. Its other
descendants are private descendants.
12.a Discussion: The first concept defined here is that a
library_item is either public or private (not in relation to
anything else - it's just a property of the library unit). The
second concept is that a library_item is a public descendant or
private descendant of a given ancestor. A given library_item can
be a public descendant of one of its ancestors, but a private
descendant of some other ancestor.
12.b A subprogram declared by a subprogram_body (as opposed to a
subprogram_declaration) is always public, since the syntax rules
disallow the reserved word private on a body.
12.c Note that a private library unit is a public descendant of itself,
but a private descendant of its parent. This is because it is
visible outside itself - its privateness means that it is not
visible outside its parent.
12.d Private children of Standard are legal, and follow the normal
rules. It is intended that implementations might have some method
for taking an existing environment, and treating it as a package
to be "imported" into another environment, treating children of
Standard in the imported environment as children of the imported
package.
12.e Ramification: Suppose we have a public library unit A, a private
library unit A.B, and a public library unit A.B.C. A.B.C is a
public descendant of itself and of A.B, but a private descendant
of A; since A.B is private to A, we don't allow A.B.C to escape
outside A either. This is similar to the situation that would
occur with physical nesting, like this:
12.f package A is
private
package B is
package C is
end C;
private
end B;
end A;
12.g Here, A.B.C is visible outside itself and outside A.B, but not
outside A. (Note that this example is intended to illustrate the
visibility of program units from the outside; the visibility
within child units is not quite identical to that of physically
nested units, since child units are nested after their parent's
declaration.)
12.1/2 {AI95-00217-06} For each library package_declaration in the
environment, there is an implicit declaration of a limited view of that
library package. The limited view of a package contains:
12.2/3 * {AI95-00217-06} {AI05-0129-1} {AI05-0262-1} For each
package_declaration occurring immediately within the visible part, a
declaration of the limited view of that package, with the same
defining_program_unit_name.
12.3/3 * {AI95-00217-06} {AI95-00326-01} {AI05-0108-1} {AI05-0129-1}
{AI05-0262-1} For each type_declaration occurring immediately within
the visible part that is not an incomplete_type_declaration, an
incomplete view of the type with no discriminant_part; if the
type_declaration is tagged, then the view is a tagged incomplete view.
12.g.1/3 Reason: {AI05-0108-1} The incomplete view of a type does not have
a discriminant_part even if the type_declaration does have one.
This is necessary because semantic analysis (and the associated
dependence on with_clauses) would be necessary to determine the
types of the discriminants.
12.g.2/3 {AI05-0129-1} No incomplete views of incomplete types are included
in the limited view. The rules of 3.10.1 ensure that the
completion of any visible incomplete type is declared in the same
visible part, so such an incomplete view would simply be
redundant.
12.g.3/2 Discussion: {AI95-00217-06} The implementation model of a limited
view is that it can be determined solely from the syntax of the
source of the unit, without any semantic analysis. That allows it
to be created without the semantic dependences of a full unit,
which is necessary for it to break mutual dependences of units.
12.g.4/2 Ramification: The limited view does not include package instances
and their contents. Semantic analysis of a unit (and dependence on
its with_clauses) would be needed to determine the contents of an
instance.
12.4/2 The limited view of a library package_declaration is private if that
library package_declaration is immediately preceded by the reserved word
private.
12.5/2 [There is no syntax for declaring limited views of packages, because
they are always implicit.] The implicit declaration of a limited view of a
library package [is not the declaration of a library unit (the library
package_declaration is); nonetheless, it] is a library_item. The implicit
declaration of the limited view of a library package forms an (implicit)
compilation unit whose context_clause is empty.
12.6/2 A library package_declaration is the completion of the declaration of
its limited view.
12.h/2 To be honest: This is notwithstanding the rule in 3.11.1 that says
that implicit declarations don't have completions.
12.i/2 Reason: This rule explains where to find the completions of the
incomplete views defined by the limited view.
Legality Rules
13 The parent unit of a library_item shall be a [library] package or generic
[library] package.
14 If a defining_program_unit_name of a given declaration or body has a
parent_unit_name, then the given declaration or body shall be a library_item.
The body of a program unit shall be a library_item if and only if the
declaration of the program unit is a library_item. In a library_unit_renaming_-
declaration, the [(old)] name shall denote a library_item.
14.a Discussion: We could have allowed nested program units to be
children of other program units; their semantics would make sense.
We disallow them to keep things simpler and because they wouldn't
be particularly useful.
15/2 {AI95-00217-06} A parent_unit_name [(which can be used within a
defining_program_unit_name of a library_item and in the separate clause of a
subunit)], and each of its prefixes, shall not denote a renaming_declaration.
[On the other hand, a name that denotes a library_unit_renaming_declaration is
allowed in a nonlimited_with_clause and other places where the name of a
library unit is allowed.]
16 If a library package is an instance of a generic package, then every child
of the library package shall either be itself an instance or be a renaming of
a library unit.
16.a Discussion: A child of an instance of a given generic unit will
often be an instance of a (generic) child of the given generic
unit. This is not required, however.
16.b Reason: Instances are forbidden from having noninstance children
for two reasons:
16.c 1. We want all source code that can depend on information from
the private part of a library unit to be inside the
"subsystem" rooted at the library unit. If an instance of a
generic unit were allowed to have a noninstance as a child,
the source code of that child might depend on information from
the private part of the generic unit, even though it is
outside the subsystem rooted at the generic unit.
16.d 2. Disallowing noninstance children simplifies the description of
the semantics of children of generic packages.
17/3 {AI05-0004-1} A child of a generic library package shall either be itself
a generic unit or be a renaming of some other child of the same generic unit.
18 A child of a parent generic package shall be instantiated or renamed only
within the declarative region of the parent generic.
19/2 {AI95-00331-01} For each child C of some parent generic package P, there
is a corresponding declaration C nested immediately within each instance of P.
For the purposes of this rule, if a child C itself has a child D, each
corresponding declaration for C has a corresponding child D. [The
corresponding declaration for a child within an instance is visible only
within the scope of a with_clause that mentions the (original) child generic
unit.]
19.a Implementation Note: Within the child, like anything nested in a
generic unit, one can make up-level references to the current
instance of its parent, and thereby gain access to the formal
parameters of the parent, to the types declared in the parent,
etc. This "nesting" model applies even within the
generic_formal_part of the child, as it does for a generic child
of a nongeneric unit.
19.b Ramification: Suppose P is a generic library package, and P.C is a
generic child of P. P.C can be instantiated inside the declarative
region of P. Outside P, P.C can be mentioned only in a
with_clause. Conceptually, an instance I of P is a package that
has a nested generic unit called I.C. Mentioning P.C in a
with_clause allows I.C to be instantiated. I need not be a library
unit, and the instantiation of I.C need not be a library unit. If
I is a library unit, and an instance of I.C is a child of I, then
this instance has to be called something other than C.
20 A library subprogram shall not override a primitive subprogram.
20.a Reason: This prevents certain obscure anomalies. For example, if a
library subprogram were to override a subprogram declared in its
parent package, then in a compilation unit that depends indirectly
on the library subprogram, the library subprogram could hide the
overridden operation from all visibility, but the library
subprogram itself would not be visible.
20.b Note that even without this rule, such subprograms would be
illegal for tagged types, because of the freezing rules.
21 The defining name of a function that is a compilation unit shall not be an
operator_symbol.
21.a Reason: Since overloading is not permitted among compilation
units, it seems unlikely that it would be useful to define one as
an operator. Note that a subunit could be renamed within its
parent to be an operator.
Static Semantics
22 A subprogram_renaming_declaration that is a
library_unit_renaming_declaration is a renaming-as-declaration, not a
renaming-as-body.
23 [There are two kinds of dependences among compilation units:]
24 * [The semantic dependences (see below) are the ones needed to check the
compile-time rules across compilation unit boundaries; a compilation
unit depends semantically on the other compilation units needed to
determine its legality. The visibility rules are based on the semantic
dependences.
25 * The elaboration dependences (see 10.2) determine the order of
elaboration of library_items.]
25.a Discussion: Don't confuse these kinds of dependences with the
run-time dependences among tasks and masters defined in 9.3, "
Task Dependence - Termination of Tasks".
26/2 {AI95-00217-06} A library_item depends semantically upon its parent
declaration. A subunit depends semantically upon its parent body. A
library_unit_body depends semantically upon the corresponding
library_unit_declaration, if any. The declaration of the limited view of a
library package depends semantically upon the declaration of the limited view
of its parent. The declaration of a library package depends semantically upon
the declaration of its limited view. A compilation unit depends semantically
upon each library_item mentioned in a with_clause of the compilation unit. In
addition, if a given compilation unit contains an attribute_reference of a
type defined in another compilation unit, then the given compilation unit
depends semantically upon the other compilation unit. The semantic dependence
relationship is transitive.
26.a Discussion: The "if any" in the third sentence is necessary
because library subprograms are not required to have a
subprogram_declaration.
26.b To be honest: If a given compilation unit contains a
choice_parameter_specification, then the given compilation unit
depends semantically upon the declaration of Ada.Exceptions.
26.c If a given compilation unit contains a pragma with an argument of
a type defined in another compilation unit, then the given
compilation unit depends semantically upon the other compilation
unit.
26.d Discussion: For example, a compilation unit containing X'Address
depends semantically upon the declaration of package System.
26.e For the Address attribute, this fixes a hole in Ada 83. Note that
in almost all cases, the dependence will need to exist due to
with_clauses, even without this rule. Hence, the rule has very
little effect on programmers.
26.f Note that the semantic dependence does not have the same effect as
a with_clause; in order to denote a declaration in one of those
packages, a with_clause will generally be needed.
26.g Note that no special rule is needed for an
attribute_definition_clause, since an expression after use will
require semantic dependence upon the compilation unit containing
the type_declaration of interest.
26.h/2 {AI95-00217-06} Unlike a full view of a package, a limited view
does not depend semantically on units mentioned in with_clauses of
the compilation_unit that defines the package. Formally, this is
achieved by saying that the limited view has an empty
context_clause. This is necessary so that they can be useful for
their intended purpose: allowing mutual dependences between
packages. The lack of semantic dependence limits the contents of a
limited view to the items that can be determined solely from the
syntax of the source of the package, without any semantic
analysis. That allows it to be created without the semantic
dependences of a full package.
Dynamic Semantics
26.1/2 {AI95-00217-06} The elaboration of the declaration of the limited view
of a package has no effect.
NOTES
27 1 A simple program may consist of a single compilation unit. A
compilation need not have any compilation units; for example, its text
can consist of pragmas.
27.a Ramification: Such pragmas cannot have any arguments that are
names, by a previous rule of this subclause. A compilation can
even be entirely empty, which is probably not useful.
27.b Some interesting properties of the three kinds of dependence: The
elaboration dependences also include the semantic dependences,
except that subunits are taken together with their parents. The
semantic dependences partly determine the order in which the
compilation units appear in the environment at compile time. At
run time, the order is partly determined by the elaboration
dependences.
27.c The model whereby a child is inside its parent's declarative
region, after the parent's declaration, as explained in 8.1, has
the following ramifications:
27.d * The restrictions on "early" use of a private type
(RM83-7.4.1(4)) or a deferred constant (RM83-7.4.3(2)) do not
apply to uses in child units, because they follow the full
declaration.
27.e * A library subprogram is never primitive, even if its profile
includes a type declared immediately within the parent's
package_specification, because the child is not declared
immediately within the same package_specification as the type
(so it doesn't declare a new primitive subprogram), and
because the child is forbidden from overriding an old
primitive subprogram. It is immediately within the same
declarative region, but not the same package_specification.
Thus, for a tagged type, it is not possible to call a child
subprogram in a dispatching manner. (This is also forbidden by
the freezing rules.) Similarly, it is not possible for the
user to declare primitive subprograms of the types declared in
the declaration of Standard, such as Integer (even if the
rules were changed to allow a library unit whose name is an
operator symbol).
27.f * When the parent unit is "used" the simple names of the with'd
child units are directly visible (see 8.4, "Use Clauses").
27.g * When a parent body with's its own child, the defining name of
the child is directly visible, and the parent body is not
allowed to include a declaration of a homograph of the child
unit immediately within the declarative_part of the body
(RM83-8.3(17)).
27.h Note that "declaration of a library unit" is different from "
library_unit_declaration" - the former includes subprogram_body.
Also, we sometimes really mean "declaration of a view of a library
unit", which includes library_unit_renaming_declarations.
27.i The visibility rules generally imply that the renamed view of a
library_unit_renaming_declaration has to be mentioned in a with_-
clause of the library_unit_renaming_declaration.
27.j To be honest: The real rule is that the renamed library unit has
to be visible in the library_unit_renaming_declaration.
27.k Reason: In most cases, "has to be visible" means there has to be a
with_clause. However, it is possible in obscure cases to avoid the
need for a with_clause; in particular, a compilation unit such as
"package P.Q renames P;" is legal with no with_clauses (though not
particularly interesting). ASCII is physically nested in Standard,
and so is not a library unit, and cannot be renamed as a library
unit.
28 2 The designator of a library function cannot be an operator_symbol,
but a nonlibrary renaming_declaration is allowed to rename a library
function as an operator. Within a partition, two library subprograms
are required to have distinct names and hence cannot overload each
other. However, renaming_declarations are allowed to define overloaded
names for such subprograms, and a locally declared subprogram is
allowed to overload a library subprogram. The expanded name Standard.L
can be used to denote a root library unit L (unless the declaration of
Standard is hidden) since root library unit declarations occur
immediately within the declarative region of package Standard.
Examples
29 Examples of library units:
30 package Rational_Numbers.IO is -- public child of Rational_Numbers, see 7.1
procedure Put(R : in Rational);
procedure Get(R : out Rational);
end Rational_Numbers.IO;
31 private procedure Rational_Numbers.Reduce(R : in out Rational);
-- private child of Rational_Numbers
32 with Rational_Numbers.Reduce; -- refer to a private child
package body Rational_Numbers is
...
end Rational_Numbers;
33 with Rational_Numbers.IO; use Rational_Numbers;
with Ada.Text_io; -- see A.10
procedure Main is -- a root library procedure
R : Rational;
begin
R := 5/3; -- construct a rational number, see 7.1
Ada.Text_IO.Put("The answer is: ");
IO.Put(R);
Ada.Text_IO.New_Line;
end Main;
34 with Rational_Numbers.IO;
package Rational_IO renames Rational_Numbers.IO;
-- a library unit renaming declaration
35 Each of the above library_items can be submitted to the compiler
separately.
35.a Discussion: Example of a generic package with children:
35.b generic
type Element is private;
with function Image(E : Element) return String;
package Generic_Bags is
type Bag is limited private; -- A bag of Elements.
procedure Add(B : in out Bag; E : Element);
function Bag_Image(B : Bag) return String;
private
type Bag is ...;
end Generic_Bags;
35.c generic
package Generic_Bags.Generic_Iterators is
... -- various additional operations on Bags.
35.d generic
with procedure Use_Element(E : in Element);
-- Called once per bag element.
procedure Iterate(B : in Bag);
end Generic_Bags.Generic_Iterators;
35.e A package that instantiates the above generic units:
35.f with Generic_Bags;
with Generic_Bags.Generic_Iterators;
package My_Abstraction is
type My_Type is ...;
function Image(X : My_Type) return String;
package Bags_Of_My_Type is new Generic_Bags(My_Type, Image);
package Iterators_Of_Bags_Of_My_Type is new Bags_Of_My_Type.Generic_Iterators;
end My_Abstraction;
35.g In the above example, Bags_Of_My_Type has a nested generic unit
called Generic_Iterators. The second with_clause makes that nested
unit visible.
35.h Here we show how the generic body could depend on one of its own
children:
35.i with Generic_Bags.Generic_Iterators;
package body Generic_Bags is
procedure Add(B : in out Bag; E : Element) is ... end Add;
35.j package Iters is new Generic_Iterators;
35.k function Bag_Image(B : Bag) return String is
Buffer : String(1..10_000);
Last : Integer := 0;
35.l procedure Append_Image(E : in Element) is
Im : constant String := Image(E);
begin
if Last /= 0 then -- Insert a comma.
Last := Last + 1;
Buffer(Last) := ',';
end if;
Buffer(Last+1 .. Last+Im'Length) := Im;
Last := Last + Im'Length;
end Append_Image;
35.m procedure Append_All is new Iters.Iterate(Append_Image);
begin
Append_All(B);
return Buffer(1..Last);
end Bag_Image;
end Generic_Bags;
Extensions to Ada 83
35.n The syntax rule for library_item is modified to allow the reserved
word private before a library_unit_declaration.
35.o Children (other than children of Standard) are new in Ada 95.
35.p Library unit renaming is new in Ada 95.
Wording Changes from Ada 83
35.q Standard is considered a library unit in Ada 95. This simplifies
the descriptions, since it implies that the parent of each library
unit is a library unit. (Standard itself has no parent, of
course.) As in Ada 83, the language does not define any way to
recompile Standard, since the name given in the declaration of a
library unit is always interpreted in relation to Standard. That
is, an attempt to compile a package Standard would result in
Standard.Standard.
Extensions to Ada 95
35.r/2 {AI95-00217-06} The concept of a limited view is new. Combined
with limited_with_clauses (see 10.1.2), they facilitate
construction of mutually recursive types in multiple packages.
Wording Changes from Ada 95
35.s/2 {AI95-00331-01} Clarified the wording so that a grandchild generic
unit will work as expected.
Wording Changes from Ada 2005
35.t/3 {AI05-0108-1} {AI05-0129-1} Correction: Clarified the wording so
that it is clear that limited views of types never have
discriminants and never are of incomplete types.
10.1.2 Context Clauses - With Clauses
1 [A context_clause is used to specify the library_items whose names are
needed within a compilation unit.]
Language Design Principles
1.a The reader should be able to understand a context_clause without
looking ahead. Similarly, when compiling a context_clause, the
compiler should not have to look ahead at subsequent
context_items, nor at the compilation unit to which the
context_clause is attached. (We have not completely achieved this.)
1.b/2 {AI95-00217-06} A ripple effect occurs when the legality of a
compilation unit could be affected by adding or removing an
otherwise unneeded with_clause on some compilation unit on which
the unit depends, directly or indirectly. We try to avoid ripple
effects because they make understanding and maintenance more
difficult. However, ripple effects can occur because of direct
visibility (as in child units); this seems impossible to
eliminate. The ripple effect for with_clauses is somewhat similar
to the Beaujolais effect (see 8.4) for use_clauses, which we also
try to avoid.
Syntax
2 context_clause ::= {context_item}
3 context_item ::= with_clause | use_clause
4/2 {AI95-00217-06} {AI95-00262-01} with_clause ::= limited_with_clause
| nonlimited_with_clause
4.1/2 limited_with_clause ::= limited [private] with library_unit_name
{, library_unit_name};
4.2/2 nonlimited_with_clause ::= [private] with library_unit_name
{, library_unit_name};
4.a/2 Discussion: {AI95-00217-06} A limited_with_clause makes a limited
view of a unit visible.
4.b/2 {AI95-00262-01} A with_clause containing the reserved word private
is called a private with_clause. It can be thought of as making
items visible only in the private part, although it really makes
items visible everywhere except the visible part. It can be used
both for documentation purposes (to say that a unit is not used in
the visible part), and to allow access to private units that
otherwise would be prohibited.
Name Resolution Rules
5 The scope of a with_clause that appears on a library_unit_declaration or
library_unit_renaming_declaration consists of the entire declarative region of
the declaration[, which includes all children and subunits]. The scope of a
with_clause that appears on a body consists of the body[, which includes all
subunits].
5.a/2 Discussion: {AI95-00262-01} Suppose a nonprivate with_clause of a
public library unit mentions one of its private siblings. (This is
only allowed on the body of the public library unit.) We
considered making the scope of that with_clause not include the
visible part of the public library unit. (This would only matter
for a subprogram_body, since those are the only kinds of body that
have a visible part, and only if the subprogram_body completes a
subprogram_declaration, since otherwise the with_clause would be
illegal.) We did not put in such a rule for two reasons: (1) It
would complicate the wording of the rules, because we would have
to split each with_clause into pieces, in order to correctly
handle "with P, Q;" where P is public and Q is private. (2) The
conformance rules prevent any problems. It doesn't matter if a
type name in the spec of the body denotes the completion of a
private_type_declaration.
5.b A with_clause also affects visibility within subsequent
use_clauses and pragmas of the same context_clause, even though
those are not in the scope of the with_clause.
6/2 {AI95-00217-06} A library_item (and the corresponding library unit) is
named in a with_clause if it is denoted by a library_unit_name in the
with_clause. A library_item (and the corresponding library unit) is mentioned
in a with_clause if it is named in the with_clause or if it is denoted by a
prefix in the with_clause.
6.a/3 Discussion: {AI05-0299-1} With_clauses control the visibility of
declarations or renamings of library units. Mentioning a root
library unit in a with_clause makes its declaration directly
visible. Mentioning a nonroot library unit makes its declaration
visible. See Clause 8 for details.
6.b/2 {AI95-00114-01} Note that this rule implies that "with A.B.C;" is
almost equivalent to "with A, A.B, A.B.C;". The reason for making
a with_clause apply to all the ancestor units is to avoid "
visibility holes" - situations in which an inner program unit is
visible while an outer one is not. Visibility holes would cause
semantic complexity and implementation difficulty. (This is not
exactly equivalent because the latter with_clause names A and A.B,
while the previous one does not. Whether a unit is "named" does
not have any effect on visibility, however, so it is equivalent
for visibility purposes.)
7 [Outside its own declarative region, the declaration or renaming of a
library unit can be visible only within the scope of a with_clause that
mentions it. The visibility of the declaration or renaming of a library unit
otherwise follows from its placement in the environment.]
Legality Rules
8/2 {AI95-00262-01} If a with_clause of a given compilation_unit mentions a
private child of some library unit, then the given compilation_unit shall be
one of:
9/2 * {AI95-00262-01} the declaration, body, or subunit of a private
descendant of that library unit;
10/2 * {AI95-00220-01} {AI95-00262-01} the body or subunit of a public
descendant of that library unit, but not a subprogram body acting as a
subprogram declaration (see 10.1.4); or
11/2 * {AI95-00262-01} the declaration of a public descendant of that
library unit, in which case the with_clause shall include the reserved
word private.
11.a/2 Reason: {AI95-00262-01} The purpose of this rule is to prevent a
private child from being visible from outside the subsystem rooted
at its parent. A private child can be semantically depended-on
without violating this principle if it is used in a private
with_clause.
11.b Discussion: This rule violates the one-pass context_clauses
Language Design Principle. We rationalize this by saying that at
least that Language Design Principle works for legal compilation
units.
11.c Example:
11.d package A is
end A;
11.e package A.B is
end A.B;
11.f private package A.B.C is
end A.B.C;
11.g package A.B.C.D is
end A.B.C.D;
11.h with A.B.C; -- (1)
private package A.B.X is
end A.B.X;
11.i package A.B.Y is
end A.B.Y;
11.j with A.B.C; -- (2)
package body A.B.Y is
end A.B.Y;
11.j.1/2 private with A.B.C; -- (3)
package A.B.Z is
end A.B.Z;
11.k/2 {AI95-00262-01} (1) is OK because it's a private child of A.B - it
would be illegal if we made A.B.X a public child of A.B. (2) is OK
because it's the body of a child of A.B. (3) is OK because it's a
child of A.B, and it is a private with_clause. It would be illegal
to say "with A.B.C;" on any library_item whose name does not start
with "A.B". Note that mentioning A.B.C.D in a with_clause
automatically mentions A.B.C as well, so "with A.B.C.D;" is
illegal in the same places as "with A.B.C;".
12/3 {AI05-0005-1} {AI95-00262-01} {AI95-00262-01} {AI05-0077-1}
{AI05-0122-1} A name denoting a library_item (or the corresponding declaration
for a child of a generic within an instance - see 10.1.1), if it is visible
only due to being mentioned in one or more with_clauses that include the
reserved word private, shall appear only within:
13/2 * a private part;
14/2 * a body, but not within the subprogram_specification of a library
subprogram body;
15/2 * a private descendant of the unit on which one of these with_clauses
appear; or
16/2 * a pragma within a context clause.
16.a/2 Ramification: These rules apply only if all of the with_clauses
that mention the name include the reserved word private. They do
not apply if the name is mentioned in any with_clause that does
not include private.
16.b/3 Reason: {AI05-0077-1} These rules make the library_item visible
anywhere that is not visible outside the subsystem rooted at the
compilation_unit having the private with_clause, including private
parts of packages nested in the visible part, private parts of
child packages, the visible part of private children, and context
clause pragmas like Elaborate_All.
16.c/2 We considered having the scope of a private with_clause not
include the visible part. However, that rule would mean that
moving a declaration between the visible part and the private part
could change its meaning from one legal interpretation to a
different legal interpretation. For example:
16.d/2 package A is
function B return Integer;
end A;
16.e/2 function B return Integer;
16.f/2 with A;
private with B;
package C is
use A;
V1 : Integer := B; -- (1)
private
V2 : Integer := B; -- (2)
end C;
16.g/2 If we say that library subprogram B is not in scope in the visible
part of C, then the B at (1) resolves to A.B, while (2) resolves
to library unit B. Simply moving a declaration could silently
change its meaning. With the legality rule defined above, the B at
(1) is illegal. If the user really meant A.B, they still can say
that.
17/2 {AI95-00217-06} [A library_item mentioned in a limited_with_clause shall
be the implicit declaration of the limited view of a library package, not the
declaration of a subprogram, generic unit, generic instance, or a renaming.]
17.a/2 Proof: This is redundant because only such implicit declarations
are visible in a limited_with_clause. See 10.1.6.
18/2 {AI95-00217-06} {AI95-00412-01} A limited_with_clause shall not appear on
a library_unit_body, subunit, or library_unit_renaming_declaration.
18.a/2 Reason: {AI95-00412-01} We don't allow a limited_with_clause on a
library_unit_renaming_declaration because it would be useless and
therefore probably is a mistake. A renaming cannot appear in a
limited_with_clause (by the rule prior to this one), and a
renaming of a limited view cannot appear in a
nonlimited_with_clause (because the name would not be within the
scope of a with_clause denoting the package, see 8.5.3). Nor could
it be the parent of another unit. That doesn't leave anywhere that
the name of such a renaming could appear, so we simply make
writing it illegal.
19/2 {AI95-00217-06} A limited_with_clause that names a library package shall
not appear:
20/3 * {AI95-00217-06} {AI05-0040-1} in the context_clause for the explicit
declaration of the named library package or any of its descendants;
20.a/2 Reason: We have to explicitly disallow
20.b/2 limited with P;
package P is ...
20.c/2 as we can't depend on the semantic dependence rules to do it for
us as with regular withs. This says "named" and not "mentioned" in
order that
20.d/2 limited private with P.Child;
package P is ...
20.e/2 can be used to allow a mutual dependence between the private part
of P and the private child P.Child, which occurs in interfacing
and other problems. Since the child always semantically depends on
the parent, this is the only way such a dependence can be broken.
20.f/3 {AI05-0040-1} The part about descendants catches examples like
20.g/3 limited with P;
package P.Child is ...
21/3 * {AI95-00217-06} {AI05-0077-1} {AI05-0262-1} within a context_clause
for a library_item that is within the scope of a
nonlimited_with_clause that mentions the same library package; or
21.a.1/3 Ramification: {AI05-0077-1} This applies to
nonlimited_with_clauses found in the same context_clause, as well
as nonlimited_with_clauses found on parent units.
21.a/3 Reason: {AI05-0077-1} Such a limited_with_clause could have no
effect, and would be confusing. If a nonlimited_with_clause for
the same package is inherited from a parent unit or given in the
context_clause, the full view is available, which strictly
provides more information than the limited view.
22/3 * {AI95-00217-06} {AI05-0077-1} {AI05-0262-1} within a context_clause
for a library_item that is within the scope of a use_clause that names
an entity declared within the declarative region of the library
package.
22.a.1/3 Ramification: {AI05-0077-1} This applies to use_clauses found in
the same context_clause, as well as use_clauses found in (or on)
parent units.
22.a/2 Reason: This prevents visibility issues, where whether an entity
is an incomplete or full view depends on how the name of the
entity is written. The limited_with_clause cannot be useful, as we
must have the full view available in the parent in order for the
use_clause to be legal.
NOTES
23/2 3 {AI95-00217-06} A library_item mentioned in a
nonlimited_with_clause of a compilation unit is visible within the
compilation unit and hence acts just like an ordinary declaration.
Thus, within a compilation unit that mentions its declaration, the
name of a library package can be given in use_clauses and can be used
to form expanded names, a library subprogram can be called, and
instances of a generic library unit can be declared. If a child of a
parent generic package is mentioned in a nonlimited_with_clause, then
the corresponding declaration nested within each visible instance is
visible within the compilation unit. Similarly, a library_item
mentioned in a limited_with_clause of a compilation unit is visible
within the compilation unit and thus can be used to form expanded
names.
23.a Ramification: The rules given for with_clauses are such that the
same effect is obtained whether the name of a library unit is
mentioned once or more than once by the applicable with_clauses,
or even within a given with_clause.
23.b If a with_clause mentions a library_unit_renaming_declaration, it
only "mentions" the prefixes appearing explicitly in the
with_clause (and the renamed view itself); the with_clause is not
defined to mention the ancestors of the renamed entity. Thus, if X
renames Y.Z, then "with X;" does not make the declarations of Y or
Z visible. Note that this does not cause the dreaded visibility
holes mentioned above.
Examples
24/2 {AI95-00433-01} package Office is
end Office;
25/2 {AI95-00433-01} with Ada.Strings.Unbounded;
package Office.Locations is
type Location is new Ada.Strings.Unbounded.Unbounded_String;
end Office.Locations;
26/2 {AI95-00433-01}
limited with Office.Departments; -- types are incomplete
private with Office.Locations; -- only visible in private part
package Office.Employees is
type Employee is private;
27/2 function Dept_Of(Emp : Employee) return access Departments.Department;
procedure Assign_Dept(Emp : in out Employee;
Dept : access Departments.Department);
28/2 ...
private
type Employee is
record
Dept : access Departments.Department;
Loc : Locations.Location;
...
end record;
end Office.Employees;
29/2 limited with Office.Employees;
package Office.Departments is
type Department is private;
30/2 function Manager_Of(Dept : Department) return access Employees.Employee;
procedure Assign_Manager(Dept : in out Department;
Mgr : access Employees.Employee);
...
end Office.Departments;
31/2 {AI95-00433-01} The limited_with_clause may be used to support mutually
dependent abstractions that are split across multiple packages. In this case,
an employee is assigned to a department, and a department has a manager who is
an employee. If a with_clause with the reserved word private appears on one
library unit and mentions a second library unit, it provides visibility to the
second library unit, but restricts that visibility to the private part and
body of the first unit. The compiler checks that no use is made of the second
unit in the visible part of the first unit.
Extensions to Ada 83
31.a The syntax rule for with_clause is modified to allow expanded name
notation.
31.b A use_clause in a context_clause may be for a package (or type)
nested in a library package.
Wording Changes from Ada 83
31.c The syntax rule for context_clause is modified to more closely
reflect the semantics. The Ada 83 syntax rule implies that the
use_clauses that appear immediately after a particular
with_clause are somehow attached to that with_clause, which is not
true. The new syntax allows a use_clause to appear first, but that
is prevented by a textual rule that already exists in Ada 83.
31.d The concept of "scope of a with_clause" (which is a region of
text) replaces RM83's notion of "apply to" (a with_clause applies
to a library_item) The visibility rules are interested in a region
of text, not in a set of compilation units.
31.e No need to define "apply to" for use_clauses. Their semantics are
fully covered by the "scope (of a use_clause)" definition in 8.4.
Incompatibilities With Ada 95
31.f/2 {AI95-00220-01} Amendment Correction: A subprogram body acting as
a declaration cannot with a private child unit. This would allow
public export of types declared in private child packages, and
thus cannot be allowed. This was allowed by mistake in Ada 95; a
subprogram that does this will now be illegal.
Extensions to Ada 95
31.g/2 {AI95-00217-06} limited_with_clauses are new. They make a limited
view of a package visible, where all of the types in the package
are incomplete. They facilitate construction of mutually recursive
types in multiple packages.
31.h/3 {AI95-00262-01} {AI05-0077-1} The syntax rules for with_clause are
modified to allow the reserved word private. Private with_clauses
do not allow the use of their library_item in the visible part of
their compilation_unit. They also allow using private units in
more locations than in Ada 95.
Incompatibilities With Ada 2005
31.i/3 {AI05-0040-1} Correction: Added missing rule that a limited with
clause cannot name an ancestor unit. This is incompatible if an
Ada 2005 program does this, but as this is a new Ada 2005 feature
and the unintentionally allowed capability is not useful, the
incompatibility is very unlikely to occur in practice.
Wording Changes from Ada 2005
31.j/3 {AI05-0077-1} Correction: Fixed wording so that we are not
checking whether something in a context_clause is "within the
scope of" something, as context_clauses are never included in
anything's scope. The intended meaning is unchanged, however.
31.k/3 {AI05-0122-1} Correction: Fixed wording so the rules for private
with clauses also apply to "sprouted" generic child units.
10.1.3 Subunits of Compilation Units
1 [Subunits are like child units, with these (important) differences:
subunits support the separate compilation of bodies only (not declarations);
the parent contains a body_stub to indicate the existence and place of each of
its subunits; declarations appearing in the parent's body can be visible
within the subunits.]
Syntax
2 body_stub ::= subprogram_body_stub | package_body_stub
| task_body_stub | protected_body_stub
3/3 {AI95-00218-03} {AI05-0267-1} subprogram_body_stub ::=
[overriding_indicator]
subprogram_specification is separate
[aspect_specification];
3.a Discussion: Although this syntax allows a parent_unit_name, that
is disallowed by 10.1.1, "Compilation Units - Library Units".
4/3 {AI05-0267-1} package_body_stub ::=
package body defining_identifier is separate
[aspect_specification];
5/3 {AI05-0267-1} task_body_stub ::=
task body defining_identifier is separate
[aspect_specification];
6/3 {AI05-0267-1} protected_body_stub ::=
protected body defining_identifier is separate
[aspect_specification];
7 subunit ::= separate (parent_unit_name) proper_body
Legality Rules
8/2 {AI95-00243-01} The parent body of a subunit is the body of the program
unit denoted by its parent_unit_name. The term subunit is used to refer to a
subunit and also to the proper_body of a subunit. The subunits of a program
unit include any subunit that names that program unit as its parent, as well
as any subunit that names such a subunit as its parent (recursively).
8.a.1/2 Reason: {AI95-00243-01} We want any rule that applies to a subunit
to apply to a subunit of a subunit as well.
9 The parent body of a subunit shall be present in the current environment,
and shall contain a corresponding body_stub with the same
defining_identifier as the subunit.
9.a Discussion: This can't be a Name Resolution Rule, because a
subunit is not a complete context.
10/3 {AI05-0004-1} A package_body_stub shall be the completion of a package_-
declaration or generic_package_declaration; a task_body_stub shall be the
completion of a task declaration; a protected_body_stub shall be the
completion of a protected declaration.
11 In contrast, a subprogram_body_stub need not be the completion of a
previous declaration, [in which case the _stub declares the subprogram]. If
the _stub is a completion, it shall be the completion of a
subprogram_declaration or generic_subprogram_declaration. The profile of a
subprogram_body_stub that completes a declaration shall conform fully to that
of the declaration.
11.a Discussion: The part about subprogram_body_stubs echoes the
corresponding rule for subprogram_bodies in 6.3, "
Subprogram Bodies".
12 A subunit that corresponds to a body_stub shall be of the same kind
(package_, subprogram_, task_, or protected_) as the body_stub. The profile of
a subprogram_body subunit shall be fully conformant to that of the
corresponding body_stub.
13 A body_stub shall appear immediately within the declarative_part of a
compilation unit body. This rule does not apply within an instance of a
generic unit.
13.a Discussion: This is a methodological restriction; that is, it is
not necessary for the semantics of the language to make sense.
14 The defining_identifiers of all body_stubs that appear immediately within
a particular declarative_part shall be distinct.
Post-Compilation Rules
15 For each body_stub, there shall be a subunit containing the corresponding
proper_body.
NOTES
16 4 The rules in 10.1.4, "The Compilation Process" say that a
body_stub is equivalent to the corresponding proper_body. This
implies:
17 * Visibility within a subunit is the visibility that would be
obtained at the place of the corresponding body_stub (within the
parent body) if the context_clause of the subunit were appended to
that of the parent body.
17.a Ramification: Recursively. Note that this transformation might
make the parent illegal; hence it is not a true equivalence, but
applies only to visibility within the subunit.
18 * The effect of the elaboration of a body_stub is to elaborate the
subunit.
18.a Ramification: The elaboration of a subunit is part of its parent
body's elaboration, whereas the elaboration of a child unit is not
part of its parent declaration's elaboration.
18.b Ramification: A library_item that is mentioned in a with_clause of
a subunit can be hidden (from direct visibility) by a declaration
(with the same identifier) given in the subunit. Moreover, such a
library_item can even be hidden by a declaration given within the
parent body since a library unit is declared in its parent's
declarative region; this however does not affect the
interpretation of the with_clauses themselves, since only
library_items are visible or directly visible in with_clauses.
18.c The body of a protected operation cannot be a subunit. This
follows from the syntax rules. The body of a protected unit can be
a subunit.
Examples
19 The package Parent is first written without subunits:
20 package Parent is
procedure Inner;
end Parent;
21 with Ada.Text_IO;
package body Parent is
Variable : String := "Hello, there.";
procedure Inner is
begin
Ada.Text_IO.Put_Line(Variable);
end Inner;
end Parent;
22 The body of procedure Inner may be turned into a subunit by rewriting the
package body as follows (with the declaration of Parent remaining the same):
23 package body Parent is
Variable : String := "Hello, there.";
procedure Inner is separate;
end Parent;
24 with Ada.Text_IO;
separate(Parent)
procedure Inner is
begin
Ada.Text_IO.Put_Line(Variable);
end Inner;
Extensions to Ada 83
24.a Subunits of the same ancestor library unit are no longer
restricted to have distinct identifiers. Instead, we require only
that the full expanded names be distinct.
Extensions to Ada 95
24.b/2 {AI95-00218-03} An overriding_indicator (see 8.3.1) is allowed on
a subprogram stub.
Wording Changes from Ada 95
24.c/2 {AI95-00243-01} Clarified that a subunit of a subunit is still a
subunit.
Extensions to Ada 2005
24.d/3 {AI05-0267-1} An optional aspect_specification can be used in a
body_stub. This is described in 13.1.1.
10.1.4 The Compilation Process
1 Each compilation unit submitted to the compiler is compiled in the context
of an environment declarative_part (or simply, an environment), which is a
conceptual declarative_part that forms the outermost declarative region of the
context of any compilation. At run time, an environment forms the
declarative_part of the body of the environment task of a partition (see
10.2, "Program Execution").
1.a Ramification: At compile time, there is no particular construct
that the declarative region is considered to be nested within -
the environment is the universe.
1.b To be honest: The environment is really just a portion of a
declarative_part, since there might, for example, be bodies that
do not yet exist.
2 The declarative_items of the environment are library_items appearing in an
order such that there are no forward semantic dependences. Each included
subunit occurs in place of the corresponding stub. The visibility rules apply
as if the environment were the outermost declarative region, except that with_-
clauses are needed to make declarations of library units visible (see 10.1.2).
3/2 {AI95-00217-06} The mechanisms for creating an environment and for adding
and replacing compilation units within an environment are implementation
defined. The mechanisms for adding a compilation unit mentioned in a
limited_with_clause to an environment are implementation defined.
3.a Implementation defined: The mechanisms for creating an environment
and for adding and replacing compilation units.
3.a.1/2 Implementation defined: The mechanisms for adding a compilation
unit mentioned in a limited_with_clause to an environment.
3.b Ramification: The traditional model, used by most Ada 83
implementations, is that one places a compilation unit in the
environment by compiling it. Other models are possible. For
example, an implementation might define the environment to be a
directory; that is, the compilation units in the environment are
all the compilation units in the source files contained in the
directory. In this model, the mechanism for replacing a
compilation unit with a new one is simply to edit the source file
containing that compilation unit.
Name Resolution Rules
4/3 {8652/0032} {AI95-00192-01} {AI05-0264-1} If a library_unit_body that is a
subprogram_body is submitted to the compiler, it is interpreted only as a
completion if a library_unit_declaration with the same
defining_program_unit_name already exists in the environment for a subprogram
other than an instance of a generic subprogram or for a generic subprogram
(even if the profile of the body is not type conformant with that of the
declaration); otherwise, the subprogram_body is interpreted as both the
declaration and body of a library subprogram.
4.a Ramification: The principle here is that a subprogram_body should
be interpreted as only a completion if and only if it "might" be
legal as the completion of some preexisting declaration, where "
might" is defined in a way that does not require overload
resolution to determine.
4.b Hence, if the preexisting declaration is a
subprogram_declaration or generic_subprogram_declaration, we treat
the new subprogram_body as its completion, because it "might" be
legal. If it turns out that the profiles don't fully conform, it's
an error. In all other cases (the preexisting declaration is a
package or a generic package, or an instance of a generic
subprogram, or a renaming, or a "spec-less" subprogram, or in the
case where there is no preexisting thing), the subprogram_body
declares a new subprogram.
4.c See also AI83-00266/09.
Legality Rules
5 When a compilation unit is compiled, all compilation units upon which it
depends semantically shall already exist in the environment; the set of these
compilation units shall be consistent in the sense that the new compilation
unit shall not semantically depend (directly or indirectly) on two different
versions of the same compilation unit, nor on an earlier version of itself.
5.a Discussion: For example, if package declarations A and B both say
"with X;", and the user compiles a compilation unit that says "
with A, B;", then the A and B have to be talking about the same
version of X.
5.b Ramification: What it means to be a "different version" is not
specified by the language. In some implementations, it means that
the compilation unit has been recompiled. In others, it means that
the source of the compilation unit has been edited in some
significant way.
5.c Note that an implementation cannot require the existence of
compilation units upon which the given one does not semantically
depend. For example, an implementation is required to be able to
compile a compilation unit that says "with A;" when A's body does
not exist. It has to be able to detect errors without looking at
A's body.
5.d/3 {AI05-0229-1} Similarly, the implementation has to be able to
compile a call to a subprogram for which aspect Inline has been
specified without seeing the body of that subprogram - inlining
would not be achieved in this case, but the call is still legal.
5.e/3 {AI95-00217-06} {AI05-0005-1} The consistency rule applies to
limited views as well as the full view of a compilation unit. That
means that an implementation needs a way to enforce consistency of
limited views, not just of full views.
Implementation Permissions
6/2 {AI95-00217-06} The implementation may require that a compilation unit be
legal before it can be mentioned in a limited_with_clause or it can be
inserted into the environment.
7/3 {AI95-00214-01} {AI05-0229-1} When a compilation unit that declares or
renames a library unit is added to the environment, the implementation may
remove from the environment any preexisting library_item or subunit with the
same full expanded name. When a compilation unit that is a subunit or the body
of a library unit is added to the environment, the implementation may remove
from the environment any preexisting version of the same compilation unit.
When a compilation unit that contains a body_stub is added to the environment,
the implementation may remove any preexisting library_item or subunit with the
same full expanded name as the body_stub. When a given compilation unit is
removed from the environment, the implementation may also remove any
compilation unit that depends semantically upon the given one. If the given
compilation unit contains the body of a subprogram for which aspect Inline is
True, the implementation may also remove any compilation unit containing a
call to that subprogram.
7.a/3 Ramification: {AI05-0005-1} The permissions given in this
paragraph correspond to the traditional model, where compilation
units enter the environment by being compiled into it, and the
compiler checks their legality at that time. An implementation
model in which the environment consists of all source files in a
given directory might not want to take advantage of these
permissions. Compilation units would not be checked for legality
as soon as they enter the environment; legality checking would
happen later, when compilation units are compiled. In this model,
compilation units might never be automatically removed from the
environment; they would be removed when the user explicitly
deletes a source file.
7.b Note that the rule is recursive: if the above permission is used
to remove a compilation unit containing an inlined subprogram
call, then compilation units that depend semantically upon the
removed one may also be removed, and so on.
7.c Note that here we are talking about dependences among existing
compilation units in the environment; it doesn't matter what
with_clauses are attached to the new compilation unit that
triggered all this.
7.d/3 {AI05-0229-1} An implementation may have other modes in which
compilation units in addition to the ones mentioned above are
removed. For example, an implementation might inline subprogram
calls without an explicit aspect Inline. If so, it either has to
have a mode in which that optimization is turned off, or it has to
automatically regenerate code for the inlined calls without
requiring the user to resubmit them to the compiler.
7.d.1/2 Discussion: {8652/0108} {AI95-00077-01} {AI95-00114-01} In the
standard mode, implementations may only remove units from the
environment for one of the reasons listed here, or in response to
an explicit user command to modify the environment. It is not
intended that the act of compiling a unit is one of the "
mechanisms" for removing units other than those specified by this
International Standard.
7.e/2 {AI95-00214-01} These rules are intended to ensure that an
implementation never need keep more than one compilation unit with
any full expanded name. In particular, it is not necessary to be
able to have a subunit and a child unit with the same name in the
environment at one time.
NOTES
8 5 The rules of the language are enforced across compilation and
compilation unit boundaries, just as they are enforced within a single
compilation unit.
8.a/3 Ramification: {AI05-0299-1} Note that Clause 1 requires an
implementation to detect illegal compilation units at compile
time.
9 6 An implementation may support a concept of a library, which
contains library_items. If multiple libraries are supported, the
implementation has to define how a single environment is constructed
when a compilation unit is submitted to the compiler. Naming conflicts
between different libraries might be resolved by treating each library
as the root of a hierarchy of child library units.
9.a Implementation Note: Alternatively, naming conflicts could be
resolved via some sort of hiding rule.
9.b Discussion: For example, the implementation might support a
command to import library Y into library X. If a root library unit
called LU (that is, Standard.LU) exists in Y, then from the point
of view of library X, it could be called Y.LU. X might contain
library units that say, "with Y.LU;".
10 7 A compilation unit containing an instantiation of a separately
compiled generic unit does not semantically depend on the body of the
generic unit. Therefore, replacing the generic body in the environment
does not result in the removal of the compilation unit containing the
instantiation.
10.a Implementation Note: Therefore, implementations have to be
prepared to automatically instantiate generic bodies at link-time,
as needed. This might imply a complete automatic recompilation,
but it is the intent of the language that generic bodies can be
(re)instantiated without forcing all of the compilation units that
semantically depend on the compilation unit containing the
instantiation to be recompiled.
Extensions to Ada 83
10.b/2 {AI95-00077-01} {AI95-00114-01} Ada 83 allowed implementations to
require that the body of a generic unit be available when the
instantiation is compiled; that permission is dropped in Ada 95.
This isn't really an extension (it doesn't allow Ada users to
write anything that they couldn't in Ada 83), but there isn't a
more appropriate category, and it does allow users more
flexibility when developing programs.
Wording Changes from Ada 95
10.c/2 {8652/0032} {AI95-00192-01} Corrigendum: The wording was clarified
to ensure that a subprogram_body is not considered a completion of
an instance of a generic subprogram.
10.d/2 {AI95-00214-01} The permissions to remove a unit from the
environment were clarified to ensure that it is never necessary to
keep multiple (sub)units with the same full expanded name in the
environment.
10.e/2 {AI95-00217-06} Units mentioned in a limited_with_clause were
added to several rules; limited views have the same presence in
the environment as the corresponding full views.
10.1.5 Pragmas and Program Units
1 [This subclause discusses pragmas related to program units, library units,
and compilations.]
Name Resolution Rules
2 Certain pragmas are defined to be program unit pragmas. A name given as
the argument of a program unit pragma shall resolve to denote the declarations
or renamings of one or more program units that occur immediately within the
declarative region or compilation in which the pragma immediately occurs, or
it shall resolve to denote the declaration of the immediately enclosing
program unit (if any); the pragma applies to the denoted program unit(s). If
there are no names given as arguments, the pragma applies to the immediately
enclosing program unit.
2.a Ramification: The fact that this is a Name Resolution Rule means
that the pragma will not apply to declarations from outer
declarative regions.
Legality Rules
3 A program unit pragma shall appear in one of these places:
4 * At the place of a compilation_unit, in which case the pragma shall
immediately follow in the same compilation (except for other pragmas)
a library_unit_declaration that is a subprogram_declaration, generic_-
subprogram_declaration, or generic_instantiation, and the pragma shall
have an argument that is a name denoting that declaration.
4.a Ramification: The name has to denote the immediately preceding
library_unit_declaration.
5/1 * {8652/0033} {AI95-00136-01} Immediately within the visible part of a
program unit and before any nested declaration (but not within a
generic formal part), in which case the argument, if any, shall be a
direct_name that denotes the immediately enclosing program unit
declaration.
5.a Ramification: The argument is optional in this case.
6 * At the place of a declaration other than the first, of a
declarative_part or program unit declaration, in which case the
pragma shall have an argument, which shall be a direct_name that
denotes one or more of the following (and nothing else): a subprogram_-
declaration, a generic_subprogram_declaration, or a
generic_instantiation, of the same declarative_part or program unit
declaration.
6.a Ramification: If you want to denote a subprogram_body that is not
a completion, or a package_declaration, for example, you have to
put the pragma inside.
7/3 {AI05-0132-1} Certain program unit pragmas are defined to be library unit
pragmas. If a library unit pragma applies to a program unit, the program unit
shall be a library unit.
7.a Ramification: This, together with the rules for program unit
pragmas above, implies that if a library unit pragma applies to a
subprogram_declaration (and similar things), it has to appear
immediately after the compilation_unit, whereas if the pragma
applies to a package_declaration, a subprogram_body that is not a
completion (and similar things), it has to appear inside, as the
first declarative_item.
Static Semantics
7.1/1 {8652/0034} {AI95-00041-01} A library unit pragma that applies to a
generic unit does not apply to its instances, unless a specific rule for the
pragma specifies the contrary.
Post-Compilation Rules
8 Certain pragmas are defined to be configuration pragmas; they shall appear
before the first compilation_unit of a compilation. [They are generally used
to select a partition-wide or system-wide option.] The pragma applies to all
compilation_units appearing in the compilation, unless there are none, in
which case it applies to all future compilation_units compiled into the same
environment.
Implementation Permissions
9/2 {AI95-00212-01} An implementation may require that configuration pragmas
that select partition-wide or system-wide options be compiled when the
environment contains no library_items other than those of the predefined
environment. In this case, the implementation shall still accept configuration
pragmas in individual compilations that confirm the initially selected
partition-wide or system-wide options.
Implementation Advice
10/1 {8652/0034} {AI95-00041-01} When applied to a generic unit, a program
unit pragma that is not a library unit pragma should apply to each instance of
the generic unit for which there is not an overriding pragma applied directly
to the instance.
10.a/2 Implementation Advice: When applied to a generic unit, a program
unit pragma that is not a library unit pragma should apply to each
instance of the generic unit for which there is not an overriding
pragma applied directly to the instance.
Wording Changes from Ada 95
10.b/2 {8652/0033} {AI95-00136-01} Corrigendum: The wording was corrected
to ensure that a program unit pragma cannot appear in private
parts or generic formal parts.
10.c/2 {8652/0034} {AI95-00041-01} Corrigendum: The wording was clarified
to explain the meaning of program unit and library unit pragmas in
generic units.
10.d/2 The Implementation Advice added by the Corrigendum was moved, as
it was not in the normal order. (This changes the paragraph
number.) It originally was directly after the new Static Semantics
rule.
10.e/2 {AI95-00212-01} The permission to place restrictions was clarified
to:
10.f/2 * Ensure that it applies only to partition-wide configuration
pragmas, not ones like Assertion_Policy (see 11.4.2), which
can be different in different units; and
10.g/2 * Ensure that confirming pragmas are always allowed.
Wording Changes from Ada 2005
10.h/3 {AI05-0132-1} Correction: A library unit pragma must apply
directly to a library unit, even if no name is given in the
pragma.
10.1.6 Environment-Level Visibility Rules
1 [The normal visibility rules do not apply within a parent_unit_name or a
context_clause, nor within a pragma that appears at the place of a compilation
unit. The special visibility rules for those contexts are given here.]
Static Semantics
2/2 {AI95-00217-06} {AI95-00312-01} Within the parent_unit_name at the
beginning of an explicit library_item, and within a nonlimited_with_clause,
the only declarations that are visible are those that are explicit
library_items of the environment, and the only declarations that are directly
visible are those that are explicit root library_items of the environment.
Within a limited_with_clause, the only declarations that are visible are those
that are the implicit declaration of the limited view of a library package of
the environment, and the only declarations that are directly visible are those
that are the implicit declaration of the limited view of a root library
package.
2.a Ramification: In "package P.Q.R is ... end P.Q.R;", this rule
requires P to be a root library unit, and Q to be a library unit
(because those are the things that are directly visible and
visible). Note that visibility does not apply between the "end"
and the ";".
2.b Physically nested declarations are not visible at these places.
2.c Although Standard is visible at these places, it is impossible to
name it, since it is not directly visible, and it has no parent.
2.c.1/2 {AI95-00217-06} Only compilation units defining limited views can
be mentioned in a limited_with_clause, while only compilation
units defining full views (that is, the explicit declarations) can
be mentioned in a nonlimited_with_clause. This resolves the
conflict inherent in having two compilation units with the same
defining name.
2.d/2 This paragraph was deleted.{AI95-00312-01}
3 Within a use_clause or pragma that is within a context_clause, each
library_item mentioned in a previous with_clause of the same context_clause is
visible, and each root library_item so mentioned is directly visible. In
addition, within such a use_clause, if a given declaration is visible or
directly visible, each declaration that occurs immediately within the given
declaration's visible part is also visible. No other declarations are visible
or directly visible.
3.a Discussion: Note the word "same". For example, if a with_clause on
a declaration mentions X, this does not make X visible in
use_clauses and pragmas that are on the body. The reason for this
rule is the one-pass context_clauses Language Design Principle.
3.b Note that the second part of the rule does not mention pragmas.
4 Within the parent_unit_name of a subunit, library_items are visible as
they are in the parent_unit_name of a library_item; in addition, the
declaration corresponding to each body_stub in the environment is also
visible.
4.a Ramification: For a subprogram without a separate
subprogram_declaration, the body_stub itself is the declaration.
5 Within a pragma that appears at the place of a compilation unit, the
immediately preceding library_item and each of its ancestors is visible. The
ancestor root library_item is directly visible.
6/2 {AI95-00312-01} Notwithstanding the rules of 4.1.3, an expanded name in a
with_clause, a pragma in a context_clause, or a pragma that appears at the
place of a compilation unit may consist of a prefix that denotes a generic
package and a selector_name that denotes a child of that generic package.
[(The child is necessarily a generic unit; see 10.1.1.)]
6.a/2 Reason: This rule allows with A.B; and pragma Elaborate(A.B);
where A is a generic library package and B is one of its (generic)
children. This is necessary because it is not normally legal to
use an expanded name to reach inside a generic package.
Wording Changes from Ada 83
6.b The special visibility rules that apply within a
parent_unit_name or a context_clause, and within a pragma that
appears at the place of a compilation_unit are clarified.
6.c Note that a context_clause is not part of any declarative region.
6.d We considered making the visibility rules within
parent_unit_names and context_clauses follow from the context of
compilation. However, this attempt failed for various reasons. For
example, it would require use_clauses in context_clauses to be
within the declarative region of Standard, which sounds
suspiciously like a kludge. And we would still need a special rule
to prevent seeing things (in our own context_clause) that were
with-ed by our parent, etc.
Wording Changes from Ada 95
6.e/2 {AI95-00217-06} Added separate visibility rules for
limited_with_clauses; the existing rules apply only to
nonlimited_with_clauses.
6.f/2 {AI95-00312-01} Clarified that the name of a generic child unit
may appear in a pragma in a context_clause.
10.2 Program Execution
1 An Ada program consists of a set of partitions[, which can execute in
parallel with one another, possibly in a separate address space, and possibly
on a separate computer.]
Post-Compilation Rules
2 A partition is a program or part of a program that can be invoked from
outside the Ada implementation. [For example, on many systems, a partition
might be an executable file generated by the system linker.] The user can
explicitly assign library units to a partition. The assignment is done in an
implementation-defined manner. The compilation units included in a partition
are those of the explicitly assigned library units, as well as other
compilation units needed by those library units. The compilation units needed
by a given compilation unit are determined as follows (unless specified
otherwise via an implementation-defined pragma, or by some other
implementation-defined means):
2.a Discussion: From a run-time point of view, an Ada 95 partition is
identical to an Ada 83 program - implementations were always
allowed to provide inter-program communication mechanisms. The
additional semantics of partitions is that interfaces between them
can be defined to obey normal language rules (as is done in
Annex E, "Distributed Systems"), whereas interfaces between
separate programs had no particular semantics.
2.b Implementation defined: The manner of explicitly assigning library
units to a partition.
2.c Implementation defined: The implementation-defined means, if any,
of specifying which compilation units are needed by a given
compilation unit.
2.d Discussion: There are no pragmas that "specify otherwise" defined
by the core language. However, an implementation is allowed to
provide such pragmas, and in fact Annex E, "Distributed Systems
" defines some pragmas whose semantics includes reducing the set
of compilation units described here.
3 * A compilation unit needs itself;
4 * If a compilation unit is needed, then so are any compilation units
upon which it depends semantically;
5 * If a library_unit_declaration is needed, then so is any corresponding
library_unit_body;
6/2 * {AI95-00217-06} If a compilation unit with stubs is needed, then so
are any corresponding subunits;
6.a Discussion: Note that in the environment, the stubs are replaced
with the corresponding proper_bodies.
6.1/2 * {AI95-00217-06} If the (implicit) declaration of the limited view of
a library package is needed, then so is the explicit declaration of
the library package.
6.b Discussion: Note that a child unit is not included just because
its parent is included - to include a child, mention it in a
with_clause.
6.c/2 {AI95-00217-06} A package is included in a partition even if the
only reference to it is in a limited_with_clause. While this isn't
strictly necessary (no objects of types imported from such a unit
can be created), it ensures that all incomplete types are
eventually completed, and is the least surprising option.
7 The user can optionally designate (in an implementation-defined manner)
one subprogram as the main subprogram for the partition. A main subprogram, if
specified, shall be a subprogram.
7.a Discussion: This may seem superfluous, since it follows from the
definition. But we would like to have every error message that
might be generated (before run time) by an implementation
correspond to some explicitly stated "shall" rule.
7.b Of course, this does not mean that the "shall" rules correspond
one-to-one with an implementation's error messages. For example,
the rule that says overload resolution "shall" succeed in
producing a single interpretation would correspond to many error
messages in a good implementation - the implementation would want
to explain to the user exactly why overload resolution failed.
This is especially true for the syntax rules - they are considered
part of overload resolution, but in most cases, one would expect
an error message based on the particular syntax rule that was
violated.
7.c Implementation defined: The manner of designating the main
subprogram of a partition.
7.d Ramification: An implementation cannot require the user to
specify, say, all of the library units to be included. It has to
support, for example, perhaps the most typical case, where the
user specifies just one library unit, the main program. The
implementation has to do the work of tracking down all the other
ones.
8 Each partition has an anonymous environment task[, which is an implicit
outermost task whose execution elaborates the library_items of the environment
declarative_part, and then calls the main subprogram, if there is one. A
partition's execution is that of its tasks.]
8.a Ramification: An environment task has no master; all
nonenvironment tasks have masters.
8.b An implementation is allowed to support multiple concurrent
executions of the same partition.
9 [The order of elaboration of library units is determined primarily by the
elaboration dependences.] There is an elaboration dependence of a given
library_item upon another if the given library_item or any of its subunits
depends semantically on the other library_item. In addition, if a given
library_item or any of its subunits has a pragma Elaborate or Elaborate_All
that names another library unit, then there is an elaboration dependence of
the given library_item upon the body of the other library unit, and, for
Elaborate_All only, upon each library_item needed by the declaration of the
other library unit.
9.a.1/2 Discussion: {8652/0107} {AI95-00180-01} {AI95-00256-01} "
Mentions" was used informally in the above rule; it was not intended to
refer to the definition of mentions in 10.1.2. It was changed to
"names" to make this clear.
9.a See above for a definition of which library_items are "needed
by" a given declaration.
9.b Note that elaboration dependences are among library_items, whereas
the other two forms of dependence are among compilation units.
Note that elaboration dependence includes semantic dependence.
It's a little bit sad that pragma Elaborate_Body can't be folded
into this mechanism. It follows from the definition that the
elaboration dependence relationship is transitive. Note that the
wording of the rule does not need to take into account a semantic
dependence of a library_item or one of its subunits upon a subunit
of a different library unit, because that can never happen.
10 The environment task for a partition has the following structure:
11 task Environment_Task;
12 task body Environment_Task is
... (1) -- The environment declarative_part
-- (that is, the sequence of library_items) goes here.
begin
... (2) -- Call the main subprogram, if there is one.
end Environment_Task;
12.a Ramification: The name of the environment task is written in
italics here to indicate that this task is anonymous.
12.b Discussion: The model is different for a "passive partition" (see
E.1). Either there is no environment task, or its
sequence_of_statements is an infinite loop rather than a call on a
main subprogram.
13 The environment declarative_part at (1) is a sequence of
declarative_items consisting of copies of the library_items included in the
partition[. The order of elaboration of library_items is the order in which
they appear in the environment declarative_part]:
14 * The order of all included library_items is such that there are no
forward elaboration dependences.
14.a Ramification: This rule is written so that if a library_item
depends on itself, we don't require it to be elaborated before
itself. See AI83-00113/12. This can happen only in pathological
circumstances. For example, if a library subprogram_body has no
corresponding subprogram_declaration, and one of the subunits of
the subprogram_body mentions the subprogram_body in a
with_clause, the subprogram_body will depend on itself. For
another example, if a library_unit_body applies a pragma
Elaborate_All to its own declaration, then the library_unit_body
will depend on itself.
15/3 * {AI05-0229-1} Any included library_unit_declaration for which aspect
Elaborate_Body is True [(including when a pragma Elaborate_Body
applies)] is immediately followed by its library_unit_body, if
included.
15.a Discussion: This implies that the body of such a library unit
shall not "with" any of its own children, or anything else that
depends semantically upon the declaration of the library unit.
15.b/3 Proof: {AI05-0229-1} Pragma Elaborate_Body sets aspect
Elaborate_Body, see 10.2.1.
16 * All library_items declared pure occur before any that are not declared
pure.
17 * All preelaborated library_items occur before any that are not
preelaborated.
17.a Discussion: Normally, if two partitions contain the same
compilation unit, they each contain a separate copy of that
compilation unit. See Annex E, "Distributed Systems" for cases
where two partitions share the same copy of something.
17.b There is no requirement that the main subprogram be elaborated
last. In fact, it is possible to write a partition in which the
main subprogram cannot be elaborated last.
17.c Ramification: This declarative_part has the properties required of
all environments (see 10.1.4). However, the environment
declarative_part of a partition will typically contain fewer
compilation units than the environment declarative_part used at
compile time - only the "needed" ones are included in the
partition.
18 There shall be a total order of the library_items that obeys the above
rules. The order is otherwise implementation defined.
18.a Discussion: The only way to violate this rule is to have
Elaborate, Elaborate_All, or Elaborate_Body pragmas that cause
circular ordering requirements, thus preventing an order that has
no forward elaboration dependences.
18.b Implementation defined: The order of elaboration of library_items.
18.c To be honest: Notwithstanding what the RM95 says elsewhere, each
rule that requires a declaration to have a corresponding
completion is considered to be a Post-Compilation Rule when the
declaration is that of a library unit.
18.d Discussion: Such rules may be checked at "link time," for example.
Rules requiring the completion to have certain properties, on the
other hand, are checked at compile time of the completion.
19 The full expanded names of the library units and subunits included in a
given partition shall be distinct.
19.a Reason: This is a Post-Compilation Rule because making it a
Legality Rule would violate the Language Design Principle labeled
"legality determinable via semantic dependences."
20 The sequence_of_statements of the environment task (see (2) above)
consists of either:
21 * A call to the main subprogram, if the partition has one. If the main
subprogram has parameters, they are passed; where the actuals come
from is implementation defined. What happens to the result of a main
function is also implementation defined.
21.a Implementation defined: Parameter passing and function return for
the main subprogram.
22 or:
23 * A null_statement, if there is no main subprogram.
23.a Discussion: For a passive partition, either there is no
environment task, or its sequence_of_statements is an infinite
loop. See E.1.
24 The mechanisms for building and running partitions are implementation
defined. [These might be combined into one operation, as, for example, in
dynamic linking, or "load-and-go" systems.]
24.a Implementation defined: The mechanisms for building and running
partitions.
Dynamic Semantics
25 The execution of a program consists of the execution of a set of
partitions. Further details are implementation defined. The execution of a
partition starts with the execution of its environment task, ends when the
environment task terminates, and includes the executions of all tasks of the
partition. [The execution of the (implicit) task_body of the environment task
acts as a master for all other tasks created as part of the execution of the
partition. When the environment task completes (normally or abnormally), it
waits for the termination of all such tasks, and then finalizes any remaining
objects of the partition.]
25.a Ramification: The "further details" mentioned above include, for
example, program termination - it is implementation defined. There
is no need to define it here; it's entirely up to the
implementation whether it wants to consider the program as a whole
to exist beyond the existence of individual partitions.
25.b Implementation defined: The details of program execution,
including program termination.
25.c To be honest: The execution of the partition terminates (normally
or abnormally) when the environment task terminates (normally or
abnormally, respectively).
Bounded (Run-Time) Errors
26 Once the environment task has awaited the termination of all other tasks
of the partition, any further attempt to create a task (during finalization)
is a bounded error, and may result in the raising of Program_Error either upon
creation or activation of the task. If such a task is activated, it is not
specified whether the task is awaited prior to termination of the environment
task.
Implementation Requirements
27 The implementation shall ensure that all compilation units included in a
partition are consistent with one another, and are legal according to the
rules of the language.
27.a Discussion: The consistency requirement implies that a partition
cannot contain two versions of the same compilation unit. That is,
a partition cannot contain two different library units with the
same full expanded name, nor two different bodies for the same
program unit. For example, suppose we compile the following:
27.b package A is -- Version 1.
...
end A;
27.c with A;
package B is
end B;
27.d package A is -- Version 2.
...
end A;
27.e with A;
package C is
end C;
27.f It would be wrong for a partition containing B and C to contain
both versions of A. Typically, the implementation would require
the use of Version 2 of A, which might require the recompilation
of B. Alternatively, the implementation might automatically
recompile B when the partition is built. A third alternative would
be an incremental compiler that, when Version 2 of A is compiled,
automatically patches the object code for B to reflect the changes
to A (if there are any relevant changes - there might not be any).
27.g An implementation that supported fancy version management might
allow the use of Version 1 in some circumstances. In no case can
the implementation allow the use of both versions in the same
partition (unless, of course, it can prove that the two versions
are semantically identical).
27.h The core language says nothing about inter-partition consistency;
see also Annex E, "Distributed Systems".
Implementation Permissions
28/3 {AI05-0299-1} The kind of partition described in this subclause is known
as an active partition. An implementation is allowed to support other kinds of
partitions, with implementation-defined semantics.
28.a Implementation defined: The semantics of any nonactive partitions
supported by the implementation.
28.b Discussion: Annex E, "Distributed Systems" defines the concept of
passive partitions; they may be thought of as a partition without
an environment task, or as one with a particularly simple form of
environment task, having an infinite loop rather than a call on a
main subprogram as its sequence_of_statements.
29 An implementation may restrict the kinds of subprograms it supports as
main subprograms. However, an implementation is required to support all main
subprograms that are public parameterless library procedures.
29.a Ramification: The implementation is required to support main
subprograms that are procedures declared by
generic_instantiations, as well as those that are children of
library units other than Standard. Generic units are, of course,
not allowed to be main subprograms, since they are not subprograms.
29.b Note that renamings are irrelevant to this rule. This rules says
which subprograms (not views) have to be supported. The
implementation can choose any way it wants for the user to
indicate which subprogram should be the main subprogram. An
implementation might allow any name of any view, including those
declared by renamings. Another implementation might require it to
be the original name. Another implementation still might use the
name of the source file or some such thing.
30 If the environment task completes abnormally, the implementation may abort
any dependent tasks.
30.a Reason: If the implementation does not take advantage of this
permission, the normal action takes place - the environment task
awaits those tasks.
30.b The possibility of aborting them is not shown in the
Environment_Task code above, because there is nowhere to put an
exception_handler that can handle exceptions raised in both the
environment declarative_part and the main subprogram, such that
the dependent tasks can be aborted. If we put an
exception_handler in the body of the environment task, then it
won't handle exceptions that occur during elaboration of the
environment declarative_part. If we were to move those things into
a nested block_statement, with the exception_handler outside that,
then the block_statement would await the library tasks we are
trying to abort.
30.c Furthermore, this is merely a permission, and is not fundamental
to the model, so it is probably better to state it separately
anyway.
30.d Note that implementations (and tools like debuggers) can have
modes that provide other behaviors in addition.
NOTES
31 8 An implementation may provide inter-partition communication
mechanism(s) via special packages and pragmas. Standard pragmas for
distribution and methods for specifying inter-partition communication
are defined in Annex E, "Distributed Systems". If no such mechanisms
are provided, then each partition is isolated from all others, and
behaves as a program in and of itself.
31.a Ramification: Not providing such mechanisms is equivalent to
disallowing multi-partition programs.
31.b An implementation may provide mechanisms to facilitate checking
the consistency of library units elaborated in different
partitions; Annex E, "Distributed Systems" does so.
32 9 Partitions are not required to run in separate address spaces. For
example, an implementation might support dynamic linking via the
partition concept.
33 10 An order of elaboration of library_items that is consistent with
the partial ordering defined above does not always ensure that each
library_unit_body is elaborated before any other compilation unit
whose elaboration necessitates that the library_unit_body be already
elaborated. (In particular, there is no requirement that the body of a
library unit be elaborated as soon as possible after the
library_unit_declaration is elaborated, unless the pragmas in
subclause 10.2.1 are used.)
34 11 A partition (active or otherwise) need not have a main subprogram.
In such a case, all the work done by the partition would be done by
elaboration of various library_items, and by tasks created by that
elaboration. Passive partitions, which cannot have main subprograms,
are defined in Annex E, "Distributed Systems".
34.a Ramification: The environment task is the outermost semantic level
defined by the language.
34.b Standard has no private part. This prevents strange
implementation-dependences involving private children of Standard
having visibility upon Standard's private part. It doesn't matter
where the body of Standard appears in the environment, since it
doesn't do anything. See Annex A, "
Predefined Language Environment".
34.c Note that elaboration dependence is carefully defined in such a
way that if (say) the body of something doesn't exist yet, then
there is no elaboration dependence upon the nonexistent body.
(This follows from the fact that "needed by" is defined that way,
and the elaboration dependences caused by a pragma Elaborate or
Elaborate_All are defined in terms of "needed by".) This property
allows us to use the environment concept both at compile time and
at partition-construction time/run time.
Extensions to Ada 83
34.d The concept of partitions is new to Ada 95.
34.e A main subprogram is now optional. The language-defined
restrictions on main subprograms are relaxed.
Wording Changes from Ada 83
34.f Ada 95 uses the term "main subprogram" instead of Ada 83's "main
program" (which was inherited from Pascal). This is done to avoid
confusion - a main subprogram is a subprogram, not a program. The
program as a whole is an entirely different thing.
Wording Changes from Ada 95
34.g/2 {AI95-00256-01} The mistaken use of "mentions" in the elaboration
dependence rule was fixed.
34.h/2 {AI95-00217-06} The needs relationship was extended to include
limited views.
10.2.1 Elaboration Control
1 [ This subclause defines pragmas that help control the elaboration order
of library_items.]
Language Design Principles
1.a The rules governing preelaboration are designed to allow it to be
done largely by bulk initialization of statically allocated
storage from information in a "load module" created by a linker.
Some implementations may require run-time code to be executed in
some cases, but we consider these cases rare enough that we need
not further complicate the rules.
1.b It is important that programs be able to declare data structures
that are link-time initialized with aggregates, string_literals,
and concatenations thereof. It is important to be able to write
link-time evaluated expressions involving the First, Last, and
Length attributes of such data structures (including variables),
because they might be initialized with positional aggregates or
string_literals, and we don't want the user to have to count the
elements. There is no corresponding need for accessing
discriminants, since they can be initialized with a static
constant, and then the constant can be referred to elsewhere. It
is important to allow link-time initialized data structures
involving discriminant-dependent components. It is important to be
able to write link-time evaluated expressions involving pointers
(both access values and addresses) to the above-mentioned data
structures.
1.c The rules also ensure that no Elaboration_Check need be performed
for calls on library-level subprograms declared within a
preelaborated package. This is true also of the Elaboration_Check
on task activation for library level task types declared in a
preelaborated package. However, it is not true of the
Elaboration_Check on instantiations.
1.d A static expression should never prevent a library unit from being
preelaborable.
Syntax
2 The form of a pragma Preelaborate is as follows:
3 pragma Preelaborate[(library_unit_name)];
4 A pragma Preelaborate is a library unit pragma.
4.1/2 {AI95-00161-01} The form of a pragma Preelaborable_Initialization is
as follows:
4.2/2 pragma Preelaborable_Initialization(direct_name);
Legality Rules
5 An elaborable construct is preelaborable unless its elaboration performs
any of the following actions:
5.a Ramification: A preelaborable construct can be elaborated without
using any information that is available only at run time. Note
that we don't try to prevent exceptions in preelaborable
constructs; if the implementation wishes to generate code to raise
an exception, that's OK.
5.b Because there is no flow of control and there are no calls (other
than to predefined subprograms), these run-time properties can
actually be detected at compile time. This is necessary in order
to require compile-time enforcement of the rules.
6 * The execution of a statement other than a null_statement.
6.a Ramification: A preelaborable construct can contain labels and
null_statements.
7 * A call to a subprogram other than a static function.
8 * The evaluation of a primary that is a name of an object, unless the
name is a static expression, or statically denotes a discriminant of
an enclosing type.
8.a Ramification: One can evaluate such a name, but not as a primary.
For example, one can evaluate an attribute of the object. One can
evaluate an attribute_reference, so long as it does not denote an
object, and its prefix does not disobey any of these rules. For
example, Obj'Access, Obj'Unchecked_Access, and Obj'Address are
generally legal in preelaborated library units.
9/3 * {AI95-00161-01} {AI05-0028-1} The creation of an object [(including a
component)] that is initialized by default, if its type does not have
preelaborable initialization. Similarly, the evaluation of an
extension_aggregate with an ancestor subtype_mark denoting a subtype
of such a type.
9.a Ramification: One can declare these kinds of types, but one cannot
create objects of those types.
9.b It is also nonpreelaborable to create an object if that will cause
the evaluation of a default expression that will call a
user-defined function. This follows from the rule above forbidding
nonnull statements.
9.c/2 This paragraph was deleted.{AI95-00161-01}
10/2 {AI95-00403-01} A generic body is preelaborable only if elaboration of a
corresponding instance body would not perform any such actions, presuming
that:
10.1/3 * {AI95-00403-01} {AI95-0028-1} the actual for each discriminated
formal derived type, formal private type, or formal private extension
declared within the formal part of the generic unit is a type that
does not have preelaborable initialization, unless pragma
Preelaborable_Initialization has been applied to the formal type;
10.2/2 * {AI95-00403-01} the actual for each formal type is nonstatic;
10.3/2 * {AI95-00403-01} the actual for each formal object is nonstatic; and
10.4/2 * {AI95-00403-01} the actual for each formal subprogram is a
user-defined subprogram.
10.a.1/2 Discussion: {AI95-00403-01} This is an "assume-the-worst" rule.
The elaboration of a generic unit doesn't perform any of the
actions listed above, because its sole effect is to establish that
the generic can from now on be instantiated. So the elaboration of
the generic itself is not the interesting part when it comes to
preelaboration rules. The interesting part is what happens when
you elaborate "any instantiation" of the generic. For instance,
declaring an object of a limited formal private type might well
start tasks, call functions, and do all sorts of nonpreelaborable
things. We prevent these situations by assuming that the actual
parameters are as badly behaved as possible.
10.a Reason: Without this rule about generics, we would have to forbid
instantiations in preelaborated library units, which would
significantly reduce their usefulness.
11/3 {8652/0035} {AI95-00002-01} {AI05-0034-1} {AI05-0243-1} A pragma
Preelaborate (or pragma Pure - see below) is used to specify that a library
unit is preelaborated, namely that the Preelaborate aspect of the library unit
is True; all compilation units of the library unit are preelaborated. The
declaration and body of a preelaborated library unit, and all subunits that
are elaborated as part of elaborating the library unit, shall be
preelaborable. All compilation units of a preelaborated library unit shall
depend semantically only on declared pure or preelaborated library_items. In
addition to the places where Legality Rules normally apply (see 12.3), these
rules also apply in the private part of an instance of a generic unit. [ If a
library unit is preelaborated, then its declaration, if any, and body, if any,
are elaborated prior to all nonpreelaborated library_items of the partition.]
11.a Ramification: In a generic body, we assume the worst about formal
private types and extensions.
11.a.1/1 {8652/0035} {AI95-00002-01} Subunits of a preelaborated subprogram
unit do not need to be preelaborable. This is needed in order to
be consistent with units nested in a subprogram body, which do not
need to be preelaborable even if the subprogram is preelaborated.
However, such subunits cannot depend semantically on
nonpreelaborated units, which is also consistent with nested
units.
11.b/3 Aspect Description for Preelaborate: Code execution during
elaboration is avoided for a given package.
11.1/2 {AI95-00161-01} The following rules specify which entities have
preelaborable initialization:
11.2/3 * {AI05-0028-1} The partial view of a private type or private
extension, a protected type without entry_declarations, a generic
formal private type, or a generic formal derived type, has
preelaborable initialization if and only if the pragma
Preelaborable_Initialization has been applied to them. [A protected
type with entry_declarations or a task type never has preelaborable
initialization.]
11.3/2 * A component (including a discriminant) of a record or protected
type has preelaborable initialization if its declaration includes a
default_expression whose execution does not perform any actions
prohibited in preelaborable constructs as described above, or if its
declaration does not include a default expression and its type has
preelaborable initialization.
11.4/3 * {AI05-0028-1} {AI05-0221-1} A derived type has preelaborable
initialization if its parent type has preelaborable initialization and
if the noninherited components all have preelaborable initialization.
However, a controlled type with an Initialize procedure that is not a
null procedure does not have preelaborable initialization.
11.5/2 * {AI95-00161-01} {AI95-00345-01} A view of a type has preelaborable
initialization if it is an elementary type, an array type whose
component type has preelaborable initialization, a record type whose
components all have preelaborable initialization, or an interface
type.
11.6/2 {AI95-00161-01} A pragma Preelaborable_Initialization specifies that a
type has preelaborable initialization. This pragma shall appear in the visible
part of a package or generic package.
11.7/3 {AI95-00161-01} {AI95-00345-01} {AI05-0028-1} If the pragma appears in
the first list of basic_declarative_items of a package_specification, then the
direct_name shall denote the first subtype of a composite type, and the type
shall be declared immediately within the same package as the pragma. If the
pragma is applied to a private type or a private extension, the full view of
the type shall have preelaborable initialization. If the pragma is applied to
a protected type, the protected type shall not have entries, and each
component of the protected type shall have preelaborable initialization. For
any other composite type, the type shall have preelaborable initialization. In
addition to the places where Legality Rules normally apply (see 12.3), these
rules apply also in the private part of an instance of a generic unit.
11.c/3 Reason: {AI05-0028-1} The reason why we need the pragma for
private types, private extensions, and protected types is fairly
clear: the properties of the full view determine whether the type
has preelaborable initialization or not; in order to preserve
privacy we need a way to express on the partial view that the full
view is well-behaved. The reason why we need the pragma for other
composite types is more subtle: a nonnull override for Initialize
might occur in the private part, even for a nonprivate type; in
order to preserve privacy, we need a way to express on a type
declared in a visible part that the private part does not contain
any nasty override of Initialize.
11.8/2 {AI95-00161-01} If the pragma appears in a generic_formal_part, then
the direct_name shall denote a generic formal private type or a generic formal
derived type declared in the same generic_formal_part as the pragma. In a
generic_instantiation the corresponding actual type shall have preelaborable
initialization.
11.d/2 Ramification: Not only do protected types with entry_declarations
and task types not have preelaborable initialization, but they
cannot have pragma Preelaborable_Initialization applied to them.
Implementation Advice
12 In an implementation, a type declared in a preelaborated package should
have the same representation in every elaboration of a given version of the
package, whether the elaborations occur in distinct executions of the same
program, or in executions of distinct programs or partitions that include the
given version.
12.a/2 Implementation Advice: A type declared in a preelaborated package
should have the same representation in every elaboration of a
given version of the package.
Syntax
13 The form of a pragma Pure is as follows:
14 pragma Pure[(library_unit_name)];
15 A pragma Pure is a library unit pragma.
Static Semantics
15.1/3 {AI95-00366-01} {AI05-0035-1} A pure compilation unit is a
preelaborable compilation unit whose elaboration does not perform any of the
following actions:
15.2/2 * the elaboration of a variable declaration;
15.3/2 * the evaluation of an allocator of an access-to-variable type; for
the purposes of this rule, the partial view of a type is presumed to
have nonvisible components whose default initialization evaluates such
an allocator;
15.a.1/3 Reason: {AI05-0004-1} Such an allocator would provide a backdoor
way to get a global variable into a pure unit, so it is
prohibited. Most such allocators are illegal anyway, as their type
is required to have Storage_Size = 0 (see the next two rules). But
access parameters and access discriminants don't necessarily
disallow allocators. However, a call is also illegal here (by the
preelaboration rules), so access parameters cannot cause trouble.
So this rule is really about prohibiting allocators in
discriminant constraints:
15.a.2/3 type Rec (Acc : access Integer) is record
C : Character;
end record;
15.a.3/3 Not_Const : constant Rec (Acc => new Integer'(2)); -- Illegal in a pure unit.
15.a/3 {AI05-0004-1} The second half of the rule is needed because
aggregates can specify the default initialization of a private
type or extension using <> or the ancestor subtype of an extension
aggregate. The subtype of a component could use an allocator to
initialize an access discriminant; the type still could have a
pragma Preelaborable_Initialization given. Ada 95 did not allow
such private types to have preelaborable initialization, so such a
default initialization could not have occurred. Thus this rule is
not incompatible with Ada 95.
15.4/3 * {AI05-0035-1} the elaboration of the declaration of a nonderived
named access-to-variable type unless the Storage_Size of the type has
been specified by a static expression with value zero or is defined by
the language to be zero;
15.b/2 Discussion: A remote access-to-class-wide type (see E.2.2) has its
Storage_Size defined to be zero.
15.c/2 Reason: {AI95-00366-01} We disallow most named access-to-object
types because an allocator has a side effect; the pool constitutes
variable data. We allow access-to-subprogram types because they
don't have allocators. We even allow named access-to-object types
if they have an empty predefined pool (they can't have a
user-defined pool as System.Storage_Pools is not pure). In this
case, most attempts to use an allocator are illegal, and any
others (in a generic body) will raise Storage_Error.
15.5/3 * {AI05-0035-1} the elaboration of the declaration of a nonderived
named access-to-constant type for which the Storage_Size has been
specified by an expression other than a static expression with value
zero.
15.d/2 Discussion: We allow access-to-constant types so long as there is
no user-specified nonzero Storage_Size; if there were a
user-specified nonzero Storage_Size restricting the size of the
storage pool, allocators would be problematic since the package is
supposedly `stateless', and the allocated size count for the
storage pool would represent state.
15.6/3 {AI05-0035-1} A generic body is pure only if elaboration of a
corresponding instance body would not perform any such actions presuming any
composite formal types have nonvisible components whose default initialization
evaluates an allocator of an access-to-variable type.
15.7/2 {AI95-00366-01} The Storage_Size for an anonymous access-to-variable
type declared at library level in a library unit that is declared pure is
defined to be zero.
15.e/2 Ramification: This makes allocators illegal for such types (see
4.8), making a storage pool unnecessary for these types. A storage
pool would represent state.
15.f/2 Note that access discriminants and access parameters are never
library-level, even when they are declared in a type or subprogram
declared at library-level. That's because they have their own
special accessibility rules (see 3.10.2).
Legality Rules
16/2 This paragraph was deleted.{AI95-00366-01}
17/3 {AI95-00366-01} {AI05-0034-1} {AI05-0035-1} {AI05-0243-1} A pragma Pure
is used to specify that a library unit is declared pure, namely that the Pure
aspect of the library unit is True; all compilation units of the library unit
are declared pure. In addition, the limited view of any library package is
declared pure. The declaration and body of a declared pure library unit, and
all subunits that are elaborated as part of elaborating the library unit,
shall be pure. All compilation units of a declared pure library unit shall
depend semantically only on declared pure library_items. In addition to the
places where Legality Rules normally apply (see 12.3), these rules also apply
in the private part of an instance of a generic unit. Furthermore, the full
view of any partial view declared in the visible part of a declared pure
library unit that has any available stream attributes shall support external
streaming (see 13.13.2).
17.a/3 This paragraph was deleted.{AI05-0243-1}
17.b Discussion: A declared-pure package is useful for defining types
to be shared between partitions with no common address space.
17.c Reason: Note that generic packages are not mentioned in the list
of things that can contain variable declarations. Note that the
Ada 95 rules for deferred constants make them allowable in library
units that are declared pure; that isn't true of Ada 83's deferred
constants.
17.d/2 Ramification: {AI95-00366-01} Anonymous access types are allowed.
17.d.1/3 {AI05-0243-1} A limited view is not a library unit, so any rule
that starts "declared pure library unit" does not apply to a
limited view. In particular, the 3rd and last sentences never
apply to limited views. However, a limited view is a
library_item, so rules that discuss "declared pure library_item
s" do include limited views.
17.e/2 Reason: {AI95-00366-01} Ada 95 didn't allow any access types as
these (including access-to-subprogram types) cause trouble for
Annex E, "Distributed Systems", because such types allow access
values in a shared passive partition to designate objects in an
active partition, thus allowing inter-address space references. We
decided to disallow such uses in the relatively rare cases where
they cause problems, rather than making life harder for the
majority of users. Types declared in a pure package can be used in
remote operations only if they are externally streamable. That
simply means that there is a means to transport values of the
type; that's automatically true for nonlimited types that don't
have an access part. The only tricky part about this is to avoid
privacy leakage; that was handled by ensuring that any private
types (and private extensions) declared in a pure package that
have available stream attributes (which include all nonlimited
types by definition) have to be externally streamable.
17.f/3 Aspect Description for Pure: Side effects are avoided in the
subprograms of a given package.
Erroneous Execution
17.1/4 {AI12-0076-1} Execution is erroneous if some operation (other than the
initialization or finalization of the object) modifies the value of a constant
object declared at library-level in a pure package.
17.g/4 Discussion: This could be accomplished via a self-referencing
pointer or via squirrelling a writable pointer to a controlled
object.
Implementation Permissions
18/3 {AI95-00366-01} {AI05-0219-1} If a library unit is declared pure, then
the implementation is permitted to omit a call on a library-level subprogram
of the library unit if the results are not needed after the call. In addition,
the implementation may omit a call on such a subprogram and simply reuse the
results produced by an earlier call on the same subprogram, provided that none
of the parameters nor any object accessible via access values from the
parameters have any part that is of a type whose full type is an immutably
limited type, and the addresses and values of all by-reference actual
parameters, the values of all by-copy-in actual parameters, and the values of
all objects accessible via access values from the parameters, are the same as
they were at the earlier call. [This permission applies even if the subprogram
produces other side effects when called.]
18.a/3 Discussion: {AI95-00366-01} {AI05-0005-1} {AI05-0299-1} A
declared-pure library_item has no variable state. Hence, a call on
one of its (nonnested) subprograms cannot normally have side
effects. Side effects are still possible via dispatching calls and
via indirect calls through access-to-subprogram values. Other
mechanisms that might be used to modify variable state include
machine code insertions, imported subprograms, and unchecked
conversion to an access type declared within the subprogram; this
list is not exhaustive. Thus, the permissions described in this
subclause may apply to a subprogram whose execution has side
effects. The compiler may omit a call to such a subprogram even if
side effects exist, so the writer of such a subprogram has to keep
this in mind.
Syntax
19 The form of a pragma Elaborate, Elaborate_All, or Elaborate_Body is as
follows:
20 pragma Elaborate(library_unit_name{, library_unit_name});
21 pragma Elaborate_All(library_unit_name{, library_unit_name});
22 pragma Elaborate_Body[(library_unit_name)];
23 A pragma Elaborate or Elaborate_All is only allowed within a
context_clause.
23.a Ramification: "Within a context_clause" allows it to be the last
item in the context_clause. It can't be first, because the name
has to denote something mentioned earlier.
24 A pragma Elaborate_Body is a library unit pragma.
24.a Discussion: Hence, a pragma Elaborate or Elaborate_All is not
elaborated, not that it makes any practical difference.
24.b Note that a pragma Elaborate or Elaborate_All is neither a program
unit pragma, nor a library unit pragma.
Legality Rules
25/3 {AI05-0229-1} If the aspect Elaborate_Body is True for a declaration
[(including when pragma Elaborate_Body applies)], then the declaration
requires a completion [(a body)].
25.a/3 Proof: {AI05-0229-1} Pragma Elaborate_Body sets the aspect (see
below).
25.1/2 {AI95-00217-06} The library_unit_name of a pragma Elaborate or
Elaborate_All shall denote a nonlimited view of a library unit.
25.b/2 Reason: These pragmas are intended to prevent elaboration check
failures. But a limited view does not make anything visible that
has an elaboration check, so the pragmas cannot do anything
useful. Moreover, the pragmas would probably reintroduce the
circularity that the limited_with_clause was intended to break. So
we make such uses illegal.
Static Semantics
26/3 {AI05-0229-1} [A pragma Elaborate specifies that the body of the named
library unit is elaborated before the current library_item. A pragma
Elaborate_All specifies that each library_item that is needed by the named
library unit declaration is elaborated before the current library_item.]
26.a Proof: The official statement of the semantics of these pragmas is
given in 10.2.
26.1/3 {AI05-0229-1} A pragma Elaborate_Body sets the Elaborate_Body
representation aspect of the library unit to which it applies to the value
True. [If the Elaborate_Body aspect of a library unit is True, the body of the
library unit is elaborated immediately after its declaration.]
26.a.1/3 Proof: The official statement of the semantics of this aspect is
given in 10.2.
26.b Implementation Note: The presence of a pragma Elaborate_Body
simplifies the removal of unnecessary Elaboration_Checks. For a
subprogram declared immediately within a library unit to which a
pragma Elaborate_Body applies, the only calls that can fail the
Elaboration_Check are those that occur in the library unit itself,
between the declaration and body of the called subprogram; if
there are no such calls (which can easily be detected at compile
time if there are no stubs), then no Elaboration_Checks are needed
for that subprogram. The same is true for Elaboration_Checks on
task activations and instantiations, and for library subprograms
and generic units.
26.c Ramification: The fact that the unit of elaboration is the
library_item means that if a subprogram_body is not a completion,
it is impossible for any library_item to be elaborated between the
declaration and the body of such a subprogram. Therefore, it is
impossible for a call to such a subprogram to fail its
Elaboration_Check.
26.d Discussion: The visibility rules imply that each
library_unit_name of a pragma Elaborate or Elaborate_All has to denote a
library unit mentioned by a previous with_clause of the same
context_clause.
26.e/3 Aspect Description for Elaborate_Body: A given package must have a
body, and that body is elaborated immediately after the
declaration.
NOTES
27 12 A preelaborated library unit is allowed to have nonpreelaborable
children.
27.a/1 Ramification: {8652/0035} {AI95-00002-01} But generally not
nonpreelaborated subunits. (Nonpreelaborated subunits of
subprograms are allowed as discussed above.)
28 13 A library unit that is declared pure is allowed to have impure
children.
28.a/1 Ramification: {8652/0035} {AI95-00002-01} But generally not impure
subunits. (Impure subunits of subprograms are allowed as discussed
above.)
28.b Ramification: Pragma Elaborate is mainly for closely related
library units, such as when two package bodies 'with' each other's
declarations. In such cases, Elaborate_All sometimes won't work.
Extensions to Ada 83
28.c The concepts of preelaborability and purity are new to Ada 95. The
Elaborate_All, Elaborate_Body, Preelaborate, and Pure pragmas are
new to Ada 95.
28.d Pragmas Elaborate are allowed to be mixed in with the other things
in the context_clause - in Ada 83, they were required to appear
last.
Incompatibilities With Ada 95
28.e/2 {AI95-00366-01} The requirement that a partial view with available
stream attributes be externally streamable can cause an
incompatibility in rare cases. If there is a limited tagged type
declared in a pure package with available attributes, and that
type is used to declare a private extension in another pure
package, and the full type for the private extension has a
component of an explicitly limited record type, a protected type,
or a type with access discriminants, then the stream attributes
will have to be user-specified in the visible part of the package.
That is not a requirement for Ada 95, but this combination seems
very unlikely in pure packages. Note that this cannot be an
incompatibility for a nonlimited type, as all of the types that
are allowed in Ada 95 that would require explicitly defined stream
attributes are limited (and thus cannot be used as components in a
nonlimited type).
28.f/2 {AI95-00403-01} Amendment Correction: Added wording to cover
missing cases for preelaborated generic units. This is
incompatible as a preelaborated unit could have used a formal
object to initialize a library-level object; that isn't allowed in
Ada 2005. But such a unit wouldn't really be preelaborable, and
Ada 95 compilers can reject such units (as this is a Binding
Interpretation), so such units should be very rare.
Extensions to Ada 95
28.g/2 {AI95-00161-01} Amendment Correction: The concept of preelaborable
initialization and pragma Preelaborable_Initialization are new.
These allow more types of objects to be created in preelaborable
units, and fix holes in the old rules.
28.h/2 {AI95-00366-01} Access-to-subprogram types and access-to-object
types with a Storage_Size of 0 are allowed in pure units. The
permission to omit calls was adjusted accordingly (which also
fixes a hole in Ada 95, as access parameters are allowed, and
changes in the values accessed by them must be taken into
account).
Wording Changes from Ada 95
28.i/2 {AI95-00002-01} Corrigendum: The wording was changed so that
subunits of a preelaborated subprogram are also preelaborated.
28.j/2 {AI95-00217-06} Disallowed pragma Elaborate and Elaborate_All for
packages that are mentioned in a limited_with_clause.
Incompatibilities With Ada 2005
28.k/3 {AI05-0028-1} Correction: Corrected a serious unintended
incompatibility with Ada 95 in the new preelaboration wording -
explicit initialization of objects of types that don't have
preelaborable initialization was not allowed. Ada 2012 switches
back to the Ada 95 rule in these cases. This is unlikely to occur
in practice, as it is unlikely that a compiler would have
implemented the more restrictive rule (it would fail many ACATS
tests if it did).
28.l/3 {AI05-0035-1} Correction: Added an assume-the-worst rule for
generic bodies (else they would never be checked for purity) and
added the boilerplate so that the entire generic specification is
rechecked. Also fixed wording to have consistent handling for
subunits for Pure and Preelaborate. An Ada 95 program could have
depended on marking a generic pure that was not really pure,
although this would defeat the purpose of the categorization and
likely cause problems with distributed programs.
Extensions to Ada 2005
28.m/3 {AI05-0035-1} Correction: Adjusted wording so that a subunit can
be pure (it is not a library_item, but it is a compilation unit).
28.n/3 {AI05-0035-1} Correction: Adjusted wording so that the rules for
access types only apply to nonderived types (derived types share
their storage pool with their parent, so if the parent access type
is legal, so is any derived type.)
28.o/3 {AI05-0229-1} Elaborate_Body is now an aspect, so it can be
specified by an aspect_specification - although the pragma is
still preferred by the Standard.
28.p/3 {AI05-0243-1} Pure and Preelaborate are now aspects, so they can
be specified by an aspect_specification - although the pragmas are
still preferred by the Standard.
Wording Changes from Ada 2005
28.q/3 {AI05-0034-1} Correction: Added wording so that a limited view is
always treated as pure, no matter what categorization is used for
the originating unit. This was undefined in Ada 2005.
28.r/3 {AI05-0028-1} {AI05-0221-1} Correction: Fixed minor issues with
preelaborable initialization (PI): null Initialize procedures do
not make a type non-PI; formal types with pragma PI can be assumed
to have PI; formal extensions are assumed to not have PI; all
composite types can have pragma PI (so that the possibility of
hidden Initialize routines can be handled); added discriminants of
a derived type are not considered in calculating PI.
28.s/3 {AI05-0219-1} Correction: Clarified that the implementation
permission to omit pure subprogram calls does not apply if any
part of the parameters or any designated object has a part that is
immutably limited. The old wording just said "limited type", which
can change via visibility and thus isn't appropriate for dynamic
semantics permissions.
Wording Changes from Ada 2012
28.t/4 {AI12-0076-1} Corrigendum: Explicitly stated that modifying a
library-level constant in a pure package is erroneous. We don't
document this as inconsistent as implementations certainly can
still do whatever they were previously doing (no change is
required); moreover, this case (and many more) were erroneous in
Ada 2005 and before, so we're just restoring the previous
semantics.
Generated by dwww version 1.15 on Fri May 24 05:46:44 CEST 2024.