Perhaps any number of such consecutive lines ought to turn into a
single "compiling top-level forms:" line.
-10:
- The way that the compiler munges types with arguments together
- with types with no arguments (in e.g. TYPE-EXPAND) leads to
- weirdness visible to the user:
- (DEFTYPE FOO () 'FIXNUM)
- (TYPEP 11 'FOO) => T
- (TYPEP 11 '(FOO)) => T, which seems weird
- (TYPEP 11 'FIXNUM) => T
- (TYPEP 11 '(FIXNUM)) signals an error, as it should
- 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 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
caught ERROR:
so they could be supported after all. Very likely
SIGCONTEXT-FLOATING-POINT-MODES could now be supported, too.
-43:
- (as discussed by Douglas Crosher on the cmucl-imp mailing list ca.
- Aug. 10, 2000): CMUCL currently interprets 'member as '(member); same
- issue with 'union, 'and, 'or etc. So even though according to the
- ANSI spec, bare 'MEMBER, 'AND, and 'OR are not legal types, CMUCL
- (and now SBCL) interpret them as legal types.
-
45:
a slew of floating-point-related errors reported by Peter Van Eynde
on July 25, 2000:
As a workaround for the problem, #'(SETF FOO) expressions can
be replaced with (EFFICIENT-SETF-FUNCTION FOO), where
(defmacro efficient-setf-function (place-function-name)
- (or #+sbcl (and (sb-impl::info :function :accessor-for place-function-name)
+ (or #+sbcl (and (sb-int:info :function :accessor-for place-function-name)
;; a workaround for the problem, encouraging the
;; inline expansion of the structure accessor, so
;; that the compiler can optimize its type test
a. On X86 an immediate operand for IMUL is printed incorrectly.
b. On X86 operand size prefix is not recognized.
-246: "NTH-VALUE scaling problem"
- NTH-VALUE's current implementation for constant integers scales in
- compile-time as O(n^4), as indeed must the optional dispatch
- mechanism on which it is implemented. While it is unlikely to
- matter in real user code, it's still unpleasant to observe that
- (NTH-VALUE 1000 (VALUES-LIST (MAKE-LIST 1001))) takes several hours
- to compile.
-
248: "reporting errors in type specifier syntax"
(TYPEP 1 '(SYMBOL NIL)) says something about "unknown type
specifier".
* bug fix: defining a generic function with a :METHOD-CLASS being a
subclass of STANDARD-METHOD no longer causes stack exhaustion.
(thanks to Gerd Moellmann)
- * increased compilation speed of long MULTIPLE-VALUES-BIND.
+ * fixed bug 246: increased compilation speed of long
+ MULTIPLE-VALUE-BIND (and likewise of NTH-VALUE with a constant
+ integer argument).
* a contributed module implementing COMPILER-LET and MACROEXPAND-ALL
has been included.
* DEFCONSTANT now throws a condition of type
Raymond Toy)
* bug fix: in macro-like defining macros/special operators the
implicit block does not enclose lambda list.
+ * fixed bugs 10 and 43: VALUES, AND, OR and MEMBER are not suitable as
+ atomic type specifiers, and their use properly signals an error now.
+ * bug fix: an argument count mismatch for a type specifier in code
+ being compiled no longer causes an unhandled error at compile
+ time, but signals a compile-time warning.
* fixed some bugs revealed by Paul Dietz' test suite:
** NIL is now allowed as a structure slot name.
** arbitrary numbers, not just reals, are allowed in certain
(or (built-in-classoid-translation spec) spec)
spec))
(t
- (let* (;; FIXME: This automatic promotion of FOO-style
- ;; specs to (FOO)-style specs violates the ANSI
- ;; standard. Unfortunately, we can't fix the
- ;; problem just by removing it, since then things
- ;; downstream should break. But at some point we
- ;; should fix this and the things downstream too.
- (lspec (if (atom spec) (list spec) spec))
+ (when (and (atom spec)
+ (member spec '(and or not member eql satisfies values)))
+ (error "The symbol ~S is not valid as a type specifier." spec))
+ (let* ((lspec (if (atom spec) (list spec) spec))
(fun (info :type :translator (car lspec))))
(cond (fun
(funcall fun lspec))
`(progn
(defun ,careful (specifier)
(handler-case (,basic specifier)
+ (sb!kernel::arg-count-error (condition)
+ (values nil (list (format nil "~A" condition))))
(simple-error (condition)
(values nil (list* (simple-condition-format-control condition)
(simple-condition-format-arguments condition))))))
(assert-nil-nil (subtypep '(vector t) '(vector utype-2)))
;;; ANSI specifically disallows bare AND and OR symbols as type specs.
-#| ; Alas, this is part of bug 10, still unfixed as of sbcl-0.7.2.
(assert (raises-error? (typep 11 'and)))
(assert (raises-error? (typep 11 'or)))
-|#
+(assert (raises-error? (typep 11 'member)))
+(assert (raises-error? (typep 11 'values)))
+(assert (raises-error? (typep 11 'eql)))
+(assert (raises-error? (typep 11 'satisfies)))
+(assert (raises-error? (typep 11 'not)))
+
;;; Of course empty lists of subtypes are still OK.
(assert (typep 11 '(and)))
(assert (not (typep 11 '(or))))
;;; checkins which aren't released. (And occasionally for internal
;;; versions, especially for internal versions off the main CVS
;;; branch, it gets hairier, e.g. "0.pre7.14.flaky4.13".)
-"0.8.0.61"
+"0.8.0.62"
projects / sbcl.git / commitdiff