<div dir="ltr"><div class="gmail_default" style="font-family:'courier new',monospace"><div class="gmail_default" style="display:inline">> </div><span style="font-family:arial">The other two combinations -- heterogeneous and dynamic, and</span><br style="font-family:arial">

> <span style="font-family:arial">homogeneous and static -- are rather useless.  The latter is merely a</span><br style="font-family:arial">> <span style="font-family:arial">degenerate case of both the above kinds, and the former is almost a</span><br style="font-family:arial">

> <span style="font-family:arial">definite code smell (if you can't describe your data, how can you</span><br style="font-family:arial">> <span style="font-family:arial">operate on it?).</span><br></div><div class="gmail_default" style="font-family:'courier new',monospace">

<span style="font-family:arial"><br></span></div><div class="gmail_default" style="font-family:'courier new',monospace"><span style="font-family:arial">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.</span></div>
<div class="gmail_default" style="font-family:'courier new',monospace"><span style="font-family:arial"><br></span></div><div class="gmail_default" style="font-family:'courier new',monospace"><span style="font-family:arial">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.</span></div>
<div class="gmail_default" style="font-family:'courier new',monospace"><span style="font-family:arial"><br></span></div><div class="gmail_default" style="font-family:'courier new',monospace"><span style="font-family:arial">Cheers,<br>
Jeremy</span></div>
<div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, May 14, 2013 at 8:25 AM, Chris King <span dir="ltr"><<a href="mailto:colanderman@gmail.com" target="_blank">colanderman@gmail.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">+1 for "Robert's records".<br>
<br>
I do NOT want to use a dictionary to store record data, for the same<br>
reason I don't want to use a list to store tuple data -- it is not the<br>
correct concept.<br>
<br>
All compound data structures are one of two kinds -- heterogeneous and<br>
static, or homogeneous and dynamic.<br>
<br>
By "heterogeneous and static", I mean that the components are<br>
potentially of differing types (heterogeneous), and that the form of<br>
the structure as a whole is determinable at compile time (static).<br>
This includes tuples, records, "Robert's records", frames, and<br>
functional objects (as they are known in OCaml).<br>
<br>
By "homogeneous and dynamic", I mean that the components are<br>
necessarily of the same type (homogeneous), and that the form of the<br>
structure as a whole is not necessarily determinable at compile time<br>
(dynamic).  This includes lists, binaries, maps, and set- or map-like<br>
ADTs.<br>
<br>
<div style="font-family:'courier new',monospace;display:inline" class="gmail_default"></div>The other two combinations -- heterogeneous and dynamic, and<br>
homogeneous and static -- are rather useless.  The latter is merely a<br>
degenerate case of both the above kinds, and the former is almost a<br>
definite code smell (if you can't describe your data, how can you<br>
operate on it?).<br>
<br>
Maps, as presented, are heterogeneous and dynamic.  I claim this is<br>
folly:  If my data is heterogeneous and static, what use have I for<br>
non-atom keys, and why must I be bound by an explicit ordering of<br>
keys(!?)?  If my data is homogeneous and dynamic, why must I pay the<br>
storage cost of identifying the type of each element, and preclude my<br>
typechecker from ensuring the homogeneity of my data?<br>
<br>
"Robert's records" / frames, on the other hand, are heterogeneous and<br>
static.  They lend themselves well to type-checking (see OCaml's<br>
functional objects), and (IMPORTANTLY -- many seem to miss this!) they<br>
provide SUBTYPING OF RECORDS.  This is HUGE (I would say the entire<br>
purpose of frames!), NOT merely syntactic, and importantly -- maps<br>
don't provide this! thanks to the above-mentioned ordering of keys.<br>
<br>
I personally don't care about a syntax for homogeneous dynamic data --<br>
syntax is useless unless it provides additional expressivity, and I<br>
don't see that the current proposal does for this case.  But if others<br>
do, all I ask is PLEASE don't present this syntax as a solution to the<br>
record subtyping problem, as it is not for reasons outlined above --<br>
and I suspect that a "maps" proposal *ignoring* the record subtyping<br>
use case will result in a more efficient implementation.<br>
<div><div><br>
On Tue, May 14, 2013 at 9:41 AM, Max Lapshin <<a href="mailto:max.lapshin@gmail.com" target="_blank">max.lapshin@gmail.com</a>> wrote:<br>
> I think, that first problem is a convenient syntax for key-value<br>
> structure. Syntax that will also work for pattern matching, not also<br>
> editing existing structure.<br>
><br>
> Second problem is a distinguishing between tuples and this special<br>
> type. Many of us have problems trying to understand: is this a list of<br>
> integers or a string? How should I pack it to json? As a result, many<br>
> modern pieces of software are migrating to binary-only.<br>
> _______________________________________________<br>
> erlang-questions mailing list<br>
> <a href="mailto:erlang-questions@erlang.org" target="_blank">erlang-questions@erlang.org</a><br>
> <a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
_______________________________________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org" target="_blank">erlang-questions@erlang.org</a><br>
<a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
</div></div></blockquote></div><br></div></div>