[erlang-questions] map elements in defined order

[Sverker Eriksson]

On 10/27/2017 04:39 PM, Richard Carlsson wrote:
> 2017-10-27 15:26 GMT+02:00 Sverker Eriksson 
> <sverker.eriksson@REDACTED <mailto:sverker.eriksson@REDACTED>>:
>
>     Yes. All Erlang terms, including maps, have a globally defined,
>     implementation independent, total order.
>
>     The reason, for this "surprising" order of maps, is the
>     alternative of using the normal arithmetic order for keys is much
>     worse.
>
>     If we want 1 and 1.0 to be different keys (which we do as we use
>     matching (=:=) to lookup keys)
>     then we need to order 1 and 1.0, and normal arithmetic term
>     ordering does not (1 == 1.0).
>
>
> 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.
>

orddict and gb_trees both use '==' to distinguish keys, which makes it 
possible to order them with '>'.

How would you order  #{1 => x, 1.0 => y} and #{1 => y, 1.0 => x}
if you can't order 1 and 1.0?



/Sverker

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20171027/bbb507cd/attachment.htm>