| blob | eeee7f241780124e4822bff13e8253ea4e793632 |
1 ;;;; This software is part of the SBCL system. See the README file for
2 ;;;; more information.
4 ;;;; This software is derived from software originally released by Xerox
5 ;;;; Corporation. Copyright and release statements follow. Later modifications
6 ;;;; to the software are in the public domain and are provided with
7 ;;;; absolutely no warranty. See the COPYING and CREDITS files for more
8 ;;;; information.
10 ;;;; copyright information from original PCL sources:
11 ;;;;
12 ;;;; Copyright (c) 1985, 1986, 1987, 1988, 1989, 1990 Xerox Corporation.
13 ;;;; All rights reserved.
14 ;;;;
15 ;;;; Use and copying of this software and preparation of derivative works based
16 ;;;; upon this software are permitted. Any distribution of this software or
17 ;;;; derivative works must comply with all applicable United States export
18 ;;;; control laws.
19 ;;;;
20 ;;;; This software is made available AS IS, and Xerox Corporation makes no
21 ;;;; warranty about the software, its performance or its conformity to any
22 ;;;; specification.
25 \f
26 #|
28 The CommonLoops evaluator is meta-circular.
30 Most of the code in PCL is methods on generic functions, including
31 most of the code that actually implements generic functions and method
32 lookup.
34 So, we have a classic bootstrapping problem. The solution to this is
35 to first get a cheap implementation of generic functions running,
36 these are called early generic functions. These early generic
37 functions and the corresponding early methods and early method lookup
38 are used to get enough of the system running that it is possible to
39 create real generic functions and methods and implement real method
41 !FIX-EARLY-GENERIC-FUNCTIONS is called to convert all the early generic
42 functions to real generic functions.
44 The cheap generic functions are built using the same
45 FUNCALLABLE-INSTANCE objects that real generic functions are made out of.
46 This means that as PCL is being bootstrapped, the cheap generic
47 function objects which are being created are the same objects which
48 will later be real generic functions. This is good because:
50 - we can keep pointers to the cheap generic function objects
51 during booting because those pointers will still point to
52 the right object after the generic functions are all fixed up.
54 This file defines the DEFMETHOD macro and the mechanism used to expand
55 it. This includes the mechanism for processing the body of a method.
56 DEFMETHOD basically expands into a call to LOAD-DEFMETHOD, which
57 basically calls ADD-METHOD to add the method to the generic function.
58 These expansions can be loaded either during bootstrapping or when PCL
59 is fully up and running.
61 An important effect of this arrangement is it means we can compile
62 files with DEFMETHOD forms in them in a completely running PCL, but
63 then load those files back in during bootstrapping. This makes
64 development easier. It also means there is only one set of code for
65 processing DEFMETHOD. Bootstrapping works by being sure to have
66 LOAD-METHOD be careful to call only primitives which work during
67 bootstrapping.
69 |#
72 ensure-generic-function-using-class
73 add-method remove-method))
79 ;;; For each of the early functions, arrange to have it point to its
80 ;;; early definition. Do this in a way that makes sure that if we
81 ;;; redefine one of the early definitions the redefinition will take
82 ;;; effect. This makes development easier.
89 name))))
91 ;;; *!GENERIC-FUNCTION-FIXUPS* is used by !FIX-EARLY-GENERIC-FUNCTIONS
92 ;;; to convert the few functions in the bootstrap which are supposed
93 ;;; to be generic functions but can't be early on.
94 ;;;
95 ;;; each entry is a list of the form
96 ;;;
97 ;;; (GENERIC-FUNCTION-NAME METHOD-COMBINATION-NAME METHODS)
98 ;;;
99 ;;; where methods is a list of lists of the form
100 ;;;
101 ;;; (LAMBDA-LIST SPECIALIZERS QUALIFIERS METHOD-BODY-FUNCTION-NAME)
102 ;;;
103 ;;;,where SPECIALIZERS is a list of class names.
106 standard
109 ()
110 real-add-method))
113 standard
116 ()
117 real-remove-method))
120 standard
123 ()
124 real-get-method))
127 standard
129 &key generic-function-class environment
132 ()
133 real-ensure-gf-using-class--generic-function)
135 &key generic-function-class environment
138 ()
139 real-ensure-gf-using-class--null))
142 standard
145 ()
146 real-make-method-lambda))
149 standard
151 lambda-expression environment)
153 ()
154 real-make-method-lambda-using-specializers))
157 standard
160 ()
161 real-make-method-specializers-form))
164 or
183 standard
186 ()
190 ()
194 ()
198 ()
202 ()
206 ()
210 ()
214 ()
218 standard
221 ()
222 real-parse-specializer-using-class))
225 standard
228 ()
229 real-unparse-specializer-using-class))
232 standard
234 lambda-expression
235 lambda-list environment)
237 ()
238 real-make-method-initargs-form))
241 standard
244 ()
245 standard-compute-effective-method)
248 ()
249 short-compute-effective-method))))
250 \f
281 DEFGENERIC: ~S~:@>"
284 ;; FIXME: this list is slightly weird.
285 ;; ANSI (on the DEFGENERIC page) in one
286 ;; place allows only OPTIMIZE; in
287 ;; another place gives this list of
288 ;; disallowed declaration specifiers.
289 ;; This seems to be the only place where
290 ;; the FUNCTION declaration is
291 ;; mentioned; TYPE seems to be missing.
292 ;; Very strange. -- CSR, 2002-10-21
294 inline notinline special))
297 is not allowed inside DEFGENERIC."
303 spec))))
304 (:method-combination
310 symbol: ~S"
314 (:argument-precedence-order
320 :ARGUMENT-PRECEDENCE-ORDER clause."
325 :ARGUMENT-PRECEDENCE-ORDER clause: ~
326 ~S and ~S"
336 (:method
339 ;; ANSI requires that unsupported things must get a
340 ;; PROGRAM-ERROR.
362 ;; Hmm. This is similar to BECOME-DEFINED-FUN-NAME
363 ;; except that it doesn't clear an :ASSUMED-TYPE. Should it?
371 :name fun-name
379 fun-name
380 :lambda-list lambda-list
381 :definition-source source-location
382 initargs))
386 ()
391 :format-control format-control
400 lambda-list
405 :context context
407 ;; PARSE-LAMBDA-LIST validates the skeleton, so just check for
408 ;; incorrect use of defaults.
411 "~@<Invalid ~A argument specifier ~S ~_in ~A ~:S~:>"
412 kind arg context lambda-list))
419 ;; no defaults or supplied-p vars allowed for &OPTIONAL or &KEY
426 ~/sb-ext:print-symbol-with-prefix/, ~S, is not a lambda ~
427 form.~@:>"
428 context method-lambda))
429 method-lambda)
430 \f
433 ;;; As per CLHS -
434 ;;; "defmethod is not required to perform any compile-time side effects."
435 ;;; and we don't do much other than to make the function be defined,
436 ;;; which means that checking of callers' arglists can only occur after called
437 ;;; methods are actually loaded.
443 ;; :compile-toplevel is needed for subsequent forms
444 ;; :execute is needed for references to itself inside the body
446 ;; KLUDGE: this double expansion is quite a monumental
447 ;; workaround: it comes about because of a fantastic interaction
448 ;; between the processing rules of CLHS 3.2.3.1 and the
449 ;; bizarreness of MAKE-METHOD-LAMBDA.
450 ;;
451 ;; MAKE-METHOD-LAMBDA can be called by the user, and if the
452 ;; lambda itself doesn't refer to outside bindings the return
453 ;; value must be compileable in the null lexical environment.
454 ;; However, the function must also refer somehow to the
455 ;; associated method object, so that it can call NO-NEXT-METHOD
456 ;; with the appropriate arguments if there is no next method --
457 ;; but when the function is generated, the method object doesn't
458 ;; exist yet.
459 ;;
460 ;; In order to resolve this issue, we insert a literal cons cell
461 ;; into the body of the method lambda, return the same cons cell
462 ;; as part of the second (initargs) return value of
463 ;; MAKE-METHOD-LAMBDA, and a method on INITIALIZE-INSTANCE fills
464 ;; in the cell when the method is created. However, this
465 ;; strategy depends on having a fresh cons cell for every method
466 ;; lambda, which (without the workaround below) is skewered by
467 ;; the processing in CLHS 3.2.3.1, which permits implementations
468 ;; to macroexpand the bodies of EVAL-WHEN forms with both
469 ;; :COMPILE-TOPLEVEL and :LOAD-TOPLEVEL only once. The
470 ;; expansion below forces the double expansion in those cases,
471 ;; while expanding only once in the common case.
482 lambda-list body env)))
498 ;;; Take a name which is either a generic function name or a list specifying
499 ;;; a SETF generic function (like: (SETF <generic-function-name>)). Return
500 ;;; the prototype instance of the method-class for that generic function.
501 ;;;
502 ;;; If there is no generic function by that name, this returns the
503 ;;; default value, the prototype instance of the class
504 ;;; STANDARD-METHOD. This default value is also returned if the spec
505 ;;; names an ordinary function or even a macro. In effect, this leaves
506 ;;; the signalling of the appropriate error until load time.
507 ;;;
508 ;;; Note: During bootstrapping, this function is allowed to return NIL.
515 ; error at load time.
520 \f
521 ;;; These are used to communicate the method name and lambda-list to
522 ;;; MAKE-METHOD-LAMBDA-INTERNAL.
527 body env)
529 ;; don't care to figure out what parts of PCL would have
530 ;; to change to accept that, so coerce.
539 proto-gf proto-method qualifiers specializers method-lambda env))
542 proto-gf proto-method method-function-lambda initargs env))
545 proto-gf proto-method specializers env)))
550 specializers lambda-list)
551 ;; Note: We could DECLAIM the ftype of the generic function here,
552 ;; since ANSI specifies that we create it if it does not
553 ;; exist. However, I chose not to, because I think it's more
554 ;; useful to support a style of programming where every generic
555 ;; function has an explicit DEFGENERIC and any typos in DEFMETHODs
556 ;; are warned about. Otherwise
557 ;;
558 ;; (DEFGENERIC FOO-BAR-BLETCH (X))
559 ;; (DEFMETHOD FOO-BAR-BLETCH ((X HASH-TABLE)) ..)
560 ;; (DEFMETHOD FOO-BRA-BLETCH ((X SIMPLE-VECTOR)) ..)
561 ;; (DEFMETHOD FOO-BAR-BLETCH ((X VECTOR)) ..)
562 ;; (DEFMETHOD FOO-BAR-BLETCH ((X ARRAY)) ..)
563 ;; (DEFMETHOD FOO-BAR-BLETCH ((X LIST)) ..)
564 ;;
565 ;; compiles without raising an error and runs without raising an
566 ;; error (since SIMPLE-VECTOR cases fall through to VECTOR) but
567 ;; still doesn't do what was intended. I hate that kind of bug
568 ;; (code which silently gives the wrong answer), so we don't do a
569 ;; DECLAIM here. -- WHN 20000229
575 initargs-form)))
582 method-class-name initargs-form)
585 fn-lambda)
598 specializers)
609 ;; CONSTANT-FORM-VALUE? What I
610 ;; kind of want to know, though,
611 ;; is what happens if we don't do
612 ;; this for some slow-method
613 ;; function because of a hairy
614 ;; lexenv -- is the only bad
615 ;; effect that the method
616 ;; function ends up unnamed? If
617 ;; so, couldn't we arrange to
618 ;; name it later?
620 specl))
621 specializers))
629 name qualifiers `',specls
630 unspecialized-lambda-list method-class-name
632 #',mname
635 name qualifiers
636 specializers
637 #+nil
643 specializers))
644 unspecialized-lambda-list
645 method-class-name
646 initargs-form))))
650 method-class-name initargs-form)
652 ',method-class-name
653 ',name
654 ',qualifiers
655 ,specializers-form
656 ',unspecialized-lambda-list
657 ,initargs-form
666 proto-gf proto-method method-function-lambda initargs env)))
669 method-lambda initargs env)
681 (check-method-lambda method-lambda 'make-method-lambda) ; TODO remove check in make-method-lambda
682 ;; Default behavior: delegate to MAKE-METHOD-LAMBDA.
694 ;;; When bootstrapping PCL MAKE-METHOD-LAMBDA starts out as a regular
695 ;;; function: REAL-MAKE-METHOD-LAMBDA set to the fdefinition of
696 ;;; MAKE-METHOD-LAMBDA. Once generic functions are born,
697 ;;; REAL-MAKE-METHOD-LAMBDA is used to implement the default method.
698 ;;; MAKE-METHOD-LAMBDA-INTERNAL is split out into a separate function
699 ;;; so that changing it in a live image is easy, and changes actually
700 ;;; take effect.
714 ;;; A helper function for creating Python-friendly type declarations
715 ;;; in DEFMETHOD forms.
716 ;;;
717 ;;; This function operates on
718 ;;; * non-parsed specializers, i.e. class names and extended
719 ;;; specializer syntaxes
720 ;;; * parsed specializers, i.e. CLASSes, EQL-SPECIALIZERs,
721 ;;; CLASS-EQ-SPECIALIZERs and generic SPECIALIZERs
722 ;;;
723 ;;; We're too lazy to cons up a new environment for this, so we just
724 ;;; pass in the list of locally declared specials in addition to the
725 ;;; old environment.
735 ;; KLUDGE: PCL, in its wisdom, sometimes calls methods with
736 ;; types which don't match their specializers. (Specifically,
737 ;; it calls ENSURE-CLASS-USING-CLASS (T NULL) with a non-NULL
738 ;; second argument.) Hopefully it only does this kind of
739 ;; weirdness when bootstrapping.. -- WHN 20000610
742 ;; Independent of SPECIALIZER, bail out if the PARAMETER is
743 ;; known to be a special variable. Our rebinding magic for SETQ
744 ;; cases doesn't work right there as SET, (SETF SYMBOL-VALUE),
745 ;; etc. make things undecidable.
749 ;; Bail out on SLOT-OBJECT special case.
750 ;;
751 ;; KLUDGE: For some low-level implementation classes, perhaps
752 ;; because of some problems related to the incomplete
753 ;; integration of PCL into SBCL's type system, some specializer
754 ;; classes can't be declared as argument types. E.g.
755 ;; (DEFMETHOD FOO ((X SLOT-OBJECT))
756 ;; (DECLARE (TYPE SLOT-OBJECT X))
757 ;; ..)
758 ;; loses when
759 ;; (DEFSTRUCT BAR A B)
760 ;; (FOO (MAKE-BAR))
761 ;; perhaps because of the way that STRUCTURE-OBJECT inherits
762 ;; both from SLOT-OBJECT and from SB-KERNEL:INSTANCE. In an
763 ;; effort to sweep such problems under the rug, we exclude these
764 ;; problem cases by blacklisting them here. -- WHN 2001-01-19
768 ;; Bail out on unparsed EQL-specializers.
769 ;;
770 ;; KLUDGE: ANSI, in its wisdom, says that EQL-SPECIALIZER-FORMs
771 ;; in EQL specializers are evaluated at DEFMETHOD expansion
772 ;; time. Thus, although one might think that in
773 ;; (DEFMETHOD FOO ((X PACKAGE)
774 ;; (Y (EQL 12))
775 ;; ..))
776 ;; the PACKAGE and (EQL 12) forms are both parallel type names,
777 ;; they're not, as is made clear when you do
778 ;; (DEFMETHOD FOO ((X PACKAGE)
779 ;; (Y (EQL 'BAR)))
780 ;; ..)
781 ;; where Y needs to be a symbol named "BAR", not some cons made
782 ;; by (CONS 'QUOTE 'BAR). I.e. when the EQL-SPECIALIZER-FORM is
783 ;; (EQL 'X), it requires an argument to be of type (EQL X). It'd
784 ;; be easy to transform one to the other, but it'd be somewhat
785 ;; messier to do so while ensuring that the EQL-SPECIALIZER-FORM
786 ;; is only EVAL'd once. (The new code wouldn't be messy, but
787 ;; it'd require a big transformation of the old code.) So
788 ;; instead we punt. -- WHN 20000610
792 ;; Parsed specializer objects, i.e. CLASS, EQL-SPECIALIZER,
793 ;; CLASS-EQ-SPECIALIZER and generic SPECIALIZER.
794 ;;
795 ;; Also unparsed specializers other than EQL: these have to be
796 ;; either class names or extended specializers.
797 ;;
798 ;; For these, we can usually make Python very happy.
799 ;;
800 ;; KLUDGE: Since INFO doesn't work right for class objects here,
801 ;; and they are valid specializers, see if the specializer is
802 ;; a named class, and use the name in that case -- otherwise
803 ;; the class instance is ok, since info will just return NIL, NIL.
804 ;;
805 ;; We still need to deal with the class case too, but at
806 ;; least #.(find-class 'integer) and integer as equivalent
807 ;; specializers with this.
810 proto-generic-function proto-method specializer))))))
817 ;; We have the %METHOD-NAME declaration in the place
818 ;; where we expect it only if there is are no
819 ;; non-standard prior MAKE-METHOD-LAMBDA methods -- or
820 ;; unless they're fantastically unintrusive.
823 ;; Macroexpansion caused by code-walking may call
824 ;; make-method-lambda and end up with wrong values
828 ;; the method-cell is a way of communicating what method
829 ;; a method-function implements, for the purpose of
830 ;; NO-NEXT-METHOD. We need something that can be shared
831 ;; between function and initargs, but not something that
832 ;; will be coalesced as a constant (because we are
833 ;; naughty, oh yes) with the expansion of any other
834 ;; methods in the same file. -- CSR, 2007-05-30
846 ;; These declarations seem to be used by PCL to pass
847 ;; information to itself; when I tried to delete 'em
848 ;; ca. 0.6.10 it didn't work. I'm not sure how they
849 ;; work, but note the (VAR-DECLARATION '%CLASS ..)
850 ;; expression in CAN-OPTIMIZE-ACCESS1. -- WHN
851 ;; 2000-12-30
855 parameters specializers)
856 ;; These TYPE declarations weren't in the original PCL
857 ;; code, but the Python compiler likes them a
858 ;; lot. (We're telling the compiler about our
859 ;; knowledge of specialized argument types so that it
860 ;; can avoid run-time type dispatch overhead, which
861 ;; can be a huge win for Python.)
865 proto-gf proto-method par spec specials env))
866 parameters specializers))))
868 ;; Remove the documentation string and insert the
869 ;; appropriate class declarations. The documentation
870 ;; string is removed to make it easy for us to insert
871 ;; new declarations later, they will just go after the
872 ;; CADR of the method lambda. The class declarations
873 ;; are inserted to communicate the class of the method's
874 ;; arguments to the code walk.
876 ;; The default ignorability of method parameters
877 ;; doesn't seem to be specified by ANSI. PCL had
878 ;; them basically ignorable but was a little
879 ;; inconsistent. E.g. even though the two
880 ;; method definitions
881 ;; (DEFMETHOD FOO ((X T) (Y T)) "Z")
882 ;; (DEFMETHOD FOO ((X T) Y) "Z")
883 ;; are otherwise equivalent, PCL treated Y as
884 ;; ignorable in the first definition but not in the
885 ;; second definition. We make all required
886 ;; parameters ignorable as a way of systematizing
887 ;; the old PCL behavior. -- WHN 2000-11-24
889 ,class-declarations
890 ,@declarations
909 method-lambda required-parameters env slots))
918 walked-lambda-body
920 ,slot-name-lists
930 aux))))
933 (,lambda-list .method-args. .next-methods.
934 :call-next-method-p
940 ,@walked-declarations
942 %parameter-binding-modified))
946 %parameter-binding-modified))
958 proto-generic-function proto-method name environment)))
969 :format-control
970 "~@<~S is not a valid parameter specializer name.~@:>"
979 specializer-name))
989 ;; In case of unknown specializer or known specializer with syntax
990 ;; error, TYPECASE may fall through to default method with error
991 ;; signaling.
1008 `(,type
1009 (,function-name
1010 proto-generic-function proto-method specializer-name environment))))
1012 ; ^ apparently not needed during bootstrapping
1013 symbol cons t)))))
1023 ;; TODO later protocol-unimplemented-error?
1026 nil)
1030 "~@<Cannot parse specializer ~S in ~S~@[: ~A~].~@:>"
1034 :format-control
1035 "~@<Cannot find type for specializer ~
1036 ~/sb-ext:print-symbol-with-prefix/ when executing ~S ~
1037 for a ~/sb-ext:print-type-specifier/ of a ~
1038 ~/sb-ext:print-type-specifier/.~@:>"
1039 :format-arguments
1047 (:primitive
1049 name
1051 name proto-generic-function proto-method)))
1052 (:defined
1053 ;; This can happen if NAME is a DEFTYPE.
1055 name proto-generic-function proto-method))
1057 ;; CLOS classes are too expensive to check (as opposed
1058 ;; to STRUCTURE-CLASS and SYSTEM-CLASS).
1059 nil)
1061 ;; TODO proper warning condition?
1063 name proto-generic-function proto-method)
1064 nil)))))
1066 ;;; Non-parsed class specializers, i.e. class names
1067 ;;;
1068 ;;; Extended generic function classes with specializers which are
1069 ;;; designated by symbols have to install their own methods
1070 ;;; specialized on symbol to replace this logic.
1076 ;; Usually tries to find the class named
1077 ;; SPECIALIZER. Can do something different when there
1078 ;; is a non-default method on
1079 ;; PARSE-SPECIALIZER-USING-CLASS.
1081 proto-generic-function specializer)
1083 ;; SPECIALIZER does not name a class, but maybe it is
1084 ;; known to name a :forthcoming-defclass-type.
1085 ;; CLASS-NAME-TYPE-SPECIFIER will emit the warning and
1086 ;; return nil if not.
1088 specializer proto-generic-function proto-method nil))
1090 ;; This can only happen if there is an EQL-specialized
1091 ;; method on PARSE-SPECIALIZER-USING-CLASS matching
1092 ;; SPECIALIZER that signals an error.
1094 nil))))
1097 proto-generic-function proto-method specializer))))
1099 ;;; Non-parsed extended specializer with default syntax
1100 ;;; i.e. (SPECIALIZER-KIND &rest SPECIFIC-SYNTAX)
1107 proto-generic-function specializer)
1109 ;; This can happen, for example, if SPECIALIZER does
1110 ;; not designate any extended specializer or if it does
1111 ;; but then does not conform to the respective extended
1112 ;; specializer syntax.
1114 nil))))
1117 proto-generic-function proto-method specializer))))
1119 ;;; Parsed EQL and CLASS-EQ specializers
1131 ;;; Parsed class specializers
1146 ;; Make sure SPECIALIZER has a proper class name and that name
1147 ;; designates the class SPECIALIZER in the global environment.
1151 name proto-generic-function proto-method)))))
1163 `(,type
1164 (,function-name
1165 proto-generic-function proto-method specializer))))
1167 structure-class system-class class)))))
1177 result
1179 specializer generic-function))))
1187 ;; FIXME: this HANDLER-CASE is a bit of a hammer to crack a nut:
1188 ;; the idea is that we want to unparse permissively, so that the
1189 ;; lazy (or rather the "portable") specializer extender (who
1190 ;; does not define methods on these new SBCL-specific MOP
1191 ;; functions) can still subclass specializer and define methods
1192 ;; without everything going wrong. Making it cleaner and
1193 ;; clearer that that is what we are defending against would be
1194 ;; nice. -- CSR, 2007-06-01
1201 class-name
1202 type))
1203 type))
1206 specializer generic-function)))
1212 ;;; For passing a list (groveled by the walker) of the required
1213 ;;; parameters whose bindings are modified in the method body to the
1214 ;;; optimized-slot-value* macros.
1218 method-args
1219 next-methods
1230 next-method-call
1231 args
1232 rest-arg
1241 parameters-setqd applyp method-cell))
1242 &body body
1246 ;; always provide the lexical function NEXT-METHOD-P.
1247 ;; I would think this to be a good candidate for declaring INLINE
1248 ;; but that's not the way it was done before.
1259 `((%check-cnm-args cnm-args
1260 ,method-args
1262 nil)
1270 ',method-cell
1279 ;; Can't easily provide a RETRY restart here, as the return value here is
1280 ;; for the method, not the generic function.
1282 method args)))
1300 call-method-args)
1302 value)
1323 pv
1324 next-method-call
1325 arg-info)
1328 value)
1332 ;; The two variants of INVOKE-FAST-METHOD-CALL differ in how REST-ARGs
1333 ;; are handled. The first one will get REST-ARG as a single list (as
1334 ;; the last argument), and will thus need to use APPLY. The second one
1335 ;; will get them as a &MORE argument, so we can pass the arguments
1336 ;; directly with MULTIPLE-VALUE-CALL and %MORE-ARG-VALUES.
1345 more-context
1346 more-count
1352 ,@required-args
1355 ;; The cases with only small amounts of required arguments passed
1356 ;; are probably very common, and special-casing speeds them up by
1357 ;; a factor of 2 with very little effect on the other
1358 ;; cases. Though it'd be nice to have the generic case be equally
1359 ;; fast.
1366 ,@required-args
1377 \f
1378 ;;;; effective method functions
1384 ;;; This function was in the CMU CL version of PCL (ca Debian 2.4.8)
1385 ;;; without explanation. It appears to be intended for debugging, so
1386 ;;; it might be useful someday, so I haven't deleted it.
1387 ;;; But it isn't documented and isn't used for anything now, so
1388 ;;; I've conditionalized it out of the base system. -- WHN 19991213
1389 #+sb-show
1422 ,@more-arg
1425 ,restp
1426 ,@required-args
1431 ;; "What," you may wonder, "do these next two clauses do?" In that
1432 ;; case, you are not a PCL implementor, for they considered this to
1433 ;; be self-documenting.:-| Or CSR, for that matter, since he can
1434 ;; also figure it out by looking at it without breaking stride. For
1435 ;; the rest of us, though: From what the code is doing with .SLOTS.
1436 ;; and whatnot, evidently it's implementing SLOT-VALUEish and
1437 ;; GET-SLOT-VALUEish things. Then we can reason backwards and
1438 ;; conclude that setting EMF to a FIXNUM is an optimized way to
1439 ;; represent these slot access operations.
1450 value)))))
1458 ;; (In cmucl-2.4.8 there was a commented-out third ,@(WHEN
1459 ;; ...) clause here to handle SLOT-BOUNDish stuff. Since
1460 ;; there was no explanation and presumably the code is 10+
1461 ;; years stale, I simply deleted it. -- WHN)
1462 )))
1464 ;;; Before SBCL 0.9.16.7 instead of
1465 ;;; INVOKE-NARROW-EFFECTIVE-METHOD-FUNCTION we passed a (THE (OR
1466 ;;; FUNCTION METHOD-CALL FAST-METHOD-CALL) EMF) form as the EMF. Now,
1467 ;;; to make less work for the compiler we take a path that doesn't
1468 ;;; involve the slot-accessor clause (where EMF is a FIXNUM) at all.
1483 ,@more-arg
1486 ,restp
1487 ,@required-args
1491 emf-n restp required-args))
1514 args)
1537 args))))))
1540 args
1552 value)))
1569 \f
1572 method-cell
1573 cnm-args)
1576 ,next-method-call
1588 ,@args
1594 call-next-method-p
1595 setq-p
1596 parameters-setqd
1597 method-cell
1598 applyp))
1599 &body body
1619 nil)
1621 ,next-method-call
1623 ,method-cell
1624 cnm-args))))
1630 ;;; CMUCL comment (Gerd Moellmann):
1631 ;;;
1632 ;;; The standard says it's an error if CALL-NEXT-METHOD is called with
1633 ;;; arguments, and the set of methods applicable to those arguments is
1634 ;;; different from the set of methods applicable to the original
1635 ;;; method arguments. (According to Barry Margolin, this rule was
1636 ;;; probably added to ensure that before and around methods are always
1637 ;;; run before primary methods.)
1638 ;;;
1639 ;;; This could be optimized for the case that the generic function
1640 ;;; doesn't have hairy methods, does have standard method combination,
1641 ;;; is a standard generic function, there are no methods defined on it
1642 ;;; for COMPUTE-APPLICABLE-METHODS and probably a lot more of such
1643 ;;; preconditions. That looks hairy and is probably not worth it,
1644 ;;; because this check will never be fast.
1646 ;; 1. Check for no arguments.
1651 ;; 2. Requirement arguments pairwise: if all are EQL, the applicable
1652 ;; methods must be the same. This takes care of the relatively common
1653 ;; case of twiddling with &KEY arguments without being horribly
1654 ;; expensive.
1661 ;; 3. Only then do the full check.
1666 ~{~S~^, ~} to call-next-method is different from ~
1667 the set of methods ~S applicable to the original ~
1668 method argument~P ~{~S~^, ~}.~@:>"
1672 ;; FIXME: replacing this entire mess with DESTRUCTURING-BIND would correct
1673 ;; problems similar to those already solved by a correct implementation
1674 ;; of DESTRUCTURING-BIND, such as incorrect binding order:
1675 ;; e.g. (macroexpand-1 '(bind-args ((&optional (x nil xsp)) args) (form)))
1676 ;; -> (LET* ((.ARGS-TAIL. ARGS) (XSP (NOT (NULL .ARGS-TAIL.))) (X ...)))
1677 ;; It's mostly irrelevant unless a method uses CALL-NEXT-METHOD though.
1693 "encountered the non-standard lambda list keyword ~S"
1694 var)))
1695 nil)
1743 ,@bindings
1744 (.dummy0.
1756 ;; FIXME: Do we want to export this symbol? Or maybe use an
1757 ;; (ERROR 'SIMPLE-PROGRAM-ERROR) form?
1760 return tail))
1764 ;; method definition
1766 ;; a list of all required parameters whose bindings might be
1767 ;; modified in the method body.
1774 ;; hierarchy: nil -> :simple -> T.
1777 form)
1779 ;; The walker will split (SETQ A 1 B 2) to
1780 ;; separate (SETQ A 1) and (SETQ B 2) forms, so we
1781 ;; only need to handle the simple case of SETQ
1782 ;; here.
1787 ;; Note that we don't need to check for
1788 ;; %VARIABLE-REBINDING declarations like is
1789 ;; done in CAN-OPTIMIZE-ACCESS1, since the
1790 ;; bindings that will have that declation will
1791 ;; never be SETQd.
1793 ;; If a parameter binding is shadowed by
1794 ;; another binding it won't have a %CLASS
1795 ;; declaration anymore, and this won't get
1796 ;; executed.
1798 form)
1802 form)
1810 form))
1814 ;;; FIXME: the walker's rewriting of the source code causes
1815 ;;; trouble when doing code coverage. The rewrites should be
1816 ;;; removed, and the same operations done using
1817 ;;; compiler-macros or tranforms.
1819 walked-lambda
1820 method-lambda)
1821 call-next-method-p
1823 parameters-setqd)))))
1831 \f
1841 new-value)
1843 \f
1849 #+nil
1853 ll initargs source-location)))
1857 initargs source-location)
1866 :name gf-spec
1867 :new-location source-location
1868 :old-method method
1871 gf-spec qualifiers specializers lambda-list
1872 :definition-source source-location
1873 initargs)))
1876 ;; FIXME: should be STYLE-WARNING?
1878 "~&At the time the method with qualifiers ~:S and~%~
1879 specializers ~:S on the generic function ~S~%~
1880 was compiled, the method-class for that generic function was~%~
1881 ~S. But, the method class is now ~S, this~%~
1882 may mean that this method was compiled improperly.~%"
1883 qualifiers specializers gf-spec
1885 method))
1913 \f
1916 ;; We say "&MUMBLE is not allowed in a generic function lambda list"
1917 ;; whether this is called by DEFMETHOD or DEFGENERIC.
1918 ;; [It is used for either. Why else recognize and silently ignore &AUX?]
1922 :silent t
1928 ;; FIXME: this does more than return an FTYPE from a lambda list -
1929 ;; it unions the type with an existing ctype object. It needs a better name,
1930 ;; and to be reimplemented as "union and call sb-c::ftype-from-lambda-list".
1941 old-ftype))))
1956 keywords)
1959 *))))
1960 \f
1961 ;;;; early generic function support
1965 ;; CLHS doesn't specify &allow-other-keys here but I guess the supposition
1966 ;; is that they'll be checked by ENSURE-GENERIC-FUNCTION-USING-CLASS.
1967 ;; Except we don't do that either, so I think the blame, if any, lies there
1968 ;; for not catching errant keywords.
1980 existing fun-name all-keys)))))
1984 'simple-program-error
1986 already names an ordinary function or a ~
1987 macro.~@:>"
2036 arg-info-precedence
2037 arg-info-metatypes
2038 arg-info-number-optional
2039 arg-info-key/rest-p
2040 arg-info-keys ;nil no &KEY or &REST allowed
2041 ;(k1 k2 ..) Each method must accept these &KEY arguments.
2042 ;T must have &KEY or &REST
2044 gf-info-simple-accessor-type ; nil, reader, writer, boundp
2047 gf-info-static-c-a-m-emf
2049 gf-info-fast-mf-p)
2067 ;;; Create a gf lambda list from a method lambda list
2080 argument-precedence-order)
2105 existing methods of ~S.~%~
2106 Old lambda-list ~s"
2113 lambda-list
2129 arg-info))
2139 to the generic function~2I~_~S;~I~_~
2140 but ~?~:>"
2150 "the method has ~A required arguments than the generic function."
2154 "the method has ~A optional arguments than the generic function."
2158 "the method and generic function differ in whether they accept~_~
2165 ~S."
2166 gf-keywords)))))))
2175 ;;; FIXME: we don't actually need this; we could test for the exact
2176 ;;; class and deal with it as appropriate. In fact we probably don't
2177 ;;; need it anyway because we only use this for METHOD-SPECIALIZERS on
2178 ;;; the standard reader method for METHOD-SPECIALIZERS. Probably.
2190 standard-writer-method standard-boundp-method
2191 global-reader-method global-writer-method
2192 global-boundp-method)
2223 nil)))
2271 nil)
2277 ;; FIXME: this test will eventually be
2278 ;; superseded by the *internal-pcl...* test,
2279 ;; above. While we are in a process of
2280 ;; transition, however, it should probably
2281 ;; remain.
2287 #'make-method-lambda
2298 arg-info)
2300 ;;; This is the early definition of ENSURE-GENERIC-FUNCTION-USING-CLASS.
2301 ;;;
2302 ;;; The STATIC-SLOTS field of the funcallable instances used as early
2303 ;;; generic functions is used to store the early methods and early
2304 ;;; discriminator code for the early generic function. The static
2305 ;;; slots field of the fins contains a list whose:
2306 ;;; CAR - a list of the early methods on this early gf
2307 ;;; CADR - the early discriminator code for this method
2310 lambda-list-p)
2311 argument-precedence-order
2312 definition-source
2313 documentation
2319 existing)
2323 argument-precedence-order definition-source
2324 documentation)
2332 argument-precedence-order definition-source
2333 documentation))))
2336 function argument-precedence-order source-location
2337 documentation)
2357 :lambda-list lambda-list
2360 fin))
2370 new-value)
2376 dfun)))
2379 ;; Check that we are under the lock.
2380 #+sb-thread
2385 new-state))))
2386 dfun)
2421 nil)
2431 ;; Use the existing lambda-list, if any. It is reasonable to do eg.
2432 ;;
2433 ;; (if (fboundp name)
2434 ;; (ensure-generic-function name)
2435 ;; (ensure-generic-function name :lambda-list '(foo)))
2436 ;;
2437 ;; in which case we end up here with no lambda-list in the first leg.
2441 t)
2450 ;; FIXME: Ideally we would like to not clobber it, but because generic
2451 ;; functions assert their FTYPEs callers believing the FTYPE are left with
2452 ;; unsafe assumptions. Hence the clobbering. Be quiet when the new type
2453 ;; is a subtype of the old one, though -- even though the type is not
2454 ;; trusted anymore, the warning is still not quite as interesting.
2458 ~/sb-ext:print-symbol-with-prefix/ clobbers an ~
2459 earlier ~S proclamation ~/sb-ext:print-type/ for ~
2460 the same name with ~/sb-ext:print-type/.~:@>"
2464 fun-name))
2470 class-or-name)
2473 symbol that names a class.~@:>"
2474 context class-or-name))))
2477 class-or-name environment)))
2479 ;; FIXME: reference MOP documentation -- this is an
2480 ;; additional requirement on our users
2482 finalizeable~@:>"
2483 class)
2486 environment
2491 generic-function-class environment)))
2496 (:method-combination
2498 key
2505 value))))
2506 (:method-class
2508 value environment)))
2535 \f
2542 ;;; FIXME: this function took on a slightly greater role than it
2543 ;;; previously had around 2005-11-02, when CSR fixed the bug whereby
2544 ;;; having more than one subclass of standard-generic-function caused
2545 ;;; the whole system to die horribly through a metacircle in
2546 ;;; GF-ARG-INFO. The fix is to be slightly more disciplined about
2547 ;;; calling accessor methods -- we call GET-GENERIC-FUN-INFO when
2548 ;;; computing discriminating functions, so we need to be careful about
2549 ;;; having a base case for the recursion, and we provide that with the
2550 ;;; STANDARD-GENERIC-FUNCTION case below. However, we are not (yet)
2551 ;;; as disciplined as CLISP's CLOS/MOP, and it would be nice to get to
2552 ;;; that stage, where all potentially dangerous cases are enumerated
2553 ;;; and stopped. -- CSR, 2005-11-02.
2555 ;; values nreq applyp metatypes nkeys arg-info
2562 metatypes
2563 arg-info))
2572 nkeys
2573 arg-info))))
2584 &key slot-name object-class method-class-function
2585 definition-source)
2588 ;; Figure out whether we got class objects or class names as the
2589 ;; specializers and set parsed and unparsed appropriately. If we
2590 ;; got class objects, then we can compute unparsed, but if we
2591 ;; got class names we don't try to compute parsed.
2597 specializers))
2608 ;; the parsed specializers. This is used by
2609 ;; EARLY-METHOD-SPECIALIZERS to cache the parse.
2610 ;; Note that this only comes into play when there is
2611 ;; more than one early method on an early gf.
2612 parsed
2614 ;; A list to which REAL-MAKE-A-METHOD can be applied
2615 ;; to make a real method corresponding to this early
2616 ;; one.
2619 initargs doc)
2625 result))
2630 definition-source)
2641 :slot-definition slot-definition
2645 initargs)
2646 :definition-source definition-source
2647 initargs)))
2667 ;;; Fetch the specializers of an early method. This is basically just
2668 ;;; a simple accessor except that when the second argument is t, this
2669 ;;; converts the specializers from symbols into class objects. The
2670 ;;; class objects are cached in the early method, this makes
2671 ;;; bootstrapping faster because the class objects only have to be
2672 ;;; computed once.
2673 ;;;
2674 ;;; NOTE:
2675 ;;; The second argument should only be passed as T by
2676 ;;; early-lookup-method. This is to implement the rule that only when
2677 ;;; there is more than one early method on a generic function is the
2678 ;;; conversion from class names to class objects done. This
2679 ;;; corresponds to the fact that we are only allowed to have one
2680 ;;; method on any generic function up until the time classes exist.
2705 specializers arglist &rest initargs
2706 &key documentation definition-source
2709 ;; argument here because the default,
2710 ;; STANDARD-GENERIC-FUNCTION, is right for all early generic
2711 ;; functions. (See REAL-ADD-NAMED-METHOD)
2721 specializers initargs documentation
2726 ;;; This is the early version of ADD-METHOD. Later this will become a
2727 ;;; generic function. See !FIX-EARLY-GENERIC-FUNCTIONS which has
2728 ;;; special knowledge about ADD-METHOD.
2741 ;;; This is the early version of REMOVE-METHOD. See comments on
2742 ;;; the early version of ADD-METHOD.
2756 ;;; This is the early version of GET-METHOD. See comments on the early
2757 ;;; version of ADD-METHOD.
2763 specializers)
2765 specializers))
2770 nil))
2773 ;; minor KLUDGE: a separate code component for this function allows GCing
2774 ;; a few symbols and their associated code that would otherwise be retained:
2775 ;; *!EARLY-{GENERIC-}FUNCTIONS*, *!GENERIC-FUNCTION-FIXUPS*
2783 ;; Rearrange *!EARLY-GENERIC-FUNCTIONS* to speed up
2784 ;; FIX-EARLY-GENERIC-FUNCTIONS.
2791 generic-function-methods
2792 method-specializers
2793 specializer-type
2794 specializer-class
2795 slot-definition-location
2796 slot-definition-name
2797 class-slots
2798 gf-arg-info
2799 class-precedence-list
2800 slot-boundp-using-class
2802 slot-value-using-class)))
2813 early-method))))
2816 early-method t))
2831 ;; This is lifted from sb-introspect, OAOO and all that.
2850 map)
2864 'standard-method
2865 qualifiers lambda-list specializers initargs nil
2876 \f
2877 ;;; PARSE-DEFMETHOD is used by DEFMETHOD to parse the &REST argument
2878 ;;; into the 'real' arguments. This is where the syntax of DEFMETHOD
2879 ;;; is really implemented.
2901 \f
2905 ;; We don't need these, but according to the unit tests,
2906 ;; they're mandated by AMOP.
2912 ()
2917 :format-control format-control
2920 ;; Return 3 values:
2921 ;; - the bound variables, without defaults, supplied-p vars, or &AUX vars.
2922 ;; - the lambda list without specializers.
2923 ;; - just the specializers
2927 arglist
2936 llks required optional rest key aux nil nil
2940 rest
2941 ;; Preserve keyword-names when given as (:KEYWORD var)
2946 key))
2948 specializers)))
2949 \f
2951 \f
2952 ;;; FIXME: In here there was a #-CMU definition of SYMBOL-MACROLET
2953 ;;; which used %WALKER stuff. That suggests to me that maybe the code
2954 ;;; walker stuff was only used for implementing stuff like that; maybe
2955 ;;; it's not needed any more? Hunt down what it was used for and see.
2961 form context))
2964 form)))
2977 ,in
2985 either a symbol or (variable-name ~
2986 slot-name)"
2987 slot-entry))
2991 `(,var-name
2993 slots)
3001 ,in
3007 be (variable-name accessor-name)"
3008 slot-entry))
3010 slot-entry
3012 slots)