[erlang-questions] Current term representation?

[Richard Carlsson]

Richard A. O'Keefe wrote:
> I have the Erlang sources and have a rough idea where to
> look, but life's a bit too short to reconstruct what someone
> already knows:
> 
>     What is the current term representation in Erlang?

Look in the file erts/emulator/beam/erl_term.h for the tag
scheme; the comments are fairly detailed.

 > In particular, how are funs represented?

Actual fun-objects are created by the C function new_fun()
in the file erts/emulator/beam/beam_emu.c.

The definition of the struct ErlFunThing is found in the file
erts/emulator/beam/erl_fun.h.

> Provided that a fun calls everything but built in functions
> through explicit module:calls, is it now safe to send a fun
> to another node? to save a fun in a data base and use it in
> a later session?

The new 'fun Module:Function/Arity' funs are purely symbolic
representations and are always safe to store and pass around.

The "normal" kind of funs, however, are always associated
with the module in which they occurred syntactically - they
contain a pointer to code in a particular (loaded) version
of that module (the version that some process was running in
when it created that fun-instance object).

- If a version of a module is unloaded from the system, then
any process that holds pointers to that code (be it funs or
return addresses on the process' stack) will be killed to
avoid dangling pointers.

- It is always "safe" to send a fun to another node if it
is not actually called by code on that node. If it gets sent
back to the original node, all information should be preserved
so that it can be applied locally again, as if it had just gone
through binary_to_term(term_to_binary(Fun)).

- If it is called by code running on the remote node, then it
depends on whether or not the exact matching module exists also
on that node. The details of what a "match" is are a bit fuzzy.
This is a rather dark corner of Erlang's semantics, and is
bogged down with historical reasons and issues of backwards
compatibility when communicating between nodes that do not
run the same version of the runtime system.

- In general, if a fun-object is recreated from a binary
representation when no matching version of the parent module
exists on the local system, (I think that) what happens is that
the fun is made to point to a stub that will cause an error if
the fun is ever called. Hence, passing it around should remain
safe, but if you dig out an ancient fun from an ETS table, you
will not be able to call it.

(Björn G. should know the details, but I think he's on vacation.)

     /Richard Carlsson


-- 
  "Having users is like optimization: the wise course is to delay it."
    -- Paul Graham