Re: Latest suggestion for 202x

[Optikos <optikos@verizon.net>]

On Sunday, June 23, 2019 at 2:38:31 AM UTC-5, G.B. wrote:
> On 22.06.19 20:37, Dmitry A. Kazakov wrote:
> >> I disagree.  Array indexing operations refer to elements of an array
> >> object.  Function calls yield a value, and can have side effects.
> > 
> > So can array indexing, when you get a copy of an array element, its construction may do whatever you wanted, e.g. spawn format c: /q.
> 
> The way in which your argument is composed is not really doing justice
> to the original ideas of array and record, I think.
> 
> It is fusing features of almost different languages, to no avail
> (other than formalism).
> 
> The original *ideas* of array and record are fairly simple:
> store plain old data objects somewhere, by index or by name.
> No fancy effects.
> 
> Your argument then invokes not-so-simple and later ideas of object
> construction and its operations. These would become associated with array
> components, but also with any other object. Hence, not specifically
> with arrays.
> 
> I think it is a better idea to conceive of Ada arrays as low
> level representational types. Arrays should only exist in private parts,
> or bodies.

I concur.  A modern backwards-compatibility-breaking course-correction of Ada would strictly enforce this prohibition of arrays outside of private.  It would do this as part of dismantling what was in vogue prior to 1980 but has not weathered the test of time due to Ada80 and Ada83 paying far too much homage to legacy languages prior to 1980.  (Thank goodness that Ada did not need to purge PL/1-esque nesting-level numbers from its records as CHILL eventually needed to do, as a hideous example of paying too much homage to one of the worst ideas in PL/1.)

> So, when there is a need to design some interface, re-inventing
> arrays will not be the optimal starting point. Traditional arrays
> are far too simplistic and universal. They therefore cannot express
> specific requirements. Such as:
> * Random-Access,

Since array indexing is already random access, I assume that you mean:  clearly differentiating O(1) random-access from O(log n) logarithmic search from O(n) linear search and so forth.  With the exception of the obviously-generalized f(x) notation (whose very nature says that this function's functionality could be from anything anywhere in the wide world of mathematics), it has always annoyed me that various languages (e.g., the STL-C++-influenced ones; the SNOBOL-influenced ones) abuse the Algol58 [ ] random-access array notation for non-random-access associative searches, such as non-vector containers in C++' s STL and in SNOBOL's tables.  Sloppy† programmers then don't think through the big-Omicron (a.k.a. big-O) Landau-notation growth rates accumulating from innermost to outermost nesting of data-structures and/or of loops.

† which is most of them nowadays

> * Independent-Components,
> * Sparse,
> * Associating<K, V> where K in I'Class and ...
> * ...
> 
> A user defined operator

I would use the plural there:  separate operators (or some sort of obvious visual clue) for different kinds of access other than random-access dense arrays, assuming that f(x) notation is not utilized for arrays, because f(x) notation says to any mathematician-minded programmer that all assumptions of what f(x) is might not be true until further inspection

> for "Element Access" then becomes a distinct subject,
> and a distinct opportunity.