Re: Redefinition of "=", elaboration and learning Ada

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

In article <3365E879.567F@elca-matrix.ch>,
Mats Weber  <Mats.Weber@elca-matrix.ch> wrote:
>Another reason why I think we should have... no reemergence of
>predefined operations ...

>Having predefined "=" reemerge in strange places when it's been
>redefined is also counterintuitive ...

You talk about "=" specifically, but above you say "operators",
presumably meaning all of them.  You still haven't given a complete
definition of when *all* operators should and should not "reemerge".

>And then try explaining to a novice programmer, without making him
>believe that the language definition is flawed, that if he makes his
>type tagged then everything will work fine :-)

OK, but try to explain to the novice why Text_IO.Integer_IO doesn't
work, because "mod" is redefined.

>What the user sees when he discovers packages and private types is that
>he can define abstractions that he can use without knowing how they are
>implemented. What he sees when he discovers a library of generic
>components is that he can instantiate them and then use them. In both
>cases, he hits what is IMO a severe pitfall: reemergence breaks his
>abstraction, and he (potentially) gets Program_Error when he
>instantiates his generic.

But having the user-defined operator used in a generic has a similar
problem.  How can I write Text_IO.Integer_IO (or a similar generic)?
How do I write the code that converts an integer to a string, if I can't
get my hands on the predefined ops?

I agree with you about elaboration -- the current rules are a mess.
And I mostly agree with you about "=".  But I don't see how you can
sensibly extend it to other ops.  Perhaps one wants to have *both*
available -- Eiffel is sort of like that.  You define something like
Basic_Compare and Compare, and then never override Basic_Compare (freeze
it).  So then a client can choose one or the other.  By default, they do
the same thing, but subclasses can override Compare.

- Bob