[erlang-questions] maps iterator

[Theepan]

Fair enough..

But if size is a concern, shouldn't we look at a different data structure,
like gb_trees/ets?

Theepan

On Wed, Sep 30, 2015 at 4:36 AM, Robert Virding <rvirding@REDACTED> wrote:

> Seeing we are wishing here I would like a function which when you call it
> with a key returns the next key in the map. This so I can step through the
> map one key at a time.
>
> M = #{a => 1, b => 2, e => 5}.
> maps:first_key(M) ==> a
> maps:next(M, a) ==> {b,2}
> maps:next(M, b) ==> {e,5}
>
> The order is irrelevant. I think the next function might as well return
> the next key and its value seeing there is no copying and very little extra
> work and you are probably going to get the value anyway. Yes, I know I can
> get a list of all the keys but then I need to keep the list somewhere and
> if it is a big map (which is now feasible) then creating a big list seems a
> waste.
>
> Without this I can't use maps in a place where they would really fit, in
> luerl my Lua implementation.
>
> Robert
>
>
> On 29 September 2015 at 10:36, Sergej Jurečko <sergej.jurecko@REDACTED>
> wrote:
>
>> Oh ok. I was under the impression maps have sorted keys.
>>
>>
>> Sergej
>>
>> On Tue, Sep 29, 2015 at 10:32 AM, zxq9 <zxq9@REDACTED> wrote:
>>
>>> On Tuesday 29 September 2015 10:12:55 Sergej Jurečko wrote:
>>> > Something like gb_trees:iterator_from
>>> > If you're traversing the entire map then to_list is fine (which
>>> fold,map
>>> > use). But if you wish to only traverse a subset of k/v pairs in a
>>> large map
>>> > it is quite wasteful.
>>>
>>> Map keys are unordered. GB tree keys are ordered.
>>>
>>> If you are using maps then something like iterator_from already does not
>>> fit. But maybe you have some subset of keys you want to traverse? That is
>>> what maps:with/2 and maps:without/2 are for. (I have no idea how efficient
>>> with/2 or without/2 are in gigantic maps in R18 -- but I imagine these are
>>> the functions that will be optimized to death eventually if anything is, so
>>> it is what I would write code against today. Unless you actually do just
>>> need gb_trees...)
>>>
>>> In some cases having maps:partition/2 would be nice, but there are no
>>> cases I can think of where an equivalent to iterator_from makes sense
>>> without either requiring a filter over the entire map's values to figure
>>> out what subset you want, or already having a sublist of keys you want to
>>> include or exclude from your traversal.
>>>
>>> What am I missing?
>>>
>>> -Craig
>>> _______________________________________________
>>> erlang-questions mailing list
>>> erlang-questions@REDACTED
>>> http://erlang.org/mailman/listinfo/erlang-questions
>>>
>>
>>
>> _______________________________________________
>> erlang-questions mailing list
>> erlang-questions@REDACTED
>> http://erlang.org/mailman/listinfo/erlang-questions
>>
>>
>
> _______________________________________________
> 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/20150930/cdc14353/attachment.htm>