What 'record' module implementation are you talking about?<br><br><a href="http://www.erlang.org/doc/man/record.html">http://www.erlang.org/doc/man/record.html</a> -> 404 Not found<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>