[erlang-in-lisp-devel] Funs

[Robert Virding]

Hi sorry I have been a bit lazy here.

I have been reading through what Matt Bone has written in is his blog and
would like to comment. As his entries are a bit old I thought this might be
a better way to get info to him. Correct me I am wrong here.

First about how funs are implemented in the BEAM today.

The compiler, in the v3_kernel module, breaks out funs into separate
"normal" functions with the free variables added as explicit variables. In
the kernel erlang format all functions are flat with unique variables and
have proper atom names. For the fun functions the name is built up from the
function in which the fun occurs and an fun index, something like
'-foo/3-anonymous-3-'.

The fun itself is basically a tuple containing the module name, the fun
function name, and the actual values of the free variables. There is also a
unique tag to make sure that you can only call a fun in the same module as
it was defined. This is needed as funs functions are called by name. Note
that there is no code in the fun, calling a fun needs the right module to be
loaded and it has to be exactly the same version of the module. This can be
difficult running distributed erlang. It also mans that funs are not realy
safe over code loading as you can have a fun which points to a too old
version of a module which has been purged.

Funs were not part of the original language/implementation and added after
the basic code handling had been defined. In this respect they don't really
fit in as well as they could.

I hope this may help a little. I will get back soon on signals and messages
and how they interact.

One thought on using the front-end of the existing Erlang compiler. Core
erlang, which is generated by the v3_core module, is very lisp like. Most of
it will directly translate to basic lisp except for patterns, and the try
and catch constructions. One hint there is to look at my LFE where I go the
opposite way and compile to core elang. The basic LFE forms are actually
very close to core erlang and LFE try is handled the same as ERlang try and
generates the same core code.

Another thought might be to use kernel erlang instead as it is simpler and
the pattern matching has been compiled out.

Robert
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/erlang-in-lisp-devel/attachments/20080808/8491d73e/attachment.html>