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: bobduff@world.std.com (Robert A Duff) Subject: Re: Equality operator overloading in ADA 83 Date: 1997/04/24 Message-ID: #1/1 X-Deja-AN: 237233128 References: <01bc4e9b$ac0e7fa0$72041dc2@lightning> <335E0B1F.12C9@elca-matrix.ch> <335F5971.6375@elca-matrix.ch> Organization: The World Public Access UNIX, Brookline, MA Newsgroups: comp.lang.ada Date: 1997-04-24T00:00:00+00:00 List-Id: In article <335F5971.6375@elca-matrix.ch>, Mats Weber wrote: >Yes, I would affect case statements, So, you mean: type T is range -10**9..10**9; function "="(X, Y: T) return Boolean; -- I hate "Left" and "Right". X: T; subtype Negative is T range T'First..-1; subtype Positive is T range 1..T'Last; case X is when Negative => Do_This; when 0 => Do_That; when Positive => Do_The_Other_Thing; end case; This should compare a billion numbers for equality with X, using the user's "=" operator? Hmm. Perhaps a reasonable thing for a new language, but rather out of the question for a "language revision" like Ada 9X. Of course, if one could redefine "in".... >...and also allow case for types other >than discrete types, such as strings, defining them as equivalent to an >if elsif sequence, with the selector expression being evaluated only >once. I would also like to see case statements on strings, but that's a much higher level language than Ada, I think. >One can still keep the advantage of having to cover all possible values >when the selector's subtype is static and discrete with no "=" >redefinition. Otherwise, there would be a when others => null by default >as the last choice. Bad choice. Better to make it a run-time error. >For instances of predefined packages such as Text_IO.Integer_IO with >types whose arithmetic has been messed with, I think it's OK if they >don't work correctly. It's easy to make the few needed type conversions >to make sure IO works with such types, which require special care >anyway. I might agree, except that I haven't the foggiest notion of how one specifies this precisely. I mean, the RM doesn't *say* Text_IO.Integer_IO needs to do a "/" by 10. I just happen to know that the implementation *might*. So what should the *spec* of Text_IO say about types that have redefined "/"? Or "mod" or "rem" or "-" etc.? >I think that the argument of backward compatibility with Ada 83 is not >that important (just my opinion). Indeed (just your opinion). In the Ada 9X project, it was an overriding concern. >... I think that if someone redefines an >operator for a type, then he probably has a good reason to do so, and >that operator becomes part of the abstraction provided by that type and >must stick with it wherever the types goes, with no exception. The problem is that you don't know where it goes -- for example, suppose there's a Sort generic. You don't know if it's defined in terms of "<=" or ">=" -- and it doesn't matter, so long as nobody redefines one without redefining the other. >> If I redefine "<" on a scalar type, should "<" on an array-of-that-type >> call it? > >Yes. OK, but then if I redefine "<" on a scalar type, should ">=" change? After all, ">=" is (or could be) defined as "not <". Historical note: I believe the Red language tried to make sure overloadings of the comparison ops "made sense" in this way -- you could overload two of them, and the other four would automatically change. - Bob P.S. I have a lot of sympathy for your point of view. I'm just griping because it's hard to fit in to Ada.