Re: Equality operator overloading in ADA 83

[Mats Weber <Mats.Weber@elca-matrix.ch>]

Robert A Duff wrote:

> This should compare a billion numbers for equality with X, using the
> user's "=" operator?  Hmm.  Perhaps a reasonable thing for a new
> language, but rather out of the question for a "language revision" like
> Ada 9X.  Of course, if one could redefine "in"....

OK, it's a tough one. One idea could be that "in" works according to the
relational operators (see my other post in this thread). Another idea is
to leave the case statement alone, i.e. use predefined equality for
case. Still another idea (maybe the best one) is to forbid case when "="
is redefined.

> I would also like to see case statements on strings, but that's a much
> higher level language than Ada, I think.

This was in one of the Ada 9X drafts, and I liked the proposal. It was
defined as equivalent to a sequence of if elsif, but I think with better
readability.

> >One can still keep the advantage of having to cover all possible values
> >when the selector's subtype is static and discrete with no "="
> >redefinition. Otherwise, there would be a when others => null by default
> >as the last choice.
> 
> Bad choice.  Better to make it a run-time error.

I like the idea of being able to make sure at compile time that I have
covered all cases. So I would keep it, but it's really a matter of
personal preference.

> >For instances of predefined packages such as Text_IO.Integer_IO with
> >types whose arithmetic has been messed with, I think it's OK if they
> >don't work correctly. It's easy to make the few needed type conversions
> >to make sure IO works with such types, which require special care
> >anyway.
> 
> I might agree, except that I haven't the foggiest notion of how one
> specifies this precisely.  I mean, the RM doesn't *say*
> Text_IO.Integer_IO needs to do a "/" by 10.  I just happen to know that
> the implementation *might*.  So what should the *spec* of Text_IO say
> about types that have redefined "/"?  Or "mod" or "rem" or "-" etc.?

I would say that the behavior is not specified by the language, and the
compiler could give a warning when such an instantiation is made.

> >I think that the argument of backward compatibility with Ada 83 is not
> >that important (just my opinion).
> 
> Indeed (just your opinion).  In the Ada 9X project, it was an overriding
> concern.

In Ada 83, the problem was quite different. You could redefine "=" only
for limited types, and inside a generic, you couldn't access "=" of a
formal limited type unless it was explicitly given as a generic formal
parameter. So there was no reemergence of "=" anywhere and the language
was "clean" in that respect. Other operators such as "+" and "<" could
reemerge, but I think it's fair to say that they are less important than
"=". (Also, there was the unexpected possibility of redefining "=" for
non-limited types, but I think that this is pathological enough not to
be worried about).

> >... 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.
> 
> The problem is that you don't know where it goes -- for example, suppose
> there's a Sort generic.  You don't know if it's defined in terms of "<="
> or ">=" -- and it doesn't matter, so long as nobody redefines one
> without redefining the other.

This can be a problem, but only if "<" is redefined while leaving the
other relationals untouched, with a meaning that does not match the "<"
redefinition, which is very questionable practice. It's prefectly OK to
define only "<" and "=" when the type is private (i.e. no predefined
ordering operators need to be hidden).

Here again, I think that the preservation of the abstraction
(redefinition of the ordering) is the most important point.

Anyway you can mess up pretty bad with operator redefinition, with or
without reemergence, for instance by defining an "=" that is not an
equivalence relation (in the mathematical sense).

> OK, but then if I redefine "<" on a scalar type, should ">=" change?
> After all, ">=" is (or could be) defined as "not <".
> 
> Historical note: I believe the Red language tried to make sure
> overloadings of the comparison ops "made sense" in this way -- you could
> overload two of them, and the other four would automatically change.

Good idea IMO (see my other post).

> P.S. I have a lot of sympathy for your point of view.
> I'm just griping because it's hard to fit in to Ada.

Nice to hear that I am not alone. I remember the pleasure I had reading
the phrase "we are eliminating the reemergence of predefined operators
in Ada 9X" in some draft Ada 9X RM. I was so upset to see it removed.