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:f002:: with SMTP id s2-v6mr806165ith.52.1527947284661; Sat, 02 Jun 2018 06:48:04 -0700 (PDT) X-Received: by 2002:a9d:520c:: with SMTP id e12-v6mr57503oth.11.1527947284569; Sat, 02 Jun 2018 06:48:04 -0700 (PDT) Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!feeder.eternal-september.org!news.gegeweb.eu!gegeweb.org!news.redatomik.org!newsfeed.xs4all.nl!newsfeed9.news.xs4all.nl!85.12.16.70.MISMATCH!peer03.ams1!peer.ams1.xlned.com!news.xlned.com!peer03.am4!peer.am4.highwinds-media.com!peer02.iad!feed-me.highwinds-media.com!news.highwinds-media.com!border1.nntp.dca1.giganews.com!nntp.giganews.com!v8-v6no3138527itc.0!news-out.google.com!b185-v6ni3445itb.0!nntp.google.com!v8-v6no3138523itc.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Sat, 2 Jun 2018 06:48:04 -0700 (PDT) In-Reply-To: <5e86db65-84b9-4b5b-9aea-427a658b5ae7@googlegroups.com> Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=47.185.233.194; posting-account=zwxLlwoAAAChLBU7oraRzNDnqQYkYbpo NNTP-Posting-Host: 47.185.233.194 References: <5e86db65-84b9-4b5b-9aea-427a658b5ae7@googlegroups.com> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: <2026b3d2-95bd-4721-912c-49dedfd696cb@googlegroups.com> Subject: Re: Ada Successor Language From: "Dan'l Miller" Injection-Date: Sat, 02 Jun 2018 13:48:04 +0000 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Received-Bytes: 4623 X-Received-Body-CRC: 2703579434 Xref: reader02.eternal-september.org comp.lang.ada:52853 Date: 2018-06-02T06:48:04-07:00 List-Id: On Friday, June 1, 2018 at 11:43:52 PM UTC-5, Shark8 wrote: > It occurs to me that in order to design a successor to Ada, there=E2=80= =99s not merely one language that ought to be defined =E2=80=94 but five = =E2=80=94 and the reason is that Ada is several languages all at once: ther= e=E2=80=99s a language for generics, a language for proofs [SPARK], low-lev= el hardware, and a language for tasking in addition to the Ada that maps to= =E2=80=9Cnormal=E2=80=9D programming languages. > One of the frustrations about Ada as-it-is is that there is a lot that s= eems like it could be =E2=80=9Cfolded together=E2=80=9D, things like (eg) a= ll the Ada.[Wide_[Wide_]]Strings packages. Or, some sort of mechanism for [= explicitly] showing the relationships between types. > In order to do that we would need some sort of meta-language, wherein al= l the rest of the languages (ideally both syntactic and semantic) could be = defined. >=20 > (1) The Meta language > (2) The Generic Language > (3) The Concurrent/Parallelism language > (4) The Proving language [SPARK] > (5) The HW/Representation language On Saturday, June 2, 2018 at 3:12:25 AM UTC-5, Dmitry A. Kazakov wrote: > (6) The language of type declarations The successor to Ada should be hypoAda a) that allows writing today's Ada as a library/personality and b) that allows writing a somewhat different Ada as an alternate personality= . That way all the backwards compatibility issues can be merely labeled as hi= storical legacy in today's Ada, not brought over to hyperAda, but expressib= le in hypoAda so as to support today's Ada in the same compiler. Note that something like hyperAda would be a better working name than succA= da (successor to Ada) or even Ada++ (unless the next-gen Ada was to import = much of C/C++'s symbol syntax: ++, --, &, &&, {}, and so forth). Btw, tod= ay's Ada needs a nickname too=E2=80=94perhaps Ada8652 from the ISO standard= number. Seed7 (a somewhat-Ada derivative) and Alphard (Carnegie-Mellon's 1970's res= earch language) have already explored some of these hypoAda topics. Alphar= d even had a sublanguage way of writing the syntax of various language's lo= oping constructs; Seed7 approaches the topic differently, but accomplished= much the same result. There should be some sort of ground-rules for hyperAda so that it doesn't g= o far afield with, say, C-family syntax as merely being a cousin of Rust. Byron seeks to be modular in the backend to permit LLVM or libFirm or GIMPL= E-RTL. Byron could also be modular in the =E2=80=98lower-front-end=E2=80= =99 so to speak to permit alternative Ada-esque personalities of front-end = =E2=80=A2=E2=80=A2in the same compiler=E2=80=A2=E2=80=A2, choosable on the = compiler's command-line, as if the Ada-esque personality =E2=80=98upper-fro= ntend=E2=80=99 were a pluggable DLL to the compiler: A) today's Ada8652 B) Ada-merged-with-SPARK C) Pascal-family-syntaxed hyperAda, leaving backwards compatibility behind = in choices A and/or B D) even Ada(-or-hyperAda)-semantics-expressed-C-crypto-syntax instead of Pa= scal syntax: Ada with braces instead of begin/end, and a hundred other syn= tactic transliterations E) and so forth.