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: mheaney@ni.net (Matthew Heaney) Subject: Re: Equality operator overloading in ADA 83 Date: 1997/04/26 Message-ID: #1/1 X-Deja-AN: 237630683 References: <01bc4e9b$ac0e7fa0$72041dc2@lightning> Organization: Estormza Software Newsgroups: comp.lang.ada Date: 1997-04-26T00:00:00+00:00 List-Id: In article , dewar@merv.cs.nyu.edu (Robert Dewar) wrote: >>The RM leaves many aspects of Ada as implementation defined. There is no >>general principle that this is unacceptable.>> > >One postscript to my previous comment. It is NOT ambiguous whether there >is a requirement for composability of equality for Bounded_String in the >RM in the absence of the AI. It is crystal clear that there is no such >requirement! > >The AI is not addressing the ambiguity of the requirement, it is adding a >requirement where none existed previously! No, no, no. That fact that many programmers wonder whether Bounded_String composes or not is proof that there is an ambiguity. Just tell the programmer what the requirement is, so he doesn't have to guess. And even if the AI did add a requirement, is that so bad? It's not as if this is anything new. In Ada 83, it required an AI to state unambiguously that Boolean'Size is 1. In Ada 95, this became an explicitly stated, unambiguous requirement. No one is asking for a language change per say, just a complete, unambiguous statement about the external behavior of Bounded_String. -------------------------------------------------------------------- Matthew Heaney Software Development Consultant (818) 985-1271