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-7-bit Received: by 10.68.1.39 with SMTP id 7mr2480222pbj.11.1316531732374; Tue, 20 Sep 2011 08:15:32 -0700 (PDT) Path: lh7ni1190pbb.0!nntp.google.com!news1.google.com!news2.google.com!newsfeed2.dallas1.level3.net!news.level3.com!bloom-beacon.mit.edu!newsswitch.lcs.mit.edu!nntp.TheWorld.com!not-for-mail From: Robert A Duff Newsgroups: comp.lang.ada Subject: Re: Optional body for nested generic Date: Tue, 20 Sep 2011 11:15:31 -0400 Organization: The World Public Access UNIX, Brookline, MA Message-ID: References: NNTP-Posting-Host: shell01.theworld.com Mime-Version: 1.0 X-Trace: pcls6.std.com 1316531731 11205 192.74.137.71 (20 Sep 2011 15:15:31 GMT) X-Complaints-To: abuse@TheWorld.com NNTP-Posting-Date: Tue, 20 Sep 2011 15:15:31 +0000 (UTC) User-Agent: Gnus/5.1008 (Gnus v5.10.8) Emacs/21.3 (irix) Cancel-Lock: sha1:QGmEykUZcKg52kbG3tYc/P/Xsj0= Xref: news1.google.com comp.lang.ada:18049 Content-Type: text/plain; charset=us-ascii Date: 2011-09-20T11:15:31-04:00 List-Id: Simon Wright writes: > I was surprised to find that GNAT makes it optional to have a body for a > nested generic package (in the code below, gpack1 has an empty body, > gpack2 doesn't have a body at all). > > package Pack is > pragma Elaborate_Body; > generic > package Gpack1 is > procedure Proc; > pragma Import (C, Proc, "proc"); > end Gpack1; > generic > package Gpack2 is > procedure Proc; > pragma Import (C, Proc, "proc"); > end Gpack2; > end Pack; > > package body Pack is > package body Gpack1 is > end Gpack1; > end Pack; > > I suppose that the reasoning for disallowing unrequired bodies (roughly, > making it impossible to obsolete the ada library by adding/removing > something with no other impact) only applies at library level, where > there's a correspondence to a file? Yes, the reasoning only applies at library level. That 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. The 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". Note that very early versions of GNAT had this same "bug", thus proving that this is an implementation issue, not a language issue. (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. - Bob