record field names

Thomas Lindgren thomasl_erlang@REDACTED
Fri Sep 16 17:33:07 CEST 2005

--- Mats Cronqvist <mats.cronqvist@REDACTED>
> if there was a real, exported
> function record_info/2 (just like 
> module_info), one could do a lot of cool things.
>   such as turning a record into a tagged tuple;

The definition of records already basically requires a
record to be just a tagged tuple (e.g., the #rec.field
notation in Section 8.3 of the Erlang reference
manual, or the Section 8.7 that you quote). 

More so if you want to be backwards compatible: 

"It is often desirable to write generic functions
which will work on any record, not just a record of a
particular type. For this reason, records are
represented internally as tuples and the ordering of
the fields in the tuple is strictly defined."
  -- the "Erlang Extensions since 4.4" documentation
of R7, section 1.9

I have accordingly encountered code that builds
tuples, then uses them as if they were records (e.g.,
I think the R7 version of the asn1 compiler generated
such tuples). 

And in the other direction, records matched against
tuple patterns. In the R9 documentation, there is an
example that goes like this:

"The new module must translate the old state into the
new state. Recall that a record is just syntactic
sugar for a tuple:


-export([get_data/0, get_time/0]).
-export([init/1, handle_call/3, handle_cast/2,
         terminate/2, code_change/3]).

%% [old definition was -record(state, {data}).

-record(state, {data, time}).


code_change(1, {state, Data}, _Extra) ->
    {ok, #state{data = Data, time = erlang:time()}}.
 -- from
 section, "advanced gen_server"

(Which in its defense is less convoluted than trying
to do the same with two definitions of #state.)

(Personally, I'd prefer records as a sensible
first-class datatype instead of tagged tuples. But it
seems difficult to introduce that while remaining
backwards compatible.)


Yahoo! Mail - PC Magazine Editors' Choice 2005

More information about the erlang-questions mailing list