+236: "THE semantics is broken"
+
+ (defun foo (a f)
+ (declare (optimize (speed 2) (safety 0)))
+ (+ 1d0
+ (the double-float
+ (multiple-value-prog1
+ (svref a 0)
+ (unless f (return-from foo 0))))))
+
+ (foo #(4) nil) => SEGV
+
+ VOP selection thinks that in unsafe code result type assertions
+ should be valid immediately. (See also bug 233a.)
+
+ The similar problem exists for TRULY-THE.
+
+237: "Environment arguments to type functions"
+ a. Functions SUBTYPEP, TYPEP, UPGRADED-ARRAY-ELEMENT-TYPE, and
+ UPGRADED-COMPLEX-PART-TYPE now have an optional environment
+ argument, but they ignore it completely. This is almost
+ certainly not correct.
+ b. Also, the compiler's optimizers for TYPEP have not been informed
+ about the new argument; consequently, they will not transform
+ calls of the form (TYPEP 1 'INTEGER NIL), even though this is
+ just as optimizeable as (TYPEP 1 'INTEGER).
+
+238: "REPL compiler overenthusiasm for CLOS code"
+ From the REPL,
+ * (defclass foo () ())
+ * (defmethod bar ((x foo) (foo foo)) (call-next-method))
+ causes approximately 100 lines of code deletion notes. Some
+ discussion on this issue happened under the title 'Three "interesting"
+ bugs in PCL', resulting in a fix for this oververbosity from the
+ compiler proper; however, the problem persists in the interactor
+ because the notion of original source is not preserved: for the
+ compiler, the original source of the above expression is (DEFMETHOD
+ BAR ((X FOO) (FOO FOO)) (CALL-NEXT-METHOD)), while by the time the
+ compiler gets its hands on the code needing compilation from the REPL,
+ it has been macroexpanded several times.
+
+241: "DEFCLASS mysteriously remembers uninterned accessor names."
+ (from tonyms on #lisp IRC 2003-02-25)
+ In sbcl-0.7.12.55, typing
+ (defclass foo () ((bar :accessor foo-bar)))
+ (profile foo-bar)
+ (unintern 'foo-bar)
+ (defclass foo () ((bar :accessor foo-bar)))
+ gives the error message
+ "#:FOO-BAR already names an ordinary function or a macro."
+ So it's somehow checking the uninterned old accessor name instead
+ of the new requested accessor name, which seems broken to me (WHN).
+
+242: "WRITE-SEQUENCE suboptimality"
+ (observed from clx performance)
+ In sbcl-0.7.13, WRITE-SEQUENCE of a sequence of type
+ (SIMPLE-ARRAY (UNSIGNED-BYTE 8) (*)) on a stream with element-type
+ (UNSIGNED-BYTE 8) will write to the stream one byte at a time,
+ rather than writing the sequence in one go, leading to severe
+ performance degradation.
+