CVS difference for ais/ai-50217.txt

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

--- ais/ai-50217.txt	2003/06/17 21:41:12	1.3
+++ ais/ai-50217.txt	2003/07/26 03:26:03	1.4
@@ -1139,6 +1139,202 @@
 
 **************************************************************
 
+From: Robert A Duff
+Sent: Tuesday, February 11, 2003  6:07 PM
+
+Dan Eilers reminded me in private e-mail to look at this e-mail he sent
+a week ago.
+
+It does seem like a reasonable proposal, and it does seem like it allows
+the full type for a private type to go in a separate file.
+
+I presume the rules for completing private types would be relaxed to
+allow the full type in a package subunit.
+
+I presume that if you say "with P'abstract", then P.T is an incomplete
+type (view).
+
+This proposal seems very similar to the one Tucker proposed a while ago,
+where package P declares that it has a child C.  The syntax here is more
+"subunit like" rather than "child like".
+
+Dan wrote:
+
+> Bob Duff wrote:
+>
+> > > I still think there is some possible dual-use synergy with the separate
+> > > private issue.  As Tuck corrected me, you can't just put the private
+> > > part in a separate file.  So instead of "private is separate" you would
+> > > have to say "the remainder of this package is separate".  A "with" clause
+> > > on such a package would continue to see both the root and the subunit.
+> > > A "with p'abstract" would see only the root.  I believe such new syntax
+> > > would at the same time solve the separate private issue and the circular
+> > > types issue, and perhaps also the separate constants issue.
+> >
+> > Perhaps, but I skept.  I'm having trouble seeing the separate-private
+> > issue as anything more than a simple textual translation, with no
+> > run-time consequences whatsoever.  I haven't seen a fully worked-out
+> > proposal that solves both problems...
+>
+> OK, here's the canonical example worked out:
+>
+> -- Note: with'ing package P creates a semantic dependency on all subunits
+> -- such as P.Extension declared in P, and makes all declarations in
+> -- P.Extension visible as if they were declared directly in P.
+>
+> -- with'ing P'abstract does not create a semantic dependency on subunits
+> -- such as P.Extension, and does not make p.Extension's declarations visible,
+> -- and does not allow declaring objects of types from P whose full type is
+> -- deferred to P.Extension.
+
+By "not allow declaring objects" I presume all the limitations of
+incomplete types are applied.  You can declare access-to-it, and you can
+declare parameters (if it's tagged), I guess.
+
+>     package Employees is
+>         type Employee is private;       -- completed in subunit
+>         type Emp_Ptr is access all Employee;
+>         package Extension is separate;
+>     end Employees;
+>
+>     package Departments is
+>         type Department is private;
+>         type Dept_Ptr is access all Department;
+>         package Extension is separate;
+>     end Departments;
+>
+>     with Departments'abstract;
+>     separate(Employees)
+>     package Extension is
+>         type Emp_Ptr is access all Employee;
+
+I don't see why you want to declare Emp_Ptr here.
+
+>         procedure Assign_Employee(E : access Employee;
+>                                   D : access Departments.Department);
+>         function Current_Department(D : access constant Employee) return
+>             Departments.Dept_Ptr;
+>     private
+>         type Employee is record
+>            dept: Departments.Dept_Ptr;
+>         end record;
+>     end Extension;
+>
+>     with Employees'abstract;
+>     separate(Departments)
+>     package Extension is
+>         type Dept_Ptr is access all Department;
+>         procedure Choose_Manager(D : access Department;
+>                                  Manager : access Employees.Employee);
+>     private
+>         type Department is
+>            mgr: Employees.Emp_Ptr;
+>         end record;
+>     end Extension;
+
+Hmm.  The existing language allows:
+
+    package P is
+        type T is private;
+
+        package Q is
+        private
+            type T is new Integer;
+        end Q;
+    private
+        type T is new Boolean;
+    end P;
+
+And the type Q.T has nothing to do with P.T.  I'm not sure how the rules
+would deal with this sort of thing.  Exactly when is a full type
+considered to complete a private type, and how do we prevent duplicate
+completions.
+
+The current language always completes things in the same declarative
+region, so this would add the complexity of completing things
+elsewhere.
+
+Well, now that I think about it, I take that back, somewhat: An
+accept_statement can be more nested than the corresponding entry, and
+there can be more than one of them.  So that's a similar situation.
+
+> For the "private is separate" problem, instead of:
+>
+>     package p is
+>       ...
+>     private is separate;
+>     end P;
+>
+> you would have:
+>
+>     package p is
+>       ...
+>     private
+>       package extension is separate;
+>     end;
+
+Seems plausible, although I'm still not sure we need to combine the
+solutions to these two problems.  After all, the separate-private as a
+purely textual translation seems OK.  Along with the "private with"
+idea.
+
+**************************************************************
+
+From: Dan Eilers
+Sent: Tuesday, February 11, 2003  7:40 PM
+
+
+Bob Duff wrote:
+> It does seem like a reasonable proposal, and it does seem like it allows
+> the full type for a private type to go in a separate file.
+...
+> This proposal seems very similar to the one Tucker proposed a while ago,
+> where package P declares that it has a child C.  The syntax here is more
+> "subunit like" rather than "child like".
+
+Yes, the two proposals are very similar.  They both involve an
+incomplete type whose completion is deferred to a child or stub
+that is mentioned in the parent.
+
+The advantages to using subunits are:
+
+1)  the subunit proposal leaves the clients unchanged.  The child
+    proposal requires library-level renames in order to leave the
+    clients unchanged;
+
+2)  it is natural in Ada for a parent to declare a subunit,
+    but not for a parent to declare a child unit;
+
+3)  the subunit proposal serves a dual purpose in solving the
+    need for separately compiled private parts;
+
+The advantage to using child units is:
+
+1)  the subunit proposal requires new syntax for "with" clauses,
+    to indicate no semantic dependence on any subunits.
+
+
+> Seems plausible, although I'm still not sure we need to combine the
+> solutions to these two problems.  After all, the separate-private as a
+> purely textual translation seems OK.  Along with the "private with"
+> idea.
+
+This "purely textual translation" is essentially "pragma include"
+from pre-Ada83 days.  It was excluded from Ada in favor of subunits
+because:
+
+    1) subunits often need their own context clauses, which include files
+          don't provide;
+    2) subunits specify their parent and can only have one parent;
+    3) subunits are well-formed, and can be compiled independently
+         from their parent
+
+These considerations also apply to separately compiled private parts,
+making subunits a much better solution than the combination of two
+hacks: "pragma include" and "private with".
+
+**************************************************************
+
 From: Tucker Taft
 Sent: Monday, February  3, 2003  4:27 PM
 
@@ -3245,7 +3441,7 @@
 -----------------
 Thoughts on the implementation of "limited with" in AdaMagic
 
-          $Revision: 1.3 $ $Date: 2003/06/17 21:41:12 $
+          $Revision: 1.4 $ $Date: 2003/07/26 03:26:03 $
 
 The "limited with" clause makes a "limited view"
 of a package visible in the compilation unit
@@ -4355,6 +4551,909 @@
 various problems. We then compare those timestamps. (Those wouldn't really
 have to be timestamps at all; anything strictly accending without
 duplication would work).
+
+**************************************************************
+
+From: Tucker Taft
+Sent: Tuesday, February 11, 2003  2:17 PM
+
+I thought I would update the full ARG on the Padua
+discussions relating to AI-00217, the mutual-dependence
+AI.  This is rightly the job of the minute taker or Pascal, but
+I thought some of you might be waiting with bated breath...
+So this is a *very* unofficial summary of what we decided.
+
+Well, we *didn't* decide on a single solution.  However,
+we did settle on an approach to make the decision, and
+we came to a number of decisions that limit the number
+of proposals that remain alive, and that answer some
+of the tricky semantic questions that all of the
+proposals are facing.
+
+We agreed to proceed with a full write up of the
+following three proposals:
+
+1) type stubs, limited to a single stub per full type,
+   where the package containing the full type must
+   have a "with" for the package containing the stub,
+   and where a "separate with ..." context clause
+   is required if a stub appears inside a package.
+   Randy will write this one up.
+
+2) incomplete type to be completed in a child/nested package.
+   (aka "type C.T;").  Tuck will write this one up.
+
+3) "limited with" of a package.  Pascal will write this
+   one up, presumably starting with Bob's version.
+
+As usual, the writeups should include wording, rationale, pros and cons,
+various examples, known gotchas, etc.
+
+In addition, Randy, Tuck, and Pascal will produce at least one
+extended example of use using "their" proposal, and then exchange
+examples and do the same for the examples developed by the other two.
+
+Finally, all three will develop implementation models for all
+three proposals within their respective compiler technologies.
+[NOTE: Tuck has an initial draft for "limited with" in the
+"AdaMagic" technology, which will be sent out shortly.]
+
+Tuck will include a presentation of these three alternatives
+at the upcoming Ada UK meeting on April 8/9 in Swindon,
+and hope to get some useful user input.  The extended examples
+should be available by this time for inclusion in the presentation.
+The implementation models need not be available by this date.
+
+During and after this sequence, the ARG will undergo
+its typically efficient process of e-mail analysis ;-),
+and no later than the end of the first day of the next
+ARG meeting, make a decision.
+
+----------------
+
+As far as specific technical decisions we made:
+
+1) When the full type declaration is visible, including
+via a renaming of its enclosing package, the incomplete
+type declaration is hidden from all visibility (type C.T
+and limited-with proposals), or the type stub becomes equivalent to
+the full type (type stub proposal).
+
+2) When a package is visible, including via a renaming, any
+"limited view" of the package is hidden from all visibility
+(type C.T and limited-with proposals).  By "limited view" we
+mean the view of a package or nested package which is made
+visible by the limited-with, or the child/nested package used as
+a prefix in the "type C.T;" proposal.
+
+3) A "limited with" would not be allowed if a
+full view of the package named is visible
+via some other means (limited with proposal).  An inherited
+limited with, or an implicit limited with of a package mentioned
+(but not the specifically "with"ed package itself) in a limited
+with clause (e.g. "P.Q" in "limited with P.Q.R"), would be
+ignored if the full view of the package is visible via some other means.
+
+4) No use clauses or renamings are permitted for a limited
+view of a package (type C.T and limited-with proposals).
+[Rationale: Use clauses seem to introduce possible Beaujolais-like
+effects, and renamings of limited views just make the
+"hidden from all visibility" rules even weirder.]
+
+5) "Limited with" would be available only on "normal" package
+declarations; a limited-with of a renaming or package instantiation
+would require too much semantic analysis for the average
+"dumb" parser.  No such limitation seemed necessary for
+the other two proposals, though it wasn't examined in
+detail.
+
+Some potentially interesting equivalences were noticed:
+
+* A "limited with" of a child has an effect that is
+  very similar to the "type C.T;" proposal.
+
+* A type stub for a type declared in a child has an
+  effect very similar to the "type C.T;" proposal.
+
+Because of these equivalences, it is always possible
+to have a single place where the access-to-incomplete type
+can be declared, and that place could always be the
+parent of the unit containing the full type, if that
+were desired.
+
+**************************************************************
+
+From: Robert A. Duff
+Sent: Tueday, February 11, 2003  4:12 PM
+
+I'll repeat my earlier admonishment: we ought to try to get this done
+ASAP.  The above schedule seems reasonable -- let's stick to it.
+
+I do not agree with Robert Dewar's comments last week, saying we should
+avoid rushing into a decision that may be technically wrong.  First,
+we've been at this for about 8 years -- it's hardly rushing.  Second,
+there are several workable solutions on the table.  In particular, the
+ARG already approved one workable solution.  We can patch it to address
+the (very minor, IMHO) concern that WG9 had, if we like.  Or we can
+leave it as is.  Or we can choose one of the other alternatives.  Either
+way, there is little danger of passing something that's broken.
+
+It seems silly to dither about this for a long time, just because we
+can't decide which of the several good solutions is best.  And no
+solution will be "perfect" in every regard.
+
+Of course, if we choose "limited with", we have to work out all the
+detailed rules.  But that seems entirely feasible to do in a matter of
+months, not years.  If not, we should pick one of the other good
+solutions.
+
+**************************************************************
+
+From: Robert Dewar
+Sent: Tuesday, February 11, 2003  4:25 PM
+
+> I do not agree with Robert Dewar's comments last week, saying we should
+> avoid rushing into a decision that may be technically wrong.
+
+That's rather amazing, look at what you are saying, you are saying you
+think it's fine to rush into a decision that may be technically wrong.
+
+Do you really mean that, or, as your supporting argument implies, are you
+arguing that we can make a decision that is technically right?
+
+To me, the LIMITED WITH looks very promising. I had thought some consensus
+was gathering on that solution, and I find it disappointing that Padua
+thought otherwise.
+
+**************************************************************
+
+From: Robert A. Duff
+Sent: Tuesday, February 11, 2003  5:00 PM
+
+> Do you really mean that, or, as your supporting argument implies, are you
+> arguing that we can make a decision that is technically right?
+
+I'm disagreeing with the assertion that we're "rushing" and I'm
+disagreeing with the assertion that there's a serious danger of
+making a bad choice.  I claim that we *already* have a technically-good
+solution (type stubs).
+
+> To me, the LIMITED WITH looks very promising. I had thought some consensus
+> was gathering on that solution, and I find it disappointing that Padua
+> thought otherwise.
+
+I also have a mild preference for the "limited with" idea.  But that
+proposal is still half baked.  If we can work out the rules in a
+reasonable time, and we don't discover any major surprises, then I'll be
+happy with that.  But I would also be happy with type stubs, or with
+Tucker's "type C.T" idea (which is pretty well baked), and if it takes
+two more years to "fully bake" the "limited with" idea, then I prefer
+the (nearly) already-worked-out solutions.
+
+If we were searching for perfection, we would still be working on the
+Ada 9X project.  ;-)
+
+**************************************************************
+
+From: Robert Dewar
+Sent: Tuesday, February 11, 2003  10:41 PM
+
+For me, the ability to reasonably automatically convert existing foreign
+language specs is the most important issue here. Perhaps I do not fully
+understand, but it seems to me that the limited with proposal is significantly
+better from this point of view.
+
+**************************************************************
+
+From: Robert A. Duff
+Sent: Tuesday, February 11, 2003  4:50 PM
+
+Tucker wrote:
+
+> 1) When the full type declaration is visible, including
+> via a renaming of its enclosing package, the incomplete
+> type declaration is hidden from all visibility (type C.T
+> and limited-with proposals), or the type stub becomes equivalent to
+> the full type (type stub proposal).
+
+All of these proposals seem to have an issue with indirect
+with_clauses.  Consider:
+
+    package P is
+        type C.T is tagged;
+        procedure Proc(X: C.T);
+    end P;
+
+    package P.C is
+        type T is tagged ...;
+    end P.C;
+
+    with P.C;
+    package Q is
+        Y, Z: P.C.T;
+    end Q;
+
+    with P, Q;
+    procedure Main is
+    begin
+        P.Proc(X => Q.Y); -- Legal?
+        Y := Z; -- Legal, surely.
+    end Main;
+
+Is the above legal?  Should it be?  Why?
+
+The full type decl of P.C.T is not visible in Main.  But we can still
+get our hands on that type via Y.  So we've got a situation where the
+incomplete type and the full type T are both "there" -- only one is
+visible by name, but we've got to ask whether these are the same type.
+
+It seems weird (to me) to make this illegal.  If it's illegal, then how
+do we explain why "X := Y" is legal?
+
+Tucker hates "Ripple Effects".  I don't entirely agree; it seems to me
+that with_clauses should have been transitive in the first place.
+
+Similar question: Can Main declare a variable of type P.C.T?
+
+If we're worried about renamings, do we also need to worry about
+subtypes (which act like renamings of types)?  E.g.:
+
+    package P is
+        type C.T is tagged;
+        procedure Proc(X: C.T);
+    end P;
+
+    package P.C is
+        type T is tagged ...;
+    end P.C;
+
+    with P.C;
+    package Q is
+        subtype S is P.C.T;
+    end Q;
+
+    with P, Q;
+    procedure Main is
+        W: S; -- Legal?
+    begin
+        Proc(X => W); -- Legal?
+    end Main;
+
+Here, the full type decl of P.C.T is not visible, but a subtype that
+essentially equivalent to that full type is visible.
+
+> 2) When a package is visible, including via a renaming, any
+> "limited view" of the package is hidden from all visibility
+> (type C.T and limited-with proposals).  By "limited view" we
+> mean the view of a package or nested package which is made
+> visible by the limited-with, or the child/nested package used as
+> a prefix in the "type C.T;" proposal.
+
+    limited with P.C;
+    package P is
+        procedure Proc(X: C.Nest.T);
+    end P;
+
+    package P.C is
+        package Nest is
+            type T is tagged ...;
+        end Nest;
+    end P.C;
+
+    with P.C;
+    package Q is
+        package Nest_XXX renames P.C.Nest;
+    end Q;
+
+    limited with P.C;
+    with P, Q;
+    procedure Main is
+        ...
+    end Main;
+
+Now in Main, does the above rule mean that we have a limited view of
+P.C, but a normal view of P.C.Nest and P.C.Nest.T?
+
+> 3) A "limited with" would not be allowed if a
+> full view of the package named is visible
+> via some other means (limited with proposal).  An inherited
+> limited with, or an implicit limited with of a package mentioned
+> (but not the specifically "with"ed package itself) in a limited
+> with clause (e.g. "P.Q" in "limited with P.Q.R"), would be
+> ignored if the full view of the package is visible via some other means.
+
+Wouldn't it be simpler to use the "ignore" semantics in both cases?
+In fact, the previous rule about the full view hiding the limited view
+would cover these cases, and imply the "ignore" semantics.
+
+The above rule seems to imply that:
+
+    with X;
+    limited with X;
+    package ...
+
+is illegal, but:
+
+    limited with X;
+    with X;
+    package ...
+
+is legal, which seems kind of silly.
+
+> 4) No use clauses or renamings are permitted for a limited
+> view of a package (type C.T and limited-with proposals).
+> [Rationale: Use clauses seem to introduce possible Beaujolais-like
+> effects, and renamings of limited views just make the
+> "hidden from all visibility" rules even weirder.]
+>
+> 5) "Limited with" would be available only on "normal" package
+> declarations; a limited-with of a renaming or package instantiation
+> would require too much semantic analysis for the average
+> "dumb" parser.
+
+I don't think the issue is "dumb parser", per se.  The issue is: if you
+say "limited with X;", the compiler has to be able to process X without
+looking at any source code outside of X, because that might lead back to
+*this* unit via a cycle.  In any case, I agree with this rule, although
+I would state the rationale differently.
+
+>...  No such limitation seemed necessary for
+> the other two proposals, though it wasn't examined in
+> detail.
+
+It seems clear that the other two proposals do not need such a
+limitation, because they do not require looking at the other package at
+all -- the type stub, or the "type C.T" tells us the name of the type,
+and whether it's tagged, which is all we need to know.  This seems like
+a minor argument in favor of those other proposals -- they would allow
+the full type to come from a renaming or an instance.
+
+**************************************************************
+
+From: Tucker Taft
+Sent: Tuesday, February 11, 2003  10:28 PM
+
+>>1) When the full type declaration is visible, including
+>>via a renaming of its enclosing package, the incomplete
+>>type declaration is hidden from all visibility (type C.T
+>>and limited-with proposals), or the type stub becomes equivalent to
+>>the full type (type stub proposal).
+>
+>
+> All of these proposals seem to have an issue with indirect
+> with_clauses.
+
+I hope not.  We made a big effort to avoid
+the so-called "ripple" effect.  This is why we
+talk about being visible rather than being in scope.
+
+ > ... Consider:
+>
+>     package P is
+>         type C.T is tagged;
+>         procedure Proc(X: C.T);
+>     end P;
+>
+>     package P.C is
+>         type T is tagged ...;
+>     end P.C;
+>
+>     with P.C;
+>     package Q is
+>         Y, Z: P.C.T;
+>     end Q;
+>
+>     with P, Q;
+>     procedure Main is
+>     begin
+>         P.Proc(X => Q.Y); -- Legal?
+
+Yes.  This is thanks to the "extra" matching
+rules.
+
+>         Y := Z; -- Legal, surely.
+
+Yes.
+
+>     end Main;
+>
+> Is the above legal?  Should it be?  Why?
+
+The "extra" matching rules deal with the cases
+where the expected type is incomplete and the actual
+is complete, and vice-versa.
+
+
+>
+> The full type decl of P.C.T is not visible in Main.  But we can still
+> get our hands on that type via Y.  So we've got a situation where the
+> incomplete type and the full type T are both "there" -- only one is
+> visible by name, but we've got to ask whether these are the same type.
+>
+> It seems weird (to me) to make this illegal.  If it's illegal, then how
+> do we explain why "X := Y" is legal?
+
+It is intended to be legal, thanks to the extra matching rules.
+
+
+>
+> Tucker hates "Ripple Effects".  I don't entirely agree; it seems to me
+> that with_clauses should have been transitive in the first place.
+
+There is no ripple effect in any of these examples.  And
+they should all be legal.
+
+>
+> Similar question: Can Main declare a variable of type P.C.T?
+
+No.  The name "P.C.T" refers to the incomplete type in Main.
+
+>
+> If we're worried about renamings, do we also need to worry about
+> subtypes (which act like renamings of types)?
+
+No.  Subtypes are treated differently by the proposed
+rules.  There seems no implementation problem having a subtype of
+the complete type visible while the incomplete type
+declaration is also visible.  Whether there is a
+danger of user confusion, I don't think so, but of
+course that is pretty hard to prove for an arbitrary user.
+
+> E.g.:
+>
+>     package P is
+>         type C.T is tagged;
+>         procedure Proc(X: C.T);
+>     end P;
+>
+>     package P.C is
+>         type T is tagged ...;
+>     end P.C;
+>
+>     with P.C;
+>     package Q is
+>         subtype S is P.C.T;
+>     end Q;
+>
+>     with P, Q;
+>     procedure Main is
+>         W: S; -- Legal?
+
+Yes, "S" is a subtype of a full type, and that
+never changes.
+
+>     begin
+>         Proc(X => W); -- Legal?
+
+Yes, the extra matching rules allow this.
+
+>     end Main;
+>
+> Here, the full type decl of P.C.T is not visible, but a subtype that
+> essentially equivalent to that full type is visible.
+
+True.
+
+>>2) When a package is visible, including via a renaming, any
+>>"limited view" of the package is hidden from all visibility
+>>(type C.T and limited-with proposals).  By "limited view" we
+>>mean the view of a package or nested package which is made
+>>visible by the limited-with, or the child/nested package used as
+>>a prefix in the "type C.T;" proposal.
+>
+>
+>     limited with P.C;
+>     package P is
+>         procedure Proc(X: C.Nest.T);
+>     end P;
+>
+>     package P.C is
+>         package Nest is
+>             type T is tagged ...;
+>         end Nest;
+>     end P.C;
+>
+>     with P.C;
+>     package Q is
+>         package Nest_XXX renames P.C.Nest;
+>     end Q;
+>
+>     limited with P.C;
+>     with P, Q;
+>     procedure Main is
+>         ...
+>     end Main;
+>
+> Now in Main, does the above rule mean that we have a limited view of
+> P.C, but a normal view of P.C.Nest and P.C.Nest.T?
+
+No.  It means you have a limited view of P.C, but
+P.C.Nest and P.C.Nest.T are hidden from all visibility.
+If you want to refer to P.C.Nest, you have to do so
+using Q.Nest_XXX.
+
+Although it may be weird for the subpackage P.C.Nest to
+"disappear," this only happens in cases where the limited
+with was unnecessary, and a normal "with" would not
+have introduced circularities.  We want to be sure this
+works, but we don't need to make it completely "pretty."
+
+>3) A "limited with" would not be allowed if a
+>>full view of the package named is visible
+>>via some other means (limited with proposal).  An inherited
+>>limited with, or an implicit limited with of a package mentioned
+>>(but not the specifically "with"ed package itself) in a limited
+>>with clause (e.g. "P.Q" in "limited with P.Q.R"), would be
+>>ignored if the full view of the package is visible via some other means.
+>
+>
+> Wouldn't it be simpler to use the "ignore" semantics in both cases?
+> In fact, the previous rule about the full view hiding the limited view
+> would cover these cases, and imply the "ignore" semantics.
+
+Yes, disallowing the limited with is simply a "friendly"
+arbitrary restriction.  It would be ignored in any case.
+But it seems friendly to notify the programmer that a
+"limited with" is useless.  This is particularly true when
+the reason it is useless is because there is a visible rename.
+We would like the compiler to point that out.
+
+
+> The above rule seems to imply that:
+>
+>     with X;
+>     limited with X;
+>     package ...
+>
+> is illegal, but:
+>
+>     limited with X;
+>     with X;
+>     package ...
+>
+> is legal, which seems kind of silly.
+
+No, that was not the intent.  The legality check
+on the limited with would be after fully processing
+the context clause (and the parent name and the
+inherited with's).  It would not be dependent
+on which came first.
+
+>>...  No such limitation seemed necessary for
+>>the other two proposals, though it wasn't examined in
+>>detail.
+>
+>
+> It seems clear that the other two proposals do not need such a
+> limitation, because they do not require looking at the other package at
+> all -- the type stub, or the "type C.T" tells us the name of the type,
+> and whether it's tagged, which is all we need to know.  This seems like
+> a minor argument in favor of those other proposals -- they would allow
+> the full type to come from a renaming or an instance.
+
+True.
+
+**************************************************************
+
+From: Robert A. Duff
+Sent: Wednesday, February 12, 2003  2:10 PM
+
+Tuck says:
+
+> I hope not.  We made a big effort to avoid
+> the so-called "ripple" effect.  This is why we
+> talk about being visible rather than being in scope.
+
+Could you please explain to me (again) precisely what a ripple effect
+is, and why you consider them to be evil?  Sorry to be dense...
+
+> >>3) A "limited with" would not be allowed if a
+> >>full view of the package named is visible
+> >>via some other means (limited with proposal).  An inherited
+> >>limited with, or an implicit limited with of a package mentioned
+> >>(but not the specifically "with"ed package itself) in a limited
+> >>with clause (e.g. "P.Q" in "limited with P.Q.R"), would be
+> >>ignored if the full view of the package is visible via some other means.
+> >
+> > Wouldn't it be simpler to use the "ignore" semantics in both cases?
+> > In fact, the previous rule about the full view hiding the limited view
+> > would cover these cases, and imply the "ignore" semantics.
+>
+> Yes, disallowing the limited with is simply a "friendly"
+> arbitrary restriction.  It would be ignored in any case.
+> But it seems friendly to notify the programmer that a
+> "limited with" is useless.  This is particularly true when
+> the reason it is useless is because there is a visible rename.
+> We would like the compiler to point that out.
+
+This is a fairly minor point, but I still suggest going with the simpler
+rule.  The RM is not in the business of good error messages; leave that
+to implementers.
+
+It's like the use-clause thing -- if you have two homographs called X
+they cancel each other out.  The straightforward implementation of that
+would cause the compiler to say "no directly visible X" or something,
+which is an extremely unhelpful message.  Good compilers go to some
+extra trouble to point out that there are actually *two* X's, each of
+which is "almost" directly visible.
+
+Maybe when you see the actual RM wording, you'll agree...  ;-)
+
+**************************************************************
+
+From: Tucker Taft
+Sent: Wednesday, February 12, 2003  3:18 PM
+Robert A Duff wrote:
+>
+> Tuck says:
+>
+> > I hope not.  We made a big effort to avoid
+> > the so-called "ripple" effect.  This is why we
+> > talk about being visible rather than being in scope.
+>
+> Could you please explain to me (again) precisely what a ripple effect
+> is, and why you consider them to be evil?  Sorry to be dense...
+
+A ripple effect is when adding or removing a "with" clause in some
+unit on which the current unit depends semantically (potentially
+quite indirectly) has a significant effect on the legality of the
+current unit.  For example, at one point in Ada 83, to use 'Address, the
+current unit had to have a semantic dependence on System.  This
+involves a ripple effect, since adding or removing a "with" of
+System in some "distant" unit could affect legality of the unit
+containing the 'Address.
+
+> > >>3) A "limited with" would not be allowed if a
+> > >>full view of the package named is visible
+> > >>via some other means (limited with proposal).  An inherited
+> > >>limited with, or an implicit limited with of a package mentioned
+> > >>(but not the specifically "with"ed package itself) in a limited
+> > >>with clause (e.g. "P.Q" in "limited with P.Q.R"), would be
+> > >>ignored if the full view of the package is visible via some other means.
+> > >
+> > >
+> > > Wouldn't it be simpler to use the "ignore" semantics in both cases?
+> > > In fact, the previous rule about the full view hiding the limited view
+> > > would cover these cases, and imply the "ignore" semantics.
+> >
+> > Yes, disallowing the limited with is simply a "friendly"
+> > arbitrary restriction.  It would be ignored in any case.
+> > But it seems friendly to notify the programmer that a
+> > "limited with" is useless.  This is particularly true when
+> > the reason it is useless is because there is a visible rename.
+> > We would like the compiler to point that out.
+>
+> This is a fairly minor point, but I still suggest going with the simpler
+> rule.  The RM is not in the business of good error messages; leave that
+> to implementers.
+
+It seems very simple to disallow these useless "limited withs," so I would
+prefer to make them illegal, and my sense was that the rest of the ARG
+in Padua felt similarly.  But they can presumably answer for themselves.
+
+> ...
+> Maybe when you see the actual RM wording, you'll agree...  ;-)
+
+With whom?
+
+**************************************************************
+
+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.4 $ $Date: 2003/07/26 03:26:03 $
+
+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).
 
 **************************************************************
 

Questions? Ask the ACAA Technical Agent