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

--- ai05s/ai05-0004-1.txt	2007/08/07 01:16:16	1.10
+++ ai05s/ai05-0004-1.txt	2007/09/13 02:20:42	1.11
@@ -1,4 +1,4 @@
-!standard C.7.1(17/2)                               07-08-03  AI05-0004-1/07
+!standard C.7.1(17/2)                               07-09-05  AI05-0004-1/08
 !standard 1.1.4(14.1/2)
 !standard 3.8(11)
 !standard 3.8(13.1/2)
@@ -9,6 +9,8 @@
 !standard 4.3.3(32)
 !standard 7.3(10.1/2)
 !standard 7.4(10)
+!standard 7.6(16)
+!standard 7.6(18)
 !standard 10.1.3(10)
 !standard 10.1.1(17)
 !standard 12.3(7)
@@ -70,6 +72,9 @@
 
 19) The mode of Person in Remove_First in 3.9.4(29/2) should be "out" not "in".
 
+20) Assignment operations are now defined for limited types, so 7.6(16) and 7.6(18)
+should not have parenthetical references to "nonlimited".
+
 !question
 
 1) Does C.7.1(17/2) apply to calls to Current_Task in an entry barrier? (Yes.)
@@ -145,6 +150,10 @@
 19) The mode of Person in Remove_First in 3.9.4(29/2) does not match that of the
 interface that it is derived from. Is that correct? (No.)
 
+20) The assignment operation is defined by for all types in the Amendment. But 7.6(16)
+and 7.6(18) have parenthetical remarks suggesting that they apply only to nonlimited
+types. Should that be corrected? (Yes.)
+
 [Other questions here.]
 
 !recommendation
@@ -192,6 +201,13 @@
 19) 3.9.4(29/2) should be changed as follows:
   "procedure Remove_First (Q : in out Fast_Food_Queue; Person : {out}[in] Person_Name);"
 
+2)) The first sentence of 7.6(16) should be modified:
+  To adjust the value of a [(nonlimited)] composite object, the values of the components
+  of the object are first adjusted in an arbitrary order, and then, if the object is
+  {nonlimited} controlled, Adjust is called.
+
+"nonlimited" should be deleted from 7.6(18).
+
 !discussion
 
 1) entry_barrier is syntactically within entry_body. C.7.1(17/2) however, says
@@ -269,6 +285,14 @@
 19) The mode needs to match that of the primitive subprogram of the interface that we're
 deriving from.
 
+20) These two paragraphs apply to all types, and surely should not claim to not apply
+to nonlimited types only. The implementation permission of 7.6(17.1/2) depends on 7.6(21/2),
+a rule which is under the header of 7.6(18): we better include limited types in 7.6(18).
+
+In addition, 7.6(16) should say that Adjust is called only for nonlimited controlled types,
+so that the canonical semantics (before the build-in-place requirement of 7.6(17.1/2)
+is applied) is well-defined.
+
 !corrigendum 1.1.4(14.1/2)
 
 @drepl
@@ -396,6 +420,30 @@
 @fa<access_definition>, or (only allowed in the case of an imported constant)
 the @fa<array_type_definition>.
 
+!corrigendum 7.6(16)
+
+@drepl
+To adjust the value of a (nonlimited) composite object, the values of the components
+of the object are first adjusted in an arbitrary order, and then, if the object
+is controlled, Adjust is called. Adjusting the value of an elementary
+object has no effect, nor does adjusting the value of a composite object with no
+controlled parts.
+@dby
+To adjust the value of a composite object, the values of the components
+of the object are first adjusted in an arbitrary order, and then, if the object
+is nonlimited controlled, Adjust is called. Adjusting the value of an elementary
+object has no effect, nor does adjusting the value of a composite object with no
+controlled parts.
+
+!corrigendum 7.6(18)
+
+@drepl
+An implementation is allowed to relax the above rules (for nonlimited controlled
+types) in the following ways: 
+@dby
+An implementation is allowed to relax the above rules (for controlled types) in
+the following ways: 
+
 !corrigendum 10.1.1(17)
 
 @drepl
@@ -800,5 +848,53 @@
 Sent: Wednesday, August 1, 2007  1:26 AM
 
 Correction: Remove_First is wrong, not Append
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Friday, August 24, 2007  10:38 PM
+
+Not wanting to do anything tough, I'm working on test objectives for 7.6 this evening
+before leaving. I noticed a very minor glitch in 7.6(16) and 7.6(18).
+
+7.6(13-15) talks about the canonical implementation of the assignment operation. That
+is now defined for limited types. 7.6(16) defines adjustment for, including a call to
+Adjust. The paragraph parenthetically claims to apply only to non-limited types, but that
+begs the question of what the meaning of this is for limited types. (Yes, I know that
+later requirements are intended to make this moot, but should the canonical semantics
+really be undefined??)
+
+So I suggest removing the parenthetical non-limited, and adding a word to make it clear
+that adjusting a limited type is a no-op (and surely does not call a routine that does
+not exist!):
+
+"To adjust the value of a [(nonlimited)] composite object, the values of the components
+of the object are first adjusted in an arbitrary order, and then, if the object is
+{nonlimited} controlled, Adjust is called. Adjusting the value of an elementary object
+has no effect, nor does adjusting the value of a composite object with no controlled parts."
+
+We could add something to the last phrase about limited objects, but since it is already
+considered redundant, it isn't necessary (and might be considered conflicting with the
+requirements following).
+
+The AARM note at 7.6(16.a) also needs a bit of repair.
+
+There is a similar problem with 7.6(18). It has a parenthetical "for nonlimited
+controlled types", but 7.6(21/2) is the rule that 7.6(17.1/2) is requiring to be
+implemented -- for both limited and nonlimited aggregates (and functions for that
+matter). It's quite clear that 7.6(21/2) *can* happen for limited types, the
+so-called proof of 7.6(18.a) notwithstanding.
+
+So I propose dropping "nonlimited" from 7.6(18) and fixing 7.6(18.a) to read
+something like:
+    Ramification: The rules below about assignment_statements apply only to
+    nonlimited controlled types, as assignment_statements are not allowed for
+    limited types. The other rule applies to both limited and nonlimited types,
+    and in fact is required for all assignment operations involving aggregates
+    and function calls. This is important because the programmer can count on
+    a stricter semantics for limited controlled types. 
+
+As both of these are parenthetical remarks, they don't affect the correctness of
+the language. As such, I propose to add these changes to the presentation AI.
 
 ****************************************************************