Re: Map iteration and modification

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

On 2024-01-04 05:07, Randy Brukardt wrote:
> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> 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