Re: Equality operator overloading in ADA 83

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

Robert A Duff wrote:

> I think I agree that "=" should compose, in the sense that composite
> types call the user-defined "=" of their components, and the predefined
> "=" doesn't "re-emerge" in generics.  But how far do you think we should
> carry this?  E.g. if "=" is redefined for a scalar type, does that
> affect case statements on that type?  After all, case stms check the
> case expression for equality with some values.  What about operators
> other than "="?  If "/" is redefined for an integer type, should
> Text_IO.Integer_IO know about it?  It might well make Put(some-integer)
> do the "wrong" thing, since the generic might need to divide by 10.

Yes, I would affect case statements, and also allow case for types other
than discrete types, such as strings, defining them as equivalent to an
if elsif sequence, with the selector expression being evaluated only
once.

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.

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 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.

> If I redefine "<" on a scalar type, should "<" on an array-of-that-type
> call it?

Yes.