There seems to be an interesting attraction between Erlang and Lisp and several times it has been tried to marry them, in different ways. Bill Clementson wrote about it already in his article
- ETOS, an Erlang to (Gambit) Scheme compiler, dating from 1997, was probably the first attempt to combine Erlang and Lisp. One of the things that came out of ETOS is Marc Feeley's paper
- Erlisp was another attempt, this time in Common Lisp. It's a (partial) reimplementation of the Erlang concurrency model. I don't think anybody is working actively on it at the moment.
- CL-MUPROC is a Common Lisp library which strives to offer some of the multiprocessing abstractions found in Erlang, very much in the same way as Erlisp. It implements some of Erlang's fault-tolerance mechanisms, but not yet distributed operations.
- Distel, a distributed Emacs Lisp with Erlang-style processes and message passing, and the Erlang distribution protocol, originally developed by Luke Gorrie of LtU, SLIME, OLPC, and other fame. Some time ago, Bill Clementson wrote a nice article about Distel.
- Termite, another Erlang-like distributed programming system, this time written in Gambit-C Scheme.
- Lisp Flavoured Erlang (LFE) is a Lisp syntax front-end to the Erlang compiler by Robert Virding (one of the inventors of Erlang). This is an interesting one, because it comes out of the Erlang community for a change, and instead of porting Erlang ideas to Lisp, it goes the other route: porting Lisp ideas to Erlang.
- Erlang Server, Common Lisp Client by Berlin Brown appears to be the latest attempt of integrating Erlang and Lisp. They are connected via sockets and exchange messages in a custom protocol. This has the advantage that either side can easily be replaced by a different implementation.
- erlang-scheme is a port of Distel from ELisp to Scheme.
- Erlang-like Threads in Common Lisp
And this list does not even include projects like (again defunct?) Kali Scheme, which are clearly related.
Personally, I think that the reimplementation approach will have a tough stance against integration approaches like Distel. They lock out either one or the other of the two language eco-systems: libraries, development tools, etc., and recreating this is a lot of work (but don't let that stop you!) With Distel, I can choose to program parts of the application in ELisp or Erlang, whatever is a better fit.
Distel implements Erlang's on-the-wire protocol, which is nice because there is no need to mess around with a Foreign Function Interface. Alternatively, one could bind to the Erlang C libraries. As far as rapid prototyping is concerned, this should be the fastest and most straight-forward approach. I wonder why everybody is doing it the hard way (reimplementation)?
Bill Clementson wrote a nice summary of the Erlang Interoperability options. Thanks again, Bill!
Jerome Baum announced an implementation of Erlang-like Threads in Common Lisp.