Re: Intervention needed?

[Optikos <optikos@verizon.net>]

On Tuesday, March 19, 2019 at 7:13:47 PM UTC-4, Randy Brukardt wrote:
> "Optikos" wrote in message 
> news:de2f5462-fa10-4fdf-97a6-99989e40c697@googlegroups.com...
> On Tuesday, March 19, 2019 at 6:13:20 PM UTC-4, Randy Brukardt wrote:
> >> Baloney. The cursor object still exists, and someone can still try to use
> >> it. Yes, you'll get an ...exception... rather than erroneous execution
> >
> >No, you have it all wrong ...there....  Not raise an exception, but rather
> >gracefully take the end-of-walk branch of code, just as in normal 
> >operations.
> 
> Walking is only a small portion of the usage of cursors, and IMHO it is the 
> least important one (since everyone other than container developers ought to 
> be using iterators to walk their containers).
> 
> A cursor is a handle accessing an element of a larger container, nothing 
> more or less than that. The primary usage is to connect data structures made 
> up of multiple containers. For instance, consider a compiler symboltable. 
> There is a tree structure that represents each of the declarations and their 
> scopes, and a map structure that represents a mapping of names to nodes of 
> the treee. The contents of that map is going to be tree cursors, each 
> representing a declaration with a particular name.
> 
> In such a structure, it would be common to assume that the cursors are valid 
> (just like you would assume that pointers are non-null in such a case --  
> that's precisely what Janus/Ada code does, for instance). And dereferencing 
> a cursor that points at a deleted node has to raise some exception (just as 
> it would when using a pointer).
> 
> The value of cursors is that they can be implemented by a range of 
> abstractions with a range of checking, from array indicies (as in the 
> bounded containers and the vector) to pointers with a variety of schemes 
> from no dangling checking to the bulletproof controlled cursor scheme.

Interesting (ab)use case for cursors:  (ab)use cursors as an obfuscated long-lived address/pointer/access instead of for transiently walking  the contents of containers.  (The walk might be of only one or few results of a transient query, but still a walk of the transient results of the search.)  What you describe as (a[n ab]use case for) cursors is in reality a pointer in the end, despite any slight-of-hand to change what noun-phrase is utilized to name what in the end is quite clearly still a pointer(-in-purpose-&-mission).  A rose by any other name is just as pungent.

To put it SQL terms to reveal how jarring the (ab)use-case of cursors is, should a cursor be able to be stored as a field or record in a table?  The SQL answer is:  of course not, cursors are transient artifacts of dynamic queries, not able to be ossified in static storage.

My words are not a harsh critique or condemnation of Ada or of anyone's programming style; you are playing the cards that you are dealt.  It is food for my contemplation of this interim era of programming that lacks BetterAda or BetterRust as available programming languages.  (I'd say BetterC++, but that would be like saying BetterAbjectPoverty, where adding any richness makes poverty or C++ not poverty or C++ anymore.)  Today's Ada is closer to BetterAda than any other language is.