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:6f0a:: with SMTP id k10mr6268354ioc.185.1553243907395; Fri, 22 Mar 2019 01:38:27 -0700 (PDT) X-Received: by 2002:a9d:30d2:: with SMTP id r18mr6031046otg.176.1553243907217; Fri, 22 Mar 2019 01:38:27 -0700 (PDT) Path: eternal-september.org!reader01.eternal-september.org!feeder.eternal-september.org!weretis.net!feeder6.news.weretis.net!feeder.usenetexpress.com!feeder-in1.iad1.usenetexpress.com!border1.nntp.dca1.giganews.com!nntp.giganews.com!w126no88494ita.0!news-out.google.com!l81ni121itl.0!nntp.google.com!w126no88491ita.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Fri, 22 Mar 2019 01:38:26 -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: <6e1977a5-701e-4b4f-a937-a1b89d9127f0@googlegroups.com> <6f9ea847-2903-48c8-9afc-930201f2765a@googlegroups.com> <74339f3f-9591-45a3-8632-8834b4b466ab@googlegroups.com> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: Subject: Re: Intervention needed? From: Optikos Injection-Date: Fri, 22 Mar 2019 08:38:27 +0000 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Xref: reader01.eternal-september.org comp.lang.ada:55925 Date: 2019-03-22T01:38:26-07:00 List-Id: On Thursday, March 21, 2019 at 10:16:24 PM UTC-4, Randy Brukardt wrote: > "Optikos" wrote in message=20 > news:74339f3f-9591-45a3-8632-8834b4b466ab@googlegroups.com... > ... > >What you describe as (a[n ab]use case for) cursors is in reality > >a pointer in the end, ... >=20 > Not a pointer, since a pointer is essentially a raw machine address which= =20 > cannot detect problems. I'd call it a reference, as the abstract way of= =20 > designating something. >=20 > And cursors can be and often are implemented so that the likelihood of an= =20 > undetected dangling reference is low to impossible. That's not possible f= or=20 > any sort of pointer. (You can do the Rust thing and do some sort of=20 > compile-time rules, but that doesn't help build complex data structures.) I am suspecting the same failure there in Rust. > I don't believe that it is possible to build a complex data structure lik= e=20 > an Ada compiler without some form of references. One can argue about the= =20 > form, but not the need. You have to be able to have long-lived connection= s=20 > between structures -- they could be strong or weak or a variety of other= =20 > things, but you can't live without some form of references. On that, we wholeheartedly agree. I look at programming as with any other = flow of human endeavor based on philosophy & politics (with emphasis on the= root-word policy within politics & police). Some ideas, philosophies, pol= icies (and their surrounding politics & police), and designs can carry a ci= vilization (or programming community) only so far. Sometimes =E2=80=9Cso f= ar=E2=80=9D is measured in centuries. Other times =E2=80=9Cso far=E2=80=9D= is measured in decades or even only years. We now see that the PL/1 & Ada= wise vision of the foundational 1970s (which C++ absconded with too) takes= us this far, but perhaps not much further. What might take us further is an intimate side-channel among containers to = have inter-container long-lived referencing that is =E2=80=A2not outside=E2= =80=A2 either the referencED container nor the higher-order referencING con= tainer, but rather a private matter within/among the federated containers= =E2=80=94and is thus an alternate form of the encapsulation of ownership of= these long-lived references, so that they are not dangling outside the bui= lt-up federated containers, and their lifetimes are guaranteed to be retire= d as each element of the container-federation is retired. (Rust in particu= lar seems to be incapable of expressing such federation to its current borr= ow checker.) This seems to need some form of multistage programming which = is to place at least: 1) [to borrow the #PL/1 & a.app Ada & OCaml P4 concept] an interpreter in t= he compiler to touch up the extrapolation of the encapsulation of the refer= ences in the federated containers or 2) something more in the logic(-declaration-of-requirements) domain akin to= Z (Zed) or ATS/LF to specify through stepwise refinement how the federatio= n is to behave with respect to the encapsulation of the interplay of refere= nces among federated containers. Then there can be stricter police (e.g., Rust's borrow checker; Tucker's fi= rst proposal) that assures no dangling pointers outside of what has been en= capsulated within the overt declarations of how the federated containers re= ference each other. What Rust has now is what perhaps history might call a= na=C3=AFve borrow checker that cannot be steered (at time of app-domain la= nguage-usage) by (app-domain-)federated containers.