| blob | c4745e14af5289828852a7b87c34f4d90c563fbf |
1 ;;;; This software is part of the SBCL system. See the README file for
2 ;;;; more information.
3 ;;;;
4 ;;;; This software is derived from the CMU CL system, which was
5 ;;;; written at Carnegie Mellon University and released into the
6 ;;;; public domain. The software is in the public domain and is
7 ;;;; provided with absolutely no warranty. See the COPYING and CREDITS
8 ;;;; files for more information.
12 ;;; (Note that when cross-compiling, SB!XC:TYPEP is interpreted as a
13 ;;; test that the host Lisp object OBJECT translates to a target SBCL
14 ;;; type TYPE. This behavior is needed e.g. to test for the validity
15 ;;; of numeric subtype bounds read when cross-compiling.)
17 #!+sb-doc
18 "Is OBJECT of type TYPE?"
21 ;; Actually interpreting types at runtime is done by %TYPEP. The
22 ;; cost of the extra function call here should be negligible
23 ;; compared to the cost of interpreting types. (And the compiler
24 ;; tries hard to optimize away the interpretation of types at
25 ;; runtime, and when it succeeds, we never get here anyway.)
28 ;;; the actual TYPEP engine. The compiler only generates calls to this
29 ;;; function when it can't figure out anything more intelligent to do.
31 ;; Checking CTYPE-P on the specifier, as used to be done, is not right.
32 ;; If the specifier were a CTYPE we shouldn't have gotten here.
49 ;; two components of a COMPLEX are always coerced to
50 ;; be the same, e.g. (COMPLEX 1.0 3/2) => #C(1.0 1.5).
51 ;; Dunno why that holds, though -- ANSI? Python
52 ;; tradition? marsh faerie spirits? -- WHN 2001-10-27
55 object)))
78 (:complex
82 (:real
104 ;; FIXME: treatment of compound types involving unknown types
105 ;; is generally bogus throughout the system, e.g.
106 ;; (TYPEP MY-ARRAY '(ARRAY (OR BAD1 BAD2) *)) => T
107 ;; because (OR BAD1 BAD2) is not represented as an UNKNOWN-TYPE,
108 ;; and has specialized type '*.
109 ;; One way to fix this is that every CTYPE needs a bit to indicate
110 ;; whether any subpart of it is unknown, or else when parsing,
111 ;; we should always return an UNKNOWN if any subpart is unknown,
112 ;; or else any time we use a CTYPE, we do a deep traversal
113 ;; to detect embedded UNKNOWNs (which seems bad for performance).
115 ;; better to fail this way than to get bogosities like
116 ;; (TYPEP (MAKE-ARRAY 11) '(ARRAY SOME-UNDEFINED-TYPE)) => T
119 t)
122 ;; FIXME: not the most efficient.
124 object)))))))
127 t))
130 ;; It might be more efficient to check that OBJECT is either INSTANCEP
131 ;; or FUNCALLABLE-INSTANCE-P before making this call.
132 ;; But doing that would change the behavior if %%TYPEP were ever called
133 ;; with a built-in classoid whose members are not instances.
134 ;; e.g. (%%typep (find-fdefn 'car) (specifier-type 'fdefn))
135 ;; I'm not sure if that can happen.
148 #!+sb-simd-pack
163 ;; dunno how to do this ANSIly -- WHN 19990413
165 ;; Parse it again to make sure it's really undefined.
174 ;; Now the tricky stuff.
181 ;; Note: it should be safe to skip OR here, because union
182 ;; types can always be represented as UNION-TYPE in general
183 ;; or other CTYPEs in special cases; we never need to use
184 ;; HAIRY-TYPE for them.
202 ;;; Do a type test from a class cell, allowing forward reference and
203 ;;; redefinition.
211 ;;; Test whether OBJ-LAYOUT is from an instance of CLASSOID.
214 ;; FIXME & KLUDGE: We could like to grab the *WORLD-LOCK* here (to ensure that
215 ;; class graph doesn't change while we're doing the typep test), but in
216 ;; pratice that causes trouble -- deadlocking against the compiler
217 ;; if compiler output (or macro, or compiler-macro expansion) causes
218 ;; another thread to do stuff. Not locking is a shoddy bandaid as it is remains
219 ;; easy to trigger the same problem using a different code path -- but in practice
220 ;; locking here makes Slime unusable with :SPAWN in post *WORLD-LOCK* world. So...
221 ;; -- NS 2008-12-16