[erlang-questions] Abstract patterns, structs and frames

[Richard O'Keefe]

On 25 Feb 2009, at 7:29 am, Rob Charlton wrote:

> Richard O'Keefe wrote:
>> Actually, tags are _optional_ in the frames proposal.
>> <Tag{ K1=E1, ..., Kn=En }>
>> is allowed, and is equivalent to <{'' = Tag, K1=E1, ..., Kn=En }>
>>
> Do you envisage that frames could become a drop-in replacement for  
> the use of records in mnesia?

I can't prove it, but I strongly suspect that
(1) almost all -record declarations are NOT related to Mnesia.
     {This is a fact for the code I can examine; I have no evidence
      that it is true for any other code.}
(2) almost all record *instances* in programs that use Mnesia
     are Mnesia records.

Not exactly "drop-in".  ETS and DETS need a key position,
and the elements of an ETS or DETS table must be tuples
with at least that many elements, but apparently need not
all be the same size (not something I've ever cared to try).

Recall that a frame is, at implementation level, basically
	{Descriptor,Field1,...,Fieldn}
where Descriptor is
	{Tag,Name1,...,Namen}
or	{Name1,...,Namen}

So we could envisage wrappers for ETS and DETS that took
a descriptor and a key *name* when you created a table,
and then mapped frames with exactly the fields of the
descriptor to tuples in the table.

Since Mnesia wants tagged records, it would be OK if the
ETS/DETS wrappers insisted on tagged frames/structs.

It's obviously possible to handle additional fields as well,
with some overheads.

So I think it's doable, and doable without any extra space
overheads *in the tables*, but I don't see it as a 'drop-in
replacement' simply because of the need to use field names
rather than key positions.  Close enough for it not too be
too painful to convert if you really wanted to.

> A lot of my record handling code is as a result of retrieving  
> records from tables. And indeed I just this second had to duplicate  
> a function that works across several tables which I could have  
> written once if based around frames or structs.

This is obviously an important question,
but I think we can proceed one step at a time.