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

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

Robert A Duff wrote:
> 
> 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".

Yes, I want the same treatment for all operators. I was just using
equality as an example because it is so important. A fairly complete
statement of what I would like (or would have liked) is in my thesis at
<http://lglwww.epfl.ch/Team/MW/Ada-Extensions/Ada-Extensions.html#RTFToC95>
I had overlooked the case statments at the time, but the general idea is
still valid.

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

I find that more natural (just my opinion): if you change the arithmetic
of a type, packages that use the arithmetic are naturally affected. And
Text_IO.Integer_IO could very well internally convert to another type in
order to get the normal arithmetic operations, if that is really
required.

Anyway, there are other similar situations in Ada 83:

type Tiny is range 1 .. 3;

generic
   type T is range <>;
pakcage P is ...

if P uses the literal 10 in its body, it will fail when instantiated
with
T => Tiny (and Ada 83 had no 'Base attribute to solve this).

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

You can always get your hands on the predefined ops by declaring a new
type with the same (or maximal) range and type conversions.
Text_IO.Integer_IO had to do this anyway because of subtype problems
(excluding 0 for instance) and the lack of a usable 'base attribute in
Ada 83. So it is even likely that the existing Ada 83 implementations of
Text_IO.Integer_IO would work even if reemergence of predefined
operations was totally removed.

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

What do you mean by "other ops" ? Things like case, or things like "+",
"*". For "+", "*", I would definitely take the same approach as for "=".

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

You can also get the predefined operations in Ada, see above.