CVS difference for ais/ai-00123.txt

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

--- ais/ai-00123.txt	2000/06/21 23:39:08	1.6
+++ ais/ai-00123.txt	2000/07/15 02:29:57	1.7
@@ -11,7 +11,7 @@
 !priority High
 !difficulty Medium
 !qualifier Clarification
-!subject Equality for Composite Types
+!subject Equality for composite types
 
 !summary
 
@@ -43,32 +43,32 @@
 
 This would seem to imply that the composability of these "=" operators
 depends on whether the implementation chooses to implement them as
-tagged types, by 4.5.2(14-24):
+tagged types, by 4.5.2(14-25):
 
-  14   For a type extension, predefined equality is defined in terms of the
+  For a type extension, predefined equality is defined in terms of the
   primitive (possibly user-defined) equals operator of the parent type and of
   any tagged components of the extension part, and predefined equality for any
   other components not inherited from the parent type.
 
-  15   For a private type, if its full type is tagged, predefined equality is
+  For a private type, if its full type is tagged, predefined equality is
   defined in terms of the primitive equals operator of the full type; if the
   full type is untagged, predefined equality for the private type is that of
   its full type.
 
-  ...
+and by 4.5.2(21-24):
 
-  21   Given the above definition of matching components, the result of the
+  Given the above definition of matching components, the result of the
   predefined equals operator for composite types (other than for those
   composite types covered earlier) is defined as follows:
 
-     22  If there are no components, the result is defined to be True;
+     If there are no components, the result is defined to be True;
 
-     23  If there are unmatched components, the result is defined to be
-         False;
+     If there are unmatched components, the result is defined to be
+     False;
 
-     24  Otherwise, the result is defined in terms of the primitive equals
-         operator for any matching tagged components, and the predefined
-         equals for any matching untagged components.
+     Otherwise, the result is defined in terms of the primitive equals
+     operator for any matching tagged components, and the predefined
+     equals for any matching untagged components.
 
 This would cause portability problems.
 
@@ -108,7 +108,7 @@
 course, if there is no user-defined equality, then equality always
 composes properly.
 
-Number 3 is irrelevant here, since none of the types in question is
+Item 3 is irrelevant here, since none of the types in question is
 (visibly) tagged.
 
 For a private type, if the underlying type is tagged, or if there is no
@@ -116,7 +116,7 @@
 (Here, "underlying type" means the full type, or if that comes from a
 private type, then the underlying type of *that* type, and so on.)
 
-However, for the private types mentioned in the question, the RM does
+However, for the private types mentioned in the question, the standard does
 not specify whether the underlying type is tagged, nor whether the
 equality operator is truly user-defined (as opposed to just being the
 normal bit-wise equality).
@@ -171,7 +171,7 @@
       index-into-table-of-TCB's).  In any case, bit-wise equality will
       work, so equality will compose.
 
-As to the second question, the RM clearly does not define any order of
+As to the second question, the standard clearly does not define any order of
 calling "=" on components, nor does it say whether the results are
 combined with "and" or "and then".  Equality operators with side effects
 are questionable in any case, so we allow implementations freedom to do

Questions? Ask the ACAA Technical Agent