CVS difference for ais/ai-00317.txt

Differences between 1.2 and version 1.3
Log of other versions for file ais/ai-00317.txt

--- ais/ai-00317.txt	2002/10/29 20:24:57	1.2
+++ ais/ai-00317.txt	2003/02/05 20:47:43	1.3
@@ -1,4 +1,4 @@
-!standard  12.07 (03)                                  02-10-06  AI95-00317/01
+!standard  12.07 (03)                                  03-02-05  AI95-00317/02
 !class amendment
 !status work item 02-10-06
 !status received 02-10-06
@@ -15,7 +15,7 @@
 When a generic has more than one formal package parameter, it is often
 important to link the two packages via their actuals.  However, the
 only way to link the packages is to specify one with no actuals, and
-specify the other will all of its actuals.  For example:
+specify the other with all of its actuals.  For example:
         with package Inst1 is new Gen1(<>);
@@ -67,8 +67,42 @@
+Replace 12.7(3) with:
+    formal_package_actual_part ::=
+        (<>)
+      | [generic_actual_part]
+      | ([generic_association {, generic_association},] OTHERS => <>)
+    Any positional generic_associations shall precede any named
+    generic_associations.
+Replace 12.7(5) with the following:
+  The actual shall be an instance of the template.  If the
+  formal_package_actual_part is (<>) or (OTHERS => <>), then the actual
+  may be any instance of the template; otherwise, certain of the actual
+  parameters shall match between the actual instance and the formal
+  package:
+     * If the formal_package_actual_part includes generic_associations
+       as well as "OTHERS => <>", then only the actual parameters specified
+       explicitly in these generic_associations are required to match;
+     * Otherwise, all actual parameters shall match, whether the actual
+       parameter is given explicitly or by default.
+  The rules for matching of actual parameters between the actual instance
+  and the formal package are as follows:
+Replace 12.7(10) with the following:
+  The visible part of a formal package includes the first list of
+  basic_declarative_items of the package_specification.  In addition,
+  for each actual parameter that is not required to match, a copy of the
+  declaration of the corresponding formal parameter of the template
+  is included in the visible part of the formal package.
 This is intended to be a natural generalization of the two capabilities
@@ -78,7 +112,98 @@
 useful, without measurably increasing the complexity of supporting the
+Semantic issues/choices:
+1) Presumably (others => <>) is exactly equivalent to (<>).
+2) We don't talk about the what implicit declarations are
+   included in the visible part of the formal package
+   when the actuals are partially specified.  Can we
+   just assume the implementor will "do the right thing"?
+   Perhaps we should say that if and only if the copy of a
+   formal type is included in the visible part, the
+   associated implicit primitive operation declarations
+   are included.
+3) The wording seems a bit convoluted.
+-- Imagine a generic signature package with
+-- two formal parameters:
+    type T is private;
+    Obj : T
+package Sig is end;
+-- Now imagine there is a layered abstraction that
+-- wants two instances of this signature, and
+-- wants them to share the same type T, but not
+-- necessarily the same object "Obj."
+    with package P1 is new Sig(<>);
+    with package P2 is new Sig(P1.T, others => <>);
+package Layered_Abstraction is
+    X : P1.T := P2.Obj;  -- Both P1.T and P2.Obj are visible because
+                         -- they were not specified in the formal package.
+                         -- Note that P2.T is not visible since it
+                         -- is required to match P1.T
+    ...
+end Layered_Abstraction;
+Note that this exact situation came up while I was
+working on the physical units AI.  I wanted to pull
+out some of the nested generics from the large "System_Of_Units"
+generic.  This would require the Unit_Signature generic
+signature to have at least one additional parameter,
+the Names_Of_Dimensions:
+    type Names_Of_Dimensions is (<>);
+    Name : in String;
+    Exponents : in Exponent_Array;
+    Scale_Factor : in Scale_Type;
+    type Value is digits <>;
+package Unit_Signature is end;
+But if I wanted to use this in something that
+constructed a "product" unit from two individual
+    with package Unit_A is new Unit_Signature(<>);
+    with package Unit_B is new Unit_Signature(Unit_A.Names_Of_Dimensions, others => <>);
+package Product_Unit is
+    type Value is ...
+    ...
+end Product_Unit;
+I would need to be sure that the Names_Of_Dimensions types were
+the same.  With the Ada 95 rule, I would have to pass in all of the
+other parameters separately to be able to force a match on
+just one of them:
+    with package Unit_A is new Unit_Signature(<>);
+    Unit_B_Name : in String;
+    Unit_B_Exponents : in Exponent_Array;
+    Unit_B_Scale_Factor : in Scale_Type;
+    type Unit_B_Value is digits <>;
+    with package Unit_B is new Unit_Signature(Unit_A.Names_Of_Dimensions,
+      Unit_B_Name, Unit_B_Exponents, Unit_B_Scale_Factor, Unit_B_Value);
+package Product_Unit is
+    type Value is ...
+    ...
+end Product_Unit;
+This is clearly much less useful, and creates an asymmetric requirement
+when instantiating, where information about Unit_A can be passed
+in using a single signature instance, whereas Unit_B requires
+four additional formal parameters and then a largely redundant
+signature instance as well.
 !ACATS test

Questions? Ask the ACAA Technical Agent