[erlang-questions] Maps

[Richard A. O'Keefe]

On 9/05/2013, at 3:33 AM, Michael Uvarov wrote:

> Max, map is just new name for frames.

ABSOLUTELY *NOT*!

The desire for O(lg N) update forces some crucial implementation
differences.

For record-like uses,
  frames would be smaller, faster, and safer than maps.
For dictionary-like uses,
  maps would be superior to frames.

Clearly distinguishing between record-like data structures and
dictionary-like data structures is the core of good design in
this area.

Looking at the example

    function(K1, #{ K1 := K2, K2 := V }) -> V.

we see an example of the kind of thinking that has gone into
the two proposals.

The Frames proposal won't have anything to do with something
like this, because I am a bear of very little brain who makes
an embarrassing number of mistakes; I am _far_ more likely to
have typed K1 by mistake (intending k1) than to want a variable
here, and I would not give you a thank-you for a compiler that
let this kind of thing through.  In particular, frames were
designed to be Dialyzer-friendly, so that there'd be a good
chance that the Erlang tools would not just tell me "Hey, K1
is not known to be an atom here" but "hey, you asked for slot
k1, but there isn't any such slot, did you mean k2?"

The Maps proposal is about *breadth* (a jack of all trades
data structure) and *expressiveness*.  Note the example
above, which _has_ to be matched from left to right.
Frame patterns can be matched in any order, just like tuple
patterns.  (No, I _don't_ want patterns that can only be
matched from left to right, thank you.  I want the pattern
match compiler to be able to choose what subpattern to do
next based on information gain, not order.)  I don't
believe it is possible to type check that example, at least
not in situations where the compiler doesn't know exactly what
keys might be present.  In contrast, <{ k1 = X, k2 = Y }> _can_
be type checked no matter what other fields might be present.

Being able to write functions that require strict left to right
matching is definitely more expressive than not being able to.
Using frames, you'd have to write the running example as

function(K1, Frame) ->
    frame_value(Frame, frame_value(Frame, K1)).

However, sometimes we like to re-order the arguments of our
functions.  In the absence of binary patterns, we can do so
freely now.  Making it hard to spot when a refactoring is
safe?  That's not something the frames proposal is supposed to
contain, and if anyone can find such a thing, I promise I'll
fix it.