| blob | b4565b1aa32b69de2b5dc6dba702b48a46ca91a0 |
1 ;;;; cross-compiler-only versions of TYPEP, TYPE-OF, and related functions
3 ;;;; This software is part of the SBCL system. See the README file for
4 ;;;; more information.
5 ;;;;
6 ;;;; This software is derived from the CMU CL system, which was
7 ;;;; written at Carnegie Mellon University and released into the
8 ;;;; public domain. The software is in the public domain and is
9 ;;;; provided with absolutely no warranty. See the COPYING and CREDITS
10 ;;;; files for more information.
14 ;;; (This was a useful warning when trying to get bootstrapping
15 ;;; to work, but it's mostly irrelevant noise now that the system
16 ;;; works.)
22 ))
25 s
26 "cross-compilation-time type ambiguity (should be OK) in ~S:~%~A"
30 ;;; This warning is issued when giving up on a type calculation where a
31 ;;; conservative answer is acceptable. Since a conservative answer is
32 ;;; acceptable, the only downside is lost optimization opportunities.
37 )))
39 ;;; This warning refers to the flexibility in the ANSI spec with
40 ;;; regard to run-time distinctions between floating point types.
41 ;;; (E.g. the cross-compilation host might not even distinguish
42 ;;; between SINGLE-FLOAT and DOUBLE-FLOAT, so a DOUBLE-FLOAT number
43 ;;; would test positive as SINGLE-FLOAT.) If the target SBCL does make
44 ;;; this distinction, then information is lost. It's not too hard to
45 ;;; contrive situations where this would be a problem. In practice we
46 ;;; don't tend to run into them because all widely used Common Lisp
47 ;;; environments do recognize the distinction between SINGLE-FLOAT and
48 ;;; DOUBLE-FLOAT, and we don't really need the other distinctions
49 ;;; (e.g. between SHORT-FLOAT and SINGLE-FLOAT), so we call
50 ;;; WARN-POSSIBLE-CROSS-TYPE-FLOAT-INFO-LOSS to test at runtime
51 ;;; whether we need to worry about this at all, and not warn unless we
52 ;;; do. If we *do* have to worry about this at runtime, my (WHN
53 ;;; 19990808) guess is that the system will break in multiple places,
54 ;;; so this is a real WARNING, not just a STYLE-WARNING.
55 ;;;
56 ;;; KLUDGE: If we ever try to support LONG-FLOAT or SHORT-FLOAT, this
57 ;;; situation will get a lot more complicated.
69 raw-result)
74 ;; it's a FIXNUM, but instead test against target
75 ;; MOST-fooITIVE-FIXNUM limits.
85 raw-result)
89 ;;; Is SYMBOL in the CL package? Note that we're testing this on the
90 ;;; cross-compilation host, which could do things any old way. In
91 ;;; particular, it might be in the CL package even though
92 ;;; SYMBOL-PACKAGE is not (FIND-PACKAGE :CL). So we test things
93 ;;; another way.
96 symbol))
98 ;; Return T if SYMBOL is a predicate acceptable for use in a SATISFIES type
99 ;; specifier. We assume that anything in CL: is allowed (see explanation at
100 ;; call point), and beyond that, anything we define has to be expressly listed
101 ;; here, for fear of later unexpected confusion.
105 ;; KLUDGE: rather than extensible list of predicates that match
106 ;; in behavior between the host and target lisp, hardcode a few.
110 ;;; This is like TYPEP, except that it asks whether HOST-OBJECT would
111 ;;; be of TARGET-TYPE when instantiated on the target SBCL. Since this
112 ;;; is hard to determine in some cases, and since in other cases we
113 ;;; just haven't bothered to try, it needs to return two values, just
114 ;;; like SUBTYPEP: the first value for its conservative opinion (never
115 ;;; T unless it's certain) and the second value to tell whether it's
116 ;;; certain.
120 ;; We don't have to keep track of this as long as system
121 ;; performance is acceptable, since giving up
122 ;; conservatively is a safe way out.
123 #+nil
130 ;; a convenient idiom for making more matches to special cases:
131 ;; Test both forms of target type for membership in LIST.
132 ;;
133 ;; (In order to avoid having to use too much deep knowledge
134 ;; of types, it's sometimes convenient to test RAW-TARGET-TYPE
135 ;; as well as the expanded type, since we can get matches with
136 ;; just EQL. E.g. SIMPLE-STRING can be matched with EQL, while
137 ;; safely matching its expansion,
138 ;; (OR (SIMPLE-ARRAY CHARACTER (*)) (SIMPLE-BASE-STRING *))
139 ;; would require logic clever enough to know that, e.g., OR is
140 ;; commutative.)
145 ;; the ANSI cross-compilation host. KLUDGE: This code will
146 ;; need to be tweaked by hand if the names of these types
147 ;; ever change, ugh!
156 ;; instead a CLASS object.
173 ;; partition, but it includes at least lists and vectors.
193 ;; KLUDGE: SBCL has * as an explicit wild type. While
194 ;; this is sort of logical (because (e.g. (ARRAY * 1)) is
195 ;; a valid type) it's not ANSI: looking at the ANSI
196 ;; definitions of complex types like like ARRAY shows
197 ;; that they consider * different from other type names.
198 ;; Someday we should probably get rid of this non-ANSIism
199 ;; in base SBCL, but until we do, we might as well here
200 ;; in the cross compiler. And in order to make sure that
201 ;; we don't continue doing it after we someday patch
202 ;; SBCL's type system so that * is no longer a type, we
203 ;; make this assertion. -- WHN 2001-08-08
207 ;; between any host ANSI Common Lisp and the target
208 ;; Common Lisp. (Some array types are too, but they
209 ;; were picked off earlier.)
212 list nil null number rational real signed-byte symbol t
213 unsigned-byte))
216 ;; too, but less exactly.
225 ;; Our dumping logic is based on contents, however, so
226 ;; reasoning about them should be safe
240 ;; We won't know how to dump it either.
244 ;; Some types require translation between the cross-compilation
245 ;; host Common Lisp and the target SBCL.
252 t))
253 ;; Some types are too hard to handle in the positive
254 ;; case, but at least we can be confident in a large
255 ;; fraction of the negative cases..
269 ;; Neither target CL:STREAM nor target SB!KERNEL:INSTANCE
270 ;; is implemented as a STRUCTURE-OBJECT, so they'll fall
271 ;; through the tests above. We don't want to assume too
272 ;; much about them here, but at least we know enough
273 ;; about them to say that neither T nor NIL nor indeed
274 ;; any other symbol in the cross-compilation host is one.
275 ;; That knowledge suffices to answer so many of the
276 ;; questions that the cross-compiler asks that it's well
277 ;; worth special-casing it here.
281 ;; various hacks for composite types..
286 ;; Many complex types are guaranteed to correspond exactly
287 ;; between any host ANSI Common Lisp and the target SBCL.
290 ;; Floating point types are guaranteed to correspond,
291 ;; too, but less exactly.
298 ;; Some complex types have translations that are less
299 ;; trivial.
308 ;; If we want to work with the KEYWORD type, we need
309 ;; to grok (SATISFIES KEYWORDP).
313 ;; Many predicates like KEYWORDP, ODDP, PACKAGEP,
314 ;; and NULL correspond between host and target.
315 ;; But we still need to handle errors, because
316 ;; the code which calls us may not understand
317 ;; that a type is unreachable. (E.g. when compiling
318 ;; (AND STRING (SATISFIES ARRAY-HAS-FILL-POINTER-P))
319 ;; CTYPEP may be called on the SATISFIES expression
320 ;; even for non-STRINGs.)
323 host-object))
327 ;; For symbols not in the CL package, it's not
328 ;; in general clear how things correspond
329 ;; between host and target, so we punt.
331 ;; Some complex types are too hard to handle in the
332 ;; positive case, but at least we can be confident in
333 ;; a large fraction of the negative cases..
350 ;; And the Common Lisp type system is complicated,
351 ;; and we don't try to implement everything.
353 ;; And the Common Lisp type system is complicated, and
354 ;; we don't try to implement everything.
358 ;;; This is an incomplete TYPEP which runs at cross-compile time to
359 ;;; tell whether OBJECT is the host Lisp representation of a target
360 ;;; SBCL type specified by TARGET-TYPE-SPEC. It need make no pretense
361 ;;; to completeness, since it need only handle the cases which arise
362 ;;; when building SBCL itself, e.g. testing that range limits FOO and
363 ;;; BAR in (INTEGER FOO BAR) are INTEGERs.
370 ;; A program that calls TYPEP doesn't want uncertainty and
371 ;; probably can't handle it.
373 opinion
375 host-object
376 target-type-spec))))
378 ;;; This is an incomplete, portable implementation for use at
379 ;;; cross-compile time only.
382 ;; There is at least one possible endless recursion in the
383 ;; cross-compiler type system: (SUBTYPEP NULL (OR UNKOWN0 UNKNOWN1)
384 ;; runs out of stack. The right way would probably be to not
385 ;; implement CTYPEP in terms of TYPE-SPECIFIER (:UNPARSE, that may
386 ;; call TYPE=, that in turn may call CTYPEP). Until then, pick a few
387 ;; cherries off.
395 ;; This is essentially just the ARRAY-TYPE case of %%TYPEP
396 ;; using !SPECIALIZED-ARRAY-ELEMENT-TYPE, not ARRAY-ELEMENT-TYPE.
426 ;; Since at cross-compile time we build a CLOS-free bootstrap
427 ;; version of SBCL, it's unclear how to explain to it what a
428 ;; generic function is.
430 ;; There's no ANSI way to find out what the function is
431 ;; declared to be, so we just return the CTYPE for the
432 ;; most-general function.
439 ;; It is critical not to inquire of the host for the array's element type.
442 ;; complexp relies on the host implementation,
443 ;; but in practice any array for which we need to
444 ;; call ctype-of will be a simple-array.
446 :element-type etype
453 nil)
455 ;; Beyond this, there seems to be no portable correspondence.
460 ;; There might be more cases which we could handle with
461 ;; sufficient effort; since all we *need* to handle are enough
462 ;; cases for bootstrapping, we don't try to be complete here,. If
463 ;; future maintainers make the bootstrap code more complicated,
464 ;; they can also add new cases here to handle it. -- WHN 2000-11-11