| blob | 7e0131dfe88334dbcda4c9fd4fa5c0bad680f16d |
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."
204 (:method
207 ;; ANSI requires that unsupported things must get a
208 ;; PROGRAM-ERROR.
240 fun-name
241 :lambda-list lambda-list
243 initargs))
245 ;;; As per section 3.4.2 of the ANSI spec, generic function lambda
246 ;;; lists have some special limitations, which we check here.
251 ;; (s/invalid/non-ANSI-conforming/ because the old PCL
252 ;; implementation allowed this, so people got used to
253 ;; it, and maybe this phrasing will help them to guess
254 ;; why their program which worked under PCL no longer works.)
255 "~@<non-ANSI-conforming argument ~S ~_in the generic function lambda list ~S~:>"
256 arg lambda-list))))
258 auxp aux morep more-context more-count)
265 ;; no defaults allowed for &OPTIONAL arguments
269 ;; no defaults allowed for &KEY arguments
280 ;; no &AUX allowed
283 lambda-list))
284 ;; Oh, *puhlease*... not specifically as per section 3.4.2 of
285 ;; the ANSI spec, but the CMU CL &MORE extension does not
286 ;; belong here!
288 \f
295 proto-gf
296 proto-method
297 qualifiers
298 lambda-list
299 body
300 env))))
315 ;;; Take a name which is either a generic function name or a list specifying
316 ;;; a SETF generic function (like: (SETF <generic-function-name>)). Return
317 ;;; the prototype instance of the method-class for that generic function.
318 ;;;
319 ;;; If there is no generic function by that name, this returns the
320 ;;; default value, the prototype instance of the class
321 ;;; STANDARD-METHOD. This default value is also returned if the spec
322 ;;; names an ordinary function or even a macro. In effect, this leaves
323 ;;; the signalling of the appropriate error until load time.
324 ;;;
325 ;;; Note: During bootstrapping, this function is allowed to return NIL.
332 ; error at load time.
337 \f
339 proto-gf
340 proto-method
341 qualifiers
342 lambda-list
343 body
344 env)
350 proto-method
351 method-function-lambda
352 initargs
353 env)))
355 ;; Note: We could DECLAIM the ftype of the generic function
356 ;; here, since ANSI specifies that we create it if it does
357 ;; not exist. However, I chose not to, because I think it's
358 ;; more useful to support a style of programming where every
359 ;; generic function has an explicit DEFGENERIC and any typos
360 ;; in DEFMETHODs are warned about. Otherwise
361 ;;
362 ;; (DEFGENERIC FOO-BAR-BLETCH ((X T)))
363 ;; (DEFMETHOD FOO-BAR-BLETCH ((X HASH-TABLE)) ..)
364 ;; (DEFMETHOD FOO-BRA-BLETCH ((X SIMPLE-VECTOR)) ..)
365 ;; (DEFMETHOD FOO-BAR-BLETCH ((X VECTOR)) ..)
366 ;; (DEFMETHOD FOO-BAR-BLETCH ((X ARRAY)) ..)
367 ;; (DEFMETHOD FOO-BAR-BLETCH ((X LIST)) ..)
368 ;;
369 ;; compiles without raising an error and runs without
370 ;; raising an error (since SIMPLE-VECTOR cases fall through
371 ;; to VECTOR) but still doesn't do what was intended. I hate
372 ;; that kind of bug (code which silently gives the wrong
373 ;; answer), so we don't do a DECLAIM here. -- WHN 20000229
375 unspecialized-lambda-list
379 initargs-form
387 unspecialized-lambda-list method-class-name
390 fn-lambda)
403 specializers)
414 specl))
415 specializers))
420 ;; (We bind *PACKAGE* to
421 ;; KEYWORD here as a way to
422 ;; force symbols to be printed
423 ;; with explicit package
424 ;; prefixes.)
431 name qualifiers `',specls
432 unspecialized-lambda-list method-class-name
434 #',mname-sym
436 pv-table-symbol)))
438 name qualifiers
444 specializers))
445 unspecialized-lambda-list
446 method-class-name
447 initargs-form
448 pv-table-symbol))))
454 ',method-class-name
455 ',name
456 ',qualifiers
457 ,specializers-form
458 ',unspecialized-lambda-list
459 ,initargs-form
460 ;; Paper over a bug in KCL by passing the cache-symbol here in
461 ;; addition to in the list. FIXME: We should no longer need to do
462 ;; this, since the CLOS code is now SBCL-specific, and doesn't
463 ;; need to be ported to every buggy compiler in existence.
475 proto-method
476 method-function-lambda
477 initargs
478 env))))
488 ;; (Old PCL code used a somewhat different style of
489 ;; list for %METHOD-NAME values. Our names use
490 ;; ,@QUALIFIERS instead of ,QUALIFIERS so that the
491 ;; method names look more like what you see in a
492 ;; DEFMETHOD form.)
493 ;;
494 ;; FIXME: As of sbcl-0.7.0.6, code elsewhere, at
495 ;; least the code to set up named BLOCKs around the
496 ;; bodies of methods, depends on the function's base
497 ;; name being the first element of the %METHOD-NAME
498 ;; list. It would be good to remove this dependency,
499 ;; perhaps by building the BLOCK here, or by using
500 ;; another declaration (e.g. %BLOCK-NAME), so that
501 ;; our method debug names are free to have any format,
502 ;; e.g. (:METHOD PRINT-OBJECT :AROUND (CLOWN T)).
503 ;;
504 ;; Further, as of sbcl-0.7.9.10, the code to
505 ;; implement NO-NEXT-METHOD is coupled to the form of
506 ;; this declaration; see the definition of
507 ;; CALL-NO-NEXT-METHOD (and the passing of
508 ;; METHOD-NAME-DECLARATION arguments around the
509 ;; various CALL-NEXT-METHOD logic).
511 ,@qualifiers
514 ,@declarations
516 unspecialized-lambda-list specializers))))
519 method-lambda initargs env)
524 is not a lambda form."
525 method-lambda))
536 ;;; a helper function for creating Python-friendly type declarations
537 ;;; in DEFMETHOD forms
541 ;; KLUDGE: ANSI, in its wisdom, says that
542 ;; EQL-SPECIALIZER-FORMs in EQL specializers are evaluated at
543 ;; DEFMETHOD expansion time. Thus, although one might think
544 ;; that in
545 ;; (DEFMETHOD FOO ((X PACKAGE)
546 ;; (Y (EQL 12))
547 ;; ..))
548 ;; the PACKAGE and (EQL 12) forms are both parallel type
549 ;; names, they're not, as is made clear when you do
550 ;; (DEFMETHOD FOO ((X PACKAGE)
551 ;; (Y (EQL 'BAR)))
552 ;; ..)
553 ;; where Y needs to be a symbol named "BAR", not some cons
554 ;; made by (CONS 'QUOTE 'BAR). I.e. when the
555 ;; EQL-SPECIALIZER-FORM is (EQL 'X), it requires an argument
556 ;; to be of type (EQL X). It'd be easy to transform one to
557 ;; the other, but it'd be somewhat messier to do so while
558 ;; ensuring that the EQL-SPECIALIZER-FORM is only EVAL'd
559 ;; once. (The new code wouldn't be messy, but it'd require a
560 ;; big transformation of the old code.) So instead we punt.
561 ;; -- WHN 20000610
564 ;; KLUDGE: For some low-level implementation
565 ;; classes, perhaps because of some problems related
566 ;; to the incomplete integration of PCL into SBCL's
567 ;; type system, some specializer classes can't be
568 ;; declared as argument types. E.g.
569 ;; (DEFMETHOD FOO ((X SLOT-OBJECT))
570 ;; (DECLARE (TYPE SLOT-OBJECT X))
571 ;; ..)
572 ;; loses when
573 ;; (DEFSTRUCT BAR A B)
574 ;; (FOO (MAKE-BAR))
575 ;; perhaps because of the way that STRUCTURE-OBJECT
576 ;; inherits both from SLOT-OBJECT and from
577 ;; SB-KERNEL:INSTANCE. In an effort to sweep such
578 ;; problems under the rug, we exclude these problem
579 ;; cases by blacklisting them here. -- WHN 2001-01-19
583 ;; KLUDGE: PCL, in its wisdom, sometimes calls methods with
584 ;; types which don't match their specializers. (Specifically,
585 ;; it calls ENSURE-CLASS-USING-CLASS (T NULL) with a non-NULL
586 ;; second argument.) Hopefully it only does this kind of
587 ;; weirdness when bootstrapping.. -- WHN 20000610
590 ;; Otherwise, we can usually make Python very happy.
600 ;; we can get here, and still not have a failure
601 ;; case, by doing MOP programming like (PROGN
602 ;; (ENSURE-CLASS 'FOO) (DEFMETHOD BAR ((X FOO))
603 ;; ...)). Best to let the user know we haven't
604 ;; been able to extract enough information:
606 "~@<can't find type for presumed class ~S in ~S.~@:>"
607 specializer
614 is not a lambda form."
615 method-lambda))
627 parameters
628 specializers))
633 ;; These declarations seem to be used by PCL to pass
634 ;; information to itself; when I tried to delete 'em
635 ;; ca. 0.6.10 it didn't work. I'm not sure how
636 ;; they work, but note the (VAR-DECLARATION '%CLASS ..)
637 ;; expression in CAN-OPTIMIZE-ACCESS1. -- WHN 2000-12-30
642 parameters
643 specializers))
644 ;; These TYPE declarations weren't in the original
645 ;; PCL code, but the Python compiler likes them a
646 ;; lot. (We're telling the compiler about our
647 ;; knowledge of specialized argument types so that
648 ;; it can avoid run-time type dispatch overhead,
649 ;; which can be a huge win for Python.)
650 ;;
651 ;; FIXME: Perhaps these belong in
652 ;; ADD-METHOD-DECLARATIONS instead of here?
654 parameters
655 specializers)))
657 ;; Remove the documentation string and insert the
658 ;; appropriate class declarations. The documentation
659 ;; string is removed to make it easy for us to insert
660 ;; new declarations later, they will just go after the
661 ;; CADR of the method lambda. The class declarations
662 ;; are inserted to communicate the class of the method's
663 ;; arguments to the code walk.
665 ;; The default ignorability of method parameters
666 ;; doesn't seem to be specified by ANSI. PCL had
667 ;; them basically ignorable but was a little
668 ;; inconsistent. E.g. even though the two
669 ;; method definitions
670 ;; (DEFMETHOD FOO ((X T) (Y T)) "Z")
671 ;; (DEFMETHOD FOO ((X T) Y) "Z")
672 ;; are otherwise equivalent, PCL treated Y as
673 ;; ignorable in the first definition but not in the
674 ;; second definition. We make all required
675 ;; parameters ignorable as a way of systematizing
676 ;; the old PCL behavior. -- WHN 2000-11-24
678 ,class-declarations
679 ,@declarations
700 required-parameters
701 env
702 slots
703 calls)
705 walked-declarations
706 walked-documentation)
724 ,slot-name-lists
732 aux))))
735 (,lambda-list .method-args. .next-methods.
736 :call-next-method-p
737 ,call-next-method-p
739 ;; we need to pass this along
740 ;; so that NO-NEXT-METHOD can
741 ;; be given a suitable METHOD
742 ;; argument; we need the
743 ;; QUALIFIERS and SPECIALIZERS
744 ;; inside the declaration to
745 ;; give to FIND-METHOD.
749 ,@walked-declarations
761 method-args
762 next-methods
773 next-method-call
774 args
775 rest-arg
788 .next-method. ,',next-methods
806 ;; KLUDGE: inefficient traversal, but hey. This should only
807 ;; happen on the slow error path anyway.
813 method
814 args)))))
818 call-method-args)
839 pv-cell
840 next-method-call
841 arg-info)
862 \f
863 ;;;; effective method functions
869 ;;; This function was in the CMU CL version of PCL (ca Debian 2.4.8)
870 ;;; without explanation. It appears to be intended for debugging, so
871 ;;; it might be useful someday, so I haven't deleted it.
872 ;;; But it isn't documented and isn't used for anything now, so
873 ;;; I've conditionalized it out of the base system. -- WHN 19991213
874 #+sb-show
911 ;; FIXME: The RESTP handling here is confusing and maybe slightly
912 ;; broken if RESTP evaluates to a non-self-evaluating form. E.g. if
913 ;; (INVOKE-EFFECTIVE-METHOD-FUNCTION EMF '(ERROR "gotcha") ...)
914 ;; then TRACE-EMF-CALL-CALL-INTERNAL might die on a gotcha error.
920 ;; "What," you may wonder, "do these next two clauses do?"
921 ;; In that case, you are not a PCL implementor, for they
922 ;; considered this to be self-documenting.:-| Or CSR, for
923 ;; that matter, since he can also figure it out by looking
924 ;; at it without breaking stride. For the rest of us,
925 ;; though: From what the code is doing with .SLOTS. and
926 ;; whatnot, evidently it's implementing SLOT-VALUEish and
927 ;; GET-SLOT-VALUEish things. Then we can reason backwards
928 ;; and conclude that setting EMF to a FIXNUM is an
929 ;; optimized way to represent these slot access operations.
938 value)))))
946 ;; (In cmucl-2.4.8 there was a commented-out third ,@(WHEN
947 ;; ...) clause here to handle SLOT-BOUNDish stuff. Since
948 ;; there was no explanation and presumably the code is 10+
949 ;; years stale, I simply deleted it. -- WHN)
990 args))))))
993 args
1002 value)))
1016 \f
1020 ;; INVOKE-EFFECTIVE-METHOD-FUNCTION has code in it to
1021 ;; dispatch on the possibility that EMF might be of
1022 ;; type FIXNUM (as an optimized representation of a
1023 ;; slot accessor). But as far as I (WHN 2002-06-11)
1024 ;; can tell, it's impossible for such a representation
1025 ;; to end up as .NEXT-METHOD-CALL. By reassuring
1026 ;; INVOKE-E-M-F that when called from this context
1027 ;; it needn't worry about the FIXNUM case, we can
1028 ;; keep those cases from being compiled, which is
1029 ;; good both because it saves bytes and because it
1030 ;; avoids annoying type mismatch compiler warnings.
1031 ;;
1032 ;; KLUDGE: In sbcl-0.7.4.29, the compiler's type
1033 ;; system isn't smart enough about NOT and intersection
1034 ;; types to benefit from a (NOT FIXNUM) declaration
1035 ;; here. -- WHN 2002-06-12
1036 ;;
1037 ;; FIXME: Might the FUNCTION type be omittable here,
1038 ;; leaving only METHOD-CALLs? Failing that, could this
1039 ;; be documented somehow? (It'd be nice if the types
1040 ;; involved could be understood without solving the
1041 ;; halting problem.)
1049 ;; This declaration suppresses a "deleting
1050 ;; unreachable code" note for the following IF when
1051 ;; REST-ARG is NIL. It is not nice for debugging
1052 ;; SBCL itself, but at least it keeps us from
1053 ;; annoying users.
1060 nil
1065 ,@',args
1075 ;; As above, this declaration suppresses code
1076 ;; deletion notes.
1084 ,@',args
1092 ((&key call-next-method-p next-method-p-p
1093 closurep applyp method-name-declaration)
1104 ,method-name-declaration
1105 cnm-args))))
1126 "encountered the non-standard lambda list keyword ~S"
1127 var)))
1128 nil)
1183 ;; FIXME: Do we want to export this symbol? Or maybe use an
1184 ;; (ERROR 'SIMPLE-PROGRAM-ERROR) form?
1187 return tail))
1191 ; should be in the method definition
1193 ; was seen in the body of a method
1195 ; should be in the method definition
1198 ;; FIXME: Jumping to a conclusion from the way it's used
1199 ;; above, perhaps CONTEXT should be called SITUATION
1200 ;; (after the term used in the ANSI specification of
1201 ;; EVAL-WHEN) and given modern ANSI keyword values
1202 ;; like :LOAD-TOPLEVEL.
1206 form)
1209 form)
1214 form)
1218 form)
1224 required-parameters
1225 env)))
1236 form required-parameters env slots calls))
1239 form required-parameters env slots calls))
1244 call-next-method-p
1245 closurep
1246 next-method-p-p)))))
1254 \f
1303 \f
1314 ll initargs pv-table-symbol)))
1318 initargs pv-table-symbol)
1321 pv-table-symbol))
1327 qualifiers
1329 nil))))
1332 gf-spec qualifiers specializers))))
1334 gf-spec qualifiers specializers lambda-list
1336 ,@qualifiers
1339 initargs)))
1342 ;; FIXME: should be STYLE-WARNING?
1344 "~&At the time the method with qualifiers ~:S and~%~
1345 specializers ~:S on the generic function ~S~%~
1346 was compiled, the method-class for that generic function was~%~
1347 ~S. But, the method class is now ~S, this~%~
1348 may mean that this method was compiled improperly.~%"
1349 qualifiers specializers gf-spec
1351 method))
1374 ;; KLUDGE: If we're going to be
1375 ;; interning private symbols in our
1376 ;; a this way, it would be cleanest
1377 ;; to use a separate package
1378 ;; %PCL-PRIVATE or something, and
1379 ;; failing that, to use a special
1380 ;; symbol prefix denoting privateness.
1381 ;; -- WHN 19991201
1403 \f
1433 x)))
1442 After &REST, a DEFGENERIC lambda-list ~
1456 keywords keyword-parameters)
1465 old-ftype))))
1480 keywords)
1483 *))))
1489 \f
1490 ;;;; early generic function support
1495 &rest all-keys
1496 &key environment
1506 existing fun-name all-keys))))
1555 arg-info-precedence
1556 arg-info-metatypes
1557 arg-info-number-optional
1558 arg-info-key/rest-p
1559 arg-info-keys ;nil no &KEY or &REST allowed
1560 ;(k1 k2 ..) Each method must accept these &KEY arguments.
1561 ;T must have &KEY or &REST
1563 gf-info-simple-accessor-type ; nil, reader, writer, boundp
1566 gf-info-static-c-a-m-emf
1568 gf-info-fast-mf-p)
1585 ;;; Keep pages clean by not setting if the value is already the same.
1593 argument-precedence-order)
1617 existing methods of ~S."
1618 lambda-list gf))))
1625 argument-precedence-order)))
1636 arg-info))
1646 to the generic function~2I~_~S;~I~_~
1647 but ~?~:>"
1657 "the method has ~A required arguments than the generic function."
1661 "the method has ~A optional arguments than the generic function."
1665 "the method and generic function differ in whether they accept~_~
1669 allow-other-keys-p
1672 ~S."
1673 gf-keywords)))))))
1683 nil)))
1726 ;; FIXME: given the presence of generalized function
1727 ;; names, this test is broken. A little
1728 ;; reverse-engineering suggests that this was intended
1729 ;; to prevent precompilation of things on some
1730 ;; PCL-internal automatically-constructed functions
1731 ;; like the old "~A~A standard class ~A reader"
1732 ;; functions. When the CADR of SB-PCL::SLOT-ACCESSOR
1733 ;; generalized functions was *, this test returned T,
1734 ;; not NIL, and an error was signalled in
1735 ;; MAKE-ACCESSOR-TABLE for (DEFUN FOO (X) (SLOT-VALUE X
1736 ;; 'ASLDKJ)). Whether the right thing to do is to fix
1737 ;; MAKE-ACCESSOR-TABLE so that it can work in the
1738 ;; presence of slot names that have no classes, or to
1739 ;; restore this test to something more obvious, I don't
1740 ;; know. -- CSR, 2003-02-14
1748 #'make-method-lambda
1759 arg-info)
1761 ;;; This is the early definition of ENSURE-GENERIC-FUNCTION-USING-CLASS.
1762 ;;;
1763 ;;; The STATIC-SLOTS field of the funcallable instances used as early
1764 ;;; generic functions is used to store the early methods and early
1765 ;;; discriminator code for the early generic function. The static
1766 ;;; slots field of the fins contains a list whose:
1767 ;;; CAR - a list of the early methods on this early gf
1768 ;;; CADR - the early discriminator code for this method
1771 lambda-list-p)
1772 argument-precedence-order
1776 existing)
1780 argument-precedence-order)
1784 spec
1789 argument-precedence-order))))
1792 function argument-precedence-order)
1795 fin
1808 fin
1809 'source
1818 :lambda-list lambda-list
1821 fin))
1828 dfun)))
1832 new-state)))
1833 dfun)
1868 nil)
1876 ll))))
1886 class nor a symbol that names a class."
1903 fun-name
1904 &rest all-keys
1919 fun-name
1920 &rest all-keys
1932 \f
1934 ;; values nreq applyp metatypes nkeys arg-info
1941 metatypes
1942 arg-info))
1945 arg-info)))
1952 ;; Figure out whether we got class objects or class names as the
1953 ;; specializers and set parsed and unparsed appropriately. If we
1954 ;; got class objects, then we can compute unparsed, but if we got
1955 ;; class names we don't try to compute parsed.
1956 ;;
1957 ;; Note that the use of not symbolp in this call to every should be
1958 ;; read as 'classp' we can't use classp itself because it doesn't
1959 ;; exist yet.
1964 specializers))
1966 parsed ()))
1972 parsed ;The parsed specializers. This is used
1973 ;by early-method-specializers to cache
1974 ;the parse. Note that this only comes
1975 ;into play when there is more than one
1976 ;early method on an early gf.
1979 qualifiers ;can be applied to make a real method
1980 arglist ;corresponding to this early one.
1981 unparsed
1982 initargs
1983 doc
1984 slot-name))))
1991 :qualifiers qualifiers
1992 :lambda-list lambda-list
1993 :specializers specializers
1994 :documentation doc
1995 :slot-name slot-name
1996 :allow-other-keys t
1997 initargs))
2014 ;;; Fetch the specializers of an early method. This is basically just
2015 ;;; a simple accessor except that when the second argument is t, this
2016 ;;; converts the specializers from symbols into class objects. The
2017 ;;; class objects are cached in the early method, this makes
2018 ;;; bootstrapping faster because the class objects only have to be
2019 ;;; computed once.
2020 ;;;
2021 ;;; NOTE:
2022 ;;; The second argument should only be passed as T by
2023 ;;; early-lookup-method. This is to implement the rule that only when
2024 ;;; there is more than one early method on a generic function is the
2025 ;;; conversion from class names to class objects done. This
2026 ;;; corresponds to the fact that we are only allowed to have one
2027 ;;; method on any generic function up until the time classes exist.
2046 qualifiers
2047 specializers
2048 arglist
2057 qualifiers
2058 arglist
2059 specializers
2060 initargs
2061 ())))
2065 ;;; This is the early version of ADD-METHOD. Later this will become a
2066 ;;; generic function. See !FIX-EARLY-GENERIC-FUNCTIONS which has
2067 ;;; special knowledge about ADD-METHOD.
2080 ;;; This is the early version of REMOVE-METHOD. See comments on
2081 ;;; the early version of ADD-METHOD.
2095 ;;; This is the early version of GET-METHOD. See comments on the early
2096 ;;; version of ADD-METHOD.
2102 specializers)
2104 specializers))
2109 nil))
2114 ;; Rearrange *!EARLY-GENERIC-FUNCTIONS* to speed up
2115 ;; FIX-EARLY-GENERIC-FUNCTIONS.
2122 generic-function-methods
2123 method-specializers
2124 specializerp
2125 specializer-type
2126 specializer-class
2127 slot-definition-location
2128 slot-definition-name
2129 class-slots
2130 gf-arg-info
2131 class-precedence-list
2132 slot-boundp-using-class
2134 slot-value-using-class
2135 structure-class-p
2136 standard-class-p
2137 funcallable-standard-class-p
2138 specializerp)))
2149 early-method))))
2152 early-method t))
2179 next-methods))
2184 ()
2185 lambda-list
2186 specializers
2187 initargs
2188 nil)))
2195 \f
2196 ;;; PARSE-DEFMETHOD is used by DEFMETHOD to parse the &REST argument
2197 ;;; into the 'real' arguments. This is where the syntax of DEFMETHOD
2198 ;;; is really implemented.
2215 result
2218 but is not the name of a class."
2219 spec)
2233 class-name
2234 type))
2235 type))
2260 :initial-element
2266 quals
2267 specls))))))))
2269 \f
2274 parameters))
2280 lambda-list))
2286 specializers))
2292 required-parameters))
2295 ;;(declare (values parameters lambda-list specializers required-parameters))
2302 ;; Now, since we try to conform to ANSI, non-standard
2303 ;; lambda-list-keywords should be treated as errors.
2306 in arglist.~%"
2308 ;; When we are at a lambda-list keyword, the parameters
2309 ;; don't include the lambda-list keyword; the lambda-list
2310 ;; does include the lambda-list keyword; and no
2311 ;; specializers are allowed to follow the lambda-list
2312 ;; keywords (at least for now).
2316 ;; check, if &rest is followed by a var ...
2320 After &REST, a DEFMETHOD lambda-list ~
2324 ()
2325 ())))
2327 ;; After a lambda-list keyword there can be no specializers.
2332 ()
2333 ())))
2341 \f
2343 \f
2344 ;;; FIXME: In here there was a #-CMU definition of SYMBOL-MACROLET
2345 ;;; which used %WALKER stuff. That suggests to me that maybe the code
2346 ;;; walker stuff was only used for implementing stuff like that; maybe
2347 ;;; it's not needed any more? Hunt down what it was used for and see.
2355 instance)))
2358 ,in
2362 slot-entry
2366 slot-entry
2368 `(,var-name
2370 slots)
2379 instance)))
2382 ,in
2387 slots)