<html>
  <head>

    <meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    Hi everyone!
    <br>
    <br>
    We finally have a Maps EEP for you.
    This will get you an idea on what we are working on. Some of the
    ideas presented here was presented at Erlang Factory SF Bay Area
    2013.<br>
    <br>
    I am sure that there will be some discussions about the contents of
    this EEP and I hope the discussions will be both fruitful and
    civilized.
    <br>
    <br>
    The journey of Maps and this EEP has been long and by no means a
    straight-forward or continuous one. I had a crystal clear picture of
    what I wanted Maps to be when we first started discussing it within
    OTP about two-three years ago. This EEP resembles that vision but it
    has had a lot of contributions of other ideas from both within
    and outside of OTP.
    <br>
    <br>
    The idea was a functional data-type, a syntax aware mapping of
    key-value associations with pattern matching. A syntax similar to
    records but without the hazzle of compile-time dependency and with
    arbitrary terms as keys. Order was not important and it could be
    implemented with a Hash-Array-Mapped-Trie with good performance and
    memory trade-offs. This was not an approach to replace records. It
    was meant to replace records where suitable and in other regards not
    be a replacement but its own <b class="moz-txt-star"><span
        class="moz-txt-tag"></span></b><span class="moz-txt-star">thing</span><b
      class="moz-txt-star"><span class="moz-txt-tag"></span></b>.
    <br>
    <br>
    From the community there has been many wishes of a Map like
    data-type and a few suggestions.  The one suggestion that stands out
    is of course the Frames proposal from Richard O'Keefe. It is the
    most complete proposal I've seen and is very well thought out. Its
    goal is to be a record replacement and the proposal satisfies this
    goal very well.
    <br>
    <br>
    - If Frames are that good, why a separate EEP?
    <br>
    - It boils down to goals and constraints.
    <br>
    <br>
    A record replacement is just that, a replacement.
    <br>
    It's like asking the question, "What do we have?" instead of "What
    can we get?"<br>
    The instant rebuttal would be "What do we need?" I say Maps. <br>
    <br>
    Frames has certainly influenced Maps. In many regards Maps also
    encompasses Frames but Maps tries to do more. I think the most
    significant difference would be, arbitrary terms as keys and how
    many different keys we would have in a Map. In the end I believe
    they are two different things and have different goals. <br>
    <br>
    Some Notes and Disclaimers:
    <br>
    <br>
    Later iterations of Maps has gone through some changes, most
    significantly,
    <br>
    <br>
      * From a set of key-values to a ordered set of key-value
    associations
    <br>
    <br>
    I was originally against this change since it forces restrictions on
    the implementation and it illuminates the lack of distinction
    between arithmetic order and term order, i.e. the problem of mixing
    integer and float types as keys in a tree. However, I was later
    persuaded that key ordering is necessary. We have to respect the
    totalitarian order of terms.
    <br>
    <br>
    Considerations has been made on how to, if at all possible, apply
    Frames characteristics to Maps. Most significantly memory space and
    key-sharing characteristics. This is not detailed in the EEP though,
    just mentioned.<br>
    <br>
    The function interface has had many revisions as well. At some stage
    the API was considered to be a drop-in-replacement for `dict` and
    thus would have the same function-names. This goal/constraint was
    dropped by Technical Board decision recently.<br>
    <br>
    From the very beginning Maps was envisioned to have the ability to
    bind variables derived from the environment. Like this:
    <br>
    <br>
        function(K1, #{ K1 := K2, K2 := V }) -> V.
    <br>
    <br>
    This feature is a beast. Powerful and scary. It is not confined to
    only Maps but should also be applicable to other types as well:
    <br>
    <br>
        function(Skip, <<_:Skip/binary, Value:Size,
    _/bits>>, Size) -> Value.
    <br>
    <br>
    It is uncertain how effective such an implementation would be and in
    the end we might not want this feature at all.<br>
    <br>
    In this EEP we will describe syntax and semantics of Maps but very
    little is disclosed of its actual implementation. Current prototypes
    stems from using sparse tuples in a HAMT-like data structure and
    tuple-like data structures. The HAMT-like data structure is
    discontinued and will be replaced by some ordered tree.<br>
    <br>
    The proposal is included as an attachment but can also be viewed at
    this git-repository:<br>
    <a class="moz-txt-link-freetext" href="https://github.com/psyeugenic/eep/blob/egil/maps/eeps/eep-0043.md">https://github.com/psyeugenic/eep/blob/egil/maps/eeps/eep-0043.md</a><br>
    <br>
    <br>
    Regards,
    <br>
    Björn-Egil Dahlberg
    <br>
    Erlang/OTP
  </body>
</html>