[erlang-questions] Maps

[Jeremy Ong]

> 
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?).

While I agree to some of your points, I don't quite agree here. For
example, during a code upgrade, one may want to add a new field to the data
(heterogeneous). With static data structures, this upgrade is trickier as
it requires the origin and destination to have the correct number of fields
or it won't work. With a dynamic structure, no state migration is necessary.

In addition, just because a feature could cause code smell in certain
circumstances doesn't mean it should be immediately excluded. Erlang
provides list_to_atom (with appropriate caution) because occasionally, it
is the right thing to do (convenience in small scripts for example). I
think a dynamic heterogeneous structure can provide tremendous value. Take
JSON for example. It's used everywhere, and people import JSON into Erlang
as a bunch of nested keylists. This is the heterogeneous dynamic structure
you are talking about and it is very clunky to work with! Using nested
keyfinds, keystores, and keydeletes is extremely clunky and I feel forced
to "take an object oriented approach" by creating modules providing getters
and setters for each of these values. I hate doing this personally but it's
better than the alternative.

Cheers,
Jeremy


On Tue, May 14, 2013 at 8:25 AM, Chris King <colanderman@REDACTED> wrote:

> +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
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20130514/f250c038/attachment.htm>