Re: Elaboration in GNAT

[dewar@gnat.com (Robert Dewar)]

Robert A Duff <bobduff@shell01.TheWorld.com> wrote in message news:<wcck7up80yy.fsf@shell01.TheWorld.com>...
> dewar@gnat.com (Robert Dewar) writes:
> 
> > I understand that this is theoretically true, but in practice with
> > GNAT's static model problems do not arise.
> > We have not had one customer using the static model ever
> > run into any elaboration problems at all.
> 
> I skept.  That is, I think you should say, "We have not had one customer
> REPORT TO US ...."  :-)


Well as a competitor (who does not have this capability)
you may of course skept :-) :-)

But our supported customers are not shy about telling us
if they have any problems!

There is one kind of order of elaboration problem that
cannot be dealt with in any automatic manner, and is in
a sense completely outside the elaboration model, and that
is the situation in which the order of elaboration is
important not because of access-before-elaboration issues
(which is what the GNAT model is all about) but because of
other issues.

Consider a library declaration that says:

   x : integer := y.z;

where in package y there is

   y : integer := 35;

Now some other package z which has no elaboration relationship to x
whatsoever (i.e. it is not with'ed
by x and does no with x, directly or indirectly) has
a package body that says:

   y.z := 42;

Now the question is whether x gets initialized to 35 or
42, and that of course depends on when package z is 
elaborated. Either answer might be the intended "right"
one, and there is no clue in the sources at ALL about which
of these is right, so neither choice is better than the
other.

Naturally, GNAT has nothing to say about this issue (and
perhaps that is where Bob's "skept" comes from).

Note that even the Ada language is uncomfortable here, there is no way
for package x to demand that z be elaborated after itself, and even if
the desire is to
have it elaborated before, it is junky to have to add
a with for z just so that it can be mentioned in a pragma
Elaborate.

For a more complete description of this problem, see the
section "Other Elaboration Order Considerations" in the
GNAT users guide.

Actually the history of this section is interesting. We
thought at one time that we had a customer who had run into
this situation, but it turns out that it was something else, but still
it seemed worth generating the special section in the manual on this.

But the bottom line here is that elaboration has proved a
big issue for code using the dynamic elaboration model in
GNAT, in particular legacy code with missing pragma Elaborates, but
once the static model has been satisfied,
elaboration disappears as a significant issue in practice.
That's based on a lot of experience in working with hundreds of
million lines of legacy code from our customers.