| blob | af92e066080b3b1c5a617411616142aef8456655 |
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.
316 ;;; As per CLHS -
317 ;;; "defmethod is not required to perform any compile-time side effects."
318 ;;; and we don't do much other than to make the function be defined,
319 ;;; which means that checking of callers' arglists can only occur after called
320 ;;; methods are actually loaded.
326 ;; :compile-toplevel is needed for subsequent forms
327 ;; :execute is needed for references to itself inside the body
329 ;; KLUDGE: this double expansion is quite a monumental
330 ;; workaround: it comes about because of a fantastic interaction
331 ;; between the processing rules of CLHS 3.2.3.1 and the
332 ;; bizarreness of MAKE-METHOD-LAMBDA.
333 ;;
334 ;; MAKE-METHOD-LAMBDA can be called by the user, and if the
335 ;; lambda itself doesn't refer to outside bindings the return
336 ;; value must be compileable in the null lexical environment.
337 ;; However, the function must also refer somehow to the
338 ;; associated method object, so that it can call NO-NEXT-METHOD
339 ;; with the appropriate arguments if there is no next method --
340 ;; but when the function is generated, the method object doesn't
341 ;; exist yet.
342 ;;
343 ;; In order to resolve this issue, we insert a literal cons cell
344 ;; into the body of the method lambda, return the same cons cell
345 ;; as part of the second (initargs) return value of
346 ;; MAKE-METHOD-LAMBDA, and a method on INITIALIZE-INSTANCE fills
347 ;; in the cell when the method is created. However, this
348 ;; strategy depends on having a fresh cons cell for every method
349 ;; lambda, which (without the workaround below) is skewered by
350 ;; the processing in CLHS 3.2.3.1, which permits implementations
351 ;; to macroexpand the bodies of EVAL-WHEN forms with both
352 ;; :COMPILE-TOPLEVEL and :LOAD-TOPLEVEL only once. The
353 ;; expansion below forces the double expansion in those cases,
354 ;; while expanding only once in the common case.
365 lambda-list body env)))
381 ;;; Take a name which is either a generic function name or a list specifying
382 ;;; a SETF generic function (like: (SETF <generic-function-name>)). Return
383 ;;; the prototype instance of the method-class for that generic function.
384 ;;;
385 ;;; If there is no generic function by that name, this returns the
386 ;;; default value, the prototype instance of the class
387 ;;; STANDARD-METHOD. This default value is also returned if the spec
388 ;;; names an ordinary function or even a macro. In effect, this leaves
389 ;;; the signalling of the appropriate error until load time.
390 ;;;
391 ;;; Note: During bootstrapping, this function is allowed to return NIL.
398 ; error at load time.
403 \f
404 ;;; These are used to communicate the method name and lambda-list to
405 ;;; MAKE-METHOD-LAMBDA-INTERNAL.
410 proto-gf
411 proto-method
412 qualifiers
413 lambda-list
414 body
415 env
416 ;; ENV could be of type SB!INTERPRETER:BASIC-ENV
417 ;; but I don't care to figure out what parts of PCL
418 ;; would have to change to accept that, so coerce.
426 specializers)
433 proto-gf proto-method method-function-lambda
434 initargs env))
436 proto-gf proto-method specializers env)))
438 ;; Note: We could DECLAIM the ftype of the generic function
439 ;; here, since ANSI specifies that we create it if it does
440 ;; not exist. However, I chose not to, because I think it's
441 ;; more useful to support a style of programming where every
442 ;; generic function has an explicit DEFGENERIC and any typos
443 ;; in DEFMETHODs are warned about. Otherwise
444 ;;
445 ;; (DEFGENERIC FOO-BAR-BLETCH (X))
446 ;; (DEFMETHOD FOO-BAR-BLETCH ((X HASH-TABLE)) ..)
447 ;; (DEFMETHOD FOO-BRA-BLETCH ((X SIMPLE-VECTOR)) ..)
448 ;; (DEFMETHOD FOO-BAR-BLETCH ((X VECTOR)) ..)
449 ;; (DEFMETHOD FOO-BAR-BLETCH ((X ARRAY)) ..)
450 ;; (DEFMETHOD FOO-BAR-BLETCH ((X LIST)) ..)
451 ;;
452 ;; compiles without raising an error and runs without
453 ;; raising an error (since SIMPLE-VECTOR cases fall through
454 ;; to VECTOR) but still doesn't do what was intended. I hate
455 ;; that kind of bug (code which silently gives the wrong
456 ;; answer), so we don't do a DECLAIM here. -- WHN 20000229
458 unspecialized-lambda-list
462 initargs-form)))))))
469 method-class-name initargs-form)
472 fn-lambda)
485 specializers)
496 ;; CONSTANT-FORM-VALUE? What I
497 ;; kind of want to know, though,
498 ;; is what happens if we don't do
499 ;; this for some slow-method
500 ;; function because of a hairy
501 ;; lexenv -- is the only bad
502 ;; effect that the method
503 ;; function ends up unnamed? If
504 ;; so, couldn't we arrange to
505 ;; name it later?
507 specl))
508 specializers))
516 name qualifiers `',specls
517 unspecialized-lambda-list method-class-name
519 #',mname
522 name qualifiers
523 specializers
524 #+nil
530 specializers))
531 unspecialized-lambda-list
532 method-class-name
533 initargs-form))))
537 method-class-name initargs-form)
539 ',method-class-name
540 ',name
541 ',qualifiers
542 ,specializers-form
543 ',unspecialized-lambda-list
544 ,initargs-form
553 proto-method
554 method-function-lambda
555 initargs
556 ;; FIXME: coerce-to-lexenv?
557 env))))
560 method-lambda initargs env)
565 is not a lambda form."
566 method-lambda))
573 ;;; When bootstrapping PCL MAKE-METHOD-LAMBDA starts out as a regular
574 ;;; functions: REAL-MAKE-METHOD-LAMBDA set to the fdefinition of
575 ;;; MAKE-METHOD-LAMBDA. Once generic functions are born, the
576 ;;; REAL-MAKE-METHOD lambda is used as the body of the default method.
577 ;;; MAKE-METHOD-LAMBDA-INTERNAL is split out into a separate function
578 ;;; so that changing it in a live image is easy, and changes actually
579 ;;; take effect.
597 is not a lambda form."
598 method-lambda))
601 ;; We have the %METHOD-NAME declaration in the place where we expect it only
602 ;; if there is are no non-standard prior MAKE-METHOD-LAMBDA methods -- or
603 ;; unless they're fantastically unintrusive.
606 ;; Macroexpansion caused by code-walking may call make-method-lambda and
607 ;; end up with wrong values
615 ;; the method-cell is a way of communicating what method a
616 ;; method-function implements, for the purpose of
617 ;; NO-NEXT-METHOD. We need something that can be shared
618 ;; between function and initargs, but not something that
619 ;; will be coalesced as a constant (because we are naughty,
620 ;; oh yes) with the expansion of any other methods in the
621 ;; same file. -- CSR, 2007-05-30
627 parameters
628 specializers))
632 ;; These declarations seem to be used by PCL to pass
633 ;; information to itself; when I tried to delete 'em
634 ;; ca. 0.6.10 it didn't work. I'm not sure how
635 ;; they work, but note the (VAR-DECLARATION '%CLASS ..)
636 ;; expression in CAN-OPTIMIZE-ACCESS1. -- WHN 2000-12-30
641 parameters
642 specializers))
643 ;; These TYPE declarations weren't in the original
644 ;; PCL code, but the Python compiler likes them a
645 ;; lot. (We're telling the compiler about our
646 ;; knowledge of specialized argument types so that
647 ;; it can avoid run-time type dispatch overhead,
648 ;; which can be a huge win for Python.)
649 ;;
650 ;; KLUDGE: when I tried moving these to
651 ;; ADD-METHOD-DECLARATIONS, things broke. No idea
652 ;; why. -- CSR, 2004-06-16
656 par spec specials env))
657 parameters
658 specializers))))
660 ;; Remove the documentation string and insert the
661 ;; appropriate class declarations. The documentation
662 ;; string is removed to make it easy for us to insert
663 ;; new declarations later, they will just go after the
664 ;; CADR of the method lambda. The class declarations
665 ;; are inserted to communicate the class of the method's
666 ;; arguments to the code walk.
668 ;; The default ignorability of method parameters
669 ;; doesn't seem to be specified by ANSI. PCL had
670 ;; them basically ignorable but was a little
671 ;; inconsistent. E.g. even though the two
672 ;; method definitions
673 ;; (DEFMETHOD FOO ((X T) (Y T)) "Z")
674 ;; (DEFMETHOD FOO ((X T) Y) "Z")
675 ;; are otherwise equivalent, PCL treated Y as
676 ;; ignorable in the first definition but not in the
677 ;; second definition. We make all required
678 ;; parameters ignorable as a way of systematizing
679 ;; the old PCL behavior. -- WHN 2000-11-24
681 ,class-declarations
682 ,@declarations
701 parameters-setqd)
703 required-parameters
704 env
705 slots)
707 walked-declarations
708 walked-documentation)
719 ,slot-name-lists
729 aux))))
732 (,lambda-list .method-args. .next-methods.
733 :call-next-method-p
739 ,@walked-declarations
742 %parameter-binding-modified))
746 %parameter-binding-modified))
761 name)
767 ;; FIXME: Document CLASS-EQ specializers.
769 :format-control
770 "~@<~S is not a valid parameter specializer name.~@:>"
783 result
785 specializer generic-function))))
793 ;; FIXME: this HANDLER-CASE is a bit of a hammer to crack a nut:
794 ;; the idea is that we want to unparse permissively, so that the
795 ;; lazy (or rather the "portable") specializer extender (who
796 ;; does not define methods on these new SBCL-specific MOP
797 ;; functions) can still subclass specializer and define methods
798 ;; without everything going wrong. Making it cleaner and
799 ;; clearer that that is what we are defending against would be
800 ;; nice. -- CSR, 2007-06-01
807 class-name
808 type))
809 type))
812 specializer generic-function)))
818 ;;; a helper function for creating Python-friendly type declarations
819 ;;; in DEFMETHOD forms.
820 ;;;
821 ;;; We're too lazy to cons up a new environment for this, so we just pass in
822 ;;; the list of locally declared specials in addition to the old environment.
827 ;; KLUDGE: ANSI, in its wisdom, says that
828 ;; EQL-SPECIALIZER-FORMs in EQL specializers are evaluated at
829 ;; DEFMETHOD expansion time. Thus, although one might think
830 ;; that in
831 ;; (DEFMETHOD FOO ((X PACKAGE)
832 ;; (Y (EQL 12))
833 ;; ..))
834 ;; the PACKAGE and (EQL 12) forms are both parallel type
835 ;; names, they're not, as is made clear when you do
836 ;; (DEFMETHOD FOO ((X PACKAGE)
837 ;; (Y (EQL 'BAR)))
838 ;; ..)
839 ;; where Y needs to be a symbol named "BAR", not some cons
840 ;; made by (CONS 'QUOTE 'BAR). I.e. when the
841 ;; EQL-SPECIALIZER-FORM is (EQL 'X), it requires an argument
842 ;; to be of type (EQL X). It'd be easy to transform one to
843 ;; the other, but it'd be somewhat messier to do so while
844 ;; ensuring that the EQL-SPECIALIZER-FORM is only EVAL'd
845 ;; once. (The new code wouldn't be messy, but it'd require a
846 ;; big transformation of the old code.) So instead we punt.
847 ;; -- WHN 20000610
850 ;; KLUDGE: For some low-level implementation
851 ;; classes, perhaps because of some problems related
852 ;; to the incomplete integration of PCL into SBCL's
853 ;; type system, some specializer classes can't be
854 ;; declared as argument types. E.g.
855 ;; (DEFMETHOD FOO ((X SLOT-OBJECT))
856 ;; (DECLARE (TYPE SLOT-OBJECT X))
857 ;; ..)
858 ;; loses when
859 ;; (DEFSTRUCT BAR A B)
860 ;; (FOO (MAKE-BAR))
861 ;; perhaps because of the way that STRUCTURE-OBJECT
862 ;; inherits both from SLOT-OBJECT and from
863 ;; SB-KERNEL:INSTANCE. In an effort to sweep such
864 ;; problems under the rug, we exclude these problem
865 ;; cases by blacklisting them here. -- WHN 2001-01-19
869 ;; KLUDGE: PCL, in its wisdom, sometimes calls methods with
870 ;; types which don't match their specializers. (Specifically,
871 ;; it calls ENSURE-CLASS-USING-CLASS (T NULL) with a non-NULL
872 ;; second argument.) Hopefully it only does this kind of
873 ;; weirdness when bootstrapping.. -- WHN 20000610
878 ;; Don't declare types for special variables -- our rebinding magic
879 ;; for SETQ cases don't work right there as SET, (SETF SYMBOL-VALUE),
880 ;; etc. make things undecidable.
883 ;; Otherwise, we can usually make Python very happy.
884 ;;
885 ;; KLUDGE: Since INFO doesn't work right for class objects here,
886 ;; and they are valid specializers, see if the specializer is
887 ;; a named class, and use the name in that case -- otherwise
888 ;; the class instance is ok, since info will just return NIL, NIL.
889 ;;
890 ;; We still need to deal with the class case too, but at
891 ;; least #.(find-class 'integer) and integer as equivalent
892 ;; specializers with this.
899 specializer))
913 ;; CLASS can be null here if the user has
914 ;; erroneously tried to use a defined type as a
915 ;; specializer; it can be a non-SYSTEM-CLASS if
916 ;; the user defines a type and calls (SETF
917 ;; FIND-CLASS) in a consistent way.
926 ;; don't declare CLOS classes as parameters;
927 ;; it's too expensive.
930 ;; we can get here, and still not have a failure
931 ;; case, by doing MOP programming like (PROGN
932 ;; (ENSURE-CLASS 'FOO) (DEFMETHOD BAR ((X FOO))
933 ;; ...)). Best to let the user know we haven't
934 ;; been able to extract enough information:
936 "~@<can't find type for specializer ~S in ~S.~@:>"
937 specializer-nameoid
943 ;;; For passing a list (groveled by the walker) of the required
944 ;;; parameters whose bindings are modified in the method body to the
945 ;;; optimized-slot-value* macros.
949 method-args
950 next-methods
961 next-method-call
962 args
963 rest-arg
972 parameters-setqd applyp method-cell))
973 &body body
977 ;; always provide the lexical function NEXT-METHOD-P.
978 ;; I would think this to be a good candidate for declaring INLINE
979 ;; but that's not the way it was done before.
990 `((%check-cnm-args cnm-args
991 ,method-args
993 nil)
1001 ',method-cell
1010 ;; Can't easily provide a RETRY restart here, as the return value here is
1011 ;; for the method, not the generic function.
1013 method args)))
1031 call-method-args)
1033 value)
1054 pv
1055 next-method-call
1056 arg-info)
1059 value)
1063 ;; The two variants of INVOKE-FAST-METHOD-CALL differ in how REST-ARGs
1064 ;; are handled. The first one will get REST-ARG as a single list (as
1065 ;; the last argument), and will thus need to use APPLY. The second one
1066 ;; will get them as a &MORE argument, so we can pass the arguments
1067 ;; directly with MULTIPLE-VALUE-CALL and %MORE-ARG-VALUES.
1076 more-context
1077 more-count
1083 ,@required-args
1086 ;; The cases with only small amounts of required arguments passed
1087 ;; are probably very common, and special-casing speeds them up by
1088 ;; a factor of 2 with very little effect on the other
1089 ;; cases. Though it'd be nice to have the generic case be equally
1090 ;; fast.
1097 ,@required-args
1108 \f
1109 ;;;; effective method functions
1115 ;;; This function was in the CMU CL version of PCL (ca Debian 2.4.8)
1116 ;;; without explanation. It appears to be intended for debugging, so
1117 ;;; it might be useful someday, so I haven't deleted it.
1118 ;;; But it isn't documented and isn't used for anything now, so
1119 ;;; I've conditionalized it out of the base system. -- WHN 19991213
1120 #+sb-show
1153 ,@more-arg
1156 ,restp
1157 ,@required-args
1162 ;; "What," you may wonder, "do these next two clauses do?" In that
1163 ;; case, you are not a PCL implementor, for they considered this to
1164 ;; be self-documenting.:-| Or CSR, for that matter, since he can
1165 ;; also figure it out by looking at it without breaking stride. For
1166 ;; the rest of us, though: From what the code is doing with .SLOTS.
1167 ;; and whatnot, evidently it's implementing SLOT-VALUEish and
1168 ;; GET-SLOT-VALUEish things. Then we can reason backwards and
1169 ;; conclude that setting EMF to a FIXNUM is an optimized way to
1170 ;; represent these slot access operations.
1181 value)))))
1189 ;; (In cmucl-2.4.8 there was a commented-out third ,@(WHEN
1190 ;; ...) clause here to handle SLOT-BOUNDish stuff. Since
1191 ;; there was no explanation and presumably the code is 10+
1192 ;; years stale, I simply deleted it. -- WHN)
1193 )))
1195 ;;; Before SBCL 0.9.16.7 instead of
1196 ;;; INVOKE-NARROW-EFFECTIVE-METHOD-FUNCTION we passed a (THE (OR
1197 ;;; FUNCTION METHOD-CALL FAST-METHOD-CALL) EMF) form as the EMF. Now,
1198 ;;; to make less work for the compiler we take a path that doesn't
1199 ;;; involve the slot-accessor clause (where EMF is a FIXNUM) at all.
1214 ,@more-arg
1217 ,restp
1218 ,@required-args
1222 emf-n restp required-args))
1245 args)
1268 args))))))
1271 args
1283 value)))
1300 \f
1303 method-cell
1304 cnm-args)
1307 ,next-method-call
1319 ,@args
1325 call-next-method-p
1326 setq-p
1327 parameters-setqd
1328 method-cell
1329 applyp))
1330 &body body
1350 nil)
1352 ,next-method-call
1354 ,method-cell
1355 cnm-args))))
1361 ;;; CMUCL comment (Gerd Moellmann):
1362 ;;;
1363 ;;; The standard says it's an error if CALL-NEXT-METHOD is called with
1364 ;;; arguments, and the set of methods applicable to those arguments is
1365 ;;; different from the set of methods applicable to the original
1366 ;;; method arguments. (According to Barry Margolin, this rule was
1367 ;;; probably added to ensure that before and around methods are always
1368 ;;; run before primary methods.)
1369 ;;;
1370 ;;; This could be optimized for the case that the generic function
1371 ;;; doesn't have hairy methods, does have standard method combination,
1372 ;;; is a standard generic function, there are no methods defined on it
1373 ;;; for COMPUTE-APPLICABLE-METHODS and probably a lot more of such
1374 ;;; preconditions. That looks hairy and is probably not worth it,
1375 ;;; because this check will never be fast.
1377 ;; 1. Check for no arguments.
1382 ;; 2. Requirement arguments pairwise: if all are EQL, the applicable
1383 ;; methods must be the same. This takes care of the relatively common
1384 ;; case of twiddling with &KEY arguments without being horribly
1385 ;; expensive.
1392 ;; 3. Only then do the full check.
1397 ~{~S~^, ~} to call-next-method is different from ~
1398 the set of methods ~S applicable to the original ~
1399 method argument~P ~{~S~^, ~}.~@:>"
1403 ;; FIXME: replacing this entire mess with DESTRUCTURING-BIND would correct
1404 ;; problems similar to those already solved by a correct implementation
1405 ;; of DESTRUCTURING-BIND, such as incorrect binding order:
1406 ;; e.g. (macroexpand-1 '(bind-args ((&optional (x nil xsp)) args) (form)))
1407 ;; -> (LET* ((.ARGS-TAIL. ARGS) (XSP (NOT (NULL .ARGS-TAIL.))) (X ...)))
1408 ;; It's mostly irrelevant unless a method uses CALL-NEXT-METHOD though.
1424 "encountered the non-standard lambda list keyword ~S"
1425 var)))
1426 nil)
1474 ,@bindings
1475 (.dummy0.
1487 ;; FIXME: Do we want to export this symbol? Or maybe use an
1488 ;; (ERROR 'SIMPLE-PROGRAM-ERROR) form?
1491 return tail))
1495 ;; method definition
1497 ;; a list of all required parameters whose bindings might be
1498 ;; modified in the method body.
1505 ;; hierarchy: nil -> :simple -> T.
1508 form)
1510 ;; The walker will split (SETQ A 1 B 2) to
1511 ;; separate (SETQ A 1) and (SETQ B 2) forms, so we
1512 ;; only need to handle the simple case of SETQ
1513 ;; here.
1518 ;; Note that we don't need to check for
1519 ;; %VARIABLE-REBINDING declarations like is
1520 ;; done in CAN-OPTIMIZE-ACCESS1, since the
1521 ;; bindings that will have that declation will
1522 ;; never be SETQd.
1524 ;; If a parameter binding is shadowed by
1525 ;; another binding it won't have a %CLASS
1526 ;; declaration anymore, and this won't get
1527 ;; executed.
1529 form)
1533 form)
1541 form))
1545 ;;; FIXME: the walker's rewriting of the source code causes
1546 ;;; trouble when doing code coverage. The rewrites should be
1547 ;;; removed, and the same operations done using
1548 ;;; compiler-macros or tranforms.
1550 walked-lambda
1551 method-lambda)
1552 call-next-method-p
1554 parameters-setqd)))))
1562 \f
1572 new-value)
1574 \f
1580 #+nil
1584 ll initargs source-location)))
1588 initargs source-location)
1597 :name gf-spec
1598 :new-location source-location
1599 :old-method method
1602 gf-spec qualifiers specializers lambda-list
1603 :definition-source source-location
1604 initargs)))
1607 ;; FIXME: should be STYLE-WARNING?
1609 "~&At the time the method with qualifiers ~:S and~%~
1610 specializers ~:S on the generic function ~S~%~
1611 was compiled, the method-class for that generic function was~%~
1612 ~S. But, the method class is now ~S, this~%~
1613 may mean that this method was compiled improperly.~%"
1614 qualifiers specializers gf-spec
1616 method))
1644 \f
1647 ;; We say "&MUMBLE is not allowed in a generic function lambda list"
1648 ;; whether this is called by DEFMETHOD or DEFGENERIC.
1649 ;; [It is used for either. Why else recognize and silently ignore &AUX?]
1653 :silent t
1659 ;; FIXME: this does more than return an FTYPE from a lambda list -
1660 ;; it unions the type with an existing ctype object. It needs a better name,
1661 ;; and to be reimplemented as "union and call sb-c::ftype-from-lambda-list".
1672 old-ftype))))
1687 keywords)
1690 *))))
1691 \f
1692 ;;;; early generic function support
1696 ;; CLHS doesn't specify &allow-other-keys here but I guess the supposition
1697 ;; is that they'll be checked by ENSURE-GENERIC-FUNCTION-USING-CLASS.
1698 ;; Except we don't do that either, so I think the blame, if any, lies there
1699 ;; for not catching errant keywords.
1711 existing fun-name all-keys)))))
1715 'simple-program-error
1766 arg-info-precedence
1767 arg-info-metatypes
1768 arg-info-number-optional
1769 arg-info-key/rest-p
1770 arg-info-keys ;nil no &KEY or &REST allowed
1771 ;(k1 k2 ..) Each method must accept these &KEY arguments.
1772 ;T must have &KEY or &REST
1774 gf-info-simple-accessor-type ; nil, reader, writer, boundp
1777 gf-info-static-c-a-m-emf
1779 gf-info-fast-mf-p)
1797 ;;; Create a gf lambda list from a method lambda list
1806 argument-precedence-order)
1830 existing methods of ~S."
1831 lambda-list gf))))
1834 lambda-list
1850 arg-info))
1860 to the generic function~2I~_~S;~I~_~
1861 but ~?~:>"
1871 "the method has ~A required arguments than the generic function."
1875 "the method has ~A optional arguments than the generic function."
1879 "the method and generic function differ in whether they accept~_~
1886 ~S."
1887 gf-keywords)))))))
1896 ;;; FIXME: we don't actually need this; we could test for the exact
1897 ;;; class and deal with it as appropriate. In fact we probably don't
1898 ;;; need it anyway because we only use this for METHOD-SPECIALIZERS on
1899 ;;; the standard reader method for METHOD-SPECIALIZERS. Probably.
1911 standard-writer-method standard-boundp-method
1912 global-reader-method global-writer-method
1913 global-boundp-method))
1943 nil)))
1991 nil)
1997 ;; FIXME: this test will eventually be
1998 ;; superseded by the *internal-pcl...* test,
1999 ;; above. While we are in a process of
2000 ;; transition, however, it should probably
2001 ;; remain.
2007 #'make-method-lambda
2018 arg-info)
2020 ;;; This is the early definition of ENSURE-GENERIC-FUNCTION-USING-CLASS.
2021 ;;;
2022 ;;; The STATIC-SLOTS field of the funcallable instances used as early
2023 ;;; generic functions is used to store the early methods and early
2024 ;;; discriminator code for the early generic function. The static
2025 ;;; slots field of the fins contains a list whose:
2026 ;;; CAR - a list of the early methods on this early gf
2027 ;;; CADR - the early discriminator code for this method
2030 lambda-list-p)
2031 argument-precedence-order
2032 definition-source
2033 documentation
2039 existing)
2043 argument-precedence-order definition-source
2044 documentation)
2052 argument-precedence-order definition-source
2053 documentation))))
2056 function argument-precedence-order source-location
2057 documentation)
2061 fin
2086 :lambda-list lambda-list
2089 fin))
2099 new-value)
2105 dfun)))
2108 ;; Check that we are under the lock.
2109 #+sb-thread
2114 new-state))))
2115 dfun)
2150 nil)
2165 class nor a symbol that names a class."
2169 ;; FIXME: reference MOP documentation -- this is an
2170 ;; additional requirement on our users
2187 method-class)
2192 ;; Use the existing lambda-list, if any. It is reasonable to do eg.
2193 ;;
2194 ;; (if (fboundp name)
2195 ;; (ensure-generic-function name)
2196 ;; (ensure-generic-function name :lambda-list '(foo)))
2197 ;;
2198 ;; in which case we end up here with no lambda-list in the first leg.
2202 t)
2211 ;; FIXME: Ideally we would like to not clobber it, but because generic
2212 ;; functions assert their FTYPEs callers believing the FTYPE are left with
2213 ;; unsafe assumptions. Hence the clobbering. Be quiet when the new type
2214 ;; is a subtype of the old one, though -- even though the type is not
2215 ;; trusted anymore, the warning is still not quite as interesting.
2219 for the same name with ~S.~:@>"
2220 fun-name 'ftype
2225 fun-name))
2229 fun-name
2230 &rest all-keys
2235 ;; KLUDGE: the above macro does SETQ on GENERIC-FUNCTION-CLASS,
2236 ;; which is what makes the next line work
2245 fun-name
2246 &rest all-keys
2257 \f
2264 ;;; FIXME: this function took on a slightly greater role than it
2265 ;;; previously had around 2005-11-02, when CSR fixed the bug whereby
2266 ;;; having more than one subclass of standard-generic-function caused
2267 ;;; the whole system to die horribly through a metacircle in
2268 ;;; GF-ARG-INFO. The fix is to be slightly more disciplined about
2269 ;;; calling accessor methods -- we call GET-GENERIC-FUN-INFO when
2270 ;;; computing discriminating functions, so we need to be careful about
2271 ;;; having a base case for the recursion, and we provide that with the
2272 ;;; STANDARD-GENERIC-FUNCTION case below. However, we are not (yet)
2273 ;;; as disciplined as CLISP's CLOS/MOP, and it would be nice to get to
2274 ;;; that stage, where all potentially dangerous cases are enumerated
2275 ;;; and stopped. -- CSR, 2005-11-02.
2277 ;; values nreq applyp metatypes nkeys arg-info
2284 metatypes
2285 arg-info))
2294 nkeys
2295 arg-info))))
2306 &key slot-name object-class method-class-function
2307 definition-source)
2310 ;; Figure out whether we got class objects or class names as the
2311 ;; specializers and set parsed and unparsed appropriately. If we
2312 ;; got class objects, then we can compute unparsed, but if we got
2313 ;; class names we don't try to compute parsed.
2314 ;;
2320 specializers))
2322 parsed ()))
2332 ;; the parsed specializers. This is used by
2333 ;; EARLY-METHOD-SPECIALIZERS to cache the parse.
2334 ;; Note that this only comes into play when there is
2335 ;; more than one early method on an early gf.
2336 parsed
2338 ;; A list to which REAL-MAKE-A-METHOD can be applied
2339 ;; to make a real method corresponding to this early
2340 ;; one.
2343 initargs doc)
2349 result)))
2354 definition-source)
2365 :slot-definition slot-definition
2369 initargs)
2370 :definition-source definition-source
2371 initargs)))
2391 ;;; Fetch the specializers of an early method. This is basically just
2392 ;;; a simple accessor except that when the second argument is t, this
2393 ;;; converts the specializers from symbols into class objects. The
2394 ;;; class objects are cached in the early method, this makes
2395 ;;; bootstrapping faster because the class objects only have to be
2396 ;;; computed once.
2397 ;;;
2398 ;;; NOTE:
2399 ;;; The second argument should only be passed as T by
2400 ;;; early-lookup-method. This is to implement the rule that only when
2401 ;;; there is more than one early method on a generic function is the
2402 ;;; conversion from class names to class objects done. This
2403 ;;; corresponds to the fact that we are only allowed to have one
2404 ;;; method on any generic function up until the time classes exist.
2429 specializers arglist &rest initargs
2430 &key documentation definition-source
2433 ;; argument here because the default,
2434 ;; STANDARD-GENERIC-FUNCTION, is right for all early generic
2435 ;; functions. (See REAL-ADD-NAMED-METHOD)
2445 specializers initargs documentation
2450 ;;; This is the early version of ADD-METHOD. Later this will become a
2451 ;;; generic function. See !FIX-EARLY-GENERIC-FUNCTIONS which has
2452 ;;; special knowledge about ADD-METHOD.
2465 ;;; This is the early version of REMOVE-METHOD. See comments on
2466 ;;; the early version of ADD-METHOD.
2480 ;;; This is the early version of GET-METHOD. See comments on the early
2481 ;;; version of ADD-METHOD.
2487 specializers)
2489 specializers))
2494 nil))
2497 ;; minor KLUDGE: a separate code component for this function allows GCing
2498 ;; a few symbols and their associated code that would otherwise be retained:
2499 ;; *!EARLY-{GENERIC-}FUNCTIONS*, *!GENERIC-FUNCTION-FIXUPS*
2507 ;; Rearrange *!EARLY-GENERIC-FUNCTIONS* to speed up
2508 ;; FIX-EARLY-GENERIC-FUNCTIONS.
2515 generic-function-methods
2516 method-specializers
2517 specializer-type
2518 specializer-class
2519 slot-definition-location
2520 slot-definition-name
2521 class-slots
2522 gf-arg-info
2523 class-precedence-list
2524 slot-boundp-using-class
2526 slot-value-using-class)))
2537 early-method))))
2540 early-method t))
2569 ()
2570 lambda-list
2571 specializers
2572 initargs
2573 nil)))
2580 \f
2581 ;;; PARSE-DEFMETHOD is used by DEFMETHOD to parse the &REST argument
2582 ;;; into the 'real' arguments. This is where the syntax of DEFMETHOD
2583 ;;; is really implemented.
2605 \f
2609 ;; We don't need these, but according to the unit tests,
2610 ;; they're mandated by AMOP.
2616 ()
2619 ;; Return 3 values:
2620 ;; - the bound variables, without defaults, supplied-p vars, or &AUX vars.
2621 ;; - the lambda list without specializers.
2622 ;; - just the specializers
2626 arglist
2635 rest
2636 ;; Preserve keyword-names when given as (:KEYWORD var)
2642 \f
2644 \f
2645 ;;; FIXME: In here there was a #-CMU definition of SYMBOL-MACROLET
2646 ;;; which used %WALKER stuff. That suggests to me that maybe the code
2647 ;;; walker stuff was only used for implementing stuff like that; maybe
2648 ;;; it's not needed any more? Hunt down what it was used for and see.
2655 form)))
2664 ,in
2668 slot-entry
2672 slot-entry
2674 `(,var-name
2676 slots)
2686 ,in
2691 slots)