CVS difference for ais/ai-00123.txt

--- ais/ai-00123.txt	2000/07/15 02:29:57	1.7
+++ ais/ai-00123.txt	2000/08/01 05:39:33	1.8
@@ -1,4 +1,4 @@
-!standard 04.05.02 (24)                               00-04-11  AI95-00123/10
+!standard 04.05.02 (24)                               00-07-31  AI95-00123/11
 !standard 04.05.02 (32)
 !class binding interpretation 96-07-23
 !status Corrigendum 2000 99-07-28
@@ -20,7 +20,7 @@
 type, or a generic actual type.
 
 For any composite type, the order in which "=" is called for components
-is not defined by the language.  Furthermore, if the result can be
+is not defined by the language. Furthermore, if the result can be
 determined before calling "=" on some components, the language does not
 define whether "=" is called on those components.
 
@@ -43,7 +43,7 @@
 
 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-25):
+tagged types, by 4.5.2(14-15):
 
   For a type extension, predefined equality is defined in terms of the
   primitive (possibly user-defined) equals operator of the parent type and of
@@ -104,7 +104,7 @@
        comparing the extension parts.
 
 Non-composability means that the predefined equality is called for T,
-despite the fact that T has a user-defined equality operator.  Of
+despite the fact that T has a user-defined equality operator. Of
 course, if there is no user-defined equality, then equality always
 composes properly.
 
@@ -112,7 +112,7 @@
 (visibly) tagged.
 
 For a private type, if the underlying type is tagged, or if there is no
-user-defined equality, then equality composes.  Otherwise, it does not.
+user-defined equality, then equality composes. Otherwise, it does not.
 (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.)
 
@@ -122,25 +122,25 @@
 normal bit-wise equality).
 
 It is important that the composability of "=" for these types be defined
-by the language.  We choose to make them composable.  An implementation
-can achieve this by making the full type tagged.  Alternatively, the
+by the language. We choose to make them composable. An implementation
+can achieve this by making the full type tagged. Alternatively, the
 implementation could simply use the predefined "=" for these types.
 (Alternatively, an implementation could treat these types specially,
-making them untagged, but with composable equality.  However, this would
+making them untagged, but with composable equality. However, this would
 add some complexity to the compiler.)
 
 Here is an analysis of implementation concerns for each type in
 question:
 
     - System.Address: The intent is for this type to directly represent
-      a hardware address.  Therefore, it is probably not feasible to
-      implement it as a tagged type.  The simplest implementation of
-      equality of Addresses is thus the normal bit-wise equality.  This
+      a hardware address. Therefore, it is probably not feasible to
+      implement it as a tagged type. The simplest implementation of
+      equality of Addresses is thus the normal bit-wise equality. This
       is what most users would expect, anyway.
 
       On certain segmented architectures, it is possible for two
-      different addresses to point to the same location.  The same thing
-      can happen due to memory mapping, on many machines.  Such
+      different addresses to point to the same location. The same thing
+      can happen due to memory mapping, on many machines. Such
       addresses will typically compare unequal, despite the fact that
       they point to the same location.
 
@@ -151,13 +151,13 @@
     - Ada.Strings.Bounded.Generic_Bounded_Length.Bounded_String: Two
       reasonable implementations are: (1) Set the unused characters to
       some particular character, and use bit-wise equality, and (2) use
-      a tagged type with a user-defined equality.  Either way, equality
-      will compose.  This is, admittedly, a slight implementation
+      a tagged type with a user-defined equality. Either way, equality
+      will compose. This is, admittedly, a slight implementation
       burden, because it rules out an untagged record with user-defined
       equality.
 
     - Ada.Strings.Unbounded.Unbounded_String: A tagged (controlled) type
-      will normally be necessary anyway, for storage reclamation.  In a
+      will normally be necessary anyway, for storage reclamation. In a
       garbage-collected implementation, a tagged type is not strictly
       necessary, but we choose to require composability anyway.
 
@@ -168,21 +168,21 @@
 
     - Ada.Task_Identification.Task_ID: This will typically be a
       pointer-to-TCB of some sort (access-to-TCB, or
-      index-into-table-of-TCB's).  In any case, bit-wise equality will
+      index-into-table-of-TCB's). In any case, bit-wise equality will
       work, so equality will compose.
 
 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
+combined with "and" or "and then". Equality operators with side effects
 are questionable in any case, so we allow implementations freedom to do
-what is most convenient and/or most efficient.  Consider equality of a
+what is most convenient and/or most efficient. Consider equality of a
 variant record: The implementation might first check that the
 discriminants are equal, and if not, skip the component-by-component
-comparison.  Alternatively, the implementation might first compare the
-common elements, and *then* check the discriminants.  A third
+comparison. Alternatively, the implementation might first compare the
+common elements, and *then* check the discriminants. A third
 possibility is to first compare some portions with a bit-wise equality,
 and then (conditionally) call user-defined equality operators on the
-other components.  All of these implementations are valid.
+other components. All of these implementations are valid.
 
 !corrigendum 4.05.02(24)
 
@@ -192,7 +192,7 @@
 equals for any matching untagged components.>
 @dinst
 For any composite type, the order in which "=" is called for components is
-not defined by the language.  Furthermore, if the result can be determined
+not defined by the language. Furthermore, if the result can be determined
 before calling "=" on some components, the language does not define whether
 "=" is called on those components.
 
@@ -204,8 +204,9 @@
 @dinst
 @i<@s8<Implementation Requirements>>@hr
 For all nonlimited types declared in language-defined packages, the "="
-operator of the type shall behave as if it were the predefined equality operator
-for the purposes of composite equality and generic formal type equality.
+and "/=" operators of the type shall behave as if they were the predefined
+equality operators for the purposes of the equality of composite types and
+generic formal types.
 
 !ACATS test