Re: Ada.strings.bounded problems?

[bobduff@world.std.com (Robert A Duff)]

In article <Mats.Weber-2301951656460001@mlma11.matrix.ch>,
Mats Weber <Mats.Weber@matrix.ch> wrote:
>I can't believe that the `Goodenough trick' is used as an excuse for not
>repairing the rules on "=". If there had been an AI on this trick, then it
>would certainly have been forbidden by some additional rule, as was
>clearly the intent in the design of the language.

I think the first time I saw that trick, it was *in* an AI, which
confirmed that you can define "=" using the trick (but not the
straightforward way).  I don't have the AI number -- I'm too lazy to
look it up.

I completely agree that the non-composability of "=" was a bad idea in
Ada 83.  However, fixing it for Ada 95 would not have been so easy.

For one thing, you have to think about all the other operators.  Suppose
I redefine "<" on character type.  Should that compose properly, so that
"<" on an array-of-that-character type uses the redefined "<"?  Of
course, you want that, but this is a more serious upward
incompatibility.  You don't have to use any Goodenough Tricks to define
that "<" -- it's a perfectly reasonable thing to do.  Changing the
run-time behavior of perhaps many existing programs would have been
rather disruptive.

But if you don't fix "<", then why fix "="?  It would seem strange for
"=" on the array to call the redefined "=" on the characters, but "<"
does not call the redefined "<".

Another issue is how far to go in the composability.  For example, if I
redefine "=" on a discrete type, does it affect the way case statements
work?  After all case statements compare the value of an expression for
equality with the various when's.  But what would the full coverage
rules mean if "=" does something weird, like always returning True?

Similarly, the expression X.all checks that X /= null.  Should it use
the programmer's notion of "/=" there?  Probably not.  Constraint checks
on discriminated types check for equality of the discriminants.

We sidestepped all those issues by drawing the line in a different place
-- "=" composes properly for tagged types, and not for untagged types.
Arrays of tagged types don't automatically have "<", and you can't do
case statements on them, and so on.  In fact, "=" and "/=" are the
*only* predefined operators for tagged types, so it's not so
unreasonable to treat them specially.

- Bob