[erlang-questions] Wanted additions to the maps module?

[Robert Virding]

OK, I am the one who asked for first/next so this is my use case.

As Lukas mentioned I need this to implement Lua tables in Erlang using maps.

I need to be able to iterate over a map one key/value pair at a time. For
me the order is completely irrelevant as along as if I do a sequence of
first-next-next-... using the previous key in the next next I am guaranteed
to *uniquely* get *all* the keys in the map. If I modify the map and try to
continue from where I was then all bets are of and there are no guarantees
any more that I will get all keys or that they will be unique.

Lua has exactly this interface to its tables so I need to be able to do it
as well. Not having it is not an option. So while having maps or folds over
a map is great there is no way these can be used to implement what I need
efficiently. That's it.

Now I use a private 2-3 trees implementation of dict with the added
functions and it works well. But using maps would seem logical and more
efficient.

That's about it.

Robert


On 9 May 2016 at 16:54, Fred Hebert <mononcqc@REDACTED> wrote:

> On 05/09, zxq9 wrote:
>
>> On Monday 09 May 2016 15:22:17 Lukas Larsson wrote:
>>
>>> On Mon, May 9, 2016 at 2:54 PM, zxq9 <zxq9@REDACTED> wrote:
>>>
>>> >
>>> > That's my whole point. Why the desire for a next/1 and previous/1
>>> > instead of a list-style operation over the map as a whole, since
>>> > outside of an abstract sense of "doing something with each element"
>>> > there is nothing interesting that can possibly be gained from
>>> > introducing an implicit concept of order?
>>> >
>>>
>>
>> Sure, internally I imagine there are a million super slick ways to use
>> this,
>> and I lack the imagination to see what they may be.
>>
>>
> - partial iteration to look for an element
> - partial iteration to only modify a subrange of the whole map; for
> example, re-hashing a window of N components. If your map has 10  million
> items and you want to re-hash 25 of them, then going over the  whole map
> every time is going to eat you up on the computation (this  one is more
> useful with a total stable order defined)
> - implementing your own map/fold/filter combination as a single pass
>  without needing to iterate and convert the whole map at once
> - ability to do lookahead/look-behind in an iteration to arbitrary  levels
> without implementing your own ad-hoc zipper or buffering all of  the
> content you have seen
>
> Those are a few I have in mind can be doable that way -- I've mostly seen
> them at work or wanted them for ETS tables, but I'm sure someone could
> twist a map into having the same requirements.
>
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20160509/2ecbd4dd/attachment.htm>