!topic LSN on Library Unit Elaboration in Ada 9X
!key LSN-1041 on Library Unit Elaboration in Ada 9X
!reference MS-10.5;4.6
!from Bob Duff $Date: 92/10/10 11:40:10 $ $Revision: 1.2 $
!discussion

This Language Study Note discusses our current thinking on order of
library unit elaboration in Ada 9X.

MS-10.5;4.6 makes pragma ELABORATE transitive.  However, due to
upward compatibility concerns expressed by the DRs, we will probably
put pragma ELABORATE back the way it was in Ada 83, and add a new
pragma with the transitive semantics.

The need for transitive semantics is clear: Suppose A calls B during
elaboration, and B calls C, but not during elaboration.  Since B does
not need C during elaboration, it will not have pragma Elaborate(C).
A needs to have pragma Elaborate(B), and also pragma Elaborate(C).
The latter is a violation of abstraction -- A should not need to even
know about the existence of C.  A probably doesn't even 'with' C.  In
Ada 9X, C might be a private child that A is not even allowed to
'with'.

Pragma ELABORATE_BODY also exists in Ada 9X.  It is placed on the
declaration of a library unit, and causes the body of that library
unit to be elaborated immediately after the declaration.  The reason
for requiring it on the declaration, rather than the body, is to
allow the compiler to optimize by removing elaboration checks.  If
the compiler knows that the body will follow immediately, then the
only possible way to fail an elaboration check is for a call to
appear textually between the declaration and body of the called
subprogram.  Since that is easy to analyze, the optimization becomes
easy.

We have also studied the idea of solving the elaboration order
problem entirely at compilation time and post-compilation time (known
in the vernacular as "link time").  The order would be determined
before running the partition, and all elaboration check failures
would also be determined at that time.  The compiler would never need
to generate the run-time checking code, and no run-time failures
would need to be debugged.

However, the exact definition of the compile-time-determined order is
somewhat lengthy, and no such definition can be strictly upward
compatible.  Therefore, we are considering the idea of defining a pragma
that asks for a compile-time-determined order, and states that the
programmer is willing to live with some restrictions.  The restrictions
would be implementation defined.  The implementation-definedness is not
ideal, but it saves us the trouble of writing that long list of rules,
and saves us from arguing endlessly about what the rules should be.  We
believe this solution to be better than the alternative of leaving the
feature out altogether, since it will at least encourage implementations
to do something reasonable.

We might decide to put this pragma in the Safety and Security Annex.
Although the need is more universal, safety-critical systems are
particularly troubled by the non-determinism and error-pronedness of the
Ada 83 rules, so it does make sense in that Annex.  There's certainly no
need to force everyone to implement it, if the semantics are
implementation defined anyway.