[erlang-questions] map elements in defined order

[Sverker Eriksson]

A clear statement of lack of guarantee makes sense.
A 'canonical' option could make sense.
That would require N*log(N) sorting to get map keys in canonical order 
(deja vu).

About VM instance and version; I don't see the big divide there.
Would it not be treacherous to base an application design
on term_to_binary being a pure function among VM instances
as long as you don't upgrade them.


/Sverker

On 10/30/2017 01:16 AM, Richard A. O'Keefe wrote:
>
>
> On 28/10/17 2:34 AM, Sverker Eriksson wrote:
> [term_to_binary/1 is not a pure function; it
> depends on the representation of its argument,
> not just its value].
>
> OUCH.
>
> For term_to_binary/2, of course the result
> depends on the Options argument, but I take
> it now that even being explicit about the
> Options is not enough.  Can we have a
> 'canonical' option?
>
>>
>> And in the case where M1 and M2 were created by different VM instances,
>> you can with current implementation get different binaries.
>
> I can live with different *versions* of the VM using different
> versions of the binary term format, but two instances of the *same*
> VM turning mathematically identical terms into different binaries
> is, well, did Nyarlathotep, the Crawling Chaos, have a hand in the
> design?  In all seriousness, *OUCH*.  Please mention this in LARGE
> red letters in the documentation for term_to_binary; I don't see it
> at the moment, but it puts limits on what you can reasonably do
> with terms-as-binaries.
>
>
>