| blob | 672e483a0125dfcf1267202ab41e46cbe9f2f61b |
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 add-named-method
73 ensure-generic-function-using-class
74 add-method
75 remove-method))
79 real-make-a-method)
81 real-add-named-method)
82 ))
84 ;;; For each of the early functions, arrange to have it point to its
85 ;;; early definition. Do this in a way that makes sure that if we
86 ;;; redefine one of the early definitions the redefinition will take
87 ;;; effect. This makes development easier.
95 name))))
97 ;;; *!GENERIC-FUNCTION-FIXUPS* is used by !FIX-EARLY-GENERIC-FUNCTIONS
98 ;;; to convert the few functions in the bootstrap which are supposed
99 ;;; to be generic functions but can't be early on.
108 real-remove-method))
112 real-get-method))
115 &key generic-function-class environment
118 real-ensure-gf-using-class--generic-function)
120 &key generic-function-class environment
123 real-ensure-gf-using-class--null))
127 real-make-method-lambda))
130 lambda-expression
131 lambda-list environment)
133 real-make-method-initargs-form))
137 standard-compute-effective-method))))
138 \f
167 ;; FIXME: this list is slightly weird.
168 ;; ANSI (on the DEFGENERIC page) in one
169 ;; place allows only OPTIMIZE; in
170 ;; another place gives this list of
171 ;; disallowed declaration specifiers.
172 ;; This seems to be the only place where
173 ;; the FUNCTION declaration is
174 ;; mentioned; TYPE seems to be missing.
175 ;; Very strange. -- CSR, 2002-10-21
177 inline notinline special)))
180 is not allowed inside DEFGENERIC."
183 (:method-combination
189 symbol: ~S"
193 (:argument-precedence-order
199 :ARGUMENT-PRECEDENCE-ORDER clause."
204 :ARGUMENT-PRECEDENCE-ORDER clause: ~
205 ~S and ~S"
215 (:method
218 ;; ANSI requires that unsupported things must get a
219 ;; PROGRAM-ERROR.
252 fun-name
253 :lambda-list lambda-list
254 :definition-source source-location
255 initargs))
259 ()
266 :format-control
267 "~@<invalid ~S ~_in the generic function lambda list ~S~:>"
270 auxp aux morep more-context more-count)
277 ;; no defaults allowed for &OPTIONAL arguments
281 ;; no defaults allowed for &KEY arguments
292 ;; no &AUX allowed
295 lambda-list))
296 ;; Oh, *puhlease*... not specifically as per section 3.4.2 of
297 ;; the ANSI spec, but the CMU CL &MORE extension does not
298 ;; belong here!
300 \f
307 proto-gf
308 proto-method
309 qualifiers
310 lambda-list
311 body
312 env))))
327 ;;; Take a name which is either a generic function name or a list specifying
328 ;;; a SETF generic function (like: (SETF <generic-function-name>)). Return
329 ;;; the prototype instance of the method-class for that generic function.
330 ;;;
331 ;;; If there is no generic function by that name, this returns the
332 ;;; default value, the prototype instance of the class
333 ;;; STANDARD-METHOD. This default value is also returned if the spec
334 ;;; names an ordinary function or even a macro. In effect, this leaves
335 ;;; the signalling of the appropriate error until load time.
336 ;;;
337 ;;; Note: During bootstrapping, this function is allowed to return NIL.
344 ; error at load time.
349 \f
351 proto-gf
352 proto-method
353 qualifiers
354 lambda-list
355 body
356 env)
362 proto-method
363 method-function-lambda
364 initargs
365 env)))
367 ;; Note: We could DECLAIM the ftype of the generic function
368 ;; here, since ANSI specifies that we create it if it does
369 ;; not exist. However, I chose not to, because I think it's
370 ;; more useful to support a style of programming where every
371 ;; generic function has an explicit DEFGENERIC and any typos
372 ;; in DEFMETHODs are warned about. Otherwise
373 ;;
374 ;; (DEFGENERIC FOO-BAR-BLETCH ((X T)))
375 ;; (DEFMETHOD FOO-BAR-BLETCH ((X HASH-TABLE)) ..)
376 ;; (DEFMETHOD FOO-BRA-BLETCH ((X SIMPLE-VECTOR)) ..)
377 ;; (DEFMETHOD FOO-BAR-BLETCH ((X VECTOR)) ..)
378 ;; (DEFMETHOD FOO-BAR-BLETCH ((X ARRAY)) ..)
379 ;; (DEFMETHOD FOO-BAR-BLETCH ((X LIST)) ..)
380 ;;
381 ;; compiles without raising an error and runs without
382 ;; raising an error (since SIMPLE-VECTOR cases fall through
383 ;; to VECTOR) but still doesn't do what was intended. I hate
384 ;; that kind of bug (code which silently gives the wrong
385 ;; answer), so we don't do a DECLAIM here. -- WHN 20000229
387 unspecialized-lambda-list
391 initargs-form))))))
398 method-class-name initargs-form)
400 fn-lambda)
413 specializers)
424 specl))
425 specializers))
433 name qualifiers `',specls
434 unspecialized-lambda-list method-class-name
436 #',mname
439 name qualifiers
445 specializers))
446 unspecialized-lambda-list
447 method-class-name
448 initargs-form))))
452 method-class-name initargs-form)
454 ',method-class-name
455 ',name
456 ',qualifiers
457 ,specializers-form
458 ',unspecialized-lambda-list
459 ,initargs-form
471 proto-method
472 method-function-lambda
473 initargs
474 env))))
484 ;; (Old PCL code used a somewhat different style of
485 ;; list for %METHOD-NAME values. Our names use
486 ;; ,@QUALIFIERS instead of ,QUALIFIERS so that the
487 ;; method names look more like what you see in a
488 ;; DEFMETHOD form.)
489 ;;
490 ;; FIXME: As of sbcl-0.7.0.6, code elsewhere, at
491 ;; least the code to set up named BLOCKs around the
492 ;; bodies of methods, depends on the function's base
493 ;; name being the first element of the %METHOD-NAME
494 ;; list. It would be good to remove this dependency,
495 ;; perhaps by building the BLOCK here, or by using
496 ;; another declaration (e.g. %BLOCK-NAME), so that
497 ;; our method debug names are free to have any format,
498 ;; e.g. (:METHOD PRINT-OBJECT :AROUND (CLOWN T)).
499 ;;
500 ;; Further, as of sbcl-0.7.9.10, the code to
501 ;; implement NO-NEXT-METHOD is coupled to the form of
502 ;; this declaration; see the definition of
503 ;; CALL-NO-NEXT-METHOD (and the passing of
504 ;; METHOD-NAME-DECLARATION arguments around the
505 ;; various CALL-NEXT-METHOD logic).
507 ,@qualifiers
510 ,@declarations
512 unspecialized-lambda-list specializers))))
515 method-lambda initargs env)
520 is not a lambda form."
521 method-lambda))
532 ;;; a helper function for creating Python-friendly type declarations
533 ;;; in DEFMETHOD forms
537 ;; KLUDGE: ANSI, in its wisdom, says that
538 ;; EQL-SPECIALIZER-FORMs in EQL specializers are evaluated at
539 ;; DEFMETHOD expansion time. Thus, although one might think
540 ;; that in
541 ;; (DEFMETHOD FOO ((X PACKAGE)
542 ;; (Y (EQL 12))
543 ;; ..))
544 ;; the PACKAGE and (EQL 12) forms are both parallel type
545 ;; names, they're not, as is made clear when you do
546 ;; (DEFMETHOD FOO ((X PACKAGE)
547 ;; (Y (EQL 'BAR)))
548 ;; ..)
549 ;; where Y needs to be a symbol named "BAR", not some cons
550 ;; made by (CONS 'QUOTE 'BAR). I.e. when the
551 ;; EQL-SPECIALIZER-FORM is (EQL 'X), it requires an argument
552 ;; to be of type (EQL X). It'd be easy to transform one to
553 ;; the other, but it'd be somewhat messier to do so while
554 ;; ensuring that the EQL-SPECIALIZER-FORM is only EVAL'd
555 ;; once. (The new code wouldn't be messy, but it'd require a
556 ;; big transformation of the old code.) So instead we punt.
557 ;; -- WHN 20000610
560 ;; KLUDGE: For some low-level implementation
561 ;; classes, perhaps because of some problems related
562 ;; to the incomplete integration of PCL into SBCL's
563 ;; type system, some specializer classes can't be
564 ;; declared as argument types. E.g.
565 ;; (DEFMETHOD FOO ((X SLOT-OBJECT))
566 ;; (DECLARE (TYPE SLOT-OBJECT X))
567 ;; ..)
568 ;; loses when
569 ;; (DEFSTRUCT BAR A B)
570 ;; (FOO (MAKE-BAR))
571 ;; perhaps because of the way that STRUCTURE-OBJECT
572 ;; inherits both from SLOT-OBJECT and from
573 ;; SB-KERNEL:INSTANCE. In an effort to sweep such
574 ;; problems under the rug, we exclude these problem
575 ;; cases by blacklisting them here. -- WHN 2001-01-19
579 ;; KLUDGE: PCL, in its wisdom, sometimes calls methods with
580 ;; types which don't match their specializers. (Specifically,
581 ;; it calls ENSURE-CLASS-USING-CLASS (T NULL) with a non-NULL
582 ;; second argument.) Hopefully it only does this kind of
583 ;; weirdness when bootstrapping.. -- WHN 20000610
588 ;; KLUDGE: Don't declare types for global special variables
589 ;; -- our rebinding magic for SETQ cases don't work right
590 ;; there.
591 ;;
592 ;; FIXME: It would be better to detect the SETQ earlier and
593 ;; skip declarations for specials only when needed, not
594 ;; always.
595 ;;
596 ;; --NS 2004-10-14
599 ;; Otherwise, we can usually make Python very happy.
600 ;;
601 ;; KLUDGE: Since INFO doesn't work right for class objects here,
602 ;; and they are valid specializers, see if the specializer is
603 ;; a named class, and use the name in that case -- otherwise
604 ;; the class instance is ok, since info will just return NIL, NIL.
605 ;;
606 ;; We still need to deal with the class case too, but at
607 ;; least #.(find-class 'integer) and integer as equivalent
608 ;; specializers with this.
614 specializer))
619 specializer
625 ;; CLASS can be null here if the user has erroneously
626 ;; tried to use a defined type as a specializer; it
627 ;; can be a non-BUILT-IN-CLASS if the user defines a
628 ;; type and calls (SETF FIND-CLASS) in a consistent
629 ;; way.
638 ;; don't declare CLOS classes as parameters;
639 ;; it's too expensive.
642 ;; we can get here, and still not have a failure
643 ;; case, by doing MOP programming like (PROGN
644 ;; (ENSURE-CLASS 'FOO) (DEFMETHOD BAR ((X FOO))
645 ;; ...)). Best to let the user know we haven't
646 ;; been able to extract enough information:
648 "~@<can't find type for presumed class ~S in ~S.~@:>"
649 specializer
658 is not a lambda form."
659 method-lambda))
671 parameters
672 specializers))
677 ;; These declarations seem to be used by PCL to pass
678 ;; information to itself; when I tried to delete 'em
679 ;; ca. 0.6.10 it didn't work. I'm not sure how
680 ;; they work, but note the (VAR-DECLARATION '%CLASS ..)
681 ;; expression in CAN-OPTIMIZE-ACCESS1. -- WHN 2000-12-30
686 parameters
687 specializers))
688 ;; These TYPE declarations weren't in the original
689 ;; PCL code, but the Python compiler likes them a
690 ;; lot. (We're telling the compiler about our
691 ;; knowledge of specialized argument types so that
692 ;; it can avoid run-time type dispatch overhead,
693 ;; which can be a huge win for Python.)
694 ;;
695 ;; KLUDGE: when I tried moving these to
696 ;; ADD-METHOD-DECLARATIONS, things broke. No idea
697 ;; why. -- CSR, 2004-06-16
699 parameters
700 specializers)))
702 ;; Remove the documentation string and insert the
703 ;; appropriate class declarations. The documentation
704 ;; string is removed to make it easy for us to insert
705 ;; new declarations later, they will just go after the
706 ;; CADR of the method lambda. The class declarations
707 ;; are inserted to communicate the class of the method's
708 ;; arguments to the code walk.
710 ;; The default ignorability of method parameters
711 ;; doesn't seem to be specified by ANSI. PCL had
712 ;; them basically ignorable but was a little
713 ;; inconsistent. E.g. even though the two
714 ;; method definitions
715 ;; (DEFMETHOD FOO ((X T) (Y T)) "Z")
716 ;; (DEFMETHOD FOO ((X T) Y) "Z")
717 ;; are otherwise equivalent, PCL treated Y as
718 ;; ignorable in the first definition but not in the
719 ;; second definition. We make all required
720 ;; parameters ignorable as a way of systematizing
721 ;; the old PCL behavior. -- WHN 2000-11-24
723 ,class-declarations
724 ,@declarations
744 next-method-p-p setq-p)
746 required-parameters
747 env
748 slots
749 calls)
751 walked-declarations
752 walked-documentation)
770 ,slot-name-lists
778 aux))))
781 (,lambda-list .method-args. .next-methods.
782 :call-next-method-p
783 ,call-next-method-p
786 ;; we need to pass this along
787 ;; so that NO-NEXT-METHOD can
788 ;; be given a suitable METHOD
789 ;; argument; we need the
790 ;; QUALIFIERS and SPECIALIZERS
791 ;; inside the declaration to
792 ;; give to FIND-METHOD.
796 ,@walked-declarations
808 method-args
809 next-methods
820 next-method-call
821 args
822 rest-arg
831 closurep applyp method-name-declaration))
832 &body body
844 `((%check-cnm-args cnm-args
845 ,method-args
847 nil)
855 ',method-name-declaration
865 ;; KLUDGE: inefficient traversal, but hey. This should only
866 ;; happen on the slow error path anyway.
872 method
873 args)))))
877 call-method-args)
898 pv-cell
899 next-method-call
900 arg-info)
921 \f
922 ;;;; effective method functions
928 ;;; This function was in the CMU CL version of PCL (ca Debian 2.4.8)
929 ;;; without explanation. It appears to be intended for debugging, so
930 ;;; it might be useful someday, so I haven't deleted it.
931 ;;; But it isn't documented and isn't used for anything now, so
932 ;;; I've conditionalized it out of the base system. -- WHN 19991213
933 #+sb-show
970 ;; FIXME: The RESTP handling here is confusing and maybe slightly
971 ;; broken if RESTP evaluates to a non-self-evaluating form. E.g. if
972 ;; (INVOKE-EFFECTIVE-METHOD-FUNCTION EMF '(ERROR "gotcha") ...)
973 ;; then TRACE-EMF-CALL-CALL-INTERNAL might die on a gotcha error.
979 ;; "What," you may wonder, "do these next two clauses do?"
980 ;; In that case, you are not a PCL implementor, for they
981 ;; considered this to be self-documenting.:-| Or CSR, for
982 ;; that matter, since he can also figure it out by looking
983 ;; at it without breaking stride. For the rest of us,
984 ;; though: From what the code is doing with .SLOTS. and
985 ;; whatnot, evidently it's implementing SLOT-VALUEish and
986 ;; GET-SLOT-VALUEish things. Then we can reason backwards
987 ;; and conclude that setting EMF to a FIXNUM is an
988 ;; optimized way to represent these slot access operations.
997 value)))))
1005 ;; (In cmucl-2.4.8 there was a commented-out third ,@(WHEN
1006 ;; ...) clause here to handle SLOT-BOUNDish stuff. Since
1007 ;; there was no explanation and presumably the code is 10+
1008 ;; years stale, I simply deleted it. -- WHN)
1055 args))))))
1058 args
1070 value)))
1087 \f
1090 ;; INVOKE-EFFECTIVE-METHOD-FUNCTION has code in it to dispatch on
1091 ;; the possibility that EMF might be of type FIXNUM (as an optimized
1092 ;; representation of a slot accessor). But as far as I (WHN
1093 ;; 2002-06-11) can tell, it's impossible for such a representation
1094 ;; to end up as .NEXT-METHOD-CALL. By reassuring INVOKE-E-M-F that
1095 ;; when called from this context it needn't worry about the FIXNUM
1096 ;; case, we can keep those cases from being compiled, which is good
1097 ;; both because it saves bytes and because it avoids annoying type
1098 ;; mismatch compiler warnings.
1099 ;;
1100 ;; KLUDGE: In sbcl-0.7.4.29, the compiler's type system isn't smart
1101 ;; enough about NOT and intersection types to benefit from a (NOT
1102 ;; FIXNUM) declaration here. -- WHN 2002-06-12 (FIXME: maybe it is
1103 ;; now... -- CSR, 2003-06-07)
1104 ;;
1105 ;; FIXME: Might the FUNCTION type be omittable here, leaving only
1106 ;; METHOD-CALLs? Failing that, could this be documented somehow?
1107 ;; (It'd be nice if the types involved could be understood without
1108 ;; solving the halting problem.)
1113 method-name-declaration
1114 cnm-args)
1119 ,@args
1129 ,@args
1135 call-next-method-p
1136 setq-p
1137 method-name-declaration
1138 next-method-p-p
1139 closurep
1140 applyp))
1141 &body body
1155 nil)
1157 ,next-method-call
1159 ,method-name-declaration
1160 cnm-args))))
1163 ()
1169 ;;; CMUCL comment (Gerd Moellmann):
1170 ;;;
1171 ;;; The standard says it's an error if CALL-NEXT-METHOD is called with
1172 ;;; arguments, and the set of methods applicable to those arguments is
1173 ;;; different from the set of methods applicable to the original
1174 ;;; method arguments. (According to Barry Margolin, this rule was
1175 ;;; probably added to ensure that before and around methods are always
1176 ;;; run before primary methods.)
1177 ;;;
1178 ;;; This could be optimized for the case that the generic function
1179 ;;; doesn't have hairy methods, does have standard method combination,
1180 ;;; is a standard generic function, there are no methods defined on it
1181 ;;; for COMPUTE-APPLICABLE-METHODS and probably a lot more of such
1182 ;;; preconditions. That looks hairy and is probably not worth it,
1183 ;;; because this check will never be fast.
1191 ~{~S~^, ~} to call-next-method is different from ~
1192 the set of methods ~S applicable to the original ~
1193 method argument~P ~{~S~^, ~}.~@:>"
1212 "encountered the non-standard lambda list keyword ~S"
1213 var)))
1214 nil)
1262 ,@bindings
1263 (.dummy0.
1275 ;; FIXME: Do we want to export this symbol? Or maybe use an
1276 ;; (ERROR 'SIMPLE-PROGRAM-ERROR) form?
1279 return tail))
1283 ; should be in the method definition
1285 ; was seen in the body of a method
1287 ; should be in the method definition
1291 ;; FIXME: Jumping to a conclusion from the way it's used
1292 ;; above, perhaps CONTEXT should be called SITUATION
1293 ;; (after the term used in the ANSI specification of
1294 ;; EVAL-WHEN) and given modern ANSI keyword values
1295 ;; like :LOAD-TOPLEVEL.
1299 form)
1302 form)
1304 ;; FIXME: this is possibly a little strong as
1305 ;; conditions go. Ideally we would want to detect
1306 ;; which, if any, of the method parameters are
1307 ;; being set, and communicate that information to
1308 ;; e.g. SPLIT-DECLARATIONS. However, the brute
1309 ;; force method doesn't really cost much; a little
1310 ;; loss of discrimination over IGNORED variables
1311 ;; should be all. -- CSR, 2004-07-01
1313 form)
1318 form)
1322 form)
1328 required-parameters
1329 env)))
1340 form required-parameters env slots calls))
1343 form required-parameters env slots calls))
1348 call-next-method-p
1349 closurep
1350 next-method-p-p
1351 setq-p)))))
1359 \f
1383 \f
1394 ll initargs source-location)))
1398 initargs source-location)
1405 qualifiers
1407 nil))))
1410 gf-spec qualifiers specializers))))
1412 gf-spec qualifiers specializers lambda-list
1413 :definition-source source-location
1414 initargs)))
1417 ;; FIXME: should be STYLE-WARNING?
1419 "~&At the time the method with qualifiers ~:S and~%~
1420 specializers ~:S on the generic function ~S~%~
1421 was compiled, the method-class for that generic function was~%~
1422 ~S. But, the method class is now ~S, this~%~
1423 may mean that this method was compiled improperly.~%"
1424 qualifiers specializers gf-spec
1426 method))
1465 \f
1495 x)))
1504 After &REST, a DEFGENERIC lambda-list ~
1518 keywords keyword-parameters)
1527 old-ftype))))
1542 keywords)
1545 *))))
1549 \f
1550 ;;;; early generic function support
1555 &rest all-keys
1556 &key environment source-location
1566 existing fun-name all-keys))))
1620 arg-info-precedence
1621 arg-info-metatypes
1622 arg-info-number-optional
1623 arg-info-key/rest-p
1624 arg-info-keys ;nil no &KEY or &REST allowed
1625 ;(k1 k2 ..) Each method must accept these &KEY arguments.
1626 ;T must have &KEY or &REST
1628 gf-info-simple-accessor-type ; nil, reader, writer, boundp
1631 gf-info-static-c-a-m-emf
1633 gf-info-fast-mf-p)
1651 ;;; Create a gf lambda list from a method lambda list
1657 argument-precedence-order)
1681 existing methods of ~S."
1682 lambda-list gf))))
1685 lambda-list
1701 arg-info))
1711 to the generic function~2I~_~S;~I~_~
1712 but ~?~:>"
1722 "the method has ~A required arguments than the generic function."
1726 "the method has ~A optional arguments than the generic function."
1730 "the method and generic function differ in whether they accept~_~
1734 allow-other-keys-p
1737 ~S."
1738 gf-keywords)))))))
1749 ;;; FIXME: we don't actually need this; we could test for the exact
1750 ;;; class and deal with it as appropriate. In fact we probably don't
1751 ;;; need it anyway because we only use this for METHOD-SPECIALIZERS on
1752 ;;; the standard reader method for METHOD-SPECIALIZERS. Probably.
1809 nil)))
1857 nil)
1862 ;; FIXME: this test will eventually be
1863 ;; superseded by the *internal-pcl...* test,
1864 ;; above. While we are in a process of
1865 ;; transition, however, it should probably
1866 ;; remain.
1872 #'make-method-lambda
1883 arg-info)
1885 ;;; This is the early definition of ENSURE-GENERIC-FUNCTION-USING-CLASS.
1886 ;;;
1887 ;;; The STATIC-SLOTS field of the funcallable instances used as early
1888 ;;; generic functions is used to store the early methods and early
1889 ;;; discriminator code for the early generic function. The static
1890 ;;; slots field of the fins contains a list whose:
1891 ;;; CAR - a list of the early methods on this early gf
1892 ;;; CADR - the early discriminator code for this method
1895 lambda-list-p)
1896 argument-precedence-order
1897 source-location
1903 existing)
1907 argument-precedence-order source-location)
1911 spec
1916 argument-precedence-order source-location))))
1919 function argument-precedence-order source-location)
1923 fin
1936 fin
1937 'source
1938 source-location)
1946 :lambda-list lambda-list
1949 fin))
1959 new-value)
1967 dfun)))
1971 new-state)))
1972 dfun)
2007 nil)
2022 class nor a symbol that names a class."
2026 ;; FIXME: reference MOP documentation -- this is an
2027 ;; additional requirement on our users
2042 method-class)
2047 fun-name
2048 &rest all-keys
2063 fun-name
2064 &rest all-keys
2076 \f
2083 ;;; FIXME: this function took on a slightly greater role than it
2084 ;;; previously had around 2005-11-02, when CSR fixed the bug whereby
2085 ;;; having more than one subclass of standard-generic-function caused
2086 ;;; the whole system to die horribly through a metacircle in
2087 ;;; GF-ARG-INFO. The fix is to be slightly more disciplined about
2088 ;;; calling accessor methods -- we call GET-GENERIC-FUN-INFO when
2089 ;;; computing discriminating functions, so we need to be careful about
2090 ;;; having a base case for the recursion, and we provide that with the
2091 ;;; STANDARD-GENERIC-FUNCTION case below. However, we are not (yet)
2092 ;;; as disciplined as CLISP's CLOS/MOP, and it would be nice to get to
2093 ;;; that stage, where all potentially dangerous cases are enumerated
2094 ;;; and stopped. -- CSR, 2005-11-02.
2096 ;; values nreq applyp metatypes nkeys arg-info
2103 metatypes
2104 arg-info))
2107 arg-info)))
2114 ;; Figure out whether we got class objects or class names as the
2115 ;; specializers and set parsed and unparsed appropriately. If we
2116 ;; got class objects, then we can compute unparsed, but if we got
2117 ;; class names we don't try to compute parsed.
2118 ;;
2119 ;; Note that the use of not symbolp in this call to every should be
2120 ;; read as 'classp' we can't use classp itself because it doesn't
2121 ;; exist yet.
2126 specializers))
2128 parsed ()))
2134 parsed ;The parsed specializers. This is used
2135 ;by early-method-specializers to cache
2136 ;the parse. Note that this only comes
2137 ;into play when there is more than one
2138 ;early method on an early gf.
2142 qualifiers ;can be applied to make a real method
2143 arglist ;corresponding to this early one.
2144 unparsed
2145 initargs
2146 doc)
2165 :slot-definition slot-definition
2169 initargs)
2170 initargs)))
2190 ;;; Fetch the specializers of an early method. This is basically just
2191 ;;; a simple accessor except that when the second argument is t, this
2192 ;;; converts the specializers from symbols into class objects. The
2193 ;;; class objects are cached in the early method, this makes
2194 ;;; bootstrapping faster because the class objects only have to be
2195 ;;; computed once.
2196 ;;;
2197 ;;; NOTE:
2198 ;;; The second argument should only be passed as T by
2199 ;;; early-lookup-method. This is to implement the rule that only when
2200 ;;; there is more than one early method on a generic function is the
2201 ;;; conversion from class names to class objects done. This
2202 ;;; corresponds to the fact that we are only allowed to have one
2203 ;;; method on any generic function up until the time classes exist.
2222 qualifiers
2223 specializers
2224 arglist
2233 qualifiers
2234 arglist
2235 specializers
2236 initargs
2237 ())))
2241 ;;; This is the early version of ADD-METHOD. Later this will become a
2242 ;;; generic function. See !FIX-EARLY-GENERIC-FUNCTIONS which has
2243 ;;; special knowledge about ADD-METHOD.
2256 ;;; This is the early version of REMOVE-METHOD. See comments on
2257 ;;; the early version of ADD-METHOD.
2271 ;;; This is the early version of GET-METHOD. See comments on the early
2272 ;;; version of ADD-METHOD.
2278 specializers)
2280 specializers))
2285 nil))
2290 ;; Rearrange *!EARLY-GENERIC-FUNCTIONS* to speed up
2291 ;; FIX-EARLY-GENERIC-FUNCTIONS.
2298 generic-function-methods
2299 method-specializers
2300 specializerp
2301 specializer-type
2302 specializer-class
2303 slot-definition-location
2304 slot-definition-name
2305 class-slots
2306 gf-arg-info
2307 class-precedence-list
2308 slot-boundp-using-class
2310 slot-value-using-class
2311 structure-class-p
2312 standard-class-p
2313 funcallable-standard-class-p
2314 specializerp)))
2325 early-method))))
2328 early-method t))
2355 next-methods))
2360 ()
2361 lambda-list
2362 specializers
2363 initargs
2364 nil)))
2371 \f
2372 ;;; PARSE-DEFMETHOD is used by DEFMETHOD to parse the &REST argument
2373 ;;; into the 'real' arguments. This is where the syntax of DEFMETHOD
2374 ;;; is really implemented.
2391 result
2394 but is not the name of a class."
2395 spec)
2409 class-name
2410 type))
2411 type))
2435 :initial-element
2443 \f
2448 parameters))
2454 lambda-list))
2460 specializers))
2466 required-parameters))
2470 ()
2483 ;; non-standard lambda-list-keywords are errors.
2487 keyword ~S~%"
2489 ;; no multiple &rest x &rest bla specifying
2493 specialized-lambda-list keyword ~S~%"
2495 ;; And no placing &key in front of &optional, either.
2499 keyword ~S~%"
2501 ;; When we are at a lambda-list keyword, the parameters
2502 ;; don't include the lambda-list keyword; the lambda-list
2503 ;; does include the lambda-list keyword; and no
2504 ;; specializers are allowed to follow the lambda-list
2505 ;; keywords (at least for now).
2516 specialized-lambda-list-keywords)
2519 specialized-lambda-list-keywords)))))
2521 :format-control
2522 "in a specialized-lambda-list, excactly one ~
2523 variable must follow &REST.~%"
2527 ()
2528 ())))
2530 ;; After a lambda-list keyword there can be no specializers.
2533 supplied-keywords
2534 allowed-keywords)
2537 ()
2538 ())))
2546 \f
2548 \f
2549 ;;; FIXME: In here there was a #-CMU definition of SYMBOL-MACROLET
2550 ;;; which used %WALKER stuff. That suggests to me that maybe the code
2551 ;;; walker stuff was only used for implementing stuff like that; maybe
2552 ;;; it's not needed any more? Hunt down what it was used for and see.
2560 instance)))
2563 ,in
2567 slot-entry
2571 slot-entry
2573 `(,var-name
2575 slots)
2584 instance)))
2587 ,in
2592 slots)