Re: AQ&S Guidance on pragma Elaborate_Body

[dewar@merv.cs.nyu.edu (Robert Dewar)]

Bob Duff said

<<But my assertion was that one could be rid of Program_Errors due to
  calling subprograms before they've been elaborated.>>

That was one of your assertions, and I agree with it, but you also asserted
that "you could dispense with all elaboration-control pragmas", and that
is more contentious, since it would reduce the expressive power of the
language, no matter how clever your implementation is.

You realize this of course, and then dispute my example (that's fair, if
a language designer suggests removing a feature that someone thinks is
essential, they can argue that it is not so essential, and that the
programs affected are somehow wrong:

<<OK, but tell us why Glorp doesn't simply call Thunk in its elaboration?
  I mean, the whole point of having elaboration is to get stuff
  initialized, and it should be Glorp's responsibility to do that.>>

I am the client, there is no way I can change my server, especially if
the server is in fact an external threads package (as was the case in
the particular instance). 

How about Glorp is "get the next random number", and Thunk is "initialize
the random number with an appropriate seed". I can quite see that the
issues of initializing the random number generators for a run, and 
using them to compute some initial static tables might be handled
in different packages.

<<I admit that your example shows a case where you want to control
elaboration order, which has nothing to do with the predefined
Program_Error checks.  Is that something the language should help you
with?  I'm not sure.>>

If the language does not let you control elaboration order, then it should
not provide elaboration, otherwise you can get into too much trouble. This
can be a major problem in C++ programs, where there is no control. We have
nice mechanisms in Ada that are very powerful, and allow handling cases
like this nicely.

I agree it would be nice if elaboration could be handled entirely statically.
The problem is finding a nice model for this. Requiring a compiler to build
a call graph for the entire program is painful (and indeed we explicitly
rejected this possibility during the Ada 95 design effort).

I think the model I have just
implemented in GNAT is very attractive, it avoids the need for a program
wide call graph (which would be an unattractive extra expense), but seems
powerful enough in practice to handle most normal cases (we found no
counter example in our regression suite, and only a couple of counter
examples in the ACVC suite -- so we run the ACVC suite with the switch
that requires full dynamic semantics for elaboration.

However, when I implemented this, my nice circuitry for choosing a good
elaboration order caused the SGI version of the runtime to blow up. The
order it chose was Program_Error free, but ran afoul of some implicit
ordering requirements (abstracted into my Glorp/Thunk example). Of 
course a pragma Elaborate or Elaborate_All properly placed would fix this.

It will be interesting to see how well the GNAT static model works. Basically
the short cut is to imply a pragma Elaborate)All on any package or generic that
is directly or indirectly accessed in elaboration code (if it is not Pure,
Preelaborate, predefined, or Elaborate_Body). For internal threads of control,
the equivalent of a full call graph is used (though never explicitly built).

More informatoin will be available when 3.10 and its documentation is released

Robert Dewar
Ada Core Technologies