Re: Ada Successor Language

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

On Friday, June 29, 2018 at 4:36:22 PM UTC-5, Dmitry A. Kazakov wrote:
> 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.

No, you are factually incorrect.  As soon as you put the keyword tagged in the Ada code, the •directly corresponding• C++ code would have the keyword virtual on F.  And then slicing is impossible because no C-era semantics are evoked in combination with any other language feature.  Do you even read the prior content of this thread?