| blob | b6d2dfd014ef02a362d81237f5e2e461413b8f6c |
1 ;;;; This software is part of the SBCL system. See the README file for
2 ;;;; more information.
4 ;;;; This software is derived from software originally released by Xerox
5 ;;;; Corporation. Copyright and release statements follow. Later modifications
6 ;;;; to the software are in the public domain and are provided with
7 ;;;; absolutely no warranty. See the COPYING and CREDITS files for more
8 ;;;; information.
10 ;;;; copyright information from original PCL sources:
11 ;;;;
12 ;;;; Copyright (c) 1985, 1986, 1987, 1988, 1989, 1990 Xerox Corporation.
13 ;;;; All rights reserved.
14 ;;;;
15 ;;;; Use and copying of this software and preparation of derivative works based
16 ;;;; upon this software are permitted. Any distribution of this software or
17 ;;;; derivative works must comply with all applicable United States export
18 ;;;; control laws.
19 ;;;;
20 ;;;; This software is made available AS IS, and Xerox Corporation makes no
21 ;;;; warranty about the software, its performance or its conformity to any
22 ;;;; specification.
25 \f
26 #|
28 The CommonLoops evaluator is meta-circular.
30 Most of the code in PCL is methods on generic functions, including
31 most of the code that actually implements generic functions and method
32 lookup.
34 So, we have a classic bootstrapping problem. The solution to this is
35 to first get a cheap implementation of generic functions running,
36 these are called early generic functions. These early generic
37 functions and the corresponding early methods and early method lookup
38 are used to get enough of the system running that it is possible to
39 create real generic functions and methods and implement real method
41 !FIX-EARLY-GENERIC-FUNCTIONS is called to convert all the early generic
42 functions to real generic functions.
44 The cheap generic functions are built using the same
45 FUNCALLABLE-INSTANCE objects that real generic functions are made out of.
46 This means that as PCL is being bootstrapped, the cheap generic
47 function objects which are being created are the same objects which
48 will later be real generic functions. This is good because:
50 - we can keep pointers to the cheap generic function objects
51 during booting because those pointers will still point to
52 the right object after the generic functions are all fixed up.
54 This file defines the DEFMETHOD macro and the mechanism used to expand
55 it. This includes the mechanism for processing the body of a method.
56 DEFMETHOD basically expands into a call to LOAD-DEFMETHOD, which
57 basically calls ADD-METHOD to add the method to the generic function.
58 These expansions can be loaded either during bootstrapping or when PCL
59 is fully up and running.
61 An important effect of this arrangement is it means we can compile
62 files with DEFMETHOD forms in them in a completely running PCL, but
63 then load those files back in during bootstrapping. This makes
64 development easier. It also means there is only one set of code for
65 processing DEFMETHOD. Bootstrapping works by being sure to have
66 LOAD-METHOD be careful to call only primitives which work during
67 bootstrapping.
69 |#
72 ensure-generic-function-using-class
73 add-method remove-method))
79 ;;; For each of the early functions, arrange to have it point to its
80 ;;; early definition. Do this in a way that makes sure that if we
81 ;;; redefine one of the early definitions the redefinition will take
82 ;;; effect. This makes development easier.
90 name))))
92 ;;; *!GENERIC-FUNCTION-FIXUPS* is used by !FIX-EARLY-GENERIC-FUNCTIONS
93 ;;; to convert the few functions in the bootstrap which are supposed
94 ;;; to be generic functions but can't be early on.
95 ;;;
96 ;;; each entry is a list of name and lambda-list, class names as
97 ;;; specializers, and method body function name.
102 real-add-method))
106 real-remove-method))
110 real-get-method))
113 &key generic-function-class environment
116 real-ensure-gf-using-class--generic-function)
118 &key generic-function-class environment
121 real-ensure-gf-using-class--null))
125 real-make-method-lambda))
129 real-make-method-specializers-form))
133 real-parse-specializer-using-class))
137 real-unparse-specializer-using-class))
140 lambda-expression
141 lambda-list environment)
143 real-make-method-initargs-form))
147 standard-compute-effective-method))))
148 \f
178 DEFGENERIC: ~S~:@>"
181 ;; FIXME: this list is slightly weird.
182 ;; ANSI (on the DEFGENERIC page) in one
183 ;; place allows only OPTIMIZE; in
184 ;; another place gives this list of
185 ;; disallowed declaration specifiers.
186 ;; This seems to be the only place where
187 ;; the FUNCTION declaration is
188 ;; mentioned; TYPE seems to be missing.
189 ;; Very strange. -- CSR, 2002-10-21
191 inline notinline special))
194 is not allowed inside DEFGENERIC."
200 spec))))
201 (:method-combination
207 symbol: ~S"
211 (:argument-precedence-order
217 :ARGUMENT-PRECEDENCE-ORDER clause."
222 :ARGUMENT-PRECEDENCE-ORDER clause: ~
223 ~S and ~S"
233 (:method
236 ;; ANSI requires that unsupported things must get a
237 ;; PROGRAM-ERROR.
259 ;; Hmm. This is similar to BECOME-DEFINED-FUN-NAME
260 ;; except that it doesn't clear an :ASSUMED-TYPE. Should it?
268 :name fun-name
276 fun-name
277 :lambda-list lambda-list
278 :definition-source source-location
279 initargs))
283 ()
288 ;; PARSE-LAMBDA-LIST validates the skeleton,
289 ;; so just check for incorrect use of defaults.
290 ;; This works for both &OPTIONAL and &KEY.
295 :format-control
296 "~@<invalid ~A argument specifier ~S ~_in the ~
297 generic function lambda list ~S~:>"
301 lambda-list
307 ;; no defaults or supplied-p vars allowed for &OPTIONAL or &KEY
310 \f
312 ;; Kill the existing definition of DEFMETHOD which expands to DEF!METHOD.
313 ;; It's there mainly so that DEFSTRUCT's printer options can expand
314 ;; to DEFMETHOD instead of a DEF!METHOD.
321 ;; :compile-toplevel is needed for subsequent forms
322 ;; :execute is needed for references to itself inside the body
324 ;; KLUDGE: this double expansion is quite a monumental
325 ;; workaround: it comes about because of a fantastic interaction
326 ;; between the processing rules of CLHS 3.2.3.1 and the
327 ;; bizarreness of MAKE-METHOD-LAMBDA.
328 ;;
329 ;; MAKE-METHOD-LAMBDA can be called by the user, and if the
330 ;; lambda itself doesn't refer to outside bindings the return
331 ;; value must be compileable in the null lexical environment.
332 ;; However, the function must also refer somehow to the
333 ;; associated method object, so that it can call NO-NEXT-METHOD
334 ;; with the appropriate arguments if there is no next method --
335 ;; but when the function is generated, the method object doesn't
336 ;; exist yet.
337 ;;
338 ;; In order to resolve this issue, we insert a literal cons cell
339 ;; into the body of the method lambda, return the same cons cell
340 ;; as part of the second (initargs) return value of
341 ;; MAKE-METHOD-LAMBDA, and a method on INITIALIZE-INSTANCE fills
342 ;; in the cell when the method is created. However, this
343 ;; strategy depends on having a fresh cons cell for every method
344 ;; lambda, which (without the workaround below) is skewered by
345 ;; the processing in CLHS 3.2.3.1, which permits implementations
346 ;; to macroexpand the bodies of EVAL-WHEN forms with both
347 ;; :COMPILE-TOPLEVEL and :LOAD-TOPLEVEL only once. The
348 ;; expansion below forces the double expansion in those cases,
349 ;; while expanding only once in the common case.
360 lambda-list body env)))
376 ;;; Take a name which is either a generic function name or a list specifying
377 ;;; a SETF generic function (like: (SETF <generic-function-name>)). Return
378 ;;; the prototype instance of the method-class for that generic function.
379 ;;;
380 ;;; If there is no generic function by that name, this returns the
381 ;;; default value, the prototype instance of the class
382 ;;; STANDARD-METHOD. This default value is also returned if the spec
383 ;;; names an ordinary function or even a macro. In effect, this leaves
384 ;;; the signalling of the appropriate error until load time.
385 ;;;
386 ;;; Note: During bootstrapping, this function is allowed to return NIL.
393 ; error at load time.
398 \f
399 ;;; These are used to communicate the method name and lambda-list to
400 ;;; MAKE-METHOD-LAMBDA-INTERNAL.
405 proto-gf
406 proto-method
407 qualifiers
408 lambda-list
409 body
410 env
411 ;; ENV could be of type SB!INTERPRETER:BASIC-ENV
412 ;; but I don't care to figure out what parts of PCL
413 ;; would have to change to accept that, so coerce.
421 specializers)
428 proto-gf proto-method method-function-lambda
429 initargs env))
431 proto-gf proto-method specializers env)))
433 ;; Note: We could DECLAIM the ftype of the generic function
434 ;; here, since ANSI specifies that we create it if it does
435 ;; not exist. However, I chose not to, because I think it's
436 ;; more useful to support a style of programming where every
437 ;; generic function has an explicit DEFGENERIC and any typos
438 ;; in DEFMETHODs are warned about. Otherwise
439 ;;
440 ;; (DEFGENERIC FOO-BAR-BLETCH (X))
441 ;; (DEFMETHOD FOO-BAR-BLETCH ((X HASH-TABLE)) ..)
442 ;; (DEFMETHOD FOO-BRA-BLETCH ((X SIMPLE-VECTOR)) ..)
443 ;; (DEFMETHOD FOO-BAR-BLETCH ((X VECTOR)) ..)
444 ;; (DEFMETHOD FOO-BAR-BLETCH ((X ARRAY)) ..)
445 ;; (DEFMETHOD FOO-BAR-BLETCH ((X LIST)) ..)
446 ;;
447 ;; compiles without raising an error and runs without
448 ;; raising an error (since SIMPLE-VECTOR cases fall through
449 ;; to VECTOR) but still doesn't do what was intended. I hate
450 ;; that kind of bug (code which silently gives the wrong
451 ;; answer), so we don't do a DECLAIM here. -- WHN 20000229
453 unspecialized-lambda-list
457 initargs-form)))))))
464 method-class-name initargs-form)
467 fn-lambda)
480 specializers)
491 ;; CONSTANT-FORM-VALUE? What I
492 ;; kind of want to know, though,
493 ;; is what happens if we don't do
494 ;; this for some slow-method
495 ;; function because of a hairy
496 ;; lexenv -- is the only bad
497 ;; effect that the method
498 ;; function ends up unnamed? If
499 ;; so, couldn't we arrange to
500 ;; name it later?
502 specl))
503 specializers))
511 name qualifiers `',specls
512 unspecialized-lambda-list method-class-name
514 #',mname
517 name qualifiers
518 specializers
519 #+nil
525 specializers))
526 unspecialized-lambda-list
527 method-class-name
528 initargs-form))))
532 method-class-name initargs-form)
534 ',method-class-name
535 ',name
536 ',qualifiers
537 ,specializers-form
538 ',unspecialized-lambda-list
539 ,initargs-form
548 proto-method
549 method-function-lambda
550 initargs
551 ;; FIXME: coerce-to-lexenv?
552 env))))
555 method-lambda initargs env)
560 is not a lambda form."
561 method-lambda))
568 ;;; When bootstrapping PCL MAKE-METHOD-LAMBDA starts out as a regular
569 ;;; functions: REAL-MAKE-METHOD-LAMBDA set to the fdefinition of
570 ;;; MAKE-METHOD-LAMBDA. Once generic functions are born, the
571 ;;; REAL-MAKE-METHOD lambda is used as the body of the default method.
572 ;;; MAKE-METHOD-LAMBDA-INTERNAL is split out into a separate function
573 ;;; so that changing it in a live image is easy, and changes actually
574 ;;; take effect.
592 is not a lambda form."
593 method-lambda))
596 ;; We have the %METHOD-NAME declaration in the place where we expect it only
597 ;; if there is are no non-standard prior MAKE-METHOD-LAMBDA methods -- or
598 ;; unless they're fantastically unintrusive.
601 ;; Macroexpansion caused by code-walking may call make-method-lambda and
602 ;; end up with wrong values
610 ;; the method-cell is a way of communicating what method a
611 ;; method-function implements, for the purpose of
612 ;; NO-NEXT-METHOD. We need something that can be shared
613 ;; between function and initargs, but not something that
614 ;; will be coalesced as a constant (because we are naughty,
615 ;; oh yes) with the expansion of any other methods in the
616 ;; same file. -- CSR, 2007-05-30
622 parameters
623 specializers))
627 ;; These declarations seem to be used by PCL to pass
628 ;; information to itself; when I tried to delete 'em
629 ;; ca. 0.6.10 it didn't work. I'm not sure how
630 ;; they work, but note the (VAR-DECLARATION '%CLASS ..)
631 ;; expression in CAN-OPTIMIZE-ACCESS1. -- WHN 2000-12-30
636 parameters
637 specializers))
638 ;; These TYPE declarations weren't in the original
639 ;; PCL code, but the Python compiler likes them a
640 ;; lot. (We're telling the compiler about our
641 ;; knowledge of specialized argument types so that
642 ;; it can avoid run-time type dispatch overhead,
643 ;; which can be a huge win for Python.)
644 ;;
645 ;; KLUDGE: when I tried moving these to
646 ;; ADD-METHOD-DECLARATIONS, things broke. No idea
647 ;; why. -- CSR, 2004-06-16
651 par spec specials env))
652 parameters
653 specializers))))
655 ;; Remove the documentation string and insert the
656 ;; appropriate class declarations. The documentation
657 ;; string is removed to make it easy for us to insert
658 ;; new declarations later, they will just go after the
659 ;; CADR of the method lambda. The class declarations
660 ;; are inserted to communicate the class of the method's
661 ;; arguments to the code walk.
663 ;; The default ignorability of method parameters
664 ;; doesn't seem to be specified by ANSI. PCL had
665 ;; them basically ignorable but was a little
666 ;; inconsistent. E.g. even though the two
667 ;; method definitions
668 ;; (DEFMETHOD FOO ((X T) (Y T)) "Z")
669 ;; (DEFMETHOD FOO ((X T) Y) "Z")
670 ;; are otherwise equivalent, PCL treated Y as
671 ;; ignorable in the first definition but not in the
672 ;; second definition. We make all required
673 ;; parameters ignorable as a way of systematizing
674 ;; the old PCL behavior. -- WHN 2000-11-24
676 ,class-declarations
677 ,@declarations
696 parameters-setqd)
698 required-parameters
699 env
700 slots)
702 walked-declarations
703 walked-documentation)
714 ,slot-name-lists
724 aux))))
727 (,lambda-list .method-args. .next-methods.
728 :call-next-method-p
734 ,@walked-declarations
737 %parameter-binding-modified))
741 %parameter-binding-modified))
756 name)
762 ;; FIXME: Document CLASS-EQ specializers.
764 :format-control
765 "~@<~S is not a valid parameter specializer name.~@:>"
778 result
780 specializer generic-function))))
788 ;; FIXME: this HANDLER-CASE is a bit of a hammer to crack a nut:
789 ;; the idea is that we want to unparse permissively, so that the
790 ;; lazy (or rather the "portable") specializer extender (who
791 ;; does not define methods on these new SBCL-specific MOP
792 ;; functions) can still subclass specializer and define methods
793 ;; without everything going wrong. Making it cleaner and
794 ;; clearer that that is what we are defending against would be
795 ;; nice. -- CSR, 2007-06-01
802 class-name
803 type))
804 type))
807 specializer generic-function)))
813 ;;; a helper function for creating Python-friendly type declarations
814 ;;; in DEFMETHOD forms.
815 ;;;
816 ;;; We're too lazy to cons up a new environment for this, so we just pass in
817 ;;; the list of locally declared specials in addition to the old environment.
822 ;; KLUDGE: ANSI, in its wisdom, says that
823 ;; EQL-SPECIALIZER-FORMs in EQL specializers are evaluated at
824 ;; DEFMETHOD expansion time. Thus, although one might think
825 ;; that in
826 ;; (DEFMETHOD FOO ((X PACKAGE)
827 ;; (Y (EQL 12))
828 ;; ..))
829 ;; the PACKAGE and (EQL 12) forms are both parallel type
830 ;; names, they're not, as is made clear when you do
831 ;; (DEFMETHOD FOO ((X PACKAGE)
832 ;; (Y (EQL 'BAR)))
833 ;; ..)
834 ;; where Y needs to be a symbol named "BAR", not some cons
835 ;; made by (CONS 'QUOTE 'BAR). I.e. when the
836 ;; EQL-SPECIALIZER-FORM is (EQL 'X), it requires an argument
837 ;; to be of type (EQL X). It'd be easy to transform one to
838 ;; the other, but it'd be somewhat messier to do so while
839 ;; ensuring that the EQL-SPECIALIZER-FORM is only EVAL'd
840 ;; once. (The new code wouldn't be messy, but it'd require a
841 ;; big transformation of the old code.) So instead we punt.
842 ;; -- WHN 20000610
845 ;; KLUDGE: For some low-level implementation
846 ;; classes, perhaps because of some problems related
847 ;; to the incomplete integration of PCL into SBCL's
848 ;; type system, some specializer classes can't be
849 ;; declared as argument types. E.g.
850 ;; (DEFMETHOD FOO ((X SLOT-OBJECT))
851 ;; (DECLARE (TYPE SLOT-OBJECT X))
852 ;; ..)
853 ;; loses when
854 ;; (DEFSTRUCT BAR A B)
855 ;; (FOO (MAKE-BAR))
856 ;; perhaps because of the way that STRUCTURE-OBJECT
857 ;; inherits both from SLOT-OBJECT and from
858 ;; SB-KERNEL:INSTANCE. In an effort to sweep such
859 ;; problems under the rug, we exclude these problem
860 ;; cases by blacklisting them here. -- WHN 2001-01-19
864 ;; KLUDGE: PCL, in its wisdom, sometimes calls methods with
865 ;; types which don't match their specializers. (Specifically,
866 ;; it calls ENSURE-CLASS-USING-CLASS (T NULL) with a non-NULL
867 ;; second argument.) Hopefully it only does this kind of
868 ;; weirdness when bootstrapping.. -- WHN 20000610
873 ;; Don't declare types for special variables -- our rebinding magic
874 ;; for SETQ cases don't work right there as SET, (SETF SYMBOL-VALUE),
875 ;; etc. make things undecidable.
878 ;; Otherwise, we can usually make Python very happy.
879 ;;
880 ;; KLUDGE: Since INFO doesn't work right for class objects here,
881 ;; and they are valid specializers, see if the specializer is
882 ;; a named class, and use the name in that case -- otherwise
883 ;; the class instance is ok, since info will just return NIL, NIL.
884 ;;
885 ;; We still need to deal with the class case too, but at
886 ;; least #.(find-class 'integer) and integer as equivalent
887 ;; specializers with this.
894 specializer))
908 ;; CLASS can be null here if the user has
909 ;; erroneously tried to use a defined type as a
910 ;; specializer; it can be a non-SYSTEM-CLASS if
911 ;; the user defines a type and calls (SETF
912 ;; FIND-CLASS) in a consistent way.
921 ;; don't declare CLOS classes as parameters;
922 ;; it's too expensive.
925 ;; we can get here, and still not have a failure
926 ;; case, by doing MOP programming like (PROGN
927 ;; (ENSURE-CLASS 'FOO) (DEFMETHOD BAR ((X FOO))
928 ;; ...)). Best to let the user know we haven't
929 ;; been able to extract enough information:
931 "~@<can't find type for specializer ~S in ~S.~@:>"
932 specializer-nameoid
938 ;;; For passing a list (groveled by the walker) of the required
939 ;;; parameters whose bindings are modified in the method body to the
940 ;;; optimized-slot-value* macros.
944 method-args
945 next-methods
956 next-method-call
957 args
958 rest-arg
967 parameters-setqd applyp method-cell))
968 &body body
972 ;; always provide the lexical function NEXT-METHOD-P.
973 ;; I would think this to be a good candidate for declaring INLINE
974 ;; but that's not the way it was done before.
985 `((%check-cnm-args cnm-args
986 ,method-args
988 nil)
996 ',method-cell
1005 ;; Can't easily provide a RETRY restart here, as the return value here is
1006 ;; for the method, not the generic function.
1008 method args)))
1026 call-method-args)
1028 value)
1049 pv
1050 next-method-call
1051 arg-info)
1054 value)
1058 ;; The two variants of INVOKE-FAST-METHOD-CALL differ in how REST-ARGs
1059 ;; are handled. The first one will get REST-ARG as a single list (as
1060 ;; the last argument), and will thus need to use APPLY. The second one
1061 ;; will get them as a &MORE argument, so we can pass the arguments
1062 ;; directly with MULTIPLE-VALUE-CALL and %MORE-ARG-VALUES.
1071 more-context
1072 more-count
1078 ,@required-args
1081 ;; The cases with only small amounts of required arguments passed
1082 ;; are probably very common, and special-casing speeds them up by
1083 ;; a factor of 2 with very little effect on the other
1084 ;; cases. Though it'd be nice to have the generic case be equally
1085 ;; fast.
1092 ,@required-args
1103 \f
1104 ;;;; effective method functions
1110 ;;; This function was in the CMU CL version of PCL (ca Debian 2.4.8)
1111 ;;; without explanation. It appears to be intended for debugging, so
1112 ;;; it might be useful someday, so I haven't deleted it.
1113 ;;; But it isn't documented and isn't used for anything now, so
1114 ;;; I've conditionalized it out of the base system. -- WHN 19991213
1115 #+sb-show
1148 ,@more-arg
1151 ,restp
1152 ,@required-args
1157 ;; "What," you may wonder, "do these next two clauses do?" In that
1158 ;; case, you are not a PCL implementor, for they considered this to
1159 ;; be self-documenting.:-| Or CSR, for that matter, since he can
1160 ;; also figure it out by looking at it without breaking stride. For
1161 ;; the rest of us, though: From what the code is doing with .SLOTS.
1162 ;; and whatnot, evidently it's implementing SLOT-VALUEish and
1163 ;; GET-SLOT-VALUEish things. Then we can reason backwards and
1164 ;; conclude that setting EMF to a FIXNUM is an optimized way to
1165 ;; represent these slot access operations.
1176 value)))))
1184 ;; (In cmucl-2.4.8 there was a commented-out third ,@(WHEN
1185 ;; ...) clause here to handle SLOT-BOUNDish stuff. Since
1186 ;; there was no explanation and presumably the code is 10+
1187 ;; years stale, I simply deleted it. -- WHN)
1188 )))
1190 ;;; Before SBCL 0.9.16.7 instead of
1191 ;;; INVOKE-NARROW-EFFECTIVE-METHOD-FUNCTION we passed a (THE (OR
1192 ;;; FUNCTION METHOD-CALL FAST-METHOD-CALL) EMF) form as the EMF. Now,
1193 ;;; to make less work for the compiler we take a path that doesn't
1194 ;;; involve the slot-accessor clause (where EMF is a FIXNUM) at all.
1209 ,@more-arg
1212 ,restp
1213 ,@required-args
1217 emf-n restp required-args))
1240 args)
1263 args))))))
1266 args
1278 value)))
1295 \f
1298 method-cell
1299 cnm-args)
1302 ,next-method-call
1314 ,@args
1320 call-next-method-p
1321 setq-p
1322 parameters-setqd
1323 method-cell
1324 applyp))
1325 &body body
1345 nil)
1347 ,next-method-call
1349 ,method-cell
1350 cnm-args))))
1356 ;;; CMUCL comment (Gerd Moellmann):
1357 ;;;
1358 ;;; The standard says it's an error if CALL-NEXT-METHOD is called with
1359 ;;; arguments, and the set of methods applicable to those arguments is
1360 ;;; different from the set of methods applicable to the original
1361 ;;; method arguments. (According to Barry Margolin, this rule was
1362 ;;; probably added to ensure that before and around methods are always
1363 ;;; run before primary methods.)
1364 ;;;
1365 ;;; This could be optimized for the case that the generic function
1366 ;;; doesn't have hairy methods, does have standard method combination,
1367 ;;; is a standard generic function, there are no methods defined on it
1368 ;;; for COMPUTE-APPLICABLE-METHODS and probably a lot more of such
1369 ;;; preconditions. That looks hairy and is probably not worth it,
1370 ;;; because this check will never be fast.
1372 ;; 1. Check for no arguments.
1377 ;; 2. Requirement arguments pairwise: if all are EQL, the applicable
1378 ;; methods must be the same. This takes care of the relatively common
1379 ;; case of twiddling with &KEY arguments without being horribly
1380 ;; expensive.
1387 ;; 3. Only then do the full check.
1392 ~{~S~^, ~} to call-next-method is different from ~
1393 the set of methods ~S applicable to the original ~
1394 method argument~P ~{~S~^, ~}.~@:>"
1398 ;; FIXME: replacing this entire mess with DESTRUCTURING-BIND would correct
1399 ;; problems similar to those already solved by a correct implementation
1400 ;; of DESTRUCTURING-BIND, such as incorrect binding order:
1401 ;; e.g. (macroexpand-1 '(bind-args ((&optional (x nil xsp)) args) (form)))
1402 ;; -> (LET* ((.ARGS-TAIL. ARGS) (XSP (NOT (NULL .ARGS-TAIL.))) (X ...)))
1403 ;; It's mostly irrelevant unless a method uses CALL-NEXT-METHOD though.
1419 "encountered the non-standard lambda list keyword ~S"
1420 var)))
1421 nil)
1469 ,@bindings
1470 (.dummy0.
1482 ;; FIXME: Do we want to export this symbol? Or maybe use an
1483 ;; (ERROR 'SIMPLE-PROGRAM-ERROR) form?
1486 return tail))
1490 ;; method definition
1492 ;; a list of all required parameters whose bindings might be
1493 ;; modified in the method body.
1500 ;; hierarchy: nil -> :simple -> T.
1503 form)
1505 ;; The walker will split (SETQ A 1 B 2) to
1506 ;; separate (SETQ A 1) and (SETQ B 2) forms, so we
1507 ;; only need to handle the simple case of SETQ
1508 ;; here.
1513 ;; Note that we don't need to check for
1514 ;; %VARIABLE-REBINDING declarations like is
1515 ;; done in CAN-OPTIMIZE-ACCESS1, since the
1516 ;; bindings that will have that declation will
1517 ;; never be SETQd.
1519 ;; If a parameter binding is shadowed by
1520 ;; another binding it won't have a %CLASS
1521 ;; declaration anymore, and this won't get
1522 ;; executed.
1524 form)
1528 form)
1536 form))
1540 ;;; FIXME: the walker's rewriting of the source code causes
1541 ;;; trouble when doing code coverage. The rewrites should be
1542 ;;; removed, and the same operations done using
1543 ;;; compiler-macros or tranforms.
1545 walked-lambda
1546 method-lambda)
1547 call-next-method-p
1549 parameters-setqd)))))
1557 \f
1567 new-value)
1569 \f
1575 #+nil
1579 ll initargs source-location)))
1583 initargs source-location)
1592 :name gf-spec
1593 :new-location source-location
1594 :old-method method
1597 gf-spec qualifiers specializers lambda-list
1598 :definition-source source-location
1599 initargs)))
1602 ;; FIXME: should be STYLE-WARNING?
1604 "~&At the time the method with qualifiers ~:S and~%~
1605 specializers ~:S on the generic function ~S~%~
1606 was compiled, the method-class for that generic function was~%~
1607 ~S. But, the method class is now ~S, this~%~
1608 may mean that this method was compiled improperly.~%"
1609 qualifiers specializers gf-spec
1611 method))
1639 \f
1642 ;; We say "&MUMBLE is not allowed in a generic function lambda list"
1643 ;; whether this is called by DEFMETHOD or DEFGENERIC.
1644 ;; [It is used for either. Why else recognize and silently ignore &AUX?]
1648 :silent t
1654 ;; FIXME: this does more than return an FTYPE from a lambda list -
1655 ;; it unions the type with an existing ctype object. It needs a better name,
1656 ;; and to be reimplemented as "union and call sb-c::ftype-from-lambda-list".
1667 old-ftype))))
1682 keywords)
1685 *))))
1686 \f
1687 ;;;; early generic function support
1691 ;; CLHS doesn't specify &allow-other-keys here but I guess the supposition
1692 ;; is that they'll be checked by ENSURE-GENERIC-FUNCTION-USING-CLASS.
1693 ;; Except we don't do that either, so I think the blame, if any, lies there
1694 ;; for not catching errant keywords.
1706 existing fun-name all-keys)))))
1710 'simple-program-error
1761 arg-info-precedence
1762 arg-info-metatypes
1763 arg-info-number-optional
1764 arg-info-key/rest-p
1765 arg-info-keys ;nil no &KEY or &REST allowed
1766 ;(k1 k2 ..) Each method must accept these &KEY arguments.
1767 ;T must have &KEY or &REST
1769 gf-info-simple-accessor-type ; nil, reader, writer, boundp
1772 gf-info-static-c-a-m-emf
1774 gf-info-fast-mf-p)
1792 ;;; Create a gf lambda list from a method lambda list
1801 argument-precedence-order)
1825 existing methods of ~S."
1826 lambda-list gf))))
1829 lambda-list
1845 arg-info))
1855 to the generic function~2I~_~S;~I~_~
1856 but ~?~:>"
1866 "the method has ~A required arguments than the generic function."
1870 "the method has ~A optional arguments than the generic function."
1874 "the method and generic function differ in whether they accept~_~
1881 ~S."
1882 gf-keywords)))))))
1891 ;;; FIXME: we don't actually need this; we could test for the exact
1892 ;;; class and deal with it as appropriate. In fact we probably don't
1893 ;;; need it anyway because we only use this for METHOD-SPECIALIZERS on
1894 ;;; the standard reader method for METHOD-SPECIALIZERS. Probably.
1906 standard-writer-method standard-boundp-method
1907 global-reader-method global-writer-method
1908 global-boundp-method))
1938 nil)))
1986 nil)
1992 ;; FIXME: this test will eventually be
1993 ;; superseded by the *internal-pcl...* test,
1994 ;; above. While we are in a process of
1995 ;; transition, however, it should probably
1996 ;; remain.
2002 #'make-method-lambda
2013 arg-info)
2015 ;;; This is the early definition of ENSURE-GENERIC-FUNCTION-USING-CLASS.
2016 ;;;
2017 ;;; The STATIC-SLOTS field of the funcallable instances used as early
2018 ;;; generic functions is used to store the early methods and early
2019 ;;; discriminator code for the early generic function. The static
2020 ;;; slots field of the fins contains a list whose:
2021 ;;; CAR - a list of the early methods on this early gf
2022 ;;; CADR - the early discriminator code for this method
2025 lambda-list-p)
2026 argument-precedence-order
2027 definition-source
2028 documentation
2034 existing)
2038 argument-precedence-order definition-source
2039 documentation)
2047 argument-precedence-order definition-source
2048 documentation))))
2051 function argument-precedence-order source-location
2052 documentation)
2056 fin
2081 :lambda-list lambda-list
2084 fin))
2094 new-value)
2100 dfun)))
2103 ;; Check that we are under the lock.
2104 #+sb-thread
2109 new-state))))
2110 dfun)
2145 nil)
2160 class nor a symbol that names a class."
2164 ;; FIXME: reference MOP documentation -- this is an
2165 ;; additional requirement on our users
2182 method-class)
2187 ;; Use the existing lambda-list, if any. It is reasonable to do eg.
2188 ;;
2189 ;; (if (fboundp name)
2190 ;; (ensure-generic-function name)
2191 ;; (ensure-generic-function name :lambda-list '(foo)))
2192 ;;
2193 ;; in which case we end up here with no lambda-list in the first leg.
2197 t)
2206 ;; FIXME: Ideally we would like to not clobber it, but because generic
2207 ;; functions assert their FTYPEs callers believing the FTYPE are left with
2208 ;; unsafe assumptions. Hence the clobbering. Be quiet when the new type
2209 ;; is a subtype of the old one, though -- even though the type is not
2210 ;; trusted anymore, the warning is still not quite as interesting.
2214 for the same name with ~S.~:@>"
2215 fun-name 'ftype
2220 fun-name))
2224 fun-name
2225 &rest all-keys
2230 ;; KLUDGE: the above macro does SETQ on GENERIC-FUNCTION-CLASS,
2231 ;; which is what makes the next line work
2240 fun-name
2241 &rest all-keys
2252 \f
2259 ;;; FIXME: this function took on a slightly greater role than it
2260 ;;; previously had around 2005-11-02, when CSR fixed the bug whereby
2261 ;;; having more than one subclass of standard-generic-function caused
2262 ;;; the whole system to die horribly through a metacircle in
2263 ;;; GF-ARG-INFO. The fix is to be slightly more disciplined about
2264 ;;; calling accessor methods -- we call GET-GENERIC-FUN-INFO when
2265 ;;; computing discriminating functions, so we need to be careful about
2266 ;;; having a base case for the recursion, and we provide that with the
2267 ;;; STANDARD-GENERIC-FUNCTION case below. However, we are not (yet)
2268 ;;; as disciplined as CLISP's CLOS/MOP, and it would be nice to get to
2269 ;;; that stage, where all potentially dangerous cases are enumerated
2270 ;;; and stopped. -- CSR, 2005-11-02.
2272 ;; values nreq applyp metatypes nkeys arg-info
2279 metatypes
2280 arg-info))
2289 nkeys
2290 arg-info))))
2301 &key slot-name object-class method-class-function
2302 definition-source)
2305 ;; Figure out whether we got class objects or class names as the
2306 ;; specializers and set parsed and unparsed appropriately. If we
2307 ;; got class objects, then we can compute unparsed, but if we got
2308 ;; class names we don't try to compute parsed.
2309 ;;
2315 specializers))
2317 parsed ()))
2327 ;; the parsed specializers. This is used by
2328 ;; EARLY-METHOD-SPECIALIZERS to cache the parse.
2329 ;; Note that this only comes into play when there is
2330 ;; more than one early method on an early gf.
2331 parsed
2333 ;; A list to which REAL-MAKE-A-METHOD can be applied
2334 ;; to make a real method corresponding to this early
2335 ;; one.
2338 initargs doc)
2344 result)))
2349 definition-source)
2360 :slot-definition slot-definition
2364 initargs)
2365 :definition-source definition-source
2366 initargs)))
2386 ;;; Fetch the specializers of an early method. This is basically just
2387 ;;; a simple accessor except that when the second argument is t, this
2388 ;;; converts the specializers from symbols into class objects. The
2389 ;;; class objects are cached in the early method, this makes
2390 ;;; bootstrapping faster because the class objects only have to be
2391 ;;; computed once.
2392 ;;;
2393 ;;; NOTE:
2394 ;;; The second argument should only be passed as T by
2395 ;;; early-lookup-method. This is to implement the rule that only when
2396 ;;; there is more than one early method on a generic function is the
2397 ;;; conversion from class names to class objects done. This
2398 ;;; corresponds to the fact that we are only allowed to have one
2399 ;;; method on any generic function up until the time classes exist.
2424 specializers arglist &rest initargs
2425 &key documentation definition-source
2428 ;; argument here because the default,
2429 ;; STANDARD-GENERIC-FUNCTION, is right for all early generic
2430 ;; functions. (See REAL-ADD-NAMED-METHOD)
2440 specializers initargs documentation
2445 ;;; This is the early version of ADD-METHOD. Later this will become a
2446 ;;; generic function. See !FIX-EARLY-GENERIC-FUNCTIONS which has
2447 ;;; special knowledge about ADD-METHOD.
2460 ;;; This is the early version of REMOVE-METHOD. See comments on
2461 ;;; the early version of ADD-METHOD.
2475 ;;; This is the early version of GET-METHOD. See comments on the early
2476 ;;; version of ADD-METHOD.
2482 specializers)
2484 specializers))
2489 nil))
2492 ;; minor KLUDGE: a separate code component for this function allows GCing
2493 ;; a few symbols and their associated code that would otherwise be retained:
2494 ;; *!EARLY-{GENERIC-}FUNCTIONS*, *!GENERIC-FUNCTION-FIXUPS*
2502 ;; Rearrange *!EARLY-GENERIC-FUNCTIONS* to speed up
2503 ;; FIX-EARLY-GENERIC-FUNCTIONS.
2510 generic-function-methods
2511 method-specializers
2512 specializer-type
2513 specializer-class
2514 slot-definition-location
2515 slot-definition-name
2516 class-slots
2517 gf-arg-info
2518 class-precedence-list
2519 slot-boundp-using-class
2521 slot-value-using-class)))
2532 early-method))))
2535 early-method t))
2564 ()
2565 lambda-list
2566 specializers
2567 initargs
2568 nil)))
2575 \f
2576 ;;; PARSE-DEFMETHOD is used by DEFMETHOD to parse the &REST argument
2577 ;;; into the 'real' arguments. This is where the syntax of DEFMETHOD
2578 ;;; is really implemented.
2600 \f
2604 ;; We don't need these, but according to the unit tests,
2605 ;; they're mandated by AMOP.
2611 ()
2614 ;; Return 3 values:
2615 ;; - the bound variables, without defaults, supplied-p vars, or &AUX vars.
2616 ;; - the lambda list without specializers.
2617 ;; - just the specializers
2621 arglist
2630 rest
2631 ;; Preserve keyword-names when given as (:KEYWORD var)
2637 \f
2639 \f
2640 ;;; FIXME: In here there was a #-CMU definition of SYMBOL-MACROLET
2641 ;;; which used %WALKER stuff. That suggests to me that maybe the code
2642 ;;; walker stuff was only used for implementing stuff like that; maybe
2643 ;;; it's not needed any more? Hunt down what it was used for and see.
2650 form)))
2659 ,in
2663 slot-entry
2667 slot-entry
2669 `(,var-name
2671 slots)
2681 ,in
2686 slots)