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:2712:: with SMTP id n18-v6mr1339248ion.90.1530050592947; Tue, 26 Jun 2018 15:03:12 -0700 (PDT) X-Received: by 2002:aca:f483:: with SMTP id s125-v6mr342299oih.7.1530050592740; Tue, 26 Jun 2018 15:03:12 -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-v6no1175542itj.0!news-out.google.com!z3-v6ni807iti.0!nntp.google.com!d7-v6no1175537itj.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Tue, 26 Jun 2018 15:03:12 -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> <878t7u1cfm.fsf@nightsong.com> <776f3645-ed0c-4118-9b4d-21660e3bba4b@googlegroups.com> <87602fbu2g.fsf@nightsong.com> <87po0mziqt.fsf@nightsong.com> <87fu1izfgs.fsf@nightsong.com> <878t75nwad.fsf@adaheads.home> <15b6f89f-997b-45ac-86b4-2e614bb624c2@googlegroups.com> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: Subject: Re: Ada Successor Language From: "Dan'l Miller" Injection-Date: Tue, 26 Jun 2018 22:03:12 +0000 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Xref: reader02.eternal-september.org comp.lang.ada:53356 Date: 2018-06-26T15:03:12-07:00 List-Id: On Tuesday, June 26, 2018 at 4:01:22 PM UTC-5, Niklas Holsti wrote: > On 18-06-26 16:59 , Dan'l Miller wrote: > > On Tuesday, June 26, 2018 at 2:44:26 AM UTC-5, Dmitry A. Kazakov > > wrote: > >> On 2018-06-25 18:21, Dan'l Miller wrote: > >>> On Monday, June 25, 2018 at 10:19:15 AM UTC-5, Dmitry A. Kazakov > >>> wrote: > >>>> On 2018-06-25 16:44, J-P. Rosen wrote: > >>>>> Le 25/06/2018 =C3=A0 16:21, Dmitry A. Kazakov a =C3=A9crit : > >>>> > >>>>>> Ada could allow T'Class for untagged T. T'Class would be an > >>>>>> indefinite type with values consisting of the actual type's > >>>>>> tag and its value. When T is by-value type, you pass > >>>>>> T'Class to a subprogram as tag + value. When T is > >>>>>> by-reference type, you pass tag + reference. > >>>>>> > >>>>>> Upon dispatch, you strip the tag from the value or > >>>>>> reference before passing value/reference down. > >>>>> > >>>>> It was a requirement of Ada95 that OOP be strictly contained, > >>>>> and that the same typing system as Ada83 be kept for those > >>>>> who don't want OOP. > >>>> > >>>> Don't want OO, don't declare T'Class objects. Where is a > >>>> problem? > >>> > >>> The problem is that you just proposed 'Class for non-OO > >>> semantics. Your proposal violates the Principal of Least > >>> Surprise. > >> > >> Remember, Ada is a strongly typed language, T'Class is not T, there > >> is no way it could break or change anything in T. > > > > Quit putting non sequitur words in my mouth. I never said that it > > would break anything in T. I said that it would break T'Class in > > =E2=80=A2some=E2=80=A2 situations of the untagged extended records, ana= logous to ways > > that are known in C++ as slicing. Ada community wants one of C++'s > > most-maligned problems where the compiler sometimes picks the wrong > > strong typing? >=20 > I'm far from competent in C++, The following replies from me interspersed below might seem harsh or snar= ky. But they paint a crystal clear picture of how precisely a C++ programm= er must think when tip-toeing through the field of landmines that is C++. > but searching a little for "C++ slicing"=20 > suggests that the slicing problem has to do with non-virtual=20 Stop right there and you will learn something. > assignment operators Oops. Now that is where you went off in the weeds. There are more ways of= slicing via non-virtual behaviors than merely assignment operators. > which implicitly and silently convert a derived-type=20 > expression Stop right there and you will learn something. > on the right hand side, Oops. Now that is where you went off in the weeds. There are more ways of= converting a derived-type expression to its base type than being an r-valu= e on the right-hand side. > to a parent type variable (reference)=20 Stop right there and you will learn something. > on the left hand side, Oops. Now there is where you went off in the weeds. There are more ways o= f discarding the components added in the derivation than being an l-value o= n the left-hand side. > discarding the components added in the derivation. Now we're back on track to learning something about slicing. Niklas, you have the outcomes understood, but you don't see the multiple si= tuations where slicing can occur. Watch out! Don't step on =E2=80=A2that= =E2=80=A2 landmine! Or =E2=80=A2that other one=E2=80=A2 over there either!= (i.e., you need to think more like a C++ programmer: landmines landmines= everywhere every waking moment.) > =E2=80=A6 I don't=20 > think Dmitry's suggestion for class-wide types rooted in untagged types= =20 > would lead to the same problems as slicing in C++. Then you are an unable to foresee slicing situations as Bjarne Stroustrup w= as. Bjarne should not be one's role model as a language designer. > Dan'l, could you explain more about the slicing-like problem you see in= =20 > Dmitry's suggestion? as quoting from page 80 of Item 22 in Scott Meyers's _Effective C++: 50 wa= ys to improve your programs and designs_ (1992, over a quarter century ago!= ): =E2=80=9CPassing parameters by reference [context: in C++ jargon, when the = object is a class or struct that has a pointer-to-vtable =3D in Ada jargon,= when the object is a tagged record] has another advantage: it avoids what= is sometimes called the =E2=80=98slicing problem.=E2=80=99 When a derived= class object is turned into a base class object [Niklas, take note: via = =E2=80=A2any=E2=80=A2 of the multitude of language features], all of the sp= ecialized features [i.e., the pointer-to-vtable and dispatch therethrough] = that made it behave like a derived class object are =E2=80=98sliced=E2=80= =99 off, and you're left with a simple base class object. This is almost n= ever what you want. =E2=80=A6=E2=80=9D So here we see Scott Meyers over 25 years prior to your Bing/Google search = telling of a quite different(-than-assignment-operator) way of achieving th= e dubious accomplishment of slicing implicitly quietly without warning or e= rror, because the programmer inadvertently told the compiler to do somethin= g that the programmer did not really intend. When the C++ programmer in ef= fect accidentally said, blow my leg off via that slicing landmine that I di= dn't notice (i.e., =E2=80=A2any=E2=80=A2 treating of the extended record as= the base record, in Ada jargon), the C++ compiler dutifully says, =E2=80= =9CYes, sir! Right away, sir! Boom. =E2=80=9D And just when you think that we have itemized the entire set of slicing lan= dmines, the history of C++ demonstrates that we can concoct yet another sli= cing/combination-of-language-features situation. Any language feature that= permits =E2=80=A2this=E2=80=A2 versus =E2=80=A2that=E2=80=A2 can be transf= ormed into a landmine. With enough contemplation, any landmine can be util= ized to concoct a slicing situation.