Faré wrote:

Relevant discussion on the uptick blog: http://wagerlabs.com/uptick/2005/07/very-frustrating-saturday.html The author has rival concerns about speed and memory-efficiency of threads.

My take:

The idea is that there should be a standard API, and then multiple ways of implementing it. Providing a light-weight implementation in terms of green threads (Eric Lavigne just ported erlisp to cmucl), or of a continuation passing transform (Screamer style), are definitely implementation strategies for Erlisp. And if all goes well, we can mix and match implementation strategies within a same Erlisp universe: gimme slower memory-efficient threads for this, faster memory-wasting threads for that, migratable (Tube-like) threads for that other thing, etc.

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 [0] http://dirkgerrits.com/programming/erlisp/roadmap/

Eric Lavigne wrote:

...

[...] make me wonder if people actually read the Erlisp roadmap. 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...

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.

Very good point...

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.

Okay so a juicier intro. Good idea. And I'm thinking of folding the overview and roadmap into one page.

Add speed related items to the list of Erlang features, such as green threads or send-and-pray networking.

Well this is already mentioned under 'Parallel programming'. I suppose I could split them off into separate features, but I'll have to locate my marketing hat. ;)

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?

I do not think there /are/ any quick and easy tasks, but perhaps he can join the technical discussions on this mailing list. That would be most welcome as I am myself just an Erlang newbie. - Dirk

"He" has already joined :-). I think I'll lurk around for a while and contribute to discussions. I'm in no position to code Erlisp at the moment. Feel free to bounce questions off of me, though.

Joel

-- http://wagerlabs.com/uptick

Welcome to the team, Joel. I'm also keeping an eye on your uptick project. Looks interesting.

...

I do not think there /are/ any quick and easy tasks,

I think this is an issue worth looking into. New developers, especially if they are new to programming in general, need easy tasks to cut their teeth on. It would be nice if ErLisp could fill that need. Each of my patches so far has some little problem with it. Allegro should be using gates rather than wait functions. That will require some reading and a few lines of code. CMUCL should probably use run-reasons instead of polling. That will require some research and a few lines of code. The bad news is that I'm a messy coder. :-( The good news is that there is no shortage of little projects laying around, and more are produced with each patch. :-) What do you think of creating a contributor's page? It could have links to the download page and the discussion page (both of which are fine the way they are). It would also include a list of contribution ideas of various difficulties and suggestions for getting started on each (such as checking the CMUCL mailing list or CMUCL's multi-proc.lisp for the CMUCL run-reasons task). Eric