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: Mon, 27 Jun 2022 16:37:08 -0500 Organization: A noiseless patient Spider Message-ID: References: Injection-Date: Mon, 27 Jun 2022 21:37:10 -0000 (UTC) Injection-Info: reader01.eternal-september.org; posting-host="af6f7f353385d44805f8f5f1d83c5664"; logging-data="803502"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18byO9HyBKcupOcLWwgzPxlau2hXv3z2i8=" Cancel-Lock: sha1:ckVWKrwB9laIpwKuy/dwadCVdQ8= X-Priority: 3 X-RFC2646: Format=Flowed; Response X-Newsreader: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.7246 X-MSMail-Priority: Normal Xref: reader02.eternal-september.org comp.lang.ada:64036 List-Id: "Dmitry A. Kazakov" wrote in message news:t96i9f$1mc1$1@gioia.aioe.org... > On 2022-06-25 05:13, Randy Brukardt wrote: ... >> 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 think we strongly agree here. I want to simplify the front-end to strengthen abstractions, and so that the effort can be put where it belongs, on static analysis/optimization and on code generation. These things are mostly fancy pattern matching, and the more of it that you can do, the better. Time spent implementing features that don't increase the expressive power (or worse, compilicate code generation in all cases) is counter-productive. >> 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. Slices are not an abstraction. They are a way to describe a particular kind of processor operation in a vaguely abstract way. But they don't extend to user-defined structures or even multi-dimensional maps (arrays if you prefer) in any practical way. The distributed overhead that they cause is immense (for instance, you can't have a discontigious array represesentation with slices, unless you are willing to pay a substantial cost for *every* array parameter). They're the anti-abstraction feature. Randy.