Bryan@SIERRA.STANFORD.EDU.UUCP (03/08/87)
Dear Ada Fans (if you're not a fan of Ada, I don't care that you read this),
I'm confused again... is there a difference between "obsolete" compilation
units and units "removed" ("deleted" for you VMS fans) from the library?
Consider:
package P is end P;
with P;
procedure Q is begin null; end;
package P is end P;
with P;
procedure Q is begin null; end;
The second compilation of P makes Q obsolete. It also makes the implicit
specification of Q (which is in the library) obsolete. Does this mean
that the second compilation of the body of Q is invalid since it is
a secondary unit of an obsolete spec?
This is related to a question I sent out a while ago, but never received
any replies to. Are there only two library states associated with a unit,
1. not in the library; never successfully compiled.
2. in the library; ready to elaborate
??
Or are there three library states assocaited with a unit?
1 - 2 as above
3. obsolete; not ready to elaborate, but was successfully
compiled once
doug
-------GOODENOUGH@A.ISI.EDU (John B. Goodenough) (03/12/87)
Doug Bryan asked a question using the following example: package P is end P; with P; procedure Q is begin null; end; package P is end P; with P; procedure Q is begin null; end; He asserted that "the second compilation of P ... makes the implicit specification of Q (which is in the library) obsolete." He then went on to ask "Does this mean that the second compilation of the body of Q is invalid since it is a secondary unit of an obsolete spec?" The problem with this question is that it's based on an invalid assumption, namely, that there is an implicit specification for procedure Q that is the library unit. I can well understand why Doug may have this interpretation, since it was my understanding of the RM at one time also, but when the Language Maintenance Panel/Committee considered this issue (in AI-00199), it concluded that there is no implicit specification for procedure Q that serves as a library unit; instead, procedure Q's body is itself the library unit. Specifically, AI-00199 says: A subprogram body given in a compilation unit (following the context clause) is interpreted as a secondary unit if the program library already contains a subprogram declaration or generic subprogram declaration with the same identifier; it is otherwise interpreted as a library unit. Now the consequences of this approved interpretation are that when P is recompiled, library unit Q is made obsolete, so the second compilation of procedure Q must be accepted; it is not a secondary unit of an obsolete (implicit) specification. "Obsolete" and "not in the library" are semantically equivalent, although a given implementation may treat these states differently. (In particular, an implementation might "recompile" very quickly units that are obsolete, but physically "in the library".) -------
amn@hutcs.UUCP.UUCP (03/14/87)
According to LRM 10.1:6 a subprogram body is treated as a secondary unit if the program library already contains a library unit (= a sub- program declaration) that is a subprogram with the same name. This means that to recompile a library subprogram the declaration or context clauses of which have been changed one has to compile a genuine subprogram specification without the corresponding body as a separate compilation unit. LRM 10.3:5 states that obsolete compilation units must be recompiled unless they are no longer needed. I think this means you cannot recompile a subprogram body if its specification is obsolete, as the recompilation needs the specification. I am not sure whether there is any need for having obsolete compilation units in the library. I think that 10.3:5 means that obsolete compilation units cannot be utilized. The only reason to have obsolete compilation units in a program library could be that the compilation library tools can decide which compilation units need to be recompiled after an 'obsoleting' compilation. Ari Mujunen Helsinki University of Technology (mcvax!penet!hut!amn, I suppose)