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-Language: ENGLISH,CP1252 X-Google-Thread: 103376,d6f7b92fd11ab291 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2003-07-21 13:12:10 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!headwall.stanford.edu!newshub.sdsu.edu!elnk-nf2-pas!newsfeed.earthlink.net!wn14feed!wn13feed!wn12feed!worldnet.att.net!204.127.198.203!attbi_feed3!attbi_feed4!attbi.com!sccrnsc03.POSTED!not-for-mail Message-ID: <3F1C48F6.8010700@attbi.com> From: "Robert I. Eachus" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: Crosspost: Help wanted from comp.compilers References: <3F158832.1040206@attbi.com> <1058378673.35463@master.nyc.kbcfp.com> <1058390613.119827@master.nyc.kbcfp.com> <2OERa.4718$0F4.3216@nwrdny02.gnilink.net> <1058539398.178565@master.nyc.kbcfp.com> <3F18D647.9020505@attbi.com> <3F1B207B.6090308@attbi.com> <1058800464.63505@master.nyc.kbcfp.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit NNTP-Posting-Host: 66.31.71.243 X-Complaints-To: abuse@comcast.net X-Trace: sccrnsc03 1058818314 66.31.71.243 (Mon, 21 Jul 2003 20:11:54 GMT) NNTP-Posting-Date: Mon, 21 Jul 2003 20:11:54 GMT Organization: Comcast Online Date: Mon, 21 Jul 2003 20:11:54 GMT Xref: archiver1.google.com comp.lang.ada:40582 Date: 2003-07-21T20:11:54+00:00 List-Id: Hyman Rosen wrote: > Not at all. That section just says that when something is compiled, > it needs to see a consistent set of the things it depends on. What > you are talking about is found in 10.1.4(7), as an implementation > *permission*. That section says that when something is compiled, an > implementation may remove its dependents from the environment. But > that is a permission, not a requirement, and is clearly suboptimal > with respect to avoiding recompilations. This I can happily answer. It is in 10.1.4(7). Let me quote it again, with some comments to explain: "When a compilation unit is compiled, all compilation units upon which it depends semantically shall already exist in the environment;" Notice two things here. All the units on which a unit being compiled depends must already be in the environment, and the semicolon at the end. IMHO the semicolon grates, but in the standard, it indicates that this rule isn't finished yet. "...the set of these compilation units shall be _consistent_ in the sense that the new compilation unit shall not semantically depend (directly or indirectly) on two different versions of the same compilation unit, nor on an earlier version of itself." The fact that consistant is italized indicates that this is a formal definition of a technical term. So a unit is only consistant with one version (there may be several in the environment) of any unit it semantically depends on, and that version must have been in the environment when the dependent unit was compiled. Finally we get to 10.2(27): "The implementation shall ensure that all compilation units included in a partition are consistent with one another, and are legal according to the rules of the language." There is that consistant again, but now it is used rather than defined. The result, when you put it all together, is that when you compile something into the environment, the environment _chooses_ a consistant set of units that the unit that you are compiling depends on. When you later execute the program, the environment for your main program or partition contains a _consistant_ set of units. As we saw above, it is only possible for a unit (call it A) to be consistant with a particular version of another unit (B) it depends on, if that version of B was in the environment when A was compiled. Whew! Now if you look at 10.2(7): "The user can optionally designate (in an implementation-defined manner) one subprogram as the main subprogram for the partition. A main subprogram, if specified, shall be a subprogram." If your main program is A from above, and you recompile B, the implementation has two choices. It can leave the original compiled version of B in the environment and link A and the old B, or it can tell you to recompile A. There are systems that do either! But it is considered highly unfriendly for the normal mode of linking to give you the old versions of A and B. For example, in a version control system, I may have a "playpen" where I can modify units that are checked in and link with them, without checking the units out. In most compilers, the playpen will be a separate directory. If you link in that directory you will get the new B--after A is recompiled. If you link in the version controlled directory, without checking the new B in, you will get the old B and the old A. So this is what is confusing you. The definition of environments is intentionally broad enough to encompass such version control systems. But combination of the paragraphs above insure that even if there are inconsistant and mutually illegal, or even totally illegal units in the environment, at the point where the program (or partition) is executed, you have a mutually consistant and legal set of units. In short, you can defer some recompilations but never beyond link time. > Many of the discussions we have here revolve around different > interpertations of the same facts, so that it's seldom clear that > someone has made a mistake. Ah, a lesson about Ada and interpretations. You may see references to AIs. These are officially Ada Issues which are being studied by or which have been studied by the ARG, the Ada Rapporteur Group, which is a part of ISO/IEC JTC1/SC22/WG9. Some Ada Issues result in "binding interpretations" which result in changes to the Ada Reference Manual. The on-line version of the RM at http://www.ada-auth.org/, as explained there has all of the interpretations from the TC folded in. So that is a good place to go to check anything you might want to know. You can also find all of the Ada Issues there. Of course, no member of the ARG is perfect. I certainly am not. But when we speak "ex cathedra" of our interpretations of what the Reference Manual says, we are literally right even when we are wrong. (There was even one AI classified as a binding interpretation for Ada 83 which reversed an earlier AI. We try to avoid that. ;-) So interpretation is a very loaded word to use in a discussion of the Ada language. > I apologize for implying that all Ada > implementations had "horrible" recompilation issues, but I think that > it's unquestionable that at least some did, and in such a way that > "days-long" recompilations became a very public and visible issue for > Ada. As I said, there were some "horrible" recompilation issues, but in every case the horrible issues were resolved by education, mostly in software engineering. There were some actual recompilation issues with early Ada compilers, but most of those were in the nature of bugs typical of compilers at that stage of development. The conclusion that there were NO language-related recompilation problems was definitely non-obvious. But it was reached by the Ada 9X requirements team, and by the time that Ada 95 was approved, that conclusion was widely shared. Incidently, a lot of that had to do with the issue of creating dependences on generic bodies by units that instantiated the generic. Originally DEC Ada took aggressive advantage of that permission by default, to generate more optimal code, but with more recompilations required. Well before the Ada 9X process began, all of the Ada compilers that took advantage of that permission had been changed due to user pressure to make it not the default behavior. Then what had been a non-binding interpretation (don't do that) became a binding interpretation (the Ada Reference Manual changed). It is perfectly reasonable to have a compiler setting that does inter-library unit optimizations at the expense of potential additional recompilations. But most programmers don't want to use such a setting during development. (GNAT doesn't even have one. You can get the effect by creating a few big compilation units--potentially one--but then it is very clear what you are asking for.) So you can see why I say this was an education issue. It is like learning that you should use gnatmake -gnato if you want all the standard constraint checks. Definitely not a language issue, but you do need to read the (GNAT) documentation. -- Robert I. Eachus �In an ally, considerations of house, clan, planet, race are insignificant beside two prime questions, which are: 1. Can he shoot? 2. Will he aim at your enemy?� -- from the Laiden novels by Sharon Lee and Steve Miller.