Tue May 14 17:25:28 CEST 2013
+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
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
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
More information about the erlang-questions