CVS difference for 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