From c7468ce98233e22d968b8a740743b4bac9ea2c5a Mon Sep 17 00:00:00 2001 From: William Harold Newman Date: Thu, 16 Aug 2001 13:59:55 +0000 Subject: [PATCH] 0.pre7.12: redid DEFCONSTANT-EQX to be less needlessly arcane --- BUGS | 15 +++++++++ src/code/primordial-extensions.lisp | 61 ++++++++++------------------------- src/cold/ansify.lisp | 28 ++++++++-------- version.lisp-expr | 2 +- 4 files changed, 46 insertions(+), 60 deletions(-) diff --git a/BUGS b/BUGS index fb6a143..5566b79 100644 --- a/BUGS +++ b/BUGS @@ -1098,6 +1098,21 @@ Error in function C::GET-LAMBDA-TO-COMPILE: your pre-0.7.0 state of grace with #+sbcl (declaim (notinline find position find-if position-if)) ; bug 117.. +118: + as reported by Eric Marsden on cmucl-imp@cons.org 2001-08-14: + (= (FLOAT 1 DOUBLE-FLOAT-EPSILON) + (+ (FLOAT 1 DOUBLE-FLOAT-EPSILON) DOUBLE-FLOAT-EPSILON)) => T + when of course it should be NIL. (He says it only fails for X86, + not SPARC; dunno about Alpha.) + + Also, "the same problem exists for LONG-FLOAT-EPSILON, + DOUBLE-FLOAT-NEGATIVE-EPSILON, LONG-FLOAT-NEGATIVE-EPSILON (though + for the -negative- the + is replaced by a - in the test)." + + Raymond Toy comments that this is tricky on the X86 since its FPU + uses 80-bit precision internally. + + KNOWN BUGS RELATED TO THE IR1 INTERPRETER (Note: At some point, the pure interpreter (actually a semi-pure diff --git a/src/code/primordial-extensions.lisp b/src/code/primordial-extensions.lisp index 15b10b9..f78d9f8 100644 --- a/src/code/primordial-extensions.lisp +++ b/src/code/primordial-extensions.lisp @@ -237,48 +237,21 @@ ;;; structure for each object file which contains code referring to ;;; the value, plus perhaps one more copy bound to the SYMBOL-VALUE of ;;; the constant. If you don't want that to happen, you should -;;; probably use DEFPARAMETER instead. +;;; probably use DEFPARAMETER instead; or if you truly desperately +;;; need to avoid runtime indirection through a symbol, you might be +;;; able to do something with LOAD-TIME-VALUE or MAKE-LOAD-FORM. (defmacro defconstant-eqx (symbol expr eqx &optional doc) - (let ((expr-tmp (gensym "EXPR-TMP-"))) - `(progn - ;; When we're building the cross-compiler, and in most - ;; situations even when we're running the cross-compiler, - ;; all we need is a nice portable definition in terms of the - ;; ANSI Common Lisp operations. - (eval-when (:compile-toplevel :load-toplevel :execute) - (let ((,expr-tmp ,expr)) - (cond ((boundp ',symbol) - (unless (and (constantp ',symbol) - (funcall ,eqx - (symbol-value ',symbol) - ,expr-tmp)) - (error "already bound differently: ~S"))) - (t - (defconstant ,symbol - ;; KLUDGE: This is a very ugly hack, to be able to - ;; build SBCL with CMU CL (2.4.19), because there - ;; seems to be some confusion in CMU CL about - ;; ,EXPR-TEMP at EVAL-WHEN time ... -- MNA 2000-02-23 - #-cmu ,expr-tmp - #+cmu ,expr - ,@(when doc `(,doc))))))) - ;; The #+SB-XC :COMPILE-TOPLEVEL situation is special, since we - ;; want to define the symbol not just in the cross-compilation - ;; host Lisp (which was handled above) but also in the - ;; cross-compiler (which we will handle now). - ;; - ;; KLUDGE: It would probably be possible to do this fairly - ;; cleanly, in a way parallel to the code above, if we had - ;; SB!XC:FOO versions of all the primitives CL:FOO used above - ;; (e.g. SB!XC:BOUNDP, SB!XC:SYMBOL-VALUE, and - ;; SB!XC:DEFCONSTANT), and took care to call them. But right - ;; now we just hack around in the guts of the cross-compiler - ;; instead. -- WHN 2000-11-03 - #+sb-xc - (eval-when (:compile-toplevel) - (let ((,expr-tmp ,symbol)) - (unless (and (eql (info :variable :kind ',symbol) :constant) - (funcall ,eqx - (info :variable :constant-value ',symbol) - ,expr-tmp)) - (sb!c::%defconstant ',symbol ,expr-tmp ,doc))))))) + `(defconstant ,symbol + (%defconstant-eqx-value ',symbol ,expr ,eqx) + ,@(when doc (list doc)))) +(defun %defconstant-eqx-value (symbol expr eqx) + (flet ((bummer (explanation) + (error "~@" symbol explanation))) + (cond ((not (boundp symbol)) + expr) + ((not (constantp symbol)) + (bummer "already bound as a non-constant")) + ((not (funcall eqx (symbol-value symbol) expr)) + (bummer "already bound as a different constant value")) + (t + (symbol-value symbol))))) diff --git a/src/cold/ansify.lisp b/src/cold/ansify.lisp index f08332e..31cf9fb 100644 --- a/src/cold/ansify.lisp +++ b/src/cold/ansify.lisp @@ -35,15 +35,13 @@ (error "can't use CLISP -- no (FUNCTION (SETF SYMBOL-FUNCTION))") ) -;;; CMU CL, at least as of 18b, doesn't support PRINT-OBJECT. In particular, it -;;; refuses to compile :PRINT-OBJECT options to DEFSTRUCT, so we need to -;;; conditionalize such options on the :NO-ANSI-PRINT-OBJECT feature in order -;;; to get the code to compile. (It also fails to do anything useful with -;;; DEFMETHOD PRINT-OBJECT, but that doesn't matter much, since it doesn't stop -;;; the cross-compiler from working.) -;;; -;;; FIXME: SBCL 0.5.0 doesn't support PRINT-OBJECT either. SBCL 0.6.0 will, -;;; at which time this conditional should go away. +;;; CMU CL, at least as of 18b, doesn't support PRINT-OBJECT. In +;;; particular, it refuses to compile :PRINT-OBJECT options to +;;; DEFSTRUCT, so we need to conditionalize such options on the +;;; :NO-ANSI-PRINT-OBJECT feature in order to get the code to compile. +;;; (It also fails to do anything useful with DEFMETHOD PRINT-OBJECT, +;;; but that doesn't matter much, since it doesn't stop the +;;; cross-compiler from working.) #+cmu (progn (warn "CMU CL doesn't support the :PRINT-OBJECT option to DEFSTRUCT.~%") @@ -60,16 +58,16 @@ ;;; /(READ-SEQUENCE *BUFFER* S :START 0 :END 3000)=3000 ;;; /(READ-SEQUENCE *BUFFER* S :START 0 :END 15000)=1096 ;;; /(READ-SEQUENCE *BUFFER* S :START 0 :END 15000)=0 -#+cmu ; FIXME: Remove SBCL once we've patched READ-SEQUENCE. +#+cmu (progn (warn "CMU CL has a broken implementation of READ-SEQUENCE.") (pushnew :no-ansi-read-sequence *features*)) -;;; Do the exports of COMMON-LISP conform to the standard? If not, try to make -;;; them conform. (Of course, ANSI says that bashing symbols in the COMMON-LISP -;;; package like this is undefined, but then if the host Common Lisp were ANSI, -;;; we wouldn't be doing this, now would we? "One dirty unportable hack -;;; deserves another.":-) +;;; Do the exports of COMMON-LISP conform to the standard? If not, try +;;; to make them conform. (Of course, ANSI says that bashing symbols +;;; in the COMMON-LISP package like this is undefined, but then if the +;;; host Common Lisp were ANSI, we wouldn't be doing this, now would +;;; we? "One dirty unportable hack deserves another.":-) (let ((standard-ht (make-hash-table :test 'equal)) (host-ht (make-hash-table :test 'equal)) (cl (find-package "COMMON-LISP"))) diff --git a/version.lisp-expr b/version.lisp-expr index 058e9ec..7a49182 100644 --- a/version.lisp-expr +++ b/version.lisp-expr @@ -16,4 +16,4 @@ ;;; four numeric fields, is used for versions which aren't released ;;; but correspond only to CVS tags or snapshots. -"0.pre7.11" +"0.pre7.12" -- 1.7.10.4