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

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

--- ai05s/ai05-0135-1.txt	2009/06/02 06:22:37	1.8
+++ ai05s/ai05-0135-1.txt	2009/10/23 06:06:31	1.9
@@ -5062,7 +5062,8 @@
 
 One would hope that this is illegal, because we don't allow any other "use"
 clauses on limited views of packages. I don't see any reason whatsoever for this
-to be different. (The problems shown in this example illustrate why that's the case.)
+to be different. (The problems shown in this example illustrate why that's the
+case.)
 
 ----
 
@@ -5076,12 +5077,12 @@
       end Inner;
    end Pkg;
 
-and mention that you would like to be able to make the name Not_Primitive visible
-directly in Pkg. But this is exactly one of the sorts of effects that bothers me
-about this proposal. Clients cannot ignore the presence of the nested package, because
-its effects re-emerge periodically. This is one of those cases: the primitiveness changes,
-so for the purposes of deriving a type from T, you have to know the *real* structure of
-the package.
+and mention that you would like to be able to make the name Not_Primitive
+visible directly in Pkg. But this is exactly one of the sorts of effects that
+bothers me about this proposal. Clients cannot ignore the presence of the nested
+package, because its effects re-emerge periodically. This is one of those cases:
+the primitiveness changes, so for the purposes of deriving a type from T, you
+have to know the *real* structure of the package.
 
 ----
 
@@ -5108,28 +5109,29 @@
 
 the supposedly "integrated" package reappears.
 
-This also happens when there are use-conflicts, even if those conflicts are within a
-single package specification.
+This also happens when there are use-conflicts, even if those conflicts are
+within a single package specification.
 
 ----
 
-You can also name the inner package in a use-clause, giving visibility to only part
-of the supposedly "integrated" whole. This seems bad from the view of a client, which
-really wants to see a real, flat view of the package.
+You can also name the inner package in a use-clause, giving visibility to only
+part of the supposedly "integrated" whole. This seems bad from the view of a
+client, which really wants to see a real, flat view of the package.
 
 Part of the trouble here is the name of this construct: there is nothing really
-"integrated" about these packages. It's really a way to force a use-clause on a client.
-If they were really "integrated", we would see none of the unusual effects seen here.
+"integrated" about these packages. It's really a way to force a use-clause on a
+client. If they were really "integrated", we would see none of the unusual
+effects seen here.
 
 ----
 
-I realize that some differences from a fully flat package are going to be required (else
-you could just declare everything without the nested package). But some of these just seem
-outright wrong.
+I realize that some differences from a fully flat package are going to be
+required (else you could just declare everything without the nested package).
+But some of these just seem outright wrong.
 
 I have to wonder if we can do better. I don't recall anymore why we switched to
-use-visibility for these things; it just seems wrong for many reasons. Perhaps there is
-some way to avoid that??
+use-visibility for these things; it just seems wrong for many reasons. Perhaps
+there is some way to avoid that??
 
 ****************************************************************
 
@@ -5143,10 +5145,10 @@
 > example illustrate why that's the case.)
 >
 
-It's not clear what this construct means, and that's the point (in the context of
-discussing whether integrated package renames are desirable). I agree that this
-probably should be illegal, but that doesn't fall out from the current wording - an
-explicit rule would be needed.
+It's not clear what this construct means, and that's the point (in the context
+of discussing whether integrated package renames are desirable). I agree that
+this probably should be illegal, but that doesn't fall out from the current
+wording - an explicit rule would be needed.
 
 > ----
 >
@@ -5169,14 +5171,15 @@
 > structure of the package.
 >
 
-I agree, although I should point out that this example came up in a "real" context; there
-was a serious question about how to accomplish this effect (an implementation-defined
-Not_Primitive pragma was mentioned as a possible solution).
+I agree, although I should point out that this example came up in a "real"
+context; there was a serious question about how to accomplish this effect (an
+implementation-defined Not_Primitive pragma was mentioned as a possible
+solution).
 
 Nobody is pretending that this construct produces identical results to doing the
-"integration" by hand (although it is interesting to note that trying to rewrite this
-particular example without using this new construct gets a little messy - I think a subtype
-declaration is required).
+"integration" by hand (although it is interesting to note that trying to rewrite
+this particular example without using this new construct gets a little messy - I
+think a subtype declaration is required).
 
 > ----
 >
@@ -5204,17 +5207,19 @@
 > the supposedly "integrated" package reappears.
 >
 
-I think the problems with limited views of integrated packages and package renames are
-dwarfed to the point of insignificance by the existing treatment of limited views of
-instantiations and of ordinary package renames (which I am not arguing against).
+I think the problems with limited views of integrated packages and package
+renames are dwarfed to the point of insignificance by the existing treatment of
+limited views of instantiations and of ordinary package renames (which I am not
+arguing against).
 
-Limited views (technical term) provide a very limited view (common English) of things.
+Limited views (technical term) provide a very limited view (common English) of
+things.
 
 That's ok, we've accepted that.
 
-As the AI mentions, we do have the option of relaxing this limitation and allowing a
-limited view of an integrated package to be integrated in some cases (not for renames,
-not for instances).
+As the AI mentions, we do have the option of relaxing this limitation and
+allowing a limited view of an integrated package to be integrated in some cases
+(not for renames, not for instances).
 
 > This also happens when there are use-conflicts, even if those
 > conflicts are within a single package specification.
@@ -5225,23 +5230,23 @@
 > to only part of the supposedly "integrated" whole. This seems bad from
 > the view of a client, which really wants to see a real, flat view of the package.
 
-The point is that the client has the option of seeing a flat view of the package.
-If the client wants to explicitly disambiguate a name by referencing the inner package,
-that's up to the client. If you want to disallow this, it could, I suppose, be detected
-by some coding-standard-enforcement tool; that is outside of the scope of the language
-definition.
+The point is that the client has the option of seeing a flat view of the
+package. If the client wants to explicitly disambiguate a name by referencing
+the inner package, that's up to the client. If you want to disallow this, it
+could, I suppose, be detected by some coding-standard-enforcement tool; that is
+outside of the scope of the language definition.
 
 > Part of the trouble here is the name of this construct: there is
 > nothing really "integrated" about these packages. It's really a way to
 > force a use-clause on a client. If they were really "integrated", we
 > would see none of the unusual effects seen here.
 
-This is a relatively lightweight solution. The fact that it is based on use-clauses
-definitely does show through in some cases.
+This is a relatively lightweight solution. The fact that it is based on
+use-clauses definitely does show through in some cases.
 
-On the other hand, if this solves the "exporting a private type and a container thereof"
-problem (and I think it does), then that alone is a strong argument for including this
-feature.
+On the other hand, if this solves the "exporting a private type and a container
+thereof" problem (and I think it does), then that alone is a strong argument for
+including this feature.
 
 > ----
 >
@@ -5253,20 +5258,20 @@
 > switched to use-visibility for these things; it just seems wrong for many reasons.
 > Perhaps there is some way to avoid that??
 
-It's often true that as we come to see the problems with one approach in more detail,
-the path that we didn't take starts looking more and more attractive.
+It's often true that as we come to see the problems with one approach in more
+detail, the path that we didn't take starts looking more and more attractive.
 
-As you noted, the early discussions of this AI were based on implicit rename/subtype
-declarations and had nothing to do with use clauses.
+As you noted, the early discussions of this AI were based on implicit
+rename/subtype declarations and had nothing to do with use clauses.
 
-One problem with that approach was collisions. Implicit declarations of non-overloadable
-constructs would have taken some work to straighten out.
+One problem with that approach was collisions. Implicit declarations of
+non-overloadable constructs would have taken some work to straighten out.
 
-Use-visibility provided a reasonable approach to resolving these issues that was already
-a well-defined part of the language,
+Use-visibility provided a reasonable approach to resolving these issues that was
+already a well-defined part of the language,
 
-If you think we should revive the rename/subtype approach or even pursue an entirely new
-solution, either
+If you think we should revive the rename/subtype approach or even pursue an
+entirely new solution, either
     a) provide a reasonably specific alternative that we can discuss or
     b) get more of a consensus from the group that we want to
        at least explore some other alternative and then I'll
@@ -5283,27 +5288,28 @@
 > I agree that this probably should be illegal, but that doesn't fall
 > out from the current wording - an explicit rule would be needed.
 
-Yes, of course such a rule is needed. I've been saying that repeatedly (see my mail
-of December 18th, 2008 and March 12, 2009), and you've never added the rule to the
-actual AI. Please do so (or at least explain what it means to not have it).
-
-Besides, this is a lousy example of why it is not desirable to allow renames. The
-problem is simply that you have declarations appearing in a scope with no sane way to
-determine where they come from.
-
-But that also happens for instantiations, and I no longer see much difference between
-"integrated" renamed packages, and "integrated" instantiations. So the reason *I* was
-objecting to renames has become OBE (can't speak for others); the more important
-question for me is whether this whole idea sacrifices too much readability. (At least
-readability in the absence of a fancy IDE.)
+Yes, of course such a rule is needed. I've been saying that repeatedly (see my
+mail of December 18th, 2008 and March 12, 2009), and you've never added the rule
+to the actual AI. Please do so (or at least explain what it means to not have
+it).
+
+Besides, this is a lousy example of why it is not desirable to allow renames.
+The problem is simply that you have declarations appearing in a scope with no
+sane way to determine where they come from.
+
+But that also happens for instantiations, and I no longer see much difference
+between "integrated" renamed packages, and "integrated" instantiations. So the
+reason *I* was objecting to renames has become OBE (can't speak for others); the
+more important question for me is whether this whole idea sacrifices too much
+readability. (At least readability in the absence of a fancy IDE.)
 
 ...
 > Limited views (technical term) provide a very limited view (common
 > English) of things.
 
-True enough; I've been trying to explain my discomfort with this proposal with things
-that are different, but they don't necessarily seem important. That means my overall point
-is getting lost.
+True enough; I've been trying to explain my discomfort with this proposal with
+things that are different, but they don't necessarily seem important. That means
+my overall point is getting lost.
 
 ...
 > > You can also name the inner package in a use-clause, giving
@@ -5317,12 +5323,13 @@
 > coding-standard-enforcement tool; that is outside of the scope of the
 > language definition.
 
-OK, here is the crux of the problem. As a package designer, I want to *limit* the ways that
-the client can refer to things. Otherwise, package maintenance becomes much harder. For
-instance, with this notion of "integrated" packages, it would be impossible to change back
-to a "flat" structure (because there can be references to the "integrated" package. Nor can
-you change to "integrated" packages from a "flat" structure without introducing incompatibilities.
-That can be bad.
+OK, here is the crux of the problem. As a package designer, I want to *limit*
+the ways that the client can refer to things. Otherwise, package maintenance
+becomes much harder. For instance, with this notion of "integrated" packages, it
+would be impossible to change back to a "flat" structure (because there can be
+references to the "integrated" package. Nor can you change to "integrated"
+packages from a "flat" structure without introducing incompatibilities. That can
+be bad.
 
 > > Part of the trouble here is the name of this construct: there is
 > > nothing really "integrated" about these packages. It's really a way
@@ -5332,17 +5339,17 @@
 > This is a relatively lightweight solution. The fact that it is based
 > on use-clauses definitely does show through in some cases.
 
-Yes, but you've missed my point completely. If you had called it something else (say
-"automatically used packages"), I wouldn't have quite the same objections. The *name*
-"integrated packages" gives an expectation of seamless merging; that isn't happening here,
-so the *name* is causing (unreasonable?) expectations.
+Yes, but you've missed my point completely. If you had called it something else
+(say "automatically used packages"), I wouldn't have quite the same objections.
+The *name* "integrated packages" gives an expectation of seamless merging; that
+isn't happening here, so the *name* is causing (unreasonable?) expectations.
 
 > On the other hand, if this solves the "exporting a private type and a
 > container thereof" problem (and I think it does), then that alone is a
 > strong argument for including this feature.
 
-Surely we need *some* solution to this problem, but I'm not certain this one is better than
-any of the other (now rejected) ideas.
+Surely we need *some* solution to this problem, but I'm not certain this one is
+better than any of the other (now rejected) ideas.
 
 ...
 > As you noted, the early discussions of this AI were based on implicit
@@ -5352,8 +5359,8 @@
 > of non-overloadable constructs would have taken some work to
 > straighten out.
 
-I think such collisions should simply be illegal. Tough if that prevents declaring two container
-instances this way; we don't want homographs.
+I think such collisions should simply be illegal. Tough if that prevents
+declaring two container instances this way; we don't want homographs.
 
 > Use-visibility provided a reasonable approach to resolving these
 > issues that was already a well-defined part of the language,
@@ -5512,8 +5519,8 @@
 From: Tucker Taft
 Sent: Thursday, May 28, 2009  2:12 PM
 
-> Another possible workaround would be to clutter the spec with an 
-> incomplete type List before the nested package. But that could not be 
+> Another possible workaround would be to clutter the spec with an
+> incomplete type List before the nested package. But that could not be
 > completed with the private extension List, so we would still end up with the
 > same problem.
 
@@ -5526,40 +5533,41 @@
 The incomplete types produced from a "limited with" allow that, so the mechanism
 will be needed in Ada 2005 to handle such a completion anyway.
 
-> In conclusion, this rearrangement works, has some client 
-> incompatibility (but it probably isn't important), but forces a major 
-> amount of junk type conversions in the body of the package. Of course, 
+> In conclusion, this rearrangement works, has some client
+> incompatibility (but it probably isn't important), but forces a major
+> amount of junk type conversions in the body of the package. Of course,
 > this is only one example, and it would be nice to look at additional examples
 > in the future.
 
 Normally I would have expected that almost the entire package would be included
-in an "integrated" package, and then this big nested package would be followed by
-various generic instantiations.  But you have illustrated a case where that doesn't
-work, because you want one of the types to be built on the result of a generic
-instantiation.  I wonder how common that is.
-
-How would you do it without this feature?  As you point out, the integrated package
-is mostly just a short-hand for a bunch of renames, and in this case, there aren't
-that many.  Hiding the nested package name automatically from use-visibility might
-be a helpful advantage of the proposed feature ;-).
-
-It does seem the ability to define an incomplete type that is completed by a partial
-view would be helpful, independent of this proposal.
-
-I wonder if your "magic iterator" generic has this problem in general, and perhaps
-it needs to be *defining* a cursor type, rather than taking it as a parameter.  Or
-is it the fact that we want the container to be usable as an iterator?  I think that
-is probably a bad idea in general, as it is inherently problematic to have the container
-carry some state about a particular iterator over the container.  I understand the
-desire for a *syntax* approximating:
+in an "integrated" package, and then this big nested package would be followed
+by various generic instantiations.  But you have illustrated a case where that
+doesn't work, because you want one of the types to be built on the result of a
+generic instantiation.  I wonder how common that is.
+
+How would you do it without this feature?  As you point out, the integrated
+package is mostly just a short-hand for a bunch of renames, and in this case,
+there aren't that many.  Hiding the nested package name automatically from
+use-visibility might be a helpful advantage of the proposed feature ;-).
+
+It does seem the ability to define an incomplete type that is completed by a
+partial view would be helpful, independent of this proposal.
+
+I wonder if your "magic iterator" generic has this problem in general, and
+perhaps it needs to be *defining* a cursor type, rather than taking it as a
+parameter.  Or is it the fact that we want the container to be usable as an
+iterator?  I think that is probably a bad idea in general, as it is inherently
+problematic to have the container carry some state about a particular iterator
+over the container.  I understand the desire for a *syntax* approximating:
 
      for Element in Container loop
         ...
      end loop;
 
-But I see no requirement that this means we somehow have an iterator built into the
-Container itself.  Also, we would certainly want to allow multiple tasks to iterate
-over a Container in parallel, I would think, or to allow nested iterators such as:
+But I see no requirement that this means we somehow have an iterator built into
+the Container itself.  Also, we would certainly want to allow multiple tasks to
+iterate over a Container in parallel, I would think, or to allow nested
+iterators such as:
 
      for Left in Container loop
         for Right in Container loop
@@ -5567,13 +5575,13 @@
         end loop;
      end loop;
 
-I think the above *syntax* should always presume there is an anonymous iterator object
-created, and that is what carries the state of the iteration.
+I think the above *syntax* should always presume there is an anonymous iterator
+object created, and that is what carries the state of the iteration.
 
-In any case, I wonder whether it is the strange nature of this generic that is creating
-the problem, or is there a common need to be able to define in a single package two
-recursively-dependent types one of which is based on a generic instantiation of the other.
-I suppose this is a very hard question to answer...
+In any case, I wonder whether it is the strange nature of this generic that is
+creating the problem, or is there a common need to be able to define in a single
+package two recursively-dependent types one of which is based on a generic
+instantiation of the other. I suppose this is a very hard question to answer...
 
 Thanks for the example!
 
@@ -5583,12 +5591,12 @@
 Sent: Thursday, May 28, 2009  2:49 PM
 
 ...
-> This particular problem seems fixable.  The requirement that an 
-> incomplete type declaration be completed with a full_type_declaration 
-> seems arbitrary.  There seems no inherent reason that it couldn't be 
+> This particular problem seems fixable.  The requirement that an
+> incomplete type declaration be completed with a full_type_declaration
+> seems arbitrary.  There seems no inherent reason that it couldn't be
 > completed with a private type or private extension declaration.
-> The incomplete types produced from a "limited with" allow that, so the 
-> mechanism will be needed in Ada 2005 to handle such a completion 
+> The incomplete types produced from a "limited with" allow that, so the
+> mechanism will be needed in Ada 2005 to handle such a completion
 > anyway.
 
 Yes, I in fact wrote this up originally assuming that such completions were
@@ -5599,57 +5607,57 @@
 doesn't really have anything to do with anything other than the implementation,
 but not a major problem overall.
 
-> > In conclusion, this rearrangement works, has some client 
-> > incompatibility (but it probably isn't important), but forces a 
-> > major amount of junk type conversions in the body of the package. Of 
+> > In conclusion, this rearrangement works, has some client
+> > incompatibility (but it probably isn't important), but forces a
+> > major amount of junk type conversions in the body of the package. Of
 > > course, this is only one example, and it would be nice to look at
 > additional examples in the future.
-> 
-> Normally I would have expected that almost the entire package would be 
-> included in an "integrated" package, and then this big nested package 
-> would be followed by various generic instantiations.  But you have 
-> illustrated a case where that doesn't work, because you want one of 
-> the types to be built on the result of a generic instantiation.  I 
+>
+> Normally I would have expected that almost the entire package would be
+> included in an "integrated" package, and then this big nested package
+> would be followed by various generic instantiations.  But you have
+> illustrated a case where that doesn't work, because you want one of
+> the types to be built on the result of a generic instantiation.  I
 > wonder how common that is.
 
 No idea. It seems to need interfaces to make much sense, so it would mainly
 come up in new code.
 
-> How would you do it without this feature?  As you point out, the 
-> integrated package is mostly just a short-hand for a bunch of renames, 
+> How would you do it without this feature?  As you point out, the
+> integrated package is mostly just a short-hand for a bunch of renames,
 > and in this case, there aren't that many.
-> Hiding the nested package name automatically from use-visibility might 
+> Hiding the nested package name automatically from use-visibility might
 > be a helpful advantage of the proposed feature ;-).
 
-I was surprised to find out that it doesn't seem to matter much either way; the key
-is to use the nested package. Making it "integrated" is just icing.
+I was surprised to find out that it doesn't seem to matter much either way; the
+key is to use the nested package. Making it "integrated" is just icing.
 
-> It does seem the ability to define an incomplete type that is 
-> completed by a partial view would be helpful, independent of this 
+> It does seem the ability to define an incomplete type that is
+> completed by a partial view would be helpful, independent of this
 > proposal.
 
 Yes, I think so.
 
-> I wonder if your "magic iterator" generic has this problem in general, 
-> and perhaps it needs to be *defining* a cursor type, rather than 
+> I wonder if your "magic iterator" generic has this problem in general,
+> and perhaps it needs to be *defining* a cursor type, rather than
 > taking it as a parameter.
 
-I don't know how that could work, given that container cursors include a reference
-to the container object. I suppose the entire thing could be created as a mix-in generic
-(adding to the container directly), but that seems annoying (isn't that exactly the sort
-of thing that interfaces were created to avoid?).
+I don't know how that could work, given that container cursors include a
+reference to the container object. I suppose the entire thing could be created
+as a mix-in generic (adding to the container directly), but that seems annoying
+(isn't that exactly the sort of thing that interfaces were created to avoid?).
 
 > Or is it the fact that
-> we want the container to be usable as an iterator?  I think that is 
-> probably a bad idea in general, as it is inherently problematic to 
-> have the container carry some state about a particular iterator over 
+> we want the container to be usable as an iterator?  I think that is
+> probably a bad idea in general, as it is inherently problematic to
+> have the container carry some state about a particular iterator over
 > the container.
 
 I strongly agree with this, but you need to convince Ed. :-) Maybe the rest of
 your message will help.
 
 > I understand the desire for a *syntax* approximating:
-> 
+>
 >      for Element in Container loop
 >         ...
 >      end loop;
@@ -5663,19 +5671,19 @@
 discriminant reference in those), I don't see the problem. But of course, I
 was always happy with this formulation, it is other people that were not.
 
-> But I see no requirement that this means we somehow have an iterator 
-> built into the Container itself.  Also, we would certainly want to 
-> allow multiple tasks to iterate over a Container in parallel, I would 
+> But I see no requirement that this means we somehow have an iterator
+> built into the Container itself.  Also, we would certainly want to
+> allow multiple tasks to iterate over a Container in parallel, I would
 > think, or to allow nested iterators such as:
-> 
+>
 >      for Left in Container loop
 >         for Right in Container loop
 >            Try_Pair(Left, Right);
 >         end loop;
 >      end loop;
-> 
-> I think the above *syntax* should always presume there is an anonymous 
-> iterator object created, and that is what carries the state of the 
+>
+> I think the above *syntax* should always presume there is an anonymous
+> iterator object created, and that is what carries the state of the
 > iteration.
 
 With the accessor proposal, you have to write a single extra selection; that
@@ -5687,14 +5695,1513 @@
         Container.Accessor(Cursor).Element.Component := 10;
     end loop;
 
-> In any case, I wonder whether it is the strange nature of this generic 
-> that is creating the problem, or is there a common need to be able to 
-> define in a single package two recursively-dependent types one of 
-> which is based on a generic instantiation of the other.  I suppose 
+> In any case, I wonder whether it is the strange nature of this generic
+> that is creating the problem, or is there a common need to be able to
+> define in a single package two recursively-dependent types one of
+> which is based on a generic instantiation of the other.  I suppose
 > this is a very hard question to answer...
 
 I would expect a similar problem any time that you wanted to define an interface
-that needs customization with some properties. But it is hard to tell for sure, other
-than to say that designers are clever and come up with structures that no one expects.
+that needs customization with some properties. But it is hard to tell for sure,
+other than to say that designers are clever and come up with structures that no
+one expects.
+
+****************************************************************
+
+From: Bob Duff
+Sent: Wednesday, June 17, 2009  4:16 PM
+
+> Append to the existing !problem section
+>
+> Consider a package which needs to export both a private type and an
+> instance of one of the container generics for that type.
+>
+> Currently, this requires something like
+>
+>    package Pkg is
+>       package Inner is
+>          type T is private;
+>       private
+>          ...
+>       end Inner;
+>
+>       package I is new Some_Container_Generic (Inner.T);
+>    end Pkg;
+>
+> What is wanted here is a way to make all of the declarations visible
+> in Pkg.Inner (and perhaps Pkg.I; that's less clear)
+
+The Pkg.I part seems clear to me.  If I declare an array-of-T at that point, the
+array ops are visible to clients without any horsing around.  If I declare a
+Vector or Linked_List of T, I want the same.
+
+The "array" is the canonical container abstraction.  We should strive to make
+other containers as much like it as possible.
+
+>...visible as if
+> they were declared immediately within Pkg.
+> This special case of the problem alone has been viewed as being
+>sufficiently important to merit considering major changes in the
+>language (see the 4 alternative versions of AI05-0074).
+>
+> An unwanted nested package may also be introduced when a user wishes
+> to declare a non-primitive operation for a tagged type, as in
+>
+>    package Pkg is
+>       type T is tagged ... ;
+>
+>       package Inner is
+>          function Not_Primitive (X : T) return T;
+>       end Inner;
+>    end Pkg;
+>
+> As in the previous example, what is wanted here is a way to make all
+> of the declarations visible in Pkg.Inner visible as if they were
+> declared immediately within Pkg.
+>
+> -------
+>
+> In !discussion section, append to the discussion item beginning with
+>
+>     If it is decided that integrated package renames are not wanted, it
+>     would be easy to remove them from the proposal.
+
+For what it's worth, I am like the "renames" part of the proposal.
+I don't buy the "it could be misused" argument.  Yes, it could.
+But it can also be used well.  Just like many other features of Ada.
+
+There may be issues with interactions with "limited with".  We need to deal with
+that, but it doesn't kill the idea, for me.
+
+> Append:
+>
+>     As Erhard has pointed out, there are good reasons to consider this
+>     option. It is certainly possible to use integrated package renames
+>     to write code that is very difficult to read; this was already true
+>     of Ada83 use clauses, but integrated package renames seem to offer
+>     substantially greater potential for confusion.
+>
+>     Integrated package renames also make possible a number of odd corner cases:
+>
+>       limited with Foo;
+>       package P is
+>         use package Bar renames Foo;
+>       end P;
+>
+>       package Outer is
+>         package Inner is
+>            use package Outer_Rename renames Outer;
+>         end Inner;
+>       end Outer;
+>
+>     Finally, integrated package renames are not needed to solve any of
+>     the problems that provided the original motivation for introducing
+>     integrated packages.
+>
+>     The wording changes need to delete integrated package renames from
+> this AI
+                          ^^^^
+needed
+
+>     would be straightforward. This would include:
+>        - eliminating the wording changes in 8.5.3
+>        - replacing "integrated package or package renaming" with
+>          "integrated package" throughout
+>        - eliminating references to integrated package renamings
+>          in the change appended after 8.4(11)
+>
+> --------
+>
+> Append a new !discussion grocery-list item after the
+
+"grocery-list"?
+
+> "if integrated package renames are not wanted" item:
+>
+>     Tuck suggests that the name of an integrated package rename
+>     should not itself become "use"-visible when the enclosing package is "use"d.
+>
+>     Consider the following example (supplied by Tuck):
+>          Text_IO, Sequential_IO, and Direct_IO each include
+>          renames of each exception declared in the package IO_Exceptions.
+>          It is a no-brainer to replace those renames with a:
+>            "use package <something> renames Ada.IO_Exceptions;"
+>          in Text_IO, Sequential_IO, and Direct_IO.
+>
+>          However, what should the <something> be?  Well, most natural would be:
+>            "use package IO_Exceptions renames Ada.IO_Exceptions;"
+>
+>          but now suppose you have:
+>
+>             with Ada.IO_Exceptions;
+>             with Ada.Text_IO;
+>         use Ada;
+>         procedure What_Fun is
+>            use Text_IO;
+>              -- oops, IO_Exceptions suddenly disappears
+>         begin
+>             ...
+>         exception
+>             when IO_Exceptions.Name_Error =>
+>                 -- oops, this doesn't compile any more!
+>         end What_Fun;
+>
+>     If it is decided that this is what we want, then corresponding
+>     wording would probably be fairly straightforward (as long as
+>     we don't also require elegance, in which case the problem
+>     may be overconstrained).
+
+For what it's worth, I agree with Tucker on this point.
+
+>     As an aside, note that the above example would be allowed if
+>     "IO_Exceptions.Name_Error" were replaced with "Name_Error".
+>
+>     Another solution would be to allow anonymous integrated package
+>     renames, as in
+>        use package <> renames Ada.Io_Exceptions;
+>     This would be equivalent to
+>        use package Some_Identifier_That_Occurs_Nowhere_Else_In_The_Program
+>          renames Ada.Io_Exceptions;
+>     Anonymous non-renames seem like a bad idea, but perhaps anonymous
+>     integrated renames would be ok?
+
+Probably OK.
+
+>     A third approach to this problem would be to add a name
+>     resolution preference rule: if a package rename has the
+>     same simple name as the renamed entity (which might or
+>     might not itself be a rename), then prefer the renamed (and
+>     similarly through chains of renames as long as the simple name
+>     remains unchanged).
+>     This would not introduce the sort of Beaujolais effects that
+>     are typically associated with preference rules, but it does
+>     seem that treating a simple-name-preserving rename differently
+>     than a simple-name-nonpreserving rename might have some
+>     peculiar consequences (e.g., there might be some odd interactions
+>     with formal packages). This is probably a bad idea.
+
+Why is it a bad idea?
+
+In fact, why not extend it -- if name resolution produces a whole bunch of
+interpretations that all mean the same thing, why not say "pick one at random"?
+
+****************************************************************
+
+From: Bob Duff
+Sent: Wednesday, June 17, 2009  4:17 PM
+
+> OK, here is the crux of the problem. As a package designer, I want to
+> *limit* the ways that the client can refer to things. Otherwise,
+> package maintenance becomes much harder. For instance, with this
+> notion of "integrated" packages, it would be impossible to change back to a "flat"
+> structure (because there can be references to the "integrated"
+> package. Nor can you change to "integrated" packages from a "flat"
+> structure without introducing incompatibilities. That can be bad.
+
+I agree with Randy, here.  It doesn't kill the idea, for me, but it sure would
+be nice if we could make this stuff more invisible.
+
+The whole point is to make clients see a possibly-different structure than the
+implementation of the abstraction.
+
+>...This proposal does not "feel
+> right" to me.
+
+Well, to me it feels like "on the right track, but more work needed".
+
+****************************************************************
+
+From: Bob Duff
+Sent: Wednesday, June 17, 2009  4:17 PM
+
+> It's often true that as we come to see the problems with one approach
+> in more detail, the path that we didn't take starts looking more and
+> more attractive.
+
+Yeah.  And then we fail to solve real user-painful problems, because every
+proposed solution has some obscure language-lawyer problems.
+
+Sigh.
+
+****************************************************************
+
+From: Bob Duff
+Sent: Wednesday, June 17, 2009  4:16 PM
+
+> You give as an example:
+>
+>    package Pkg is
+>       type T is tagged ... ;
+>
+>       use package Inner is
+>          function Not_Primitive (X : T) return T;
+>       end Inner;
+>    end Pkg;
+>
+> and mention that you would like to be able to make the name
+> Not_Primitive visible directly in Pkg. But this is exactly one of the
+> sorts of effects that bothers me about this proposal. Clients cannot
+> ignore the presence of the nested package, because its effects
+> re-emerge periodically. This is one of those cases: the primitiveness
+> changes, so for the purposes of deriving a type from T, you have to know the *real* structure of the package.
+
+How can that cause trouble?  I mean, when you call a procedure dispatchingly,
+you get an error if it's not dispatching.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Thursday, June 18, 2009  11:27 AM
+
+> How can that cause trouble?  I mean, when you call a procedure
+> dispatchingly, you get an error if it's not dispatching.
+
+Well, when writing (or debugging) your program, you will want to know whether or
+not something is inherited. That's pretty important for *static* calls (as well
+as dispatching calls), because calling Not_Primitive for an object of type Der_T
+isn't going to work. Sure, you'll get an error if it doesn't work, but
+compilation is hardly the time to find out that your design doesn't work. (And
+it may be hard to figure out *why* you are getting an error from the call.)
+
+It's even worse if you are use-adverse (like me) and name the routine with a
+full expanded name. What that name is could change dramatically.
+
+****************************************************************
+
+From: Bob Duff
+Sent: Thursday, June 18, 2009  1:37 PM
+
+> Well, when writing (or debugging) your program, you will want to know
+> whether or not something is inherited. That's pretty important for
+> *static* calls (as well as dispatching calls), because calling
+> Not_Primitive for an object of type Der_T isn't going to work. Sure,
+> you'll get an error if it doesn't work, but compilation is hardly the
+> time to find out that your design doesn't work.
+
+Well, I can't get too excited about errors that are detected at compile time.
+
+>... (And it may be hard to figure out *why* you are getting  an error
+>from the call.)
+
+True, it can.  That's annoying.  But it's still typically orders of magnitude
+cheaper to fix than a bug that escapes into customer's hands.
+
+> It's even worse if you are use-adverse (like me) and name the routine
+> with a full expanded name. What that name is could change dramatically.
+
+Well, I suppose if you're use-averse, you won't use "use package" much.
+
+It's unfortunate that the Ada world is split into "use haters" and "use lovers",
+but I don't see any solution to that problem.  (I'm somewhere in between, by the
+way, and I change my mind toward either end of the spectrum, back and forth over
+the years.)
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Thursday, June 18, 2009  2:14 PM
+
+We won't have any choice. "use package" (or whatever we come up with) will be
+used in commonly used libraries (possibly including language-defined ones).
+Ignoring it is somewhat of an option, but having the possibility of multiple
+views harms maintenance and has an effect on compatibility.
+
+I'd rather see a solution that "collapsed" the package completely so that the
+clients have no visibility at all on the fact that nested packages are used. To
+do that safely, we'd have to have a mechanism for preventing conflicts (one way
+would be to make conflicts illegal, but that would be limiting), so as to avoid
+the hiding problem that Erhard pointed out.
+
+Maybe we need to go back to the <> package and look at other ways to eliminate
+the hiding problem. Tucker wants to hide the name anyway, so it seems that the
+package name is the least important part of the mechanism.
+
+****************************************************************
+
+From: Steve Baird
+Sent: Friday, June 19, 2009  10:40 AM
+
+>> Append a new !discussion grocery-list item after the
+>
+> "grocery-list"?
+>
+
+I think Randy once observed that some of my !discussion sections read like a
+grocery list.
+
+>>     A third approach to this problem would be to add a name
+>>     resolution preference rule: if a package rename has the
+>>     same simple name as the renamed entity (which might or
+>>     might not itself be a rename), then prefer the renamed (and
+>>     similarly through chains of renames as long as the simple name
+>>     remains unchanged).
+>>     This would not introduce the sort of Beaujolais effects that
+>>     are typically associated with preference rules, but it does
+>>     seem that treating a simple-name-preserving rename differently
+>>     than a simple-name-nonpreserving rename might have some
+>>     peculiar consequences (e.g., there might be some odd interactions
+>>     with formal packages). This is probably a bad idea.
+>
+> Why is it a bad idea?
+> In fact, why not extend it -- if name resolution produces a whole
+> bunch of interpretations that all mean the same thing, why not say "pick one at random"?
+>
+
+Maybe you are right. This sounds like a fairly major change that would have to
+be looked at very carefully. We'd want to preserve the "implicit rename" model
+for the binding of generic actuals to formals.\ Do you think this is worth
+looking into more closely?
+
+Bob Duff wrote:
+> Randy Brukardt wrote:
+>
+>> OK, here is the crux of the problem. As a package designer, I want to
+>> *limit* the ways that the client can refer to things. Otherwise,
+>> package maintenance becomes much harder. For instance, with this
+>> notion of "integrated" packages, it would be impossible to change back to a "flat"
+>> structure (because there can be references to the "integrated"
+>> package. Nor can you change to "integrated" packages from a "flat"
+>> structure without introducing incompatibilities. That can be bad.
+>
+> I agree with Randy, here.  It doesn't kill the idea, for me, but it
+> sure would be nice if we could make this stuff more invisible.
+
+One way to achieve this would be to allow anonymous packages even in the
+non-rename case, as in
+
+    package Outer is
+        use package <> is
+           ...;
+        end <>;
+    end Outer;
+
+I don't think this interacts well with the use-visibility-based approach that we
+have been discussing. There are times when use-visibility doesn't get you what
+you want and you need the fallback mechanism of explicit qualification. This
+construct would remove that option.
+
+On the other hand, it sounds like removing the option of explicit qualification
+is exactly what you and Randy want. It preserves the desired "flat" interface.
+
+I had lunch with Pascal Leroy yesterday and we discussed this AI briefly. He
+didn't claim to have looked at this one in depth, but he did observe that the
+implicit-rename-declaration approach that was being considered initially seemed
+more intuitive than the current approach that is based on use-visibility.
+
+Do you think the rename-based approach would somehow help with this problem -
+making these inner packages invisible while still allowing the user to name
+everything that needs naming. As far as I can see the answer is "no", but I
+thought I would raise the question.
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Friday, June 19, 2009  11:40 AM
+
+The implicit rename and the use-visibility differ primarily only when there is a
+conflict.  Implicit rename suffers from Beaujolais if you allow conflicts, while
+use-visibility doesn't. I don't think we want to introduce Beaujolais effects,
+so I presume we are talking a model where conflicts are illegal.
+
+Perhaps a compromise might say that if you give a name, then conflicts are
+permitted (and use-visibility rules apply), while if you don't give a name, then
+conflicts are illegal, so it is more like the implicit rename model.
+
+I suppose the other area of difference is primitiveness of operations.  I
+thought it was a feature that you could get non-primitive operations to be
+directly visible, essentially like those declared in the body. Perhaps the same
+rule would apply: if you give a name, then the subprograms are *not* primitive
+of a type in the enclosing scope, whereas if you use "<>" then the subprograms
+*do* become primitives of such types.
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Wednesday, June 24, 2009  12:59 PM
+
+Any comments on this thought of having "use package <> ..." follow renaming
+semantics (with no conflicts permitted), and "use package Integrated ..." follow
+transitive "use-visibility" semantics (with conflicts resolved in the use-ish
+way, and a name available to disambiguate)?
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Wednesday, June 24, 2009  1:10 PM
+
+I have to wonder if we *really* need both. But if we do, the semantics you
+suggest seem correct.
+
+I'm pretty convinced that we need the nameless version because of all of the
+reasons that have been previously noted about compatibility, the client view,
+name space pollution, etc.
+
+I'm less convinced that we need the named version if we have the nameless
+version (because of those same reasons mentioned above), but I suppose there
+might be significant use cases in its favor. It surely would be annoying if some
+maintenance far away was to make a program illegal (by adding a conflict) and
+there being no good way to avoid the problem.
+
+BTW, if we do this, do we "fix" Text_IO to have
+    use package <> renames Ada.IO_Exceptions; instead of the batch of individual
+    renames of exceptions??
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Wednesday, June 24, 2009  1:40 PM
+
+> I have to wonder if we *really* need both. But if we do, the semantics
+> you suggest seem correct.
+
+Good.  That's a start.
+
+...
+> BTW, if we do this, do we "fix" Text_IO to have
+>     use package <> renames Ada.IO_Exceptions; instead of the batch of
+> individual renames of exceptions??
+
+Yes, that would make sense.
+
+****************************************************************
+
+From: Steve Baird
+Sent: Wednesday, June 24, 2009  2:45 PM
+
+I like the idea of guaranteeing that the name
+    Enclosing_Package.Some_Entity
+will resolve in precisely the case where we are taking away the fallback option of using the name
+    Enclosing_Package.Named_Integrated_Package.Some_Entity
+.
+
+There are, however, the usual problems with having two very similar complex
+constructs which are different in subtle but important ways.
+
+This approach (deliberately) spoils the equivalence between
+    use package <> ... ;
+and
+    use package An_Identifier_That_Occurs_Nowhere_Else ... ; , which seems
+    potentially confusing.
+
+Could we revisit the approach of allowing named and anonymous integrated
+packages while unconditionally using "rename" semantics, perhaps allowing
+collisions between renames (including constraintless subtypes) which denote the
+same thing? In other words, throw out the whole use-clause-based approach?
+
+When we first explored that approach, the problems with collisions looked pretty
+bad. If, however, the alternative is the one you suggest (if it's named, use one
+complicated model; if anonymous, use another), then maybe it is time to have
+another look to see if those collision problems were really that bad.
+
+--------
+
+Would anonymous packages be limited to renames and instances? Perhaps only
+renames?
+
+I don't want to see "package body <> is".
+
+--------
+
+There may be problems with the rename approach and disallowing conflicts in the
+case of an integrated instantiation. I'm thinking about child units of the
+instantiated generic.
+
+    generic
+    package G1 is
+    end G1;
+
+    with G1;
+    package Pkg is
+       package <> is new G1;
+       G2 : Integer;
+    end Pkg;
+
+    generic
+    package G1.G2 is
+    end G1.G2;
+
+    with G1.G2;
+    with Pkg;
+    package Troublemaker is
+       -- what is the story on Pkg.G2 here ?
+    end Troublemaker;
+
+Perhaps you only get implicitly declared renames of the items which are visible
+in the integrated package spec at the point of the integrated package's
+declaration.
+
+--------
+
+For anonymous packages, the <> identifier tells us everything we need to know
+and the word "use" is redundant.
+
+Would it make matters clearer or more confusing if we took advantage of this and
+dropped the word "use" so that the syntax would be, for example,
+    package <> renames Ada.IO_Exceptions; instead of
+    use package <> renames Ada.IO_Exceptions; ?
+
+If we decide that anonymous packages get "rename" rather than "use" semantics,
+this might add weight to the argument for dropping the word "use" in that case.
+
+If we decide that we are not going to support named integrated packages at all,
+then it seems clear to me that there is no need for the word "use" in the
+syntax.
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Wednesday, June 24, 2009  3:07 PM
+
+I agree that we could drop the "use"
+for the renaming-based semantics:
+
+    package <> renames ...;
+
+and perhaps
+
+    package <> is new Gen_Pkg(...);
+
+I had forgotten the problem of "package body <> is"
+in generalizing this to handle integrated, non-rename, non-instance packages.  I
+would hate to give up on the "normal" nested package case, as that was our
+technique for solving the instantiating-with-private-type problem. I suppose we
+could allow at most one such nested package, so the "package body <> is" would
+be unambiguous.
+
+Round and round we go... ;-)
+
+****************************************************************
+
+From: Steve Baird
+Sent: Wednesday, June 24, 2009  4:07 PM
+
+> I would hate
+> to give up on the "normal" nested package case, as that was our
+> technique for solving the instantiating-with-private-type problem.
+
+I agree.
+
+I would have to hear a very persuasive argument before I would be interested in
+any design alternative for integrated packages that cannot be used to solve that
+problem.
+
+> I suppose we could allow at most one such nested package, so the
+> "package body <> is" would be unambiguous.
+
+Yuck. Requiring that the anonymous package cannot require
+a body is also no good.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Thursday, June 25, 2009  9:38 PM
+
+> > I suppose we could allow at most one such nested package, so the
+> > "package body <> is" would be unambiguous.
+>
+> Yuck. Requiring that the anonymous package cannot require a body is
+> also no good.
+
+I'm not sure I understand "yuck" in this context. It seems that it makes sense
+to allow only one anonymous package (of any kind) per scope, and thus there
+couldn't be any confusion about which one has the body. That also would greatly
+reduce the possibilities for conflicts and surely simplify the implementation of
+checking for conflicts.
+
+It's not like you could have a whole bunch of anonymous instances anyway: with
+the "no conflicts" model, you are quickly going to hit some brick wall. For
+instance, it would not be possible to have more than one anonymous instance of a
+predefined container, because they all contain a constant No_Element (which is
+not overloadable).
+
+And it surely is obvious that you can only have one anonymous regular package.
+
+So it might make sense to simply allow only one per scope to avoid confusion.
+
+I doubt that this would be a major hardship, at least for the relatively simple
+uses that we've envisioned. We're trying to be able to add a container to the
+visible part of a package, not necessarily a whole flock of them.
+
+Still, I suppose this makes it clear why we would want to continue to support
+the named version as well -- the anonymous version would be limited in
+applicability (but preferable if it could be used).
+
+P.S. It's wonderful that no idea for fixing the instantiating-with-private-type
+problem works for long, unless it is hard enough to use that everyone [other
+than me and Brad :-)] rejects it. :-(
+
+****************************************************************
+
+From: Steve Baird
+Sent: Thursday, June 25, 2009  9:59 PM
+
+> I'm not sure I understand "yuck" in this context.
+
+A rule that allows one "special" construct just seems a bit ugly to me. If we
+are going to go down this route, I'd rather consider something equivalent to
+(but hopefully better looking than)
+    package <X> is
+    end <X>;
+
+    package <Y> is
+    end <Y>;
+so that the two (or more) anonymous packages cannot be named by an identifier,
+but their completions can be disambiguated.
+
+If we do decide to allow package bodies for anonymous packages, we still should
+not allow such bodies to be separate; that would have too much impact on tools,
+file naming conventions, etc.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Thursday, June 25, 2009  10:21 PM
+
+You mean as in subunits and separate compilation? I think that follows from the
+fact that we don't allow much for subunits: no overloading, no operators, no
+name conflicts. I don't think we'd need to say anything at all, since we'd need
+to *add* syntax to allow anonymous stubs -- and I can't imagine any reason for
+doing that.
+
+****************************************************************
+
+From: Ed Schonberg
+Sent: Friday, June 26, 2009  8:45 AM
+
+> It's not like you could have a whole bunch of anonymous instances
+> anyway:
+> with the "no conflicts" model, you are quickly going to hit some brick
+> wall.
+> For instance, it would not be possible to have more than one anonymous
+> instance of a predefined container, because they all contain a
+> constant No_Element (which is not overloadable).
+
+But a rule that says "you can only have one package"  will immediately strike
+users as arbitrary. Why should I be able to define a single container in a spec?
+
+> And it surely is obvious that you can only have one anonymous regular
+> package.
+
+Then that dooms anonymous packages.
+
+>
+> So it might make sense to simply allow only one per scope to avoid
+> confusion.
+>
+> I doubt that this would be a major hardship, at least for the
+> relatively simple uses that we've envisioned. We're trying to be able
+> to add a container to the visible part of a package, not necessarily a
+> whole flock of them.
+>
+> Still, I suppose this makes it clear why we would want to continue to
+> support the named version as well -- the anonymous version would be
+> limited in applicability (but preferable if it could be used).
+>
+>            Randy.
+>
+> P.S. It's wonderful that no idea for fixing the
+> instantiating-with-private-type problem works for long, unless it is
+> hard enough to use that everyone [other than me and Brad :-)] rejects
+> it. :-(
+
+If the central purpose of this AI is to ease the use of containers, then I think
+AI05-74 (3)  namely deferred freezing rules for  instantiations deserves another
+look.  It is a minimal change,   Discussion on it was sidetracked by other
+concerns, but I have not seen crippling arguments against it. Steve has proposed
+a pragma to prevent contract issues, what are the big objections to this?
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Friday, June 26, 2009  9:02 AM
+
+My objection to Steve's proposal is precisely because it relies on a pragma.  I
+believe whatever we do deserves some kind of distinguishing syntax.
+
+Note that my suggestion was that we would only allow at most one integrated,
+anonymous non-instance, non-rename package. There seems no difficulty allowing
+any number of anonymous instances/renamings, as these don't need bodies. Also,
+there seems no difficulty in allowing any number of named non-instance,
+non-rename integrated packages.
+
+Allowing only one "normal" nested package to be anonymous seems pretty
+reasonable.  The only reason for making a nested package anonymous and
+integrated seems to be to provide for freezing uses of private types within the
+enclosing package.  It doesn't seem like you would need more than one such
+anonymous nested package in typical scenarios.
+
+****************************************************************
+
+From: Steve Baird
+Sent: Friday, June 26, 2009  9:32 AM
+
+> But a rule that says "you can only have one package"  will immediately
+> strike users as arbitrary.
+
+I agree.
+
+> Allowing only one "normal" nested package to be anonymous seems pretty
+> reasonable.  The only reason for making a nested package anonymous and
+> integrated seems to be to provide for freezing uses of private types
+> within the enclosing package.  It doesn't seem like you would need
+> more than one such anonymous nested package in typical scenarios.
+
+What about a package that wants to export two private types, as in
+
+    package Pkg is
+       package <anonymous 1> is
+           type T1 is private;
+           -- primitive operations of T1;
+       end <anonymous 1>;
+
+       package T1_Containers is new Some_Container_Generic (T1);
+
+       package <anonymous 2> is
+          type T2 is private;
+          -- primitive operations of T2, perhaps
+          -- involving parameters of type T1_Container.Some_Type
+       end <anonymous 2>;
+
+       package T2_Containers is new Some_Container_Generic (T2);
+    end Pkg;
+
+?
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Friday, June 26, 2009  12:22 PM
+
+I believe the following would work:
+
+    package Pkg is
+
+       package <> is
+          package <> is
+              type T1 is private;
+              -- primitive operations of T1;
+          end <>;
+
+          package T1_Containers is new Some_Container_Generic (T1);
+          type T2 is private;
+          -- primitive operations of T2, perhaps
+          -- involving parameters of type T1_Container.Some_Type
+       end <>;
+
+       package T2_Containers is new Some_Container_Generic (T2);
+    end Pkg;
+
+I believe it is possible to show that by nesting package <>, you can achieve
+whatever you want.
+
+Of course, this is now the moral equivalent of allowing multiple visible parts,
+separated by private/end-private.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Friday, June 26, 2009  12:25 PM
+
+> If the central purpose of this AI is to ease the use of containers,
+> then I think AI05-74 (3)  namely deferred freezing rules for
+> instantiations deserves another look.  It is a minimal change,
+> Discussion on it was sidetracked by other concerns, but I have not
+> seen crippling arguments against it. Steve has proposed a pragma to
+> prevent contract issues, what are the big objections to this?
+
+I agree with Tucker that we don't want something so fundamental to be a pragma.
+Syntax would be preferred.
+
+Steve also had a number of "Baird cases" which complicated the model
+considerably (just as in anonymous packages, use package, and all of the other
+ideas that we've looked at).
+
+Finally, there is nothing "minimal" about this change. It would be an
+implementation earthquake in Janus/Ada (since we share both the spec and body of
+generics, and depend heavily on freezing to prevent problems). And it would add
+some conceptual complexity to generics (now there would be two different sets of
+freezing rules for them)
+
+I continue to prefer a version of the "forward instantiation" (probably
+exporting limited views) as the best solution, but I admit that we've never
+found a syntax which makes sense both from the client view (where the forward
+instance looks like a normal instance) and from the local package view (where
+the forward instance is special). Note that the proposed extension of uses of
+incomplete types would also have the effect of making this idea much more
+powerful.
+
+Brad has been exploring variations on this theme, perhaps he's found the perfect
+solution while we weren't paying attention.
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Friday, June 26, 2009  12:34 PM
+
+> Finally, there is nothing "minimal" about this change. It would be an
+> implementation earthquake in Janus/Ada (since we share both the spec
+> and body of generics, and depend heavily on freezing to prevent
+> problems). And it would add some conceptual complexity to generics
+> (now there would be two different sets of freezing rules for them)
+
+I think we should get an estimate of implementation impact from multiple
+implementations before we decide on this feature. I am dubious, seems like the
+motivation here comes from the designers rather than users, but I may be wrong
+on this, do we have cases of large scale users complaining about this missing
+functionality?
+
+> I continue to prefer a version of the "forward instantiation"
+> (probably exporting limited views) as the best solution, but I admit
+> that we've never found a syntax which makes sense both from the client
+> view (where the forward instance looks like a normal instance) and
+> from the local package view (where the forward instance is special).
+> Note that the proposed extension of uses of incomplete types would
+> also have the effect of making this idea much more powerful.
+>
+> Brad has been exploring variations on this theme, perhaps he's found
+> the perfect solution while we weren't paying attention.
+
+I sure share the feeling that we could find some better solution here, but i
+realize the search has not been fruitful so far.
+
+****************************************************************
+
+From: Ed Schonberg
+Sent: Friday, June 26, 2009  12:51 PM
+
+> I agree with Tucker that we don't want something so fundamental to be
+> a pragma. Syntax would be preferred.
+
+I don't understand this comment: if a pragma is sufficient, then it is NOT a
+fundamental change, and there is very little to add to the RM.  Looks like a
+plus to me.
+
+> Steve also had a number of "Baird cases" which complicated the model
+> considerably (just as in anonymous packages, use package, and all of
+> the other ideas that we've looked at).
+
+I trust that Steve will provide other admirably  byzantine examples on any
+solution, but the ones I have seen are no worse than for integrated packages.
+
+> Finally, there is nothing "minimal" about this change. It would be an
+> implementation earthquake in Janus/Ada (since we share both the spec
+> and body of generics, and depend heavily on freezing to prevent
+> problems). And it would add some conceptual complexity to generics
+> (now there would be two different sets of freezing rules for them)
+
+Sorry, implementation difficulties are minor objections if we can get the
+language right. The change in freezing rules will add a few lines to 13.14. In
+comparison, integrated packages (named and anonymous) will require plenty of
+text in the RM and AARM to explain why they are there, when they should be used,
+why they are preferable (perhaps) to child units, etc.
+
+> I continue to prefer a version of the "forward instantiation"
+> (probably exporting limited views) as the best solution, but I admit
+> that we've never found a syntax which makes sense both from the client
+> view (where the forward instance looks like a normal instance) and
+> from the local package view (where the forward instance is special).
+> Note that the proposed extension of uses of incomplete types would
+> also have the effect of making this idea much more powerful.
+>
+> Brad has been exploring variations on this theme, perhaps he's found
+> the perfect solution while we weren't paying attention.
+
+OK, worth looking at in more detail.
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Friday, June 26, 2009  1:05 PM
+
+> Sorry, implementation difficulties are minor objections if we can get
+> the language right. The change in freezing rules will add a few lines
+> to 13.14. In comparison, integrated packages (named and anonymous)
+> will require plenty of text in the RM and AARM to explain why they are
+> there, when they should be used, why they are preferable (perhaps) to
+> child units, etc.
+
+We have *never* taken the position that implementation difficulties are to be
+ignored, and we shouldn't start now. I would like to see at the minimum an
+analysis from AdaCore, Tuck, and Rational on forseen implementation
+difficulties, given this is a non-critical feature. I say it is non-critical,
+since I don't see its absence as having a significant effect on Ada adoption.
+
+To me, at this stage, EVERY proposal for language change should include an
+analysis of impact on implementations.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Friday, June 26, 2009  3:48 PM
+
+> > I agree with Tucker that we don't want something so fundamental to
+> > be a pragma. Syntax would be preferred.
+>
+> I don't understand this comment: if a pragma is sufficient, then it is
+> NOT a fundamental change, and there is very little to add to the RM.
+> Looks like a plus to me.
+
+I don't understand this comment: there is a massive amount of semantic change
+(at a minimum concerning freezing and elaboration) behind this difference. All
+of this change clearly violates good taste in pragmas. You could argue that
+there are a number of existing pragmas that also violate this good taste, but I
+don't think that two wrongs make a right. Just because we screwed up in the past
+does not mean that we should do so again.
+
+Note that we considered and rejected pragma-based solutions in a number of other
+areas; this doesn't seem that different to me.
+
+> > Steve also had a number of "Baird cases" which complicated the model
+> > considerably (just as in anonymous packages, use package, and all of
+> > the other ideas that we've looked at).
+>
+> I trust that Steve will provide other admirably  byzantine examples on
+> any solution, but the ones I have seen are no worse than for
+> integrated packages.
+
+That's possible; I was just skimming the e-mail in the AI, and it showed a
+number of new interactions that would have to be addressed (presumably with
+additional rules).
+
+> > Finally, there is nothing "minimal" about this change. It would be
+> > an implementation earthquake in Janus/Ada (since we share both the
+> > spec and body of generics, and depend heavily on freezing to prevent
+> > problems). And it would add some conceptual complexity to generics
+> > (now there would be two different sets of freezing rules for them)
+>
+> Sorry, implementation difficulties are minor objections if we can get
+> the language right. The change in freezing rules will add a few lines
+> to 13.14. In comparison, integrated packages (named and anonymous)
+> will require plenty of text in the RM and AARM to explain why they are
+> there, when they should be used, why they are preferable (perhaps) to
+> child units, etc.
+
+Robert made the point about implementation better than I could have.
+
+I think you are dreaming if you think that only "a few lines [in] 13.14" are
+needed here. No significant proposal, no matter how apparently simple, ends up
+that easy. In this case, we surely will have to make changes in the elaboration
+rules for instances, define the syntax (or pragma) that enables these semantic
+changes, and add additional rules to fix the interactions that Steve pointed
+out. We may also want to use the new feature in some of the existing predefined
+packages. I would be very, very surprised if the number of changes were less
+than those needed in Steve's latest draft of AI05-135 (which seems to cover
+everything required for "integrated packages" with the exception of use in
+existing predefined packages). In any case, explaining "why they are there" and
+especially "why they are preferable" belongs in textbooks (and the AI), not the
+standard and is pretty much irrelevant to any discussion of the size of a change
+to the language.
+
+****************************************************************
+
+From: Brad Moore
+Sent: Saturday, June 27, 2009  5:35 PM
+
+> If the central purpose of this AI is to ease the use of containers,
+> then I think AI05-74 (3)  namely deferred freezing rules for
+> instantiations deserves another look.  It is a minimal change,
+> Discussion on it was sidetracked by other concerns, but I have not
+> seen crippling arguments against it. Steve has proposed a pragma to
+> prevent contract issues, what are the big objections to this?
+
+My concern regarding the pragma approach is that I think we should avoid putting
+things (pragmas) in the "server" (the generic package), that makes assumptions
+about how the "client" will want to use the package. If we went with this
+approach, then I envision the next incarnation of the Ada style guide (hopefully
+we will see someday) would be modified to say, "Use this new pragma everywhere
+on every new generic if at all possible, and do not declare variables or
+expressions in the generic specs, unless you can provide strong justifications,
+otherwise you may be limiting the reuse possibilities for your generic code."
+
+This also seems like a maintenance problem. If the maintenance of a generic
+package needs to add a variable declaration or expression to the package, (and
+thereby remove the special pragma) then this could break clients, which may not
+notice the change until the next time a build for a particular program is
+executed. By then other clients may be dependent on the newer version of the
+generic code.
+
+Basically, I don't think we want to go there.
+
+My thoughts were that it is better to not change the way generics work. (i.e.,
+no restrictions on declaring variables or expressions), and instead put any
+restrictions needed to prevent problems in the client. This is why I do not have
+any such pragma in my most recent proposal. (It isn't in my most recent version
+of AI05-0074-4 either, though earlier incarnations did have it, as I originally
+"borrowed" the idea from AI05-0074-3)
+
+I haven't thought too much about whether AI05-0074-3 could be reworked, in a
+manner similar to AI05-0074-5? to eliminate the pragma, though I think
+*something* (whether it be syntax or pragma) is needed to distinguish between
+this usage and a normal instantiation.
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Saturday, June 27, 2009  5:42 PM
+
+> This also seems like a maintenance problem. If the maintenance of a
+> generic package needs to add a variable declaration or expression to
+> the package, (and thereby remove the special pragma) then this could
+> break clients, which may not notice the change until the next time a
+> build for a particular program is executed. By then other clients may
+> be dependent on the newer version of the generic code.
+
+I don't really see this point. ANY change to ANY package may break clients, and
+surely you don't go changing a generic spec without a lot of discussion and
+testing if it is in general use.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Saturday, June 27, 2009  6:08 PM
+
+As a pragma, I agree with Brad, simply because this pragma would violate "good
+taste in pragmas". We recently added some discussion to the AARM to explain what
+good taste is (see 2.8(1.a/3) or AI05-0100-1 if you don't have the draft 7 AARM
+handy). In particular, removing a pragma from a legal program should not make
+the program illegal, and this proposed pragma would have that effect. (Adding a
+pragma can make a legal program illegal, however.)
+
+If we are talking about syntax instead, however, I agree with Robert. It would
+be amazing to make major changes to the syntax of a package specification
+(generic or not) and expect clients to be unaffected. So I don't find this point
+to be very compelling.
+
+The style guide issue doesn't bother me much, either; it seems to be a good
+practice to avoid this stuff in the specification anyway (it causes too much
+coupling), so a style requiring that doesn't seem that terrible. There is plenty
+of stuff that Ada allows you to do that you should really avoid.
+
+I definitely agree that there needs to be syntax somewhere to distinguish this
+special case from the more normal rules, for compatibility if for no other
+reason. (Whatever special case we decide on.)
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Saturday, June 27, 2009  6:19 PM
+
+> As a pragma, I agree with Brad, simply because this pragma would
+> violate "good taste in pragmas". We recently added some discussion to
+> the AARM to explain what good taste is (see 2.8(1.a/3) or AI05-0100-1
+> if you don't have the draft 7 AARM handy). In particular, removing a
+> pragma from a legal program should not make the program illegal, and
+> this proposed pragma would have that effect. (Adding a pragma can make
+> a legal program illegal,
+> however.)
+
+Well i can't get too excited about that, since we already have pragmas that are
+in bad taste from this point of view. I don't really mind if these are language
+defined pragmas, actually come to think of it I don't mind at all. Language
+definitions should not be in the business of defining what is "good taste" in
+any case, so anything like that in the standard is going to be ignored by me
+anyway. We design pragmas to be useful, not to meet some committee's idea of
+what is good taste :-) :-) If you think a pragma is in bad taste, you don't have
+to use it!
+
+> If we are talking about syntax instead, however, I agree with Robert.
+> It would be amazing to make major changes to the syntax of a package
+> specification (generic or not) and expect clients to be unaffected. So
+> I don't find this point to be very compelling.
+
+OK, well new syntax is fine by me too, though of course it is always more
+troublesome in practice.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Saturday, June 27, 2009  6:46 PM
+
+> Well i can't get too excited about that, since we already have pragmas
+> that are in bad taste from this point of view. I don't really mind if
+> these are language defined pragmas, actually come to think of it I
+> don't mind at all. Language definitions should not be in the business
+> of defining what is "good taste" in any case, so anything like that in
+> the standard is going to be ignored by me anyway. We design pragmas to
+> be useful, not to meet some committee's idea of what is good taste
+> :-) :-) If you think a pragma is in bad taste, you don't have to use
+> it!
+
+That's not really true for language-defined pragmas. Pragma Import is a pragma
+in bad taste, but it's pretty much impossible to avoid using it (as much as I'd
+like to). Imagine trying to write Claw without using pragma Import! :-)
+
+> > If we are talking about syntax instead, however, I agree with Robert.
+> > It would be amazing to make major changes to the syntax of a package
+> > specification (generic or not) and expect clients to be unaffected.
+> > So I don't find this point to be very compelling.
+>
+> OK, well new syntax is fine by me too, though of course it is always
+> more troublesome in practice.
+
+It can't be that much more troublesome, if you've already managed to implement
+conditional expressions. :-) :-)
+
+Seriously, syntax has a bit more impact on tools than a pragma would, but
+otherwise it isn't much different. I prefer either to just changing the
+semantics of something, which leads to all kinds of complications both in
+implementation and in use.
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Saturday, June 27, 2009  6:50 PM
+
+> As a pragma, I agree with Brad, simply because this pragma would
+> violate "good taste in pragmas". We recently added some discussion to
+> the AARM to explain what good taste is (see 2.8(1.a/3) or AI05-0100-1
+> if you don't have the draft 7 AARM handy). In particular, removing a
+> pragma from a legal program should not make the program illegal
+
+This really isn't vaguely true for existing pragmas!
+
+For example, removing pragma Pack often makes a program illegal.
+
+Removing a pragma Import almost certainly makes a program illegal.
+
+Removing a pragma Convention can easily make a program illegal
+
+Removing a pragma Pure, Preelaborate, or any of the other categorization pragmas
+can make a program illegal.
+
+Removing a pragma Elaborate can make a program illegal same of course with
+Elaborate_All and Elaborate_Body.
+
+Removing a pragma Atomic or Volatile can make a program illegal.
+
+There aren't that many pragmas defined in the RM, and as we see many of them are
+in "bad taste" :-)
+
+Once we have done such a bad job of following our own bad taste rules, I can
+hardly get upset at adding one more.
+
+And since the language is so free in adding these bad taste pragmas (note that
+most of these were added in Ada 95), I see no reason for implementors to feel
+bound to stricter standards.
+
+I guess to me, it is MUCH worse when removing a pragma can cause the progam to
+become erroneous, or malfunction in mysterious ways. Ilegality is a nice outcome
+of improperly removing a pragma compared to these alternatives!
+
+Notionally if an implementation has only "good taste" pragmas, then you can
+remove them all or ignore them all, and the program is still legal. But so what?
+Pragmas are not there for amusement purposes, almost certainly they are
+important to the correct functioning of the program. If you have a GNAT program
+that uses pragma Weak_External, sure you can remove it and the compiler will
+consider the program legal, but good luck at link time :-) And if you remove a
+pragma Wide_Character_Encoding, it will be quite surprising if you can still
+compile your source :-)
+
+[Most of the rest of the pragmas thread can be found in AI05-0163-1. - Editor.]
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Saturday, June 27, 2009  6:59 PM
+
+> It can't be that much more troublesome, if you've already managed to
+> implement conditional expressions. :-) :-)
+
+I am not concerned with implementation difficultioes, obviously it does not
+matter two hoots to the implementation whether something is syntax or pragmas,
+to an implementation, a pragma *is* syntax.
+
+I was concerned about incompatibilities, certainly for instance introducing new
+keywords has serious impacts. And new syntax is far more likely to cause trouble
+with tools like pretty printers, syntax oriented editors, ASIS etc.
+
+> Seriously, syntax has a bit more impact on tools than a pragma would,
+> but otherwise it isn't much different. I prefer either to just
+> changing the semantics of something, which leads to all kinds of
+> complications both in implementation and in use.
+
+Definitely I agree on that, the change to returning limited types caused chaos
+for our users, and delayed many of them in moving to Ada 2005.
+
+****************************************************************
+
+From: Brad Moore
+Sent: Sunday, June 28, 2009  12:51 AM
+
+> If we are talking about syntax instead, however, I agree with Robert.
+> It would be amazing to make major changes to the syntax of a package
+> specification (generic or not) and expect clients to be unaffected. So
+> I don't find this point to be very compelling.
+>
+> The style guide issue doesn't bother me much, either; it seems to be a
+> good practice to avoid this stuff in the specification anyway (it
+> causes too much coupling), so a style requiring that doesn't seem that
+> terrible. There is plenty of stuff that Ada allows you to do that you should really avoid.
+
+I agree that both these points are not serious, show-stopper type problems. We
+could certainly live with them if we had to. I guess my point is that regardless
+how serious these are, they can still be viewed as being negatives. If we can
+achieve more or less the same thing without the negatives, then that may be even
+more desirable.
+
+****************************************************************
+
+From: Brad Moore
+Sent: Sunday, June 28, 2009  12:33 PM
+
+> I agree with Randy that we should avoid using pragmas that make things
+> legal that would otherwise be illegal (ignoring representational issues).
+> Yes we have some such pragmas now, but there are few, and it was back
+> in Ada 9X that we established this principle and did our best to stick
+> with it.
+> I don't like to see us slipping backwards now.
+
+I also think there is something to be said for having the distinguishing syntax
+(or pragma if we must) at the site of where we want the benefits of that syntax.
+i.e., close to the instantiation in the unit that wants to instantiate a generic
+using a private type, rather than in the generic unit being instantiated.
+
+For example, I still see a maintenance problem. If a client discovers a need to
+instantiate some existing generic using a private type, modifying the generic to
+add the pragma may not be an option, if the generic is in a unit supplied by a
+3rd party vendor, or if removing any existing declarations or expressions in the
+generic would break too many other clients.
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Sunday, June 28, 2009  12:43 PM
+
+makes sense to me!
+though the devil is in the details for something like this.
+
+****************************************************************
+
+From: Brad Moore
+Sent: Friday, July 10, 2009  10:47 AM
+
+I have another approach for addressing the private type instantiation issue.
+
+On the surface, it appears to have a lot of the desirable qualities of the
+integrated packages solution, but without some of the not so desirable
+qualities.
+
+I think it is the implicitness of the integrated package solution that is
+generating some uneasiness. It is the implicitness that led us to look (so far
+unsuccessfully) at the anonymous package idea as a means of avoiding conflicts.
+
+I also think it is desirable if we can make it more explicit about which
+services we want to export from the instantiation.
+
+What if instead we allowed type renames to solve this issue?
+
+The idea is that the type rename would export all operations involving that type
+from the inner package (or instance).
+
+For enumeration types, this would export all the literals of the enumeration.
+
+This gives the client the ability to provide a name for the type, thus avoiding
+conflicts, and eliminates the need to look at the equivalence of the anonymous
+packages idea.
+
+If you want to export a subprogram that involves more than one type declared in
+the inner package, (or instance), then you would need to also declare a type
+rename for those other types. (or otherwise be required the name to be qualified
+to reference the  inner type).
+
+eg.
+
+with Ada.Containers.Doubly_Linked_Lists;
+with Ada.Containers.Vectors;
+package P is
+
+   package Nested is
+      type T is private;
+   private
+      type T is ...;
+   end Nested;
+
+   type R renames Nested.T; -- R makes T available outside Nested
+
+   package Lists is new Ada.Containers.Doubly_Linked_Lists (R);
+
+   -- Make the Lists services directly available in package P;
+   type List renames Lists.List;
+   type Iterator renames Lists.Cursor;
+   No_List_Element renames Lists.No_Element;
+
+   -- Another instantiation without any conflicts
+   package Arrays is new Ada.Containers.Vectors
+      (Index_Type => Natural, Element_Type => R);
+   type Array renames Arrays.Vector;
+   type Array_Cursor renames Arrays.Cursor;
+   No_Array_Element renames Arrays.No_Element;
+
+end P;
+
+with P;
+procedure Q is
+  My_List : P.List; -- Really is P.Lists.List
+  My_Cursor : P.Iterator; -- Really P.Lists.Cursor
+  My_R : P.R;  -- Really P.Nested.T
+begin
+  My_List.Append (My_R); -- Really P.Lists.Append
+  My_Cursor := My_List.First;
+end Q;
+
+The integrated package idea also would export object declarations and exception
+declarations.
+
+This solution probably wouldn't export object declarations, and would not export
+exception declarations since those are not tied to type declarations, but having
+to explicitly rename those might be considered a good thing.
+
+Is this idea worth developing further?
+
+****************************************************************
+
+From: Steve Baird
+Sent: Friday, July 10, 2009  12:05 PM
+
+> What if instead we allowed type renames to solve this issue?
+>
+> The idea is that the type rename would export all operations involving
+> that type from the inner package (or instance).
+>
+
+This would certainly be a heck of a lot simpler than integrated packages.
+
+It is less general, but if it is powerful enough to solve the problems that
+integrated packages were intended to solve, then that's all we need.
+
+Having two similar-but-slightly-different constructs in the language (i.e.
+"subtype S is Pkg.T;" vs. "type S renames Pkg.T;") may be confusing to some
+users at first, but is this any worse in this respect than subtypes vs. derived
+types or qualified expressions vs. type conversion?
+
+> Is this idea worth developing further?
+
+I think so.
+
+The first question that comes to my mind is whether there are problems that need
+solving for which (some version of) integrated packages provide a solution and
+this proposal does not.
+
+****************************************************************
+
+From: Ed Schonberg
+Sent: Friday, July 10, 2009  12:20 PM
+
+> Having two similar-but-slightly-different constructs in the language
+> (i.e. "subtype S is Pkg.T;" vs. "type S renames Pkg.T;") may be
+> confusing to some users at first, but is this any worse in this
+> respect than subtypes vs. derived types or qualified expressions vs.
+> type conversion?
+
+In fact, three constructs:
+
+subtype S is Pkg.T;
+
+type T is new Pkg.T;  -- with null record when needed
+
+type T renames Pkg.T;  --  whose semantics is not that different from the
+                       --  previous one.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Friday, July 10, 2009  1:50 PM
+
+> It is less general, but if it is powerful enough to solve the problems
+> that integrated packages were intended to solve, then that's all we
+> need.
+
+Wasn't that the original idea that eventually led to the integrated package
+idea? I thought we previously explored that possibility.
+
+I recall that Bob Duff was very much against it, claiming that there is lots of
+other stuff (like exceptions, and sometimes enumeration types) that need to come
+along with the primitive operations of a type. That's why we eventually
+gravitated to a package-based solution.
+
+Of course, it's worthwhile to look back at other solutions, because we still
+aren't happy with what we've got. But I'd expect the basic objections to remain.
+
+****************************************************************
+
+From: Steve Baird
+Sent: Friday, July 10, 2009  2:11 PM
+
+What may have changed is the magnitude of the objections to the other available
+alternatives.
+
+If we conclude that integrated packages are a complicated mess (and I am not
+quite ready to concede that point), then alternatives that we originally
+discarded may start looking better.
+
+****************************************************************
+
+From: Brad Moore
+Sent: Friday, July 10, 2009  5:29 PM
+
+> The first question that comes to my mind is whether there are problems
+> that need solving for which (some version
+> of) integrated packages provide a solution and this proposal does not.
+
+Well I can think of one other problem this would solve that the integrated
+packages solution does not solve.
+
+The issue about not being able to derive from a synchronized tagged when you
+want a primitive subprogram that returns an access to an element of the
+instantiation.
+
+With the ability to rename a type, you would not need to derive a new type. I
+think. Hopefully we would be allowed to complete an incomplete type with a
+renamed type.
+
+e.g.
+
+   with Generic_Synchronized_List_Package;
+
+   package Pkg is
+      type List_Type;
+
+      package Nested is
+        type T is private;
+      private
+        type T is
+          record
+            List : access List_Type;
+          end record;
+      end Nested;
+
+      type R renames Nested.T;
+
+      package I is new Generic_Synchronized_List_Package (R);
+
+      -- type List_Type is new I.List with null record;
+      -- ERROR Cannot derive if I.List is a synchronized tagged type
+
+      type List_Type renames I.List; -- This should work, hopefully
+
+   end Pkg;
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Friday, July 10, 2009  9:09 PM
+
+The problem I see is that a package involves more than a type and its
+operations.  A package defines nested generics, exceptions, objects, etc.  As it
+is now, when you use the idiom of instantiating a package and then defining a
+derived type to get the operations to be direct components of the outer package,
+you have to know that the nested generics, etc., are not direct components, but
+still require the extra level of selection.  In some way the renaming would
+help, in that you could use the nested generics and the objects without having
+to throw in some conversions to "undo" the type derivation.  But that is really
+only solving half of the problem.
+
+I really think the ability to "integrate" a generic instantiation has a lot of
+value on its own.
+
+Being able to "integrate" an arbitrary package seems useful, but less so.  Being
+able to integrate a directly declared nested package is definitely just a
+"trick" in my view, and I have become reinterested in the "end private" approach
+as preferable to the "package <> is ... end <>;"
 
 ****************************************************************

Questions? Ask the ACAA Technical Agent