[erlang-questions] Maps

[Chris King]

+1 for "Robert's records".

I do NOT want to use a dictionary to store record data, for the same
reason I don't want to use a list to store tuple data -- it is not the
correct concept.

All compound data structures are one of two kinds -- heterogeneous and
static, or homogeneous and dynamic.

By "heterogeneous and static", I mean that the components are
potentially of differing types (heterogeneous), and that the form of
the structure as a whole is determinable at compile time (static).
This includes tuples, records, "Robert's records", frames, and
functional objects (as they are known in OCaml).

By "homogeneous and dynamic", I mean that the components are
necessarily of the same type (homogeneous), and that the form of the
structure as a whole is not necessarily determinable at compile time
(dynamic).  This includes lists, binaries, maps, and set- or map-like
ADTs.

The other two combinations -- heterogeneous and dynamic, and
homogeneous and static -- are rather useless.  The latter is merely a
degenerate case of both the above kinds, and the former is almost a
definite code smell (if you can't describe your data, how can you
operate on it?).

Maps, as presented, are heterogeneous and dynamic.  I claim this is
folly:  If my data is heterogeneous and static, what use have I for
non-atom keys, and why must I be bound by an explicit ordering of
keys(!?)?  If my data is homogeneous and dynamic, why must I pay the
storage cost of identifying the type of each element, and preclude my
typechecker from ensuring the homogeneity of my data?

"Robert's records" / frames, on the other hand, are heterogeneous and
static.  They lend themselves well to type-checking (see OCaml's
functional objects), and (IMPORTANTLY -- many seem to miss this!) they
provide SUBTYPING OF RECORDS.  This is HUGE (I would say the entire
purpose of frames!), NOT merely syntactic, and importantly -- maps
don't provide this! thanks to the above-mentioned ordering of keys.

I personally don't care about a syntax for homogeneous dynamic data --
syntax is useless unless it provides additional expressivity, and I
don't see that the current proposal does for this case.  But if others
do, all I ask is PLEASE don't present this syntax as a solution to the
record subtyping problem, as it is not for reasons outlined above --
and I suspect that a "maps" proposal *ignoring* the record subtyping
use case will result in a more efficient implementation.

On Tue, May 14, 2013 at 9:41 AM, Max Lapshin <max.lapshin@REDACTED> wrote:
> I think, that first problem is a convenient syntax for key-value
> structure. Syntax that will also work for pattern matching, not also
> editing existing structure.
>
> Second problem is a distinguishing between tuples and this special
> type. Many of us have problems trying to understand: is this a list of
> integers or a string? How should I pack it to json? As a result, many
> modern pieces of software are migrating to binary-only.
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions