[erlang-questions] Finding inconsistencies in record definitions and pretty printing records

Joe Armstrong erlang@REDACTED
Tue Oct 14 21:57:49 CEST 2008

On Tue, Oct 14, 2008 at 6:16 PM, mats cronqvist
<mats.cronqvist@REDACTED> wrote:
> "Joe Armstrong" <erlang@REDACTED> writes:
>> Hi,
>> This is a method for ensuring the consistency of records and for
>> providing record field information at run-time.
>> Long-time readers of this list will recognize this as a long-standing
>> problem.
>> (what's the problem? if you change a record definition and
>>  forget to recompile everything you will get fried - and
>>  record definitions get forgotten at run time)
>> (Short summary of how it works)
>>     - compile record definitions into the modules
>>       (uses a simple parse transform)
>  this is the problematic bit. as has been hashed several times on
>  this list, were record info exported (perhaps as a field in
>  module_info), all kinds of cool things could be accomplished.

It's not problematic - the parse transform in the enclosed code does
exactly that.

The enclosed code compiles record defs into the modules
concerned - sets up the servers, detects module inconsitencies at run
time and retrieves record definitions at run time *from any module*
(not just the definition module).

As far as I can see it is ready to include in a production version -
except for a slight
improvement to the pretty printer and to make sure the definitions are
reloaded when we recompile
a module.

A slight (and obvious) change makes all kind of dynamic (and generic)
record operations
possible. ie things like  doing X#rec{a=A} at run time *in any module*
when the module
concerned did not have knowledge of #rec at compile time. (hint change
the parse transform
to make an efficient form of module_record so that calling
module_record(rec, a) -> 1 (or whatever)
the "trick" is in finding which module #rec came from - and this is
solved in the enclosed code.

(With a simple optimization in the beam (hint - cache the module, once
it it is known) this
would be pretty efficient).


>  mats

More information about the erlang-questions mailing list