Implementing tables - advice wanted

[Christian S]

On 6/13/06, Joe Armstrong (AL/EAB) <joe.armstrong@REDACTED> wrote:
>
> Hello,
>
>    I've been thinking a bit about tables in Erlang.
>
>    Erlang really really really (^100) needs tables.
>
>    Tables are like records without the record declarations, or like
> ets tables with a nicer syntactic structure - they are what I used to
> call structs in earlier postings, but most other languages call them
> tables.

I have been missing records in erlang that know what named fields they
contain at runtime. The design issues that i care most about is how
they would be integrated in terms of pattern matching and being
immutable.

@{age=Age} = Table,

Table2 = Table@{age=Age+1},

NSA ! {birthday, table_to_list(Table2)}

If they are mutable it would lead to ad-hoc OO systems in erlang and
people using OO programming (storing methods in tables). I kind of
like the explicit state that erlang makes you carry around (*naa*
*naa* *naa*  the process dictionary doesnt exist *naa* *naa* *naa*),
and i dont want it to go away.

How would tables be used in mnesia? mnesia:write would allow you to store
a "table" if it contains all the keys that the target mnesia table
has? (eeek, name collision, isnt associative array a better name?
map?)

Is there a good reason to limit the types of the keys? Or are you not?

How would these tables be stored in term_to_binary() format?