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

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

--- ai05s/ai05-0135-1.txt	2009/02/13 03:10:54	1.4
+++ ai05s/ai05-0135-1.txt	2009/03/19 06:39:02	1.5
@@ -1,4 +1,4 @@
-!standard  4.1.3(12)                                   09-02-11    AI05-0135-1/02
+!standard  4.1.3(12)                                 09-02-11    AI05-0135-1/02
 !standard  8.4(3)
 !standard  8.4(4)
 !standard  8.4(8/2)
@@ -119,7 +119,7 @@
     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 expanded name denotes that declaration.
 
 Modify 8.43-4) to add optional "all" reserved word syntax:
 
@@ -170,7 +170,7 @@
    package G is
        function Make return T;
    end G;
-   
+
    with G;
    pragma Elaborate (G);
    package Pkg1 is
@@ -212,11 +212,11 @@
       X : Pkg.Valise; -- the name Pkg.Valise denotes Pkg.I.Valise;
     end Client;
 
-That is why the example given in the Example section of the 
+That is why the example given in the Example section of the
 wording involves an instantiation, albeit one that does not
 involve passing in a non-yet-completed private type as an
 actual parameter.
-     
+
 The use_type_clause-specific part of the proposal is completely
 orthogonal to the rest. One could imagine different syntax for
 this and then having all 4 forms of use_type_clause, as in
@@ -248,7 +248,7 @@
       use all type Pkg2.S;
       X : Integer := Foo (Aa);
     end Pkg3;
-    
+
 The language has no notion of a use_clause (which is not a declaration)
 being visible or not. The closest thing in the language to visibility
 for a non-declaration is the streaming attribute availability stuff
@@ -305,7 +305,7 @@
 does in this case, but no language rule depends on the result.
 The notion of "use visibility by selection" is defined
 in terms of the set of declarations that are "potentially use-visible",
-but the set of "use-visible" declarations plays no role here. 
+but the set of "use-visible" declarations plays no role here.
 
 Note that the with of a child unit may add a declaration to the
 visible part of the parent unit and thereby hide a declaration
@@ -2426,7 +2426,7 @@
 From: Bob Duff
 Date: Monday, February  2, 2009  2:15 PM
 
-> After all, you make this sound nasty and original; but it already 
+> After all, you make this sound nasty and original; but it already
 > happens for use clauses and child units, and has since Ada 95 was introduced.
 
 You can come up with similar surprises even in Ada 83.  And with subunits, you
@@ -2450,8 +2450,8 @@
 From: Robert I. Eachus
 Date: Monday, February  2, 2009  6:28 PM
 
->You can come up with similar surprises even in Ada 83.  And with 
->subunits, you can make the surprise cross source-file boundaries.  Ada 
+>You can come up with similar surprises even in Ada 83.  And with
+>subunits, you can make the surprise cross source-file boundaries.  Ada
 >95 makes it a little worse, with child units.
 
 Reminds me of a very old gotcha in Ada.  I think I originally wrote it as
@@ -2508,3 +2508,1130 @@
 The only hard part of separating the two properties would be deciding on syntax.
 
 ****************************************************************
+
+From: Tucker Taft
+Date: Thursday, March 12, 2009  6:05 AM
+
+I am growing pretty fond of the "use package P is ..."
+proposal as a way to both define and then "open" a subpackage, particularly
+since it solves the private-type instantiation problem so nicely. I had a few
+additional thoughts about the proposal:
+
+1) Don't make the subpackage name itself directly visible when the enclosing
+package is "use"d -- just make the contents of the subpackage directly visible.
+
+Rationale: I was somewhat enamored of allowing the subpackage name to be "<>"
+but I understand Erhard's objection to it, and I also realize if there were more
+than one, defining the body for the subpackage would be ambiguous. The main
+reason for wanting "<>" was so that the subpackage name didn't pollute the
+namespace.  Then I realized that if we simply didn't make the subpackage name
+directly visible when the enclosing package were "use"d, it would solve the
+problem.  This way you can call the subpackage "Inner" or any name you find
+suggestive of its purpose, but if the enclosing package is "use"d, the
+subpackage name won't end up creating any problems by "cancelling" other
+use-visible entities that happen to have the same name.  It also seems to make
+some intuitive sense.  The whole point of this use package P ... syntax is that
+the contents of P are made directly visible when the enclosing package is
+"use"d. It seems reasonable then to "subtract" the name of the subpackage itself
+if you are getting all of its contents.
+
+Example:
+
+
+     package Abstraction is
+
+      use
+        package Inner is
+          -- "Inner" is *not* made directly
+          -- visible by a "use Abstraction"
+            type ADT is private;
+            ...
+        private
+            type ADT is ...
+        end Inner;
+
+
+        package Signature is
+          new Container_Signature(ADT, ...);
+            -- Instantiate signature
+
+      use
+        package ADT_Vectors is Vectors(ADT, ...);
+           -- Create vector of ADT
+
+        subtype ADT_Vector is ADT_Vectors.Vector;
+           -- Define longer name
+    end Abstraction;
+
+
+2) Allow "use" in front of a package rename, with the effect of "open"ing the
+named package.
+
+Rationale:  This seems consistent, since there are three ways to create
+something that looks like a subpackage -- define one, instantiate one, or rename
+one.  Furthermore, it gives us the "transitive" use, but with a syntax that is
+clearly distinct from the current "use" clause syntax. And finally, by providing
+a name to the renamed package, we avoid running into the same problem that
+Erhard identified with package instantiations, so there is always a way to
+handle name collisions that result from transitive "use."
+
+Example:
+
+     with Useful_Stuff, More_Useful_Stuff;
+     package Combination is
+
+       use package Part1 renames Useful_Stuff;
+
+       use package Part2 renames More_Useful_Stuff;
+
+     end Combination;
+
+3) Consider using syntax similar to aspect specification
+    to rename components as part of doing a "use package":
+
+Rationale: If you are going to "open" a package into the enclosing scope, you
+may periodically want to rename some of its components to avoid collisions.
+
+Example:
+
+    use package ADT_Vectors is new Vectors(ADT, ...)
+      with
+        ADT_Vector renames Vector,
+        ADT_Cursor renames Cursor;
+
+This would instantiate Vectors and then "open" up the instance, but with the two
+types renamed to better reflect their meaning in the enclosing scope.  This
+would only be allowed on package instantiations and renames, not on newly
+defined nested packages.
+
+****************************************************************
+
+From: Bob Duff
+Date: Thursday, March 12, 2009  8:47 AM
+
+> Rationale: I was somewhat enamored of allowing the subpackage name to
+> be "<>" but I understand Erhard's objection
+
+This is the third time in as many days that I've seen proposals to add new
+meanings to the <> symbol!
+
+****************************************************************
+
+From: Tucker Taft
+Date: Thursday, March 12, 2009  1:08 PM
+
+But in my case it was just a strawman, and I am not recommending it.  But it is
+a very nice symbol, after all ... ;-)
+
+****************************************************************
+
+From: Steve Baird
+Date: Thursday, March 12, 2009  3:24 PM
+
+> I am growing pretty fond of the "use package P is ..."
+> proposal as a way to both define and then "open" a subpackage,
+> particularly since it solves the private-type instantiation problem so
+> nicely.
+
+I like it too.
+I think it is a clean solution to an important problem.
+
+> I had a few additional thoughts about the proposal:
+>
+> 1) Don't make the subpackage name itself directly visible when the
+> enclosing package is "use"d -- just make the contents of the
+> subpackage directly visible.
+>
+
+I don't like this idea, but I don't feel strongly about it. I don't see any
+definitional problems with it - it just seems strikes me as unnecessarily
+irregular. I would be interested in knowing whether others feel that I am
+underestimating the impact of the name space pollution problem,
+
+
+> Rationale: I was somewhat enamored of allowing the subpackage name to
+> be "<>" but I understand Erhard's objection to it, and I also realize
+> if there were more than one, defining the body for the subpackage
+> would be ambiguous.
+> The main reason for wanting "<>" was so that the subpackage name
+> didn't pollute the namespace.  Then I realized that if we simply
+> didn't make the subpackage name directly visible when the enclosing
+> package were "use"d, it would solve the problem.  This way you can
+> call the subpackage "Inner" or any name you find suggestive of its
+> purpose, but if the enclosing package is "use"d, the subpackage name
+> won't end up creating any problems by "cancelling" other use-visible
+> entities that happen to have the same name.  It also seems to make
+> some intuitive sense.  The whole point of this use package P ...
+> syntax is that the contents of P are made directly visible when the
+> enclosing package is "use"d.
+> It seems reasonable then to "subtract" the name of the subpackage
+> itself if you are getting all of its contents.
+>
+> Example:
+>
+>
+>     package Abstraction is
+>
+>      use
+>        package Inner is
+>          -- "Inner" is *not* made directly
+>          -- visible by a "use Abstraction"
+>            type ADT is private;
+>            ...
+>        private
+>            type ADT is ...
+>        end Inner;
+>
+>
+>        package Signature is
+>          new Container_Signature(ADT, ...);
+>            -- Instantiate signature
+>
+>      use
+>        package ADT_Vectors is Vectors(ADT, ...);
+>           -- Create vector of ADT
+>
+>        subtype ADT_Vector is ADT_Vectors.Vector;
+>           -- Define longer name
+>    end Abstraction;
+>
+>
+> 2) Allow "use" in front of a package rename, with the effect of
+> "open"ing the named package.
+>
+> Rationale:  This seems consistent, since there are three ways to
+> create something that looks like a subpackage -- define one,
+> instantiate one, or rename one.  Furthermore, it gives us the
+> "transitive" use, but with a syntax that is clearly distinct from the
+> current "use" clause syntax.
+> And finally, by providing a name to the renamed package, we avoid
+> running into the same problem that Erhard identified with package
+> instantiations, so there is always a way to handle name collisions
+> that result from transitive "use."
+>
+
+Is it clear that we need this generality?
+
+This would require adding wording to cope with various pathological cases that
+this would make possible (e.g. a rename of a limited view of a package, a rename
+of a package whose spec encloses the rename).
+
+All this is doable, but I think that it would introduce some definitional
+complexity.
+
+This feature also has a very high potential for misuse.
+Use clauses can already be used to write code which is difficult to read; this
+construct would make matters even worse in this respect.
+
+Incidentally, should the following be legal?
+
+    package Outer is
+        use package Inner is
+            type T is new Integer;
+        end Inner;
+    end Outer;
+
+    limited with Outer;
+    package Snort is
+        type T_Ref is access Outer.T;
+    end Snort;
+
+In other words, is the distinction between a "use" and a "non-use" package
+retained in the limited view of an enclosing package?
+
+
+> Example:
+>
+>     with Useful_Stuff, More_Useful_Stuff;
+>     package Combination is
+>
+>       use package Part1 renames Useful_Stuff;
+>
+>       use package Part2 renames More_Useful_Stuff;
+>
+>     end Combination;
+>
+> 3) Consider using syntax similar to aspect specification
+>    to rename components as part of doing a "use package":
+>
+> Rationale: If you are going to "open" a package into the enclosing
+> scope, you may periodically want to rename some of its components to
+> avoid collisions.
+>
+> Example:
+>
+>    use package ADT_Vectors is new Vectors(ADT, ...)
+>      with
+>        ADT_Vector renames Vector,
+>        ADT_Cursor renames Cursor;
+>
+> This would instantiate Vectors and then "open" up the instance, but
+> with the two types renamed to better reflect their meaning in the
+> enclosing scope.  This would only be allowed on package instantiations
+> and renames, not on newly defined nested packages.
+
+This seems like a fairly big change, because it is no longer so simple to define
+this construct just in terms of use-visibility.
+
+As I imagine it, adding the word "use" to a package declaration would have only
+three effects:
+
+    1) Visible declarations within the inner package spec become
+       use-visible within the enclosing package. Informally,
+       this can be thought of as meaning that an implicit use
+       clause is inserted immediately after the package declaration,
+       as in
+
+           package P is
+               use package Q is
+                  X : constant Integer := ... ;
+               end Q;
+
+               use Q; -- implicitly inserted
+
+               Y : Integer := X;
+           end P;
+
+    2) A use clause which applies to the enclosing package
+       also applies to the inner package. Informally,
+       this can be thought of as meaning that an implicit
+       use clause is inserted immediately after any
+       use clause which applies to the enclosing package,
+       as in
+
+           with P;
+           package Gronk is
+               use P;
+               use P.Q; -- implicitly inserted
+
+               Z : Integer := X;
+           end Gronk;
+
+     3) At the point of resolving an expanded name whose
+        prefix denotes the enclosing package, any visible
+        declarations of the inner package become
+        "use visible by selection", which is
+        a term defined in the current (now obsolete)
+        version of AI05-0135. Informally (and I mean
+        *really* informally), this can be thought of
+        as meaning that an implicit use clause is
+        inserted at the point of the dot in the selected
+        name, as in
+
+            with P;
+            package Snuffle is
+                W : Integer := P .
+                     use P.Q; -- implicitly inserted
+                     X;
+            end Snuffle;
+
+The change you are proposing does not seem to fit this model well. I'm not
+trying to let the implementation dictate the specification here. I'm saying that
+we have a fairly clean model which
+    - should not require a lot of complicated RM wording
+    - should be possible for users to understand and I'm reluctant to give that
+      up.
+
+This approach I've outlined depends on the fact that we are only making existing
+declarations use-visible - we are not introducing renames or any other new
+implicitly-declared declarations.
+
+Rename-based (as opposed to use-visibility-based) approaches to this problem
+were discussed a while back (that was the approach that I initially had in mind)
+and have been abandoned for good reasons having to do with homograph collisions.
+
+If we really wanted to include this feature, I'd think about a "like a rename,
+but different" approach where the identifier "Vector" in your example becomes
+use-visible by the name of "Adt_Vector". I'm not advocating this approach - I'd
+rather not include the feature - but this seems like the way to define it if we
+decide that we really want the feature. I don't think mixing implicit rename
+declarations into a definition that is based on use-visibility is the way to go.
+
+****************************************************************
+
+From: Gary Dismukes
+Date: Thursday, March 12, 2009  3:55 PM
+
+> I like it too.
+> I think it is a clean solution to an important problem.
+
+I haven't completely decided whether I like it yet, but I certainly like it
+better than other alternatives proposed for solving the "private instantiation"
+problem, so from that point of view it's appealing.
+
+> > I had a few additional thoughts about the proposal:
+> >
+> > 1) Don't make the subpackage name itself directly visible when the
+> > enclosing package is "use"d -- just make the contents of the
+> > subpackage directly visible.
+> >
+>
+> I don't like this idea, but I don't feel strongly about it. I don't
+> see any definitional problems with it - it just seems strikes me as
+> unnecessarily irregular.
+> I would be interested in knowing whether others feel that I am
+> underestimating the impact of the name space pollution problem,
+
+I also find that odd.  For one thing, it seems weird to have a name that can't
+be referenced.  It seems like it should still be possible to name the entities
+in the package by selection from the package, though I realize that's
+unnecessary once they're "reexported". As you say, it feels irregular.
+
+****************************************************************
+
+From: Randy Brukardt
+Date: Thursday, March 12, 2009  4:07 PM
+
+> I haven't completely decided whether I like it yet, but I certainly
+> like it better than other alternatives proposed for solving the
+> "private instantiation" problem, so from that point of view it's
+> appealing.
+
+So far, I think it's a good idea. I've never liked using derivation to make
+things visible (too tricky for my taste, and you get types that you don't need
+or want). But since I don't like "use" clauses much, I'll reserve final judgment
+until we get further along with the definition.
+
+...
+> I also find that odd.  For one thing, it seems weird to have a name
+> that can't be referenced.  It seems like it should still be possible
+> to name the entities in the package by selection from the package,
+> though I realize that's unnecessary once they're "reexported".
+> As you say, it feels irregular.
+
+I agree with Gary and Steve. It doesn't seem necessary to add complexity to this
+proposal. If you really are worried about name pollution and you are pretty sure
+that you'll never want to use the package name, just name it something like
+"package Dont_Ever_Use_This_Package_Name_In_Your_Code" or "package
+This_Package_Has_No_Name_and_Dont_Ever_Use_It" and you should not have to worry
+about conflicts. (And yes, I have done that in a few cases in my code.)
+
+****************************************************************
+
+From: Tucker Taft
+Date: Thursday, March 12, 2009  4:02 PM
+
+...
+> I don't like this idea, but I don't feel strongly about it. I don't
+> see any definitional problems with it - it just seems strikes me as
+> unnecessarily irregular.
+> I would be interested in knowing whether others feel that I am
+> underestimating the impact of the name space pollution problem,
+
+I think the namespace pollution issue is a big one.  If we don't do this, I
+foresee people using all kinds of weird names to try to be sure they don't have
+any collisions, and that seems like a waste of time and something that will make
+such packages look bogus.  Hiding the name of the subpackage itself from use
+visibility, for a subpackage that is "used at birth" (or "always open") feels
+like a much cleaner approach, and allows the user to pick a name for the
+subpackage that is descriptive rather than intentionally obscure.  I don't see
+it as "irregular" but rather I see it as a fairly natural consequence of having
+its contents always use-visible.
+
+>> 2) Allow "use" in front of a package rename, with the effect of
+>> "open"ing the named package.
+>> ...
+>
+> Is it clear that we need this generality?
+>
+> This would require adding wording to cope with various pathological
+> cases that this would make possible (e.g. a rename of a limited view
+> of a package, a rename of a package whose spec encloses the rename).
+
+Why are these pathological?  Can you explain what makes them worse than a rename
+followed by a normal "use" of the package?  (My mind isn't as fiendish as yours,
+I suspect.)
+
+> All this is doable, but I think that it would introduce some
+> definitional complexity.
+
+I would agree if this adds complexity it isn't worth it.  But if not, it just
+feels unnatural if you see the three ways of defining a subpackage, but we allow
+"use" in front of two of them but not the third, even though a "normal" use
+clause is legal with any of the three.
+
+> This feature also has a very high potential for misuse.
+> Use clauses can already be used to write code which is difficult to
+> read; this construct would make matters even worse in this respect.
+
+I'm not sure I see the issue here, so perhaps an example might help.
+
+>
+> Incidentally, should the following be legal?
+>
+>    package Outer is
+>        use package Inner is
+>            type T is new Integer;
+>        end Inner;
+>    end Outer;
+>
+>    limited with Outer;
+>    package Snort is
+>        type T_Ref is access Outer.T;
+>    end Snort;
+>
+> In other words, is the distinction between a "use" and a "non-use"
+> package retained in the limited view of an enclosing package?
+
+It would be weird if when you changed from non-limited to limited or vice versa,
+you had to insert/remove the name of the subpackage.  I don't see a big
+implementation burden here, and thus far limited views have been subsets of the
+full view.  It would be annoying if they were not just subsets, but really
+markedly different from the full view.
+
+...
+>> 3) Consider using syntax similar to aspect specification
+>>    to rename components as part of doing a "use package":
+...
+> This seems like a fairly big change, because it is no longer so simple
+> to define this construct just in terms of use-visibility.
+
+That's why I said "consider using" ;-)
+
+The rationale for this is that after instantiating a container, users are
+probably going to have to have several "subtype" declarations, as illustrated
+above. It just seems preferable to do it all in one fell swoop. I think the
+renames could be implicitly inserted *inside* the subpackage, just prior to any
+private part.  That would mean that you would still rely on use-visibility
+rather than "rename" visibility" for any effect outside the package.
+
+****************************************************************
+
+From: Bob Duff
+Date: Thursday, March 12, 2009  3:39 PM
+
+> I like it too.
+
+Me, three.
+
+> I think it is a clean solution to an important problem.
+>
+> > I had a few additional thoughts about the proposal:
+> >
+> > 1) Don't make the subpackage name itself directly visible when the
+> > enclosing package is "use"d -- just make the contents of the
+> > subpackage directly visible.
+> >
+>
+> I don't like this idea, but I don't feel strongly about it.
+
+Same here.
+
+>...I don't see any definitional problems with it -  it just seems
+>strikes me as unnecessarily irregular.
+> I would be interested in knowing whether others feel that I  am
+>underestimating the impact of the name space pollution problem,
+...
+> > 2) Allow "use" in front of a package rename, with the effect of
+> > "open"ing the named package.
+...
+> Is it clear that we need this generality?
+
+I won't say we "need" it, but it seems quite useful.
+
+> > 3) Consider using syntax similar to aspect specification
+> >    to rename components as part of doing a "use package":
+...
+> This seems like a fairly big change, because it is no longer so simple
+> to define this construct just in terms of use-visibility.
+
+Furthermore, it doesn't buy you much.  What does this give you beyond:
+
+    use package ADT_Vectors is new Vectors(ADT, ...)
+    subtype ADT_Vector is ADT_Vectors.Vector,
+    subtype ADT_Cursor is ADT_Vectors.Cursor;
+
+?
+
+****************************************************************
+
+From: Ed Schonberg
+Date: Thursday, March 12, 2009  4:25 PM
+
+> I think the namespace pollution issue is a big one.  If we don't do
+> this, I foresee people using all kinds of weird names to try to be
+> sure they don't have any collisions, and that seems like a waste of
+> time and something that will make such packages look bogus.  Hiding
+> the name of the subpackage itself from use visibility, for a
+> subpackage that is "used at birth"
+> (or "always open") feels like a much cleaner approach, and allows the
+> user to pick a name for the subpackage that is descriptive rather than
+> intentionally obscure.  I don't see it as "irregular"
+> but rather I see it as a fairly natural consequence of having its
+> contents always use-visible.
+
+The potential for name pollution comes from the opening of the package, not from
+the name of the package on its own. If the name is in the source it should be
+usable, and it should still be possible to use qualified names to retrieve its
+contents (even if this is redundant). I agree with the other critics of this
+idea: a name in the source must be usable. Otherwise <> would be the right name,
+but this has been discarded for other reasons.
+
+****************************************************************
+
+From: Randy Brukardt
+Date: Thursday, March 12, 2009  4:55 PM
+
+...
+> > Incidentally, should the following be legal?
+> >
+> >    package Outer is
+> >        use package Inner is
+> >            type T is new Integer;
+> >        end Inner;
+> >    end Outer;
+> >
+> >    limited with Outer;
+> >    package Snort is
+> >        type T_Ref is access Outer.T;
+> >    end Snort;
+> >
+> > In other words, is the distinction between a "use" and a "non-use"
+> > package retained in the limited view of an enclosing package?
+>
+> It would be weird if when you changed from non-limited to limited or
+> vice versa, you had to insert/remove the name of the subpackage.  I
+> don't see a big implementation burden here, and thus far limited views
+> have been subsets of the full view.  It would be annoying if they were
+> not just subsets, but really markedly different from the full view.
+
+Umm, normally use clauses aren't allowed for limited views. I forget the exact
+reasons, but I believe it had something to do with weird cases that we don't
+want to allow. So having use visibility of a limited view *solely* for this use
+would surely be unusual and irregular.
+
+OTOH, not having it would harm the abstraction that we're trying to create.
+I'm not sure what the correct answer is.
+
+****************************************************************
+
+From: Steve Baird
+Date: Thursday, March 12, 2009  5:54 PM
+
+> I think the namespace pollution issue is a big one.
+
+As I said, I don't feel strongly about this one.
+If I really thought that it would be common practice to introduce weird names to
+avoid collisions, I would certainly support this proposal.
+
+It does seem odd that you would get an error if you move some code out of the
+enclosing package (code which references the inner package explicitly) and plunk
+it down within the scope of a use-clause which names the outer package. On the
+other hand, I suppose this is an unimportant corner case.
+
+What about the case where explicit qualification is needed to resolve a
+use-visibility collision?
+
+     generic
+        type T is private;
+     package G is
+         X : Integer;
+         ... ;
+     end G;
+
+     with G;
+     package P is
+         use package I1 is new G (Integer);
+         use package I2 is new G (Float);
+     end P;
+
+     with P;
+     use P;
+     package P_Client is
+        Y : Integer renames I1.X; -- illegal
+        Z : Integer renames P.I1.X; -- legal
+     end P_Client;
+
+Don't you think users would find this confusing?
+
+
+>>> 2) Allow "use" in front of a package rename, with the effect
+
+>
+> Why are these pathological?  Can you explain what makes them worse
+> than a rename followed by a normal "use" of the package?  (My mind
+> isn't as fiendish as yours, I suspect.)
+>>
+
+You may be right. I ran into problems with these constructs during an earlier
+attempt at this problem, but I think the equivalences we have been discussing
+move these constructs from the "undefined" category into merely "confusing".
+
+Would this sort of thing pose any problems?
+
+     package Outer is
+         package Inner is
+            use package Ren renames Outer;
+         end Inner;
+         X : Integer := ... ;
+         Y : Integer := Inner.X -- legal
+                        + Inner.Y -- illegal
+                        + Inner.Z; -- illegal
+         Z : Integer := ... ;
+     end Outer;
+
+I remember very tangled discussions about the rules concerning a package which
+has a limited with of a unit but which has the full view of the unit indirectly
+in its closure.
+
+Would there be issues along those lines with something like
+
+     package Pkg is
+        Squamish_Players_Per_Team : constant := 43;
+     end Pkg;
+
+     limited with Pkg;;
+     package Zoofle is
+         use package Ren renames Pkg;
+     end Zoofle;
+
+     with Pkg;
+     with Zoofle;
+     package Doofle is
+        X : Integer := Zoofle.Squamish_Players_Per_Team; -- legal?
+     end Doofle;
+
+?
+
+
+...
+>> This feature also has a very high potential for misuse.
+>> Use clauses can already be used to write code which is difficult to
+>> read; this construct would make matters even worse in this respect.
+>
+> I'm not sure I see the issue here, so perhaps an example might help.
+
+I see this as the stronger argument against this construct.
+
+If you have something like
+
+     use P1;
+     use P2;
+     use P3;
+     ...
+     use P9;
+     package User is
+         X : Integer := Foo;
+     end User;
+
+and you have no idea where Foo is coming from, you currently have to look in
+each of the used specs. If any of the packages named in the use clauses are
+library unit renames, you have to look through those renames. Assuming that you
+haven't run into a particularly nasty case of an inherited function with
+defaults for all parameters, you ought to find it in one of those specs.
+
+If each of the used units now looks like
+
+    with P3A;
+    with P3B;
+    ...
+    with P3Z;
+    package P3 is
+       use package A renames P3A;
+       use package B renames P3B;
+       ...
+    end P3;
+
+, you've got a bigger search on your hands. And it need not end there - P3A may
+have the same structure. And woe unto you if you're down in a subunit where
+you've inherited a with of the child unit P3B.Foo ...
+
+In the restricted case where "use package" is not used for renames, you can
+still see this search-space expansion in the case of an instance (now you have
+to go look at the generic spec) but somehow this seems more forgivable (for one
+thing, it stops after one iteration if you ignore library unit renames).
+
+>>
+>> Incidentally, should the following be legal?
+>>
+>>    package Outer is
+>>        use package Inner is
+>>            type T is new Integer;
+>>        end Inner;
+>>    end Outer;
+>>
+>>    limited with Outer;
+>>    package Snort is
+>>        type T_Ref is access Outer.T;
+>>    end Snort;
+>>
+>> In other words, is the distinction between a "use" and a "non-use"
+>> package retained in the limited view of an enclosing package?
+>
+> It would be weird if when you changed from non-limited to limited or
+> vice versa, you had to insert/remove the name of the subpackage.  I
+> don't see a big implementation burden here, and thus far limited views
+> have been subsets of the full view.  It would be annoying if they were
+> not just subsets, but really markedly different from the full view.
+>>
+
+I completely agree. The argument against this (which I think is weak) is that
+this requires extracting additional information from the limited view before
+full semantic analysis has been run.
+
+...
+>>> 3) Consider using syntax similar to aspect specification
+>>>    to rename components as part of doing a "use package":
+...
+>> This seems like a fairly big change, because it is no longer so
+>> simple to define this construct just in terms of use-visibility.
+>
+> That's why I said "consider using" ;-)
+>
+
+I think Bob makes a good point here.
+It is sufficiently easy to do this using existing mechanisms that the cost
+associated with inventing any sort of new mechanism does not seem to be
+justified (Bob - speak up if I'm misinterpreting your comment).
+
+Adding implicit declarations to a package at some point other than the package
+declaration is fine as long as you are sure that you are the only one doing it.
+Suppose that you add a subtype named Foo to a package spec which then turns out
+to have a child unit named Foo. We ran into this with the two different
+mechanisms for defining a child unit of a package instance. Not that this case
+couldn't be defined, but why bother?
+
+There might also be issues with a Foo declared in the private part of the
+package and a client who can see both the private part and the rename-inducing
+"use package".
+
+
+****************************************************************
+
+From: Steve Baird
+Date: Thursday, March 12, 2009  6:13 PM
+
+>     limited with Pkg;
+>     package Zoofle is
+>         use package Ren renames Pkg;
+>     end Zoofle;
+>
+
+Randy Brukardt wrote:
+> Umm, normally use clauses aren't allowed for limited views.
+
+I suppose the rule Randy cited would need to be generalized to disallow the
+above example if "use" package renames are introduced.
+
+****************************************************************
+
+From: Bob duff
+Date: Thursday, March 12, 2009  6:58 PM
+
+> > I think the namespace pollution issue is a big one.
+
+Tuck, I don't understand the problem here.  Why wouldn't people just use some
+naming convention, like "use package Subpack is...", and have lots of things all
+over the place called Subpack, which are not directly nameable because they all
+conflict with each other?  I don't see why anyone would write "use package
+Some_Horribly_Long_Name_That_Nobody_Would_Write". I mean, there's no real _harm_
+in referring to it, so why not call them all "Subpackage" or whatever?
+
+Am I missing something obvious?  We're talking about the package name polluting,
+not the contents of, right?
+
+If you like, you can call it "use package Box is" instead of "use package <>
+is".  ;-)
+
+> As I said, I don't feel strongly about this one.
+
+Me, too.
+
+...
+> , you've got a bigger search on your hands. And it need not end there
+> - P3A may have the same structure. And woe unto you if you're down in
+> a subunit where you've inherited a with of the child unit P3B.Foo ...
+
+I don't buy such "can be abused" arguments.  Patient: It hurts when I abuse use.
+Doctor: So don't do that.  ;-) Anyway, in practice, you click on your fancy IDE
+to find the thing.
+
+> > That's why I said "consider using" ;-)
+>
+> I think Bob makes a good point here.
+> It is sufficiently easy to do this using existing mechanisms that the
+> cost associated with inventing any sort of new mechanism does not seem
+> to be justified (Bob - speak up if I'm misinterpreting your comment).
+
+[Bob wisely remains silent, indicating that Steve understood correctly.  ;-)]
+
+****************************************************************
+
+From: Tucker Taft
+Date: Thursday, March 12, 2009  8:19 PM
+
+> The potential for name pollution comes from the opening of the
+> package, not from the name of the package on its own. If the name is
+> in the source it should be usable, and it should still be possible to
+> use qualified names to retrieve its contents (even if this is
+> redundant). I agree with the other critics of this idea: a name in the
+> source must be usable. Otherwise <> would be the right name, but this
+> has been discarded for other reasons.
+
+Just to be clear, I'm not suggesting the name completely disappears.  I'm
+suggesting that if you "use" the *enclosing* package, and thereby also
+implicitly "use" the inner package, you don't end up with the name of the inner
+package itself directly (use) visible.   For example:
+
+     package P is
+        type S is ...;
+        use package Inner is
+           type T is ...
+        end P;
+        -- At this point "Inner", "S",
+        -- "Inner.T" and simply "T" are all legal names.
+
+     end P;
+
+     -- At this point, "P", "P.S", "P.Inner", "P.Inner.T",
+     -- "P.T" are all legal names.
+
+     use P;
+      -- At this point, in addition to the above, we can
+      -- now use "S" and "T" legally.  My proposal is that
+      -- "Inner" would *not* be directly use-visible,
+      -- but you could still say "P.Inner".
+
+The reason I am recommending this is that I think without it you will have
+trouble using this feature when you are given an abstract spec, and you decide
+the best way to implement it is using one of these "used-at-birth" subpackages.
+
+For example, suppose we define a package spec in the Ada standard, or the ASIS
+standard.  It turns out it can be nicely implemented by one or more
+used-at-birth package instantiations, package renames, or nested packages.
+Unfortunately, if someone does a "use" of this package, some user code might not
+compile which should compile, because of the "extra" identifiers introduced by
+these used-at-birth packages.  To avoid this problem, the implementor will have
+to pick names that are unlikely to collide with any names used by clients,
+meaning that every conscientious user of this feature will find themselves using
+stupid-looking intentionally-unlikely names on all such used-at-birth packages.
+By simply saying that the name of a used-at-birth subpackage doesn't get made
+use-visible when the enclosing package is used, we eliminate this need to use
+bogus-looking names.
+
+****************************************************************
+
+From: Jean-Pierre Rosen
+Date: Friday, March 13, 2009  3:30 AM
+
+> I think the namespace pollution issue is a big one.  If we don't do
+> this, I foresee people using all kinds of weird names to try to be
+> sure they don't have any collisions, and that seems like a waste of
+> time and something that will make such packages look bogus.  Hiding
+> the name of the subpackage itself from use visibility, for a
+> subpackage that is "used at birth"
+> (or "always open") feels like a much cleaner approach, and allows the
+> user to pick a name for the subpackage that is descriptive rather than
+> intentionally obscure.  I don't see it as "irregular"
+> but rather I see it as a fairly natural consequence of having its
+> contents always use-visible.
+
+If you think the name of the package itself is not useful, why not make the
+package anonymous, as I suggested earlier? i.e. instead of "use package Blah is
+", just say "package is", and such a package would automatically be "open".
+
+****************************************************************
+
+From: Edmond Schonberg
+Date: Friday, March 13, 2009  8:44 AM
+
+Jean-Pierre's latest suggestion that the fictitious package should have no name
+brings us back to the beginning: replace "use package"  with "private" and what
+we have is the multiple private parts proposal, with fewer characters.  In fact
+this is the full semantic contents of the "use package" proposal:  a way of
+slipping in interspersed visible and private parts.  If this is the desired
+effect we might as well go with it rather than define strange semantics for
+"almost invisible" inner packages.  The implementation costs might be even
+smaller.
+
+****************************************************************
+
+From: Steve Baird
+Date: Friday, March 13, 2009  9:07 AM
+
+> If you think the name of the package itself is not useful, why not
+> make the package anonymous, as I suggested earlier? i.e. instead of
+> "use package Blah is ", just say "package is", and such a package
+> would automatically be "open".
+
+Someone pointed out that there are problems with providing the body for an
+anonymous package, particularly if you declare more than one in the same
+enclosing package.
+
+****************************************************************
+
+From: Bob Duff
+Date: Friday, March 13, 2009  7:09 AM
+
+> For example, suppose we define a package spec in the Ada standard, or
+> the ASIS standard.  It turns out it can be nicely implemented by one
+> or more used-at-birth package instantiations, package renames, or
+> nested packages.  Unfortunately, if someone does a "use" of this
+> package, some user code might not compile which should compile,
+> because of the "extra" identifiers introduced by these used-at-birth
+> packages.  To avoid this problem, the implementor will have to pick
+> names that are unlikely to collide with any names used by clients,
+> meaning that every conscientious user of this feature will find
+> themselves using stupid-looking intentionally-unlikely names on all
+> such used-at-birth packages.  By simply saying that the name of a
+> used-at-birth subpackage doesn't get made use-visible when the
+> enclosing package is used, we eliminate this need to use bogus-looking
+> names.
+
+I find this argument convincing.  In fact, in this scenario, even a
+stupid-looking name is technically in violation of the ASIS standard.
+
+Can you tell us what the problem is with your "use package <> is" idea?
+I assume the same issues would apply to J.P.'s proposed syntax "package is"
+(which seems preferable -- we got enough <>'s in the syntax!).
+
+****************************************************************
+
+From: Tucker Taft
+Date: Friday, March 13, 2009  12:22 PM
+
+The problem with "package <> is" comes when you get to the body.  If there is
+more than one, things are ambiguous.  Also, Erhard made a convincing argument
+that if you use unnamed packages, there really is no good way to workaround
+collisions that might come up due to multiple "use" clauses.  With a name for
+these packages, you can at least give a full expanded name in the case of a
+collision.
+
+****************************************************************
+
+From: Tucker Taft
+Date: Friday, March 13, 2009  3:43 PM
+
+I just ran into another potential use for this feature.  Periodically I want to
+define a new generic package which has somewhat different formal parameters than
+an existing generic, but declares essentially the same types and operations.
+
+This could be done quite easily with this proposed feature:
+
+  given an existing generic:
+
+    generic
+        type T is private;
+        with procedure Op(...);
+        Blah : in T;
+    package Old_Generic is
+        type Container is private;
+        ...
+    end Old_Generic;
+
+  Presume I want to create a version of the generic that
+  only takes derivatives of P.T as the formal type,
+  and has fewer generic formals:
+
+    with P;
+    generic
+       type T is new P.T;
+    package New_Generic is
+       use package Instance is
+         new Old_Generic(T, Op => P.Op1, Blah => T(P.Val));
+    end New_Generic;
+
+Very elegant, in my view.  In the current language you end up having to repeat
+the entire package spec, and then in the private part or body instantiate the
+old generic, and define each of the operations via renaming or wrapping of the
+old one.
+
+(This is another example of where you really have no interest in having the name
+"Instance" be made directly visible when you apply a "use" clause to some
+instance of New_Generic, though I promise that wasn't the point of the
+example... ;-)
+
+****************************************************************
+
+From: Steve Baird
+Date: Friday, March 13, 2009  4:14 PM
+
+> Very elegant, in my view.
+
+Typos aside, I agree.
+This could be a useful idiom.
+
+> In the current language you end up having to repeat the entire package
+> spec, and then in the private part or body instantiate the old
+> generic, and define each of the operations via renaming or wrapping of
+> the old one.
+>
+> (This is another example of where you really have no interest in
+> having the name "Instance" be made directly visible when you apply a
+> "use" clause to some instance of New_Generic, though I promise that
+> wasn't the point of the example... ;-)
+
+Until you want to instantiate a generic which takes a formal instance of
+Old_Generic. This is really more of an argument against making the name
+completely unavailable, as opposed to your proposal which only makes it
+unavailable via a use clause.
+
+****************************************************************
+
+From: Bob Duff
+Date: Friday, March 13, 2009  4:56 PM
+
+> Very elegant, in my view.
+
+Yes, very nice.
+
+****************************************************************
+
+From: Randy Brukardt
+Date: Thursday, March 19, 2009  12:25 AM
+
+...
+> >> 2) Allow "use" in front of a package rename, with the effect of
+> >> "open"ing the named package.
+> >> ...
+> >
+> > Is it clear that we need this generality?
+> >
+> > This would require adding wording to cope with various pathological
+> > cases that this would make possible (e.g. a rename of a limited view
+> > of a package, a rename of a package whose spec encloses the rename).
+>
+> Why are these pathological?  Can you explain what makes them worse
+> than a rename followed by a normal "use" of the package?  (My mind
+> isn't as fiendish as yours, I suspect.)
+
+The problem I see here is that we decided we didn't like "use all pack;" because
+of issues with re-exporting existing packages (rather than new, as in an
+instance or nested package).
+
+We didn't like:
+   with Bar;
+   package Glarch is
+      use all Bar;
+   end Glarch;
+
+But Tucker wants to allow:
+   with Bar;
+   package Glarch is
+      use package Foo renames Bar;
+   end Glarch;
+
+I have an amazingly hard time figuring the (semantic) difference between these
+two, except that we now have a name Glarch.Foo. That doesn't seem to be an
+improvement over "use all Bar"!
+
+---
+
+The annoying thing here is I didn't record in the minutes precisely why we
+thought this was distasteful. All I have is:
+
+There is some discomfort with the idea that this essentially forces a use clause
+into clients of a package. Use-adverse programmers will not be happy. It seems
+especially weird when it is used on a package that is defined outside of the
+current unit.
+
+Based on this, I'm confused. If we don't find the latter example distasteful,
+then I don't see how we can find the former example distasteful, either. So then
+we should simply go back to "use all Pack", because it surely looks simpler to
+me than this funny prefix.
+
+Otherwise, "use" should not be allowed on renames.
+
+****************************************************************
+
+

Questions? Ask the ACAA Technical Agent