October 28th 2004 #
random, October 28th 2004
SBCL 0.8.16 has been released, including a loop analysis code and a better register allocator by Juho Snellman. Meanwhile Christophe Rhodes is slowly merging the unicode branch to HEAD; I think I'll have to get meself an UTF-8 terminal. ;-)
A short while back the question "Why SBCL isn't at 1.0 yet?" was raised on comp.lang.lisp — albeit indirectly. My own views largely parallel the points made by CSR in the thread, but let me pontificate a bit...
What does 1.0 mean?
As a user I want to be relatively confident that as long I use documented interfaces my code won't break across minor revisions, and while I'd be fine with most new features appearing on an unstable branch I would expect bugfixes to be backported. Some measure of fasl-compatibility would be appreciated, though that isn't a really big issue for me personally.
As a developer I want to be relatively confident that these expectations can be catered to with a reasonable effort while continuing development of fancy features on the unstable branch. This requires among other things some degree of experience with the various interfaces: no better way to tell if what seemed like an inspired idea was really a brainfart. Additionally, major features (like XREF) should IMO be in place for 1.0 — otherwise people who really should be using the stable version will gravitate to the unstable one like bees drawn by honey.
As exemplified by this excerpt from today's commit messages, none of this is really the case yet:
0.8.16.11: Partial fix for #318 & more incompatible changes
* Robustify STYLE-WARNINGs and compiler messages
against circular objects and other nasties.
* In the process replace *COMPILER-ERROR-PRINT-FOO* with
*COMPILER-PRINT-VARIABLE-ALIST*, remove support for
already depracated *DEBUG-PRINT-FOO*s and move both
printer control alists to SB-EXT.
* Update the fine manual.
Deciphered, that means two incompatible changes to fix a questionable bug, and a new exported interface...
Of course, none of this should stop you from using SBCL, quite the opposite: as far as performance, ANSI conformance and stability in the sense of "not crashing" goes everything is pretty much the way it should be.