Re: Ada Interfaces and the Liskov Substitution Principle

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

On 27 May 2007 01:30:36 -0700, Maciej Sobczak wrote:

> On 26 Maj, 09:48, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
> wrote:
> 
>>> I'm still for banning it.
>>
>> For this you have to make assignment contravariant (non-primitive
>> operation) in one of its arguments. That would be a total mess, because it
>> would require overloading assignment for each derived type.
> 
> I don't get it. I said I would ban it. There is no "for this". :-)

To ban something in the language you have to translate the ban into
language terms. That could be either by syntax or by semantic rules.
Because syntactically banned assignments are indistinguishable from legal
ones, the only mechanics you could use for this is matching types. The
types in question are from the same hierarchy (covariant). This lets mixing
such types. So it *must* be contravariant to be banned = the operation
(":=") will not be inherited in the argument of interest upon inheritance.

>> For the same reason all signatures with a class-wide parameter are bad,
>> because they lead to ambiguities in trivial cases:
>>
>> type S is new T with ...;
>> X, Y : S;
>>
>> X := Y;  -- S'Class x S'Class vs T'Class x T'Class?
>>
>> You will need some sort of dominance rules to resolve that.
> 
> Why?

Per definition/meaning of class-wide operations: they apply to *all* types
from the class.

> Both X and Y are of the same type above and it is not a class
> wide type in the sense that no dispatching is needed here.

Dispatching is about primitive operations acting on class-wide objects.
Class-wide operations acting on specific objects is a way different story.

>> P.S. Probably you have in mind a "stratified" assignment which statically
>> checks that LHS and RHS are of the same type.
> 
> Not necessarily. I would allow different types if the
> assignment_statement is overloaded for them for those who like to
> introduce sort of implicit conversions.
> What I worry about is the situation where *both* dynamic types are not
> known statically. This is a mess.

You cannot express it in terms of the types system. So you have to roll up
another formal types framework.

And I don't see why it is a mess. What is wrong in assignment of
UTF8_String to Wide_String, both from String'Class?

The very definition of a class says that types there share class-wide and
primitive operations. If that is not the case: ":=" is not shared, then
either it is not a class (= don't derive! if need not) or there is no ":="
(= make it limited! if unsure). Looks much like a design problem.

>> -----------
>> *  Ada's assignment is doubly dispatching. The dispatching table is a
>> square, the diagonal of consists of thunks:
>>
>>    Finalize (LHS);
>>    bit-copy (LHS, RHS);
>>    Adjust (LHS);
>>
>> Non-diagonal elements are:
>>
>>    raise Constraint_Error;
> 
> Which is a run-time thingy. It's good if it's there, but I want
> stricter guarantees. You can get them by just banning
> assignment_statement between class-wide types.

No, because that would be inconsistent. A doubly dispatching operation
*has* a square table. There is nothing to do about it. You have to make it
something else instead, I have listed possible variants earlier. These
alternatives are mess. Hardwired rules imposed on assignments were an even
bigger mess. It is bad enough that Ada has assignment defined as an
statement, rather than a procedure call. There is nothing special in
assignments. So your mechanism, if any, should be universally applied to
all operations with multiple arguments from the same types hierarchy.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de