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

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

--- ai05s/ai05-0135-1.txt	2009/11/04 06:26:38	1.10
+++ ai05s/ai05-0135-1.txt	2010/01/16 03:27:55	1.11
@@ -1,11 +1,15 @@
-!standard  4.1.3(12)                                 09-05-27    AI05-0135-1/05
+!standard  4.1.3(12)                                 10-01-15    AI05-0135-1/07
 !standard  7.1(2)
-!standard  7.1.3(7)
+!standard  7.1(3)
+!standard  7.1(4)
+!standard  7.1(5/2)
+!standard  7.1(7)
+!standard  8.3(25)
 !standard  8.4(5/2)
-!standard  8.4(11)
-!standard  8.4(18)
+!standard  8.4(16)
 !standard  8.5.3(3)
 !standard  8.5.3(4)
+!standard  10.1.1(12.2/3)
 !standard  12.3(2/2)
 !standard  12.3(18)
 !class Amendment 09-01-31
@@ -17,7 +21,7 @@
 
 !summary
 
-Add "use package P is ..." to allow integrated packages and package renames.
+Add "package <P> is ..." to allow integrated packages and package renames.
 
 !problem
 
@@ -80,34 +84,37 @@
 !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.
+visible part of an enclosing package may be declared with angle brackets
+enclosing the first occurence of the package identifier. 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;
+  with Some_Container_Generic;
+  package Pkg is
+    package <Inner> is
+      type T is private;
+    private
+       ...;
+    end Inner;
 
-      use package I is new Some_Container_Generic (T); -- exports type Valise
-   end Pkg;
+    package <I> is new Some_Container_Generic (T);  -- exports type Valise
+  end Pkg;
 
-   with Pkg;
-   package Client is
-      X : Pkg.T;
-      Y : Pkg.Valise;
-   end Client;
+  with Pkg;
+  package Client is
+    X : Pkg.T;
+    Y : Pkg.Valise;
+    use Pkg;
+    Xx : T;
+    Yy : Valise;
+  end Client;
 
 !wording
 
@@ -120,23 +127,85 @@
     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:
+Replace 7.1(3) to allow optional "< package_id >" syntax
 
-   package_declaration ::= {use} package_specification;
+   integrated_package_identification ::= < defining_identifier >
 
-Add after 7.1.3(7) (i.e. append to the end of the Static Semantics section):
+   package_identification :=
+     defining_program_unit_name | integrated_package_identification
 
-   If the optional reserved word "use" is present in a package_declaration,
-   then the package is said to be "integrated" (see 8.4).
+   package_specification ::=
+     package package_identification is
+        {basic_declarative_item}
+     [private
+        {basic_declarative_item}]
+     end [[parent_unit_name] . identifier ]
+
+Modify 7.1(4):
+
+    If an identifier or parent_unit_name.identifier appears at
+    the end of a package_specification, then this sequence of
+    lexical elements shall repeat the defining_program_unit_name
+    {or, in the case of an integrated_package_identification, the
+    defining_identifier}.
+
+Add after 7.1(5/2):
+
+    If a package's package_identification consists of an
+    integrated_package_identification, then the package is said to
+    be *integrated* (see 8.4). The declaration of an integrated
+    package or package renaming (see 8.5.3) shall occur immediately
+    within the visible part of an enclosing package or generic
+    package. The package_identification of a
+    generic_package_declaration shall not consist of an
+    integrated_package_identification. The package_identification of
+    a package_declaration of a library_unit_declaration (or of a
+    package_renaming_declaration of a
+    library_unit_renaming_declaration) shall not consist of
+    an integrated_package_identification.
+
+[We could have moved the legality rules after the static semantic
+rules and put the definition of "integrated package" into the
+static semantic section. But that would necessarily change the
+paragraph number of an unchanged legality rule; since it is very
+likely that compiler error messages refer to the paragraph numbers
+of legality rules, we prefer to avoid that. - Editor.]
+
+
+Add after 8.3(25) (still in the Name Resolution Rules section):
+
+    A name shall not resolve to denote an integrated package
+    or package renaming outside of the immediate scope of that
+    declaration.
+
+    AARM note:
+    This rule means that an integrated package or package renaming
+    is, in effect, anonymous outside of its immediate scope. However,
+    it remains visible.  This peculiar distinction (i.e., visible but
+    unnamable) is important because visibility of the declarations
+    declared within an integrated package may depend on the visibility
+    of the package (see 8.4). Because this is a name resolution
+    rule, the following example is legal:
+
+      declare
+         package P1 is
+            package X is end X;
+         end P1;
+
+         package P2 is
+            package <X> is end X;
+         end P2;
 
-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.
+         use P1;
+         use P2;
 
+         package Y renames X; -- unambiguously renames P1.X
+      begin
+         null;
+      end;
+
 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
@@ -156,59 +225,82 @@
    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
+         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.
 
-Add after 8.4(18) (in the Examples section)
+Add after 8.4(16) (in the Examples section)
 
-   generic
-       type T is private;
-   package G is
-       function Make return T;
-   end G;
-
-   with G;
-   pragma Elaborate (G);
-   package Pkg1 is
-     type T is null record;
-     use package I is new G (T);
-   end Pkg1;
-
-   with Pkg1;
-   package Pkg2 is
-      X : Pkg1.T := Pkg1.Make;
-      use Pkg1;
-      Y : T := Make;
-   end Pkg2;
-
-Modify 8.5.3(3) to allow optional "use" syntax:
-
-   package_renaming_declaration
-     ::= {use} package defining_identifier renames ...
-
-Add after 8.5.3(4) (i.e. append to the end of the Static Semantics section):
-
-   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).
+    Example of integrated packages:
+
+      generic
+        type T is private;
+      package G is
+        function Make return T;
+      end G;
+
+      with G;
+      pragma Elaborate (G);
+      package Pkg1 is
+        package <Inner_Pkg_1> is
+          type T is private;
+        private
+          type T is ... ;
+        end Inner_Pkg_1;
+
+        package <Inner_Pkg_2> is new G (T);
+      end Pkg1;
+
+      with Pkg1;
+      package Pkg2 is
+        X : Pkg1.T := Pkg1.Make;
+        use Pkg1;
+        Y : T := Make;
+      end Pkg2;
+
+Modify 8.5.3(3) to allow optional "< package_id >" syntax:
+
+    package_renaming_declaration
+        ::= package_identification renames package_name;
 
-Modify 12.3(2/2) to allow optional "use" syntax:
-   generic_instantiation ::= {use} package defining_program_unit_name is ...
+Add after 8.5.3(3.1/2) (Legality Rules):
 
-Add after 12.3(18) (i.e. append to the end of the Static Semantics section):
+    If a package rename's package_identification consists of an
+    integrated_package_identification, then the package renaming is said
+    to be *integrated* (see 8.4). The package_name of an integrated
+    package_renaming_declaration shall not denote a limited view of a package.
+    The package_name of an integrated package_renaming_declaration shall not
+    denote (directly or through renaming) a package whose declarative region
+    encloses the package_renaming_declaration.
 
-   If the optional reserved word "use" is present in a generic_instantiation,
-   then the package instance is said to be "integrated" (see 8.4).
 
+Modify 10.1.1(12.2/3) (as modified by AI05-0129-1) to disallow limited views
+of integrated packages:
+
+    For each nested package_declaration directly in the visible part
+    {which does not declare an integrated package},
+    a declaration of the limited view of that package, with the same
+    defining_program_unit_name.
+
+Modify 12.3(2/2) to allow optional "< package_id >" syntax:
+
+    generic_instantiation ::=
+        package package_identification
+          is new generic_package_name [generic_actual_part];
+
+Add after 12.3(18) (i.e. append to the end of the Static Semantics
+section):
+
+    If a package instance's package_identification consists of an
+    integrated_package_identification, then the package instance
+    is said to be "integrated" (see 8.4).
+
 !discussion
 
-Just to summarize, adding the reserved word "use" to a package
-or package rename declaration has three main effects:
+Just to summarize, adding angle brackets to a package
+or package rename declaration has four main effects:
 
   1) It is as though an implicit use_clause were added
      immediately after the package declaration, so that visible
@@ -217,7 +309,7 @@
 
      This allows:
        package P is
-          use package Q is
+          package <Q> is
              X : Integer := 0;
           end Q;
           -- use Q;
@@ -229,7 +321,7 @@
 
      This allows:
        package P is
-          use Package Q is
+          Package <Q> is
              X : Integer := 0;
           end Q;
        end P;
@@ -247,7 +339,7 @@
 
      This allows:
        package P is
-          use Package Q is
+          Package <Q> is
              X : Integer := 0;
           end Q;
        end P;
@@ -258,53 +350,54 @@
                           -- use P.Q
                           X;
        end R;
+
+   4) The integrated package cannot be named outside of its immediate
+      scope (and this is a name resolution rule).
 
-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.
+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.
-
+  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.
+use clauses described in #1 - #3.
 
 This allows:
+  use System;
+  package P is
+    package <S_Ren> renames System;
+  end P;
 
-   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;
+  with P;
+  package Q is
+    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
+The usual use_clause name resolution rules apply.
+This allows:
 
   package P is
-     use Package Q is
-         X, Y : Integer := 0;
-     end Q;
-     X : Float;
+    package <Q> is
+      X, Y : Integer := 0;
+    end Q;
+    X : Float;
   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".
+  with P;
+  package R is
+    Z : Float renames P.X; -- legal
+  end R:
 
 ----
 
@@ -317,210 +410,184 @@
 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:
+We needed rules to prevent some odd corner cases:
 
     limited with Foo;
     package P is
-      use package Bar renames Foo;
+      package <Bar> renames Foo;
     end P;
 
+We don't want this for the same reasons that we don't allow use clauses of
+Foo.
+
+Another odd case:
+
     package Outer is
       package Inner is
-         use package Outer_Rename renames Outer;
+         package <Outer_Rename> renames Outer;
       end Inner;
     end Outer;
 
+The declarations of Outer_Rename will always be hidden by those of Outer. So
+this is useless. It also has a (small) implementation burden, as a simple
+implementation would be at risk of going into an infinite loop: Outer_Rename
+would appear inside of itself. Thus the case needs to be detected and handled
+specially; given that it is useless, that effort might as well be spent
+toward making it illegal.
+
 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)
+would be straightforward. These would include:
 
-----
+  - in the additions after 7.1(5/2), delete "or package renaming" and
+      "(or of a package_renaming_declaration
+        of a library_unit_renaming_declaration)".
 
-    Tuck suggests that the name of an integrated package (whether a rename or
-    not) should not itself become "use"-visible when the enclosing package is "use"d.
+  - in the additions after 8.3(25), delete "or package renaming" (twice).
 
-    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".
-
-    Tuck observes that this rule should "apply
-    to *all* integrated packages, not just integrated package
-    renames, since the same problem comes up when you
-    declare an integrated subpackage, or an integrated
-    generic instance. You really don't want the names of
-    the integrated packages cluttering up the namespace when
-    you do a "use" of the enclosing package, but you *do*
-    want them when trying to disambiguate where you would
-    be using a complete expanded name."
-
-    If there is general agreement on this point, then
-    the two alternatives described below should be
-    discarded because they only address the case of
-    an integrated package rename.
-
-    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.
+  - in the additions after 8.4(11), delete "or package renaming" (three
+    occurences), "or renamed package" (twice), and "(or, in the case of an
+    integrated package renaming, within  the renamed package)" .
 
-----
+  - eliminate the changes to 8.5.3(3) and the addition after 8.5.3(3.1/2).
 
-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;
+The only occurences of any form of the word "rename" (e.g.,
+renaming, renamed) remaining in the proposed wording changes would then
+be the rename declaration in the example in the AARM note after 8.3(25) and
+the text "(or a rename thereof)" added after 8.4(11).
 
-   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;
+An integrated package may not be named outside of its immediate scope.
+To understand the motivation for this rule, 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
+    package <Some_Name> renames Ada.IO_Exceptions;
+  However, what should "Some_Name" be? Well, most natural would be:
+    package <IO_Exceptions> renames Ada.IO_Exceptions;
+  But now suppose you have:
+    with Ada.IO_Exceptions;
+    with Ada.Text_IO;
+    use Ada;
+    use Text_Io;
+    procedure What_Fun is
+    begin
+       ...;
+    exception
+      when IO_Exceptions.Name_Error => -- we want this to compile
+        ...;
+    end What_Fun;
 
-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.
+Tuck observes that this rule should "apply to all integrated packages, not
+just integrated package renames, since the same problem comes up when you
+declare an integrated subpackage, or an integrated generic instance. You
+really don't want the names of the integrated packages cluttering up the
+namespace when you do a "use" of the enclosing package, but you do want them
+when trying to disambiguate where you would be using a complete expanded name."
 
 ----
 
-A limited view of a non-instance non-rename integrated package
-declaration *could* be defined to be integrated, thus allowing
+We simply disallow limited views of integrated packages (10.1.1).
+They are like instantiations. Now that we don't allow the normal
+view of an integrated package to be named outside of its
+immediate scope, why would we want to allow naming of the
+limited view of an integrated package? If we were going to go
+down that road, it would be better to incorporate (integrate?)
+integration into limited views, allowing something like
 
-    package P is
-       use package Q is
-          type T is new Integer;
-       end Q;
-    end P;
-
-    limited with P;
-    package R is
-       type Ref is access P.T; -- currently illegal
-    end R;
+  package P is
+    package <Q> is
+      type T is ... ;
+    end Q;
+  end P;
 
-Would this be desirable? It won't work for instances or package renames.
+  limited with P;
+  package R is
+    type Ref is access P.T; -- illegal
+  end R;
+
+and we have decided against that. It seems fine to say that
+an integrated package, like an instance, simply does not have a limited
+view.
 
 ----
-
-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;
+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.
 
-      use package P2 is
-         use package Inner is
-            Bbb : Integer;
+This allows:
+  package P is
+    package <P1> is
+      Aaa : Integer;
+      package <Inner> is
+        function F return Integer;
+      end Inner;
+    end P1;
 
-            function F return Float;
-         end Inner;
-      end P2;
-   end P;
+    package <P2> is
+      package <Inner> is
+        Bbb : Integer;
+        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
+  with P;
+  package Q is
+    X : Float := P.F; -- legal
+  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
+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
+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;
-
-   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.
+  package P is
+    package <Q> is
+      X, Y : Integer;
+    end Q;
+  end P;
+
+  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.
+
+----
 
+The angle brackets of an integrated package are not part of
+the package's identifier.
+
+In this example,
+  package P is
+     package <Q> is
+     end Q;
+  end P;
+, the name of the nested package is "Q", not "<Q>".
+
+This is why angle brackets are not repeated at the end of a package
+spec, at the start or end of a package body, or for a package body stub.
+
 --!corrigendum 8.4(3)
 
 
@@ -7975,5 +8042,200 @@
 too tired on Saturday night to actually remember the proper term. "despair" is
 probably a bit much for this issue (although it does seem appropriate in some
 ways :-). Sorry about any confusion.
+
+****************************************************************
+
+From: Steve Baird
+Sent: Thursday, January 7, 2010  6:35 PM
+
+Here's a new version reflecting feedback from the St. Petersburg meeting and
+subsequent discussions with Randy. [This is version /06 - Editor.]
+
+This proposal includes:
+    - new angle-bracket "package <P> is" syntax instead of
+      "use package P".
+    - effective anonymity of an integrated package outside of
+      its immediate scope
+    - support for easily jettisoning integrated package renames
+      from the AI if it is decided that this is what we want
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Monday, January 11, 2010  11:29 PM
+
+You still don't have the legality rule to make an integrated renames of a
+limited view of a package illegal. Since that is supposed to be equivalent to an
+implicit use-clause, and we make use clauses of limited views illegal for good
+reasons, we need a similar rule here or we'll reintroduce all of the problems
+that we introduced 8.4(5/2) to fix. You call this an "odd corner case" in the
+discussion, but there is nothing "odd" about it -- it has to be illegal and have
+a rule to that effect.
+
+I suspect that the circular rename you show also ought to be illegal, as it
+could never have any useful effect (the names would always be hidden by the
+direct names from the outer package).
+
+Adding these rules will make the renames look "heavier" than it currently does,
+which is an important data point in whether or not we should be allowing the
+renames.
+
+****************************************************************
+
+From: Steve Baird
+Sent: Tuesday, January 12, 2010  1:31 PM
+
+> You still don't have the legality rule to make an integrated renames
+> of a limited view of a package illegal. Since that is supposed to be
+> equivalent to an implicit use-clause, and we make use clauses of
+> limited views illegal for good reasons, we need a similar rule here or
+> we'll reintroduce all of the problems that we introduced 8.4(5/2) to
+> fix. You call this an "odd corner case" in the discussion, but there
+> is nothing "odd" about it -- it has to be illegal and have a rule to that effect.
+>
+
+Good point. How about swapping the order of the "Legality Rules" and "Static
+Semantics" sections of 8.5.3 (so that the definition of an integrated package
+rename precedes the legality rules) and then appending the following legality
+rule to 4.5.3(3.1/2):
+    The package_name of an integrated package_renaming_declaration
+    shall not denote a limited view of a package.
+?
+
+> I suspect that the circular rename you show also ought to be illegal,
+> as it could never have any useful effect (the names would always be
+> hidden by the direct names from the outer package).
+>
+
+Certainly we should disallow this if it introduces definitional or
+implementation problems, but I don't see that it does. Disallowing something
+because it is useless seems like overkill. Your next statement is a good
+argument for allowing it:
+   > Adding these rules will make the renames look "heavier" than it currently
+   > does, which is an important data point in whether or not we should be
+   > allowing the renames.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Tuesday, January 12, 2010  4:07 PM
+
+...
+> Good point. How about swapping the order of the "Legality Rules" and
+> "Static Semantics" sections of 8.5.3 (so that the definition of an
+> integrated package rename precedes the legality rules) and then
+> appending the following legality rule to 4.5.3(3.1/2):
+>     The package_name of an integrated package_renaming_declaration
+>     shall not denote a limited view of a package.
+> ?
+
+That seems OK, assuming that you meant 8.5.3(3.1/2) here and not the 4.5.3
+(Binary adding operators??) that you wrote.
+
+> > I suspect that the circular rename you show also ought to be
+> > illegal, as it could never have any useful effect (the names would
+> > always be hidden by the direct names from the outer package).
+>
+> Certainly we should disallow this if it introduces definitional or
+> implementation problems, but I don't see that it does.
+> Disallowing something because it is useless seems like overkill.
+
+Maybe it is a difference in philosophy, but I think that things that are
+*always* useless ought to be illegal. No one intentionally writes (well, other
+than ACATS test writers!) anything useless, so if it occurs in a program, it
+represents a mistake. And we want the compiler to detect mistakes.
+
+I also worry that having circularly linked symboltable structures could be a
+burden for compilers: you'd have to have some special mechanism to detect this
+case otherwise you would go into an infinite regress doing lookups (as the
+integrated package rename would appear inside of itself). That's probably not
+that hard to do, but why spend any effort making some useless case work??
+
+> Your next statement is a good argument for allowing it:
+>    > Adding these rules will make the renames look "heavier" than it currently
+>    > does, which is an important data point in whether or not we should be
+>    > allowing the renames.
+
+Well, the implementation cost of the possibility will exist whether or not a
+rule exists to prevent it, so in some sense you are being misleading by hiding
+it. Not a big deal, but certainly this is a weak reason for avoiding a rule.
+
+****************************************************************
+
+From: Steve Baird
+Sent: Tuesday, January 12, 2010  4:20 PM
+
+>>> I suspect that the circular rename you show also ought to be
+>>> illegal,
+
+I don't feel strongly about it.
+Would you like wording for this rule?
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Wednesday, January 13, 2010  9:14 PM
+
+Yes, please. It's easier to delete a rule that we decide isn't needed
+than to create one out of air (and to remember to consider it).
+
+****************************************************************
+
+From: Steve Baird
+Sent: Thursday, January 14, 2010  1:00 PM
+
+We've already swapped the order of the "Legality Rules" and "Static Semantics"
+sections of 8.5.3 so that the definition of an integrated package rename
+precedes the legality rules.
+
+We're already appending one legality rule after 8.5.3(3.1/2) [not after
+4.5.3(3.1/2) - good catch, Randy] to disallow integrated renames of limited
+views of packages.
+
+So now we also append:
+
+    The package_name of an integrated package_renaming_declaration
+    shall not denote (directly or through renaming) a package
+    whose declarative region encloses the package_renaming_declaration.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Friday, January 15, 2010  9:15 PM
+
+> Good point. How about swapping the order of the "Legality Rules" and
+> "Static Semantics" sections of 8.5.3 (so that the definition of an
+> integrated package rename precedes the legality rules) and then
+> appending the following legality rule to 4.5.3(3.1/2):
+>     The package_name of an integrated package_renaming_declaration
+>     shall not denote a limited view of a package.
+> ?
+
+"Swapping the order" means deleting one or the other sections, because we have
+to renumber the paragraphs. And that doesn't seem necessary in this case anyway:
+just put the definition of *integrated package* into the legality rules (it's
+not used elsewhere here, is it?) There's not a strong boundary between "Static
+Semantics" and "Legality Rules" anyway (unlike "Name Resolution Rules" and
+"Dynamic Semantics") So we end up with something like:
+
+Add after 8.5.3(3.1/2):
+
+  If a package rename's package_identification consists of an
+  integrated_package_identification, then the package renaming
+  is said to be *integrated* (see 8.4). The package_name of an
+  integrated package_renaming_declaration shall not denote
+  a limited view of a package. The package_name of an integrated
+  package_renaming_declaration shall not denote (directly or
+  through renaming) a package whose declarative region encloses
+  the package_renaming_declaration.
+
+I'd suggest the same in 7.1. Note that changing the paragraph numbers of
+legality rules is nasty, because it not unusual for compiler error messages to
+refer to them; it's much less likely that the paragraph numbers of other things
+are referred to. So I'd prefer not to change the paragraph numbers of unmodified
+legality rules.
+
+I've modified the draft AI as suggested here. I'm sure someone will have an even
+better idea...
 
 ****************************************************************

Questions? Ask the ACAA Technical Agent