| blob | e3d348845af3d8c3a04b3adecd126b04d1a832c9 |
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 |#
71 ;;; FIXME: As of sbcl-0.6.9.10, PCL still uses this nonstandard type
72 ;;; of declaration internally. It would be good to figure out how to
73 ;;; get rid of it, or failing that, (1) document why it's needed and
74 ;;; (2) use a private symbol with a forbidding name which suggests
75 ;;; it's not to be messed with by the user (e.g. SB-PCL:%CLASS)
76 ;;; instead of the too-inviting CLASS. (I tried just deleting the
77 ;;; declarations in MAKE-METHOD-LAMBDA-INTERNAL ca. sbcl-0.6.9.10, but
78 ;;; then things break.)
82 add-named-method
83 ensure-generic-function-using-class
84 add-method
85 remove-method))
89 real-make-a-method)
91 real-add-named-method)
92 ))
94 ;;; For each of the early functions, arrange to have it point to its
95 ;;; early definition. Do this in a way that makes sure that if we
96 ;;; redefine one of the early definitions the redefinition will take
97 ;;; effect. This makes development easier.
105 name))))
107 ;;; *!GENERIC-FUNCTION-FIXUPS* is used by !FIX-EARLY-GENERIC-FUNCTIONS
108 ;;; to convert the few functions in the bootstrap which are supposed
109 ;;; to be generic functions but can't be early on.
118 real-remove-method))
122 real-get-method))
125 &key generic-function-class environment
128 real-ensure-gf-using-class--generic-function)
130 &key generic-function-class environment
133 real-ensure-gf-using-class--null))
137 real-make-method-lambda))
140 lambda-expression
141 lambda-list environment)
143 real-make-method-initargs-form))
147 standard-compute-effective-method))))
148 \f
177 ;; FIXME: this list is slightly weird.
178 ;; ANSI (on the DEFGENERIC page) in one
179 ;; place allows only OPTIMIZE; in
180 ;; another place gives this list of
181 ;; disallowed declaration specifiers.
182 ;; This seems to be the only place where
183 ;; the FUNCTION declaration is
184 ;; mentioned; TYPE seems to be missing.
185 ;; Very strange. -- CSR, 2002-10-21
187 inline notinline special)))
190 is not allowed inside DEFGENERIC."
193 (:method-combination
199 symbol: ~S"
203 (:argument-precedence-order
209 :ARGUMENT-PRECEDENCE-ORDER clause."
214 :ARGUMENT-PRECEDENCE-ORDER clause: ~
215 ~S and ~S"
225 (:method
228 ;; ANSI requires that unsupported things must get a
229 ;; PROGRAM-ERROR.
261 fun-name
262 :lambda-list lambda-list
264 initargs))
266 ;;; As per section 3.4.2 of the ANSI spec, generic function lambda
267 ;;; lists have some special limitations, which we check here.
272 ;; (s/invalid/non-ANSI-conforming/ because the old PCL
273 ;; implementation allowed this, so people got used to
274 ;; it, and maybe this phrasing will help them to guess
275 ;; why their program which worked under PCL no longer works.)
276 "~@<non-ANSI-conforming argument ~S ~_in the generic function lambda list ~S~:>"
277 arg lambda-list))))
279 auxp aux morep more-context more-count)
286 ;; no defaults allowed for &OPTIONAL arguments
290 ;; no defaults allowed for &KEY arguments
301 ;; no &AUX allowed
304 lambda-list))
305 ;; Oh, *puhlease*... not specifically as per section 3.4.2 of
306 ;; the ANSI spec, but the CMU CL &MORE extension does not
307 ;; belong here!
309 \f
316 proto-gf
317 proto-method
318 qualifiers
319 lambda-list
320 body
321 env))))
336 ;;; Take a name which is either a generic function name or a list specifying
337 ;;; a SETF generic function (like: (SETF <generic-function-name>)). Return
338 ;;; the prototype instance of the method-class for that generic function.
339 ;;;
340 ;;; If there is no generic function by that name, this returns the
341 ;;; default value, the prototype instance of the class
342 ;;; STANDARD-METHOD. This default value is also returned if the spec
343 ;;; names an ordinary function or even a macro. In effect, this leaves
344 ;;; the signalling of the appropriate error until load time.
345 ;;;
346 ;;; Note: During bootstrapping, this function is allowed to return NIL.
353 ; error at load time.
358 \f
360 proto-gf
361 proto-method
362 qualifiers
363 lambda-list
364 body
365 env)
371 proto-method
372 method-function-lambda
373 initargs
374 env)))
376 ;; Note: We could DECLAIM the ftype of the generic function
377 ;; here, since ANSI specifies that we create it if it does
378 ;; not exist. However, I chose not to, because I think it's
379 ;; more useful to support a style of programming where every
380 ;; generic function has an explicit DEFGENERIC and any typos
381 ;; in DEFMETHODs are warned about. Otherwise
382 ;;
383 ;; (DEFGENERIC FOO-BAR-BLETCH ((X T)))
384 ;; (DEFMETHOD FOO-BAR-BLETCH ((X HASH-TABLE)) ..)
385 ;; (DEFMETHOD FOO-BRA-BLETCH ((X SIMPLE-VECTOR)) ..)
386 ;; (DEFMETHOD FOO-BAR-BLETCH ((X VECTOR)) ..)
387 ;; (DEFMETHOD FOO-BAR-BLETCH ((X ARRAY)) ..)
388 ;; (DEFMETHOD FOO-BAR-BLETCH ((X LIST)) ..)
389 ;;
390 ;; compiles without raising an error and runs without
391 ;; raising an error (since SIMPLE-VECTOR cases fall through
392 ;; to VECTOR) but still doesn't do what was intended. I hate
393 ;; that kind of bug (code which silently gives the wrong
394 ;; answer), so we don't do a DECLAIM here. -- WHN 20000229
396 unspecialized-lambda-list
400 initargs-form
408 unspecialized-lambda-list method-class-name
411 fn-lambda)
424 specializers)
435 specl))
436 specializers))
441 ;; (We bind *PACKAGE* to
442 ;; KEYWORD here as a way to
443 ;; force symbols to be printed
444 ;; with explicit package
445 ;; prefixes.)
452 name qualifiers `',specls
453 unspecialized-lambda-list method-class-name
455 #',mname-sym
457 pv-table-symbol)))
459 name qualifiers
465 specializers))
466 unspecialized-lambda-list
467 method-class-name
468 initargs-form
469 pv-table-symbol))))
475 ',method-class-name
476 ',name
477 ',qualifiers
478 ,specializers-form
479 ',unspecialized-lambda-list
480 ,initargs-form
481 ;; Paper over a bug in KCL by passing the cache-symbol here in
482 ;; addition to in the list. FIXME: We should no longer need to do
483 ;; this, since the CLOS code is now SBCL-specific, and doesn't
484 ;; need to be ported to every buggy compiler in existence.
496 proto-method
497 method-function-lambda
498 initargs
499 env))))
509 ;; (Old PCL code used a somewhat different style of
510 ;; list for %METHOD-NAME values. Our names use
511 ;; ,@QUALIFIERS instead of ,QUALIFIERS so that the
512 ;; method names look more like what you see in a
513 ;; DEFMETHOD form.)
514 ;;
515 ;; FIXME: As of sbcl-0.7.0.6, code elsewhere, at
516 ;; least the code to set up named BLOCKs around the
517 ;; bodies of methods, depends on the function's base
518 ;; name being the first element of the %METHOD-NAME
519 ;; list. It would be good to remove this dependency,
520 ;; perhaps by building the BLOCK here, or by using
521 ;; another declaration (e.g. %BLOCK-NAME), so that
522 ;; our method debug names are free to have any format,
523 ;; e.g. (:METHOD PRINT-OBJECT :AROUND (CLOWN T)).
524 ;;
525 ;; Further, as of sbcl-0.7.9.10, the code to
526 ;; implement NO-NEXT-METHOD is coupled to the form of
527 ;; this declaration; see the definition of
528 ;; CALL-NO-NEXT-METHOD (and the passing of
529 ;; METHOD-NAME-DECLARATION arguments around the
530 ;; various CALL-NEXT-METHOD logic).
532 ,@qualifiers
535 ,@declarations
537 unspecialized-lambda-list specializers))))
540 method-lambda initargs env)
545 is not a lambda form."
546 method-lambda))
557 ;;; a helper function for creating Python-friendly type declarations
558 ;;; in DEFMETHOD forms
562 ;; KLUDGE: ANSI, in its wisdom, says that
563 ;; EQL-SPECIALIZER-FORMs in EQL specializers are evaluated at
564 ;; DEFMETHOD expansion time. Thus, although one might think
565 ;; that in
566 ;; (DEFMETHOD FOO ((X PACKAGE)
567 ;; (Y (EQL 12))
568 ;; ..))
569 ;; the PACKAGE and (EQL 12) forms are both parallel type
570 ;; names, they're not, as is made clear when you do
571 ;; (DEFMETHOD FOO ((X PACKAGE)
572 ;; (Y (EQL 'BAR)))
573 ;; ..)
574 ;; where Y needs to be a symbol named "BAR", not some cons
575 ;; made by (CONS 'QUOTE 'BAR). I.e. when the
576 ;; EQL-SPECIALIZER-FORM is (EQL 'X), it requires an argument
577 ;; to be of type (EQL X). It'd be easy to transform one to
578 ;; the other, but it'd be somewhat messier to do so while
579 ;; ensuring that the EQL-SPECIALIZER-FORM is only EVAL'd
580 ;; once. (The new code wouldn't be messy, but it'd require a
581 ;; big transformation of the old code.) So instead we punt.
582 ;; -- WHN 20000610
585 ;; KLUDGE: For some low-level implementation
586 ;; classes, perhaps because of some problems related
587 ;; to the incomplete integration of PCL into SBCL's
588 ;; type system, some specializer classes can't be
589 ;; declared as argument types. E.g.
590 ;; (DEFMETHOD FOO ((X SLOT-OBJECT))
591 ;; (DECLARE (TYPE SLOT-OBJECT X))
592 ;; ..)
593 ;; loses when
594 ;; (DEFSTRUCT BAR A B)
595 ;; (FOO (MAKE-BAR))
596 ;; perhaps because of the way that STRUCTURE-OBJECT
597 ;; inherits both from SLOT-OBJECT and from
598 ;; SB-KERNEL:INSTANCE. In an effort to sweep such
599 ;; problems under the rug, we exclude these problem
600 ;; cases by blacklisting them here. -- WHN 2001-01-19
604 ;; KLUDGE: PCL, in its wisdom, sometimes calls methods with
605 ;; types which don't match their specializers. (Specifically,
606 ;; it calls ENSURE-CLASS-USING-CLASS (T NULL) with a non-NULL
607 ;; second argument.) Hopefully it only does this kind of
608 ;; weirdness when bootstrapping.. -- WHN 20000610
611 ;; Otherwise, we can usually make Python very happy.
621 ;; we can get here, and still not have a failure
622 ;; case, by doing MOP programming like (PROGN
623 ;; (ENSURE-CLASS 'FOO) (DEFMETHOD BAR ((X FOO))
624 ;; ...)). Best to let the user know we haven't
625 ;; been able to extract enough information:
627 "~@<can't find type for presumed class ~S in ~S.~@:>"
628 specializer
635 is not a lambda form."
636 method-lambda))
648 parameters
649 specializers))
654 ;; These declarations seem to be used by PCL to pass
655 ;; information to itself; when I tried to delete 'em
656 ;; ca. 0.6.10 it didn't work. I'm not sure how
657 ;; they work, but note the (VAR-DECLARATION '%CLASS ..)
658 ;; expression in CAN-OPTIMIZE-ACCESS1. -- WHN 2000-12-30
663 parameters
664 specializers))
665 ;; These TYPE declarations weren't in the original
666 ;; PCL code, but the Python compiler likes them a
667 ;; lot. (We're telling the compiler about our
668 ;; knowledge of specialized argument types so that
669 ;; it can avoid run-time type dispatch overhead,
670 ;; which can be a huge win for Python.)
671 ;;
672 ;; KLUDGE: when I tried moving these to
673 ;; ADD-METHOD-DECLARATIONS, things broke. No idea
674 ;; why. -- CSR, 2004-06-16
676 parameters
677 specializers)))
679 ;; Remove the documentation string and insert the
680 ;; appropriate class declarations. The documentation
681 ;; string is removed to make it easy for us to insert
682 ;; new declarations later, they will just go after the
683 ;; CADR of the method lambda. The class declarations
684 ;; are inserted to communicate the class of the method's
685 ;; arguments to the code walk.
687 ;; The default ignorability of method parameters
688 ;; doesn't seem to be specified by ANSI. PCL had
689 ;; them basically ignorable but was a little
690 ;; inconsistent. E.g. even though the two
691 ;; method definitions
692 ;; (DEFMETHOD FOO ((X T) (Y T)) "Z")
693 ;; (DEFMETHOD FOO ((X T) Y) "Z")
694 ;; are otherwise equivalent, PCL treated Y as
695 ;; ignorable in the first definition but not in the
696 ;; second definition. We make all required
697 ;; parameters ignorable as a way of systematizing
698 ;; the old PCL behavior. -- WHN 2000-11-24
700 ,class-declarations
701 ,@declarations
721 next-method-p-p setq-p)
723 required-parameters
724 env
725 slots
726 calls)
728 walked-declarations
729 walked-documentation)
747 ,slot-name-lists
755 aux))))
758 (,lambda-list .method-args. .next-methods.
759 :call-next-method-p
760 ,call-next-method-p
763 ;; we need to pass this along
764 ;; so that NO-NEXT-METHOD can
765 ;; be given a suitable METHOD
766 ;; argument; we need the
767 ;; QUALIFIERS and SPECIALIZERS
768 ;; inside the declaration to
769 ;; give to FIND-METHOD.
773 ,@walked-declarations
785 method-args
786 next-methods
797 next-method-call
798 args
799 rest-arg
812 .next-method. ,',next-methods
834 ;; KLUDGE: inefficient traversal, but hey. This should only
835 ;; happen on the slow error path anyway.
841 method
842 args)))))
846 call-method-args)
867 pv-cell
868 next-method-call
869 arg-info)
890 \f
891 ;;;; effective method functions
897 ;;; This function was in the CMU CL version of PCL (ca Debian 2.4.8)
898 ;;; without explanation. It appears to be intended for debugging, so
899 ;;; it might be useful someday, so I haven't deleted it.
900 ;;; But it isn't documented and isn't used for anything now, so
901 ;;; I've conditionalized it out of the base system. -- WHN 19991213
902 #+sb-show
939 ;; FIXME: The RESTP handling here is confusing and maybe slightly
940 ;; broken if RESTP evaluates to a non-self-evaluating form. E.g. if
941 ;; (INVOKE-EFFECTIVE-METHOD-FUNCTION EMF '(ERROR "gotcha") ...)
942 ;; then TRACE-EMF-CALL-CALL-INTERNAL might die on a gotcha error.
948 ;; "What," you may wonder, "do these next two clauses do?"
949 ;; In that case, you are not a PCL implementor, for they
950 ;; considered this to be self-documenting.:-| Or CSR, for
951 ;; that matter, since he can also figure it out by looking
952 ;; at it without breaking stride. For the rest of us,
953 ;; though: From what the code is doing with .SLOTS. and
954 ;; whatnot, evidently it's implementing SLOT-VALUEish and
955 ;; GET-SLOT-VALUEish things. Then we can reason backwards
956 ;; and conclude that setting EMF to a FIXNUM is an
957 ;; optimized way to represent these slot access operations.
966 value)))))
974 ;; (In cmucl-2.4.8 there was a commented-out third ,@(WHEN
975 ;; ...) clause here to handle SLOT-BOUNDish stuff. Since
976 ;; there was no explanation and presumably the code is 10+
977 ;; years stale, I simply deleted it. -- WHN)
1018 args))))))
1021 args
1030 value)))
1044 \f
1050 ;; INVOKE-EFFECTIVE-METHOD-FUNCTION has code in it to
1051 ;; dispatch on the possibility that EMF might be of
1052 ;; type FIXNUM (as an optimized representation of a
1053 ;; slot accessor). But as far as I (WHN 2002-06-11)
1054 ;; can tell, it's impossible for such a representation
1055 ;; to end up as .NEXT-METHOD-CALL. By reassuring
1056 ;; INVOKE-E-M-F that when called from this context
1057 ;; it needn't worry about the FIXNUM case, we can
1058 ;; keep those cases from being compiled, which is
1059 ;; good both because it saves bytes and because it
1060 ;; avoids annoying type mismatch compiler warnings.
1061 ;;
1062 ;; KLUDGE: In sbcl-0.7.4.29, the compiler's type
1063 ;; system isn't smart enough about NOT and
1064 ;; intersection types to benefit from a (NOT FIXNUM)
1065 ;; declaration here. -- WHN 2002-06-12 (FIXME: maybe
1066 ;; it is now... -- CSR, 2003-06-07)
1067 ;;
1068 ;; FIXME: Might the FUNCTION type be omittable here,
1069 ;; leaving only METHOD-CALLs? Failing that, could this
1070 ;; be documented somehow? (It'd be nice if the types
1071 ;; involved could be understood without solving the
1072 ;; halting problem.)
1080 ;; This declaration suppresses a "deleting
1081 ;; unreachable code" note for the following IF
1082 ;; when REST-ARG is NIL. It is not nice for
1083 ;; debugging SBCL itself, but at least it
1084 ;; keeps us from annoying users.
1091 nil
1096 ,@',args
1106 ;; As above, this declaration suppresses code
1107 ;; deletion notes.
1115 ,@',args
1129 ((&key call-next-method-p next-method-p-p setq-p
1130 closurep applyp method-name-declaration)
1140 ,method-name-declaration
1141 cnm-args))))
1163 "encountered the non-standard lambda list keyword ~S"
1164 var)))
1165 nil)
1213 ,@bindings
1214 (.dummy0.
1226 ;; FIXME: Do we want to export this symbol? Or maybe use an
1227 ;; (ERROR 'SIMPLE-PROGRAM-ERROR) form?
1230 return tail))
1234 ; should be in the method definition
1236 ; was seen in the body of a method
1238 ; should be in the method definition
1242 ;; FIXME: Jumping to a conclusion from the way it's used
1243 ;; above, perhaps CONTEXT should be called SITUATION
1244 ;; (after the term used in the ANSI specification of
1245 ;; EVAL-WHEN) and given modern ANSI keyword values
1246 ;; like :LOAD-TOPLEVEL.
1250 form)
1253 form)
1256 form)
1261 form)
1265 form)
1271 required-parameters
1272 env)))
1283 form required-parameters env slots calls))
1286 form required-parameters env slots calls))
1291 call-next-method-p
1292 closurep
1293 next-method-p-p
1294 setq-p)))))
1302 \f
1351 \f
1362 ll initargs pv-table-symbol)))
1366 initargs pv-table-symbol)
1369 pv-table-symbol))
1376 qualifiers
1378 nil))))
1381 gf-spec qualifiers specializers))))
1383 gf-spec qualifiers specializers lambda-list
1385 ,@qualifiers
1388 initargs)))
1391 ;; FIXME: should be STYLE-WARNING?
1393 "~&At the time the method with qualifiers ~:S and~%~
1394 specializers ~:S on the generic function ~S~%~
1395 was compiled, the method-class for that generic function was~%~
1396 ~S. But, the method class is now ~S, this~%~
1397 may mean that this method was compiled improperly.~%"
1398 qualifiers specializers gf-spec
1400 method))
1423 ;; KLUDGE: If we're going to be
1424 ;; interning private symbols in our
1425 ;; a this way, it would be cleanest
1426 ;; to use a separate package
1427 ;; %PCL-PRIVATE or something, and
1428 ;; failing that, to use a special
1429 ;; symbol prefix denoting privateness.
1430 ;; -- WHN 19991201
1452 \f
1482 x)))
1491 After &REST, a DEFGENERIC lambda-list ~
1505 keywords keyword-parameters)
1514 old-ftype))))
1529 keywords)
1532 *))))
1536 \f
1537 ;;;; early generic function support
1542 &rest all-keys
1543 &key environment
1553 existing fun-name all-keys))))
1602 arg-info-precedence
1603 arg-info-metatypes
1604 arg-info-number-optional
1605 arg-info-key/rest-p
1606 arg-info-keys ;nil no &KEY or &REST allowed
1607 ;(k1 k2 ..) Each method must accept these &KEY arguments.
1608 ;T must have &KEY or &REST
1610 gf-info-simple-accessor-type ; nil, reader, writer, boundp
1613 gf-info-static-c-a-m-emf
1615 gf-info-fast-mf-p)
1632 ;;; Keep pages clean by not setting if the value is already the same.
1640 argument-precedence-order)
1664 existing methods of ~S."
1665 lambda-list gf))))
1672 argument-precedence-order)))
1683 arg-info))
1693 to the generic function~2I~_~S;~I~_~
1694 but ~?~:>"
1704 "the method has ~A required arguments than the generic function."
1708 "the method has ~A optional arguments than the generic function."
1712 "the method and generic function differ in whether they accept~_~
1716 allow-other-keys-p
1719 ~S."
1720 gf-keywords)))))))
1730 nil)))
1774 nil)
1779 ;; FIXME: this test will eventually be
1780 ;; superseded by the *internal-pcl...* test,
1781 ;; above. While we are in a process of
1782 ;; transition, however, it should probably
1783 ;; remain.
1789 #'make-method-lambda
1800 arg-info)
1802 ;;; This is the early definition of ENSURE-GENERIC-FUNCTION-USING-CLASS.
1803 ;;;
1804 ;;; The STATIC-SLOTS field of the funcallable instances used as early
1805 ;;; generic functions is used to store the early methods and early
1806 ;;; discriminator code for the early generic function. The static
1807 ;;; slots field of the fins contains a list whose:
1808 ;;; CAR - a list of the early methods on this early gf
1809 ;;; CADR - the early discriminator code for this method
1812 lambda-list-p)
1813 argument-precedence-order
1819 existing)
1823 argument-precedence-order)
1827 spec
1832 argument-precedence-order))))
1835 function argument-precedence-order)
1838 fin
1851 fin
1852 'source
1861 :lambda-list lambda-list
1864 fin))
1871 dfun)))
1875 new-state)))
1876 dfun)
1911 nil)
1919 ll))))
1929 class nor a symbol that names a class."
1946 fun-name
1947 &rest all-keys
1962 fun-name
1963 &rest all-keys
1975 \f
1977 ;; values nreq applyp metatypes nkeys arg-info
1984 metatypes
1985 arg-info))
1988 arg-info)))
1995 ;; Figure out whether we got class objects or class names as the
1996 ;; specializers and set parsed and unparsed appropriately. If we
1997 ;; got class objects, then we can compute unparsed, but if we got
1998 ;; class names we don't try to compute parsed.
1999 ;;
2000 ;; Note that the use of not symbolp in this call to every should be
2001 ;; read as 'classp' we can't use classp itself because it doesn't
2002 ;; exist yet.
2007 specializers))
2009 parsed ()))
2015 parsed ;The parsed specializers. This is used
2016 ;by early-method-specializers to cache
2017 ;the parse. Note that this only comes
2018 ;into play when there is more than one
2019 ;early method on an early gf.
2022 qualifiers ;can be applied to make a real method
2023 arglist ;corresponding to this early one.
2024 unparsed
2025 initargs
2026 doc
2027 slot-name))))
2034 :qualifiers qualifiers
2035 :lambda-list lambda-list
2036 :specializers specializers
2037 :documentation doc
2038 :slot-name slot-name
2039 :allow-other-keys t
2040 initargs))
2057 ;;; Fetch the specializers of an early method. This is basically just
2058 ;;; a simple accessor except that when the second argument is t, this
2059 ;;; converts the specializers from symbols into class objects. The
2060 ;;; class objects are cached in the early method, this makes
2061 ;;; bootstrapping faster because the class objects only have to be
2062 ;;; computed once.
2063 ;;;
2064 ;;; NOTE:
2065 ;;; The second argument should only be passed as T by
2066 ;;; early-lookup-method. This is to implement the rule that only when
2067 ;;; there is more than one early method on a generic function is the
2068 ;;; conversion from class names to class objects done. This
2069 ;;; corresponds to the fact that we are only allowed to have one
2070 ;;; method on any generic function up until the time classes exist.
2089 qualifiers
2090 specializers
2091 arglist
2100 qualifiers
2101 arglist
2102 specializers
2103 initargs
2104 ())))
2108 ;;; This is the early version of ADD-METHOD. Later this will become a
2109 ;;; generic function. See !FIX-EARLY-GENERIC-FUNCTIONS which has
2110 ;;; special knowledge about ADD-METHOD.
2123 ;;; This is the early version of REMOVE-METHOD. See comments on
2124 ;;; the early version of ADD-METHOD.
2138 ;;; This is the early version of GET-METHOD. See comments on the early
2139 ;;; version of ADD-METHOD.
2145 specializers)
2147 specializers))
2152 nil))
2157 ;; Rearrange *!EARLY-GENERIC-FUNCTIONS* to speed up
2158 ;; FIX-EARLY-GENERIC-FUNCTIONS.
2165 generic-function-methods
2166 method-specializers
2167 specializerp
2168 specializer-type
2169 specializer-class
2170 slot-definition-location
2171 slot-definition-name
2172 class-slots
2173 gf-arg-info
2174 class-precedence-list
2175 slot-boundp-using-class
2177 slot-value-using-class
2178 structure-class-p
2179 standard-class-p
2180 funcallable-standard-class-p
2181 specializerp)))
2192 early-method))))
2195 early-method t))
2222 next-methods))
2227 ()
2228 lambda-list
2229 specializers
2230 initargs
2231 nil)))
2238 \f
2239 ;;; PARSE-DEFMETHOD is used by DEFMETHOD to parse the &REST argument
2240 ;;; into the 'real' arguments. This is where the syntax of DEFMETHOD
2241 ;;; is really implemented.
2258 result
2261 but is not the name of a class."
2262 spec)
2276 class-name
2277 type))
2278 type))
2303 :initial-element
2309 quals
2310 specls))))))))
2312 \f
2317 parameters))
2323 lambda-list))
2329 specializers))
2335 required-parameters))
2347 ;; Now, since we try to conform to ANSI, non-standard
2348 ;; lambda-list-keywords should be treated as errors.
2352 keyword ~S~%"
2354 ;; no multiple &rest x &rest bla specifying
2358 specialized-lambda-list keyword ~S~%"
2360 ;; And no placing &key in front of &optional, either.
2364 keyword ~S~%"
2366 ;; When we are at a lambda-list keyword, the parameters
2367 ;; don't include the lambda-list keyword; the lambda-list
2368 ;; does include the lambda-list keyword; and no
2369 ;; specializers are allowed to follow the lambda-list
2370 ;; keywords (at least for now).
2381 specialized-lambda-list-keywords)
2384 specialized-lambda-list-keywords)))))
2386 :format-control
2387 "in a specialized-lambda-list, excactly one ~
2388 variable must follow &REST.~%"
2392 ()
2393 ())))
2395 ;; After a lambda-list keyword there can be no specializers.
2398 supplied-keywords
2399 allowed-keywords)
2402 ()
2403 ())))
2411 \f
2413 \f
2414 ;;; FIXME: In here there was a #-CMU definition of SYMBOL-MACROLET
2415 ;;; which used %WALKER stuff. That suggests to me that maybe the code
2416 ;;; walker stuff was only used for implementing stuff like that; maybe
2417 ;;; it's not needed any more? Hunt down what it was used for and see.
2425 instance)))
2428 ,in
2432 slot-entry
2436 slot-entry
2438 `(,var-name
2440 slots)
2449 instance)))
2452 ,in
2457 slots)