| blob | 424c65b13d27f1f70e33c800030c512b46bf37c5 |
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.
90 name))))
92 ;;; *!GENERIC-FUNCTION-FIXUPS* is used by !FIX-EARLY-GENERIC-FUNCTIONS
93 ;;; to convert the few functions in the bootstrap which are supposed
94 ;;; to be generic functions but can't be early on.
95 ;;;
96 ;;; each entry is a list of name and lambda-list, class names as
97 ;;; specializers, and method body function name.
102 real-add-method))
106 real-remove-method))
110 real-get-method))
113 &key generic-function-class environment
116 real-ensure-gf-using-class--generic-function)
118 &key generic-function-class environment
121 real-ensure-gf-using-class--null))
125 real-make-method-lambda))
129 real-make-method-specializers-form))
133 real-parse-specializer-using-class))
137 real-unparse-specializer-using-class))
140 lambda-expression
141 lambda-list environment)
143 real-make-method-initargs-form))
147 standard-compute-effective-method))))
148 \f
178 DEFGENERIC: ~S~:@>"
181 ;; FIXME: this list is slightly weird.
182 ;; ANSI (on the DEFGENERIC page) in one
183 ;; place allows only OPTIMIZE; in
184 ;; another place gives this list of
185 ;; disallowed declaration specifiers.
186 ;; This seems to be the only place where
187 ;; the FUNCTION declaration is
188 ;; mentioned; TYPE seems to be missing.
189 ;; Very strange. -- CSR, 2002-10-21
191 inline notinline special))
194 is not allowed inside DEFGENERIC."
200 spec))))
201 (:method-combination
207 symbol: ~S"
211 (:argument-precedence-order
217 :ARGUMENT-PRECEDENCE-ORDER clause."
222 :ARGUMENT-PRECEDENCE-ORDER clause: ~
223 ~S and ~S"
233 (:method
236 ;; ANSI requires that unsupported things must get a
237 ;; PROGRAM-ERROR.
259 ;; Hmm. This is similar to BECOME-DEFINED-FUN-NAME
260 ;; except that it doesn't clear an :ASSUMED-TYPE. Should it?
268 :name fun-name
276 fun-name
277 :lambda-list lambda-list
278 :definition-source source-location
279 initargs))
283 ()
291 :format-control
292 "~@<invalid ~S ~_in the generic function lambda list ~S~:>"
296 lambda-list
302 ;; no defaults allowed for &OPTIONAL arguments
305 ;; no defaults allowed for &KEY arguments
310 \f
316 ;; :compile-toplevel is needed for subsequent forms
317 ;; :execute is needed for references to itself inside the body
319 ;; KLUDGE: this double expansion is quite a monumental
320 ;; workaround: it comes about because of a fantastic interaction
321 ;; between the processing rules of CLHS 3.2.3.1 and the
322 ;; bizarreness of MAKE-METHOD-LAMBDA.
323 ;;
324 ;; MAKE-METHOD-LAMBDA can be called by the user, and if the
325 ;; lambda itself doesn't refer to outside bindings the return
326 ;; value must be compileable in the null lexical environment.
327 ;; However, the function must also refer somehow to the
328 ;; associated method object, so that it can call NO-NEXT-METHOD
329 ;; with the appropriate arguments if there is no next method --
330 ;; but when the function is generated, the method object doesn't
331 ;; exist yet.
332 ;;
333 ;; In order to resolve this issue, we insert a literal cons cell
334 ;; into the body of the method lambda, return the same cons cell
335 ;; as part of the second (initargs) return value of
336 ;; MAKE-METHOD-LAMBDA, and a method on INITIALIZE-INSTANCE fills
337 ;; in the cell when the method is created. However, this
338 ;; strategy depends on having a fresh cons cell for every method
339 ;; lambda, which (without the workaround below) is skewered by
340 ;; the processing in CLHS 3.2.3.1, which permits implementations
341 ;; to macroexpand the bodies of EVAL-WHEN forms with both
342 ;; :COMPILE-TOPLEVEL and :LOAD-TOPLEVEL only once. The
343 ;; expansion below forces the double expansion in those cases,
344 ;; while expanding only once in the common case.
355 lambda-list body env)))
371 ;;; Take a name which is either a generic function name or a list specifying
372 ;;; a SETF generic function (like: (SETF <generic-function-name>)). Return
373 ;;; the prototype instance of the method-class for that generic function.
374 ;;;
375 ;;; If there is no generic function by that name, this returns the
376 ;;; default value, the prototype instance of the class
377 ;;; STANDARD-METHOD. This default value is also returned if the spec
378 ;;; names an ordinary function or even a macro. In effect, this leaves
379 ;;; the signalling of the appropriate error until load time.
380 ;;;
381 ;;; Note: During bootstrapping, this function is allowed to return NIL.
388 ; error at load time.
393 \f
394 ;;; These are used to communicate the method name and lambda-list to
395 ;;; MAKE-METHOD-LAMBDA-INTERNAL.
400 proto-gf
401 proto-method
402 qualifiers
403 lambda-list
404 body
405 env)
415 proto-gf proto-method method-function-lambda
416 initargs env))
418 proto-gf proto-method specializers env)))
420 ;; Note: We could DECLAIM the ftype of the generic function
421 ;; here, since ANSI specifies that we create it if it does
422 ;; not exist. However, I chose not to, because I think it's
423 ;; more useful to support a style of programming where every
424 ;; generic function has an explicit DEFGENERIC and any typos
425 ;; in DEFMETHODs are warned about. Otherwise
426 ;;
427 ;; (DEFGENERIC FOO-BAR-BLETCH (X))
428 ;; (DEFMETHOD FOO-BAR-BLETCH ((X HASH-TABLE)) ..)
429 ;; (DEFMETHOD FOO-BRA-BLETCH ((X SIMPLE-VECTOR)) ..)
430 ;; (DEFMETHOD FOO-BAR-BLETCH ((X VECTOR)) ..)
431 ;; (DEFMETHOD FOO-BAR-BLETCH ((X ARRAY)) ..)
432 ;; (DEFMETHOD FOO-BAR-BLETCH ((X LIST)) ..)
433 ;;
434 ;; compiles without raising an error and runs without
435 ;; raising an error (since SIMPLE-VECTOR cases fall through
436 ;; to VECTOR) but still doesn't do what was intended. I hate
437 ;; that kind of bug (code which silently gives the wrong
438 ;; answer), so we don't do a DECLAIM here. -- WHN 20000229
440 unspecialized-lambda-list
444 initargs-form)))))))
451 method-class-name initargs-form)
454 fn-lambda)
467 specializers)
478 ;; CONSTANT-FORM-VALUE? What I
479 ;; kind of want to know, though,
480 ;; is what happens if we don't do
481 ;; this for some slow-method
482 ;; function because of a hairy
483 ;; lexenv -- is the only bad
484 ;; effect that the method
485 ;; function ends up unnamed? If
486 ;; so, couldn't we arrange to
487 ;; name it later?
489 specl))
490 specializers))
498 name qualifiers `',specls
499 unspecialized-lambda-list method-class-name
501 #',mname
504 name qualifiers
505 specializers
506 #+nil
512 specializers))
513 unspecialized-lambda-list
514 method-class-name
515 initargs-form))))
519 method-class-name initargs-form)
521 ',method-class-name
522 ',name
523 ',qualifiers
524 ,specializers-form
525 ',unspecialized-lambda-list
526 ,initargs-form
535 proto-method
536 method-function-lambda
537 initargs
538 env))))
541 method-lambda initargs env)
546 is not a lambda form."
547 method-lambda))
554 ;;; When bootstrapping PCL MAKE-METHOD-LAMBDA starts out as a regular
555 ;;; functions: REAL-MAKE-METHOD-LAMBDA set to the fdefinition of
556 ;;; MAKE-METHOD-LAMBDA. Once generic functions are born, the
557 ;;; REAL-MAKE-METHOD lambda is used as the body of the default method.
558 ;;; MAKE-METHOD-LAMBDA-INTERNAL is split out into a separate function
559 ;;; so that changing it in a live image is easy, and changes actually
560 ;;; take effect.
578 is not a lambda form."
579 method-lambda))
582 ;; We have the %METHOD-NAME declaration in the place where we expect it only
583 ;; if there is are no non-standard prior MAKE-METHOD-LAMBDA methods -- or
584 ;; unless they're fantastically unintrusive.
587 ;; Macroexpansion caused by code-walking may call make-method-lambda and
588 ;; end up with wrong values
596 ;; the method-cell is a way of communicating what method a
597 ;; method-function implements, for the purpose of
598 ;; NO-NEXT-METHOD. We need something that can be shared
599 ;; between function and initargs, but not something that
600 ;; will be coalesced as a constant (because we are naughty,
601 ;; oh yes) with the expansion of any other methods in the
602 ;; same file. -- CSR, 2007-05-30
608 parameters
609 specializers))
613 ;; These declarations seem to be used by PCL to pass
614 ;; information to itself; when I tried to delete 'em
615 ;; ca. 0.6.10 it didn't work. I'm not sure how
616 ;; they work, but note the (VAR-DECLARATION '%CLASS ..)
617 ;; expression in CAN-OPTIMIZE-ACCESS1. -- WHN 2000-12-30
622 parameters
623 specializers))
624 ;; These TYPE declarations weren't in the original
625 ;; PCL code, but the Python compiler likes them a
626 ;; lot. (We're telling the compiler about our
627 ;; knowledge of specialized argument types so that
628 ;; it can avoid run-time type dispatch overhead,
629 ;; which can be a huge win for Python.)
630 ;;
631 ;; KLUDGE: when I tried moving these to
632 ;; ADD-METHOD-DECLARATIONS, things broke. No idea
633 ;; why. -- CSR, 2004-06-16
637 par spec specials env))
638 parameters
639 specializers))))
641 ;; Remove the documentation string and insert the
642 ;; appropriate class declarations. The documentation
643 ;; string is removed to make it easy for us to insert
644 ;; new declarations later, they will just go after the
645 ;; CADR of the method lambda. The class declarations
646 ;; are inserted to communicate the class of the method's
647 ;; arguments to the code walk.
649 ;; The default ignorability of method parameters
650 ;; doesn't seem to be specified by ANSI. PCL had
651 ;; them basically ignorable but was a little
652 ;; inconsistent. E.g. even though the two
653 ;; method definitions
654 ;; (DEFMETHOD FOO ((X T) (Y T)) "Z")
655 ;; (DEFMETHOD FOO ((X T) Y) "Z")
656 ;; are otherwise equivalent, PCL treated Y as
657 ;; ignorable in the first definition but not in the
658 ;; second definition. We make all required
659 ;; parameters ignorable as a way of systematizing
660 ;; the old PCL behavior. -- WHN 2000-11-24
662 ,class-declarations
663 ,@declarations
682 parameters-setqd)
684 required-parameters
685 env
686 slots)
688 walked-declarations
689 walked-documentation)
700 ,slot-name-lists
710 aux))))
713 (,lambda-list .method-args. .next-methods.
714 :call-next-method-p
720 ,@walked-declarations
723 %parameter-binding-modified))
727 %parameter-binding-modified))
742 name)
748 ;; FIXME: Document CLASS-EQ specializers.
750 :format-control
751 "~@<~S is not a valid parameter specializer name.~@:>"
764 result
766 specializer generic-function))))
774 ;; FIXME: this HANDLER-CASE is a bit of a hammer to crack a nut:
775 ;; the idea is that we want to unparse permissively, so that the
776 ;; lazy (or rather the "portable") specializer extender (who
777 ;; does not define methods on these new SBCL-specific MOP
778 ;; functions) can still subclass specializer and define methods
779 ;; without everything going wrong. Making it cleaner and
780 ;; clearer that that is what we are defending against would be
781 ;; nice. -- CSR, 2007-06-01
788 class-name
789 type))
790 type))
793 specializer generic-function)))
799 ;;; a helper function for creating Python-friendly type declarations
800 ;;; in DEFMETHOD forms.
801 ;;;
802 ;;; We're too lazy to cons up a new environment for this, so we just pass in
803 ;;; the list of locally declared specials in addition to the old environment.
808 ;; KLUDGE: ANSI, in its wisdom, says that
809 ;; EQL-SPECIALIZER-FORMs in EQL specializers are evaluated at
810 ;; DEFMETHOD expansion time. Thus, although one might think
811 ;; that in
812 ;; (DEFMETHOD FOO ((X PACKAGE)
813 ;; (Y (EQL 12))
814 ;; ..))
815 ;; the PACKAGE and (EQL 12) forms are both parallel type
816 ;; names, they're not, as is made clear when you do
817 ;; (DEFMETHOD FOO ((X PACKAGE)
818 ;; (Y (EQL 'BAR)))
819 ;; ..)
820 ;; where Y needs to be a symbol named "BAR", not some cons
821 ;; made by (CONS 'QUOTE 'BAR). I.e. when the
822 ;; EQL-SPECIALIZER-FORM is (EQL 'X), it requires an argument
823 ;; to be of type (EQL X). It'd be easy to transform one to
824 ;; the other, but it'd be somewhat messier to do so while
825 ;; ensuring that the EQL-SPECIALIZER-FORM is only EVAL'd
826 ;; once. (The new code wouldn't be messy, but it'd require a
827 ;; big transformation of the old code.) So instead we punt.
828 ;; -- WHN 20000610
831 ;; KLUDGE: For some low-level implementation
832 ;; classes, perhaps because of some problems related
833 ;; to the incomplete integration of PCL into SBCL's
834 ;; type system, some specializer classes can't be
835 ;; declared as argument types. E.g.
836 ;; (DEFMETHOD FOO ((X SLOT-OBJECT))
837 ;; (DECLARE (TYPE SLOT-OBJECT X))
838 ;; ..)
839 ;; loses when
840 ;; (DEFSTRUCT BAR A B)
841 ;; (FOO (MAKE-BAR))
842 ;; perhaps because of the way that STRUCTURE-OBJECT
843 ;; inherits both from SLOT-OBJECT and from
844 ;; SB-KERNEL:INSTANCE. In an effort to sweep such
845 ;; problems under the rug, we exclude these problem
846 ;; cases by blacklisting them here. -- WHN 2001-01-19
850 ;; KLUDGE: PCL, in its wisdom, sometimes calls methods with
851 ;; types which don't match their specializers. (Specifically,
852 ;; it calls ENSURE-CLASS-USING-CLASS (T NULL) with a non-NULL
853 ;; second argument.) Hopefully it only does this kind of
854 ;; weirdness when bootstrapping.. -- WHN 20000610
859 ;; Don't declare types for special variables -- our rebinding magic
860 ;; for SETQ cases don't work right there as SET, (SETF SYMBOL-VALUE),
861 ;; etc. make things undecidable.
864 ;; Otherwise, we can usually make Python very happy.
865 ;;
866 ;; KLUDGE: Since INFO doesn't work right for class objects here,
867 ;; and they are valid specializers, see if the specializer is
868 ;; a named class, and use the name in that case -- otherwise
869 ;; the class instance is ok, since info will just return NIL, NIL.
870 ;;
871 ;; We still need to deal with the class case too, but at
872 ;; least #.(find-class 'integer) and integer as equivalent
873 ;; specializers with this.
880 specializer))
894 ;; CLASS can be null here if the user has
895 ;; erroneously tried to use a defined type as a
896 ;; specializer; it can be a non-SYSTEM-CLASS if
897 ;; the user defines a type and calls (SETF
898 ;; FIND-CLASS) in a consistent way.
907 ;; don't declare CLOS classes as parameters;
908 ;; it's too expensive.
911 ;; we can get here, and still not have a failure
912 ;; case, by doing MOP programming like (PROGN
913 ;; (ENSURE-CLASS 'FOO) (DEFMETHOD BAR ((X FOO))
914 ;; ...)). Best to let the user know we haven't
915 ;; been able to extract enough information:
917 "~@<can't find type for specializer ~S in ~S.~@:>"
918 specializer-nameoid
924 ;;; For passing a list (groveled by the walker) of the required
925 ;;; parameters whose bindings are modified in the method body to the
926 ;;; optimized-slot-value* macros.
930 method-args
931 next-methods
942 next-method-call
943 args
944 rest-arg
953 parameters-setqd applyp method-cell))
954 &body body
958 ;; always provide the lexical function NEXT-METHOD-P.
959 ;; I would think this to be a good candidate for declaring INLINE
960 ;; but that's not the way it was done before.
971 `((%check-cnm-args cnm-args
972 ,method-args
974 nil)
982 ',method-cell
991 ;; Can't easily provide a RETRY restart here, as the return value here is
992 ;; for the method, not the generic function.
994 method args)))
1012 call-method-args)
1014 value)
1035 pv
1036 next-method-call
1037 arg-info)
1040 value)
1044 ;; The two variants of INVOKE-FAST-METHOD-CALL differ in how REST-ARGs
1045 ;; are handled. The first one will get REST-ARG as a single list (as
1046 ;; the last argument), and will thus need to use APPLY. The second one
1047 ;; will get them as a &MORE argument, so we can pass the arguments
1048 ;; directly with MULTIPLE-VALUE-CALL and %MORE-ARG-VALUES.
1057 more-context
1058 more-count
1064 ,@required-args
1067 ;; The cases with only small amounts of required arguments passed
1068 ;; are probably very common, and special-casing speeds them up by
1069 ;; a factor of 2 with very little effect on the other
1070 ;; cases. Though it'd be nice to have the generic case be equally
1071 ;; fast.
1078 ,@required-args
1089 \f
1090 ;;;; effective method functions
1096 ;;; This function was in the CMU CL version of PCL (ca Debian 2.4.8)
1097 ;;; without explanation. It appears to be intended for debugging, so
1098 ;;; it might be useful someday, so I haven't deleted it.
1099 ;;; But it isn't documented and isn't used for anything now, so
1100 ;;; I've conditionalized it out of the base system. -- WHN 19991213
1101 #+sb-show
1134 ,@more-arg
1137 ,restp
1138 ,@required-args
1143 ;; "What," you may wonder, "do these next two clauses do?" In that
1144 ;; case, you are not a PCL implementor, for they considered this to
1145 ;; be self-documenting.:-| Or CSR, for that matter, since he can
1146 ;; also figure it out by looking at it without breaking stride. For
1147 ;; the rest of us, though: From what the code is doing with .SLOTS.
1148 ;; and whatnot, evidently it's implementing SLOT-VALUEish and
1149 ;; GET-SLOT-VALUEish things. Then we can reason backwards and
1150 ;; conclude that setting EMF to a FIXNUM is an optimized way to
1151 ;; represent these slot access operations.
1162 value)))))
1170 ;; (In cmucl-2.4.8 there was a commented-out third ,@(WHEN
1171 ;; ...) clause here to handle SLOT-BOUNDish stuff. Since
1172 ;; there was no explanation and presumably the code is 10+
1173 ;; years stale, I simply deleted it. -- WHN)
1174 )))
1176 ;;; Before SBCL 0.9.16.7 instead of
1177 ;;; INVOKE-NARROW-EFFECTIVE-METHOD-FUNCTION we passed a (THE (OR
1178 ;;; FUNCTION METHOD-CALL FAST-METHOD-CALL) EMF) form as the EMF. Now,
1179 ;;; to make less work for the compiler we take a path that doesn't
1180 ;;; involve the slot-accessor clause (where EMF is a FIXNUM) at all.
1195 ,@more-arg
1198 ,restp
1199 ,@required-args
1203 emf-n restp required-args))
1226 args)
1249 args))))))
1252 args
1264 value)))
1281 \f
1284 method-cell
1285 cnm-args)
1288 ,next-method-call
1300 ,@args
1306 call-next-method-p
1307 setq-p
1308 parameters-setqd
1309 method-cell
1310 applyp))
1311 &body body
1331 nil)
1333 ,next-method-call
1335 ,method-cell
1336 cnm-args))))
1342 ;;; CMUCL comment (Gerd Moellmann):
1343 ;;;
1344 ;;; The standard says it's an error if CALL-NEXT-METHOD is called with
1345 ;;; arguments, and the set of methods applicable to those arguments is
1346 ;;; different from the set of methods applicable to the original
1347 ;;; method arguments. (According to Barry Margolin, this rule was
1348 ;;; probably added to ensure that before and around methods are always
1349 ;;; run before primary methods.)
1350 ;;;
1351 ;;; This could be optimized for the case that the generic function
1352 ;;; doesn't have hairy methods, does have standard method combination,
1353 ;;; is a standard generic function, there are no methods defined on it
1354 ;;; for COMPUTE-APPLICABLE-METHODS and probably a lot more of such
1355 ;;; preconditions. That looks hairy and is probably not worth it,
1356 ;;; because this check will never be fast.
1358 ;; 1. Check for no arguments.
1363 ;; 2. Requirement arguments pairwise: if all are EQL, the applicable
1364 ;; methods must be the same. This takes care of the relatively common
1365 ;; case of twiddling with &KEY arguments without being horribly
1366 ;; expensive.
1373 ;; 3. Only then do the full check.
1378 ~{~S~^, ~} to call-next-method is different from ~
1379 the set of methods ~S applicable to the original ~
1380 method argument~P ~{~S~^, ~}.~@:>"
1384 ;; FIXME: replacing this entire mess with DESTRUCTURING-BIND would correct
1385 ;; problems similar to those already solved by a correct implementation
1386 ;; of DESTRUCTURING-BIND, such as incorrect binding order:
1387 ;; e.g. (macroexpand-1 '(bind-args ((&optional (x nil xsp)) args) (form)))
1388 ;; -> (LET* ((.ARGS-TAIL. ARGS) (XSP (NOT (NULL .ARGS-TAIL.))) (X ...)))
1389 ;; It's mostly irrelevant unless a method uses CALL-NEXT-METHOD though.
1405 "encountered the non-standard lambda list keyword ~S"
1406 var)))
1407 nil)
1455 ,@bindings
1456 (.dummy0.
1468 ;; FIXME: Do we want to export this symbol? Or maybe use an
1469 ;; (ERROR 'SIMPLE-PROGRAM-ERROR) form?
1472 return tail))
1476 ;; method definition
1478 ;; a list of all required parameters whose bindings might be
1479 ;; modified in the method body.
1486 ;; hierarchy: nil -> :simple -> T.
1489 form)
1491 ;; The walker will split (SETQ A 1 B 2) to
1492 ;; separate (SETQ A 1) and (SETQ B 2) forms, so we
1493 ;; only need to handle the simple case of SETQ
1494 ;; here.
1499 ;; Note that we don't need to check for
1500 ;; %VARIABLE-REBINDING declarations like is
1501 ;; done in CAN-OPTIMIZE-ACCESS1, since the
1502 ;; bindings that will have that declation will
1503 ;; never be SETQd.
1505 ;; If a parameter binding is shadowed by
1506 ;; another binding it won't have a %CLASS
1507 ;; declaration anymore, and this won't get
1508 ;; executed.
1510 form)
1514 form)
1522 form))
1526 ;;; FIXME: the walker's rewriting of the source code causes
1527 ;;; trouble when doing code coverage. The rewrites should be
1528 ;;; removed, and the same operations done using
1529 ;;; compiler-macros or tranforms.
1531 walked-lambda
1532 method-lambda)
1533 call-next-method-p
1535 parameters-setqd)))))
1543 \f
1553 new-value)
1555 \f
1561 #+nil
1565 ll initargs source-location)))
1569 initargs source-location)
1578 :name gf-spec
1579 :new-location source-location
1580 :old-method method
1583 gf-spec qualifiers specializers lambda-list
1584 :definition-source source-location
1585 initargs)))
1588 ;; FIXME: should be STYLE-WARNING?
1590 "~&At the time the method with qualifiers ~:S and~%~
1591 specializers ~:S on the generic function ~S~%~
1592 was compiled, the method-class for that generic function was~%~
1593 ~S. But, the method class is now ~S, this~%~
1594 may mean that this method was compiled improperly.~%"
1595 qualifiers specializers gf-spec
1597 method))
1625 \f
1655 x)))
1664 After &REST, a DEFGENERIC lambda-list ~
1678 keywords keyword-parameters)
1687 old-ftype))))
1702 keywords)
1705 *))))
1706 \f
1707 ;;;; early generic function support
1711 ;; CLHS doesn't specify &allow-other-keys here but I guess the supposition
1712 ;; is that they'll be checked by ENSURE-GENERIC-FUNCTION-USING-CLASS.
1713 ;; Except we don't do that either, so I think the blame, if any, lies there
1714 ;; for not catching errant keywords.
1726 existing fun-name all-keys)))))
1730 'simple-program-error
1781 arg-info-precedence
1782 arg-info-metatypes
1783 arg-info-number-optional
1784 arg-info-key/rest-p
1785 arg-info-keys ;nil no &KEY or &REST allowed
1786 ;(k1 k2 ..) Each method must accept these &KEY arguments.
1787 ;T must have &KEY or &REST
1789 gf-info-simple-accessor-type ; nil, reader, writer, boundp
1792 gf-info-static-c-a-m-emf
1794 gf-info-fast-mf-p)
1812 ;;; Create a gf lambda list from a method lambda list
1818 argument-precedence-order)
1842 existing methods of ~S."
1843 lambda-list gf))))
1846 lambda-list
1862 arg-info))
1872 to the generic function~2I~_~S;~I~_~
1873 but ~?~:>"
1883 "the method has ~A required arguments than the generic function."
1887 "the method has ~A optional arguments than the generic function."
1891 "the method and generic function differ in whether they accept~_~
1895 allow-other-keys-p
1898 ~S."
1899 gf-keywords)))))))
1908 ;;; FIXME: we don't actually need this; we could test for the exact
1909 ;;; class and deal with it as appropriate. In fact we probably don't
1910 ;;; need it anyway because we only use this for METHOD-SPECIALIZERS on
1911 ;;; the standard reader method for METHOD-SPECIALIZERS. Probably.
1923 standard-writer-method standard-boundp-method
1924 global-reader-method global-writer-method
1925 global-boundp-method))
1955 nil)))
2003 nil)
2009 ;; FIXME: this test will eventually be
2010 ;; superseded by the *internal-pcl...* test,
2011 ;; above. While we are in a process of
2012 ;; transition, however, it should probably
2013 ;; remain.
2019 #'make-method-lambda
2030 arg-info)
2032 ;;; This is the early definition of ENSURE-GENERIC-FUNCTION-USING-CLASS.
2033 ;;;
2034 ;;; The STATIC-SLOTS field of the funcallable instances used as early
2035 ;;; generic functions is used to store the early methods and early
2036 ;;; discriminator code for the early generic function. The static
2037 ;;; slots field of the fins contains a list whose:
2038 ;;; CAR - a list of the early methods on this early gf
2039 ;;; CADR - the early discriminator code for this method
2042 lambda-list-p)
2043 argument-precedence-order
2044 definition-source
2045 documentation
2051 existing)
2055 argument-precedence-order definition-source
2056 documentation)
2064 argument-precedence-order definition-source
2065 documentation))))
2068 function argument-precedence-order source-location
2069 documentation)
2073 fin
2099 :lambda-list lambda-list
2102 fin))
2112 new-value)
2118 dfun)))
2121 ;; Check that we are under the lock.
2122 #+sb-thread
2127 new-state))))
2128 dfun)
2163 nil)
2178 class nor a symbol that names a class."
2182 ;; FIXME: reference MOP documentation -- this is an
2183 ;; additional requirement on our users
2200 method-class)
2205 ;; Use the existing lambda-list, if any. It is reasonable to do eg.
2206 ;;
2207 ;; (if (fboundp name)
2208 ;; (ensure-generic-function name)
2209 ;; (ensure-generic-function name :lambda-list '(foo)))
2210 ;;
2211 ;; in which case we end up here with no lambda-list in the first leg.
2215 t)
2224 ;; FIXME: Ideally we would like to not clobber it, but because generic
2225 ;; functions assert their FTYPEs callers believing the FTYPE are left with
2226 ;; unsafe assumptions. Hence the clobbering. Be quiet when the new type
2227 ;; is a subtype of the old one, though -- even though the type is not
2228 ;; trusted anymore, the warning is still not quite as interesting.
2232 for the same name with ~S.~:@>"
2233 fun-name 'ftype
2238 fun-name))
2242 fun-name
2243 &rest all-keys
2248 ;; KLUDGE: the above macro does SETQ on GENERIC-FUNCTION-CLASS,
2249 ;; which is what makes the next line work
2258 fun-name
2259 &rest all-keys
2270 \f
2277 ;;; FIXME: this function took on a slightly greater role than it
2278 ;;; previously had around 2005-11-02, when CSR fixed the bug whereby
2279 ;;; having more than one subclass of standard-generic-function caused
2280 ;;; the whole system to die horribly through a metacircle in
2281 ;;; GF-ARG-INFO. The fix is to be slightly more disciplined about
2282 ;;; calling accessor methods -- we call GET-GENERIC-FUN-INFO when
2283 ;;; computing discriminating functions, so we need to be careful about
2284 ;;; having a base case for the recursion, and we provide that with the
2285 ;;; STANDARD-GENERIC-FUNCTION case below. However, we are not (yet)
2286 ;;; as disciplined as CLISP's CLOS/MOP, and it would be nice to get to
2287 ;;; that stage, where all potentially dangerous cases are enumerated
2288 ;;; and stopped. -- CSR, 2005-11-02.
2290 ;; values nreq applyp metatypes nkeys arg-info
2297 metatypes
2298 arg-info))
2307 nkeys
2308 arg-info))))
2319 &key slot-name object-class method-class-function
2320 definition-source)
2323 ;; Figure out whether we got class objects or class names as the
2324 ;; specializers and set parsed and unparsed appropriately. If we
2325 ;; got class objects, then we can compute unparsed, but if we got
2326 ;; class names we don't try to compute parsed.
2327 ;;
2328 ;; Note that the use of not symbolp in this call to every should be
2329 ;; read as 'classp' we can't use classp itself because it doesn't
2330 ;; exist yet.
2335 specializers))
2337 parsed ()))
2347 ;; the parsed specializers. This is used by
2348 ;; EARLY-METHOD-SPECIALIZERS to cache the parse.
2349 ;; Note that this only comes into play when there is
2350 ;; more than one early method on an early gf.
2351 parsed
2353 ;; A list to which REAL-MAKE-A-METHOD can be applied
2354 ;; to make a real method corresponding to this early
2355 ;; one.
2358 initargs doc)
2364 result)))
2369 definition-source)
2380 :slot-definition slot-definition
2384 initargs)
2385 :definition-source definition-source
2386 initargs)))
2406 ;;; Fetch the specializers of an early method. This is basically just
2407 ;;; a simple accessor except that when the second argument is t, this
2408 ;;; converts the specializers from symbols into class objects. The
2409 ;;; class objects are cached in the early method, this makes
2410 ;;; bootstrapping faster because the class objects only have to be
2411 ;;; computed once.
2412 ;;;
2413 ;;; NOTE:
2414 ;;; The second argument should only be passed as T by
2415 ;;; early-lookup-method. This is to implement the rule that only when
2416 ;;; there is more than one early method on a generic function is the
2417 ;;; conversion from class names to class objects done. This
2418 ;;; corresponds to the fact that we are only allowed to have one
2419 ;;; method on any generic function up until the time classes exist.
2444 specializers arglist &rest initargs
2445 &key documentation definition-source
2448 ;; argument here because the default,
2449 ;; STANDARD-GENERIC-FUNCTION, is right for all early generic
2450 ;; functions. (See REAL-ADD-NAMED-METHOD)
2460 specializers initargs documentation
2465 ;;; This is the early version of ADD-METHOD. Later this will become a
2466 ;;; generic function. See !FIX-EARLY-GENERIC-FUNCTIONS which has
2467 ;;; special knowledge about ADD-METHOD.
2480 ;;; This is the early version of REMOVE-METHOD. See comments on
2481 ;;; the early version of ADD-METHOD.
2495 ;;; This is the early version of GET-METHOD. See comments on the early
2496 ;;; version of ADD-METHOD.
2502 specializers)
2504 specializers))
2509 nil))
2512 ;; minor KLUDGE: a separate code component for this function allows GCing
2513 ;; a few symbols and their associated code that would otherwise be retained:
2514 ;; *!EARLY-{GENERIC-}FUNCTIONS*, *!GENERIC-FUNCTION-FIXUPS*
2522 ;; Rearrange *!EARLY-GENERIC-FUNCTIONS* to speed up
2523 ;; FIX-EARLY-GENERIC-FUNCTIONS.
2530 generic-function-methods
2531 method-specializers
2532 specializerp
2533 specializer-type
2534 specializer-class
2535 slot-definition-location
2536 slot-definition-name
2537 class-slots
2538 gf-arg-info
2539 class-precedence-list
2540 slot-boundp-using-class
2542 slot-value-using-class
2543 structure-class-p
2544 standard-class-p
2545 funcallable-standard-class-p
2546 specializerp)))
2557 early-method))))
2560 early-method t))
2589 ()
2590 lambda-list
2591 specializers
2592 initargs
2593 nil)))
2600 \f
2601 ;;; PARSE-DEFMETHOD is used by DEFMETHOD to parse the &REST argument
2602 ;;; into the 'real' arguments. This is where the syntax of DEFMETHOD
2603 ;;; is really implemented.
2625 \f
2630 parameters))
2636 lambda-list))
2642 specializers))
2648 required-parameters))
2652 ()
2665 ;; non-standard lambda-list-keywords are errors.
2669 keyword ~S~%"
2671 ;; no multiple &rest x &rest bla specifying
2675 specialized-lambda-list keyword ~S~%"
2677 ;; And no placing &key in front of &optional, either.
2681 keyword ~S~%"
2683 ;; When we are at a lambda-list keyword, the parameters
2684 ;; don't include the lambda-list keyword; the lambda-list
2685 ;; does include the lambda-list keyword; and no
2686 ;; specializers are allowed to follow the lambda-list
2687 ;; keywords (at least for now).
2698 specialized-lambda-list-keywords)
2701 specialized-lambda-list-keywords)))))
2703 :format-control
2704 "in a specialized-lambda-list, excactly one ~
2705 variable must follow &REST.~%"
2709 ()
2710 ())))
2712 ;; After a lambda-list keyword there can be no specializers.
2715 supplied-keywords
2716 allowed-keywords)
2719 ()
2720 ())))
2724 ;; Check for valid arguments.
2736 \f
2738 \f
2739 ;;; FIXME: In here there was a #-CMU definition of SYMBOL-MACROLET
2740 ;;; which used %WALKER stuff. That suggests to me that maybe the code
2741 ;;; walker stuff was only used for implementing stuff like that; maybe
2742 ;;; it's not needed any more? Hunt down what it was used for and see.
2749 form)))
2758 ,in
2762 slot-entry
2766 slot-entry
2768 `(,var-name
2770 slots)
2780 ,in
2785 slots)