[erlang-questions] Maps branch and disclaimers

Robert Virding robert.virding@REDACTED
Wed Oct 30 16:48:33 CET 2013

----- Original Message -----

> From: "Chris King" <colanderman@REDACTED>

> On Wed, 30 Oct 2013 08:40:44 -0400, Robert Virding
> <robert.virding@REDACTED> wrote:

> > - I need functions:

> > first(Map) -> {Key,Value} | error.
> > last(Map) -> {Key,Value} | error.
> > next(Key, Map) -> {Key1,Value} | error.
> > prev(Key, Map) -> {Key1,Value} | error.

> > for stepping through maps. Have them return both key and value in one go as
> > it saves an explicit fetch and the extra cost is minimal.

> I don't get this use case. Why do you need syntax support for a key-value map
> where you don't know a priori what the keys and values are? Why don't dict()
> and friends suffice?

> To me this is akin to iterating through a record/tuple.

I need this ability to step through a map/dict/whatever in an application I am working on (luerl). Dict does not provide this type of functionality. It would be easy to hack into an orddict but I don't want to use lists. Gb_trees provides an iterators but they are quite limited in that they only allow you to step through the whole tree from beginning to end; you can't jump in in the middle. Which I need to be able to do. 

I solved this by writing my own dict compatible module, ttdict, based on 2-3 trees where I added these 4 extra functions. Ttdict was quite good and provided dict API on ordered keys which is faster than gb_trees. I had planned to add it to the libraries but with maps the need for it has more or less disappeared. I think. 

My idea was that now maps are coming I could replace ttdict with maps, not for functionality but for speed. Hence the request for the extra functions. I am assuming that doing it in C will be faster than doing it in Erlang. 

What would be interesting to see is how much faster you could get a dict replacement which uses hashing and doesn't give key ordering. 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20131030/a7a10ed5/attachment.htm>

More information about the erlang-questions mailing list