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.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: 103376,2bcab3f121e1e3a7 X-Google-NewGroupId: yes X-Google-Attributes: gida07f3367d7,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII Received: by 10.68.28.231 with SMTP id e7mr721315pbh.5.1316617640697; Wed, 21 Sep 2011 08:07:20 -0700 (PDT) Path: lh7ni1898pbb.0!nntp.google.com!news1.google.com!postnews.google.com!en1g2000vbb.googlegroups.com!not-for-mail From: Adam Beneschan Newsgroups: comp.lang.ada Subject: Re: Optional body for nested generic Date: Wed, 21 Sep 2011 08:01:30 -0700 (PDT) Organization: http://groups.google.com Message-ID: <8ad3b626-8608-4561-8d8f-bf11e7e8efc0@en1g2000vbb.googlegroups.com> References: NNTP-Posting-Host: 66.126.103.122 Mime-Version: 1.0 X-Trace: posting.google.com 1316617640 26988 127.0.0.1 (21 Sep 2011 15:07:20 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Wed, 21 Sep 2011 15:07:20 +0000 (UTC) Complaints-To: groups-abuse@google.com Injection-Info: en1g2000vbb.googlegroups.com; posting-host=66.126.103.122; posting-account=duW0ogkAAABjRdnxgLGXDfna0Gc6XqmQ User-Agent: G2/1.0 X-Google-Web-Client: true X-Google-Header-Order: ARLUEHNKC X-HTTP-UserAgent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.0; WOW64; Trident/4.0; SLCC1; .NET CLR 2.0.50727; Media Center PC 5.0; .NET CLR 3.5.21022; .NET CLR 3.5.30729; .NET CLR 3.0.30618; .NET4.0C),gzip(gfe) Xref: news1.google.com comp.lang.ada:18069 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Date: 2011-09-21T08:01:30-07:00 List-Id: On Sep 20, 8:15=A0am, Robert A Duff wrote: > > Yes, the reasoning only applies at library level. =A0That was the > thinking during the Ada 9X project. > > However, I think the reasoning is bogus in the first place, > although I didn't realize it at the time. > > Suppose there were no Elab_Body above. > If a file pack.adb (using the GNAT convention) exists, > then it should be compiled and linked in as part of the program. > > If you delete pack.adb, then it should vanish. =A0The problem was > that Ada 83 compilers didn't do that -- they would link in the > obsolete object code for Pack body. > > Likewise, if you created a new pack.adb, they wouldn't notice unless > you explicitly "compiled it into the program library". =A0Note that very > early versions of GNAT had this same "bug", thus proving that this > is an implementation issue, not a language issue. =A0(Those early > versions defined pack.adb to NOT exist in the program library unless > pack.ads required it for some reason, completely defeating the purpose.) > Long since fixed! > > In a truly source-based program library, these problems just don't > exist. I think there was a problem in Ada 83, because it had more (apparently) concrete concepts of the program library, compilations, recompilations, program units becoming obsolete and being removed from the library. The Ada 95 Rationale pointed out a real problem: if a library package specification that does not require a body has a body, then when the specification is recompiled, the body, according to the language rules, becomes obsolete and is removed from the library. If you forget to submit the body for recompilation, this changes the meaning of the program if the body contains an initialization part or declares any tasks. So in that context, I think the new rule (that a library package body cannot be present unless it's required) was needed. However, Ada 95 also removed a lot of the concepts that had been IMHO overspecified in Ada 83 (AARM 10.1(4.c): "The interactions between language issues and environmental issues are left open in Ada 95.... In Ada 83, the concept of the program library, for example, appeared to be quite concrete, although the rules had no force..."). Now, I think the basic rule about recompilations and obsolete units and such is just that the implementation has to get it right. (E.g. if a library spec is recompiled, and it has been changed in a way that makes the body illegal, the body can't become part of the final program, and a partition can't be created if the body is required; the notion of an "obsolete" unit isn't necessary at all.) Because of this change, the other new rule (that disallowed a body unless required) probably wasn't necessary. Still, I'm not unhappy with the rule, since it can prevent accidents. Suppose, for example, that a specification of P declares some procedures, and the body contains the code for those procedures. Then the user decides he wants the procedures moved somewhere else, so he eliminates them so that P now declares only types. It's too easy to make a mistake that causes P's body to be included in the final executable anyway. I think it's beneficial to force the programmer to take some action (in this case, adding a pragma) if P's body is still supposed to be included. -- Adam