Re: Equality operator overloading in ADA 83

[mheaney@ni.net (Matthew Heaney)]

In article <335F5971.6375@elca-matrix.ch>, Mats.Weber@elca-matrix.ch wrote:

>I think that the argument of backward compatibility with Ada 83 is not
>that important (just my opinion). I think that if someone redefines an
>operator for a type, then he probably has a good reason to do so, and
>that operator becomes part of the abstraction provided by that type and
>must stick with it wherever the types goes, with no exception.

And this time I agree with you 100%.  With respect to redefining equality,
if introducing a backwards incompatibility was the price for always having
the overriding version get called, then so be it.

Alas, I wasn't on the design commitee, and they made a different choice. 
Oh, well.  They're smart guys, and they had their reasons.

To remember that predefined equality re-emerges when a bounded_string is a
record or array componant is to a lot (too much, I say) to ask the average
programmer. 
Most programmers don't know that predefined operators even in Ada 83
re-emerge for a type passed as a generic actual, so what magic is supposed
to happen to make them aware of the re-emergence of predefined equality in
Ada 95?

This whole issue of re-emergence of operators is something I really wish no
Ada programmer ever had to think about, and it will only contribute to the
perception (reality?) of Ada as a "complex language."  My Prognistication
is that this will be a pernicious source of error in Ada 95 systems.

At a minimum we should guarantee that predefined types - such as
Ada.Strings.Bounded.Bounded_String - are composable.  Because it would be
very naive to think that a tired programmer who has been furiously working
all weekend, and is still hacking away at 11:30 Sunday night because he has
a code delivery Monday morning, is going to be even remotely thinking about
when predefined equality re-emerges.  So let's solve his problem so that he
_never_does_ have to think about it, by guaranteeing that Bounded_String is
composable.  

The whole point of a high level language is so that the programmer
_doesn't_ have to think about those things.  He should be thinking about
the problem, not the solution.  We have to remove programming language as a
barrior to the production of correct software systems.

Gee, I think I'm beginning to sound like someone else.  Bertrand, are you
listening?

Matt

--------------------------------------------------------------------
Matthew Heaney
Software Development Consultant
<mailto:matthew_heaney@acm.org>
(818) 985-1271