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:bb42:: with SMTP id l63-v6mr6337037iof.101.1530301607489; Fri, 29 Jun 2018 12:46:47 -0700 (PDT) X-Received: by 2002:aca:4787:: with SMTP id u129-v6mr782828oia.4.1530301607207; Fri, 29 Jun 2018 12:46:47 -0700 (PDT) Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!feeder.eternal-september.org!news.uzoreto.com!weretis.net!feeder6.news.weretis.net!feeder.usenetexpress.com!feeder-in1.iad1.usenetexpress.com!border1.nntp.dca1.giganews.com!nntp.giganews.com!d7-v6no750152itj.0!news-out.google.com!p13-v6ni1120itf.0!nntp.google.com!d7-v6no750149itj.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Fri, 29 Jun 2018 12:46:46 -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> <87fu1izfgs.fsf@nightsong.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: Subject: Re: Ada Successor Language From: "Dan'l Miller" Injection-Date: Fri, 29 Jun 2018 19:46:47 +0000 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Xref: reader02.eternal-september.org comp.lang.ada:53440 Date: 2018-06-29T12:46:46-07:00 List-Id: 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 dispatc= h > >> operation (a multi-method). C++ per design does no support MD. Here yo= u 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. > >=20 > > Dmitry, you make it sound as though multiple =E2=80=A2dispatch=E2=80=A2= would solve slicing in C++ (which has no > > dispatch whatsoever). >=20 > I said nothing about =E2=80=A2dispatch=E2=80=A2! All types in question ar= e statically known! Dmitry, do you even read what you write? In what you just wrote 12 hours a= go 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 ask th= e programmer to =E2=80=A2override=E2=80=A2 it=E2=80=9D via the OO tag/vtabl= e 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 an= d how MD is directly related to the remedy to maldesigns in user-provided a= ssignment 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++. >=20 > I care little of C++ design flaws. There are plenty and C++ is far=20 > beyond the point where anything could be done to fix it. I argued that=20 > this problem could never occur in Ada with its sane type system. >=20 > The case constituting this bug in C++ is well present in Ada: >=20 > type T is tagged null record; > function F return T; >=20 > 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++. =E2=80=A2=E2=80=A2Hypothetically=E2=80=A2=E2=80=A2 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 wa= s 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 overloa= ded program with T as the first parameter is invoked (chopping the S-ness o= ff S) so that the strong typing of S versus T is strictly enforced the wron= g 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 =E2=80=A2=E2=80=A2hypothetical=E2=80=A2=E2= =80=A2 case of trying to cause slicing in Ada via trying to trick the compi= ler to pick the =E2=80=98wrong=E2=80=99 overloaded subprogram of same name.= All the other ways of slicing (e.g., assignment, 'Image, record return va= lue, perhaps generics, and so forth) would have their own contrived Ada95-t= agged inheritance versus Ada83-untagged inheritance =E2=80=A2=E2=80=A2hypot= hetical=E2=80=A2=E2=80=A2 stress tests that hopefully the _LRM_ individuall= y explicitly carves out as overtly prohibited in at least one way. There might even be ways of stress-testing potential slicing scenarios in A= da 1) without resorting to Ada83's subtyping at all or 2) without putting Ada83's subtype constraints in direct =E2=80=A2head-to-h= ead=E2=80=A2 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 wou= ld fail to compile (and fail to compile due to overt wording in the _LRM_= =E2=80=94not due to spurious misinterpretation of the _LRM_ or due to bug-b= ox compiler internal fault). * perfect storm of 2 or more Ada{83, 95, 2005, 2012, 2020} language feature= s interacting