CVS difference for ais/ai-20217.txt

Differences between 1.6 and version 1.7
Log of other versions for file ais/ai-20217.txt

--- ais/ai-20217.txt	2002/02/05 02:06:24	1.6
+++ ais/ai-20217.txt	2002/02/07 04:56:42	1.7
@@ -10,8 +10,8 @@
 
 A new construct, called a separate incomplete type, is proposed
 as a potential solution to the "mutually recursive types across packages"
-problem. This is an alternative to the "with type" proposal of AI-217 and
-the "package abstract" proposal of AI-271.
+problem. This is an alternative to the "with type" proposal of AI-217-01 and
+the "package abstract" proposal of AI-217-02.
 
 A separate incomplete type is an incomplete type which is never completed.
 Another type can be "bound" to the separate incomplete type, which then allows
@@ -1820,110 +1820,6 @@
 from (keep in mind that Do_Something could have been defined in Interface
 itself, and a body dependence then would essentially reintroduce the problem
 we're trying to get around).
-
-*************************************************************
-
-From: Tucker Taft
-Sent: Monday, February 4, 2002,  5:49 PM
-
-[ai-217-02 is the AI formerly known as "ai-277" ;-]
-
-I thought I would mention that we went ahead and did a prototype
-implementation of incomplete type stubs, following the suggestion
-from Erhard where the package that defines the type is specified
-at the point of the stub.  It turned out to be a relatively modest
-enhancement to the existing support for incomplete types.
-
-The only tricky part is defining under exactly what circumstances a
-reference to the stub (say "P.T") is equivalent to a reference to
-the completing type (say "A.B.C.T").  The basic rule was that,
-presuming the package name given in the type stub declaration
-was "A.B.C" then "A" must be the name of a (root) library
-package that is visible in package Standard at the point
-of the reference (because it was "with"ed or because it encloses
-the point of reference); similarly B must be a (child) library package
-visible within A, and C must be visible within B.  A, B, and C must
-not be renamings, to avoid multiple names for the same completion.
-And of course a (non-type-stub?) type with the same name as the type stub
-(say "T") must be declared within the visible part of "C".  Presumably if "A"
-is not *directly* visible (because it is hidden by an inner
-homograph) that is OK, so long as <pkg_standard>.A is visible.
-
-This check is done at pretty much any use of P.T *except* as a
-designated subtype, as well as any dereference of an access-to-P.T.
-One question is if A.B.C is visible at the point of a declaration
-of an access-to-P.T type, should you "remember" that?  Our presumption
-was no, since the user could have written "A.B.C.T" if they had wanted
-those semantics.  Instead, if they write P.T as the designated subtype,
-then this may be dereferenced only where A.B.C is visible.
-
-Note that we require A.B.C to be visible, not merely in scope, so
-that "ripple" effects due to adding or removing a "distant" with
-clause don't alter the semantics.
-
-I suppose another question is what happens when there are two
-incomplete stubs with the same completing type.  Are they considered
-statically matching subtypes?  Or only where their (shared) completion
-is "available."  (I am using the term "available" to mean
-the full type's full name, e.g. A.B.C.T, is visible.)
-
-*************************************************************
-
-From: Randy Brukardt
-Sent: Monday, February 4, 2002,  5:49 PM
-
-> [ai-217-02 is the AI formerly known as "ai-277" ;-]
-
-Well, actually, AI-00217-03 (the third alternative of AI-217) is the AI
-formerly known as AI-277.
-
-> I thought I would mention that we went ahead and did a prototype
-> implementation of incomplete type stubs, following the suggestion
-> from Erhard where the package that defines the type is specified
-> at the point of the stub.  It turned out to be a relatively modest
-> enhancement to the existing support for incomplete types.
-
-Great! I need this yesterday in the Claw Builder. :-)
-
-I've been waiting for a proposal (and the upcoming meeting) before doing
-anything about an implementation.
-
-How did you describe the package "name" in the incomplete stub (since it cannot
-be a 'name' in the Ada sense, as it is not visible and cannot 'denote' anything
-in the stub -- at least if it is to be a useful construct)?
-
-> The only tricky part is defining under exactly what circumstances a
-> reference to the stub (say "P.T") is equivalent to a reference to
-> the completing type (say "A.B.C.T").  The basic rule was that,
-> presuming the package name given in the type stub declaration
-> was "A.B.C" then "A" must be the name of a (root) library
-> package that is visible in package Standard at the point
-> of the reference (because it was "with"ed or because it encloses
-> the point of reference); similarly B must be a (child) library package
-> visible within A, and C must be visible within B.  A, B, and C must
-> not be renamings, to avoid multiple names for the same completion.
-> And of course a (non-type-stub?) type with the same name as the type stub
-> (say "T") must be declared within the visible part of "C".  Presumably if "A"
-> is not *directly* visible (because it is hidden by an inner
-> homograph) that is OK, so long as <pkg_standard>.A is visible.
-
-Is the restriction against renames really necessary? It seems odd to introduce
-a case where a renamed package is not semantically equivalent to the package it
-renames. Such a restriction may make sense for the declaration (that would be
-equivalent to the rule for child packages), but I don't think you would want to
-enforce that on the checks (which is the 'use' of the rename, which is
-certainly allowed for child units).
-
-> ...
->
-> I suppose another question is what happens when there are two
-> incomplete stubs with the same completing type.  Are they considered
-> statically matching subtypes?  Or only where their (shared) completion
-> is "available."  (I am using the term "available" to mean
-> the full type's full name, e.g. A.B.C.T, is visible.)
-
-I would think only when the (shared) completion is available. But it doesn't
-seem important either way.
 
 *************************************************************
 

Questions? Ask the ACAA Technical Agent