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/26 Message-ID: #1/1 X-Deja-AN: 237582070 References: <01bc4e9b$ac0e7fa0$72041dc2@lightning> Organization: The World Public Access UNIX, Brookline, MA Newsgroups: comp.lang.ada Date: 1997-04-26T00:00:00+00:00 List-Id: In article , Robert Dewar wrote: ><Bounded_String. The requirement for composability is therefore ambiguous, >which isn't acceptable for any kind of requirements document.>> > >The RM leaves many aspects of Ada as implementation defined. There is no >general principle that this is unacceptable. Robert, I think you misunderstand his point. I think he's saying that if so-and-so is implementation dependent, the RM should say, "so-and-so is implementation dependent", rather than being silent on the issue. I agree with that. Otherwise, you're never quite sure whether the language designers meant it to be undefined, versus they never thought about it. In this particular case, I think the language designers never thought about whether "=" should compose for various predefined types, such as Bounded_String, so its implementation-dependence is accidental. In general, this principle is good, and I tried to obey it in RM95 -- if something is undefined, then the RM should say so explicitly. Nothing should be undefined just because the RM doesn't bother to define it. Anyway, this is why we have an AI on this point. >... Indeed, trying to remove all >implementation dependencies as Java does is an efficiency disaster -- for >example in the Java case, the requirement for IEEE fpt leads to completely >unaceptable performance on some targets (such as SGI and Alpha), but >in practice no one takes these specs that seriously. Perhaps Java goes too far. IMHO Ada doesn't go far enough in this direction. There's always a trade-off between nailing down the semantics, versus efficiency. The IEEE example is rather extreme (hardware floating point is almost right, but you have to do floating point in software to get it just right). Of course, Ada and Java are targetting rather different application areas. - Bob