That has been my take all along! And the code to do this is already there. (That is, there is a PROCESS class with THREADED-PROCESS as a subclass and more subclasses planned.)
Guys like Joel make me wonder if people actually read the Erlisp roadmap [0]. Is it too fluffy? Not clear enough? Too long? Not structured properly? I'm willing to rewrite it if that can prevent things like these...
- Dirk
Your interest in speed is very clear (and very emphasized) in your roadmap, but only at the end. If I read the first two pages, I would get the impression that you didn't even notice that Erlang has fast threading (and that you had already implemented processes as threads). Then at the end I would see a long discussion of how to make Erlisp fast, including such extreme measures as hacking the CLisp backend or submitting CLRFIs. If all I cared about was speed, I might be inclined to stop reading after the first or second page and not see the third. That is probably what happened to Joel.
Possible ways to change this: Add a goals section at the top, maybe only 10 lines long but listing what you expect from ErLisp when it is completed. Add speed related items to the list of Erlang features, such as green threads or send-and-pray networking.
This is not the first time that Joel has started developing something in Lisp, expressed his desire to continue working in Lisp, but left to Erlang for its networking/threading features. If he could be persuaded to make some small contribution to ErLisp, I suspect he would remain a regular contributor for years to come. The obvious candidate would be light-weight threading, but that sounds rather difficult. Do we have any quick and easy tasks that might interest him?
Eric