From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,c3a7c1845ec5caf9 X-Google-Attributes: gid103376,public From: stt@houdini.camb.inmet.com (Tucker Taft) Subject: Re: Equality operator overloading in ADA 83 Date: 1997/05/02 Message-ID: #1/1 X-Deja-AN: 238837149 Sender: news@inmet.camb.inmet.com (USENET news) X-Nntp-Posting-Host: houdini.camb.inmet.com References: Organization: Intermetrics, Inc. Newsgroups: comp.lang.ada Date: 1997-05-02T00:00:00+00:00 List-Id: Matthew Heaney (mheaney@ni.net) wrote: : In article , bobduff@world.std.com (Robert A : Duff) wrote: : >In retrospect, I tend to agree that we should have gone a wee bit : >further in composability of "=". Especially since "=" on nonlimited : >types is a new feature (except for the Goodenough trick, which is silly : >to worry about). And because "=" is already special anyway -- the magic : >"/=" you get for free, the fact that dispatching calls to "=" do a : >different sort of tag check, etc. : > : >However, I'm not quite sure how far we should have gone. Not very. : >Certainly not to extending composability to other operators, and : >certainly not affecting the semantics of "in" or "case". Perhaps I'd : >consider such things for a new language, but not for Ada 9X. : Yes, I agree; that about sums it up nicely. I feel that the language : should have guaranteed that equality composes, when redefined for : nonlimited, untagged types. I'm not passionate about other operators (how : many times do you have "<" for records?). One suggestion which was made (a bit late) was to make a user-defined "=" on records the "official" "=" for the record type, and have the predefined "=" never reemerge for records. This is just expanding the current rule for tagged records to apply to all record types. Since things like "case" don't apply to record types, this imposes essentially no additional burden on the implementation. In retrospect, treating all records specially in this way, rather than just "tagged" records, might have been a better choice. On the other hand, I agree with Robert that using "=" on records is rare to begin with, and gets extremely rare when you start talking about arrays of records, or records of records. Reemergence inside generics is perhaps the real issue, but there, you can always import the "=" operator explicitly, with a default of "<>", so the current state isn't too bad. A part of the rationale for the Ada 95 choice related to the rules for overriding primitive operators/subprograms. For untagged types, the Ada 83 rules were preserved, where only type conformance was required for overriding. For tagged types, we impose a stricter subtype conformance on overriding of primitive operators/subprograms. Without this stricter conformance rule, reemergence in a generic is almost required to avoid bizarre contract model violations. This partially explains why operators and other primitive subprograms reemerge in a generic for a formal untagged derived type as well. One might want to consider going to a stricter conformance rule for overriding of primitives for all record types, rather than just for tagged record types, as part of also eliminating reemergence of operators and other primitives of all record types. As one example of where reemergence is desirable, there are generic packages which rely on arithmetic operators to have their normal effects. For example, a generic package like Text_IO.Integer_IO might very well do some computation to convert to or from a string representation of an integer. If the user has done some bizarre overriding of the arithmetic operators for a particular integer type, it is quite likely that a generic like Text_IO.Integer_IO would act bizarrely if the predefined operators did not reemerge. This kind of problem does not seem to be as big an issue with overriding of the equality operator of a non-numeric type. Anyway, rest assured that this particular issue of operator reemergence was debated hotly several times during the Ada 95 process. The upward compatibility of the final choice was a powerful reason in its favor, but it wasn't the only one... : ... : Matt : -------------------------------------------------------------------- : Matthew Heaney : Software Development Consultant : : (818) 985-1271 -- -Tucker Taft stt@inmet.com http://www.inmet.com/~stt/ Intermetrics, Inc. Burlington, MA USA