<div dir="ltr">Actually, they ARE, in some ways.<div><br></div><div>I should have been clearer. I was, of course, referring to the uses of records where they were never optimal in the first place, but were tolerated e.g. because of the great convenience of referencing elements by name in pattern-matching.<br></div><div><br></div><div>Quoted from EEP-0043:</div><div><br></div><div>«The idea was a data-type, a syntax-aware mapping of key-value associations with pattern matching. A syntax similar to records but without the hassle of compile-time dependency and with arbitrary terms as keys. Order was not important and it could be implemented with a Hash-Array-Mapped-Trie with good performance and memory trade-offs. This was a different approach than to replace records. It was meant to replace records where suitable and in other regards not be a replacement but its own _thing_.»</div><div><br></div><div>Further, relevant to this discussion:</div><div><br></div><div>«A restriction set on the implementation by the Erlang specification is that order is total, i.e. satisfies _antisymmetry, transitivity and totality_.</div><div>...</div><div>- Ordered maps impose restrictions on the underlying implementation and a hashing approach will be nearly impossible.</div><div>- The underlying structure does not need to be sorted, an order could be produced when needed,»</div><div><br></div><div>The thing I tried to highlight was that "an order could be produced when needed" is actually a bit more involved than you'd think, given that no API function does it for you. At least if you want to reflect the internal sort order - given that the actual implementation is NOT as described in the EEP: "If a key or value differs, the order of the respective terms, in Erlang term order".</div><div><br></div><div>You'd have to write your own sort function, in which you visit all elements of complex structures, finding all instances of floats and ensuring that they get the right priority.</div><div><br></div><div>Or... you simply do this:</div><div><br></div><div>lists:sort(fun(A, B) -> #{A => 0} =< #{B => 0} end, maps:to_list(Map))</div><div><br></div><div><br></div><div>As evidenced e.g. by Benoit's comment above, I believe lots of people already rely on the order of map elements being IN SOME WAY stable. This is likely a brittle assumption, but one that may - in time - trap the OTP team into having to preserve the current APPARENT order.</div><div><br></div><div>And the apparent order does appear to be sorted, as long as only maps of size =< 32 ("flatmaps") are inspected. For larger maps ("hashmaps"), the order of elements returned by maps:to_list/1 indeed appears arbitrary.</div><div><br></div><div>BR,</div><div>Ulf W</div></div><div class="gmail_extra"><br><div class="gmail_quote">2017-10-27 6:01 GMT+02:00 zxq9 <span dir="ltr"><<a href="mailto:zxq9@zxq9.com" target="_blank">zxq9@zxq9.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 2017年10月26日 木曜日 21:13:07 Ulf Wiger wrote:<br>
> ... to use as a replacement for records.<br>
<br>
But they are IN NO WAY a replacement for records.<br>
<br>
-Craig<br>
<div class="HOEnZb"><div class="h5">______________________________<wbr>_________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org">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>
</div></div></blockquote></div><br></div>