From mboxrd@z Thu Jan  1 00:00:00 1970
Path: eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: "G.B." <bauhaus@notmyhomepage.invalid>
Newsgroups: comp.lang.ada
Subject: Re: Map iteration and modification
Date: Mon, 1 Jan 2024 20:27:51 +0100
Organization: A noiseless patient Spider
Message-ID: <umv3nn$2adp0$1@dont-email.me>
References: <umjukd$9sp$1@rasp.pasdenom.info>
 <umjuvc$9sp$2@rasp.pasdenom.info> <umk6ds$e9hc$1@dont-email.me>
 <umldsq$na79$1@dont-email.me> <umm4r5$ppag$1@dont-email.me>
 <ummn4v$s6gr$1@dont-email.me> <ummtfl$t4uo$1@dont-email.me>
Reply-To: nonlegitur@notmyhomepage.de
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Mon, 1 Jan 2024 19:27:51 -0000 (UTC)
Injection-Info: dont-email.me; posting-host="3eb352a508ae871bcc96e772bf130991";
	logging-data="2438944"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+NdugzlngHAkh0lcHNVkLVSjMTf1weYBU="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:JntLBwpd72NPisn7osWmv3sutUQ=
In-Reply-To: <ummtfl$t4uo$1@dont-email.me>
Content-Language: en-US
Xref: news.eternal-september.org comp.lang.ada:65949
List-Id: <comp.lang.ada>

On 29.12.23 17:52, Dmitry A. Kazakov wrote:

>> Suppose that there is a way of orderly proceeding from one item to the next.
>> It is probably known to the implementation of map. Do single steps
>> guarantee transitivity, though, so that an algorithm can assume the
>> order to be invariable?
> 
> An insane implementation can expose random orders each time.

An implementation order should then not be exposed, right?
What portable benefits would there be when another interface
is added to that of map, i.e., to Ada containers for general use?
Would it not be possible to get these benefits using a different
approach? I think the use case is clearly stated:

First, find Cursors in map =: C*.
Right after that, Delete from map all nodes referred to by C*.


> Unless removing element invalidates all cursors. Look, insanity has no bounds. Cursors AKA pointers are as volatile as positions in certain implementations. Consider a garbage collector running after removing a pair and shuffling remaining pairs in memory.
> 
>> Maybe the bulk operations of some DBMS' programming
>> interfaces work just like this, for practical reasons.
>> Ada 202x' Ordered_Maps might want to add a feature ;-)
>>
>>       procedure Delete (Container : in out Map;
>>                         From      : in out Cursor;
>>                         To        : in out Cursor);
> 
> Here you assume that cursors are ordered and the order is preserved from call to call. Even if From and To are stable the range From..To can include random pairs in between.

Yes, given the descriptions of Ordered_Maps, so long as there is no
tampering, a Cursor will respect an order. Likely the one that the
programmer has in mind.

For deleting, this thread has shown a loop that calls Delete
multiple times right after collecting the cursors.
And it is boilerplate text.  Could Maps be improved for this use case?

[Bulk deletion] We do get bulk insertion in containers.  Also,
A.18.2 already has bulk Delete operations.  Similarly,
the Strings packages have them.
  
[No thread safety needed] If standard Ada maps are usually operated
by just one task, stability of Cursors is predictable.

Then, with or without automatic management of storage,
when My_Map is from an instance of Ordered_Map,

    Start  := In_13th_Floor (My_Map.Ceiling (13.0));
    Finish := In_13th_Floor (My_Map.Floor (Fxd'Pred (14.0)));
    My_Map.Delete (
       From    => Start,
       Through => Finish);

where
    function In_13th_Floor (C : Cursor) return Cursor
    --  C, if the key at C is in [13.0, 14.0), No_Element otherwise

should therefore do the right thing, in that nothing
is left to chance.