Re: Intervention needed?

[Optikos <optikos@verizon.net>]

On Thursday, March 21, 2019 at 10:16:24 PM UTC-4, Randy Brukardt wrote:
> "Optikos" wrote in message 
> 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, ...
> 
> Not a pointer, since a pointer is essentially a raw machine address which 
> cannot detect problems. I'd call it a reference, as the abstract way of 
> designating something.
> 
> And cursors can be and often are implemented so that the likelihood of an 
> undetected dangling reference is low to impossible. That's not possible for 
> any sort of pointer. (You can do the Rust thing and do some sort of 
> 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 like 
> an Ada compiler without some form of references. One can argue about the 
> form, but not the need. You have to be able to have long-lived connections 
> between structures -- they could be strong or weak or a variety of other 
> 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, policies (and their surrounding politics & police), and designs can carry a civilization (or programming community) only so far.  Sometimes “so far” is measured in centuries.  Other times “so far” 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 •not outside• either the referencED container nor the higher-order referencING container, but rather a private matter within/among the federated containers—and is thus an alternate form of the encapsulation of ownership of these long-lived references, so that they are not dangling outside the built-up federated containers, and their lifetimes are guaranteed to be retired as each element of the container-federation is retired.  (Rust in particular seems to be incapable of expressing such federation to its current borrow 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 the compiler to touch up the extrapolation of the encapsulation of the references 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 federation is to behave with respect to the encapsulation of the interplay of references among federated containers.

Then there can be stricter police (e.g., Rust's borrow checker; Tucker's first proposal) that assures no dangling pointers outside of what has been encapsulated within the overt declarations of how the federated containers reference each other.  What Rust has now is what perhaps history might call a naïve borrow checker that cannot be steered (at time of app-domain language-usage) by (app-domain-)federated containers.