Peter Seibel <peter@javamonkey.com> writes:

I'm getting to the point in the work on my book that I'm starting to think in detail about packaging code for the accompanying CD, etc. I'm planning to use some version of the Lisp In A Box package that Matthew Danish and Mikel Evins have been working on which features SLIME heavily. I'll also be using SLIME as my example of a Lisp development environment, talking about it in the text.

I guess this means that the book is almost complete. Anyway, granulations for the good work!

So, the question is, what version of SLIME do I use?

I've only been loosely paying attention--have there been any changes since 1.0 that I'll want? (I've been running CVS head for pretty much forever). Are there any plans for a 1.1 or 1.0.1 or whatever?

We haven't made any plans for the next release yet. So it's probably best to stick with 1.0. The most annoying bug in the release I'm aware of is that the macro expansion commands use the wrong package. The major new feature since the release is the new inspector and I think Alan added a lot of nice stuff for OpenMCL. There where some other improvements, but I think they're are not essential.

Also, is there anything that Franz could do to help us make SLIME better on Allegro? Since they're the ones who started this book project, the accompanying CD will probably contain a version of Allegro for Linux, Windows, and OS X. Are there any features of SLIME that are missing or lame on Allegro compared to other Lisp's? If there's any low-hanging fruit that could be picked off with a bit of cooperation from the folks at Franz maybe I can talk to them about it.

I don't use Allegro much and so I don't know so well what's missing. In general, it would be very nice if some Franz developer could join our mailing list and occasionally comment on our doings. I'm very glad that the implementors of other Lisps do that and their input is very valuable. Thank you guys! More specifically, Franz could probably write a much better implementation of list-callers without much effort. There is currently a nasty reference to excl::external-fn_symdef in swank-allegro. Clearly, there must be a better way to access the docstrings of functions. It would also be nice if our inspector could show the same stuff like Allegro's native inspector. Perhaps they could document the internal inspector interface, so that we don't have to use disassemble so frequently ;-).

FWIW, I'm also planning to provide SBCL for Linux and OS X, OpenMCL for OS X, and perhaps CLISP for all three platforms. (Unless either a Windows port of SBCL or CMUCL shows up in the near future.) So if there any notable SLIME defficiencies on any of those platforms that I should be aware of, feel free to let me know.

I think SBCL and OpenMCL work quite well SLIME. CLISP support is IMO rather shaky. The most serious problem with CLISP is that M-. is almost useless. I don't expect this to change, since CLISP implementor seem to use grep or etags.

Finally, are there any major holes in the current SLIME docs? I may be able to help plug them if there are so I can just refer folks to SLIME docs rather than having to explain everything in the book text proper.

The SLIME docs are clearly written for experienced Emacs users and may not be so well suited for Emacs beginners. I don't know if that's a problem for your audience. I quite like it the way it is. I think the manual does currently not explain how SLIME finds the value for *package*. There's also not much explanation how multi-threading works with SLIME. I guess that could be important for people who dare to use threads. It would also be good to give some general advice, e.g., that you really should configure the pretty printer. Also, there seems to be an endless confusion about indentation in general. Maybe someone with good writing skills could explain it, because it is actually quite simple. I would also like to see a section about how to write SLIME commands, e.g., a command that computes something in CL and displays the result in an Emacs buffers. Such little commands are very easy to write but can be tremendously useful. Helmut.