| blob | 4df48bd25181bff7fada0185bd23d29e3850dfd1 |
1 ;;;; This file contains structures and functions for the maintenance of
2 ;;;; basic information about defined types. Different object systems
3 ;;;; can be supported simultaneously.
5 ;;;; This software is part of the SBCL system. See the README file for
6 ;;;; more information.
7 ;;;;
8 ;;;; This software is derived from the CMU CL system, which was
9 ;;;; written at Carnegie Mellon University and released into the
10 ;;;; public domain. The software is in the public domain and is
11 ;;;; provided with absolutely no warranty. See the COPYING and CREDITS
12 ;;;; files for more information.
17 \f
18 ;;;; the CLASSOID structure
20 ;;; The CLASSOID structure is a supertype of all classoid types.
21 ;;; Its definition occurs in 'early-classoid.lisp'
29 self))))
31 \f
32 ;;;; basic LAYOUT stuff
34 ;;; a list of conses, initialized by genesis
35 ;;;
36 ;;; In each cons, the car is the symbol naming the layout, and the
37 ;;; cdr is the layout itself.
40 ;;; a table mapping class names to layouts for classes we have
41 ;;; referenced but not yet loaded. This is initialized from an alist
42 ;;; created by genesis describing the layouts that genesis created at
43 ;;; cold-load time.
45 (!cold-init-forms
46 ;; Protected by *WORLD-LOCK*
56 ;;; The LAYOUT structure itself is defined in 'early-classoid.lisp'
64 "for ~S~@[, INVALID=~S~]"
71 \f
72 ;;;; support for the hash values used by CLOS when working with LAYOUTs
74 ;;; a generator for random values suitable for the CLOS-HASH slots of
75 ;;; LAYOUTs. We use our own RANDOM-STATE here because we'd like
76 ;;; pseudo-random values to come the same way in the target even when
77 ;;; we make minor changes to the system, in order to reduce the
78 ;;; mysteriousness of possible CLOS bugs.
81 ;; FIXME: I'm not sure why this expression is (1+ (RANDOM FOO)),
82 ;; returning a strictly positive value. I copied it verbatim from
83 ;; CMU CL INITIALIZE-LAYOUT-HASH, so presumably it works, but I
84 ;; dunno whether the hash values are really supposed to be 1-based.
85 ;; They're declared as INDEX.. Or is this a hack to try to avoid
86 ;; having to use bignum arithmetic? Or what? An explanation would be
87 ;; nice.
88 ;;
89 ;; an explanation is provided in Kiczales and Rodriguez, "Efficient
90 ;; Method Dispatch in PCL", 1990. -- CSR, 2005-11-30
96 \f
97 ;;; If we can't find any existing layout, then we create a new one
98 ;;; storing it in *FORWARD-REFERENCED-LAYOUTS*. In classic CMU CL, we
99 ;;; used to immediately check for compatibility, but for
100 ;;; cross-compilability reasons (i.e. convenience of using this
101 ;;; function in a MAKE-LOAD-FORM expression) that functionality has
102 ;;; been split off into INIT-OR-CHECK-LAYOUT.
104 ;; The comment "This seems ..." is misleading but I don't have a better one.
105 ;; FIND-LAYOUT is used by FIND-AND-INIT-OR-CHECK-LAYOUT which is used
106 ;; by FOP-LAYOUT, so clearly it's used when reading fasl files.
108 ;; This seems to be currently used only from the compiler, but make
109 ;; it thread-safe all the same. We need to lock *F-R-L* before doing
110 ;; FIND-CLASSOID in case (SETF FIND-CLASSOID) happens in parallel.
119 ;;; If LAYOUT is uninitialized, initialize it with CLASSOID, LENGTH,
120 ;;; INHERITS, DEPTHOID, and BITMAP.
121 ;;; Otherwise require that it be consistent with the existing values.
122 ;;;
123 ;;; UNDEFINED-CLASS values are interpreted specially as "we don't know
124 ;;; anything about the class", so if LAYOUT is initialized, any
125 ;;; preexisting class slot value is OK, and if it's not initialized,
126 ;;; its class slot value is set to an UNDEFINED-CLASS. -- FIXME: This
127 ;;; is no longer true, :UNINITIALIZED used instead.
129 layout)
130 %init-or-check-layout))
133 ;; There was no layout before, we just created one which
134 ;; we'll now initialize with our information.
141 ;; FIXME: Now that LAYOUTs are born :UNINITIALIZED, maybe this
142 ;; clause is not needed?
146 ;; There was an old layout already initialized with old
147 ;; information, and we'll now check that old information
148 ;; which was known with certainty is consistent with current
149 ;; information which is known with certainty.
151 layout)
153 ;;; In code for the target Lisp, we don't dump LAYOUTs using the
154 ;;; standard load form mechanism, we use special fops instead, in
155 ;;; order to make cold load come out right. But when we're building
156 ;;; the cross-compiler, we can't do that because we don't have access
157 ;;; to special non-ANSI low-level things like special fops, and we
158 ;;; don't need to do that anyway because our code isn't going to be
159 ;;; cold loaded, so we use the ordinary load form system.
160 #+sb-xc-host
169 ;; Since LAYOUT refers to a class which refers back to the LAYOUT,
170 ;; we have to do this in two stages, like the TREE-WITH-PARENT
171 ;; example in the MAKE-LOAD-FORM entry in the ANSI spec.
173 ;; "creation" form (which actually doesn't create a new LAYOUT if
174 ;; there's a preexisting one with this name)
176 ;; "initialization" form (which actually doesn't initialize
177 ;; preexisting LAYOUTs, just checks that they're consistent).
186 ;;; If LAYOUT's slot values differ from the specified slot values in
187 ;;; any interesting way, then give a warning and return T.
189 layout
190 simple-string
191 index
192 simple-vector
193 layout-depthoid
194 layout-bitmap))
195 redefine-layout-warning))
197 context length inherits depthoid bitmap)
203 ~A superclasses: ~S~% ~
204 ~A superclasses: ~S"
205 name
206 old-context
208 context
210 t)
214 ~@(~A~) definition of superclass ~S is incompatible with~% ~
215 ~A definition."
216 name
217 old-context
219 context)
220 t))
224 ~A length: ~W~% ~
225 ~A length: ~W"
226 name
227 old-context old-length
228 context length)
229 t))
233 between the ~A definition and the ~A definition"
234 name old-context context)
235 t))
238 between the ~A definition and the ~A definition"
239 name old-context context)
240 t))))
242 ;;; Require that LAYOUT data be consistent with CLASSOID, LENGTH,
243 ;;; INHERITS, DEPTHOID, and BITMAP.
245 check-layout))
250 ;; Classic CMU CL had more options here. There are several reasons
251 ;; why they might want more options which are less appropriate for
252 ;; us: (1) It's hard to fit the classic CMU CL flexible approach
253 ;; into the ANSI-style MAKE-LOAD-FORM system, and having a
254 ;; non-MAKE-LOAD-FORM-style system is painful when we're trying to
255 ;; make the cross-compiler run under vanilla ANSI Common Lisp. (2)
256 ;; We have CLOS now, and if you want to be able to flexibly
257 ;; redefine classes without restarting the system, it'd make sense
258 ;; to use that, so supporting complexity in order to allow
259 ;; modifying DEFSTRUCTs without restarting the system is a low
260 ;; priority. (3) We now have the ability to rebuild the SBCL
261 ;; system from scratch, so we no longer need this functionality in
262 ;; order to maintain the SBCL system by modifying running images.
267 ;;; a common idiom (the same as CMU CL FIND-LAYOUT) rolled up into a
268 ;;; single function call
269 ;;;
270 ;;; Used by the loader to forward-reference layouts for classes whose
271 ;;; definitions may not have been loaded yet. This allows type tests
272 ;;; to be loaded when the type definition hasn't been loaded yet.
274 layout)
275 find-and-init-or-check-layout))
281 (%init-or-check-layout layout
284 length
285 inherits
286 depthoid
287 bitmap)))))
289 ;;; Record LAYOUT as the layout for its class, adding it as a subtype
290 ;;; of all superclasses. This is the operation that "installs" a
291 ;;; layout for a class in the type system, clobbering any old layout.
292 ;;; However, this does not modify the class namespace; that is a
293 ;;; separate operation (think anonymous classes.)
294 ;;; -- If INVALIDATE, then all the layouts for any old definition
295 ;;; and subclasses are invalidated, and the SUBCLASSES slot is cleared.
296 ;;; -- If DESTRUCT-LAYOUT, then this is some old layout, and is to be
297 ;;; destructively modified to hold the same type information.
306 ;; Attempting to register ourselves with a temporary undefined
307 ;; class placeholder is almost certainly a programmer error. (I
308 ;; should know, I did it.) -- WHN 19990927
311 ;; This assertion dates from classic CMU CL. The rationale is
312 ;; probably that calling REGISTER-LAYOUT more than once for the
313 ;; same LAYOUT is almost certainly a programmer error.
316 ;; Figure out what classes are affected by the change, and issue
317 ;; appropriate warnings and invalidations.
358 ;;; Arrange the inherited layouts to appear at their expected depth,
359 ;;; ensuring that hierarchical type tests succeed. Layouts with
360 ;;; DEPTHOID >= 0 (i.e. hierarchical classes) are placed first,
361 ;;; at exactly that index in the INHERITS vector. Then, non-hierarchical
362 ;;; layouts are placed in remaining elements. Then, any still-empty
363 ;;; elements are filled with their successors, ensuring that each
364 ;;; element contains a valid layout.
365 ;;;
366 ;;; This reordering may destroy CPL ordering, so the inherits should
367 ;;; not be read as being in CPL order.
377 ;; KLUDGE: 0 here is the "uninitialized" element. We need
378 ;; to specify it explicitly for portability purposes, as
379 ;; elements can be read before being set [ see below, "(EQL
380 ;; OLD-LAYOUT 0)" ]. -- CSR, 2002-04-20
406 inherits)))
407 \f
408 ;;;; class precedence lists
410 ;;; Topologically sort the list of objects to meet a set of ordering
411 ;;; constraints given by pairs (A . B) constraining A to precede B.
412 ;;; When there are multiple objects to choose, the tie-breaker
413 ;;; function is called with both the list of object to choose from and
414 ;;; the reverse ordering built so far.
449 obj)))
459 ;;; standard class precedence list computation
479 superclasses)))
484 \f
485 ;;;; object types to represent classes
487 ;;; BUILT-IN-CLASS is used to represent the standard classes that
488 ;;; aren't defined with DEFSTRUCT and other specially implemented
489 ;;; primitive types whose only attribute is their name.
490 ;;; It is defined in 'early-classoid.lisp'
492 ;;; STRUCTURE-CLASS represents what we need to know about structure
493 ;;; classes. Non-structure "typed" defstructs are a special case, and
494 ;;; don't have a corresponding class.
499 \f
500 ;;;; classoid namespace
511 (:forthcoming-defclass-type
512 ;; FIXME: Currently, nothing needs to be done in this case.
513 ;; Later, when PCL is integrated tighter into SBCL, this
514 ;; might need more work.
515 nil)
516 (:instance
520 ;; KLUDGE: The reason these clauses aren't directly
521 ;; parallel is that we need to use the internal
522 ;; CLASSOID structure ourselves, because we don't
523 ;; have CLASSes to work with until PCL is built. In
524 ;; the host, CLASSes have an approximately
525 ;; one-to-one correspondence with the target
526 ;; CLASSOIDs (as well as with the target CLASSes,
527 ;; modulo potential differences with respect to
528 ;; conditions).
529 #+sb-xc-host
534 cross-compiler."
536 #-sb-xc-host
542 (:primitive
545 (:defined
553 ;; FIXME: I'm unconvinced of the need to handle either of these.
554 ;; Package locks preclude the latter, and in the former case,
555 ;; once you've made some random thing into a :PRIMITIVE kind of type,
556 ;; you've painted yourself into a corner - those types
557 ;; elicit vociferous complaints if you try to redefine them.
558 ;;
559 ;; we need to handle things like
560 ;; (setf (find-class 'foo) (find-class 'integer))
561 ;; and
562 ;; (setf (find-class 'integer) (find-class 'integer))
564 ;; But I can't figure out how to get assertions to pass
565 ;; without violation what would otherwise be invariants
566 ;; of the internal representation of types. This sucks.
576 new-value)
582 (:primitive
587 ;; Note: We cannot remove the classoid cell from the table,
588 ;; since compiled code may refer directly to the cell, and
589 ;; getting a different cell for a classoid with the same name
590 ;; just would not do.
592 ;; Remove the proper name of the classoid, if this was it.
598 ;; Clear the cell.
605 ;;; Called when we are about to define NAME as a class meeting some
606 ;;; predicate (such as a meta-class type test.) The first result is
607 ;;; always of the desired class. The second result is any existing
608 ;;; LAYOUT for this name.
609 ;;;
610 ;;; Again, this should be compiler-only, but easier to make this
611 ;;; thread-safe.
618 old
626 ;;; If the classoid has a proper name, return the name, otherwise return
627 ;;; the classoid.
632 name
633 classoid)))
634 \f
635 ;;;; CLASS type operations
637 ;; CLASSOID-ENUMERABLE-P is referenced during compile by !DEFINE-TYPE-CLASS.
638 ;; But don't redefine it when building the target since we've already
639 ;; got a perfectly good definition loaded for the host.
641 ;; Actually this definition makes very little sense because
642 ;; (TYPE-ENUMERABLE (FIND-CLASSOID 'CHARACTER)) => T
643 ;; but (TYPE-ENUMERABLE (SPECIFIER-TYPE 'CHARACTER)) => NIL.
644 ;; You should never see the CLASSOID used as a type though,
645 ;; at least not from parsing and set operations.
646 ;; On a related note, (TYPE-ENUMERABLE (FIND-CLASSOID 'NULL))
647 ;; should probably be T, but you'll never see that type either.
648 ;; Perhaps a better definition of this function would be
649 ;; (if (classoid-translation x) (bug "enumerable-p classoid?") nil)
659 super-or-name)))
663 ;;; We might be passed classoids with invalid layouts; in any pairwise
664 ;;; class comparison, we must ensure that both are valid before
665 ;;; proceeding.
670 ;; Avoid accidentally reaching code that can't work.
672 #-sb-xc-host
678 t)
682 ~S in ~A.~%~:@>"
683 class
685 error-context))
686 nil)
689 t)))
691 for ~A.~%~:@>"
699 t)
707 ;; FIXME: explain why this isn't (LAYOUT-FOR-STD-CLASS-P LAYOUT).
712 ;;; Simple methods for TYPE= and SUBTYPEP should never be called when
713 ;;; the two classes are equal, since there are EQ checks in those
714 ;;; operations.
732 ;; If there's a forward-referenced class involved we don't know for sure.
733 ;; (There are cases which we /could/ figure out, but that doesn't seem
734 ;; to be required or important, really.)
739 ;;; When finding the intersection of a sealed class and some other
740 ;;; class (not hierarchically related) the intersection is the union
741 ;;; of the currently shared subclasses.
760 class1)
761 ;; If one is a subclass of the other, then that is the
762 ;; intersection.
765 class1)
768 class2)
769 ;; Otherwise, we can't in general be sure that the
770 ;; intersection is empty, since a subclass of both might be
771 ;; defined. But we can eliminate it for some special cases.
774 ;; No subclass of both can be defined.
777 ;; checking whether a subclass of both can be defined:
780 ;; checking whether a subclass of both can be defined:
782 ;; If exactly one of CLASS{1,2} is a CONDITION-CLASSOID,
783 ;; there can be no intersection: sub-/superclass relations
784 ;; between CONDITION-CLASSOIDs and other CLASSOIDs are not
785 ;; possible and a CONDITION-CLASSOIDs cannot be changed into
786 ;; different CLASSOIDs.
792 ;; uncertain, since a subclass of both might be defined
793 nil))))
795 ;;; KLUDGE: we need this to deal with the special-case INSTANCE and
796 ;;; FUNCALLABLE-INSTANCE types (which used to be CLASSOIDs until CSR
797 ;;; discovered that this was incompatible with the MOP class
798 ;;; hierarchy). See NAMED :COMPLEX-SUBTYPEP-ARG2
802 lra fdefn random-class))
809 ;;; KLUDGE: we need this because of the need to represent
810 ;;; intersections of two classes, even when empty at a given time, as
811 ;;; uncanonicalized intersections because of the possibility of later
812 ;;; defining a subclass of both classes. The necessity for changing
813 ;;; the default return value from SUBTYPEP to NIL, T if no alternate
814 ;;; method is present comes about because, unlike the other places we
815 ;;; use INVOKE-COMPLEX-SUBTYPEP-ARG1-METHOD, in HAIRY methods and the
816 ;;; like, classes are in their own hierarchy with no possibility of
817 ;;; mixtures with other type classes.
828 \f
829 ;;;; built-in classes
831 ;;; The BUILT-IN-CLASSES list is a data structure which configures the
832 ;;; creation of all the built-in classes. It contains all the info
833 ;;; that we need to maintain the mapping between classes, compile-time
834 ;;; types and run-time type codes. These options are defined:
835 ;;;
836 ;;; :TRANSLATION (default none)
837 ;;; When this class is "parsed" as a type specifier, it is
838 ;;; translated into the specified internal type representation,
839 ;;; rather than being left as a class. This is used for types
840 ;;; which we want to canonicalize to some other kind of type
841 ;;; object because in general we want to be able to include more
842 ;;; information than just the class (e.g. for numeric types.)
843 ;;;
844 ;;; :STATE (default :SEALED)
845 ;;; The value of CLASS-STATE which we want on completion,
846 ;;; indicating whether subclasses can be created at run-time.
847 ;;;
848 ;;; :HIERARCHICAL-P (default T unless any of the inherits are non-hierarchical)
849 ;;; True if we can assign this class a unique inheritance depth.
850 ;;;
851 ;;; :CODES (default none)
852 ;;; Run-time type codes which should be translated back to this
853 ;;; class by CLASS-OF. Unspecified for abstract classes.
854 ;;;
855 ;;; :INHERITS (default this class and T)
856 ;;; The class-precedence list for this class, with this class and
857 ;;; T implicit.
858 ;;;
859 ;;; :DIRECT-SUPERCLASSES (default to head of CPL)
860 ;;; List of the direct superclasses of this class.
861 ;;;
862 ;;; NB: not to be confused with SB-PCL::*BUILT-IN-CLASSES*
864 ;; To me these data would look nicer with commas instead of "#."
877 ;; should this be #!-(or x86 x86-64) ?
891 :translation complex
905 #!+long-float
911 #!+sb-simd-pack
913 :translation simd-pack
918 :translation float
921 :translation single-float
926 :translation double-float
930 #!+long-float
932 :translation long-float
937 :translation rational
945 :translation integer
960 :hierarchical-p nil
987 array sequence)
1075 (*))
1080 :element-type
1108 #!+long-float
1127 #!+long-float
1135 :translation string
1139 :translation simple-string
1153 array sequence)
1156 :translation base-string
1162 :translation simple-base-string
1166 array sequence)
1168 #!+sb-unicode
1175 #!+sb-unicode
1181 array sequence)
1188 :translation cons
1208 ;;; See also src/code/class-init.lisp where we finish setting up the
1209 ;;; translations for built-in types.
1210 (!cold-init-forms
1216 inherits
1217 codes
1218 state
1219 depth
1220 prototype-form
1225 x
1228 ()
1233 ;; Unseal it so that REGISTER-LAYOUT doesn't warn
1235 it)
1241 :name name
1243 :direct-superclasses
1245 nil
1247 direct-superclasses)))))))))
1258 super-layout))
1259 inherits-list))
1265 0
1266 inherits-vector
1267 depthoid
1272 ;;; Define temporary PCL STANDARD-CLASSes. These will be set up
1273 ;;; correctly and the Lisp layout replaced by a PCL wrapper after PCL
1274 ;;; is loaded and the class defined.
1275 (!cold-init-forms
1277 ;; You'd think with all the pedantic explanation in here it would at least
1278 ;; be right, but it isn't: layout-inherits for FUNDAMENTAL-STREAM
1279 ;; ends up as (T SLOT-OBJECT STREAM STANDARD-OBJECT)
1281 ;; the inherits-vector of FUNDAMENTAL-STREAM is set up,
1282 ;; a vector containing the elements of the list below,
1283 ;; i.e. '(T STREAM STREAM), is created, and
1284 ;; this is what the function ORDER-LAYOUT-INHERITS
1285 ;; would do, too.
1286 ;;
1287 ;; So, the purpose is to guarantee a valid layout for
1288 ;; the FUNDAMENTAL-STREAM class, matching what
1289 ;; ORDER-LAYOUT-INHERITS would do.
1290 ;; ORDER-LAYOUT-INHERITS would place STREAM at index 2
1291 ;; in the INHERITS(-VECTOR). Index 1 would not be
1292 ;; filled, so STREAM is duplicated there (as
1293 ;; ORDER-LAYOUTS-INHERITS would do). Maybe the
1294 ;; duplicate definition could be removed (removing a
1295 ;; STREAM element), because FUNDAMENTAL-STREAM is
1296 ;; redefined after PCL is set up, anyway. But to play
1297 ;; it safely, we define the class with a valid INHERITS
1298 ;; vector.
1305 ;; Needed to open-code the MAP, below
1312 inherits-list)))
1319 ;;; Now that we have set up the class heterarchy, seal the sealed
1320 ;;; classes. This must be done after the subclasses have been set up.
1321 (!cold-init-forms
1325 \f
1326 ;;;; class definition/redefinition
1328 ;;; This is to be called whenever we are altering a class.
1329 #+sb-xc-host
1331 #-sb-xc-host
1335 ;; FIXME: This should probably be CERROR.
1339 ;;; Mark LAYOUT as invalid. Setting DEPTHOID -1 helps cause unsafe
1340 ;;; structure type tests to fail. Remove class from all superclasses
1341 ;;; too (might not be registered, so might not be in subclasses of the
1342 ;;; nominal superclasses.) We set the layout-clos-hash slots to 0 to
1343 ;;; invalidate the wrappers for specialized dispatch functions, which
1344 ;;; use those slots as indexes into tables.
1358 \f
1359 ;;;; cold loading initializations
1361 ;;; FIXME: It would be good to arrange for this to be called when the
1362 ;;; cross-compiler is being built, not just when the target Lisp is
1363 ;;; being cold loaded. Perhaps this could be moved to its own file
1364 ;;; late in the build-order.lisp-expr sequence, and be put in
1365 ;;; !COLD-INIT-FORMS there?
1375 name layout))))))
1377 (!cold-init-forms
1384 x
1389 \f