Re: Latest suggestion for 202x

["G.B." <bauhaus@notmyhomepage.invalid>]

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.

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,
* Independent-Components,
* Sparse,
* Associating<K, V> where K in I'Class and ...
* ...

A user defined operator for "Element Access" then becomes a distinct subject,
and a distinct opportunity.