X-Git-Url: http://repo.macrolet.net/gitweb/?a=blobdiff_plain;f=src%2Fcode%2Ftypep.lisp;h=19ac49a3c8881095b069f15ecd0933e766b872f9;hb=90ca09b75fbc3b63b2f7d09c67b04b866dd783f6;hp=bec03acd3da83a3650a3d86c023ae3e5be23f60e;hpb=be9eb6c67b5f43a095c3de17bea945c309d662e4;p=sbcl.git

diff --git a/src/code/typep.lisp b/src/code/typep.lisp
index bec03ac..19ac49a 100644
--- a/src/code/typep.lisp
+++ b/src/code/typep.lisp
@@ -9,6 +9,20 @@
 
 (in-package "SB!KERNEL")
 
+;;; (Note that when cross-compiling, SB!XC:TYPEP is interpreted as a
+;;; test that the host Lisp object OBJECT translates to a target SBCL
+;;; type TYPE. This behavior is needed e.g. to test for the validity
+;;; of numeric subtype bounds read when cross-compiling.)
+(defun typep (object type)
+  #!+sb-doc
+  "Is OBJECT of type TYPE?"
+  ;; Actually interpreting types at runtime is done by %TYPEP. The
+  ;; cost of the extra function call here should be negligible
+  ;; compared to the cost of interpreting types. (And the compiler
+  ;; tries hard to optimize away the interpretation of types at
+  ;; runtime, and when it succeeds, we never get here anyway.)
+  (%typep object type))
+
 ;;; the actual TYPEP engine. The compiler only generates calls to this
 ;;; function when it can't figure out anything more intelligent to do.
 (defun %typep (object specifier)
@@ -25,7 +39,14 @@
        ((nil) nil)))
     (numeric-type
      (and (numberp object)
-	  (let ((num (if (complexp object) (realpart object) object)))
+	  (let (;; I think this works because of an invariant of the
+		;; two components of a COMPLEX are always coerced to
+		;; be the same, e.g. (COMPLEX 1.0 3/2) => #C(1.0 1.5).
+		;; Dunno why that holds, though -- ANSI? Python
+		;; tradition? marsh faerie spirits? -- WHN 2001-10-27
+		(num (if (complexp object)
+			 (realpart object)
+			 object)))
 	    (ecase (numeric-type-class type)
 	      (integer (integerp num))
 	      (rational (rationalp num))