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/22 Message-ID: #1/1 X-Deja-AN: 236475046 References: <528878564wnr@diphi.demon.co.uk> <5jfu0b$l5p@top.mitre.org> Organization: The World Public Access UNIX, Brookline, MA Newsgroups: comp.lang.ada Date: 1997-04-22T00:00:00+00:00 List-Id: In article <5jfu0b$l5p@top.mitre.org>, Michael F Brenner wrote: >One more thing must be said: in reusing this software, the reuse itself >might have a circular dependency, which the compiler may or may not >be able to figure out. What do you mean by this? If by "reuse" you mean taking some existing set of packages, and using them without modification, then I don't see how you can introduce a circularity. To make a cycle, you need to add a with_clause to one of those packages. >... To reduce the amount of stuff that the compiler >has to worry about, and to make it possible to compute a SINGLE >elaboration order (without which the program may raise program_error >at will), you MUST add one of the first three to all packages you >think are NOT in a circular elaboration dependency loop. Doing this >also helps you identify your elaboration loops more clearly, so you >can deal with them using elaborate or elaborate_all or by removing >the regression testing code from the elaboration-time executable >statements at the bottom of the package. Failure to add these will >cause needless failures when they are reused INSIDE an elaboration >dependency loop. I agree that it's a good idea to put Pure, Preelaborate, or Elab_Body on everything you can, but I don't see how you can reuse something inside an elab dep loop. Unless you're changing the re-used stuff, in which case, of course, you can introduce cycles. Or plain old bugs, for that matter. Probably Elaborate_Body should have been the default (or maybe even Preelab or Pure), and there should have been a pragma to turn *off* Elab_Body, in case of mutual recursion. (By "recursion", I mean "defined in terms of itself", not necessarily recursive calling. E.g. mutually recursive type declarations can exist.) IMHO the worst thing about this stuff is that elab order is not portable. If you make a mistake, you might not find out until you're long dead and somebody else tries to port your code. - Bob