| blob | ad252643a516e5d45cdebb1ddce028c282bda0d5 |
1 ;;;; This file contains the definition of non-CLASS types (e.g.
2 ;;;; subtypes of interesting BUILT-IN-CLASSes) and the interfaces to
3 ;;;; the type system. Common Lisp type specifiers are parsed into a
4 ;;;; somewhat canonical internal type representation that supports
5 ;;;; type union, intersection, etc. (Except that ALIEN types have
6 ;;;; moved out..)
8 ;;;; This software is part of the SBCL system. See the README file for
9 ;;;; more information.
10 ;;;;
11 ;;;; This software is derived from the CMU CL system, which was
12 ;;;; written at Carnegie Mellon University and released into the
13 ;;;; public domain. The software is in the public domain and is
14 ;;;; provided with absolutely no warranty. See the COPYING and CREDITS
15 ;;;; files for more information.
23 ;;; ### Remaining incorrectnesses:
24 ;;;
25 ;;; TYPE-UNION (and the OR type) doesn't properly canonicalize an
26 ;;; exhaustive partition or coalesce contiguous ranges of numeric
27 ;;; types.
28 ;;;
29 ;;; There are all sorts of nasty problems with open bounds on FLOAT
30 ;;; types (and probably FLOAT types in general.)
31 ;;;
32 ;;; RATIO and BIGNUM are not recognized as numeric types.
34 ;;; FIXME: This really should go away. Alas, it doesn't seem to be so
35 ;;; simple to make it go away.. (See bug 123 in BUGS file.)
37 #!+sb-doc
38 "*USE-IMPLEMENTATION-TYPES* is a semi-public flag which determines how
39 restrictive we are in determining type membership. If two types are the
40 same in the implementation, then we will consider them them the same when
41 this switch is on. When it is off, we try to be as restrictive as the
42 language allows, allowing us to detect more errors. Currently, this only
46 ;;; These functions are used as method for types which need a complex
47 ;;; subtypep method to handle some superclasses, but cover a subtree
48 ;;; of the type graph (i.e. there is no simple way for any other type
49 ;;; class to be a subtype.) There are always still complex ways,
50 ;;; namely UNION and MEMBER types, so we must give TYPE1's method a
51 ;;; chance to run, instead of immediately returning NIL, T.
65 ;;; This is used by !DEFINE-SUPERCLASSES to define the SUBTYPE-ARG1
66 ;;; method. INFO is a list of conses
67 ;;; (SUPERCLASS-CLASS . {GUARD-TYPE-SPECIFIER | NIL}).
69 ;; If TYPE2 might be concealing something related to our class
70 ;; hierarchy
72 ;; too confusing, gotta punt
74 ;; ordinary case expected by old CMU CL code, where the taxonomy
75 ;; of TYPE2's representation accurately reflects the taxonomy of
76 ;; the underlying set
78 ;; FIXME: This old CMU CL code probably deserves a comment
79 ;; explaining to us mere mortals how it works...
90 t)))
92 ;;; This function takes a list of specs, each of the form
93 ;;; (SUPERCLASS-NAME &OPTIONAL GUARD).
94 ;;; Consider one spec (with no guard): any instance of the named
95 ;;; TYPE-CLASS is also a subtype of the named superclass and of any of
96 ;;; its superclasses. If there are multiple specs, then some will have
97 ;;; guards. We choose the first spec whose guard is a supertype of
98 ;;; TYPE1 and use its superclass. In effect, a sequence of guards
99 ;;; G0, G1, G2
100 ;;; is actually
101 ;;; G0,(and G1 (not G0)), (and G2 (not (or G0 G1))).
102 ;;;
103 ;;; WHEN controls when the forms are executed.
107 `(,when
112 spec
122 \f
123 ;;;; FUNCTION and VALUES types
124 ;;;;
125 ;;;; Pretty much all of the general type operations are illegal on
126 ;;;; VALUES types, since we can't discriminate using them, do
127 ;;;; SUBTYPEP, etc. FUNCTION types are acceptable to the normal type
128 ;;;; operations, but are generally considered to be equivalent to
129 ;;;; FUNCTION. These really aren't true types in any type theoretic
130 ;;;; sense, but we still parse them into CTYPE structures for two
131 ;;;; reasons:
133 ;;;; -- Parsing and unparsing work the same way, and indeed we can't
134 ;;;; tell whether a type is a function or values type without
135 ;;;; parsing it.
136 ;;;; -- Many of the places that can be annotated with real types can
137 ;;;; also be annotated with function or values types.
139 ;;; the description of a &KEY argument
142 ;; the key (not necessarily a keyword in ANSI Common Lisp)
144 ;; the type of the argument value
150 ;; FIXME: should be TYPE-ERROR, here and in next method
161 ;;; Return true if LIST1 and LIST2 have the same elements in the same
162 ;;; positions according to TYPE=. We return NIL, NIL if there is an
163 ;;; uncertain comparison.
200 ;;; a flag that we can bind to cause complex function types to be
201 ;;; unparsed as FUNCTION. This is useful when we want a type that we
202 ;;; can pass to TYPEP.
208 'function
211 '*
216 ;;; The meaning of this is a little confused. On the one hand, all
217 ;;; function objects are represented the same way regardless of the
218 ;;; arglists and return values, and apps don't get to ask things like
219 ;;; (TYPEP #'FOO (FUNCTION (FIXNUM) *)) in any meaningful way. On the
220 ;;; other hand, Python wants to reason about function types. So...
227 for a1 in types1
228 for a2 in types2
273 ;;; The union or intersection of two FUNCTION types is FUNCTION.
281 ;;; ### Not very real, but good enough for redefining transforms
282 ;;; according to type:
297 ;;; Given a LAMBDA-LIST-like values type specification and an ARGS-TYPE
298 ;;; structure, fill in the slots in the structure accordingly. This is
299 ;;; used for both FUNCTION and VALUES types.
321 kwd lambda-list))
328 ;;; Return the lambda-list-like type specification corresponding
329 ;;; to an ARGS-TYPE.
362 res))
367 res))
368 \f
369 ;;;; VALUES types interfaces
370 ;;;;
371 ;;;; We provide a few special operations that can be meaningfully used
372 ;;;; on VALUES types (as well as on any other type).
374 ;;; Return the type of the first value indicated by TYPE. This is used
375 ;;; by people who don't want to have to deal with VALUES types.
377 ; (inline single-value-type))
390 type)))
392 ;;; Return the minimum number of arguments that a function can be
393 ;;; called with, and the maximum number or NIL. If not a function
394 ;;; type, return NIL, NIL.
406 ;;; Determine whether TYPE corresponds to a definite number of values.
407 ;;; The first value is a list of the types for each value, and the
408 ;;; second value is the number of values. If the number of values is
409 ;;; not fixed, then return NIL and :UNKNOWN.
425 ;;; Return two values:
426 ;;; 1. A list of all the positional (fixed and optional) types.
427 ;;; 2. The &REST type (if any). If keywords allowed, *UNIVERSAL-TYPE*.
428 ;;; If no keywords or &REST, then the DEFAULT-TYPE.
436 default-type))))
438 ;;; Return a list of OPERATION applied to the types in TYPES1 and
439 ;;; TYPES2, padding with REST2 as needed. TYPES1 must not be shorter
440 ;;; than TYPES2. The second value is T if OPERATION always returned a
441 ;;; true second value.
450 res))
451 types1
455 exact)))
457 ;;; If TYPE isn't a values type, then make it into one:
458 ;;; <type> ==> (values type &rest t)
462 type
465 ;;; Do the specified OPERATION on TYPE1 and TYPE2, which may be any
466 ;;; type, including VALUES types. With VALUES types such as:
467 ;;; (VALUES a0 a1)
468 ;;; (VALUES b0 b1)
469 ;;; we compute the more useful result
470 ;;; (VALUES (<operation> a0 b0) (<operation> a1 b1))
471 ;;; rather than the precise result
472 ;;; (<operation> (values a0 a1) (values b0 b1))
473 ;;; This has the virtue of always keeping the VALUES type specifier
474 ;;; outermost, and retains all of the information that is really
475 ;;; useful for static type analysis. We want to know what is always
476 ;;; true of each value independently. It is worthless to know that if
477 ;;; the first value is B0 then the second will be B1.
478 ;;;
479 ;;; If the VALUES count signatures differ, then we produce a result with
480 ;;; the required VALUE count chosen by NREQ when applied to the number
481 ;;; of required values in TYPE1 and TYPE2. Any &KEY values become
482 ;;; &REST T (anyone who uses keyword values deserves to lose.)
483 ;;;
484 ;;; The second value is true if the result is definitely empty or if
485 ;;; OPERATION returned true as its second value each time we called
486 ;;; it. Since we approximate the intersection of VALUES types, the
487 ;;; second value being true doesn't mean the result is exact.
516 :required required
519 ())
524 ;;; Do a union or intersection operation on types that might be values
525 ;;; types. The result is optimized for utility rather than exactness,
526 ;;; but it is guaranteed that it will be no smaller (more restrictive)
527 ;;; than the precise result.
528 ;;;
529 ;;; The return convention seems to be analogous to
530 ;;; TYPES-EQUAL-OR-INTERSECT. -- WHN 19990910.
533 :default nil
553 #'type-intersection
554 #'max
557 ;;; This is like TYPES-EQUAL-OR-INTERSECT, except that it sort of
558 ;;; works on VALUES types. Note that due to the semantics of
559 ;;; VALUES-TYPE-INTERSECTION, this might return (VALUES T T) when
560 ;;; there isn't really any intersection.
567 win)))
571 ;;; a SUBTYPEP-like operation that can be used on any types, including
572 ;;; VALUES types
611 \f
612 ;;;; type method interfaces
614 ;;; like SUBTYPEP, only works on CTYPE structures
630 type1 type2
633 ;;; Just parse the type specifiers and call CSUBTYPE.
635 #!+sb-doc
636 "Return two values indicating the relationship between type1 and type2.
637 If values are T and T, type1 definitely is a subtype of type2.
638 If values are NIL and T, type1 definitely is not a subtype of type2.
639 If values are NIL and NIL, it couldn't be determined."
643 ;;; If two types are definitely equivalent, return true. The second
644 ;;; value indicates whether the first value is definitely correct.
645 ;;; This should only fail in the presence of HAIRY types.
657 ;;; Not exactly the negation of TYPE=, since when the relationship is
658 ;;; uncertain, we still return NIL, NIL. This is useful in cases where
659 ;;; the conservative assumption is =.
667 ;;; the type method dispatch case of TYPE-UNION2
669 ;; As in %TYPE-INTERSECTION2, it seems to be a good idea to give
670 ;; both argument orders a chance at COMPLEX-INTERSECTION2. Unlike
671 ;; %TYPE-INTERSECTION2, though, I don't have a specific case which
672 ;; demonstrates this is actually necessary. Also unlike
673 ;; %TYPE-INTERSECTION2, there seems to be no need to distinguish
674 ;; between not finding a method and having a method return NIL.
677 x y
683 ;;; Find a type which includes both types. Any inexactness is
684 ;;; represented by the fuzzy element types; we return a single value
685 ;;; that is precise to the best of our knowledge. This result is
686 ;;; simplified into the canonical form, thus is not a UNION-TYPE
687 ;;; unless we find no other way to represent the result.
692 ;; KLUDGE: This was generated from TYPE-INTERSECTION2 by Ye Olde Cut And
693 ;; Paste technique of programming. If it stays around (as opposed to
694 ;; e.g. fading away in favor of some CLOS solution) the shared logic
695 ;; should probably become shared code. -- WHN 2001-03-16
698 type1)
703 ;; Unions of UNION-TYPE should have the UNION-TYPE-TYPES
704 ;; values broken out and united separately. The full TYPE-UNION
705 ;; function knows how to do this, so let it handle it.
708 ;; the ordinary case: we dispatch to type methods
711 ;;; the type method dispatch case of TYPE-INTERSECTION2
713 ;; We want to give both argument orders a chance at
714 ;; COMPLEX-INTERSECTION2. Without that, the old CMU CL type
715 ;; methods could give noncommutative results, e.g.
716 ;; (TYPE-INTERSECTION2 *EMPTY-TYPE* SOME-HAIRY-TYPE)
717 ;; => NIL, NIL
718 ;; (TYPE-INTERSECTION2 SOME-HAIRY-TYPE *EMPTY-TYPE*)
719 ;; => #<NAMED-TYPE NIL>, T
720 ;; We also need to distinguish between the case where we found a
721 ;; type method, and it returned NIL, and the case where we fell
722 ;; through without finding any type method. An example of the first
723 ;; case is the intersection of a HAIRY-TYPE with some ordinary type.
724 ;; An example of the second case is the intersection of two
725 ;; completely-unrelated types, e.g. CONS and NUMBER, or SYMBOL and
726 ;; ARRAY.
727 ;;
728 ;; (Why yes, CLOS probably *would* be nicer..)
731 x y
743 nil))))))))
748 :default nil
753 ;; FIXME: For some reason, this doesn't catch e.g. type1 =
754 ;; type2 = (SPECIFIER-TYPE
755 ;; 'SOME-UNKNOWN-TYPE). Investigate. - CSR, 2002-04-10
756 type1)
759 ;; Intersections of INTERSECTION-TYPE should have the
760 ;; INTERSECTION-TYPE-TYPES values broken out and intersected
761 ;; separately. The full TYPE-INTERSECTION function knows how
762 ;; to do that, so let it handle it.
765 ;; the ordinary case: we dispatch to type methods
768 ;;; Return as restrictive and simple a type as we can discover that is
769 ;;; no more restrictive than the intersection of TYPE1 and TYPE2. At
770 ;;; worst, we arbitrarily return one of the arguments as the first
771 ;;; value (trying not to return a hairy type).
777 ;;; a test useful for checking whether a derived type matches a
778 ;;; declared type
779 ;;;
780 ;;; The first value is true unless the types don't intersect and
781 ;;; aren't equal. The second value is true if the first value is
782 ;;; definitely correct. NIL is considered to intersect with any type.
783 ;;; If T is a subtype of either type, then we also return T, T. This
784 ;;; way we recognize that hairy types might intersect with T.
798 ;;; Return a Common Lisp type specifier corresponding to the TYPE
799 ;;; object.
804 ;;; (VALUES-SPECIFIER-TYPE and SPECIFIER-TYPE moved from here to
805 ;;; early-type.lisp by WHN ca. 19990201.)
807 ;;; Take a list of type specifiers, computing the translation of each
808 ;;; specifier and defining it as a builtin type.
815 ;; KLUDGE: the three copies of this idiom in this file (and
816 ;; the one in class.lisp as at sbcl-0.7.4.1x) should be
817 ;; coalesced, or perhaps the error-detecting code that
818 ;; disallows redefinition of :PRIMITIVE types should be
819 ;; rewritten to use *TYPE-SYSTEM-FINALIZED* (rather than
820 ;; *TYPE-SYSTEM-INITIALIZED*). The effect of this is not to
821 ;; cause redefinition errors when precompute-types is called
822 ;; for a second time while building the target compiler using
823 ;; the cross-compiler. -- CSR, trying to explain why this
824 ;; isn't completely wrong, 2002-06-07
827 \f
828 ;;;; general TYPE-UNION and TYPE-INTERSECTION operations
829 ;;;;
830 ;;;; These are fully general operations on CTYPEs: they'll always
831 ;;;; return a CTYPE representing the result.
833 ;;; shared logic for unions and intersections: Stuff TYPE into the
834 ;;; vector TYPES, finding pairs of types which can be simplified by
835 ;;; SIMPLIFY2 (TYPE-UNION2 or TYPE-INTERSECTION2) and replacing them
836 ;;; by their simplified forms.
841 ;; Any input object satisfying %COMPOUND-TYPE-P should've been
842 ;; broken into components before it reached us.
847 ;; Discard the old (AREF TYPES I).
849 ;; Merge the new SIMPLIFIED2 into TYPES, by tail recursing.
850 ;; (Note that the tail recursion is indirect: we go through
851 ;; ACCUMULATE, not ACCUMULATE1, so that if SIMPLIFIED2 is
852 ;; handled properly if it satisfies %COMPOUND-TYPE-P.)
854 types
855 %compound-type-p
856 simplify2)))))
857 ;; Voila.
860 ;;; shared logic for unions and intersections: Use
861 ;;; ACCUMULATE1-COMPOUND-TYPE to merge TYPE into TYPES, either
862 ;;; all in one step or, if %COMPOUND-TYPE-P is satisfied,
863 ;;; component by component.
874 ;;; shared logic for unions and intersections: Return a vector of
875 ;;; types representing the same types as INPUT-TYPES, but with
876 ;;; COMPOUND-TYPEs satisfying %COMPOUND-TYPE-P broken up into their
877 ;;; component types, and with any SIMPLY2 simplifications applied.
881 :adjustable t
883 ;; (This INITIAL-ELEMENT shouldn't
884 ;; matter, but helps avoid type
885 ;; warnings at compile time.)
889 simplified-types
890 %compound-type-p
891 simplify2))
892 simplified-types))
894 ;;; shared logic for unions and intersections: Make a COMPOUND-TYPE
895 ;;; object whose components are the types in TYPES, or skip to special
896 ;;; cases when TYPES is short.
905 enumerable
906 ;; FIXME: This should be just (COERCE TYPES 'LIST), but as
907 ;; of sbcl-0.6.11.17 the COERCE optimizer is really
908 ;; brain-dead, so that would generate a full call to
909 ;; SPECIFIER-TYPE at runtime, so we get into bootstrap
910 ;; problems in cold init because 'LIST is a compound
911 ;; type, so we need to MAKE-COMPOUND-TYPE-OR-SOMETHING
912 ;; before we know what 'LIST is. Once the COERCE
913 ;; optimizer is less brain-dead, we can make this
914 ;; (COERCE TYPES 'LIST) again.
924 union)
925 union
926 nil)))
935 #'intersection-type-p
938 ;; We want to have a canonical representation of types (or failing
939 ;; that, punt to HAIRY-TYPE). Canonical representation would have
940 ;; intersections inside unions but not vice versa, since you can
941 ;; always achieve that by the distributive rule. But we don't want
942 ;; to just apply the distributive rule, since it would be too easy
943 ;; to end up with unreasonably huge type expressions. So instead
944 ;; we try to generate a simple type by distributing the union; if
945 ;; the type can't be made simple, we punt to HAIRY-TYPE.
952 other-types)))
957 #'type-specifier
958 simplified-types)))))
960 simplified-types
962 simplified-types)
972 #'union-type-p
975 simplified-types
978 \f
979 ;;;; built-in types
987 (!cold-init-forms
994 ;; KLUDGE: In ANSI, * isn't really the name of a type, it's just a
995 ;; special symbol which can be stuck in some places where an
996 ;; ordinary type can go, e.g. (ARRAY * 1) instead of (ARRAY T 1).
997 ;; At some point, in order to become more standard, we should
998 ;; convert all the classic CMU CL legacy *s and *WILD-TYPE*s into
999 ;; Ts and *UNIVERSAL-TYPE*s.
1008 ;; FIXME: BUG 85: This assertion failed when I added it in
1009 ;; sbcl-0.6.11.13. It probably shouldn't fail; but for now it's
1010 ;; just commented out.
1011 ;;(aver (not (eq type1 *wild-type*))) ; * isn't really a type.
1018 ;; not allowed to be unsure on these... FIXME: keep the list
1019 ;; of CL types that are intersection types once and only
1020 ;; once.
1023 ;; things like (AND (EQL 0) (SATISFIES ODDP)) or (AND FUNCTION
1024 ;; STREAM) can get here. In general, we can't really tell
1025 ;; whether these are equal to NIL or not, so
1036 ;; This AVER causes problems if we write accurate methods for the
1037 ;; union (and possibly intersection) types which then delegate to
1038 ;; us; while a user shouldn't get here, because of the odd status of
1039 ;; *wild-type* a type-intersection executed by the compiler can. -
1040 ;; CSR, 2002-04-10
1041 ;;
1042 ;; (aver (not (eq type1 *wild-type*))) ; * isn't really a type.
1044 t)
1047 ;; Now that the UNION and HAIRY COMPLEX-SUBTYPEP-ARG2 methods
1048 ;; can delegate to us (more or less as CALL-NEXT-METHOD) when
1049 ;; they're uncertain, we can't just barf on COMPOUND-TYPE and
1050 ;; HAIRY-TYPEs as we used to. Instead we deal with the
1051 ;; problem (where at least part of the problem is cases like
1052 ;; (SUBTYPEP T '(SATISFIES FOO))
1053 ;; or
1054 ;; (SUBTYPEP T '(AND (SATISFIES FOO) (SATISFIES BAR)))
1055 ;; where the second type is a hairy type like SATISFIES, or
1056 ;; is a compound type which might contain a hairy type) by
1057 ;; returning uncertainty.
1060 ;; By elimination, TYPE1 is the universal type.
1062 ;; This case would have been picked off by the SIMPLE-SUBTYPEP
1063 ;; method, and so shouldn't appear here.
1065 ;; Since TYPE2 is not EQ *UNIVERSAL-TYPE* and is not the
1066 ;; universal type in disguise, TYPE2 is not a superset of TYPE1.
1074 ;; those types can be *EMPTY-TYPE* or *UNIVERSAL-TYPE* in
1075 ;; disguise. So we'd better delegate.
1078 ;; FIXME: This seems to rely on there only being 2 or 3
1079 ;; NAMED-TYPE values, and the exclusion of various
1080 ;; possibilities above. It would be good to explain it and/or
1081 ;; rewrite it so that it's clearer.
1085 ;; FIXME: This assertion failed when I added it in sbcl-0.6.11.13.
1086 ;; Perhaps when bug 85 is fixed it can be reenabled.
1087 ;;(aver (not (eq type2 *wild-type*))) ; * isn't really a type.
1091 ;; Perhaps when bug 85 is fixed this can be reenabled.
1092 ;;(aver (not (eq type2 *wild-type*))) ; * isn't really a type.
1097 \f
1098 ;;;; hairy and unknown types
1125 type1
1126 nil))
1131 type1
1132 nil))
1142 ;; Check legality of arguments.
1147 :datum predicate-name
1151 ;; Create object.
1153 \f
1154 ;;;; negation types
1165 complement-type2)))
1167 ;; FIXME: if uncertain, maybe try arg1?
1172 ;; "Incrementally extended heuristic algorithms tend inexorably toward the
1173 ;; incomprehensible." -- http://www.unlambda.com/~james/lambda/lambda.txt
1174 ;;
1175 ;; You may not believe this. I couldn't either. But then I sat down
1176 ;; and drew lots of Venn diagrams. Comments involving a and b refer
1177 ;; to the call (subtypep '(not a) 'b) -- CSR, 2002-02-27.
1179 ;; (Several logical truths in this block are true as long as
1180 ;; b/=T. As of sbcl-0.7.1.28, it seems impossible to construct a
1181 ;; case with b=T where we actually reach this type method, but
1182 ;; we'll test for and exclude this case anyway, since future
1183 ;; maintenance might make it possible for it to end up in this
1184 ;; code.)
1192 ;; Do the special cases first, in order to give us a chance if
1193 ;; subtype/supertype relationships are hairy.
1196 ;; If a = b, ~a is not a subtype of b (unless b=T, which was
1197 ;; excluded above).
1202 ;; KLUDGE: ANSI requires that the SUBTYPEP result between any
1203 ;; two built-in atomic type specifiers never be uncertain. This
1204 ;; is hard to do cleanly for the built-in types whose
1205 ;; definitions include (NOT FOO), i.e. CONS and RATIO. However,
1206 ;; we can do it with this hack, which uses our global knowledge
1207 ;; that our implementation of the type system uses disjoint
1208 ;; implementation types to represent disjoint sets (except when
1209 ;; types are contained in other types). (This is a KLUDGE
1210 ;; because it's fragile. Various changes in internal
1211 ;; representation in the type system could make it start
1212 ;; confidently returning incorrect results.) -- WHN 2002-03-08
1215 ;; Because of the way our types which don't contain other
1216 ;; types are disjoint subsets of the space of possible values,
1217 ;; (SUBTYPEP '(NOT AA) 'B)=NIL when AA and B are simple (and B
1218 ;; is not T, as checked above).
1220 ;; The old (TYPE= TYPE1 TYPE2) branch would never be taken, as
1221 ;; TYPE1 and TYPE2 will only be equal if they're both NOT types,
1222 ;; and then the :SIMPLE-SUBTYPEP method would be used instead.
1223 ;; But a CSUBTYPEP relationship might still hold:
1226 ;; If a is a subtype of b, ~a is not a subtype of b (unless
1227 ;; b=T, which was excluded above).
1234 ;; If b is a subtype of a, ~a is not a subtype of b. (FIXME:
1235 ;; That's not true if a=T. Do we know at this point that a is
1236 ;; not T?)
1241 ;; old CSR comment ca. 0.7.2, now obsoleted by the SIMPLE-CTYPE?
1242 ;; KLUDGE case above: Other cases here would rely on being able
1243 ;; to catch all possible cases, which the fragility of this type
1244 ;; system doesn't inspire me; for instance, if a is type= to ~b,
1245 ;; then we want T, T; if this is not the case and the types are
1246 ;; disjoint (have an intersection of *empty-type*) then we want
1247 ;; NIL, T; else if the union of a and b is the *universal-type*
1248 ;; then we want T, T. So currently we still claim to be unsure
1249 ;; about e.g. (subtypep '(not fixnum) 'single-float).
1250 ;;
1251 ;; OTOH we might still get here:
1255 ;; (NOT FOO) isn't equivalent to anything that's not a negation
1256 ;; type, except possibly a type that might contain it in disguise.
1268 ;; Why no analagous clause to the disjoint in the SIMPLE-UNION2
1269 ;; method, below? The clause would read
1270 ;;
1271 ;; ((EQ (TYPE-UNION NOT1 NOT2) *UNIVERSAL-TYPE*) *EMPTY-TYPE*)
1272 ;;
1273 ;; but with proper canonicalization of negation types, there's
1274 ;; no way of constructing two negation types with union of their
1275 ;; negations being the universal type.
1278 nil))))
1284 type1)
1301 type2)
1311 ;; canonicalize (NOT (NOT FOO))
1314 ;; canonicalize (NOT NIL) and (NOT T)
1328 not-type
1334 not-type
1335 :low nil
1340 not-type
1341 :low nil
1345 not-type
1390 \f
1391 ;;;; numeric types
1402 t))
1437 'unsigned-byte
1441 (:real
1443 (:complex
1445 'complex
1451 ;;; Return true if X is "less than or equal" to Y, taking open bounds
1452 ;;; into consideration. CLOSED is the predicate used to test the bound
1453 ;;; on a closed interval (e.g. <=), and OPEN is the predicate used on
1454 ;;; open bounds (e.g. <). Y is considered to be the outside bound, in
1455 ;;; the sense that if it is infinite (NIL), then the test succeeds,
1456 ;;; whereas if X is infinite, then the test fails (unless Y is also
1457 ;;; infinite).
1458 ;;;
1459 ;;; This is for comparing bounds of the same kind, e.g. upper and
1460 ;;; upper. Use NUMERIC-BOUND-TEST* for different kinds of bounds.
1461 #!-negative-zero-is-not-zero
1474 #!+negative-zero-is-not-zero
1480 #!+negative-zero-is-not-zero
1493 ;;; This is used to compare upper and lower bounds. This is different
1494 ;;; from the same-bound case:
1495 ;;; -- Since X = NIL is -infinity, whereas y = NIL is +infinity, we
1496 ;;; return true if *either* arg is NIL.
1497 ;;; -- an open inner bound is "greater" and also squeezes the interval,
1498 ;;; causing us to use the OPEN test for those cases as well.
1499 #!-negative-zero-is-not-zero
1512 #!+negative-zero-is-not-zero
1525 ;;; Return whichever of the numeric bounds X and Y is "maximal"
1526 ;;; according to the predicates CLOSED (e.g. >=) and OPEN (e.g. >).
1527 ;;; This is only meaningful for maximizing like bounds, i.e. upper and
1528 ;;; upper. If MAX-P is true, then we return NIL if X or Y is NIL,
1529 ;;; otherwise we return the other arg.
1553 ;; If one is complex and the other isn't, they are disjoint.
1557 ;; If the classes are specified and different, the types are
1558 ;; disjoint unless type2 is RATIONAL and type1 is INTEGER.
1559 ;; [ or type1 is INTEGER and type2 is of the form (RATIONAL
1560 ;; X X) for integral X, but this is dealt with in the
1561 ;; canonicalization inside MAKE-NUMERIC-TYPE ]
1566 ;; If the float formats are specified and different, the types
1567 ;; are disjoint.
1571 ;; Check the bounds.
1580 ;;; If the high bound of LOW is adjacent to the low bound of HIGH,
1581 ;;; then return true, otherwise NIL.
1588 #!-negative-zero-is-not-zero
1595 #!+negative-zero-is-not-zero
1598 #!-negative-zero-is-not-zero
1605 #!+negative-zero-is-not-zero
1607 #!+negative-zero-is-not-zero
1614 nil))))
1616 ;;; Return a numeric type that is a supertype for both TYPE1 and TYPE2.
1617 ;;;
1618 ;;; Old comment, probably no longer applicable:
1619 ;;;
1620 ;;; ### Note: we give up early to keep from dropping lots of
1621 ;;; information on the floor by returning overly general types.
1641 :class class1
1642 :format format1
1643 :complexp complexp1
1650 ;; FIXME: These two clauses are almost identical, and the
1651 ;; consequents are in fact identical in every respect.
1663 :format format1
1664 :complexp complexp1
1682 :format format1
1683 :complexp complexp1
1693 (!cold-init-forms
1704 typespec))
1707 typespec))
1717 ;; KLUDGE: This TYPECASE more or less does
1718 ;; (UPGRADED-COMPLEX-PART-TYPE (TYPE-OF COMPONENT)),
1719 ;; (plus a small hack to treat (EQL COMPONENT 0) specially)
1720 ;; but uses logic cut and pasted from the DEFUN of
1721 ;; UPGRADED-COMPLEX-PART-TYPE. That's fragile, because
1722 ;; changing the definition of UPGRADED-COMPLEX-PART-TYPE
1723 ;; would tend to break the code here. Unfortunately,
1724 ;; though, reusing UPGRADED-COMPLEX-PART-TYPE here
1725 ;; would cause another kind of fragility, because
1726 ;; ANSI's definition of TYPE-OF is so weak that e.g.
1727 ;; (UPGRADED-COMPLEX-PART-TYPE (TYPE-OF 1/2)) could
1728 ;; end up being (UPGRADED-COMPLEX-PART-TYPE 'REAL)
1729 ;; instead of (UPGRADED-COMPLEX-PART-TYPE 'RATIONAL).
1730 ;; So using TYPE-OF would mean that ANSI-conforming
1731 ;; maintenance changes in TYPE-OF could break the code here.
1732 ;; It's not clear how best to fix this. -- WHN 2002-01-21,
1733 ;; trying to summarize CSR's concerns in his patch
1736 is complex: ~S"
1737 component))
1741 #!+long-float
1749 ;; FIXME: This code could suffer from
1750 ;; (admittedly very obscure) cases of
1751 ;; bug 145 e.g. when TYPE is
1752 ;; (OR (AND INTEGER (SATISFIES ODDP))
1753 ;; (AND FLOAT (SATISFIES FOO))
1754 ;; and not even report the problem very well.
1757 ;; MEMBER-TYPE is almost the same as UNION-TYPE, but
1758 ;; there's a gotcha: (COMPLEX (EQL 0)) is, according to
1759 ;; ANSI, equal to type NIL, the empty set.
1768 ;; ANSI just says that TYPESPEC is any subtype of
1769 ;; type REAL, not necessarily a NUMERIC-TYPE. In
1770 ;; particular, at this point TYPESPEC could legally be
1771 ;; an intersection type like (AND REAL (SATISFIES ODDP)),
1772 ;; in which case we fall through the logic above and
1773 ;; end up here, stumped.
1775 used for a COMPLEX component.~:@>"
1776 typespec)))))))))
1778 ;;; If X is *, return NIL, otherwise return the bound, which must be a
1779 ;;; member of TYPE or a one-element list of a member of TYPE.
1787 bound)
1790 '*
1791 type
1792 type
1793 bound))))
1805 :low lb
1816 :low lb
1821 ;;; Unlike CMU CL, we represent the types FLOAT and REAL as
1822 ;;; UNION-TYPEs of more primitive types, in order to make
1823 ;;; type representation more unique, avoiding problems in the
1824 ;;; simplification of things like
1825 ;;; (subtypep '(or (single-float -1.0 1.0) (single-float 0.1))
1826 ;;; '(or (real -1 7) (single-float 0.1) (single-float -1.0 1.0)))
1827 ;;; When we allowed REAL to remain as a separate NUMERIC-TYPE,
1828 ;;; it was too easy for the first argument to be simplified to
1829 ;;; '(SINGLE-FLOAT -1.0), and for the second argument to be simplified
1830 ;;; to '(OR (REAL -1 7) (SINGLE-FLOAT 0.1)) and then for the
1831 ;;; SUBTYPEP to fail (returning NIL,T instead of T,T) because
1832 ;;; the first argument can't be seen to be a subtype of any of the
1833 ;;; terms in the second argument.
1834 ;;;
1835 ;;; The old CMU CL way was:
1836 ;;; (!def-bounded-type float float nil)
1837 ;;; (!def-bounded-type real nil nil)
1838 ;;;
1839 ;;; FIXME: If this new way works for a while with no weird new
1840 ;;; problems, we can go back and rip out support for separate FLOAT
1841 ;;; and REAL flavors of NUMERIC-TYPE. The new way was added in
1842 ;;; sbcl-0.6.11.22, 2001-03-21.
1843 ;;;
1844 ;;; FIXME: It's probably necessary to do something to fix the
1845 ;;; analogous problem with INTEGER and RATIONAL types. Perhaps
1846 ;;; bounded RATIONAL types should be represented as (OR RATIO INTEGER).
1850 bound)
1860 bound
1861 ;; Coerce to the widest float format available, to
1862 ;; avoid unnecessary loss of precision:
1901 ;; If one is complex and the other isn't, then they are disjoint.
1904 nil)
1905 ;; If either type is a float, then the other must either be
1906 ;; specified to be a float or unspecified. Otherwise, they
1907 ;; are disjoint.
1912 ;; If the float formats are specified and different, the
1913 ;; types are disjoint.
1915 nil)
1917 ;; Check the bounds. This is a bit odd because we must
1918 ;; always have the outer bound of the interval as the
1919 ;; second arg.
1930 ;;; Take the numeric bound X and convert it into something that can be
1931 ;;; used as a bound in a numeric type with the specified CLASS and
1932 ;;; FORMAT. If UP-P is true, then we round up as needed, otherwise we
1933 ;;; round down. UP-P true implies that X is a lower bound, i.e. (N) > N.
1934 ;;;
1935 ;;; This is used by NUMERIC-TYPE-INTERSECTION to mash the bound into
1936 ;;; the appropriate type number. X may only be a float when CLASS is
1937 ;;; FLOAT.
1938 ;;;
1939 ;;; ### Note: it is possible for the coercion to a float to overflow
1940 ;;; or underflow. This happens when the bound doesn't fit in the
1941 ;;; specified format. In this case, we should really return the
1942 ;;; appropriate {Most | Least}-{Positive | Negative}-XXX-Float float
1943 ;;; of desired format. But these conditions aren't currently signalled
1944 ;;; in any useful way.
1945 ;;;
1946 ;;; Also, when converting an open rational bound into a float we
1947 ;;; should probably convert it to a closed bound of the closest float
1948 ;;; in the specified format. KLUDGE: In general, open float bounds are
1949 ;;; screwed up. -- (comment from original CMU CL)
1962 nil))
1964 ;;; Handle the case of type intersection on two numeric types. We use
1965 ;;; TYPES-EQUAL-OR-INTERSECT to throw out the case of types with no
1966 ;;; intersection. If an attribute in TYPE1 is unspecified, then we use
1967 ;;; TYPE2's attribute, which must be at least as restrictive. If the
1968 ;;; types intersect, then the only attributes that can be specified
1969 ;;; and different are the class and the bounds.
1970 ;;;
1971 ;;; When the class differs, we use the more restrictive class. The
1972 ;;; only interesting case is RATIONAL/INTEGER, since RATIONAL includes
1973 ;;; INTEGER.
1974 ;;;
1975 ;;; We make the result lower (upper) bound the maximum (minimum) of
1976 ;;; the argument lower (upper) bounds. We convert the bounds into the
1977 ;;; appropriate numeric type before maximizing. This avoids possible
1978 ;;; confusion due to mixed-type comparisons (but I think the result is
1979 ;;; the same).
1989 'integer
1994 :class class
1995 :format format
2000 class format t)
2002 class format t)
2006 class format nil)
2008 class format nil)
2012 ;;; Given two float formats, return the one with more precision. If
2013 ;;; either one is null, return NIL.
2020 ;;; Return the result of an operation on TYPE1 and TYPE2 according to
2021 ;;; the rules of numeric contagion. This is always NUMBER, some float
2022 ;;; format (possibly complex) or RATIONAL. Due to rational
2023 ;;; canonicalization, there isn't much we can do here with integers or
2024 ;;; rational complex numbers.
2025 ;;;
2026 ;;; If either argument is not a NUMERIC-TYPE, then return NUMBER. This
2027 ;;; is useful mainly for allowing types that are technically numbers,
2028 ;;; but not a NUMERIC-TYPE.
2047 ;; A double-float with any real number is a
2048 ;; double-float.
2049 #!-long-float
2051 'double-float
2052 nil)
2053 ;; A long-float with any real number is a
2054 ;; long-float.
2055 #!+long-float
2057 'long-float
2058 nil)))
2061 :complex
2071 \f
2072 ;;;; array types
2076 ;;; What this does depends on the setting of the
2077 ;;; *USE-IMPLEMENTATION-TYPES* switch. If true, return the specialized
2078 ;;; element type, otherwise return the original element type.
2091 ;; by its nature, the call to TYPE= should never return NIL,
2092 ;; T, as we don't know what the UNKNOWN-TYPE will grow up to
2093 ;; be. -- CSR, 2002-08-19
2102 t)))
2151 ;; (sbcl-0.6.4 has trouble figuring out that
2152 ;; DIMS1 and DIMS2 must be lists at this
2153 ;; point, and knowing that is important to
2154 ;; compiling EVERY efficiently.)
2162 ;; not subtypep unless complexness is compatible
2166 ;; Since we didn't fail any of the tests above, we win
2167 ;; if the TYPE2 element type is wild.
2171 ;; can't give a good answer unless both the element types
2172 ;; have been defined.
2177 ;; types are equal, and they're equal iff the specialized
2178 ;; element types are identical.
2179 t
2182 t)))))
2184 (!define-superclasses array
2196 ;; See whether dimensions are compatible.
2201 dims1 dims2))))
2203 ;; See whether complexpness is compatible.
2208 ;; Old comment:
2209 ;;
2210 ;; If either element type is wild, then they intersect.
2211 ;; Otherwise, the types must be identical.
2212 ;;
2213 ;; FIXME: There seems to have been a fair amount of
2214 ;; confusion about the distinction between requested element
2215 ;; type and specialized element type; here is one of
2216 ;; them. If we request an array to hold objects of an
2217 ;; unknown type, we can do no better than represent that
2218 ;; type as an array specialized on wild-type. We keep the
2219 ;; requested element-type in the -ELEMENT-TYPE slot, and
2220 ;; *WILD-TYPE* in the -SPECIALIZED-ELEMENT-TYPE. So, here,
2221 ;; we must test for the SPECIALIZED slot being *WILD-TYPE*,
2222 ;; not just the ELEMENT-TYPE slot. Maybe the return value
2223 ;; in that specific case should be T, NIL? Or maybe this
2224 ;; function should really be called
2225 ;; ARRAY-TYPES-COULD-POSSIBLY-INTERSECT? In any case, this
2226 ;; was responsible for bug #123, and this whole issue could
2227 ;; do with a rethink and/or a rewrite. -- CSR, 2002-08-21
2252 dims1 dims2)))
2257 ;;; Check a supplied dimension list to determine whether it is legal,
2258 ;;; and return it in canonical form (as either '* or a list).
2277 dims)
2280 \f
2281 ;;;; MEMBER types
2294 t))
2298 type2
2301 ;;; We punt if the odd type is enumerable and intersects with the
2302 ;;; MEMBER type. If not enumerable, then it is definitely not a
2303 ;;; subtype of the MEMBER type.
2335 ;;; We don't need a :COMPLEX-UNION2, since the only interesting case is
2336 ;;; a union type, and the member/union interaction is handled by the
2337 ;;; union type method.
2351 t)))
2374 \f
2375 ;;;; intersection types
2376 ;;;;
2377 ;;;; Until version 0.6.10.6, SBCL followed the original CMU CL approach
2378 ;;;; of punting on all AND types, not just the unreasonably complicated
2379 ;;;; ones. The change was motivated by trying to get the KEYWORD type
2380 ;;;; to behave sensibly:
2381 ;;;; ;; reasonable definition
2382 ;;;; (DEFTYPE KEYWORD () '(AND SYMBOL (SATISFIES KEYWORDP)))
2383 ;;;; ;; reasonable behavior
2384 ;;;; (AVER (SUBTYPEP 'KEYWORD 'SYMBOL))
2385 ;;;; Without understanding a little about the semantics of AND, we'd
2386 ;;;; get (SUBTYPEP 'KEYWORD 'SYMBOL)=>NIL,NIL and, for entirely
2387 ;;;; parallel reasons, (SUBTYPEP 'RATIO 'NUMBER)=>NIL,NIL. That's
2388 ;;;; not so good..)
2389 ;;;;
2390 ;;;; We still follow the example of CMU CL to some extent, by punting
2391 ;;;; (to the opaque HAIRY-TYPE) on sufficiently complicated types
2392 ;;;; involving AND.
2396 ;;; A few intersection types have special names. The others just get
2397 ;;; mechanically unparsed.
2403 ;;; shared machinery for type equality: true if every type in the set
2404 ;;; TYPES1 matches a type in the set TYPES2 and vice versa
2411 x)))
2414 t)))
2416 ;;; Two intersection types are equal if their subtypes are equal sets.
2417 ;;;
2418 ;;; FIXME: Might it be better to use
2419 ;;; (AND (SUBTYPEP X Y) (SUBTYPEP Y X))
2420 ;;; instead, since SUBTYPEP is the usual relationship that we care
2421 ;;; most about, so it would be good to leverage any ingenuity there
2422 ;;; in this more obscure method?
2432 type1
2447 ;;; FIXME: This will look eeriely familiar to readers of the UNION
2448 ;;; :SIMPLE-INTERSECTION2 :COMPLEX-INTERSECTION2 method. That's
2449 ;;; because it was generated by cut'n'paste methods. Given that
2450 ;;; intersections and unions have all sorts of symmetries known to
2451 ;;; mathematics, it shouldn't be beyond the ken of some programmers to
2452 ;;; reflect those symmetries in code in a way that ties them together
2453 ;;; more strongly than having two independent near-copies :-/
2456 ;; Within this method, type2 is guaranteed to be an intersection
2457 ;; type:
2459 ;; Make sure to call only the applicable methods...
2466 type2)
2469 type1)
2470 ;; KLUDGE: This special (and somewhat hairy) magic is required
2471 ;; to deal with the RATIONAL/INTEGER special case. The UNION
2472 ;; of (INTEGER * -1) and (AND (RATIONAL * -1/2) (NOT INTEGER))
2473 ;; should be (RATIONAL * -1/2) -- CSR, 2003-02-28
2480 :complexp nil
2482 nil
2485 nil
2498 ;; we have to give up here -- there are all sorts of
2499 ;; ordering worries, but it's better than before.
2500 ;; Doing exactly the same as in the UNION
2501 ;; :SIMPLE/:COMPLEX-INTERSECTION2 method causes stack
2502 ;; overflow with the mutual recursion never bottoming
2503 ;; out.
2506 ;; KLUDGE: if we get here, we have a partially
2507 ;; simplified result. While this isn't by any
2508 ;; means a universal simplification, including
2509 ;; this logic here means that we can get (OR
2510 ;; KEYWORD (NOT KEYWORD)) canonicalized to T.
2519 type-specifiers)))
2520 \f
2521 ;;;; union types
2525 ;;; The LIST, FLOAT and REAL types have special names. Other union
2526 ;;; types just get mechanically unparsed.
2537 ;;; Two union types are equal if they are each subtypes of each
2538 ;;; other. We need to be this clever because our complex subtypep
2539 ;;; methods are now more accurate; we don't get infinite recursion
2540 ;;; because the simple-subtypep method delegates to complex-subtypep
2541 ;;; of the individual types of type1. - CSR, 2002-04-09
2542 ;;;
2543 ;;; Previous comment, now obsolete, but worth keeping around because
2544 ;;; it is true, though too strong a condition:
2545 ;;;
2546 ;;; Two union types are equal if their subtypes are equal sets.
2552 ;; we might as well become as certain as possible.
2567 ;;; Similarly, a union type is a subtype of another if and only if
2568 ;;; every element of TYPE1 is a subtype of TYPE2.
2571 type2
2579 type2
2587 ;; was: (any/type #'csubtypep type1 (union-type-types type2)),
2588 ;; which turns out to be too restrictive, causing bug 91.
2589 ;;
2590 ;; the following reimplementation might look dodgy. It is
2591 ;; dodgy. It depends on the union :complex-= method not doing
2592 ;; very much work -- certainly, not using subtypep. Reasoning:
2594 ;; At this stage, we know that type2 is a union type and type1
2595 ;; isn't. We might as well check this, though:
2598 ;; A is a subset of (B1 u B2)
2599 ;; <=> A n (B1 u B2) = A
2600 ;; <=> (A n B1) u (A n B2) = A
2601 ;;
2602 ;; But, we have to be careful not to delegate this type= to
2603 ;; something that could invoke subtypep, which might get us
2604 ;; back here -> stack explosion. We therefore ensure that the
2605 ;; second type (which is the one that's dispatched on) is
2606 ;; either a union type (where we've ensured that the complex-=
2607 ;; method will not call subtypep) or something with no union
2608 ;; types involved, in which case we'll never come back here.
2609 ;;
2610 ;; If we don't do this, then e.g.
2611 ;; (SUBTYPEP '(MEMBER 3) '(OR (SATISFIES FOO) (SATISFIES BAR)))
2612 ;; would loop infinitely, as the member :complex-= method is
2613 ;; implemented in terms of subtypep.
2614 ;;
2615 ;; Ouch. - CSR, 2002-04-10
2622 ;; The ANY/TYPE expression above is a sufficient condition for
2623 ;; subsetness, but not a necessary one, so we might get a more
2624 ;; certain answer by this CALL-NEXT-METHOD-ish step when the
2625 ;; ANY/TYPE expression is uncertain.
2633 ;; The CSUBTYPEP clauses here let us simplify e.g.
2634 ;; (TYPE-INTERSECTION2 (SPECIFIER-TYPE 'LIST)
2635 ;; (SPECIFIER-TYPE '(OR LIST VECTOR)))
2636 ;; (where LIST is (OR CONS NULL)).
2637 ;;
2638 ;; The tests are more or less (CSUBTYPEP TYPE1 TYPE2) and vice
2639 ;; versa, but it's important that we pre-expand them into
2640 ;; specialized operations on individual elements of
2641 ;; UNION-TYPE-TYPES, instead of using the ordinary call to
2642 ;; CSUBTYPEP, in order to avoid possibly invoking any methods which
2643 ;; might in turn invoke (TYPE-INTERSECTION2 TYPE1 TYPE2) and thus
2644 ;; cause infinite recursion.
2645 ;;
2646 ;; Within this method, type2 is guaranteed to be a union type:
2648 ;; Make sure to call only the applicable methods...
2655 type1)
2658 type2)
2660 ;; KLUDGE: This code accumulates a sequence of TYPE-UNION2
2661 ;; operations in a particular order, and gives up if any of
2662 ;; the sub-unions turn out not to be simple. In other cases
2663 ;; ca. sbcl-0.6.11.15, that approach to taking a union was a
2664 ;; bad idea, since it can overlook simplifications which
2665 ;; might occur if the terms were accumulated in a different
2666 ;; order. It's possible that that will be a problem here too.
2667 ;; However, I can't think of a good example to demonstrate
2668 ;; it, and without an example to demonstrate it I can't write
2669 ;; test cases, and without test cases I don't want to
2670 ;; complicate the code to address what's still a hypothetical
2671 ;; problem. So I punted. -- WHN 2001-03-20
2681 type-specifiers)))
2682 \f
2683 ;;;; CONS types
2697 'cons
2715 ;;; Give up if a precise type is not possible, to avoid returning
2716 ;;; overly general types.
2723 ;; UGH. -- CSR, 2003-02-24
2737 cdr-type1))
2742 ;; Don't put these in -- consider the effect of taking the
2743 ;; union of (CONS (INTEGER 0 2) (INTEGER 5 7)) and
2744 ;; (CONS (INTEGER 0 3) (INTEGER 5 6)).
2745 #+nil
2748 #+nil
2755 cdr-int2)
2761 \f
2762 ;;; Return the type that describes all objects that are in X but not
2763 ;;; in Y. If we can't determine this type, then return NIL.
2764 ;;;
2765 ;;; For now, we only are clever dealing with union and member types.
2766 ;;; If either type is not a union type, then we pretend that it is a
2767 ;;; union of just one type. What we do is remove from X all the types
2768 ;;; that are a subtype any type in Y. If any type in X intersects with
2769 ;;; a type in Y but is not a subtype, then we give up.
2770 ;;;
2771 ;;; We must also special-case any member type that appears in the
2772 ;;; union. We remove from X's members all objects that are TYPEP to Y.
2773 ;;; If Y has any members, we must be careful that none of those
2774 ;;; members are CTYPEP to any of Y's non-member types. We give up in
2775 ;;; this case, since to compute that difference we would have to break
2776 ;;; the type from X into some collection of types that represents the
2777 ;;; type without that particular element. This seems too hairy to be
2778 ;;; worthwhile, given its low utility.
2809 \f
2821 :complexp nil
2823 \f
2824 ;;;; utilities shared between cross-compiler and target system
2826 ;;; Does the type derived from compilation of an actual function
2827 ;;; definition satisfy declarations of a function's type?
2834 ;; that's what happens when we (DECLAIM (FTYPE FUNCTION FOO)).
2836 ;; In that case, any definition satisfies the declaration.
2837 t)
2839 ;; #<BUILT-IN-CLASS FUNCTION>, but it's not obviously
2840 ;; invalid, so let's handle that case too, just in case.
2842 ;; No matter what DECLARED-FTYPE might be, we can't prove
2843 ;; that an object of type FUNCTION doesn't satisfy it, so
2844 ;; we return success no matter what.
2845 t)
2847 t
2848 ;; FIXME: For now we only check compatibility of the return
2849 ;; type, not argument types, and we don't even check the
2850 ;; return type very precisely (as per bug 94a). It would be
2851 ;; good to do a better job. Perhaps to check the
2852 ;; compatibility of the arguments, we should (1) redo
2853 ;; VALUES-TYPES-EQUAL-OR-INTERSECT as
2854 ;; ARGS-TYPES-EQUAL-OR-INTERSECT, and then (2) apply it to
2855 ;; the ARGS-TYPE slices of the FUN-TYPEs. (ARGS-TYPE
2856 ;; is a base class both of VALUES-TYPE and of FUN-TYPE.)
2861 ;;; This messy case of CTYPE for NUMBER is shared between the
2862 ;;; cross-compiler and the target system.
2875 :complexp complexp
2876 :low low
2878 \f
2880 ;; Why SAFETY 0? To suppress the is-it-the-right-structure-type
2881 ;; checking for declarations in structure accessors. Otherwise we
2882 ;; can get caught in a chicken-and-egg bootstrapping problem, whose
2883 ;; symptom on x86 OpenBSD sbcl-0.pre7.37.flaky5.22 is an illegal
2884 ;; instruction trap. I haven't tracked it down, but I'm guessing it
2885 ;; has to do with setting LAYOUTs when the LAYOUT hasn't been set
2886 ;; yet. -- WHN