<div dir="ltr">2013/10/25 Fred Hebert <span dir="ltr"><<a href="mailto:mononcqc@ferd.ca" target="_blank">mononcqc@ferd.ca</a>></span><br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div class="im">On 10/25, Björn-Egil Dahlberg wrote:<br>
><br>
> Roughly,<br>
> M0 = #{ key => Value1, "key" => Value2}, % for construction.<br>
> M1 = M1#{ "key" := Value3, <<"key">> => Value4 }, % for updates<br>
> #{ "key" := V } = M1. % for matching<br>
><br>
<br>
</div>I assume you meant M2 = M1#... here?<br></blockquote><div><br></div><div>Aww .. That's what I get for speeding through examples in mails.</div><div><br></div><div>Yep, I screwed up the variables in the example .. =)</div>
<div><span style="color:rgb(80,0,80)"><br></span></div><div><span style="color:rgb(80,0,80)"><br></span></div><div><span style="color:rgb(80,0,80)">> Value1 = a, Value2 = b, Value3 = c, Value4 = d.</span></div><div><span style="color:rgb(80,0,80)">d</span></div>
<div><span style="color:rgb(80,0,80)">> </span><span style="color:rgb(80,0,80)">M0 = #{ key => Value1, "key" => Value2}.</span></div><div><font color="#500050">#{key => a,"key" => b}</font><br>
</div><div><span style="color:rgb(80,0,80)">> M1 = M0#{ "key" := Value3, <<"key">> => Value4 }.</span></div><div><font color="#500050">#{key => a,"key" => c,<<"key">> => d}</font><br>
</div><div><span style="color:rgb(80,0,80)">> #{ "key" := V } = M1, V.</span></div><div>c<br style="color:rgb(80,0,80)"><br></div><div>That will work .. </div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
<br>
><br>
> ...<br>
><br>
> _The External Format_<br>
><br>
> The current external format /needs/ ordered keys as input for<br>
<div class="im">> binary_to_term/1 and in distribution.<br>
><br>
> This is of course an inconvinience when dealing with other language<br>
> interfaces which has no idea of what the erlang term order is. I<br>
> instead propose that the external format should handle unordered<br>
> input of key-value pairs. The trade off is a more complicated<br>
> decoding which will take longer.<br>
><br>
<br>
</div>Could there be a flag in there that will allow to specify whether the<br>
terms are ordered or not? It sounds to me like this could yield the<br>
lowest cost for languages that *do* support sorting in manners similar<br>
to Erlang (most notably, other Erlang nodes), while having very little<br>
overhead for talking with other languages (where most of the time will<br>
be spent unserializing anyway).<br>
<br>
The flag could be ignored by languages unserializing the terms that do<br>
not understand/need Erlang's ordering, too, or optimize accordingly.<br></blockquote><div><br></div><div>Erlang nodes, and all other nodes capable, will handle this like what we say below here (caching). </div><div>The capability detection would be part of the negotiation when connecting.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div class="im"><br>
> The distribution format should also be extended to be able cache<br>
> keys. This is similar to the atom cache except we<br>
> cache the entire key array for maps. This has been the intention all<br>
> along but it not mentioned in the EEP.<br>
<br>
</div>Shall the EEP be extended?<br></blockquote><div><br></div><div>Perhaps.</div><div><br></div><div>I think this should be extended later on. I will wait for more input.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
><br>
> _Term order and sorting_<br>
<div class="im">><br>
><br>
> The Erlang term order is what I call arithmetic term order. I<br>
> propose that we extend Erlang with true term order where integer<br>
> compares less then float, i.e. total term order.<br>
><br>
</div>> ...<br>
<div class="im">><br>
> But for completness, the following operators should also be implemented:<br>
><br>
> =:= term exact equal to, already implemented<br>
> =/= term not equal to, already implemented<br>
> =:< term less or equal than<br>
> >:= term greater or equal than<br>
> <:< term less than<br>
> >:> term greater than<br>
><br>
<br>
</div>Hell yes! I've found this extremely annoying for a long while. I could<br>
see the use of this, and it could be done without breaking backwards<br>
compatibility, except in some rare cases where it could be perceived as<br>
somewhat inconsistent (orddicts come to mind, where they use the<br>
arithmetic term order internally, but still enforce the true term order<br>
for keys -- and I can't see this being fixed)<br></blockquote><div><br></div><div>Yoy \o/</div><div><br></div><div>Hopefully it is an inconsistency we can live with. I certainly thinks so.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
For what it's worth, Prolog's operators are @<, @=<, @>, @>=. I think<br>
that I would prefer your form, but someone with more clout on the matter<br>
(such as ROK) would be better placed than me to voice an opinion on<br>
this.<br>
<br>
Regards,<br>
Fred.<br>
<div class=""><div class="h5">_______________________________________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a><br>
<a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
</div></div></blockquote></div><br></div></div>