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, XPRIO autolearn=ham autolearn_force=no version=3.4.6 Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: New aggregates with Ada 2022. Date: Fri, 24 Jun 2022 22:13:44 -0500 Organization: A noiseless patient Spider Message-ID: References: Injection-Date: Sat, 25 Jun 2022 03:13:46 -0000 (UTC) Injection-Info: reader02.eternal-september.org; posting-host="ea8ee915547ce677c25b93936a1e0f4c"; logging-data="14778"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18IqpiTZ0ME9mU3ytLCog7n2po+/3ghTxg=" Cancel-Lock: sha1:L2QO4pqTw6vVfIQMs7jHiW2EtIw= X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.7246 X-RFC2646: Format=Flowed; Response X-Newsreader: Microsoft Outlook Express 6.00.2900.5931 X-Priority: 3 X-MSMail-Priority: Normal Xref: reader02.eternal-september.org comp.lang.ada:64029 List-Id: "Dmitry A. Kazakov" wrote in message news:t93mr6$pvm$1@gioia.aioe.org... > 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. Dymanic means a function. And there is no reason to treat a few functions as special (again, at the user level). Something purely-compile time (like the selection of record components) clearly needs some special semantics. Not so clear with dynamic things. >> 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. They add a huge amount of complication for very little gain. One could simplify them (getting rid of mistaken features like slices), but you still would want a user-defined version. And once you have that, you no longer need a special version - you just have some predefined versions (just like Ada handles operators). > 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). I'd rather plan for a future where the compiler tool set does a lot of correctness checking for one's programs; code generation will always be much cheaper than that (especially if you do not need bleeding edge performance). Simplify (and abstract) the language, complicate the compiler! Randy.