Re: Your wish list for Ada 202X

["Randy Brukardt" <randy@rrsoftware.com>]

"Niklas Holsti" <niklas.holsti@tidorum.invalid> wrote in message 
news:brdegqFi62jU1@mid.individual.net...
> On 14-04-17 01:27 , Randy Brukardt wrote:
>> "Niklas Holsti" <niklas.holsti@tidorum.invalid> wrote in message
>> news:br8bu5Fg3keU1@mid.individual.net...
>>> On 14-04-15 03:08 , Randy Brukardt wrote:
...
>> There's also the point that a
>> dispatching call always has to be assumed to be to some body not even
>> written yet, so it's nearly impossible to say anything definitive about 
>> it's
>> contract.
>
> But the operation has been *specified*, even if no bodies exist,
> therefore the contract *from the caller's point of view* should have
> been defined. Otherwise there is not much point in using a class at all,
> or indeed in separating operation declarations and bodies.

Right, but here I'm a practicalist, rather than theortician. Humans write 
programs, and they tend to ignore anything not convinient. That certainly 
goes for whatever part of the contract is not formally specified and 
checked. So there is a lot more risk from re-dispatching than static 
binding, simply because there is more likelihood of error (unintentional or 
malicious).

>> ...
>>>> This last issue doesn't arise for a class-wide operation, where every
>>>> call is going to look at an object of TT as type TT.
>>>
>>> Except if TT inherits some operation from T, because then that operation
>>> looks at the object as type T. (I know that from the language-semantics
>>> point of view the inherited operation acts on TT, but the programmer
>>> wrote its code with T in mind.)
>>>
>>> If redispatching is suspect because it breaks the assocation of an
>>> operation with a unique type, then inheritance of operations must also
>>> be suspect, for the same reason.
>>
>> I understand your point, but I think the language-semantics view is 
>> actually
>> the correct one. One only allows inheritance of operations when the
>> implementation for T and for TT is thought to be identical. One hopes 
>> that
>> the author of TT considered that carefully!
>
> Well, I use redispatching only when I think that the operation being
> called is well specified and is or will be carefully implemented for
> each type in the class, as appropriate for that type. Same difference :-)

If you truly believe that you can "well specify" and "carefully implement" 
everything in your system, well, you're a better man than me. :-) I don't 
believe that about my code even when I write the entire thing at one time - 
much less when other people are involved or years pass between work. One of 
the things that attracted me to Ada in the first place is that it forces me 
to specify enough that it prevents many of my worst impulses. (Instantiating 
Unchecked_Conversion is painful enough to prevent most reuse of objects, for 
one example.) I doubt I'd ever get a lengthy C program to work!

>> It's true that maintenance of the T operation might in fact break the TT
>> operation (meaning that they should have different implementations), so
>> there is some additional danger in inheritance.
>
> Yes. In general, the more a program is "factored" into parts that are
> combined and invoked in many contexts, the harder it becomes to maintain
> proper behaviour in all contexts. Subprograms, inheritance, dispatching,
> redispatching all tend in this direction.

Right.

>> There is also danger in
>> inheritance that the author of TT didn't know about. (I think it would be
>> much better if all inheritance was explicit; but to be practical that 
>> would
>> require a rather different syntax than Ada uses, and thus such a thing 
>> would
>> not make sense in an Ada perspective.
>
> To make inheritance explicit, it seems to me that each inherited
> operation must be declared for the derived type, with its full profile,
> perhaps as
>
>   inherited procedure Foo (X: in T; ....);
>
> This would require just one new reserved word, "inherited", and does not
> feel like a "rather different syntax". Did you have something else in 
> mind?

The problem with this sort of syntax is that it's really wordy and tends to 
obscure the important issues (which is not the exact profile, as least 
unless you have a resolution problem). Remember all of the people that used 
renames to avoid using use clauses for Ada 83? (Maybe not, that was a long 
time ago.) They often had bugs like:
   function "+" (Left, Right : P.Big_Int) return P.Big_Int renames P."-";
where the profile is obscuring the critical differences.

I'd prefer a much simpler declaration of inheritance, something like:
   type Child is new Parent with ...
      with inherits => Foo, Bar, Blech;

where names not listed are hidden from all visibility unless overridden. 
(The Ada dispatching model insists that the routines exist, so for Ada all 
one could do would be to hide any uninherited operations from direct calls. 
One could imagine have uninherited operations raise Program_Error in 
dispatching as an alternative, but that's not ideal either because it makes 
a tripping hazard as Bob calls it. Thirdly, one could require all operations 
to be either inherited or overridden, but that just makes a new kind of pain 
for deriving types, especially for those of us who prefer incremental 
implementation of things).

Whether that's enough or if some alternative with optional profiles is 
necessary, I don't know. Most operations aren't overloaded, after all, so 
the profile is just noise.

                       Randy.