| blob | bfa56ce84da4b3b2744fbdadccbef5589ca0b115 |
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
177 ;; FIXME: this list is slightly weird.
178 ;; ANSI (on the DEFGENERIC page) in one
179 ;; place allows only OPTIMIZE; in
180 ;; another place gives this list of
181 ;; disallowed declaration specifiers.
182 ;; This seems to be the only place where
183 ;; the FUNCTION declaration is
184 ;; mentioned; TYPE seems to be missing.
185 ;; Very strange. -- CSR, 2002-10-21
187 inline notinline special)))
190 is not allowed inside DEFGENERIC."
193 (:method-combination
199 symbol: ~S"
203 (:argument-precedence-order
209 :ARGUMENT-PRECEDENCE-ORDER clause."
214 :ARGUMENT-PRECEDENCE-ORDER clause: ~
215 ~S and ~S"
225 (:method
228 ;; ANSI requires that unsupported things must get a
229 ;; PROGRAM-ERROR.
262 fun-name
263 :lambda-list lambda-list
264 :definition-source source-location
265 initargs))
269 ()
276 :format-control
277 "~@<invalid ~S ~_in the generic function lambda list ~S~:>"
280 auxp aux morep more-context more-count)
287 ;; no defaults allowed for &OPTIONAL arguments
291 ;; no defaults allowed for &KEY arguments
302 ;; no &AUX allowed
305 lambda-list))
306 ;; Oh, *puhlease*... not specifically as per section 3.4.2 of
307 ;; the ANSI spec, but the CMU CL &MORE extension does not
308 ;; belong here!
310 \f
315 ;; KLUDGE: this double expansion is quite a monumental
316 ;; workaround: it comes about because of a fantastic interaction
317 ;; between the processing rules of CLHS 3.2.3.1 and the
318 ;; bizarreness of MAKE-METHOD-LAMBDA.
319 ;;
320 ;; MAKE-METHOD-LAMBDA can be called by the user, and if the
321 ;; lambda itself doesn't refer to outside bindings the return
322 ;; value must be compileable in the null lexical environment.
323 ;; However, the function must also refer somehow to the
324 ;; associated method object, so that it can call NO-NEXT-METHOD
325 ;; with the appropriate arguments if there is no next method --
326 ;; but when the function is generated, the method object doesn't
327 ;; exist yet.
328 ;;
329 ;; In order to resolve this issue, we insert a literal cons cell
330 ;; into the body of the method lambda, return the same cons cell
331 ;; as part of the second (initargs) return value of
332 ;; MAKE-METHOD-LAMBDA, and a method on INITIALIZE-INSTANCE fills
333 ;; in the cell when the method is created. However, this
334 ;; strategy depends on having a fresh cons cell for every method
335 ;; lambda, which (without the workaround below) is skewered by
336 ;; the processing in CLHS 3.2.3.1, which permits implementations
337 ;; to macroexpand the bodies of EVAL-WHEN forms with both
338 ;; :COMPILE-TOPLEVEL and :LOAD-TOPLEVEL only once. The
339 ;; expansion below forces the double expansion in those cases,
340 ;; while expanding only once in the common case.
351 lambda-list body env)))
367 ;;; Take a name which is either a generic function name or a list specifying
368 ;;; a SETF generic function (like: (SETF <generic-function-name>)). Return
369 ;;; the prototype instance of the method-class for that generic function.
370 ;;;
371 ;;; If there is no generic function by that name, this returns the
372 ;;; default value, the prototype instance of the class
373 ;;; STANDARD-METHOD. This default value is also returned if the spec
374 ;;; names an ordinary function or even a macro. In effect, this leaves
375 ;;; the signalling of the appropriate error until load time.
376 ;;;
377 ;;; Note: During bootstrapping, this function is allowed to return NIL.
384 ; error at load time.
389 \f
391 proto-gf
392 proto-method
393 qualifiers
394 lambda-list
395 body
396 env)
402 proto-gf proto-method method-function-lambda
403 initargs env))
405 proto-gf proto-method specializers env)))
407 ;; Note: We could DECLAIM the ftype of the generic function
408 ;; here, since ANSI specifies that we create it if it does
409 ;; not exist. However, I chose not to, because I think it's
410 ;; more useful to support a style of programming where every
411 ;; generic function has an explicit DEFGENERIC and any typos
412 ;; in DEFMETHODs are warned about. Otherwise
413 ;;
414 ;; (DEFGENERIC FOO-BAR-BLETCH (X))
415 ;; (DEFMETHOD FOO-BAR-BLETCH ((X HASH-TABLE)) ..)
416 ;; (DEFMETHOD FOO-BRA-BLETCH ((X SIMPLE-VECTOR)) ..)
417 ;; (DEFMETHOD FOO-BAR-BLETCH ((X VECTOR)) ..)
418 ;; (DEFMETHOD FOO-BAR-BLETCH ((X ARRAY)) ..)
419 ;; (DEFMETHOD FOO-BAR-BLETCH ((X LIST)) ..)
420 ;;
421 ;; compiles without raising an error and runs without
422 ;; raising an error (since SIMPLE-VECTOR cases fall through
423 ;; to VECTOR) but still doesn't do what was intended. I hate
424 ;; that kind of bug (code which silently gives the wrong
425 ;; answer), so we don't do a DECLAIM here. -- WHN 20000229
427 unspecialized-lambda-list
431 initargs-form))))))
438 method-class-name initargs-form)
440 fn-lambda)
453 specializers)
464 ;; CONSTANT-FORM-VALUE? What I
465 ;; kind of want to know, though,
466 ;; is what happens if we don't do
467 ;; this for some slow-method
468 ;; function because of a hairy
469 ;; lexenv -- is the only bad
470 ;; effect that the method
471 ;; function ends up unnamed? If
472 ;; so, couldn't we arrange to
473 ;; name it later?
475 specl))
476 specializers))
484 name qualifiers `',specls
485 unspecialized-lambda-list method-class-name
487 #',mname
490 name qualifiers
491 specializers
492 #+nil
498 specializers))
499 unspecialized-lambda-list
500 method-class-name
501 initargs-form))))
505 method-class-name initargs-form)
507 ',method-class-name
508 ',name
509 ',qualifiers
510 ,specializers-form
511 ',unspecialized-lambda-list
512 ,initargs-form
521 proto-method
522 method-function-lambda
523 initargs
524 env))))
534 ;; (Old PCL code used a somewhat different style of
535 ;; list for %METHOD-NAME values. Our names use
536 ;; ,@QUALIFIERS instead of ,QUALIFIERS so that the
537 ;; method names look more like what you see in a
538 ;; DEFMETHOD form.)
539 ;;
540 ;; FIXME: As of sbcl-0.7.0.6, code elsewhere, at
541 ;; least the code to set up named BLOCKs around the
542 ;; bodies of methods, depends on the function's base
543 ;; name being the first element of the %METHOD-NAME
544 ;; list. It would be good to remove this dependency,
545 ;; perhaps by building the BLOCK here, or by using
546 ;; another declaration (e.g. %BLOCK-NAME), so that
547 ;; our method debug names are free to have any format,
548 ;; e.g. (:METHOD PRINT-OBJECT :AROUND (CLOWN T)).
549 ;;
550 ;; Further, as of sbcl-0.7.9.10, the code to
551 ;; implement NO-NEXT-METHOD is coupled to the form of
552 ;; this declaration; see the definition of
553 ;; CALL-NO-NEXT-METHOD (and the passing of
554 ;; METHOD-NAME-DECLARATION arguments around the
555 ;; various CALL-NEXT-METHOD logic).
557 ,@qualifiers
560 ,@declarations
562 unspecialized-lambda-list specializers))))
565 method-lambda initargs env)
570 is not a lambda form."
571 method-lambda))
578 ;;; When bootstrapping PCL MAKE-METHOD-LAMBDA starts out as a regular
579 ;;; functions: REAL-MAKE-METHOD-LAMBDA set to the fdefinition of
580 ;;; MAKE-METHOD-LAMBDA. Once generic functions are born, the
581 ;;; REAL-MAKE-METHOD lambda is used as the body of the default method.
582 ;;; MAKE-METHOD-LAMBDA-INTERNAL is split out into a separate function
583 ;;; so that changing it in a live image is easy, and changes actually
584 ;;; take effect.
596 is not a lambda form."
597 method-lambda))
605 ;; the method-cell is a way of communicating what method a
606 ;; method-function implements, for the purpose of
607 ;; NO-NEXT-METHOD. We need something that can be shared
608 ;; between function and initargs, but not something that
609 ;; will be coalesced as a constant (because we are naughty,
610 ;; oh yes) with the expansion of any other methods in the
611 ;; same file. -- CSR, 2007-05-30
617 parameters
618 specializers))
622 ;; These declarations seem to be used by PCL to pass
623 ;; information to itself; when I tried to delete 'em
624 ;; ca. 0.6.10 it didn't work. I'm not sure how
625 ;; they work, but note the (VAR-DECLARATION '%CLASS ..)
626 ;; expression in CAN-OPTIMIZE-ACCESS1. -- WHN 2000-12-30
631 parameters
632 specializers))
633 ;; These TYPE declarations weren't in the original
634 ;; PCL code, but the Python compiler likes them a
635 ;; lot. (We're telling the compiler about our
636 ;; knowledge of specialized argument types so that
637 ;; it can avoid run-time type dispatch overhead,
638 ;; which can be a huge win for Python.)
639 ;;
640 ;; KLUDGE: when I tried moving these to
641 ;; ADD-METHOD-DECLARATIONS, things broke. No idea
642 ;; why. -- CSR, 2004-06-16
644 parameters
645 specializers)))
647 ;; Remove the documentation string and insert the
648 ;; appropriate class declarations. The documentation
649 ;; string is removed to make it easy for us to insert
650 ;; new declarations later, they will just go after the
651 ;; CADR of the method lambda. The class declarations
652 ;; are inserted to communicate the class of the method's
653 ;; arguments to the code walk.
655 ;; The default ignorability of method parameters
656 ;; doesn't seem to be specified by ANSI. PCL had
657 ;; them basically ignorable but was a little
658 ;; inconsistent. E.g. even though the two
659 ;; method definitions
660 ;; (DEFMETHOD FOO ((X T) (Y T)) "Z")
661 ;; (DEFMETHOD FOO ((X T) Y) "Z")
662 ;; are otherwise equivalent, PCL treated Y as
663 ;; ignorable in the first definition but not in the
664 ;; second definition. We make all required
665 ;; parameters ignorable as a way of systematizing
666 ;; the old PCL behavior. -- WHN 2000-11-24
668 ,class-declarations
669 ,@declarations
689 next-method-p-p setq-p
690 parameters-setqd)
692 required-parameters
693 env
694 slots)
696 walked-declarations
697 walked-documentation)
708 ,slot-name-lists
718 aux))))
721 (,lambda-list .method-args. .next-methods.
722 :call-next-method-p
723 ,call-next-method-p
729 ,@walked-declarations
732 %parameter-binding-modified))
736 %parameter-binding-modified))
749 name)
765 result
767 specializer generic-function))))
775 ;; FIXME: this HANDLER-CASE is a bit of a hammer to crack a nut:
776 ;; the idea is that we want to unparse permissively, so that the
777 ;; lazy (or rather the "portable") specializer extender (who
778 ;; does not define methods on these new SBCL-specific MOP
779 ;; functions) can still subclass specializer and define methods
780 ;; without everything going wrong. Making it cleaner and
781 ;; clearer that that is what we are defending against would be
782 ;; nice. -- CSR, 2007-06-01
789 class-name
790 type))
791 type))
794 specializer generic-function)))
800 ;;; a helper function for creating Python-friendly type declarations
801 ;;; in DEFMETHOD forms
805 ;; KLUDGE: ANSI, in its wisdom, says that
806 ;; EQL-SPECIALIZER-FORMs in EQL specializers are evaluated at
807 ;; DEFMETHOD expansion time. Thus, although one might think
808 ;; that in
809 ;; (DEFMETHOD FOO ((X PACKAGE)
810 ;; (Y (EQL 12))
811 ;; ..))
812 ;; the PACKAGE and (EQL 12) forms are both parallel type
813 ;; names, they're not, as is made clear when you do
814 ;; (DEFMETHOD FOO ((X PACKAGE)
815 ;; (Y (EQL 'BAR)))
816 ;; ..)
817 ;; where Y needs to be a symbol named "BAR", not some cons
818 ;; made by (CONS 'QUOTE 'BAR). I.e. when the
819 ;; EQL-SPECIALIZER-FORM is (EQL 'X), it requires an argument
820 ;; to be of type (EQL X). It'd be easy to transform one to
821 ;; the other, but it'd be somewhat messier to do so while
822 ;; ensuring that the EQL-SPECIALIZER-FORM is only EVAL'd
823 ;; once. (The new code wouldn't be messy, but it'd require a
824 ;; big transformation of the old code.) So instead we punt.
825 ;; -- WHN 20000610
828 ;; KLUDGE: For some low-level implementation
829 ;; classes, perhaps because of some problems related
830 ;; to the incomplete integration of PCL into SBCL's
831 ;; type system, some specializer classes can't be
832 ;; declared as argument types. E.g.
833 ;; (DEFMETHOD FOO ((X SLOT-OBJECT))
834 ;; (DECLARE (TYPE SLOT-OBJECT X))
835 ;; ..)
836 ;; loses when
837 ;; (DEFSTRUCT BAR A B)
838 ;; (FOO (MAKE-BAR))
839 ;; perhaps because of the way that STRUCTURE-OBJECT
840 ;; inherits both from SLOT-OBJECT and from
841 ;; SB-KERNEL:INSTANCE. In an effort to sweep such
842 ;; problems under the rug, we exclude these problem
843 ;; cases by blacklisting them here. -- WHN 2001-01-19
847 ;; KLUDGE: PCL, in its wisdom, sometimes calls methods with
848 ;; types which don't match their specializers. (Specifically,
849 ;; it calls ENSURE-CLASS-USING-CLASS (T NULL) with a non-NULL
850 ;; second argument.) Hopefully it only does this kind of
851 ;; weirdness when bootstrapping.. -- WHN 20000610
856 ;; KLUDGE: Don't declare types for global special variables
857 ;; -- our rebinding magic for SETQ cases don't work right
858 ;; there.
859 ;;
860 ;; FIXME: It would be better to detect the SETQ earlier and
861 ;; skip declarations for specials only when needed, not
862 ;; always.
863 ;;
864 ;; --NS 2004-10-14
867 ;; Otherwise, we can usually make Python very happy.
868 ;;
869 ;; KLUDGE: Since INFO doesn't work right for class objects here,
870 ;; and they are valid specializers, see if the specializer is
871 ;; a named class, and use the name in that case -- otherwise
872 ;; the class instance is ok, since info will just return NIL, NIL.
873 ;;
874 ;; We still need to deal with the class case too, but at
875 ;; least #.(find-class 'integer) and integer as equivalent
876 ;; specializers with this.
883 specializer))
897 ;; CLASS can be null here if the user has
898 ;; erroneously tried to use a defined type as a
899 ;; specializer; it can be a non-BUILT-IN-CLASS if
900 ;; the user defines a type and calls (SETF
901 ;; FIND-CLASS) in a consistent way.
910 ;; don't declare CLOS classes as parameters;
911 ;; it's too expensive.
914 ;; we can get here, and still not have a failure
915 ;; case, by doing MOP programming like (PROGN
916 ;; (ENSURE-CLASS 'FOO) (DEFMETHOD BAR ((X FOO))
917 ;; ...)). Best to let the user know we haven't
918 ;; been able to extract enough information:
920 "~@<can't find type for specializer ~S in ~S.~@:>"
921 specializer-nameoid
927 ;;; For passing a list (groveled by the walker) of the required
928 ;;; parameters whose bindings are modified in the method body to the
929 ;;; optimized-slot-value* macros.
933 method-args
934 next-methods
945 next-method-call
946 args
947 rest-arg
956 closurep applyp method-cell))
957 &body body
969 `((%check-cnm-args cnm-args
970 ,method-args
972 nil)
980 ',method-cell
991 method args)))
995 call-method-args)
997 value)
1018 pv
1019 next-method-call
1020 arg-info)
1023 value)
1027 ;; The two variants of INVOKE-FAST-METHOD-CALL differ in how REST-ARGs
1028 ;; are handled. The first one will get REST-ARG as a single list (as
1029 ;; the last argument), and will thus need to use APPLY. The second one
1030 ;; will get them as a &MORE argument, so we can pass the arguments
1031 ;; directly with MULTIPLE-VALUE-CALL and %MORE-ARG-VALUES.
1040 more-context
1041 more-count
1047 ,@required-args
1050 ;; The cases with only small amounts of required arguments passed
1051 ;; are probably very common, and special-casing speeds them up by
1052 ;; a factor of 2 with very little effect on the other
1053 ;; cases. Though it'd be nice to have the generic case be equally
1054 ;; fast.
1061 ,@required-args
1072 \f
1073 ;;;; effective method functions
1079 ;;; This function was in the CMU CL version of PCL (ca Debian 2.4.8)
1080 ;;; without explanation. It appears to be intended for debugging, so
1081 ;;; it might be useful someday, so I haven't deleted it.
1082 ;;; But it isn't documented and isn't used for anything now, so
1083 ;;; I've conditionalized it out of the base system. -- WHN 19991213
1084 #+sb-show
1117 ,@more-arg
1120 ,restp
1121 ,@required-args
1126 ;; "What," you may wonder, "do these next two clauses do?" In that
1127 ;; case, you are not a PCL implementor, for they considered this to
1128 ;; be self-documenting.:-| Or CSR, for that matter, since he can
1129 ;; also figure it out by looking at it without breaking stride. For
1130 ;; the rest of us, though: From what the code is doing with .SLOTS.
1131 ;; and whatnot, evidently it's implementing SLOT-VALUEish and
1132 ;; GET-SLOT-VALUEish things. Then we can reason backwards and
1133 ;; conclude that setting EMF to a FIXNUM is an optimized way to
1134 ;; represent these slot access operations.
1145 value)))))
1153 ;; (In cmucl-2.4.8 there was a commented-out third ,@(WHEN
1154 ;; ...) clause here to handle SLOT-BOUNDish stuff. Since
1155 ;; there was no explanation and presumably the code is 10+
1156 ;; years stale, I simply deleted it. -- WHN)
1157 )))
1159 ;;; Before SBCL 0.9.16.7 instead of
1160 ;;; INVOKE-NARROW-EFFECTIVE-METHOD-FUNCTION we passed a (THE (OR
1161 ;;; FUNCTION METHOD-CALL FAST-METHOD-CALL) EMF) form as the EMF. Now,
1162 ;;; to make less work for the compiler we take a path that doesn't
1163 ;;; involve the slot-accessor clause (where EMF is a FIXNUM) at all.
1178 ,@more-arg
1181 ,restp
1182 ,@required-args
1186 emf-n restp required-args))
1209 args)
1232 args))))))
1235 args
1247 value)))
1264 \f
1267 method-cell
1268 cnm-args)
1271 ,next-method-call
1283 ,@args
1289 call-next-method-p
1290 setq-p
1291 method-cell
1292 next-method-p-p
1293 closurep
1294 applyp))
1295 &body body
1310 nil)
1312 ,next-method-call
1314 ,method-cell
1315 cnm-args))))
1324 ;;; CMUCL comment (Gerd Moellmann):
1325 ;;;
1326 ;;; The standard says it's an error if CALL-NEXT-METHOD is called with
1327 ;;; arguments, and the set of methods applicable to those arguments is
1328 ;;; different from the set of methods applicable to the original
1329 ;;; method arguments. (According to Barry Margolin, this rule was
1330 ;;; probably added to ensure that before and around methods are always
1331 ;;; run before primary methods.)
1332 ;;;
1333 ;;; This could be optimized for the case that the generic function
1334 ;;; doesn't have hairy methods, does have standard method combination,
1335 ;;; is a standard generic function, there are no methods defined on it
1336 ;;; for COMPUTE-APPLICABLE-METHODS and probably a lot more of such
1337 ;;; preconditions. That looks hairy and is probably not worth it,
1338 ;;; because this check will never be fast.
1346 ~{~S~^, ~} to call-next-method is different from ~
1347 the set of methods ~S applicable to the original ~
1348 method argument~P ~{~S~^, ~}.~@:>"
1367 "encountered the non-standard lambda list keyword ~S"
1368 var)))
1369 nil)
1417 ,@bindings
1418 (.dummy0.
1430 ;; FIXME: Do we want to export this symbol? Or maybe use an
1431 ;; (ERROR 'SIMPLE-PROGRAM-ERROR) form?
1434 return tail))
1438 ;; method definition
1440 ;; flag indicating that #'CALL-NEXT-METHOD was seen in the
1441 ;; body of a method
1443 ;; flag indicating that NEXT-METHOD-P should be in the method
1444 ;; definition
1446 ;; a list of all required parameters whose bindings might be
1447 ;; modified in the method body.
1451 ;; FIXME: Jumping to a conclusion from the way it's used
1452 ;; above, perhaps CONTEXT should be called SITUATION
1453 ;; (after the term used in the ANSI specification of
1454 ;; EVAL-WHEN) and given modern ANSI keyword values
1455 ;; like :LOAD-TOPLEVEL.
1459 form)
1462 form)
1464 ;; FIXME: this is possibly a little strong as
1465 ;; conditions go. Ideally we would want to detect
1466 ;; which, if any, of the method parameters are
1467 ;; being set, and communicate that information to
1468 ;; e.g. SPLIT-DECLARATIONS. However, the brute
1469 ;; force method doesn't really cost much; a little
1470 ;; loss of discrimination over IGNORED variables
1471 ;; should be all. -- CSR, 2004-07-01
1472 ;;
1473 ;; As of 2006-09-18 modified parameter bindings
1474 ;; are now tracked with more granularity than just
1475 ;; one SETQ-P flag, in order to disable SLOT-VALUE
1476 ;; optimizations for parameters that are SETQd.
1477 ;; The old binary SETQ-P flag is still used for
1478 ;; all other purposes, since as noted above, the
1479 ;; extra cost is minimal. -- JES, 2006-09-18
1480 ;;
1481 ;; The walker will split (SETQ A 1 B 2) to
1482 ;; separate (SETQ A 1) and (SETQ B 2) forms, so we
1483 ;; only need to handle the simple case of SETQ
1484 ;; here.
1489 ;; Note that we don't need to check for
1490 ;; %VARIABLE-REBINDING declarations like is
1491 ;; done in CAN-OPTIMIZE-ACCESS1, since the
1492 ;; bindings that will have that declation will
1493 ;; never be SETQd.
1495 ;; If a parameter binding is shadowed by
1496 ;; another binding it won't have a %CLASS
1497 ;; declaration anymore, and this won't get
1498 ;; executed.
1500 form)
1505 form)
1509 form)
1522 ;;; FIXME: the walker's rewriting of the source code causes
1523 ;;; trouble when doing code coverage. The rewrites should be
1524 ;;; removed, and the same operations done using
1525 ;;; compiler-macros or tranforms.
1527 walked-lambda
1528 method-lambda)
1529 call-next-method-p
1530 closurep
1531 next-method-p-p
1533 parameters-setqd)))))
1541 \f
1551 new-value)
1553 \f
1559 #+nil
1563 ll initargs source-location)))
1567 initargs source-location)
1576 gf-spec qualifiers specializers))))
1578 gf-spec qualifiers specializers lambda-list
1579 :definition-source source-location
1580 initargs)))
1583 ;; FIXME: should be STYLE-WARNING?
1585 "~&At the time the method with qualifiers ~:S and~%~
1586 specializers ~:S on the generic function ~S~%~
1587 was compiled, the method-class for that generic function was~%~
1588 ~S. But, the method class is now ~S, this~%~
1589 may mean that this method was compiled improperly.~%"
1590 qualifiers specializers gf-spec
1592 method))
1620 \f
1650 x)))
1659 After &REST, a DEFGENERIC lambda-list ~
1673 keywords keyword-parameters)
1682 old-ftype))))
1697 keywords)
1700 *))))
1704 \f
1705 ;;;; early generic function support
1710 &rest all-keys
1711 &key environment source-location
1724 existing fun-name all-keys)))))
1728 'simple-program-error
1779 arg-info-precedence
1780 arg-info-metatypes
1781 arg-info-number-optional
1782 arg-info-key/rest-p
1783 arg-info-keys ;nil no &KEY or &REST allowed
1784 ;(k1 k2 ..) Each method must accept these &KEY arguments.
1785 ;T must have &KEY or &REST
1787 gf-info-simple-accessor-type ; nil, reader, writer, boundp
1790 gf-info-static-c-a-m-emf
1792 gf-info-fast-mf-p)
1810 ;;; Create a gf lambda list from a method lambda list
1816 argument-precedence-order)
1840 existing methods of ~S."
1841 lambda-list gf))))
1844 lambda-list
1860 arg-info))
1870 to the generic function~2I~_~S;~I~_~
1871 but ~?~:>"
1881 "the method has ~A required arguments than the generic function."
1885 "the method has ~A optional arguments than the generic function."
1889 "the method and generic function differ in whether they accept~_~
1893 allow-other-keys-p
1896 ~S."
1897 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.
1961 nil)))
2009 nil)
2014 ;; FIXME: this test will eventually be
2015 ;; superseded by the *internal-pcl...* test,
2016 ;; above. While we are in a process of
2017 ;; transition, however, it should probably
2018 ;; remain.
2024 #'make-method-lambda
2035 arg-info)
2037 ;;; This is the early definition of ENSURE-GENERIC-FUNCTION-USING-CLASS.
2038 ;;;
2039 ;;; The STATIC-SLOTS field of the funcallable instances used as early
2040 ;;; generic functions is used to store the early methods and early
2041 ;;; discriminator code for the early generic function. The static
2042 ;;; slots field of the fins contains a list whose:
2043 ;;; CAR - a list of the early methods on this early gf
2044 ;;; CADR - the early discriminator code for this method
2047 lambda-list-p)
2048 argument-precedence-order
2049 source-location
2050 documentation
2056 existing)
2060 argument-precedence-order source-location
2061 documentation)
2069 argument-precedence-order source-location
2070 documentation))))
2073 function argument-precedence-order source-location
2074 documentation)
2078 fin
2101 :lambda-list lambda-list
2104 fin))
2114 new-value)
2120 dfun)))
2123 ;; Check that we are under the lock.
2124 #+sb-thread
2129 new-state))))
2130 dfun)
2165 nil)
2180 class nor a symbol that names a class."
2184 ;; FIXME: reference MOP documentation -- this is an
2185 ;; additional requirement on our users
2200 method-class)
2205 fun-name
2206 &rest all-keys
2211 ;; KLUDGE: the above macro does SETQ on GENERIC-FUNCTION-CLASS,
2212 ;; which is what makes the next line work
2222 fun-name
2223 &rest all-keys
2235 \f
2242 ;;; FIXME: this function took on a slightly greater role than it
2243 ;;; previously had around 2005-11-02, when CSR fixed the bug whereby
2244 ;;; having more than one subclass of standard-generic-function caused
2245 ;;; the whole system to die horribly through a metacircle in
2246 ;;; GF-ARG-INFO. The fix is to be slightly more disciplined about
2247 ;;; calling accessor methods -- we call GET-GENERIC-FUN-INFO when
2248 ;;; computing discriminating functions, so we need to be careful about
2249 ;;; having a base case for the recursion, and we provide that with the
2250 ;;; STANDARD-GENERIC-FUNCTION case below. However, we are not (yet)
2251 ;;; as disciplined as CLISP's CLOS/MOP, and it would be nice to get to
2252 ;;; that stage, where all potentially dangerous cases are enumerated
2253 ;;; and stopped. -- CSR, 2005-11-02.
2255 ;; values nreq applyp metatypes nkeys arg-info
2262 metatypes
2263 arg-info))
2266 arg-info)))
2272 ;; Figure out whether we got class objects or class names as the
2273 ;; specializers and set parsed and unparsed appropriately. If we
2274 ;; got class objects, then we can compute unparsed, but if we got
2275 ;; class names we don't try to compute parsed.
2276 ;;
2277 ;; Note that the use of not symbolp in this call to every should be
2278 ;; read as 'classp' we can't use classp itself because it doesn't
2279 ;; exist yet.
2284 specializers))
2286 parsed ()))
2296 ;; the parsed specializers. This is used by
2297 ;; EARLY-METHOD-SPECIALIZERS to cache the parse.
2298 ;; Note that this only comes into play when there is
2299 ;; more than one early method on an early gf.
2300 parsed
2302 ;; A list to which REAL-MAKE-A-METHOD can be applied
2303 ;; to make a real method corresponding to this early
2304 ;; one.
2307 initargs doc)
2312 result)))
2327 :slot-definition slot-definition
2331 initargs)
2332 initargs)))
2352 ;;; Fetch the specializers of an early method. This is basically just
2353 ;;; a simple accessor except that when the second argument is t, this
2354 ;;; converts the specializers from symbols into class objects. The
2355 ;;; class objects are cached in the early method, this makes
2356 ;;; bootstrapping faster because the class objects only have to be
2357 ;;; computed once.
2358 ;;;
2359 ;;; NOTE:
2360 ;;; The second argument should only be passed as T by
2361 ;;; early-lookup-method. This is to implement the rule that only when
2362 ;;; there is more than one early method on a generic function is the
2363 ;;; conversion from class names to class objects done. This
2364 ;;; corresponds to the fact that we are only allowed to have one
2365 ;;; method on any generic function up until the time classes exist.
2392 ;; argument here because the default,
2393 ;; STANDARD-GENERIC-FUNCTION, is right for all early generic
2394 ;; functions. (See REAL-ADD-NAMED-METHOD)
2408 ;;; This is the early version of ADD-METHOD. Later this will become a
2409 ;;; generic function. See !FIX-EARLY-GENERIC-FUNCTIONS which has
2410 ;;; special knowledge about ADD-METHOD.
2423 ;;; This is the early version of REMOVE-METHOD. See comments on
2424 ;;; the early version of ADD-METHOD.
2438 ;;; This is the early version of GET-METHOD. See comments on the early
2439 ;;; version of ADD-METHOD.
2445 specializers)
2447 specializers))
2452 nil))
2457 ;; Rearrange *!EARLY-GENERIC-FUNCTIONS* to speed up
2458 ;; FIX-EARLY-GENERIC-FUNCTIONS.
2465 generic-function-methods
2466 method-specializers
2467 specializerp
2468 specializer-type
2469 specializer-class
2470 slot-definition-location
2471 slot-definition-name
2472 class-slots
2473 gf-arg-info
2474 class-precedence-list
2475 slot-boundp-using-class
2477 slot-value-using-class
2478 structure-class-p
2479 standard-class-p
2480 funcallable-standard-class-p
2481 specializerp)))
2492 early-method))))
2495 early-method t))
2522 next-methods))
2527 ()
2528 lambda-list
2529 specializers
2530 initargs
2531 nil)))
2538 \f
2539 ;;; PARSE-DEFMETHOD is used by DEFMETHOD to parse the &REST argument
2540 ;;; into the 'real' arguments. This is where the syntax of DEFMETHOD
2541 ;;; is really implemented.
2564 \f
2569 parameters))
2575 lambda-list))
2581 specializers))
2587 required-parameters))
2591 ()
2604 ;; non-standard lambda-list-keywords are errors.
2608 keyword ~S~%"
2610 ;; no multiple &rest x &rest bla specifying
2614 specialized-lambda-list keyword ~S~%"
2616 ;; And no placing &key in front of &optional, either.
2620 keyword ~S~%"
2622 ;; When we are at a lambda-list keyword, the parameters
2623 ;; don't include the lambda-list keyword; the lambda-list
2624 ;; does include the lambda-list keyword; and no
2625 ;; specializers are allowed to follow the lambda-list
2626 ;; keywords (at least for now).
2637 specialized-lambda-list-keywords)
2640 specialized-lambda-list-keywords)))))
2642 :format-control
2643 "in a specialized-lambda-list, excactly one ~
2644 variable must follow &REST.~%"
2648 ()
2649 ())))
2651 ;; After a lambda-list keyword there can be no specializers.
2654 supplied-keywords
2655 allowed-keywords)
2658 ()
2659 ())))
2667 \f
2669 \f
2670 ;;; FIXME: In here there was a #-CMU definition of SYMBOL-MACROLET
2671 ;;; which used %WALKER stuff. That suggests to me that maybe the code
2672 ;;; walker stuff was only used for implementing stuff like that; maybe
2673 ;;; it's not needed any more? Hunt down what it was used for and see.
2680 form)))
2689 ,in
2693 slot-entry
2697 slot-entry
2699 `(,var-name
2701 slots)
2711 ,in
2716 slots)