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=-1.9 required=5.0 tests=BAYES_00 autolearn=unavailable autolearn_force=no version=3.4.4 X-Received: by 2002:ac8:1888:: with SMTP id s8mr124617523qtj.190.1561314846694; Sun, 23 Jun 2019 11:34:06 -0700 (PDT) X-Received: by 2002:a9d:2f0:: with SMTP id 103mr74780075otl.182.1561314846453; Sun, 23 Jun 2019 11:34:06 -0700 (PDT) Path: eternal-september.org!reader01.eternal-september.org!feeder.eternal-september.org!weretis.net!feeder6.news.weretis.net!feeder.usenetexpress.com!feeder-in1.iad1.usenetexpress.com!border1.nntp.dca1.giganews.com!nntp.giganews.com!m24no9531655qtm.0!news-out.google.com!33ni169qtt.0!nntp.google.com!m24no9531652qtm.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Sun, 23 Jun 2019 11:34:06 -0700 (PDT) In-Reply-To: Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=47.185.234.171; posting-account=zwxLlwoAAAChLBU7oraRzNDnqQYkYbpo NNTP-Posting-Host: 47.185.234.171 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> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: <5fed1874-ab88-41a6-8da2-723756f73d53@googlegroups.com> Subject: Re: Latest suggestion for 202x From: Optikos Injection-Date: Sun, 23 Jun 2019 18:34:06 +0000 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Xref: reader01.eternal-september.org comp.lang.ada:56723 Date: 2019-06-23T11:34:06-07:00 List-Id: 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=C2=A0disagree.=C2=A0=C2=A0Array=C2=A0indexing=C2=A0operations=C2=A0r= efer=C2=A0to=C2=A0elements=C2=A0of=C2=A0an=C2=A0array > >> object.=C2=A0=C2=A0Function=C2=A0calls=C2=A0yield=C2=A0a=C2=A0value,= =C2=A0and=C2=A0can=C2=A0have=C2=A0side=C2=A0effects. > >=20 > > So can array indexing, when you get a copy of an array element, its con= struction=C2=A0may=C2=A0do=C2=A0whatever=C2=A0you=C2=A0wanted,=C2=A0e.g.=C2= =A0spawn=C2=A0format=C2=A0c:=C2=A0/q. >=20 > The way in which your argument is composed is not really doing justice > to the original ideas of array and record, I think. >=20 > It is fusing features of almost different languages, to no avail > (other than formalism). >=20 > The original *ideas* of array and record are fairly simple: > store plain old data objects somewhere, by index or by name. > No fancy effects. >=20 > 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. >=20 > 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 A= da would strictly enforce this prohibition of arrays outside of private. I= t 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 mu= ch 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 CHIL= L eventually needed to do, as a hideous example of paying too much homage t= o 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: cle= arly differentiating O(1) random-access from O(log n) logarithmic search fr= om O(n) linear search and so forth. With the exception of the obviously-ge= neralized f(x) notation (whose very nature says that this function's functi= onality could be from anything anywhere in the wide world of mathematics), = it has always annoyed me that various languages (e.g., the STL-C++-influenc= ed ones; the SNOBOL-influenced ones) abuse the Algol58 [ ] random-access ar= ray notation for non-random-access associative searches, such as non-vector= containers in C++' s STL and in SNOBOL's tables. Sloppy=E2=80=A0 programm= ers 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-stru= ctures and/or of loops. =E2=80=A0 which is most of them nowadays > * Independent-Components, > * Sparse, > * Associating where K in I'Class and ... > * ... >=20 > 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 a= rrays, 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.