<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>I doubt that anyone would abuse an extra function that produces the map element pairs in the internally defined sort order, given that the documentation would clearly state that it's more expensive than maps:to_list/1 (though likely faster than lists:sort(maps:to_list(M), fun custom_sort_fun/2) - not to mention less error-prone.)</div><div><br></div><div>But it's not a feature I'm willing to go to war over. If no one else sees a use for it, I'm willing to concede that it has low priority. :)</div><div><br></div><div>BR,</div><div>Ulf W</div></div><div class="gmail_extra"><br><div class="gmail_quote">2017-10-26 20:31 GMT+02:00 Jesper Louis Andersen <span dir="ltr"><<a href="mailto:jesper.louis.andersen@gmail.com" target="_blank">jesper.louis.andersen@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">It is generally a bad idea to rely on order in anything which uses a hash function. The hash function is often subject to change---rather quickly I might add if it proves to be a security bug. Picking a family of hashes and seeding it randomly is usually a good trick.<div><br></div><div>Our "sister language" Go *randomizes* iteration order on its maps. This is to force programmers into not relying on the map order at all, even if it happens to be ordered right now. This opens up implementations in the future.</div><div><br></div><div>If you wanted order in a map, it would be *far* better if you could create a map based on RB-trees or the like. Those are naturally ordered by structure. OCaml, for instance, defines Hash Tables as well as Maps. The latter is the ordered variant.</div><div><br></div></div><br><div class="gmail_quote"><div><div class="h5"><div dir="ltr">On Thu, Oct 26, 2017 at 8:07 PM Ulf Wiger <<a href="mailto:ulf@wiger.net" target="_blank">ulf@wiger.net</a>> wrote:<br></div></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5"><div dir="auto"><div>But they *are* ordered. Otherwise, comparison of two maps would be undefined. </div><div dir="auto"><br></div><div dir="auto">BR, </div><div dir="auto">Ulf W</div></div><div dir="auto"><div dir="auto"><br><div class="gmail_extra" dir="auto"><br><div class="gmail_quote">Den 26 okt. 2017 18:20 skrev "Roger Lipscombe" <<a href="mailto:roger@differentpla.net" target="_blank">roger@differentpla.net</a>>:<br type="attribution"><blockquote class="m_3333576130270394918m_-8746558959939451565quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="m_3333576130270394918m_-8746558959939451565quoted-text">On 26 October 2017 at 16:30, Ulf Wiger <<a href="mailto:ulf@wiger.net" target="_blank">ulf@wiger.net</a>> wrote:<br>
> Wouldn't it be reasonable to have such a function?<br>
<br>
</div>First thought: No, because people would start abusing it. Maps *aren't* ordered.<br>
</blockquote></div><br></div></div></div></div></div><span class="">
______________________________<wbr>_________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org" target="_blank">erlang-questions@erlang.org</a><br>
<a href="http://erlang.org/mailman/listinfo/erlang-questions" rel="noreferrer" target="_blank">http://erlang.org/mailman/<wbr>listinfo/erlang-questions</a><br>
</span></blockquote></div>
</blockquote></div><br></div>