Christophe Rhodes csr21@cam.ac.uk writes:
There's a load of complicated code in swank-sbcl.lisp that I'd just love to break on the grounds that no-one asked me for PERMISSION to use MY symbols... on the other hand, I can imagine hordes of angry lispers turning up in London (or Cambridge, at the weekend ;-) and lynching me if I've broken their SLIME 1.0.
I've given this some more thought. I think it's highly likely that SLIME 1.0 will be broken pretty quickly due to changes to Lisp internals that it pokes around in, either SBCL or some other Lisp.
Let's accept that. When you upgrade your Lisp there'll be a chance that you have to upgrade SLIME too (and vice versa), and we'll need to stay on top of this so that we have a SLIME update ready and e.g. SBCL release notes can say "this doesn't work with SLIME before version foo."
These invariants are probably pretty realistic:
The latest SLIME works with the latest of each Lisp. Each Lisp release is compatible with some released version of SLIME.
Naturally we try to minimize breakages and make an honest mode of ourself by using supported interfaces in the future. Meanwhile if you want to update SLIME or Lisp then you may have to do both, just like when you do 'cvs update' today :-)
This would suggest we be careful of which packaging systems we try to bundle 1.0 with. In e.g. Debian which handles dependencies and includes Lisp implementations is probably fine. Bundling with e.g. XEmacs is possibly not so fine, since most people don't want to upgrade Emacs as often as their Lisp. (Though perhaps their packaging system can handle this anyway.)
This should be okay for Peter's book. "Lisp in a Box" can include mutually compatible SLIME/Lisp releases and anyone who wants to download stuff themself can just grab the latest SLIME and Lisp off the 'net and plug them together.
That's my 2c for today anyway.
-Luke