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=-0.3 required=5.0 tests=BAYES_00,
	REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4
Path: 
 eternal-september.org!reader01.eternal-september.org!.POSTED!not-for-mail
From: "G.B." <bauhaus@notmyhomepage.invalid>
Newsgroups: comp.lang.ada
Subject: Re: Latest suggestion for 202x
Date: Sun, 23 Jun 2019 09:38:28 +0200
Organization: A noiseless patient Spider
Message-ID: <qena9l$hpt$1@dont-email.me>
References: <728c4668-8fa0-4a57-a502-2bf476fc3940@googlegroups.com>
 <4908c3e3-18dc-4953-bf26-46f160d2ebfd@googlegroups.com>
 <9dcf22a2-2255-4089-b1f0-93e31448415e@googlegroups.com>
 <86h88obeu0.fsf@gaheris.avalon.lan>
 <39e749cd-de5c-44fa-b8ec-50d36f3bd52c@googlegroups.com>
 <qe8b41$pji$1@gioia.aioe.org> <lnef3rnb8d.fsf@kst-u.example.com>
 <qeh0sh$3rd$1@franka.jacob-sparre.dk> <qei8ps$nec$1@gioia.aioe.org>
 <lnd0j6kdsl.fsf@kst-u.example.com> <qej8gm$1b40$1@gioia.aioe.org>
 <ln8stuk7pu.fsf@kst-u.example.com> <qekjbb$vu0$1@gioia.aioe.org>
 <lnr27likgv.fsf@kst-u.example.com> <qelsh7$pej$1@gioia.aioe.org>
Reply-To: nonlegitur@notmyhomepage.de
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Sun, 23 Jun 2019 07:38:30 -0000 (UTC)
Injection-Info: reader02.eternal-september.org;
 posting-host="c00e274b966be1689d0f34838ceaa694";
	logging-data="18237"; mail-complaints-to="abuse@eternal-september.org";
	posting-account="U2FsdGVkX195aM+zrRGTwvrHxLgBZp05aAF0113ebUE="
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0)
 Gecko/20100101 Thunderbird/60.7.1
Cancel-Lock: sha1:cQNbrS04As5Otx+9xSixLPofC6w=
In-Reply-To: <qelsh7$pej$1@gioia.aioe.org>
Content-Language: de-DE
Xref: reader01.eternal-september.org comp.lang.ada:56719
Date: 2019-06-23T09:38:28+02:00
List-Id: <comp.lang.ada>

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.