[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 21 Nov 2008, at 4:54 am, Robert Virding wrote:
> 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.

Amongst other things, the 'frames' proposal insists that
the keys may only be atoms.  Not any other kind of Erlang value.
There are many reasons for this.  Readability is fairly high on
the list.

That makes them utterly unsuitable as replacements for anything
but records.

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

There's an American cartoon strip called Broomhilda
(http://www.gocomics.com/broomhilda).
One particular strip I almost remember has Broomhilda
wandering into a saleroom where the salesman offers her
some implausible combination gadget, and the punchline
is something like "Then I guess you aren't interested
in a combination pool table/washing machine either."

Of course it is possible to have an abstract data structure
(with several representations) that can cover a wide range
of sizes.  The problem is that checking what representation
you have adds extra time.  It's probably not measurable for
the large collections, but it WOULD be measurable for the
tiny ones.

The thing is that 'frames' are designed for the record-like
case where in any one clause body that looks at the thing
at all, you typically want 10% or more of the fields.

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

Simple: frames are for heterogeneous aggregates with slots
identified by atomic labels known at compile time that you want
to pattern-match against, dicts are for homogeneous collections
with arbitrary keys determined at run time that
you want to update a lot and iterate over.  You usually don't
want to pattern match against a dict because you have no idea
what keys to write in your source code.
>
>
> I am all for adding something like frames, but I also think it is  
> best to leave records in the system as they are.

Backwards compatibility has long been an emphasis of Erlang/OTP.