CVS difference for ais/ai-00317.txt

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

--- ais/ai-00317.txt	2004/11/03 00:53:42	1.12
+++ ais/ai-00317.txt	2004/11/14 06:37:12	1.13
@@ -1,4 +1,4 @@
-!standard  12.07 (03)                                  04-10-15  AI95-00317/09
+!standard  12.07 (03)                                  04-11-09  AI95-00317/10
 !standard  12.07 (05)
 !standard  12.07 (10)
 !class amendment
@@ -99,7 +99,7 @@
   parameter of the formal package, determined as follows:
 
      * If the formal_package_actual_part includes generic_associations
-       as well as associations with "<>", then only the actual parameters
+       as well as associations with <>, then only the actual parameters
        specified explicitly with generic_associations are required to match;
 
      * Otherwise, all actual parameters shall match, whether the actual
@@ -134,32 +134,35 @@
 useful, without measurably increasing the complexity of supporting the
 capability.
 
-We have generalized the syntax since the original proposal, to bring
-it in line with AI-287 syntax proposed for aggregates with defaulted
-components.  This allows a programmer to indicate specific parameters
-don't require matching, without resorting to the use of "others =>".
-Avoiding "others" provides some additional safety when additional generic
-formal parameters are added, since the programmer then gets to make
-an explicit choice whether a new formal parameter should be given
-a corresponding explicit actual, or a box.
+The syntax is similar to that proposed for aggregates with <>. It requires
+that individual defaulted parameters be given using named notation except
+that others => <> with the usual meaning concerning all remaining parameters
+may be used. Note, however, that avoiding others provides greater safety
+when additional formal paramters are added since the programmer than has to
+make an explicit choice as to whether a new formal parmater should be given
+an explicit actual or <>.
 
-
 There is an issue of which names are visible outside an instance:
 
     generic
         type T is new A;
-          	-- function F1 (X : T) return T; -- Implicit
+             -- function F1 (X : T) return T; -- Implicit
         type U is new B;
-            -- function F2 (X : U) return U; -- Implicit
+             -- function F2 (X : U) return U; -- Implicit
     package GP is ... end GP;
 
     generic
         ...
-        with package FP is new GP (T1, others => <>);
-            -- Can use FP.U, cannot use FP.T.
+        with package FP is new GP (T => T1, U => <>);
+             -- Can use FP.U, cannot use FP.T.
 
-So FP.F2 is OK, and FP.F1 is illegal. Thus the 12.7(10) wording has been
-adjusted so as to include copies of primitive operations.
+In the above, we suppose that F1 is an operation of A and so a
+corresponding operation for T is implicitly declared, similarly we have an
+implicitly declared operation F2 for U. The revised wording for the second
+sentence of 12.7(10) clarifies that copies of the primitive operations for
+the defaulted type U are visible whereas those for T are not. So we can
+write FP.F2 but not FP.F1; however, since we have an explicit actual type T1
+we can simply say T1.F1 anyway.
 
 This AI also answers a related question. If a generic formal package A
 whose actual part contains <> is passed as an actual to another generic
@@ -168,7 +171,8 @@
 But what are the actuals of A which are given by "<>" in the definition of A?
 Clearly, they should be the entities denoted by names of the form A.x, where x
 is a generic formal parameter of A. These are the "copies of the
-formal parameters of the template included in the visible part of A."
+formal parameters of the template included in the visible part of A" mentioned
+in the final sentence of 12.7(10).
 
 Consider the following illegal example:
 
@@ -231,8 +235,15 @@
         ...
     end G3;
 
-The instantiation I2 is legal because the actual for T2 is FP3.T1,
-which matches FP3.T1.
+The instantiation I2 is legal by the following reasoning. The instantiation
+I2 of G2 requires that the actual parameter corresponding to T2 of G2 is the
+same as the type used for the instantiation of G1 which is the actual
+package corresponding to FP2 of G2. In the instantiation I2, the package
+corresponding to FP2 (the second parameter) is FP3 which is indeed an
+instantiation of G1 and since it is with <>, the actual type for that
+instantiation is simply denoted by FP3.T1; moreover, the actual type
+corresponding to T2 (the first parameter) is explicitly given as T2 =>
+FP3.T1 and so they are the same.
 
 !example
 
@@ -240,7 +251,7 @@
 
 generic
     type T is private;
-    Obj : T
+    Obj : T;
 package Sig is end;
 
 Now imagine there is a layered abstraction that wants two instances of this
@@ -249,7 +260,7 @@
 
 generic
     with package P1 is new Sig(<>);
-    with package P2 is new Sig(P1.T, others => <>);
+    with package P2 is new Sig(T => P1.T, Obj => <>);
 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.
@@ -258,9 +269,9 @@
     ...
 end Layered_Abstraction;
 
-Note that this exact situation came up during the design of the physical units
-AI (AI-324). We wanted to pull out some of the nested generics from the large
-"System_Of_Units" generic. This would require the Unit_Signature generic
+Note that this exact situation came up during the design of a proposed physical
+units AI (AI-324). We wanted to pull out some of the nested generics from the
+large "System_Of_Units" generic. This would require the Unit_Signature generic
 signature package to have at least one additional parameter, the
 Names_Of_Dimensions:
 
@@ -314,9 +325,13 @@
     (<@>) | [generic_actual_part]>>
 @dby
 @xcode<@fa<formal_package_actual_part ::=
-    (<@>)
+    ([>@ft<@b<others>>@fa< =@>] <@>)
   | [generic_actual_part]
-  | ([generic_association {, generic_association},] >@ft<@b<others>>@fa< =@> <@>)>>
+  | (formal_package_association {, formal_package_association}, >@ft<@b<others>>@fa< =@> <@>)>>
+
+@xcode<@fa<formal_package_association ::=
+    generic_association
+  | >@ft<@i<generic_formal_parameter_>>@fa<selector_name =@> <@>>>
 
 Any positional @fa<generic_association>s shall precede any named
 @fa<generic_association>s.
@@ -337,7 +352,7 @@
 parameter of the formal package, determined as follows:
 
 @xbullet<If the @fa<formal_package_actual_part> includes
-@fa<generic_association>s as well as "@b<others> =@> <@>", then only the
+@fa<generic_association>s as well as associations with <>, then only the
 actual parameters specified explicitly in these @fa<generic_associations> are
 required to match;>
 
@@ -366,8 +381,8 @@
 
 For the purposes of matching, if the actual instance A is itself a
 formal package, then the actual parameters of A are those specified
-explicitly or implicitly in the @fa<formal_package_actual_part> for A, plus, for
-those not specified, the copies of the formal parameters of the
+explicitly or implicitly in the @fa<formal_package_actual_part> for A, plus,
+for those not specified, the copies of the formal parameters of the
 template included in the visible part of A.
 
 !ACATS test

Questions? Ask the ACAA Technical Agent