[erlang-bugs] Maps equality failure / Maps merge failure

[Ulf Wiger]

> On 25 Mar 2015, at 16:55, Kostis Sagonas <kostis@REDACTED> wrote:
> 
> Not familiar with 'sext' encoding, but I am not sure I get the details in the problem you run into...  For once, I do not see any use of lists:sort/1 here.  Is it buried in the comp*/2 functions somehow?  Does comp/2 use arithmetic rather than term comparison ?

Ah, forgive me for being so terse.

Sext is short for Sortable External Term format (a name picked before I heard of sexting). The library serializes Erlang terms in a way that preserves the original sort order.

https://github.com/uwiger/sext

> Or can it simply be that the reason the "intuitive" property cannot be used is because you have used ==/2 instead of =:=/2 there?

The intuitive property is that encoding and then decoding any Erlang term should give the same term back*.

It’s obviously difficult to support this and still preserve the notion that e.g. 1.0 and 1 are indistinguishable when sorting, so in the sext properties, I have to distinguish between floats and ints in the comparison and basically make them compare in a way that makes sense for my particular problem. 

An intuitive sort property could have been that for any list L,  if L1 = [{X, sext:encode(X)} || X <- L], then lists:keysort(1, L1) =:= lists:keysort(2, L1).

The lists:sort/1 function suffers form using the standard comparison operators, <, >, =<, >= and ==. OTOH, there are no strict comparison operators for anything but equality.

BR,
Ulf W

* Yes, floats are problematic in themselves here. In the test suite, I ‘normalize’ the floats using the bit syntax, which seems to work for now. But that property of floats is undocumented, possibly even unintentional.

Ulf Wiger, Co-founder & Developer Advocate, Feuerlabs Inc.
http://feuerlabs.com