[erlang-questions] map elements in defined order
Richard Carlsson
carlsson.richard@REDACTED
Fri Oct 27 23:10:22 CEST 2017
2017-10-27 22:25 GMT+02:00 Stanislaw Klekot <erlang.org@REDACTED>:
> On Fri, Oct 27, 2017 at 09:36:58PM +0200, Richard Carlsson wrote:
> > 2017-10-27 17:45 GMT+02:00 Sverker Eriksson <
> sverker.eriksson@REDACTED>
> > >
> > > How would you order #{1 => x, 1.0 => y} and #{1 => y, 1.0 => x}
> > > if you can't order 1 and 1.0?
> >
> > As long as we're talking about the arithmetic term order (<, >, ==), I
> > don't see why they would need to be. Look at tuples:
> >
> > {1, 1.0} < {1.0, 1}.
> > false
> > {1, 1.0} > {1.0, 1}.
> > false
> > {1, 1.0} == {1.0, 1}.
> > true
> > {1, 1.0} =:= {1.0, 1}.
> > false
> >
> > Maps ought to behave analogously, in the arithmetic ordering.
>
> The problem is, the tuples you provide and comparison operators (<, >,
> =<, >=, and == (not =:= one)) form a well-defined partial order (total
> order, actually); mainly, if A =< B and B =< A, then A == B. Being
> a partial order is a very important property of Erlang's type system,
> one that was quite explicitly baked in the VM and is used in many
> different places.
No, the real problem, that I begin to see now, is that if arithmetic
ordering is used, two keys could appear to be the same, and if their
corresponding values differ, it is not clear in which order to compare
them. I guess that's what Sverker was trying to convey, but I missed it at
first.
So, using tuples {K1, ... Kn, V1, ... Vn} again for comparison, Sverker's
example could become either:
{1, 1.0, x, y} < {1, 1.0, y, x}
or
{1.0, 1, y, x} == {1, 1.0, y, x}
(switching the order of the keys in the left tuple), both of which would be
equally "legal" since 1 == 1.0. But this switches the order of x and y, so
that the comparisons of the maps would give different results. One way to
avoid this situation would be to say that you can't have two keys that
compare equal with == in the same map, just as for an orddict.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20171027/5939e4c7/attachment.htm>
More information about the erlang-questions
mailing list