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:6315:: with SMTP id p21-v6mr2613043iog.43.1530117229111; Wed, 27 Jun 2018 09:33:49 -0700 (PDT) X-Received: by 2002:aca:c744:: with SMTP id x65-v6mr167976oif.2.1530117228722; Wed, 27 Jun 2018 09:33:48 -0700 (PDT) Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!feeder.eternal-september.org!feeder4.usenet.farm!feed.usenet.farm!feeder.usenetexpress.com!feeder-in1.iad1.usenetexpress.com!border1.nntp.dca1.giganews.com!nntp.giganews.com!u78-v6no1941112itb.0!news-out.google.com!z3-v6ni1421iti.0!nntp.google.com!d7-v6no1960631itj.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Wed, 27 Jun 2018 09:33:48 -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> <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: <396e6cfe-8f97-4aa7-9034-67fa089d8609@googlegroups.com> Subject: Re: Ada Successor Language From: "Dan'l Miller" Injection-Date: Wed, 27 Jun 2018 16:33:49 +0000 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Xref: reader02.eternal-september.org comp.lang.ada:53383 Date: 2018-06-27T09:33:48-07:00 List-Id: 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: >=20 > >> =E2=80=A6 I don't > >> think Dmitry's suggestion for class-wide types rooted in untagged type= s > >> would lead to the same problems as slicing in C++. > >=20 > > Then you are an unable to foresee slicing situations as Bjarne Stroustr= up was. Bjarne should not be one's role model as a language designer. >=20 > But you are able to foresee that, right? Then maybe you put up an=20 > example of what the problem is? Rather than talk in C++-speak about importation of one of C++'s notorious f= laws, let us instead talk in Ada-speak about an analogous proposed Ada feat= ure. The Steelman requirement 3-3F strongly resembles portions of your tag= -external-to-type idea on which your 'Class for untagged types depends. Bo= th 3-3F and your tag-external-to-type require the compiler to know precisel= y which strong type is being utilized in =E2=80=A2=E2=80=A2every language c= onstruct everywhere under all circumstances=E2=80=A2=E2=80=A2. If the comp= iler 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-sto= rage-allocated-within-record extra fields among various 3-3F-utilizing reco= rd-types. or 2) losing track of precisely which strong type had this versus that tag-ext= ernal-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 =E2=80=A2intentionally=E2=80=A2 d= esign the losing-of-track into the language. Rather, these losings-of-trac= k would occur at the intersection/junction/boundary of 2 or more language f= eatures. Because there are hundreds of language features, the combinatoria= l 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 t= hem all on Day One). The medical world has a term for flaws at the junctio= n of 2 or more tissue features: conjunctive nevus. Nearly all of C++'s la= ndmines that must be meticulously vigilantly avoided every waking moment ar= e in fact conjunctive nevuses where 2 or more language features interact ba= dly with each other at their point of contact with each other. That is wha= t 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 b= e 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 =E2=80=A6 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 Ic= hbiah 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 St= eelman 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 a= ccidentally 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 hav= e __________ 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 cognitiv= e 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=20 > class-wide types, which makes C++ OO weakly-typed, whereas in Ada OO is= =20 > 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 =E2=80=9Cweakly-typed=E2=80=9D = =E2=80=9C50 shades of mess=E2=80=9D. Now Ada generics are the paragon of s= trong typing able to nobly withstand any interaction with bad-idea other la= nguage 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. > >=20 > > 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. >=20 > There are 50 shades of mess. Ada's generics try to introduce some=20 > weakly-typed contracts on the formal generic parameters, where C++=20 > templates go completely untyped, but mess is always mess. You cannot=20 > 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:= =20 > >> 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. >=20 > There is no such thing in Ada. Formal generic types, e.g. >=20 > type Foo (<>) is private; >=20 > match pretty much anything. The actual type is then substituted in all=20 > language constructs just like macros do. The only constraint here is the= =20 > language syntax and a few sematic checks which make the language of=20 > generics (not to confuse with the core language) weakly typed, where C++= =20 > 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 offi= cial AI or tantamount (same format & content) to an AI is what is truly us= eless. It isn't the responsibility of the other 7 billion people on the pl= anet to =E2=80=A2guess=E2=80=A2 what you mean. The onus is on you to take = the warnings that I have offered as food for thought when =E2=80=A2you=E2= =80=A2 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 meti= culous 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 you= r bad idea), you can play mind games of fibbing, =E2=80=9Coh, silly you, my= idea is quite different than that,=E2=80=9D then going down dozens of obli= que tangents of distraction. With such an AI, we can see whether your AI p= lugs every hole in the leaky dike, whether the intersection of language fea= tures has planted a buried C++-esque landmine or whether the junction of la= nguage features has a conjunctive-nevus flaw.