0.9.2.43:
[sbcl.git] / src / cold / ansify.lisp
index 25b957c..901286d 100644 (file)
@@ -68,7 +68,7 @@
   (warn "CMU CL has a broken implementation of READ-SEQUENCE.")
   (pushnew :no-ansi-read-sequence *features*))
 
-;;; This is apparently quite old, according to 
+;;; This is apparently quite old, according to
 ;;; <http://tunes.org/~nef/logs/lisp/03.10.22>:
 ;;;   <dan`b> (error "CMUCL on Alpha can't read floats in the format \"1.0l0\".
 ;;;   <dan`b> the warning relates to a random vinary produced from cvs of
@@ -84,8 +84,8 @@
 ;;;; OpenMCL issues
 
 ;;; This issue in OpenMCL led to some SBCL bug reports ca. late 2003.
-#+openmcl 
-(unless (ignore-errors (funcall (constantly t) 1 2 3)) 
+#+openmcl
+(unless (ignore-errors (funcall (constantly t) 1 2 3))
   (error "please find a binary that understands CONSTANTLY to build from"))
 \f
 ;;;; general non-ANSI-ness
@@ -95,7 +95,7 @@
 (defmacro munging-cl-package (&body body)
   #-clisp `(progn ,@body)
   #+clisp `(ext:without-package-lock ("CL")
-            ,@body))
+             ,@body))
 
 ;;; Do the exports of COMMON-LISP conform to the standard? If not, try
 ;;; to make them conform. (Of course, ANSI says that bashing symbols
 ;;; 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")))
+      (cl         (find-package "COMMON-LISP")))
   (do-external-symbols (i cl)
     (setf (gethash (symbol-name i) host-ht) t))
   (dolist (i (read-from-file "common-lisp-exports.lisp-expr"))
     (setf (gethash i standard-ht) t))
   (maphash (lambda (key value)
-            (declare (ignore value))
-            (unless (gethash key standard-ht)
-              (warn "removing non-ANSI export from package CL: ~S" key)
-              (munging-cl-package
-               (unexport (intern key cl) cl))))
-          host-ht)
+             (declare (ignore value))
+             (unless (gethash key standard-ht)
+               (warn "removing non-ANSI export from package CL: ~S" key)
+               (munging-cl-package
+                (unexport (intern key cl) cl))))
+           host-ht)
   (maphash (lambda (key value)
-            (declare (ignore value))
-            (unless (gethash key host-ht)
-              (warn "adding required-by-ANSI export to package CL: ~S" key)
-              (munging-cl-package 
-               (export (intern key cl) cl)))
-            
-            ;; FIXME: My righteous indignation below was misplaced. ANSI sez
-            ;; (in 11.1.2.1, "The COMMON-LISP Package") that it's OK for
-            ;; COMMON-LISP things to have their home packages elsewhere.
-            ;; For now, the hack below works, but it's not good to rely
-            ;; on this nonstandardness. Ergo, I should fix things so that even
-            ;; when the cross-compilation host COMMON-LISP package has
-            ;; symbols with home packages elsewhere, genesis dumps out
-            ;; the correct stuff. (For each symbol dumped, check whether it's
-            ;; exported from COMMON-LISP, and if so, dump it as though its
-            ;; home package is COMMON-LISP regardless of whether it actually
-            ;; is. I think..)
-            ;;
-            ;; X CMU CL, at least the Debian versions ca. 2.4.9 that I'm
-            ;; X using as I write this, plays a sneaky trick on us by
-            ;; X putting DEBUG and FLOATING-POINT-INEXACT in the
-            ;; X EXTENSIONS package, then IMPORTing them into
-            ;; X COMMON-LISP, then reEXPORTing them from COMMON-LISP.
-            ;; X This leaves their home packages bogusly set to
-            ;; X EXTENSIONS, which confuses genesis into thinking that
-            ;; X the CMU CL EXTENSIONS package has to be dumped into the
-            ;; X target SBCL. (perhaps a last-ditch survival strategy
-            ;; X for the CMU CL "nooo! don't bootstrap from scratch!"
-            ;; X meme?) As far as I can see, there's no even slightly
-            ;; X portable way to undo the damage, so we'll play the "one
-            ;; X dirty unportable hack deserves another" game, only even
-            ;; X dirtierly and more unportably than before..
-            #+cmu
-            (let ((symbol (intern key cl)))
-              (unless (eq (symbol-package symbol) cl)
-                (warn "using low-level hack to move ~S from ~S to ~S"
-                      symbol
-                      (symbol-package symbol)
-                      cl)
-                (kernel:%set-symbol-package symbol cl))))
-          standard-ht))
+             (declare (ignore value))
+             (unless (gethash key host-ht)
+               (warn "adding required-by-ANSI export to package CL: ~S" key)
+               (munging-cl-package
+                (export (intern key cl) cl)))
+
+             ;; FIXME: My righteous indignation below was misplaced. ANSI sez
+             ;; (in 11.1.2.1, "The COMMON-LISP Package") that it's OK for
+             ;; COMMON-LISP things to have their home packages elsewhere.
+             ;; For now, the hack below works, but it's not good to rely
+             ;; on this nonstandardness. Ergo, I should fix things so that even
+             ;; when the cross-compilation host COMMON-LISP package has
+             ;; symbols with home packages elsewhere, genesis dumps out
+             ;; the correct stuff. (For each symbol dumped, check whether it's
+             ;; exported from COMMON-LISP, and if so, dump it as though its
+             ;; home package is COMMON-LISP regardless of whether it actually
+             ;; is. I think..)
+             ;;
+             ;; X CMU CL, at least the Debian versions ca. 2.4.9 that I'm
+             ;; X using as I write this, plays a sneaky trick on us by
+             ;; X putting DEBUG and FLOATING-POINT-INEXACT in the
+             ;; X EXTENSIONS package, then IMPORTing them into
+             ;; X COMMON-LISP, then reEXPORTing them from COMMON-LISP.
+             ;; X This leaves their home packages bogusly set to
+             ;; X EXTENSIONS, which confuses genesis into thinking that
+             ;; X the CMU CL EXTENSIONS package has to be dumped into the
+             ;; X target SBCL. (perhaps a last-ditch survival strategy
+             ;; X for the CMU CL "nooo! don't bootstrap from scratch!"
+             ;; X meme?) As far as I can see, there's no even slightly
+             ;; X portable way to undo the damage, so we'll play the "one
+             ;; X dirty unportable hack deserves another" game, only even
+             ;; X dirtierly and more unportably than before..
+             #+cmu
+             (let ((symbol (intern key cl)))
+               (unless (eq (symbol-package symbol) cl)
+                 (warn "using low-level hack to move ~S from ~S to ~S"
+                       symbol
+                       (symbol-package symbol)
+                       cl)
+                 (kernel:%set-symbol-package symbol cl))))
+           standard-ht))