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.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,4c86cf2332cbe682 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 1995-01-24 10:49:47 PST Newsgroups: comp.lang.ada Path: nntp.gmd.de!newsserver.jvnc.net!howland.reston.ans.net!pipex!uunet!world!bobduff From: bobduff@world.std.com (Robert A Duff) Subject: Re: Ada.strings.bounded problems? Message-ID: Organization: The World Public Access UNIX, Brookline, MA References: <1995Jan19.124412@lglsun.epfl.ch> <3fmnc1$rns@watnews1.watson.ibm.com> Date: Tue, 24 Jan 1995 18:49:47 GMT Date: 1995-01-24T18:49:47+00:00 List-Id: In article , Mats Weber wrote: >I can't believe that the `Goodenough trick' is used as an excuse for not >repairing the rules on "=". If there had been an AI on this trick, then it >would certainly have been forbidden by some additional rule, as was >clearly the intent in the design of the language. I think the first time I saw that trick, it was *in* an AI, which confirmed that you can define "=" using the trick (but not the straightforward way). I don't have the AI number -- I'm too lazy to look it up. I completely agree that the non-composability of "=" was a bad idea in Ada 83. However, fixing it for Ada 95 would not have been so easy. For one thing, you have to think about all the other operators. Suppose I redefine "<" on character type. Should that compose properly, so that "<" on an array-of-that-character type uses the redefined "<"? Of course, you want that, but this is a more serious upward incompatibility. You don't have to use any Goodenough Tricks to define that "<" -- it's a perfectly reasonable thing to do. Changing the run-time behavior of perhaps many existing programs would have been rather disruptive. But if you don't fix "<", then why fix "="? It would seem strange for "=" on the array to call the redefined "=" on the characters, but "<" does not call the redefined "<". Another issue is how far to go in the composability. For example, if I redefine "=" on a discrete type, does it affect the way case statements work? After all case statements compare the value of an expression for equality with the various when's. But what would the full coverage rules mean if "=" does something weird, like always returning True? Similarly, the expression X.all checks that X /= null. Should it use the programmer's notion of "/=" there? Probably not. Constraint checks on discriminated types check for equality of the discriminants. We sidestepped all those issues by drawing the line in a different place -- "=" composes properly for tagged types, and not for untagged types. Arrays of tagged types don't automatically have "<", and you can't do case statements on them, and so on. In fact, "=" and "/=" are the *only* predefined operators for tagged types, so it's not so unreasonable to treat them specially. - Bob