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:43d0:: with SMTP id s199mr7503736itb.17.1552827168511; Sun, 17 Mar 2019 05:52:48 -0700 (PDT) X-Received: by 2002:aca:3fc4:: with SMTP id m187mr6552140oia.37.1552827168273; Sun, 17 Mar 2019 05:52:48 -0700 (PDT) Path: eternal-september.org!reader01.eternal-september.org!feeder.eternal-september.org!i2pn.org!weretis.net!feeder6.news.weretis.net!feeder.usenetexpress.com!feeder-in1.iad1.usenetexpress.com!border1.nntp.dca1.giganews.com!nntp.giganews.com!82no297609itk.0!news-out.google.com!l81ni382itl.0!nntp.google.com!78no103227itl.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Sun, 17 Mar 2019 05:52:47 -0700 (PDT) In-Reply-To: Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=96.255.209.31; posting-account=zwxLlwoAAAChLBU7oraRzNDnqQYkYbpo NNTP-Posting-Host: 96.255.209.31 References: User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: <6e1977a5-701e-4b4f-a937-a1b89d9127f0@googlegroups.com> Subject: Re: Intervention needed? From: Optikos Injection-Date: Sun, 17 Mar 2019 12:52:48 +0000 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Xref: reader01.eternal-september.org comp.lang.ada:55878 Date: 2019-03-17T05:52:47-07:00 List-Id: On Tuesday, March 12, 2019 at 5:53:04 PM UTC-4, Randy Brukardt wrote: > "Lucretia" wrote in message=20 > news:bba8f6a8-36ce-4bed-bd84-8a9ea7dc02f7@googlegroups.com... > > On Tuesday, 12 March 2019 18:14:04 UTC, Olivier Henley wrote: > >> On Tuesday, March 12, 2019 at 12:32:34 PM UTC-4, Jeffrey R. Carter wro= te: > ... > >> It has nothing to do with ourselves... me my, my. > >> > >> I suppose we did so to set the record straight about Ada to a communit= y > >> that has 'A LOT' of traction and think they are reinventing the wheel.= ..=20 > >> by staying blind to Ada. > > > > It's also to do with the fact that Rust isn't all that either. It=20 > > literally only adds the > > pointer ownership thing, nothing else, yet this is the hype this train = is=20 > > carrying and > > lods of people are getting on it, instead of getting on Ada. >=20 > My understanding is that the SPARK people are far into designing ownershi= p=20 > contracts for Spark. >=20 > It's also possible that Ada 2020 will have a form of pointer ownership.= =20 > (Unfortunately, we didn't make any conclusions on that during yesterday's= =20 > meeting, so it's still in limbo, and we're getting very close to the fini= sh=20 > line.) The current problem is that in Ada 2020 as it stands, it's not=20 > possible to write a containers implementation in pure Ada. You'd have to= =20 > have some implementation hack to turn off some of the Legality Rules. Tuc= ker=20 > has designed a solution, based on an ownership mechanism, but as it is ne= w=20 > and barely vetted, it's unclear what we will do with it ultimately. Note= =20 > that this solution will not provide the perfect safety that you would get= =20 > with SPARK or Rust, but it would form the foundation of the SPARK solutio= n=20 > and it would clearly catch a lot of issues with using pointers to impleme= nt=20 > ADTs. (And there is little other reason to use pointers, IMHO.) I am sorry to hear that the hope for Ada being the 2nd language (not counti= ng the Draconian SPARK variant) to achieve Rust's level of pointer safety h= as been abandoned. ARG, please leave an immense paper trail of what-confli= cts-with-what in Ada as defined to achieve a Rust-esque borrow checker in i= ts full perfect-pointer form. Randy, would Tucker's new ownership proposal come close to 100% feature-par= ity with Rust's borrow checker? If not, then with or without Tucker's new = ownership proposal, please provide an example of bad access code that Ada20= 20 would still allow to be written (e.g., a leak at runtime?) that Rust's b= orrow checker would find at compile-time. Or equivalently (I think), technically what in today's Ada (or new in Ada20= 20) stops ARG from a wholesale importation of Rust's borrow checker grafted= onto Ada syntax? And why cannot the ARG apply for a timeline extension to= ISO? (If ever there was a time to have time to get it right, this would b= e the one!) Ada being 2nd best at compile-time revelation of aberrant accesses/pointers= with Rust being in 1st place does not market Ada well. It makes it sound = like Rust definitively won, despite Ada's 40 years of diligently trying to = be the safest language. (Let's not allow that to happen, or else the world= needs AdaSyntaxRustSemantics as a new language=E2=80=94with a catchier nam= e.)