From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=unavailable autolearn_force=no version=3.4.4 X-Received: by 2002:a6b:cf04:: with SMTP id o4-v6mr6106247ioa.87.1530310890940; Fri, 29 Jun 2018 15:21:30 -0700 (PDT) X-Received: by 2002:aca:c6ca:: with SMTP id w193-v6mr1463513oif.1.1530310890856; Fri, 29 Jun 2018 15:21:30 -0700 (PDT) Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!feeder.eternal-september.org!news.linkpendium.com!news.linkpendium.com!news.snarked.org!border2.nntp.dca1.giganews.com!nntp.giganews.com!d7-v6no850975itj.0!news-out.google.com!p13-v6ni1241itf.0!nntp.google.com!d7-v6no850971itj.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Fri, 29 Jun 2018 15:21:30 -0700 (PDT) In-Reply-To: Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=47.185.195.62; posting-account=zwxLlwoAAAChLBU7oraRzNDnqQYkYbpo NNTP-Posting-Host: 47.185.195.62 References: <5e86db65-84b9-4b5b-9aea-427a658b5ae7@googlegroups.com> <878t75nwad.fsf@adaheads.home> <15b6f89f-997b-45ac-86b4-2e614bb624c2@googlegroups.com> <28a46046-e7eb-4306-bc39-72bc751831ae@googlegroups.com> <400ba7f8-6875-4ba8-99ee-c105180d5d8b@googlegroups.com> <87tvpm1e2q.fsf@nightsong.com> <1fbec811-1c54-4d6f-a072-447a0c8c23a2@googlegroups.com> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: <55f5dec3-4b01-43d9-8ce7-52202473c7d9@googlegroups.com> Subject: Re: Ada Successor Language From: "Dan'l Miller" Injection-Date: Fri, 29 Jun 2018 22:21:30 +0000 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Xref: reader02.eternal-september.org comp.lang.ada:53461 Date: 2018-06-29T15:21:30-07:00 List-Id: 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 dispa= tch > >>>> 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 > >>>> > >>>> ":=3D" : S x T -> S > >>>> > >>>> could not be safely inherited by S from T's: > >>>> > >>>> ":=3D" : 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 =E2=80=A2dispatch=E2=80= =A2 would solve slicing in C++ (which has no > >>> dispatch whatsoever). > >> > >> I said nothing about =E2=80=A2dispatch=E2=80=A2! All types in question= are statically known! > >=20 > > Dmitry, do you even read what you write? In what you just wrote 12 hou= rs ago above, the =E2=80=9Cclassic multiple =E2=80=A2dispatch=E2=80=A2=E2= =80=9D, the =E2=80=9Cdoes no[t] support =E2=80=A2MD=E2=80=A2=E2=80=9D where= MD =3D multiple =E2=80=A2dispatch=E2=80=A2, the =E2=80=9Ccompiler would as= k the programmer to =E2=80=A2override=E2=80=A2 it=E2=80=9D via the OO tag/v= table mechanism, and the =E2=80=9C=E2=80=A2=E2=80=A2Problem solved=E2=80=A2= =E2=80=A2=E2=80=9D all directly mention multiple =E2=80=A2dispatch=E2=80=A2= and how MD is directly related to the remedy to maldesigns in user-provide= d assignment operators in your direct reply to slicing via C++ assignment. >=20 > You are confusing "multiple dispatch" as a property of an operation with= =20 > [multiple] "dispatch" as an act of resolution of a call at run-time. The= =20 > former in Ada terms means that an operation has multiple controlling=20 > arguments/results see RM 3.9.2 for the term "controlling". >=20 > If C++ had both arguments and the result of "=3D" controlling then the=20 > problem were resolved, regardless run-time dispatch involved or not. >=20 > Equivalently, if C++'s assignment "=3D" were in Ada terms a primitive=20 > operation of its type the problem were resolved. >=20 > In Ada terms C++'s "=3D" should have been declared as: >=20 > function "=3D" (Left : in out T; Right : T) return T; >=20 > Since C++ has no MD, it is effectively declared, again in Ada terms, as: >=20 > function "=3D" (Left : in out T; Right : T'Class) return T'Class; >=20 > This is a ticking bomb since C++ does not distinguish T and T'Class. As= =20 > the result, "=3D" is contravariant in the second argument and the result.= =20 > So goes a big boom, because contravariance is *unsafe* upon type extensio= n. >=20 > [I am sorry explaining such trivial things] >=20 > > Turing test and uncanny valley come to mind. > >=20 > >>> In the situations where slicing occurs, it is due to the old backward= s-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; > >=20 > > That is clearly not analogous to the vicinity where C++'s slicing occur= s. >=20 > It clearly is. Inheriting F could lead to the situation when some fields= =20 > 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 =E2=80=A2directly corresponding=E2=80=A2 C++ code would h= ave the keyword virtual on F. And then slicing is impossible because no C-= era semantics are evoked in combination with any other language feature. D= o you even read the prior content of this thread?