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=0.2 required=5.0 tests=BAYES_00,INVALID_MSGID, REPLYTO_WITHOUT_TO_CC 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: Mats Weber Subject: Re: AQ&S Guidance on pragma Elaborate_Body Date: 1997/04/24 Message-ID: <335F5449.6644@elca-matrix.ch>#1/1 X-Deja-AN: 237105069 References: <528878564wnr@diphi.demon.co.uk> <5jabeq$3ltk@info4.rus.uni-stuttgart.de> Organization: ELCA Matrix SA Reply-To: Mats.Weber@elca-matrix.ch Newsgroups: comp.lang.ada Date: 1997-04-24T00:00:00+00:00 List-Id: Robert A Duff wrote: > 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. I agree 100% here, and the solution was described at least in two articles before or during the Ada 9X effort. I still don't understand why it's not in the language. Moreover, most compilers I have used do a very good job of putting packages in a 'good' elaboration order, to the point that I almost never bother using the elaboration pragmas, taking the risk of hitting a bad compiler some time in the future (which won't be GNAT, given the effort being made to solve the problem :-). I really think this elaboration stuff should fixed in an AI (of course only the part that ensures Program_Error is not raised on a subprogram call or generic instantiation). Do you think that would be possible, or will we have to wait until Ada 0X ? :-)