[erlang-questions] next(Erlang): "Fix up records so that records are first-class citizens and not just syntax saccharine for tuples?"

[Richard O'Keefe]

On 20 Nov 2008, at 11:45 am, damien morton wrote:
> Hmm, I see - these fixed-up records would be dictionary-like data
> structures, with a supporting syntax for dictionary literals and
> pattern matching. They would lose the very fast lookup access that
> records have, though they would gain the expandability that a
> dictionary-type (proplist,hashtable,tree) data structure offers.

They could still be quite fast.  Until they've been implemented,
we shan't know for sure.  One aspect of this is that one tends
to write slightly different code with frames than with records.
With records, it's quite common to see

	f(..., R, ...) ->
	    ...R#foo.bar...
	    ...R#foo.ugh...
	    ...R#foo.zoo...

With frames, you write

	f(..., R = <{bar ~ X, ugh ~ Y, zoo ~ Z}>, ...) ->
	    ...X...
	    ...Y...
	    ...Z...

or	f(..., R = <foo{bar ~ X, ugh ~ Y, zoo ~ Z}>, ...) ->

if you want the extra checking.  You _could_ do this with records,
but it's less common.  And the combined form may well be faster than
several separate field accesses.

> The only way I could see a tighter integration between records and
> frames is if the keys were stored separately from the values, with the
> keys being the "schema" and the values being the data.

My proposal comes with an implementation sketch
that *does* store the keys and the values separately.
Up to tagging, a frame is basically
	{{foo,bar,ugh,zoo},X,Y,Z}
and the "descriptor" part would normally be shared.
This in no way impairs extensibility; the descriptor
doesn't *have* to be shared.