CVS difference for ais/ai-00317.txt

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

--- ais/ai-00317.txt	2004/06/10 04:22:27	1.9
+++ ais/ai-00317.txt	2004/06/10 05:33:49	1.10
@@ -1,4 +1,4 @@
-!standard  12.07 (03)                                  04-06-07  AI95-00317/06
+!standard  12.07 (03)                                  04-06-10  AI95-00317/07
 !standard  12.07 (05)
 !standard  12.07 (10)
 !class amendment
@@ -114,7 +114,7 @@
 
   For the purposes of matching, if the actual instance is itself a
   formal package, then its actual parameters are those specified
-  explicitly or implicitly in the formal package actual part, plus, for
+  explicitly or implicitly in the formal_package_actual_part, plus, for
   those not specified, the copies of the formal parameters of the
   template included in the visible part of the actual instance.
 
@@ -146,6 +146,82 @@
 adjusted so as to include copies of primitive operations.
 
 
+This AI also answers a related question. If a generic formal package B
+whose actual part is (<>) is passed as an actual to another generic formal
+package A without (<>), then 12.7(5-8) requires the actuals of B to match the
+actuals of A. But what are the actuals of B? Clearly, they should be the
+entities denoted by names of the form B.x, where x is a generic formal
+parameter of B.
+
+12.7(5-8) require the actual parameters of the actual package to match
+the actual parameters of the formal package. But if the actual package
+has (<>), then its actual parameters are denoted by the formal
+parameters.
+
+Consider the following illegal example:
+
+   generic
+      type T is private;
+   package Template is
+      X : T;
+   end Template;
+
+   with Template;
+   generic
+      type Ft1 is private;
+      with package Formal_With_Actual is new Template( Ft1 );
+   package G1 is
+      Y : Ft1 := Formal_With_Actual.X;
+   end G1;
+
+   with Template;
+   generic
+      type Ft2 is private;
+      with package Formal_With_Box is new Template( <> );
+   package G2 is
+      package I3 is new G1( Ft2, Formal_With_Box ); -- Illegal!
+   end G2;
+
+The above is illegal, because the actual for Formal_With_Box is
+Formal_With_Box.T, and this does not statically match Ft2 (or anything
+else).
+
+Note that if the above were legal, the following would cause trouble:
+
+   with Template, G2;
+   package Instantiator is
+      package I1 is new Template( Integer );
+      package I2 is new G2( Boolean, I1 );
+   end Instantiator;
+
+because I2 contains a variable (Y) of type Boolean, initialized to I1.X,
+which is of type Integer.
+
+Note that we cannot defer the check of I3 until the instantiation of G2,
+because I3 could be in the *body* of G2 (instead of in the specification,
+as shown above), and this would constitute a contract model violation.
+
+Now, consider the following legal example:
+
+    generic
+       type T1 is private;
+    package G1 is ... end G1;
+
+    generic
+       type T2 is private;
+       with package FP2 is new G1(T2);
+    package G2 is ... end G2;
+
+    generic
+        with package FP3 is new G1(<>);
+    package G3 is
+        package I2 is new G2(T2 => FP3.T1, FP2 => FP3); -- OK.
+        ...
+    end G3;
+
+The instantiation I2 is legal because the actual for T2 is FP3.T1,
+which matches FP3.T1.
+
 !example
 
 Imagine a generic signature package with two formal parameters:
@@ -278,16 +354,307 @@
 
 For the purposes of matching, if the actual instance is itself a
 formal package, then its actual parameters are those specified
-explicitly or implicitly in the formal package actual part, plus, for
+explicitly or implicitly in the @fa<formal_package_actual_part>, plus, for
 those not specified, the copies of the formal parameters of the
 template included in the visible part of the actual instance.
 
 !ACATS test
 
-Create an ACATS test to check this feature.
+Create ACATS tests to check this feature. Also, create B and C tests out
+of the examples in the discussion.
 
 !appendix
 
+!section 12.7(0)
+!subject Generic Contract Model Violation ?
+!reference AARM95-12.7;6.0
+!from Jesper Joergensen 95-08-16
+!reference as: 95-5257.a Jesper Joergensen 95-8-16>>
+!discussion
+
+The use of a formal package as an actual to another formal package is a quite
+complex matter and as far as I can see we have a contract model violation with
+the present rules. Consider the example (I'm sorry, but I don't think this
+example can be shorter):
+
+
+   -- first the "template" in the sense of [AARM 12.7(4)]:
+
+   generic
+      type T is private;
+   package Template is
+      X : T;
+   end Template;
+
+
+   -- then a formal package using the template:
+
+   with Template;
+   generic
+      type Ft1 is private;
+      with package Formal_With_Actual is new Template( Ft1 );
+   package G1 is
+      Y : Ft1 := Formal_With_Actual.X;
+   end G1;
+
+
+   -- then another formal package using the template:
+
+   with Template;
+   generic
+      type Ft2 is private;
+      with package Formal_With_Box is new Template( <> );
+   package G2 is
+      pragma Elaborate_Body;   -- just to make a body for G2 legal
+   end G2;
+
+
+   -- then a unit instantiating G2:
+
+   with Template, G2;
+   package Instantiator is
+      package I1 is new Template( Integer );
+      package I2 is new G2( Boolean, I1 );
+   end Instantiator;
+
+
+   -- so far nothing is wrong (all legality rules are fulfilled), but if the
+   -- body of G2 contains an instantiation of G1 using its own formal
+   -- parameters as the actuals, we have a problem:
+
+   with G1;
+   package body G2 is
+      package I3 is new G1( Ft2, Formal_With_Box );
+   end G2;
+
+This is a legal instantiation as far as I can see. The result of all this is
+that we have a package instance I2 with the following contents:
+
+   package I2 is
+      pragma Elaborate_Body;
+   end I2;
+
+   package body I2 is
+      -- package I3 is new G1( Boolean, I1 ):
+      package I3 is
+         Y : Boolean := I1.X;
+      end I3;
+   end I2;
+
+
+And here we have a boolean variable initialized to that of an integer value!
+because we have associated the formal type T with both of these types.
+
+1. Is the above analysis correct ?
+2. If yes, don't we need a legality rule that forbids using a formal package
+   with a box as an actual package for a formal package without box. As far as
+   I can see this kind of instantiation is the only one requiring an extra
+   check in an instance (for an enclosed instance) for the rules 12.7(6-8).
+   In all other cases we only need to check for these rules at the place of
+   the individual instantiations. In the context of the above example, we
+   can't check the rules at the place of G2.I3 because we still don't know
+   the actuals for Formal_With_Box.
+
+
+/Jesper, DDC-I
+
+****************************************************************
+
+!section 12.7(00)
+!subject Generic Contract Model Violation ?
+!reference AARM95-12.7;6.0
+!reference 95-5257.a Jesper Joergensen 95-08-16
+!from Tucker Taft 95-08-16
+!reference as: 95-5260.a Tucker Taft 95-8-17>>
+!discussion
+
+> The use of a formal package as an actual to another formal package is a quite
+> complex matter and as far as I can see we have a contract model violation with
+> the present rules. Consider the example (I'm sorry, but I don't think this
+> example can be shorter):
+>
+>
+>    -- first the "template" in the sense of [AARM 12.7(4)]:
+>
+>    generic
+>       type T is private;
+>    package Template is
+>       X : T;
+>    end Template;
+>
+>
+>    -- then a formal package using the template:
+>
+>    with Template;
+>    generic
+>       type Ft1 is private;
+>       with package Formal_With_Actual is new Template( Ft1 );
+>    package G1 is
+>       Y : Ft1 := Formal_With_Actual.X;
+>    end G1;
+>
+>
+>    -- then another formal package using the template:
+>
+>    with Template;
+>    generic
+>       type Ft2 is private;
+>       with package Formal_With_Box is new Template( <> );
+>    package G2 is
+>       pragma Elaborate_Body;   -- just to make a body for G2 legal
+>    end G2;
+>
+>
+>    -- then a unit instantiating G2:
+>
+>    with Template, G2;
+>    package Instantiator is
+>       package I1 is new Template( Integer );
+>       package I2 is new G2( Boolean, I1 );
+>    end Instantiator;
+>
+>
+>    -- so far nothing is wrong (all legality rules are fulfilled), but if the
+>    -- body of G2 contains an instantiation of G1 using its own formal
+>    -- parameters as the actuals, we have a problem:
+>
+>    with G1;
+>    package body G2 is
+>       package I3 is new G1( Ft2, Formal_With_Box );
+
+This violates 12.7(5), since the actual parameter of the
+"instance" Formal_With_Box is Formal_With_Box.T, and this does not
+statically match Ft2.
+
+>    end G2;
+>
+> This is a legal instantiation as far as I can see.
+
+No, it violates 12.7(5).  When inside a generic, a
+formal-package-with-box F looks like an instance whose
+actual parameters are F.formal1, F.formal2, etc.
+These "actual" parameters only match themselves for the purposes
+of 12.7(6..8), since nothing else is known about them.
+
+Perhaps an explicit clarification of this in the RM would be helpful.
+
+> ...
+> 1. Is the above analysis correct ?
+
+No.
+
+> ...
+> /Jesper, DDC-I
+
+-Tuck
+
+****************************************************************
+
+!section 12.7(00)
+!subject Generic Contract Model Violation ?
+!reference AARM95-12.7;6.0
+!reference 95-5257.a Jesper Joergensen 95-8-16
+!from Jesper Joergensen 95-08-16
+!reference as: 95-5261.a Pascal Leroy 95-8-17>>
+!discussion
+
+>    -- first the "template" in the sense of [AARM 12.7(4)]:
+>
+>    generic
+>       type T is private;
+>    package Template is
+>       X : T;
+>    end Template;
+>
+>    -- then a formal package using the template:
+>
+>    with Template;
+>    generic
+>       type Ft1 is private;
+>       with package Formal_With_Actual is new Template( Ft1 );
+>    package G1 is
+>       Y : Ft1 := Formal_With_Actual.X;
+>    end G1;
+>
+>    -- then another formal package using the template:
+>
+>    with Template;
+>    generic
+>       type Ft2 is private;
+>       with package Formal_With_Box is new Template( <> );
+>    package G2 is
+>       pragma Elaborate_Body;   -- just to make a body for G2 legal
+>    end G2;
+>
+>    -- so far nothing is wrong (all legality rules are fulfilled), but if the
+>    -- body of G2 contains an instantiation of G1 using its own formal
+>    -- parameters as the actuals, we have a problem:
+>
+>    with G1;
+>    package body G2 is
+>       package I3 is new G1( Ft2, Formal_With_Box );
+>    end G2;
+>
+> This is a legal instantiation as far as I can see. The result of all this is
+> that we have a package instance I2 with the following contents:
+
+I may have an overly optimistic reading of the RM, but this instantiation
+seems illegal to me.  RM95 12.7(5) states that "each actual parameter of the
+actual instance shall match the corresponding actual parameter of the formal
+package". In addition, RM95 12.3(3-4) indicates that actual parameters are
+provided by a generic_actual_part.  Now the syntax in RM95 12.7(3) clearly
+says that "(<>)" is _not_ a generic_actual_part.
+
+>From these rules I draw the conclusion that your Formal_With_Box has no actual
+parameters, and therefore that the instantiation I3 is illegal, because the
+actual parameters don't match the formal parameters.
+
+Note that following this reasoning, I3 would be legal if Template had an empty
+generic_formal_part: Formal_With_Actual would have an empty
+generic_actual_part, and in this case the actual parameters of Formal_With_Box
+would match those of Formal_With_Actual.  But I don't see that you could come
+up with a contract model violation with empty formal parts...
+
+> 1. Is the above analysis correct ?
+> 2. If yes, don't we need a legality rule that forbids using a formal package
+>    with a box as an actual package for a formal package without box. As far
+as
+>    I can see this kind of instantiation is the only one requiring an extra
+>    check in an instance (for an enclosed instance) for the rules 12.7(6-8).
+>    In all other cases we only need to check for these rules at the place of
+>    the individual instantiations. In the context of the above example, we
+>    can't check the rules at the place of G2.I3 because we still don't know
+>    the actuals for Formal_With_Box.
+
+Even if your analysis was correct (which I doubt), it would not be a good idea
+to do the check in the instance.  If we want to avoid all sorts of nasty
+dependences on the contents of the generic bodies, the check must be done at
+the place of G2.I3, "assuming the worst" (as is already the case for other
+rules).
+
+Pascal.
+
+_____________________________________________________________________
+Pascal Leroy                                    +33.1.30.12.09.68
+pleroy@rational.com                             +33.1.30.12.09.66 FAX
+
+****************************************************************
+
+From the editor, July 7, 2000
+
+At the Potsdam ARG meeting (the 11th ARG meeting), it was decided that
+AI-86 should not appear in the Records of Response, as it no one was able to
+provide a explanation as to how the the conclusion follows from the existing
+text of the RM. Moreover, we didn't feel capable to write that text at this
+time.
+
+AI-86 was be changed back to a work item, in order to either find an
+appropriate explanation, or to decide on wording to implement the
+recommendation (that is, a change in status from !confirmation to !binding
+interpretation). [It was later folded into AI-317.]
+
+****************************************************************
+
 From: Tucker Taft
 Semt: Sunday, September 28, 2003 3:41 PM
 
@@ -408,6 +775,38 @@
 Sure is. I wonder what it means? :-) In particular, what's an "actual part"?
 There's no such term in the Standard's index. Do you mean "actual parameter
 list"? Or maybe you meant "formal_package_actual_part" (the syntactic entity).
+
+****************************************************************
+
+From: Tucker Taft
+Semt: Thursday, June 10, 2004  12:06 AM
+
+> I think it would be unfortunate to lose the examples and
+> discussion from AI-86 (which would happen as the AI would be
+> deleted since it was folded into AI-317). They would make good
+> ACATS tests, if nothing else. But since the problem is real and requires
+> wording to fix, it would be useful to explain the problem and the fix.
+
+Can we just concatenate the AI-86 discussion and examples to
+that of AI-317?  I would think that would work with just a
+bit of smoothing.
+
+>>   For the purposes of matching, if the actual instance is itself a
+>>   formal package, then its actual parameters are those specified
+>>   explicitly or implicitly in the formal package actual part, plus, for
+>>   those not specified, the copies of the formal parameters of the
+>>   template included in the visible part of the actual instance.
+>>
+>>That is admittedly quite a sentence. ;-)
+>
+>
+> Sure is. I wonder what it means? :-) In particular, what's an
+> "actual part"? There's no such term in the Standard's index. Do you mean
+> "actual parameter list"? Or maybe you meant "formal_package_actual_part"
+> (the syntactic entity).
+
+The phrase "formal package actual part" should have been
+the syntactic entity "formal_package_actual_part."
 
 ****************************************************************
 

Questions? Ask the ACAA Technical Agent