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

Differences between 1.2 and version 1.3
Log of other versions for file ai05s/ai05-0011-1.txt

--- ai05s/ai05-0011-1.txt	2006/04/01 06:59:17	1.2
+++ ai05s/ai05-0011-1.txt	2006/04/20 05:30:39	1.3
@@ -2843,3 +2843,159 @@
 I agree that these are all interesting and useful topics to study.
 
 ****************************************************************
+
+From: Stephen W. Baird
+Date: Monday, April  4, 2006  2:25 PM
+
+>    1) allowing children of generics to be instantiations
+>       rather than generics;
+>    ...
+> Within the scope of a with clause for the
+> child of the generic, any instantiation of the generic
+> will create a child of the instantiation with the same name.
+
+It is not clear that this topic is still of general interest,
+but here is another problem with this proposal.
+
+If one child unit refers to another, and if an instance of
+the parent occurs within the scope of a with clause for the
+first child unit, then the instance had better behave as
+though the second child unit had also been withed. If we
+allow two-part children (not just instances), then this
+would include the case where the 2nd child is withed by
+the body of the 1st. This gets even messier if the 1st child
+unit is itself a generic, and therefore follows the original
+Ada95 "sprouting" rules; this case would probably have to be
+disallowed somehow (see example #2 below).
+
+    -- Steve
+
+Example #1:
+
+  generic
+     with procedure Put_Line (S : String);
+  package G is
+     N : Integer := 10;
+  end G;
+
+  package G.Child1 is
+  private
+     type T;
+  end G.Child1;
+
+  package G.Child2 is
+    S : String := Integer'Image (N);
+  end G.Child2;
+
+  with G.Child2;
+  package body G.Child1 is
+    type T is  ... ;
+  begin
+     Put_Line (Child2.S);
+  end G.Child1;
+
+  with G.Child1;
+  package I is new G ( ... );
+
+  -- If this sequence of units is accepted,
+  -- then the declaration of I.Child2.S must
+  -- somehow be elaborated.
+
+Example #2:
+
+  generic
+     with procedure Put_Line (S : String);
+  package G is
+     N : Integer := 10;
+  end G;
+
+  generic -- in this version, Child1 is a generic
+  package G.Child1 is
+  private
+     type T;
+  end G.Child1;
+
+  package G.Child2 is
+    S : String := Integer'Image (N);
+  end G.Child2;
+
+  with G.Child2;
+  package body G.Child1 is
+     type T is  ... ;
+  begin
+     Put_Line (Child2.S);
+  end G.Child1;
+
+  -- no with of Child1 at this point
+  package I is new G ( ... );
+
+  with G.Child1;
+  with I;
+  package Ii is new I.Child1;
+
+  -- If this sequence of units is accepted,
+  -- then the declaration of I.Child2.S must
+  -- somehow be elaborated.
+
+
+****************************************************************
+
+From: Tucker Taft
+Date: Monday, April  4, 2006  2:25 PM
+
+> If one child unit refers to another, and if an instance of
+> the parent occurs within the scope of a with clause for the
+> first child unit, then the instance had better behave as
+> though the second child unit had also been withed.
+
+Agreed, except that any unit that is not explicitly with'ed
+at the point of the instantiation would not be visible
+outside the instance.  It is as though they become "private"
+children of the instance.  I agree you need to do the usual
+"closure" thing, but from a visibility point of view,
+you only can talk about the children you mention in
+with clauses.
+
+I would probably go further and require that the non-generic
+children be mentioned *again* when you reference the
+instance.  What this would mean is that both generic and
+non-generic children of generics would need to be mentioned
+at the point of use to be visible, and non-generic children
+need to be mentioned at the point of instantiation as well.
+
+> ...
+> If we
+> allow two-part children (not just instances), then this
+> would include the case where the 2nd child is withed by
+> the body of the 1st. This gets even messier if the 1st child
+> unit is itself a generic, and therefore follows the original
+> Ada95 "sprouting" rules; this case would probably have to be
+> disallowed somehow (see example #2 below).
+
+Good point.  An important feature of generic children of
+generics is that they can be added "after the fact,"
+that is, after the generic parent has already been instantiated.
+If such a generic child were to start imposing requirements
+on the instantiations that already occurred, that would be
+quite difficult.
+
+Perhaps limited with clauses might fit in here somewhere.
+If a parent spec has a limited with for one of its children,
+then that would imply the child is "needed," and perhaps
+only such children are visible to other generic children.
+
+****************************************************************
+
+From: Stephen W. Baird
+Date: Monday, April  4, 2006  2:25 PM
+
+> Agreed, except that any unit that is not explicitly with'ed
+> at the point of the instantiation would not be visible
+> outside the instance. 
+
+Right. When I said that "the instance had better behave as
+though the second child unit had also been withed", I was
+talking about dynamic semantics and the set of
+declarations that need to be elaborated.
+
+****************************************************************

Questions? Ask the ACAA Technical Agent