CVS difference for ais/ai-00123.txt

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

--- ais/ai-00123.txt	1998/09/30 00:17:20	1.1
+++ ais/ai-00123.txt	1999/07/29 00:51:02	1.2
@@ -1,5 +1,6 @@
-!standard 04.05.02 (24)                               97-05-27  AI95-00123/07
+!standard 04.05.02 (24)                               99-07-28  AI95-00123/08
 !class binding interpretation 96-07-23
+!status Corrigendum 2000 99-07-28
 !status WG9 approved (8-0-0) 97-07-04
 !status ARG approved 10-0-2 (subject to editorial review)  96-10-07
 !status work item (letter ballot was 6-6-0) 96-10-03
@@ -10,7 +11,7 @@
 !difficulty Medium
 !subject Equality for Composite Types
 
-!summary 97-05-08
+!summary
 
 The primitive equality operators of a language-defined type compose
 properly (i.e., do not "reemerge"), when the type is used as a component
@@ -21,7 +22,7 @@
 determined before calling "=" on some components, the language does not
 define whether "=" is called on those components.
 
-!question 96-07-23
+!question
 
 The following language-defined types are private, and have an explicitly
 defined primitive "=" operator:
@@ -67,14 +68,16 @@
 language define whether all of these side effects happen, and in what
 order?
 
-!recommendation 96-11-16
+!recommendation
 
 (See summary.)
 
-!wording 96-07-23
+!wording
 
-!discussion 97-05-27
+(See corrigendum.)
 
+!discussion
+
 Composability of equality for a type T means three things:
 
     1. If a composite type has a component of type T with a user-defined
@@ -120,7 +123,7 @@
 Here is an analysis of implementation concerns for each type in
 question:
 
-    - System.Address: The intent is for this type to directly represent 
+    - System.Address: The intent is for this type to directly represent
       a hardware address.  Therefore, it is probably not feasible to
       to implement it as a tagged type.  The simplest implementation of
       equality of Addresses is thus the normal bit-wise equality.  This
@@ -171,8 +174,42 @@
 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.
+
+!corrigendum 4.05.02(20)
+
+@dinsa
+The analogous definitions apply if the types of the two objects or
+values are convertible, rather than being the same.
+@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
+before calling "=" on some components, the language does not define whether
+"=" is called on those components.
+
+!corrigendum 4.05.02(32)
+
+@dinsa
+A membership test using @b<not in> gives the complementary result to the
+corresponding membership test using @b<in>.
+@dinst
+@i<@s8<Implementation Requirements>>@hr
+Certain language-defined packages provide private types with an explicit
+declaration of the "=" operator. The implementation of the "=" operator
+shall be such that it composes properly (i.e., that no predefined equality
+of the full type "reemerges"), when the type is used as a component type, or
+as a generic actual type.
+
+!ACATS test
+
+Create a C-Test to check that equality of language-defined types
+compose properly when used as a component or as a generic formal.
+(There is no surefire way to do this, but a test that insures
+the results of predefined equality on a type with components
+of the language-defined types matches the results of the
+equality for those types should suffice. Try independently derived
+objects that have the same values, as well as some different objects.)
 
-!appendix 97-03-19
+!appendix
 
 !section 4.5.2(24)
 !subject Equality for composite types
@@ -322,7 +359,7 @@
 could be (required to be) implemented either as a tagged type or in such
 a way that predefined "=" works correctly.
 
--- 
+--
 Keith Thompson (The_Other_Keith)  kst@thomsoft.com (kst@alsys.com still works)
 TeleSoft^H^H^H^H^H^H^H^H Alsys^H^H^H^H^H Thomson Software Products
 10251 Vista Sorrento Parkway, Suite 300, San Diego, CA, USA, 92121-2718
@@ -389,7 +426,7 @@
 
 The analysis of type System.Address in AI95-00123 currently says:
 
-    - System.Address: The intent is for this type to directly represent 
+    - System.Address: The intent is for this type to directly represent
       a hardware address.  Therefore, it is probably not feasible to
       to implement it as a tagged type.  This AI implies therefore that
       equality of Addresses must be implemented as the normal bit-wise
@@ -442,7 +479,7 @@
 version of Ada.
 
 Note that by this criterion, I also find the language of the AI dubious, since
-it also reasons by what might be in the Ada implementation. For example, 
+it also reasons by what might be in the Ada implementation. For example,
 suppose that I don't use a tagged type, and I still let some strange
 non-bit equality compose, is this improper? Certainly not, since there is
 nothing improper about implementing type Address with a tagged type, that
@@ -646,98 +683,36 @@
 
 >Bob Duff says:
 >
->    - The implementation uses a special hack to make the "=3D" compose.
->      IMHO, this simply isn't feasible -- it adds too much complexity =
-to the
+>    - The implementation uses a special hack to make the "=" compose.
+>      IMHO, this simply isn't feasible -- it adds too much complexity to the
 >      compiler.  In theory, it's possible, but in practice, no compiler
 >      writer would do this.
 >
 >Not at all, at least in GNAT it is trivial to extend proper equality
->composition to any type. Since Ada has this peculiar rule that =
-sometimes
+>composition to any type. Since Ada has this peculiar rule that sometimes
 >equality composes and sometimes it does not, the compiler has to handle
 >the general case anyway.
 >
 >I agree however that in practice address comparison will almost always
 >involve comparing the bits.
 
-I agree completely with Robert.  Our compiler also is prepared to =
-compose
+I agree completely with Robert.  Our compiler also is prepared to compose
 everything properly, and do a component-by-component comparision for any
 type.
 
-In our case, all we need to do is to mark the scalar type appropriately, =
-and
+In our case, all we need to do is to mark the scalar type appropriately, and
 a component-by-component comparison will be used.  We used this property
 to great effect on the 1's complement U2200 compiler: bitwise comparsion
-of integers does not work, since -0 and 0 compare differently when a =
-bitwise
+of integers does not work, since -0 and 0 compare differently when a bitwise
 comparsion is made, and compare the same when an arithmetic comparsion
 is made.
-
-Doing something similar for address would be trivial, and we would do it =
-in a
-minute if a case where it mattered arose.  (Use of System.Address as an =
-object ought to be rare in Ada 95, so the runtime cost is not a =
-concern).
-
-Therefore, I strongly disagree with the statement that "in practice, no =
-compiler
-writer would do this.", especially given that we had to do it for =
-integer types on
-the U2200.
-
------- =_NextPart_000_01BBD869.117B9CA0
-Content-Type: application/ms-tnef
-Content-Transfer-Encoding: base64
-
-eJ8+IgURAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAENgAQAAgAAAAIAAgABBJAG
-AHgBAAABAAAADAAAAAMAADADAAAACwAPDgAAAAACAf8PAQAAAH8AAAAAAAAAtTvCwCx3EBqhvAgA
-KypWwhUAAACQAar7GenOEbvGREVTVAAAxIEAAAAAAACBKx+kvqMQGZ1uAN0BD1QCAAAAAEFkYSBD
-b21tZW50AElOVEVSTkVUAGFkYS1jb21tZW50QHN3LWVuZy5mYWxscy1jaHVyY2gudmEudXMAAB4A
-AjABAAAACQAAAElOVEVSTkVUAAAAAB4AAzABAAAAJgAAAGFkYS1jb21tZW50QHN3LWVuZy5mYWxs
-cy1jaHVyY2gudmEudXMAAAADABUMAQAAAAMA/g8GAAAAHgABMAEAAAAOAAAAJ0FkYSBDb21tZW50
-JwAAAAIBCzABAAAALwAAAElOVEVSTkVUOkFEQS1DT01NRU5UQFNXLUVORy5GQUxMUy1DSFVSQ0gu
-VkEuVVMAAAMAADkAAAAACwBAOgEAAAACAfYPAQAAAAQAAAAAAAADqk8BCIAHABgAAABJUE0uTWlj
-cm9zb2Z0IE1haWwuTm90ZQAxCAEEgAEAIQAAAFJFOiBFcXVhbGl0eSBmb3IgQ29tcG9zaXRlIFR5
-cGVzAK4LAQWAAwAOAAAAzAcLABYACwAiAAQABQAqAQEggAMADgAAAMwHCwAWAAsAGQAXAAUANAEB
-CYABACEAAAAwQjdDNTBBMDlENDNEMDExQjM1NzAwQzBGMDAzMDk4OQDjBgEDkAYANAcAABIAAAAL
-ACMAAAAAAAMAJgAAAAAACwApAAAAAAADADYAAAAAAEAAOQCgfglbm9i7AR4AcAABAAAAIQAAAFJF
-OiBFcXVhbGl0eSBmb3IgQ29tcG9zaXRlIFR5cGVzAAAAAAIBcQABAAAAFgAAAAG72Jta8aBQfAxD
-nRHQs1cAwPADCYkAAB4AHgwBAAAAAwAAAE1TAAAeAB8MAQAAABQAAABXaW5kb3dzL2FkbWluL1Jh
-bmR5AAMABhDXY6WKAwAHEM8FAAAeAAgQAQAAAGUAAABUT1BJQ0VRVUFMSVRZRk9SQ09NUE9TSVRF
-VFlQRVNSRUZFUkVOQ0VBSTk1LTAwMTIzLzA0UkVGRVJFTkNFUk05NS00NTIoMTIpUkVGRVJFTkNF
-OTYtNTc2MEFLRUlUSFRIT01QAAAAAAIBCRABAAAAtAUAALAFAAAfDAAATFpGdQWE9pn/AAoBDwIV
-AqgF6wKDAFAC8gkCAGNoCsBzZXQyNwYABsMCgzIDxQIAcHJCcRHic3RlbQKDM3cC5AcTAoB9CoAI
-zwnZO/EWDzI1NQKACoENsQtg4G5nMTAzFFALChRRKwvyE1BvE9BjBUAhdABvcGljIEVxdeEHQGl0
-eSACEAXACFAYbXBvAJAT0CBUedZwB5AKhSEWEGYEkAnwAmMc8EFJOTUtMIAwMTIzLzA0HW8FB/BN
-HqE0LjUuMgooHvApH18gOTYtADU3NjAuYSBLqmUb8GgdAGgcgXMCIGkiYjExJCA5IV8iZTHbIuEI
-AGIEkAVARAfQCsFfJGAkBAHQJI8iZTImGEH9JqB1DdAj9SefIkcgwCYv7SpVMQqHGetjAEAbIANS
-CwfwAHBkHBBCcnVrtwsRBUAqVTIuDxpsZAQAdGN1BBBpAiAKhQqFPvsufy+AQjHvGtQsoCnxNP/T
-L4AqIXNhE7A6Nj8a1P8xfy8XNO46nzuvPL8axUFC/i0jYRzwB3ALUBPgCfABkLp0M9EgM6AHkSLw
-cx0wimMHMSARgGNrIBtAOiAAwGsc8CNAHPAiPcwiIAWgHJJlLj4/P0+DQF9BQ0lNSE8sRJGfBAA5
-QEHyHBAEAG4nBUDdHgBhAJACYBzwLUGQG/C5QyBkZAQgG0BEMXURcPtFE0IgeBvyRCFEoUWvRr/f
-R89BQ0UiAxAEkC5JAQOg20ShBbB5SWAb8CcEIByhc0rTSWBidQVAC4BSoHLvANBCkB5QSWBuRDBR
-Bk2Pd06fT69BQ3cFEBPQBcB34QhgbGQgZE0yBABFn99WH1cvWe9a/zJeThrQQyD5S3FsbElgYGFC
-IErAU3OwR05BVEtSSaF0BRD+dkOSRCFMwBPQMCBTsRtQ/VjRZRu1XQ9eHzJeRSQb8L9CokQhAHBN
-AR0hUYBTC4D9HlJkIvARgEvBSZJDYVkg/wcwBcAwcEsBI0BgYSPAB4D/QpAHgWRvZX8yXmPmRRZD
-Eb9jQWt3S1JZYAeRVGB0SWL/HPBRBmmkRDARgDAgQiBsD3dtHzJeRKJnCfAEkEOhY+9KwBzwaHEm
-0HlZ33Sfda93eD95TzJeSUMgCcJDwG/4d2V2WNFrI1OZS4IWEP8EEUUiCsAEACPRA/BgoGCB/wRg
-YUEHQHfxa/gZn3yvGnp9C4B2BvB/MID2GRBEk2L/G/BZwITcNGaC1X52THQT0N9KEQPwI0EslFGB
-TwhwcijvB0AjwGISE1BlgwEJgEQS90UlgtV/InlJgYcxY3RKEH9gwWNBWWEi8EUjdxACMC34Ynkt
-kKeA90KiHDJocf+C1WiziO0DoAhhd2NgwYHRf38QVFAJ4I2TWWFiIkQycr9EAUHBBPAHQJOFQyBw
-Y3L/ByGKoo/zgtWQj5GegYYssPVC0mRRgVectGnlY4NkR/9EIQnBYGENwTdjUcMnAFKBc0x0QkIg
-VTFQHtBQ9zrvh5ID8YamM8lvKjALgBPQ/3bwEaBxR1jxl1BJYACQHkJ/HsBwM6GkjWFZUAaQHgN0
-/4rCQcADoCLwomWC1aLoYhLfAMANsI/0ppaXg2EHgKfF+6gBWKFoa5IbgKLvqdWT/fxEb4cia3OP
-I0nRAxAKwf+S04CVWQScoWJVj/SV8VkH72HyqAGC1bBwblNgQdEqMP+aEXeCp9Gm4UthAMACQB4R
-z1lACsBFYkFAKFV3kaPxfROkLmlwgKRpwQORLKBq8TdjdWdodpFEMJyhU9D/tdIDoGlyHqClgU0z
-asECMH8HcUURYUKk5JoSHkEEoCn/k/2DT4ixQbEd4QWwUyF+cP8TwANgGRBKETNhfpSK85eD90Jx
-oQRrIyKE34XmU79UyudYn0mRh/0uIklgB5BDZP1KEWdicKfxayOV8RGAllf/SoEFsaQlaKMEIDPn
-RKKhYwuT/RUxAM7gAwAQEAEAAAADABEQAQAAAEAABzDAzPokmti7AUAACDDAzPokmti7AR4APQAB
-AAAABQAAAFJFOiAAAAAAgXo=
-
------- =_NextPart_000_01BBD869.117B9CA0--
-
 
+Doing something similar for address would be trivial, and we would do it in a
+minute if a case where it mattered arose.  (Use of System.Address as an object
+ought to be rare in Ada 95, so the runtime cost is not a concern).
+
+Therefore, I strongly disagree with the statement that "in practice, no
+compiler writer would do this.", especially given that we had to do it for
+integer types on the U2200.
 
 ****************************************************************

Questions? Ask the ACAA Technical Agent