| blob | 3ef0ca9f651255297aa6e066878a8c6cea9e3d7a |
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.
89 name))))
91 ;;; *!GENERIC-FUNCTION-FIXUPS* is used by !FIX-EARLY-GENERIC-FUNCTIONS
92 ;;; to convert the few functions in the bootstrap which are supposed
93 ;;; to be generic functions but can't be early on.
94 ;;;
95 ;;; each entry is a list of the form
96 ;;;
97 ;;; (GENERIC-FUNCTION-NAME METHOD-COMBINATION-NAME METHODS)
98 ;;;
99 ;;; where methods is a list of lists of the form
100 ;;;
101 ;;; (LAMBDA-LIST SPECIALIZERS QUALIFIERS METHOD-BODY-FUNCTION-NAME)
102 ;;;
103 ;;;,where SPECIALIZERS is a list of class names.
106 standard
109 ()
110 real-add-method))
113 standard
116 ()
117 real-remove-method))
120 standard
123 ()
124 real-get-method))
127 standard
129 &key generic-function-class environment
132 ()
133 real-ensure-gf-using-class--generic-function)
135 &key generic-function-class environment
138 ()
139 real-ensure-gf-using-class--null))
142 standard
145 ()
146 real-make-method-lambda))
149 standard
152 ()
153 real-make-method-specializers-form))
156 standard
159 ()
160 real-parse-specializer-using-class))
163 standard
166 ()
167 real-unparse-specializer-using-class))
170 standard
172 lambda-expression
173 lambda-list environment)
175 ()
176 real-make-method-initargs-form))
179 standard
182 ()
183 standard-compute-effective-method)
186 ()
187 short-compute-effective-method))))
188 \f
218 DEFGENERIC: ~S~:@>"
221 ;; FIXME: this list is slightly weird.
222 ;; ANSI (on the DEFGENERIC page) in one
223 ;; place allows only OPTIMIZE; in
224 ;; another place gives this list of
225 ;; disallowed declaration specifiers.
226 ;; This seems to be the only place where
227 ;; the FUNCTION declaration is
228 ;; mentioned; TYPE seems to be missing.
229 ;; Very strange. -- CSR, 2002-10-21
231 inline notinline special))
234 is not allowed inside DEFGENERIC."
240 spec))))
241 (:method-combination
247 symbol: ~S"
251 (:argument-precedence-order
257 :ARGUMENT-PRECEDENCE-ORDER clause."
262 :ARGUMENT-PRECEDENCE-ORDER clause: ~
263 ~S and ~S"
273 (:method
276 ;; ANSI requires that unsupported things must get a
277 ;; PROGRAM-ERROR.
299 ;; Hmm. This is similar to BECOME-DEFINED-FUN-NAME
300 ;; except that it doesn't clear an :ASSUMED-TYPE. Should it?
308 :name fun-name
316 fun-name
317 :lambda-list lambda-list
318 :definition-source source-location
319 initargs))
323 ()
328 ;; PARSE-LAMBDA-LIST validates the skeleton,
329 ;; so just check for incorrect use of defaults.
330 ;; This works for both &OPTIONAL and &KEY.
335 :format-control
336 "~@<invalid ~A argument specifier ~S ~_in the ~
337 generic function lambda list ~S~:>"
341 lambda-list
347 ;; no defaults or supplied-p vars allowed for &OPTIONAL or &KEY
354 ~/sb-impl:print-symbol-with-prefix/, ~S, is not a lambda ~
355 form.~@:>"
356 context method-lambda))
357 method-lambda)
358 \f
361 ;;; As per CLHS -
362 ;;; "defmethod is not required to perform any compile-time side effects."
363 ;;; and we don't do much other than to make the function be defined,
364 ;;; which means that checking of callers' arglists can only occur after called
365 ;;; methods are actually loaded.
371 ;; :compile-toplevel is needed for subsequent forms
372 ;; :execute is needed for references to itself inside the body
374 ;; KLUDGE: this double expansion is quite a monumental
375 ;; workaround: it comes about because of a fantastic interaction
376 ;; between the processing rules of CLHS 3.2.3.1 and the
377 ;; bizarreness of MAKE-METHOD-LAMBDA.
378 ;;
379 ;; MAKE-METHOD-LAMBDA can be called by the user, and if the
380 ;; lambda itself doesn't refer to outside bindings the return
381 ;; value must be compileable in the null lexical environment.
382 ;; However, the function must also refer somehow to the
383 ;; associated method object, so that it can call NO-NEXT-METHOD
384 ;; with the appropriate arguments if there is no next method --
385 ;; but when the function is generated, the method object doesn't
386 ;; exist yet.
387 ;;
388 ;; In order to resolve this issue, we insert a literal cons cell
389 ;; into the body of the method lambda, return the same cons cell
390 ;; as part of the second (initargs) return value of
391 ;; MAKE-METHOD-LAMBDA, and a method on INITIALIZE-INSTANCE fills
392 ;; in the cell when the method is created. However, this
393 ;; strategy depends on having a fresh cons cell for every method
394 ;; lambda, which (without the workaround below) is skewered by
395 ;; the processing in CLHS 3.2.3.1, which permits implementations
396 ;; to macroexpand the bodies of EVAL-WHEN forms with both
397 ;; :COMPILE-TOPLEVEL and :LOAD-TOPLEVEL only once. The
398 ;; expansion below forces the double expansion in those cases,
399 ;; while expanding only once in the common case.
410 lambda-list body env)))
426 ;;; Take a name which is either a generic function name or a list specifying
427 ;;; a SETF generic function (like: (SETF <generic-function-name>)). Return
428 ;;; the prototype instance of the method-class for that generic function.
429 ;;;
430 ;;; If there is no generic function by that name, this returns the
431 ;;; default value, the prototype instance of the class
432 ;;; STANDARD-METHOD. This default value is also returned if the spec
433 ;;; names an ordinary function or even a macro. In effect, this leaves
434 ;;; the signalling of the appropriate error until load time.
435 ;;;
436 ;;; Note: During bootstrapping, this function is allowed to return NIL.
443 ; error at load time.
448 \f
449 ;;; These are used to communicate the method name and lambda-list to
450 ;;; MAKE-METHOD-LAMBDA-INTERNAL.
455 proto-gf
456 proto-method
457 qualifiers
458 lambda-list
459 body
460 env
461 ;; ENV could be of type SB!INTERPRETER:BASIC-ENV
462 ;; but I don't care to figure out what parts of PCL
463 ;; would have to change to accept that, so coerce.
471 specializers)
478 proto-gf proto-method method-function-lambda
479 initargs env))
481 proto-gf proto-method specializers env)))
483 ;; Note: We could DECLAIM the ftype of the generic function
484 ;; here, since ANSI specifies that we create it if it does
485 ;; not exist. However, I chose not to, because I think it's
486 ;; more useful to support a style of programming where every
487 ;; generic function has an explicit DEFGENERIC and any typos
488 ;; in DEFMETHODs are warned about. Otherwise
489 ;;
490 ;; (DEFGENERIC FOO-BAR-BLETCH (X))
491 ;; (DEFMETHOD FOO-BAR-BLETCH ((X HASH-TABLE)) ..)
492 ;; (DEFMETHOD FOO-BRA-BLETCH ((X SIMPLE-VECTOR)) ..)
493 ;; (DEFMETHOD FOO-BAR-BLETCH ((X VECTOR)) ..)
494 ;; (DEFMETHOD FOO-BAR-BLETCH ((X ARRAY)) ..)
495 ;; (DEFMETHOD FOO-BAR-BLETCH ((X LIST)) ..)
496 ;;
497 ;; compiles without raising an error and runs without
498 ;; raising an error (since SIMPLE-VECTOR cases fall through
499 ;; to VECTOR) but still doesn't do what was intended. I hate
500 ;; that kind of bug (code which silently gives the wrong
501 ;; answer), so we don't do a DECLAIM here. -- WHN 20000229
503 unspecialized-lambda-list
507 initargs-form)))))))
514 method-class-name initargs-form)
517 fn-lambda)
530 specializers)
541 ;; CONSTANT-FORM-VALUE? What I
542 ;; kind of want to know, though,
543 ;; is what happens if we don't do
544 ;; this for some slow-method
545 ;; function because of a hairy
546 ;; lexenv -- is the only bad
547 ;; effect that the method
548 ;; function ends up unnamed? If
549 ;; so, couldn't we arrange to
550 ;; name it later?
552 specl))
553 specializers))
561 name qualifiers `',specls
562 unspecialized-lambda-list method-class-name
564 #',mname
567 name qualifiers
568 specializers
569 #+nil
575 specializers))
576 unspecialized-lambda-list
577 method-class-name
578 initargs-form))))
582 method-class-name initargs-form)
584 ',method-class-name
585 ',name
586 ',qualifiers
587 ,specializers-form
588 ',unspecialized-lambda-list
589 ,initargs-form
598 proto-gf proto-method method-function-lambda initargs env)))
601 method-lambda initargs env)
610 ;;; When bootstrapping PCL MAKE-METHOD-LAMBDA starts out as a regular
611 ;;; function: REAL-MAKE-METHOD-LAMBDA set to the fdefinition of
612 ;;; MAKE-METHOD-LAMBDA. Once generic functions are born,
613 ;;; REAL-MAKE-METHOD-LAMBDA is used to implement the default method.
614 ;;; MAKE-METHOD-LAMBDA-INTERNAL is split out into a separate function
615 ;;; so that changing it in a live image is easy, and changes actually
616 ;;; take effect.
635 ;; We have the %METHOD-NAME declaration in the place where we expect it only
636 ;; if there is are no non-standard prior MAKE-METHOD-LAMBDA methods -- or
637 ;; unless they're fantastically unintrusive.
640 ;; Macroexpansion caused by code-walking may call make-method-lambda and
641 ;; end up with wrong values
649 ;; the method-cell is a way of communicating what method a
650 ;; method-function implements, for the purpose of
651 ;; NO-NEXT-METHOD. We need something that can be shared
652 ;; between function and initargs, but not something that
653 ;; will be coalesced as a constant (because we are naughty,
654 ;; oh yes) with the expansion of any other methods in the
655 ;; same file. -- CSR, 2007-05-30
661 parameters
662 specializers))
666 ;; These declarations seem to be used by PCL to pass
667 ;; information to itself; when I tried to delete 'em
668 ;; ca. 0.6.10 it didn't work. I'm not sure how
669 ;; they work, but note the (VAR-DECLARATION '%CLASS ..)
670 ;; expression in CAN-OPTIMIZE-ACCESS1. -- WHN 2000-12-30
675 parameters
676 specializers))
677 ;; These TYPE declarations weren't in the original
678 ;; PCL code, but the Python compiler likes them a
679 ;; lot. (We're telling the compiler about our
680 ;; knowledge of specialized argument types so that
681 ;; it can avoid run-time type dispatch overhead,
682 ;; which can be a huge win for Python.)
686 par spec specials env))
687 parameters
688 specializers))))
690 ;; Remove the documentation string and insert the
691 ;; appropriate class declarations. The documentation
692 ;; string is removed to make it easy for us to insert
693 ;; new declarations later, they will just go after the
694 ;; CADR of the method lambda. The class declarations
695 ;; are inserted to communicate the class of the method's
696 ;; arguments to the code walk.
698 ;; The default ignorability of method parameters
699 ;; doesn't seem to be specified by ANSI. PCL had
700 ;; them basically ignorable but was a little
701 ;; inconsistent. E.g. even though the two
702 ;; method definitions
703 ;; (DEFMETHOD FOO ((X T) (Y T)) "Z")
704 ;; (DEFMETHOD FOO ((X T) Y) "Z")
705 ;; are otherwise equivalent, PCL treated Y as
706 ;; ignorable in the first definition but not in the
707 ;; second definition. We make all required
708 ;; parameters ignorable as a way of systematizing
709 ;; the old PCL behavior. -- WHN 2000-11-24
711 ,class-declarations
712 ,@declarations
731 parameters-setqd)
733 required-parameters
734 env
735 slots)
737 walked-declarations
738 walked-documentation)
749 ,slot-name-lists
759 aux))))
762 (,lambda-list .method-args. .next-methods.
763 :call-next-method-p
769 ,@walked-declarations
772 %parameter-binding-modified))
776 %parameter-binding-modified))
791 name)
797 ;; FIXME: Document CLASS-EQ specializers.
799 :format-control
800 "~@<~S is not a valid parameter specializer name.~@:>"
813 result
815 specializer generic-function))))
823 ;; FIXME: this HANDLER-CASE is a bit of a hammer to crack a nut:
824 ;; the idea is that we want to unparse permissively, so that the
825 ;; lazy (or rather the "portable") specializer extender (who
826 ;; does not define methods on these new SBCL-specific MOP
827 ;; functions) can still subclass specializer and define methods
828 ;; without everything going wrong. Making it cleaner and
829 ;; clearer that that is what we are defending against would be
830 ;; nice. -- CSR, 2007-06-01
837 class-name
838 type))
839 type))
842 specializer generic-function)))
848 ;;; a helper function for creating Python-friendly type declarations
849 ;;; in DEFMETHOD forms.
850 ;;;
851 ;;; We're too lazy to cons up a new environment for this, so we just pass in
852 ;;; the list of locally declared specials in addition to the old environment.
857 ;; KLUDGE: ANSI, in its wisdom, says that
858 ;; EQL-SPECIALIZER-FORMs in EQL specializers are evaluated at
859 ;; DEFMETHOD expansion time. Thus, although one might think
860 ;; that in
861 ;; (DEFMETHOD FOO ((X PACKAGE)
862 ;; (Y (EQL 12))
863 ;; ..))
864 ;; the PACKAGE and (EQL 12) forms are both parallel type
865 ;; names, they're not, as is made clear when you do
866 ;; (DEFMETHOD FOO ((X PACKAGE)
867 ;; (Y (EQL 'BAR)))
868 ;; ..)
869 ;; where Y needs to be a symbol named "BAR", not some cons
870 ;; made by (CONS 'QUOTE 'BAR). I.e. when the
871 ;; EQL-SPECIALIZER-FORM is (EQL 'X), it requires an argument
872 ;; to be of type (EQL X). It'd be easy to transform one to
873 ;; the other, but it'd be somewhat messier to do so while
874 ;; ensuring that the EQL-SPECIALIZER-FORM is only EVAL'd
875 ;; once. (The new code wouldn't be messy, but it'd require a
876 ;; big transformation of the old code.) So instead we punt.
877 ;; -- WHN 20000610
880 ;; KLUDGE: For some low-level implementation
881 ;; classes, perhaps because of some problems related
882 ;; to the incomplete integration of PCL into SBCL's
883 ;; type system, some specializer classes can't be
884 ;; declared as argument types. E.g.
885 ;; (DEFMETHOD FOO ((X SLOT-OBJECT))
886 ;; (DECLARE (TYPE SLOT-OBJECT X))
887 ;; ..)
888 ;; loses when
889 ;; (DEFSTRUCT BAR A B)
890 ;; (FOO (MAKE-BAR))
891 ;; perhaps because of the way that STRUCTURE-OBJECT
892 ;; inherits both from SLOT-OBJECT and from
893 ;; SB-KERNEL:INSTANCE. In an effort to sweep such
894 ;; problems under the rug, we exclude these problem
895 ;; cases by blacklisting them here. -- WHN 2001-01-19
899 ;; KLUDGE: PCL, in its wisdom, sometimes calls methods with
900 ;; types which don't match their specializers. (Specifically,
901 ;; it calls ENSURE-CLASS-USING-CLASS (T NULL) with a non-NULL
902 ;; second argument.) Hopefully it only does this kind of
903 ;; weirdness when bootstrapping.. -- WHN 20000610
908 ;; Don't declare types for special variables -- our rebinding magic
909 ;; for SETQ cases don't work right there as SET, (SETF SYMBOL-VALUE),
910 ;; etc. make things undecidable.
913 ;; Otherwise, we can usually make Python very happy.
914 ;;
915 ;; KLUDGE: Since INFO doesn't work right for class objects here,
916 ;; and they are valid specializers, see if the specializer is
917 ;; a named class, and use the name in that case -- otherwise
918 ;; the class instance is ok, since info will just return NIL, NIL.
919 ;;
920 ;; We still need to deal with the class case too, but at
921 ;; least #.(find-class 'integer) and integer as equivalent
922 ;; specializers with this.
929 specializer))
943 ;; CLASS can be null here if the user has
944 ;; erroneously tried to use a defined type as a
945 ;; specializer; it can be a non-SYSTEM-CLASS if
946 ;; the user defines a type and calls (SETF
947 ;; FIND-CLASS) in a consistent way.
956 ;; don't declare CLOS classes as parameters;
957 ;; it's too expensive.
960 ;; we can get here, and still not have a failure
961 ;; case, by doing MOP programming like (PROGN
962 ;; (ENSURE-CLASS 'FOO) (DEFMETHOD BAR ((X FOO))
963 ;; ...)). Best to let the user know we haven't
964 ;; been able to extract enough information:
966 "~@<can't find type for specializer ~S in ~S.~@:>"
967 specializer-nameoid
973 ;;; For passing a list (groveled by the walker) of the required
974 ;;; parameters whose bindings are modified in the method body to the
975 ;;; optimized-slot-value* macros.
979 method-args
980 next-methods
991 next-method-call
992 args
993 rest-arg
1002 parameters-setqd applyp method-cell))
1003 &body body
1007 ;; always provide the lexical function NEXT-METHOD-P.
1008 ;; I would think this to be a good candidate for declaring INLINE
1009 ;; but that's not the way it was done before.
1020 `((%check-cnm-args cnm-args
1021 ,method-args
1023 nil)
1031 ',method-cell
1040 ;; Can't easily provide a RETRY restart here, as the return value here is
1041 ;; for the method, not the generic function.
1043 method args)))
1061 call-method-args)
1063 value)
1084 pv
1085 next-method-call
1086 arg-info)
1089 value)
1093 ;; The two variants of INVOKE-FAST-METHOD-CALL differ in how REST-ARGs
1094 ;; are handled. The first one will get REST-ARG as a single list (as
1095 ;; the last argument), and will thus need to use APPLY. The second one
1096 ;; will get them as a &MORE argument, so we can pass the arguments
1097 ;; directly with MULTIPLE-VALUE-CALL and %MORE-ARG-VALUES.
1106 more-context
1107 more-count
1113 ,@required-args
1116 ;; The cases with only small amounts of required arguments passed
1117 ;; are probably very common, and special-casing speeds them up by
1118 ;; a factor of 2 with very little effect on the other
1119 ;; cases. Though it'd be nice to have the generic case be equally
1120 ;; fast.
1127 ,@required-args
1138 \f
1139 ;;;; effective method functions
1145 ;;; This function was in the CMU CL version of PCL (ca Debian 2.4.8)
1146 ;;; without explanation. It appears to be intended for debugging, so
1147 ;;; it might be useful someday, so I haven't deleted it.
1148 ;;; But it isn't documented and isn't used for anything now, so
1149 ;;; I've conditionalized it out of the base system. -- WHN 19991213
1150 #+sb-show
1183 ,@more-arg
1186 ,restp
1187 ,@required-args
1192 ;; "What," you may wonder, "do these next two clauses do?" In that
1193 ;; case, you are not a PCL implementor, for they considered this to
1194 ;; be self-documenting.:-| Or CSR, for that matter, since he can
1195 ;; also figure it out by looking at it without breaking stride. For
1196 ;; the rest of us, though: From what the code is doing with .SLOTS.
1197 ;; and whatnot, evidently it's implementing SLOT-VALUEish and
1198 ;; GET-SLOT-VALUEish things. Then we can reason backwards and
1199 ;; conclude that setting EMF to a FIXNUM is an optimized way to
1200 ;; represent these slot access operations.
1211 value)))))
1219 ;; (In cmucl-2.4.8 there was a commented-out third ,@(WHEN
1220 ;; ...) clause here to handle SLOT-BOUNDish stuff. Since
1221 ;; there was no explanation and presumably the code is 10+
1222 ;; years stale, I simply deleted it. -- WHN)
1223 )))
1225 ;;; Before SBCL 0.9.16.7 instead of
1226 ;;; INVOKE-NARROW-EFFECTIVE-METHOD-FUNCTION we passed a (THE (OR
1227 ;;; FUNCTION METHOD-CALL FAST-METHOD-CALL) EMF) form as the EMF. Now,
1228 ;;; to make less work for the compiler we take a path that doesn't
1229 ;;; involve the slot-accessor clause (where EMF is a FIXNUM) at all.
1244 ,@more-arg
1247 ,restp
1248 ,@required-args
1252 emf-n restp required-args))
1275 args)
1298 args))))))
1301 args
1313 value)))
1330 \f
1333 method-cell
1334 cnm-args)
1337 ,next-method-call
1349 ,@args
1355 call-next-method-p
1356 setq-p
1357 parameters-setqd
1358 method-cell
1359 applyp))
1360 &body body
1380 nil)
1382 ,next-method-call
1384 ,method-cell
1385 cnm-args))))
1391 ;;; CMUCL comment (Gerd Moellmann):
1392 ;;;
1393 ;;; The standard says it's an error if CALL-NEXT-METHOD is called with
1394 ;;; arguments, and the set of methods applicable to those arguments is
1395 ;;; different from the set of methods applicable to the original
1396 ;;; method arguments. (According to Barry Margolin, this rule was
1397 ;;; probably added to ensure that before and around methods are always
1398 ;;; run before primary methods.)
1399 ;;;
1400 ;;; This could be optimized for the case that the generic function
1401 ;;; doesn't have hairy methods, does have standard method combination,
1402 ;;; is a standard generic function, there are no methods defined on it
1403 ;;; for COMPUTE-APPLICABLE-METHODS and probably a lot more of such
1404 ;;; preconditions. That looks hairy and is probably not worth it,
1405 ;;; because this check will never be fast.
1407 ;; 1. Check for no arguments.
1412 ;; 2. Requirement arguments pairwise: if all are EQL, the applicable
1413 ;; methods must be the same. This takes care of the relatively common
1414 ;; case of twiddling with &KEY arguments without being horribly
1415 ;; expensive.
1422 ;; 3. Only then do the full check.
1427 ~{~S~^, ~} to call-next-method is different from ~
1428 the set of methods ~S applicable to the original ~
1429 method argument~P ~{~S~^, ~}.~@:>"
1433 ;; FIXME: replacing this entire mess with DESTRUCTURING-BIND would correct
1434 ;; problems similar to those already solved by a correct implementation
1435 ;; of DESTRUCTURING-BIND, such as incorrect binding order:
1436 ;; e.g. (macroexpand-1 '(bind-args ((&optional (x nil xsp)) args) (form)))
1437 ;; -> (LET* ((.ARGS-TAIL. ARGS) (XSP (NOT (NULL .ARGS-TAIL.))) (X ...)))
1438 ;; It's mostly irrelevant unless a method uses CALL-NEXT-METHOD though.
1454 "encountered the non-standard lambda list keyword ~S"
1455 var)))
1456 nil)
1504 ,@bindings
1505 (.dummy0.
1517 ;; FIXME: Do we want to export this symbol? Or maybe use an
1518 ;; (ERROR 'SIMPLE-PROGRAM-ERROR) form?
1521 return tail))
1525 ;; method definition
1527 ;; a list of all required parameters whose bindings might be
1528 ;; modified in the method body.
1535 ;; hierarchy: nil -> :simple -> T.
1538 form)
1540 ;; The walker will split (SETQ A 1 B 2) to
1541 ;; separate (SETQ A 1) and (SETQ B 2) forms, so we
1542 ;; only need to handle the simple case of SETQ
1543 ;; here.
1548 ;; Note that we don't need to check for
1549 ;; %VARIABLE-REBINDING declarations like is
1550 ;; done in CAN-OPTIMIZE-ACCESS1, since the
1551 ;; bindings that will have that declation will
1552 ;; never be SETQd.
1554 ;; If a parameter binding is shadowed by
1555 ;; another binding it won't have a %CLASS
1556 ;; declaration anymore, and this won't get
1557 ;; executed.
1559 form)
1563 form)
1571 form))
1575 ;;; FIXME: the walker's rewriting of the source code causes
1576 ;;; trouble when doing code coverage. The rewrites should be
1577 ;;; removed, and the same operations done using
1578 ;;; compiler-macros or tranforms.
1580 walked-lambda
1581 method-lambda)
1582 call-next-method-p
1584 parameters-setqd)))))
1592 \f
1602 new-value)
1604 \f
1610 #+nil
1614 ll initargs source-location)))
1618 initargs source-location)
1627 :name gf-spec
1628 :new-location source-location
1629 :old-method method
1632 gf-spec qualifiers specializers lambda-list
1633 :definition-source source-location
1634 initargs)))
1637 ;; FIXME: should be STYLE-WARNING?
1639 "~&At the time the method with qualifiers ~:S and~%~
1640 specializers ~:S on the generic function ~S~%~
1641 was compiled, the method-class for that generic function was~%~
1642 ~S. But, the method class is now ~S, this~%~
1643 may mean that this method was compiled improperly.~%"
1644 qualifiers specializers gf-spec
1646 method))
1674 \f
1677 ;; We say "&MUMBLE is not allowed in a generic function lambda list"
1678 ;; whether this is called by DEFMETHOD or DEFGENERIC.
1679 ;; [It is used for either. Why else recognize and silently ignore &AUX?]
1683 :silent t
1689 ;; FIXME: this does more than return an FTYPE from a lambda list -
1690 ;; it unions the type with an existing ctype object. It needs a better name,
1691 ;; and to be reimplemented as "union and call sb-c::ftype-from-lambda-list".
1702 old-ftype))))
1717 keywords)
1720 *))))
1721 \f
1722 ;;;; early generic function support
1726 ;; CLHS doesn't specify &allow-other-keys here but I guess the supposition
1727 ;; is that they'll be checked by ENSURE-GENERIC-FUNCTION-USING-CLASS.
1728 ;; Except we don't do that either, so I think the blame, if any, lies there
1729 ;; for not catching errant keywords.
1741 existing fun-name all-keys)))))
1745 'simple-program-error
1747 already names an ordinary function or a ~
1748 macro.~@:>"
1798 arg-info-precedence
1799 arg-info-metatypes
1800 arg-info-number-optional
1801 arg-info-key/rest-p
1802 arg-info-keys ;nil no &KEY or &REST allowed
1803 ;(k1 k2 ..) Each method must accept these &KEY arguments.
1804 ;T must have &KEY or &REST
1806 gf-info-simple-accessor-type ; nil, reader, writer, boundp
1809 gf-info-static-c-a-m-emf
1811 gf-info-fast-mf-p)
1829 ;;; Create a gf lambda list from a method lambda list
1838 argument-precedence-order)
1862 existing methods of ~S."
1863 lambda-list gf))))
1866 lambda-list
1882 arg-info))
1892 to the generic function~2I~_~S;~I~_~
1893 but ~?~:>"
1903 "the method has ~A required arguments than the generic function."
1907 "the method has ~A optional arguments than the generic function."
1911 "the method and generic function differ in whether they accept~_~
1918 ~S."
1919 gf-keywords)))))))
1928 ;;; FIXME: we don't actually need this; we could test for the exact
1929 ;;; class and deal with it as appropriate. In fact we probably don't
1930 ;;; need it anyway because we only use this for METHOD-SPECIALIZERS on
1931 ;;; the standard reader method for METHOD-SPECIALIZERS. Probably.
1943 standard-writer-method standard-boundp-method
1944 global-reader-method global-writer-method
1945 global-boundp-method))
1975 nil)))
2023 nil)
2029 ;; FIXME: this test will eventually be
2030 ;; superseded by the *internal-pcl...* test,
2031 ;; above. While we are in a process of
2032 ;; transition, however, it should probably
2033 ;; remain.
2039 #'make-method-lambda
2050 arg-info)
2052 ;;; This is the early definition of ENSURE-GENERIC-FUNCTION-USING-CLASS.
2053 ;;;
2054 ;;; The STATIC-SLOTS field of the funcallable instances used as early
2055 ;;; generic functions is used to store the early methods and early
2056 ;;; discriminator code for the early generic function. The static
2057 ;;; slots field of the fins contains a list whose:
2058 ;;; CAR - a list of the early methods on this early gf
2059 ;;; CADR - the early discriminator code for this method
2062 lambda-list-p)
2063 argument-precedence-order
2064 definition-source
2065 documentation
2071 existing)
2075 argument-precedence-order definition-source
2076 documentation)
2084 argument-precedence-order definition-source
2085 documentation))))
2088 function argument-precedence-order source-location
2089 documentation)
2093 fin
2118 :lambda-list lambda-list
2121 fin))
2131 new-value)
2137 dfun)))
2140 ;; Check that we are under the lock.
2141 #+sb-thread
2146 new-state))))
2147 dfun)
2182 nil)
2197 class nor a symbol that names a class."
2201 ;; FIXME: reference MOP documentation -- this is an
2202 ;; additional requirement on our users
2219 method-class)
2224 ;; Use the existing lambda-list, if any. It is reasonable to do eg.
2225 ;;
2226 ;; (if (fboundp name)
2227 ;; (ensure-generic-function name)
2228 ;; (ensure-generic-function name :lambda-list '(foo)))
2229 ;;
2230 ;; in which case we end up here with no lambda-list in the first leg.
2234 t)
2243 ;; FIXME: Ideally we would like to not clobber it, but because generic
2244 ;; functions assert their FTYPEs callers believing the FTYPE are left with
2245 ;; unsafe assumptions. Hence the clobbering. Be quiet when the new type
2246 ;; is a subtype of the old one, though -- even though the type is not
2247 ;; trusted anymore, the warning is still not quite as interesting.
2251 for the same name with ~S.~:@>"
2252 fun-name 'ftype
2257 fun-name))
2261 fun-name
2262 &rest all-keys
2267 ;; KLUDGE: the above macro does SETQ on GENERIC-FUNCTION-CLASS,
2268 ;; which is what makes the next line work
2277 fun-name
2278 &rest all-keys
2289 \f
2296 ;;; FIXME: this function took on a slightly greater role than it
2297 ;;; previously had around 2005-11-02, when CSR fixed the bug whereby
2298 ;;; having more than one subclass of standard-generic-function caused
2299 ;;; the whole system to die horribly through a metacircle in
2300 ;;; GF-ARG-INFO. The fix is to be slightly more disciplined about
2301 ;;; calling accessor methods -- we call GET-GENERIC-FUN-INFO when
2302 ;;; computing discriminating functions, so we need to be careful about
2303 ;;; having a base case for the recursion, and we provide that with the
2304 ;;; STANDARD-GENERIC-FUNCTION case below. However, we are not (yet)
2305 ;;; as disciplined as CLISP's CLOS/MOP, and it would be nice to get to
2306 ;;; that stage, where all potentially dangerous cases are enumerated
2307 ;;; and stopped. -- CSR, 2005-11-02.
2309 ;; values nreq applyp metatypes nkeys arg-info
2316 metatypes
2317 arg-info))
2326 nkeys
2327 arg-info))))
2338 &key slot-name object-class method-class-function
2339 definition-source)
2342 ;; Figure out whether we got class objects or class names as the
2343 ;; specializers and set parsed and unparsed appropriately. If we
2344 ;; got class objects, then we can compute unparsed, but if we
2345 ;; got class names we don't try to compute parsed.
2351 specializers))
2362 ;; the parsed specializers. This is used by
2363 ;; EARLY-METHOD-SPECIALIZERS to cache the parse.
2364 ;; Note that this only comes into play when there is
2365 ;; more than one early method on an early gf.
2366 parsed
2368 ;; A list to which REAL-MAKE-A-METHOD can be applied
2369 ;; to make a real method corresponding to this early
2370 ;; one.
2373 initargs doc)
2379 result))
2384 definition-source)
2395 :slot-definition slot-definition
2399 initargs)
2400 :definition-source definition-source
2401 initargs)))
2421 ;;; Fetch the specializers of an early method. This is basically just
2422 ;;; a simple accessor except that when the second argument is t, this
2423 ;;; converts the specializers from symbols into class objects. The
2424 ;;; class objects are cached in the early method, this makes
2425 ;;; bootstrapping faster because the class objects only have to be
2426 ;;; computed once.
2427 ;;;
2428 ;;; NOTE:
2429 ;;; The second argument should only be passed as T by
2430 ;;; early-lookup-method. This is to implement the rule that only when
2431 ;;; there is more than one early method on a generic function is the
2432 ;;; conversion from class names to class objects done. This
2433 ;;; corresponds to the fact that we are only allowed to have one
2434 ;;; method on any generic function up until the time classes exist.
2459 specializers arglist &rest initargs
2460 &key documentation definition-source
2463 ;; argument here because the default,
2464 ;; STANDARD-GENERIC-FUNCTION, is right for all early generic
2465 ;; functions. (See REAL-ADD-NAMED-METHOD)
2475 specializers initargs documentation
2480 ;;; This is the early version of ADD-METHOD. Later this will become a
2481 ;;; generic function. See !FIX-EARLY-GENERIC-FUNCTIONS which has
2482 ;;; special knowledge about ADD-METHOD.
2495 ;;; This is the early version of REMOVE-METHOD. See comments on
2496 ;;; the early version of ADD-METHOD.
2510 ;;; This is the early version of GET-METHOD. See comments on the early
2511 ;;; version of ADD-METHOD.
2517 specializers)
2519 specializers))
2524 nil))
2527 ;; minor KLUDGE: a separate code component for this function allows GCing
2528 ;; a few symbols and their associated code that would otherwise be retained:
2529 ;; *!EARLY-{GENERIC-}FUNCTIONS*, *!GENERIC-FUNCTION-FIXUPS*
2537 ;; Rearrange *!EARLY-GENERIC-FUNCTIONS* to speed up
2538 ;; FIX-EARLY-GENERIC-FUNCTIONS.
2545 generic-function-methods
2546 method-specializers
2547 specializer-type
2548 specializer-class
2549 slot-definition-location
2550 slot-definition-name
2551 class-slots
2552 gf-arg-info
2553 class-precedence-list
2554 slot-boundp-using-class
2556 slot-value-using-class)))
2567 early-method))))
2570 early-method t))
2596 'standard-method
2597 qualifiers lambda-list specializers initargs nil)))))
2607 \f
2608 ;;; PARSE-DEFMETHOD is used by DEFMETHOD to parse the &REST argument
2609 ;;; into the 'real' arguments. This is where the syntax of DEFMETHOD
2610 ;;; is really implemented.
2632 \f
2636 ;; We don't need these, but according to the unit tests,
2637 ;; they're mandated by AMOP.
2643 ()
2646 ;; Return 3 values:
2647 ;; - the bound variables, without defaults, supplied-p vars, or &AUX vars.
2648 ;; - the lambda list without specializers.
2649 ;; - just the specializers
2653 arglist
2662 rest
2663 ;; Preserve keyword-names when given as (:KEYWORD var)
2669 \f
2671 \f
2672 ;;; FIXME: In here there was a #-CMU definition of SYMBOL-MACROLET
2673 ;;; which used %WALKER stuff. That suggests to me that maybe the code
2674 ;;; walker stuff was only used for implementing stuff like that; maybe
2675 ;;; it's not needed any more? Hunt down what it was used for and see.
2682 form)))
2691 ,in
2695 slot-entry
2699 slot-entry
2701 `(,var-name
2703 slots)
2713 ,in
2718 slots)