0.7.2.7:
[sbcl.git] / src / code / typedefs.lisp
index 3d0c69f..228d605 100644 (file)
@@ -27,7 +27,7 @@
 ;;; Define the translation from a type-specifier to a type structure for
 ;;; some particular type. Syntax is identical to DEFTYPE.
 (defmacro !def-type-translator (name arglist &body body)
-  (check-type name symbol)
+  (declare (type symbol name))
   ;; FIXME: Now that the T%CL hack is ancient history and we just use CL
   ;; instead, we can probably return to using PARSE-DEFMACRO here.
   ;;
@@ -69,7 +69,7 @@
   ;; named TYPE-CLASS-INFO which is an accessor for the CTYPE structure
   ;; even though the TYPE-CLASS structure also exists in the system.
   ;; Rename this slot: TYPE-CLASS or ASSOCIATED-TYPE-CLASS or something.
-  (class-info (required-argument) :type type-class)
+  (class-info (missing-arg) :type type-class)
   ;; True if this type has a fixed number of members, and as such
   ;; could possibly be completely specified in a MEMBER type. This is
   ;; used by the MEMBER type methods.
   ;; (since EQ hashing can't be done portably)
   (hash-value (random (1+ most-positive-fixnum))
              :type (and fixnum unsigned-byte)
-             :read-only t))
+             :read-only t)
+  ;; Can this object contain other types? A global property of our
+  ;; implementation (which unfortunately seems impossible to enforce
+  ;; with assertions or other in-the-code checks and constraints) is
+  ;; that subclasses which don't contain other types correspond to
+  ;; disjoint subsets (except of course for the NAMED-TYPE T, which
+  ;; covers everything). So NUMBER-TYPE is disjoint from CONS-TYPE is
+  ;; is disjoint from MEMBER-TYPE and so forth. But types which can
+  ;; contain other types, like HAIRY-TYPE and INTERSECTION-TYPE, can
+  ;; violate this rule.
+  (might-contain-other-types? nil :read-only t))
 (def!method print-object ((ctype ctype) stream)
   (print-unreadable-object (ctype stream :type t)
     (prin1 (type-specifier ctype) stream)))