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:a24:7681:: with SMTP id z123-v6mr344368itb.0.1529680733627; Fri, 22 Jun 2018 08:18:53 -0700 (PDT) X-Received: by 2002:a9d:4c96:: with SMTP id m22-v6mr139543otf.6.1529680733472; Fri, 22 Jun 2018 08:18:53 -0700 (PDT) Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!feeder.eternal-september.org!maths.tcd.ie!newsswitch.lcs.mit.edu!ottix-news.ottix.net!border1.nntp.dca1.giganews.com!nntp.giganews.com!d7-v6no822573itj.0!news-out.google.com!z3-v6ni967iti.0!nntp.google.com!u78-v6no815116itb.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Fri, 22 Jun 2018 08:18:53 -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> <30e271d8-0ef9-4986-8726-2b09c7fb9526@googlegroups.com> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: <9c30a174-9fdc-47ce-be34-338223c07735@googlegroups.com> Subject: Re: Ada Successor Language From: "Dan'l Miller" Injection-Date: Fri, 22 Jun 2018 15:18:53 +0000 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Xref: reader02.eternal-september.org comp.lang.ada:53252 Date: 2018-06-22T08:18:53-07:00 List-Id: On Wednesday, June 20, 2018 at 2:33:26 AM UTC-5, Dmitry A. Kazakov wrote: > On 2018-06-19 23:07, Dan'l Miller wrote: > > On Tuesday, June 19, 2018 at 2:39:30 PM UTC-5, Dmitry A. Kazakov wrote: > >> On 2018-06-19 21:19, Paul Rubin wrote: > >>> "Dmitry A. Kazakov" writes: > >>>> 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. > >>> > >>> I don't understand what you're getting at. Are Ada generics implemen= ted > >>> with a macro processor? C++ templates amount to that, but there are > >>> other, better ways to implement generics. > >> > >> 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 > > Clearly, Ada's generics are not performing textual substitution. Ada's= generics are performing > restriction-matching on subtypes passed as formal arguments. If the crit= eria of the restrictions are > satisfied, the previously-declared-long-ago subtype in the AST is what is= passed in as the formal > argument of an Ada generic. >=20 > There is no such thing in Ada. No such thing? Nothing? Nada? Zilch? Empty set? Apparently you have no= t read =C2=A712.1 in the _AARM_ nor examples {12.3.15.i, 12.3.18.c} a few p= ages later. Just about the only restriction not permitted on generic formal parameters = is constraint on subtypes: =E2=80=9CReason: The reason for forbidding constraints in subtype_indicatio= ns is that it simplifies the elaboration of generic_declarations (since there is nothing to evaluate), and that it simp= lifies the matching rules, and makes them more checkable at compile time.= =E2=80=9D 12.3.15.i: type T1 is tagged record ... end record; generic type Formal is new T1; 12.3.18.c: type Ancestor is tagged null record; generic type Formal is new Ancestor with private; and in http://www.adaic.org/resources/add_content/standards/05rat/html/Rat-6-5.htm= l generic type T is limited new LT; -- untagged type TT is limited new TLT with private; -- tagged type A is interface; procedure Op1(X: A; ... ) is abstract; procedure N1(X: A; ... ) is null; generic type F is interface and A; These are the awesome achievement in Ada that Stroustup & Austern have been= struggling for a decade to standardize in C++ under the jargon =E2=80=9Cco= ncepts=E2=80=9D. The C++ standardization committee keeps finding some gotc= ha that causes the proposal to be rejected from C++{11,14,17}. Ada also has concept maps (which Stroustrup was also trying to standardize = a while back to facilitate concepts): again from the Ada2005 Rationale linked above: generic type My_Element is private; with package Sets is new Set_Signature(Element =3D> My_Element, others = =3D> <>); overriding procedure This is new That( ... ); All these {T1, Ancestor, LT, TLT, A, Set_Signature, Element, That} are the = restrictions that, if absent, cause the generic package to fail to compile.= So, yes, there most certainly is such a thing in Ada. > Formal generic types, e.g. >=20 > type Foo (<>) is private; red herring. I am discussing nearly every category of generic parameter ot= her than (<>). > 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, How are strictly matching the generic formal parameters' overtly-stated res= trictions on {T1, Ancestor, LT, TLT, A, Set_Signature, Element, That} in th= e examples above not strongly typed? I don't see any loosey-goosey loophol= es to bypass those restrictions to sneak a mismatch-to-those-restrictions i= n the backdoor when no one is looking. > where C++ templates are completely untyped. I would say that C++ templates have no overt matching based on =E2=80=A2res= trictions=E2=80=A2 on the formal-parameters, (other than absences discovere= d later on upon expanding the template). Conversely, the entire Turing-com= pleteness debacle in C++ templates is caused by carving out specific types = as exceptional/nongeneric/special-case template specializations that occlud= e the generic template for those precisely-matched type parameters. So the= Turing completeness is entirely based on the vicinity that C++ templates h= ave the utmost of strong typing (that even Ada doesn't have*: Ada cannot u= tilize strong typing to carve out nongeneric/special-case parameterized-typ= e package from the generic parameterized-type package). * Thank goodness Ada generics lack C++'s template specialization, because t= hat is the key feature needed to go down the path of C++-metatemplate-progr= amming-esque Turing-complete functional programming (with horrendous cobble= d-together syntax) in Ada generics.