What are the most important things that free Lisps lack compared with commercial ones?

Which of the open-source Common Lisp implementation projects has a full time staff of researchers working on it?

I very often read the commercial Lisps offer so much more than open source Lisps but I'm not sure if that's the case.

Corman Lisp (I'm a registered customer) has a looong way to go until it is fully ANSI-compliant, LispWorks (I've also paid for it) doesn't have much network support except for the raw socket interface, and the last time I looked SCL didn't come with GUI libraries, just to mention a few things. I can't comment on MCL because I don't use it.

I think the only commercial Lisp that really comes with everything and the kitchen sink is Allegro CL but we all know its price. (And then you could also argue that it doesn't have a cross-platform GUI like CAPI or native threads on Linux like SCL and SBCL. Or that it's slower than CMUCL.)

Don't get me wrong: These are all fine products. I just don't buy the argument that open source Lisps are lacking in every corner while the commercial implementations will make you happy for the rest of your life.

I'll offer some perspective on MCL, since I just bought a copy for my own personal use. I am still a happy SBCL user, but to me, MCL offers these advantages:

* The inspector. It's impossible to describe how nice it is to have this everywhere. It's much nicer than an ACL-ish text-based inspector - I'm a Mac user, and I like things to be visual and clickable, and I like to leave them on the screen for later.

* Much better debugging. MCL has a very nice backtrace which points you directly at the original source and allows you to inspect all of the frame locals. Tracing is much more featureful and single-stepping is integrated.

* It might be a small advantage to some, but the nicely apropos and documentation are a plus to me.

* And lastly, the editor (FRED, stands for Fred Resembles Emacs Deliberately) is - well - not emacs. I'm grateful to slime for allowing me to separate which of my frustrations were ilisp and which where emacs. It turns out too many were emacs. I dislike elisp, I'm constantly annoyed by its buffer management vs frame management schizophrenia, and I can't stand the nonsensical defaults that it seems to be plagued with. I like having one window per buffer, and one buffer per window.

I've put together a screenshot at http://shell.iddqd.org/~chandler/pictures/MCL-Big.png which shows off many of these features in action.

Now, does this mean that the open source lisps have no chance of catching up? On the contrary, I think it would be quite doable to create a Cocoa frontend for OS X which has most of these features - preferably separated from its lisp backend ala SLIME / SWANK. Cocoa's text widgets already come with a lot of emacs built in, the freeware TextExtras adds even more emacs keybindings, and the rest (like sexpr editing and indentation) can be written and integrated. Thus there's no real need to actually implement an editor. The rest is just a Simple Matter Of Programming. If anyone wants to help, just shoot me an email :-)

Whoops! "nicely apropos" above should read "nicely done apropos".

BTW, if people are more interested in doing such a frontend in GTK2 than a single-platform Cocoa implementation, I'm game for that too.

For the Ediwho asked, the thing that puts Allegro over the open source lisps (at least over the CMUCL family, which I'm most familiar with) is the sophistication and flexibility of the interactive debugger. As Edi says, "we all know its price," but the lisp market is tiny and they've gotta eat.

I just wish they'd change the runtime licensing terms so it wasn't prohibitively expensive to deliver an application in lisp. I've been thinking about developing in Allegro and delivering in CMUCL for that reason....

What about a wxWindows binding?

wxWindows bindings IMHO would be real nice. Someone even thought of doing them. A nice example of how it should not be done - wrote like 40 pages of ideas and documentation, wrote ~1kb of source and the project is abandoned for like a year now :(.

This has been a big issue on my mind at the moment. I am shifting between the cheaper Corman LISP and Allegro, and was wondering - would it be possible to develop in Allegro and then deploy the final application in a free lisp implementation to avoid runtime issues? Or are there too many porting issues involved to do this? Is CLIM itself tied down by licensing as well?
Eric