CVS difference for ai05s/ai05-0135-1.txt

Differences between 1.5 and version 1.6
Log of other versions for file ai05s/ai05-0135-1.txt

--- ai05s/ai05-0135-1.txt	2009/03/19 06:39:02	1.5
+++ ai05s/ai05-0135-1.txt	2009/04/30 06:19:47	1.6
@@ -1,19 +1,23 @@
-!standard  4.1.3(12)                                 09-02-11    AI05-0135-1/02
-!standard  8.4(3)
-!standard  8.4(4)
-!standard  8.4(8/2)
+!standard  4.1.3(12)                                 09-04-22    AI05-0135-1/03
+!standard  7.1(2)
+!standard  7.1.3(7)
+!standard  8.4(5/2)
 !standard  8.4(11)
 !standard  8.4(18)
+!standard  8.5.3(3)
+!standard  8.5.3(4)
+!standard  12.3(2/2)
+!standard  12.3(18)
 !class Amendment 09-01-31
 !status work item 09-01-31
 !status received 08-12-17
 !priority Medium
 !difficulty Medium
-!subject An extended-scope use clause
+!subject "Integrated" nested packages
 
 !summary
 
-(See proposal.)
+Add "use package P is ..." to allow integrated packages and package renames.
 
 !problem
 
@@ -36,79 +40,37 @@
 they were declared at the same level as the instantiation
 (as opposed to within it).
 
-A different, but related, problem has to do with a desire to
-make more declarations visible via a use_type clause.
-Given a subtype name (which is often declared in a different
-declarative region than the first named subtype of the type in
-question), an existing "use type S;" clause provides use-visibility
-of the primitive operators of S. It is often the case that more
-is wanted - use-visibility of other primitive subprograms (notably
-enumeration literals) and, in the case of a tagged type, subprograms
-which operate on the corresponding classwide type.
-
-Solving these two problems via two separate mechanisms would introduce
-too much syntactic complexity. These problems need to be solved
-via the addition of a single new construct.
-
 !proposal
+
+A package or package rename which is declared immediately within the
+visible part of an enclosing package may be declared with the optional
+reserved word "use". This indicates that the package is to be
+"integrated" into its parent; this means that clients of the parent
+have the ability to name the constructs declared within the integrated
+package as though they were declared within the enclosing package.
+
+One scenario where this construct may be useful is in declaring a
+package that exports both a private type and a container generic instance
+for that type without requiring that clients deal with nested packages.
+
+This can be accomplished using this new construct as follows:
+
+   with Some_Container_Generic;
+   package Pkg is
+      use package Inner is
+          type T is private;
+      private
+          ...;
+      end Inner;
 
-Define a syntactically new form of use clause by allowing the
-(optional) reserved word "all", as in
+      use package I is new Some_Container_Generic (T); -- exports type Valise
+   end Pkg;
 
-    use all Pkg1, Pkg2;
-or
-    use all type T1, T2;
-
-
-Adding the reserved word "all" gives the use clause the following
-new effects on visibility:
-
-   1) If the use clause occurs in the visible part of a package, then
-      the items that would be made use-visible by a "normal" use_clause
-      are also made visible as if they were declared in the visible part
-      of the given package. A new form of use visibility, "use-visibility
-      by selection", is defined.
-
-      For example,
-
-        declare
-          package Pkg1 is
-            X : Integer := 0;
-          end Pkg1;
-
-          generic
-          package G is
-            Y : Integer := 0;
-          end G;
-
-          package Pkg2 is
-            use all Pkg1; -- makes "Pkg2.X" visible
-
-            package I is new G;
-            use all I; -- makes "Pkg2.Y" visible
-
-            Z1 : Integer := X + Y;
-            package Inner is
-              X, Y : Float;
-              Z2 : Integer := Pkg2.X = Pkg2.Y;
-            end Inner;
-          end Pkg2;
-
-          Ren1 : Integer renames Pkg2.X;
-          Ren2 : Integer renames Pkg2.Y;
-          use Pkg2;
-          Ren3 : Integer renames X;
-          Ren4 : Integer renames Y;
-        begin
-          null;
-        end;
-
-   2) In the case of a use_type_clause, the reserved word "all" causes
-      more subprograms to become use-visible. These include all
-      primitive subprograms of T (not just the primitive operators)
-      and, in the case of a tagged type, the "primitive subprograms"
-      of T'Class (ignoring for purposes of discussion the fact that
-      this notion isn't really defined).
+   with Pkg;
+   package Client is
+      X : Pkg.T;
+      Y : Pkg.Valise;
+   end Client;
 
 !wording
 
@@ -117,52 +79,54 @@
     The selector_name shall resolve to denote a declaration that occurs
     immediately within the declarative region of the package or enclosing
     construct (the declaration shall be visible at the place of the expanded
-    name  see 8.3) [, or to denote a declaration that is use-visible by
-    selection at the point of the selector name (see 8.4)].
+    name  see 8.3) {, or to denote a declaration that is use-visible by
+    selection at the point of the selector_name (see 8.4)}.
     The expanded name denotes that declaration.
+
+Modify 7.1(2) to allow optional "use" syntax:
 
-Modify 8.43-4) to add optional "all" reserved word syntax:
+   package_declaration ::= {use} package_specification;
 
-    use_package_clause ::= use [all] package_name {, package_name};
-    use_type_clause ::= use [all] type subtype_mark {, subtype_mark};
+Add after 7.1.3(7) (i.e. append to the end of the Static Semantics section):
 
-Add to the end of 8.4(8/2):
+   If the optional reserved word "use" is present in a package_declaration,
+   then the package is said to be "integrated" (see 8.4).
 
-    If a use_type_clause includes the reserved word "all", then the
-    following additional declarations are also made potentially
-    use-visible in the same way as is done for the primitive operators of T:
-
-      - The visible primitive subprograms of T;
-      - If T is a tagged type declared immediately within a
-        package_specification, then any visible subprograms that are declared
-        immediately within the same package_specification and
-        operate on T'Class.
-
-Add after 8.4(11) (at the end of the Static Semantics section)
-
-    A use_clause which includes the reserved word "all" and which occurs
-    immediately within the visible part of a package is called a
-    *reexporting* use_clause. The scope of a reexporting use_clause
-    includes the scope of any use_package_clause which names the
-    package immediately enclosing the reexporting use_clause.
-
-    At the point of an expanded_name whose prefix denotes a package P (or
-    a rename thereof) the scope of any reexporting use clause which
-    occurs immediately within the visible part of P includes the
-    selector_name of the expanded name. A declaration with the same
-    identifier as that selector_name which is made
-    potentially use-visible in this way is said to be "use-visible by
-    selection" at the point of the selector_name unless
-       - a visible homograph of the declaration is declared in P; or
+Add after 8.4(5/2) (i.e. append to the end of the Legality Rules section)
+   The declaration of an integrated package or package renaming shall
+   occur immediately within the visible part of an enclosing package
+   or generic package. An integrated package or package renaming shall
+   not be library unit (see 10.1.1). The limited view of an integrated
+   package is not integrated.
+
+Add after 8.4(11) (i.e. append to the end of the Static Semantics section)
+   At any point where an integrated package or package renaming is either
+   potentially use-visible or directly visible, and where an entity declared
+   immediately within the package or renamed package is visible, the entity
+   is potentially use-visible.
+
+   At the point of an expanded_name whose prefix denotes a package P (or
+   a rename thereof) which immediately encloses the visible declaration of
+   an integrated package or package renaming, any visible declaration
+   declared immediately within the integrated package (or, in the
+   case of an integrated package renaming, within the renamed package)
+   is said to be "potentially use-visible by selection" at the point of
+   the selector_name. In addition, if the declaration of an integrated
+   package or package rename is "potentially use-visible by selection"
+   at the point of a selector_name, then so are any visible declarations
+   declared immediately within the package or renamed package.
+   A declaration which is "potentially use-visible by selection"
+   at the point of a selector_name is said to be "use-visible by selection"
+   at that point unless
+       - the defining name of the declaration is not the same as the
+         selector_name
+    or
+       - a visible homograph of the declaration is declared in P
+    or
        - more than one such declaration is potentially use-visible
          by selection at the point of the selector_name and at least
          one of them is not overloadable.
 
-    The above rules notwithstanding, the scope of a
-    reexporting use_clause never includes any portion of the
-    enclosing package visible part up to and including
-    the use_clause itself.
-
 Add after 8.4(18) (in the Examples section)
 
    generic
@@ -175,8 +139,7 @@
    pragma Elaborate (G);
    package Pkg1 is
      type T is null record;
-     package I is new G (T);
-     use all I;
+     use package I is new G (T);
    end Pkg1;
 
    with Pkg1;
@@ -186,164 +149,234 @@
       Y : T := Make;
    end Pkg2;
 
+Modify 8.5.3(3) to allow optional "use" syntax:
 
-!discussion
+   package_renaming_declaration
+     ::= {use} package defining_identifier renames ...
 
-One of the solutions that is currently being discussed for the
-"declare a private type, use it to instantiate a generic, and
-export the instance" problem is the "deferred instance body elaboration"
-proposal.
-
-The original motivation for this "reexporting use_clause" proposal was to
-make the "deferred instance body elaboration" proposal more attractive
-by allowing something like
+Add after 8.5.3(4) (i.e. append to the end of the Static Semantics section):
 
-    with Some_Container_Generic;
-    package Pkg is
-      type T is private;
-      package I is new Some_Container_Generic (T);
-      use all I;
-    private
-       ...
-    end Pkg;
+   If the optional reserved word "use" is present in a
+   package_renaming_declaration, then the package renaming is said to be
+   "integrated" (see 8.4).
 
-    with Pkg;
-    package Client is
-      X : Pkg.Valise; -- the name Pkg.Valise denotes Pkg.I.Valise;
-    end Client;
-
-That is why the example given in the Example section of the
-wording involves an instantiation, albeit one that does not
-involve passing in a non-yet-completed private type as an
-actual parameter.
-
-The use_type_clause-specific part of the proposal is completely
-orthogonal to the rest. One could imagine different syntax for
-this and then having all 4 forms of use_type_clause, as in
-
-    use type T;
-    use all type T;
-    use type T with all of interface; -- or whatever
-    use all type T with all of interface;
-
-, but this seems like overkill. The use_type_clause-specific part
-of this proposal is motivated by a desire to be able to use a
-subtype name to make more than just the primitive operators of the
-type use-visible (e.g., enumeration literals).
+Modify 12.3(2/2) to allow optional "use" syntax:
+   generic_instantiation ::= {use} package defining_program_unit_name is ...
 
-Consider:
+Add after 12.3(18) (i.e. append to the end of the Static Semantics section):
 
-    package Pkg1 is
-      type Enum is (Aa, Bb, Cc);
-      function Foo (X : Enum) return Integer;
-    end Pkg;
+   If the optional reserved word "use" is present in a generic_instantiation,
+   then the package instance is said to be "integrated" (see 8.4).
 
-    with Pkg1;
-    package Pkg2 is
-      subtype S is Pkg1.Enum;
-    end Pkg2;
-
-    with Pkg2; -- no with of Pkg1
-    package Pkg3 is
-      use all type Pkg2.S;
-      X : Integer := Foo (Aa);
-    end Pkg3;
-
-The language has no notion of a use_clause (which is not a declaration)
-being visible or not. The closest thing in the language to visibility
-for a non-declaration is the streaming attribute availability stuff
-for limited types, but that's not applicable to use clauses.
+!discussion
 
-This means that we have to be careful in the wording not to open the door
-for something like
+Just to summarize, adding the reserved word "use" to a package
+or package rename declaration has three main effects:
 
-    package P is
-      X : Integer;
+  1) It is as though an implicit use_clause were added
+     immediately after the package declaration, so that visible
+     declarations in the integrated package's spec become
+     potentially use-visible within the enclosing package.
+
+     This allows:
+       package P is
+          use package Q is
+             X : Integer := 0;
+          end Q;
+          -- use Q;
+          Y : Integer := X;
+       end P;
+
+  2) It is as though an implicit use_clause were added immediately
+     after any use_clause that applies to the enclosing package.
+
+     This allows:
+       package P is
+          use Package Q is
+             X : Integer := 0;
+          end Q;
+       end P;
+
+       with P;
+       use P;
+       -- use P.Q;
+       package R is
+           Y : Integer := X;
+       end R;
+
+  3) It is as though an implicit use_clause were in effect when
+     resolving the selector_name of a selected name whose prefix
+     denotes the enclosing package.
+
+     This allows:
+       package P is
+          use Package Q is
+             X : Integer := 0;
+          end Q;
+       end P;
+
+       with P;
+       package R is
+           Y : Integer := P.
+                          -- use P.Q
+                          X;
+       end R;
+
+Note that this construct is not defined in terms of implicit
+use_clauses. This is just an alternative way to view it for
+expository purposes.
+
+----
+
+#2 above states
+    It is as though an implicit use_clause were added immediately
+    after any use_clause that applies to the enclosing package.
+
+Note that this informal description applies recursively to the implicit
+withs described in #1 - #3.
+
+This allows:
+
+   use System;
+   package P is
+      use Package S_Ren renames System;
+   end P;
+
+   with P;
+   package Q is
+      use package P_Ren renames P;
+   end Q;
+
+   with Q;
+   use Q;
+   package R is
+      A : Address;
+   end R;
+
+----
+
+The usual use_clause name resolution rules apply. In the case of
+the following example
+
+  package P is
+     use Package Q is
+         X, Y : Integer := 0;
+     end Q;
+     X : Float;
+  end P;
 
-      package Q is
-        Y : Integer renames Q.X; -- illegal
-        use all P;
-      end Q;
-    end P;
+, this means that the use adding/deleting the reserved word "use"
+in the declaration of package Q can only make a difference to clients
+when resolving occurrences of the identifier "Y", not "X".
 
-and other more convoluted examples.
+----
 
-That's why the wording includes a "notwithstanding" clause. The visible
-part of Q includes a use all clause which will eventually make the
-declaration of P.X visible via the name Q.X, but this hasn't happened
-yet at the point where the name Q.X is being resolved and the wording
-needs to somehow reflect this.
+If it is decided that integrated package renames are not wanted,
+it would be easy to remove them from the proposal.
 
-A "use all" clause affects name resolution of direct names
-and expanded names.
+----
 
-The legality of
+Consider the following example:
+   package Pkg is
+      type T is ... ;
+      use package Inner is
+         function Is_Brobdingnagian (X : T) return Boolean;
+      end Inner;
+   end Pkg;
 
-    declare
-      package P is
-        X : Integer;
-      end P;
+   with Pkg;
+   package Client is
+      X : Pkg.T := ... ;
+      Y : Boolean := Pkg.Is_Brobdingnagian (X); -- ok
+
+      type D is new Pkg.T;
+      Dx : D := ... ;
+      Dy : Boolean := Is_Brobdingnagian (Dx); -- illegal
+   end Client;
+
+Is this a problem? The function looks a lot like
+a primitive operation of the type, but the fact that
+it isn't really one does show through in some cases.
 
-      package Q is
-        use all P;
-      end Q;
+----
 
-      use Q;
-      Y : Integer renames X;
-    begin null; end;
-
-follows from the rule that the scope of the first use clause
-includes the scope of the second. This illustrates how the
-resolution of a direct name may be affected.
-
-The bulk of the wording deals with the case of an expanded name,
-which is illustrated by the example in the !proposal section.
-
-Note that in resolving an expanded name, we make use of the
-existing definition of "potentially use-visible", but not that
-of "use-visible". The definition of "use-visible" does whatever it
-does in this case, but no language rule depends on the result.
-The notion of "use visibility by selection" is defined
-in terms of the set of declarations that are "potentially use-visible",
-but the set of "use-visible" declarations plays no role here.
-
-Note that the with of a child unit may add a declaration to the
-visible part of the parent unit and thereby hide a declaration
-which otherwise would have been use-visible. For example,
+A limited view of a non-instance non-rename integrated package
+declaration *could* be defined to be integrated, thus allowing
 
-   package Pkg is
-     Child : Integer;
-   end Pkg;
+    package P is
+       use package Q is
+          type T is new Integer;
+       end Q;
+    end P;
 
-   with Pkg;
-   package Parent is
-     use all Pkg;
-   end Parent;
-
-   with Parent;
-   package Client1 is
-     X1 : Integer renames Parent.Child;
-   end Client1;
-
-   package Parent.Child is
-   end Parent.Child;
-
-   with Parent.Child;
-   package Client2 is
-     package X2 renames Parent.Child;
-   end Client2;
-
-This means that one can never refer to the set of visible
-declarations declared in a package spec as though it were
-an immutable set (at least as seen from outside of the package).
-The wording must always be in terms of the set of declarations that
-are visible at some particular point in the program.
-In hindsight this is probably obvious.
+    limited with P;
+    package R is
+       type Ref is access P.T; -- currently illegal
+    end R;
+
+Would this be desirable? It won't work for instances or package renames.
+
+----
+
+Note that when resolving the name P.Q, where P denotes a package,
+declarations with names other than "Q" may be potentially
+use-visible by selection at the point of the selector_name, but
+they will never be use-visible by selection at that point. This is
+necessary because a visible integrated package declared directly
+in P must be potentially use-visible by selection regardless of
+the name of the package.
+
+The following example is therefore legal:
+
+   package P is
+      use package P1 is
+         Aaa : Integer;
+
+         use package Inner is
+            function F return Integer;
+         end Inner;
+      end P1;
 
+      use package P2 is
+         use package Inner is
+            Bbb : Integer;
 
-!example
+            function F return Float;
+         end Inner;
+      end P2;
+   end P;
+
+   with P;
+   package Q is
+      X : Float := P.F;
+   end Q;
+
+At the point of the selector_name, 8 declarations are
+potentially use-visible by selection:
+    P.P1, P.P1.Inner, P.P1.Inner.F, P.P2, P.P2.Inner, P.P2.Inner.F,
+    P.P1.Aaa, and P.P2.Bbb
+but only 2 declarations are use-visible by selection:
+    P.P1.Inner.F and P.P2.Inner.F
+
+Note that this means that the word "such" in "more than one such
+declaration is potentially use-visible" is important.
+
+In this example,
+   package P is
+      use package Q is
+         X, Y : Integer;
+      end Q;
+   end P;
 
-(See other sections.)
+   with P;
+   package R is
+      Z : Integer renames P.X;
+   end R;
+
+both X and Y are potentially use-visible at
+the point of the selector_name, but the word
+"such" implies that only declarations named "X" are
+to be considered. Thus, the example is legal.
 
 --!corrigendum 8.4(3)
 
@@ -3634,4 +3667,316 @@
 
 ****************************************************************
 
+From: Tucker Taft
+Date: Thursday, March 19, 2009  7:48 AM
+
+One of Erhard's major complaints with the "use all" was that it was subject to
+use-clause cancellation with no workaround.  The "use package Foo renames
+X.Bar;" avoids that problem, by providing the name "Foo" as a way to identify
+declarations within X.Bar that might be subject to cancellation.
+
+I don't understand the "use-averse" comment.  The presumption is that if they
+didn't have this capability, the programmer would have to use a derived type or
+a bunch of individual renames to get the names from the other package declared
+directly within the new package.  This merely allows the programmer to do this
+more efficiently and without the cut-and-paste errors that can crop up with a
+sequence of renames. It also avoids introducing the potentially confusing new
+types that a derived type would imply.
+
+Nothing is made directly visible unless the client of the enclosing package
+decides to "use" that package, which of course wouldn't happen if the client
+were use-averse.
+
+****************************************************************
+
+From: Micronian
+Date: Thursday, April 2, 2009  12:38 PM
+
+I read this AI and while it does seem useful to make a package abstraction by
+"combining" other packages, I am concerned about the possibility of people
+inadvertently coding a hierarchy such as below:
+
+package Pkg1 is
+    -- some stuff declared here
+end Pkg1;
+
+
+with Pkg1;
+package Pkg2 is
+    use package Inner renames Pkg1;
+    -- some stuff declared here
+end Pkg2;
+
+
+with Pkg2;
+package Pkg3 is
+    use package Inner renames Pkg2;
+    -- some stuff declared here
+end Pkg3;
+
+
+This would make it confusing for a person to trace down declarations since now
+you have to look through a chain of packages. This is also one of the reasons
+why I dislike working with C code with the transitive nature of the #include
+statements:
+
+header1.h <----header2.h <----header3.h
+
+This linear case is simple, but sometimes there are a few more branches of
+header dependencies further along the hierarchy. It is possible that this new
+extended-scope use clause would invite such coding habits into Ada (e.g. C
+programmers programming Ada in a C like fashion).
+
+Any thoughts?
+
+****************************************************************
+
+From: Randy Brukardt
+Date: Thursday, April 2, 2009  1:44 PM
+
+This has recently been discussed within the ARG. The original "use package"
+proposal only applied to nested packages and to instances, but not renames.
+So the example you give wasn't intended.
+
+It was suggested that it be extended to include package renames for consistency
+reasons. But I think that is essentially the same as the original "use all
+<package>;" proposal, and the reason it was rejected (at least the reason *I*
+rejected it) was because of examples like the one you give here.
+
+"Use all <package>;" has the effect of allowing the author of an abstraction to
+*force* clients to use "use clauses" whether they want to or not. For
+programmers that are use-averse (like me), that's not acceptable.
+
+The non-use-adverse claim that the inclusion of the name in the renames makes
+all the difference, and I admit that it does help a bit - you at least have a
+fully expanded name to use. But the readability problems in other people's code
+remain.
+
+The argument has been made that you can use your fancy IDE to find the
+declaration; but I don't buy that. My "fancy IDE" is an 1980's vintage MS-DOS
+text editor, since it is a better *programming editor* than anything I've ever
+tried on Windows. No IDE capabilities there, and oddly enough, I don't expect an
+update to add any! And, in any case, you have to be able to compile most of a
+program before the fancy IDE can provide any help at all; it is no help on
+snippets of code or partially completed programs.
+
+****************************************************************
+
+From: Micronian
+Date: Thursday, April 2, 2009  2:19 PM
+
+I'm glad to hear that renames were rejected. That helps keep the hierarchy very
+shallow.
+
+Normally when I use a USE clause in my Ada code, I still try to qualify many,
+but not all things with the package names because I dislike looking into code
+that makes it inconvenient to find out at first glance where things came from.
+Like you, I often still use my good ol' super "text" editor (Emacs :) ), but
+there are plenty of cases where the projects I'm on happen to use a nicer IDE
+(e.g. Visual Studio). While these IDE's make code navigation easier, I agree
+that it should not be a requirement to have these tools around.
+
+****************************************************************
+
+From: Dmitry A. Kazakov
+Date: Thursday, April 2, 2009  2:15 PM
+
+> Any thoughts?
+
+I think that the proposal is extremely important for designing reusable
+components. Presently it is impossible to decompose a package declarative part
+into several smaller packages without exposing these parts later to the clients.
+Since their declarations remain outside the "main" package, the user must be
+aware of the relationship between these packages, which is often occasional and
+implementation controlled. This becomes especially painful with instances of
+generic packages within the declarative part. Another extremely important case
+is generic packages themselves. For example:
+
+   generic
+      with package Numbers is new Rational_Numbers (<>);
+   package Rational_Series is
+      use all Numbers;
+      ...
+   end Rational_Series;
+
+It makes no sense to do "use Rational_Series" without "use"-ing its numbers.
+Usually such hierarchies of packages are quite deep, and it is very tedious to
+find all corresponding instances and then "with" and "use" all of them.
+
+In my view transitiveness is exactly what is needed to make design of packages
+use-clause friendly.
+
+****************************************************************
+
+From: Micronian
+Date: Thursday, April 2, 2009  2:33 PM
+
+Don't get me wrong, I still think the feature is useful, but I just don't think
+WITHing one package should automatically include a large deep hiearchy that
+makes it a hassle to navigate through. When I learned Ada, I was happy to see
+that it did not have the transitive nature of C's #includes. But, yes I have
+come into cases like you have said where you split the implementation to keep
+the "main" package smaller, yet increasing the number of WITHs for the user. I
+just think it would be great if the extended-use feature has a good balance.
+
+****************************************************************
+
+From: Randy Brukardt
+Date: Thursday, April 2, 2009  11:06 PM
+
+> I'm glad to hear that renames were rejected. That helps keep the
+> hierarchy very shallow.
+
+Umm, that's my opinion; the full ARG hasn't really considered the issue. I could
+imagine it going either way, because this is a "deep pit" issue (as Tucker once
+described it). We're already in a deep pit (in this case, because of inheritance
+-- it's pretty much necessary to have a tool to figure out where things are
+declared when doing OOP, because nothing interesting appears in the source), and
+it is not clear whether there is any reason to avoid going all the way to the
+bottom.
+
+I know where *I* stand on this one, and it is good to know that others think
+like me. But whether that will be enough to defeat the forces of "consistency"
+remains to be seen.
+
+****************************************************************
+
+From: Randy Brukardt
+Date: Thursday, April 23, 2009  12:22 AM
+
+Now for the technical comments:
+
+You have:
+
+Add after 8.4(11) (i.e. append to the end of the Static Semantics section)
+   At any point where an integrated package or package renaming is either
+   potentially use-visible or directly visible, and where an entity declared
+   immediately within the package or renamed package is visible, the entity
+   is potentially use-visible.
+
+This wording is very different than the existing wording for potentially
+use-visible (which talks about "scope enclosing a place" and "each
+declaration that occurs immediately within the declaration region of the
+package"). And we always try to avoid stuff like "at any point". You seem
+to have "solved" that by putting it as far away as possible from 8.4(8).
+But I think all of reasons for a declaration being "potentially use-visible"
+should go together; this paragraph should go right after 8.4(8) (it's not
+really related to "potentially use-visible by selection", which can go later).
+
+----
+
+The main reason I was reading the above was that I was trying to figure out
+what happens when the same declaration is use-visible (and use-visible by
+selection) by multiple paths. This is where the equivalence you give at the
+beginning of the discussion breaks down (or something is getting very
+complicated). Consider the following:
+
+    package P1 is
+       C : constant Boolean := True;
+    end P1;
+
+    with P1;
+    package P2 is
+       use package P3 renames P1;
+    end P2;
+
+    with P1, P2; use P1, P2;
+    procedure M1 is
+    begin
+       if C then -- OK?
+           ...
+       end if;
+    end M1;
+
+One would like this to be legal, by analogy with a regular use clause.
+But use-by-selection starts getting messy:
+
+    with P1;
+    package P4 is
+        use package P1 renames Standard.P1;
+    end P4;
+
+    with P1, P4; use P1, P4;
+    procedure M2 is
+    begin
+       if P1.C then -- (1)
+            ...
+       end if;
+    end M2;
+
+Is (1) OK? I suppose it is because the prefix P1 is directly visible,
+which hides the use-visible P4.P1.
+
+But then try:
+
+    with P1;
+    package P5 is
+        use package P1 renames Standard.P1;
+    end P5;
+
+    with P4, P5; use P4, P5;
+    procedure M3 is
+    begin
+       if P1.C then -- (2)
+            ...
+       end if;
+    end M3;
+
+Both P4.P1.C and P5.P1.C denote the same declaration, so one would expect
+this to work. (That is how I read the proposed wording.) But it isn't clear
+to me at all how that gets worked out from the non-overloadable prefixes.
+(Currently, there can only be one interpretation of a non-overloadable name,
+but here it seems that we have two.)
+
+One could argue that we don't need this complication, and declare (2) to be
+ambiguous. But then you would risk eliminating declarations that don't
+conflict with anything and that we need to see.
+
+    package P6 is
+       V : Integer := 0;
+    end P6;
+
+    with P6;
+    package P7 is
+        use package P1 renames Standard.P6;
+    end P7;
+
+    with P4, P7; use P4, P7;
+    procedure M4 is
+    begin
+       if P1.C then -- (3)
+            ...
+       end if;
+    end M4;
+
+One would hope there is no ambiguity here (in (3)), as there is only one
+C in the program. Again, this is what the wording appears to say.
+
+So it looks like *everything* is overloadable in a practical sense (the
+compiler will have to treat every prefix that way at least). At which point
+I wonder what the advantage of continuing to even have non-overloadable
+declarations will be, since they'll no longer provide any benefit in
+resolution or error correction.
+
+Unfortunately, this last case can happen with instances and nested packages
+as well as package renames (obviously, the declarations can't be same unless
+a rename is involved). I admit that I was trying to find cases where "integrated"
+renames caused semantic problems, but it appears that instead I've found that
+this whole idea is going to cause significant implementation problems (at
+least for any implementation that takes any advantage of knowing that a name
+is non-overloadable).
+
+This is going to happen a lot in practice, because there is no good name for
+typical nested packages (especially as there is no real intent to use them
+via that name). So I expect a lot of use of the same names (much like the
+style of calling all object-oriented types "Object" and using the package
+name as the "real" name). That's going to lead to this sort of conflict.
+
+So it appears that my objection to the renames case has now spread to the
+entire idea. Besides making it pretty much impossible to find the declaration
+of something without a fancy tool (which of course doesn't work if the code
+isn't compilable), it also will substantially complicate implementation. So,
+if this is the proposal that is going forward, I'm opposed.
+
+****************************************************************
 

Questions? Ask the ACAA Technical Agent