CVS difference for ais/ai-00213.txt

Differences between 1.5 and version 1.6
Log of other versions for file ais/ai-00213.txt

--- ais/ai-00213.txt	1999/04/01 22:23:43	1.5
+++ ais/ai-00213.txt	1999/04/13 15:54:27	1.6
@@ -12,10 +12,8 @@
 For a generic formal object of mode in, the rule in clause 12.7(6) is applied
 to the actual parameter of the actual instance, and the actual parameter for
 the formal package. If the actual parameter for the formal package is itself
-a formal parameter (for another generic unit), the actual for that parameter
-is used for matching. The latter rule is applied recursively, so that if the
-actual is also a formal parameter, the actual for that parameter is used,
-and so on.
+a formal parameter (of another generic unit), the actual for that parameter
+is used for matching. The latter rule is applied recursively.
 
 !question
 
@@ -119,19 +117,19 @@
 
 CC50A01
 
-When a generic unit declares, in its generic formal part, a formal package 
- with a generic_actual_part (as opposed to "(<>)"), the rules governing 
-which instances are legal as an actual parameter (RM 12.7(6)) are quite 
-strict when the generic_package_name mentioned in the formal package has 
-formal objects. In particular, if the formal object is of mode IN, then the 
-actual in the formal package and the actual in its matching actual package 
-must be static expressions with the same value, or statically denote the 
+When a generic unit declares, in its generic formal part, a formal package
+ with a generic_actual_part (as opposed to "(<>)"), the rules governing
+which instances are legal as an actual parameter (RM 12.7(6)) are quite
+strict when the generic_package_name mentioned in the formal package has
+formal objects. In particular, if the formal object is of mode IN, then the
+actual in the formal package and the actual in its matching actual package
+must be static expressions with the same value, or statically denote the
 same constant, or both be the literal null.
 
-The generic package CC50A01_0 has a formal object of mode IN in its generic 
-formal part. This generic package is used as the generic_package_name in 
-the formal package Stacker in generic CC50A01_1. The generic package 
-CC50A01_1 is then instantiated twice as CC50A01.TC_Count_Test and as CC5  
+The generic package CC50A01_0 has a formal object of mode IN in its generic
+formal part. This generic package is used as the generic_package_name in
+the formal package Stacker in generic CC50A01_1. The generic package
+CC50A01_1 is then instantiated twice as CC50A01.TC_Count_Test and as CC5
 0A01.TC_Person_Test.
 Included is an abbreviated version of the test:
 
@@ -184,23 +182,23 @@
 
 For TC_Count_Test, the value FC50A00.TC_Default_Count is specified for
 Default. Therefore Default becomes a stand-alone constant initialized to
-the value of FC50A00.TC_Default_Count by RM 12.4(10). Default is the actual 
-for the formal object TC_Default_Value in the formal package Stacker. The 
-actual for the formal package Stacker is Count_Stacks, which is a rename of 
-CC50A01_2. Its actual for the formal object TC_Default_Value is 
+the value of FC50A00.TC_Default_Count by RM 12.4(10). Default is the actual
+for the formal object TC_Default_Value in the formal package Stacker. The
+actual for the formal package Stacker is Count_Stacks, which is a rename of
+CC50A01_2. Its actual for the formal object TC_Default_Value is
 FC50A00.TC_Default_Count.
 
-For Count_Stacks to be a legal actual for the formal package Stacker, then 
+For Count_Stacks to be a legal actual for the formal package Stacker, then
 the actuals corresponding to each of their formal objects TC_Default_Count
 must be static expressions with the same value, or they must statically
-denote the same constant, or they must both be the literal null. Obviously, 
-neither is the literal null. Also, neither is a static expression because 
-they are both of tagged record types, and RM 4.9(24) in conjunction with 
-4.9(5) considers only those constants initialized with static scalar or 
-string expressions to be static expressions. Finally, they do not 
-statically denote the same constant. The actual for Count_Stacks denotes 
-the object FC50A00.TC_Default_Count, whereas the actual for Stacker denotes 
-Default, which is a new stand-alone constant merely initialized to the 
+denote the same constant, or they must both be the literal null. Obviously,
+neither is the literal null. Also, neither is a static expression because
+they are both of tagged record types, and RM 4.9(24) in conjunction with
+4.9(5) considers only those constants initialized with static scalar or
+string expressions to be static expressions. Finally, they do not
+statically denote the same constant. The actual for Count_Stacks denotes
+the object FC50A00.TC_Default_Count, whereas the actual for Stacker denotes
+Default, which is a new stand-alone constant merely initialized to the
 value of FC50A00.TC_Default_Count.
 
 Because of this, the following diagnostic is issued:
@@ -221,17 +219,17 @@
 CC50A01_3. Its actual for the formal object TC_Default_Value is
 FC50A00.TC_Default_Person.
 
-For Person_Stacks to be a legal actual for the formal package Stacker, then 
-the actuals corresponding to each of their formal objects TC_Default_Person 
-must be static expressions with the same value, or they must statically 
-denote the same constant, or they must both be the literal null. Obviously, 
-neither is the literal null. Also, neither is a static expression because 
-they are both of tagged record types, and RM 4.9(24) in conjunction with RM 
-4.9(5) considers only those constants initialized with static scalar or 
-string expressions to be static expressions. Finally, they do not 
-statically denote the same constant. The actual for Person_Stacks denotes 
-the object FC50A00.TC_Default_Person, whereas the actual for Stacker 
-denotes Default, which is a new stand-alone constant merely initialized to 
+For Person_Stacks to be a legal actual for the formal package Stacker, then
+the actuals corresponding to each of their formal objects TC_Default_Person
+must be static expressions with the same value, or they must statically
+denote the same constant, or they must both be the literal null. Obviously,
+neither is the literal null. Also, neither is a static expression because
+they are both of tagged record types, and RM 4.9(24) in conjunction with RM
+4.9(5) considers only those constants initialized with static scalar or
+string expressions to be static expressions. Finally, they do not
+statically denote the same constant. The actual for Person_Stacks denotes
+the object FC50A00.TC_Default_Person, whereas the actual for Stacker
+denotes Default, which is a new stand-alone constant merely initialized to
 the value of FC50A00.TC_Default_Person.
 
 Because of this, the following diagnostic is issued:
@@ -249,15 +247,15 @@
 
 ACAA analysis:
 
-My first reaction to this petition is ugh - if the petition is correct, the 
+My first reaction to this petition is ugh - if the petition is correct, the
 use of formal
-packages is greatly restricted Once getting past this, I found that the 
+packages is greatly restricted Once getting past this, I found that the
 operative
 part is:
 
-"Finally, they do not statically denote the same constant. The actual for 
-Count_Stacks denotes the object FC50A00.TC_Default_Count, whereas the 
-actual for Stacker denotes Default, which is a new stand-alone constant 
+"Finally, they do not statically denote the same constant. The actual for
+Count_Stacks denotes the object FC50A00.TC_Default_Count, whereas the
+actual for Stacker denotes Default, which is a new stand-alone constant
 merely initialized to the value of FC50A00.TC_Default_Count."
 
 Since the TC_Default_Count IS a constant, the only question is
@@ -301,19 +299,19 @@
       The wording in paragraphs in 12.7(5) and 12.7(6) was carefully
       constructed to insure that the actuals to the instantiations are used
       when applying 12.7(6), and not the copy defined by 12.4(10). The
-      lengthy wording "the actual parameter of the actual instance" was 
+      lengthy wording "the actual parameter of the actual instance" was
 used
       to insure that the meaning was unambiguous.
 
-      If the implementors interpretation was used, none of the matching 
+      If the implementors interpretation was used, none of the matching
 rules
       defined in 12.7(6) would be meaningful. The "stand-alone constant
       object" of 12.4(10) cannot be a static expression or the literal null
       anymore than it "denotes the same constant". Therefore, adopting the
-      implementors interpretation makes 12.7(6) completely useless, and 
+      implementors interpretation makes 12.7(6) completely useless, and
 would
       make it impossible to use formal packages with formal object of mode
-      in. Such a result is clearly nonsense, and could not have been 
+      in. Such a result is clearly nonsense, and could not have been
 intended
       by the language designers.
 
@@ -328,13 +326,13 @@
 
       We do not fully agree with this.  We agree that the actuals to the
       formal package and the actuals to the actual instance are used when
-      applying 12.7(6).  But the text in 12.7(5-6) clearly does not apply 
+      applying 12.7(6).  But the text in 12.7(5-6) clearly does not apply
 to
       actuals of the containing instance (the instance to which the actual
-      instance is an actual) or to any actuals of any instance other than 
+      instance is an actual) or to any actuals of any instance other than
 the
       formal package and the actual instance.  In particular, if the actual
-      to the formal package is a copy created for a formal object in the 
+      to the formal package is a copy created for a formal object in the
 same
       generic formal part as the formal package, then it does not apply to
       that copy for the formal object.
@@ -346,31 +344,31 @@
       But what is at issue is the actual parameter of the formal package.
       The actual parameter to the formal package is the copy made by
       12.4(10).  Again, for TC_Count_Test, this is the actual for
-      TC_Count_Test.Stacker, which is TC_Count_Test.Default.  There does 
+      TC_Count_Test.Stacker, which is TC_Count_Test.Default.  There does
 not
-      appear to be any rule to indicate that the actual corresponding to 
+      appear to be any rule to indicate that the actual corresponding to
 the
       formal object in the containing instance (which would be
       FC50A00.TC_Default_Count) should be used.
 
-      We agree that this interpretation of 12.7(5-6) makes the matching 
+      We agree that this interpretation of 12.7(5-6) makes the matching
 rules
       for formal objects of mode "in" overly strict, although it doesn't
       quite make them meaningless.  Formal packages are only unmatchable
-      because of formal objects of mode "in" when a sibling formal object 
+      because of formal objects of mode "in" when a sibling formal object
 in
-      the same generic formal part or an entity declared in a sibling 
+      the same generic formal part or an entity declared in a sibling
 formal
       package in the same generic formal part is used as the actual of the
       formal package.
 
-      Implementing the matching rules in a less strict way is not 
+      Implementing the matching rules in a less strict way is not
 difficult.
       It merely involves using the initial values of copies created for
-      formal objects in the right circumstances.  But because we can find 
+      formal objects in the right circumstances.  But because we can find
 no
       language rule that precisely specifies these circumstances, it is
-      difficult to know where to draw the line and stop searching the 
+      difficult to know where to draw the line and stop searching the
 initial
       value chains for an "ultimate actual".  For instance, consider the
       following example:
@@ -404,24 +402,24 @@
          package i2 is new g2 (obj, i0, i1);
 
       Pretend that g2.f1 is a legal formal package and i1 is a legal
-      instance.  It is unclear whether or not i2 is a legal instance.  In 
+      instance.  It is unclear whether or not i2 is a legal instance.  In
 i2,
       12.7(6) requires that the actual of the actual instance i1 (obj) must
-      statically denote the same constant as the actual of the formal 
+      statically denote the same constant as the actual of the formal
 package
-      i2.f1 (i2.f0.copy, or i0.copy), which is a constant initialized to 
+      i2.f1 (i2.f0.copy, or i0.copy), which is a constant initialized to
 the
       value of i0.default, which is a constant initialized to the value of
       its corresponding actual (obj).  If the implementation followed this
-      chain completely and used obj as the actual of the formal package, 
+      chain completely and used obj as the actual of the formal package,
 then
-      i2 would be legal.  But if the presence of a non-formal object in 
+      i2 would be legal.  But if the presence of a non-formal object in
 this
-      chain of initializations indicates that the implementation should 
+      chain of initializations indicates that the implementation should
 stop
       searching for the "ultimate actual", then i2 would be illegal.
 
-      If the latter were the case, then consider a slightly more 
+      If the latter were the case, then consider a slightly more
 complicated
       example:
 
@@ -460,14 +458,14 @@
       which is a new constant initialized to the value of its actual (obj).
       In this case, the initialization chain contains only a single formal
       object.  In some respects it is like the example in CC50A01.  But in
-      this example, the formal object is not of the containing instance as 
+      this example, the formal object is not of the containing instance as
 it
-      was in TC_Count_Tests, but rather of a sibling formal package 
+      was in TC_Count_Tests, but rather of a sibling formal package
 (i2.f0).
       So, should its initial value be used for the rule in 12.7(6) or not?
-      If it should, then i2 would be legal.  But if the presence of a 
+      If it should, then i2 would be legal.  But if the presence of a
 formal
-      object of an unrelated formal package indicates that the 
+      object of an unrelated formal package indicates that the
 implementation
       should stop searching for the "ultimate actual", then i2 would be
       illegal.
@@ -495,32 +493,32 @@
          package i0 is new g0 (obj);
          package i1 is new g1 (obj, f0 => i0);
 
-      In i1, 12.7(6) requires that the actual of the actual instance i0 
+      In i1, 12.7(6) requires that the actual of the actual instance i0
 (obj)
       must statically denote the same constant as the actual of the formal
-      package i1.f0 (i1.default2), which is a constant whose initial value 
+      package i1.f0 (i1.default2), which is a constant whose initial value
 is
-      i1.default1, which is another constant whose initial value is obj. 
+      i1.default1, which is another constant whose initial value is obj.
  So,
-      if the second formal object's initial value should be used for 
+      if the second formal object's initial value should be used for
 12.7(6),
-      then i1 would be legal.  But if the presence of a second formal 
+      then i1 would be legal.  But if the presence of a second formal
 object
       indicates that the implementation should stop searching for the
       "ultimate actual", then i1 would be illegal.
 
-      Although we agree that our interpretation of 12.7(5-6) is possibly 
+      Although we agree that our interpretation of 12.7(5-6) is possibly
 not
       the intent of the language designers, we do believe that it follows
       from the rules of the RM.  Determining the precise intent of the
-      language designers is a difficult matter in this case.  We can 
+      language designers is a difficult matter in this case.  We can
 imagine
       several different useful intents, including:
 
        * Initial values of any constants in the chain of initializations
          should be used.
        * Only initial values of copies of formal objects should be used.
-       * Only initial values of copies of formal objects declared somewhere 
+       * Only initial values of copies of formal objects declared somewhere
          (possibly nested in another formal package) in the same generic
          formal part as the formal package should be used.
        * Only initial values of copies of formal objects declared
@@ -528,16 +526,16 @@
          package should be used.
        * Only the first initial value of a copy of a formal object, if any,
          should be used.
-       * No initial values of copies for formal objects should ever be 
+       * No initial values of copies for formal objects should ever be
 used;
-         the copy for the formal object should be used, itself.  [The 
+         the copy for the formal object should be used, itself.  [The
 strict
          RM rule, and our interpretation.]
 
-      We do not consider it appropriate for us to guess at the intent of 
+      We do not consider it appropriate for us to guess at the intent of
 the
       language designers, when there are so many possibilities.  So, we
-      repetition that this test be withdrawn until and unless an AI 
+      repetition that this test be withdrawn until and unless an AI
 clarifies
       this issue.
 
@@ -552,8 +550,8 @@
 The thing I missed before was that there were two generic
 formal objects involved, not just one.
 
-If you stare at the source for cc50a01.a starting at line 188, 
-you will see the following (with some slight changes to emphasize 
+If you stare at the source for cc50a01.a starting at line 188,
+you will see the following (with some slight changes to emphasize
 differences):
 
     generic
@@ -562,13 +560,13 @@
         with package Stacker is new Gen_Pkg(Item_Type, Default);
     procedure Gen_Proc ...
 
-The point the petitioner is making is that the formal object "Default" 
+The point the petitioner is making is that the formal object "Default"
 above is used as the *actual* in the formal package declaration for Stacker.
 
 That is doomed to failure, since there could be no instantiation
 of Gen_Pkg (outside of the generic Gen_Proc itself) which could have an actual
 that statically denoted the constant "Default."  The constant "Default"
-is simply not visible outside of Gen_Proc.  "Default" is a new constant, 
+is simply not visible outside of Gen_Proc.  "Default" is a new constant,
 created anew each time Gen_Proc is instantiated.
 
 I looked at our own Ada 95 front end implementation to figure out
@@ -591,7 +589,7 @@
 and change the instantiations to only pass in the package,
 rather than passing in the item_type and the default as well.
 
-The original test construct should probably be incorporated into some B 
+The original test construct should probably be incorporated into some B
 test at some point (not anytime soon, I hope).
 
 -Tuck
@@ -602,8 +600,8 @@
 Sent: 	Wednesday, November 25, 1998 5:40 PM
 Subject: RE: Generic formal package matching.
 
->If you stare at the source for cc50a01.a starting at line 188, 
->you will see the following (with some slight changes to emphasize 
+>If you stare at the source for cc50a01.a starting at line 188,
+>you will see the following (with some slight changes to emphasize
 >differences):
 >
 >    generic
@@ -612,7 +610,7 @@
 >        with package Stacker is new Gen_Pkg(Item_Type, Default);
 >    procedure Gen_Proc ...
 
->The point the petitioner is making is that the formal object "Default" 
+>The point the petitioner is making is that the formal object "Default"
 >above is used as the *actual* in the formal package declaration for Stacker.
 
 Yes...but this is the standard usage for generic formal packages.
@@ -622,7 +620,7 @@
 >That is doomed to failure, since there could be no instantiation
 >of Gen_Pkg (outside of the generic Gen_Proc itself) which could have an actual
 >that statically denoted the constant "Default."  The constant "Default"
->is simply not visible outside of Gen_Proc.  "Default" is a new constant, 
+>is simply not visible outside of Gen_Proc.  "Default" is a new constant,
 >created anew each time Gen_Proc is instantiated.
 
 Right, but then any useful use of a generic formal package with a generic
@@ -775,8 +773,8 @@
 I suggest we offer this vendor a choice:  We may rule this test
 inapplicable to them, but they are required to add the flexibility
 to their compiler before their next validation (presuming a binding
-interpretation AI is imminent).  Better, for uniformity's sake, 
-we encourage them to add the flexibility to their compiler so they 
+interpretation AI is imminent).  Better, for uniformity's sake,
+we encourage them to add the flexibility to their compiler so they
 can pass this test, as all other validated compilers have already done.
 
 In any case, an AI is very much needed here.

Questions? Ask the ACAA Technical Agent