| blob | ed40a6274a071faf180bc7b1be98f85b21b3e4ad |
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 ()
187 real-parse-specializer-using-class))
190 standard
193 ()
194 real-unparse-specializer-using-class))
197 standard
199 lambda-expression
200 lambda-list environment)
202 ()
203 real-make-method-initargs-form))
206 standard
209 ()
210 standard-compute-effective-method)
213 ()
214 short-compute-effective-method))))
215 \f
245 DEFGENERIC: ~S~:@>"
248 ;; FIXME: this list is slightly weird.
249 ;; ANSI (on the DEFGENERIC page) in one
250 ;; place allows only OPTIMIZE; in
251 ;; another place gives this list of
252 ;; disallowed declaration specifiers.
253 ;; This seems to be the only place where
254 ;; the FUNCTION declaration is
255 ;; mentioned; TYPE seems to be missing.
256 ;; Very strange. -- CSR, 2002-10-21
258 inline notinline special))
261 is not allowed inside DEFGENERIC."
267 spec))))
268 (:method-combination
274 symbol: ~S"
278 (:argument-precedence-order
284 :ARGUMENT-PRECEDENCE-ORDER clause."
289 :ARGUMENT-PRECEDENCE-ORDER clause: ~
290 ~S and ~S"
300 (:method
303 ;; ANSI requires that unsupported things must get a
304 ;; PROGRAM-ERROR.
326 ;; Hmm. This is similar to BECOME-DEFINED-FUN-NAME
327 ;; except that it doesn't clear an :ASSUMED-TYPE. Should it?
335 :name fun-name
343 fun-name
344 :lambda-list lambda-list
345 :definition-source source-location
346 initargs))
350 ()
355 ;; PARSE-LAMBDA-LIST validates the skeleton,
356 ;; so just check for incorrect use of defaults.
357 ;; This works for both &OPTIONAL and &KEY.
362 :format-control
363 "~@<invalid ~A argument specifier ~S ~_in the ~
364 generic function lambda list ~S~:>"
368 lambda-list
374 ;; no defaults or supplied-p vars allowed for &OPTIONAL or &KEY
381 ~/sb-impl:print-symbol-with-prefix/, ~S, is not a lambda ~
382 form.~@:>"
383 context method-lambda))
384 method-lambda)
385 \f
388 ;;; As per CLHS -
389 ;;; "defmethod is not required to perform any compile-time side effects."
390 ;;; and we don't do much other than to make the function be defined,
391 ;;; which means that checking of callers' arglists can only occur after called
392 ;;; methods are actually loaded.
398 ;; :compile-toplevel is needed for subsequent forms
399 ;; :execute is needed for references to itself inside the body
401 ;; KLUDGE: this double expansion is quite a monumental
402 ;; workaround: it comes about because of a fantastic interaction
403 ;; between the processing rules of CLHS 3.2.3.1 and the
404 ;; bizarreness of MAKE-METHOD-LAMBDA.
405 ;;
406 ;; MAKE-METHOD-LAMBDA can be called by the user, and if the
407 ;; lambda itself doesn't refer to outside bindings the return
408 ;; value must be compileable in the null lexical environment.
409 ;; However, the function must also refer somehow to the
410 ;; associated method object, so that it can call NO-NEXT-METHOD
411 ;; with the appropriate arguments if there is no next method --
412 ;; but when the function is generated, the method object doesn't
413 ;; exist yet.
414 ;;
415 ;; In order to resolve this issue, we insert a literal cons cell
416 ;; into the body of the method lambda, return the same cons cell
417 ;; as part of the second (initargs) return value of
418 ;; MAKE-METHOD-LAMBDA, and a method on INITIALIZE-INSTANCE fills
419 ;; in the cell when the method is created. However, this
420 ;; strategy depends on having a fresh cons cell for every method
421 ;; lambda, which (without the workaround below) is skewered by
422 ;; the processing in CLHS 3.2.3.1, which permits implementations
423 ;; to macroexpand the bodies of EVAL-WHEN forms with both
424 ;; :COMPILE-TOPLEVEL and :LOAD-TOPLEVEL only once. The
425 ;; expansion below forces the double expansion in those cases,
426 ;; while expanding only once in the common case.
437 lambda-list body env)))
453 ;;; Take a name which is either a generic function name or a list specifying
454 ;;; a SETF generic function (like: (SETF <generic-function-name>)). Return
455 ;;; the prototype instance of the method-class for that generic function.
456 ;;;
457 ;;; If there is no generic function by that name, this returns the
458 ;;; default value, the prototype instance of the class
459 ;;; STANDARD-METHOD. This default value is also returned if the spec
460 ;;; names an ordinary function or even a macro. In effect, this leaves
461 ;;; the signalling of the appropriate error until load time.
462 ;;;
463 ;;; Note: During bootstrapping, this function is allowed to return NIL.
470 ; error at load time.
475 \f
476 ;;; These are used to communicate the method name and lambda-list to
477 ;;; MAKE-METHOD-LAMBDA-INTERNAL.
482 body env)
484 ;; don't care to figure out what parts of PCL would have
485 ;; to change to accept that, so coerce.
493 proto-gf proto-method qualifiers specializers method-lambda env))
496 proto-gf proto-method method-function-lambda initargs env))
499 proto-gf proto-method specializers env)))
504 specializers lambda-list)
505 ;; Note: We could DECLAIM the ftype of the generic function here,
506 ;; since ANSI specifies that we create it if it does not
507 ;; exist. However, I chose not to, because I think it's more
508 ;; useful to support a style of programming where every generic
509 ;; function has an explicit DEFGENERIC and any typos in DEFMETHODs
510 ;; are warned about. Otherwise
511 ;;
512 ;; (DEFGENERIC FOO-BAR-BLETCH (X))
513 ;; (DEFMETHOD FOO-BAR-BLETCH ((X HASH-TABLE)) ..)
514 ;; (DEFMETHOD FOO-BRA-BLETCH ((X SIMPLE-VECTOR)) ..)
515 ;; (DEFMETHOD FOO-BAR-BLETCH ((X VECTOR)) ..)
516 ;; (DEFMETHOD FOO-BAR-BLETCH ((X ARRAY)) ..)
517 ;; (DEFMETHOD FOO-BAR-BLETCH ((X LIST)) ..)
518 ;;
519 ;; compiles without raising an error and runs without raising an
520 ;; error (since SIMPLE-VECTOR cases fall through to VECTOR) but
521 ;; still doesn't do what was intended. I hate that kind of bug
522 ;; (code which silently gives the wrong answer), so we don't do a
523 ;; DECLAIM here. -- WHN 20000229
529 initargs-form)))
536 method-class-name initargs-form)
539 fn-lambda)
552 specializers)
563 ;; CONSTANT-FORM-VALUE? What I
564 ;; kind of want to know, though,
565 ;; is what happens if we don't do
566 ;; this for some slow-method
567 ;; function because of a hairy
568 ;; lexenv -- is the only bad
569 ;; effect that the method
570 ;; function ends up unnamed? If
571 ;; so, couldn't we arrange to
572 ;; name it later?
574 specl))
575 specializers))
583 name qualifiers `',specls
584 unspecialized-lambda-list method-class-name
586 #',mname
589 name qualifiers
590 specializers
591 #+nil
597 specializers))
598 unspecialized-lambda-list
599 method-class-name
600 initargs-form))))
604 method-class-name initargs-form)
606 ',method-class-name
607 ',name
608 ',qualifiers
609 ,specializers-form
610 ',unspecialized-lambda-list
611 ,initargs-form
620 proto-gf proto-method method-function-lambda initargs env)))
623 method-lambda initargs env)
635 (check-method-lambda method-lambda 'make-method-lambda) ; TODO remove check in make-method-lambda
636 ;; Default behavior: delegate to MAKE-METHOD-LAMBDA.
648 ;;; When bootstrapping PCL MAKE-METHOD-LAMBDA starts out as a regular
649 ;;; function: REAL-MAKE-METHOD-LAMBDA set to the fdefinition of
650 ;;; MAKE-METHOD-LAMBDA. Once generic functions are born,
651 ;;; REAL-MAKE-METHOD-LAMBDA is used to implement the default method.
652 ;;; MAKE-METHOD-LAMBDA-INTERNAL is split out into a separate function
653 ;;; so that changing it in a live image is easy, and changes actually
654 ;;; take effect.
673 ;; We have the %METHOD-NAME declaration in the place where we expect it only
674 ;; if there is are no non-standard prior MAKE-METHOD-LAMBDA methods -- or
675 ;; unless they're fantastically unintrusive.
678 ;; Macroexpansion caused by code-walking may call make-method-lambda and
679 ;; end up with wrong values
687 ;; the method-cell is a way of communicating what method a
688 ;; method-function implements, for the purpose of
689 ;; NO-NEXT-METHOD. We need something that can be shared
690 ;; between function and initargs, but not something that
691 ;; will be coalesced as a constant (because we are naughty,
692 ;; oh yes) with the expansion of any other methods in the
693 ;; same file. -- CSR, 2007-05-30
699 parameters
700 specializers))
704 ;; These declarations seem to be used by PCL to pass
705 ;; information to itself; when I tried to delete 'em
706 ;; ca. 0.6.10 it didn't work. I'm not sure how
707 ;; they work, but note the (VAR-DECLARATION '%CLASS ..)
708 ;; expression in CAN-OPTIMIZE-ACCESS1. -- WHN 2000-12-30
713 parameters
714 specializers))
715 ;; These TYPE declarations weren't in the original
716 ;; PCL code, but the Python compiler likes them a
717 ;; lot. (We're telling the compiler about our
718 ;; knowledge of specialized argument types so that
719 ;; it can avoid run-time type dispatch overhead,
720 ;; which can be a huge win for Python.)
724 par spec specials env))
725 parameters
726 specializers))))
728 ;; Remove the documentation string and insert the
729 ;; appropriate class declarations. The documentation
730 ;; string is removed to make it easy for us to insert
731 ;; new declarations later, they will just go after the
732 ;; CADR of the method lambda. The class declarations
733 ;; are inserted to communicate the class of the method's
734 ;; arguments to the code walk.
736 ;; The default ignorability of method parameters
737 ;; doesn't seem to be specified by ANSI. PCL had
738 ;; them basically ignorable but was a little
739 ;; inconsistent. E.g. even though the two
740 ;; method definitions
741 ;; (DEFMETHOD FOO ((X T) (Y T)) "Z")
742 ;; (DEFMETHOD FOO ((X T) Y) "Z")
743 ;; are otherwise equivalent, PCL treated Y as
744 ;; ignorable in the first definition but not in the
745 ;; second definition. We make all required
746 ;; parameters ignorable as a way of systematizing
747 ;; the old PCL behavior. -- WHN 2000-11-24
749 ,class-declarations
750 ,@declarations
769 parameters-setqd)
771 required-parameters
772 env
773 slots)
775 walked-declarations
776 walked-documentation)
787 ,slot-name-lists
797 aux))))
800 (,lambda-list .method-args. .next-methods.
801 :call-next-method-p
807 ,@walked-declarations
810 %parameter-binding-modified))
814 %parameter-binding-modified))
826 proto-generic-function proto-method name environment)))
837 :format-control
838 "~@<~S is not a valid parameter specializer name.~@:>"
847 specializer-name))
857 ;; In case of unknown specializer or known specializer with syntax
858 ;; error, TYPECASE may fall through to default method with error
859 ;; signaling.
876 `(,type
877 (,function-name
878 proto-generic-function proto-method specializer-name environment))))
880 ; ^ apparently not needed during bootstrapping
881 symbol cons t)))))
891 result
893 specializer generic-function))))
901 ;; FIXME: this HANDLER-CASE is a bit of a hammer to crack a nut:
902 ;; the idea is that we want to unparse permissively, so that the
903 ;; lazy (or rather the "portable") specializer extender (who
904 ;; does not define methods on these new SBCL-specific MOP
905 ;; functions) can still subclass specializer and define methods
906 ;; without everything going wrong. Making it cleaner and
907 ;; clearer that that is what we are defending against would be
908 ;; nice. -- CSR, 2007-06-01
915 class-name
916 type))
917 type))
920 specializer generic-function)))
926 ;;; a helper function for creating Python-friendly type declarations
927 ;;; in DEFMETHOD forms.
928 ;;;
929 ;;; We're too lazy to cons up a new environment for this, so we just pass in
930 ;;; the list of locally declared specials in addition to the old environment.
935 ;; KLUDGE: ANSI, in its wisdom, says that
936 ;; EQL-SPECIALIZER-FORMs in EQL specializers are evaluated at
937 ;; DEFMETHOD expansion time. Thus, although one might think
938 ;; that in
939 ;; (DEFMETHOD FOO ((X PACKAGE)
940 ;; (Y (EQL 12))
941 ;; ..))
942 ;; the PACKAGE and (EQL 12) forms are both parallel type
943 ;; names, they're not, as is made clear when you do
944 ;; (DEFMETHOD FOO ((X PACKAGE)
945 ;; (Y (EQL 'BAR)))
946 ;; ..)
947 ;; where Y needs to be a symbol named "BAR", not some cons
948 ;; made by (CONS 'QUOTE 'BAR). I.e. when the
949 ;; EQL-SPECIALIZER-FORM is (EQL 'X), it requires an argument
950 ;; to be of type (EQL X). It'd be easy to transform one to
951 ;; the other, but it'd be somewhat messier to do so while
952 ;; ensuring that the EQL-SPECIALIZER-FORM is only EVAL'd
953 ;; once. (The new code wouldn't be messy, but it'd require a
954 ;; big transformation of the old code.) So instead we punt.
955 ;; -- WHN 20000610
958 ;; KLUDGE: For some low-level implementation
959 ;; classes, perhaps because of some problems related
960 ;; to the incomplete integration of PCL into SBCL's
961 ;; type system, some specializer classes can't be
962 ;; declared as argument types. E.g.
963 ;; (DEFMETHOD FOO ((X SLOT-OBJECT))
964 ;; (DECLARE (TYPE SLOT-OBJECT X))
965 ;; ..)
966 ;; loses when
967 ;; (DEFSTRUCT BAR A B)
968 ;; (FOO (MAKE-BAR))
969 ;; perhaps because of the way that STRUCTURE-OBJECT
970 ;; inherits both from SLOT-OBJECT and from
971 ;; SB-KERNEL:INSTANCE. In an effort to sweep such
972 ;; problems under the rug, we exclude these problem
973 ;; cases by blacklisting them here. -- WHN 2001-01-19
977 ;; KLUDGE: PCL, in its wisdom, sometimes calls methods with
978 ;; types which don't match their specializers. (Specifically,
979 ;; it calls ENSURE-CLASS-USING-CLASS (T NULL) with a non-NULL
980 ;; second argument.) Hopefully it only does this kind of
981 ;; weirdness when bootstrapping.. -- WHN 20000610
986 ;; Don't declare types for special variables -- our rebinding magic
987 ;; for SETQ cases don't work right there as SET, (SETF SYMBOL-VALUE),
988 ;; etc. make things undecidable.
991 ;; Otherwise, we can usually make Python very happy.
992 ;;
993 ;; KLUDGE: Since INFO doesn't work right for class objects here,
994 ;; and they are valid specializers, see if the specializer is
995 ;; a named class, and use the name in that case -- otherwise
996 ;; the class instance is ok, since info will just return NIL, NIL.
997 ;;
998 ;; We still need to deal with the class case too, but at
999 ;; least #.(find-class 'integer) and integer as equivalent
1000 ;; specializers with this.
1007 specializer))
1021 ;; CLASS can be null here if the user has
1022 ;; erroneously tried to use a defined type as a
1023 ;; specializer; it can be a non-SYSTEM-CLASS if
1024 ;; the user defines a type and calls (SETF
1025 ;; FIND-CLASS) in a consistent way.
1034 ;; don't declare CLOS classes as parameters;
1035 ;; it's too expensive.
1038 ;; we can get here, and still not have a failure
1039 ;; case, by doing MOP programming like (PROGN
1040 ;; (ENSURE-CLASS 'FOO) (DEFMETHOD BAR ((X FOO))
1041 ;; ...)). Best to let the user know we haven't
1042 ;; been able to extract enough information:
1044 "~@<can't find type for specializer ~S in ~S.~@:>"
1045 specializer-nameoid
1051 ;;; For passing a list (groveled by the walker) of the required
1052 ;;; parameters whose bindings are modified in the method body to the
1053 ;;; optimized-slot-value* macros.
1057 method-args
1058 next-methods
1069 next-method-call
1070 args
1071 rest-arg
1080 parameters-setqd applyp method-cell))
1081 &body body
1085 ;; always provide the lexical function NEXT-METHOD-P.
1086 ;; I would think this to be a good candidate for declaring INLINE
1087 ;; but that's not the way it was done before.
1098 `((%check-cnm-args cnm-args
1099 ,method-args
1101 nil)
1109 ',method-cell
1118 ;; Can't easily provide a RETRY restart here, as the return value here is
1119 ;; for the method, not the generic function.
1121 method args)))
1139 call-method-args)
1141 value)
1162 pv
1163 next-method-call
1164 arg-info)
1167 value)
1171 ;; The two variants of INVOKE-FAST-METHOD-CALL differ in how REST-ARGs
1172 ;; are handled. The first one will get REST-ARG as a single list (as
1173 ;; the last argument), and will thus need to use APPLY. The second one
1174 ;; will get them as a &MORE argument, so we can pass the arguments
1175 ;; directly with MULTIPLE-VALUE-CALL and %MORE-ARG-VALUES.
1184 more-context
1185 more-count
1191 ,@required-args
1194 ;; The cases with only small amounts of required arguments passed
1195 ;; are probably very common, and special-casing speeds them up by
1196 ;; a factor of 2 with very little effect on the other
1197 ;; cases. Though it'd be nice to have the generic case be equally
1198 ;; fast.
1205 ,@required-args
1216 \f
1217 ;;;; effective method functions
1223 ;;; This function was in the CMU CL version of PCL (ca Debian 2.4.8)
1224 ;;; without explanation. It appears to be intended for debugging, so
1225 ;;; it might be useful someday, so I haven't deleted it.
1226 ;;; But it isn't documented and isn't used for anything now, so
1227 ;;; I've conditionalized it out of the base system. -- WHN 19991213
1228 #+sb-show
1261 ,@more-arg
1264 ,restp
1265 ,@required-args
1270 ;; "What," you may wonder, "do these next two clauses do?" In that
1271 ;; case, you are not a PCL implementor, for they considered this to
1272 ;; be self-documenting.:-| Or CSR, for that matter, since he can
1273 ;; also figure it out by looking at it without breaking stride. For
1274 ;; the rest of us, though: From what the code is doing with .SLOTS.
1275 ;; and whatnot, evidently it's implementing SLOT-VALUEish and
1276 ;; GET-SLOT-VALUEish things. Then we can reason backwards and
1277 ;; conclude that setting EMF to a FIXNUM is an optimized way to
1278 ;; represent these slot access operations.
1289 value)))))
1297 ;; (In cmucl-2.4.8 there was a commented-out third ,@(WHEN
1298 ;; ...) clause here to handle SLOT-BOUNDish stuff. Since
1299 ;; there was no explanation and presumably the code is 10+
1300 ;; years stale, I simply deleted it. -- WHN)
1301 )))
1303 ;;; Before SBCL 0.9.16.7 instead of
1304 ;;; INVOKE-NARROW-EFFECTIVE-METHOD-FUNCTION we passed a (THE (OR
1305 ;;; FUNCTION METHOD-CALL FAST-METHOD-CALL) EMF) form as the EMF. Now,
1306 ;;; to make less work for the compiler we take a path that doesn't
1307 ;;; involve the slot-accessor clause (where EMF is a FIXNUM) at all.
1322 ,@more-arg
1325 ,restp
1326 ,@required-args
1330 emf-n restp required-args))
1353 args)
1376 args))))))
1379 args
1391 value)))
1408 \f
1411 method-cell
1412 cnm-args)
1415 ,next-method-call
1427 ,@args
1433 call-next-method-p
1434 setq-p
1435 parameters-setqd
1436 method-cell
1437 applyp))
1438 &body body
1458 nil)
1460 ,next-method-call
1462 ,method-cell
1463 cnm-args))))
1469 ;;; CMUCL comment (Gerd Moellmann):
1470 ;;;
1471 ;;; The standard says it's an error if CALL-NEXT-METHOD is called with
1472 ;;; arguments, and the set of methods applicable to those arguments is
1473 ;;; different from the set of methods applicable to the original
1474 ;;; method arguments. (According to Barry Margolin, this rule was
1475 ;;; probably added to ensure that before and around methods are always
1476 ;;; run before primary methods.)
1477 ;;;
1478 ;;; This could be optimized for the case that the generic function
1479 ;;; doesn't have hairy methods, does have standard method combination,
1480 ;;; is a standard generic function, there are no methods defined on it
1481 ;;; for COMPUTE-APPLICABLE-METHODS and probably a lot more of such
1482 ;;; preconditions. That looks hairy and is probably not worth it,
1483 ;;; because this check will never be fast.
1485 ;; 1. Check for no arguments.
1490 ;; 2. Requirement arguments pairwise: if all are EQL, the applicable
1491 ;; methods must be the same. This takes care of the relatively common
1492 ;; case of twiddling with &KEY arguments without being horribly
1493 ;; expensive.
1500 ;; 3. Only then do the full check.
1505 ~{~S~^, ~} to call-next-method is different from ~
1506 the set of methods ~S applicable to the original ~
1507 method argument~P ~{~S~^, ~}.~@:>"
1511 ;; FIXME: replacing this entire mess with DESTRUCTURING-BIND would correct
1512 ;; problems similar to those already solved by a correct implementation
1513 ;; of DESTRUCTURING-BIND, such as incorrect binding order:
1514 ;; e.g. (macroexpand-1 '(bind-args ((&optional (x nil xsp)) args) (form)))
1515 ;; -> (LET* ((.ARGS-TAIL. ARGS) (XSP (NOT (NULL .ARGS-TAIL.))) (X ...)))
1516 ;; It's mostly irrelevant unless a method uses CALL-NEXT-METHOD though.
1532 "encountered the non-standard lambda list keyword ~S"
1533 var)))
1534 nil)
1582 ,@bindings
1583 (.dummy0.
1595 ;; FIXME: Do we want to export this symbol? Or maybe use an
1596 ;; (ERROR 'SIMPLE-PROGRAM-ERROR) form?
1599 return tail))
1603 ;; method definition
1605 ;; a list of all required parameters whose bindings might be
1606 ;; modified in the method body.
1613 ;; hierarchy: nil -> :simple -> T.
1616 form)
1618 ;; The walker will split (SETQ A 1 B 2) to
1619 ;; separate (SETQ A 1) and (SETQ B 2) forms, so we
1620 ;; only need to handle the simple case of SETQ
1621 ;; here.
1626 ;; Note that we don't need to check for
1627 ;; %VARIABLE-REBINDING declarations like is
1628 ;; done in CAN-OPTIMIZE-ACCESS1, since the
1629 ;; bindings that will have that declation will
1630 ;; never be SETQd.
1632 ;; If a parameter binding is shadowed by
1633 ;; another binding it won't have a %CLASS
1634 ;; declaration anymore, and this won't get
1635 ;; executed.
1637 form)
1641 form)
1649 form))
1653 ;;; FIXME: the walker's rewriting of the source code causes
1654 ;;; trouble when doing code coverage. The rewrites should be
1655 ;;; removed, and the same operations done using
1656 ;;; compiler-macros or tranforms.
1658 walked-lambda
1659 method-lambda)
1660 call-next-method-p
1662 parameters-setqd)))))
1670 \f
1680 new-value)
1682 \f
1688 #+nil
1692 ll initargs source-location)))
1696 initargs source-location)
1705 :name gf-spec
1706 :new-location source-location
1707 :old-method method
1710 gf-spec qualifiers specializers lambda-list
1711 :definition-source source-location
1712 initargs)))
1715 ;; FIXME: should be STYLE-WARNING?
1717 "~&At the time the method with qualifiers ~:S and~%~
1718 specializers ~:S on the generic function ~S~%~
1719 was compiled, the method-class for that generic function was~%~
1720 ~S. But, the method class is now ~S, this~%~
1721 may mean that this method was compiled improperly.~%"
1722 qualifiers specializers gf-spec
1724 method))
1752 \f
1755 ;; We say "&MUMBLE is not allowed in a generic function lambda list"
1756 ;; whether this is called by DEFMETHOD or DEFGENERIC.
1757 ;; [It is used for either. Why else recognize and silently ignore &AUX?]
1761 :silent t
1767 ;; FIXME: this does more than return an FTYPE from a lambda list -
1768 ;; it unions the type with an existing ctype object. It needs a better name,
1769 ;; and to be reimplemented as "union and call sb-c::ftype-from-lambda-list".
1780 old-ftype))))
1795 keywords)
1798 *))))
1799 \f
1800 ;;;; early generic function support
1804 ;; CLHS doesn't specify &allow-other-keys here but I guess the supposition
1805 ;; is that they'll be checked by ENSURE-GENERIC-FUNCTION-USING-CLASS.
1806 ;; Except we don't do that either, so I think the blame, if any, lies there
1807 ;; for not catching errant keywords.
1819 existing fun-name all-keys)))))
1823 'simple-program-error
1825 already names an ordinary function or a ~
1826 macro.~@:>"
1876 arg-info-precedence
1877 arg-info-metatypes
1878 arg-info-number-optional
1879 arg-info-key/rest-p
1880 arg-info-keys ;nil no &KEY or &REST allowed
1881 ;(k1 k2 ..) Each method must accept these &KEY arguments.
1882 ;T must have &KEY or &REST
1884 gf-info-simple-accessor-type ; nil, reader, writer, boundp
1887 gf-info-static-c-a-m-emf
1889 gf-info-fast-mf-p)
1907 ;;; Create a gf lambda list from a method lambda list
1920 argument-precedence-order)
1945 existing methods of ~S.~%~
1946 Old lambda-list ~s"
1953 lambda-list
1969 arg-info))
1979 to the generic function~2I~_~S;~I~_~
1980 but ~?~:>"
1990 "the method has ~A required arguments than the generic function."
1994 "the method has ~A optional arguments than the generic function."
1998 "the method and generic function differ in whether they accept~_~
2005 ~S."
2006 gf-keywords)))))))
2015 ;;; FIXME: we don't actually need this; we could test for the exact
2016 ;;; class and deal with it as appropriate. In fact we probably don't
2017 ;;; need it anyway because we only use this for METHOD-SPECIALIZERS on
2018 ;;; the standard reader method for METHOD-SPECIALIZERS. Probably.
2030 standard-writer-method standard-boundp-method
2031 global-reader-method global-writer-method
2032 global-boundp-method))
2062 nil)))
2110 nil)
2116 ;; FIXME: this test will eventually be
2117 ;; superseded by the *internal-pcl...* test,
2118 ;; above. While we are in a process of
2119 ;; transition, however, it should probably
2120 ;; remain.
2126 #'make-method-lambda
2137 arg-info)
2139 ;;; This is the early definition of ENSURE-GENERIC-FUNCTION-USING-CLASS.
2140 ;;;
2141 ;;; The STATIC-SLOTS field of the funcallable instances used as early
2142 ;;; generic functions is used to store the early methods and early
2143 ;;; discriminator code for the early generic function. The static
2144 ;;; slots field of the fins contains a list whose:
2145 ;;; CAR - a list of the early methods on this early gf
2146 ;;; CADR - the early discriminator code for this method
2149 lambda-list-p)
2150 argument-precedence-order
2151 definition-source
2152 documentation
2158 existing)
2162 argument-precedence-order definition-source
2163 documentation)
2171 argument-precedence-order definition-source
2172 documentation))))
2175 function argument-precedence-order source-location
2176 documentation)
2180 fin
2205 :lambda-list lambda-list
2208 fin))
2218 new-value)
2224 dfun)))
2227 ;; Check that we are under the lock.
2228 #+sb-thread
2233 new-state))))
2234 dfun)
2269 nil)
2284 class nor a symbol that names a class."
2288 ;; FIXME: reference MOP documentation -- this is an
2289 ;; additional requirement on our users
2306 method-class)
2311 ;; Use the existing lambda-list, if any. It is reasonable to do eg.
2312 ;;
2313 ;; (if (fboundp name)
2314 ;; (ensure-generic-function name)
2315 ;; (ensure-generic-function name :lambda-list '(foo)))
2316 ;;
2317 ;; in which case we end up here with no lambda-list in the first leg.
2321 t)
2330 ;; FIXME: Ideally we would like to not clobber it, but because generic
2331 ;; functions assert their FTYPEs callers believing the FTYPE are left with
2332 ;; unsafe assumptions. Hence the clobbering. Be quiet when the new type
2333 ;; is a subtype of the old one, though -- even though the type is not
2334 ;; trusted anymore, the warning is still not quite as interesting.
2338 for the same name with ~S.~:@>"
2339 fun-name 'ftype
2344 fun-name))
2348 fun-name
2349 &rest all-keys
2354 ;; KLUDGE: the above macro does SETQ on GENERIC-FUNCTION-CLASS,
2355 ;; which is what makes the next line work
2364 fun-name
2365 &rest all-keys
2376 \f
2383 ;;; FIXME: this function took on a slightly greater role than it
2384 ;;; previously had around 2005-11-02, when CSR fixed the bug whereby
2385 ;;; having more than one subclass of standard-generic-function caused
2386 ;;; the whole system to die horribly through a metacircle in
2387 ;;; GF-ARG-INFO. The fix is to be slightly more disciplined about
2388 ;;; calling accessor methods -- we call GET-GENERIC-FUN-INFO when
2389 ;;; computing discriminating functions, so we need to be careful about
2390 ;;; having a base case for the recursion, and we provide that with the
2391 ;;; STANDARD-GENERIC-FUNCTION case below. However, we are not (yet)
2392 ;;; as disciplined as CLISP's CLOS/MOP, and it would be nice to get to
2393 ;;; that stage, where all potentially dangerous cases are enumerated
2394 ;;; and stopped. -- CSR, 2005-11-02.
2396 ;; values nreq applyp metatypes nkeys arg-info
2403 metatypes
2404 arg-info))
2413 nkeys
2414 arg-info))))
2425 &key slot-name object-class method-class-function
2426 definition-source)
2429 ;; Figure out whether we got class objects or class names as the
2430 ;; specializers and set parsed and unparsed appropriately. If we
2431 ;; got class objects, then we can compute unparsed, but if we
2432 ;; got class names we don't try to compute parsed.
2438 specializers))
2449 ;; the parsed specializers. This is used by
2450 ;; EARLY-METHOD-SPECIALIZERS to cache the parse.
2451 ;; Note that this only comes into play when there is
2452 ;; more than one early method on an early gf.
2453 parsed
2455 ;; A list to which REAL-MAKE-A-METHOD can be applied
2456 ;; to make a real method corresponding to this early
2457 ;; one.
2460 initargs doc)
2466 result))
2471 definition-source)
2482 :slot-definition slot-definition
2486 initargs)
2487 :definition-source definition-source
2488 initargs)))
2508 ;;; Fetch the specializers of an early method. This is basically just
2509 ;;; a simple accessor except that when the second argument is t, this
2510 ;;; converts the specializers from symbols into class objects. The
2511 ;;; class objects are cached in the early method, this makes
2512 ;;; bootstrapping faster because the class objects only have to be
2513 ;;; computed once.
2514 ;;;
2515 ;;; NOTE:
2516 ;;; The second argument should only be passed as T by
2517 ;;; early-lookup-method. This is to implement the rule that only when
2518 ;;; there is more than one early method on a generic function is the
2519 ;;; conversion from class names to class objects done. This
2520 ;;; corresponds to the fact that we are only allowed to have one
2521 ;;; method on any generic function up until the time classes exist.
2546 specializers arglist &rest initargs
2547 &key documentation definition-source
2550 ;; argument here because the default,
2551 ;; STANDARD-GENERIC-FUNCTION, is right for all early generic
2552 ;; functions. (See REAL-ADD-NAMED-METHOD)
2562 specializers initargs documentation
2567 ;;; This is the early version of ADD-METHOD. Later this will become a
2568 ;;; generic function. See !FIX-EARLY-GENERIC-FUNCTIONS which has
2569 ;;; special knowledge about ADD-METHOD.
2582 ;;; This is the early version of REMOVE-METHOD. See comments on
2583 ;;; the early version of ADD-METHOD.
2597 ;;; This is the early version of GET-METHOD. See comments on the early
2598 ;;; version of ADD-METHOD.
2604 specializers)
2606 specializers))
2611 nil))
2614 ;; minor KLUDGE: a separate code component for this function allows GCing
2615 ;; a few symbols and their associated code that would otherwise be retained:
2616 ;; *!EARLY-{GENERIC-}FUNCTIONS*, *!GENERIC-FUNCTION-FIXUPS*
2624 ;; Rearrange *!EARLY-GENERIC-FUNCTIONS* to speed up
2625 ;; FIX-EARLY-GENERIC-FUNCTIONS.
2632 generic-function-methods
2633 method-specializers
2634 specializer-type
2635 specializer-class
2636 slot-definition-location
2637 slot-definition-name
2638 class-slots
2639 gf-arg-info
2640 class-precedence-list
2641 slot-boundp-using-class
2643 slot-value-using-class)))
2654 early-method))))
2657 early-method t))
2672 ;; This is lifted from sb-introspect, OAOO and all that.
2691 map)
2705 'standard-method
2706 qualifiers lambda-list specializers initargs nil
2717 \f
2718 ;;; PARSE-DEFMETHOD is used by DEFMETHOD to parse the &REST argument
2719 ;;; into the 'real' arguments. This is where the syntax of DEFMETHOD
2720 ;;; is really implemented.
2742 \f
2746 ;; We don't need these, but according to the unit tests,
2747 ;; they're mandated by AMOP.
2753 ()
2756 ;; Return 3 values:
2757 ;; - the bound variables, without defaults, supplied-p vars, or &AUX vars.
2758 ;; - the lambda list without specializers.
2759 ;; - just the specializers
2763 arglist
2772 rest
2773 ;; Preserve keyword-names when given as (:KEYWORD var)
2779 \f
2781 \f
2782 ;;; FIXME: In here there was a #-CMU definition of SYMBOL-MACROLET
2783 ;;; which used %WALKER stuff. That suggests to me that maybe the code
2784 ;;; walker stuff was only used for implementing stuff like that; maybe
2785 ;;; it's not needed any more? Hunt down what it was used for and see.
2792 form)))
2801 ,in
2805 slot-entry
2809 slot-entry
2811 `(,var-name
2813 slots)
2823 ,in
2828 slots)