Re: Crosspost: Help wanted from comp.compilers

["Robert I. Eachus" <rieachus@attbi.com>]

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 (<b>in an implementation-defined 
manner</b>) 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.