From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on ip-172-31-65-14.ec2.internal X-Spam-Level: X-Spam-Status: No, score=-1.9 required=3.0 tests=BAYES_00,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!aioe.org!siG8trSPtxwtkBCOZpBn8A.user.46.165.242.91.POSTED!not-for-mail From: "Dmitry A. Kazakov" Newsgroups: comp.lang.ada Subject: Re: New aggregates with Ada 2022. Date: Fri, 24 Jun 2022 08:50:14 +0200 Organization: Aioe.org NNTP Server Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: gioia.aioe.org; logging-data="26614"; posting-host="siG8trSPtxwtkBCOZpBn8A.user.gioia.aioe.org"; mail-complaints-to="abuse@aioe.org"; User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.10.0 Content-Language: en-US X-Notice: Filtered by postfilter v. 0.9.2 Xref: reader02.eternal-september.org comp.lang.ada:64024 List-Id: On 2022-06-24 03:24, Randy Brukardt wrote: > "Dmitry A. Kazakov" wrote in message > news:t91buq$10im$1@gioia.aioe.org... >> On 2022-06-23 03:06, Randy Brukardt wrote: > ... >>> (How something gets implemented should not be part of a language >>> design, so long as the design does not prevent an efficient >>> implementation.) >>> I certainly would not treat them as special in any way, just a series of >>> function calls. (Possibly records could be treated that way as well, >>> although it is less clear that an efficient implementation is possible >>> for >>> them.) >> >> Syntax sugar for subprogram calls is not enough because it does not allow >> generic programming. One should be able to write a program that deals with >> any instance of the interface. Like a generic body working with any actual >> array or a class-wide body which unfortunately is impossible to have for >> arrays presently. > > You're thinking too small. Obviously, in a language without an syntactic > array construct, every data structure would be some sort of record. They are fundamentally different. Record interface is static mapping: identifier -> value 1D array interface is dynamic mapping: ordered value -> value It not only has run-time semantics of (indexing). It is also ordering of the index which implies enumeration, ranges, slices. > So > class-wide operations would be available for all of those -- and without all > of the complications of a separate formal array type. The idea is to have > one mechanism for pretty much everything, and let the compiler sort out the > results. Back when we created Janus/Ada, that wasn't really practical > because of memory and CPU speed constraints, but none of that holds true > anymore. Simplify the language, complicate the compiler! I don't buy the idea of run-time penalty for having abstract data types and I don't see why built-in arrays cannot coexist with user-defined ones without turning the language into LISP. Furthermore, the age of free CPU cycles came to an end. Soon we will have return back to sanity. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de