X-Git-Url: http://repo.macrolet.net/gitweb/?a=blobdiff_plain;f=src%2Fcode%2Ftype-class.lisp;h=bf12bec17bba4d75099aff9c5d93f613f1aa7bae;hb=86210c4e406c1b2ff10cc3bac0e71435867db48b;hp=379c8a440735007e6a6b08f5620f7b5623ec946a;hpb=ce02ab2ecd9c6ae2e570abd8c93ebf3be55bbdad;p=sbcl.git diff --git a/src/code/type-class.lisp b/src/code/type-class.lisp index 379c8a4..bf12bec 100644 --- a/src/code/type-class.lisp +++ b/src/code/type-class.lisp @@ -36,7 +36,7 @@ (print-unreadable-object (x stream :type t) (prin1 (type-class-name x) stream))))) ;; the name of this type class (used to resolve references at load time) - (name nil :type symbol) ; FIXME: should perhaps be REQUIRED-ARGUMENT? + (name nil :type symbol) ; FIXME: should perhaps be (MISSING-ARG) default? ;; Dyadic type methods. If the classes of the two types are EQ, then ;; we call the SIMPLE-xxx method. If the classes are not EQ, and ;; either type's class has a COMPLEX-xxx method, then we call it. @@ -79,12 +79,8 @@ ;; TYPE-UNION, and TYPE-INTERSECTION handle those cases specially ;; (and deal with canonicalization/simplification issues at the ;; same time). - ;; - ;; FIXME: SIMPLE-UNION and COMPLEX-UNION methods haven't been - ;; converted to the new scheme yet. (Thus they never return NIL, I - ;; think. -- WHN 2001-03-11) - (simple-union #'vanilla-union :type function) - (complex-union nil :type (or function null)) + (simple-union2 #'hierarchical-union2 :type function) + (complex-union2 nil :type (or function null)) (simple-intersection2 #'hierarchical-intersection2 :type function) (complex-intersection2 nil :type (or function null)) (simple-= #'must-supply-this :type function) @@ -104,62 +100,67 @@ ;; supplying both. (unary-typep nil :type (or symbol null)) (typep nil :type (or symbol null)) - ;; Like TYPEP, UNARY-TYPEP except these functions coerce objects to this - ;; type. + ;; These are like TYPEP and UNARY-TYPEP except they coerce objects to + ;; the type. (unary-coerce nil :type (or symbol null)) (coerce :type (or symbol null)) |# ) (eval-when (:compile-toplevel :load-toplevel :execute) + ;; KLUDGE: If the slots of TYPE-CLASS ever change, the slots here + ;; will have to be tweaked to match. -- WHN 19991021 + (defparameter *type-class-fun-slots* + '((:simple-subtypep . type-class-simple-subtypep) + (:complex-subtypep-arg1 . type-class-complex-subtypep-arg1) + (:complex-subtypep-arg2 . type-class-complex-subtypep-arg2) + (:simple-union2 . type-class-simple-union2) + (:complex-union2 . type-class-complex-union2) + (:simple-intersection2 . type-class-simple-intersection2) + (:complex-intersection2 . type-class-complex-intersection2) + (:simple-= . type-class-simple-=) + (:complex-= . type-class-complex-=) + (:unparse . type-class-unparse)))) -;;; Copy TYPE-CLASS object X, using only operations which will work early in -;;; cold load. (COPY-STRUCTURE won't work early in cold load, because it needs -;;; RAW-INDEX and RAW-LENGTH information from LAYOUT-INFO, and LAYOUT-INFO -;;; isn't initialized early in cold load.) +(eval-when (:compile-toplevel :load-toplevel :execute) + +;;; Copy TYPE-CLASS object X, using only operations which will work +;;; early in cold load. (COPY-STRUCTURE won't work early in cold load, +;;; because it needs RAW-INDEX and RAW-LENGTH information from +;;; LAYOUT-INFO, and LAYOUT-INFO isn't initialized early in cold +;;; load.) ;;; -;;; FIXME: It's nasty having to maintain this hand-written copy function. And -;;; it seems intrinsically dain-bramaged to have RAW-INDEX and RAW-LENGTH in -;;; LAYOUT-INFO instead of directly in LAYOUT. We should fix this: * Move -;;; RAW-INDEX and RAW-LENGTH slots into LAYOUT itself. * Rewrite the various -;;; CHECK-LAYOUT-related functions so that they check RAW-INDEX and RAW-LENGTH -;;; too. * Remove this special hacked copy function, just use COPY-STRUCTURE -;;; instead. (For even more improvement, it'd be good to move the raw slots +;;; FIXME: It's nasty having to maintain this hand-written copy +;;; function. And it seems intrinsically dain-bramaged to have +;;; RAW-INDEX and RAW-LENGTH in LAYOUT-INFO instead of directly in +;;; LAYOUT. We should fix this: +;;; * Move RAW-INDEX and RAW-LENGTH slots into LAYOUT itself. +;;; * Rewrite the various CHECK-LAYOUT-related functions so that +;;; they check RAW-INDEX and RAW-LENGTH too. +;;; * Remove this special hacked copy function, just use +;;; COPY-STRUCTURE instead. +;;; (For even more improvement, it might be good to move the raw slots ;;; into the same object as the ordinary slots, instead of having the -;;; unfortunate extra level of indirection. But that'd probably require a lot -;;; of work, including updating the garbage collector to understand it.) +;;; unfortunate extra level of indirection. But that'd probably +;;; require a lot of work, including updating the garbage collector to +;;; understand it. And it might even hurt overall performance, because +;;; the positive effect of removing indirection could be cancelled by +;;; the negative effect of imposing an unnecessary GC write barrier on +;;; raw data which doesn't actually affect GC.) (declaim (ftype (function (type-class) type-class) copy-type-class-coldly)) (defun copy-type-class-coldly (x) - ;; KLUDGE: If the slots of TYPE-CLASS ever change, the slots here will have - ;; to be hand-tweaked to match. -- WHN 19991021 - (make-type-class :name (type-class-name x) - :simple-subtypep (type-class-simple-subtypep x) - :complex-subtypep-arg1 (type-class-complex-subtypep-arg1 x) - :complex-subtypep-arg2 (type-class-complex-subtypep-arg2 x) - :simple-union (type-class-simple-union x) - :complex-union (type-class-complex-union x) - :simple-intersection2 (type-class-simple-intersection2 x) - :complex-intersection2 (type-class-complex-intersection2 x) - :simple-= (type-class-simple-= x) - :complex-= (type-class-complex-= x) - :unparse (type-class-unparse x))) - -;;; KLUDGE: If the slots of TYPE-CLASS ever change, the slots here -;;; will have to be tweaked to match. -- WHN 19991021 -(defparameter *type-class-function-slots* - '((:simple-subtypep . type-class-simple-subtypep) - (:complex-subtypep-arg1 . type-class-complex-subtypep-arg1) - (:complex-subtypep-arg2 . type-class-complex-subtypep-arg2) - (:simple-union . type-class-simple-union) - (:complex-union . type-class-complex-union) - (:simple-intersection2 . type-class-simple-intersection2) - (:complex-intersection2 . type-class-complex-intersection2) - (:simple-= . type-class-simple-=) - (:complex-= . type-class-complex-=) - (:unparse . type-class-unparse))) + ;; KLUDGE: If the slots of TYPE-CLASS ever change in a way not + ;; reflected in *TYPE-CLASS-FUN-SLOTS*, the slots here will + ;; have to be hand-tweaked to match. -- WHN 2001-03-19 + (make-type-class :name (type-class-name x) + . #.(mapcan (lambda (type-class-fun-slot) + (destructuring-bind (keyword . slot-accessor) + type-class-fun-slot + `(,keyword (,slot-accessor x)))) + *type-class-fun-slots*))) -(defun class-function-slot-or-lose (name) - (or (cdr (assoc name *type-class-function-slots*)) +(defun class-fun-slot-or-lose (name) + (or (cdr (assoc name *type-class-fun-slots*)) (error "~S is not a defined type class method." name))) ;;; FIXME: This seems to be called at runtime by cold init code. ;;; Make sure that it's not being called at runtime anywhere but @@ -175,7 +176,7 @@ ,@body) (!cold-init-forms ,@(mapcar (lambda (method) - `(setf (,(class-function-slot-or-lose method) + `(setf (,(class-fun-slot-or-lose method) (type-class-or-lose ',class)) #',name)) (cons method more-methods))) @@ -210,18 +211,18 @@ (complex-arg1 :foo complex-arg1-p)) (declare (type keyword simple complex-arg1 complex-arg2)) `(multiple-value-bind (result-a result-b valid-p) - (%invoke-type-method ',(class-function-slot-or-lose simple) - ',(class-function-slot-or-lose + (%invoke-type-method ',(class-fun-slot-or-lose simple) + ',(class-fun-slot-or-lose (if complex-arg1-p - complex-arg1 - complex-arg2)) - ',(class-function-slot-or-lose complex-arg2) + complex-arg1 + complex-arg2)) + ',(class-fun-slot-or-lose complex-arg2) ,complex-arg1-p ,type1 ,type2) (if valid-p - (values result-a result-b) - ,default))) + (values result-a result-b) + ,default))) ;;; most of the implementation of !INVOKE-TYPE-METHOD ;;; @@ -240,20 +241,48 @@ (let ((class1 (type-class-info type1)) (class2 (type-class-info type2))) (if (eq class1 class2) - (funcall (funcall simple class1) type1 type2) - (let ((complex2 (funcall cslot2 class2))) - (if complex2 - (funcall complex2 type1 type2) - (let ((complex1 (funcall cslot1 class1))) - (if complex1 - (if complex-arg1-p - (funcall complex1 type1 type2) - (funcall complex1 type2 type1)) - ;; No meaningful result was found: the caller should - ;; use the default value instead. - (return-from %invoke-type-method (values nil nil nil)))))))) + (funcall (funcall simple class1) type1 type2) + (let ((complex2 (funcall cslot2 class2))) + (if complex2 + (funcall complex2 type1 type2) + (let ((complex1 (funcall cslot1 class1))) + (if complex1 + (if complex-arg1-p + (funcall complex1 type1 type2) + (funcall complex1 type2 type1)) + ;; No meaningful result was found: the caller + ;; should use the default value instead. + (return-from %invoke-type-method + (values nil nil nil)))))))) ;; If we get to here (without breaking out by calling RETURN-FROM) ;; then a meaningful result was found, and we return it. (values result-a result-b t))) +;;; This is a very specialized implementation of CLOS-style +;;; CALL-NEXT-METHOD within our twisty little type class object +;;; system, which works given that it's called from within a +;;; COMPLEX-SUBTYPEP-ARG2 method. (We're particularly motivated to +;;; implement CALL-NEXT-METHOD in that case, because ANSI imposes some +;;; strict limits on when SUBTYPEP is allowed to return (VALUES NIL NIL), +;;; so instead of just complacently returning (VALUES NIL NIL) from a +;;; COMPLEX-SUBTYPEP-ARG2 method we usually need to CALL-NEXT-METHOD.) +;;; +;;; KLUDGE: In CLOS, this could just be CALL-NEXT-METHOD and +;;; everything would Just Work without us having to think about it. In +;;; our goofy type dispatch system, it's messier to express. It's also +;;; more fragile, since (0) there's no check that it's called from +;;; within a COMPLEX-SUBTYPEP-ARG2 method as it should be, and (1) we +;;; rely on our global knowledge that the next (and only) relevant +;;; method is COMPLEX-SUBTYPEP-ARG1, and (2) we rely on our global +;;; knowledge of the appropriate default for the CSUBTYPEP function +;;; when no next method exists. -- WHN 2002-04-07 +;;; +;;; (We miss CLOS! -- CSR and WHN) +(defun invoke-complex-subtypep-arg1-method (type1 type2) + (let* ((type-class (type-class-info type1)) + (method-fun (type-class-complex-subtypep-arg1 type-class))) + (if method-fun + (funcall (the function method-fun) type1 type2) + (values nil nil)))) + (!defun-from-collected-cold-init-forms !type-class-cold-init)