+54:
+ The implementation of #'+ returns its single argument without
+ type checking, e.g. (+ "illegal") => "illegal".
+
+55:
+ In sbcl-0.6.7, there is no doc string for CL:PUSH, probably
+ because it's defined with the DEFMACRO-MUNDANELY macro and something
+ is wrong with doc string setting in that macro.
+
+56:
+ Attempting to use COMPILE on something defined by DEFMACRO fails:
+ (DEFMACRO FOO (X) (CONS X X))
+ (COMPILE 'FOO)
+Error in function C::GET-LAMBDA-TO-COMPILE:
+ #<Closure Over Function "DEFUN (SETF MACRO-FUNCTION)" {480E21B1}> was defined in a non-null environment.
+
+58:
+ (SUBTYPEP '(AND ZILCH INTEGER) 'ZILCH)
+ => NIL, NIL
+
+59:
+ CL:*DEFAULT-PATHNAME-DEFAULTS* doesn't behave as ANSI suggests (reflecting
+ current working directory). And there's no supported way to update
+ or query the current working directory (a la Unix "chdir" and "pwd"),
+ which is functionality that ILISP needs (and currently gets with low-level
+ hacks).
+
+60:
+ The debugger LIST-LOCATIONS command doesn't work properly.
+
+61:
+ Compiling and loading
+ (DEFUN FAIL (X) (THROW 'FAIL-TAG X))
+ (FAIL 12)
+ then requesting a BACKTRACE at the debugger prompt gives no information
+ about where in the user program the problem occurred.
+
+62:
+ The compiler is supposed to do type inference well enough that
+ the declaration in
+ (TYPECASE X
+ ((SIMPLE-ARRAY SINGLE-FLOAT)
+ (LOCALLY
+ (DECLARE (TYPE (SIMPLE-ARRAY SINGLE-FLOAT) X))
+ ..))
+ ..)
+ is redundant. However, as reported by Juan Jose Garcia Ripoll for
+ CMU CL, it sometimes doesn't. Adding declarations is a pretty good
+ workaround for the problem for now, but can't be done by the TYPECASE
+ macros themselves, since it's too hard for the macro to detect
+ assignments to the variable within the clause.
+ Note: The compiler *is* smart enough to do the type inference in
+ many cases. This case, derived from a couple of MACROEXPAND-1
+ calls on Ripoll's original test case,
+ (DEFUN NEGMAT (A)
+ (DECLARE (OPTIMIZE SPEED (SAFETY 0)))
+ (COND ((TYPEP A '(SIMPLE-ARRAY SINGLE-FLOAT)) NIL
+ (LET ((LENGTH (ARRAY-TOTAL-SIZE A)))
+ (LET ((I 0) (G2554 LENGTH))
+ (DECLARE (TYPE REAL G2554) (TYPE REAL I))
+ (TAGBODY
+ SB-LOOP::NEXT-LOOP
+ (WHEN (>= I G2554) (GO SB-LOOP::END-LOOP))
+ (SETF (ROW-MAJOR-AREF A I) (- (ROW-MAJOR-AREF A I)))
+ (GO SB-LOOP::NEXT-LOOP)
+ SB-LOOP::END-LOOP))))))
+ demonstrates the problem; but the problem goes away if the TAGBODY
+ and GO forms are removed (leaving the SETF in ordinary, non-looping
+ code), or if the TAGBODY and GO forms are retained, but the
+ assigned value becomes 0.0 instead of (- (ROW-MAJOR-AREF A I)).
+
+
+KNOWN BUGS RELATED TO THE IR1 INTERPRETER
+
+(Note: At some point, the pure interpreter (actually a semi-pure
+interpreter aka "the IR1 interpreter") will probably go away, replaced
+by constructs like
+ (DEFUN EVAL (X) (FUNCALL (COMPILE NIL (LAMBDA ..)))))
+and at that time these bugs should either go away automatically or
+become more tractable to fix. Until then, they'll probably remain,
+since some of them aren't considered urgent, and the rest are too hard
+to fix as long as so many special cases remain. After the IR1
+interpreter goes away is also the preferred time to start
+systematically exterminating cases where debugging functionality
+(backtrace, breakpoint, etc.) breaks down, since getting rid of the
+IR1 interpreter will reduce the number of special cases we need to
+support.)
+
+IR1-1:
+ The FUNCTION special operator doesn't check properly whether its
+ argument is a function name. E.g. (FUNCTION (X Y)) returns a value
+ instead of failing with an error. (Later attempting to funcall the
+ value does cause an error.)
+
+IR1-2:
+ COMPILED-FUNCTION-P bogusly reports T for interpreted functions:
+ * (DEFUN FOO (X) (- 12 X))
+ FOO
+ * (COMPILED-FUNCTION-P #'FOO)
+ T
+
+IR1-3:
+ Executing
+ (DEFVAR *SUPPRESS-P* T)
+ (EVAL '(UNLESS *SUPPRESS-P*
+ (EVAL-WHEN (:COMPILE-TOPLEVEL :LOAD-TOPLEVEL :EXECUTE)
+ (FORMAT T "surprise!"))))
+ prints "surprise!". Probably the entire EVAL-WHEN mechanism ought to be
+ rewritten from scratch to conform to the ANSI definition, abandoning
+ the *ALREADY-EVALED-THIS* hack which is used in sbcl-0.6.8.9 (and
+ in the original CMU CL source, too). This should be easier to do --
+ though still nontrivial -- once the various IR1 interpreter special
+ cases are gone.
+
+IR1-3a:
+ EVAL-WHEN's idea of what's a toplevel form is even more screwed up
+ than the example in IR1-3 would suggest, since COMPILE-FILE and
+ COMPILE both print both "right now!" messages when compiling the
+ following code,
+ (LAMBDA (X)
+ (COND (X
+ (EVAL-WHEN (:COMPILE-TOPLEVEL :LOAD-TOPLEVEL :EXECUTE)
+ (PRINT "yes! right now!"))
+ "yes!")
+ (T
+ (EVAL-WHEN (:COMPILE-TOPLEVEL :LOAD-TOPLEVEL :EXECUTE)
+ (PRINT "no! right now!"))
+ "no!")))
+ and while EVAL doesn't print the "right now!" messages, the first
+ FUNCALL on the value returned by EVAL causes both of them to be printed.