Re: Equality operator overloading in ADA 83

[mheaney@ni.net (Matthew Heaney)]

In article <dewar.861970467@merv>, 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
<mailto:matthew_heaney@acm.org>
(818) 985-1271