<div dir="ltr">Sverker, I understand and agree with the reasons behind the implementation decision.<div><br></div><div>I can expand a little on discussions I've been involved in:</div><div><br></div><div>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.</div><div><br></div><div>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*.</div><div><br></div><div>Better then to stick with the assumption that map key ordering is undefined.</div><div><br></div><div>Picking e.g. msgpack encoding as an example, a possible alternative would be to use arrays of 1-element maps:</div><div><br></div><div>[#{K1 => V1, #{K2 => V2}, ...]</div><div><br></div><div>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.</div><div><br></div><div>* 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.</div><div><br></div><div>BR,</div><div>Ulf W<br><div class="gmail_extra"><br><div class="gmail_quote">2017-10-27 15:26 GMT+02:00 Sverker Eriksson <span dir="ltr"><<a href="mailto:sverker.eriksson@ericsson.com" target="_blank">sverker.eriksson@ericsson.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
  
    
  
  <div text="#000000" bgcolor="#FFFFFF">
    <p>Yes. All Erlang terms, including maps, have a globally defined,
      implementation independent, total order.<br>
    </p>
    The reason, for this "surprising" order of maps, is the alternative
    of using the normal arithmetic order for keys is much worse.<br>
    <br>
    If we want 1 and 1.0 to be different keys (which we do as we use
    matching (=:=) to lookup keys)<br>
    then we need to order 1 and 1.0, and normal arithmetic term ordering
    does not (1 == 1.0).<br>
    <br>
    <br>
    It has been discussed (more and less serious) to expose this
    "map-key-order" with operators like :<, :>, =:<, >:=.<span class="HOEnZb"><font color="#888888"><br>
    <br>
    <br>
    /Sverker</font></span><div><div class="h5"><br></div></div></div></blockquote></div></div></div></div>