<div dir="ltr">Hi,<div><br></div><div>Nice!</div><div><br></div><div>I noticed that syntax_tools needs to be updated with support for maps.  Perhaps you already have that on some list?</div><div><br></div><div>Keep up the good work. :-)</div>

<div><br></div><div><br></div><div>Cheers,</div><div>Klas</div><div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Oct 25, 2013 at 6:37 PM, Björn-Egil Dahlberg <span dir="ltr"><<a href="mailto:egil@erlang.org" target="_blank">egil@erlang.org</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
  

    
  
  <div bgcolor="#FFFFFF" text="#000000">
    Hi!<br>
    <br>
    Here you go, Maps!<br>
    <br>
    I've pushed a Maps branch to Erlang/OTPs repository at GitHub.<br>
    <br>
    To get the branch,<br>
    <br>
    <tt>  git fetch <a href="mailto:git@github.com:erlang/otp.git" target="_blank">git@github.com:erlang/otp.git</a>
      egil/maps/eep-implementation</tt><br>
    <br>
    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>
    <br>
    I want to state the following so there is no room for uncertainty:<br>
    - This branch contains a <b>development stage</b> of the <b>experimental</b>
    Maps feature for Erlang.<br>
    <br>
    This means:<br>
     - Do not use it in production since it is not stable,<br>
     - Do not base any git branch on this branch since it will most
    likely be rebased,<br>
     - and finally, we reserve the right to change any API or interfaces
    to Maps currently implemented.<br>
    <br>
    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>
    <br>
    <u>What is implemented?</u><br>
    <br>
    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>
    <br>
    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>
    <br>
    I recommend people look at the EEP for information and also the
    testsuite located at <tt>erts/emulator/test/map_SUITE.erl</tt> for
    information on how to use Maps since no other documentation is
    available.<br>
    <br>
    Roughly, <br>
    <tt>  </tt><tt>M0 = #{ key => Value1, "key" => Value2}, % for
      construction.</tt><tt><br>
    </tt><tt>  M1 = M1#{  "key" := Value3, <<"key">> =>
      Value4 }, % for updates</tt><tt><br>
    </tt><tt>  #{ "key" := V } = M1. % for matching</tt><tt><br>
    </tt><br>
    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>
    <br>
    Look at the tests and EEP for details and inspiration.<br>
    <br>
    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>
    <br>
    Here are some additional disclaimers to make people sad.<br>
    <br>
    <u>What is not implemented?</u><br>
    <br>
    - No variable keys.<br>
    - No single value access.<br>
    - No map comprehensions.<br>
    - No datastructure to handle large Maps.<br>
    - No MatchSpecs which uses the Maps syntax will work.<br>
    <br>
    <u>Known issues</u><br>
    <br>
    - Dialyzer will not work with maps in the code, this include PLT
    building with erts and stdlib.<br>
    - HiPE, the native compiler, will not with maps code.<br>
    - EDoc will not work with maps.<br>
    <br>
    I'm sure there are other issues as well, it is a development branch
    after all. =)<br>
    <br>
    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>
    <br>
    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>
    <br>
    I would like to continue with saying a few words about possible
    changes that we are thinking about.<br>
    <br>
    <u>Variables in Keys</u><br>
    <br>
    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>
    <br>
    <u>The External Format</u><br>
    <br>
    The current external format <i>needs</i> ordered keys as input for
    binary_to_term/1 and in distribution.<br>
    <br>
    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>
    <br>
    The distribution format should also be extended to be able cache
    keys. This is similar to the atom cache except we<br>
    cache the entire key array for maps. This has been the intention all
    along but it not mentioned in the EEP.<br>
    <br>
    <u>Term order and sorting</u><br>
    <br>
    Finally the term order. This has been a sore point from the get go.<br>
    <br>
    Maps currently respects the Erlang term order for it's keys.<br>
    <br>
    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>
    <br>
    This would allowing newer ordered data structures, like maps, to be
    more useful. We don't have to take<br>
    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>
    <br>
    With this type ordering we could have maps with this type of keys,
    #{ 1 => "integer", 1.0 => "float" } without causing confusion.<br>
    <br>
    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>
    <br>
    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>
    <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>
    So, true = 1 <:< 1.0.<br>
    <br>
    I don't know prolog but perhaps these sematics should mimic prolog
    to respect Erlangs heritage. I have no strong opinion on this.<br>
    <br>
    This syntax would mimic the already present =:= and =/= relational
    operators hower this syntax is another topic and should be a
    seperate EEP.<br>
    <br>
    Happy testing!<br>
    <br>
    Regards,<br>
    Björn-Egil Dahlberg<br>
    Erlang/OTP<br>
  </div>

<br>_______________________________________________<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>
<br></blockquote></div><br></div>