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.15.228 with SMTP id a4mr1912713pbd.4.1316701706624; Thu, 22 Sep 2011 07:28:26 -0700 (PDT) Path: lh7ni2594pbb.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: Thu, 22 Sep 2011 10:28:21 -0400 Organization: The World Public Access UNIX, Brookline, MA Message-ID: References: <8ad3b626-8608-4561-8d8f-bf11e7e8efc0@en1g2000vbb.googlegroups.com> NNTP-Posting-Host: shell01.theworld.com Mime-Version: 1.0 X-Trace: pcls6.std.com 1316701705 16901 192.74.137.71 (22 Sep 2011 14:28:25 GMT) X-Complaints-To: abuse@TheWorld.com NNTP-Posting-Date: Thu, 22 Sep 2011 14:28:25 +0000 (UTC) User-Agent: Gnus/5.1008 (Gnus v5.10.8) Emacs/21.3 (irix) Cancel-Lock: sha1:oYqj5q2A8k6WvBc7fRoGx4n0SPc= Xref: news1.google.com comp.lang.ada:18094 Content-Type: text/plain; charset=us-ascii Date: 2011-09-22T10:28:21-04:00 List-Id: "Randy Brukardt" writes: > "Adam Beneschan" wrote in message > news:8ad3b626-8608-4561-8d8f-bf11e7e8efc0@en1g2000vbb.googlegroups.com... >>On Sep 20, 8:15 am, Robert A Duff wrote: > ... >>> However, I think the reasoning is bogus in the first place, >>> although I didn't realize it at the time. > > [Lots of discussion of a source-based compiler model.] > >>> In a truly source-based program library, these problems just don't >>> exist. > > Sure, but most Ada compilers aren't source-based! Assuming that is > essentially the same as saying Ada = GNAT, and not even AdaCore really wants > that situation. OK, but clearly a non-source-based compiler can do the right thing, too. [1] >>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. > > This was NOT an implementation issue in Ada 83 -- the ACVC *required* the > unit be be ignored. Then I claim the ACVC was broken. Maybe the RM was broken, too (it was surely unclear at best), but my claim is that the fix we added in Ada 95 was not necessary. The attitude in the early days of Ada 83 was too rigid, as if the RM had been handed down from Mount Sanai. Nowadays, we're much more willing to say "the RM requires something idiotic (or is unclear about it); therefore that's not what it means". >...Janus/Ada had given an error message in this case, and I > had to spend a week or so figuring out how to change our binder so that it > could silently (other than a warning) drop the offending unit. OK, that's proof of my statement [1] above. You did it right. You should have disputed the test, because it's truly idiotic to silently ignore things like that. (And I claim that the Ada 83 RM didn't really require the bad behavior -- I rewrote chapter 10 mainly to CLARIFY that fact, not to change it.) On the other hand, warnings are just as good as errors, IMHO, especially if you have a "treat warnings as errors" switch, as GNAT does. > And having done so, I was repeatedly bitten by programs that didn't work > because some body was no longer elaborating the initialization (especially > the Janus/Ada compiler). We eventually abandoned doing almost anything at > elaboration time; besides this problem, we also were having a lot of trouble > keeping things happening in the "right" order. Unfortunately, elaboration, > at least as defined in Ada 83, seemed a lot more useful than it really was. Elaboration is rather broken in Ada. The rules should be checked statically (compile/link time). And the allowance for different compilers to choose different orders of elaboration is just Wrong. AdaCore customers have no end of trouble with that, when porting code. > The Ada 95 rule would have prevented most of that trouble. Yes, it's sufficient, but not 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. > > Yup. And having the rule gave us a good reason to get rid of the ACVC test > that was causing all of the pain in the first place. I'm not sure the > relaxation of the rules would have allowed that - it would have allowed > automatic recompilation, but I'm not sure it would have allowed an error in > that case (and it *should* be an error if it is not automatically > recompiled, IMHO). Agreed. - Bob