From mboxrd@z Thu Jan 1 00:00:00 1970 Path: eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: Map iteration and modification Date: Thu, 4 Jan 2024 20:00:37 -0600 Organization: A noiseless patient Spider Message-ID: References: Injection-Date: Fri, 5 Jan 2024 01:59:43 -0000 (UTC) Injection-Info: dont-email.me; posting-host="ef5742db43e50af7920779a9b0b05274"; logging-data="4059447"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX184/7T8Dbw3M0BLEKWRUSuoW7cZRPUXkTk=" Cancel-Lock: sha1:ifh6LGxVeeqMQOMg5uaTJoy9d28= X-Priority: 3 X-Newsreader: Microsoft Outlook Express 6.00.2900.5931 X-RFC2646: Format=Flowed; Response X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.7246 X-MSMail-Priority: Normal Xref: news.eternal-september.org comp.lang.ada:65961 List-Id: "Dmitry A. Kazakov" wrote in message news:un64o3$3krch$1@dont-email.me... ... >> Exactly. These operations, especially slicing, have a huge impact on the >> cost of parameter passing for arrays (whether or not they are used). And >> that's a pretty fundamental operation. > > It is not slicing it is dynamically constrained arrays which are required > anyway. A general problem of language design is how to treat statically > known constraints effectively. No, it's the combination of slicing and passing arrays with unknown (at compile-time) constraints that causes problems. And it only causes problems if you want to separate the array interface and the array implementation (which we both want to do). In such a case, you are passing arrays with unknown constraints and implementation. Assignable slices don't work with that, as they require a contiguous implementation of elements. You could work around that in various ways (passing slices by copy-result, passing an assignment routine along with the parameter), but all of them have substantial performance impacts that would make traditional array implementations much slower. > Ada arrays are pretty good to me. Note, I am saying that after years of > using Ada arrays for interfacing C! Yes, I would like having more support > for flattening arrays, but the mere fact that Ada can interface C using > *in-place* semantics invalidates your point. Inferfacing is using the array implementation, not the array interface. Of course it works great, as you note Ada commingles those in a way that makes them inseparable. To separate them, you are going to have to lose something. I chose slices and other array-specific operations as a built-in as that something. YMMV. ... >>> Usability always trumps performance. >> >> That's the philosophy of languages like Python, not Ada. > > Ah, this is why Python is totally unusable? (:-)) I would tend to argue that it is indeed the case that you get dubious results when you put usability first. Ada puts readability/understandability, maintainability, and consistency first (along with performance). Those attributes tend to provide usability, but not at the cost of making things less consistent or understandable. I wrote an article on this topic a year and a half ago that I wanted to publish on Ada-Auth.org. But I got enough pushback about not being "neutral" that I never did so. (I don't think discussing why we don't do things some other languages do is negative, but whatever.) I've put this on RR's blog at http://www.rrsoftware.com/html/blog/consequences.html so it isn't lost. Randy.