| blob | 12467fa33bbf0fa9e2e9bd1d9c24da42605fe74c |
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.
263 fun-name
264 :lambda-list lambda-list
265 :definition-source source-location
266 initargs))
270 ()
277 :format-control
278 "~@<invalid ~S ~_in the generic function lambda list ~S~:>"
281 auxp aux morep more-context more-count)
288 ;; no defaults allowed for &OPTIONAL arguments
292 ;; no defaults allowed for &KEY arguments
303 ;; no &AUX allowed
306 lambda-list))
307 ;; Oh, *puhlease*... not specifically as per section 3.4.2 of
308 ;; the ANSI spec, but the CMU CL &MORE extension does not
309 ;; belong here!
311 \f
316 ;; KLUDGE: this double expansion is quite a monumental
317 ;; workaround: it comes about because of a fantastic interaction
318 ;; between the processing rules of CLHS 3.2.3.1 and the
319 ;; bizarreness of MAKE-METHOD-LAMBDA.
320 ;;
321 ;; MAKE-METHOD-LAMBDA can be called by the user, and if the
322 ;; lambda itself doesn't refer to outside bindings the return
323 ;; value must be compileable in the null lexical environment.
324 ;; However, the function must also refer somehow to the
325 ;; associated method object, so that it can call NO-NEXT-METHOD
326 ;; with the appropriate arguments if there is no next method --
327 ;; but when the function is generated, the method object doesn't
328 ;; exist yet.
329 ;;
330 ;; In order to resolve this issue, we insert a literal cons cell
331 ;; into the body of the method lambda, return the same cons cell
332 ;; as part of the second (initargs) return value of
333 ;; MAKE-METHOD-LAMBDA, and a method on INITIALIZE-INSTANCE fills
334 ;; in the cell when the method is created. However, this
335 ;; strategy depends on having a fresh cons cell for every method
336 ;; lambda, which (without the workaround below) is skewered by
337 ;; the processing in CLHS 3.2.3.1, which permits implementations
338 ;; to macroexpand the bodies of EVAL-WHEN forms with both
339 ;; :COMPILE-TOPLEVEL and :LOAD-TOPLEVEL only once. The
340 ;; expansion below forces the double expansion in those cases,
341 ;; while expanding only once in the common case.
352 lambda-list body env)))
368 ;;; Take a name which is either a generic function name or a list specifying
369 ;;; a SETF generic function (like: (SETF <generic-function-name>)). Return
370 ;;; the prototype instance of the method-class for that generic function.
371 ;;;
372 ;;; If there is no generic function by that name, this returns the
373 ;;; default value, the prototype instance of the class
374 ;;; STANDARD-METHOD. This default value is also returned if the spec
375 ;;; names an ordinary function or even a macro. In effect, this leaves
376 ;;; the signalling of the appropriate error until load time.
377 ;;;
378 ;;; Note: During bootstrapping, this function is allowed to return NIL.
385 ; error at load time.
390 \f
392 proto-gf
393 proto-method
394 qualifiers
395 lambda-list
396 body
397 env)
403 proto-gf proto-method method-function-lambda
404 initargs env))
406 proto-gf proto-method specializers env)))
408 ;; Note: We could DECLAIM the ftype of the generic function
409 ;; here, since ANSI specifies that we create it if it does
410 ;; not exist. However, I chose not to, because I think it's
411 ;; more useful to support a style of programming where every
412 ;; generic function has an explicit DEFGENERIC and any typos
413 ;; in DEFMETHODs are warned about. Otherwise
414 ;;
415 ;; (DEFGENERIC FOO-BAR-BLETCH (X))
416 ;; (DEFMETHOD FOO-BAR-BLETCH ((X HASH-TABLE)) ..)
417 ;; (DEFMETHOD FOO-BRA-BLETCH ((X SIMPLE-VECTOR)) ..)
418 ;; (DEFMETHOD FOO-BAR-BLETCH ((X VECTOR)) ..)
419 ;; (DEFMETHOD FOO-BAR-BLETCH ((X ARRAY)) ..)
420 ;; (DEFMETHOD FOO-BAR-BLETCH ((X LIST)) ..)
421 ;;
422 ;; compiles without raising an error and runs without
423 ;; raising an error (since SIMPLE-VECTOR cases fall through
424 ;; to VECTOR) but still doesn't do what was intended. I hate
425 ;; that kind of bug (code which silently gives the wrong
426 ;; answer), so we don't do a DECLAIM here. -- WHN 20000229
428 unspecialized-lambda-list
432 initargs-form))))))
439 method-class-name initargs-form)
441 fn-lambda)
454 specializers)
465 ;; CONSTANT-FORM-VALUE? What I
466 ;; kind of want to know, though,
467 ;; is what happens if we don't do
468 ;; this for some slow-method
469 ;; function because of a hairy
470 ;; lexenv -- is the only bad
471 ;; effect that the method
472 ;; function ends up unnamed? If
473 ;; so, couldn't we arrange to
474 ;; name it later?
476 specl))
477 specializers))
485 name qualifiers `',specls
486 unspecialized-lambda-list method-class-name
488 #',mname
491 name qualifiers
492 specializers
493 #+nil
499 specializers))
500 unspecialized-lambda-list
501 method-class-name
502 initargs-form))))
506 method-class-name initargs-form)
508 ',method-class-name
509 ',name
510 ',qualifiers
511 ,specializers-form
512 ',unspecialized-lambda-list
513 ,initargs-form
522 proto-method
523 method-function-lambda
524 initargs
525 env))))
535 ;; (Old PCL code used a somewhat different style of
536 ;; list for %METHOD-NAME values. Our names use
537 ;; ,@QUALIFIERS instead of ,QUALIFIERS so that the
538 ;; method names look more like what you see in a
539 ;; DEFMETHOD form.)
540 ;;
541 ;; FIXME: As of sbcl-0.7.0.6, code elsewhere, at
542 ;; least the code to set up named BLOCKs around the
543 ;; bodies of methods, depends on the function's base
544 ;; name being the first element of the %METHOD-NAME
545 ;; list. It would be good to remove this dependency,
546 ;; perhaps by building the BLOCK here, or by using
547 ;; another declaration (e.g. %BLOCK-NAME), so that
548 ;; our method debug names are free to have any format,
549 ;; e.g. (:METHOD PRINT-OBJECT :AROUND (CLOWN T)).
550 ;;
551 ;; Further, as of sbcl-0.7.9.10, the code to
552 ;; implement NO-NEXT-METHOD is coupled to the form of
553 ;; this declaration; see the definition of
554 ;; CALL-NO-NEXT-METHOD (and the passing of
555 ;; METHOD-NAME-DECLARATION arguments around the
556 ;; various CALL-NEXT-METHOD logic).
558 ,@qualifiers
561 ,@declarations
563 unspecialized-lambda-list specializers))))
566 method-lambda initargs env)
571 is not a lambda form."
572 method-lambda))
579 ;;; When bootstrapping PCL MAKE-METHOD-LAMBDA starts out as a regular
580 ;;; functions: REAL-MAKE-METHOD-LAMBDA set to the fdefinition of
581 ;;; MAKE-METHOD-LAMBDA. Once generic functions are born, the
582 ;;; REAL-MAKE-METHOD lambda is used as the body of the default method.
583 ;;; MAKE-METHOD-LAMBDA-INTERNAL is split out into a separate function
584 ;;; so that changing it in a live image is easy, and changes actually
585 ;;; take effect.
603 is not a lambda form."
604 method-lambda))
612 ;; the method-cell is a way of communicating what method a
613 ;; method-function implements, for the purpose of
614 ;; NO-NEXT-METHOD. We need something that can be shared
615 ;; between function and initargs, but not something that
616 ;; will be coalesced as a constant (because we are naughty,
617 ;; oh yes) with the expansion of any other methods in the
618 ;; same file. -- CSR, 2007-05-30
624 parameters
625 specializers))
629 ;; These declarations seem to be used by PCL to pass
630 ;; information to itself; when I tried to delete 'em
631 ;; ca. 0.6.10 it didn't work. I'm not sure how
632 ;; they work, but note the (VAR-DECLARATION '%CLASS ..)
633 ;; expression in CAN-OPTIMIZE-ACCESS1. -- WHN 2000-12-30
638 parameters
639 specializers))
640 ;; These TYPE declarations weren't in the original
641 ;; PCL code, but the Python compiler likes them a
642 ;; lot. (We're telling the compiler about our
643 ;; knowledge of specialized argument types so that
644 ;; it can avoid run-time type dispatch overhead,
645 ;; which can be a huge win for Python.)
646 ;;
647 ;; KLUDGE: when I tried moving these to
648 ;; ADD-METHOD-DECLARATIONS, things broke. No idea
649 ;; why. -- CSR, 2004-06-16
653 par spec specials env))
654 parameters
655 specializers))))
657 ;; Remove the documentation string and insert the
658 ;; appropriate class declarations. The documentation
659 ;; string is removed to make it easy for us to insert
660 ;; new declarations later, they will just go after the
661 ;; CADR of the method lambda. The class declarations
662 ;; are inserted to communicate the class of the method's
663 ;; arguments to the code walk.
665 ;; The default ignorability of method parameters
666 ;; doesn't seem to be specified by ANSI. PCL had
667 ;; them basically ignorable but was a little
668 ;; inconsistent. E.g. even though the two
669 ;; method definitions
670 ;; (DEFMETHOD FOO ((X T) (Y T)) "Z")
671 ;; (DEFMETHOD FOO ((X T) Y) "Z")
672 ;; are otherwise equivalent, PCL treated Y as
673 ;; ignorable in the first definition but not in the
674 ;; second definition. We make all required
675 ;; parameters ignorable as a way of systematizing
676 ;; the old PCL behavior. -- WHN 2000-11-24
678 ,class-declarations
679 ,@declarations
699 next-method-p-p setq-p
700 parameters-setqd)
702 required-parameters
703 env
704 slots)
706 walked-declarations
707 walked-documentation)
718 ,slot-name-lists
728 aux))))
731 (,lambda-list .method-args. .next-methods.
732 :call-next-method-p
733 ,call-next-method-p
739 ,@walked-declarations
742 %parameter-binding-modified))
746 %parameter-binding-modified))
759 name)
775 result
777 specializer generic-function))))
785 ;; FIXME: this HANDLER-CASE is a bit of a hammer to crack a nut:
786 ;; the idea is that we want to unparse permissively, so that the
787 ;; lazy (or rather the "portable") specializer extender (who
788 ;; does not define methods on these new SBCL-specific MOP
789 ;; functions) can still subclass specializer and define methods
790 ;; without everything going wrong. Making it cleaner and
791 ;; clearer that that is what we are defending against would be
792 ;; nice. -- CSR, 2007-06-01
799 class-name
800 type))
801 type))
804 specializer generic-function)))
810 ;;; a helper function for creating Python-friendly type declarations
811 ;;; in DEFMETHOD forms.
812 ;;;
813 ;;; We're too lazy to cons up a new environment for this, so we just pass in
814 ;;; the list of locally declared specials in addition to the old environment.
819 ;; KLUDGE: ANSI, in its wisdom, says that
820 ;; EQL-SPECIALIZER-FORMs in EQL specializers are evaluated at
821 ;; DEFMETHOD expansion time. Thus, although one might think
822 ;; that in
823 ;; (DEFMETHOD FOO ((X PACKAGE)
824 ;; (Y (EQL 12))
825 ;; ..))
826 ;; the PACKAGE and (EQL 12) forms are both parallel type
827 ;; names, they're not, as is made clear when you do
828 ;; (DEFMETHOD FOO ((X PACKAGE)
829 ;; (Y (EQL 'BAR)))
830 ;; ..)
831 ;; where Y needs to be a symbol named "BAR", not some cons
832 ;; made by (CONS 'QUOTE 'BAR). I.e. when the
833 ;; EQL-SPECIALIZER-FORM is (EQL 'X), it requires an argument
834 ;; to be of type (EQL X). It'd be easy to transform one to
835 ;; the other, but it'd be somewhat messier to do so while
836 ;; ensuring that the EQL-SPECIALIZER-FORM is only EVAL'd
837 ;; once. (The new code wouldn't be messy, but it'd require a
838 ;; big transformation of the old code.) So instead we punt.
839 ;; -- WHN 20000610
842 ;; KLUDGE: For some low-level implementation
843 ;; classes, perhaps because of some problems related
844 ;; to the incomplete integration of PCL into SBCL's
845 ;; type system, some specializer classes can't be
846 ;; declared as argument types. E.g.
847 ;; (DEFMETHOD FOO ((X SLOT-OBJECT))
848 ;; (DECLARE (TYPE SLOT-OBJECT X))
849 ;; ..)
850 ;; loses when
851 ;; (DEFSTRUCT BAR A B)
852 ;; (FOO (MAKE-BAR))
853 ;; perhaps because of the way that STRUCTURE-OBJECT
854 ;; inherits both from SLOT-OBJECT and from
855 ;; SB-KERNEL:INSTANCE. In an effort to sweep such
856 ;; problems under the rug, we exclude these problem
857 ;; cases by blacklisting them here. -- WHN 2001-01-19
861 ;; KLUDGE: PCL, in its wisdom, sometimes calls methods with
862 ;; types which don't match their specializers. (Specifically,
863 ;; it calls ENSURE-CLASS-USING-CLASS (T NULL) with a non-NULL
864 ;; second argument.) Hopefully it only does this kind of
865 ;; weirdness when bootstrapping.. -- WHN 20000610
870 ;; Don't declare types for special variables -- our rebinding magic
871 ;; for SETQ cases don't work right there as SET, (SETF SYMBOL-VALUE),
872 ;; etc. make things undecidable.
875 ;; Otherwise, we can usually make Python very happy.
876 ;;
877 ;; KLUDGE: Since INFO doesn't work right for class objects here,
878 ;; and they are valid specializers, see if the specializer is
879 ;; a named class, and use the name in that case -- otherwise
880 ;; the class instance is ok, since info will just return NIL, NIL.
881 ;;
882 ;; We still need to deal with the class case too, but at
883 ;; least #.(find-class 'integer) and integer as equivalent
884 ;; specializers with this.
891 specializer))
905 ;; CLASS can be null here if the user has
906 ;; erroneously tried to use a defined type as a
907 ;; specializer; it can be a non-BUILT-IN-CLASS if
908 ;; the user defines a type and calls (SETF
909 ;; FIND-CLASS) in a consistent way.
918 ;; don't declare CLOS classes as parameters;
919 ;; it's too expensive.
922 ;; we can get here, and still not have a failure
923 ;; case, by doing MOP programming like (PROGN
924 ;; (ENSURE-CLASS 'FOO) (DEFMETHOD BAR ((X FOO))
925 ;; ...)). Best to let the user know we haven't
926 ;; been able to extract enough information:
928 "~@<can't find type for specializer ~S in ~S.~@:>"
929 specializer-nameoid
935 ;;; For passing a list (groveled by the walker) of the required
936 ;;; parameters whose bindings are modified in the method body to the
937 ;;; optimized-slot-value* macros.
941 method-args
942 next-methods
953 next-method-call
954 args
955 rest-arg
964 closurep applyp method-cell))
965 &body body
977 `((%check-cnm-args cnm-args
978 ,method-args
980 nil)
988 ',method-cell
999 method args)))
1003 call-method-args)
1005 value)
1026 pv
1027 next-method-call
1028 arg-info)
1031 value)
1035 ;; The two variants of INVOKE-FAST-METHOD-CALL differ in how REST-ARGs
1036 ;; are handled. The first one will get REST-ARG as a single list (as
1037 ;; the last argument), and will thus need to use APPLY. The second one
1038 ;; will get them as a &MORE argument, so we can pass the arguments
1039 ;; directly with MULTIPLE-VALUE-CALL and %MORE-ARG-VALUES.
1048 more-context
1049 more-count
1055 ,@required-args
1058 ;; The cases with only small amounts of required arguments passed
1059 ;; are probably very common, and special-casing speeds them up by
1060 ;; a factor of 2 with very little effect on the other
1061 ;; cases. Though it'd be nice to have the generic case be equally
1062 ;; fast.
1069 ,@required-args
1080 \f
1081 ;;;; effective method functions
1087 ;;; This function was in the CMU CL version of PCL (ca Debian 2.4.8)
1088 ;;; without explanation. It appears to be intended for debugging, so
1089 ;;; it might be useful someday, so I haven't deleted it.
1090 ;;; But it isn't documented and isn't used for anything now, so
1091 ;;; I've conditionalized it out of the base system. -- WHN 19991213
1092 #+sb-show
1125 ,@more-arg
1128 ,restp
1129 ,@required-args
1134 ;; "What," you may wonder, "do these next two clauses do?" In that
1135 ;; case, you are not a PCL implementor, for they considered this to
1136 ;; be self-documenting.:-| Or CSR, for that matter, since he can
1137 ;; also figure it out by looking at it without breaking stride. For
1138 ;; the rest of us, though: From what the code is doing with .SLOTS.
1139 ;; and whatnot, evidently it's implementing SLOT-VALUEish and
1140 ;; GET-SLOT-VALUEish things. Then we can reason backwards and
1141 ;; conclude that setting EMF to a FIXNUM is an optimized way to
1142 ;; represent these slot access operations.
1153 value)))))
1161 ;; (In cmucl-2.4.8 there was a commented-out third ,@(WHEN
1162 ;; ...) clause here to handle SLOT-BOUNDish stuff. Since
1163 ;; there was no explanation and presumably the code is 10+
1164 ;; years stale, I simply deleted it. -- WHN)
1165 )))
1167 ;;; Before SBCL 0.9.16.7 instead of
1168 ;;; INVOKE-NARROW-EFFECTIVE-METHOD-FUNCTION we passed a (THE (OR
1169 ;;; FUNCTION METHOD-CALL FAST-METHOD-CALL) EMF) form as the EMF. Now,
1170 ;;; to make less work for the compiler we take a path that doesn't
1171 ;;; involve the slot-accessor clause (where EMF is a FIXNUM) at all.
1186 ,@more-arg
1189 ,restp
1190 ,@required-args
1194 emf-n restp required-args))
1217 args)
1240 args))))))
1243 args
1255 value)))
1272 \f
1275 method-cell
1276 cnm-args)
1279 ,next-method-call
1291 ,@args
1297 call-next-method-p
1298 setq-p
1299 method-cell
1300 next-method-p-p
1301 closurep
1302 applyp))
1303 &body body
1318 nil)
1320 ,next-method-call
1322 ,method-cell
1323 cnm-args))))
1332 ;;; CMUCL comment (Gerd Moellmann):
1333 ;;;
1334 ;;; The standard says it's an error if CALL-NEXT-METHOD is called with
1335 ;;; arguments, and the set of methods applicable to those arguments is
1336 ;;; different from the set of methods applicable to the original
1337 ;;; method arguments. (According to Barry Margolin, this rule was
1338 ;;; probably added to ensure that before and around methods are always
1339 ;;; run before primary methods.)
1340 ;;;
1341 ;;; This could be optimized for the case that the generic function
1342 ;;; doesn't have hairy methods, does have standard method combination,
1343 ;;; is a standard generic function, there are no methods defined on it
1344 ;;; for COMPUTE-APPLICABLE-METHODS and probably a lot more of such
1345 ;;; preconditions. That looks hairy and is probably not worth it,
1346 ;;; because this check will never be fast.
1354 ~{~S~^, ~} to call-next-method is different from ~
1355 the set of methods ~S applicable to the original ~
1356 method argument~P ~{~S~^, ~}.~@:>"
1375 "encountered the non-standard lambda list keyword ~S"
1376 var)))
1377 nil)
1425 ,@bindings
1426 (.dummy0.
1438 ;; FIXME: Do we want to export this symbol? Or maybe use an
1439 ;; (ERROR 'SIMPLE-PROGRAM-ERROR) form?
1442 return tail))
1446 ;; method definition
1448 ;; flag indicating that #'CALL-NEXT-METHOD was seen in the
1449 ;; body of a method
1451 ;; flag indicating that NEXT-METHOD-P should be in the method
1452 ;; definition
1454 ;; a list of all required parameters whose bindings might be
1455 ;; modified in the method body.
1459 ;; FIXME: Jumping to a conclusion from the way it's used
1460 ;; above, perhaps CONTEXT should be called SITUATION
1461 ;; (after the term used in the ANSI specification of
1462 ;; EVAL-WHEN) and given modern ANSI keyword values
1463 ;; like :LOAD-TOPLEVEL.
1467 form)
1470 form)
1472 ;; FIXME: this is possibly a little strong as
1473 ;; conditions go. Ideally we would want to detect
1474 ;; which, if any, of the method parameters are
1475 ;; being set, and communicate that information to
1476 ;; e.g. SPLIT-DECLARATIONS. However, the brute
1477 ;; force method doesn't really cost much; a little
1478 ;; loss of discrimination over IGNORED variables
1479 ;; should be all. -- CSR, 2004-07-01
1480 ;;
1481 ;; As of 2006-09-18 modified parameter bindings
1482 ;; are now tracked with more granularity than just
1483 ;; one SETQ-P flag, in order to disable SLOT-VALUE
1484 ;; optimizations for parameters that are SETQd.
1485 ;; The old binary SETQ-P flag is still used for
1486 ;; all other purposes, since as noted above, the
1487 ;; extra cost is minimal. -- JES, 2006-09-18
1488 ;;
1489 ;; The walker will split (SETQ A 1 B 2) to
1490 ;; separate (SETQ A 1) and (SETQ B 2) forms, so we
1491 ;; only need to handle the simple case of SETQ
1492 ;; here.
1497 ;; Note that we don't need to check for
1498 ;; %VARIABLE-REBINDING declarations like is
1499 ;; done in CAN-OPTIMIZE-ACCESS1, since the
1500 ;; bindings that will have that declation will
1501 ;; never be SETQd.
1503 ;; If a parameter binding is shadowed by
1504 ;; another binding it won't have a %CLASS
1505 ;; declaration anymore, and this won't get
1506 ;; executed.
1508 form)
1513 form)
1517 form)
1530 ;;; FIXME: the walker's rewriting of the source code causes
1531 ;;; trouble when doing code coverage. The rewrites should be
1532 ;;; removed, and the same operations done using
1533 ;;; compiler-macros or tranforms.
1535 walked-lambda
1536 method-lambda)
1537 call-next-method-p
1538 closurep
1539 next-method-p-p
1541 parameters-setqd)))))
1549 \f
1559 new-value)
1561 \f
1567 #+nil
1571 ll initargs source-location)))
1575 initargs source-location)
1588 gf-spec qualifiers specializers lambda-list
1589 :definition-source source-location
1590 initargs)))
1593 ;; FIXME: should be STYLE-WARNING?
1595 "~&At the time the method with qualifiers ~:S and~%~
1596 specializers ~:S on the generic function ~S~%~
1597 was compiled, the method-class for that generic function was~%~
1598 ~S. But, the method class is now ~S, this~%~
1599 may mean that this method was compiled improperly.~%"
1600 qualifiers specializers gf-spec
1602 method))
1630 \f
1660 x)))
1669 After &REST, a DEFGENERIC lambda-list ~
1683 keywords keyword-parameters)
1692 old-ftype))))
1707 keywords)
1710 *))))
1711 \f
1712 ;;;; early generic function support
1717 &rest all-keys
1718 &key environment source-location
1731 existing fun-name all-keys)))))
1735 'simple-program-error
1786 arg-info-precedence
1787 arg-info-metatypes
1788 arg-info-number-optional
1789 arg-info-key/rest-p
1790 arg-info-keys ;nil no &KEY or &REST allowed
1791 ;(k1 k2 ..) Each method must accept these &KEY arguments.
1792 ;T must have &KEY or &REST
1794 gf-info-simple-accessor-type ; nil, reader, writer, boundp
1797 gf-info-static-c-a-m-emf
1799 gf-info-fast-mf-p)
1817 ;;; Create a gf lambda list from a method lambda list
1823 argument-precedence-order)
1847 existing methods of ~S."
1848 lambda-list gf))))
1851 lambda-list
1867 arg-info))
1877 to the generic function~2I~_~S;~I~_~
1878 but ~?~:>"
1888 "the method has ~A required arguments than the generic function."
1892 "the method has ~A optional arguments than the generic function."
1896 "the method and generic function differ in whether they accept~_~
1900 allow-other-keys-p
1903 ~S."
1904 gf-keywords)))))))
1915 ;;; FIXME: we don't actually need this; we could test for the exact
1916 ;;; class and deal with it as appropriate. In fact we probably don't
1917 ;;; need it anyway because we only use this for METHOD-SPECIALIZERS on
1918 ;;; the standard reader method for METHOD-SPECIALIZERS. Probably.
1965 nil)))
2013 nil)
2019 ;; FIXME: this test will eventually be
2020 ;; superseded by the *internal-pcl...* test,
2021 ;; above. While we are in a process of
2022 ;; transition, however, it should probably
2023 ;; remain.
2029 #'make-method-lambda
2040 arg-info)
2042 ;;; This is the early definition of ENSURE-GENERIC-FUNCTION-USING-CLASS.
2043 ;;;
2044 ;;; The STATIC-SLOTS field of the funcallable instances used as early
2045 ;;; generic functions is used to store the early methods and early
2046 ;;; discriminator code for the early generic function. The static
2047 ;;; slots field of the fins contains a list whose:
2048 ;;; CAR - a list of the early methods on this early gf
2049 ;;; CADR - the early discriminator code for this method
2052 lambda-list-p)
2053 argument-precedence-order
2054 source-location
2055 documentation
2061 existing)
2065 argument-precedence-order source-location
2066 documentation)
2074 argument-precedence-order source-location
2075 documentation))))
2078 function argument-precedence-order source-location
2079 documentation)
2083 fin
2109 :lambda-list lambda-list
2112 fin))
2122 new-value)
2128 dfun)))
2131 ;; Check that we are under the lock.
2132 #+sb-thread
2137 new-state))))
2138 dfun)
2173 nil)
2188 class nor a symbol that names a class."
2192 ;; FIXME: reference MOP documentation -- this is an
2193 ;; additional requirement on our users
2208 method-class)
2213 fun-name
2214 &rest all-keys
2219 ;; KLUDGE: the above macro does SETQ on GENERIC-FUNCTION-CLASS,
2220 ;; which is what makes the next line work
2233 fun-name
2234 &rest all-keys
2249 \f
2256 ;;; FIXME: this function took on a slightly greater role than it
2257 ;;; previously had around 2005-11-02, when CSR fixed the bug whereby
2258 ;;; having more than one subclass of standard-generic-function caused
2259 ;;; the whole system to die horribly through a metacircle in
2260 ;;; GF-ARG-INFO. The fix is to be slightly more disciplined about
2261 ;;; calling accessor methods -- we call GET-GENERIC-FUN-INFO when
2262 ;;; computing discriminating functions, so we need to be careful about
2263 ;;; having a base case for the recursion, and we provide that with the
2264 ;;; STANDARD-GENERIC-FUNCTION case below. However, we are not (yet)
2265 ;;; as disciplined as CLISP's CLOS/MOP, and it would be nice to get to
2266 ;;; that stage, where all potentially dangerous cases are enumerated
2267 ;;; and stopped. -- CSR, 2005-11-02.
2269 ;; values nreq applyp metatypes nkeys arg-info
2276 metatypes
2277 arg-info))
2280 arg-info)))
2283 &key slot-name object-class method-class-function
2284 definition-source)
2287 ;; Figure out whether we got class objects or class names as the
2288 ;; specializers and set parsed and unparsed appropriately. If we
2289 ;; got class objects, then we can compute unparsed, but if we got
2290 ;; class names we don't try to compute parsed.
2291 ;;
2292 ;; Note that the use of not symbolp in this call to every should be
2293 ;; read as 'classp' we can't use classp itself because it doesn't
2294 ;; exist yet.
2299 specializers))
2301 parsed ()))
2311 ;; the parsed specializers. This is used by
2312 ;; EARLY-METHOD-SPECIALIZERS to cache the parse.
2313 ;; Note that this only comes into play when there is
2314 ;; more than one early method on an early gf.
2315 parsed
2317 ;; A list to which REAL-MAKE-A-METHOD can be applied
2318 ;; to make a real method corresponding to this early
2319 ;; one.
2322 initargs doc)
2328 result)))
2333 definition-source)
2344 :slot-definition slot-definition
2348 initargs)
2349 :definition-source definition-source
2350 initargs)))
2370 ;;; Fetch the specializers of an early method. This is basically just
2371 ;;; a simple accessor except that when the second argument is t, this
2372 ;;; converts the specializers from symbols into class objects. The
2373 ;;; class objects are cached in the early method, this makes
2374 ;;; bootstrapping faster because the class objects only have to be
2375 ;;; computed once.
2376 ;;;
2377 ;;; NOTE:
2378 ;;; The second argument should only be passed as T by
2379 ;;; early-lookup-method. This is to implement the rule that only when
2380 ;;; there is more than one early method on a generic function is the
2381 ;;; conversion from class names to class objects done. This
2382 ;;; corresponds to the fact that we are only allowed to have one
2383 ;;; method on any generic function up until the time classes exist.
2408 specializers arglist &rest initargs
2409 &key documentation definition-source
2412 ;; argument here because the default,
2413 ;; STANDARD-GENERIC-FUNCTION, is right for all early generic
2414 ;; functions. (See REAL-ADD-NAMED-METHOD)
2424 specializers initargs documentation
2429 ;;; This is the early version of ADD-METHOD. Later this will become a
2430 ;;; generic function. See !FIX-EARLY-GENERIC-FUNCTIONS which has
2431 ;;; special knowledge about ADD-METHOD.
2444 ;;; This is the early version of REMOVE-METHOD. See comments on
2445 ;;; the early version of ADD-METHOD.
2459 ;;; This is the early version of GET-METHOD. See comments on the early
2460 ;;; version of ADD-METHOD.
2466 specializers)
2468 specializers))
2473 nil))
2478 ;; Rearrange *!EARLY-GENERIC-FUNCTIONS* to speed up
2479 ;; FIX-EARLY-GENERIC-FUNCTIONS.
2486 generic-function-methods
2487 method-specializers
2488 specializerp
2489 specializer-type
2490 specializer-class
2491 slot-definition-location
2492 slot-definition-name
2493 class-slots
2494 gf-arg-info
2495 class-precedence-list
2496 slot-boundp-using-class
2498 slot-value-using-class
2499 structure-class-p
2500 standard-class-p
2501 funcallable-standard-class-p
2502 specializerp)))
2513 early-method))))
2516 early-method t))
2543 next-methods))
2548 ()
2549 lambda-list
2550 specializers
2551 initargs
2552 nil)))
2559 \f
2560 ;;; PARSE-DEFMETHOD is used by DEFMETHOD to parse the &REST argument
2561 ;;; into the 'real' arguments. This is where the syntax of DEFMETHOD
2562 ;;; is really implemented.
2585 \f
2590 parameters))
2596 lambda-list))
2602 specializers))
2608 required-parameters))
2612 ()
2625 ;; non-standard lambda-list-keywords are errors.
2629 keyword ~S~%"
2631 ;; no multiple &rest x &rest bla specifying
2635 specialized-lambda-list keyword ~S~%"
2637 ;; And no placing &key in front of &optional, either.
2641 keyword ~S~%"
2643 ;; When we are at a lambda-list keyword, the parameters
2644 ;; don't include the lambda-list keyword; the lambda-list
2645 ;; does include the lambda-list keyword; and no
2646 ;; specializers are allowed to follow the lambda-list
2647 ;; keywords (at least for now).
2658 specialized-lambda-list-keywords)
2661 specialized-lambda-list-keywords)))))
2663 :format-control
2664 "in a specialized-lambda-list, excactly one ~
2665 variable must follow &REST.~%"
2669 ()
2670 ())))
2672 ;; After a lambda-list keyword there can be no specializers.
2675 supplied-keywords
2676 allowed-keywords)
2679 ()
2680 ())))
2688 \f
2690 \f
2691 ;;; FIXME: In here there was a #-CMU definition of SYMBOL-MACROLET
2692 ;;; which used %WALKER stuff. That suggests to me that maybe the code
2693 ;;; walker stuff was only used for implementing stuff like that; maybe
2694 ;;; it's not needed any more? Hunt down what it was used for and see.
2701 form)))
2710 ,in
2714 slot-entry
2718 slot-entry
2720 `(,var-name
2722 slots)
2732 ,in
2737 slots)