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/25 Message-ID: #1/1 X-Deja-AN: 237425518 References: <01bc4e9b$ac0e7fa0$72041dc2@lightning> <335CAEFE.35DC@elca-matrix.ch> Organization: Estormza Software Newsgroups: comp.lang.ada Date: 1997-04-25T00:00:00+00:00 List-Id: In article , dewar@merv.cs.nyu.edu (Robert Dewar) wrote: >I think probably the nicest way of doing this is to introduce a pragma > >pragma Compose_Equality (type-name); > >yes, it's a bit aggressive, but then so is the ARG's decision, and if the >problem in the standard library is important enough to be worth the ARG >changing the language, it seems reasonable to spupose that other libraries >will need the same treatment. I don't think anyone's arguing for a language change (though you all know by now I didn't agree with the decision). All I'm saying is to mandate a sort of coding convention that says, implement your abstraction so that equality always works, even predefined equality for when it inevitably re-emerges. Can the programmer assume Bounded_String composes, or not? The RM95 just needs to state - unambigously - whether it does or doesn't. Whatever way the ARG decides (they did, for the former), it doesn't require a change to the language. Right now, the RM95 is silent about whether equality composes for Bounded_String. The requirement for composability is therefore ambiguous, which isn't acceptable for any kind of requirements document. Matt P.S. By the way, it would be really swell if compilers could issue an informational diagnostic when predefined operators re-emerge for a type. -------------------------------------------------------------------- Matthew Heaney Software Development Consultant (818) 985-1271