| blob | 7b6fb1a18c8db15e2e7bbe9a4629e4d18996cf9b |
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
524 proto-method
525 method-function-lambda
526 initargs
527 env))))
537 ;; (Old PCL code used a somewhat different style of
538 ;; list for %METHOD-NAME values. Our names use
539 ;; ,@QUALIFIERS instead of ,QUALIFIERS so that the
540 ;; method names look more like what you see in a
541 ;; DEFMETHOD form.)
542 ;;
543 ;; FIXME: As of sbcl-0.7.0.6, code elsewhere, at
544 ;; least the code to set up named BLOCKs around the
545 ;; bodies of methods, depends on the function's base
546 ;; name being the first element of the %METHOD-NAME
547 ;; list. It would be good to remove this dependency,
548 ;; perhaps by building the BLOCK here, or by using
549 ;; another declaration (e.g. %BLOCK-NAME), so that
550 ;; our method debug names are free to have any format,
551 ;; e.g. (:METHOD PRINT-OBJECT :AROUND (CLOWN T)).
552 ;;
553 ;; Further, as of sbcl-0.7.9.10, the code to
554 ;; implement NO-NEXT-METHOD is coupled to the form of
555 ;; this declaration; see the definition of
556 ;; CALL-NO-NEXT-METHOD (and the passing of
557 ;; METHOD-NAME-DECLARATION arguments around the
558 ;; various CALL-NEXT-METHOD logic).
560 ,@qualifiers
563 ,@declarations
565 unspecialized-lambda-list specializers))))
568 method-lambda initargs env)
573 is not a lambda form."
574 method-lambda))
596 name)
612 result
614 specializer generic-function))))
622 ;; FIXME: this HANDLER-CASE is a bit of a hammer to crack a nut:
623 ;; the idea is that we want to unparse permissively, so that the
624 ;; lazy (or rather the "portable") specializer extender (who
625 ;; does not define methods on these new SBCL-specific MOP
626 ;; functions) can still subclass specializer and define methods
627 ;; without everything going wrong. Making it cleaner and
628 ;; clearer that that is what we are defending against would be
629 ;; nice. -- CSR, 2007-06-01
636 class-name
637 type))
638 type))
641 specializer generic-function)))
647 ;;; a helper function for creating Python-friendly type declarations
648 ;;; in DEFMETHOD forms
652 ;; KLUDGE: ANSI, in its wisdom, says that
653 ;; EQL-SPECIALIZER-FORMs in EQL specializers are evaluated at
654 ;; DEFMETHOD expansion time. Thus, although one might think
655 ;; that in
656 ;; (DEFMETHOD FOO ((X PACKAGE)
657 ;; (Y (EQL 12))
658 ;; ..))
659 ;; the PACKAGE and (EQL 12) forms are both parallel type
660 ;; names, they're not, as is made clear when you do
661 ;; (DEFMETHOD FOO ((X PACKAGE)
662 ;; (Y (EQL 'BAR)))
663 ;; ..)
664 ;; where Y needs to be a symbol named "BAR", not some cons
665 ;; made by (CONS 'QUOTE 'BAR). I.e. when the
666 ;; EQL-SPECIALIZER-FORM is (EQL 'X), it requires an argument
667 ;; to be of type (EQL X). It'd be easy to transform one to
668 ;; the other, but it'd be somewhat messier to do so while
669 ;; ensuring that the EQL-SPECIALIZER-FORM is only EVAL'd
670 ;; once. (The new code wouldn't be messy, but it'd require a
671 ;; big transformation of the old code.) So instead we punt.
672 ;; -- WHN 20000610
675 ;; KLUDGE: For some low-level implementation
676 ;; classes, perhaps because of some problems related
677 ;; to the incomplete integration of PCL into SBCL's
678 ;; type system, some specializer classes can't be
679 ;; declared as argument types. E.g.
680 ;; (DEFMETHOD FOO ((X SLOT-OBJECT))
681 ;; (DECLARE (TYPE SLOT-OBJECT X))
682 ;; ..)
683 ;; loses when
684 ;; (DEFSTRUCT BAR A B)
685 ;; (FOO (MAKE-BAR))
686 ;; perhaps because of the way that STRUCTURE-OBJECT
687 ;; inherits both from SLOT-OBJECT and from
688 ;; SB-KERNEL:INSTANCE. In an effort to sweep such
689 ;; problems under the rug, we exclude these problem
690 ;; cases by blacklisting them here. -- WHN 2001-01-19
694 ;; KLUDGE: PCL, in its wisdom, sometimes calls methods with
695 ;; types which don't match their specializers. (Specifically,
696 ;; it calls ENSURE-CLASS-USING-CLASS (T NULL) with a non-NULL
697 ;; second argument.) Hopefully it only does this kind of
698 ;; weirdness when bootstrapping.. -- WHN 20000610
703 ;; KLUDGE: Don't declare types for global special variables
704 ;; -- our rebinding magic for SETQ cases don't work right
705 ;; there.
706 ;;
707 ;; FIXME: It would be better to detect the SETQ earlier and
708 ;; skip declarations for specials only when needed, not
709 ;; always.
710 ;;
711 ;; --NS 2004-10-14
714 ;; Otherwise, we can usually make Python very happy.
715 ;;
716 ;; KLUDGE: Since INFO doesn't work right for class objects here,
717 ;; and they are valid specializers, see if the specializer is
718 ;; a named class, and use the name in that case -- otherwise
719 ;; the class instance is ok, since info will just return NIL, NIL.
720 ;;
721 ;; We still need to deal with the class case too, but at
722 ;; least #.(find-class 'integer) and integer as equivalent
723 ;; specializers with this.
730 specializer))
744 ;; CLASS can be null here if the user has
745 ;; erroneously tried to use a defined type as a
746 ;; specializer; it can be a non-BUILT-IN-CLASS if
747 ;; the user defines a type and calls (SETF
748 ;; FIND-CLASS) in a consistent way.
757 ;; don't declare CLOS classes as parameters;
758 ;; it's too expensive.
761 ;; we can get here, and still not have a failure
762 ;; case, by doing MOP programming like (PROGN
763 ;; (ENSURE-CLASS 'FOO) (DEFMETHOD BAR ((X FOO))
764 ;; ...)). Best to let the user know we haven't
765 ;; been able to extract enough information:
767 "~@<can't find type for specializer ~S in ~S.~@:>"
768 specializer-nameoid
774 ;;; For passing a list (groveled by the walker) of the required
775 ;;; parameters whose bindings are modified in the method body to the
776 ;;; optimized-slot-value* macros.
782 is not a lambda form."
783 method-lambda))
791 ;; the method-cell is a way of communicating what method a
792 ;; method-function implements, for the purpose of
793 ;; NO-NEXT-METHOD. We need something that can be shared
794 ;; between function and initargs, but not something that
795 ;; will be coalesced as a constant (because we are naughty,
796 ;; oh yes) with the expansion of any other methods in the
797 ;; same file. -- CSR, 2007-05-30
803 parameters
804 specializers))
809 ;; These declarations seem to be used by PCL to pass
810 ;; information to itself; when I tried to delete 'em
811 ;; ca. 0.6.10 it didn't work. I'm not sure how
812 ;; they work, but note the (VAR-DECLARATION '%CLASS ..)
813 ;; expression in CAN-OPTIMIZE-ACCESS1. -- WHN 2000-12-30
818 parameters
819 specializers))
820 ;; These TYPE declarations weren't in the original
821 ;; PCL code, but the Python compiler likes them a
822 ;; lot. (We're telling the compiler about our
823 ;; knowledge of specialized argument types so that
824 ;; it can avoid run-time type dispatch overhead,
825 ;; which can be a huge win for Python.)
826 ;;
827 ;; KLUDGE: when I tried moving these to
828 ;; ADD-METHOD-DECLARATIONS, things broke. No idea
829 ;; why. -- CSR, 2004-06-16
831 parameters
832 specializers)))
834 ;; Remove the documentation string and insert the
835 ;; appropriate class declarations. The documentation
836 ;; string is removed to make it easy for us to insert
837 ;; new declarations later, they will just go after the
838 ;; CADR of the method lambda. The class declarations
839 ;; are inserted to communicate the class of the method's
840 ;; arguments to the code walk.
842 ;; The default ignorability of method parameters
843 ;; doesn't seem to be specified by ANSI. PCL had
844 ;; them basically ignorable but was a little
845 ;; inconsistent. E.g. even though the two
846 ;; method definitions
847 ;; (DEFMETHOD FOO ((X T) (Y T)) "Z")
848 ;; (DEFMETHOD FOO ((X T) Y) "Z")
849 ;; are otherwise equivalent, PCL treated Y as
850 ;; ignorable in the first definition but not in the
851 ;; second definition. We make all required
852 ;; parameters ignorable as a way of systematizing
853 ;; the old PCL behavior. -- WHN 2000-11-24
855 ,class-declarations
856 ,@declarations
876 next-method-p-p setq-p
877 parameters-setqd)
879 required-parameters
880 env
881 slots
882 calls)
884 walked-declarations
885 walked-documentation)
899 ,slot-name-lists
910 aux))))
913 (,lambda-list .method-args. .next-methods.
914 :call-next-method-p
915 ,call-next-method-p
921 ,@walked-declarations
924 %parameter-binding-modified))
928 %parameter-binding-modified))
935 method-args
936 next-methods
947 next-method-call
948 args
949 rest-arg
958 closurep applyp method-cell))
959 &body body
971 `((%check-cnm-args cnm-args
972 ,method-args
974 nil)
982 ',method-cell
993 method args)))
997 call-method-args)
999 value)
1020 pv-cell
1021 next-method-call
1022 arg-info)
1025 value)
1029 ;; The two variants of INVOKE-FAST-METHOD-CALL differ in how REST-ARGs
1030 ;; are handled. The first one will get REST-ARG as a single list (as
1031 ;; the last argument), and will thus need to use APPLY. The second one
1032 ;; will get them as a &MORE argument, so we can pass the arguments
1033 ;; directly with MULTIPLE-VALUE-CALL and %MORE-ARG-VALUES.
1042 more-context
1043 more-count
1049 ,@required-args
1052 ;; The cases with only small amounts of required arguments passed
1053 ;; are probably very common, and special-casing speeds them up by
1054 ;; a factor of 2 with very little effect on the other
1055 ;; cases. Though it'd be nice to have the generic case be equally
1056 ;; fast.
1063 ,@required-args
1074 \f
1075 ;;;; effective method functions
1081 ;;; This function was in the CMU CL version of PCL (ca Debian 2.4.8)
1082 ;;; without explanation. It appears to be intended for debugging, so
1083 ;;; it might be useful someday, so I haven't deleted it.
1084 ;;; But it isn't documented and isn't used for anything now, so
1085 ;;; I've conditionalized it out of the base system. -- WHN 19991213
1086 #+sb-show
1119 ,@more-arg
1122 ,restp
1123 ,@required-args
1128 ;; "What," you may wonder, "do these next two clauses do?" In that
1129 ;; case, you are not a PCL implementor, for they considered this to
1130 ;; be self-documenting.:-| Or CSR, for that matter, since he can
1131 ;; also figure it out by looking at it without breaking stride. For
1132 ;; the rest of us, though: From what the code is doing with .SLOTS.
1133 ;; and whatnot, evidently it's implementing SLOT-VALUEish and
1134 ;; GET-SLOT-VALUEish things. Then we can reason backwards and
1135 ;; conclude that setting EMF to a FIXNUM is an optimized way to
1136 ;; represent these slot access operations.
1147 value)))))
1155 ;; (In cmucl-2.4.8 there was a commented-out third ,@(WHEN
1156 ;; ...) clause here to handle SLOT-BOUNDish stuff. Since
1157 ;; there was no explanation and presumably the code is 10+
1158 ;; years stale, I simply deleted it. -- WHN)
1159 )))
1161 ;;; Before SBCL 0.9.16.7 instead of
1162 ;;; INVOKE-NARROW-EFFECTIVE-METHOD-FUNCTION we passed a (THE (OR
1163 ;;; FUNCTION METHOD-CALL FAST-METHOD-CALL) EMF) form as the EMF. Now,
1164 ;;; to make less work for the compiler we take a path that doesn't
1165 ;;; involve the slot-accessor clause (where EMF is a FIXNUM) at all.
1180 ,@more-arg
1183 ,restp
1184 ,@required-args
1188 emf-n restp required-args))
1211 args)
1234 args))))))
1237 args
1249 value)))
1266 \f
1269 method-cell
1270 cnm-args)
1273 ,next-method-call
1285 ,@args
1291 call-next-method-p
1292 setq-p
1293 method-cell
1294 next-method-p-p
1295 closurep
1296 applyp))
1297 &body body
1312 nil)
1314 ,next-method-call
1316 ,method-cell
1317 cnm-args))))
1326 ;;; CMUCL comment (Gerd Moellmann):
1327 ;;;
1328 ;;; The standard says it's an error if CALL-NEXT-METHOD is called with
1329 ;;; arguments, and the set of methods applicable to those arguments is
1330 ;;; different from the set of methods applicable to the original
1331 ;;; method arguments. (According to Barry Margolin, this rule was
1332 ;;; probably added to ensure that before and around methods are always
1333 ;;; run before primary methods.)
1334 ;;;
1335 ;;; This could be optimized for the case that the generic function
1336 ;;; doesn't have hairy methods, does have standard method combination,
1337 ;;; is a standard generic function, there are no methods defined on it
1338 ;;; for COMPUTE-APPLICABLE-METHODS and probably a lot more of such
1339 ;;; preconditions. That looks hairy and is probably not worth it,
1340 ;;; because this check will never be fast.
1348 ~{~S~^, ~} to call-next-method is different from ~
1349 the set of methods ~S applicable to the original ~
1350 method argument~P ~{~S~^, ~}.~@:>"
1369 "encountered the non-standard lambda list keyword ~S"
1370 var)))
1371 nil)
1419 ,@bindings
1420 (.dummy0.
1432 ;; FIXME: Do we want to export this symbol? Or maybe use an
1433 ;; (ERROR 'SIMPLE-PROGRAM-ERROR) form?
1436 return tail))
1440 ;; method definition
1442 ;; flag indicating that #'CALL-NEXT-METHOD was seen in the
1443 ;; body of a method
1445 ;; flag indicating that NEXT-METHOD-P should be in the method
1446 ;; definition
1448 ;; a list of all required parameters whose bindings might be
1449 ;; modified in the method body.
1453 ;; FIXME: Jumping to a conclusion from the way it's used
1454 ;; above, perhaps CONTEXT should be called SITUATION
1455 ;; (after the term used in the ANSI specification of
1456 ;; EVAL-WHEN) and given modern ANSI keyword values
1457 ;; like :LOAD-TOPLEVEL.
1461 form)
1464 form)
1466 ;; FIXME: this is possibly a little strong as
1467 ;; conditions go. Ideally we would want to detect
1468 ;; which, if any, of the method parameters are
1469 ;; being set, and communicate that information to
1470 ;; e.g. SPLIT-DECLARATIONS. However, the brute
1471 ;; force method doesn't really cost much; a little
1472 ;; loss of discrimination over IGNORED variables
1473 ;; should be all. -- CSR, 2004-07-01
1474 ;;
1475 ;; As of 2006-09-18 modified parameter bindings
1476 ;; are now tracked with more granularity than just
1477 ;; one SETQ-P flag, in order to disable SLOT-VALUE
1478 ;; optimizations for parameters that are SETQd.
1479 ;; The old binary SETQ-P flag is still used for
1480 ;; all other purposes, since as noted above, the
1481 ;; extra cost is minimal. -- JES, 2006-09-18
1482 ;;
1483 ;; The walker will split (SETQ A 1 B 2) to
1484 ;; separate (SETQ A 1) and (SETQ B 2) forms, so we
1485 ;; only need to handle the simple case of SETQ
1486 ;; here.
1491 ;; Note that we don't need to check for
1492 ;; %VARIABLE-REBINDING declarations like is
1493 ;; done in CAN-OPTIMIZE-ACCESS1, since the
1494 ;; bindings that will have that declation will
1495 ;; never be SETQd.
1497 ;; If a parameter binding is shadowed by
1498 ;; another binding it won't have a %CLASS
1499 ;; declaration anymore, and this won't get
1500 ;; executed.
1502 form)
1507 form)
1511 form)
1517 required-parameters
1518 env)))
1527 ;;; FIXME: the walker's rewriting of the source code causes
1528 ;;; trouble when doing code coverage. The rewrites should be
1529 ;;; removed, and the same operations done using
1530 ;;; compiler-macros or tranforms.
1532 walked-lambda
1533 method-lambda)
1534 call-next-method-p
1535 closurep
1536 next-method-p-p
1538 parameters-setqd)))))
1546 \f
1556 new-value)
1558 \f
1564 #+nil
1568 ll initargs source-location)))
1572 initargs source-location)
1581 gf-spec qualifiers specializers))))
1583 gf-spec qualifiers specializers lambda-list
1584 :definition-source source-location
1585 initargs)))
1588 ;; FIXME: should be STYLE-WARNING?
1590 "~&At the time the method with qualifiers ~:S and~%~
1591 specializers ~:S on the generic function ~S~%~
1592 was compiled, the method-class for that generic function was~%~
1593 ~S. But, the method class is now ~S, this~%~
1594 may mean that this method was compiled improperly.~%"
1595 qualifiers specializers gf-spec
1597 method))
1626 \f
1656 x)))
1665 After &REST, a DEFGENERIC lambda-list ~
1679 keywords keyword-parameters)
1688 old-ftype))))
1703 keywords)
1706 *))))
1710 \f
1711 ;;;; early generic function support
1716 &rest all-keys
1717 &key environment source-location
1730 existing fun-name all-keys)))))
1734 'simple-program-error
1785 arg-info-precedence
1786 arg-info-metatypes
1787 arg-info-number-optional
1788 arg-info-key/rest-p
1789 arg-info-keys ;nil no &KEY or &REST allowed
1790 ;(k1 k2 ..) Each method must accept these &KEY arguments.
1791 ;T must have &KEY or &REST
1793 gf-info-simple-accessor-type ; nil, reader, writer, boundp
1796 gf-info-static-c-a-m-emf
1798 gf-info-fast-mf-p)
1816 ;;; Create a gf lambda list from a method lambda list
1822 argument-precedence-order)
1846 existing methods of ~S."
1847 lambda-list gf))))
1850 lambda-list
1866 arg-info))
1876 to the generic function~2I~_~S;~I~_~
1877 but ~?~:>"
1887 "the method has ~A required arguments than the generic function."
1891 "the method has ~A optional arguments than the generic function."
1895 "the method and generic function differ in whether they accept~_~
1899 allow-other-keys-p
1902 ~S."
1903 gf-keywords)))))))
1914 ;;; FIXME: we don't actually need this; we could test for the exact
1915 ;;; class and deal with it as appropriate. In fact we probably don't
1916 ;;; need it anyway because we only use this for METHOD-SPECIALIZERS on
1917 ;;; the standard reader method for METHOD-SPECIALIZERS. Probably.
1967 nil)))
2015 nil)
2020 ;; FIXME: this test will eventually be
2021 ;; superseded by the *internal-pcl...* test,
2022 ;; above. While we are in a process of
2023 ;; transition, however, it should probably
2024 ;; remain.
2030 #'make-method-lambda
2041 arg-info)
2043 ;;; This is the early definition of ENSURE-GENERIC-FUNCTION-USING-CLASS.
2044 ;;;
2045 ;;; The STATIC-SLOTS field of the funcallable instances used as early
2046 ;;; generic functions is used to store the early methods and early
2047 ;;; discriminator code for the early generic function. The static
2048 ;;; slots field of the fins contains a list whose:
2049 ;;; CAR - a list of the early methods on this early gf
2050 ;;; CADR - the early discriminator code for this method
2053 lambda-list-p)
2054 argument-precedence-order
2055 source-location
2061 existing)
2065 argument-precedence-order source-location)
2073 argument-precedence-order source-location))))
2076 function argument-precedence-order source-location)
2080 fin
2093 fin
2094 'source
2095 source-location)
2103 :lambda-list lambda-list
2106 fin))
2116 new-value)
2122 dfun)))
2125 ;; Check that we are under the lock.
2126 #+sb-thread
2131 new-state))))
2132 dfun)
2167 nil)
2182 class nor a symbol that names a class."
2186 ;; FIXME: reference MOP documentation -- this is an
2187 ;; additional requirement on our users
2202 method-class)
2207 fun-name
2208 &rest all-keys
2213 ;; KLUDGE: the above macro does SETQ on GENERIC-FUNCTION-CLASS,
2214 ;; which is what makes the next line work
2224 fun-name
2225 &rest all-keys
2237 \f
2244 ;;; FIXME: this function took on a slightly greater role than it
2245 ;;; previously had around 2005-11-02, when CSR fixed the bug whereby
2246 ;;; having more than one subclass of standard-generic-function caused
2247 ;;; the whole system to die horribly through a metacircle in
2248 ;;; GF-ARG-INFO. The fix is to be slightly more disciplined about
2249 ;;; calling accessor methods -- we call GET-GENERIC-FUN-INFO when
2250 ;;; computing discriminating functions, so we need to be careful about
2251 ;;; having a base case for the recursion, and we provide that with the
2252 ;;; STANDARD-GENERIC-FUNCTION case below. However, we are not (yet)
2253 ;;; as disciplined as CLISP's CLOS/MOP, and it would be nice to get to
2254 ;;; that stage, where all potentially dangerous cases are enumerated
2255 ;;; and stopped. -- CSR, 2005-11-02.
2257 ;; values nreq applyp metatypes nkeys arg-info
2264 metatypes
2265 arg-info))
2268 arg-info)))
2274 ;; Figure out whether we got class objects or class names as the
2275 ;; specializers and set parsed and unparsed appropriately. If we
2276 ;; got class objects, then we can compute unparsed, but if we got
2277 ;; class names we don't try to compute parsed.
2278 ;;
2279 ;; Note that the use of not symbolp in this call to every should be
2280 ;; read as 'classp' we can't use classp itself because it doesn't
2281 ;; exist yet.
2286 specializers))
2288 parsed ()))
2298 ;; the parsed specializers. This is used by
2299 ;; EARLY-METHOD-SPECIALIZERS to cache the parse.
2300 ;; Note that this only comes into play when there is
2301 ;; more than one early method on an early gf.
2302 parsed
2304 ;; A list to which REAL-MAKE-A-METHOD can be applied
2305 ;; to make a real method corresponding to this early
2306 ;; one.
2309 initargs doc)
2314 result)))
2329 :slot-definition slot-definition
2333 initargs)
2334 initargs)))
2354 ;;; Fetch the specializers of an early method. This is basically just
2355 ;;; a simple accessor except that when the second argument is t, this
2356 ;;; converts the specializers from symbols into class objects. The
2357 ;;; class objects are cached in the early method, this makes
2358 ;;; bootstrapping faster because the class objects only have to be
2359 ;;; computed once.
2360 ;;;
2361 ;;; NOTE:
2362 ;;; The second argument should only be passed as T by
2363 ;;; early-lookup-method. This is to implement the rule that only when
2364 ;;; there is more than one early method on a generic function is the
2365 ;;; conversion from class names to class objects done. This
2366 ;;; corresponds to the fact that we are only allowed to have one
2367 ;;; method on any generic function up until the time classes exist.
2394 ;; argument here because the default,
2395 ;; STANDARD-GENERIC-FUNCTION, is right for all early generic
2396 ;; functions. (See REAL-ADD-NAMED-METHOD)
2406 specializers initargs ())))
2410 ;;; This is the early version of ADD-METHOD. Later this will become a
2411 ;;; generic function. See !FIX-EARLY-GENERIC-FUNCTIONS which has
2412 ;;; special knowledge about ADD-METHOD.
2425 ;;; This is the early version of REMOVE-METHOD. See comments on
2426 ;;; the early version of ADD-METHOD.
2440 ;;; This is the early version of GET-METHOD. See comments on the early
2441 ;;; version of ADD-METHOD.
2447 specializers)
2449 specializers))
2454 nil))
2459 ;; Rearrange *!EARLY-GENERIC-FUNCTIONS* to speed up
2460 ;; FIX-EARLY-GENERIC-FUNCTIONS.
2467 generic-function-methods
2468 method-specializers
2469 specializerp
2470 specializer-type
2471 specializer-class
2472 slot-definition-location
2473 slot-definition-name
2474 class-slots
2475 gf-arg-info
2476 class-precedence-list
2477 slot-boundp-using-class
2479 slot-value-using-class
2480 structure-class-p
2481 standard-class-p
2482 funcallable-standard-class-p
2483 specializerp)))
2494 early-method))))
2497 early-method t))
2524 next-methods))
2529 ()
2530 lambda-list
2531 specializers
2532 initargs
2533 nil)))
2540 \f
2541 ;;; PARSE-DEFMETHOD is used by DEFMETHOD to parse the &REST argument
2542 ;;; into the 'real' arguments. This is where the syntax of DEFMETHOD
2543 ;;; is really implemented.
2566 \f
2571 parameters))
2577 lambda-list))
2583 specializers))
2589 required-parameters))
2593 ()
2606 ;; non-standard lambda-list-keywords are errors.
2610 keyword ~S~%"
2612 ;; no multiple &rest x &rest bla specifying
2616 specialized-lambda-list keyword ~S~%"
2618 ;; And no placing &key in front of &optional, either.
2622 keyword ~S~%"
2624 ;; When we are at a lambda-list keyword, the parameters
2625 ;; don't include the lambda-list keyword; the lambda-list
2626 ;; does include the lambda-list keyword; and no
2627 ;; specializers are allowed to follow the lambda-list
2628 ;; keywords (at least for now).
2639 specialized-lambda-list-keywords)
2642 specialized-lambda-list-keywords)))))
2644 :format-control
2645 "in a specialized-lambda-list, excactly one ~
2646 variable must follow &REST.~%"
2650 ()
2651 ())))
2653 ;; After a lambda-list keyword there can be no specializers.
2656 supplied-keywords
2657 allowed-keywords)
2660 ()
2661 ())))
2669 \f
2671 \f
2672 ;;; FIXME: In here there was a #-CMU definition of SYMBOL-MACROLET
2673 ;;; which used %WALKER stuff. That suggests to me that maybe the code
2674 ;;; walker stuff was only used for implementing stuff like that; maybe
2675 ;;; it's not needed any more? Hunt down what it was used for and see.
2683 instance)))
2686 ,in
2690 slot-entry
2694 slot-entry
2696 `(,var-name
2698 slots)
2707 instance)))
2710 ,in
2715 slots)