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

Robert Virding rvirding@REDACTED
Thu Nov 20 16:54:30 CET 2008

2008/11/20 Richard O'Keefe <ok@REDACTED>

> 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.
> ...
> 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.

Richard, one question about implementations. In some discussions I have had
with people about such an extension (all want it) is that many see it not
only as a replacement for records but also as a replacement for
dict/gb_trees/sometimes even ets. Do you think it is possible to have one
data structure which would efficiently span such a large range of entries?
>From 0 in frames to 100,000s in in dict/gb_trees?

I personally don't think it is possible, without changing internal
representation somewhere. But if we have two different packages, frames and
dicts, then we get the problem of trying to explain to people the difference
between them and when to use which.

I am all for adding something like frames, but I also think it is best to
leave records in the system as they are. While we are at it I would like to
see a hash table data type which could be used as a basis for dict to make
it more efficient.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20081120/e73209ce/attachment.htm>

More information about the erlang-questions mailing list