-called SAVE-LISP-AND-DIE instead of SAVE-LISP, and SBCL's
-SAVE-LISP-AND-DIE supports fewer keyword options than CMU CL's
-SAVE-LISP does.
-
-(Why doesn't SBCL support more extensions? Why drop all those nice
-extensions from CMU CL when the code already exists? This is a
-frequently asked question on the mailing list. In other cases, it's a
-design philosophy issue: arguably SBCL has done its job by supplying a
-stable FFI, and the right design decision is to move functionality
-derived from that, like socket support, into separate libraries,
-distributed as separate software packages by separate maintainers. In
-other cases it's a practical decision, hoping that focusing on a
-smaller number of things will let us do a better job on them. This is
-very much the case for multithreading: it's an important, valuable
-extension, but it's not easy to get right, and especially while SBCL
-is still working on basic ANSI compliance, difficult extensions aren't
-likely to be a priority.)
+called SAVE\-LISP\-AND\-DIE instead of SAVE\-LISP, and SBCL's
+SAVE\-LISP\-AND\-DIE supports fewer keyword options than CMU CL's
+SAVE\-LISP does.
+
+(Why doesn't SBCL support more extensions natively? Why drop all
+those nice extensions from CMU CL when the code already exists? This
+is a frequently asked question on the mailing list. There are two
+principal reasons. First, it's a design philosophy issue: arguably
+SBCL has done its job by supplying a stable FFI, and the right design
+decision is to move functionality derived from that, like socket
+support, into separate libraries. Some of these are distributed with
+SBCL as "contrib" modules, others are distributed as separate software
+packages by separate maintainers. Second, it's a practical decision -
+focusing on a smaller number of things will, we hope, let us do a
+better job on them.)