From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,baa6871d466e5af9 X-Google-Attributes: gid103376,public From: dewar@merv.cs.nyu.edu (Robert Dewar) Subject: Re: AQ&S Guidance on pragma Elaborate_Body Date: 1997/04/23 Message-ID: #1/1 X-Deja-AN: 237067135 References: <528878564wnr@diphi.demon.co.uk> <5jabeq$3ltk@info4.rus.uni-stuttgart.de> Organization: New York University Newsgroups: comp.lang.ada Date: 1997-04-23T00:00:00+00:00 List-Id: Bob Duff said <> 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: <> 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. <> 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