Re: Ada Interfaces and the Liskov Substitution Principle

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

On Fri, 01 Jun 2007 13:31:04 -0700, Maciej Sobczak wrote:

> On 1 Cze, 16:53, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
> wrote:
> 
>> or claiming that there is a semantic difference between X:=Y
>> and Assign(X,Y). I don't want a language with magical, semantically
>> non-decomposable assignments.
> 
> You have them at the level of fundamental types.

So what?

> You can treat X:=Y and Assign(X,Y) to be equivalent for *your* T (and
> if you have complete control over overloading of assignment then that
> might be actually the case), but at some level of detail they have to
> be implemented in terms of *non-decomposable* assignments of
> fundamental types anyway.

How a fundamental X:=Y differs from fundamental Assign(X,Y)? The question
is not about implementation of, but about semantic differences.
 
(It is the first time I meet somebody who tries to deny procedural
decomposition. You have to chance.)

> Now, the difference between T and T'Class is
> that operations with T can be statically decomposed down to this non-
> decomposable bricks. With T'Class it's just impossible to do this
> mechanically and it's unrealistic to expect it from the programmer for
> any non-trivial hierarchy.

The operations of T'Class are perfectly decomposable. There are two of them
(in Ada)

1. Class-wide operation has one body.

2. Primitive operation. The body is composed out for the bodies of the
operations defined for the specific types. This precisely means:

2.a. The specific body is explicitly overridden
2.b. It is inherited, and thus, it is built as a composition of a type view
conversion and the body of the parent type.

>>> You can replace a Circle with a Triangle but you better not try to
>>> assign them.
>>
>> This is not an explanation. Show a semantic difference between changing a
>> name binding from one value to another by A) "replacement" and B)
>> "assignment."
> 
> No problem. Replacement is when you just stop refering to X and start
> refering to Y (or its clone if the objects are mutable). Assignment is
> when you decompose down to real, hard-core-metal-and-concrete ':=' on
> fundamental types.

Mixing abstraction levels is a logical fallacy. You have to choose one,
which would define the semantics. Take any of above and show a difference:
either between "start to refer" and "start to have", or else between the
sequences of machine implementing "start to what."

> The difference is that (in Ada terms) replacement
> allows you to change the tag. Assignment cannot do this.

Neither can. But to show this we'd need to formalize it. Briefly: types
access T and T are different types. The semantic of assignment of access T
is not one of T, and neither is of the assignment of T'Class! It is a typed
language, after all...

>> Ah, wouldn't replacement double dispatching?
> 
> No, it wouldn't and that's the second difference. Replacement just
> gets rid of the current value before the new value is refered to,
> which means that from the dispatching point of view this operation is
> simply linear on right-hand-side - it's a pure single dispatch.

No, this does not work. Apart from being semantically wrong in general
case, it is technically wrong. You have to dispatch to finalize LHS. You
have to dispatch to re-construct it from RHS. See above, in Ada there is no
choice beyond class-wide and primitive operation. The latter dispatches
immediately, the former postpones the dispatch until its body. In both
cases it ultimately dispatches on both arguments. So semantically there is
no difference. Also see my earlier posts about ambiguity of the signatures
T x T'Class and T'Class x T in presence of derived types.

> Assignment has to be '2D' with both axes, or O(n2) in terms of
> implementation complexity. It has to be double-dispatching to make any
> sense and this is unrealistic implementation-wise.

It is semantically this way. There is nothing to do about it, but to scrap
either assignment or class. (We are going in circles)

> That's why T'Class, even though very interesting from the language
> construction point of view, cannot entirely include all functionality
> of access variable to T'Class (or pointer to base class in C++
> jargon).

This is irrelevant as they are different types. In fact an access type
could be treated as a member of the class, but then its assignment would
have a deep copy semantics and you are back where you have started from.

(C++ OO model is really poisoning. Don't mix types, just don't.)

>> Then let "assignment" :=
>> "replacement,"
> 
> Do you mean:
> - let's replace assignment by replacement, or
> - let's assign replacement to assignment?
> 
> ;-)

Take what you wish, but referential semantic is fundamentally insufficient,
in the sense that you cannot have a language without values, but only
references. This is the conceptual fault of Java et al. Once you had at
least one value at the end of the referential chains, you'd have to assign
(:-)) it and give a type to it. (It is about typed languages, right?)  Then
because your types algebra has classes one could create a class of. In the
end you will face the same question again: what is the assignment on the
class. All this referential stuff is just shifting subjects.

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