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,cf75272301f10c97 X-Google-Attributes: gid103376,public From: stt@houdini.camb.inmet.com (Tucker Taft) Subject: Re: Ada.Exceptions could be 'pragma Preelaborate' ? Date: 1998/10/30 Message-ID: #1/1 X-Deja-AN: 406774227 Sender: news@inmet.camb.inmet.com (USENET news) X-Nntp-Posting-Host: houdini.camb.inmet.com References: Organization: Intermetrics, Inc. Newsgroups: comp.lang.ada Date: 1998-10-30T00:00:00+00:00 List-Id: Stephen Leake (Stephen.Leake@gsfc.nasa.gov) wrote: : Currently, Ada.Exceptions has no elaboration pragma, and thus any unit : that 'withs' Ada.Exceptions cannot have 'pragma Preelaborate'. This is : a pain; I'm building a nice library, everything is either Pure or : Preelaborate, but then I start adding nice error messages to my : exceptions, and I have to get rid of the pragmas. I started replacing : Preelaborate with Elaborate_Body, and got some circular elaboration : problems. : So, is there a reason Ada.Exceptions can't be Preelaborate? nothing in : the public spec violates a rule; do most implementations require : something that does? Probably RM95 should have erred on the side of putting too many Preelaborate pragmas in, rather than too few. Implementations sometimes have to "cheat" anyway, so we shouldn't have worried about that. I think the rationale for not putting a Preelaborate here was that it clearly depended on the run-time system, and most run-time systems certainly need to do some kind of run-time initialization. However, it is permissible to raise exceptions in a preelaborable package, so calling Raise_Exception explicitly should be allowed as well. This problem could probably be "fixed" pretty quickly by the Ada Rapporteur Group as part of their language maintenance activities. We have already been looking into the general issue of "categorization" pragmas for run-time system packages. Package Calendar is another one which should probably get a Preelaborate pragma. There probably aren't many language-defined packages that shouldn't either have a pragma Pure or a pragma Preelaborate. A similar issue relates to the Remote_Types pragma, for what it is worth... : -- Stephe -- -Tucker Taft stt@inmet.com http://www.inmet.com/~stt/ Intermetrics, Inc. Burlington, MA USA An AverStar Company