[erlang-questions] map elements in defined order

Ulf Wiger ulf@REDACTED
Fri Oct 27 15:42:30 CEST 2017

Sverker, I understand and agree with the reasons behind the implementation

I can expand a little on discussions I've been involved in:

We have a scenario where we need to serialize objects partly for network
comms, partly for storage and partly for signing and cryptographic hasing.
We also prefer the serialization to work easily across programming

The trouble is of course the signing/crypto-hashing. For this to be stable,
the order must be fixed. Obviously, adding a function that makes Erlang
maps appear ordered will not suffice, since other language environments
would either not expect maps to be ordered at all, or are likely to have a
different take on how keys are ordered*.

Better then to stick with the assumption that map key ordering is undefined.

Picking e.g. msgpack encoding as an example, a possible alternative would
be to use arrays of 1-element maps:

[#{K1 => V1, #{K2 => V2}, ...]

This is easy enough to decode and handle in e.g. JavaScript, and should be
stable enough to sign (using the msgpack-encoded representation as input to
the signing/hash function). The encoding overhead compared to using a
single map seems to be about one byte per key.

* For example, the Go implementation of msgpack has a function to make maps
appear ordered, but with its own idea of what key types can be sorted.

Ulf W

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).
> It has been discussed (more and less serious) to expose this
> "map-key-order" with operators like :<, :>, =:<, >:=.
> /Sverker
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20171027/dd804c74/attachment.htm>

More information about the erlang-questions mailing list