Perhaps any number of such consecutive lines ought to turn into a
single "byte compiling top-level forms:" line.
-9:
- The handling of IGNORE declarations on lambda list arguments of
- DEFMETHOD is at least weird, and in fact seems broken and useless.
- I should fix up another layer of binding, declared IGNORABLE, for
- typed lambda list arguments.
-
10:
The way that the compiler munges types with arguments together
with types with no arguments (in e.g. TYPE-EXPAND) leads to
The situation is complicated by the presence of Common Lisp types
like UNSIGNED-BYTE (which can either be used in list form or alone)
so I'm not 100% sure that the behavior above is actually illegal.
- But I'm 90+% sure, and someday perhaps I'll be motivated to look it up..
+ But I'm 90+% sure, and the following related behavior,
+ (TYPEP 11 'AND) => T
+ treating the bare symbol AND as equivalent to '(AND), is specifically
+ forbidden (by the ANSI specification of the AND type).
11:
It would be nice if the
to SBCL, I was looking for complexity to delete, and I thought it was safe
to just delete support for floating point infinities. It wasn't: they're
generated by the floating point hardware even when we remove support
- for them in software. -- WHN] Support for them should be restored.
+ for them in software. Also we claim the :IEEE-FLOATING-POINT feature,
+ and I think that means we should support infinities.-- WHN] Support
+ for them should be restored.
14:
The ANSI syntax for non-STANDARD method combination types in CLOS is
a secondary error "caught ERROR: unrecoverable error during compilation"
and then return with FAILURE-P true,
-25:
- from CMU CL mailing list 01 May 2000
-
-I realize I can take care of this by doing (proclaim (ignore pcl::.slots1.))
-but seeing as .slots0. is not-exported, shouldn't it be ignored within the
-+expansion
-when not used?
-
-In: DEFMETHOD FOO-BAR-BAZ (RESOURCE-TYPE)
- (DEFMETHOD FOO-BAR-BAZ
- ((SELF RESOURCE-TYPE))
- (SETF (SLOT-VALUE SELF 'NAME) 3))
---> BLOCK MACROLET PCL::FAST-LEXICAL-METHOD-FUNCTIONS
---> PCL::BIND-FAST-LEXICAL-METHOD-MACROS MACROLET
---> PCL::BIND-LEXICAL-METHOD-FUNCTIONS LET PCL::BIND-ARGS LET* PCL::PV-BINDING
---> PCL::PV-BINDING1 PCL::PV-ENV LET
-==>
- (LET ((PCL::.SLOTS0. #))
- (PROGN SELF)
- (BLOCK FOO-BAR-BAZ
- (LET #
- #)))
-Warning: Variable PCL::.SLOTS0. defined but never used.
-
-Compilation unit finished.
- 1 warning
-
-#<Standard-Method FOO-BAR-BAZ (RESOURCE-TYPE) {480918FD}>
-
26:
reported by Sam Steingold on the cmucl-imp mailing list 12 May 2000:
And as long as we're wishing, it would be awfully nice if INSPECT could
also report on closures, telling about the values of the bound variables.
-34:
- WHN test case: Compile this file:
- (eval-when (:compile-toplevel :load-toplevel :execute)
- (defclass a-class () (a)))
- (defconstant +a-constant+ (make-instance 'a-class))
- (defconstant +another-constant+ (vector +a-constant+))
- as reported by Robert Strandh on the CMU CL mailing list 12 Jun 2000:
- $ cat xx.lisp
- (defconstant +a-constant+ (make-instance 'a-class))
- (defconstant +another-constant+ (vector +a-constant+))
- $ lisp
- CMU Common Lisp release x86-linux 2.4.19 8 February 2000 build 456,
- running on
- bobby
- Send bug reports and questions to your local CMU CL maintainer,
- or to pvaneynd@debian.org
- or to cmucl-help@cons.org. (prefered)
- type (help) for help, (quit) to exit, and (demo) to see the demos
- Loaded subsystems:
- Python 1.0, target Intel x86
- CLOS based on PCL version: September 16 92 PCL (f)
- * (defclass a-class () ())
- #<STANDARD-CLASS A-CLASS {48027BD5}>
- * (compile-file "xx.lisp")
- Python version 1.0, VM version Intel x86 on 12 JUN 00 08:12:55 am.
- Compiling:
- /home/strandh/Research/Functional/Common-Lisp/CLIM/Development/McCLIM
- /xx.lisp 12 JUN 00 07:47:14 am
- Compiling Load Time Value of (PCL::GET-MAKE-INSTANCE-FUNCTION-SYMBOL
- '(A-CLASS NIL NIL)):
- Byte Compiling Top-Level Form:
- Error in function C::DUMP-STRUCTURE: Attempt to dump invalid
- structure:
- #<A-CLASS {4803A5B5}>
- How did this happen?
-
35:
The compiler assumes that any time a function of declared FTYPE
doesn't signal an error, its arguments were of the declared type.
files and make it share the same new safe logic.
80:
- The subtle CMU CL bug discussed by Douglas Thomas Crosher on
- cmucl-imp@cons.org 29 Jan 2001 sounds like something that probably
- still exists in the corresponding SBCL code.
-
+ (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
+ used to implement CLOS methods. E.g. the output of
+ (DESCRIBE 'PRINT-OBJECT) lists functions like
+ #<FUNCTION "DEF!STRUCT (TRACE-INFO (:MAKE-LOAD-FORM-FUN SB-KERNEL:JUST-DUMP-IT-NORMALLY) (:PRINT-OBJECT #))" {1020E49}>
+ and
+ #<FUNCTION "MACROLET ((FORCE-DELAYED-DEF!METHODS NIL #))" {1242871}>
+ It would be better if these functions' names always identified
+ them as methods, and identified their generic functions and
+ specializers.
+
+83:
+ RANDOM-INTEGER-EXTRA-BITS=10 may not be large enough for the RANDOM
+ RNG to be high quality near RANDOM-FIXNUM-MAX; it looks as though
+ the mean of the distribution can be systematically O(0.1%) wrong.
+ Just increasing R-I-E-B is probably not a good solution, since
+ it would decrease efficiency more than is probably necessary. Perhaps
+ using some sort of accept/reject method would be better.
KNOWN BUGS RELATED TO THE IR1 INTERPRETER