I consider the new release of SBCL (sbcl-0.6.0) to be alpha quality,
unstable but fairly usable.

Some changes in sbcl-0.6.0 relative to CMU CL include:
  * The system can bootstrap itself cleanly, unlike CMU CL, whose
    bootstrap process involves elements of mutating a running CMU CL
    into a new executable. Thus
    ** Arbitrarily large changes to SBCL can be made without having to
       set up special hacks to keep the changes from breaking the
       cross-compilation host. (Such bootstrapping issues are a
       fertile topic of conversation on the CMU CL list, but should
       not be interesting in SBCL.)
    ** The target system is completely described by the source code
       of the current version, without stealth contributions from
       the source code from previous versions. (It should not be
       interesting to "recompile the system with itself a few times
       until things settle down".)
  * There are some improvements in ANSI compliance (especially in the
    behavior of PRINT-OBJECT and STYLE-WARNING).
  * There are various other bug fixes.
  * Many non-ANSI extensions have been simplified, e.g. environment
    variable handling, options to COMPILE-FILE.
  * Many non-ANSI extensions have been cleaned up, e.g. i/o handling in
    the debugger.
  * Many non-ANSI extensions are no longer supported, e.g. sockets,
    X11, and the Hemlock editor.

The SBCL system is smaller than CMU CL, but as of 0.6.0 that doesn't
really show up in the size of compiled code, since the sbcl-0.6.0
core is entirely native code, while CMU CL uses byte compilation for
non-speed-critical code. "Entirely native code" sounds a little like a
feature, but it's really a bug, which will probably be fixed at some
point. Once SBCL can byte compile itself, the compiled code for SBCL
should become significantly smaller than CMU CL.

Version 0.6.0 of SBCL has a number of drawbacks compared to CMU CL:
  * It's almost certainly buggier, since it's an alpha release.
  * The system only runs on Linux/x86. (This isn't for any
    fundamental reason, only because no one has ported it.
    Porting SBCL should be comparable in difficulty to porting CMU CL;
    porting SBCL to an architecture already supported by CMU CL should
    be pretty easy.)
  * The documentation is not as good as CMU CL's. In particular, there
    is no SBCL user manual yet, only a man page and doc strings, so
    if you need user manual information, you have to refer to the
    CMU CL user manual.

Besides the particular shortcomings of version 0.6.0, SBCL will
probably always have some drawbacks compared with CMU CL:
  * SBCL doesn't try to be backwards compatible with most of the
    CMU CL non-ANSI extensions. (However, I have retained the FFI
    extensions, which are the fundamental building blocks for most of
    the other stuff; and I'd be happy to distribute ports of the other
    CMU CL extension packages as contrib/ code if someone else would
    like to maintain them. I just don't want to maintain them myself.)
  * I've been willing to simplify the system even at some cost to
    performance, so SBCL may be slower than CMU CL in some respects.
(E.g.,
    I've removed memory pooling in the compiler, so the SBCL compiler
conses
    more than CMU CL's; and the SBCL READ-SEQUENCE implementation has
fewer
    performance-oriented special cases than CMU CL's (and is hopefully
    less buggy, too:-).)
  * Despite my desire for simplicity, in some ways the SBCL code is
    necessarily more complicated than the CMU CL code, because SBCL
    maintains a clean separation between cross-compilation host and
    target system instead of sharing things opportunistically between
    them. I believe the benefits of this clean separation easily pay
    for the costs, but the costs are noticeable. (Common Lisp is not
    a cross-compiler-friendly language.:-)

As an aside to anyone who looked at the previous, pre-alpha version
(sbcl-0.5.0):
  The bootstrap process in the current version is less of a memory pig
  than in 0.5.0. In 0.6.0, bootstrapping takes on the order of 40 Mb
  through most of the build phase and peaks at a little under 128 Mb.
  The peak usage occurs in the "genesis" phase (static linking, more
  or less), which doesn't stress the virtual memory system very hard, so
  building the system works fine on my old laptop (P133 with 48 Mb of
  RAM and 128 Mb of swap).

SBCL is available at
        http://sbcl.sourceforge.net/
This site maintains mailing lists for SBCL, and SBCL-specific
discussion (e.g. "Can I run SBCL on a non-ELF system?" or "When are
you planning to make a user manual?") probably belongs there instead
of comp.lang.lisp.

  Bill Newman
  PGP key fingerprint 85 CE 1C BA 79 8D 51 8C  B9 25 FB EE E0 C3 E5 7C