Re: Ada Successor Language

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

On 2018-06-29 21:46, Dan'l Miller wrote:
> On Friday, June 29, 2018 at 12:39:59 PM UTC-5, Dmitry A. Kazakov wrote:
>> On 2018-06-29 15:25, Dan'l Miller wrote:
>>> On Friday, June 29, 2018 at 2:20:40 AM UTC-5, Dmitry A. Kazakov wrote:
>>>> On 2018-06-29 05:11, Paul Rubin wrote:
>>>>> "Dan'l Miller" writes:
>>>>>> bad idea that threatens to bring C++ slicing to Ada
>>>>>
>>>>> Are you talking about this?
>>>>>
>>>>>       https://en.wikipedia.org/wiki/Object_slicing
>>>>>
>>>>> Does Ada somehow escape from it now?
>>>>
>>>> Sure, there is no way to reconstruct that in Ada.
>>>>
>>>>> It does sound bad.
>>>>
>>>> Only due to C++ design fault. Assignment is a classic multiple dispatch
>>>> operation (a multi-method). C++ per design does no support MD. Here you go.
>>>>
>>>> With MD it is no more an issue. Let T and S be two types T <: S. The
>>>> assignment operation of mixed arguments and result
>>>>
>>>>       ":=" : S x T -> S
>>>>
>>>> could not be safely inherited by S from T's:
>>>>
>>>>       ":=" : T x T -> T
>>>>
>>>> Therefore the compiler would ask the programmer to override it (or
>>>> redesign). Problem solved.
>>>
>>> Dmitry, you make it sound as though multiple •dispatch• would solve slicing in C++ (which has no
>>> dispatch whatsoever).
>>
>> I said nothing about •dispatch•! All types in question are statically known!
> 
> Dmitry, do you even read what you write?  In what you just wrote 12 hours ago above, the “classic multiple •dispatch•”, the “does no[t] support •MD•” where MD = multiple •dispatch•, the “compiler would ask the programmer to •override• it” via the OO tag/vtable mechanism, and the “••Problem solved••” all directly mention multiple •dispatch• and how MD is directly related to the remedy to maldesigns in user-provided assignment operators in your direct reply to slicing via C++ assignment.

You are confusing "multiple dispatch" as a property of an operation with 
[multiple] "dispatch" as an act of resolution of a call at run-time. The 
former in Ada terms means that an operation has multiple controlling 
arguments/results see RM 3.9.2 for the term "controlling".

If C++ had both arguments and the result of "=" controlling then the 
problem were resolved, regardless run-time dispatch involved or not.

Equivalently, if C++'s assignment "=" were in Ada terms a primitive 
operation of its type the problem were resolved.

In Ada terms C++'s "=" should have been declared as:

    function "=" (Left : in out T; Right : T) return T;

Since C++ has no MD, it is effectively declared, again in Ada terms, as:

    function "=" (Left : in out T; Right : T'Class) return T'Class;

This is a ticking bomb since C++ does not distinguish T and T'Class. As 
the result, "=" is contravariant in the second argument and the result. 
So goes a big boom, because contravariance is *unsafe* upon type extension.

[I am sorry explaining such trivial things]

> Turing test and uncanny valley come to mind.
> 
>>> In the situations where slicing occurs, it is due to the old backwards-compatibility-with-C functionality in C++.
>>
>> I care little of C++ design flaws. There are plenty and C++ is far
>> beyond the point where anything could be done to fix it. I argued that
>> this problem could never occur in Ada with its sane type system.
>>
>> The case constituting this bug in C++ is well present in Ada:
>>
>>      type T is tagged null record;
>>      function F return T;
>>
>>      type S is new T with record
>>         I : Integer;
>>      end record;
> 
> That is clearly not analogous to the vicinity where C++'s slicing occurs.

It clearly is. Inheriting F could lead to the situation when some fields 
of S were undefined, just like inheriting assignment does.

> ••Hypothetically•• in (not-this-timeline's-)Ada the analogous situation would be in the vicinity of:

[...]

None of the situations you mentioned could ever lead to the problem. 
There is absolutely no way to have such a thing in a strongly typed 
language. Whatever issues C++ has these are because of its weak typing.

P.S. Like with dispatch, you keep on confusing Ada subtyping with OO 
and/or LSP subtyping. These are different things sharing only the name. 
In no way Ada's subtyping can be exposed to a problem similar to C++.

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