[erlang-questions] map elements in defined order
Richard Carlsson
carlsson.richard@REDACTED
Fri Oct 27 16:39:08 CEST 2017
2017-10-27 15:26 GMT+02:00 Sverker Eriksson <sverker.eriksson@REDACTED>:
> Yes. All Erlang terms, including maps, have a globally defined,
> implementation independent, total order.
> The reason, for this "surprising" order of maps, is the alternative of
> using the normal arithmetic order for keys is much worse.
>
> If we want 1 and 1.0 to be different keys (which we do as we use matching
> (=:=) to lookup keys)
> then we need to order 1 and 1.0, and normal arithmetic term ordering does
> not (1 == 1.0).
>
Yes... but I'm not sure that the term order when comparing one map to
another needs to have anything to do with how lookup works within maps
(much like it doesn't in an orddict, gb_trees, or similar). The global term
order only needs to be fixed and preferably straightforward. I could, for
example, implement maps using the sort of tuple I showed: {K1, ..., Kn, V1,
..., Vn}, and they would have one order given by '>', but using #{K1=>V1,
... Kn=>Vn}, they would be ordered differently if keys were floats. I think
that key order as used internally by the maps could and should be kept
separate from the global term order.
> It has been discussed (more and less serious) to expose this
> "map-key-order" with operators like :<, :>, =:<, >:=.
>
And as I recall, that was suggested even before maps were a thing, since it
would occasionally be useful also for things like lists of key/value tuples
where the keys may be floats.
/Richard
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20171027/265f7212/attachment.htm>
More information about the erlang-questions
mailing list