[slime-devel] Re: SLIME User Survey

[Luke Gorrie]

Christophe Rhodes <csr21 at 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