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

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

--- ai05s/ai05-0135-1.txt	2009/10/23 06:06:31	1.9
+++ ai05s/ai05-0135-1.txt	2009/11/04 06:26:38	1.10
@@ -7205,3 +7205,775 @@
 as preferable to the "package <> is ... end <>;"
 
 ****************************************************************
+
+From: Steve Baird
+Sent: Thursday, October 29, 2009  7:40 PM
+
+I have an action item from Brest to do something with this AI, so here we go.
+
+Based on the discussions since Brest, it seems that we have two major questions
+to resolve:
+
+   1) Anonymous vs. named integrated packages. Should the
+      non-integrated view of an integrated package be
+      nameable? Should we support both ways?
+
+   2) Implicit rename declarations vs. use-visibility.
+      Do we want to (in some cases, at least) go with
+      implicit renames, possibly with the addition of
+      some rules to allow collisions between homographic
+      renames of the same thing?
+
+As with any AI, there is also the question of "should we do nothing?". Doing
+nothing could only make sense if we adopt some other solution to the early
+instantiation problem.
+
+The current writeup of the AI has named integrated packages and use-visibility.
+
+As an alternative, I'll sketch out the opposite combination, anonymous
+integrated packages with implicit renames.
+
+I would like to reach a consensus regarding which direction we want to proceed
+with this one.
+
+I'm leaning towards named packages (when you make something anonymous, you
+discover later that you want to name it) with implicit rename declarations.
+
+========
+
+!proposal
+A package or package rename which is declared immediately within the visible
+part of an enclosing package may be declared with a non-identifier in place of
+the package identifier. This may be either "<>" or a bracketed identifier such
+as "<Foo>". 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. The integrated package itself is anonymous and
+cannot be named, even from within itself.
+
+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
+      package <> is type T is private; private ...; end <>;
+      package <> is new Some_Container_Generic (T);
+      - exports type Valise
+   end Pkg;
+
+   with Pkg;
+   package Client is
+       X : Pkg.T;
+       Y : Pkg.Valise;
+   end Client;
+
+Two integrated packages declared within the same declarative region are required
+to have distinct non-identifiers unless at least one of the two declares a
+package rename or an instance of a generic package. This is needed in order to
+map a package body to its corresponding specification. The body for one of these
+guys cannot be a separate subunit.
+
+For each visible declaration in the visible part of an integrated package, there
+is an implicit rename declaration renaming that declaration immediately
+following the declaration of the integrated package. A type or subtype
+declaration is "renamed" via a constraintless subtype declaration. No rename is
+generated for an incomplete type declaration. Renames are generated for
+enumeration literals. Renames are generated for (visible) implicitly declared
+declarations. Renames of subprograms preserve default parameter values. A
+package rename may be integrated, in which case renames/subtypes are generated
+for the visible declarations of the renamed package. The dynamic semantics of a
+package declaration (e.g., its elaboration and finalization) are unaffected by
+whether or not it is integrated.
+
+Immediately after the implicit declarations associated with an integrated
+package, a check for violations of the no-homographs rule in the enclosing
+declarative region is performed. If a pair of illegal homographs is detected
+such that exactly one of the two is among the set of just-added implicit
+rename/subtype declarations, then that one is cast into the pit of darkness,
+never to be seen again (thereby averting the illegal homograph collision). If an
+implicit rename/subtype declaration survives this test, then a subsequent
+homograph conflict involving that declaration is a hard error.
+
+   package P1 is
+      Foo : Integer;
+      package <> is
+         Foo : Float;
+      end <>;
+      -- ok; P1.Foo is of type Integer
+   end P1;
+
+   package P2 is
+      package <> is
+         Foo : Float;
+      end <>;
+      Foo : Integer; -- illegal
+   end P2;
+
+   package P3 is
+      package <1> is
+         Foo : Integer;
+      end <1>;
+      package <2> is
+         Foo : Float;
+      end <2>;
+      -- ok; P3.Foo is of type Integer
+   end P1;
+
+An integrated package is treated like an unnamed block statement for purposes of
+Ada.Tags.Expanded_Name and friends.
+
+Renames are generated only for the declarations that are visible at the point of
+an integrated package rename declaration. Thus,
+
+    package P is
+       X : Integer;
+    end P;
+
+    package P.Child
+       ...;
+    end P.Child;
+
+    with P;
+    package Q is
+       package <> renames P;
+       -- implicitly declares Q.X
+    end Q;
+
+    with P.Child;
+    with Q;
+    package Q_Client is
+       Y : Integer renames Q.X; -- ok
+       package Goof renames Q.Child; -- illegal
+    end Q_Client;
+
+!discussion
+
+Is there any reason to allow/disallow an integrated package declared immediately
+within another integrated package?
+
+There was discussion earlier of some sort of relaxed homograph checking mode
+which would allow homographic renames if they renamed the same thing. It appears
+that the "cast them into the pit of darkness" mechanism has eliminated the need
+for this. Do folks agree? The "renames the same thing" test might be useful in
+helping a compiler decide whether to emit a warning message about a discarded,
+but that's not part of the language definition. Alternatively, the rule stated
+above could be tightened up so that package P3 above would be illegal, but we
+would still allow
+
+    package P4 is
+       package <1> is
+          C_E : exception renames Constraint_Error;
+       end <1>;
+       package <2> is
+          C_E : exception renames Constraint_Error;
+       end <2>;
+       -- ok: P4.C_E denotes Constraint_Error
+    end P4;
+
+The idea is that a declaration would be discarded (thereby averting an illegal
+homograph collision) only if the declaration that it conflicts with denotes the
+same thing (after looking through renames), as well as perhaps passing other
+tests (e.g., default parameters agree for a subprogram rename). This would
+result in less discarding, more homograph collisions, and perhaps more readable
+code.
+
+We probably want to disallow integrated renames of enclosing packages, just
+because they add complexity without adding utility.
+
+A limited view of a package doesn't see integrated packages at all; if it's good
+enough for instances ...
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Thursday, October 29, 2009  8:28 PM
+
+The idea of putting the identifier inside "<>" is very clever.  It provides some
+additional interesting alternatives.  In particular, it allows us to establish
+special rules for these identifiers. For example, we considered allowing them to
+be usable in expanded names, but never become directly "use" visible.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Thursday, October 29, 2009  8:57 PM
+
+...
+> There was discussion earlier of some sort of relaxed homograph
+> checking mode which would allow homographic renames if they renamed
+> the same thing. It appears that the "cast them into the pit of
+> darkness" mechanism has eliminated the need for this.
+
+I would agree, but I don't think the "pit of darkness" model works in all cases.
+
+For instance, if you have two containers of different kinds, you're going to
+want to somehow get at both cursor types. But its quite possible that other
+operations that you care about wouldn't conflict, or would be redefined.
+
+So I think there needs to be a shorthand which allows renaming items that
+otherwise would end up in the "pit", without having to rename the entire
+contents of a potentially large package. (We talked about this privately, but
+since it has disappeared and it is a critical part of the model, IMHO.)
+
+For instance, consider something like:
+
+    package Test is
+        package <> is
+           type T is private;
+           ...
+        end <>;
+
+        package <> is new Ada.Containers.Vector (T, Natural);
+        package <> is new Ada.Containers.Map (T, String);
+    end Test;
+
+Here, the second type Cursor would disappear (or become illegal), and both
+probably is not what you want. Which would then force you back to the same old
+solutions that don't work very well.
+
+But if you could say something like:
+    renames Cursor => Map_Cursor, No_Cursor => Map_No_Cursor,
+
+Then the problem goes away (everything else you want is overloadable).
+
+    package Test is
+        package <> is
+           type T is private;
+           ...
+        end <>;
+
+        package <> is new Ada.Containers.Vector (T, Natural);
+        package <> is new Ada.Containers.Map (T, String)
+           renames Cursor => Map_Cursor, No_Cursor => Map_No_Cursor;
+    end Test;
+
+It also means that you can use a stricter legality model such as the alternative
+you outlined (which seems much less error prone - I don't like the idea that
+moving a declaration could cause something unrelated [and not clearly declared]
+to become invisible - isn't that a form of Beaujolais??).
+
+Other thoughts: perhaps we should require an identifier in the <>? One could
+imagine that identifier being available in local expanded names (that is, in the
+package body). And that would eliminate any problem with body matching and the
+like -- you could have as many of these as you want.
+
+---
+
+> I'm leaning towards named packages (when you make something anonymous,
+> you discover later that you want to name it)
+
+I don't mind the idea of naming them, so long as the name is *never* visible
+outside of the package itself. Otherwise, you bring up all of the problems of
+controlling the client view (and the impossibility of maintenance that changes
+that view).
+
+****************************************************************
+
+From: Brad Moore
+Sent: Saturday, October 31, 2009  7:23 PM
+
+> But if you could say something like:
+>     renames Cursor => Map_Cursor, No_Cursor => Map_No_Cursor,
+>
+> Then the problem goes away (everything else you want is overloadable).
+>
+>     package Test is
+>         package <> is
+>            type T is private;
+>            ...
+>         end <>;
+>
+>         package <> is new Ada.Containers.Vector (T, Natural);
+>         package <> is new Ada.Containers.Map (T, String)
+>            renames Cursor => Map_Cursor, No_Cursor => Map_No_Cursor;
+>     end Test;
+
+
+I had been thinking about this over the summer and arrived at something very
+similar to this as well. The idea of being able to supply renames, for types,
+enumerations, objects, etc to eliminate conflicts for anonymous packages.
+
+Another issue with generics in general that is addressed by this approach:
+
+I was also thinking that the names in a generic package have to be generic, but
+when you want to instantiate a generic, it would be nice to supply names that
+are more specific, so that the client can use names that more closely fit the
+abstraction.
+
+For example, instead of List, you might want to see Grocery_List, or
+List_Of_Ingredients.
+
+I arrived at a syntax for generating renames for a package. The idea was to use
+the <> as a place holder in the renames. This placeholder represents the
+original name from the package you are integrating.
+
+You could give renames for specific entities, or you could also apply this "wild
+card" approach.
+
+For the containers example, I might use:
+
+
+      package Test is
+          package <> is
+             type T is private;
+             ...
+          end <>;
+
+          package <> is new Ada.Containers.Doubly_Linked_List (T)
+             with renames (Empty_List => Empty_Grocery_List,
+                           No_Element => No_Grocery_Element,
+                           Others => Grocery_<>);
+
+          package <> is new Ada.Containers.Doubly_Linked_List (T)
+            with renames (Empty_List => Empty_Ingredient_List,
+                          No_Element => No_Ingedient,
+                          Others => <>_Of_Ingredients);
+
+          X : List_Of_Ingredients;
+          Y : Grocery_List;
+
+      end Test;
+
+In this model, I was thinking that there should be no pit of despair.
+Conflicts should not be allowed period, as hopefully this mechanism would
+provide sufficient flexibility to eliminate all conflicts.
+
+With this scheme, we probably would want to avoid using "renames" to do a
+package renames, because you might end up with two "renames" in the same
+declaration. In that case, I would suggest we not use the "renames" for the
+package renames, but just eliminate the word "new", as in
+
+          package P is
+             type T is null record;
+          end P;
+
+          with P;
+          package Q is
+             package <> is P
+                with renames (Others => Cup_Of_<>ea);
+          end Q;
+
+I think this helps, but ideally we could reduce the usage of <> as well.
+
+Perhaps "Use" could be used for the anonymous package rename, and reserver the
+<> for the rename wildcards. Or (dare I say) add a new reserved word such as
+"blend" which implies you are integrating something, and hopefully a word like
+blend is not too likely to conflict with existing usage.
+
+eg.
+
+      package Test is
+          blend package foo is
+             type T is private;
+             ...
+          end foo;
+
+          blend new Ada.Containers.Doubly_Linked_List (T)
+             with renames (Empty_List => Empty_Grocery_List,
+                           No_Element => No_Grocery_Element,
+                           Others => Grocery_<>);
+
+          -- or is "use" preferable?
+          use new Ada.Containers.Doubly_Linked_List (T)
+            with renames (Empty_List => Empty_Ingredient_List,
+                          No_Element => No_Ingedient,
+                          Others => <>_Of_Ingredients);
+
+          X : List_Of_Ingredients;
+          Y : Grocery_List;
+
+      end Test;
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Saturday, October 31, 2009  8:03 PM
+
+Wouldn't it be simpler if you could just use a regular rename?
+E.g.:
+
+    package <T_Maps> is new Ada.Containers.Maps(T, Natural);
+    subtype Map_Cursor is T_Maps.Cursor;
+    No_Cursor : Map_Cursor renames T_Maps.No_Cursor;
+
+It seems like allowing the name to be used in certain circumstances, at least
+inside the package, is simpler than inventing more new syntax, such as for
+renaming.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Saturday, October 31, 2009  11:13 PM
+
+True, but that means that you have to *allow* what Steve called the "pit of
+despair", essentially names that are hidden from all visibility. As Brad
+mentions, that rule is better off not existing. The problem is that maintenance
+that added one or more declarations on one of the generic packages could cause
+declarations in some unrelated anonymous instance far away to disappear and
+cause errors. ("unrelated" other than accidental proximity.)
+
+The whole reason that I am pushing for these "integrated packages" to be
+anonymous is to avoid maintenance hazards. It doesn't help much to push the bump
+around (in that case, we're better off just living with the problems and the
+imperfect solutions).
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Sunday, November 1, 2009  10:02 AM
+
+Isn't this the same thing that happens with "use" visibility, namely that if you
+change one package spec, other packages also "use"d in the same scope will
+suddenly lose declarations? I don't see why this problem is any worse.  Perhaps
+you could give a more concrete example to explain the problem.
+
+I also couldn't tell from your response why the proposal for using "regular"
+renames was related to this issue of "despair."
+
+****************************************************************
+
+From: Brad Moore
+Sent: Sunday, November 1, 2009  11:11 AM
+
+I think the "regular" renames proposal almost works, but not quite.
+For this to work comparable to the renaming idea, I am thinking that;
+
+1) If there are conflicts, all conflicting names are thrown into the pit of
+despair, not just the 2nd occurrence.
+
+2) To get the code to compile, all conflicts need to be resolved by "fishing"
+things out of the pit of despair using renames, until there are no conflicts.
+Once you are down to a conflict between two uses, fishing one of the uses out of
+the pit, brings the remaining use out of the pit as well, because there no
+longer would be a conflict.
+
+3) To fish a type name out of the pit of despair, would require a type rename. A
+subtype declaration doesn't cut it, because that doesn't fish out all the other
+things associated with the type. Unfortunately, type renames do not exist today.
+That is the missing piece of the puzzle I think.
+
+So I think you could accomplish the same ends using the "renaming approach" if
+we find a way to do type renames, or you could go with an approach along the
+lines of what Randy and I are suggesting, which gives you another way to get
+type renames.
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Sunday, November 1, 2009  11:33 AM
+
+I don't understand why a subtype declaration wouldn't work. Are you saying the
+type's primitive operations are somehow tied to whether the type's name
+conflicts?  That seems weird.
+
+****************************************************************
+
+From: Brad Moore
+Sent: Sunday, November 1, 2009  12:17 PM
+
+Maybe (more likely) I am not understanding something about the regular renaming
+idea.
+
+I was thinking that a subtype declaration would not count as a substitute for a
+type rename, because it doesn't give you things like enumeration literals,
+exceptions, class-wide operations. It's the same reason why we sometimes derive
+a new type (as a kludge) rather than use a subtype declaration. You could create
+renames for all of those as well, (or deriving new types) but then you might as
+well be doing the package integration all by hand at that point. It seems to me
+that once you start deriving new types, you no longer are integrating a package,
+but creating a new one.
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Sunday, November 1, 2009  1:01 PM
+
+Well maybe *I'm* missing something, but I presumed that everything in the
+"integrated" package was made visible in the enclosing scope, unless there was
+some kind of conflict.  So all of those enumeration literals, exceptions, etc.,
+have already been made visible in the enclosing scope, even if the type name
+happens to conflict.  So a subtype declaration for the type name is all you need
+to do.  All of the other things, presuming they didn't conflict, are already
+there, even if their type isn't directly nameable.
+
+****************************************************************
+
+From: Brad Moore
+Sent: Sunday, November 1, 2009  1:23 PM
+
+True, but I am thinking conflicts for other things could end up being quite
+common. Suppose you have a package that wants to instantiate the same generic
+with two different types. The whole 2nd instance would end up being in the pit
+of despair, correct? Or suppose you have a set of container libraries that have
+similar names for objects (Like Cursor, No_Element, etc) so they can be used
+more interchangeably. (Like our standard containers) Two Container
+instantiations in the same package, even if they are different containers could
+end up conflicting quite a bit.
+
+I was thinking after I sent my last email that I should have included an
+example. So here it is.
+
+
+generic
+    type F is tagged private;
+package P is
+    -- Enumeration Literals
+    type E is (This, That, Other_Thing);
+
+    type T is new F with null record;
+    function Process (Item : T) return Boolean;
+
+    -- Classwide Operation
+    function Compare (L, R : T'Class) return Boolean;
+
+    -- Exception
+    Red_Alert : exception;
+
+end P;
+
+
+-- My understanding of the renames approach
+
+with P;
+package Q is
+   type T1 is null record;
+   type T2 is null record;
+
+   package <> is new P(T1);
+   package <Foo> is new P(T2);
+   -- At this point all of the second instance is in the pit of despair,
+   -- correct?
+   subtype Foo_T2 is Foo.T; -- This gives me T, but about T'Class
+   type Foo2_T2 is new Foo.T with null record;
+    -- OK, now I have T'Class but had to derive a new type.
+    -- I dont really have Foo.T
+
+   type Foo_E is new Foo.E;
+   Foo_Red_Alert : exception renames Foo.Red_Alert;
+
+   -- The more declarations in P, the more renames we need.
+end Q;
+
+
+-- The approach I was suggesting.
+
+Or if you go with what I was suggesting, this becomes the following; Note that
+the following scales better than the above. The more declarations in P, might
+not involve adding any more declarations to the following
+
+with P;
+package Q is
+   type T1 is null record;
+   type T2 is null record;
+
+   use new P(T1);
+   use new P(T2) with renames (Others => Foo_<>); end Q;
+
+
+-- Example usage
+with Q;
+procedure Main is
+   X : Q.T;
+   Y : Q.Foo_T;
+   Z : Q.Foo_E;
+begin
+   case Z is
+      when Q.This =>
+        null;
+      when Q.That =>
+        null;
+      when Q.Other_Thing =>
+        null;
+   end case;
+end
+
+Hmmm. Would the enumeration literals resolve correctly to the correct version? I
+am thinking they would because Z is of a specific type.
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Sunday, November 1, 2009  1:49 PM
+
+This feels a bit like we are just "making stuff up."
+I think we should be looking for minimal syntax and semantic invention here.
+
+But back to our specific issue:
+
+I presume that things that are overloadable would not be considered conflicts,
+in the same way they don't conflict as far as use-visibility.  Since we are
+trying to do away with having to use a type derivation and all the confusion
+that creates, the only thing that would ever need renaming that is *not*
+overloadable, among those things provided by a derived type, is the type name
+itself.  You currently don't get exceptions, generics, etc. when you do a type
+derivation, so I believe my claim that a subtype declaration is just as good as
+a type "renaming" in this context is correct.
+
+And the integrated package is clearly better than type derivation because you
+*do* get exceptions, generics, etc., presuming they don't conflict. But if we
+start doing wholesale renaming of the entire contents to deal with conflicts of
+non- overloadables, then why bother?  Using a subpackage name is probably just
+as convenient.
+
+I would say having two integrated instances of the same package in the same
+scope is not the primary purpose of this feature, and presuming you have some
+sort of a name for the integrated subpackages that can at least be used locally,
+then selective, "targeted" renaming is adequate to deal with that case.
+Wholesale renaming just doesn't make sense to me.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Monday, November 2, 2009  6:03 PM
+
+> Isn't this the same thing that happens with "use" visibility, namely
+> that if you change one package spec, other packages also "use"d in the
+> same scope will suddenly lose declarations?
+> I don't see why this problem is any worse.  Perhaps you could give a
+> more concrete example to explain the problem.
+>
+> I also couldn't tell from your response why the proposal for using
+> "regular" renames was related to this issue of "despair."
+
+It is similar to the problem of "use" visibility, but it is worse because it is
+forced on clients by the design of the packages (rather than by their own use of
+"use").
+
+Something I just realized this morning in thinking about this question (which I
+read last night but didn't answer due to the lateness of the hour) is that a
+major reason that I am mostly use-adverse is the maintenance hazard that "use"
+causes. That is, adding a declaration somewhere can make something unrelated
+disappear. I hadn't realized until today that this is why I don't mind "use"
+clauses of overloadable entities as much (especially operators and enumeration
+literals) -- they are far less likely to run into this "maintenance
+disappearance" because it only happens when the profiles are identical. (And
+that's pretty weird.) For non-overloadable entities, it happens even when the
+two items could never be confused by a human (such as an exception and a
+function).
+
+Currently, programmers can decide how much of this maintenance hazard they are
+willing to risk, by choosing how much to use "use" clauses and directly visible
+names, and how much to use fully-qualified names (FQNs). Even when you do have a
+use clause, you can avoid the maintenance hazard by using an FQN.
+
+But that isn't true if you have Steve's "pit of despair", any version. The name
+disappears even when you do use an FQN, since the integrated package name isn't
+available for use (and that itself is important for maintenance, so that clients
+cannot depend on whether an integrated package is used, or a set of direct
+declarations, or a set of renames of a nested package -- they all work the same
+to a client -- allowing the implementation to be changed if necessary).
+
+Let me try to give a simple example:
+
+    generic
+    package G1 is
+       Foo : Integer;
+       --Bar : Integer; -- (1)
+    end G1;
+
+    with G1;
+    package Test is
+        package <I1> is new G1;
+        package <N1> is
+            Bar : Float; -- (2)
+        end <N1>;
+    end Test;
+
+    with Test;
+    procedure Main is
+        function Is_Groddy (I : Integer) return Boolean is ...
+        function Is_Groddy (F : Float) return Boolean is ...
+    begin
+         if Is_Groddy (Test.Bar) then -- (3)
+             ...
+    end Main;
+
+As written, (3) resolves to the float Bar declared at (2).
+
+Let's look at what happens if the declaration of Bar at (1) is added.
+
+With Steve's original proposal, which is order-based, the Bar at (1) becomes
+automatically renamed because of the integrated package <I1>. Then, because a
+homograph already exists when integrating <N1>, the Bar at (2) is cast into the
+pit of despair (which really means it is hidden from all visibility, or even
+more simply, it isn't declared). The problem here is that we have a first-class
+Beaujolias effect: the call at (3) changes silently from using object (2) to
+using object (1). (Of course, it is more likely to cause some sort of error, but
+I wanted to show the worst case.) I believe that is unacceptable, so I won't
+spend any more time on Steve's first idea.
+
+Another idea is to revert to use-like visibility for integrated packages. That
+is, *both* names Bar are tossed into the pit of despair and neither is visible
+in Test (this has strange semantics, because after <I1> and before <N1>, there
+is a point where Bar is directly visible in Test, and then is later disappears).
+That makes the name Test.Bar at (3) illegal, because there are two homographs
+meaning that neither is visible. I find this obnoxious, because the change is
+completely unrelated to the package where the error occurred. The writer of this
+code doesn't care at all about the <I1> potion of Test; moreover the maintainer
+of G1 probably doesn't know that users of Test will be impacted by a seemingly
+unrelated change. Also note that the writer of Main tried to avoid exactly this
+sort of effect by not using a use-clause -- yet they end up with one of the
+worst side-effects of use clauses simply because some other author used
+integrated packages.
+
+Note that in this case there is no obvious repair. We can't easily change
+anything to make Bar properly visible. If we have Tucker's suggested local names
+for these packages, we could rename the two Bars to something else, but of
+course that would force all of the clients to be changed. I suppose with a
+complex enough definition of what happens to these homographs we might be able
+to allow an explicit renaming to Bar (that is Bar : Float renames N1.Bar;), but
+that seems pretty complex to me.
+
+The rule I was advocating was that if there are conflicting homographs, then the
+program is simply illegal. Steve notes that is necessary anyway when there are
+explicit declarations of things, so I'm actually suggesting a simpler rule: no
+conflicts. Then the maintenance hazard is at least closer to the original cause.
+
+In that case, adding Bar to G1 would make package Test illegal.
+
+Now, we need a way to work around that restriction when it unavoidably happens
+(such as when two different containers are instantiated). That's why I suggested
+supporting renaming as part of integrated packages. If you had added Bar to G1,
+all you would need to do to make Test legal again (and not change any of Test's
+clients) would be to add an appropriate rename. Using the syntax that Brad
+suggested (a bit better than mine):
+
+    with G1;
+    package Test is
+        package <I1> is new G1
+            with renames Bar => Soap_Bar;
+        package <N1> is
+            Bar : Float;
+        end <N1>;
+    end Test;
+
+And now there aren't any homographs and the program is legal. In addition, no
+clients need to change.
+
+Note that this renaming facility is mainly aimed at non-overloadable entities,
+so we don't need any profile information.
+
+This also means that the name <N1> does not need to be visible outside of the
+package <N1> itself, which seems to be a simpler rule to me than trying to allow
+it to be used in its parent unit (only). It avoids having to answer the question
+as to whether N1 is visible in a child of Test, for instance.
+
+Anyway, much food for thought. I've got to get all of the work done to prepare
+for this meeting, so I can't spend any more time discussing this until I see you
+on Thursday.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Monday, November 2, 2009  7:35 PM
+
+> But that isn't true if you have Steve's "pit of despair", any version ...
+
+Steve points out that the correct term is "pit of darkness". I apparently was
+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.
+
+****************************************************************

Questions? Ask the ACAA Technical Agent