| blob | 741525af33cceb88c06efe266765be042cd03e47 |
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.
264 :name fun-name
272 fun-name
273 :lambda-list lambda-list
274 :definition-source source-location
275 initargs))
279 ()
286 :format-control
287 "~@<invalid ~S ~_in the generic function lambda list ~S~:>"
290 auxp aux morep more-context more-count)
297 ;; no defaults allowed for &OPTIONAL arguments
301 ;; no defaults allowed for &KEY arguments
312 ;; no &AUX allowed
315 lambda-list))
316 ;; Oh, *puhlease*... not specifically as per section 3.4.2 of
317 ;; the ANSI spec, but the CMU CL &MORE extension does not
318 ;; belong here!
320 \f
326 ;; :compile-toplevel is needed for subsequent forms
327 ;; :execute is needed for references to itself inside the body
329 ;; KLUDGE: this double expansion is quite a monumental
330 ;; workaround: it comes about because of a fantastic interaction
331 ;; between the processing rules of CLHS 3.2.3.1 and the
332 ;; bizarreness of MAKE-METHOD-LAMBDA.
333 ;;
334 ;; MAKE-METHOD-LAMBDA can be called by the user, and if the
335 ;; lambda itself doesn't refer to outside bindings the return
336 ;; value must be compileable in the null lexical environment.
337 ;; However, the function must also refer somehow to the
338 ;; associated method object, so that it can call NO-NEXT-METHOD
339 ;; with the appropriate arguments if there is no next method --
340 ;; but when the function is generated, the method object doesn't
341 ;; exist yet.
342 ;;
343 ;; In order to resolve this issue, we insert a literal cons cell
344 ;; into the body of the method lambda, return the same cons cell
345 ;; as part of the second (initargs) return value of
346 ;; MAKE-METHOD-LAMBDA, and a method on INITIALIZE-INSTANCE fills
347 ;; in the cell when the method is created. However, this
348 ;; strategy depends on having a fresh cons cell for every method
349 ;; lambda, which (without the workaround below) is skewered by
350 ;; the processing in CLHS 3.2.3.1, which permits implementations
351 ;; to macroexpand the bodies of EVAL-WHEN forms with both
352 ;; :COMPILE-TOPLEVEL and :LOAD-TOPLEVEL only once. The
353 ;; expansion below forces the double expansion in those cases,
354 ;; while expanding only once in the common case.
365 lambda-list body env)))
381 ;;; Take a name which is either a generic function name or a list specifying
382 ;;; a SETF generic function (like: (SETF <generic-function-name>)). Return
383 ;;; the prototype instance of the method-class for that generic function.
384 ;;;
385 ;;; If there is no generic function by that name, this returns the
386 ;;; default value, the prototype instance of the class
387 ;;; STANDARD-METHOD. This default value is also returned if the spec
388 ;;; names an ordinary function or even a macro. In effect, this leaves
389 ;;; the signalling of the appropriate error until load time.
390 ;;;
391 ;;; Note: During bootstrapping, this function is allowed to return NIL.
398 ; error at load time.
403 \f
404 ;;; These are used to communicate the method name and lambda-list to
405 ;;; MAKE-METHOD-LAMBDA-INTERNAL.
410 proto-gf
411 proto-method
412 qualifiers
413 lambda-list
414 body
415 env)
425 proto-gf proto-method method-function-lambda
426 initargs env))
428 proto-gf proto-method specializers env)))
430 ;; Note: We could DECLAIM the ftype of the generic function
431 ;; here, since ANSI specifies that we create it if it does
432 ;; not exist. However, I chose not to, because I think it's
433 ;; more useful to support a style of programming where every
434 ;; generic function has an explicit DEFGENERIC and any typos
435 ;; in DEFMETHODs are warned about. Otherwise
436 ;;
437 ;; (DEFGENERIC FOO-BAR-BLETCH (X))
438 ;; (DEFMETHOD FOO-BAR-BLETCH ((X HASH-TABLE)) ..)
439 ;; (DEFMETHOD FOO-BRA-BLETCH ((X SIMPLE-VECTOR)) ..)
440 ;; (DEFMETHOD FOO-BAR-BLETCH ((X VECTOR)) ..)
441 ;; (DEFMETHOD FOO-BAR-BLETCH ((X ARRAY)) ..)
442 ;; (DEFMETHOD FOO-BAR-BLETCH ((X LIST)) ..)
443 ;;
444 ;; compiles without raising an error and runs without
445 ;; raising an error (since SIMPLE-VECTOR cases fall through
446 ;; to VECTOR) but still doesn't do what was intended. I hate
447 ;; that kind of bug (code which silently gives the wrong
448 ;; answer), so we don't do a DECLAIM here. -- WHN 20000229
450 unspecialized-lambda-list
454 initargs-form)))))))
461 method-class-name initargs-form)
464 fn-lambda)
477 specializers)
488 ;; CONSTANT-FORM-VALUE? What I
489 ;; kind of want to know, though,
490 ;; is what happens if we don't do
491 ;; this for some slow-method
492 ;; function because of a hairy
493 ;; lexenv -- is the only bad
494 ;; effect that the method
495 ;; function ends up unnamed? If
496 ;; so, couldn't we arrange to
497 ;; name it later?
499 specl))
500 specializers))
508 name qualifiers `',specls
509 unspecialized-lambda-list method-class-name
511 #',mname
514 name qualifiers
515 specializers
516 #+nil
522 specializers))
523 unspecialized-lambda-list
524 method-class-name
525 initargs-form))))
529 method-class-name initargs-form)
531 ',method-class-name
532 ',name
533 ',qualifiers
534 ,specializers-form
535 ',unspecialized-lambda-list
536 ,initargs-form
545 proto-method
546 method-function-lambda
547 initargs
548 env))))
551 method-lambda initargs env)
556 is not a lambda form."
557 method-lambda))
564 ;;; When bootstrapping PCL MAKE-METHOD-LAMBDA starts out as a regular
565 ;;; functions: REAL-MAKE-METHOD-LAMBDA set to the fdefinition of
566 ;;; MAKE-METHOD-LAMBDA. Once generic functions are born, the
567 ;;; REAL-MAKE-METHOD lambda is used as the body of the default method.
568 ;;; MAKE-METHOD-LAMBDA-INTERNAL is split out into a separate function
569 ;;; so that changing it in a live image is easy, and changes actually
570 ;;; take effect.
588 is not a lambda form."
589 method-lambda))
592 ;; We have the %METHOD-NAME declaration in the place where we expect it only
593 ;; if there is are no non-standard prior MAKE-METHOD-LAMBDA methods -- or
594 ;; unless they're fantastically unintrusive.
597 ;; Macroexpansion caused by code-walking may call make-method-lambda and
598 ;; end up with wrong values
606 ;; the method-cell is a way of communicating what method a
607 ;; method-function implements, for the purpose of
608 ;; NO-NEXT-METHOD. We need something that can be shared
609 ;; between function and initargs, but not something that
610 ;; will be coalesced as a constant (because we are naughty,
611 ;; oh yes) with the expansion of any other methods in the
612 ;; same file. -- CSR, 2007-05-30
618 parameters
619 specializers))
623 ;; These declarations seem to be used by PCL to pass
624 ;; information to itself; when I tried to delete 'em
625 ;; ca. 0.6.10 it didn't work. I'm not sure how
626 ;; they work, but note the (VAR-DECLARATION '%CLASS ..)
627 ;; expression in CAN-OPTIMIZE-ACCESS1. -- WHN 2000-12-30
632 parameters
633 specializers))
634 ;; These TYPE declarations weren't in the original
635 ;; PCL code, but the Python compiler likes them a
636 ;; lot. (We're telling the compiler about our
637 ;; knowledge of specialized argument types so that
638 ;; it can avoid run-time type dispatch overhead,
639 ;; which can be a huge win for Python.)
640 ;;
641 ;; KLUDGE: when I tried moving these to
642 ;; ADD-METHOD-DECLARATIONS, things broke. No idea
643 ;; why. -- CSR, 2004-06-16
647 par spec specials env))
648 parameters
649 specializers))))
651 ;; Remove the documentation string and insert the
652 ;; appropriate class declarations. The documentation
653 ;; string is removed to make it easy for us to insert
654 ;; new declarations later, they will just go after the
655 ;; CADR of the method lambda. The class declarations
656 ;; are inserted to communicate the class of the method's
657 ;; arguments to the code walk.
659 ;; The default ignorability of method parameters
660 ;; doesn't seem to be specified by ANSI. PCL had
661 ;; them basically ignorable but was a little
662 ;; inconsistent. E.g. even though the two
663 ;; method definitions
664 ;; (DEFMETHOD FOO ((X T) (Y T)) "Z")
665 ;; (DEFMETHOD FOO ((X T) Y) "Z")
666 ;; are otherwise equivalent, PCL treated Y as
667 ;; ignorable in the first definition but not in the
668 ;; second definition. We make all required
669 ;; parameters ignorable as a way of systematizing
670 ;; the old PCL behavior. -- WHN 2000-11-24
672 ,class-declarations
673 ,@declarations
693 next-method-p-p setq-p
694 parameters-setqd)
696 required-parameters
697 env
698 slots)
700 walked-declarations
701 walked-documentation)
712 ,slot-name-lists
722 aux))))
725 (,lambda-list .method-args. .next-methods.
726 :call-next-method-p
734 ,@walked-declarations
737 %parameter-binding-modified))
741 %parameter-binding-modified))
756 name)
762 ;; FIXME: Document CLASS-EQ specializers.
764 :format-control
765 "~@<~S is not a valid parameter specializer name.~@:>"
778 result
780 specializer generic-function))))
788 ;; FIXME: this HANDLER-CASE is a bit of a hammer to crack a nut:
789 ;; the idea is that we want to unparse permissively, so that the
790 ;; lazy (or rather the "portable") specializer extender (who
791 ;; does not define methods on these new SBCL-specific MOP
792 ;; functions) can still subclass specializer and define methods
793 ;; without everything going wrong. Making it cleaner and
794 ;; clearer that that is what we are defending against would be
795 ;; nice. -- CSR, 2007-06-01
802 class-name
803 type))
804 type))
807 specializer generic-function)))
813 ;;; a helper function for creating Python-friendly type declarations
814 ;;; in DEFMETHOD forms.
815 ;;;
816 ;;; We're too lazy to cons up a new environment for this, so we just pass in
817 ;;; the list of locally declared specials in addition to the old environment.
822 ;; KLUDGE: ANSI, in its wisdom, says that
823 ;; EQL-SPECIALIZER-FORMs in EQL specializers are evaluated at
824 ;; DEFMETHOD expansion time. Thus, although one might think
825 ;; that in
826 ;; (DEFMETHOD FOO ((X PACKAGE)
827 ;; (Y (EQL 12))
828 ;; ..))
829 ;; the PACKAGE and (EQL 12) forms are both parallel type
830 ;; names, they're not, as is made clear when you do
831 ;; (DEFMETHOD FOO ((X PACKAGE)
832 ;; (Y (EQL 'BAR)))
833 ;; ..)
834 ;; where Y needs to be a symbol named "BAR", not some cons
835 ;; made by (CONS 'QUOTE 'BAR). I.e. when the
836 ;; EQL-SPECIALIZER-FORM is (EQL 'X), it requires an argument
837 ;; to be of type (EQL X). It'd be easy to transform one to
838 ;; the other, but it'd be somewhat messier to do so while
839 ;; ensuring that the EQL-SPECIALIZER-FORM is only EVAL'd
840 ;; once. (The new code wouldn't be messy, but it'd require a
841 ;; big transformation of the old code.) So instead we punt.
842 ;; -- WHN 20000610
845 ;; KLUDGE: For some low-level implementation
846 ;; classes, perhaps because of some problems related
847 ;; to the incomplete integration of PCL into SBCL's
848 ;; type system, some specializer classes can't be
849 ;; declared as argument types. E.g.
850 ;; (DEFMETHOD FOO ((X SLOT-OBJECT))
851 ;; (DECLARE (TYPE SLOT-OBJECT X))
852 ;; ..)
853 ;; loses when
854 ;; (DEFSTRUCT BAR A B)
855 ;; (FOO (MAKE-BAR))
856 ;; perhaps because of the way that STRUCTURE-OBJECT
857 ;; inherits both from SLOT-OBJECT and from
858 ;; SB-KERNEL:INSTANCE. In an effort to sweep such
859 ;; problems under the rug, we exclude these problem
860 ;; cases by blacklisting them here. -- WHN 2001-01-19
864 ;; KLUDGE: PCL, in its wisdom, sometimes calls methods with
865 ;; types which don't match their specializers. (Specifically,
866 ;; it calls ENSURE-CLASS-USING-CLASS (T NULL) with a non-NULL
867 ;; second argument.) Hopefully it only does this kind of
868 ;; weirdness when bootstrapping.. -- WHN 20000610
873 ;; Don't declare types for special variables -- our rebinding magic
874 ;; for SETQ cases don't work right there as SET, (SETF SYMBOL-VALUE),
875 ;; etc. make things undecidable.
878 ;; Otherwise, we can usually make Python very happy.
879 ;;
880 ;; KLUDGE: Since INFO doesn't work right for class objects here,
881 ;; and they are valid specializers, see if the specializer is
882 ;; a named class, and use the name in that case -- otherwise
883 ;; the class instance is ok, since info will just return NIL, NIL.
884 ;;
885 ;; We still need to deal with the class case too, but at
886 ;; least #.(find-class 'integer) and integer as equivalent
887 ;; specializers with this.
894 specializer))
908 ;; CLASS can be null here if the user has
909 ;; erroneously tried to use a defined type as a
910 ;; specializer; it can be a non-BUILT-IN-CLASS if
911 ;; the user defines a type and calls (SETF
912 ;; FIND-CLASS) in a consistent way.
921 ;; don't declare CLOS classes as parameters;
922 ;; it's too expensive.
925 ;; we can get here, and still not have a failure
926 ;; case, by doing MOP programming like (PROGN
927 ;; (ENSURE-CLASS 'FOO) (DEFMETHOD BAR ((X FOO))
928 ;; ...)). Best to let the user know we haven't
929 ;; been able to extract enough information:
931 "~@<can't find type for specializer ~S in ~S.~@:>"
932 specializer-nameoid
938 ;;; For passing a list (groveled by the walker) of the required
939 ;;; parameters whose bindings are modified in the method body to the
940 ;;; optimized-slot-value* macros.
944 method-args
945 next-methods
956 next-method-call
957 args
958 rest-arg
967 parameters-setqd closurep applyp method-cell))
968 &body body
981 `((%check-cnm-args cnm-args
982 ,method-args
984 nil)
992 ',method-cell
1002 ;; Can't easily provide a RETRY restart here, as the return value here is
1003 ;; for the method, not the generic function.
1005 method args)))
1023 call-method-args)
1025 value)
1046 pv
1047 next-method-call
1048 arg-info)
1051 value)
1055 ;; The two variants of INVOKE-FAST-METHOD-CALL differ in how REST-ARGs
1056 ;; are handled. The first one will get REST-ARG as a single list (as
1057 ;; the last argument), and will thus need to use APPLY. The second one
1058 ;; will get them as a &MORE argument, so we can pass the arguments
1059 ;; directly with MULTIPLE-VALUE-CALL and %MORE-ARG-VALUES.
1068 more-context
1069 more-count
1075 ,@required-args
1078 ;; The cases with only small amounts of required arguments passed
1079 ;; are probably very common, and special-casing speeds them up by
1080 ;; a factor of 2 with very little effect on the other
1081 ;; cases. Though it'd be nice to have the generic case be equally
1082 ;; fast.
1089 ,@required-args
1100 \f
1101 ;;;; effective method functions
1107 ;;; This function was in the CMU CL version of PCL (ca Debian 2.4.8)
1108 ;;; without explanation. It appears to be intended for debugging, so
1109 ;;; it might be useful someday, so I haven't deleted it.
1110 ;;; But it isn't documented and isn't used for anything now, so
1111 ;;; I've conditionalized it out of the base system. -- WHN 19991213
1112 #+sb-show
1145 ,@more-arg
1148 ,restp
1149 ,@required-args
1154 ;; "What," you may wonder, "do these next two clauses do?" In that
1155 ;; case, you are not a PCL implementor, for they considered this to
1156 ;; be self-documenting.:-| Or CSR, for that matter, since he can
1157 ;; also figure it out by looking at it without breaking stride. For
1158 ;; the rest of us, though: From what the code is doing with .SLOTS.
1159 ;; and whatnot, evidently it's implementing SLOT-VALUEish and
1160 ;; GET-SLOT-VALUEish things. Then we can reason backwards and
1161 ;; conclude that setting EMF to a FIXNUM is an optimized way to
1162 ;; represent these slot access operations.
1173 value)))))
1181 ;; (In cmucl-2.4.8 there was a commented-out third ,@(WHEN
1182 ;; ...) clause here to handle SLOT-BOUNDish stuff. Since
1183 ;; there was no explanation and presumably the code is 10+
1184 ;; years stale, I simply deleted it. -- WHN)
1185 )))
1187 ;;; Before SBCL 0.9.16.7 instead of
1188 ;;; INVOKE-NARROW-EFFECTIVE-METHOD-FUNCTION we passed a (THE (OR
1189 ;;; FUNCTION METHOD-CALL FAST-METHOD-CALL) EMF) form as the EMF. Now,
1190 ;;; to make less work for the compiler we take a path that doesn't
1191 ;;; involve the slot-accessor clause (where EMF is a FIXNUM) at all.
1206 ,@more-arg
1209 ,restp
1210 ,@required-args
1214 emf-n restp required-args))
1237 args)
1260 args))))))
1263 args
1275 value)))
1292 \f
1295 method-cell
1296 cnm-args)
1299 ,next-method-call
1311 ,@args
1317 call-next-method-p
1318 setq-p
1319 parameters-setqd
1320 method-cell
1321 next-method-p-p
1322 closurep
1323 applyp))
1324 &body body
1339 nil)
1341 ,next-method-call
1343 ,method-cell
1344 cnm-args))))
1352 ;;; CMUCL comment (Gerd Moellmann):
1353 ;;;
1354 ;;; The standard says it's an error if CALL-NEXT-METHOD is called with
1355 ;;; arguments, and the set of methods applicable to those arguments is
1356 ;;; different from the set of methods applicable to the original
1357 ;;; method arguments. (According to Barry Margolin, this rule was
1358 ;;; probably added to ensure that before and around methods are always
1359 ;;; run before primary methods.)
1360 ;;;
1361 ;;; This could be optimized for the case that the generic function
1362 ;;; doesn't have hairy methods, does have standard method combination,
1363 ;;; is a standard generic function, there are no methods defined on it
1364 ;;; for COMPUTE-APPLICABLE-METHODS and probably a lot more of such
1365 ;;; preconditions. That looks hairy and is probably not worth it,
1366 ;;; because this check will never be fast.
1368 ;; 1. Check for no arguments.
1373 ;; 2. Requirement arguments pairwise: if all are EQL, the applicable
1374 ;; methods must be the same. This takes care of the relatively common
1375 ;; case of twiddling with &KEY arguments without being horribly
1376 ;; expensive.
1383 ;; 3. Only then do the full check.
1388 ~{~S~^, ~} to call-next-method is different from ~
1389 the set of methods ~S applicable to the original ~
1390 method argument~P ~{~S~^, ~}.~@:>"
1409 "encountered the non-standard lambda list keyword ~S"
1410 var)))
1411 nil)
1459 ,@bindings
1460 (.dummy0.
1472 ;; FIXME: Do we want to export this symbol? Or maybe use an
1473 ;; (ERROR 'SIMPLE-PROGRAM-ERROR) form?
1476 return tail))
1480 ;; method definition
1482 ;; flag indicating that #'CALL-NEXT-METHOD was seen in the
1483 ;; body of a method
1485 ;; flag indicating that NEXT-METHOD-P should be in the method
1486 ;; definition
1488 ;; a list of all required parameters whose bindings might be
1489 ;; modified in the method body.
1493 ;; FIXME: Jumping to a conclusion from the way it's used
1494 ;; above, perhaps CONTEXT should be called SITUATION
1495 ;; (after the term used in the ANSI specification of
1496 ;; EVAL-WHEN) and given modern ANSI keyword values
1497 ;; like :LOAD-TOPLEVEL.
1501 t
1503 form)
1506 form)
1508 ;; The walker will split (SETQ A 1 B 2) to
1509 ;; separate (SETQ A 1) and (SETQ B 2) forms, so we
1510 ;; only need to handle the simple case of SETQ
1511 ;; here.
1516 ;; Note that we don't need to check for
1517 ;; %VARIABLE-REBINDING declarations like is
1518 ;; done in CAN-OPTIMIZE-ACCESS1, since the
1519 ;; bindings that will have that declation will
1520 ;; never be SETQd.
1522 ;; If a parameter binding is shadowed by
1523 ;; another binding it won't have a %CLASS
1524 ;; declaration anymore, and this won't get
1525 ;; executed.
1527 form)
1532 form)
1536 form)
1549 ;;; FIXME: the walker's rewriting of the source code causes
1550 ;;; trouble when doing code coverage. The rewrites should be
1551 ;;; removed, and the same operations done using
1552 ;;; compiler-macros or tranforms.
1554 walked-lambda
1555 method-lambda)
1556 call-next-method-p
1557 closurep
1558 next-method-p-p
1560 parameters-setqd)))))
1568 \f
1578 new-value)
1580 \f
1586 #+nil
1590 ll initargs source-location)))
1594 initargs source-location)
1603 :name gf-spec
1604 :new-location source-location
1605 :old-method method
1608 gf-spec qualifiers specializers lambda-list
1609 :definition-source source-location
1610 initargs)))
1613 ;; FIXME: should be STYLE-WARNING?
1615 "~&At the time the method with qualifiers ~:S and~%~
1616 specializers ~:S on the generic function ~S~%~
1617 was compiled, the method-class for that generic function was~%~
1618 ~S. But, the method class is now ~S, this~%~
1619 may mean that this method was compiled improperly.~%"
1620 qualifiers specializers gf-spec
1622 method))
1650 \f
1680 x)))
1689 After &REST, a DEFGENERIC lambda-list ~
1703 keywords keyword-parameters)
1712 old-ftype))))
1727 keywords)
1730 *))))
1731 \f
1732 ;;;; early generic function support
1736 ;; CLHS doesn't specify &allow-other-keys here but I guess the supposition
1737 ;; is that they'll be checked by ENSURE-GENERIC-FUNCTION-USING-CLASS.
1738 ;; Except we don't do that either, so I think the blame, if any, lies there
1739 ;; for not catching errant keywords.
1751 existing fun-name all-keys)))))
1755 'simple-program-error
1806 arg-info-precedence
1807 arg-info-metatypes
1808 arg-info-number-optional
1809 arg-info-key/rest-p
1810 arg-info-keys ;nil no &KEY or &REST allowed
1811 ;(k1 k2 ..) Each method must accept these &KEY arguments.
1812 ;T must have &KEY or &REST
1814 gf-info-simple-accessor-type ; nil, reader, writer, boundp
1817 gf-info-static-c-a-m-emf
1819 gf-info-fast-mf-p)
1837 ;;; Create a gf lambda list from a method lambda list
1843 argument-precedence-order)
1867 existing methods of ~S."
1868 lambda-list gf))))
1871 lambda-list
1887 arg-info))
1897 to the generic function~2I~_~S;~I~_~
1898 but ~?~:>"
1908 "the method has ~A required arguments than the generic function."
1912 "the method has ~A optional arguments than the generic function."
1916 "the method and generic function differ in whether they accept~_~
1920 allow-other-keys-p
1923 ~S."
1924 gf-keywords)))))))
1933 ;;; FIXME: we don't actually need this; we could test for the exact
1934 ;;; class and deal with it as appropriate. In fact we probably don't
1935 ;;; need it anyway because we only use this for METHOD-SPECIALIZERS on
1936 ;;; the standard reader method for METHOD-SPECIALIZERS. Probably.
1948 standard-writer-method standard-boundp-method
1949 global-reader-method global-writer-method
1950 global-boundp-method))
1980 nil)))
2028 nil)
2034 ;; FIXME: this test will eventually be
2035 ;; superseded by the *internal-pcl...* test,
2036 ;; above. While we are in a process of
2037 ;; transition, however, it should probably
2038 ;; remain.
2044 #'make-method-lambda
2055 arg-info)
2057 ;;; This is the early definition of ENSURE-GENERIC-FUNCTION-USING-CLASS.
2058 ;;;
2059 ;;; The STATIC-SLOTS field of the funcallable instances used as early
2060 ;;; generic functions is used to store the early methods and early
2061 ;;; discriminator code for the early generic function. The static
2062 ;;; slots field of the fins contains a list whose:
2063 ;;; CAR - a list of the early methods on this early gf
2064 ;;; CADR - the early discriminator code for this method
2067 lambda-list-p)
2068 argument-precedence-order
2069 definition-source
2070 documentation
2076 existing)
2080 argument-precedence-order definition-source
2081 documentation)
2089 argument-precedence-order definition-source
2090 documentation))))
2093 function argument-precedence-order source-location
2094 documentation)
2098 fin
2124 :lambda-list lambda-list
2127 fin))
2137 new-value)
2143 dfun)))
2146 ;; Check that we are under the lock.
2147 #+sb-thread
2152 new-state))))
2153 dfun)
2188 nil)
2203 class nor a symbol that names a class."
2207 ;; FIXME: reference MOP documentation -- this is an
2208 ;; additional requirement on our users
2225 method-class)
2230 ;; Use the existing lambda-list, if any. It is reasonable to do eg.
2231 ;;
2232 ;; (if (fboundp name)
2233 ;; (ensure-generic-function name)
2234 ;; (ensure-generic-function name :lambda-list '(foo)))
2235 ;;
2236 ;; in which case we end up here with no lambda-list in the first leg.
2240 t)
2249 ;; FIXME: Ideally we would like to not clobber it, but because generic
2250 ;; functions assert their FTYPEs callers believing the FTYPE are left with
2251 ;; unsafe assumptions. Hence the clobbering. Be quiet when the new type
2252 ;; is a subtype of the old one, though -- even though the type is not
2253 ;; trusted anymore, the warning is still not quite as interesting.
2257 for the same name with ~S.~:@>"
2258 fun-name 'ftype
2263 fun-name))
2267 fun-name
2268 &rest all-keys
2273 ;; KLUDGE: the above macro does SETQ on GENERIC-FUNCTION-CLASS,
2274 ;; which is what makes the next line work
2283 fun-name
2284 &rest all-keys
2295 \f
2302 ;;; FIXME: this function took on a slightly greater role than it
2303 ;;; previously had around 2005-11-02, when CSR fixed the bug whereby
2304 ;;; having more than one subclass of standard-generic-function caused
2305 ;;; the whole system to die horribly through a metacircle in
2306 ;;; GF-ARG-INFO. The fix is to be slightly more disciplined about
2307 ;;; calling accessor methods -- we call GET-GENERIC-FUN-INFO when
2308 ;;; computing discriminating functions, so we need to be careful about
2309 ;;; having a base case for the recursion, and we provide that with the
2310 ;;; STANDARD-GENERIC-FUNCTION case below. However, we are not (yet)
2311 ;;; as disciplined as CLISP's CLOS/MOP, and it would be nice to get to
2312 ;;; that stage, where all potentially dangerous cases are enumerated
2313 ;;; and stopped. -- CSR, 2005-11-02.
2315 ;; values nreq applyp metatypes nkeys arg-info
2322 metatypes
2323 arg-info))
2332 nkeys
2333 arg-info))))
2344 &key slot-name object-class method-class-function
2345 definition-source)
2348 ;; Figure out whether we got class objects or class names as the
2349 ;; specializers and set parsed and unparsed appropriately. If we
2350 ;; got class objects, then we can compute unparsed, but if we got
2351 ;; class names we don't try to compute parsed.
2352 ;;
2353 ;; Note that the use of not symbolp in this call to every should be
2354 ;; read as 'classp' we can't use classp itself because it doesn't
2355 ;; exist yet.
2360 specializers))
2362 parsed ()))
2372 ;; the parsed specializers. This is used by
2373 ;; EARLY-METHOD-SPECIALIZERS to cache the parse.
2374 ;; Note that this only comes into play when there is
2375 ;; more than one early method on an early gf.
2376 parsed
2378 ;; A list to which REAL-MAKE-A-METHOD can be applied
2379 ;; to make a real method corresponding to this early
2380 ;; one.
2383 initargs doc)
2389 result)))
2394 definition-source)
2405 :slot-definition slot-definition
2409 initargs)
2410 :definition-source definition-source
2411 initargs)))
2431 ;;; Fetch the specializers of an early method. This is basically just
2432 ;;; a simple accessor except that when the second argument is t, this
2433 ;;; converts the specializers from symbols into class objects. The
2434 ;;; class objects are cached in the early method, this makes
2435 ;;; bootstrapping faster because the class objects only have to be
2436 ;;; computed once.
2437 ;;;
2438 ;;; NOTE:
2439 ;;; The second argument should only be passed as T by
2440 ;;; early-lookup-method. This is to implement the rule that only when
2441 ;;; there is more than one early method on a generic function is the
2442 ;;; conversion from class names to class objects done. This
2443 ;;; corresponds to the fact that we are only allowed to have one
2444 ;;; method on any generic function up until the time classes exist.
2469 specializers arglist &rest initargs
2470 &key documentation definition-source
2473 ;; argument here because the default,
2474 ;; STANDARD-GENERIC-FUNCTION, is right for all early generic
2475 ;; functions. (See REAL-ADD-NAMED-METHOD)
2485 specializers initargs documentation
2490 ;;; This is the early version of ADD-METHOD. Later this will become a
2491 ;;; generic function. See !FIX-EARLY-GENERIC-FUNCTIONS which has
2492 ;;; special knowledge about ADD-METHOD.
2505 ;;; This is the early version of REMOVE-METHOD. See comments on
2506 ;;; the early version of ADD-METHOD.
2520 ;;; This is the early version of GET-METHOD. See comments on the early
2521 ;;; version of ADD-METHOD.
2527 specializers)
2529 specializers))
2534 nil))
2539 ;; Rearrange *!EARLY-GENERIC-FUNCTIONS* to speed up
2540 ;; FIX-EARLY-GENERIC-FUNCTIONS.
2547 generic-function-methods
2548 method-specializers
2549 specializerp
2550 specializer-type
2551 specializer-class
2552 slot-definition-location
2553 slot-definition-name
2554 class-slots
2555 gf-arg-info
2556 class-precedence-list
2557 slot-boundp-using-class
2559 slot-value-using-class
2560 structure-class-p
2561 standard-class-p
2562 funcallable-standard-class-p
2563 specializerp)))
2574 early-method))))
2577 early-method t))
2604 next-methods))
2609 ()
2610 lambda-list
2611 specializers
2612 initargs
2613 nil)))
2620 \f
2621 ;;; PARSE-DEFMETHOD is used by DEFMETHOD to parse the &REST argument
2622 ;;; into the 'real' arguments. This is where the syntax of DEFMETHOD
2623 ;;; is really implemented.
2645 \f
2650 parameters))
2656 lambda-list))
2662 specializers))
2668 required-parameters))
2672 ()
2685 ;; non-standard lambda-list-keywords are errors.
2689 keyword ~S~%"
2691 ;; no multiple &rest x &rest bla specifying
2695 specialized-lambda-list keyword ~S~%"
2697 ;; And no placing &key in front of &optional, either.
2701 keyword ~S~%"
2703 ;; When we are at a lambda-list keyword, the parameters
2704 ;; don't include the lambda-list keyword; the lambda-list
2705 ;; does include the lambda-list keyword; and no
2706 ;; specializers are allowed to follow the lambda-list
2707 ;; keywords (at least for now).
2718 specialized-lambda-list-keywords)
2721 specialized-lambda-list-keywords)))))
2723 :format-control
2724 "in a specialized-lambda-list, excactly one ~
2725 variable must follow &REST.~%"
2729 ()
2730 ())))
2732 ;; After a lambda-list keyword there can be no specializers.
2735 supplied-keywords
2736 allowed-keywords)
2739 ()
2740 ())))
2744 ;; Check for valid arguments.
2756 \f
2758 \f
2759 ;;; FIXME: In here there was a #-CMU definition of SYMBOL-MACROLET
2760 ;;; which used %WALKER stuff. That suggests to me that maybe the code
2761 ;;; walker stuff was only used for implementing stuff like that; maybe
2762 ;;; it's not needed any more? Hunt down what it was used for and see.
2769 form)))
2778 ,in
2782 slot-entry
2786 slot-entry
2788 `(,var-name
2790 slots)
2800 ,in
2805 slots)