10.1.1 Compilation Units - Library Units
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.
library unit is a child
of its parent unit. The root
units are the children of the predefined library package Standard.
parent_unit_name ::= name
The children of a library unit occur immediately
within the declarative region of the declaration of the library unit.
of a library unit are itself,
its parent, its parent's parent, and so on. (Standard is an ancestor
of every library unit.)
is the inverse of the ancestor relation.
or a library_unit_renaming_declaration
if the declaration is immediately preceded by the reserved
; it is otherwise public
. A library unit is
private or public according to its declaration.
of a library unit are the library unit itself,
and the public descendants of its public children.
other descendants are private descendants
For each library package_declaration
in the environment, there is an implicit declaration of a limited
of that library package.
The limited view
of a package contains:
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
The parent unit of a library_item
shall be a library package or generic library package.
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.
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.
A child of a parent generic package shall be instantiated
or renamed only within the declarative region of the parent generic.
For each child C
of some parent generic package
, there is a corresponding declaration C
within each instance of P
. For the purposes of this rule, if a
itself has a child D
, each corresponding declaration
has a corresponding child D
. The corresponding declaration
for a child within an instance is visible only within the scope of a
that mentions the (original) child generic unit.
A library subprogram shall not override a primitive
The defining name of a function that is a compilation
unit shall not be an operator_symbol
There are two kinds
of dependences among compilation units:
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.
The elaboration dependences
determine the order of elaboration of 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
mentioned in a with_clause
of the compilation unit. In addition, if a given compilation unit contains
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.
The elaboration of the declaration of the limited
view of a package has no effect.
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
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_declaration
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
Examples of library
-- public child of Rational_Numbers, see 7.1
Put(R : in
Get(R : out
private procedure Rational_Numbers.Reduce(R : in out Rational);
-- private child of Rational_Numbers
with Rational_Numbers.Reduce; -- refer to a private child
package body Rational_Numbers is
Ada.Text_io; -- see A.10
-- a root library procedure
R : Rational;
R := 5/3; -- construct a rational number, see 7.1
Ada.Text_IO.Put("The answer is: ");
package Rational_IO renames Rational_Numbers.IO;
-- a library unit renaming declaration
Each of the above library_item
can be submitted to the compiler separately.
Ada 2005 and 2012 Editions sponsored in part by Ada-Europe