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