<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Thu, Oct 26, 2017 at 9:13 PM Ulf Wiger <<a href="mailto:ulf@wiger.net">ulf@wiger.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">But again, Jesper, just about everyone relies on the fact that maps follow the general principle that there is a well-defined term comparison order. Otherwise, maps would be highly unsuitable to use in keys, and generally treacherous to use as a replacement for records. Following the Principle of Least Surprise, it's a darned good thing that Erlang doesn't randomize the key order in its maps.<div><br></div></div></blockquote><div><br></div><div>I largely regard a total term order as a language mistake. The right solution, obviously, is to have several equalities, where the programmer can define what they mean by equality in a certain part of the program. Equality is way too important in programming for you to be left with a single one!</div><div><br></div><div>That said, there is a well-defined order of maps currently, but it is not the logical one you might expect (which is by ordering the keys of the map). Rather the order is defined on</div><div><br></div><div>* What the key hashes to</div><div>* What the internal HAMT structure looks like right now</div><div><br></div><div>It is a total order even! So you can use maps as keys in a balanced search tree for instance.</div><div><br></div><div>However, your point does seem to touch on a couple of important things that should be considered for future inclusion:</div><div><br></div><div>* We may want to have an "ordered map" in the language. These are self-balancing binary trees. They are more costly in lookup time and they take up more memory space, but they have the "natural ordering" of keys which means they are well-defined in their traversal.</div><div><br></div><div>* Your "sext" library exists to plug yet another hole in the language, namely that binary_to_term have certain freedoms with certain data structures and this leads to situations where you cannot rely on the binary output for, e.g., cryptographic applications.</div><div><br></div><div>In short, one has to weigh different implementation details when building data structures. If you want to have it all, your efficiency eventually has to give.</div></div></div>