Re: Ada Successor Language

["Dan'l Miller" <optikos@verizon.net>]

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.

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.  That is analogous to correctly-functioning behavior of C++.

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

a) tagged T is then constrained-subtyped as CST, a constrained subtype of T (to evoke Ada83-era semantics instead of Ada95).

b) Then 2 same-named subprograms would be overloaded to take T as the first parameter and CST as the first parameter.

c) Then tagged S would extend CST instead of T, so that the Ada95-era OO was mixed with the Ada83-era pre-OO inheritance of T to CST.

d) Then the programmer thinks that he is invoking the overloaded subprogram with CST as the first parameter, passing S in,

e) but (if Ada were as botched in certain areas as C++) instead the overloaded program with T as the first parameter is invoked (chopping the S-ness off S) so that the strong typing of S versus T is strictly enforced the wrong way, and the compiler would definitely strongly-typedly work with T when the programmer thought that the context was definitely strongly-typed as S and CST.

This perfect storm is merely one ••hypothetical•• case of trying to cause slicing in Ada via trying to trick the compiler to pick the ‘wrong’ overloaded subprogram of same name.  All the other ways of slicing (e.g., assignment, 'Image, record return value, perhaps generics, and so forth) would have their own contrived Ada95-tagged inheritance versus Ada83-untagged inheritance ••hypothetical•• stress tests that hopefully the _LRM_ individually explicitly carves out as overtly prohibited in at least one way.

There might even be ways of stress-testing potential slicing scenarios in Ada
1) without resorting to Ada83's subtyping at all
or
2) without putting Ada83's subtype constraints in direct •head-to-head• conflict with Ada95's OO tagged record extensions, but rather more obliquely through the interaction of 2 or more other language features (e.g., generics, child packages, private, use).

One would hope that 100% of all the dozen or so contrived* stress-tests would fail to compile (and fail to compile due to overt wording in the _LRM_—not due to spurious misinterpretation of the _LRM_ or due to bug-box compiler internal fault).

* perfect storm of 2 or more Ada{83, 95, 2005, 2012, 2020} language features interacting