- (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'').
- (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)
- The mechanisms for creating an environment and for adding and replacing
compilation units within an environment are implementation defined.
Name Resolution Rules
- (4)
- 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 for a subprogram or a generic subprogram with the same defining_program_unit_name already exists in the environment (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.
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.
Implementation Permissions
- (6)
- The implementation may require that a compilation unit be legal before
inserting it into the environment.
- (7)
- 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 with the same defining_program_unit_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 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 to which a pragma Inline
applies, the implementation may also remove any compilation unit containing a
call to that subprogram.
-
- (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.
- (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.
- (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.
-- Email comments, additions, corrections, gripes, kudos, etc. to:
Magnus Kempe -- Magnus.Kempe@di.epfl.ch
Copyright statement
Page last generated: 95-03-12