<div dir="ltr"><div class="gmail_extra"><div><div class="gmail_signature" data-smartmail="gmail_signature">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></div></div><div class="gmail_quote"><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></div></blockquote><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div text="#000000" bgcolor="#FFFFFF">
    It has been discussed (more and less serious) to expose this
    "map-key-order" with operators like :<, :>, =:<, >:=.</div></blockquote><div><br></div><div>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.</div><div><br></div><div>    /Richard</div><div><br></div></div></div></div>