CVS difference for ais/ai-50217.txt

Differences between 1.2 and version 1.3
Log of other versions for file ais/ai-50217.txt

--- ais/ai-50217.txt	2003/05/24 00:51:43	1.2
+++ ais/ai-50217.txt	2003/06/17 21:41:12	1.3
@@ -1,4 +1,4 @@
-!standard 10.01.02   (03)                           03-02-04  AI95-00217-06/01
+!standard 10.01.02   (03)                           03-04-03  AI95-00217-06/02
 !standard 10.01.02   (04)
 !standard 10.01.02   (08)
 !standard J.10       (00)
@@ -63,22 +63,94 @@
 
 !wording
 
-10.1.2(4) says:
+Add after 8.3(20):
 
-    with_clause ::= with library_unit_name {, library_unit_name};
+The full view of a library package is hidden from all visibility within the
+scope of a limited_with_clause that mentions it. The limited view of a library
+package is hidden from all visibility within the declarative region of the
+package, and within the scope of a nonlimited_with_clause that mentions this
+package or a renaming thereof.
 
-Change to:
 
+Replace 8.4(5) by:
+
+A package_name of a use_package_clause shall denote a non-limited view of a
+package.
+
+
+Replace 8.5.3(3) by:
+
+The renamed entity shall be a non-limited view of a package.
+
+
+Replace 10.1.2(4) by:
+
   with_clause ::= limited_with_clause | unlimited_with_clause
   limited_with_clause ::= limited with library_unit_name {, library_unit_name};
   unlimited_with_clause ::=       with library_unit_name {, library_unit_name};
+
+Add after 10.1.2(5):
 
-Add a legality rule:
+A with_clause is *more nested than* a context_item if they are both part of the
+same context_clause, or if the scope of the with_clause is entirely included in
+the scope of the context_item.
+
+Replace 10.1.2(6) by:
+
+A library_item is *explicitly mentioned* in a with_clause if it is denoted by a
+library_unit_name in the with_clause. A library_item is mentioned in a
+nonlimited_with_clause if it is explicitly mentioned or if it is denoted by a
+prefix in the with_clause. A library_item is mentioned in a limited_with_clause
+if it is explicitly mentioned or if it is denoted by a prefix in the
+with_clause, and that with_clause is not more nested than a
+nonlimited_with_clause that mentions the same library_item. A name mentioned in
+a limited_with_clause denotes the limited view of the corresponding library
+package.
 
+Add after 10.1.2(8):
+
 A library_item mentioned in a limited_with_clause shall be a
 package_declaration[, not a subprogram_declaration, generic_declaration,
 or generic_instantiation].
 
+A limited_with_clause which explicitly mentions a library_item shall not be
+more nested than a nonlimited_with_clause or use_clause which mentions the same
+library_item or a renaming thereof.
+
+Add after 10.1.4(3):
+
+In addition, for each library_package_declaration in the environment, there is
+a conceptual declaration of a *limited view* of that library package. The
+limited view of a package contains:
+
+ - A declaration of the limited view of each nested package_declaration.
+
+ - For each type_declaration in the visible part, an incomplete_type_declaration
+   with the same name, whose completion is the type_declaration. If the
+   type_declaration is tagged, then the incomplete_type_declaration is tagged
+   incomplete.
+
+The limited view of a package has the same identifier as the
+package_declaration.
+
+There is no syntax for declaring limited package views, because they are always
+implicit.  Nonetheless, the declaration of a limited package view is considered
+to be a library_item.
+
+A library_package_declaration is considered to be the completion of its limited
+view declaration.
+
+
+Insert somewhere in 10.1.1(26):
+
+A limited library package view declaration depends semantically upon the parent
+limited package view declaration.  A library package declaration depends
+semantically upon its limited view.  [Author's Note: Not sure what is the
+purpose of the first rule.]
+
+
+!discussion
+
 Discussion of existing wording:
 
 It is natural to think of a with_clause as causing a library unit to
@@ -117,184 +189,111 @@
 view of X that only includes nested packages and incomplete types.  I
 think I'll try the latter idea, even though I hate to introduce yet more
 magical implicit junk.
+
+Discussion of new wording:
+
+We need to define the nesting of with_clauses relative to each other and to
+use_clauses to phrase a number of rules that describe the interaction between
+use_clauses and nonlimited_ and limited_with_clauses appearing on different
+units. Note that a with_clause is more nested than itself (not that it matters
+much, but it make some of the wording simpler).
+
+For nonlimited_with_clauses, the new 10.1.2(26) doesn't change the current RM.
+For limited_with_clause, it says that if for instance the specification of Q
+has a "with P" and the body of Q has a "limited with P.R.S" then P is not
+mentioned in the limited_with_clause. So the limited_with_clause has no effect
+for P; in particular it doesn't revert to the limited view of P. On the other
+hand, it makes the limited views of P.R and P.R.S visible. This is mostly a
+methodological restriction, as we have (pathological) cases where the limited
+view hides the full view. However, we want to make such cases infrequent to
+avoid confusing users.
+
+The changes to 10.1.2(8) ensure that, if for instance the specification of Q
+has a "with P.R", it shall not have a "limited with P" or a "limited P.R". The
+same applies to the body of Q, its subunits, etc. On the other hand, a "limited
+with P.R.S" is fine. Again this is to avoid reverting to the limited view as
+much as possible.
+
+The fact that a "limited with P" hides the full view of P from all visibility
+prevents ripple effects. If you are is the scope of a "limited with P", the
+full view of P is hidden from all visibility, even if P would otherwise be
+visible indirectly (e.g. by a renaming in an auxiliary package). So the
+limited_with_clause effectively reverts to the limited view of P, and the types
+it declares are incomplete, and therefore subject to the limitations described
+in 3.10.1. From an implementation standpoint, it means that compilers can
+decide early (i.e., after looking at the context_clauses of a unit and of its
+ancestry) what view of P needs to be made available for name resolution
+purposes. It is still the case that the compiler may need to look at the full
+view of P, e.g. if some unit in the closure was compiled against the full view
+of P.
+
+Note that package instantiations and package renamings are not part of the
+limited view of a package, because we want to be able to build the limited view
+using very simple syntactic analysis (we are lucky that it's possible to
+identify tagged types simply by looking at the syntax). But for package
+renamings and instantiations, the name of the renamed package or of the generic
+would need to be resolved, and that would required full-fledged visibility
+analysis.
+
+A limited view of a package cannot be mentioned in a use clause to avoid a
+funky kind of Beaujolais effect where changing a with_clause causes the meaning
+of an identifier to switch from one interpretation to another:
+
+    package A is
+        X : Integer := 7;
+    end A;
+
+    package B is
+        X : Integer := 203;
+    end B;
+
+    with A; -- change this to "with B;" and see what happens
+    package P is end;
+
+    limited with A, B;
+    use A, B; -- Shouldn't be allowed
+    package P.C is
+        Y : Integer := X; -- which X is this?
+    end P.C;
+
+[This is an example that Tucker sent a while back. But is there a problem now
+that the limited_with_clause above is illegal?]
+
+Also, a limited view of a package cannot be mentioned in a package renaming
+declaration. This restriction is probably not as critical as the others. The
+problem comes when someone from outside the unit containing the limited with
+references this package renaming. What does it see? If it has a "regular" with
+for the target of the limited-with, does it see the "full" view of the package
+via the renaming, or only the limited view of it. These are question that are
+best left unanswered.
+
+We do not allow a limited_with_clause to mention a procedure, because that
+would allow calling a procedure before its spec is elaborated.  The language
+has no mechanism to deal with that.  Similarly, we do not allow a
+limited_with_clause to mention a generic, because that would allow
+instantiating a generic before its spec is elaborated.
 
-Here goes:
+We do not allow a limited_with_clause to mention a generic instantiation,
+because that would require all kinds of semantic analysis stuff, such as
+visibility.
 
-10.1.4(1-3) says:
 
-1     Each compilation unit submitted to the compiler is compiled in the
-context of an environment declarative_part (or simply, an environment), which
-is a conceptual declarative_part that forms the outermost declarative region
-of the context of any compilation. At run time, an environment forms the
-declarative_part of the body of the environment task of a partition (see
-10.2, ``Program Execution'').
-
-2     The declarative_items of the environment are library_items appearing in
-an order such that there are no forward semantic dependences. Each included
-subunit occurs in place of the corresponding stub. The visibility rules apply
-as if the environment were the outermost declarative region, except that with_-
-clauses are needed to make declarations of library units visible (see 10.1.2).
-
-3     The mechanisms for creating an environment and for adding and replacing
-compilation units within an environment are implementation defined.
-
-Add some text somewhere in there:
-
-    In addition, for each library_package_declaration in the
-    environment, there is a conceptual declaration of a "limited view"
-    of that library package.  [Note: This animal is sort of what folks
-    have been calling a "package abstract", except that it is
-    automatically generated (or imagined) by the compiler.]
-
-    The limited view of a package contains:
-
-        - A declaration of the limited view of each nested package.
-
-        - For each type_declaration in the visible part, an
-          incomplete_type_declaration with the same name,
-          whose completion is the type_declaration.
-          If the type_declaration is tagged, then the
-          incomplete_type_declaration is tagged incomplete.
-
-    The limited view of a package has the same identifier as the
-    package_declaration.
-
-    There is no syntax for declaring limited package views, because they
-    are always implicit.  Nonetheless, the declaration of a limited
-    package view is considered to be a library_item.
-
-    A name mentioned in a limited_with_clause denotes the limited view
-    declaration.  I guess we need to make sure the definition of
-    "mentioned" is appropriate: for a limited_with_clause, we are
-    "mentioning" the limited view.
-
-    A library_package_declaration is considered to be the completion of
-    its limited view declaration.
-
-10.1(26) says:
-
-26    A library_item depends semantically upon its parent declaration. A
-subunit depends semantically upon its parent body. A library_unit_body depends
-semantically upon the corresponding library_unit_declaration, if any. A
-compilation unit depends semantically upon each library_item mentioned in a
-with_clause of the compilation unit. In addition, if a given compilation unit
-contains an attribute_reference of a type defined in another compilation unit,
-then the given compilation unit depends semantically upon the other
-compilation unit. The semantic dependence relationship is transitive.
-
-Add some new cases:
-
-    - A limited library package view declaration depends semantically
-      upon the parent limited package view declaration.
-
-    - A library package declaration depends semantically upon its
-      limited view.
-
-    - The part about with_clauses should work unchanged: for a
-      limited_with_clause, the dependence is upon the limited view; for
-      an unlimited_with_clause, the dependence is upon the package_decl.
-
-There are various places in Chapter 8 that refer to "the declaration of
-a library unit", presuming that there's only one.  We need to change the
-wording, since library packages now have two declarations: the limited
-view, plus the normal package_decl.  With minor wording changes, most of
-it should work OK, because:
+Open Issues:
+
+There are various places in Chapter 8 that refer to "the declaration of a
+library unit", presuming that there's only one.  We need to change the wording,
+since library packages now have two declarations: the limited view, plus the
+normal package_decl.  With minor wording changes, most of it should work OK,
+because:
 
     A library_package_decl is the completion of its limited view,
-    and therefore hides it.
+    and therefore hides it from all visibility.
 
     The incomplete types in the limited view are completed by the
     regular types.  This introduces the possibility of completing an
     incomplete type with a private type, but I think all the proposals
     are going to have a similar problem (if it's a problem).
 
-!discussion
-
-To review this proposal, one should search the RM for the following
-terms, to see if they still make sense:
-
-    - with_clause
-    - semantic dependence, depend[s] semantically
-
-Also study chaps 8 and 10.
-
-----
-
-Here's one possible implementation method: Whenever the compiler sees
-"limited with X", it reads the source file containing X, parses it, and
-collects a list of nested package and type names, and whether they're
-tagged.  It is important that this process can be done without doing any
-"serious" semantic analysis, and without looking at anything imported by
-X.  The compiler then constructs the limited view of X.
-
-Luckily, taggedness of types can be detected syntactically.
-
-At any place where a package_decl is visible, the compiler needs to be
-sure the limited view of it is hidden.
-
-The compiler can avoid reconstructing the limited view of X, if it
-likes, if it knows the source has not changed.
-
-For compilers that save program library information on disk, I presume
-the limited view would have to be saved on disk in a similar manner.
-In Rational terms, this means each source file has (up to) *two*
-compilation artifacts.
-
-I presume all compilers have some subroutine to check whether two types
-are the same type (in case of incomplete types and the like).  And/or a
-subroutine to determine which view of a type should be used.  These
-subroutines need to be changed to deal with this new flavor of
-incomplete type.  But I would expect that to be fairly localized; the
-calls to those subroutines should still work.
-
-----
-
-We do not allow a limited_with_clause to mention a procedure, because
-that would allow calling a procedure before its spec is elaborated.  The
-language has no mechanism to deal with that.  Similarly, we do not allow
-a limited_with_clause to mention a generic, because that would allow
-instantiating a generic before its spec is elaborated.
-
-We do not allow a limited_with_clause to mention a generic
-instantiation, because that would require all kinds of semantic analysis
-stuff, such as visibility.
-
-----
-
-A package could say "limited with A.B.C;" and then its child could say
-"with A.B.C;".  Now we're within the scope of the real things, so the
-limited views would be hidden.
-
-Similarly, if P says "limited with P.C", we're within the scope of the
-real P, so the limited view of it is hidden.  We have limited access to
-C.
-
-----
-
-Consider:
-
-package A is
-    type T is range 1..10;
-end A;
-
-with A; use A;
-package B is
-    X, Y: T;
-end B;
-
-limited with A;
-with B; use B;
-package C is
-    X := Y;
-end C;
-
-OK, assignment statements are syntactically illegal in a package spec.
-But think of some other thing that depends on the type.  Perhaps,
-"Flag: Boolean := X in 1..10;".
-
-Is this legal?  It would be odd if adding "limited with A;" reduced ones
-capabilities.
-
 !example
 
 !ACATS test
@@ -3231,6 +3230,1131 @@
 
 We will definitely try to prototype this in GNAT as soon as there is a
 reasonably well defined proposal.
+
+**************************************************************
+
+From: Tucker Taft
+Sent: Tuesday, February 11, 2003  2:21 PM
+
+Here is some initial analysis of implementation issues associated
+with "limited with."  I tried to make most of the analysis
+technology independent, but of course that is nearly impossible,
+so it may apply less or more to technologies other than AdaMagic.
+-Tuck
+
+-----------------
+Thoughts on the implementation of "limited with" in AdaMagic
+
+          $Revision: 1.3 $ $Date: 2003/06/17 21:41:12 $
+
+The "limited with" clause makes a "limited view"
+of a package visible in the compilation unit
+that has the limited-with clause, as well as all of its
+descendants.  However, the limited view is
+hidden from all visibility (as are all the incomplete
+types and nested package limited views within it) under
+certain circumstances.  After much discussion at
+the Padua ARG meeting, the best rule seemed
+to be that if the full view of the package is
+visible, including via one or more renamings,
+then the limited view is hidden from all visibility.
+[This was considerd necessary so as to avoid having two different
+views of the same package usable at the same point
+in the source text, which was felt to create both
+implementation complexity and possible user confusion.]
+
+SEPARATE "LIMITED" COMPILATION UNIT
+
+Our model for implementing a limited view of a library package
+will be that it has its "own" compilation-unit name,
+constructed from its "real" name but with suffix "'Limited".
+Hence P.Q.R'Limited is the limited view of P.Q.R.
+[Note that "P.Q.R.Limited" could also be used as the
+name, since "limited" is a reserved word, and would
+never be the real name of a package.  However, it is
+very important that in any case P.Q.R.Limited or
+P.Q.R'Limited not depend semantically on P.Q.R itself.]
+
+In the representation of the library, it is important
+that P.Q.R'Limited can exist before P.Q.R has been
+fully compiled, and can retain some continuing existence
+while P.Q.R is being fully compiled, and thereafter.
+It is also important to realize that the packages
+nested within P.Q.R'Limited are themselves limited
+views.  Hence, P.Q.R'Limited.NP always denotes a limited view
+of a package, if P.Q.R.NP denotes a nested package spec.  Similarly,
+P.Q.R'Limited.T denotes an incomplete type declaration for T,
+if P.Q.R.T denotes a full type declaration.
+
+SEPARATE TIMESTAMP FOR LIMITED VIEW
+
+P.Q.R'Limited has its own timestamp, for the purposes
+of out-of-dateness checking.  It is important that this
+*not* change when a "full" compile of P.Q.R is started,
+because that would make the units that P.Q.R depends
+on that themselves depend on P.Q.R'Limited, automatically
+appear out of date.
+
+Once the full compile of P.Q.R is complete, a check for
+consistency between P.Q.R'Limited and P.Q.R should be
+performed.  If the views are no longer consistent, due to
+some change in P.Q.R, a new version of P.Q.R'Limited should
+be constructed, and its timestamp changed.  This will effectively
+put all the dependents of P.Q.R'Limited out of date,
+and may in fact put P.Q.R itself out of date.  If so,
+then P.Q.R will have to be compiled again.  Ideally, this
+will be performed immediately, since the source code for
+P.Q.R is readily available at that time.  However, depending on the
+compilation mechanism, it may be first necessary to compile
+other dependents of P.Q.R'Limited, so they are back in
+an up-to-date state before re-attempting the full
+compilation of P.Q.R.  This might be left until link time,
+or to a separate "make" tool.
+
+Of course if P.Q.R'Limited is initially created by simply parsing
+the source text for P.Q.R, the timestamp of P.Q.R'Limited would be
+set at parse time.
+
+For those compilation systems that retain the date of modification
+of the source file as the time stamp of the corresponding units
+in the program library, some of this becomes simpler.
+Nevertheless, it seems a helpful, and in some cases
+necessary, "optimization" to *not* change the timestamp of
+the limited view every time the source text timestamp changes.
+Because the check for consistency between a full view and
+a limited view should be relatively easy to perform, there
+seems no need to change the timestamp on the limited view
+so long as it remains consistent with the full view, even
+if the full view corresponds to source text with a different
+timestamp.  This means that units that depend only on the
+P.Q.R'Limited are isolated from "minor" changes to P.Q.R,
+and are only affected when a type or nested package is
+added or removed from P.Q.R.   In other words, you get
+a "poor man's" version of incremental compilation as a side
+effect of implementing limited views of packages.
+
+HIDING THE LIMITED VIEW
+
+As mentioned above, a limited view of a package can be hidden from
+all visibility.  The anticipated rule is that the limited
+view is hidden from all visibility if the full view is visible
+either "normally" or via a rename.  This implies that if
+P.Q.R is visible, including via a rename, then P.Q.R'Limited
+is not visible.  Furthermore, even when P.Q.R'Limited
+is visible, it is possible that P.Q.R'Limited.NP might
+not be visible, because P.Q.R.NP might be visible via
+a renaming.
+
+A relatively simple implementation of this requirement
+would seem to be to build up a set representing those (external) packages
+that have a full view visible, including via a rename, within the
+current compilation unit.  (By "external" we mean it is from some
+other compilation unit.)  This set will not grow once the
+context clause has been fully processed, since it is not
+possible to locally declare a renaming of a package that is not
+already visible.
+
+This set of visible packages would probably be represented
+using a hash table of some sort.  It would start out empty
+when starting to compile a new compilation unit, and would
+grow each time a (real, not limited) "with" for a package or a package
+renaming is processed.  Each of these "with"ed packages
+would be scanned for enclosed renamings, recursively.
+[Alternatively, the representation of every package could
+include a set of all enclosed renamings (directly or indirectly).]
+The "with"ed package, plus all of the packages for which it
+contains a renaming, would be unioned into this set.
+
+Later, whenever a limited view of a package is encountered
+within a name, a check is made to see whether a corresponding
+full view exists in this set.  If so, the limited view may
+not be named, and so the name is illegal.
+
+Another anticipated rule is that a limited with clause is
+illegal if the package is already visible, including
+via a rename.  This would seem to be friendlier than allowing
+the programmer to put a "limited with" on a compilation unit and
+then not be able to use it at all.  However, there will still
+be "limited with"s inherited from ancestor units, and these
+will be essentially ignored if the corresponding package
+is fully visible some other way.  Also, in a limited with
+clause like "limited with P.Q.R;" presumably implicit
+limited withs for P and P.Q are provided, but such an implicit
+limtied with again must be ignored if the package mentioned
+is already fully visible via some other means.
+
+To enforce the above rule regarding disallowing and/or ignoring
+limited withs, it may be necessary to do a second pass over
+the context clause, after the full set of visible packages has
+been built up.  In many cases, a second pass is already necessary
+in Ada 95 to correctly deal with "with"s of private units, since it is
+not known whether those with's are legal until the name of the
+compilation unit being compiled is known, so it may be possible
+to combine these error-checking passes.
+
+WHEN IS THE INCOMPLETE TYPE COMPLETE?
+
+Our current plan is to disallow "use" clauses and renamings
+for limited views.  Given that, the only way to name one
+of the incomplete types inside a limited view is by naming
+the enclosing package, so there is no need to have a separate mechanism
+for determining whether the incomplete type declaration is visible.
+It is visible exactly when the enclosing limited view can be named.
+
+However, there are access types that might have been declared
+using the incomplete type, and it is important to know when a
+dereference of the access type is considered "complete."
+The basic rule would be that when the full type is visible,
+including via a rename of the enclosing package, (or equivalently,
+when the incomplete type declaration is hidden from all visibility),
+the access type may be dereferenced to produce the full type.
+This implies that any time such an access type is dereferenced,
+a check should be made whether the designated type's enclosing limited
+view(s) are all still visible.  If they are all still visible,
+then the incomplete type is still visible, and the dereference
+produces an incomplete object.  If any one of them is hidden from
+all visibility, then the full type is visible, and the dereference
+produces an object of a "full" type.  Some optimization of this
+check is probably possible.
+
+Even when a dereference of the access type is considered
+incomplete, it may still be legal in a context where a full
+type would normally be required, so long as the expected type
+is the full type, or the full type is "nearby."  One of the
+versions of the type-stub proposal laid out the rules for
+this matching between incomplete and full type, and those
+rules seem still relevant for all of the other proposals as well.
+
+Here is a copy of those rules (from AI-00217-04/04):
+
+    A dereference (implicit or explicit) of a value of an access type whose
+    designated type D is incomplete is allowed only in the following
+    contexts:
+
+    * in a place where the completion of D is available (see above);
+
+    * in a context where the expected type is E and
+       o E covers the completion of D,
+       o E is tagged and covers D,
+       o E covers D'Class or its completion, or
+       o E'Class covers D or its completion;
+
+    * as the target of an assignment_statement where the type of the value
+      being assigned is V, and V or V'Class is the completion of D.
+
+    In these contexts, the incomplete type is defined to be the same
+    type as its completion, and its first subtype statically matches the
+    first subtype of its completion.
+
+The first bullet would be replaced by "where the full type declaration
+for D is visible" for the limited-with proposal (and for the
+"type C.T;" proposal).
+
+**************************************************************
+
+From: Robert A. Duff
+Sent: Tuesday, February 11, 2003  5:34 PM
+
+...
+> SEPARATE "LIMITED" COMPILATION UNIT
+>
+> Our model for implementing a limited view of a library package
+> will be that it has its "own" compilation-unit name,
+> constructed from its "real" name but with suffix "'Limited".
+
+I don't see why you want it to have a different name.  It seems to me
+that there are two declarations of views, both called P.Q.R, and the
+full view hides the limited view.
+
+> Hence P.Q.R'Limited is the limited view of P.Q.R.
+> [Note that "P.Q.R.Limited" could also be used as the
+> name, since "limited" is a reserved word, and would
+> never be the real name of a package.  However, it is
+> very important that in any case P.Q.R.Limited or
+> P.Q.R'Limited not depend semantically on P.Q.R itself.]
+
+Right -- the dependence is the other way 'round.
+
+> In the representation of the library, it is important
+> that P.Q.R'Limited can exist before P.Q.R has been
+> fully compiled, and can retain some continuing existence
+> while P.Q.R is being fully compiled, and thereafter.
+> It is also important to realize that the packages
+> nested within P.Q.R'Limited are themselves limited
+> views.
+
+And *they* don't get weird names...
+
+>...Hence, P.Q.R'Limited.NP always denotes a limited view
+> of a package, if P.Q.R.NP denotes a nested package spec.  Similarly,
+> P.Q.R'Limited.T denotes an incomplete type declaration for T,
+> if P.Q.R.T denotes a full type declaration.
+>
+> SEPARATE TIMESTAMP FOR LIMITED VIEW
+>
+> P.Q.R'Limited has its own timestamp, for the purposes
+> of out-of-dateness checking.  It is important that this
+> *not* change when a "full" compile of P.Q.R is started,
+> because that would make the units that P.Q.R depends
+> on that themselves depend on P.Q.R'Limited, automatically
+> appear out of date.
+
+Right.  It seems to me that in a source-based library model, the
+timestamp of the limited view can be the timestamp of the source file
+containing that package, whereas the timestamp of the full view is
+really a collection of timestamps for all the source files the package
+depends upon.
+
+> Once the full compile of P.Q.R is complete, a check for
+> consistency between P.Q.R'Limited and P.Q.R should be
+> performed.
+
+I don't understand the need for this consistency check.
+It seems to me that P.Q.R depends upon P.Q.R'Limited,
+and you do the normal check at link time, to make sure that
+two different versions of P.Q.R'Limited are not included in the same
+partition.
+
+In normal operation, you just do a "build" command, and the only way the
+link-time check can fail is if you edit your source code while the build
+is running.
+
+>...  If the views are no longer consistent, due to
+> some change in P.Q.R, a new version of P.Q.R'Limited should
+> be constructed, and its timestamp changed.  This will effectively
+> put all the dependents of P.Q.R'Limited out of date,
+> and may in fact put P.Q.R itself out of date.  If so,
+> then P.Q.R will have to be compiled again.  Ideally, this
+> will be performed immediately, since the source code for
+> P.Q.R is readily available at that time.  However, depending on the
+> compilation mechanism, it may be first necessary to compile
+> other dependents of P.Q.R'Limited, so they are back in
+> an up-to-date state before re-attempting the full
+> compilation of P.Q.R.  This might be left until link time,
+> or to a separate "make" tool.
+
+I don't see the need for such complexity in the "make" tool
+(recompiling things twice and whatnot).  It seems no different
+than the current language: if you edit package Foo in between compiling
+two different things that depend on Foo, then you get a link-time
+failure, and run the "make" tool again.
+
+> Of course if P.Q.R'Limited is initially created by simply parsing
+> the source text for P.Q.R, the timestamp of P.Q.R'Limited would be
+> set at parse time.
+>
+> For those compilation systems that retain the date of modification
+> of the source file as the time stamp of the corresponding units
+> in the program library, some of this becomes simpler.
+> Nevertheless, it seems a helpful, and in some cases
+> necessary, "optimization" to *not* change the timestamp of
+> the limited view every time the source text timestamp changes.
+> Because the check for consistency between a full view and
+> a limited view should be relatively easy to perform, there
+> seems no need to change the timestamp on the limited view
+> so long as it remains consistent with the full view, even
+> if the full view corresponds to source text with a different
+> timestamp.  This means that units that depend only on the
+> P.Q.R'Limited are isolated from "minor" changes to P.Q.R,
+> and are only affected when a type or nested package is
+> added or removed from P.Q.R.   In other words, you get
+> a "poor man's" version of incremental compilation as a side
+> effect of implementing limited views of packages.
+
+Seems like a nice optimization, but I don't see why it's necessary.
+
+> HIDING THE LIMITED VIEW
+>
+> As mentioned above, a limited view of a package can be hidden from
+> all visibility.  The anticipated rule is that the limited
+> view is hidden from all visibility if the full view is visible
+> either "normally" or via a rename.  This implies that if
+> P.Q.R is visible, including via a rename, then P.Q.R'Limited
+> is not visible.  Furthermore, even when P.Q.R'Limited
+> is visible, it is possible that P.Q.R'Limited.NP might
+> not be visible, because P.Q.R.NP might be visible via
+> a renaming.
+>
+> A relatively simple implementation of this requirement
+> would seem to be to build up a set representing those (external) packages
+> that have a full view visible, including via a rename, within the
+> current compilation unit.  (By "external" we mean it is from some
+> other compilation unit.)  This set will not grow once the
+> context clause has been fully processed, since it is not
+> possible to locally declare a renaming of a package that is not
+> already visible.
+
+Well, sort of.  Not just the context clause, but the parent unit name,
+and all the context clauses that get inherited by children and subunits
+and bodies.
+
+> This set of visible packages would probably be represented
+> using a hash table of some sort.  It would start out empty
+> when starting to compile a new compilation unit, and would
+> grow each time a (real, not limited) "with" for a package or a package
+> renaming is processed.  Each of these "with"ed packages
+> would be scanned for enclosed renamings, recursively.
+> [Alternatively, the representation of every package could
+> include a set of all enclosed renamings (directly or indirectly).]
+> The "with"ed package, plus all of the packages for which it
+> contains a renaming, would be unioned into this set.
+>
+> Later, whenever a limited view of a package is encountered
+> within a name, a check is made to see whether a corresponding
+> full view exists in this set.  If so, the limited view may
+> not be named, and so the name is illegal.
+
+I don't undersstand this.  First, it seems like this is all part of
+overload resolution: you see a name, and it will resolve to the full
+view, if the full view is visible.
+
+Second, why do you concentrate on names?  I mean, you run across types
+in the symbol table all the time, and it seems like you need to make the
+decision there as well.  (Consider the examples in my earlier e-mail,
+where you refered to a variable that is of the type, a subtype of the
+type, or whatever.)
+
+> Another anticipated rule is that a limited with clause is
+> illegal if the package is already visible, including
+> via a rename.  This would seem to be friendlier than allowing
+> the programmer to put a "limited with" on a compilation unit and
+> then not be able to use it at all.
+
+Perhaps a little bit friendlier, but it's not the simplest rule,
+and you're not really protecting the user against any serious damage.
+
+>...  However, there will still
+> be "limited with"s inherited from ancestor units, and these
+> will be essentially ignored if the corresponding package
+> is fully visible some other way.  Also, in a limited with
+> clause like "limited with P.Q.R;" presumably implicit
+> limited withs for P and P.Q are provided, but such an implicit
+> limtied with again must be ignored if the package mentioned
+> is already fully visible via some other means.
+>
+> To enforce the above rule regarding disallowing and/or ignoring
+> limited withs, it may be necessary to do a second pass over
+> the context clause, after the full set of visible packages has
+> been built up.  In many cases, a second pass is already necessary
+> in Ada 95 to correctly deal with "with"s of private units, since it is
+> not known whether those with's are legal until the name of the
+> compilation unit being compiled is known, so it may be possible
+> to combine these error-checking passes.
+
+The existing rule requires looking at the comp unit name before
+processing the context clause.  It doesn't require two passes over the
+context clause.  (Either way, it's not the "one pass semantics" that you
+and Robert Dewar like so much.  ;-) )
+
+> WHEN IS THE INCOMPLETE TYPE COMPLETE?
+>
+> Our current plan is to disallow "use" clauses and renamings
+> for limited views.  Given that, the only way to name one
+> of the incomplete types inside a limited view is by naming
+> the enclosing package, so there is no need to have a separate mechanism
+> for determining whether the incomplete type declaration is visible.
+> It is visible exactly when the enclosing limited view can be named.
+>
+> However, there are access types that might have been declared
+> using the incomplete type, and it is important to know when a
+> dereference of the access type is considered "complete."
+
+And parameters (in the tagged case).  Normally, the body will 'with' the
+full view, so it can do stuff with the type.  But if you forget that
+'with', the compiler needs to notice that the type is still incomplete.
+
+> The basic rule would be that when the full type is visible,
+> including via a rename of the enclosing package, (or equivalently,
+> when the incomplete type declaration is hidden from all visibility),
+> the access type may be dereferenced to produce the full type.
+> This implies that any time such an access type is dereferenced,
+> a check should be made whether the designated type's enclosing limited
+> view(s) are all still visible.  If they are all still visible,
+> then the incomplete type is still visible, and the dereference
+> produces an incomplete object.
+
+I don't think you mean, "produces an incomplete object".  I think you
+mean, simply, "is illegal".
+
+I'm not sure I understand the "all" here.  I mean, just because the full
+view of *one* such containing package is visible doesn't make the full
+view of the type visible, does it?
+
+>...If any one of them is hidden from
+> all visibility, then the full type is visible, and the dereference
+> produces an object of a "full" type.  Some optimization of this
+> check is probably possible.
+>
+> Even when a dereference of the access type is considered
+> incomplete, it may still be legal in a context where a full
+> type would normally be required, so long as the expected type
+> is the full type, or the full type is "nearby."  One of the
+> versions of the type-stub proposal laid out the rules for
+> this matching between incomplete and full type, and those
+> rules seem still relevant for all of the other proposals as well.
+
+Oh, I see.  So what I said above is wrong.  Hmm.
+
+> Here is a copy of those rules (from AI-00217-04/04):
+>
+>     A dereference (implicit or explicit) of a value of an access type whose
+>     designated type D is incomplete is allowed only in the following
+>     contexts:
+>
+>     * in a place where the completion of D is available (see above);
+>
+>     * in a context where the expected type is E and
+>        o E covers the completion of D,
+>        o E is tagged and covers D,
+>        o E covers D'Class or its completion, or
+>        o E'Class covers D or its completion;
+>
+>     * as the target of an assignment_statement where the type of the value
+>       being assigned is V, and V or V'Class is the completion of D.
+
+How can V'Class be the completion of something?
+
+>     In these contexts, the incomplete type is defined to be the same
+>     type as its completion, and its first subtype statically matches the
+>     first subtype of its completion.
+>
+> The first bullet would be replaced by "where the full type declaration
+> for D is visible" for the limited-with proposal (and for the
+> "type C.T;" proposal).
+
+**************************************************************
+
+From: Tucker Taft
+Sent: Tuesday, February 11, 2003  10:28 PM
+
+Robert A Duff wrote:
+>>SEPARATE "LIMITED" COMPILATION UNIT
+>>
+>>Our model for implementing a limited view of a library package
+>>will be that it has its "own" compilation-unit name,
+>>constructed from its "real" name but with suffix "'Limited".
+>
+>
+> I don't see why you want it to have a different name.  It seems to me
+> that there are two declarations of views, both called P.Q.R, and the
+> full view hides the limited view.
+
+Some of this is in reaction to Randy and Pascal's
+comments on my earlier implementation musings.
+They don't like the idea of having two units in the library with
+the same name.  It breaks their model badly.  So
+I was proposing that they have different names,
+at least as far as the program library mechanism is
+concerned.  In general, the program library mechanism
+is presumed to be too stupid to understand hiding.
+And the limited view might be needed even when the
+full view has been added to the program library, because
+a unit explicitly requests the limited view via "limited with."
+
+>>Hence P.Q.R'Limited is the limited view of P.Q.R.
+>>[Note that "P.Q.R.Limited" could also be used as the
+>>name, since "limited" is a reserved word, and would
+>>never be the real name of a package.  However, it is
+>>very important that in any case P.Q.R.Limited or
+>>P.Q.R'Limited not depend semantically on P.Q.R itself.]
+>
+>
+> Right -- the dependence is the other way 'round.
+
+If there is any dependence at all.  They both depend
+on the source text for P.Q.R, but only the full view
+depends on the source text for other units on which
+it is semantically dependent.
+
+>>In the representation of the library, it is important
+>>that P.Q.R'Limited can exist before P.Q.R has been
+>>fully compiled, and can retain some continuing existence
+>>while P.Q.R is being fully compiled, and thereafter.
+>>It is also important to realize that the packages
+>>nested within P.Q.R'Limited are themselves limited
+>>views.
+>
+>
+> And *they* don't get weird names...
+
+Right.  The "weird" names are just so the program
+library mechanism can be relatively stupid, and
+just deliver up one and only one unit given a particular
+name.
+
+>>...Hence, P.Q.R'Limited.NP always denotes a limited view
+>>of a package, if P.Q.R.NP denotes a nested package spec.  Similarly,
+>>P.Q.R'Limited.T denotes an incomplete type declaration for T,
+>>if P.Q.R.T denotes a full type declaration.
+>>
+>>SEPARATE TIMESTAMP FOR LIMITED VIEW
+>>
+>>P.Q.R'Limited has its own timestamp, for the purposes
+>>of out-of-dateness checking.  It is important that this
+>>*not* change when a "full" compile of P.Q.R is started,
+>>because that would make the units that P.Q.R depends
+>>on that themselves depend on P.Q.R'Limited, automatically
+>>appear out of date.
+>
+>
+> Right.  It seems to me that in a source-based library model, the
+> timestamp of the limited view can be the timestamp of the source file
+> containing that package, whereas the timestamp of the full view is
+> really a collection of timestamps for all the source files the package
+> depends upon.
+
+I was trying to handle various approaches to time stamps.
+In our model, each compiled representation keeps the
+timestamps of all the source files it depends on.  As you
+imply above, P.Q.R'Limited would depend on exactly one
+source file ("p.q.r.spc", for example), whereas P.Q.R would
+probably depend on many source files, including p.q.r.spc
+as well.
+
+I believe in Randy's model, there is a timestamp
+associated with the compiled representation itself, and
+it must be >= the timestamps of all other compiled representations
+it depends on.  I don't believe he keeps source file timestamps
+at all.  Timestamps are associated with when a unit is submitted
+to the compiler, I believe.
+
+I think Rational has aspects of both timestamp models, though
+I will let Pascal talk about the details.
+
+>>Once the full compile of P.Q.R is complete, a check for
+>>consistency between P.Q.R'Limited and P.Q.R should be
+>>performed.
+>
+> I don't understand the need for this consistency check.
+> It seems to me that P.Q.R depends upon P.Q.R'Limited,
+> and you do the normal check at link time, to make sure that
+> two different versions of P.Q.R'Limited are not included in the same
+> partition.
+>
+> In normal operation, you just do a "build" command, and the only way the
+> link-time check can fail is if you edit your source code while the build
+> is running.
+
+Again, I was trying to accommodate a model where timestamps
+are associated with compiled representations, rather than
+only with source text.  I agree that a purely source-based
+model can be simpler.
+
+>>...  If the views are no longer consistent, due to
+>>some change in P.Q.R, a new version of P.Q.R'Limited should
+>>be constructed, and its timestamp changed.  This will effectively
+>>put all the dependents of P.Q.R'Limited out of date,
+>>and may in fact put P.Q.R itself out of date.  If so,
+>>then P.Q.R will have to be compiled again.  Ideally, this
+>>will be performed immediately, since the source code for
+>>P.Q.R is readily available at that time.  However, depending on the
+>>compilation mechanism, it may be first necessary to compile
+>>other dependents of P.Q.R'Limited, so they are back in
+>>an up-to-date state before re-attempting the full
+>>compilation of P.Q.R.  This might be left until link time,
+>>or to a separate "make" tool.
+>
+>
+> I don't see the need for such complexity in the "make" tool
+> (recompiling things twice and whatnot).  It seems no different
+> than the current language: if you edit package Foo in between compiling
+> two different things that depend on Foo, then you get a link-time
+> failure, and run the "make" tool again.
+
+Yes, I agree the source-based model can be simpler.  However,
+Randy seemed to find the timestamp issue a big problem with
+"limited with," so I was making some attempt to address that.
+I probably shouldn't have strayed away from the source-based
+model.
+
+>>Of course if P.Q.R'Limited is initially created by simply parsing
+>>the source text for P.Q.R, the timestamp of P.Q.R'Limited would be
+>>set at parse time.
+>>
+>>For those compilation systems that retain the date of modification
+>>of the source file as the time stamp of the corresponding units
+>>in the program library, some of this becomes simpler.
+>>Nevertheless, it seems a helpful, and in some cases
+>>necessary, "optimization" to *not* change the timestamp of
+>>the limited view every time the source text timestamp changes.
+>>Because the check for consistency between a full view and
+>>a limited view should be relatively easy to perform, there
+>>seems no need to change the timestamp on the limited view
+>>so long as it remains consistent with the full view, even
+>>if the full view corresponds to source text with a different
+>>timestamp.  This means that units that depend only on the
+>>P.Q.R'Limited are isolated from "minor" changes to P.Q.R,
+>>and are only affected when a type or nested package is
+>>added or removed from P.Q.R.   In other words, you get
+>>a "poor man's" version of incremental compilation as a side
+>>effect of implementing limited views of packages.
+>
+>
+> Seems like a nice optimization, but I don't see why it's necessary.
+
+I think it might be necessary in the non-source-based
+model, if timestamps are associated with the time when units
+are submitted to the compiler, rather than with when
+the source text is edited.
+
+
+>
+>
+>>HIDING THE LIMITED VIEW
+>>
+>>As mentioned above, a limited view of a package can be hidden from
+>>all visibility.  The anticipated rule is that the limited
+>>view is hidden from all visibility if the full view is visible
+>>either "normally" or via a rename.  This implies that if
+>>P.Q.R is visible, including via a rename, then P.Q.R'Limited
+>>is not visible.  Furthermore, even when P.Q.R'Limited
+>>is visible, it is possible that P.Q.R'Limited.NP might
+>>not be visible, because P.Q.R.NP might be visible via
+>>a renaming.
+>>
+>>A relatively simple implementation of this requirement
+>>would seem to be to build up a set representing those (external) packages
+>>that have a full view visible, including via a rename, within the
+>>current compilation unit.  (By "external" we mean it is from some
+>>other compilation unit.)  This set will not grow once the
+>>context clause has been fully processed, since it is not
+>>possible to locally declare a renaming of a package that is not
+>>already visible.
+>
+>
+> Well, sort of.  Not just the context clause, but the parent unit name,
+> and all the context clauses that get inherited by children and subunits
+> and bodies.
+
+Right.
+
+>
+>
+>>This set of visible packages would probably be represented
+>>using a hash table of some sort.  It would start out empty
+>>when starting to compile a new compilation unit, and would
+>>grow each time a (real, not limited) "with" for a package or a package
+>>renaming is processed.  Each of these "with"ed packages
+>>would be scanned for enclosed renamings, recursively.
+>>[Alternatively, the representation of every package could
+>>include a set of all enclosed renamings (directly or indirectly).]
+>>The "with"ed package, plus all of the packages for which it
+>>contains a renaming, would be unioned into this set.
+>>
+>>Later, whenever a limited view of a package is encountered
+>>within a name, a check is made to see whether a corresponding
+>>full view exists in this set.  If so, the limited view may
+>>not be named, and so the name is illegal.
+>
+>
+> I don't undersstand this.  First, it seems like this is all part of
+> overload resolution: you see a name, and it will resolve to the full
+> view, if the full view is visible.
+
+The problem is package renames.  We concluded that if there
+is a renaming of P.Q.R visible, then the limited view of
+P.Q.R should become invisible, even though "P.Q.R" does not
+denote the full view.  So this is a case where a name is
+hidden from all visibility, even though it isn't a homograph
+with the thing doing the hiding.  This is somewhat like a more
+extreme version of the situation where having one overloadable
+in a use-visible set hides all the non-overloadables in the
+use-visible set, and vice versa.  Here, S.Renaming_Of_P_Q_R
+is hiding P.Q.R'Limited from all visibility.
+
+>
+> Second, why do you concentrate on names?  I mean, you run across types
+> in the symbol table all the time, and it seems like you need to make the
+> decision there as well.
+
+Well, I talk about that later.  If the types are already in the
+symbol table, the question is whether they should be considered
+incomplete or complete.  The name issue is whether the name is
+even visible.
+
+
+> ...
+>  (Consider the examples in my earlier e-mail,
+> where you refered to a variable that is of the type, a subtype of the
+> type, or whatever.)
+
+I gave an adequate explanation of that there, hopefully.
+
+>
+>
+>>Another anticipated rule is that a limited with clause is
+>>illegal if the package is already visible, including
+>>via a rename.  This would seem to be friendlier than allowing
+>>the programmer to put a "limited with" on a compilation unit and
+>>then not be able to use it at all.
+>
+>
+> Perhaps a little bit friendlier, but it's not the simplest rule,
+> and you're not really protecting the user against any serious damage.
+
+That's true.  But it would seem mysterious if the reason
+the limited with has no effect is because there is a renaming
+in some "with"ed package.  I think the programmer should be
+told about that as soon as possible, and the limited with
+clause seems like the ideal place.
+
+>
+>
+>>...  However, there will still
+>>be "limited with"s inherited from ancestor units, and these
+>>will be essentially ignored if the corresponding package
+>>is fully visible some other way.  Also, in a limited with
+>>clause like "limited with P.Q.R;" presumably implicit
+>>limited withs for P and P.Q are provided, but such an implicit
+>>limtied with again must be ignored if the package mentioned
+>>is already fully visible via some other means.
+>>
+>>To enforce the above rule regarding disallowing and/or ignoring
+>>limited withs, it may be necessary to do a second pass over
+>>the context clause, after the full set of visible packages has
+>>been built up.  In many cases, a second pass is already necessary
+>>in Ada 95 to correctly deal with "with"s of private units, since it is
+>>not known whether those with's are legal until the name of the
+>>compilation unit being compiled is known, so it may be possible
+>>to combine these error-checking passes.
+>
+>
+> The existing rule requires looking at the comp unit name before
+> processing the context clause.  It doesn't require two passes over the
+> context clause.  (Either way, it's not the "one pass semantics" that you
+> and Robert Dewar like so much.  ;-) )
+
+You can do it either way.  AdaMagic doesn't peak ahead at the comp-unit
+name.  Instead, it processes all the "with" clauses and then
+when it reaches the comp-unit name, it checks to be sure they
+are legal.  So if you do it that way, you already have that
+second pass over the context clause.
+
+>>WHEN IS THE INCOMPLETE TYPE COMPLETE?
+>>
+>>Our current plan is to disallow "use" clauses and renamings
+>>for limited views.  Given that, the only way to name one
+>>of the incomplete types inside a limited view is by naming
+>>the enclosing package, so there is no need to have a separate mechanism
+>>for determining whether the incomplete type declaration is visible.
+>>It is visible exactly when the enclosing limited view can be named.
+>>
+>>However, there are access types that might have been declared
+>>using the incomplete type, and it is important to know when a
+>>dereference of the access type is considered "complete."
+>
+>
+> And parameters (in the tagged case).  Normally, the body will 'with' the
+> full view, so it can do stuff with the type.  But if you forget that
+> 'with', the compiler needs to notice that the type is still incomplete.
+
+Right.
+
+>>The basic rule would be that when the full type is visible,
+>>including via a rename of the enclosing package, (or equivalently,
+>>when the incomplete type declaration is hidden from all visibility),
+>>the access type may be dereferenced to produce the full type.
+>>This implies that any time such an access type is dereferenced,
+>>a check should be made whether the designated type's enclosing limited
+>>view(s) are all still visible.  If they are all still visible,
+>>then the incomplete type is still visible, and the dereference
+>>produces an incomplete object.
+>
+>
+> I don't think you mean, "produces an incomplete object".  I think you
+> mean, simply, "is illegal".
+
+That used to be true.  But with incomplete tagged types, it is
+legal to dereference under certain circumstances.  Also, the
+"extra" matching rules also imply that the dereference can be legal,
+even for a non-tagged incomplete type.
+
+> I'm not sure I understand the "all" here.  I mean, just because the full
+> view of *one* such containing package is visible doesn't make the full
+> view of the type visible, does it?
+
+Yes, if the full view of any containing package is visible,
+then everything inside the package is definitely visible.
+By "containing" I should say "textually" containing.  I don't
+mean to include ancestor library packages.
+
+>>...If any one of them is hidden from
+>>all visibility, then the full type is visible, and the dereference
+>>produces an object of a "full" type.  Some optimization of this
+>>check is probably possible.
+>>
+>>Even when a dereference of the access type is considered
+>>incomplete, it may still be legal in a context where a full
+>>type would normally be required, so long as the expected type
+>>is the full type, or the full type is "nearby."  One of the
+>>versions of the type-stub proposal laid out the rules for
+>>this matching between incomplete and full type, and those
+>>rules seem still relevant for all of the other proposals as well.
+>
+>
+> Oh, I see.  So what I said above is wrong.  Hmm.
+>
+>
+>>Here is a copy of those rules (from AI-00217-04/04):
+
+The second and third bullets below are what I have
+been referring to as the "extra" matching rules.
+
+>>
+>>    A dereference (implicit or explicit) of a value of an access type whose
+>>    designated type D is incomplete is allowed only in the following
+>>    contexts:
+>>
+>>    * in a place where the completion of D is available (see above);
+>>
+>>    * in a context where the expected type is E and
+>>       o E covers the completion of D,
+>>       o E is tagged and covers D,
+>>       o E covers D'Class or its completion, or
+>>       o E'Class covers D or its completion;
+>>
+>>    * as the target of an assignment_statement where the type of the value
+>>      being assigned is V, and V or V'Class is the completion of D.
+>
+>
+> How can V'Class be the completion of something?
+
+The "full" implicitly declared type P.Q.R.V'Class can be the
+completion of the (implicitly declared) incomplete type
+P.Q.R'Limited.V'Class.
+
+**************************************************************
+
+From: Robert A. Duff
+Sent: Wednesday, February 12, 2003  2:40 PM
+
+Tucker says:
+
+> Some of this is in reaction to Randy and Pascal's
+> comments on my earlier implementation musings.
+> They don't like the idea of having two units in the library with
+> the same name.  It breaks their model badly.  So
+> I was proposing that they have different names,
+> at least as far as the program library mechanism is
+> concerned.
+
+It seems just like spec vs. body.  Now we have limited view vs. spec.
+
+> > I don't understand the need for this consistency check.
+> > It seems to me that P.Q.R depends upon P.Q.R'Limited,
+> > and you do the normal check at link time, to make sure that
+> > two different versions of P.Q.R'Limited are not included in the same
+> > partition.
+> >
+> > In normal operation, you just do a "build" command, and the only way the
+> > link-time check can fail is if you edit your source code while the build
+> > is running.
+>
+> Again, I was trying to accommodate a model where timestamps
+> are associated with compiled representations, rather than
+> only with source text.  I agree that a purely source-based
+> model can be simpler.
+
+I don't see what difference the library model makes in this regard.  If
+you have a "build" command, it has to look at timestamps of source
+files.  It doesn't matter whether those time stamps are recorded with
+the compilation artifacts, or whether those get the timestamp of when
+they were generated.
+
+Either way, so long as the user is not doing something in parallel (like
+editing the source, or deleting the compilation artifacts by hand), then
+end result will be a consistent build result.
+
+In other words, the job of a "build" tool is to bring everything up to
+date, whatever that means for the library model in use.  If the build
+tool complains about things being out of date, then it's broken (except
+when the user is meddling in parallel as described above).
+
+I claim this is possible to achieve in *any* of the models, without
+extra complexity (such as when you talked about compile the same thing
+twice).
+
+Of course, implementations are not required to support "build" tools,
+and if they don't then the user has to worry about more stuff.
+But we were talking about what a build tool would do...
+
+Perhaps Randy or Pascal can explain about non-source-based compilers
+better....
+
+**************************************************************
+
+From: Tucker Taft
+Sent: Wednesday, February 12, 2003  3:33 PM
+
+Robert A Duff wrote:
+> It seems just like spec vs. body.  Now we have limited view vs. spec.
+
+Yes, that is similar.  The "full" name of the unit in the program library
+could really be <comp_unit => "P.Q.R", kind => spec/body/limited-view>.
+
+> > > I don't understand the need for this consistency check.
+> > > It seems to me that P.Q.R depends upon P.Q.R'Limited,
+> > > and you do the normal check at link time, to make sure that
+> > > two different versions of P.Q.R'Limited are not included in the same
+> > > partition.
+> > >
+> > > In normal operation, you just do a "build" command, and the only way the
+> > > link-time check can fail is if you edit your source code while the build
+> > > is running.
+> >
+> > Again, I was trying to accommodate a model where timestamps
+> > are associated with compiled representations, rather than
+> > only with source text.  I agree that a purely source-based
+> > model can be simpler.
+>
+> I don't see what difference the library model makes in this regard.  If
+> you have a "build" command, it has to look at timestamps of source
+> files.  It doesn't matter whether those time stamps are recorded with
+> the compilation artifacts, or whether those get the timestamp of when
+> they were generated.
+
+I'll let Randy explain whatever problem he was foreseeing.
+I may not have it right in any case.
+
+If I remember correctly, Randy implied that
+the source file timestamps were useless on Windows, because
+they weren't reliable or didn't have enough resolution,
+so his compiler generated sequential timestamps that were
+associated with the order in which files were submitted to
+the compiler.  His build tool determines an order that should
+work, and perhaps queries the compiler to determine which
+units are considered out of date, and determines a sequence
+for just those units.
+
+> Either way, so long as the user is not doing something in parallel (like
+> editing the source, or deleting the compilation artifacts by hand), then
+> end result will be a consistent build result.
+>
+> In other words, the job of a "build" tool is to bring everything up to
+> date, whatever that means for the library model in use.  If the build
+> tool complains about things being out of date, then it's broken (except
+> when the user is meddling in parallel as described above).
+
+I think this presumes a build tool that understands the out-of-dateness
+rules.  I'm not sure that is how RR's works.
+
+> I claim this is possible to achieve in *any* of the models, without
+> extra complexity (such as when you talked about compile the same thing
+> twice).
+>
+> Of course, implementations are not required to support "build" tools,
+> and if they don't then the user has to worry about more stuff.
+> But we were talking about what a build tool would do...
+
+I wasn't talking about what a build tool would do, but maybe
+you were.  I was talking about what the compiler would do when
+presented with a request to "fully" compile a unit, when it had
+earlier been parsed to produce a limited view.  If the full view
+and the limited view share a single sequentially-assigned time stamp,
+then you can get yourself into a tangle.  If the full view and
+the limited view have distinct time stamps, then things can work out.
+But you have no way of knowing whether the limited view and the
+full view were created from the same version of the source file
+if you don't believe source file timestamps.  The only way would
+be to compare the results of the two different ways of processing
+the same file.  I was suggesting that you compare the representation
+of the limited view with the representation of the full view, and
+if they are consistent, then there is no need to change the time
+stamp assigned to the limited view when it was first parsed.
+However, if they are inconsistent, then you need to recreate the
+limited view, and need to assign it the next sequential time stamp
+to make everything that depended on it out of date.
+
+> Perhaps Randy or Pascal can explain about non-source-based compilers
+> better....
+
+I presume so as well.  And I suspect that Rational and RR have
+different timestamp mechanisms.  So I suppose what I really did
+was propose an implementation model for a library based on
+sequentially assigned time stamps, where the modification date
+of the source text is not saved, nor generally believed.
+
+Our compiler, on the other hand, bases everything on the modification
+date of the source text, and, as you point out, if you do
+that, the only way things can get out of sync is if the file
+is edited in the middle of a "build."
+
+**************************************************************
+
+From: Robert A. Duff
+Sent: Wednesday, February 12, 2003  4:30 PM
+
+> If I remember correctly, Randy implied that
+> the source file timestamps were useless on Windows, because
+> they weren't reliable or didn't have enough resolution,
+
+I know of two problems with windows file timestamps, which have caused
+trouble for AdaMagic in the past:
+
+It does weird things with daylight-savings time, and with time zones, so
+that if you compiled everything in the summer, and then waited until
+winter (or vice versa) it would wrongly think everything it out of date
+and need recompiling, and similarly that shipping a program library to a
+different time zone would cause everything to seem out of date.
+
+Different windows file systems store the timestamps with different
+granularity (half second versus 1 second, or something like that), so
+that if you copy a directory from one to the other it would perturb some
+of the timestamps by, say, half a second.
+
+We found workarounds to both of these problems, but I sympathize with
+Randy: it was a pain.
+
+> so his compiler generated sequential timestamps that were
+> associated with the order in which files were submitted to
+> the compiler.
+
+**************************************************************
+
+From: Robert Dewar
+Sent: Wednesday, February 12, 2003  10:27 PM
+
+> It does weird things with daylight-savings time, and with time zones, so
+> that if you compiled everything in the summer, and then waited until
+> winter (or vice versa) it would wrongly think everything it out of date
+> and need recompiling, and similarly that shipping a program library to a
+> different time zone would cause everything to seem out of date.
+
+This sounds like something that results from an improper attempt to use GMT
+time stamps on windows. That's always a mistake.
+
+**************************************************************
+
+From: Randy Brukardt
+Sent: Thursday, February 13, 2003  2:09 PM
+
+> > It does weird things with daylight-savings time, and with time zones, so
+> > that if you compiled everything in the summer, and then waited until
+> > winter (or vice versa) it would wrongly think everything it out of date
+> > and need recompiling, and similarly that shipping a program library to a
+> > different time zone would cause everything to seem out of date.
+>
+> This sounds like something that results from an improper attempt to use
+> GMT time stamps on windows. That's always a mistake.
+
+I'm not sure. But I do know that when daylight saving time changes, all of
+the file times change an hour. It's not just GMT time stamps, if you look at
+files in Explorer, you can see this effect. (This is certainly true on
+Windows 2000, I don't recall seeing it on NT or 95.) I hadn't realized that
+it happened for timezones as well until Bob mentioned it, although that
+makes perfect sense.
+
+Most of the problems we had, however, was that the granularity of source
+changes is fairly large, and its possible to have multiple time stamps that
+are identical. In the worst cases (such as subunits updated by a tool), this
+potentially caused out-of-date things to fail to get recompiled.
+
+Anyway, the build tool uses the source timestamps anyway, but the compiler
+uses a timestamp for each generated symbol file created at the creation (or
+rewrite) of the file. We couldn't use the timestamps directly because of the
+various problems. We then compare those timestamps. (Those wouldn't really
+have to be timestamps at all; anything strictly accending without
+duplication would work).
 
 **************************************************************
 

Questions? Ask the ACAA Technical Agent