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: bobduff@world.std.com (Robert A Duff) Subject: Re: AQ&S Guidance on pragma Elaborate_Body Date: 1997/04/23 Message-ID: #1/1 X-Deja-AN: 236884527 References: <528878564wnr@diphi.demon.co.uk> <5jabeq$3ltk@info4.rus.uni-stuttgart.de> Organization: The World Public Access UNIX, Brookline, MA Newsgroups: comp.lang.ada Date: 1997-04-23T00:00:00+00:00 List-Id: In article , Robert Dewar wrote: >Robert Duff said > ><(slow?) processing at link time, you could dispense with all >elaboration-control pragmas, and have the link phase determine an >elaboration order that's guaranteed to not raise Program_Error. But >note that some of these pragmas (Pure, especially) have purposes other >than just elaboration order.>> > >No, that's quite wrong. There are many things that can place restrictions >on the order of elaboration. But my assertion was that one could be rid of Program_Errors due to calling subprograms before they've been elaborated. That's certainly true. The link-time processing would have to walk the call graph, and make sure every subprogram gets elaborated before it might be called. This is complex, and perhaps slow, and would make some (fairly obscure) legal programs illegal. 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. It seems to me that elaboration order should not be implementation dependent -- the main problem with the current Ada rules is that you can port code (or simply recompile with a new version of your compiler) and get a P_E that didn't used to happen. But your example seems questionable to me. (See below.) >Suppose we have a package Glorp that has several procedures including >Thunk, Boggle, and Glub. In the comments of package Glorp, we find the >comment: > >-- WARNING: It is essential to call Thunk before calling Boggle. If you >-- fail to do this, all subsequent calls to Glub will raise the Glob-Glob >-- exception or otherwise malfunction. Clients of Glorp are responsible for >-- obeying this rule, since no check is made (a check would introduce too >-- much overhead). 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 will admit that no reasonable Ada implementation will understand the above comment. ;-) >Now, suppose we have two clients of Glorp, Jabber and Wocky. The elaboration >code of Jabber calls Thunk, and the elaboration code of Wocky calls Boggle. > >Well now it is essential that Jabber is elaborated before Wocky, and no >static analysis of the program code can determine this, and a pragma >Elaborate is required. > >And if you think this is just theoretical, think again, there are >instantiations of the names above in the SGI GNAT runtime library, and >when we installed some new clever elaboration stuff (a bit like Bob >proposes, but more effective, and easier to understand), the binder >chose a much better elaboration order, much more clearly guaranteed >to prevent Program_Error, but unfortunately wrong (of course this is >a bug in the runtime, there is a missing pragma Elaborate). But wouldn't the runtime be simpler if each package took care of its own initialization? >It is quite true that you can guarantee absence from Program_Error for a wide >variety of programs automatically, and version 3.10 of GNAT does that. That's all I was asserting. >...BUT >it is far from true that this means that you could "dispense with all >elaboration-control pragmas". You quote me out of context -- there's a ", and have the link phase determine an elaboration order that's guaranteed to not raise Program_Error." there. That's all I meant, although the more general situation is interesting from a language design point of view. - Bob