CVS difference for ais/ai-50217.txt

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

--- ais/ai-50217.txt	2003/09/30 02:01:17	1.9
+++ ais/ai-50217.txt	2003/10/29 00:39:32	1.10
@@ -1,7 +1,7 @@
-!standard 10.01.02   (03)                           03-09-22  AI95-00217-06/04
-!standard 10.01.02   (04)
-!standard 10.01.02   (08)
-!standard J.10       (00)
+!standard 10.01.02   (04)                           03-10-08  AI95-00217-06/05
+!standard 10.01.02   (06)
+!standard 10.01.04   (02)
+!standard 10.01.04   (03)
 !class amendment 03-02-04
 !status work item 03-02-04
 !status received 03-02-04
@@ -20,7 +20,7 @@
 structures of a program into a single library unit, which is clearly
 undesirable in some situations.
 
-The goal of the proposed feature is to allow mutual recursion among type
+The goal of the proposed feature is to allow mutual recursion among types
 declared in separate packages (types containing (pointers to) each other as
 components, and primitive operations with (pointers to) each other as
 parameters), and to do this in a way that doesn't place any undue restrictions
@@ -62,7 +62,10 @@
 
 o  its expected type is the completion of T.
 
+<Author's note: this wording is provisional; final wording will be provided by
+AI 326, which is expected to define incomplete types in terms of views.>
 
+
 Replace 4.1(9) by:
 
 If the type of the name in a dereference is some access-to-object type T, then
@@ -70,6 +73,8 @@
 is the designated subtype T, unless T is an incomplete type, in which case the
 nominal subtype is the completion of T.
 
+<Author's note: same comment as for 3.10.1(10), above.>
+
 
 Change the beginning of 8.3(20):
 
@@ -86,26 +91,62 @@
 A package_name of a use_package_clause shall denote a non-limited view of a
 package.
 
-
-Add after of 8.4(10):
 
-o  A potentially use-visible declaration is not visible if the place considered
-   is within the scope of a limited_with_clause which:
+Insert after 8.4(7):
 
-   - is more nested than the use_clause; and
-   - mentions the package where the declaration occurs; and
-   - is not more nested than a nonlimited_with_clause which names that package.
+A package is *named* in a use_package_clause if it is denoted by a package_name
+of that clause. A type is *named* in a use_type_clause if it is determined by a
+subtype_mark of that clause.
+
+Replace 8.4(8) by (this is just using the new terminology):
+
+For each package named in a use_package_clause whose scope encloses a place,
+each declaration that occurs immediately within the declarative region of the
+package is potentially use-visible at this place if the declaration is visible
+at this place. For each type T or T'Class named in a use_type_clause whose
+scope encloses a place, the declaration of each primitive operator of type T is
+potentially use-visible at this place if its declaration is visible at this
+place.
 
 Replace 8.5.3(3) by:
 
 The renamed entity shall be a non-limited view of a package.
 
 
+Add after 10.1.1(12):
+
+For each library_package_declaration in the environment, there is
+an implicit declaration of a *limited view* of that library package. The
+limited view of a package contains:
+
+ - For each nested package_declaration, a declaration of the limited view of
+   that package, with the same defining_program_unit_name.
+
+ - For each type_declaration in the visible part, an incomplete_type_declaration
+   with the same defining_identifier, whose completion is the type_declaration.
+   If the type_declaration is tagged, then the incomplete_type_declaration is
+   tagged incomplete.
+
+The limited view of a library_package_declaration is private if that
+library_package_declaration is immediately preceded by the reserved word
+*private*.
+
+[There is no syntax for declaring limited views of packages, because they are
+always implicit.] The implicit declaration of a limited view of a package is
+_not_ the declaration of a library unit (the library_package_declaration is);
+nonetheless, it is a library_item.
+
+A library_package_declaration is the completion of its limited view
+declaration.
+
+The elaboration of the limited view of a package has no effect.
+
 Insert somewhere in 10.1.1(26):
 
-A limited library package view declaration depends semantically upon the parent
-limited package view declaration. A library package declaration depends
-semantically upon its limited view.
+The implicit declaration of the limited view of a library package depends
+semantically upon the implicit declaration of the limited view of its parent.
+The declaration of a library package depends semantically upon the implicit
+declaration of its limited view.
 
 
 Replace 10.1.2(4) by:
@@ -114,14 +155,6 @@
   limited_with_clause  ::= limited with library_unit_name {, library_unit_name};
   nonlimited_with_clause ::=       with library_unit_name {, library_unit_name};
 
-Add after 10.1.2(5):
-
-A with_clause is *more nested than* a context_item if the scope of the
-with_clause is (strictly) included in the scope of the context_item.
-Similarly, a with_clause is *more nested than* a use_clause occurring
-immediately within a declarative region, if the scope of the with_clause is
-included in the scope of the use_clause.
-
 Replace 10.1.2(6) by:
 
 A library_item is *named* in a with_clause if it is denoted by a
@@ -137,40 +170,21 @@
 generic_instantiation, or package_renaming_declaration].
 
 A limited_with_clause shall not appear on a library_unit_body or subunit.
-
-A limited_with_clause which names a library_item shall not be:
-
-o  part of the same context_clause as a nonlimited_with_clause which mentions
-   the same library_item; or
 
-o  more nested than a nonlimited_with_clause which mentions the same
-   library_item.
+A limited_with_clause which names a library_item shall not appear:
 
+o  in the same context_clause as a nonlimited_with_clause which mentions the
+   same library_item; or
 
-Add after 10.1.4(2):
+o  in the same context_clause as a use_clause which names an entity declared
+   within the declarative region of the library_item; or
 
-In addition, for each library_package_declaration in the environment, there is
-a conceptual declaration of a *limited view* of that library package. The
-limited view of a package contains:
-
- - A declaration of the limited view of each nested package_declaration.
+o  in the scope of a nonlimited_with_clause which mentions the same library_item;
+   or
 
- - For each type_declaration in the visible part, an incomplete_type_declaration
-   with the same name, whose completion is the type_declaration. If the
-   type_declaration is tagged, then the incomplete_type_declaration is tagged
-   incomplete.
-
-The limited view of a package has the same identifier as the
-package_declaration. It is private or public according to the declaration of
-the corresponding library_package_declaration.
-
-There is no syntax for declaring limited package views, because they are always
-implicit. A limited package view is _not_ the declaration of a library unit
-(the library_package_declaration is). Nonetheless, the declaration of a
-limited package view is considered to be a library_item.
+o  in the scope of a use_clause which names an entity declared within the
+   declarative region of the library_item.
 
-A library_package_declaration is considered to be the completion of its limited
-view declaration.
 
 Add after 10.1.4(3):
 
@@ -215,11 +229,6 @@
 in its usual place. "Limited with X" introduces a very limited view of X that
 only includes nested packages and incomplete types.
 
-We need to define the nesting of with_clauses relative to each other and to
-use_clauses to phrase a number of rules that describe the interaction between
-use_clauses and nonlimited_ and limited_with_clauses appearing on different
-units.
-
 The changes to 10.1.2(8) ensure that, if for instance the specification of Q
 has a "with P.R", it shall not have a "limited with P" or a "limited with P.R". The same applies to the children of Q. On the other hand, a "limited with P.R.S" is fine.
 
@@ -270,7 +279,9 @@
 
 Furthermore, use clauses are inherited from the parent unit. This may be used
 to construct a situation where a limited_with_clause occurs in the scope of a
-use_clause for the same unit. For example:
+use_clause for the same unit. We make such a limited_with_clause illegal, so
+that we don't have entities which are use-visible in a region where only the
+limited view of the enclosing library package is visible. For example:
 
    with A;
    package P is
@@ -279,45 +290,44 @@
 
    with P;
    package Q is
-      use P.R; -- Makes A use-visible.
+      use P.R; -- Makes declarations in A use-visible.
    end Q;
 
-   limited with A;
+   limited with A; -- Illegal.
    package Q.C is
-      -- A _not_ use-visible here.
+      -- Would declarations in A be use-visible here?
+      -- Better not answer that question...
    end Q.C;
 
-In this situation we say that the declarations in A are _not_ use-visible in
-the scope of the limited_with_clause. They are still potentially use-visible
-to prevent a Beaujolais effect illustrated by the following example (assume the
-same declaration for A and B as above):
+The following example shows the interactions with child units and nested
+packages:
 
-   with A, B;
    package P is
-      package RA renames A;
-      package RB renames B;
    end P;
 
-   with P;
+   package P.C is
+      package NP is
+      end NP;
+   end P.C;
+
+   with P.C;
    package Q is
-      use P.RA, P.RB; -- Makes A and B use-visible.
+      package PC renames P.C;
    end Q;
-
-   limited with A; -- Make this one a nonlimited "with"...
-   with B;         -- ... and this one a "limited with"
-   package Q.C is
-      Y : Integer := X; -- Illegal, really.
-   end Q.C;
 
-The rules are such that both Xs are made potentially use-visible, so the name X
-is illegal. If P.RA.X was not made potentially use-visible, the name X would
-resolve to P.RB.X, and its meaning would change when switching the with_clause
-as explained in the example.
-
-If you nest (in that order) (1) a use_clause, (2) a limited_with_clause and (3)
-a nonlimited_with_clause, then the limited_with_clause effectively cancels the
-use_clause, but the nonlimited_with_clause doesn't reestablish it. Again,
-that's to prevent Beaujolais effects.
+   with Q;
+   package R is
+      use Q.PC.NP; -- Makes declarations in P.C.NP use-visible.
+   end R;
+
+   limited with P; -- Illegal.
+   package R.C is
+   end R.C;
+
+In package R.C, the declarations in package P.C.NP are use-visible. We avoid
+complex visibility issues by making the "limited with P" illegal. It cannot be
+useful anyway, because the full view of P is surely available if we have
+use-visibility on some entity declared within its declarative region.
 
 A limited view of a package cannot be mentioned in a package renaming
 declaration. This restriction is probably not as critical as the others. The
@@ -388,7 +398,9 @@
 Note that a dereference that would occur after the completion of T would not be
 of an incomplete type, so 3.10.1(10) would not apply; consequently, such a
 dereference would be legal even though it would be in the declarative region of
-the incomplete type T.
+the incomplete type T. Note that the final wording regarding dereferences will
+be provided by AI 326 based on the definition of partial views for incomplete
+types.
 
 Presuming that AI 262 is adopted, limited_with_clauses also combine with
 private_with_clauses, with the following syntax:
@@ -404,6 +416,8 @@
 
 !ACATS test
 
+ACATS tests need to be created for this feature.
+
 !appendix
 
 From: Pascal Leroy
@@ -3547,7 +3561,7 @@
 -----------------
 Thoughts on the implementation of "limited with" in AdaMagic
 
-          $Revision: 1.9 $ $Date: 2003/09/30 02:01:17 $
+          $Revision: 1.10 $ $Date: 2003/10/29 00:39:32 $
 
 The "limited with" clause makes a "limited view"
 of a package visible in the compilation unit
@@ -5356,7 +5370,7 @@
 -----------------
 Thoughts on the implementation of "limited with" in AdaMagic
 
-          $Revision: 1.9 $ $Date: 2003/09/30 02:01:17 $
+          $Revision: 1.10 $ $Date: 2003/10/29 00:39:32 $
 
 The "limited with" clause makes a "limited view"
 of a package visible in the compilation unit
@@ -9449,6 +9463,84 @@
 design problem that can't be solved with an additional level of
 indirection. In any case, thanks again for sending us on the right
 path!
+
+***************************************************************
+
+From: Randy Brukardt
+Sent: Tuesday, September 30, 2003  3:36 PM
+
+> As a consequence, we must treat the limited_view of a type as an entity in
+> its own right, and add special type resolution rules to make the limited
+> and non-limited views compatible. We introduce shadow entities to hold the
+> limited_views, and links between the shadow entity and its partner, to
+> simplify type-checking. It turns out that these shadow entities (which
+> collectively correspond to the "abstract" of the package)  make the
+> implementation simpler that the one-entity model with a swapping mechanism
+> between views. They also make it easier to maintain necessary invariants
+> between the semantic analyzer and the back-end (that is to say the tree
+> transducer that uses the Ada AST to build the GCC tree).
+
+Janus/Ada has always used a model like this for incomplete and private
+types. However, type matching is done independently of visibility (with the
+exception of a nasty hack for private types in parent units).
+
+Could you explain in more detail the matching rules needed here? I'm trying
+to determine if they can be implemented in Janus/Ada without doing great
+violence to the existing type mechanisms.
+
+***************************************************************
+
+From: Ed Schonberg
+Sent: Tuesday, September 30, 2003  5:23 PM
+
+>  Janus/Ada has always used a model like this for incomplete and private
+>  types. However, type matching is done independently of visibility (with the
+>  exception of a nasty hack for private types in parent units).
+
+"nasty hack" and "implementation of private types" are closely related in
+my experience!
+
+>  Could you explain in more detail the matching rules needed here? I'm trying
+>  to determine if they can be implemented in Janus/Ada without doing great
+>  violence to the existing type mechanisms.
+
+The basic type-checking routine for T1 and T2 checks whether T1 and T2 have
+the same base type, or one of them is a universal type and the other a type
+of the class, etc. In this case, T1 and T2 are two distinct entities: one
+is a limited view which appears as an incomplete type, the other is some
+(partial or full view) of some other type, so they will not type-check.
+We have to recognize that these two entities are actually views of the same
+type, and that is done by means of a link between the two, created when the
+limited views are created. I don't know whether this implementation artifact
+could be used in Janus/Ada, but in our case it falls out of the data structure.
+This link cannot be the same one that relates the two views of a single type,
+but it is needed precisely to exchange limited and non-limited views when
+installing/removing parent units, etc.
+
+***************************************************************
+
+From: Randy Brukardt
+Sent: Tuesday, September 30, 2003  5:39 PM
+
+I see. In our case, an incomplete type is just a view of the completion. Of
+course, there is a link between the two nodes to represent that. (Private
+types are implemented the same way). What we do for private types is
+'ignore' the existence of the link when the full type cannot be used (the
+visible part of a child, for instance). That's a nasty hack, because it
+doesn't scale well (OK, it doesn't scale at all - it only works for sure in
+the innermost nested program unit).
+
+The main reason for the links existing always is so that any stub or spec
+has the same view of the real types as the units that it withs. Otherwise,
+there are code generation issues (you might use the wrong parameter passing
+mechanism, for one example). (Code generation never depends on visibility.)
+
+I don't want to have to walk the type table adding or removing links once
+the context clause is processed, and I'd rather not have to add a new
+mechanism for adding links during context clause processing (that is very
+tricky to do right, even without visibility issues).
+
+Humm. Lots to think about here. Well, thanks for your input.
 
 ***************************************************************
 

Questions? Ask the ACAA Technical Agent