From mboxrd@z Thu Jan 1 00:00:00 1970 Path: eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: "Dmitry A. Kazakov" Newsgroups: comp.lang.ada Subject: Re: Map iteration and modification Date: Fri, 5 Jan 2024 12:51:50 +0100 Organization: A noiseless patient Spider Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Date: Fri, 5 Jan 2024 11:51:50 -0000 (UTC) Injection-Info: dont-email.me; posting-host="a36213fd0c8385d2810934b654e68e59"; logging-data="164236"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/2JBjraZoWe7yC5peOh5h7YKYhphjuf+Q=" User-Agent: Mozilla Thunderbird Cancel-Lock: sha1:kOdwUJapdRRxutYfhG/BaG/w4BM= In-Reply-To: Content-Language: en-US Xref: news.eternal-september.org comp.lang.ada:65963 List-Id: On 2024-01-05 03:00, Randy Brukardt wrote: > "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. As well as passing non-null pointers, discriminated objects, class-wide objects... > 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. Only if the base type implementation is contiguous. A slice of a non-contiguous container is non-contiguous. If you can deal with the first you can do with the second. The crucial point is removing static constraints from the instances which Ada does on some occasions and not on others, especially for the user-defined types. > 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. Sure, but the point is that the loss should never happen when constraints are static when the callee knows them. When the callee does not, then a constraint must be passed to it. >>>> 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. Thanks for posting this. I disagree with what you wrote on several points: 1. Your premise was that use = writing. To me using includes all aspects of software developing and maintenance process. Writing is only a small part of it. 2. You argue for language regularity as if it were opposite to usability. Again, it is pretty much obvious that a regular language is easier to use in any possible sense. 3. Removing meaningless repetitions contributes to usability. But X := X + Y is only one instance where Ada required such repetition. There are others. E.g. if X in T'Class then declare XT : T'Class renames T'Class (X); T'Class is repeated 3 times. A discussion point is whether a new name XT could be avoided etc. Introducing @ for a *single* purpose contradicts the principle of regularity. I would rather have a regular syntax for most if not all such instances. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de