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: Thu, 4 Jan 2024 12:28:04 +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: Thu, 4 Jan 2024 11:28:03 -0000 (UTC) Injection-Info: dont-email.me; posting-host="f5ce3a56fb13d510cf983b765108175f"; logging-data="3829137"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+ErfqwVAM5tRDFGcLe4LWPY0w+rF0AI+k=" User-Agent: Mozilla Thunderbird Cancel-Lock: sha1:D7iwNO3k6Tnyz5SdWJNNJ66O6ls= In-Reply-To: Content-Language: en-US Xref: news.eternal-september.org comp.lang.ada:65960 List-Id: On 2024-01-04 05:07, Randy Brukardt wrote: > "Dmitry A. Kazakov" wrote in message > news:un3bg9$35mhv$1@dont-email.me... [...] >> Yes, ordering is an ability to enumerate elements of a set. It is not an >> artifact it is the sole semantics of. > > Iteration is not necessarily enumeration. It is applying an operation to all > elements, and doing that does not require an order. That is not iteration, it is unordered listing, a totally useless thing because the result is the same unordered set. You could not implement it without prior ordering of the elements you fed to the threads. If the threads picked up elements concurrently there would be no way to do that without ordering elements into a taken / not yet taken order. Hell, you cannot even get an element from a truly unordered set, no way! If the programmer tried to make any use of the listing he would again have to impose ordering when collecting results per some shared object. The unordered listing is a null operation without ordering. >> The key difference is that index does not refer any element. It is >> container + index that do. > > That's not a "key difference". That exactly how one should use cursors, > especially in Ada 2022. The Ada containers do have cursor-only operations, > but those should be avoided since it is impossible to provide useful > contracts for those operations (the container is unknown, so the world can > be modified, which is bad for parallelism and understanding). Best to > consider those operations obsolete. (Note that I was *always* against the > cursor-only operations in the containers.) > > So, using a cursor implies calling an operation that includes the container > of its parameter. OK. It is some immensely over-designed index operation, then! (:-)) So, my initial question is back, why all that overhead? When you cannot do elementary things like preserving your indices from a well-defined set of upon deleting elements with indices outside that set? >>>> I don't see anything that is not already there. What are reasons for not >>>> providing: >>>> >>>> M (n) [ e.g. M (n).Key, M (n).Value ] >>>> M (n1..n2) [ in mutable contexts too ] >>>> M'First >>>> M'Last >>>> M1 & M2 [ M1 or M2 ] >>>> >>>> They are all well-defined and useful operations. >>> >>> Performance. >> >> Irrelevant so long it does not tamper implementations of other operations. > > 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. 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. > Specifically, the containers are separate from Ada. Not really. Like STL with C++ it massively influenced the language design motivating adding certain language features and shifting general language paradigm in certain direction. >> Usability always trumps performance. > > That's the philosophy of languages like Python, not Ada. Ah, this is why Python is totally unusable? (:-)) Ada is usable and performant because of right abstractions it deploys. If you notice performance problems then, maybe, just my guess, you are using a wrong abstraction? >> And again, looking at the standard containers and all these *tagged* >> *intermediate* objects one needs in order to do elementary things, I kind >> of in doubts... (:-)) > > The standard containers were designed to make *safe* containers with decent > performance. Well, we always wish the best... (:-)) -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de