| blob | 017e1471ad81ca7e03a756a4d912c7308ba1d9aa |
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))
623 ;; These declarations seem to be used by PCL to pass
624 ;; information to itself; when I tried to delete 'em
625 ;; ca. 0.6.10 it didn't work. I'm not sure how
626 ;; they work, but note the (VAR-DECLARATION '%CLASS ..)
627 ;; expression in CAN-OPTIMIZE-ACCESS1. -- WHN 2000-12-30
632 parameters
633 specializers))
634 ;; These TYPE declarations weren't in the original
635 ;; PCL code, but the Python compiler likes them a
636 ;; lot. (We're telling the compiler about our
637 ;; knowledge of specialized argument types so that
638 ;; it can avoid run-time type dispatch overhead,
639 ;; which can be a huge win for Python.)
640 ;;
641 ;; KLUDGE: when I tried moving these to
642 ;; ADD-METHOD-DECLARATIONS, things broke. No idea
643 ;; why. -- CSR, 2004-06-16
645 parameters
646 specializers)))
648 ;; Remove the documentation string and insert the
649 ;; appropriate class declarations. The documentation
650 ;; string is removed to make it easy for us to insert
651 ;; new declarations later, they will just go after the
652 ;; CADR of the method lambda. The class declarations
653 ;; are inserted to communicate the class of the method's
654 ;; arguments to the code walk.
656 ;; The default ignorability of method parameters
657 ;; doesn't seem to be specified by ANSI. PCL had
658 ;; them basically ignorable but was a little
659 ;; inconsistent. E.g. even though the two
660 ;; method definitions
661 ;; (DEFMETHOD FOO ((X T) (Y T)) "Z")
662 ;; (DEFMETHOD FOO ((X T) Y) "Z")
663 ;; are otherwise equivalent, PCL treated Y as
664 ;; ignorable in the first definition but not in the
665 ;; second definition. We make all required
666 ;; parameters ignorable as a way of systematizing
667 ;; the old PCL behavior. -- WHN 2000-11-24
669 ,class-declarations
670 ,@declarations
690 next-method-p-p setq-p
691 parameters-setqd)
693 required-parameters
694 env
695 slots
696 calls)
698 walked-declarations
699 walked-documentation)
713 ,slot-name-lists
724 aux))))
727 (,lambda-list .method-args. .next-methods.
728 :call-next-method-p
729 ,call-next-method-p
735 ,@walked-declarations
738 %parameter-binding-modified))
742 %parameter-binding-modified))
755 name)
771 result
773 specializer generic-function))))
781 ;; FIXME: this HANDLER-CASE is a bit of a hammer to crack a nut:
782 ;; the idea is that we want to unparse permissively, so that the
783 ;; lazy (or rather the "portable") specializer extender (who
784 ;; does not define methods on these new SBCL-specific MOP
785 ;; functions) can still subclass specializer and define methods
786 ;; without everything going wrong. Making it cleaner and
787 ;; clearer that that is what we are defending against would be
788 ;; nice. -- CSR, 2007-06-01
795 class-name
796 type))
797 type))
800 specializer generic-function)))
806 ;;; a helper function for creating Python-friendly type declarations
807 ;;; in DEFMETHOD forms
811 ;; KLUDGE: ANSI, in its wisdom, says that
812 ;; EQL-SPECIALIZER-FORMs in EQL specializers are evaluated at
813 ;; DEFMETHOD expansion time. Thus, although one might think
814 ;; that in
815 ;; (DEFMETHOD FOO ((X PACKAGE)
816 ;; (Y (EQL 12))
817 ;; ..))
818 ;; the PACKAGE and (EQL 12) forms are both parallel type
819 ;; names, they're not, as is made clear when you do
820 ;; (DEFMETHOD FOO ((X PACKAGE)
821 ;; (Y (EQL 'BAR)))
822 ;; ..)
823 ;; where Y needs to be a symbol named "BAR", not some cons
824 ;; made by (CONS 'QUOTE 'BAR). I.e. when the
825 ;; EQL-SPECIALIZER-FORM is (EQL 'X), it requires an argument
826 ;; to be of type (EQL X). It'd be easy to transform one to
827 ;; the other, but it'd be somewhat messier to do so while
828 ;; ensuring that the EQL-SPECIALIZER-FORM is only EVAL'd
829 ;; once. (The new code wouldn't be messy, but it'd require a
830 ;; big transformation of the old code.) So instead we punt.
831 ;; -- WHN 20000610
834 ;; KLUDGE: For some low-level implementation
835 ;; classes, perhaps because of some problems related
836 ;; to the incomplete integration of PCL into SBCL's
837 ;; type system, some specializer classes can't be
838 ;; declared as argument types. E.g.
839 ;; (DEFMETHOD FOO ((X SLOT-OBJECT))
840 ;; (DECLARE (TYPE SLOT-OBJECT X))
841 ;; ..)
842 ;; loses when
843 ;; (DEFSTRUCT BAR A B)
844 ;; (FOO (MAKE-BAR))
845 ;; perhaps because of the way that STRUCTURE-OBJECT
846 ;; inherits both from SLOT-OBJECT and from
847 ;; SB-KERNEL:INSTANCE. In an effort to sweep such
848 ;; problems under the rug, we exclude these problem
849 ;; cases by blacklisting them here. -- WHN 2001-01-19
853 ;; KLUDGE: PCL, in its wisdom, sometimes calls methods with
854 ;; types which don't match their specializers. (Specifically,
855 ;; it calls ENSURE-CLASS-USING-CLASS (T NULL) with a non-NULL
856 ;; second argument.) Hopefully it only does this kind of
857 ;; weirdness when bootstrapping.. -- WHN 20000610
862 ;; KLUDGE: Don't declare types for global special variables
863 ;; -- our rebinding magic for SETQ cases don't work right
864 ;; there.
865 ;;
866 ;; FIXME: It would be better to detect the SETQ earlier and
867 ;; skip declarations for specials only when needed, not
868 ;; always.
869 ;;
870 ;; --NS 2004-10-14
873 ;; Otherwise, we can usually make Python very happy.
874 ;;
875 ;; KLUDGE: Since INFO doesn't work right for class objects here,
876 ;; and they are valid specializers, see if the specializer is
877 ;; a named class, and use the name in that case -- otherwise
878 ;; the class instance is ok, since info will just return NIL, NIL.
879 ;;
880 ;; We still need to deal with the class case too, but at
881 ;; least #.(find-class 'integer) and integer as equivalent
882 ;; specializers with this.
889 specializer))
903 ;; CLASS can be null here if the user has
904 ;; erroneously tried to use a defined type as a
905 ;; specializer; it can be a non-BUILT-IN-CLASS if
906 ;; the user defines a type and calls (SETF
907 ;; FIND-CLASS) in a consistent way.
916 ;; don't declare CLOS classes as parameters;
917 ;; it's too expensive.
920 ;; we can get here, and still not have a failure
921 ;; case, by doing MOP programming like (PROGN
922 ;; (ENSURE-CLASS 'FOO) (DEFMETHOD BAR ((X FOO))
923 ;; ...)). Best to let the user know we haven't
924 ;; been able to extract enough information:
926 "~@<can't find type for specializer ~S in ~S.~@:>"
927 specializer-nameoid
933 ;;; For passing a list (groveled by the walker) of the required
934 ;;; parameters whose bindings are modified in the method body to the
935 ;;; optimized-slot-value* macros.
939 method-args
940 next-methods
951 next-method-call
952 args
953 rest-arg
962 closurep applyp method-cell))
963 &body body
975 `((%check-cnm-args cnm-args
976 ,method-args
978 nil)
986 ',method-cell
997 method args)))
1001 call-method-args)
1003 value)
1024 pv-cell
1025 next-method-call
1026 arg-info)
1029 value)
1033 ;; The two variants of INVOKE-FAST-METHOD-CALL differ in how REST-ARGs
1034 ;; are handled. The first one will get REST-ARG as a single list (as
1035 ;; the last argument), and will thus need to use APPLY. The second one
1036 ;; will get them as a &MORE argument, so we can pass the arguments
1037 ;; directly with MULTIPLE-VALUE-CALL and %MORE-ARG-VALUES.
1046 more-context
1047 more-count
1053 ,@required-args
1056 ;; The cases with only small amounts of required arguments passed
1057 ;; are probably very common, and special-casing speeds them up by
1058 ;; a factor of 2 with very little effect on the other
1059 ;; cases. Though it'd be nice to have the generic case be equally
1060 ;; fast.
1067 ,@required-args
1078 \f
1079 ;;;; effective method functions
1085 ;;; This function was in the CMU CL version of PCL (ca Debian 2.4.8)
1086 ;;; without explanation. It appears to be intended for debugging, so
1087 ;;; it might be useful someday, so I haven't deleted it.
1088 ;;; But it isn't documented and isn't used for anything now, so
1089 ;;; I've conditionalized it out of the base system. -- WHN 19991213
1090 #+sb-show
1123 ,@more-arg
1126 ,restp
1127 ,@required-args
1132 ;; "What," you may wonder, "do these next two clauses do?" In that
1133 ;; case, you are not a PCL implementor, for they considered this to
1134 ;; be self-documenting.:-| Or CSR, for that matter, since he can
1135 ;; also figure it out by looking at it without breaking stride. For
1136 ;; the rest of us, though: From what the code is doing with .SLOTS.
1137 ;; and whatnot, evidently it's implementing SLOT-VALUEish and
1138 ;; GET-SLOT-VALUEish things. Then we can reason backwards and
1139 ;; conclude that setting EMF to a FIXNUM is an optimized way to
1140 ;; represent these slot access operations.
1151 value)))))
1159 ;; (In cmucl-2.4.8 there was a commented-out third ,@(WHEN
1160 ;; ...) clause here to handle SLOT-BOUNDish stuff. Since
1161 ;; there was no explanation and presumably the code is 10+
1162 ;; years stale, I simply deleted it. -- WHN)
1163 )))
1165 ;;; Before SBCL 0.9.16.7 instead of
1166 ;;; INVOKE-NARROW-EFFECTIVE-METHOD-FUNCTION we passed a (THE (OR
1167 ;;; FUNCTION METHOD-CALL FAST-METHOD-CALL) EMF) form as the EMF. Now,
1168 ;;; to make less work for the compiler we take a path that doesn't
1169 ;;; involve the slot-accessor clause (where EMF is a FIXNUM) at all.
1184 ,@more-arg
1187 ,restp
1188 ,@required-args
1192 emf-n restp required-args))
1215 args)
1238 args))))))
1241 args
1253 value)))
1270 \f
1273 method-cell
1274 cnm-args)
1277 ,next-method-call
1289 ,@args
1295 call-next-method-p
1296 setq-p
1297 method-cell
1298 next-method-p-p
1299 closurep
1300 applyp))
1301 &body body
1316 nil)
1318 ,next-method-call
1320 ,method-cell
1321 cnm-args))))
1330 ;;; CMUCL comment (Gerd Moellmann):
1331 ;;;
1332 ;;; The standard says it's an error if CALL-NEXT-METHOD is called with
1333 ;;; arguments, and the set of methods applicable to those arguments is
1334 ;;; different from the set of methods applicable to the original
1335 ;;; method arguments. (According to Barry Margolin, this rule was
1336 ;;; probably added to ensure that before and around methods are always
1337 ;;; run before primary methods.)
1338 ;;;
1339 ;;; This could be optimized for the case that the generic function
1340 ;;; doesn't have hairy methods, does have standard method combination,
1341 ;;; is a standard generic function, there are no methods defined on it
1342 ;;; for COMPUTE-APPLICABLE-METHODS and probably a lot more of such
1343 ;;; preconditions. That looks hairy and is probably not worth it,
1344 ;;; because this check will never be fast.
1352 ~{~S~^, ~} to call-next-method is different from ~
1353 the set of methods ~S applicable to the original ~
1354 method argument~P ~{~S~^, ~}.~@:>"
1373 "encountered the non-standard lambda list keyword ~S"
1374 var)))
1375 nil)
1423 ,@bindings
1424 (.dummy0.
1436 ;; FIXME: Do we want to export this symbol? Or maybe use an
1437 ;; (ERROR 'SIMPLE-PROGRAM-ERROR) form?
1440 return tail))
1444 ;; method definition
1446 ;; flag indicating that #'CALL-NEXT-METHOD was seen in the
1447 ;; body of a method
1449 ;; flag indicating that NEXT-METHOD-P should be in the method
1450 ;; definition
1452 ;; a list of all required parameters whose bindings might be
1453 ;; modified in the method body.
1457 ;; FIXME: Jumping to a conclusion from the way it's used
1458 ;; above, perhaps CONTEXT should be called SITUATION
1459 ;; (after the term used in the ANSI specification of
1460 ;; EVAL-WHEN) and given modern ANSI keyword values
1461 ;; like :LOAD-TOPLEVEL.
1465 form)
1468 form)
1470 ;; FIXME: this is possibly a little strong as
1471 ;; conditions go. Ideally we would want to detect
1472 ;; which, if any, of the method parameters are
1473 ;; being set, and communicate that information to
1474 ;; e.g. SPLIT-DECLARATIONS. However, the brute
1475 ;; force method doesn't really cost much; a little
1476 ;; loss of discrimination over IGNORED variables
1477 ;; should be all. -- CSR, 2004-07-01
1478 ;;
1479 ;; As of 2006-09-18 modified parameter bindings
1480 ;; are now tracked with more granularity than just
1481 ;; one SETQ-P flag, in order to disable SLOT-VALUE
1482 ;; optimizations for parameters that are SETQd.
1483 ;; The old binary SETQ-P flag is still used for
1484 ;; all other purposes, since as noted above, the
1485 ;; extra cost is minimal. -- JES, 2006-09-18
1486 ;;
1487 ;; The walker will split (SETQ A 1 B 2) to
1488 ;; separate (SETQ A 1) and (SETQ B 2) forms, so we
1489 ;; only need to handle the simple case of SETQ
1490 ;; here.
1495 ;; Note that we don't need to check for
1496 ;; %VARIABLE-REBINDING declarations like is
1497 ;; done in CAN-OPTIMIZE-ACCESS1, since the
1498 ;; bindings that will have that declation will
1499 ;; never be SETQd.
1501 ;; If a parameter binding is shadowed by
1502 ;; another binding it won't have a %CLASS
1503 ;; declaration anymore, and this won't get
1504 ;; executed.
1506 form)
1511 form)
1515 form)
1528 ;;; FIXME: the walker's rewriting of the source code causes
1529 ;;; trouble when doing code coverage. The rewrites should be
1530 ;;; removed, and the same operations done using
1531 ;;; compiler-macros or tranforms.
1533 walked-lambda
1534 method-lambda)
1535 call-next-method-p
1536 closurep
1537 next-method-p-p
1539 parameters-setqd)))))
1547 \f
1557 new-value)
1559 \f
1565 #+nil
1569 ll initargs source-location)))
1573 initargs source-location)
1582 gf-spec qualifiers specializers))))
1584 gf-spec qualifiers specializers lambda-list
1585 :definition-source source-location
1586 initargs)))
1589 ;; FIXME: should be STYLE-WARNING?
1591 "~&At the time the method with qualifiers ~:S and~%~
1592 specializers ~:S on the generic function ~S~%~
1593 was compiled, the method-class for that generic function was~%~
1594 ~S. But, the method class is now ~S, this~%~
1595 may mean that this method was compiled improperly.~%"
1596 qualifiers specializers gf-spec
1598 method))
1627 \f
1657 x)))
1666 After &REST, a DEFGENERIC lambda-list ~
1680 keywords keyword-parameters)
1689 old-ftype))))
1704 keywords)
1707 *))))
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.
1968 nil)))
2016 nil)
2021 ;; FIXME: this test will eventually be
2022 ;; superseded by the *internal-pcl...* test,
2023 ;; above. While we are in a process of
2024 ;; transition, however, it should probably
2025 ;; remain.
2031 #'make-method-lambda
2042 arg-info)
2044 ;;; This is the early definition of ENSURE-GENERIC-FUNCTION-USING-CLASS.
2045 ;;;
2046 ;;; The STATIC-SLOTS field of the funcallable instances used as early
2047 ;;; generic functions is used to store the early methods and early
2048 ;;; discriminator code for the early generic function. The static
2049 ;;; slots field of the fins contains a list whose:
2050 ;;; CAR - a list of the early methods on this early gf
2051 ;;; CADR - the early discriminator code for this method
2054 lambda-list-p)
2055 argument-precedence-order
2056 source-location
2057 documentation
2063 existing)
2067 argument-precedence-order source-location
2068 documentation)
2076 argument-precedence-order source-location
2077 documentation))))
2080 function argument-precedence-order source-location
2081 documentation)
2085 fin
2108 :lambda-list lambda-list
2111 fin))
2121 new-value)
2127 dfun)))
2130 ;; Check that we are under the lock.
2131 #+sb-thread
2136 new-state))))
2137 dfun)
2172 nil)
2187 class nor a symbol that names a class."
2191 ;; FIXME: reference MOP documentation -- this is an
2192 ;; additional requirement on our users
2207 method-class)
2212 fun-name
2213 &rest all-keys
2218 ;; KLUDGE: the above macro does SETQ on GENERIC-FUNCTION-CLASS,
2219 ;; which is what makes the next line work
2229 fun-name
2230 &rest all-keys
2242 \f
2249 ;;; FIXME: this function took on a slightly greater role than it
2250 ;;; previously had around 2005-11-02, when CSR fixed the bug whereby
2251 ;;; having more than one subclass of standard-generic-function caused
2252 ;;; the whole system to die horribly through a metacircle in
2253 ;;; GF-ARG-INFO. The fix is to be slightly more disciplined about
2254 ;;; calling accessor methods -- we call GET-GENERIC-FUN-INFO when
2255 ;;; computing discriminating functions, so we need to be careful about
2256 ;;; having a base case for the recursion, and we provide that with the
2257 ;;; STANDARD-GENERIC-FUNCTION case below. However, we are not (yet)
2258 ;;; as disciplined as CLISP's CLOS/MOP, and it would be nice to get to
2259 ;;; that stage, where all potentially dangerous cases are enumerated
2260 ;;; and stopped. -- CSR, 2005-11-02.
2262 ;; values nreq applyp metatypes nkeys arg-info
2269 metatypes
2270 arg-info))
2273 arg-info)))
2279 ;; Figure out whether we got class objects or class names as the
2280 ;; specializers and set parsed and unparsed appropriately. If we
2281 ;; got class objects, then we can compute unparsed, but if we got
2282 ;; class names we don't try to compute parsed.
2283 ;;
2284 ;; Note that the use of not symbolp in this call to every should be
2285 ;; read as 'classp' we can't use classp itself because it doesn't
2286 ;; exist yet.
2291 specializers))
2293 parsed ()))
2303 ;; the parsed specializers. This is used by
2304 ;; EARLY-METHOD-SPECIALIZERS to cache the parse.
2305 ;; Note that this only comes into play when there is
2306 ;; more than one early method on an early gf.
2307 parsed
2309 ;; A list to which REAL-MAKE-A-METHOD can be applied
2310 ;; to make a real method corresponding to this early
2311 ;; one.
2314 initargs doc)
2319 result)))
2334 :slot-definition slot-definition
2338 initargs)
2339 initargs)))
2359 ;;; Fetch the specializers of an early method. This is basically just
2360 ;;; a simple accessor except that when the second argument is t, this
2361 ;;; converts the specializers from symbols into class objects. The
2362 ;;; class objects are cached in the early method, this makes
2363 ;;; bootstrapping faster because the class objects only have to be
2364 ;;; computed once.
2365 ;;;
2366 ;;; NOTE:
2367 ;;; The second argument should only be passed as T by
2368 ;;; early-lookup-method. This is to implement the rule that only when
2369 ;;; there is more than one early method on a generic function is the
2370 ;;; conversion from class names to class objects done. This
2371 ;;; corresponds to the fact that we are only allowed to have one
2372 ;;; method on any generic function up until the time classes exist.
2399 ;; argument here because the default,
2400 ;; STANDARD-GENERIC-FUNCTION, is right for all early generic
2401 ;; functions. (See REAL-ADD-NAMED-METHOD)
2415 ;;; This is the early version of ADD-METHOD. Later this will become a
2416 ;;; generic function. See !FIX-EARLY-GENERIC-FUNCTIONS which has
2417 ;;; special knowledge about ADD-METHOD.
2430 ;;; This is the early version of REMOVE-METHOD. See comments on
2431 ;;; the early version of ADD-METHOD.
2445 ;;; This is the early version of GET-METHOD. See comments on the early
2446 ;;; version of ADD-METHOD.
2452 specializers)
2454 specializers))
2459 nil))
2464 ;; Rearrange *!EARLY-GENERIC-FUNCTIONS* to speed up
2465 ;; FIX-EARLY-GENERIC-FUNCTIONS.
2472 generic-function-methods
2473 method-specializers
2474 specializerp
2475 specializer-type
2476 specializer-class
2477 slot-definition-location
2478 slot-definition-name
2479 class-slots
2480 gf-arg-info
2481 class-precedence-list
2482 slot-boundp-using-class
2484 slot-value-using-class
2485 structure-class-p
2486 standard-class-p
2487 funcallable-standard-class-p
2488 specializerp)))
2499 early-method))))
2502 early-method t))
2529 next-methods))
2534 ()
2535 lambda-list
2536 specializers
2537 initargs
2538 nil)))
2545 \f
2546 ;;; PARSE-DEFMETHOD is used by DEFMETHOD to parse the &REST argument
2547 ;;; into the 'real' arguments. This is where the syntax of DEFMETHOD
2548 ;;; is really implemented.
2571 \f
2576 parameters))
2582 lambda-list))
2588 specializers))
2594 required-parameters))
2598 ()
2611 ;; non-standard lambda-list-keywords are errors.
2615 keyword ~S~%"
2617 ;; no multiple &rest x &rest bla specifying
2621 specialized-lambda-list keyword ~S~%"
2623 ;; And no placing &key in front of &optional, either.
2627 keyword ~S~%"
2629 ;; When we are at a lambda-list keyword, the parameters
2630 ;; don't include the lambda-list keyword; the lambda-list
2631 ;; does include the lambda-list keyword; and no
2632 ;; specializers are allowed to follow the lambda-list
2633 ;; keywords (at least for now).
2644 specialized-lambda-list-keywords)
2647 specialized-lambda-list-keywords)))))
2649 :format-control
2650 "in a specialized-lambda-list, excactly one ~
2651 variable must follow &REST.~%"
2655 ()
2656 ())))
2658 ;; After a lambda-list keyword there can be no specializers.
2661 supplied-keywords
2662 allowed-keywords)
2665 ()
2666 ())))
2674 \f
2676 \f
2677 ;;; FIXME: In here there was a #-CMU definition of SYMBOL-MACROLET
2678 ;;; which used %WALKER stuff. That suggests to me that maybe the code
2679 ;;; walker stuff was only used for implementing stuff like that; maybe
2680 ;;; it's not needed any more? Hunt down what it was used for and see.
2687 form)))
2696 ,in
2700 slot-entry
2704 slot-entry
2706 `(,var-name
2708 slots)
2718 ,in
2723 slots)