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,5dba30d6260ef552 X-Google-Attributes: gid103376,public From: "Wolf-Dieter Heker" Subject: Re: Elaboration Order Date: 1999/11/16 Message-ID: #1/1 X-Deja-AN: 549212322 Sender: news@sd.aonix.com (USENET News Admin @flash) X-Nntp-Posting-Host: 192.157.139.120 References: <80pcdf$7u5$1@nnrp1.deja.com> Organization: Aonix, San Diego, CA, USA X-Msmail-Priority: Normal X-Priority: 3 Newsgroups: comp.lang.ada X-Mimeole: Produced By Microsoft MimeOLE V5.00.2014.211 Date: 1999-11-16T00:00:00+00:00 List-Id: Robert Dewar schrieb in im Newsbeitrag: 80pcdf$7u5$1@nnrp1.deja.com... > In article , > "Wolf-Dieter Heker" wrote: > > Hence I would suggest that these packages should contain an > > elaborate_body pragma (except, of course, if the have no > body). But alas, > > most programmers - including myself ;-) - do not write these > pragmas until > > the get into trouble. > > Well then they are not following standard coding guidelines, > which is to use pragma Pure if possible, and if not possible, > use pragma Preelaborate, and if not possible use pragma > Elaborate_Body. So you say, most packages should have one of these pragmas. I agree. But the code I have seen so far does NOT contain them. I think that's real life. Do you agree? > > The lack of these pragmas is a portability issue. > > Of course the static elaboration model of GNAT eliminates this > portability issue, especially if you follow the ELaborate_All > guidelines suggested by -gnatwl. > > > And isn't it true that if > > a package body cannnot be elaborated immediately after the > spec we have > > generally a doubtful design? > > No, it is common to have package bodies that are mutually > recursive, and there is nothing whatsoever doubtful about > such a design. At least in this case, the author of the mutually dependent packages knows about the fact and is clearly responsible to resolve the elaboration issue. > > Now my major question: Why didn't the language designers > choose an approach > > that would make the standard case easy and provide a pragma > > defer_elaboration_of_body for those rare cases, where the user > doesn't want > > the body elaborated immediately after the spec? > > Because they are not so rare > > > Is there more reason that > > just compatibility with the user unfriendly definition of > > Ada83? > > I see nothing especially unfriendly here, and it is not at > all obvious what the right solution is here. Programs that > use elaboration sparingly usually have little trouble. They have little trouble until somebody tries to initialize a variable by a function call, for example. Then he discovers that a whole system of packages is incomplete with respect to elaboration pragmas. It is then not sufficient to do a local change. It affects code that was considered ok until then. > THe supposedly user friendly suggestion you give of the defer > pragma would be a huge pain in the neck and result in piles > of pragmas for programs that do not need pragmas now. Didn't you say above that 'following standard coding guidelines' every package should contain one of the Pure, Preelaborate or Elaborate_Body pragmas if possible. From that I conclude that the number of pragmas would not be increased. > > Remember you only need elaborate pragmas if you actually call > routines during elaboration. Your pragma would need to be used > all over the place even in a program that HAD no elaboratoin > code at all. > > To see an alternative approach, read the chapter on elaboration > in the GNAT RM. Can this be viewed online? I am one of those few people who haven't (yet) installed GNAT. > > Sent via Deja.com http://www.deja.com/ > Before you buy.