help / color / mirror / Atom feed
From: "Dmitry A. Kazakov" <>
Subject: Re: Map iteration and modification
Date: Fri, 29 Dec 2023 10:51:33 +0100	[thread overview]
Message-ID: <umm4r5$ppag$> (raw)
In-Reply-To: <umldsq$na79$>

On 2023-12-29 04:20, Randy Brukardt wrote:
> "Dmitry A. Kazakov" <> wrote in message
> news:umk6ds$e9hc$
> ...
>> Provided a sane implementation of map.
>> 1. It is safe to loop over the map items in the *reverse* order of,
>> deleting whatever items.
> A sane implementation of a map does not have/require an ordering of keys.

Yes, but iterating a map requires ordering regardless properties of the 

> So
> the idea of "reverse" or "forward" does not make sense for a general map.
> (There are, of course, special cases where the keys have an order that
> matters to the map; the standard ordered map is like that.) Assuming an
> ordering is exposing the implementation unnecessarily.

It always does sense *IF* enumeration (needed for iteration) is 
provided. Enumeration of pairs (<key>, <value>) is not same as ordering 
values by the keys.

> You always complain about mixing implementation with interface, but you are
> clearly doing that here. That technique really only works if the data
> structure is implemented with an underlying array. If you have separately
> allocated nodes, deletion might completely destroy a node that the iterator
> is holding onto. Avoiding that takes significant efforts that sap
> performance when you don't intend to modify the container you're iterating
> (which is the usual case).

No. First, it is two different interfaces. A view of a map as:

1. An ordered set of pairs (<key>, <value>)

2. A mapping <key> -> <value>

Second, the point is that both are array interfaces. The first has 
position as the index, the second has the key as the index.

Both are invariant to removal a pair and any *sane* implementation must 
be OK with that.

The problem is not whether you allocate pairs individually or not. The 
insanity begins with things unrelated to the map:

1. OOP iterator object.

2. FP iteration function.

Both are bad ideas imposed by poor programming paradigms on 
implementation of a clear mathematical concept. That comes with 
constraints, assumptions and limitation array interface do not have.

    for Index in reverse Map'Range loop
       Map.Delete (Index);
    end loop;

would always work. OOP/FP anti-patterns, who knows?

> My longstanding objection to the entire concept of arrays is that they are
> not a data structure, but rather a building block for making data
> structures.

Arrays have interface and implementation. The array interface is a 
mapping key -> value, the most fundamental thing in programming. An 
array implementation as a contiguous block of values indexed by a linear 
function is a basic data structure that supports the interface.

> One wants indexed sequences sometimes, cheap maps othertimes,
> but arrays have all of the operations needed for both, along with other
> capabilities not really related to data structures at all.

Let me help (:-))

    One wants array interface without a built-in array implementation.

> It's way better
> to declare what you need and get no more (visibly, at least). That makes it
> way easier to swap implementations if that becomes necessary - you're not
> stuck with a large array that really should be managed piecemeal.

Sure. The problem with Ada is that it does not separate array interface 
from its built-in array implementation and does not separate record 
interface and implementation either.

Both are mappings. BTW in many cases people could prefer record 
interface of a map to array interface:


instead of

    Map (Key)

Now, tell me that you have a longstanding objection to the entire 
concept of records... (:-))

Dmitry A. Kazakov

  reply	other threads:[~2023-12-29  9:51 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-12-28 13:53 Map iteration and modification DrPi
2023-12-28 13:59 ` DrPi
2023-12-28 16:06   ` Dmitry A. Kazakov
2023-12-28 17:57     ` DrPi
2023-12-29  3:20     ` Randy Brukardt
2023-12-29  9:51       ` Dmitry A. Kazakov [this message]
2023-12-29 15:03         ` G.B.
2023-12-29 16:52           ` Dmitry A. Kazakov
2024-01-01 19:27             ` G.B.
2024-01-01 20:55               ` Dmitry A. Kazakov
2024-01-02 16:40                 ` G.B.
2024-01-02 20:57                   ` Dmitry A. Kazakov
2024-01-03  3:22                 ` Randy Brukardt
2024-01-03  4:05                   ` moi
2023-12-30  7:21         ` Randy Brukardt
2023-12-30 11:07           ` Dmitry A. Kazakov
2024-01-03  3:15             ` Randy Brukardt
2024-01-03 10:04               ` Dmitry A. Kazakov
2024-01-04  4:07                 ` Randy Brukardt
2024-01-04 11:28                   ` Dmitry A. Kazakov
2024-01-05  2:00                     ` Randy Brukardt
2024-01-05  9:26                       ` Simon Wright
2024-01-05 11:51                       ` Dmitry A. Kazakov
2024-01-06  7:25                         ` Randy Brukardt
2024-01-07 15:06                           ` Jeffrey R.Carter
2024-01-09  4:46                             ` Randy Brukardt
2024-01-09  5:56                               ` when-clauses (was Re: Map iteration and modification) Lawrence D'Oliveiro
2024-01-09  9:43                               ` Map iteration and modification Jeffrey R.Carter
2024-04-17 10:12                         ` Cóilín Nioclás Pól Glostéir
2024-01-06  2:54                       ` “Usability” (was Re: Map iteration and modification) Lawrence D'Oliveiro
2024-01-06  7:03                         ` "Usability" " Randy Brukardt
2024-01-06  8:14                           ` Niklas Holsti
2024-01-06 23:41                           ` Lawrence D'Oliveiro
2024-01-07  1:21                           ` J-P. Rosen
2024-01-09 15:19                             ` Bill Findlay
2024-01-09 20:30                             ` Lawrence D'Oliveiro
2023-12-29  3:08   ` Map iteration and modification Randy Brukardt
2023-12-29 13:53     ` DrPi
2023-12-30  6:29       ` Randy Brukardt
2023-12-31 13:56         ` DrPi
replies disabled

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox