[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).
/Joe
>
> mats
>
More information about the erlang-questions
mailing list