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

Differences between 1.1 and version 1.2
Log of other versions for file ai05s/ai05-0135-2.txt

--- ai05s/ai05-0135-2.txt	2010/01/16 05:29:34	1.1
+++ ai05s/ai05-0135-2.txt	2010/01/16 05:30:08	1.2
@@ -1,4 +1,4 @@
-!standard  4.1.3(12)                                 10-01-07    AI05-0135-2/01
+!standard  4.1.3(12)                                 10-01-15    AI05-0135-2/02
 !standard  7.1(2)
 !standard  7.1(3)
 !standard  7.1(4)
@@ -114,18 +114,21 @@
     use Pkg;
     Xx : T;
     Yy : Valise;
-  end Client; 
+  end Client;
 
 !wording
+
 Modify 4.1.3(12) as follows
-   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)}.
-   The expanded name denotes that declaration.
+
+    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)}.
+    The expanded name denotes that declaration.
 
 Replace 7.1(3) to allow optional "< package_id >" syntax
+
    integrated_package_identification ::= < defining_identifier >
 
    package_identification :=
@@ -139,36 +142,38 @@
      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) (i.e. append to the end of the Legality
-section):
-    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.
+Add after 7.1(5/2):
 
-Add after 7.1(7) (i.e. append to the end of the Static Semantics
-section):
     If a package's package_identification consists of an
     integrated_package_identification, then the package is said to
-    be "integrated" (see 8.4). 
+    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.]
 
-[Move the Legality section of 7.1 so that it follows, rather than
-precedes, the Static Semantics section. This is because the legality
-rule added above refers to "an integrated package" and this term
-is defined in the Static Semantics section.]
 
 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.
@@ -183,49 +188,51 @@
     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;
-
-          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 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.
+         package P1 is
+            package X is end X;
+         end P1;
+
+         package P2 is
+            package <X> is end X;
+         end P2;
+
+         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
+   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.
 
 Add after 8.4(16) (in the Examples section)
+
     Example of integrated packages:
 
       generic
@@ -254,49 +261,59 @@
       end Pkg2;
 
 Modify 8.5.3(3) to allow optional "< package_id >" syntax:
+
     package_renaming_declaration
         ::= package_identification renames package_name;
 
-Add after 8.5.3(4) (i.e. append to the end of the Static Semantics
-section):
+Add after 8.5.3(3.1/2) (Legality Rules):
+
     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).
+    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.
+
 
-Modify 10.1.1(12.2/3) to disallow limited views of integrated packages:
+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 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
-     declarations in the integrated package's spec become potentially
-     use-visible within the enclosing package.
+     declarations in the integrated package's spec become
+     potentially use-visible within the enclosing package.
 
      This allows:
        package P is
-         package <Q> is
-           X : Integer := 0;
-         end Q;
-         -- use Q;
-         Y : Integer := X;
+          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
@@ -304,35 +321,35 @@
 
      This allows:
        package P is
-         package <Q> is
-           X : Integer := 0;
-         end Q;
+          Package <Q> is
+             X : Integer := 0;
+          end Q;
        end P;
- 
+
        with P;
        use P;
        -- use P.Q;
        package R is
-         Y : Integer := X;
+           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.
+  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
-          package <Q> is
-            X : Integer := 0;
+     This allows:
+       package P is
+          Package <Q> is
+             X : Integer := 0;
           end Q;
-        end P;
+       end P;
 
-        with P;
-        package R is
-          Y : Integer := P.
-                         -- use P.Q
-                         X;
-        end R;
+       with P;
+       package R is
+           Y : Integer := P.
+                          -- 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).
@@ -384,29 +401,42 @@
 
 ----
 
-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.
+If it is decided that integrated package renames are not wanted,
+it would be easy to remove them from the proposal.
 
-Integrated package renames also make possible a number of odd corner cases:
+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.
 
-  limited with Foo;
-  package P is
-    package <Bar> renames Foo;
-  end P;
+We needed rules to prevent some odd corner cases:
 
-  package Outer is
-    package Inner is
-      package <Outer_Rename> renames Outer;
-    end Inner;
-  end Outer;
+    limited with Foo;
+    package P is
+      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
+         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
+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
@@ -422,7 +452,7 @@
     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(4).
+  - eliminate the changes to 8.5.3(3) and the addition after 8.5.3(3.1/2).
 
 The only occurences of any form of the word "rename" (e.g.,
 renaming, renamed) remaining in the proposed wording changes would then
@@ -571,8 +601,7 @@
 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 a new alternative; version /01 of
-that alternative - Editor.]
+subsequent discussions with Randy. [This is version /01 - Editor.]
 
 This proposal includes:
     - new angle-bracket "package <P> is" syntax instead of
@@ -584,3 +613,181 @@
 
 ****************************************************************
 
+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