[erlang-questions] Maps branch and disclaimers

[Björn-Egil Dahlberg]

2013/10/25 Fred Hebert <mononcqc@REDACTED>

> On 10/25, Björn-Egil Dahlberg wrote:
> >
> > Roughly,
> > M0 = #{ key => Value1, "key" => Value2}, % for construction.
> >   M1 = M1#{  "key" := Value3, <<"key">> => Value4 }, % for updates
> >   #{ "key" := V } = M1. % for matching
> >
>
> I assume you meant M2 = M1#... here?
>

Aww .. That's what I get for speeding through examples in mails.

Yep, I screwed up the variables in the example .. =)


> Value1 = a, Value2 = b, Value3 = c, Value4 = d.
d
> M0 = #{ key => Value1, "key" => Value2}.
#{key => a,"key" => b}
> M1 = M0#{  "key" := Value3, <<"key">> => Value4 }.
#{key => a,"key" => c,<<"key">> => d}
> #{ "key" := V } = M1, V.
c

That will work ..


>
>
> >
> > ...
> >
> > _The External Format_
> >
> > The current external format /needs/ ordered keys as input for
> > binary_to_term/1 and in distribution.
> >
> > This is of course an inconvinience when dealing with other language
> > interfaces which has no idea of what the erlang term order is. I
> > instead propose that the external format should handle unordered
> > input of key-value pairs. The trade off is a more complicated
> > decoding which will take longer.
> >
>
> Could there be a flag in there that will allow to specify whether the
> terms are ordered or not? It sounds to me like this could yield the
> lowest cost for languages that *do* support sorting in manners similar
> to Erlang (most notably, other Erlang nodes), while having very little
> overhead for talking with other languages (where most of the time will
> be spent unserializing anyway).
>
> The flag could be ignored by languages unserializing the terms that do
> not understand/need Erlang's ordering, too, or optimize accordingly.
>

Erlang nodes, and all other nodes capable, will handle this like what we
say below here (caching).
The capability detection would be part of the negotiation when connecting.


>
> > The distribution format should also be extended to be able cache
> > keys. This is similar to the atom cache except we
> > cache the entire key array for maps. This has been the intention all
> > along but it not mentioned in the EEP.
>
> Shall the EEP be extended?
>

Perhaps.

I think this should be extended later on. I will wait for more input.


>
> >
> > _Term order and sorting_
> >
> >
> > The Erlang term order is what I call arithmetic term order. I
> > propose that we extend Erlang with true term order where integer
> > compares less then float, i.e. total term order.
> >
> > ...
> >
> > But for completness, the following operators should also be implemented:
> >
> >     =:=         term exact equal to, already implemented
> >     =/=         term not equal to, already implemented
> >     =:<         term less or equal than
> >     >:=         term greater or equal than
> >     <:<         term less than
> >     >:>         term greater than
> >
>
> Hell yes! I've found this extremely annoying for a long while. I could
> see the use of this, and it could be done without breaking backwards
> compatibility, except in some rare cases where it could be perceived as
> somewhat inconsistent (orddicts come to mind, where they use the
> arithmetic term order internally, but still enforce the true term order
> for keys -- and I can't see this being fixed)
>

Yoy \o/

Hopefully it is an inconsistency we can live with. I certainly thinks so.


>
> For what it's worth, Prolog's operators are @<, @=<, @>, @>=. I think
> that I would prefer your form, but someone with more clout on the matter
> (such as ROK) would be better placed than me to voice an opinion on
> this.
>
> Regards,
> Fred.
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20131025/7232be93/attachment.htm>