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

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

--- ai05s/ai05-0135-1.txt	2009/04/30 06:19:47	1.6
+++ ai05s/ai05-0135-1.txt	2009/05/26 23:46:24	1.7
@@ -1,4 +1,4 @@
-!standard  4.1.3(12)                                 09-04-22    AI05-0135-1/03
+!standard  4.1.3(12)                                 09-05-26    AI05-0135-1/04
 !standard  7.1(2)
 !standard  7.1.3(7)
 !standard  8.4(5/2)
@@ -40,6 +40,43 @@
 they were declared at the same level as the instantiation
 (as opposed to within it).
 
+Consider a package which needs to export both a private type and an
+instance of one of the container generics for that type.
+
+Currently, this requires something like
+
+   package Pkg is
+      package Inner is
+         type T is private;
+      private
+         ...
+      end Inner;
+
+      package I is new Some_Container_Generic (Inner.T);
+   end Pkg;
+
+What is wanted here is a way to make all of the declarations visible
+in Pkg.Inner (and perhaps Pkg.I; that's less clear) visible as if
+they were declared immediately within Pkg.
+This special case of the problem alone has been viewed as being
+sufficiently important to merit considering major changes in the
+language (see the 4 alternative versions of AI05-0074).
+
+An unwanted nested package may also be introduced when a user wishes to
+declare a non-primitive operation for a tagged type, as in
+
+   package Pkg is
+      type T is tagged ... ;
+
+      package Inner is
+         function Not_Primitive (X : T) return T;
+      end Inner;
+   end Pkg;
+
+As in the previous example, what is wanted here is a way to make all of the
+declarations visible in Pkg.Inner visible as if they were declared immediately
+within Pkg.
+
 !proposal
 
 A package or package rename which is declared immediately within the
@@ -274,8 +311,99 @@
 If it is decided that integrated package renames are not wanted,
 it would be easy to remove them from the proposal.
 
+    As Erhard has pointed out, there are good reasons to consider this
+    option. It is certainly possible to use integrated package renames
+    to write code that is very difficult to read; this was already true
+    of Ada83 use clauses, but integrated package renames seem to offer
+    substantially greater potential for confusion.
+
+    Integrated package renames also make possible a number of odd corner cases:
+
+      limited with Foo;
+      package P is
+        use package Bar renames Foo;
+      end P;
+
+      package Outer is
+        package Inner is
+           use package Outer_Rename renames Outer;
+        end Inner;
+      end Outer;
+
+    Finally, integrated package renames are not needed to solve any of
+    the problems that provided the original motivation for introducing
+    integrated packages.
+
+    The wording changes need to delete integrated package renames from this AI
+    would be straightforward. This would include:
+       - eliminating the wording changes in 8.5.3
+       - replacing "integrated package or package renaming" with
+         "integrated package" throughout
+       - eliminating references to integrated package renamings
+         in the change appended after 8.4(11)
+
 ----
 
+    Tuck suggests that the name of an integrated package rename
+    should not itself become "use"-visible when the enclosing package is "use"d.
+
+    Consider the following example (supplied by Tuck):
+         Text_IO, Sequential_IO, and Direct_IO each include
+         renames of each exception declared in the package IO_Exceptions.
+         It is a no-brainer to replace those renames with a:
+           "use package <something> renames Ada.IO_Exceptions;"
+         in Text_IO, Sequential_IO, and Direct_IO.
+
+         However, what should the <something> be?  Well, most natural would be:
+           "use package IO_Exceptions renames Ada.IO_Exceptions;"
+
+         but now suppose you have:
+
+            with Ada.IO_Exceptions;
+            with Ada.Text_IO;
+        use Ada;
+        procedure What_Fun is
+           use Text_IO;
+             -- oops, IO_Exceptions suddenly disappears
+        begin
+            ...
+        exception
+            when IO_Exceptions.Name_Error =>
+                -- oops, this doesn't compile any more!
+        end What_Fun;
+
+    If it is decided that this is what we want, then corresponding
+    wording would probably be fairly straightforward (as long as
+    we don't also require elegance, in which case the problem
+    may be overconstrained).
+
+    As an aside, note that the above example would be allowed if
+    "IO_Exceptions.Name_Error" were replaced with "Name_Error".
+
+    Another solution would be to allow anonymous integrated package
+    renames, as in
+       use package <> renames Ada.Io_Exceptions;
+    This would be equivalent to
+       use package Some_Identifier_That_Occurs_Nowhere_Else_In_The_Program
+         renames Ada.Io_Exceptions;
+    Anonymous non-renames seem like a bad idea, but perhaps anonymous
+    integrated renames would be ok?
+
+    A third approach to this problem would be to add a name
+    resolution preference rule: if a package rename has the
+    same simple name as the renamed entity (which might or
+    might not itself be a rename), then prefer the renamed (and
+    similarly through chains of renames as long as the simple name
+    remains unchanged).
+    This would not introduce the sort of Beaujolais effects that
+    are typically associated with preference rules, but it does
+    seem that treating a simple-name-preserving rename differently
+    than a simple-name-nonpreserving rename might have some
+    peculiar consequences (e.g., there might be some odd interactions
+    with formal packages). This is probably a bad idea.
+
+----
+
 Consider the following example:
    package Pkg is
       type T is ... ;
@@ -3977,6 +4105,763 @@
 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.
+
+****************************************************************
+
+From: Steve Baird
+Date: Thursday, April 23, 2009  10:37 AM
+
+> ...  this paragraph should go right after 8.4(8) (it's not really 
+> related to "potentially use-visible by selection", which can go 
+> later).
+> 
+
+Good point.
+
+> ----
+> 
+> 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. 
+
+And we agree that it is legal, right?
+
+> 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.
+> 
+
+Right.
+
+> 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.)
+> 
+
+This is ambiguous because the prefix of the name P1.C is ambiguous.
+I believe the wording I suggested captures this correctly, and that this is consistent
+with the informal implicitly-inserted-use_clauses model.
+
+It is similar to the following situation in the current language:
+
+   declare
+      package P1 is
+          X : Integer := 0;
+      end P1;
+
+      package P2 is
+          package P1_Ren renames P1;
+      end P2;
+
+      package P3 is
+          package P1_Ren renames P1;
+      end P3;
+
+      use P2, P3;
+
+      Y : Integer := P1_Ren.X; -- illegal
+
+> 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.
+>
+
+No, I believe the prefix of the name "P1.C" is ambiguous and that this example should be
+rejected. Certainly that was my intent and I believe the suggested wording captures that.
+
+> 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.
+
+I don't think so. I think the bad consequences you describe are based on a misunderstanding.
+Support for ambiguous prefixes was certainly not intended. I believe the suggested wording
+captures that intent, but if it doesn't then the wording needs to be corrected.
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Thursday, May 21, 2009  5:27 AM
+
+I had a couple of "waking up" thoughts, as Jimmy Carter used to call them:
+
+[Editor's note: The other thought pertains to AI05-0142-2 and is filed in that AI.]
+
+  2) I had a perfect example of why the name of an "integrated" package
+      should not become "use" visible when the enclosing package
+      is "use"d, and a good example of why integrated package renames
+      are useful:  Text_IO, Sequential_IO, and Direct_IO each include
+      renames of each exception declared in the package IO_Exceptions.
+      It is a no-brainer to replace those renames with a:
+        "use package <something> renames Ada.IO_Exceptions;"
+      in Text_IO, Sequential_IO, and Direct_IO.
+
+      However, what should the <something> be?  Well, most natural would be:
+        "use package IO_Exceptions renames Ada.IO_Exceptions;"
+
+      but now suppose you have:
+
+         with Ada.IO_Exceptions;
+         with Ada.Text_IO;
+         use Ada;
+         procedure What_Fun is
+            use Text_IO;
+              -- oops, IO_Exceptions suddenly disappears
+         begin
+             ...
+         exception
+             when IO_Exceptions.Name_Error =>
+                 -- oops, this doesn't compile any more!
+
+         end What_Fun;
+
+      There is always a compatibility problem whenever we consider
+      adding another identifier to an existing package.  But the
+      problem is always about "use" visibility of that new identifier.
+      We don't worry about there being another identifier available
+      for "selective" visibility, because no existing program would
+      have a reference to the newly added identifier as a component
+      of the existing package.
+
+      I really think this integrated package concept will be a
+      useful way to implement packages, allowing after-the-fact
+      reusability of parts of packages, but every time I think
+      about it, I end up worrying what the heck I am going to use for
+      the names of those integrated packages.  We considered allowing "<>"
+      for the name of the integrated package, but Erhard seems to have
+      convinced us that you need them for resolving ambiguities.  Just
+      making integrated package names *not* themselves use-visible provides
+      an elegant solution and ensures upward compatibility when you
+      decide to (re)implement part of the functionality of an existing
+      package by using one.
+
+      By the way, a *nice* feature of implementing the sequence of
+      renames of exceptions via "use package blah renames Ada.IO_Exceptions"
+      is that the exception names would presumably *not* cancel each other
+      out if you use'd two different instantiations of, say, Direct_IO.
+      But I suppose that depends on the details of the wording for
+      how the contents of an integrated package rename (presuming we
+      support them) become visible...  Steve?
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Friday, May 22, 2009  12:45 PM
+
+...
+>       There is always a compatibility problem whenever we consider
+>       adding another identifier to an existing package.  But the
+>       problem is always about "use" visibility of that new identifier.
+>       We don't worry about there being another identifier available
+>       for "selective" visibility, because no existing program would
+>       have a reference to the newly added identifier as a component
+>       of the existing package.
+
+Client use clauses are always a problem. They ought to be used very sparingly.
+
+>       I really think this integrated package concept will be a
+>       useful way to implement packages, allowing after-the-fact
+>       reusability of parts of packages, but every time I think
+>       about it, I end up worrying what the heck I am going to use for
+>       the names of those integrated packages.  We considered allowing "<>"
+>       for the name of the integrated package, but Erhard seems to have
+>       convinced us that you need them for resolving ambiguities.
+
+You also need a name for limited with, which does not allow any use clauses. That has
+to be true for these "integrated" packages as well. (You could easily get the same sorts
+of anomolies.)
+
+>       Just making integrated package names *not* themselves use-visible provides
+>       an elegant solution and ensures upward compatibility when you
+>       decide to (re)implement part of the functionality of an existing
+>       package by using one.
+
+Banning client use clauses would work, too. ;-)
+
+>       By the way, a *nice* feature of implementing the sequence of
+>       renames of exceptions via "use package blah renames Ada.IO_Exceptions"
+>       is that the exception names would presumably *not* cancel each other
+>       out if you use'd two different instantiations of, say, Direct_IO.
+>       But I suppose that depends on the details of the wording for
+>       how the contents of an integrated package rename (presuming we
+>       support them) become visible...  Steve?
+
+I made an argument like this once (in terms of implementation difficulty) and Steve
+convinced me that there is none because we're not allowing anything new. This sounds new,
+since we get such conflicts from renames with client use clauses:
+
+    package P is
+        Obj : Natural;
+    end P;
+
+    with P;
+    package Q is
+        package Inner renames P;
+    end Q;
+
+    with P;
+    package R is
+        package Inner renames P;
+    end R;
+
+    with Q, R;
+    procedure Test is
+       use Q.Inner, R.Inner;
+    begin
+       Obj := 10; -- Not use-visible due to collision.
+    end Test;
+
+I don't see why we would want "integrated packages" to work differently, that would make
+a lot of additional work and would add confusion to users (which kind of use clause works how??).
+
+****************************************************************
+
+From: Steve Baird
+Sent: Friday, May 22, 2009  4:04 PM
+
+...
+>      However, what should the <something> be?  Well, most natural would be:
+>        "use package IO_Exceptions renames Ada.IO_Exceptions;"
+> 
+>      but now suppose you have:
+> 
+>         with Ada.IO_Exceptions;
+>         with Ada.Text_IO;
+>         use Ada;
+>         procedure What_Fun is
+>            use Text_IO;
+>              -- oops, IO_Exceptions suddenly disappears
+>         begin
+>             ...
+>         exception
+>             when IO_Exceptions.Name_Error =>
+>                 -- oops, this doesn't compile any more!
+> 
+>         end What_Fun;
+> 
+
+Good point. I'll certainly include this example in the AI.
+
+>      By the way, a *nice* feature of implementing the sequence of
+>      renames of exceptions via "use package blah renames Ada.IO_Exceptions"
+>      is that the exception names would presumably *not* cancel each other
+>      out if you use'd two different instantiations of, say, Direct_IO.
+>      But I suppose that depends on the details of the wording for
+>      how the contents of an integrated package rename (presuming we
+>      support them) become visible...  Steve?
+> 
+
+Right.
+The compilation error you mentioned above can be fixed by replacing
+   when Io_Exceptions.Name_Error =>
+with
+   when Name_Error =>
+.
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Friday, May 22, 2009  4:18 PM
+
+> Right.
+
+Can you be a bit more specific?  Randy seemed to think you had said something
+else.  My presumption is that if we support integrated renames, "use"ing the
+package enclosing the integrated rename as well as "use"ing the renamed inner
+package itself will not cause cancellation, any more than it would if you do a
+"use" of two different renames of the same package.
+
+****************************************************************
+
+From: Steve Baird
+Sent: Friday, May 22, 2009  5:22 PM
+
+I agree with your interpretation.
+
+One way to verify this is a two-step process
+    1) Check the informal definition of how integrated packages work
+       at the beginning of the !discussion section to see if it
+       yields the desired behavior.
+    2) Check the wording to see if it correctly captures the
+       informal definition.
+
+We are looking at something like
+
+    with Ada.Io_Exceptions;
+    package P1 is
+        use package Io_Exceptions renames Ada.Io_Exceptions;
+    end P1;
+
+    with Ada.Io_Exceptions;
+    package P2 is
+        use package Io_Exceptions renames Ada.Io_Exceptions;
+    end P2;
+
+    with P1, P2;
+    use P1, P2;
+    procedure Foo is
+    begin
+       ...
+    exception
+       when Name_Error => ... ;
+    end Foo;
+
+By informal equivalence #2, "use P1" is equivalent to "use P1; use P1.Io_Exceptions".
+Ditto for "use P2".
+
+It has been well established since Ada83 that it makes no difference whether a
+use clause names a package or a rename of that package. It is similarly
+well established that being within the scope of two uses clauses of a given
+package is no different than being within the scope of one.
+Let me know if you would like a more detailed justification for thoee assertions,
+but this is stuff that hasn't changed in years.
+
+Taken together, this means that the use of Name_Error occurs in a use-clause state
+that is equivalent to being in the scope of a use clause that denotes Ada.Io_Exceptions.
+
+Thus, the use of the simple name Name_Error is legal.
+
+The AI wording that corresponds to equivalence #2 is
+   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.
+
+Note that homographs can be simultaneously potentially use-visible.
+The fact that they are homographs doesn't matter until we come to the question of
+whether they are use-visible (as opposed to potentially use-visible).
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Friday, May 22, 2009  2:12 PM
+
+>     with Q, R;
+>     procedure Test is
+>        use Q.Inner, R.Inner;
+>     begin
+>        Obj := 10; -- Not use-visible due to collision.
+
+Huh?  I don't believe that.  Are you sure?
+Our front end has no problem compiling this example.
+
+>     end Test;
+> 
+> I don't see why we would want "integrated packages" to work 
+> differently, that would make a lot of additional work and would add 
+> confusion to users (which kind of use clause works how??).
+
+I agree that integrated renames should work like regular renames from this point
+of view, and my claim is that the above "use" clauses do *not* cause cancellation,
+because they are "using" the *same* package (through two different renamings).
+
+If you look in RM 8.4, it talks about *packages* denoted by the name appearing
+in the "use" clause (as opposed to "package declarations).  A package *rename*
+does not create a distinct package, though of course it is a distinct declaration.
+In general when talking about entities (as opposed to declarations), renames are
+irrelevant.  No matter how many different renames are involved, there is only
+one entity involved, and the two "use" clauses in your example denote the *same*
+package entity.  So that is why I wanted integrated packages to work the same way.
+
+Steve, do you disagree?
+
+****************************************************************
+
+From: Steve Baird
+Sent: Friday, May 22, 2009  5:44 PM
+
+I agree, both with respect to the existing language and with respect to integrated
+packages.
+
+****************************************************************
+
+From: Steve Baird
+Sent: Friday, May 22, 2009  4:56 PM
+
+> I made an argument like this once (in terms of implementation 
+> difficulty) and Steve convinced me that there is none because we're 
+> not allowing anything new. This sounds new, since we get such 
+> conflicts from renames with client use clauses:
+> 
+>     package P is
+>         Obj : Natural;
+>     end P;
+> 
+>     with P;
+>     package Q is
+>         package Inner renames P;
+>     end Q;
+> 
+>     with P;
+>     package R is
+>         package Inner renames P;
+>     end R;
+> 
+>     with Q, R;
+>     procedure Test is
+>        use Q.Inner, R.Inner;
+>     begin
+>        Obj := 10; -- Not use-visible due to collision.
+>     end Test;
+
+I'm not sure what you are talking about here.
+This example is legal Ada.
+If you rewrote it with integrated package renames in what seems to me like
+the obvious way, it would still be legal.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Friday, May 22, 2009  5:29 PM
+
+Without Tucker's explanation, I would have no idea what you are talking about. Even
+with Tucker's explanation, I find the idea that this is supposed to work highly
+distrubing. I don't buy the notion that Q.Inner.Obj and R.Inner.Obj are the same entity
+for resolution proposes; you're essentially claiming that the full name of Obj in this
+example would be P.Obj, even though that name isn't even visible in this context. I
+suppose the counter-argument is that it doesn't matter to the Ada program (but it makes
+writing tools - especially a use-clause remover - much more difficult).
+
+What you guys are telling me is that the features which I detest so much about *this*
+proposal and its interaction with renames (to the point that I've been trying to keep
+this particular combination out of "integrated packages") is in fact already a part of Ada.
+
+Indeed, this entire area makes me so uncomfortable that at this point I cannot in good
+conscience support any expansion of use-visibility. (I'd rather see pragma
+Restrictions(No_Package_Use); added to the language...) Thus "integrated packages" are
+a dead idea in my mind, and I'm not going to spend any more of my time (other than
+administratively, of course) on it.
+
+P.S. The only acceptable way IMHO to deal with these interactions is to outright ban
+the use of 'package use' on packages that contains "integrated packages". But that seems
+like a weird restriction, even to me.
+
+P.P.S. Besides this issue, I've also soured on this version of "integrated packages"
+because they re-emerge annoyingly: you have to use the nested package name when you are
+using limited withs; you have to use the nested package name to work around naming
+conflicts; and I think there was another case where you had to use the "real" name (which
+I've forgotten the details of). This really doesn't have the effect of "integrating" the
+package (treating it as being non-nested for almost all purposes) as we really wanted.
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Friday, May 22, 2009  9:27 PM
+
+This is not very radical.  In fact, when it doesn't work it is more surprising.
+Use-clause cancellation is generally a pain, and we should minimize unnecessary
+cancellation.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Friday, May 22, 2009  10:57 PM
+
+Ada is a name-equivalence language, and Q.Inner.Obj and R.Inner.Obj are not name equivalent;
+therefore they're not the same. They *ought* to use-clause cancel. I realize that I'm going
+against Ichbiah on this one, but I really don't want to see any expansion of what I see as
+a major error in the language definition. I really dislike using renames in this way in any
+case (the only reason to use a renames of a package is to provide a shorter name when you
+are *not* using use clauses; a use clause of such a package is clearly a hack and very bad
+style).
+
+Also note that I think that we have usage problems with this proposal anyway - above and beyond
+this particular concern. These nested packages are going to pop up at inopportune times;
+they are not really going to "feel" integrated. I'd really rather have a mechanism where the
+names really are part of the root package. (I realize that we sort of tried that initially
+and had some problems with collisions; I'm thinking now that such names should simply be
+illegal (rather than some sort of hiding)). But I've got so many other proposals to work on
+- ones that appear to work out - that spending more time on this one just doesn't make sense.
+
+P.S. This is all your fault. :-) I have such strong regrets about ignoring my gut feelings
+in favor of "rationality" and letting you put the "coextension" abomination into the
+language, that I've vowed to take stronger stands against things that "feel" wrong. This
+appears to be the first real test...
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Friday, May 22, 2009  11:28 PM
+
+I should also say that if this is the way things are intended to work, it is extremely
+irregular in that it only works for packages. It greatly rubs me the wrong way that you
+would get different results for:
+
+   with Ada.IO_Exceptions;
+   package Ada.Text_IO is
+       Name_Error : renames Ada.IO_Exceptions.Name_Error;
+   end Ada.Text_IO;
+
+   with Ada.IO_Exceptions;
+   package Ada.Stream_IO is
+       Name_Error : renames Ada.IO_Exceptions.Name_Error;
+   end Ada.Stream_IO;
+
+   with Ada.Text_IO, Ada.Stream_IO;
+   use  Ada.Text_IO, Ada.Stream_IO; -- This is pretty much the only time I'd use one of these...
+   procedure Test is
+       null;
+   exception
+      when Name_Error => null; -- Illegal, use-clause cancelation
+   end;
+
+versus
+
+   with Ada.IO_Exceptions;
+   package Ada.Text_IO is
+       use package IO_Exceptions renames Ada.IO_Exceptions;
+   end Ada.Text_IO;
+
+   with Ada.IO_Exceptions;
+   package Ada.Stream_IO is
+       use package IO_Exceptions renames Ada.IO_Exceptions;
+   end Ada.Stream_IO;
+
+   with Ada.Text_IO, Ada.Stream_IO;
+   use  Ada.Text_IO, Ada.Stream_IO; -- This is pretty much the only time I'd use one of these...
+   procedure Test is
+       null;
+   exception
+      when Name_Error => null; -- Supposedly OK.
+   end;
+
+I want "integrated packages" to work exactly as if the declarations are in the outer package,
+and this difference is aggravating.
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Saturday, May 23, 2009  10:29 AM
+
+It doesn't work differently for package *names*, but it works for the contents of a package
+if it is "use"d via two different renames.  Ada is not a "name equivalent" language in the
+sense you imply.  It is "name equivalent" only if there are no renamings in the name, and you
+start from "Standard".
+
+Even "full conformance" allows matching of two different "expanded names" so long as they
+denote the "same" declaration (see 6.3.1(21.a-f) for an explicit discussion of this).
+
+Renaming a package doesn't create
+a new package, nor a new set of declarations for the components of the package.
+It only creates a new "package renaming declaration,"
+and (somewhat annoyingly) these package *renamings* will cancel each other out in a case like:
+
+     with R;
+     package P is
+        package S renames R.S;
+        ...
+     end P;
+
+     with R;
+     package Q is
+        package S renames R.S;
+        ...
+     end Q;
+
+     with P, Q;
+     procedure Test is
+        use P, Q; -- "S" is canceled out here;
+                  -- packages are *not* a special case
+
+        use P.S, Q.S;  -- But no cancellation occurs here.
+                       -- because P.S and Q.S denote
+                       -- the *same* package.
+
+Package renamings would not work if they created a new set of declarations of the components
+of the package. We clearly want P.S.T and Q.S.T to denote the same declaration.  If for example,
+T is a type declaration, P.S.T and Q.S.T are the same type.
+
+****************************************************************
+
+From: Edmond Schonberg
+Sent: Saturday, May 23, 2009  12:38 PM
+
+>  with Ada.IO_Exceptions;
+>   package Ada.Text_IO is
+>       use package IO_Exceptions renames Ada.IO_Exceptions;
+>   end Ada.Text_IO;
+>
+>   with Ada.IO_Exceptions;
+>   package Ada.Stream_IO is
+>       use package IO_Exceptions renames Ada.IO_Exceptions;
+>   end Ada.Stream_IO;
+>
+>   with Ada.Text_IO, Ada.Stream_IO;
+>   use  Ada.Text_IO, Ada.Stream_IO; -- This is pretty much the only time I'd use one of these...
+>   procedure Test is
+>       null;
+>   exception
+>      when Name_Error => null; -- Supposedly OK.
+>   end;
+>
+> I want "integrated packages" to work exactly as if the declarations 
+> are in the outer package, and this difference is aggravating.
+
+But as Steve points out, this has always been legal with regular use- clauses on renamings.
+My understanding is that use clauses look through the renaming, and redundant use clauses are
+noops. If instead of "integrated packages" you write:
+
+  with Ada.Text_IO, Ada.Stream_IO;
+   use  Ada.Text_IO, Ada.Stream_IO; -- This is the only time I'd use one of these ...
+   procedure Test is
+    use Ada.Text_IO.IO_Exceptions;
+    use Ada.Stream_IO.IO_Exceptions;
+   begin
+       null;
+   exception
+      when Name_Error => null; -- Supposedly OK.
+   end;
+
+this has been legal for some 14 years.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Tuesday, May 26, 2009  6:38 PM
+
+> It doesn't work differently for package *names*, but it works for the 
+> contents of a package if it is "use"d via two different renames.  Ada 
+> is not a "name equivalent" language in the sense you imply.  It is 
+> "name equivalent" only if there are no renamings in the name, and you 
+> start from "Standard".
+
+Sorry, but this last sentence is clearly False. And that is what I'm objecting
+to. If you had said:
+
+It is "name equivalent" only if there are no renamings {of packages} in the name,
+and you start from "Standard".
+
+then you would have made a True statement. But why should packages get this special
+treatment, and not renames of exceptions, or generics, or subprograms, etc.? We have
+"Ada is a name equivalence language unless the name is a renaming of a package".
+
+...
+>      with P, Q;
+>      procedure Test is
+>         use P, Q; -- "S" is canceled out here;
+>                   -- packages are *not* a special case
+> 
+>         use P.S, Q.S;  -- But no cancellation occurs here.
+>                        -- because P.S and Q.S denote
+>                        -- the *same* package.
+> 
+> Package renamings would not work if they created a new set of 
+> declarations of the components of the package.
+> We clearly want P.S.T and Q.S.T to denote the same declaration.  If 
+> for example, T is a type declaration, P.S.T and Q.S.T are the same 
+> type.
+
+I can't think of any legitimate reason to write a use clause of a renamed package in
+Ada 95 or 2005, so why do we care what happens here? In particular, why should it work
+differently than all other renames?
+
+Surely the packages could be different while still denoting the same underlying entities:
+that certainly works for renaming of other entities, such as exceptions.
+
+Nobody has made any effort to address (or even acknowledge) my other concerns. I'll put
+them on the main ARG list for further discussion.
+
+****************************************************************
+
+From: Steve Baird
+Sent: Tuesday, May 26, 2009  1:27 PM
+
+Here are the updates to the AI that were discussed during the 5/20 call.
+[This is version /04 of the AI - Editor.]
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Tuesday, May 26, 2009  6:38 PM
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Tuesday, May 26, 2009  6:38 PM
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Tuesday, May 26, 2009  6:38 PM
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Tuesday, May 26, 2009  6:38 PM
 
 ****************************************************************
 

Questions? Ask the ACAA Technical Agent