Ada provides rather general mechanisms for executing code at elaboration time, that is to say before the main program starts executing. Such code arises in three contexts:
Variables declared at the library level, in package specs or bodies, can require initialization that is performed at elaboration time, as in:
Sqrt_Half : Float := Sqrt (0.5);
Code in a BEGIN-END section at the outer level of a package body is executed as part of the package body elaboration code.
Tasks that are declared using task allocators at the library level start executing immediately and hence can execute at elaboration time.
Subprogram calls are possible in any of these contexts, which means that any arbitrary part of the program may be executed as part of the elaboration code. It is even possible to write a program which does all its work at elaboration time, with a null main program, although stylistically this would usually be considered an inappropriate way to structure a program.
An important concern arises in the context of elaboration code: we have to be sure that it is executed in an appropriate order. What we have is a series of elaboration code sections, potentially one section for each unit in the program. It is important that these execute in the correct order. Correctness here means that, taking the above example of the declaration of Sqrt_Half, if some other piece of elaboration code references Sqrt_Half, then it must run after the section of elaboration code that contains the declaration of Sqrt_Half.
There would never be any order of elaboration problem if we made a rule that whenever you `with' a unit, you must elaborate both the spec and body of that unit before elaborating the unit doing the `with'ing:
with Unit_1;
package Unit_2 is ...
would require that both the body and spec of Unit_1 be elaborated before the spec of Unit_2. However, a rule like that would be far too restrictive. In particular, it would make it impossible to have routines in separate packages that were mutually recursive.
You might think that a clever enough compiler could look at the actual elaboration code and determine an appropriate correct order of elaboration, but in the general case, this is not possible. Consider the following example.
In the body of Unit_1, we have a procedure Func_1 that references the variable Sqrt_1, which is declared in the elaboration code of the body of Unit_1:
Sqrt_1 : Float := Sqrt (0.1);
The elaboration code of the body of Unit_1 also contains:
if expression_1 = 1 then
Q := Unit_2.Func_2;
end if;
Unit_2 is exactly parallel, it has a procedure Func_2 that references the variable Sqrt_2, which is declared in the elaboration code of the body Unit_2:
Sqrt_2 : Float := Sqrt (0.1);
The elaboration code of the body of Unit_2 also contains:
if expression_2 = 2 then
Q := Unit_1.Func_1;
end if;
Now the question is, which of the following orders of elaboration is acceptable:
Spec of Unit_1
Spec of Unit_2
Body of Unit_1
Body of Unit_2
or
Spec of Unit_2
Spec of Unit_1
Body of Unit_2
Body of Unit_1
If you carefully analyze the flow here, you will see that you cannot tell at compile time the answer to this question. If expression_1 is not equal to 1, and expression_2 is not equal to 2, then either order is acceptable, because neither of the function calls is executed. If both tests evaluate to true, then neither order is acceptable and in fact there is no correct order.
If one of the two expressions is true, and the other is false, then one of the above orders is correct, and the other is incorrect. For example, if expression_1 /= 1 and expression_2 = 2, then the call to Func_1 will occur, but not the call to Func_2. This means that it is essential to elaborate the body of Unit_1 before the body of Unit_2, so the first order of elaboration is correct and the second is wrong.
By making expression_1 and expression_2 depend on input data, or perhaps the time of day, we can make it impossible for the compiler or binder to figure out which of these expressions will be true, and hence it is impossible to guarantee a safe order of elaboration at run time.