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

[Robert Virding]

My maps:first/1 and maps:next/2will be coming when? :-)

Robert


On 20 April 2016 at 16:44, Björn-Egil Dahlberg XB <
bjorn-egil.xb.dahlberg@REDACTED> wrote:

> On 2016-04-20 16:38, Federico Carrone wrote:
>
> It would be awesome to have a a map iterator/map comprehension.
>
>
> Many are of the same opinion. However iterators are not in this scope.
> Only API additions to the maps module are.
> Efficient iterators are necessary to implement efficient generators for
> maps. Efficient maps comprehension is whole other ballgame.
>
> I will post a PR of maps:take/2 and maps:apply/3,4 later this week. I'm
> not sure about apply .. or it's name.
>
>
>
>
> On Tue, Apr 19, 2016 at 5:30 PM Robert Virding <rvirding@REDACTED> wrote:
>
>> I missed this thread, but Björn-Egil you know what I want. :-)
>>
>> maps:first(Map) -> {Key,Value} | error.
>> maps:next(Key, Map) -> {Key,Value} | error.
>>
>> Robert
>>
>>
>> On 13 April 2016 at 15:40, Björn-Egil Dahlberg XB <
>> <bjorn-egil.xb.dahlberg@REDACTED>bjorn-egil.xb.dahlberg@REDACTED>
>> wrote:
>>
>>> There is currently no (good) way to get out of C-context to execute some
>>> erlang snippet and then get back into c-context. Traps does this but only
>>> in a controlled manner. I think it is doable though.
>>>
>>> Your proposal of maps_apply/3 is the maps equivalent of dict:update/3
>>> and sadly that name is already occupied in maps (it's the equivalent of
>>> gb_trees).
>>>
>>> I think we should add it to the API without thinking about the
>>> performance too much. Performance can always be improved later on.
>>>
>>> Is maps:apply/3 the best name we can think of? I don't really trust you
>>> and naming things. =) update/3,4 would probably have been best but c'est la
>>> vie.
>>>
>>> // Björn-Egil
>>>
>>>
>>> On 2016-04-13 13:09, Jesper Louis Andersen wrote:
>>>
>>>
>>> On Fri, Apr 8, 2016 at 8:31 PM, Björn-Egil Dahlberg <
>>> wallentin.dahlberg@REDACTED> wrote:
>>>
>>>> Have you repeated some code or built your own private lib to handle
>>>> certain maps specific tasks and thought "why isn't this in the maps module?"
>>>
>>>
>>> One function I like to have is "apply update via function", and I
>>> implement it somewhat often:
>>>
>>> maps_apply(F, K, Map) ->
>>>     V = maps:get(K, Map),
>>>     maps:put(K, F(V), Map).
>>>
>>> But it can be made much faster in a direct implementation since I don't
>>> have to first pick up the value: I can apply F when I sit with the value at
>>> hand and thus avoid the "put" lookup path. It might, however, be nasty to
>>> implement because F is in Erlang-context, whereas the maps operations are
>>> in BIF-context.
>>>
>>>
>>> --
>>> J.
>>>
>>>
>>> _______________________________________________
>>> erlang-questions mailing listerlang-questions@REDACTED://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
>>
>
>
> _______________________________________________
> 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/20160422/aa73c6e8/attachment.htm>