Your approach have many drawbacks by design. Each set operation have O(N) memory complexity and also O(N) time complexity (Your bisec search is O(logN) but you must copy whole assoc tuple which is O(N)). I don't understand why not use some tree representation which have set operation O(logN) memory and time. You haven't any gain from tuple representaion for get because your get is O(logN) which is same as for tree representations. You can idealy balance tree when you have fixed key set and do not cope with tree rebalance. It shoudl be more worth approach.<br>
<br><div class="gmail_quote">On Mon, Jan 12, 2009 at 7:25 PM, Christian <span dir="ltr"><<a href="mailto:chsu79@gmail.com">chsu79@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="Ih2E3d">On Mon, Jan 12, 2009 at 00:10, James Hague <<a href="mailto:james.hague@gmail.com">james.hague@gmail.com</a>> wrote:<br>
> but the code ends up bulky and contrived.  Yeah, we've all discussed<br>
> this for years, so here's hoping there's some movement on this front.<br>
> Syntactically, the version I like the most at the moment is the record<br>
> syntax without a record name:<br>
><br>
>   #{width=1280, height=1024, colors=65536}<br>
<br>
</div>Ponder this approach I implemented:<br>
<br>
1> Assoc = record:list_to_assoc([foo, bar, baz]).<br>
{{bar,3},{baz,4},{foo,2}}<br>
2> record:in(baz, Assoc).<br>
4<br>
<br>
Basically a map from atoms to integers. I choose to perform binary<br>
search. One can then create a tuple where this Assoc takes the place<br>
of the atom tag in a plain record:<br>
<br>
3> Rec = record:new(Assoc).<br>
{{{bar,3},{baz,4},{foo,2}},[],[],[]}<br>
<br>
And operations use the atom->integer map to implement basic<br>
manipulations on tuples by field name:<br>
<br>
4> Rec1 = record:set(baz, x, Rec).<br>
{{{bar,3},{baz,4},{foo,2}},[],[],x}<br>
<br>
5> record:get(baz, Rec1).<br>
x<br>
<br>
The downside in this implementation of Assoc is that there is going to<br>
be lots of repeated references to new copies of same-valued tuples.<br>
Every copy inserted and taken out of ets will create a new one, as<br>
well as when they are sent between processes using the normal memory<br>
model.<br>
<br>
<br>
But would it be ugly to 'intern' this Assoc into a new first-class<br>
type? A reference counted atom() to integer() map type? Each module<br>
could put the assoc objects it needs in the constant pool so they<br>
would not need to intern the assoc object over and over again.<br>
<br>
<br>
Checking that an assoc contains a number of fields or the tuple<br>
element they're mapped to is efficient enough that it is no worser<br>
compared to the existing non-constant-complexity guards and bifs.<br>
<br>
<br>
I actually cant think of any downside to the approach that is a<br>
problem for the intended use. It just looks very difficult to create a<br>
new type and guards for it, requiring changes to both the compiler and<br>
the vm.<br>
<div><div></div><div class="Wj3C7c">_______________________________________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a><br>
<a href="http://www.erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://www.erlang.org/mailman/listinfo/erlang-questions</a><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>--Hynek (Pichi) Vychodil<br><br>Analyze your data in minutes. Share your insights instantly. Thrill your boss.  Be a data hero!<br>Try Good Data now for free: <a href="http://www.gooddata.com">www.gooddata.com</a><br>