0.pre7.45:
[sbcl.git] / BUGS
diff --git a/BUGS b/BUGS
index fd5ebfc..00127a1 100644 (file)
--- a/BUGS
+++ b/BUGS
@@ -387,18 +387,6 @@ WORKAROUND:
        c: SYMBOL-MACROLET should signal PROGRAM-ERROR if something
           it binds is declared SPECIAL inside.
 
-49:
-  LOOP bugs reported by Peter Van Eynde July 25, 2000:
-       a: (LOOP WITH (A B) DO (PRINT 1)) is a syntax error according to
-          the definition of WITH clauses given in the ANSI spec, but
-          compiles and runs happily in SBCL.
-       b: a messy one involving package iteration:
-interpreted Form: (LET ((PACKAGE (MAKE-PACKAGE "LOOP-TEST"))) (INTERN "blah" PACKAGE) (LET ((BLAH2 (INTERN "blah2" PACKAGE))) (EXPORT BLAH2 PACKAGE)) (LIST (SORT (LOOP FOR SYM BEING EACH PRESENT-SYMBOL OF PACKAGE FOR SYM-NAME = (SYMBOL-NAME SYM) COLLECT SYM-NAME) (FUNCTION STRING<)) (SORT (LOOP FOR SYM BEING EACH EXTERNAL-SYMBOL OF PACKAGE FOR SYM-NAME = (SYMBOL-NAME SYM) COLLECT SYM-NAME) (FUNCTION STRING<))))
-Should be: (("blah" "blah2") ("blah2"))
-SBCL: (("blah") ("blah2"))
-       * (LET ((X 1)) (LOOP FOR I BY (INCF X) FROM X TO 10 COLLECT I))
-         doesn't work -- SBCL's LOOP says BY isn't allowed in a FOR clause.
-
 50:
   type system errors reported by Peter Van Eynde July 25, 2000:
        a: (SUBTYPEP 'BIGNUM 'INTEGER) => NIL, NIL
@@ -709,17 +697,6 @@ Error in function C::GET-LAMBDA-TO-COMPILE:
 80:
   (fixed early Feb 2001 by MNA)
 
-81:
-  As reported by wbuss@TELDA.NET (Wolfhard Buss) on cmucl-help
-  2001-02-14, 
-    According to CLHS
-        (loop with (a . b) of-type float = '(0.0 . 1.0)
-          and (c . d) of-type float = '(2.0 . 3.0)
-          return (list a b c d))
-    should evaluate to (0.0 1.0 2.0 3.0). cmucl-18c disagrees and
-    invokes the debugger: "B is not of type list".
-  SBCL does the same thing.
-
 82: 
   Functions are assigned names based on the context in which they're
   defined. This is less than ideal for the functions which are
@@ -1240,64 +1217,32 @@ Error in function C::GET-LAMBDA-TO-COMPILE:
    but actual specification quoted above says that the actual behavior
    is undefined.
 
+125:
+   (as reported by Gabe Garza on cmucl-help 2001-09-21)
+       (defvar *tmp* 3)
+       (defun test-pred (x y)
+         (eq x y))
+       (defun test-case ()
+         (let* ((x *tmp*)
+                (func (lambda () x)))
+           (print (eq func func))
+           (print (test-pred func func))
+           (delete func (list func))))
+   Now calling (TEST-CASE) gives output
+     NIL
+     NIL
+     (#<FUNCTION {500A9EF9}>)
+   Evidently Python thinks of the lambda as a code transformation so
+   much that it forgets that it's also an object.
+
+126:
+  (fixed in 0.pre7.41)
+
+
 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.
+(Now that the IR1 interpreter has gone away, these should be 
+relatively straightforward to fix.)
 
 IR1-4:
   The system accepts DECLAIM in most places where DECLARE would be