Funs

[Thomas Lindgren]

--- Rudolph van Graan <rvg@REDACTED> wrote:

> I only changed the code IN the fun, not any
> references or arity or  
> anything else. I presume beam checks the version of
> the stored fun  
> against the one in ets and gives me a badfun when
> they don't match.

Yes, funs are considered "transient", I guess.
(Whether this way of handling funs is Right is another
discussion.)

One way of getting around this would be to store such
funs in a module of their own (either one fun per
module or one group of funs per module). The funs will
live as long as that module.

A second approach is to avoid funs, store {M,F,A, FVs}
and invoke the actual function by hand. Some variation
on this is probably the common solution.

Inside the runtime system, a third way would be to
garbage collect code; the fun can then just hang on to
the code it needs. This is used in some FPLs, I
believe, and was at least proposed for the
multiprocessor Erlang prototype (don't know if it was
implemented?). Persistence, e.g., storing the fun in
mnesia, could yield surprising amounts of copying,
though :-)

Finally, perhaps the compiler and runtime could keep
track of funs by using an extra level of indirection. 

Each fun gets a hash (a pseudo code pointer, or a
handle to its code pointer) which is the hash key to
its code pointer. When a module is loaded or unloaded,
the hash table of (key, codeptr) is updated
appropriately by deleting keys from purged modules and
adding keys from loaded ones. Some refcounting may be
required too.

Anyway, an identical fun (same hash) will then by
default point to its code in the most recent module.
Cost of applying the fun compared to today is unclear.

Best,
Thomas



		
__________________________________ 
Yahoo! Mail - PC Magazine Editors' Choice 2005 
http://mail.yahoo.com