Records (was RE: Fun syntax & language feature poll)

[Thomas Lindgren]

> Are any record changes expected in R9?  I've been hearing about records
> becoming separate types (not just tuples) and better record support in the
> shell for what seems like years now :)

The sooner the better :-)

What are the current requirements?

- create record, #rec{fld1=E1,...}
- modify record, R#rec{fld1=E1,...}
- access record field, R#rec.fld
- index of field, #rec.fld  (this one is messy)
- record_info
- test record type, record(X, rec)
- readable, printable (currently, this is ad hoc)
(did I forget anything?)

I think there are some frequently used operations, e.g., lists:keysearch,
mnesia to some extent, that rely on the tuple representation at this time.

Other issues:
- What is the scope of a record declaration?
- Do record declarations exist at runtime?

In my optimizer, I used a strict compile-time approach and renamed all
records using the MD5-hash of their declarations, so that
	#rec
became
	#'rec <very long unique number>'
which made them unique throughout the program (at least unique up to
equivalence; identical declarations got the same name). But this is
unsatisfactory for use in the shell.

I can see two methods for that:

1. The shell keeps track of what record declarations are active (and permits
the user to declare records and including files), and reads and prints
records using this information, or

2. When a record type is declared, we allocate an information object about
it, which stores the field names, the printname (= declared name), and
whatever else is convenient. A heap record then points to this information
object. Common operations on records should compile into code that does NOT
need to access the record info object, or performance will likely suck.

The first one is simpler. The second one seems the more principled approach.
(Suitable runtime record info also permits operations such as X#rec.Fld,
X#Rec.fld, ... which would come in handy now and then.)

Best,
Thomas