[erlang-questions] term_to_binary and record improvements
Richard A. O'Keefe
Fri Aug 29 05:15:24 CEST 2008
On 29 Aug 2008, at 8:07 am, Jos Visser wrote:
> - It opens up the possibility of "hacky" code, with people
> records in novel and dynamic ways. On the other hand, that is what
> dynamically typed languages are for, and real programmers can write
> assembler in any language.
This possibility already exists in, for example,
- IBM Prolog
Psi-terms in LiFE (and the analogue in IBM Prolog) correspond very
to the "feature structures" used in unification-based approaches to
natural language processing.
Basically, any dynamically typed programming language that gives you
tables as values you can pass around is going to give you this feature.
(So add Common Lisp and ANSI Smalltalk to the list as well.
> - It is slightly less space efficient, but probably negligible.
I don't know why Joe split the descriptor into two separate parts;
backwards compatibility, maybe? The representation described in my
"frames" paper requires space for the descriptor (which is basically
a sorted tuple of field names), but that is usually one fixed shared
copy per construction site, and then each actual "frame" requires
EXACTLY the same amount of space as the corresponding "record".
Only if you create a "frame" in "novel and dynamic ways" is there
any space overhead, and then not always.
> - It breaks backward compatibility, although you can probably
> this in the compiler/VM by analyzing the tuple and deciding on
> we are dealing with a new or an old-style record-tuple.
If is_record/[2,3] were changed to match, there need be no effect on
well written source code at all. With my approach, which requires
sorting the fields by name, #<type>.<field> would change value;
Having the whole descriptor as a single tuple means that you can
easily tell the difference between an old-style record and a new-style
one, should you wish to. (Actually, in the "frames" proposal,
frames are like tuples but have a new tag, so they are actually a proper
> Which sort of prompts the question what the original problem is that
> you're trying to solve and whether this is worth it. An advantage
> that I
> see is that it would allow for more generic code, for instance
> referencing to X.name, which would work for every record which has a
> field called "name", without having to specify the type information.
> could be used to implement some sort of "inheritance" in records. You
> might want to extend the record definition language to make this
Half the point is that "the record definition language" becomes
unnecessary. The other half is that updates become easier: adding a new
field to a record in one place doesn't break every other place that uses
it. Having records be a proper type also means that they can always be
printed *as* records.
More information about the erlang-questions