| blob | e4f51b04fd86635b781468c4409f4fdc07e655da |
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?"
20 ;; Actually interpreting types at runtime is done by %TYPEP. The
21 ;; cost of the extra function call here should be negligible
22 ;; compared to the cost of interpreting types. (And the compiler
23 ;; tries hard to optimize away the interpretation of types at
24 ;; runtime, and when it succeeds, we never get here anyway.)
27 ;;; the actual TYPEP engine. The compiler only generates calls to this
28 ;;; function when it can't figure out anything more intelligent to do.
30 ;; Checking CTYPE-P on the specifier, as used to be done, is not right.
31 ;; If the specifier were a CTYPE we shouldn't have gotten here.
47 ;; two components of a COMPLEX are always coerced to
48 ;; be the same, e.g. (COMPLEX 1.0 3/2) => #C(1.0 1.5).
49 ;; Dunno why that holds, though -- ANSI? Python
50 ;; tradition? marsh faerie spirits? -- WHN 2001-10-27
53 object)))
76 (:complex
80 (:real
102 ;; FIXME: treatment of compound types involving unknown types
103 ;; is generally bogus throughout the system, e.g.
104 ;; (TYPEP MY-ARRAY '(ARRAY (OR BAD1 BAD2) *)) => T
105 ;; because (OR BAD1 BAD2) is not represented as an UNKNOWN-TYPE,
106 ;; and has specialized type '*.
107 ;; One way to fix this is that every CTYPE needs a bit to indicate
108 ;; whether any subpart of it is unknown, or else when parsing,
109 ;; we should always return an UNKNOWN if any subpart is unknown,
110 ;; or else any time we use a CTYPE, we do a deep traversal
111 ;; to detect embedded UNKNOWNs (which seems bad for performance).
113 ;; better to fail this way than to get bogosities like
114 ;; (TYPEP (MAKE-ARRAY 11) '(ARRAY SOME-UNDEFINED-TYPE)) => T
117 t)
120 ;; FIXME: not the most efficient.
122 object)))))))
125 t))
128 ;; It might be more efficient to check that OBJECT is either INSTANCEP
129 ;; or FUNCALLABLE-INSTANCE-P before making this call.
130 ;; But doing that would change the behavior if %%TYPEP were ever called
131 ;; with a built-in classoid whose members are not instances.
132 ;; e.g. (%%typep (find-fdefn 'car) (specifier-type 'fdefn))
133 ;; I'm not sure if that can happen.
146 #!+sb-simd-pack
161 ;; dunno how to do this ANSIly -- WHN 19990413
163 ;; Parse it again to make sure it's really undefined.
172 ;; Now the tricky stuff.
179 ;; Note: it should be safe to skip OR here, because union
180 ;; types can always be represented as UNION-TYPE in general
181 ;; or other CTYPEs in special cases; we never need to use
182 ;; HAIRY-TYPE for them.
200 ;;; Do a type test from a class cell, allowing forward reference and
201 ;;; redefinition.
209 ;;; Test whether OBJ-LAYOUT is from an instance of CLASSOID.
212 ;; FIXME & KLUDGE: We could like to grab the *WORLD-LOCK* here (to ensure that
213 ;; class graph doesn't change while we're doing the typep test), but in
214 ;; pratice that causes trouble -- deadlocking against the compiler
215 ;; if compiler output (or macro, or compiler-macro expansion) causes
216 ;; another thread to do stuff. Not locking is a shoddy bandaid as it is remains
217 ;; easy to trigger the same problem using a different code path -- but in practice
218 ;; locking here makes Slime unusable with :SPAWN in post *WORLD-LOCK* world. So...
219 ;; -- NS 2008-12-16