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: Sat, 25 Jun 2022 10:50:54 +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="55681"; 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:64034 List-Id: On 2022-06-25 05:13, Randy Brukardt wrote: > "Dmitry A. Kazakov" wrote in message > news:t93mr6$pvm$1@gioia.aioe.org... >> On 2022-06-24 03:24, Randy Brukardt wrote: >>> 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. > > Dymanic means a function. And there is no reason to treat a few functions as > special (again, at the user level). No. Identifier is not a value, it is a static name. This allows us to have any statically chosen type on the right side of the mapping. With a dynamic mapping we must have the same type for all outcomes, e.g. of the array element. >> 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. > > They add a huge amount of complication for very little gain. We have different priorities here. I see arrays with slices as one of the most important language features. Especially considering formal verification and validation. >> Furthermore, the age of free CPU cycles came to an end. Soon we will have >> return back to sanity. > > I don't think programming abstractly and translating that into good code > will ever be a bad idea. After all, that is the idea behind Ada. If you > truly want to worry about the cost of compilation, then you have program in > a very close to the metal language, even lower level than C. And current > machines are way harder to generate code for than the Z-80 that we started > out on (and even then, we generated pretty bad code with the very tiny > compiler). No, I worry about cost of execution. You want to simplify the compiler at the expense of the program complexity and efficiency of its code. > I'd rather plan for a future where the compiler tool set does a lot of > correctness checking for one's programs; Yes and correctness checking requires proper and very refined abstractions you are ready to throw away. Here is a contradiction. In a language like Forth there is basically nothing to check. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de