| blob | 46b983fa46b2e20da249974a97be619e2f25ecd7 |
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 ;;; Since all function types are equivalent to FUNCTION, they are all
217 ;;; subtypes of each other.
218 (!define-type-method
225 for a1 in types1
226 for a2 in types2
265 ;;; The union or intersection of two FUNCTION types is FUNCTION.
273 ;;; ### Not very real, but good enough for redefining transforms
274 ;;; according to type:
289 ;;; Given a LAMBDA-LIST-like values type specification and an ARGS-TYPE
290 ;;; structure, fill in the slots in the structure accordingly. This is
291 ;;; used for both FUNCTION and VALUES types.
310 kwd lambda-list))
317 ;;; Return the lambda-list-like type specification corresponding
318 ;;; to an ARGS-TYPE.
351 res))
356 res))
357 \f
358 ;;;; VALUES types interfaces
359 ;;;;
360 ;;;; We provide a few special operations that can be meaningfully used
361 ;;;; on VALUES types (as well as on any other type).
363 ;;; Return the type of the first value indicated by TYPE. This is used
364 ;;; by people who don't want to have to deal with VALUES types.
366 ; (inline single-value-type))
379 type)))
381 ;;; Return the minimum number of arguments that a function can be
382 ;;; called with, and the maximum number or NIL. If not a function
383 ;;; type, return NIL, NIL.
395 ;;; Determine whether TYPE corresponds to a definite number of values.
396 ;;; The first value is a list of the types for each value, and the
397 ;;; second value is the number of values. If the number of values is
398 ;;; not fixed, then return NIL and :UNKNOWN.
414 ;;; Return two values:
415 ;;; 1. A list of all the positional (fixed and optional) types.
416 ;;; 2. The &REST type (if any). If keywords allowed, *UNIVERSAL-TYPE*.
417 ;;; If no keywords or &REST, then the DEFAULT-TYPE.
425 default-type))))
427 ;;; Return a list of OPERATION applied to the types in TYPES1 and
428 ;;; TYPES2, padding with REST2 as needed. TYPES1 must not be shorter
429 ;;; than TYPES2. The second value is T if OPERATION always returned a
430 ;;; true second value.
439 res))
440 types1
444 exact)))
446 ;;; If Type isn't a values type, then make it into one:
447 ;;; <type> ==> (values type &rest t)
451 type
454 ;;; Do the specified OPERATION on TYPE1 and TYPE2, which may be any
455 ;;; type, including VALUES types. With VALUES types such as:
456 ;;; (VALUES a0 a1)
457 ;;; (VALUES b0 b1)
458 ;;; we compute the more useful result
459 ;;; (VALUES (<operation> a0 b0) (<operation> a1 b1))
460 ;;; rather than the precise result
461 ;;; (<operation> (values a0 a1) (values b0 b1))
462 ;;; This has the virtue of always keeping the VALUES type specifier
463 ;;; outermost, and retains all of the information that is really
464 ;;; useful for static type analysis. We want to know what is always
465 ;;; true of each value independently. It is worthless to know that if
466 ;;; the first value is B0 then the second will be B1.
467 ;;;
468 ;;; If the VALUES count signatures differ, then we produce a result with
469 ;;; the required VALUE count chosen by NREQ when applied to the number
470 ;;; of required values in TYPE1 and TYPE2. Any &KEY values become
471 ;;; &REST T (anyone who uses keyword values deserves to lose.)
472 ;;;
473 ;;; The second value is true if the result is definitely empty or if
474 ;;; OPERATION returned true as its second value each time we called
475 ;;; it. Since we approximate the intersection of VALUES types, the
476 ;;; second value being true doesn't mean the result is exact.
503 :required required
506 ())
511 ;;; Do a union or intersection operation on types that might be values
512 ;;; types. The result is optimized for utility rather than exactness,
513 ;;; but it is guaranteed that it will be no smaller (more restrictive)
514 ;;; than the precise result.
515 ;;;
516 ;;; The return convention seems to be analogous to
517 ;;; TYPES-EQUAL-OR-INTERSECT. -- WHN 19990910.
520 :default nil
540 #'type-intersection
541 #'max
544 ;;; This is like TYPES-EQUAL-OR-INTERSECT, except that it sort of
545 ;;; works on VALUES types. Note that due to the semantics of
546 ;;; VALUES-TYPE-INTERSECTION, this might return (VALUES T T) when
547 ;;; there isn't really any intersection.
554 win)))
558 ;;; a SUBTYPEP-like operation that can be used on any types, including
559 ;;; VALUES types
598 \f
599 ;;;; type method interfaces
601 ;;; like SUBTYPEP, only works on CTYPE structures
617 type1 type2
620 ;;; Just parse the type specifiers and call CSUBTYPE.
622 #!+sb-doc
623 "Return two values indicating the relationship between type1 and type2.
624 If values are T and T, type1 definitely is a subtype of type2.
625 If values are NIL and T, type1 definitely is not a subtype of type2.
626 If values are NIL and NIL, it couldn't be determined."
629 ;;; If two types are definitely equivalent, return true. The second
630 ;;; value indicates whether the first value is definitely correct.
631 ;;; This should only fail in the presence of HAIRY types.
643 ;;; Not exactly the negation of TYPE=, since when the relationship is
644 ;;; uncertain, we still return NIL, NIL. This is useful in cases where
645 ;;; the conservative assumption is =.
653 ;;; the type method dispatch case of TYPE-UNION2
655 ;; As in %TYPE-INTERSECTION2, it seems to be a good idea to give
656 ;; both argument orders a chance at COMPLEX-INTERSECTION2. Unlike
657 ;; %TYPE-INTERSECTION2, though, I don't have a specific case which
658 ;; demonstrates this is actually necessary. Also unlike
659 ;; %TYPE-INTERSECTION2, there seems to be no need to distinguish
660 ;; between not finding a method and having a method return NIL.
663 x y
669 ;;; Find a type which includes both types. Any inexactness is
670 ;;; represented by the fuzzy element types; we return a single value
671 ;;; that is precise to the best of our knowledge. This result is
672 ;;; simplified into the canonical form, thus is not a UNION-TYPE
673 ;;; unless we find no other way to represent the result.
678 ;; KLUDGE: This was generated from TYPE-INTERSECTION2 by Ye Olde Cut And
679 ;; Paste technique of programming. If it stays around (as opposed to
680 ;; e.g. fading away in favor of some CLOS solution) the shared logic
681 ;; should probably become shared code. -- WHN 2001-03-16
684 type1)
689 ;; Unions of UNION-TYPE should have the UNION-TYPE-TYPES
690 ;; values broken out and united separately. The full TYPE-UNION
691 ;; function knows how to do this, so let it handle it.
694 ;; the ordinary case: we dispatch to type methods
697 ;;; the type method dispatch case of TYPE-INTERSECTION2
699 ;; We want to give both argument orders a chance at
700 ;; COMPLEX-INTERSECTION2. Without that, the old CMU CL type
701 ;; methods could give noncommutative results, e.g.
702 ;; (TYPE-INTERSECTION2 *EMPTY-TYPE* SOME-HAIRY-TYPE)
703 ;; => NIL, NIL
704 ;; (TYPE-INTERSECTION2 SOME-HAIRY-TYPE *EMPTY-TYPE*)
705 ;; => #<NAMED-TYPE NIL>, T
706 ;; We also need to distinguish between the case where we found a
707 ;; type method, and it returned NIL, and the case where we fell
708 ;; through without finding any type method. An example of the first
709 ;; case is the intersection of a HAIRY-TYPE with some ordinary type.
710 ;; An example of the second case is the intersection of two
711 ;; completely-unrelated types, e.g. CONS and NUMBER, or SYMBOL and
712 ;; ARRAY.
713 ;;
714 ;; (Why yes, CLOS probably *would* be nicer..)
717 x y
729 nil))))))))
734 :default nil
739 ;; FIXME: For some reason, this doesn't catch e.g. type1 =
740 ;; type2 = (SPECIFIER-TYPE
741 ;; 'SOME-UNKNOWN-TYPE). Investigate. - CSR, 2002-04-10
742 type1)
745 ;; Intersections of INTERSECTION-TYPE should have the
746 ;; INTERSECTION-TYPE-TYPES values broken out and intersected
747 ;; separately. The full TYPE-INTERSECTION function knows how
748 ;; to do that, so let it handle it.
751 ;; the ordinary case: we dispatch to type methods
754 ;;; Return as restrictive and simple a type as we can discover that is
755 ;;; no more restrictive than the intersection of TYPE1 and TYPE2. At
756 ;;; worst, we arbitrarily return one of the arguments as the first
757 ;;; value (trying not to return a hairy type).
763 ;;; a test useful for checking whether a derived type matches a
764 ;;; declared type
765 ;;;
766 ;;; The first value is true unless the types don't intersect and
767 ;;; aren't equal. The second value is true if the first value is
768 ;;; definitely correct. NIL is considered to intersect with any type.
769 ;;; If T is a subtype of either type, then we also return T, T. This
770 ;;; way we recognize that hairy types might intersect with T.
784 ;;; Return a Common Lisp type specifier corresponding to the TYPE
785 ;;; object.
790 ;;; (VALUES-SPECIFIER-TYPE and SPECIFIER-TYPE moved from here to
791 ;;; early-type.lisp by WHN ca. 19990201.)
793 ;;; Take a list of type specifiers, computing the translation of each
794 ;;; specifier and defining it as a builtin type.
801 ;; KLUDGE: the three copies of this idiom in this file (and
802 ;; the one in class.lisp as at sbcl-0.7.4.1x) should be
803 ;; coalesced, or perhaps the error-detecting code that
804 ;; disallows redefinition of :PRIMITIVE types should be
805 ;; rewritten to use *TYPE-SYSTEM-FINALIZED* (rather than
806 ;; *TYPE-SYSTEM-INITIALIZED*). The effect of this is not to
807 ;; cause redefinition errors when precompute-types is called
808 ;; for a second time while building the target compiler using
809 ;; the cross-compiler. -- CSR, trying to explain why this
810 ;; isn't completely wrong, 2002-06-07
813 \f
814 ;;;; general TYPE-UNION and TYPE-INTERSECTION operations
815 ;;;;
816 ;;;; These are fully general operations on CTYPEs: they'll always
817 ;;;; return a CTYPE representing the result.
819 ;;; shared logic for unions and intersections: Stuff TYPE into the
820 ;;; vector TYPES, finding pairs of types which can be simplified by
821 ;;; SIMPLIFY2 (TYPE-UNION2 or TYPE-INTERSECTION2) and replacing them
822 ;;; by their simplified forms.
827 ;; Any input object satisfying %COMPOUND-TYPE-P should've been
828 ;; broken into components before it reached us.
833 ;; Discard the old (AREF TYPES I).
835 ;; Merge the new SIMPLIFIED2 into TYPES, by tail recursing.
836 ;; (Note that the tail recursion is indirect: we go through
837 ;; ACCUMULATE, not ACCUMULATE1, so that if SIMPLIFIED2 is
838 ;; handled properly if it satisfies %COMPOUND-TYPE-P.)
840 types
841 %compound-type-p
842 simplify2)))))
843 ;; Voila.
846 ;;; shared logic for unions and intersections: Use
847 ;;; ACCUMULATE1-COMPOUND-TYPE to merge TYPE into TYPES, either
848 ;;; all in one step or, if %COMPOUND-TYPE-P is satisfied,
849 ;;; component by component.
860 ;;; shared logic for unions and intersections: Return a vector of
861 ;;; types representing the same types as INPUT-TYPES, but with
862 ;;; COMPOUND-TYPEs satisfying %COMPOUND-TYPE-P broken up into their
863 ;;; component types, and with any SIMPLY2 simplifications applied.
867 :adjustable t
869 ;; (This INITIAL-ELEMENT shouldn't
870 ;; matter, but helps avoid type
871 ;; warnings at compile time.)
875 simplified-types
876 %compound-type-p
877 simplify2))
878 simplified-types))
880 ;;; shared logic for unions and intersections: Make a COMPOUND-TYPE
881 ;;; object whose components are the types in TYPES, or skip to special
882 ;;; cases when TYPES is short.
891 enumerable
892 ;; FIXME: This should be just (COERCE TYPES 'LIST), but as
893 ;; of sbcl-0.6.11.17 the COERCE optimizer is really
894 ;; brain-dead, so that would generate a full call to
895 ;; SPECIFIER-TYPE at runtime, so we get into bootstrap
896 ;; problems in cold init because 'LIST is a compound
897 ;; type, so we need to MAKE-COMPOUND-TYPE-OR-SOMETHING
898 ;; before we know what 'LIST is. Once the COERCE
899 ;; optimizer is less brain-dead, we can make this
900 ;; (COERCE TYPES 'LIST) again.
910 union)
911 union
912 nil)))
916 #'intersection-type-p
919 ;; We want to have a canonical representation of types (or failing
920 ;; that, punt to HAIRY-TYPE). Canonical representation would have
921 ;; intersections inside unions but not vice versa, since you can
922 ;; always achieve that by the distributive rule. But we don't want
923 ;; to just apply the distributive rule, since it would be too easy
924 ;; to end up with unreasonably huge type expressions. So instead
925 ;; we try to generate a simple type by distributing the union; if
926 ;; the type can't be made simple, we punt to HAIRY-TYPE.
937 simplified-types
939 simplified-types)
944 #'union-type-p
947 simplified-types
950 \f
951 ;;;; built-in types
959 (!cold-init-forms
965 ;; KLUDGE: In ANSI, * isn't really the name of a type, it's just a
966 ;; special symbol which can be stuck in some places where an
967 ;; ordinary type can go, e.g. (ARRAY * 1) instead of (ARRAY T 1).
968 ;; At some point, in order to become more standard, we should
969 ;; convert all the classic CMU CL legacy *s and *WILD-TYPE*s into
970 ;; Ts and *UNIVERSAL-TYPE*s.
979 ;; FIXME: BUG 85: This assertion failed when I added it in
980 ;; sbcl-0.6.11.13. It probably shouldn't fail; but for now it's
981 ;; just commented out.
982 ;;(aver (not (eq type1 *wild-type*))) ; * isn't really a type.
990 ;; This AVER causes problems if we write accurate methods for the
991 ;; union (and possibly intersection) types which then delegate to
992 ;; us; while a user shouldn't get here, because of the odd status of
993 ;; *wild-type* a type-intersection executed by the compiler can. -
994 ;; CSR, 2002-04-10
995 ;;
996 ;; (aver (not (eq type1 *wild-type*))) ; * isn't really a type.
998 t)
1001 ;; Now that the UNION and HAIRY COMPLEX-SUBTYPEP-ARG2 methods
1002 ;; can delegate to us (more or less as CALL-NEXT-METHOD) when
1003 ;; they're uncertain, we can't just barf on COMPOUND-TYPE and
1004 ;; HAIRY-TYPEs as we used to. Instead we deal with the
1005 ;; problem (where at least part of the problem is cases like
1006 ;; (SUBTYPEP T '(SATISFIES FOO))
1007 ;; or
1008 ;; (SUBTYPEP T '(AND (SATISFIES FOO) (SATISFIES BAR)))
1009 ;; where the second type is a hairy type like SATISFIES, or
1010 ;; is a compound type which might contain a hairy type) by
1011 ;; returning uncertainty.
1014 ;; By elimination, TYPE1 is the universal type.
1016 ;; This case would have been picked off by the SIMPLE-SUBTYPEP
1017 ;; method, and so shouldn't appear here.
1019 ;; Since TYPE2 is not EQ *UNIVERSAL-TYPE* and is not the
1020 ;; universal type in disguise, TYPE2 is not a superset of TYPE1.
1030 ;; FIXME: This seems to rely on there only being 2 or 3
1031 ;; HAIRY-TYPE values, and the exclusion of various
1032 ;; possibilities above. It would be good to explain it and/or
1033 ;; rewrite it so that it's clearer.
1037 ;; FIXME: This assertion failed when I added it in sbcl-0.6.11.13.
1038 ;; Perhaps when bug 85 is fixed it can be reenabled.
1039 ;;(aver (not (eq type2 *wild-type*))) ; * isn't really a type.
1043 ;; Perhaps when bug 85 is fixed this can be reenabled.
1044 ;;(aver (not (eq type2 *wild-type*))) ; * isn't really a type.
1049 \f
1050 ;;;; hairy and unknown types
1072 complement-type2)))
1080 ;; "Incrementally extended heuristic algorithms tend inexorably toward the
1081 ;; incomprehensible." -- http://www.unlambda.com/~james/lambda/lambda.txt
1084 ;; You may not believe this. I couldn't either. But then I
1085 ;; sat down and drew lots of Venn diagrams. Comments
1086 ;; involving a and b refer to the call (subtypep '(not a)
1087 ;; 'b) -- CSR, 2002-02-27.
1089 ;; (Several logical truths in this block are true as
1090 ;; long as b/=T. As of sbcl-0.7.1.28, it seems
1091 ;; impossible to construct a case with b=T where we
1092 ;; actually reach this type method, but we'll test for
1093 ;; and exclude this case anyway, since future
1094 ;; maintenance might make it possible for it to end up
1095 ;; in this code.)
1103 ;; Do the special cases first, in order to give us a
1104 ;; chance if subtype/supertype relationships are hairy.
1107 ;; If a = b, ~a is not a subtype of b (unless b=T,
1108 ;; which was excluded above).
1113 ;; KLUDGE: ANSI requires that the SUBTYPEP result
1114 ;; between any two built-in atomic type specifiers
1115 ;; never be uncertain. This is hard to do cleanly for
1116 ;; the built-in types whose definitions include
1117 ;; (NOT FOO), i.e. CONS and RATIO. However, we can do
1118 ;; it with this hack, which uses our global knowledge
1119 ;; that our implementation of the type system uses
1120 ;; disjoint implementation types to represent disjoint
1121 ;; sets (except when types are contained in other types).
1122 ;; (This is a KLUDGE because it's fragile. Various
1123 ;; changes in internal representation in the type
1124 ;; system could make it start confidently returning
1125 ;; incorrect results.) -- WHN 2002-03-08
1128 ;; Because of the way our types which don't contain
1129 ;; other types are disjoint subsets of the space of
1130 ;; possible values, (SUBTYPEP '(NOT AA) 'B)=NIL when
1131 ;; AA and B are simple (and B is not T, as checked above).
1133 ;; The old (TYPE= TYPE1 TYPE2) branch would never be
1134 ;; taken, as TYPE1 and TYPE2 will only be equal if
1135 ;; they're both NOT types, and then the
1136 ;; :SIMPLE-SUBTYPEP method would be used instead.
1137 ;; But a CSUBTYPEP relationship might still hold:
1140 ;; If a is a subtype of b, ~a is not a subtype of b
1141 ;; (unless b=T, which was excluded above).
1148 ;; If b is a subtype of a, ~a is not a subtype of b.
1149 ;; (FIXME: That's not true if a=T. Do we know at
1150 ;; this point that a is not T?)
1155 ;; old CSR comment ca. 0.7.2, now obsoleted by the
1156 ;; SIMPLE-CTYPE? KLUDGE case above:
1157 ;; Other cases here would rely on being able to catch
1158 ;; all possible cases, which the fragility of this
1159 ;; type system doesn't inspire me; for instance, if a
1160 ;; is type= to ~b, then we want T, T; if this is not
1161 ;; the case and the types are disjoint (have an
1162 ;; intersection of *empty-type*) then we want NIL, T;
1163 ;; else if the union of a and b is the
1164 ;; *universal-type* then we want T, T. So currently we
1165 ;; still claim to be unsure about e.g. (subtypep '(not
1166 ;; fixnum) 'single-float).
1167 )))
1178 type1
1179 nil))
1189 ;; Check legality of arguments.
1194 ;; canonicalize (not (not foo))
1200 ;; Check legality of arguments.
1205 :datum predicate-name
1209 ;; Create object.
1211 \f
1212 ;;;; numeric types
1223 t))
1258 'unsigned-byte
1262 (:real
1264 (:complex
1266 'complex
1272 ;;; Return true if X is "less than or equal" to Y, taking open bounds
1273 ;;; into consideration. CLOSED is the predicate used to test the bound
1274 ;;; on a closed interval (e.g. <=), and OPEN is the predicate used on
1275 ;;; open bounds (e.g. <). Y is considered to be the outside bound, in
1276 ;;; the sense that if it is infinite (NIL), then the test succeeds,
1277 ;;; whereas if X is infinite, then the test fails (unless Y is also
1278 ;;; infinite).
1279 ;;;
1280 ;;; This is for comparing bounds of the same kind, e.g. upper and
1281 ;;; upper. Use NUMERIC-BOUND-TEST* for different kinds of bounds.
1282 #!-negative-zero-is-not-zero
1295 #!+negative-zero-is-not-zero
1301 #!+negative-zero-is-not-zero
1314 ;;; This is used to compare upper and lower bounds. This is different
1315 ;;; from the same-bound case:
1316 ;;; -- Since X = NIL is -infinity, whereas y = NIL is +infinity, we
1317 ;;; return true if *either* arg is NIL.
1318 ;;; -- an open inner bound is "greater" and also squeezes the interval,
1319 ;;; causing us to use the OPEN test for those cases as well.
1320 #!-negative-zero-is-not-zero
1333 #!+negative-zero-is-not-zero
1346 ;;; Return whichever of the numeric bounds X and Y is "maximal"
1347 ;;; according to the predicates CLOSED (e.g. >=) and OPEN (e.g. >).
1348 ;;; This is only meaningful for maximizing like bounds, i.e. upper and
1349 ;;; upper. If MAX-P is true, then we return NIL if X or Y is NIL,
1350 ;;; otherwise we return the other arg.
1374 ;; If one is complex and the other isn't, they are disjoint.
1378 ;; If the classes are specified and different, the types are
1379 ;; disjoint unless type2 is rational and type1 is integer.
1385 ;; If the float formats are specified and different, the types
1386 ;; are disjoint.
1390 ;; Check the bounds.
1399 ;;; If the high bound of LOW is adjacent to the low bound of HIGH,
1400 ;;; then return true, otherwise NIL.
1407 #!-negative-zero-is-not-zero
1414 #!+negative-zero-is-not-zero
1417 #!-negative-zero-is-not-zero
1424 #!+negative-zero-is-not-zero
1426 #!+negative-zero-is-not-zero
1433 nil))))
1435 ;;; Return a numeric type that is a supertype for both TYPE1 and TYPE2.
1436 ;;;
1437 ;;; ### Note: we give up early to keep from dropping lots of information on
1438 ;;; the floor by returning overly general types.
1457 :class class1
1458 :format format1
1459 :complexp complexp1
1467 (!cold-init-forms
1477 typespec))
1480 typespec))
1490 ;; KLUDGE: This TYPECASE more or less does
1491 ;; (UPGRADED-COMPLEX-PART-TYPE (TYPE-OF COMPONENT)),
1492 ;; (plus a small hack to treat (EQL COMPONENT 0) specially)
1493 ;; but uses logic cut and pasted from the DEFUN of
1494 ;; UPGRADED-COMPLEX-PART-TYPE. That's fragile, because
1495 ;; changing the definition of UPGRADED-COMPLEX-PART-TYPE
1496 ;; would tend to break the code here. Unfortunately,
1497 ;; though, reusing UPGRADED-COMPLEX-PART-TYPE here
1498 ;; would cause another kind of fragility, because
1499 ;; ANSI's definition of TYPE-OF is so weak that e.g.
1500 ;; (UPGRADED-COMPLEX-PART-TYPE (TYPE-OF 1/2)) could
1501 ;; end up being (UPGRADED-COMPLEX-PART-TYPE 'REAL)
1502 ;; instead of (UPGRADED-COMPLEX-PART-TYPE 'RATIONAL).
1503 ;; So using TYPE-OF would mean that ANSI-conforming
1504 ;; maintenance changes in TYPE-OF could break the code here.
1505 ;; It's not clear how best to fix this. -- WHN 2002-01-21,
1506 ;; trying to summarize CSR's concerns in his patch
1509 is complex: ~S"
1510 component))
1514 #!+long-float
1522 ;; FIXME: This code could suffer from
1523 ;; (admittedly very obscure) cases of
1524 ;; bug 145 e.g. when TYPE is
1525 ;; (OR (AND INTEGER (SATISFIES ODDP))
1526 ;; (AND FLOAT (SATISFIES FOO))
1527 ;; and not even report the problem very well.
1530 ;; MEMBER-TYPE is almost the same as UNION-TYPE, but
1531 ;; there's a gotcha: (COMPLEX (EQL 0)) is, according to
1532 ;; ANSI, equal to type NIL, the empty set.
1541 ;; ANSI just says that TYPESPEC is any subtype of
1542 ;; type REAL, not necessarily a NUMERIC-TYPE. In
1543 ;; particular, at this point TYPESPEC could legally be
1544 ;; an intersection type like (AND REAL (SATISFIES ODDP)),
1545 ;; in which case we fall through the logic above and
1546 ;; end up here, stumped.
1548 used for a COMPLEX component.~:@>"
1549 typespec)))))))))
1551 ;;; If X is *, return NIL, otherwise return the bound, which must be a
1552 ;;; member of TYPE or a one-element list of a member of TYPE.
1560 bound)
1563 '*
1564 type
1565 type
1566 bound))))
1574 ;; previously we threw an error here:
1575 ;; (error "Lower bound ~S is greater than upper bound ~S." l h))
1576 ;; but ANSI doesn't say anything about that, so:
1581 :low lb
1589 ;; as above, previously we did
1590 ;; (error "Lower bound ~S is not less than upper bound ~S." low high))
1591 ;; but it is correct to do
1597 ;;; Unlike CMU CL, we represent the types FLOAT and REAL as
1598 ;;; UNION-TYPEs of more primitive types, in order to make
1599 ;;; type representation more unique, avoiding problems in the
1600 ;;; simplification of things like
1601 ;;; (subtypep '(or (single-float -1.0 1.0) (single-float 0.1))
1602 ;;; '(or (real -1 7) (single-float 0.1) (single-float -1.0 1.0)))
1603 ;;; When we allowed REAL to remain as a separate NUMERIC-TYPE,
1604 ;;; it was too easy for the first argument to be simplified to
1605 ;;; '(SINGLE-FLOAT -1.0), and for the second argument to be simplified
1606 ;;; to '(OR (REAL -1 7) (SINGLE-FLOAT 0.1)) and then for the
1607 ;;; SUBTYPEP to fail (returning NIL,T instead of T,T) because
1608 ;;; the first argument can't be seen to be a subtype of any of the
1609 ;;; terms in the second argument.
1610 ;;;
1611 ;;; The old CMU CL way was:
1612 ;;; (!def-bounded-type float float nil)
1613 ;;; (!def-bounded-type real nil nil)
1614 ;;;
1615 ;;; FIXME: If this new way works for a while with no weird new
1616 ;;; problems, we can go back and rip out support for separate FLOAT
1617 ;;; and REAL flavors of NUMERIC-TYPE. The new way was added in
1618 ;;; sbcl-0.6.11.22, 2001-03-21.
1619 ;;;
1620 ;;; FIXME: It's probably necessary to do something to fix the
1621 ;;; analogous problem with INTEGER and RATIONAL types. Perhaps
1622 ;;; bounded RATIONAL types should be represented as (OR RATIO INTEGER).
1626 bound)
1636 bound
1637 ;; Coerce to the widest float format available, to
1638 ;; avoid unnecessary loss of precision:
1677 ;; If one is complex and the other isn't, then they are disjoint.
1680 nil)
1681 ;; If either type is a float, then the other must either be
1682 ;; specified to be a float or unspecified. Otherwise, they
1683 ;; are disjoint.
1688 ;; If the float formats are specified and different, the
1689 ;; types are disjoint.
1691 nil)
1693 ;; Check the bounds. This is a bit odd because we must
1694 ;; always have the outer bound of the interval as the
1695 ;; second arg.
1706 ;;; Take the numeric bound X and convert it into something that can be
1707 ;;; used as a bound in a numeric type with the specified CLASS and
1708 ;;; FORMAT. If UP-P is true, then we round up as needed, otherwise we
1709 ;;; round down. UP-P true implies that X is a lower bound, i.e. (N) > N.
1710 ;;;
1711 ;;; This is used by NUMERIC-TYPE-INTERSECTION to mash the bound into
1712 ;;; the appropriate type number. X may only be a float when CLASS is
1713 ;;; FLOAT.
1714 ;;;
1715 ;;; ### Note: it is possible for the coercion to a float to overflow
1716 ;;; or underflow. This happens when the bound doesn't fit in the
1717 ;;; specified format. In this case, we should really return the
1718 ;;; appropriate {Most | Least}-{Positive | Negative}-XXX-Float float
1719 ;;; of desired format. But these conditions aren't currently signalled
1720 ;;; in any useful way.
1721 ;;;
1722 ;;; Also, when converting an open rational bound into a float we
1723 ;;; should probably convert it to a closed bound of the closest float
1724 ;;; in the specified format. KLUDGE: In general, open float bounds are
1725 ;;; screwed up. -- (comment from original CMU CL)
1738 nil))
1740 ;;; Handle the case of type intersection on two numeric types. We use
1741 ;;; TYPES-EQUAL-OR-INTERSECT to throw out the case of types with no
1742 ;;; intersection. If an attribute in TYPE1 is unspecified, then we use
1743 ;;; TYPE2's attribute, which must be at least as restrictive. If the
1744 ;;; types intersect, then the only attributes that can be specified
1745 ;;; and different are the class and the bounds.
1746 ;;;
1747 ;;; When the class differs, we use the more restrictive class. The
1748 ;;; only interesting case is RATIONAL/INTEGER, since RATIONAL includes
1749 ;;; INTEGER.
1750 ;;;
1751 ;;; We make the result lower (upper) bound the maximum (minimum) of
1752 ;;; the argument lower (upper) bounds. We convert the bounds into the
1753 ;;; appropriate numeric type before maximizing. This avoids possible
1754 ;;; confusion due to mixed-type comparisons (but I think the result is
1755 ;;; the same).
1765 'integer
1770 :class class
1771 :format format
1776 class format t)
1778 class format t)
1782 class format nil)
1784 class format nil)
1788 ;;; Given two float formats, return the one with more precision. If
1789 ;;; either one is null, return NIL.
1796 ;;; Return the result of an operation on TYPE1 and TYPE2 according to
1797 ;;; the rules of numeric contagion. This is always NUMBER, some float
1798 ;;; format (possibly complex) or RATIONAL. Due to rational
1799 ;;; canonicalization, there isn't much we can do here with integers or
1800 ;;; rational complex numbers.
1801 ;;;
1802 ;;; If either argument is not a NUMERIC-TYPE, then return NUMBER. This
1803 ;;; is useful mainly for allowing types that are technically numbers,
1804 ;;; but not a NUMERIC-TYPE.
1823 ;; A double-float with any real number is a
1824 ;; double-float.
1825 #!-long-float
1827 'double-float
1828 nil)
1829 ;; A long-float with any real number is a
1830 ;; long-float.
1831 #!+long-float
1833 'long-float
1834 nil)))
1837 :complex
1847 \f
1848 ;;;; array types
1852 ;;; What this does depends on the setting of the
1853 ;;; *USE-IMPLEMENTATION-TYPES* switch. If true, return the specialized
1854 ;;; element type, otherwise return the original element type.
1867 ;; by its nature, the call to TYPE= should never return NIL,
1868 ;; T, as we don't know what the UNKNOWN-TYPE will grow up to
1869 ;; be. -- CSR, 2002-08-19
1878 t)))
1927 ;; (sbcl-0.6.4 has trouble figuring out that
1928 ;; DIMS1 and DIMS2 must be lists at this
1929 ;; point, and knowing that is important to
1930 ;; compiling EVERY efficiently.)
1938 ;; not subtypep unless complexness is compatible
1942 ;; Since we didn't fail any of the tests above, we win
1943 ;; if the TYPE2 element type is wild.
1947 ;; can't give a good answer unless both the element types
1948 ;; have been defined.
1953 ;; types are equal, and they're equal iff the specialized
1954 ;; element types are identical.
1955 t
1958 t)))))
1960 (!define-superclasses array
1972 ;; See whether dimensions are compatible.
1977 dims1 dims2))))
1979 ;; See whether complexpness is compatible.
1984 ;; Old comment:
1985 ;;
1986 ;; If either element type is wild, then they intersect.
1987 ;; Otherwise, the types must be identical.
1988 ;;
1989 ;; FIXME: There seems to have been a fair amount of
1990 ;; confusion about the distinction between requested element
1991 ;; type and specialized element type; here is one of
1992 ;; them. If we request an array to hold objects of an
1993 ;; unknown type, we can do no better than represent that
1994 ;; type as an array specialized on wild-type. We keep the
1995 ;; requested element-type in the -ELEMENT-TYPE slot, and
1996 ;; *WILD-TYPE* in the -SPECIALIZED-ELEMENT-TYPE. So, here,
1997 ;; we must test for the SPECIALIZED slot being *WILD-TYPE*,
1998 ;; not just the ELEMENT-TYPE slot. Maybe the return value
1999 ;; in that specific case should be T, NIL? Or maybe this
2000 ;; function should really be called
2001 ;; ARRAY-TYPES-COULD-POSSIBLY-INTERSECT? In any case, this
2002 ;; was responsible for bug #123, and this whole issue could
2003 ;; do with a rethink and/or a rewrite. -- CSR, 2002-08-21
2028 dims1 dims2)))
2033 ;;; Check a supplied dimension list to determine whether it is legal,
2034 ;;; and return it in canonical form (as either '* or a list).
2053 dims)
2056 \f
2057 ;;;; MEMBER types
2070 t))
2074 type2
2077 ;;; We punt if the odd type is enumerable and intersects with the
2078 ;;; MEMBER type. If not enumerable, then it is definitely not a
2079 ;;; subtype of the MEMBER type.
2111 ;;; We don't need a :COMPLEX-UNION2, since the only interesting case is
2112 ;;; a union type, and the member/union interaction is handled by the
2113 ;;; union type method.
2127 t)))
2141 \f
2142 ;;;; intersection types
2143 ;;;;
2144 ;;;; Until version 0.6.10.6, SBCL followed the original CMU CL approach
2145 ;;;; of punting on all AND types, not just the unreasonably complicated
2146 ;;;; ones. The change was motivated by trying to get the KEYWORD type
2147 ;;;; to behave sensibly:
2148 ;;;; ;; reasonable definition
2149 ;;;; (DEFTYPE KEYWORD () '(AND SYMBOL (SATISFIES KEYWORDP)))
2150 ;;;; ;; reasonable behavior
2151 ;;;; (AVER (SUBTYPEP 'KEYWORD 'SYMBOL))
2152 ;;;; Without understanding a little about the semantics of AND, we'd
2153 ;;;; get (SUBTYPEP 'KEYWORD 'SYMBOL)=>NIL,NIL and, for entirely
2154 ;;;; parallel reasons, (SUBTYPEP 'RATIO 'NUMBER)=>NIL,NIL. That's
2155 ;;;; not so good..)
2156 ;;;;
2157 ;;;; We still follow the example of CMU CL to some extent, by punting
2158 ;;;; (to the opaque HAIRY-TYPE) on sufficiently complicated types
2159 ;;;; involving AND.
2163 ;;; A few intersection types have special names. The others just get
2164 ;;; mechanically unparsed.
2170 ;;; shared machinery for type equality: true if every type in the set
2171 ;;; TYPES1 matches a type in the set TYPES2 and vice versa
2178 x)))
2181 t)))
2183 ;;; Two intersection types are equal if their subtypes are equal sets.
2184 ;;;
2185 ;;; FIXME: Might it be better to use
2186 ;;; (AND (SUBTYPEP X Y) (SUBTYPEP Y X))
2187 ;;; instead, since SUBTYPEP is the usual relationship that we care
2188 ;;; most about, so it would be good to leverage any ingenuity there
2189 ;;; in this more obscure method?
2196 type2
2201 type1
2213 type-specifiers)))
2214 \f
2215 ;;;; union types
2219 ;;; The LIST, FLOAT and REAL types have special names. Other union
2220 ;;; types just get mechanically unparsed.
2231 ;;; Two union types are equal if they are each subtypes of each
2232 ;;; other. We need to be this clever because our complex subtypep
2233 ;;; methods are now more accurate; we don't get infinite recursion
2234 ;;; because the simple-subtypep method delegates to complex-subtypep
2235 ;;; of the individual types of type1. - CSR, 2002-04-09
2236 ;;;
2237 ;;; Previous comment, now obsolete, but worth keeping around because
2238 ;;; it is true, though too strong a condition:
2239 ;;;
2240 ;;; Two union types are equal if their subtypes are equal sets.
2246 ;; we might as well become as certain as possible.
2260 ;;; Similarly, a union type is a subtype of another if and only if
2261 ;;; every element of TYPE1 is a subtype of TYPE2.
2264 type2
2272 type2
2280 ;; was: (any/type #'csubtypep type1 (union-type-types type2)),
2281 ;; which turns out to be too restrictive, causing bug 91.
2282 ;;
2283 ;; the following reimplementation might look dodgy. It is
2284 ;; dodgy. It depends on the union :complex-= method not doing
2285 ;; very much work -- certainly, not using subtypep. Reasoning:
2287 ;; At this stage, we know that type2 is a union type and type1
2288 ;; isn't. We might as well check this, though:
2291 ;; A is a subset of (B1 u B2)
2292 ;; <=> A n (B1 u B2) = A
2293 ;; <=> (A n B1) u (A n B2) = A
2294 ;;
2295 ;; But, we have to be careful not to delegate this type= to
2296 ;; something that could invoke subtypep, which might get us
2297 ;; back here -> stack explosion. We therefore ensure that the
2298 ;; second type (which is the one that's dispatched on) is
2299 ;; either a union type (where we've ensured that the complex-=
2300 ;; method will not call subtypep) or something with no union
2301 ;; types involved, in which case we'll never come back here.
2302 ;;
2303 ;; If we don't do this, then e.g.
2304 ;; (SUBTYPEP '(MEMBER 3) '(OR (SATISFIES FOO) (SATISFIES BAR)))
2305 ;; would loop infinitely, as the member :complex-= method is
2306 ;; implemented in terms of subtypep.
2307 ;;
2308 ;; Ouch. - CSR, 2002-04-10
2315 ;; The ANY/TYPE expression above is a sufficient condition for
2316 ;; subsetness, but not a necessary one, so we might get a more
2317 ;; certain answer by this CALL-NEXT-METHOD-ish step when the
2318 ;; ANY/TYPE expression is uncertain.
2326 ;; The CSUBTYPEP clauses here let us simplify e.g.
2327 ;; (TYPE-INTERSECTION2 (SPECIFIER-TYPE 'LIST)
2328 ;; (SPECIFIER-TYPE '(OR LIST VECTOR)))
2329 ;; (where LIST is (OR CONS NULL)).
2330 ;;
2331 ;; The tests are more or less (CSUBTYPEP TYPE1 TYPE2) and vice
2332 ;; versa, but it's important that we pre-expand them into
2333 ;; specialized operations on individual elements of
2334 ;; UNION-TYPE-TYPES, instead of using the ordinary call to
2335 ;; CSUBTYPEP, in order to avoid possibly invoking any methods which
2336 ;; might in turn invoke (TYPE-INTERSECTION2 TYPE1 TYPE2) and thus
2337 ;; cause infinite recursion.
2338 ;;
2339 ;; Within this method, type2 is guaranteed to be a union type:
2341 ;; Make sure to call only the applicable methods...
2348 type1)
2351 type2)
2353 ;; KLUDGE: This code accumulates a sequence of TYPE-UNION2
2354 ;; operations in a particular order, and gives up if any of
2355 ;; the sub-unions turn out not to be simple. In other cases
2356 ;; ca. sbcl-0.6.11.15, that approach to taking a union was a
2357 ;; bad idea, since it can overlook simplifications which
2358 ;; might occur if the terms were accumulated in a different
2359 ;; order. It's possible that that will be a problem here too.
2360 ;; However, I can't think of a good example to demonstrate
2361 ;; it, and without an example to demonstrate it I can't write
2362 ;; test cases, and without test cases I don't want to
2363 ;; complicate the code to address what's still a hypothetical
2364 ;; problem. So I punted. -- WHN 2001-03-20
2370 ;; When our result isn't simple any more (because
2371 ;; TYPE-UNION2 was unable to give us a simple result)
2378 type-specifiers)))
2379 \f
2380 ;;;; CONS types
2393 'cons
2411 ;;; Give up if a precise type is not possible, to avoid returning
2412 ;;; overly general types.
2424 cdr-type1)))))
2429 cdr-int2)
2435 \f
2436 ;;; Return the type that describes all objects that are in X but not
2437 ;;; in Y. If we can't determine this type, then return NIL.
2438 ;;;
2439 ;;; For now, we only are clever dealing with union and member types.
2440 ;;; If either type is not a union type, then we pretend that it is a
2441 ;;; union of just one type. What we do is remove from X all the types
2442 ;;; that are a subtype any type in Y. If any type in X intersects with
2443 ;;; a type in Y but is not a subtype, then we give up.
2444 ;;;
2445 ;;; We must also special-case any member type that appears in the
2446 ;;; union. We remove from X's members all objects that are TYPEP to Y.
2447 ;;; If Y has any members, we must be careful that none of those
2448 ;;; members are CTYPEP to any of Y's non-member types. We give up in
2449 ;;; this case, since to compute that difference we would have to break
2450 ;;; the type from X into some collection of types that represents the
2451 ;;; type without that particular element. This seems too hairy to be
2452 ;;; worthwhile, given its low utility.
2483 \f
2496 \f
2497 ;;;; utilities shared between cross-compiler and target system
2499 ;;; Does the type derived from compilation of an actual function
2500 ;;; definition satisfy declarations of a function's type?
2507 ;; that's what happens when we (DECLAIM (FTYPE FUNCTION FOO)).
2509 ;; In that case, any definition satisfies the declaration.
2510 t)
2512 ;; #<BUILT-IN-CLASS FUNCTION>, but it's not obviously
2513 ;; invalid, so let's handle that case too, just in case.
2515 ;; No matter what DECLARED-FTYPE might be, we can't prove
2516 ;; that an object of type FUNCTION doesn't satisfy it, so
2517 ;; we return success no matter what.
2518 t)
2520 t
2521 ;; FIXME: For now we only check compatibility of the return
2522 ;; type, not argument types, and we don't even check the
2523 ;; return type very precisely (as per bug 94a). It would be
2524 ;; good to do a better job. Perhaps to check the
2525 ;; compatibility of the arguments, we should (1) redo
2526 ;; VALUES-TYPES-EQUAL-OR-INTERSECT as
2527 ;; ARGS-TYPES-EQUAL-OR-INTERSECT, and then (2) apply it to
2528 ;; the ARGS-TYPE slices of the FUN-TYPEs. (ARGS-TYPE
2529 ;; is a base class both of VALUES-TYPE and of FUN-TYPE.)
2534 ;;; This messy case of CTYPE for NUMBER is shared between the
2535 ;;; cross-compiler and the target system.
2548 :complexp complexp
2549 :low low
2551 \f
2553 ;; Why SAFETY 0? To suppress the is-it-the-right-structure-type
2554 ;; checking for declarations in structure accessors. Otherwise we
2555 ;; can get caught in a chicken-and-egg bootstrapping problem, whose
2556 ;; symptom on x86 OpenBSD sbcl-0.pre7.37.flaky5.22 is an illegal
2557 ;; instruction trap. I haven't tracked it down, but I'm guessing it
2558 ;; has to do with setting LAYOUTs when the LAYOUT hasn't been set
2559 ;; yet. -- WHN