Re: Ada Successor Language

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

On Wednesday, June 27, 2018 at 2:15:23 AM UTC-5, Dmitry A. Kazakov wrote:
> On 2018-06-27 00:03, Dan'l Miller wrote:
> > On Tuesday, June 26, 2018 at 4:01:22 PM UTC-5, Niklas Holsti wrote:
> 
> >> … 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.
> 
> But you are able to foresee that, right? Then maybe you put up an 
> example of what the problem is?

Rather than talk in C++-speak about importation of one of C++'s notorious flaws, let us instead talk in Ada-speak about an analogous proposed Ada feature.  The Steelman requirement 3-3F strongly resembles portions of your tag-external-to-type idea on which your 'Class for untagged types depends.  Both 3-3F and your tag-external-to-type require the compiler to know precisely which strong type is being utilized in ••every language construct everywhere under all circumstances••.  If the compiler at any time obfuscates that single strong type among a set of multiple related types, then the compiler runs the risk of
1) losing track of precisely which strong type this versus that 3-3F no-storage-allocated-within-record extra fields among various 3-3F-utilizing record-types.
or
2) losing track of precisely which strong type had this versus that tag-external-to-type regarding your various untagged types.

Just like Bjarne and the C++ standards committee's accidental introduction of landmines in C++, no sane person would •intentionally• design the losing-of-track into the language.  Rather, these losings-of-track would occur at the intersection/junction/boundary of 2 or more language features.  Because there are hundreds of language features, the combinatorial explosion of 2 or more language features in each other's context is quite a large number (hence the difficulty of the language designer foreseeing them all on Day One).  The medical world has a term for flaws at the junction of 2 or more tissue features:  conjunctive nevus.  Nearly all of C++'s landmines that must be meticulously vigilantly avoided every waking moment are in fact conjunctive nevuses where 2 or more language features interact badly with each other at their point of contact with each other.  That is what we are looking for here as well in Ada regarding 3-3F's and tags-external-to-type's perfect inability to never ever lose track of the single strong type.

Several language features come to mind immediately that could potentially be such obfuscations of strong typing into a set of 2 or more related types existing concurrently or progressively/incrementally over time:
a) generics
  a.1) especially compilers whose generics factor out a common object code for all/some varieties of arguments passed in
b) in the subprograms after OO tag dispatch via tagged records
c) discriminants
d) universal integer
e) private
f) Ada compilers with the _LRM_-permitted automatic garbage collection
g) constrained subtypes vis a vis each other and vis a vis the type's first subtype
h) array slices vis a vis each other and vis a vis the whole array
i) with … use
j) renames
h) child packages
j) aspects
k) pragmas
l) unchecked_conversion
m) unchecked_access
n) unchecked_deallocation
o) unchecked_union
p) any other language feature that directly allows  /this/ versus /that/ or conspires in /this/ versus /that/

Let us assume for the moment (or always) that Jean Ichbiah and Tucker Taft (and indeed the people at AJPO stating the goals of the Ada9X project) aren't ignorant dolts who didn't do their homework.  Let us assume that both Ichbiah and Taft actually read Steelman requirement 3-3F.  Let us assume that both Ichbiah et. al. and Taft et. al. seriously pondered how to achieve Steelman requirement 3-3F.

http://www.adahome.com/History/Steelman/steeltas.htm#3-3F

But both Ada83 and Ada95 lack 3-3F.  Are we to infer that twice 2 language-design teams with 2 strong captains at the helm of the ship goofed up and accidentally forgot to include 3-3F?  No, sometime around 1980 give or take a few years and sometime around 1993 give or take a few years someone found really good reasons why 3-3F is a bad idea for Ada, because 3-3F would have __________ negative interactions with the _____________ language feature or because 3-3F would have ________ negative interactions with the ___________ psychology of the programmer as measured by the aforementioned cognitive dimensions of notation.

https://en.wikipedia.org/wiki/Cognitive_dimensions_of_notations

> P.S. The major failure of OO design in C++ is conflating specific and 
> class-wide types, which makes C++ OO weakly-typed, whereas in Ada OO is 
> strongly typed all the way.

Oh how quickly you change your tune.  Just 8 or 7 days ago you claimed the opposite regarding Ada's generics being a “weakly-typed” “50 shades of mess”.  Now Ada generics are the paragon of strong typing able to nobly withstand any interaction with bad-idea other language features.

On Tuesday, June 19, 2018 at 2:58:49 AM UTC-5, Dmitry A. Kazakov wrote:
> On 2018-06-19 00:36, Paul Rubin wrote:
> > "Dmitry A. Kazakov" writes:
> >> P.S. Stepanov arguing for generics (templates) claimed that the reason
> >> why C++ needed this mess was impossibility to write Max using dynamic
> >> polymorphism... I believe it is possible to have a language where
> >> generic Max and Swap could be written without generics.
> > 
> > I've been wanting to look up how Ada generics work.  C++ generics are
> > implemented with templates which leads to a horrible mess, but generics
> > themselves don't have to be a mess, as far as I know.
> 
> There are 50 shades of mess. Ada's generics try to introduce some 
> weakly-typed contracts on the formal generic parameters, where C++ 
> templates go completely untyped, but mess is always mess. You cannot 
> make a decent language out of macro processor.

On Wednesday, June 20, 2018 at 2:33:26 AM UTC-5, Dmitry A. Kazakov wrote:
> On Tuesday, June 19, 2018 at 2:39:30 PM UTC-5, Dmitry A. Kazakov wrote: 
> >> Generics and macros are same thing regardless implementation. The core
> >> idea and all power lies in textual substitution as opposed to the
> >> concept substitutability in a properly typed systems.
> 
> There is no such thing in Ada. Formal generic types, e.g.
> 
>     type Foo (<>) is private;
> 
> match pretty much anything. The actual type is then substituted in all 
> language constructs just like macros do. The only constraint here is the 
> language syntax and a few sematic checks which make the language of 
> generics (not to confuse with the core language) weakly typed, where C++ 
> templates are completely untyped.

> So any comparison to C++ without concrete examples is useless.

No, any critique of an Ada proposal that has not been written up as an official AI or tantamount (same format &  content) to an AI is what is truly useless.  It isn't the responsibility of the other 7 billion people on the planet to •guess• what you mean.  The onus is on you to take the warnings that I have offered as food for thought when •you• write the AI for this 'Class for untagged types (and its external-to-type tag).  After the AI is in my hands, then and only then is the onus on me to critique it, both in Ada-only domain and vicariously by drawing meticulous parallels to C++.  Currently, I have nothing but hand-waving to work with there.

Without such an AI, every time that I nail your bad idea and eviscerate it totally (hitting the nail directly on the head of a fundamental flaw in your bad idea), you can play mind games of fibbing, “oh, silly you, my idea is quite different than that,” then going down dozens of oblique tangents of distraction.  With such an AI, we can see whether your AI plugs every hole in the leaky dike, whether the intersection of language features has planted a buried C++-esque landmine or whether the junction of language features has a conjunctive-nevus flaw.