[erlang-questions] map elements in defined order

[Ulf Wiger]

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

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
languages.

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.

BR,
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>