X-Git-Url: http://repo.macrolet.net/gitweb/?a=blobdiff_plain;f=src%2Fcode%2Fcross-type.lisp;h=de7869a5c80f842498502ef323f901d98cecddef;hb=b8f63d9b4e978bec3bfc1f4fc471e5ed946781fd;hp=9e16a6faaa4abd24b8ce01428cb3db11dfd7f95e;hpb=a530bbe337109d898d5b4a001fc8f1afa3b5dc39;p=sbcl.git

diff --git a/src/code/cross-type.lisp b/src/code/cross-type.lisp
index 9e16a6f..de7869a 100644
--- a/src/code/cross-type.lisp
+++ b/src/code/cross-type.lisp
@@ -11,9 +11,6 @@
 
 (in-package "SB!IMPL")
 
-(file-comment
-  "$Header$")
-
 ;;; (This was a useful warning when trying to get bootstrapping
 ;;; to work, but it's mostly irrelevant noise now that the system
 ;;; works.)
@@ -39,21 +36,22 @@
 	    #+cmu :reader #+cmu #.(gensym) ; (to stop bogus non-STYLE WARNING)
 	    )))
 
-;;; This warning refers to the flexibility in the ANSI spec with regard to
-;;; run-time distinctions between floating point types. (E.g. the
-;;; cross-compilation host might not even distinguish between SINGLE-FLOAT and
-;;; DOUBLE-FLOAT, so a DOUBLE-FLOAT number would test positive as
-;;; SINGLE-FLOAT.) If the target SBCL does make this distinction, then
-;;; information is lost. It's not too hard to contrive situations where this
-;;; would be a problem. In practice we don't tend to run into them because all
-;;; widely used Common Lisp environments do recognize the distinction between
-;;; SINGLE-FLOAT and DOUBLE-FLOAT, and we don't really need the other
-;;; distinctions (e.g. between SHORT-FLOAT and SINGLE-FLOAT), so we call
-;;; WARN-POSSIBLE-CROSS-TYPE-FLOAT-INFO-LOSS to test at runtime whether
-;;; we need to worry about this at all, and not warn unless we do. If we *do*
-;;; have to worry about this at runtime, my (WHN 19990808) guess is that
-;;; the system will break in multiple places, so this is a real
-;;; WARNING, not just a STYLE-WARNING.
+;;; This warning refers to the flexibility in the ANSI spec with
+;;; regard to run-time distinctions between floating point types.
+;;; (E.g. the cross-compilation host might not even distinguish
+;;; between SINGLE-FLOAT and DOUBLE-FLOAT, so a DOUBLE-FLOAT number
+;;; would test positive as SINGLE-FLOAT.) If the target SBCL does make
+;;; this distinction, then information is lost. It's not too hard to
+;;; contrive situations where this would be a problem. In practice we
+;;; don't tend to run into them because all widely used Common Lisp
+;;; environments do recognize the distinction between SINGLE-FLOAT and
+;;; DOUBLE-FLOAT, and we don't really need the other distinctions
+;;; (e.g. between SHORT-FLOAT and SINGLE-FLOAT), so we call
+;;; WARN-POSSIBLE-CROSS-TYPE-FLOAT-INFO-LOSS to test at runtime
+;;; whether we need to worry about this at all, and not warn unless we
+;;; do. If we *do* have to worry about this at runtime, my (WHN
+;;; 19990808) guess is that the system will break in multiple places,
+;;; so this is a real WARNING, not just a STYLE-WARNING.
 ;;;
 ;;; KLUDGE: If we ever try to support LONG-FLOAT or SHORT-FLOAT, this
 ;;; situation will get a lot more complicated.
@@ -63,9 +61,10 @@
     (warn "possible floating point information loss in ~S" call)))
 
 (defun sb!xc:type-of (object)
-  (labels (;; FIXME: This function is a no-op now that we no longer have a
-	   ;; distinct package T%CL to translate for-the-target-Lisp CL symbols
-	   ;; to, and should go away completely.
+  (labels (;; FIXME: This function is a no-op now that we no longer
+	   ;; have a distinct package T%CL to translate
+	   ;; for-the-target-Lisp CL symbols to, and should go away
+	   ;; completely.
 	   (translate (expr) expr))
     (let ((raw-result (type-of object)))
       (cond ((or (subtypep raw-result 'float)
@@ -86,12 +85,12 @@
 	    (t
 	     (error "can't handle TYPE-OF ~S in cross-compilation"))))))
 
-;;; Like TYPEP, but asks whether HOST-OBJECT would be of TARGET-TYPE when
-;;; instantiated on the target SBCL. Since this is hard to decide in some
-;;; cases, and since in other cases we just haven't bothered to try, it
-;;; needs to return two values, just like SUBTYPEP: the first value for
-;;; its conservative opinion (never T unless it's certain) and the second
-;;; value to tell whether it's certain.
+;;; Like TYPEP, but asks whether HOST-OBJECT would be of TARGET-TYPE
+;;; when instantiated on the target SBCL. Since this is hard to decide
+;;; in some cases, and since in other cases we just haven't bothered
+;;; to try, it needs to return two values, just like SUBTYPEP: the
+;;; first value for its conservative opinion (never T unless it's
+;;; certain) and the second value to tell whether it's certain.
 (defun cross-typep (host-object target-type)
   (flet ((warn-and-give-up ()
 	   ;; We don't have to keep track of this as long as system performance
@@ -317,7 +316,7 @@
 			:complexp (not (typep x 'simple-array))
 			:element-type etype
 			:specialized-element-type etype)))
-    (cons (sb!xc:find-class 'cons))
+    (cons (specifier-type 'cons))
     (character
      (cond ((typep x 'standard-char)
 	    ;; (Note that SBCL doesn't distinguish between BASE-CHAR and
@@ -331,7 +330,9 @@
     (structure!object
      (sb!xc:find-class (uncross (class-name (class-of x)))))
     (t
-     ;; There might be more cases which we could handle with sufficient effort;
-     ;; since all we *need* to handle are enough cases for bootstrapping, we
-     ;; don't try to be complete here. -- WHN 19990512
+     ;; There might be more cases which we could handle with
+     ;; sufficient effort; since all we *need* to handle are enough
+     ;; cases for bootstrapping, we don't try to be complete here,. If
+     ;; future maintainers make the bootstrap code more complicated,
+     ;; they can also add new cases here to handle it. -- WHN 2000-11-11
      (error "can't handle ~S in cross CTYPE-OF" x))))