| blob | ac0ce019b20f8193caf7608399a9db2285b50308 |
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 ;;; There are all sorts of nasty problems with open bounds on FLOAT
26 ;;; types (and probably FLOAT types in general.)
28 ;;; This condition is signalled whenever we make a UNKNOWN-TYPE so that
29 ;;; compiler warnings can be emitted as appropriate.
33 ;;; FIXME: This really should go away. Alas, it doesn't seem to be so
34 ;;; simple to make it go away.. (See bug 123 in BUGS file.)
36 #!+sb-doc
37 "*USE-IMPLEMENTATION-TYPES* is a semi-public flag which determines how
38 restrictive we are in determining type membership. If two types are the
39 same in the implementation, then we will consider them them the same when
40 this switch is on. When it is off, we try to be as restrictive as the
41 language allows, allowing us to detect more errors. Currently, this only
45 ;;; These functions are used as method for types which need a complex
46 ;;; subtypep method to handle some superclasses, but cover a subtree
47 ;;; of the type graph (i.e. there is no simple way for any other type
48 ;;; class to be a subtype.) There are always still complex ways,
49 ;;; namely UNION and MEMBER types, so we must give TYPE1's method a
50 ;;; chance to run, instead of immediately returning NIL, T.
64 ;;; This is used by !DEFINE-SUPERCLASSES to define the SUBTYPE-ARG1
65 ;;; method. INFO is a list of conses
66 ;;; (SUPERCLASS-CLASS . {GUARD-TYPE-SPECIFIER | NIL}).
68 ;; If TYPE2 might be concealing something related to our class
69 ;; hierarchy
71 ;; too confusing, gotta punt
73 ;; ordinary case expected by old CMU CL code, where the taxonomy
74 ;; of TYPE2's representation accurately reflects the taxonomy of
75 ;; the underlying set
77 ;; FIXME: This old CMU CL code probably deserves a comment
78 ;; 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.
106 `(,when
111 spec
121 \f
122 ;;;; FUNCTION and VALUES types
123 ;;;;
124 ;;;; Pretty much all of the general type operations are illegal on
125 ;;;; VALUES types, since we can't discriminate using them, do
126 ;;;; SUBTYPEP, etc. FUNCTION types are acceptable to the normal type
127 ;;;; operations, but are generally considered to be equivalent to
128 ;;;; FUNCTION. These really aren't true types in any type theoretic
129 ;;;; sense, but we still parse them into CTYPE structures for two
130 ;;;; reasons:
132 ;;;; -- Parsing and unparsing work the same way, and indeed we can't
133 ;;;; tell whether a type is a function or values type without
134 ;;;; parsing it.
135 ;;;; -- Many of the places that can be annotated with real types can
136 ;;;; also be annotated with function or values types.
138 ;;; the description of a &KEY argument
141 ;; the key (not necessarily a keyword in ANSI Common Lisp)
143 ;; the type of the argument value
149 ;; FIXME: should be TYPE-ERROR, here and in next method
166 unparsed
169 ;;; Return true if LIST1 and LIST2 have the same elements in the same
170 ;;; positions according to TYPE=. We return NIL, NIL if there is an
171 ;;; uncertain comparison.
192 ;;; a flag that we can bind to cause complex function types to be
193 ;;; unparsed as FUNCTION. This is useful when we want a type that we
194 ;;; can pass to TYPEP.
203 'function
206 '*
211 ;;; The meaning of this is a little confused. On the one hand, all
212 ;;; function objects are represented the same way regardless of the
213 ;;; arglists and return values, and apps don't get to ask things like
214 ;;; (TYPEP #'FOO (FUNCTION (FIXNUM) *)) in any meaningful way. On the
215 ;;; other hand, Python wants to reason about function types. So...
222 for a1 in types1
223 for a2 in types2
241 type2))))))
266 ;;; The union or intersection of two FUNCTION types is FUNCTION.
295 :optional opt
296 :rest rest
297 ;; FIXME: :keys
302 ;;; The union or intersection of a subclass of FUNCTION with a
303 ;;; FUNCTION type is somewhat complicated.
311 ;; TYPE2 is a FUNCTION type. If TYPE1 is a classoid type naming
312 ;; FUNCTION, then it is the union of the two; otherwise, there is no
313 ;; special union.
343 ;;; Return the lambda-list-like type specification corresponding
344 ;;; to an ARGS-TYPE.
378 \f
379 ;;;; VALUES types interfaces
380 ;;;;
381 ;;;; We provide a few special operations that can be meaningfully used
382 ;;;; on VALUES types (as well as on any other type).
390 ;;; Return the type of the first value indicated by TYPE. This is used
391 ;;; by people who don't want to have to deal with VALUES types.
393 ; (inline single-value-type))
401 type)
407 ;;; Return the minimum number of arguments that a function can be
408 ;;; called with, and the maximum number or NIL. If not a function
409 ;;; type, return NIL, NIL.
421 ;;; Determine whether TYPE corresponds to a definite number of values.
422 ;;; The first value is a list of the types for each value, and the
423 ;;; second value is the number of values. If the number of values is
424 ;;; not fixed, then return NIL and :UNKNOWN.
436 ;;; Return two values:
437 ;;; 1. A list of all the positional (fixed and optional) types.
438 ;;; 2. The &REST type (if any). If no &REST, then the DEFAULT-TYPE.
448 ;;; types of values in (the <type> (values o_1 ... o_n))
463 repeat count
467 ;;; types of variable in (m-v-bind (v_1 ... v_n) (the <type> ...
486 repeat count
490 ;;; Return a list of OPERATION applied to the types in TYPES1 and
491 ;;; TYPES2, padding with REST2 as needed. TYPES1 must not be shorter
492 ;;; than TYPES2. The second value is T if OPERATION always returned a
493 ;;; true second value.
502 res))
503 types1
507 exact)))
509 ;;; If TYPE isn't a values type, then make it into one.
519 ;; FIXME: What should we do with (NOT SURE)?
530 type)
533 ;;; Return type, corresponding to ANSI short form of VALUES type
534 ;;; specifier.
540 types
551 ;;; Do the specified OPERATION on TYPE1 and TYPE2, which may be any
552 ;;; type, including VALUES types. With VALUES types such as:
553 ;;; (VALUES a0 a1)
554 ;;; (VALUES b0 b1)
555 ;;; we compute the more useful result
556 ;;; (VALUES (<operation> a0 b0) (<operation> a1 b1))
557 ;;; rather than the precise result
558 ;;; (<operation> (values a0 a1) (values b0 b1))
559 ;;; This has the virtue of always keeping the VALUES type specifier
560 ;;; outermost, and retains all of the information that is really
561 ;;; useful for static type analysis. We want to know what is always
562 ;;; true of each value independently. It is worthless to know that if
563 ;;; the first value is B0 then the second will be B1.
564 ;;;
565 ;;; If the VALUES count signatures differ, then we produce a result with
566 ;;; the required VALUE count chosen by NREQ when applied to the number
567 ;;; of required values in TYPE1 and TYPE2. Any &KEY values become
568 ;;; &REST T (anyone who uses keyword values deserves to lose.)
569 ;;;
570 ;;; The second value is true if the result is definitely empty or if
571 ;;; OPERATION returned true as its second value each time we called
572 ;;; it. Since we approximate the intersection of VALUES types, the
573 ;;; second value being true doesn't mean the result is exact.
601 :optional optional
603 exactp)))
622 ;;; Do a union or intersection operation on types that might be values
623 ;;; types. The result is optimized for utility rather than exactness,
624 ;;; but it is guaranteed that it will be no smaller (more restrictive)
625 ;;; than the precise result.
626 ;;;
627 ;;; The return convention seems to be analogous to
628 ;;; TYPES-EQUAL-OR-INTERSECT. -- WHN 19990910.
631 :default nil
650 type1)
663 #'type-intersection
666 ;;; This is like TYPES-EQUAL-OR-INTERSECT, except that it sort of
667 ;;; works on VALUES types. Note that due to the semantics of
668 ;;; VALUES-TYPE-INTERSECTION, this might return (VALUES T T) when
669 ;;; there isn't really any intersection.
678 t)))))
680 ;;; a SUBTYPEP-like operation that can be used on any types, including
681 ;;; VALUES types
700 type2))
720 \f
721 ;;;; type method interfaces
723 ;;; like SUBTYPEP, only works on CTYPE structures
735 #+nil
740 type1 type2
743 ;;; Just parse the type specifiers and call CSUBTYPE.
745 #!+sb-doc
746 "Return two values indicating the relationship between type1 and type2.
747 If values are T and T, type1 definitely is a subtype of type2.
748 If values are NIL and T, type1 definitely is not a subtype of type2.
749 If values are NIL and NIL, it couldn't be determined."
753 ;;; If two types are definitely equivalent, return true. The second
754 ;;; value indicates whether the first value is definitely correct.
755 ;;; This should only fail in the presence of HAIRY types.
767 ;;; Not exactly the negation of TYPE=, since when the relationship is
768 ;;; uncertain, we still return NIL, NIL. This is useful in cases where
769 ;;; the conservative assumption is =.
777 ;;; the type method dispatch case of TYPE-UNION2
779 ;; As in %TYPE-INTERSECTION2, it seems to be a good idea to give
780 ;; both argument orders a chance at COMPLEX-INTERSECTION2. Unlike
781 ;; %TYPE-INTERSECTION2, though, I don't have a specific case which
782 ;; demonstrates this is actually necessary. Also unlike
783 ;; %TYPE-INTERSECTION2, there seems to be no need to distinguish
784 ;; between not finding a method and having a method return NIL.
787 x y
793 ;;; Find a type which includes both types. Any inexactness is
794 ;;; represented by the fuzzy element types; we return a single value
795 ;;; that is precise to the best of our knowledge. This result is
796 ;;; simplified into the canonical form, thus is not a UNION-TYPE
797 ;;; unless we find no other way to represent the result.
802 ;; KLUDGE: This was generated from TYPE-INTERSECTION2 by Ye Olde Cut And
803 ;; Paste technique of programming. If it stays around (as opposed to
804 ;; e.g. fading away in favor of some CLOS solution) the shared logic
805 ;; should probably become shared code. -- WHN 2001-03-16
808 type1)
813 ;; Unions of UNION-TYPE should have the UNION-TYPE-TYPES
814 ;; values broken out and united separately. The full TYPE-UNION
815 ;; function knows how to do this, so let it handle it.
818 ;; the ordinary case: we dispatch to type methods
821 ;;; the type method dispatch case of TYPE-INTERSECTION2
823 ;; We want to give both argument orders a chance at
824 ;; COMPLEX-INTERSECTION2. Without that, the old CMU CL type
825 ;; methods could give noncommutative results, e.g.
826 ;; (TYPE-INTERSECTION2 *EMPTY-TYPE* SOME-HAIRY-TYPE)
827 ;; => NIL, NIL
828 ;; (TYPE-INTERSECTION2 SOME-HAIRY-TYPE *EMPTY-TYPE*)
829 ;; => #<NAMED-TYPE NIL>, T
830 ;; We also need to distinguish between the case where we found a
831 ;; type method, and it returned NIL, and the case where we fell
832 ;; through without finding any type method. An example of the first
833 ;; case is the intersection of a HAIRY-TYPE with some ordinary type.
834 ;; An example of the second case is the intersection of two
835 ;; completely-unrelated types, e.g. CONS and NUMBER, or SYMBOL and
836 ;; ARRAY.
837 ;;
838 ;; (Why yes, CLOS probably *would* be nicer..)
841 x y
853 nil))))))))
858 :default nil
863 ;; FIXME: For some reason, this doesn't catch e.g. type1 =
864 ;; type2 = (SPECIFIER-TYPE
865 ;; 'SOME-UNKNOWN-TYPE). Investigate. - CSR, 2002-04-10
866 type1)
869 ;; Intersections of INTERSECTION-TYPE should have the
870 ;; INTERSECTION-TYPE-TYPES values broken out and intersected
871 ;; separately. The full TYPE-INTERSECTION function knows how
872 ;; to do that, so let it handle it.
875 ;; the ordinary case: we dispatch to type methods
878 ;;; Return as restrictive and simple a type as we can discover that is
879 ;;; no more restrictive than the intersection of TYPE1 and TYPE2. At
880 ;;; worst, we arbitrarily return one of the arguments as the first
881 ;;; value (trying not to return a hairy type).
887 ;;; a test useful for checking whether a derived type matches a
888 ;;; declared type
889 ;;;
890 ;;; The first value is true unless the types don't intersect and
891 ;;; aren't equal. The second value is true if the first value is
892 ;;; definitely correct. NIL is considered to intersect with any type.
893 ;;; If T is a subtype of either type, then we also return T, T. This
894 ;;; way we recognize that hairy types might intersect with T.
908 ;;; Return a Common Lisp type specifier corresponding to the TYPE
909 ;;; object.
919 :default nil
925 ;;; (VALUES-SPECIFIER-TYPE and SPECIFIER-TYPE moved from here to
926 ;;; early-type.lisp by WHN ca. 19990201.)
928 ;;; Take a list of type specifiers, computing the translation of each
929 ;;; specifier and defining it as a builtin type.
936 ;; KLUDGE: the three copies of this idiom in this file (and
937 ;; the one in class.lisp as at sbcl-0.7.4.1x) should be
938 ;; coalesced, or perhaps the error-detecting code that
939 ;; disallows redefinition of :PRIMITIVE types should be
940 ;; rewritten to use *TYPE-SYSTEM-FINALIZED* (rather than
941 ;; *TYPE-SYSTEM-INITIALIZED*). The effect of this is not to
942 ;; cause redefinition errors when precompute-types is called
943 ;; for a second time while building the target compiler using
944 ;; the cross-compiler. -- CSR, trying to explain why this
945 ;; isn't completely wrong, 2002-06-07
948 \f
949 ;;;; general TYPE-UNION and TYPE-INTERSECTION operations
950 ;;;;
951 ;;;; These are fully general operations on CTYPEs: they'll always
952 ;;;; return a CTYPE representing the result.
954 ;;; shared logic for unions and intersections: Return a list of
955 ;;; types representing the same types as INPUT-TYPES, but with
956 ;;; COMPOUND-TYPEs satisfying %COMPOUND-TYPE-P broken up into their
957 ;;; component types, and with any SIMPLY2 simplifications applied.
981 union)
982 union
983 nil)))
993 ;; We want to have a canonical representation of types (or failing
994 ;; that, punt to HAIRY-TYPE). Canonical representation would have
995 ;; intersections inside unions but not vice versa, since you can
996 ;; always achieve that by the distributive rule. But we don't want
997 ;; to just apply the distributive rule, since it would be too easy
998 ;; to end up with unreasonably huge type expressions. So instead
999 ;; we try to generate a simple type by distributing the union; if
1000 ;; the type can't be made simple, we punt to HAIRY-TYPE.
1006 other-types)))
1011 #'type-specifier
1012 simplified-types)))))
1018 simplified-types))))))
1032 simplified-types)))))
1033 \f
1034 ;;;; built-in types
1038 (!cold-init-forms
1045 ;; KLUDGE: In ANSI, * isn't really the name of a type, it's just a
1046 ;; special symbol which can be stuck in some places where an
1047 ;; ordinary type can go, e.g. (ARRAY * 1) instead of (ARRAY T 1).
1048 ;; In SBCL it also used to denote universal VALUES type.
1057 ;;(aver (not (eq type1 *wild-type*))) ; * isn't really a type.
1064 ;; not allowed to be unsure on these... FIXME: keep the list
1065 ;; of CL types that are intersection types once and only
1066 ;; once.
1069 ;; things like (AND (EQL 0) (SATISFIES ODDP)) or (AND FUNCTION
1070 ;; STREAM) can get here. In general, we can't really tell
1071 ;; whether these are equal to NIL or not, so
1082 ;; This AVER causes problems if we write accurate methods for the
1083 ;; union (and possibly intersection) types which then delegate to
1084 ;; us; while a user shouldn't get here, because of the odd status of
1085 ;; *wild-type* a type-intersection executed by the compiler can. -
1086 ;; CSR, 2002-04-10
1087 ;;
1088 ;; (aver (not (eq type1 *wild-type*))) ; * isn't really a type.
1090 t)
1093 ;; Now that the UNION and HAIRY COMPLEX-SUBTYPEP-ARG2 methods
1094 ;; can delegate to us (more or less as CALL-NEXT-METHOD) when
1095 ;; they're uncertain, we can't just barf on COMPOUND-TYPE and
1096 ;; HAIRY-TYPEs as we used to. Instead we deal with the
1097 ;; problem (where at least part of the problem is cases like
1098 ;; (SUBTYPEP T '(SATISFIES FOO))
1099 ;; or
1100 ;; (SUBTYPEP T '(AND (SATISFIES FOO) (SATISFIES BAR)))
1101 ;; where the second type is a hairy type like SATISFIES, or
1102 ;; is a compound type which might contain a hairy type) by
1103 ;; returning uncertainty.
1106 ;; By elimination, TYPE1 is the universal type.
1108 ;; This case would have been picked off by the SIMPLE-SUBTYPEP
1109 ;; method, and so shouldn't appear here.
1111 ;; Since TYPE2 is not EQ *UNIVERSAL-TYPE* and is not the
1112 ;; universal type in disguise, TYPE2 is not a superset of TYPE1.
1120 ;; those types can be *EMPTY-TYPE* or *UNIVERSAL-TYPE* in
1121 ;; disguise. So we'd better delegate.
1124 ;; FIXME: This seems to rely on there only being 2 or 3
1125 ;; NAMED-TYPE values, and the exclusion of various
1126 ;; possibilities above. It would be good to explain it and/or
1127 ;; rewrite it so that it's clearer.
1131 ;; FIXME: This assertion failed when I added it in sbcl-0.6.11.13.
1132 ;; Perhaps when bug 85 is fixed it can be reenabled.
1133 ;;(aver (not (eq type2 *wild-type*))) ; * isn't really a type.
1137 ;; Perhaps when bug 85 is fixed this can be reenabled.
1138 ;;(aver (not (eq type2 *wild-type*))) ; * isn't really a type.
1150 \f
1151 ;;;; hairy and unknown types
1179 specifier2)))
1190 type1
1191 nil))
1196 type1
1197 nil))
1207 ;; Check legality of arguments.
1212 :datum predicate-name
1216 ;; Create object.
1218 \f
1219 ;;;; negation types
1226 'atom
1235 complement-type2)))
1237 ;; FIXME: if uncertain, maybe try arg1?
1242 ;; "Incrementally extended heuristic algorithms tend inexorably toward the
1243 ;; incomprehensible." -- http://www.unlambda.com/~james/lambda/lambda.txt
1244 ;;
1245 ;; You may not believe this. I couldn't either. But then I sat down
1246 ;; and drew lots of Venn diagrams. Comments involving a and b refer
1247 ;; to the call (subtypep '(not a) 'b) -- CSR, 2002-02-27.
1249 ;; (Several logical truths in this block are true as long as
1250 ;; b/=T. As of sbcl-0.7.1.28, it seems impossible to construct a
1251 ;; case with b=T where we actually reach this type method, but
1252 ;; we'll test for and exclude this case anyway, since future
1253 ;; maintenance might make it possible for it to end up in this
1254 ;; code.)
1262 ;; Do the special cases first, in order to give us a chance if
1263 ;; subtype/supertype relationships are hairy.
1266 ;; If a = b, ~a is not a subtype of b (unless b=T, which was
1267 ;; excluded above).
1272 ;; KLUDGE: ANSI requires that the SUBTYPEP result between any
1273 ;; two built-in atomic type specifiers never be uncertain. This
1274 ;; is hard to do cleanly for the built-in types whose
1275 ;; definitions include (NOT FOO), i.e. CONS and RATIO. However,
1276 ;; we can do it with this hack, which uses our global knowledge
1277 ;; that our implementation of the type system uses disjoint
1278 ;; implementation types to represent disjoint sets (except when
1279 ;; types are contained in other types). (This is a KLUDGE
1280 ;; because it's fragile. Various changes in internal
1281 ;; representation in the type system could make it start
1282 ;; confidently returning incorrect results.) -- WHN 2002-03-08
1285 ;; Because of the way our types which don't contain other
1286 ;; types are disjoint subsets of the space of possible values,
1287 ;; (SUBTYPEP '(NOT AA) 'B)=NIL when AA and B are simple (and B
1288 ;; is not T, as checked above).
1290 ;; The old (TYPE= TYPE1 TYPE2) branch would never be taken, as
1291 ;; TYPE1 and TYPE2 will only be equal if they're both NOT types,
1292 ;; and then the :SIMPLE-SUBTYPEP method would be used instead.
1293 ;; But a CSUBTYPEP relationship might still hold:
1296 ;; If a is a subtype of b, ~a is not a subtype of b (unless
1297 ;; b=T, which was excluded above).
1304 ;; If b is a subtype of a, ~a is not a subtype of b. (FIXME:
1305 ;; That's not true if a=T. Do we know at this point that a is
1306 ;; not T?)
1311 ;; old CSR comment ca. 0.7.2, now obsoleted by the SIMPLE-CTYPE?
1312 ;; KLUDGE case above: Other cases here would rely on being able
1313 ;; to catch all possible cases, which the fragility of this type
1314 ;; system doesn't inspire me; for instance, if a is type= to ~b,
1315 ;; then we want T, T; if this is not the case and the types are
1316 ;; disjoint (have an intersection of *empty-type*) then we want
1317 ;; NIL, T; else if the union of a and b is the *universal-type*
1318 ;; then we want T, T. So currently we still claim to be unsure
1319 ;; about e.g. (subtypep '(not fixnum) 'single-float).
1320 ;;
1321 ;; OTOH we might still get here:
1325 ;; (NOT FOO) isn't equivalent to anything that's not a negation
1326 ;; type, except possibly a type that might contain it in disguise.
1338 ;; Why no analagous clause to the disjoint in the SIMPLE-UNION2
1339 ;; method, below? The clause would read
1340 ;;
1341 ;; ((EQ (TYPE-UNION NOT1 NOT2) *UNIVERSAL-TYPE*) *EMPTY-TYPE*)
1342 ;;
1343 ;; but with proper canonicalization of negation types, there's
1344 ;; no way of constructing two negation types with union of their
1345 ;; negations being the universal type.
1348 nil))))
1354 type1)
1371 type2)
1379 \f
1380 ;;;; numeric types
1395 t))
1406 type
1412 type
1413 :low nil
1418 type
1419 :low nil
1423 type
1461 'unsigned-byte
1465 (:real
1467 (:complex
1474 ;;; Return true if X is "less than or equal" to Y, taking open bounds
1475 ;;; into consideration. CLOSED is the predicate used to test the bound
1476 ;;; on a closed interval (e.g. <=), and OPEN is the predicate used on
1477 ;;; open bounds (e.g. <). Y is considered to be the outside bound, in
1478 ;;; the sense that if it is infinite (NIL), then the test succeeds,
1479 ;;; whereas if X is infinite, then the test fails (unless Y is also
1480 ;;; infinite).
1481 ;;;
1482 ;;; This is for comparing bounds of the same kind, e.g. upper and
1483 ;;; upper. Use NUMERIC-BOUND-TEST* for different kinds of bounds.
1496 ;;; This is used to compare upper and lower bounds. This is different
1497 ;;; from the same-bound case:
1498 ;;; -- Since X = NIL is -infinity, whereas y = NIL is +infinity, we
1499 ;;; return true if *either* arg is NIL.
1500 ;;; -- an open inner bound is "greater" and also squeezes the interval,
1501 ;;; causing us to use the OPEN test for those cases as well.
1514 ;;; Return whichever of the numeric bounds X and Y is "maximal"
1515 ;;; according to the predicates CLOSED (e.g. >=) and OPEN (e.g. >).
1516 ;;; This is only meaningful for maximizing like bounds, i.e. upper and
1517 ;;; upper. If MAX-P is true, then we return NIL if X or Y is NIL,
1518 ;;; otherwise we return the other arg.
1542 ;; If one is complex and the other isn't, they are disjoint.
1546 ;; If the classes are specified and different, the types are
1547 ;; disjoint unless type2 is RATIONAL and type1 is INTEGER.
1548 ;; [ or type1 is INTEGER and type2 is of the form (RATIONAL
1549 ;; X X) for integral X, but this is dealt with in the
1550 ;; canonicalization inside MAKE-NUMERIC-TYPE ]
1555 ;; If the float formats are specified and different, the types
1556 ;; are disjoint.
1560 ;; Check the bounds.
1569 ;;; If the high bound of LOW is adjacent to the low bound of HIGH,
1570 ;;; then return true, otherwise NIL.
1618 nil))))
1620 ;;; Return a numeric type that is a supertype for both TYPE1 and TYPE2.
1621 ;;;
1622 ;;; Old comment, probably no longer applicable:
1623 ;;;
1624 ;;; ### Note: we give up early to keep from dropping lots of
1625 ;;; information on the floor by returning overly general types.
1645 :class class1
1646 :format format1
1647 :complexp complexp1
1654 ;; FIXME: These two clauses are almost identical, and the
1655 ;; consequents are in fact identical in every respect.
1667 :format format1
1668 :complexp complexp1
1686 :format format1
1687 :complexp complexp1
1697 (!cold-init-forms
1708 typespec))
1711 typespec))
1728 ;; FIXME: This code could suffer from (admittedly
1729 ;; very obscure) cases of bug 145 e.g. when TYPE
1730 ;; is
1731 ;; (OR (AND INTEGER (SATISFIES ODDP))
1732 ;; (AND FLOAT (SATISFIES FOO))
1733 ;; and not even report the problem very well.
1744 ;; ANSI just says that TYPESPEC is any subtype of
1745 ;; type REAL, not necessarily a NUMERIC-TYPE. In
1746 ;; particular, at this point TYPESPEC could legally be
1747 ;; an intersection type like (AND REAL (SATISFIES ODDP)),
1748 ;; in which case we fall through the logic above and
1749 ;; end up here, stumped.
1751 used for a COMPLEX component.~:@>"
1752 typespec)))))))))
1754 ;;; If X is *, return NIL, otherwise return the bound, which must be a
1755 ;;; member of TYPE or a one-element list of a member of TYPE.
1763 bound)
1766 '*
1767 type
1768 type
1769 bound))))
1781 :low lb
1792 :low lb
1797 ;;; Unlike CMU CL, we represent the types FLOAT and REAL as
1798 ;;; UNION-TYPEs of more primitive types, in order to make
1799 ;;; type representation more unique, avoiding problems in the
1800 ;;; simplification of things like
1801 ;;; (subtypep '(or (single-float -1.0 1.0) (single-float 0.1))
1802 ;;; '(or (real -1 7) (single-float 0.1) (single-float -1.0 1.0)))
1803 ;;; When we allowed REAL to remain as a separate NUMERIC-TYPE,
1804 ;;; it was too easy for the first argument to be simplified to
1805 ;;; '(SINGLE-FLOAT -1.0), and for the second argument to be simplified
1806 ;;; to '(OR (REAL -1 7) (SINGLE-FLOAT 0.1)) and then for the
1807 ;;; SUBTYPEP to fail (returning NIL,T instead of T,T) because
1808 ;;; the first argument can't be seen to be a subtype of any of the
1809 ;;; terms in the second argument.
1810 ;;;
1811 ;;; The old CMU CL way was:
1812 ;;; (!def-bounded-type float float nil)
1813 ;;; (!def-bounded-type real nil nil)
1814 ;;;
1815 ;;; FIXME: If this new way works for a while with no weird new
1816 ;;; problems, we can go back and rip out support for separate FLOAT
1817 ;;; and REAL flavors of NUMERIC-TYPE. The new way was added in
1818 ;;; sbcl-0.6.11.22, 2001-03-21.
1819 ;;;
1820 ;;; FIXME: It's probably necessary to do something to fix the
1821 ;;; analogous problem with INTEGER and RATIONAL types. Perhaps
1822 ;;; bounded RATIONAL types should be represented as (OR RATIO INTEGER).
1826 bound)
1836 bound
1837 ;; Coerce to the widest float format available, to
1838 ;; avoid unnecessary loss of precision:
1877 ;; If one is complex and the other isn't, then they are disjoint.
1880 nil)
1881 ;; If either type is a float, then the other must either be
1882 ;; specified to be a float or unspecified. Otherwise, they
1883 ;; are disjoint.
1888 ;; If the float formats are specified and different, the
1889 ;; types are disjoint.
1891 nil)
1893 ;; Check the bounds. This is a bit odd because we must
1894 ;; always have the outer bound of the interval as the
1895 ;; second arg.
1906 ;;; Take the numeric bound X and convert it into something that can be
1907 ;;; used as a bound in a numeric type with the specified CLASS and
1908 ;;; FORMAT. If UP-P is true, then we round up as needed, otherwise we
1909 ;;; round down. UP-P true implies that X is a lower bound, i.e. (N) > N.
1910 ;;;
1911 ;;; This is used by NUMERIC-TYPE-INTERSECTION to mash the bound into
1912 ;;; the appropriate type number. X may only be a float when CLASS is
1913 ;;; FLOAT.
1914 ;;;
1915 ;;; ### Note: it is possible for the coercion to a float to overflow
1916 ;;; or underflow. This happens when the bound doesn't fit in the
1917 ;;; specified format. In this case, we should really return the
1918 ;;; appropriate {Most | Least}-{Positive | Negative}-XXX-Float float
1919 ;;; of desired format. But these conditions aren't currently signalled
1920 ;;; in any useful way.
1921 ;;;
1922 ;;; Also, when converting an open rational bound into a float we
1923 ;;; should probably convert it to a closed bound of the closest float
1924 ;;; in the specified format. KLUDGE: In general, open float bounds are
1925 ;;; screwed up. -- (comment from original CMU CL)
1938 nil))
1940 ;;; Handle the case of type intersection on two numeric types. We use
1941 ;;; TYPES-EQUAL-OR-INTERSECT to throw out the case of types with no
1942 ;;; intersection. If an attribute in TYPE1 is unspecified, then we use
1943 ;;; TYPE2's attribute, which must be at least as restrictive. If the
1944 ;;; types intersect, then the only attributes that can be specified
1945 ;;; and different are the class and the bounds.
1946 ;;;
1947 ;;; When the class differs, we use the more restrictive class. The
1948 ;;; only interesting case is RATIONAL/INTEGER, since RATIONAL includes
1949 ;;; INTEGER.
1950 ;;;
1951 ;;; We make the result lower (upper) bound the maximum (minimum) of
1952 ;;; the argument lower (upper) bounds. We convert the bounds into the
1953 ;;; appropriate numeric type before maximizing. This avoids possible
1954 ;;; confusion due to mixed-type comparisons (but I think the result is
1955 ;;; the same).
1965 'integer
1970 :class class
1971 :format format
1976 class format t)
1978 class format t)
1982 class format nil)
1984 class format nil)
1988 ;;; Given two float formats, return the one with more precision. If
1989 ;;; either one is null, return NIL.
1996 ;;; Return the result of an operation on TYPE1 and TYPE2 according to
1997 ;;; the rules of numeric contagion. This is always NUMBER, some float
1998 ;;; format (possibly complex) or RATIONAL. Due to rational
1999 ;;; canonicalization, there isn't much we can do here with integers or
2000 ;;; rational complex numbers.
2001 ;;;
2002 ;;; If either argument is not a NUMERIC-TYPE, then return NUMBER. This
2003 ;;; is useful mainly for allowing types that are technically numbers,
2004 ;;; but not a NUMERIC-TYPE.
2023 ;; A double-float with any real number is a
2024 ;; double-float.
2025 #!-long-float
2027 'double-float
2028 nil)
2029 ;; A long-float with any real number is a
2030 ;; long-float.
2031 #!+long-float
2033 'long-float
2034 nil)))
2037 :complex
2047 \f
2048 ;;;; array types
2052 ;;; What this does depends on the setting of the
2053 ;;; *USE-IMPLEMENTATION-TYPES* switch. If true, return the specialized
2054 ;;; element type, otherwise return the original element type.
2067 ;; By its nature, the call to TYPE= should never return NIL,
2068 ;; T, as we don't know what the UNKNOWN-TYPE will grow up to
2069 ;; be. -- CSR, 2002-08-19
2078 t)))
2081 ;; FIXME (and hint to PFD): we're vulnerable here to attacks of the
2082 ;; form "are (AND ARRAY (NOT (ARRAY T))) and (OR (ARRAY BIT) (ARRAY
2083 ;; NIL) (ARRAY CHAR) ...) equivalent?" -- CSR, 2003-12-10
2129 ;; (sbcl-0.6.4 has trouble figuring out that
2130 ;; DIMS1 and DIMS2 must be lists at this
2131 ;; point, and knowing that is important to
2132 ;; compiling EVERY efficiently.)
2140 ;; not subtypep unless complexness is compatible
2144 ;; Since we didn't fail any of the tests above, we win
2145 ;; if the TYPE2 element type is wild.
2149 ;; can't give a good answer unless both the element types
2150 ;; have been defined.
2155 ;; types are equal, and they're equal iff the specialized
2156 ;; element types are identical.
2157 t
2160 t)))))
2162 ;;; FIXME: is this dead?
2163 (!define-superclasses array
2175 ;; See whether dimensions are compatible.
2180 dims1 dims2))))
2182 ;; See whether complexpness is compatible.
2187 ;; Old comment:
2188 ;;
2189 ;; If either element type is wild, then they intersect.
2190 ;; Otherwise, the types must be identical.
2191 ;;
2192 ;; FIXME: There seems to have been a fair amount of
2193 ;; confusion about the distinction between requested element
2194 ;; type and specialized element type; here is one of
2195 ;; them. If we request an array to hold objects of an
2196 ;; unknown type, we can do no better than represent that
2197 ;; type as an array specialized on wild-type. We keep the
2198 ;; requested element-type in the -ELEMENT-TYPE slot, and
2199 ;; *WILD-TYPE* in the -SPECIALIZED-ELEMENT-TYPE. So, here,
2200 ;; we must test for the SPECIALIZED slot being *WILD-TYPE*,
2201 ;; not just the ELEMENT-TYPE slot. Maybe the return value
2202 ;; in that specific case should be T, NIL? Or maybe this
2203 ;; function should really be called
2204 ;; ARRAY-TYPES-COULD-POSSIBLY-INTERSECT? In any case, this
2205 ;; was responsible for bug #123, and this whole issue could
2206 ;; do with a rethink and/or a rewrite. -- CSR, 2002-08-21
2231 dims1 dims2)))
2239 ;;; Check a supplied dimension list to determine whether it is legal,
2240 ;;; and return it in canonical form (as either '* or a list).
2259 dims)
2262 \f
2263 ;;;; MEMBER types
2271 (dolist (pair `((0.0f0 . ,(load-time-value (make-unportable-float :single-float-negative-zero)))
2273 #!+long-float
2300 floats)))
2312 t))
2316 type2
2319 ;;; We punt if the odd type is enumerable and intersects with the
2320 ;;; MEMBER type. If not enumerable, then it is definitely not a
2321 ;;; subtype of the MEMBER type.
2353 ;;; We don't need a :COMPLEX-UNION2, since the only interesting case is
2354 ;;; a union type, and the member/union interaction is handled by the
2355 ;;; union type method.
2369 t)))
2395 \f
2396 ;;;; intersection types
2397 ;;;;
2398 ;;;; Until version 0.6.10.6, SBCL followed the original CMU CL approach
2399 ;;;; of punting on all AND types, not just the unreasonably complicated
2400 ;;;; ones. The change was motivated by trying to get the KEYWORD type
2401 ;;;; to behave sensibly:
2402 ;;;; ;; reasonable definition
2403 ;;;; (DEFTYPE KEYWORD () '(AND SYMBOL (SATISFIES KEYWORDP)))
2404 ;;;; ;; reasonable behavior
2405 ;;;; (AVER (SUBTYPEP 'KEYWORD 'SYMBOL))
2406 ;;;; Without understanding a little about the semantics of AND, we'd
2407 ;;;; get (SUBTYPEP 'KEYWORD 'SYMBOL)=>NIL,NIL and, for entirely
2408 ;;;; parallel reasons, (SUBTYPEP 'RATIO 'NUMBER)=>NIL,NIL. That's
2409 ;;;; not so good..)
2410 ;;;;
2411 ;;;; We still follow the example of CMU CL to some extent, by punting
2412 ;;;; (to the opaque HAIRY-TYPE) on sufficiently complicated types
2413 ;;;; involving AND.
2421 ;;; A few intersection types have special names. The others just get
2422 ;;; mechanically unparsed.
2428 ;;; shared machinery for type equality: true if every type in the set
2429 ;;; TYPES1 matches a type in the set TYPES2 and vice versa
2435 x y)))
2439 ;;; Two intersection types are equal if their subtypes are equal sets.
2440 ;;;
2441 ;;; FIXME: Might it be better to use
2442 ;;; (AND (SUBTYPEP X Y) (SUBTYPEP Y X))
2443 ;;; instead, since SUBTYPEP is the usual relationship that we care
2444 ;;; most about, so it would be good to leverage any ingenuity there
2445 ;;; in this more obscure method?
2455 type1
2470 ;;; FIXME: This will look eeriely familiar to readers of the UNION
2471 ;;; :SIMPLE-INTERSECTION2 :COMPLEX-INTERSECTION2 method. That's
2472 ;;; because it was generated by cut'n'paste methods. Given that
2473 ;;; intersections and unions have all sorts of symmetries known to
2474 ;;; mathematics, it shouldn't be beyond the ken of some programmers to
2475 ;;; reflect those symmetries in code in a way that ties them together
2476 ;;; more strongly than having two independent near-copies :-/
2479 ;; Within this method, type2 is guaranteed to be an intersection
2480 ;; type:
2482 ;; Make sure to call only the applicable methods...
2489 type2)
2492 type1)
2493 ;; KLUDGE: This special (and somewhat hairy) magic is required
2494 ;; to deal with the RATIONAL/INTEGER special case. The UNION
2495 ;; of (INTEGER * -1) and (AND (RATIONAL * -1/2) (NOT INTEGER))
2496 ;; should be (RATIONAL * -1/2) -- CSR, 2003-02-28
2503 :complexp nil
2505 nil
2508 nil
2521 ;; we have to give up here -- there are all sorts of
2522 ;; ordering worries, but it's better than before.
2523 ;; Doing exactly the same as in the UNION
2524 ;; :SIMPLE/:COMPLEX-INTERSECTION2 method causes stack
2525 ;; overflow with the mutual recursion never bottoming
2526 ;; out.
2529 ;; KLUDGE: if we get here, we have a partially
2530 ;; simplified result. While this isn't by any
2531 ;; means a universal simplification, including
2532 ;; this logic here means that we can get (OR
2533 ;; KEYWORD (NOT KEYWORD)) canonicalized to T.
2542 \f
2543 ;;;; union types
2552 ;;; The LIST, FLOAT and REAL types have special names. Other union
2553 ;;; types just get mechanically unparsed.
2567 ;;; Two union types are equal if they are each subtypes of each
2568 ;;; other. We need to be this clever because our complex subtypep
2569 ;;; methods are now more accurate; we don't get infinite recursion
2570 ;;; because the simple-subtypep method delegates to complex-subtypep
2571 ;;; of the individual types of type1. - CSR, 2002-04-09
2572 ;;;
2573 ;;; Previous comment, now obsolete, but worth keeping around because
2574 ;;; it is true, though too strong a condition:
2575 ;;;
2576 ;;; Two union types are equal if their subtypes are equal sets.
2582 ;; we might as well become as certain as possible.
2597 ;;; Similarly, a union type is a subtype of another if and only if
2598 ;;; every element of TYPE1 is a subtype of TYPE2.
2601 type2
2609 type2
2617 ;; was: (any/type #'csubtypep type1 (union-type-types type2)),
2618 ;; which turns out to be too restrictive, causing bug 91.
2619 ;;
2620 ;; the following reimplementation might look dodgy. It is
2621 ;; dodgy. It depends on the union :complex-= method not doing
2622 ;; very much work -- certainly, not using subtypep. Reasoning:
2624 ;; At this stage, we know that type2 is a union type and type1
2625 ;; isn't. We might as well check this, though:
2628 ;; A is a subset of (B1 u B2)
2629 ;; <=> A n (B1 u B2) = A
2630 ;; <=> (A n B1) u (A n B2) = A
2631 ;;
2632 ;; But, we have to be careful not to delegate this type= to
2633 ;; something that could invoke subtypep, which might get us
2634 ;; back here -> stack explosion. We therefore ensure that the
2635 ;; second type (which is the one that's dispatched on) is
2636 ;; either a union type (where we've ensured that the complex-=
2637 ;; method will not call subtypep) or something with no union
2638 ;; types involved, in which case we'll never come back here.
2639 ;;
2640 ;; If we don't do this, then e.g.
2641 ;; (SUBTYPEP '(MEMBER 3) '(OR (SATISFIES FOO) (SATISFIES BAR)))
2642 ;; would loop infinitely, as the member :complex-= method is
2643 ;; implemented in terms of subtypep.
2644 ;;
2645 ;; Ouch. - CSR, 2002-04-10
2652 ;; The ANY/TYPE expression above is a sufficient condition for
2653 ;; subsetness, but not a necessary one, so we might get a more
2654 ;; certain answer by this CALL-NEXT-METHOD-ish step when the
2655 ;; ANY/TYPE expression is uncertain.
2663 ;; The CSUBTYPEP clauses here let us simplify e.g.
2664 ;; (TYPE-INTERSECTION2 (SPECIFIER-TYPE 'LIST)
2665 ;; (SPECIFIER-TYPE '(OR LIST VECTOR)))
2666 ;; (where LIST is (OR CONS NULL)).
2667 ;;
2668 ;; The tests are more or less (CSUBTYPEP TYPE1 TYPE2) and vice
2669 ;; versa, but it's important that we pre-expand them into
2670 ;; specialized operations on individual elements of
2671 ;; UNION-TYPE-TYPES, instead of using the ordinary call to
2672 ;; CSUBTYPEP, in order to avoid possibly invoking any methods which
2673 ;; might in turn invoke (TYPE-INTERSECTION2 TYPE1 TYPE2) and thus
2674 ;; cause infinite recursion.
2675 ;;
2676 ;; Within this method, type2 is guaranteed to be a union type:
2678 ;; Make sure to call only the applicable methods...
2685 type1)
2688 type2)
2690 ;; KLUDGE: This code accumulates a sequence of TYPE-UNION2
2691 ;; operations in a particular order, and gives up if any of
2692 ;; the sub-unions turn out not to be simple. In other cases
2693 ;; ca. sbcl-0.6.11.15, that approach to taking a union was a
2694 ;; bad idea, since it can overlook simplifications which
2695 ;; might occur if the terms were accumulated in a different
2696 ;; order. It's possible that that will be a problem here too.
2697 ;; However, I can't think of a good example to demonstrate
2698 ;; it, and without an example to demonstrate it I can't write
2699 ;; test cases, and without test cases I don't want to
2700 ;; complicate the code to address what's still a hypothetical
2701 ;; problem. So I punted. -- WHN 2001-03-20
2711 type-specifiers)))
2712 \f
2713 ;;;; CONS types
2753 'cons
2771 ;;; Give up if a precise type is not possible, to avoid returning
2772 ;;; overly general types.
2779 car-not1
2780 car-not2)
2781 ;; UGH. -- CSR, 2003-02-24
2789 not1
2797 cdr-type1))
2802 ;; more general case of the above, but harder to compute
2811 ;; Don't put these in -- consider the effect of taking the
2812 ;; union of (CONS (INTEGER 0 2) (INTEGER 5 7)) and
2813 ;; (CONS (INTEGER 0 3) (INTEGER 5 6)).
2814 #+nil
2817 #+nil
2836 cdr-int2)))))
2837 \f
2838 ;;; Return the type that describes all objects that are in X but not
2839 ;;; in Y. If we can't determine this type, then return NIL.
2840 ;;;
2841 ;;; For now, we only are clever dealing with union and member types.
2842 ;;; If either type is not a union type, then we pretend that it is a
2843 ;;; union of just one type. What we do is remove from X all the types
2844 ;;; that are a subtype any type in Y. If any type in X intersects with
2845 ;;; a type in Y but is not a subtype, then we give up.
2846 ;;;
2847 ;;; We must also special-case any member type that appears in the
2848 ;;; union. We remove from X's members all objects that are TYPEP to Y.
2849 ;;; If Y has any members, we must be careful that none of those
2850 ;;; members are CTYPEP to any of Y's non-member types. We give up in
2851 ;;; this case, since to compute that difference we would have to break
2852 ;;; the type from X into some collection of types that represents the
2853 ;;; type without that particular element. This seems too hairy to be
2854 ;;; worthwhile, given its low utility.
2885 \f
2899 :complexp nil
2903 \f
2904 ;;;; utilities shared between cross-compiler and target system
2906 ;;; Does the type derived from compilation of an actual function
2907 ;;; definition satisfy declarations of a function's type?
2914 ;; that's what happens when we (DECLAIM (FTYPE FUNCTION FOO)).
2916 ;; In that case, any definition satisfies the declaration.
2917 t)
2919 ;; #<BUILT-IN-CLASS FUNCTION>, but it's not obviously
2920 ;; invalid, so let's handle that case too, just in case.
2922 ;; No matter what DECLARED-FTYPE might be, we can't prove
2923 ;; that an object of type FUNCTION doesn't satisfy it, so
2924 ;; we return success no matter what.
2925 t)
2927 t
2928 ;; FIXME: For now we only check compatibility of the return
2929 ;; type, not argument types, and we don't even check the
2930 ;; return type very precisely (as per bug 94a). It would be
2931 ;; good to do a better job. Perhaps to check the
2932 ;; compatibility of the arguments, we should (1) redo
2933 ;; VALUES-TYPES-EQUAL-OR-INTERSECT as
2934 ;; ARGS-TYPES-EQUAL-OR-INTERSECT, and then (2) apply it to
2935 ;; the ARGS-TYPE slices of the FUN-TYPEs. (ARGS-TYPE
2936 ;; is a base class both of VALUES-TYPE and of FUN-TYPE.)
2941 ;;; This messy case of CTYPE for NUMBER is shared between the
2942 ;;; cross-compiler and the target system.
2955 :complexp complexp
2956 :low low
2958 \f
2960 ;; Why SAFETY 0? To suppress the is-it-the-right-structure-type
2961 ;; checking for declarations in structure accessors. Otherwise we
2962 ;; can get caught in a chicken-and-egg bootstrapping problem, whose
2963 ;; symptom on x86 OpenBSD sbcl-0.pre7.37.flaky5.22 is an illegal
2964 ;; instruction trap. I haven't tracked it down, but I'm guessing it
2965 ;; has to do with setting LAYOUTs when the LAYOUT hasn't been set
2966 ;; yet. -- WHN