Re: Ada Successor Language

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

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 à 16:21, Dmitry A. Kazakov a écrit :
> >>>>
> >>>>>> 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
> > •some• situations of the untagged extended records, analogous 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?
> 
> I'm far from competent in C++,

  The following replies from me interspersed below might seem harsh or snarky.  But they paint a crystal clear picture of how precisely a C++ programmer must think when tip-toeing through the field of landmines that is C++.

> but searching a little for "C++ slicing" 
> suggests that the slicing problem has to do with non-virtual 

  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 
> 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-value on the right-hand side.

> to a parent type variable (reference) 

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 of discarding the components added in the derivation than being an l-value on 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 situations where slicing can occur.  Watch out!  Don't step on •that• landmine!  Or •that other one• over there either!  (i.e., you need to think more like a C++ programmer:  landmines landmines everywhere every waking moment.)

> … I don't 
> think Dmitry's suggestion for class-wide types rooted in untagged types 
> would lead to the same problems as slicing in C++.

Then you are an unable to foresee slicing situations as Bjarne Stroustrup was.  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 
> Dmitry's suggestion?

as quoting from page 80 of Item 22 in Scott Meyers's _Effective C++:  50 ways to improve your programs and designs_ (1992, over a quarter century ago!):
“Passing parameters by reference [context: in C++ jargon, when the object is a class or struct that has a pointer-to-vtable = in Ada jargon, when the object is a tagged record] has another advantage:  it avoids what is sometimes called the ‘slicing problem.’  When a derived class object is turned into a base class object [Niklas, take note:  via •any• of the multitude of language features], all of the specialized features [i.e., the pointer-to-vtable and dispatch therethrough] that made it behave like a derived class object are ‘sliced’ off, and you're left with a simple base class object.  This is almost never what you want.  …”

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 the dubious accomplishment of slicing implicitly quietly without warning or error, because the programmer inadvertently told the compiler to do something that the programmer did not really intend.  When the C++ programmer in effect accidentally said, blow my leg off via that slicing landmine that I didn't notice (i.e., •any• treating of the extended record as the base record, in Ada jargon), the C++ compiler dutifully says, “Yes, sir!  Right away, sir!  Boom.  <leg now smithereens>”

And just when you think that we have itemized the entire set of slicing landmines, the history of C++ demonstrates that we can concoct yet another slicing/combination-of-language-features situation.  Any language feature that permits •this• versus •that• can be transformed into a landmine.  With enough contemplation, any landmine can be utilized to concoct a slicing situation.