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

[Christian]

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.