Ah, good. Another library in CL's hip pocket. Interestingly, James Hendler (http://www.cs.umd.edu/~hendler/), while speaking at ILC, mentioned the lack of an IRC library as a reason he wasn't using CL when teaching his students. I guess that reason isn't valid no more.

This seems like a nice effort but I confess I was hoping for something a bit more sophisticated in a CL implementation. As far as I could tell it is not even multi-threaded.

Perhaps I'm missing something (I've only really looked at the examples), but I can't see what's stopping you from using it with multiple threads. In fact, given that it appears to run its own event loop it'd probably be more useful with threads than without

What were you looking for?

If you'd like to submit patches to the library so it provides a multithreaded interface while retaining the current functionality I'd be happy to integrate those into the CVS tree. Personally, I wasn't entirely sure how users would use the library so I thought I'd wait until I had some usecases before I decided on a multithreaded API.

You mention "not even multithreaded" which leaves me with the feeling that multithreading was one of several issues you spotted. Care to elaborate on the others?

Not multithreaded? ;-)
I do not know how far Erik mutated my original sources but it actually was already used in a multithreaded application (my IRC Client WeirdIRC).
The statement about the non-existence of an IRC library as a lack of CL sounds quite strange to me since mine (on which Erik built on) was not even the only one.

As for multi-threading, there are several ways to handle it but I was expecting a separate thread per socket read loop. I don't think the user should have to call "(read-message-loop connection)" after each command.

The approach taken in net-nttin-irc is very straight-forward and I didn't mean to criticize it. But I have seen many (and written 2) IRC client implementations and I was hoping to see a Lisp expert tackle the problem by writing a mini Domain Specific Language.

net-nittin-irc actually can use fd-handlers on SBCL, meaning that it can process events asynchronously upon receipt of a message. This is obviously not as good as threading, but if you want, just spawn another thread to handle the regular message loop. That's that.