[erlang-questions] Here's hoping we get frames or structs in 2009!

[Hynek Vychodil]

What 'record' module implementation are you talking about?

http://www.erlang.org/doc/man/record.html -> 404 Not found

On Mon, Jan 12, 2009 at 7:25 PM, Christian <chsu79@REDACTED> wrote:

> On Mon, Jan 12, 2009 at 00:10, James Hague <james.hague@REDACTED> wrote:
> > but the code ends up bulky and contrived.  Yeah, we've all discussed
> > this for years, so here's hoping there's some movement on this front.
> > Syntactically, the version I like the most at the moment is the record
> > syntax without a record name:
> >
> >   #{width=1280, height=1024, colors=65536}
>
> Ponder this approach I implemented:
>
> 1> Assoc = record:list_to_assoc([foo, bar, baz]).
> {{bar,3},{baz,4},{foo,2}}
> 2> record:in(baz, Assoc).
> 4
>
> Basically a map from atoms to integers. I choose to perform binary
> search. One can then create a tuple where this Assoc takes the place
> of the atom tag in a plain record:
>
> 3> Rec = record:new(Assoc).
> {{{bar,3},{baz,4},{foo,2}},[],[],[]}
>
> And operations use the atom->integer map to implement basic
> manipulations on tuples by field name:
>
> 4> Rec1 = record:set(baz, x, Rec).
> {{{bar,3},{baz,4},{foo,2}},[],[],x}
>
> 5> record:get(baz, Rec1).
> x
>
> The downside in this implementation of Assoc is that there is going to
> be lots of repeated references to new copies of same-valued tuples.
> Every copy inserted and taken out of ets will create a new one, as
> well as when they are sent between processes using the normal memory
> model.
>
>
> But would it be ugly to 'intern' this Assoc into a new first-class
> type? A reference counted atom() to integer() map type? Each module
> could put the assoc objects it needs in the constant pool so they
> would not need to intern the assoc object over and over again.
>
>
> Checking that an assoc contains a number of fields or the tuple
> element they're mapped to is efficient enough that it is no worser
> compared to the existing non-constant-complexity guards and bifs.
>
>
> I actually cant think of any downside to the approach that is a
> problem for the intended use. It just looks very difficult to create a
> new type and guards for it, requiring changes to both the compiler and
> the vm.
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://www.erlang.org/mailman/listinfo/erlang-questions
>



-- 
--Hynek (Pichi) Vychodil

Analyze your data in minutes. Share your insights instantly. Thrill your
boss.  Be a data hero!
Try Good Data now for free: www.gooddata.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20090113/3b31279c/attachment.htm>