<!DOCTYPE html>
<html>
<head>
<title></title>
</head>
<body><div>This is great! And fun. Waiting so long to play with these I had to make a branch of jsx using maps for objects today: <a href="https://github.com/tsloughter/jsx/tree/maps">https://github.com/tsloughter/jsx/tree/maps</a><br></div>
<div> </div>
<div id="sig19305637"><div class="signature">-- </div>
<div class="signature"> Tristan Sloughter</div>
<div class="signature"> tristan.sloughter@gmail.com</div>
<div class="signature"> </div>
</div>
<div> </div>
<div> </div>
<div>On Fri, Oct 25, 2013, at 07:22 PM, Daniel Goertzen wrote:<br></div>
<blockquote type="cite"><div dir="ltr"><div>Works like a charm!<br></div>
<div> </div>
<div>Yamler (Erlang yaml file loader) now constructs yaml mappings as erlang maps. I updated the README examples to show these maps in action:<br></div>
<div> </div>
<div><a href="https://github.com/goertzenator/yamler/tree/mapping_as_map">https://github.com/goertzenator/yamler/tree/mapping_as_map</a><br></div>
<div> </div>
<div> </div>
<div>Thanks for maps!<br></div>
<div>Dan.<br></div>
</div>
<div><div> </div>
<div> </div>
<div><div>On Fri, Oct 25, 2013 at 11:37 AM, Björn-Egil Dahlberg <span dir="ltr"><<a href="mailto:egil@erlang.org" target="_blank">egil@erlang.org</a>></span> wrote:<br></div>
<div> </div>
<blockquote style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF">
Hi!<br></div>
<div bgcolor="#FFFFFF"> </div>
<div bgcolor="#FFFFFF">
Here you go, Maps!<br></div>
<div bgcolor="#FFFFFF"> </div>
<div bgcolor="#FFFFFF">
I've pushed a Maps branch to Erlang/OTPs repository at GitHub.<br></div>
<div bgcolor="#FFFFFF"> </div>
<div bgcolor="#FFFFFF">
To get the branch,<br></div>
<div bgcolor="#FFFFFF"> </div>
<div bgcolor="#FFFFFF">
<span style="font-family:menlo,consolas,"courier new",monospace" class="font"> git fetch <a href="mailto:git@github.com:erlang/otp.git" target="_blank">git@github.com:erlang/otp.git</a>
egil/maps/eep-implementation</span><br></div>
<div bgcolor="#FFFFFF"> </div>
<div bgcolor="#FFFFFF">
or find it at
<a href="https://github.com/erlang/otp/tree/egil/maps/eep-implementation" target="_blank">https://github.com/erlang/otp/tree/egil/maps/eep-implementation</a><br></div>
<div bgcolor="#FFFFFF"> </div>
<div bgcolor="#FFFFFF">
I want to state the following so there is no room for uncertainty:<br></div>
<div bgcolor="#FFFFFF">
- This branch contains a <b>development stage</b> of the <b>experimental</b>
Maps feature for Erlang.<br></div>
<div bgcolor="#FFFFFF"> </div>
<div bgcolor="#FFFFFF">
This means:<br></div>
<div bgcolor="#FFFFFF">
- Do not use it in production since it is not stable,<br></div>
<div bgcolor="#FFFFFF">
- Do not base any git branch on this branch since it will most
likely be rebased,<br></div>
<div bgcolor="#FFFFFF">
- and finally, we reserve the right to change any API or interfaces
to Maps currently implemented.<br></div>
<div bgcolor="#FFFFFF"> </div>
<div bgcolor="#FFFFFF">
The implementation is based on EEP 43 - Maps, see
<a href="http://github.com/erlang/eep/blob/master/eeps/eep-0043.md" target="_blank">http://github.com/erlang/eep/blob/master/eeps/eep-0043.md</a>, for
details.<br></div>
<div bgcolor="#FFFFFF"> </div>
<div bgcolor="#FFFFFF">
<u>What is implemented?</u><br></div>
<div bgcolor="#FFFFFF"> </div>
<div bgcolor="#FFFFFF">
The maps module API and erlang guard BIFs as defined in the EEP are
implemented. There are however some sematic mismatches with the EEP.
I think those are where the definition contradict itself. For
instance maps:is_key/1 compares with =:= as stated first in the
definition but the later example uses lists:keymember which compares
with ==.<br></div>
<div bgcolor="#FFFFFF"> </div>
<div bgcolor="#FFFFFF">
The syntax and all what that entails is implemented. The compiler
will handle the map syntax and produce loadable beam-code. I believe
this is what people want to test and is what I want people to test.
Test the usability that is.<br></div>
<div bgcolor="#FFFFFF"> </div>
<div bgcolor="#FFFFFF">
I recommend people look at the EEP for information and also the
testsuite located at <span style="font-family:menlo,consolas,"courier new",monospace" class="font">erts/emulator/test/map_SUITE.erl</span> for
information on how to use Maps since no other documentation is
available.<br></div>
<div bgcolor="#FFFFFF"> </div>
<div bgcolor="#FFFFFF">
Roughly, <br></div>
<div bgcolor="#FFFFFF">
<span style="font-family:menlo,consolas,"courier new",monospace" class="font"></span><span style="font-family:menlo,consolas,"courier new",monospace" class="font">M0 = #{ key => Value1, "key" => Value2}, % for
construction.</span><span style="font-family:menlo,consolas,"courier new",monospace" class="font"></span><br></div>
<div bgcolor="#FFFFFF"><span style="font-family:menlo,consolas,"courier new",monospace" class="font">
</span><span style="font-family:menlo,consolas,"courier new",monospace" class="font"> M1 = M1#{ "key" := Value3, <<"key">> =>
Value4 }, % for updates</span><span style="font-family:menlo,consolas,"courier new",monospace" class="font"></span><br></div>
<div bgcolor="#FFFFFF"><span style="font-family:menlo,consolas,"courier new",monospace" class="font">
</span><span style="font-family:menlo,consolas,"courier new",monospace" class="font"> #{ "key" := V } = M1. % for matching</span><span style="font-family:menlo,consolas,"courier new",monospace" class="font"></span><br></div>
<div bgcolor="#FFFFFF"> </div>
<div bgcolor="#FFFFFF">
Where the operator '=>' (assoc operator) is used for extending
and creating new Maps and the operator ':=' is used to update
existing key/values. The ':=' operator is the only operator allowed
in patterns. I'm guessing some confusion will arise from these two
types of operators on where you can and/or should use them.<br></div>
<div bgcolor="#FFFFFF"> </div>
<div bgcolor="#FFFFFF">
Look at the tests and EEP for details and inspiration.<br></div>
<div bgcolor="#FFFFFF"> </div>
<div bgcolor="#FFFFFF">
A major difference from the EEP are variables in keys. Variables in
keys are not allowed at all. This is because we want to reduce the
scope for this first stage. Plenty to do besides that.<br></div>
<div bgcolor="#FFFFFF"> </div>
<div bgcolor="#FFFFFF">
Here are some additional disclaimers to make people sad.<br></div>
<div bgcolor="#FFFFFF"> </div>
<div bgcolor="#FFFFFF">
<u>What is not implemented?</u><br></div>
<div bgcolor="#FFFFFF"> </div>
<div bgcolor="#FFFFFF">
- No variable keys.<br></div>
<div bgcolor="#FFFFFF">
- No single value access.<br></div>
<div bgcolor="#FFFFFF">
- No map comprehensions.<br></div>
<div bgcolor="#FFFFFF">
- No datastructure to handle large Maps.<br></div>
<div bgcolor="#FFFFFF">
- No MatchSpecs which uses the Maps syntax will work.<br></div>
<div bgcolor="#FFFFFF"> </div>
<div bgcolor="#FFFFFF">
<u>Known issues</u><br></div>
<div bgcolor="#FFFFFF"> </div>
<div bgcolor="#FFFFFF">
- Dialyzer will not work with maps in the code, this include PLT
building with erts and stdlib.<br></div>
<div bgcolor="#FFFFFF">
- HiPE, the native compiler, will not with maps code.<br></div>
<div bgcolor="#FFFFFF">
- EDoc will not work with maps.<br></div>
<div bgcolor="#FFFFFF"> </div>
<div bgcolor="#FFFFFF">
I'm sure there are other issues as well, it is a development branch
after all. =)<br></div>
<div bgcolor="#FFFFFF"> </div>
<div bgcolor="#FFFFFF">
I would also like to point out that no optimizations are done either
with respect to the generated code. This means that the instruction
set may change. We know of several optimization we want to do before
R17, especially for the match compiler so keep that in mind.<br></div>
<div bgcolor="#FFFFFF"> </div>
<div bgcolor="#FFFFFF">
We will continue stabilizing the Maps implementation as we move
forward towards R17 and take appropriate action depending on the
feedback you give us.<br></div>
<div bgcolor="#FFFFFF"> </div>
<div bgcolor="#FFFFFF">
I would like to continue with saying a few words about possible
changes that we are thinking about.<br></div>
<div bgcolor="#FFFFFF"> </div>
<div bgcolor="#FFFFFF">
<u>Variables in Keys</u><br></div>
<div bgcolor="#FFFFFF"> </div>
<div bgcolor="#FFFFFF">
This feature is actually furthest down on the work prio list. We
want to stabilize the current features before moving forward and
variable keys is the one most likely to be dropped if we get pressed
for time. Meaning, it might not be implemented for R17 but instead
implemented for R18. The plan right now is to keep it though. <br></div>
<div bgcolor="#FFFFFF"> </div>
<div bgcolor="#FFFFFF">
<u>The External Format</u><br></div>
<div bgcolor="#FFFFFF"> </div>
<div bgcolor="#FFFFFF">
The current external format <i>needs</i> ordered keys as input for
binary_to_term/1 and in distribution.<br></div>
<div bgcolor="#FFFFFF"> </div>
<div bgcolor="#FFFFFF">
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.<br></div>
<div bgcolor="#FFFFFF"> </div>
<div bgcolor="#FFFFFF">
The distribution format should also be extended to be able cache
keys. This is similar to the atom cache except we<br></div>
<div bgcolor="#FFFFFF">
cache the entire key array for maps. This has been the intention all
along but it not mentioned in the EEP.<br></div>
<div bgcolor="#FFFFFF"> </div>
<div bgcolor="#FFFFFF">
<u>Term order and sorting</u><br></div>
<div bgcolor="#FFFFFF"> </div>
<div bgcolor="#FFFFFF">
Finally the term order. This has been a sore point from the get go.<br></div>
<div bgcolor="#FFFFFF"> </div>
<div bgcolor="#FFFFFF">
Maps currently respects the Erlang term order for it's keys.<br></div>
<div bgcolor="#FFFFFF"> </div>
<div bgcolor="#FFFFFF">
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.<br></div>
<div bgcolor="#FFFFFF"> </div>
<div bgcolor="#FFFFFF">
This would allowing newer ordered data structures, like maps, to be
more useful. We don't have to take<br></div>
<div bgcolor="#FFFFFF">
special care for the odd cases like keys 1.0 and 1 inhabiting the
same slot in the data structure. gb_trees and such structures could
also be extended to use this as those structures has the same
limitations.<br></div>
<div bgcolor="#FFFFFF"> </div>
<div bgcolor="#FFFFFF">
With this type ordering we could have maps with this type of keys,
#{ 1 => "integer", 1.0 => "float" } without causing confusion.<br></div>
<div bgcolor="#FFFFFF"> </div>
<div bgcolor="#FFFFFF">
I've been told that ETS ordered sets tables used to have this
behaviour. Distinguishing between floats and integers. This was
supposedly before the open source era, way back when dinosaurs
roamed the planet .. I'm not clear on the details on why this
behaviour was removed. Probably because of inconsistencies.<br></div>
<div bgcolor="#FFFFFF"> </div>
<div bgcolor="#FFFFFF">
For maps to work with this I only need two things. First, a compare
operation in the runtime that can distinguish between floats and
integers, very easy. Secondly, a BIF that sort a list of terms with
this new compare operation which will be used in the compiler.<br></div>
<div bgcolor="#FFFFFF"> </div>
<div bgcolor="#FFFFFF">
But for completness, the following operators should also be
implemented:<br></div>
<div bgcolor="#FFFFFF"> </div>
<div bgcolor="#FFFFFF">
=:= term exact equal to, already implemented<br></div>
<div bgcolor="#FFFFFF">
=/= term not equal to, already implemented<br></div>
<div bgcolor="#FFFFFF">
=:< term less or equal than<br></div>
<div bgcolor="#FFFFFF">
>:= term greater or equal than<br></div>
<div bgcolor="#FFFFFF">
<:< term less than<br></div>
<div bgcolor="#FFFFFF">
>:> term greater than<br></div>
<div bgcolor="#FFFFFF"> </div>
<div bgcolor="#FFFFFF">
So, true = 1 <:< 1.0.<br></div>
<div bgcolor="#FFFFFF"> </div>
<div bgcolor="#FFFFFF">
I don't know prolog but perhaps these sematics should mimic prolog
to respect Erlangs heritage. I have no strong opinion on this.<br></div>
<div bgcolor="#FFFFFF"> </div>
<div bgcolor="#FFFFFF">
This syntax would mimic the already present =:= and =/= relational
operators hower this syntax is another topic and should be a
seperate EEP.<br></div>
<div bgcolor="#FFFFFF"> </div>
<div bgcolor="#FFFFFF">
Happy testing!<br></div>
<div bgcolor="#FFFFFF"> </div>
<div bgcolor="#FFFFFF">
Regards,<br></div>
<div bgcolor="#FFFFFF">
Björn-Egil Dahlberg<br></div>
<div bgcolor="#FFFFFF">
Erlang/OTP
<br></div>
<div> </div>
<div>_______________________________________________<br></div>
<div>
erlang-questions mailing list<br></div>
<div>
<a href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a><br></div>
<div>
<a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br></div>
<div> </div>
</blockquote></div>
<div> </div>
</div>
<div><u>_______________________________________________</u><br></div>
<div>erlang-questions mailing list<br></div>
<div><a href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a><br></div>
<div><a href="http://erlang.org/mailman/listinfo/erlang-questions">http://erlang.org/mailman/listinfo/erlang-questions</a><br></div>
</blockquote></body>
</html>