[erlang-questions] map elements in defined order

zxq9 zxq9@REDACTED
Fri Oct 27 12:56:36 CEST 2017


On 2017年10月27日 金曜日 10:38:46 Attila Rajmund Nohl wrote:
> 2017-10-27 9:25 GMT+02:00 Ulf Wiger <ulf@REDACTED>:
> [...]
> > 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.
> >
> > 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.
> 
> I already run into a bug where the code expected the map to be sorted.
> When the 33rd element was added, it started to show pathological
> behavior.

...and this means there is a bug in the calling code, NOT in maps (which I'm pretty sure is the point Attila is pointing out).

I can't believe we are having this discussion. Again.

Having a discussion about internal ordering in the context of efficient matches and comparisons *in implementation*: totally logical

Relying on that implementation detail to leak out: ridiculous


If we really want ordered maps we should make ordered maps. And highlight in big bold letters all the baggage that brings with it. Alternately, we already have other data structures that work this way, perhaps they could be utilized. I think people just really really wish they could add wazoo syntax to various tree structures... ugh.

This discussion comes up a little more frequently than once a year and every time it reminds me of watching distributed systems engineers (try desperately to) explain CAP theorem tradeoffs to a VP of marketing.

-Craig



More information about the erlang-questions mailing list