From Owners-CommonLoops.pa@Xerox.COM Tue Dec 20 09:31:25 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA17965; Tue, 20 Dec 88 09:31:25 PST Received: from Salvador.ms by ArpaGateway.ms ; 20 DEC 88 09:29:34 PST Return-Path: Redistributed: CommonLoops.pa Received: from WILMA.BBN.COM ([128.89.1.216]) by Xerox.COM ; 20 DEC 88 08:58:03 PST To: CommonLoops.pa@Xerox.COM Cc: kanderson@WILMA.BBN.COM Subject: real-add-method in KCL Date: Tue, 20 Dec 88 11:53:50 -0500 From: kanderso@WILMA.BBN.COM Message-Id: <881220-092934-4999@Xerox> I'm having some trouble in KCL: PCL>*pcl-system-date* "12/7/88 Can't think of a cute name PCL" PCL>(defmethod foo :after (x) (print x)) Error: Can't hack qualifiers in early methods. Error signalled by REAL-ADD-NAMED-METHOD. Broken at ADD-METHOD. Type :H for Help. PCL>>:b Backtrace: > eval > progn > eval-when > progn > progn > progn > load-defmethod > real-add-named-method > ADD-METHOD This is very confusing. It looks like early methods didn't get fixed up right. However, I'd expect this message from early-add-named-method, not from inside add-method, and i'd expect the generic function add-method to actually call real-add-method. I have added the turbo-closure patch. If i screwed up, could that cause such problems? What is a turbo-closure anyway? k From Gregor.pa@Xerox.COM Tue Dec 20 11:21:51 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA19242; Tue, 20 Dec 88 11:21:51 PST Received: from Semillon.ms by ArpaGateway.ms ; 20 DEC 88 11:12:32 PST Date: Tue, 20 Dec 88 11:08 PST From: Gregor.pa@Xerox.COM Subject: Re: real-add-method in KCL To: kanderso@WILMA.BBN.COM Cc: CommonLoops.pa@Xerox.COM, kanderson@WILMA.BBN.COM Fcc: BD:>Gregor>mail>outgoing-mail-4.text.newest In-Reply-To: The message of 20 Dec 88 08:53 PST from kanderso@WILMA.BBN.COM Message-Id: <19881220190828.8.GREGOR@PORTNOY.parc.xerox.com> Line-Fold: no Date: Tue, 20 Dec 88 11:53:50 -0500 From: kanderso@WILMA.BBN.COM I'm having some trouble in KCL: What KCL are you using? Does this happen when you don't have the turbo closure patch installed? P.S. I don't know what turbo closures are. Presumably they need to be serviced more often, and cost more each time they are serviced. ------- From Owners-commonloops.pa@Xerox.COM Tue Dec 20 13:35:26 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA20605; Tue, 20 Dec 88 13:35:26 PST Received: from Chardonnay.ms by ArpaGateway.ms ; 20 DEC 88 13:24:09 PST Return-Path: Redistributed: commonloops.pa Received: from NSS.Cs.Ucl.AC.UK ([128.41.9.3]) by Xerox.COM ; 20 DEC 88 13:02:19 PST Received: from ai.leeds.ac.uk by NSS.Cs.Ucl.AC.UK via Janet with NIFTP id aa07766; 20 Dec 88 20:22 GMT From: Andrew J Cole Date: Tue, 20 Dec 88 20:39:30 GMT Message-Id: <10963.8812202039@ai.leeds.ac.uk> To: commonloops.pa@Xerox.COM, sokolov@a-boy.media.mit.edu Subject: Re: Lucid compiler barfs The problem with Lucid which Michael Sokolov pointed out previously (see below) is still present for the 12/7/88 version (at least for Sun Common Lisp, Development Environment 2.1.1, 10-Aug-88). The fix still works. Cheers, Andrew ------ >Date: Mon, 22 Aug 88 20:30:05 EDT >From: Michael Sokolov >Message-Id: <8808230030.AB01482@a-boy> > For some strange reason, the Lucid compiler goes into an >infinite loop when trying to compile the function "describe-instance" >in high.lisp of 8/28/88 AAAI PCL. While tail merging, It complains >about the argument list to describe-slot: >> ;;; Compiling function DESCRIBE-INSTANCE...tail merging... >;;; Warning: Malformed optional argument (ALLOCATION (QUOTE NIL) >ALLOC-P ALLOC-P ALLOC-P ALLOC-P ALLOC-P ... (etc) >This seems like a compiler bug to me, but this seems to patch over the >rough spots: >(The key here is to make alloc-p an explicit keyword argument and >bypass whatever weirdness is happening as a result of the supplied-p >parameter. I don't claim to understand it.) From Gregor.pa@Xerox.COM Tue Dec 20 17:53:27 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA22371; Tue, 20 Dec 88 17:53:27 PST Received: from Cabernet.ms by ArpaGateway.ms ; 20 DEC 88 17:51:37 PST Date: Tue, 20 Dec 88 17:49 PST From: Gregor.pa@Xerox.COM Subject: Re: CLOS lambda-list congruence To: David N Gray Cc: Patrick Dussud , kempf@Sun.COM, Moon@STONY-BROOK.SCRC.Symbolics.COM, CLOS@DSG.csc.ti.com, CommonLoops.pa@Xerox.COM Fcc: BD:>Gregor>mail>outgoing-mail-4.text.newest In-Reply-To: <2807630738-542526@Kelvin> Message-Id: <19881221014903.8.GREGOR@PORTNOY.parc.xerox.com> Line-Fold: no Date: Tue, 20 Dec 88 11:25:38 CST From: David N Gray I should have commented on this sooner, sorry for the delay. Note that this message is cc'd to the CommonLoops list since it will be of interest to the people there. > > If you want to preserve the old semantics, and alternative > > is to implement your own generic function type using the > > metaobject protocol, which relaxes the restriction on lambda > > list congruence. > > Looking at document 88-003, I can't find any provision for being > able to do that. Is that a new feature in the forthcoming draft? > Do you mean write your own ADD-METHOD method? There aren't enough lower level primitives defined to be able to do that in a portable way, and if you need to modify internals of the implementation, then what is the point of a standard metaclass protocol? I think there must be something seriously wrong here somewhere if everyone believes that it is possible and reasonable to use the metaclass protocol to relax the congruence rules, but nobody can explain how to do it. Let me start by making to important points about the metaobject protocol. I will then present a solution to your particular problem. The first, and most important point, is that you shouldn't look to the metaobject protocol to provide special purpose "hooks" for customizing particular aspects of the CLOS behavior. In the case of your problem, there is an easy solution, but no canned hook. The second point is that any particular capability in the metaobject protocol always costs. It makes that part of the protocol more complex, and can make other parts more complex as well. In addition, anytime part of the CLOS behavior is controlled by a protocol (rather than being hardwired), it complicates implementation. The current design is a balance between providing flexibility to the user without specifying a large and difficult to implement protocol. There is a way to solve your problem short of defining a completely new kind of generic function. The basic idea behind this solution is to transform the lambda list of each method of a generic function in a uniform way, so that the methods appear to be following a more relaxed congruence rule, but are still satisfying the rules required by the underlying CLOS. For each method function, the user supplied lambda list will be reduced to a most general common form using &rest. The body of the method function will then pull values out of the &rest argument into whatever &optional or &key arguments may have been supplied. This is done by defining a new generic function class. For any generic function of that class all methods will be of a corresponding new method class. The method functions for that generic function and method class will be automatically transformed to use reduced lambda lists. What follows is a sketch of an implementation. A real implementation would want to do more error checking and have fewer performance bogosities in it. I have checked this code, but I cannot test it completely since PCL does not yet implement the metaobject protocol specified in the most recent draft of the MOP. ;;; ;;; Given a lambda list with any &mumble args in it, replace it with ;;; &rest .rest.. This could use other reduction rules too depending ;;; on your needs. ;;; ;;; (a b c) ==> (A B C) ;;; (a b &optional c) ==> (A B &REST .REST.) ;;; (a b &key c) ==> (A B &REST .REST.) ;;; ;;; (defun reduce-ll (ll) (wbni)) ;;; ;;; If the lambda list has no &mumble keywords in it, this returns nil, ;;; otherwise it returns the tail of the lambda list starting with ;;; the first &mumble keyword. ;;; (defun ll-&mumble-part (ll) (member lambda-list-keywords ll :test #'(lambda (x y) (member y x)))) (defclass reduced-generic-function (standard-generic-function) () (:metaclass funcallable-standard-class)) (defmethod generic-function-default-method-class ((gf reduced-generic-function)) (find-class 'reduced-method)) (defclass reduced-method (standard-method) (unreduced-ll)) (defmethod shared-initialize ((method standard-method) &rest all-keys &key lambda-list) (setf (slot-value method 'unreduced-ll) lambda-list) (apply #'call-next-method method :lambda-list (reduce-ll lambda-list) all-keys)) ;;; ;;; This implementation ignores processing of declarations to be more ;;; clear. They aren't hard to add. ;;; (defmethod make-method-lambda ((gf standard-generic-function) (method reduced-method) lambda) (let ((&mumble (ll-&mumble-part (cadr lambda)))) (call-next-method gf method (if &mumble `(lambda ,(reduce-ll (cadr lambda)) (apply #'(lambda ,&mumble . ,(cddr lambda)) .REST.)) lambda)))) ------- From Owners-commonloops.pa@Xerox.COM Wed Dec 21 12:19:05 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA01828; Wed, 21 Dec 88 12:19:05 PST Received: from Chardonnay.ms by ArpaGateway.ms ; 21 DEC 88 11:27:46 PST Return-Path: Redistributed: commonloops.pa Received: from uunet.UU.NET ([192.12.141.129]) by Xerox.COM ; 21 DEC 88 11:21:27 PST Received: from steinmetz.UUCP by uunet.UU.NET (5.59/1.14) with UUCP id AA21247; Wed, 21 Dec 88 14:21:18 EST Received: from eraserhead.steinmetz.GE.COM (eraserhead.ARPA) by kbsvax.steinmetz (1.2/1.1x Steinmetz) id AA18481; Wed, 21 Dec 88 13:30:39 est Received: by eraserhead.steinmetz.GE.COM (4.0/SMI-4.0) id AA03022; Wed, 21 Dec 88 13:30:07 EST Date: Wed, 21 Dec 88 13:30:07 EST From: duff%eraserhead%steinmetz@uunet.UU.NET (David A Duff) Message-Id: <8812211830.AA03022@eraserhead.steinmetz.GE.COM> To: CommonLoops.pa@Xerox.COM Subject: chapter 3 Reply-To: duff@eraserhead.steinmetz.Ge.Com I'd like to know where can I get a copy of the current draft of chapter 3 of the CLOS spec (the one on the Meta-Object protocol). Thanks, Dave Duff GE Research and Development Center duff@eraserhead.steinmetz.ge.com Schenectady, New York uunet!steinmetz!eraserhead!duff 518-387-5649 From Owners-commonloops.pa@Xerox.COM Wed Dec 21 15:01:44 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA03347; Wed, 21 Dec 88 15:01:44 PST Received: from Chardonnay.ms by ArpaGateway.ms ; 21 DEC 88 14:54:20 PST Return-Path: Redistributed: commonloops.pa Received: from vaxa.isi.edu ([128.9.0.33]) by Xerox.COM ; 21 DEC 88 14:49:00 PST Posted-Date: Wed, 21 Dec 88 14:50:03 PST Message-Id: <8812212250.AA23779@vaxa.isi.edu> Received: from LOCALHOST by vaxa.isi.edu (5.59/5.51) id AA23779; Wed, 21 Dec 88 14:50:08 PST To: commonloops.pa@Xerox.COM From: goldman@vaxa.isi.edu Subject: PCL bug or CLOS spec issue? Cc: goldman@vaxa.isi.edu Date: Wed, 21 Dec 88 14:50:03 PST Sender: goldman@vaxa.isi.edu When I try to define a recursive method for (setf foo), and it is the FIRST method being defined for (setf foo), I get an error message from PCL's code walker, because the use of (setf foo) in the body is not (yet) acceptable. It seems to me that a self contained recursive method (even for (setf foo)) should not require any kind of "forward declaration' -- e.g., (ENSURE-GENERIC-FUNCTION '(setf foo) :lambda-list ...) -- that the lambda-list of the method should establish the lambda-list for the generic function (SETF FOO), and thus the generic function should be callable from within the method. In other words, I think the code below should be portable. Opinions? neil ---------------------------------------------------------------- (defclass xxx () ((slot1) (slot2) (delegate :reader delegate))) (defmethod foo ((x xxx)) (let ((d (delegate x))) (if d (foo d) (+ (slot-value x 'slot1) (slot-value x 'slot2))))) (defmethod (setf foo) (new (x xxx)) (let ((d (delegate x))) (if d (setf (foo d) new) (setf (slot-value x 'slot1) new (slot-value x 'slot2) 0)))) From Gregor.pa@Xerox.COM Wed Dec 21 16:27:24 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA04702; Wed, 21 Dec 88 16:27:24 PST Received: from Salvador.ms by ArpaGateway.ms ; 21 DEC 88 16:22:44 PST Date: Wed, 21 Dec 88 16:18 PST From: Gregor.pa@Xerox.COM Subject: Re: PCL bug or CLOS spec issue? To: goldman@vaxa.isi.edu Cc: commonloops.pa@Xerox.COM Fcc: BD:>Gregor>mail>outgoing-mail-4.text.newest In-Reply-To: <8812212250.AA23779@vaxa.isi.edu> Message-Id: <19881222001832.8.GREGOR@PORTNOY.parc.xerox.com> Line-Fold: no Date: Wed, 21 Dec 88 14:50:03 PST From: goldman@vaxa.isi.edu When I try to define a recursive method for (setf foo), and it is the FIRST method being defined for (setf foo), I get an error message from PCL's code walker, because the use of (setf foo) in the body is not (yet) acceptable. Resolving this kind of problem is exactly what the cleanup proposal setf function is all about. By assigning a default behavior to setf, it resolves any problems having to do with trying to expand a setf before it is defined. Currently, PCL uses a hack to pretend that the required underlying change to setf has been made, your example is tickling a bug in that hack. The following patch should solve your problem: ;from boot.lisp (defun expand-defmethod-internal (generic-function-name qualifiers specialized-lambda-list body env) (declare (values fn-form specializers doc) (ignore qualifiers)) (when (listp generic-function-name) (do-standard-defsetf-1 (cadr generic-function-name))) (multiple-value-bind (documentation declarations real-body) (extract-declarations body) (multiple-value-bind (parameters lambda-list specializers) (parse-specialized-lambda-list specialized-lambda-list) (let* ((required-parameters (mapcar #'(lambda (r s) (declare (ignore s)) r) parameters specializers)) (parameters-to-reference (make-parameter-references specialized-lambda-list required-parameters declarations generic-function-name specializers)) (class-declarations `(declare ,@(remove nil (mapcar #'(lambda (a s) (and (symbolp s) (neq s 't) `(class ,a ,s))) parameters specializers)))) (method-lambda ;; Remove the documentation string and insert the ;; appropriate class declarations. The documentation ;; string is removed to make it easy for us to insert ;; new declarations later, they will just go after the ;; cadr of the method lambda. The class declarations ;; are inserted to communicate the class of the method's ;; arguments to the code walk. (let () `(lambda ,lambda-list ,class-declarations ,@declarations (progn ,@parameters-to-reference) (block ,(if (listp generic-function-name) (cadr generic-function-name) generic-function-name) ,@real-body)))) (call-next-method-p nil) ;flag indicating that call-next-method ;should be in the method definition (next-method-p-p nil) ;flag indicating that next-method-p ;should be in the method definition (save-original-args nil) ;flag indicating whether or not the ;original arguments to the method ;must be preserved. This happens ;for two reasons: ; - the method takes &mumble args, ; so one of the lexical functions ; might be used in a default value ; form ; - call-next-method is used without ; arguments at least once in the ; body of the method (original-args ()) (applyp nil) ;flag indicating whether or not the ;method takes &mumble arguments. If ;it does, it means call-next-method ;without arguments must be APPLY'd ;to original-args. If this gets set ;true, save-original-args is set so ;as well (aux-bindings ()) ;Suffice to say that &aux is one of ;damndest things to have put in a ;language. (slots (mapcar #'list required-parameters)) (plist ()) (walked-lambda nil)) (flet ((walk-function (form context env) (cond ((not (eq context ':eval)) form) ((not (listp form)) form) ((eq (car form) 'call-next-method) (setq call-next-method-p 't) (setq save-original-args (not (cdr form))) form) ((eq (car form) 'next-method-p) (setq next-method-p-p 't) form) ((and (eq (car form) 'function) (cond ((eq (cadr form) 'call-next-method) (setq call-next-method-p 't) (setq save-original-args 't) form) ((eq (cadr form) 'next-method-p) (setq next-method-p-p 't) form) (t nil)))) ((and (or (eq (car form) 'slot-value) (eq (car form) 'set-slot-value)) (symbolp (cadr form)) (constantp (caddr form))) (multiple-value-bind (parameter class) (can-optimize-access (cadr form) env) (if parameter (ecase (car form) (slot-value (optimize-slot-value class form)) (set-slot-value (optimize-set-slot-value class form))) form))) ((eq (car form) 'standard-instance-access) (multiple-value-bind (parameter class) (can-optimize-access (cadr form) env) (if parameter (optimize-standard-instance-access class parameter form slots) form))) (t form)))) (setq walked-lambda (walk-form method-lambda env #'walk-function)) ;; ;; Add &allow-other-keys to the lambda list as an interim ;; way of implementing lambda list congruence rules. ;; (when (and (memq '&key lambda-list) (not (memq '&allow-other-keys lambda-list))) (let* ((rll (reverse lambda-list)) (aux (memq '&aux rll))) (setq lambda-list (if aux (progn (setf (cdr aux) (cons '&allow-other-keys (cdr aux))) (nreverse rll)) (nconc (nreverse rll) (list '&allow-other-keys)))))) ;; Scan the lambda list to determine whether this method ;; takes &mumble arguments. If it does, we set applyp and ;; save-original-args true. ;; ;; This is also the place where we construct the original ;; arguments lambda list if there has to be one. (dolist (p lambda-list) (if (memq p lambda-list-keywords) (if (eq p '&aux) (progn (setq aux-bindings (cdr (memq '&aux lambda-list))) (return nil)) (progn (setq applyp t save-original-args t) (push '&rest original-args) (push (make-symbol "AMPERSAND-ARGS") original-args) (return nil))) (push (make-symbol (symbol-name p)) original-args))) (setq original-args (if save-original-args (nreverse original-args) ())) (multiple-value-bind (ignore walked-declarations walked-lambda-body) (extract-declarations (cddr walked-lambda)) (declare (ignore ignore)) (when (some #'cdr slots) (setq slots (sort-slots-into-isl slots)) (setq plist (list* :isl slots plist)) (setq walked-lambda-body (add-pv-binding walked-lambda-body plist required-parameters specializers))) (when (or next-method-p-p call-next-method-p) (setq plist (list* :needs-next-methods-p 't plist))) (values `(function ,(if (or call-next-method-p next-method-p-p) (add-lexical-functions-to-method-lambda walked-declarations walked-lambda-body `(lambda ,lambda-list ,@walked-declarations ,.walked-lambda-body) original-args lambda-list save-original-args applyp aux-bindings call-next-method-p next-method-p-p) `(lambda ,lambda-list ,@walked-declarations ,.walked-lambda-body))) specializers documentation plist))))))) ------- From Owners-commonloops.PA@Xerox.COM Wed Dec 21 21:05:33 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA08102; Wed, 21 Dec 88 21:05:33 PST Received: from Semillon.ms by ArpaGateway.ms ; 21 DEC 88 21:04:20 PST Return-Path: Redistributed: commonloops.PA Received: from ucsd.edu ([128.54.16.1]) by Xerox.COM ; 21 DEC 88 21:00:36 PST Received: from roland.ucsd.edu by ucsd.edu Wed, 21 Dec 88 21:00:47 PST; sendmail 5.60/UCSD-1.0, id AA14256 for commonloops@xerox.com Received: by roland.UCSD.EDU (3.2/UCSDPSEUDO.2) id AA00251 for delivery to commonloops@xerox.com; Wed, 21 Dec 88 21:00:42 PST Date: Wed, 21 Dec 88 21:00:42 PST From: rik%cs@ucsd.edu (Rik Belew) Message-Id: <8812220500.AA00251@roland.UCSD.EDU> To: commonloops.PA@Xerox.COM Subject: Installing PCL, on Coral and Lucid I'm hoping someone on this list can help me with a couple of stumbling blocks I've hit installing PCL, one on Coral's compiler and one on Lucid's Sun Common Lisp compiler. The Coral bug is: Welcome to Allegro CL Version 1.1! ? ;Loading "Internal:Common Lisp:PCL:defsys.lisp"... ? (pcl::compile-pcl :recompile-some) Loading binary of PKG... Loading binary of WALK... Loading binary of ITERATE... Loading binary of MACROS... Loading binary of LOW... Loading binary of CORAL-LOW... > Warning: FUNCTION OBJECT-CACHE-NO originally defined in: (CCL;low.lisp) is now being redefined in: CCL;coral-low.lisp > While executing: CCL::RECORD-SOURCE-FILE > Warning: FUNCTION PRINTING-RANDOM-THING-INTERNAL originally defined in: (CCL; macros.lisp) is now being redefined in: CCL;coral-low.lisp > While executing: CCL::RECORD-SOURCE-FILE > Warning: FUNCTION SET-FUNCTION-NAME-1 originally defined in: (CCL;low.lisp) is now being redefined in: CCL;coral-low.lisp > While executing: CCL::RECORD-SOURCE-FILE Loading binary of FIN... Loading binary of DEFS... Loading binary of BOOT... Loading binary of VECTOR... Loading binary of SLOTS... Loading binary of MKI... Loading binary of INIT... Loading binary of DEFCLASS... Compiling STD-CLASS... > Error: Array index -45 out of bounds for #(NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL N IL NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL) . > While executing: # > Type Command-/ to continue, Command-. to abort. 1 > Aborted. ? And on the Sun, with Lucid: > (load "pcl/defsys.lisp") #P"pcl/defsys.lisp" > (pcl::compile-pcl :recompile-some) Loading binary of PKG... Loading binary of WALK... Loading binary of ITERATE... Loading binary of MACROS... Loading binary of LOW... Loading binary of LUCID-LOW... ;;; Warning: Redefining %LOGAND ;;; Warning: Redefining %ASH ;;; Warning: Redefining MAKE-MEMORY-BLOCK ;;; Warning: Redefining OBJECT-CACHE-NO ;;; Warning: Redefining SET-FUNCTION-NAME-1 >>Error: # should be a function. ARGLIST: Required arg 0 (X): # :A Abort to Lisp Top Level :C Supply a function. -> Has anyone bumped into either of these problems? Thanks for any help you can provide. Richard K. Belew rik%cs@ucsd.edu Assistant Professor CSE Department (C-014) UCSD San Diego, CA 92093 619 / 534-2601 or 534-5948 (messages) From Gregor.pa@Xerox.COM Thu Dec 22 11:08:41 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA18158; Thu, 22 Dec 88 11:08:41 PST Received: from Semillon.ms by ArpaGateway.ms ; 22 DEC 88 10:59:51 PST Date: Thu, 22 Dec 88 10:56 PST From: Gregor.pa@Xerox.COM Subject: Re: Installing PCL, on Coral and Lucid To: Rik Belew Cc: commonloops.PA@Xerox.COM Fcc: BD:>Gregor>mail>outgoing-mail-4.text.newest In-Reply-To: <8812220500.AA00251@roland.UCSD.EDU> Message-Id: <19881222185638.5.GREGOR@PORTNOY.parc.xerox.com> Line-Fold: no Date: Wed, 21 Dec 88 21:00:42 PST From: rik%cs@ucsd.edu (Rik Belew) I'm hoping someone on this list can help me with a couple of stumbling blocks I've hit installing PCL, one on Coral's compiler and one on Lucid's Sun Common Lisp compiler. The Coral bug is: Welcome to Allegro CL Version 1.1! You need to use a newer version of Coral Lisp. We use 1.2 here and the current version of PCL runs without problem in it. And on the Sun, with Lucid: You don't say which version of Lucid, or which version of PCL you are using, so it is hard for me to advise you. The version of pcl is the value of the variable *pcl-system-date*. This variable is defined in the defsys file. I vaguely remember the bug you are experiencing, but I haven't seen it in a long while. ------- From Owners-commonloops.pa@Xerox.COM Fri Dec 23 12:01:33 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA02474; Fri, 23 Dec 88 12:01:33 PST Received: from Cabernet.ms by ArpaGateway.ms ; 23 DEC 88 11:59:36 PST Return-Path: Redistributed: commonloops.pa Received: from hplabs.HP.COM ([15.255.16.7]) by Xerox.COM ; 23 DEC 88 11:57:43 PST Received: from hpldew.HP.COM (hpldew) by hplabs.HP.COM with SMTP ; Fri, 23 Dec 88 11:58:04 PST Received: from hpldew by hpldew.HP.COM; Fri, 23 Dec 88 11:57:23 pst Return-Path: Message-Id: <8812231957.AA13792@hpldew.HP.COM> To: commonloops.pa@Xerox.COM Subject: Finding "Non-applicable" Methods Date: Fri, 23 Dec 88 11:57:20 PST From: David E. Wallace The CLOS Spec in Chapters 1 & 2 offers a way to find all applicable methods for a given set of arguments, but it doesn't seem to provide any way to determine what methods might be applicable to a different set of arguments. What I would like to see is (1): a way to get all currently defined methods on a particular generic function, and (2): a way to determine, given a method object, what set of arguments would select it. Is there a portable way to do this with the spec as it now stands? If not, is it still possible to submit something like this as a cleanup proposal? Applications would include: (1): Debugging (the obvious one) (2): A coercion planner. Given a multi-method coerce-meth that takes an object and a type to coerce it to, define a default case that will try to plan a multi-step strategy to coerce the object to a type based on all currently defined coercions (if I want to coerce an A to a D, and have methods defined to coerce an A to a B, a B to a C, and a C to a D, this would be an acceptable strategy). (3): A DWIM-like fixup method when no-applicable-method arises (determine what methods do exist, and query the user about using methods that are "close" to the actual arguments supplied). Comments? Dave Wallace From Common-Lisp-Object-System-mailer@SAIL.STANFORD.EDU Wed Dec 28 16:59:52 1988 Received: from [36.86.0.194] by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA06636; Wed, 28 Dec 88 16:59:52 PST Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 28 Dec 88 16:58:42 PST Received: from hplabs.HP.COM by SCORE.STANFORD.EDU with TCP; Wed 28 Dec 88 16:57:45-PST Received: from hpldew.HP.COM ([15.255.32.26]) by hplabs.HP.COM with SMTP ; Wed, 28 Dec 88 16:58:05 PST Received: from hpldew by hpldew.HP.COM; Wed, 28 Dec 88 16:57:12 pst Return-Path: Message-Id: <8812290057.AA15755@hpldew.HP.COM> To: Common-Lisp-Object-System@SAIL.STANFORD.EDU Subject: Suggestion Sent to CommonLoops List Date: Wed, 28 Dec 88 16:57:10 PST From: David E. Wallace Last week I sent a design suggestion about being able to find "non-applicable" methods to the CommonLoops list, since I couldn't find the name of this list. I assume that everyone on this list also reads the CommonLoops list and so has seen my note - if this isn't true, let me know and I'll repost it. Dave Wallace From Common-Lisp-Object-System-mailer@SAIL.STANFORD.EDU Thu Dec 29 05:00:04 1988 Received: from Sail.Stanford.EDU by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA14292; Thu, 29 Dec 88 05:00:04 PST Received: from lucid.com by SAIL.Stanford.EDU with TCP; 29 Dec 88 04:54:06 PST Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA00911g; Thu, 29 Dec 88 04:50:36 PST Received: by bhopal id AA10083g; Thu, 29 Dec 88 04:52:47 PST Date: Thu, 29 Dec 88 04:52:47 PST From: Jon L White Message-Id: <8812291252.AA10083@bhopal> To: Common-Lisp-Object-System@SAIL.STANFORD.EDU Cc: CL-Compiler@SAIL.STANFORD.EDU Subject: Compilation implications This somewhat long msg has questions aobut two issues in it: (A) "Reconstructor" functions for instances (B) References to classes "by name" Partly I would like an answer to them to aid in development at Lucid, and partly to help resolve lingering issues in the CL-Compiler's work on quoted constants. (A) "Reconstructor" functions for instances We at Lucid are getting more and more requests for a coherent "Reconstructor" protocol (well, they are usually couched in ill-advised terms about making FASLOUT user-extensible, but we've already seen this issue before). Does anyone have any plans to work on this problem? Didn't someone recently say that Symbolics has some possibly-private Reconstructor capability? What is the feeling about the Symbolics facility (I don't know anything about it). One might ask, "How do ``instances'' come to the attention of FASLOUT?" They can appear as a quoted constant; hence, Cris Perdue's query: Date: Mon, 14 Nov 88 11:54:29 PST From: cperdue@Sun.COM (Cris Perdue) To: cl-object-oriented-programming@sail.stanford.edu Subject: Standard-objects in quoted constants to which Moon replied later that day about the need for a reconstructor protocol. I should think it rare for quoted instances to appear directly in code files. But there are some important exceptions that, indirectly, introduce "constants" into a file; for example, the use of #. to emulate a FASDMP facility; and also macro-generated code that produces otherwise unREADable forms. If the semantics of DEFCONSTANT were more "hard-wired", then it too would be such an exception. ["hard-wired" means that the value at run time is that obtained by evaluating the defconstant form at compile time, rather than by evaluating the form at load time; it would mean that (defconstant foo (bar)) is similar to (defconstant foo (quote #.(bar))).] Possibly, EQL specializers could raise this question. Upon re-reading, the language of 88-002R now seems a bit vague to me, and possibly open to misinterpretation, as to just when an EQL parameter specializer form is evaluated. Consider the similarity with DEFCONSTANT. The language in CLtL about DEFCONSTANT seems to imply, to most people, that the runtime environment ought to have a special variable that holds the "constant" value (references to which are allowed to be "snapped" in compiled code); and that the value of this variable is set at load time, when the defining form's "form" is evaluated, just like it would be for defparameter. [Hence DEFCONSTANT doesn't define a compile-time constant in the same way that conventional language compilers do.] The various implementations I've looked at so far seem to do it this way -- they do an evaluation at load time (typically, by executing a "thunk") to produce the constant's value. The language of 88-002R doesn't seem to rule out either way of obtaining the "object"-- producing a thunk or producing a compile-time constant. The only relevant difference is that it prescribed the evaluation to be done in the lexical environment of the defining form, which for COMPILE-FILE simply means that the "thunk" is compiled in that lexical environment. But has anyone wanted the more "hardwired" version? (B) References to classes "by name" The analogy between FIND-PACKAGE and FIND-CLASS suggests that class objects are in the same "database" category as packages. Shouldn't they be referenced "by name" in compiled file? Lucid has been fasl'ing out packages for some time merely "by reference"; the culmination of the CL-Compiler's deliberations on "quoted constants in compiled files" seems to be that this is the only reasonable meaning for reference to a "quoted package". Are there any other implementations that do otherwise for "quoted" classes? I realize this may pose some ordering constraints on the executions in a file, if the compiled version is to operate correctly -- i.e., classes might have to be defined before the use of any constant that "names" that class. Such constraints may not be as feasible as they are in the package world (Indeed, some folks even dislike the package ordering constraints!). Can a forward-reference, "placeholder" be substituted for a class that hasn't yet been defined, but is referenced by a quoted constant? -- JonL -- From Common-Lisp-Object-System-mailer@SAIL.STANFORD.EDU Thu Dec 29 10:01:35 1988 Received: from Sail.Stanford.EDU by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA16073; Thu, 29 Dec 88 10:01:35 PST Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 29 Dec 88 10:01:43 PST Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 513111; Thu 29-Dec-88 12:59:40 EST Date: Thu, 29 Dec 88 12:59 EST From: David A. Moon Subject: Compilation implications To: Jon L White Cc: Common-Lisp-Object-System@SAIL.STANFORD.EDU, CL-Compiler@SAIL.STANFORD.EDU In-Reply-To: <8812291252.AA10083@bhopal> Message-Id: <19881229175913.8.MOON@EUPHRATES.SCRC.Symbolics.COM> [Responding to only one portion of your message] Date: Thu, 29 Dec 88 04:52:47 PST From: Jon L White (A) "Reconstructor" functions for instances We at Lucid are getting more and more requests for a coherent "Reconstructor" protocol (well, they are usually couched in ill-advised terms about making FASLOUT user-extensible, but we've already seen this issue before). Does anyone have any plans to work on this problem? Didn't someone recently say that Symbolics has some possibly-private Reconstructor capability? What is the feeling about the Symbolics facility (I don't know anything about it). It's very simple and effective. There is a generic function (never mind its name, the current stupid name was chosen about a dozen years ago) that is applied to one argument and returns a Lisp form. The intent is that when that form is evaluated at some later time, it should return an object that is equivalent to the argument. Using EVAL provides full generality. Of course the compiler/fasdumper/fasloader is allowed to optimize special-case forms that it recognizes, rather than always calling EVAL at load time. This generic function is supported for standard-object and structure-object (using CLOS terminology). A good name would be MAKE-RECONSTRUCTION-FORM or perhaps MAKE-LOAD-FORM (why introduce a new word "reconstruct" when we already have the word "load" which really means the same thing?). In addition, there is a level of protocol built on top of this that some things use. There is a mixin flavor that provides a method for the first generic function; it returns a form that calls MAKE-INSTANCE with (TYPE-OF SELF) as the first argument, and the remaining arguments obtained by calling another generic function whose methods' results are usually combined with APPEND. This provides a convenient way for multiple classes to contribute to the reconstruction of an object; each class supplies the initargs that are relevant to that class. I'd suggest MAKE-LOAD-INITARGS for the name of this generic function and LOAD-USING-INITARGS-MIXIN for the name of the class. I haven't put a great deal of thought into these names. There is also a method that uses the simple-minded reconstruction technique of just looking at the slots that have :INITARGs and calling MAKE-INSTANCE with the reconstructed values of those slots. An important thing to realize is that the default for a standard-object is to signal an error; there is no default method on standard-object for either of these generic functions. That's important because no default reconstruction method can be correct for all objects, and we feel it's better to make the programmer pick a method explicitly than to supply a default that might just make trouble. I don't remember why the CLOS committee didn't put anything like this into the proposed standard. Maybe we thought it was the Compiler committee's business, maybe we had some disagreement, or maybe we just ran out of time. One might ask, "How do ``instances'' come to the attention of FASLOUT?" They can appear as a quoted constant; hence, Cris Perdue's query: Date: Mon, 14 Nov 88 11:54:29 PST From: cperdue@Sun.COM (Cris Perdue) To: cl-object-oriented-programming@sail.stanford.edu Subject: Standard-objects in quoted constants to which Moon replied later that day about the need for a reconstructor protocol. I should think it rare for quoted instances to appear directly in code files. But there are some important exceptions that, indirectly, introduce "constants" into a file; for example, the use of #. to emulate a FASDMP facility; and also macro-generated code that produces otherwise unREADable forms. Rare, but not unheard of. Note also two other common sources of non-built-in type objects in compiled-code files: 1. Any type that has a read syntax is likely to appear as a quoted constant or inside a quoted constant. Pathnames are one example, user programs often define others. 2. Symbolics has a facility for creating a compiled-code file full of data (rather than compiled Lisp programs), which is convenient because it's an efficient binary file that you can load with LOAD instead of having to write your own loader. (This can be simulated in any Common Lisp implementation by creating a dummy file that consists of just one call to a special macro, defining the macro to expand into forms to put the data where you want it, then using COMPILE-FILE on that dummy file). Most of the rest of your message concerns the metaobject protocol and I can't answer it. I'll just note that in Flavors we generate metaobjects at compile time, but we never put them (to speak loosely) into the compiled-code file; instead macros like DEFFLAVOR and DEFMETHOD expand into Lisp code that obtains new metaobjects at load time, based on the class name and generic function name. I don't see how any other way could work, actually, since two distinct compiled files that refer to a class by the same name must end up referring to the same metaobject after loading. In Flavors we don't have anonymous classes nor anonymous generic functions, so we don't have to solve those issues. From CL-Compiler-mailer@SAIL.STANFORD.EDU Fri Dec 30 04:03:50 1988 Received: from Sail.Stanford.EDU by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA24029; Fri, 30 Dec 88 04:03:50 PST Received: from lucid.com by SAIL.Stanford.EDU with TCP; 30 Dec 88 03:48:39 PST Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA01516g; Fri, 30 Dec 88 03:44:28 PST Received: by bhopal id AA13748g; Fri, 30 Dec 88 03:46:40 PST Date: Fri, 30 Dec 88 03:46:40 PST From: Jon L White Message-Id: <8812301146.AA13748@bhopal> To: Moon@STONY-BROOK.SCRC.Symbolics.COM Cc: Common-Lisp-Object-System@SAIL.STANFORD.EDU, CL-Compiler@SAIL.STANFORD.EDU In-Reply-To: David A. Moon's message of Thu, 29 Dec 88 12:59 EST <19881229175913.8.MOON@EUPHRATES.SCRC.Symbolics.COM> Subject: Compilation implications Thanks for your many comments, Dave. I'm sure they will be useful. re: ["Reconstructor" forms and mixins] I don't remember why the CLOS committee didn't put anything like this into the proposed standard. Maybe we thought it was the Compiler committee's business, maybe we had some disagreement, or maybe we just ran out of time. There is a blend of problems here -- partly object-oriented and partly semantics of compilation. It could be that the buck is getting shuffled back and forth and nothing being done. Maybe the time just wasn't ripe for specifying this protocol -- maybe more experience is needed -- but sooner or later the user-community will be "push coming to shove" and the lack of a portable interface could be damaging. re: [fasling out classes "by name"] I don't see how any other way could work, actually, since two distinct compiled files that refer to a class by the same name must end up referring to the same metaobject after loading. Right. Separate compilation seems to be the clinching argument. -- JonL -- From CL-Compiler-mailer@SAIL.STANFORD.EDU Fri Dec 30 11:32:21 1988 Received: from Sail.Stanford.EDU by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA26228; Fri, 30 Dec 88 11:32:21 PST Received: from Sun.COM by SAIL.Stanford.EDU with TCP; 30 Dec 88 11:28:17 PST Received: from snail.Sun.COM by Sun.COM (4.1/SMI-4.0) id AA17613; Fri, 30 Dec 88 11:30:11 PST Received: from suntana.sun.com by snail.Sun.COM (4.1/SMI-4.0) id AA28437; Fri, 30 Dec 88 11:26:52 PST Received: from localhost by suntana.sun.com (4.0/SMI-4.0) id AA09230; Fri, 30 Dec 88 11:27:29 PST Message-Id: <8812301927.AA09230@suntana.sun.com> To: Jon L White Cc: Common-Lisp-Object-System@SAIL.STANFORD.EDU, CL-Compiler@SAIL.STANFORD.EDU, cperdue%suntana@Sun.COM Subject: Re: Compilation implications In-Reply-To: Your message of Thu, 29 Dec 88 04:52:47 -0800. <8812291252.AA10083@bhopal> Date: Fri, 30 Dec 88 11:27:27 PST From: kempf@Sun.COM A couple comments on the original and Moon's followup. 1) I proposed as a strawman awhile back that a read macro be introduced similar to #S for DEFSTRUCTSs so that CLOS objects could be stored in readable ASCII form and also so that they could be made persistent. There was some discussion on the issue but it eventually died out without a proposal. 2) I think Moon's solution of a constructor form which gets executed using EVAL at load time is the only possible solution to this problem. In particular, the semantics of quoted constants implied by CLtL is that only symbols can be expected to be EQ across a FASDUMP, and only characters and numbers can additionally be expected to be EQL. This has interesting implications for EQL specializers. Since the only objects which can be expected to survive a FASDUMP and remain EQL are symbols, numbers, and characters, these are the only objects which make sense to have in a DEFMETHOD form with an EQL specialized parameter. This makes it important that machinery be available to add methods to a generic function through a functional interface, since some of the things one wants to do with EQL methods require other objects. Part of that machinery is already in Chapter 2 (ADD-METHOD, MAKE-INSTANCE) but part of it is not (how to make a method function, for example). 3) With regard to using name equivalence for classes across FASDUMP, again, I largely agree with Moon on this issue, however I'll take the liberty of extending his comment somewhat, since I think that slot structure needs to be taken into account. The problem is basically one of how to handle class or type equivalence of two CLOS objects in FASL files. When the two objects are FASLed back in, when will their classes be the same? Because of the restrictions on EQ and EQL, the class objects, themselves, cannot be FASLed out because they are not guaranteed to be EQL when FASLed back in. This solution is impractical in any case, since it implies FASLing out the entire metaobject structure at compile time just to save a single object. Also, name equivalence only (i.e. the names of the classes are the same) may not be sufficient, because the number and names of slots might be changed, and, in order to FASL the object in, there must be at least as many slots as their were when it was FASLed out. Having the same slot names is probably also necessary, since it allows a logical mapping between the slot contents in the FASL file and the object in memory, as well as the physical constraint of having enough slots to handle the slot contents. Note that, again, EQLness of slot descriptor objects, or any other solution not involving symbols won't work. Requiring the same class precedence list, or that the inheritance of slots match strikes me as too restrictive, though I could see arguments why it would be desirable. Alternatively, the class redefinition protocol could be put to good use to allow the object to redefine its class if the number and names of slots didn't match. In that case, name equivalence of classes is the only requirement. Note that this solution handles anonymous classes fine, but not instances of anonymous classes. In particular, two instances of the same anonymous class which are FASLed out then in cannot ever have a class object which is EQ or EQL, since the FASL in code will create two separate instances of the anonymous class. The only way around this problem is to either change the semantics of EQ and EQL for CLOS objects or to treat CLOS classes separately during FASDUMP. Using class and slot name equivalence or just class name equivalence with the redefinition protocol coming into play when there is a mismatch between the slot structures seems like an easier solution. jak From CL-Compiler-mailer@SAIL.STANFORD.EDU Fri Dec 30 20:14:00 1988 Received: from Sail.Stanford.EDU by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA01881; Fri, 30 Dec 88 20:14:00 PST Received: from lucid.com by SAIL.Stanford.EDU with TCP; 30 Dec 88 20:08:34 PST Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA02064g; Fri, 30 Dec 88 20:05:01 PST Received: by bhopal id AA16126g; Fri, 30 Dec 88 20:07:12 PST Date: Fri, 30 Dec 88 20:07:12 PST From: Jon L White Message-Id: <8812310407.AA16126@bhopal> To: kempf@Sun.COM Cc: Common-Lisp-Object-System@SAIL.STANFORD.EDU, CL-Compiler@SAIL.STANFORD.EDU, cperdue%suntana@Sun.COM In-Reply-To: kempf@Sun.COM's message of Fri, 30 Dec 88 11:27:27 PST <8812301927.AA09230@suntana.sun.com> Subject: Compilation implications I'll address only the comments you have under item (3). re: name equivalence only (i.e. the names of the classes are the same) may not be sufficient, because the number and names of slots might be changed, and, in order to FASL the object in, there must be at least as many slots as their were when it was FASLed out. Having the same slot names is probably also necessary, since it allows a logical mapping between the slot contents in the FASL file and the object in memory, as well as the physical constraint of having enough slots to handle the slot contents. Well, at load time you could just assuming that a compile-time reference to a class named FOO is not inconsistent with the class named FOO existing at load time. [I was more worried about forward references in the compiled file, that weren't "forward" when the compile-time environment was built -- happens e.g. when you load things out of order]. Part of what you are suggesting could be compared, by analogy, to the package case. Lucid currently only dumps the name reference; but you are saying for example that it could also dump the names of all "used" packages just as a consistency check. Unfortunately, I don't see how to evaluate the myriads of consistency checks that could conceivable be placed in a "dumped" class; would they be worth the effort? re: In particular, two instances of the same anonymous class which are FASLed out then in cannot ever have a class object which is EQ or EQL, since the FASL in code will create two separate instances of the anonymous class. This is not a problem in Lucid Common Lisp [by the bye, I'm assuming a single COMPILE-FILE -- I'm not talking about the problem of separate file compilations] LCL file-compilation arranges to preserve EQLness over the data objects in a single compile-file. At one time, some implementations didn't even preserve EQLness over uninternd gensyms (over a single compile-file); but PCL dependended so heavily on this working, that those implementations at least made that case work. -- JonL -- From Gregor.pa@Xerox.COM Sat Dec 31 20:01:31 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA03555; Sat, 31 Dec 88 20:01:31 PST Received: from Cabernet.ms by ArpaGateway.ms ; 31 DEC 88 14:44:52 PST Date: Wed, 28 Dec 88 13:35 PST From: Gregor.pa@Xerox.COM Subject: Re: Finding "Non-applicable" Methods To: David E. Wallace Cc: commonloops.pa@Xerox.COM Fcc: BD:>Gregor>mail>outgoing-mail-5.text.newest In-Reply-To: <8812231957.AA13792@hpldew.HP.COM> Message-Id: <19881228213504.0.GREGOR@PORTNOY.parc.xerox.com> Line-Fold: no Date: Fri, 23 Dec 88 11:57:20 PST From: David E. Wallace The CLOS Spec in Chapters 1 & 2 offers a way to find all applicable methods for a given set of arguments, but it doesn't seem to provide any way to determine what methods might be applicable to a different set of arguments. What I would like to see is (1): a way to get all currently defined methods on a particular generic function, and (2): a way to determine, given a method object, what set of arguments would select it. Is there a portable way to do this with the spec as it now stands? If not, is it still possible to submit something like this as a cleanup proposal? The functionality you are asking for is available with simple metaobject accessors defined in the metaobject protocol. Using these accessors, it is possible to find out about the methods of a generic function, and the class precedence list of classes. Given that information, you can write the particular functionality you are asking for. The accessors in question are: GENERIC-FUNCTION-METHODS (generic-function) [Generic Function] Given a generic function object, this returns a list of the methods on that generic function. The elements of this list are method objects. METHOD-SPECIALIZERS (method) [Generic Function] Given a method object, this returns a list of the method's specializers. The elements of this list are class objects, or lists of the form (EQL ). CLASS-PRECEDENCE-LIST (class) [Generic Function] Given a class, this returns the class precedence list of the class. The elements of this list are class objects. Each of these exist in the current PCL with the exception that method-specializers is currently called method-type-specifiers. ------- From CL-Cleanup-mailer@SAIL.STANFORD.EDU Mon Jan 2 13:36:16 1989 Received: from Sail.Stanford.EDU by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA18147; Mon, 2 Jan 89 13:36:16 PST Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 2 Jan 89 13:28:15 PST Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 514035; 2 Jan 89 16:26:46 EST Date: Mon, 2 Jan 89 16:26 EST From: David A. Moon Subject: Issue: LOAD-OBJECTS (Version 1) To: CL-Cleanup@SAIL.STANFORD.EDU Cc: Common-Lisp-Object-System@SAIL.STANFORD.EDU, CL-Compiler@SAIL.STANFORD.EDU In-Reply-To: <19881229175913.8.MOON@EUPHRATES.SCRC.Symbolics.COM> Message-Id: <19890102212611.8.MOON@EUPHRATES.SCRC.Symbolics.COM> This was discussed on the clos and compiler lists. I thought it would be a good idea to write it up for discussion and give the cleanup group a look at it. I think it's something that fell in the cracks between these three subcommittees. Issue: LOAD-OBJECTS References: none Related issues: none Category: ADDITION Edit history: Version 1, 2-Jan-89, by Moon (for discussion) Problem description: Common Lisp doesn't provide any way to use an object of a user-defined type (defined with DEFCLASS or DEFSTRUCT) as a constant in a program compiled with COMPILE-FILE. The problem is that LOAD has to be able to "reconstruct" an equivalent object when the compiled-code file is loaded, but the programmer has no way to tell LOAD how to do that. Proposal (LOAD-OBJECTS:MAKE-LOAD-FORM): Define a new generic function named MAKE-LOAD-FORM, which takes one argument and returns one value. The value is a form which, when evaluated at some later time, should return an object that is equivalent to the argument. The exact meaning of "equivalent" depends on the type of object and is up to the programmer who defines a method for MAKE-LOAD-FORM. Define that COMPILE-FILE calls MAKE-LOAD-FORM on any object that appears in a constant and has STANDARD-CLASS or STRUCTURE-CLASS as a metaclass. Define that COMPILE-FILE will only call MAKE-LOAD-FORM once for any given object (compared with EQ) within a single file. It is unspecified whether LOAD calls EVAL on the form or does some other operation that has an equivalent effect. Define that an instance of a class defined with DEFCLASS without any direct superclasses, or defined with DEFSTRUCT without the :TYPE or :INCLUDE options, does not inherit any method for MAKE-LOAD-FORM other than possibly a method that only signals an error. Example: (defclass my-class () ((a :initarg :a :reader my-a) (b :initarg :b :reader my-b) (c :accessor my-c))) (defmethod shared-initialize ((self my-class) ignore &rest ignore) (unless (slot-boundp self 'c) (setf (my-c self) (some-computation (my-a self) (my-b self))))) (defmethod make-load-form ((self my-class)) `(make-instance ',(class-name (class-of self)) :a ',(my-a self) :b ',(my-b self))) In this example, an equivalent instance of my-class is reconstructed by using the values of two of its slots. The value of the third slot is derived from those two values. (defclass my-frob () ((name :initarg :name :reader my-name))) (defmethod make-load-form ((self my-frob)) `(find-my-frob ',(my-name self) :if-does-not-exist :create)) In this example, instances of my-frob are "interned" in some way. An equivalent instance is reconstructed by using the value of the name slot as a key for searching existing objects. In this case the programmer has chosen to create a new object if no existing object is found; alternatively she could have chosen to signal an error in that case. Rationale: Only the programmer who designed a class can know the correct way to reconstruct objects of that class at load time, therefore the reconstruction should be controlled by a generic function. Using EVAL as the interface for telling LOAD what to do provides full generality. A default method, such as one that makes an object whose class has the same name and whose slots have equivalent contents, is not supplied because this is inappropriate for many objects and because it is easy to write for those objects where it is appropriate. MAKE-LOAD-FORM has a natural resemblance to PRINT-OBJECT. Current practice: Symbolics Flavors has something like this, but under a different name. The name Symbolics uses is not suitable for standardization. JonL reports that Lucid is getting more and more requests for this. Cost to Implementors: This seems like only a few one-line changes in the compiled-code file writer and reader. Cost to Users: None. Cost of non-adoption: Serious impairment of the ability to use extended-type objects. Each implementation will probably make up its own version of this as an extension. Performance impact: None. Benefits: See Cost of non-adoption. Esthetics: No significant positive or negative impact. Discussion: It would be possible to define an additional level of protocol that allows multiple classes to contribute to the reconstruction of an object, combining initialization arguments contributed by each class. Since a user can easily define that in terms of MAKE-LOAD-FORM without modifying the Lisp system, it is not being proposed now. Any type that has a read syntax is likely to appear as a quoted constant or inside a quoted constant. Pathnames are one example, user programs often define others. Also many implementations provide a way to create a compiled-code file full of data (rather than compiled Lisp programs), and such data probably include extended-type objects. Moon supports this. From Owners-CommonLoops.pa@Xerox.COM Mon Jan 2 18:54:04 1989 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA19848; Mon, 2 Jan 89 18:54:04 PST Received: from Cabernet.ms by ArpaGateway.ms ; 02 JAN 89 18:53:29 PST Return-Path: <@MCC.COM,@CREOLE.CAD.MCC.COM:dsouza@MCC.COM> Redistributed: CommonLoops.pa Received: from MCC.COM ([10.3.0.62]) by Xerox.COM ; 02 JAN 89 18:51:49 PST Received: from cadillac.cad.mcc.com by MCC.COM with TCP/SMTP; Mon 2 Jan 89 20:23:05-CST Posted-Date: Mon, 2 Jan 89 20:22 CST Received: from CREOLE.CAD.MCC.COM by cadillac.cad.mcc.com (3.2/CAD) id AA01485; Mon, 2 Jan 89 20:22:59 CST Date: Mon, 2 Jan 89 20:22 CST From: D'Souza Desmond Subject: Mailing List Request To: CommonLoops.pa@Xerox.COM Message-Id: <19890103022256.5.DSOUZA@CREOLE.CAD.MCC.COM> Reply-To: dsouza@MCC.COM Postal-Address: MCC, 3500 West Balcones Center Dr., Austin, TX 78759 Business-Phone: (512)338-3324 Please remove me from the CommonLisp mailing list. Thanks. Desmond D'Souza -- D'Souza Desmond From CL-Compiler-mailer@SAIL.STANFORD.EDU Tue Jan 3 09:35:11 1989 Received: from Sail.Stanford.EDU by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA25608; Tue, 3 Jan 89 09:35:11 PST Received: from Sun.COM by SAIL.Stanford.EDU with TCP; 3 Jan 89 09:32:02 PST Received: from snail.Sun.COM by Sun.COM (4.1/SMI-4.0) id AA25364; Tue, 3 Jan 89 09:33:49 PST Received: from suntana.sun.com by snail.Sun.COM (4.1/SMI-4.0) id AA00274; Tue, 3 Jan 89 09:30:28 PST Received: from localhost by suntana.sun.com (4.0/SMI-4.0) id AA11579; Tue, 3 Jan 89 09:31:04 PST Message-Id: <8901031731.AA11579@suntana.sun.com> To: Jon L White Cc: kempf@Sun.COM, Common-Lisp-Object-System@SAIL.STANFORD.EDU, CL-Compiler@SAIL.STANFORD.EDU, cperdue%suntana@Sun.COM Subject: Re: Compilation implications In-Reply-To: Your message of Fri, 30 Dec 88 20:07:12 -0800. <8812310407.AA16126@bhopal> Date: Tue, 03 Jan 89 09:31:00 PST From: kempf@Sun.COM >packages just as a consistency check. Unfortunately, I don't see how >to evaluate the myriads of consistency checks that could conceivable be >placed in a "dumped" class; would they be worth the effort? The class redefinition protocol is probably the right way to go here. If there is a difference between the instance structure in the file and in memory, it could be called to update the instance. >This is not a problem in Lucid Common Lisp [by the bye, I'm assuming a >single COMPILE-FILE -- I'm not talking about the problem of separate file Sorry, I should have said "in a portable way." There are some Lisps (maybe all of them now) which maintain EQLness over FASL for things other than characters, symbols, and numbers. But the language spec in CLtL doesn't require it. jak From Common-Lisp-Object-System-mailer@SAIL.STANFORD.EDU Tue Jan 3 09:59:18 1989 Received: from Sail.Stanford.EDU by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA26877; Tue, 3 Jan 89 09:59:18 PST Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 3 Jan 89 09:59:35 PST Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 514403; Tue 3-Jan-89 12:57:30 EST Date: Tue, 3 Jan 89 12:56 EST From: David A. Moon Subject: Re: Compilation implications To: kempf@Sun.COM Cc: Jon L White , Common-Lisp-Object-System@SAIL.STANFORD.EDU, CL-Compiler@SAIL.STANFORD.EDU, cperdue%suntana@Sun.COM In-Reply-To: <8901031731.AA11579@suntana.sun.com> Message-Id: <19890103175655.8.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Tue, 03 Jan 89 09:31:00 PST From: kempf@Sun.COM >packages just as a consistency check. Unfortunately, I don't see how >to evaluate the myriads of consistency checks that could conceivable be >placed in a "dumped" class; would they be worth the effort? The class redefinition protocol is probably the right way to go here. If there is a difference between the instance structure in the file and in memory, it could be called to update the instance. I thought you said you agreed with my proposal that the way to load an instance of a standard-class from a compiled file is for a method of the instance to return a form which is then evaluated at load time. Once this is adopted, there is no such thing as "the instance structure in the file" and no issue of making that structure consistent with some other structure. The semantics of loading an instance of a standard-class from a compiled file can be entirely understood in terms of MAKE-INSTANCE or whatever other function is called by the form returned by MAKE-LOAD-FORM; no new concepts need be introduced. If the programmer of a given class wants to use the class redefinition protocol, that class's MAKE-LOAD-FORM method can output something that uses that protocol, and if he doesn't, it can output something that doesn't. From CL-Compiler-mailer@SAIL.STANFORD.EDU Tue Jan 3 18:42:03 1989 Received: from Sail.Stanford.EDU by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA02698; Tue, 3 Jan 89 18:42:03 PST Received: from Sun.COM by SAIL.Stanford.EDU with TCP; 3 Jan 89 18:38:08 PST Received: from snail.Sun.COM by Sun.COM (4.1/SMI-4.0) id AA01222; Tue, 3 Jan 89 18:39:10 PST Received: from suntana.sun.com by snail.Sun.COM (4.1/SMI-4.0) id AA23845; Tue, 3 Jan 89 18:35:50 PST Received: from localhost by suntana.sun.com (4.0/SMI-4.0) id AA11798; Tue, 3 Jan 89 18:36:27 PST Message-Id: <8901040236.AA11798@suntana.sun.com> To: David A. Moon Cc: kempf@Sun.COM, Jon L White , Common-Lisp-Object-System@SAIL.STANFORD.EDU, CL-Compiler@SAIL.STANFORD.EDU, cperdue%suntana@Sun.COM Subject: Re: Compilation implications In-Reply-To: Your message of Tue, 03 Jan 89 12:56:00 -0500. <19890103175655.8.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Tue, 03 Jan 89 18:36:24 PST From: kempf@Sun.COM >thought you said you agreed with my proposal that the way to load an >instance of a standard-class from a compiled file is for a method of the >instance to return a form which is then evaluated at load time. Once >this is adopted, there is no such thing as "the instance structure in >the file" and no issue of making that structure consistent with some >other structure. The semantics of loading an instance of a standard-class Right. In general, this will be the case, but remember that your proposal leaves open a programmer hook which may, in specific instances, require the class redefinition protocol to be run. However, they will probably be rare, so we can disregard them for now. jak From Owners-CommonLoops.pa@Xerox.COM Wed Jan 4 16:53:32 1989 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA19691; Wed, 4 Jan 89 16:53:32 PST Received: from Salvador.ms by ArpaGateway.ms ; 04 JAN 89 14:56:08 PST Return-Path: Redistributed: CommonLoops.pa Received: from KL.SRI.COM ([10.1.0.2]) by Xerox.COM ; 04 JAN 89 14:52:52 PST Date: Wed, 4 Jan 89 14:52:24 PST From: Wei-Han Chu Subject: Accessing arisia.xerox.com To: CommonLoops.pa@Xerox.COM Cc: chu@KL.SRI.COM Message-Id: <12459954159.20.CHU@KL.SRI.COM> I am experiencing great difficulty trying to connect to arisia.xerox.com to get the latest version of PCL. Mostf the time when I tried to connect through FTP I get the message ?Connect failed - Device is not on line Of the few occasions I managed to connect, the connection was dropped during file transfer. Is arisia.xerox.com only only on the network during certain hours of the day? If so, what would be the best time to connect? Thanks for your help. - Wei-Han Chu - Varian Research Center ------- From CL-Compiler-mailer@SAIL.STANFORD.EDU Thu Jan 5 10:14:37 1989 Received: from Sail.Stanford.EDU by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA07752; Thu, 5 Jan 89 10:14:37 PST Received: from ti.com by SAIL.Stanford.EDU with TCP; 5 Jan 89 10:05:06 PST Received: by ti.com id AA27755; Thu, 5 Jan 89 12:03:51 CST Received: from Kelvin by tilde id AA05297; Thu, 5 Jan 89 11:49:50 CST Message-Id: <2809014625-3421425@Kelvin> Sender: GRAY@Kelvin.csc.ti.com Date: Thu, 5 Jan 89 11:50:25 CST From: David N Gray To: Jon L White Cc: Common-Lisp-Object-System@SAIL.STANFORD.EDU, CL-Compiler@SAIL.STANFORD.EDU Subject: Re: Compilation implications In-Reply-To: Msg of Thu, 29 Dec 88 04:52:47 PST from Jon L White > (A) "Reconstructor" functions for instances I've been giving this a little thought. I have modified our compiler to call the generic function RECONSTRUCTION-FORM when it needs to dump an object that is not one of the primitive types it knows how to handle directly. It takes the object as its argument and returns a form to be evaluated to reconstruct the object (or else you get a "no applicable method" error). With that hook, it then becomes possible to define a general-purpose object dumper in portable CLOS code, which I hereby donate to the public domain: (defclass fasdump-mixin () () (:documentation "Including this class allows instances to be dumped to object files.")) (defmacro push-key-and-value (key value list) `(setf ,list (list* ,key ,value ,list))) (defmethod reconstruction-form ((object fasdump-mixin)) (let ((plist '()) (class-name (type-of object)) (unbound-slots '()) (allocation-args '())) (dolist (slot (class-slots (class-of object))) (let ((name (slot-description-name slot))) (when (eq (slot-description-allocation slot) ':instance) (if (slot-boundp object name) (push-key-and-value name (slot-value object name) plist) (push name unbound-slots))))) (if (and (null unbound-slots) (null allocation-args)) `(remake-object ',class-name ',plist) `(remake-object ',class-name ',plist ',unbound-slots ',allocation-args)))) (defun remake-object (class-name &optional slots-and-values unbound-slots allocation-args) (let* ((class1 (find-class class-name)) (object (progn (unless (class-finalized-p class1) (finalize-inheritance class1)) (apply #'allocate-instance class1 allocation-args))) (class (class-of object)) (deleted-slots '()) (plist '()) (added-slots '()) (default '#,(cons nil nil))) (do ((tail slots-and-values (cddr tail))) ((atom tail)) (let ((slot-name (first tail))) (if (slot-exists-p-using-class class object slot-name) (setf (slot-value-using-class class object slot-name) (second tail)) (progn (push slot-name deleted-slots) (push-key-and-value slot-name (second tail) plist))))) (dolist (slot (class-slots class)) (let ((slot-name (slot-description-name slot))) (when (and (eq (slot-description-allocation slot) ':instance) (eq (getf slots-and-values slot-name default) default) (not (member slot-name unbound-slots :test #'eq))) (push slot-name added-slots)))) (when (or deleted-slots added-slots) (update-instance-for-redefined-class object added-slots deleted-slots plist)) object)) Note that this does not require the slots to have initargs, and note the use of UPDATE-INSTANCE-FOR-REDEFINED-CLASS at the end to take account of any changes in the class definition between compilation and loading. If any slot values are themselves class instances, then the compiler will invoke RECONSTRUCTION-FORM on them in the process of writing out the form returned by the first call. While this works, I don't think this is an ideal solution because it doesn't handle the case of recursive data structures. A better solution might be something along the lines of having the generic function return four values: 1. The class name. 2. A list of additional arguments for ALLOCATE-INSTANCE. 3. The name of an initialization function. 4. Initialization arguments. The loader would then first do (APPLY #'ALLOCATE-INSTANCE (FIND-CLASS class-name) other-allocate-args) to create the object before it begins reading the next two items, and then finally do (APPLY (SYMBOL-FUNCTION init-function) the-object initialization-args) to fill in the slots. > Possibly, EQL specializers could raise this question. Upon re-reading, > the language of 88-002R now seems a bit vague to me, and possibly open > to misinterpretation, as to just when an EQL parameter specializer form > is evaluated. Yes, I ran into this when I wrote a method that looked something like this: (DEFMETHOD MAKE-INSTANCE ((CLASS (EQL (FIND-CLASS 'MY-CLASS))) ...) ...) which wouldn't work without doing something like this: (defmethod reconstruction-form ((object class)) (let ((class-name (class-name object))) (if (and (symbolp class-name) (eq (find-class class-name nil) object)) `(find-class ',class-name) (error "Can't dump ~S to object file because it doesn't have a proper name." object)))) but I'm not sure if this is what the designers of CLOS had in mind. > (B) References to classes "by name" > > The analogy between FIND-PACKAGE and FIND-CLASS suggests that class > objects are in the same "database" category as packages. Shouldn't > they be referenced "by name" in compiled file? That sounds right to me. > I realize this may pose some ordering constraints on the executions in a > file, if the compiled version is to operate correctly -- i.e., classes might > have to be defined before the use of any constant that "names" that class. > Such constraints may not be as feasible as they are in the package world > (Indeed, some folks even dislike the package ordering constraints!). Can > a forward-reference, "placeholder" be substituted for a class that hasn't > yet been defined, but is referenced by a quoted constant? We ran into this problem where we optimize calls to TYPEP to specialized code using the class object, which might not be defined yet when the code is loaded, so at that point the loader constructs a dummy class definition and trusts it to be redefined correctly later. So far, that seems to be working ok, but, again, I'm not sure if that is really considered proper. From Common-Lisp-Object-System-mailer@SAIL.STANFORD.EDU Thu Jan 5 13:35:46 1989 Received: from Sail.Stanford.EDU by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA12080; Thu, 5 Jan 89 13:35:46 PST Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 5 Jan 89 13:35:47 PST Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 516094; Thu 5-Jan-89 16:32:43 EST Date: Thu, 5 Jan 89 16:32 EST From: David A. Moon Subject: Re: Compilation implications To: David N Gray Cc: Jon L White , Common-Lisp-Object-System@SAIL.STANFORD.EDU, CL-Compiler@SAIL.STANFORD.EDU In-Reply-To: <2809014625-3421425@Kelvin> Message-Id: <19890105213202.9.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Thu, 5 Jan 89 11:50:25 CST From: David N Gray > Possibly, EQL specializers could raise this question. Upon re-reading, > the language of 88-002R now seems a bit vague to me, and possibly open > to misinterpretation, as to just when an EQL parameter specializer form > is evaluated. Yes, I ran into this when I wrote a method that looked something like this: (DEFMETHOD MAKE-INSTANCE ((CLASS (EQL (FIND-CLASS 'MY-CLASS))) ...) ...) which wouldn't work without doing something like this: (defmethod reconstruction-form ((object class)) (let ((class-name (class-name object))) (if (and (symbolp class-name) (eq (find-class class-name nil) object)) `(find-class ',class-name) (error "Can't dump ~S to object file because it doesn't have a proper name." object)))) but I'm not sure if this is what the designers of CLOS had in mind. The macroexpansion of defmethod must be wrong. The form inside the EQL parameter specializer name should be evaluated at load time, not at compile time. That's my opinion anyway; 88-002R doesn't say as far as I can see. From Common-Lisp-Object-System-mailer@SAIL.STANFORD.EDU Thu Jan 5 13:42:08 1989 Received: from Sail.Stanford.EDU by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA12182; Thu, 5 Jan 89 13:42:08 PST Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 5 Jan 89 13:42:11 PST Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 516101; Thu 5-Jan-89 16:39:43 EST Date: Thu, 5 Jan 89 16:39 EST From: David A. Moon Subject: Re: Compilation implications To: David N Gray Cc: Jon L White , Common-Lisp-Object-System@SAIL.STANFORD.EDU, CL-Compiler@SAIL.STANFORD.EDU In-Reply-To: <2809014625-3421425@Kelvin> Message-Id: <19890105213908.0.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Thu, 5 Jan 89 11:50:25 CST From: David N Gray (defclass fasdump-mixin .... While this works, For classes where simply saving the values of the slots is enough to save all relevant state of the object, and where simply restoring equivalent values into the slots and not calling make-instance, initialize-instance, nor shared-initialize is enough to create an equivalent object. Such classes do exist, so this is worth telling people how to do so they can use it with such classes. I don't think this is an ideal solution because it doesn't handle the case of recursive data structures. A better solution might be something along the lines of having the generic function return four values: 1. The class name. 2. A list of additional arguments for ALLOCATE-INSTANCE. 3. The name of an initialization function. 4. Initialization arguments. The loader would then first do (APPLY #'ALLOCATE-INSTANCE (FIND-CLASS class-name) other-allocate-args) to create the object before it begins reading the next two items, and then finally do (APPLY (SYMBOL-FUNCTION init-function) the-object initialization-args) to fill in the slots. You can make your REMAKE-OBJECT technique do this without modifying the loader (you have to put in a special variable that allows you to detect recursive calls). Or did you want to do the final step at some later time than when the outermost in a set of nested objects is created? I don't think deferring the final step until the end of loading the file would work in many cases. From CL-Compiler-mailer@SAIL.STANFORD.EDU Thu Jan 5 14:54:24 1989 Received: from Sail.Stanford.EDU by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA13506; Thu, 5 Jan 89 14:54:24 PST Received: from ti.com by SAIL.Stanford.EDU with TCP; 5 Jan 89 14:50:58 PST Received: by ti.com id AA29024; Thu, 5 Jan 89 16:49:03 CST Received: from Kelvin by tilde id AA11935; Thu, 5 Jan 89 16:40:27 CST Message-Id: <2809032076-4469910@Kelvin> Sender: GRAY@Kelvin.csc.ti.com Date: Thu, 5 Jan 89 16:41:16 CST From: David N Gray To: "David A. Moon" Cc: Jon L White , Common-Lisp-Object-System@SAIL.STANFORD.EDU, CL-Compiler@SAIL.STANFORD.EDU Subject: Re: Compilation implications In-Reply-To: Msg of Thu, 5 Jan 89 16:39 EST from David A. Moon > You can make your REMAKE-OBJECT technique do this without modifying the loader > (you have to put in a special variable that allows you to detect recursive > calls). The problem with the approach of reading one form and then evaluating it is that the slot values have already been read and constructed before allocating the object they go in. I suppose it would be possible to add special handling for recursive references that would maintain a list of these so that the loader can go back and fill them in later, but the approach of allocating the object before reading its contents is much simpler. That's what we already do for lists and arrays. From Common-Lisp-Object-System-mailer@SAIL.STANFORD.EDU Thu Jan 5 15:47:07 1989 Received: from Sail.Stanford.EDU by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA14300; Thu, 5 Jan 89 15:47:07 PST Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 5 Jan 89 15:47:11 PST Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 516198; Thu 5-Jan-89 18:44:15 EST Date: Thu, 5 Jan 89 18:43 EST From: David A. Moon Subject: Re: Compilation implications To: David N Gray Cc: Jon L White , Common-Lisp-Object-System@SAIL.STANFORD.EDU, CL-Compiler@SAIL.STANFORD.EDU In-Reply-To: <2809032076-4469910@Kelvin> Message-Id: <19890105234343.4.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Thu, 5 Jan 89 16:41:16 CST From: David N Gray > You can make your REMAKE-OBJECT technique do this without modifying the loader > (you have to put in a special variable that allows you to detect recursive > calls). The problem with the approach of reading one form and then evaluating it is that the slot values have already been read and constructed before allocating the object they go in. I suppose it would be possible to add special handling for recursive references that would maintain a list of these so that the loader can go back and fill them in later, but the approach of allocating the object before reading its contents is much simpler. That's what we already do for lists and arrays. Apparently my message wasn't clear. What I meant to say was that you can make the form returned by your MAKE-LOAD-FORM method do just that, allocate the object and then fill in its contents. Then you can detect nested objects and move all the allocation forms to the front. Oh, I'm sorry. This all depends on the assumption that when the form is (PROGN form1 form2), the loader evaluates form1 before reading form2. I had not realized that that might not be true of all loaders. Should we make special-case treatment of PROGN a requirement? Probably it would be a better idea for MAKE-LOAD-FORM to return two values, where the first value is a form that will create the object and the second value is a form that will further initialize the object? This way the order of evaluation requirement is more explicit. It's upward compatible since the second value can be NIL if you don't need it. Also this gives the opportunity to communicate between the forms without using a special variable; suppose we plug the object returned by the first form into the second form and do (schematically): ;; This part happens at compile time (MULTIPLE-VALUE-BIND (form1.1 form1.2) (MAKE-LOAD-FORM object1) (MULTIPLE-VALUE-BIND (form2.1 form2.2) (MAKE-LOAD-FORM object2) ;; This part happens at load time (LET ((x1 (EVAL form1.1)) (x2 (EVAL form2.1))) (WHEN form1.2 (EVAL (APPEND form1.2 (LIST (LIST 'QUOTE x1))))) (WHEN form2.2 (EVAL (APPEND form2.2 (LIST (LIST 'QUOTE x2)))))))) Should I evolve the proposal I sent out the other day along these lines? It's still the case that only the programmer of the class knows whether this is an appropriate protocol, so it has to be under the control of the programmer, not built-in. Consider, for example, any class whose objects are interned. Calling ALLOCATE-INSTANCE unconditionally is not going to work. That's why I prefer to see an interface in terms of forms rather than in terms of functions, since forms are the simplest way to do something that is completely general. From CL-Compiler-mailer@SAIL.STANFORD.EDU Thu Jan 5 17:24:51 1989 Received: from Sail.Stanford.EDU by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA16193; Thu, 5 Jan 89 17:24:51 PST Received: from ti.com by SAIL.Stanford.EDU with TCP; 5 Jan 89 17:20:51 PST Received: by ti.com id AA29934; Thu, 5 Jan 89 19:19:00 CST Received: from Kelvin by tilde id AA15060; Thu, 5 Jan 89 19:05:11 CST Message-Id: <2809040762-4991819@Kelvin> Sender: GRAY@Kelvin.csc.ti.com Date: Thu, 5 Jan 89 19:06:02 CST From: David N Gray To: "David A. Moon" Cc: Jon L White , Common-Lisp-Object-System@SAIL.STANFORD.EDU, CL-Compiler@SAIL.STANFORD.EDU Subject: Re: Compilation implications In-Reply-To: Msg of Thu, 5 Jan 89 18:43 EST from David A. Moon > Probably it would be a better idea for MAKE-LOAD-FORM to return two > values, where the first value is a form that will create the object and > the second value is a form that will further initialize the object? > This way the order of evaluation requirement is more explicit. It's > upward compatible since the second value can be NIL if you don't need > it. Yes, that sounds good except for the problem of how to pass the object to the second form. > ... suppose we plug the object returned by > the first form into the second form and do (schematically): ... > (WHEN form1.2 > (EVAL (APPEND form1.2 (LIST (LIST 'QUOTE x1))))) ... This reduces generality because the second form can't use optional arguments, and it seems a little strange to say that the second value is a form minus its last argument. I wonder if it wouldn't look nicer to just designate a variable name to indicate where the object is to be plugged in? For example, we might do: (defmethod make-load-form ((object my-class)) (values `(allocate-mine ...) `(init-mine * ...))) where it is understood that the loader will bind * to the result of the first form while evaluating the second. This follows the convention that * is the result of the previous evaluation, so doesn't introduce a new name to remember. Now that I think about it, I like this better than my previous 4-value suggestion. > Should I evolve the proposal I sent out the other day along these lines? Yes, I would like to see that. From Common-Lisp-Object-System-mailer@SAIL.STANFORD.EDU Fri Jan 6 10:51:03 1989 Received: from Sail.Stanford.EDU by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA29813; Fri, 6 Jan 89 10:51:03 PST Received: from ti.com by SAIL.Stanford.EDU with TCP; 6 Jan 89 09:36:05 PST Received: by ti.com id AA02335; Fri, 6 Jan 89 11:34:06 CST Received: from Kelvin by tilde id AA00655; Fri, 6 Jan 89 11:16:52 CST Message-Id: <2809099069-8494933@Kelvin> Sender: GRAY@Kelvin.csc.ti.com Date: Fri, 6 Jan 89 11:17:49 CST From: David N Gray To: Jon L White Cc: Moon@STONY-BROOK.SCRC.Symbolics.COM, Common-Lisp-Object-System@SAIL.STANFORD.EDU Subject: Re: Compilation implications In-Reply-To: Msg of Fri, 6 Jan 89 00:31:37 PST from Jon L White > -- Your code for the 'reconstruction-form' method never adds anything > to the 'allocation-args' -- did you excise some TI-specific parts? > or what is this ever supposed to be besides nil? My version uses an implementation-dependent argument for the memory area; I omitted that from the portable version I mailed out. > -- What is 'finalize-inheritance'? is it to fix up "stubs" that had > been created as "placeholder" classes merely so that some type > dispatch could make reference to the class? It's defined in CLOS chapter 3; my intent was to perform any bookkeeping needed if the class had not been instantiated before (such as computing the class precedence list and effective slot list). I haven't yet had a chance to study the December edition of chapter 3 to make sure that's the right way to do it. > -- Why do you use 'slot-exists-p-using-class' instead of 'slot-exists-p'? > The class argument you are passing in for 'object' is simply the > value obtained from (class-of object) anyway? For efficiency -- since I already have the class object, I might as well call SLOT-EXISTS-P-USING-CLASS directly instead of having SLOT-EXISTS-P do it. This has the effect of moving the call to CLASS-OF outside the loop. > -- When you ran into some trouble with the form: > > (DEFMETHOD MAKE-INSTANCE ((CLASS (EQL (FIND-CLASS 'MY-CLASS))) ...) ...) > > was it because your DEFMETHOD treats this form essentially the same as > > (DEFMETHOD MAKE-INSTANCE ((CLASS (EQL '#.(FIND-CLASS 'MY-CLASS))) ...) ...) > > Does your macro expander for DEFMETHOD call EVAL to get the object, > rather than returning a form to be evaluated later? Yes, the evaluation is being done at macro expansion time. If that's not right, I'll need to change it. From Common-Lisp-Object-System-mailer@SAIL.STANFORD.EDU Fri Jan 6 10:54:09 1989 Received: from Sail.Stanford.EDU by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA29836; Fri, 6 Jan 89 10:54:09 PST Received: from lucid.com by SAIL.Stanford.EDU with TCP; 6 Jan 89 00:33:36 PST Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA06806g; Fri, 6 Jan 89 00:29:23 PST Received: by bhopal id AA07509g; Fri, 6 Jan 89 00:31:37 PST Date: Fri, 6 Jan 89 00:31:37 PST From: Jon L White Message-Id: <8901060831.AA07509@bhopal> To: Gray@DSG.csc.ti.com Cc: Moon@STONY-BROOK.SCRC.Symbolics.COM, Common-Lisp-Object-System@SAIL.STANFORD.EDU In-Reply-To: David N Gray's message of Thu, 5 Jan 89 11:50:25 CST <2809014625-3421425@Kelvin> Subject: Compilation implications And thanks to you too, David, for putting some time into this. [Note that I've dropped cl-compiler off the cc list.] Some Questions. -- Your code for the 'reconstruction-form' method never adds anything to the 'allocation-args' -- did you excise some TI-specific parts? or what is this ever supposed to be besides nil? -- What is 'finalize-inheritance'? is it to fix up "stubs" that had been created as "placeholder" classes merely so that some type dispatch could make reference to the class? -- Why do you use 'slot-exists-p-using-class' instead of 'slot-exists-p'? The class argument you are passing in for 'object' is simply the value obtained from (class-of object) anyway? -- When you ran into some trouble with the form: (DEFMETHOD MAKE-INSTANCE ((CLASS (EQL (FIND-CLASS 'MY-CLASS))) ...) ...) was it because your DEFMETHOD treats this form essentially the same as (DEFMETHOD MAKE-INSTANCE ((CLASS (EQL '#.(FIND-CLASS 'MY-CLASS))) ...) ...) Does your macro expander for DEFMETHOD call EVAL to get the object, rather than returning a form to be evaluated later? I agree with you very much that the reasonable way to handle potentially circular data is to allocate an object first (and "register" it in the corresponding compiler or binary-loader table) and _then_ create the several components. As Moon points out, there may be some classes of objects for which this componentwise protocol is unsatisfactory -- objects which must, for example, be "massaged" after creation by one or the other initialization protocol (or both). For these, circularities could be an intractable problem; but for classes for which the fasdmp- mixin is suitable, there should be no problem. I hope it's true that the vast majority of cases can be handled by fasdmp-mixin. -- JonL -- From Common-Lisp-Object-System-mailer@SAIL.STANFORD.EDU Fri Jan 6 15:19:55 1989 Received: from Sail.Stanford.EDU by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA04283; Fri, 6 Jan 89 15:19:55 PST Received: from Sun.COM by SAIL.Stanford.EDU with TCP; 6 Jan 89 15:18:46 PST Received: from snail.Sun.COM by Sun.COM (4.1/SMI-4.0) id AA27087; Fri, 6 Jan 89 15:19:58 PST Received: from lukasiewicz.sun.com by snail.Sun.COM (4.1/SMI-4.0) id AA07702; Fri, 6 Jan 89 15:16:36 PST Received: by lukasiewicz.sun.com (4.0/SMI-4.0) id AA00547; Fri, 6 Jan 89 15:19:04 PST Date: Fri, 6 Jan 89 15:19:04 PST From: jrose@Sun.COM (John Rose) Message-Id: <8901062319.AA00547@lukasiewicz.sun.com> To: jonl@lucid.com Cc: Moon@STONY-BROOK.SCRC.Symbolics.COM, Common-Lisp-Object-System@SAIL.STANFORD.EDU, CL-Compiler@SAIL.STANFORD.EDU In-Reply-To: Jon L White's message of Fri, 30 Dec 88 03:46:40 PST <8812301146.AA13748@bhopal> Subject: Compilation implications Date: Fri, 30 Dec 88 03:46:40 PST From: Jon L White Thanks for your many comments, Dave. I'm sure they will be useful. re: ["Reconstructor" forms and mixins] I don't remember why the CLOS committee didn't put anything like this into the proposed standard. Maybe we thought it was the Compiler committee's business, maybe we had some disagreement, or maybe we just ran out of time. There is a blend of problems here -- partly object-oriented and partly semantics of compilation. It could be that the buck is getting shuffled back and forth and nothing being done. Maybe the time just wasn't ripe for specifying this protocol -- maybe more experience is needed -- but sooner or later the user-community will be "push coming to shove" and the lack of a portable interface could be damaging. re: [fasling out classes "by name"] I don't see how any other way could work, actually, since two distinct compiled files that refer to a class by the same name must end up referring to the same metaobject after loading. Right. Separate compilation seems to be the clinching argument. Wait. Fasling out classes by name is not always the right thing to do, and any institutionalization of JonL's and Moon's comments will probably be a mistake. In recent proposals, fasl-ing out of classes is not specially addressed by the proposed STANDARD-OBJECT fasdumping protocol, so it's not so important that we get this ironed out immediately. Still, I think the following points need to be made: 1. If anything like a "mixin manager" is being used to create classes on the fly, such classes should be dumped not as names, but as mixture specifications, perhaps lists of names. 2. In general, dynamic class creation may result in classes which are nameless, have gensyms for names, or have names which do not fully reflect their nature (such as the mixins of #1). Yet such classes may well have a sensible meaning which is independent of the current Lisp instance, and which can be transported across load boundaries; such classes need a way to encode this meaning in a non-symbol form. 2a. An interesting example of dynamic class creation which shows up less in dynamically typed languages is the construction of parametrized types. After instantiating a PT, you compile its methods (or whatever you call the code is associated with it) with formal type parameters filled in with actuals. This means that the methods can be efficiently compiled for the PT instantiation, using any extra information that the actual type parameters give. For example, "stack of character" can use character arrays internally, while "stack of bit" can use bit arrays. These considerations apply to any language with PTs. Some languages can't even begin to compile a PT unless it's fully instantiated. In Lisp, you can program generic stacks using T-arrays, but at a loss of storage efficiency if you're going to use them for bits. One solution is to supply a FOO-STACK type for every implementationally significant sequence element type FOO. A better solution is to define a class-valued function which takes the element type as a parameter, and finds or creates a CLOS class with the appropriate efficient code and data structures. So PTs can have a place in CLOS, and give another example where symbols don't work well as class names. Even better than a class-valued function would be the ability to give parameters to class names, just as DEFTYPE names accept parameters. I hope the Meta Object Protocol can be used to do this. In that case, something like '(STACK CHARACTER) might make a good fasdumpable class name. 3. This point is concerned less with fasloading from files, but shows another way that simple symbols are insufficient to refer to classes. An acid test of an object-oriented system is whether objects of new classes can be introduced into a running system without breaking it, and can take participate in existing protocols. Often, such objects of new class are introduced by loading new modules into Lisp, so we can assume that whenever an object is loaded, its class is loaded too. But what if an object enters a Lisp system alone, perhaps in the process of IPC, or from an OODB, and it has a class not seen before? It may then be desirable not only for the class to have a name, but some indication of where its definition is to be sought, so that it may be loaded. Such autoloading of classes would be necessary in systems featuring transfer of objects between Lisps and a large or growing space of classes. So, be careful! Mere symbols make good class names only for systems of limited size, and a fixed class population. -- JonL -- -- John From Common-Lisp-Object-System-mailer@SAIL.STANFORD.EDU Fri Jan 6 15:39:53 1989 Received: from Sail.Stanford.EDU by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA04653; Fri, 6 Jan 89 15:39:53 PST Received: from Sun.COM by SAIL.Stanford.EDU with TCP; 6 Jan 89 15:38:27 PST Received: from snail.Sun.COM by Sun.COM (4.1/SMI-4.0) id AA27525; Fri, 6 Jan 89 15:40:07 PST Received: from lukasiewicz.sun.com by snail.Sun.COM (4.1/SMI-4.0) id AA08599; Fri, 6 Jan 89 15:36:42 PST Received: by lukasiewicz.sun.com (4.0/SMI-4.0) id AA00581; Fri, 6 Jan 89 15:39:08 PST Date: Fri, 6 Jan 89 15:39:08 PST From: jrose@Sun.COM (John Rose) Message-Id: <8901062339.AA00581@lukasiewicz.sun.com> To: kempf@Sun.COM Cc: jonl@lucid.com, Common-Lisp-Object-System@SAIL.STANFORD.EDU, CL-Compiler@SAIL.STANFORD.EDU, cperdue%suntana@Sun.COM In-Reply-To: kempf@sun.com's message of Fri, 30 Dec 88 11:27:27 PST <8812301927.AA09230@suntana.sun.com> Subject: Compilation implications Date: Fri, 30 Dec 88 11:27:27 PST From: kempf@sun.com A couple comments on the original and Moon's followup. ... 2) I think Moon's solution of a constructor form which gets executed using EVAL at load time is the only possible solution to this problem. In particular, the semantics of quoted constants implied by CLtL is that only symbols can be expected to be EQ across a FASDUMP, and only characters and numbers can additionally be expected to be EQL. This has interesting implications for EQL specializers. Since the only objects which can be expected to survive a FASDUMP and remain EQL are symbols, numbers, and characters, these are the only objects which make sense to have in a DEFMETHOD form with an EQL That's only true for non-CLOS types. I'm quite pleased that Moon's solution allows the programmer to define new STANDARD-OBJEcT types which, like symbols, characters, and numbers, preserve EQL-ness across dumps. (For example, two Symbolics pathnames are EQL iff they have equivalent components, thus allowing them to be compared efficiently and to have well-defined property lists.) This is done by having a object being fasloaded into a Lisp "look around" in the Lisp for a pre-existing "equivalent" object, and, if it's found, return that pre-existing object's reference. The definition of "look around" and "equivalent" is type-dependent, but the technique is general. (For symbols, "look around" is FIND-SYMBOL and "equivalent" is "same print name and package".) You might call any such type an "EQL-preserving" or "interning" type. So, EQL specializers can usefully apply to symbols, numbers, characters, and selected STANDARD-OBJECT classes. Interestingly, STANDARD-CLASS must be EQL-preserving, since the MAKE-INSTANCE protocol relies on EQL specializers which point to all the classes. In my previous message, I argued that mere symbols are not always sufficient for class names. In the terms of present message, this means that the implementation of the interning behavior of classes cannot be simply "dump the class name symbol, and do a FIND-CLASS when loading". In fact, it may be necessary on occasion to create the class on the fly, when the name is first seen, just as symbols are created when first seen. specialized parameter. This makes it important that machinery be available to add methods to a generic function through a functional interface, since some of the things one wants to do with EQL methods require other objects. Part of that machinery is already in Chapter 2 (ADD-METHOD, MAKE-INSTANCE) but part of it is not (how to make a method function, for example). These are important points too. But it seems to me that method definition is essentially an "off-line" activity, like compilation. Or do the CLOS people envision fast dispatch __and__ fast generic function redefinition? I assume that fast dispatch is being paid for partly by heavy crunching at generic function definition time. Or is it all in the cache action? ... jak -- John From Owners-commonloops.pa@Xerox.COM Fri Jan 6 18:03:23 1989 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA06861; Fri, 6 Jan 89 18:03:23 PST Received: from Semillon.ms by ArpaGateway.ms ; 06 JAN 89 17:34:41 PST Return-Path: Redistributed: commonloops.pa Received: from VAX.BBN.COM ([128.89.0.91]) by Xerox.COM ; 06 JAN 89 17:31:45 PST To: commonloops.pa@Xerox.COM Subject: Question (complaint?) on CLOS Spec Date: Fri, 06 Jan 89 16:04:59 -0500 From: Mike Thome Message-Id: <890106-173441-1654@Xerox> (I'm referring to 88-002R of the CLOS spec, so if these (bugs?) have been fixed since this version of the spec, please ignore...) In the discussion on define-method-combination, I've got a few questions and complaints on the spec: 1. What was the reasoning behind having short-form-defined method combination styles have thier primary methods defined as those with a qualifier the same as the name of the combination style? Clarity? 2. The examples given in this section make no use of defgeneric - which I suspect must be required, since I see nothing in the spec that prohibits the name of a short-form-defined method combination from being the same as one of the optional qualifiers for a long-form-defined combination style. 3. Generally, it seems inconsistant that standard method combination has null method qualified primary methods, while all the rest of the examples (as well as any short-form-defined combinations) have non-null primaries. curiously, -mike thome (mthome@bbn.com) From Common-Lisp-Object-System-mailer@SAIL.STANFORD.EDU Fri Jan 6 21:09:26 1989 Received: from Sail.Stanford.EDU by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA09201; Fri, 6 Jan 89 21:09:26 PST Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 6 Jan 89 21:07:56 PST Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 516877; Sat 7-Jan-89 00:06:25 EST Date: Sat, 7 Jan 89 00:05 EST From: David A. Moon Subject: Compilation implications To: John Rose Cc: kempf@Sun.COM, jonl@lucid.com, Common-Lisp-Object-System@SAIL.STANFORD.EDU, CL-Compiler@SAIL.STANFORD.EDU, cperdue%suntana@Sun.COM In-Reply-To: <8901062339.AA00581@lukasiewicz.sun.com> Message-Id: <19890107050551.5.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Fri, 6 Jan 89 15:39:08 PST From: jrose@Sun.COM (John Rose) So, EQL specializers can usefully apply to symbols, numbers, characters, and selected STANDARD-OBJECT classes. Interestingly, STANDARD-CLASS must be EQL-preserving, since the MAKE-INSTANCE protocol relies on EQL specializers which point to all the classes. As I pointed out in an earlier message, translation of parameter specializer names to parameter specializers occurs at load time, not at compile time. Thus the available space of EQL specializers is not affected by the behavior of COMPILE-FILE and LOAD. Now you understand why CLOS uses (EQL
) where CommonLoops used (QUOTE ). In my previous message, I argued that mere symbols are not always sufficient for class names. In the terms of present message, this means that the implementation of the interning behavior of classes cannot be simply "dump the class name symbol, and do a FIND-CLASS when loading". In fact, it may be necessary on occasion to create the class on the fly, when the name is first seen, just as symbols are created when first seen. As far as I know, nothing in CLOS, not even in metaobjects, requires the ability to dump classes with COMPILE-FILE and load them with LOAD. The programmer writing a particular MAKE-LOAD-FORM method might indeed implement the behavior you describe, or some other behavior, for their particular class, but I don't think the core CLOS language requires this. specialized parameter. This makes it important that machinery be available to add methods to a generic function through a functional interface, since some of the things one wants to do with EQL methods require other objects. Part of that machinery is already in Chapter 2 (ADD-METHOD, MAKE-INSTANCE) but part of it is not (how to make a method function, for example). This is chapter 3 (metaobject) business. It's probably just an accident that a few bits of it leaked into chapter 2. These are important points too. But it seems to me that method definition is essentially an "off-line" activity, like compilation. Or do the CLOS people envision fast dispatch __and__ fast generic function redefinition? I assume that fast dispatch is being paid for partly by heavy crunching at generic function definition time. Or is it all in the cache action? CLOS is a language, not an implementation. The CLOS language does not specify the speed of particular operations. That's a matter for implementations to decide based on their own tradeoffs. From Common-Lisp-Object-System-mailer@SAIL.STANFORD.EDU Fri Jan 6 22:06:48 1989 Received: from Sail.Stanford.EDU by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA09697; Fri, 6 Jan 89 22:06:48 PST Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 6 Jan 89 22:07:07 PST Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 516917; Sat 7-Jan-89 01:04:36 EST Date: Sat, 7 Jan 89 01:04 EST From: David A. Moon Subject: Re: Compilation implications To: David N Gray Cc: Jon L White , Common-Lisp-Object-System@SAIL.STANFORD.EDU, CL-Compiler@SAIL.STANFORD.EDU In-Reply-To: <2809040762-4991819@Kelvin> Message-Id: <19890107060409.4.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Thu, 5 Jan 89 19:06:02 CST From: David N Gray > Probably it would be a better idea for MAKE-LOAD-FORM to return two > values, where the first value is a form that will create the object and > the second value is a form that will further initialize the object? > This way the order of evaluation requirement is more explicit. It's > upward compatible since the second value can be NIL if you don't need > it. Yes, that sounds good except for the problem of how to pass the object to the second form. > ... suppose we plug the object returned by > the first form into the second form and do (schematically): ... > (WHEN form1.2 > (EVAL (APPEND form1.2 (LIST (LIST 'QUOTE x1))))) ... This reduces generality because the second form can't use optional arguments, and it seems a little strange to say that the second value is a form minus its last argument. What I had in mind was ((LAMBDA (object) ...code...)). But I like your suggestion of evaluating the form in an environment where * is bound to the object better. Other people should check me on this, it might just be that you appealed to my sense of hackish kludgery. It would be nicer if we could just use a function, but the last proposal I saw for what you could use as constants in COMPILE-FILE said you could not use functions. We could use a LAMBDA expression, I suppose. > Should I evolve the proposal I sent out the other day along these lines? Yes, I would like to see that. I'll update it based on all the received comments as early as I can next week. From CL-Compiler-mailer@SAIL.STANFORD.EDU Fri Jan 6 22:51:39 1989 Received: from Sail.Stanford.EDU by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA10126; Fri, 6 Jan 89 22:51:39 PST Received: from lucid.com by SAIL.Stanford.EDU with TCP; 6 Jan 89 22:45:28 PST Received: from bhopal ([192.9.200.13]) by heavens-gate id AA08230g; Fri, 6 Jan 89 22:40:51 PST Received: by bhopal id AA02511g; Fri, 6 Jan 89 22:43:05 PST Date: Fri, 6 Jan 89 22:43:05 PST From: Jon L White Message-Id: <8901070643.AA02511@bhopal> To: Gray@DSG.csc.ti.com Cc: Moon@STONY-BROOK.SCRC.Symbolics.COM, jrose@Sun.COM, Common-Lisp-Object-System@SAIL.STANFORD.EDU, Cl-compiler@SAIL.STANFORD.EDU In-Reply-To: David N Gray's message of Fri, 6 Jan 89 11:17:49 CST <2809099069-8494933@Kelvin> Subject: Compilation implications re: [CLOS Chapter 3 stuff] Hmm, well maybe portable code won't want to be using that just yet. re: > Does your macro expander for DEFMETHOD call EVAL to get the object, > rather than returning a form to be evaluated later? Yes, the evaluation is being done at macro expansion time. If that's not right, I'll need to change it. A few things weigh against the evaluation being done at macroexpansion time: -- Lucid's DEFSTRUCT implementation does some of the work of the defstruct definition at macro-expansion time, and the rest at the subsequent evaluation time (when that macro-expanded form is finally evaluated). This has caused numerous headaches, such as in trying to fully macroexpand a form like: (progn (defstruct foo a b c) (defstruct (bar (:include foo)) d e) ) [The bug is that the second defstruct cannot be macroexpanded, because it cannot :include the first one until the first defstruct has been truly evaluated.] Were it not for other constraints, we probably would have fixed this long ago. In summary, always have a macroexpander return a "simple" program rather than "part program, and part (constant) data containing pre-calculated evaluations." -- Treated as a program, the (FOO) in a specializer (EQL (FOO)) poses no special problems in cross-compiling; but treating it as a kind of constant designator (implying object creation at compile time) requires a tremendous amount more of the runtime class hierarchy to be "present and accounted for" in the cross-compiling environment. -- In PCL, Gregor took the "program" approach rather than the "data" one; Moon has gone on record favoring it too. And although I dislike the approach taken for DEFCONSTANT by most implentations, it too favors the "program" approach. It sure would be nice for eql specializers not to have to fall into the horrible controversy surrounding compiled constants (i.e., those other than DEFCONSTANT constants). -- JonL -- P.S. This part of the discussion seemed relevant to the cl-compiler group also; messages dealing primarly with CLASS semantics, however, probably don't need to be cc'd there. From Owners-CommonLoops.pa@Xerox.COM Mon Jan 9 18:36:00 1989 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA24605; Mon, 9 Jan 89 18:36:00 PST Received: from Cabernet.ms by ArpaGateway.ms ; 09 JAN 89 18:30:41 PST Return-Path: Redistributed: CommonLoops.pa Received: from shire.cs.psu.edu ([128.118.6.4]) by Xerox.COM ; 09 JAN 89 18:29:05 PST Received: by shire.cs.psu.edu (4.0/PSUCS-0.0) id AA20161; Mon, 9 Jan 89 20:35:20 EST Date: Mon, 9 Jan 89 20:35:20 EST From: maida@shire.cs.psu.edu (Anthony Maida) Message-Id: <8901100135.AA20161@shire.cs.psu.edu> To: CommonLoops.pa@Xerox.COM Subject: pcl What is the internet address of the machine for ftp-ing PCL? Thank you, Anthony Maida From Common-Lisp-Object-System-mailer@SAIL.STANFORD.EDU Tue Jan 10 19:21:50 1989 Received: from Sail.Stanford.EDU by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA11028; Tue, 10 Jan 89 19:03:51 PST Received: from Sun.COM by SAIL.Stanford.EDU with TCP; 10 Jan 89 19:03:59 PST Received: from snail.Sun.COM by Sun.COM (4.1/SMI-4.0) id AA17216; Tue, 10 Jan 89 19:04:42 PST Received: from lukasiewicz.sun.com by snail.Sun.COM (4.1/SMI-4.0) id AA16547; Tue, 10 Jan 89 19:01:19 PST Received: by lukasiewicz.sun.com (4.0/SMI-4.0) id AA10509; Tue, 10 Jan 89 19:03:49 PST Date: Tue, 10 Jan 89 19:03:49 PST From: jrose@Sun.COM (John Rose) Message-Id: <8901110303.AA10509@lukasiewicz.sun.com> To: Moon@STONY-BROOK.SCRC.Symbolics.COM Cc: Gray@DSG.csc.ti.com, jonl@lucid.com, Common-Lisp-Object-System@SAIL.STANFORD.EDU, CL-Compiler@SAIL.STANFORD.EDU In-Reply-To: David A. Moon's message of Sat, 7 Jan 89 01:04 EST <19890107060409.4.MOON@EUPHRATES.SCRC.Symbolics.COM> Subject: MAKE-LOAD-FORM can handle circularities [was Compilation implications] Date: Sat, 7 Jan 89 01:04 EST From: David A. Moon Date: Thu, 5 Jan 89 19:06:02 CST From: David N Gray > Probably it would be a better idea for MAKE-LOAD-FORM to return two > values, where the first value is a form that will create the object and > the second value is a form that will further initialize the object? > This way the order of evaluation requirement is more explicit. It's > upward compatible since the second value can be NIL if you don't need > it. Yes, that sounds good except for the problem of how to pass the object to the second form. ... What I had in mind was ((LAMBDA (object) ...code...)). But I like your suggestion of evaluating the form in an environment where * is bound to the object better. Other people should check me on this, it might just be that you appealed to my sense of hackish kludgery. There's a less kludgey way to get this taken care of: Simply allow the second form to contain a reference to the object being dumped. Neat, yes? File-level EQ preservation works to restore the embedded object reference "for free". And, while we're at it, give the programmer a break, and let the second form be optional. Here's a more complete description of these ideas: Define a generic function MAKE-LOAD-FORM which takes one argument and returns one or two values. This function is called whenever COMPILE-FILE needs to dump an object whose class is of type STANDARD-CLASS or STRUCTURE-CLASS. (Call these types "user defined".) It returns one or two Lisp forms, which when passed at load time to EVAL will construct an object which is, in some class-specific sense, "equivalent" to the original object. Call the first form returned by MAKE-LOAD-FORM the "allocator", and the second form the "initializer". The allocator must wholly or partially build the reconstructed object, and return an ordinary Lisp reference to it. The initializer, if supplied and non-null, must finish any initialization required by the object's class. It is an error if the result of this second form is not EQ to the result of the first. Both the allocator and initializer are dumped to and restored from the binary file by COMPILE-FILE, by the usual means. It is expected that they will consist of list structure, possibly with object of user-defined type at the fringe. The allocator must be dumpable without reference to the original object. That is, in the process of dumping the original object, the dumper must not be called upon to output the original object again until the allocator has been completely dumped. The initializer may contain references to arbitrary objects. In particular, it will typically contain a reference to the original object. Because all references to a given object in a compiled file remain EQ across load, this can be reliably ensured simply by having MAKE-LOAD-FORM return a reference to the original object embedded in its second argument. While the initializer form is being read in, the reconstructed object is possibly in an uninitialized state, analogous to the state of an object between the time its reference has been created by ALLOCATE-INSTANCE and it has been processed fully by INITIALIZE-INSTANCE. Implementors must take care in manipulating objects referenced by allocator and initializer forms, as they would in manipulating partially initialized objects inside INITIALIZE-INSTANCE. (Think of the allocator as creating a reference to a chunk of storage, which stands in for the object until such time as the initializer can really create it. Meanwhile, the reference can be stored in other data structure, and such stored references will become fully valid when the object is finally initialized.) Note that it is possible for uninitialized objects to appear in either of the allocator or initializer forms, but when the loading process completes, all initalizers will have been run. A programmer of a certain class may elect to return a null initializer, and perform all initialization in the allocator (which could then be a simple call to MAKE-INSTANCE). In this case, some circular data structures involving that class will not be dumpable. However, such "simply dumped" classes may take part in circularities, as long as any such a circularity includes at least one object which returns two values for MAKE-LOAD-FORM, and whose allocator form breaks the circularity by omitting all references to the next object in the circle. Therefore, not all classes need support the two-phase dumping protocol. (Roughly speaking, in order to win, you need to have "enough" classes with "small" allocator forms.) Example: (defclass tree-with-parent () (parent children)) (defmethod make-load-form ((x tree-with-parent)) (values `(allocate-instance (class-of x) :children ',(slot-value x 'children)) `(initialize-instance ',x :parent ',(slot-value x 'parent)))) From Common-Lisp-Object-System-mailer@SAIL.STANFORD.EDU Tue Jan 10 20:58:04 1989 Received: from Sail.Stanford.EDU by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA12661; Tue, 10 Jan 89 20:58:04 PST Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 10 Jan 89 20:58:02 PST Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 519020; 10 Jan 89 23:55:07 EST Date: Tue, 10 Jan 89 23:54 EST From: David A. Moon Subject: MAKE-LOAD-FORM can handle circularities [was Compilation implications] To: John Rose Cc: Gray@DSG.csc.ti.com, jonl@lucid.com, Common-Lisp-Object-System@SAIL.STANFORD.EDU, CL-Compiler@SAIL.STANFORD.EDU In-Reply-To: <8901110303.AA10509@lukasiewicz.sun.com> Message-Id: <19890111045446.1.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Tue, 10 Jan 89 19:03:49 PST From: jrose@Sun.COM (John Rose) Simply allow the second form to contain a reference to the object being dumped. Neat, yes? File-level EQ preservation works to restore the embedded object reference "for free". Right. You are so smart! And, while we're at it, give the programmer a break, and let the second form be optional. That was always the intention. Complex capabilities shouldn't make doing simple things harder. Here's a more complete description of these ideas: I pretty much agree with your description. I still hope to find time to write a second version of the proposal, which will incorporate what you said, except that I will try to write it in less implementation oriented terms and more language oriented terms. Define a generic function MAKE-LOAD-FORM which takes one argument and returns one or two values. This function is called whenever COMPILE-FILE needs to dump an object whose class is of type STANDARD-CLASS or STRUCTURE-CLASS. (Call these types "user defined".) It returns one or two Lisp forms, which when passed at load time to EVAL will construct an object which is, in some class-specific sense, "equivalent" to the original object. Call the first form returned by MAKE-LOAD-FORM the "allocator", and the second form the "initializer". The allocator must wholly or partially build the reconstructed object, and return an ordinary Lisp reference to it. The initializer, if supplied and non-null, must finish any initialization required by the object's class. It is an error if the result of this second form is not EQ to the result of the first. If you remove this seemingly useless error check, you don't have to special case NIL as a second value. (EVAL NIL) never hurts. Both the allocator and initializer are dumped to and restored from the binary file by COMPILE-FILE, by the usual means. It is expected that they will consist of list structure, possibly with object of user-defined type at the fringe. The allocator must be dumpable without reference to the original object. That is, in the process of dumping the original object, the dumper must not be called upon to output the original object again until the allocator has been completely dumped. The initializer may contain references to arbitrary objects. In particular, it will typically contain a reference to the original object. Because all references to a given object in a compiled file remain EQ across load, this can be reliably ensured simply by having MAKE-LOAD-FORM return a reference to the original object embedded in its second argument. While the initializer form is being read in, the reconstructed object is possibly in an uninitialized state, analogous to the state of an object between the time its reference has been created by ALLOCATE-INSTANCE and it has been processed fully by INITIALIZE-INSTANCE. Implementors must take care in manipulating objects referenced by allocator and initializer forms, as they would in manipulating partially initialized objects inside INITIALIZE-INSTANCE. (Think of the allocator as creating a reference to a chunk of storage, which stands in for the object until such time as the initializer can really create it. Meanwhile, the reference can be stored in other data structure, and such stored references will become fully valid when the object is finally initialized.) Note that it is possible for uninitialized objects to appear in either of the allocator or initializer forms, but when the loading process completes, all initalizers will have been run. A programmer of a certain class may elect to return a null initializer, and perform all initialization in the allocator (which could then be a simple call to MAKE-INSTANCE). In this case, some circular data structures involving that class will not be dumpable. However, such "simply dumped" classes may take part in circularities, as long as any such a circularity includes at least one object which returns two values for MAKE-LOAD-FORM, and whose allocator form breaks the circularity by omitting all references to the next object in the circle. Therefore, not all classes need support the two-phase dumping protocol. (Roughly speaking, in order to win, you need to have "enough" classes with "small" allocator forms.) Example: (defclass tree-with-parent () (parent children)) (defmethod make-load-form ((x tree-with-parent)) (values `(allocate-instance (class-of x) :children ',(slot-value x 'children)) `(initialize-instance ',x :parent ',(slot-value x 'parent)))) The example needs some debugging. From Common-Lisp-Object-System-mailer@SAIL.STANFORD.EDU Wed Jan 11 14:21:46 1989 Received: from Sail.Stanford.EDU by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA25229; Wed, 11 Jan 89 14:21:46 PST Received: from ti.com by SAIL.Stanford.EDU with TCP; 11 Jan 89 12:18:09 PST Received: by ti.com id AA10250; Wed, 11 Jan 89 11:50:52 CST Received: from Kelvin by tilde id AA26201; Wed, 11 Jan 89 11:36:49 CST Message-Id: <2809532336-3923292@Kelvin> Sender: GRAY@Kelvin.csc.ti.com Date: Wed, 11 Jan 89 11:38:56 CST From: David N Gray To: jrose@Sun.COM (John Rose) Cc: Moon@STONY-BROOK.SCRC.Symbolics.COM, jonl@lucid.com, Common-Lisp-Object-System@SAIL.STANFORD.EDU Subject: Re: MAKE-LOAD-FORM can handle circularities [was Compilation implications] In-Reply-To: Msg of Tue, 10 Jan 89 19:03:49 PST from jrose@Sun.COM (John Rose) > Simply allow the second form to contain a reference to the object > being dumped. > > Neat, yes? File-level EQ preservation works to restore the embedded > object reference "for free". Yes. > Define a generic function MAKE-LOAD-FORM which takes one argument and > returns one or two values. This function is called whenever > COMPILE-FILE needs to dump an object whose class is of type > STANDARD-CLASS or STRUCTURE-CLASS. Or if its class is a user-defined metaclass, even if not a subclass of STANDARD-CLASS. Maybe it would be best to say anything whose metaclass is not BUILT-IN-CLASS. > The allocator must wholly or partially build the reconstructed object, > and return an ordinary Lisp reference to it. The initializer, if > supplied and non-null, must finish any initialization required by the > object's class. It is an error if the result of this second form is not > EQ to the result of the first. It would be a convenient convention for the second form to return the object, but the value returned by the second form would not actually be used for anything, so it doesn't need to be constrained. Or maybe you just want to verify that it did what it was intended to? > Example: > (defclass tree-with-parent () (parent children)) > (defmethod make-load-form ((x tree-with-parent)) > (values > `(allocate-instance (class-of x) :children ',(slot-value x 'children)) > `(initialize-instance ',x :parent ',(slot-value x 'parent)))) This isn't quite right because ALLOCATE-INSTANCE doesn't fill in any slot values. Maybe what you want is something like (defclass tree-with-parent () ((parent :accessor tree-parent) (children :initarg :children))) (defmethod make-load-form ((x tree-with-parent)) (values `(make-instance ',(class-of x) :children ',(slot-value x 'children)) `(setf (tree-parent ',x) ',(slot-value x 'parent)))) From Common-Lisp-Object-System-mailer@SAIL.STANFORD.EDU Wed Jan 11 14:31:29 1989 Received: from Sail.Stanford.EDU by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA25283; Wed, 11 Jan 89 14:31:29 PST Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 11 Jan 89 12:25:28 PST Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 519263; Wed 11-Jan-89 12:37:35 EST Date: Wed, 11 Jan 89 12:37 EST From: David A. Moon Subject: MAKE-LOAD-FORM can handle circularities [was Compilation implications] To: Eric Benson Cc: jrose@Sun.COM, Gray@DSG.csc.ti.com, jonl@lucid.com, Common-Lisp-Object-System@SAIL.STANFORD.EDU, CL-Compiler@SAIL.STANFORD.EDU In-Reply-To: <8901111659.AA01229@blacksox> Message-Id: <19890111173731.3.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Wed, 11 Jan 89 08:59:40 pst From: Eric Benson The dumper should be allowed to compile the forms returned by MAKE-LOAD-FORM. That would be a way of trading increased dumping time for decreased loading time. If the file is to be loaded many times that would be a desirable trade-off. Also, it is then possible to load it into a Lisp that has no EVAL. I agree. Didn't the version 1 writeup say that? From Common-Lisp-Object-System-mailer@SAIL.STANFORD.EDU Wed Jan 11 14:31:33 1989 Received: from Sail.Stanford.EDU by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA25288; Wed, 11 Jan 89 14:31:33 PST Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 11 Jan 89 12:25:38 PST Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 519270; Wed 11-Jan-89 12:53:09 EST Date: Wed, 11 Jan 89 12:53 EST From: David A. Moon Subject: Re: MAKE-LOAD-FORM can handle circularities [was Compilation implications] To: Sandra J Loosemore Cc: John Rose , Gray@DSG.csc.ti.com, jonl@lucid.com, Common-Lisp-Object-System@SAIL.STANFORD.EDU, CL-Compiler@SAIL.STANFORD.EDU In-Reply-To: <8901111611.AA12297@defun.utah.edu> Message-Id: <19890111175308.4.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Wed, 11 Jan 89 09:11:57 MST From: sandra%defun@cs.utah.edu (Sandra J Loosemore) Just to set the record straight: > Date: Tue, 10 Jan 89 19:03:49 PST > From: jrose@Sun.COM (John Rose) > > File-level EQ preservation works to restore the embedded > object reference "for free". Unfortunately, we don't know yet if file-level EQ preservation works; see issue CONSTANT-CIRCULAR-COMPILATION. KCL is one implementation where COMPILE-FILE/LOAD does not now preserve EQness of structures. If file-level EQ preservation is punted, MAKE-LOAD-FORM only returns one value, and this whole discussion is punted. So it doesn't actually matter that we don't know yet (except that we might be wasting our time). Personally, I think file-level EQ preservation is important and would hate to see it excluded from the language specification. To throw a digression into the discussion, the only thing I know of that's hard about file-level EQ preservation is EQness of CDRs in implementations with cdr-coding of lists. Even that's only "hard" in the sense that it is difficult to convince implementors to do EQness checking by treating each individual cons as a separate object, rather than treating the whole list as a single object, because it seems (and in fact is) less efficient. Symbolics Genera 7.x gets this wrong. What about the TI Explorer? From CL-Compiler-mailer@SAIL.STANFORD.EDU Wed Jan 11 14:42:37 1989 Received: from Sail.Stanford.EDU by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA25345; Wed, 11 Jan 89 14:42:37 PST Received: from cs.utah.edu ([128.110.4.21]) by SAIL.Stanford.EDU with TCP; 11 Jan 89 12:26:15 PST Received: from defun.utah.edu by cs.utah.edu (5.59/utah-2.1-cs) id AA04433; Wed, 11 Jan 89 09:12:22 MST Received: by defun.utah.edu (5.59/utah-2.0-leaf) id AA12297; Wed, 11 Jan 89 09:11:58 MST From: sandra%defun@cs.utah.edu (Sandra J Loosemore) Message-Id: <8901111611.AA12297@defun.utah.edu> Date: Wed, 11 Jan 89 09:11:57 MST Subject: Re: MAKE-LOAD-FORM can handle circularities [was Compilation implications] To: jrose@Sun.COM (John Rose) Cc: Moon@STONY-BROOK.SCRC.Symbolics.COM, Gray@DSG.csc.ti.com, jonl@lucid.com, Common-Lisp-Object-System@SAIL.STANFORD.EDU, CL-Compiler@SAIL.STANFORD.EDU In-Reply-To: jrose@Sun.COM (John Rose), Tue, 10 Jan 89 19:03:49 PST Just to set the record straight: > Date: Tue, 10 Jan 89 19:03:49 PST > From: jrose@Sun.COM (John Rose) > > File-level EQ preservation works to restore the embedded > object reference "for free". Unfortunately, we don't know yet if file-level EQ preservation works; see issue CONSTANT-CIRCULAR-COMPILATION. KCL is one implementation where COMPILE-FILE/LOAD does not now preserve EQness of structures. -Sandra ------- From CL-Compiler-mailer@SAIL.STANFORD.EDU Wed Jan 11 14:43:26 1989 Received: from Sail.Stanford.EDU by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA25366; Wed, 11 Jan 89 14:43:26 PST Received: from lucid.com ([192.26.25.1]) by SAIL.Stanford.EDU with TCP; 11 Jan 89 12:33:14 PST Received: from blacksox ([192.9.201.39]) by heavens-gate.lucid.com id AA03444g; Wed, 11 Jan 89 08:57:15 PST Received: by blacksox id AA01229g; Wed, 11 Jan 89 08:59:40 pst Date: Wed, 11 Jan 89 08:59:40 pst From: Eric Benson Message-Id: <8901111659.AA01229@blacksox> To: Moon@STONY-BROOK.SCRC.Symbolics.COM Cc: jrose@Sun.COM, Gray@DSG.csc.ti.com, jonl@lucid.com, Common-Lisp-Object-System@SAIL.STANFORD.EDU, CL-Compiler@SAIL.STANFORD.EDU In-Reply-To: David A. Moon's message of Tue, 10 Jan 89 23:54 EST <19890111045446.1.MOON@EUPHRATES.SCRC.Symbolics.COM> Subject: MAKE-LOAD-FORM can handle circularities [was Compilation implications] The dumper should be allowed to compile the forms returned by MAKE-LOAD-FORM. That would be a way of trading increased dumping time for decreased loading time. If the file is to be loaded many times that would be a desirable trade-off. Also, it is then possible to load it into a Lisp that has no EVAL. From CL-Compiler-mailer@SAIL.STANFORD.EDU Wed Jan 11 15:06:01 1989 Received: from Sail.Stanford.EDU by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA26037; Wed, 11 Jan 89 15:06:01 PST Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 11 Jan 89 14:47:27 PST Received: from defun.utah.edu by cs.utah.edu (5.59/utah-2.1-cs) id AA17453; Wed, 11 Jan 89 15:44:43 MST Received: by defun.utah.edu (5.59/utah-2.0-leaf) id AA12661; Wed, 11 Jan 89 15:44:31 MST From: sandra%defun@cs.utah.edu (Sandra J Loosemore) Message-Id: <8901112244.AA12661@defun.utah.edu> Date: Wed, 11 Jan 89 15:44:29 MST Subject: Re: MAKE-LOAD-FORM can handle circularities [was Compilation implications] To: Eric Benson Cc: Moon@STONY-BROOK.SCRC.Symbolics.COM, jrose@Sun.COM, Gray@DSG.csc.ti.com, jonl@lucid.com, Common-Lisp-Object-System@SAIL.STANFORD.EDU, CL-Compiler@SAIL.STANFORD.EDU In-Reply-To: Eric Benson , Wed, 11 Jan 89 08:59:40 pst > The dumper should be allowed to compile the forms returned by > MAKE-LOAD-FORM. This sounds like a good use for the proposed new LOAD-TIME-VALUE special form. -Sandra ------- From CL-Compiler-mailer@SAIL.STANFORD.EDU Wed Jan 11 15:23:30 1989 Received: from Sail.Stanford.EDU by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA26311; Wed, 11 Jan 89 15:23:30 PST Received: from lucid.com ([192.26.25.1]) by SAIL.Stanford.EDU with TCP; 11 Jan 89 12:59:51 PST Received: from blacksox ([192.9.201.39]) by heavens-gate.lucid.com id AA03707g; Wed, 11 Jan 89 12:55:13 PST Received: by blacksox id AA01277g; Wed, 11 Jan 89 12:57:38 pst Date: Wed, 11 Jan 89 12:57:38 pst From: Eric Benson Message-Id: <8901112057.AA01277@blacksox> To: Moon@STONY-BROOK.SCRC.Symbolics.COM Cc: jrose@Sun.COM, Gray@DSG.csc.ti.com, jonl@lucid.com, Common-Lisp-Object-System@SAIL.STANFORD.EDU, CL-Compiler@SAIL.STANFORD.EDU In-Reply-To: David A. Moon's message of Wed, 11 Jan 89 12:37 EST <19890111173731.3.MOON@EUPHRATES.SCRC.Symbolics.COM> Subject: MAKE-LOAD-FORM can handle circularities [was Compilation implications] Date: Wed, 11 Jan 89 12:37 EST From: David A. Moon Date: Wed, 11 Jan 89 08:59:40 pst From: Eric Benson The dumper should be allowed to compile the forms returned by MAKE-LOAD-FORM. That would be a way of trading increased dumping time for decreased loading time. If the file is to be loaded many times that would be a desirable trade-off. Also, it is then possible to load it into a Lisp that has no EVAL. I agree. Didn't the version 1 writeup say that? Maybe it did. Some CL mail has gotten lost on its way here, due to lossage at SAIL. Or I might have just overlooked it. From CL-Cleanup-mailer@SAIL.STANFORD.EDU Fri Jan 13 15:06:14 1989 Received: from Sail.Stanford.EDU by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA00551; Fri, 13 Jan 89 15:06:14 PST Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 13 Jan 89 14:53:53 PST Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 521325; Fri 13-Jan-89 17:52:09 EST Date: Fri, 13 Jan 89 17:52 EST From: David A. Moon Subject: Issue: LOAD-OBJECTS (Version 2) To: CL-Cleanup@SAIL.STANFORD.EDU Cc: Common-Lisp-Object-System@SAIL.STANFORD.EDU, CL-Compiler@SAIL.STANFORD.EDU Message-Id: <19890113225201.0.MOON@EUPHRATES.SCRC.Symbolics.COM> Here is the updated version of this. Sorry it took so long. I will bring a few copies of this with me to the meeting. Issue: LOAD-OBJECTS References: none Related issues: LOAD-TIME-EVAL, CONSTANT-COMPILABLE-TYPES, CONSTANT-CIRCULAR-COMPILATION Category: ADDITION Forum: Cleanup Edit history: Version 1, 2-Jan-89, by Moon (for discussion) Version 2, 13-Jan-89, by Moon (draft updated from discussion) Problem description: Common Lisp doesn't provide any way to use an object of a user-defined type (defined with DEFCLASS or DEFSTRUCT) as a constant in a program compiled with COMPILE-FILE. The problem is that LOAD has to be able to "reconstruct" an equivalent object when the compiled-code file is loaded, but the programmer has no way to tell LOAD how to do that. Proposal (LOAD-OBJECTS:MAKE-LOAD-FORM): Define a new generic function named MAKE-LOAD-FORM, which takes one argument and returns two values. The argument is an object that is referenced as a constant or as a self-evaluating form in a file being compiled by COMPILE-FILE. The objective is to enable LOAD to construct an equivalent object. The first value, called the "creation form," is a form that, when evaluated at load time, should return an object that is equivalent to the argument. The exact meaning of "equivalent" depends on the type of object and is up to the programmer who defines a method for MAKE-LOAD-FORM. This is the same type of equivalence discussed in issue CONSTANT-COMPILABLE-TYPES. The second value, called the "initialization form," is a form that, when evaluated at load time, should perform further initialization of the object. The value returned by the initialization form is ignored. If the MAKE-LOAD-FORM method returns only one value, the initialization form is NIL, which has no effect. If the object used as the argument to MAKE-LOAD-FORM appears as a constant in the initialization form, at load time it will be replaced by the equivalent object constructed by the creation form; this is how the further initialization gains access to the object. Both the creation form and the initialization form can contain references to objects of user-defined types (defined precisely below). However, there must not be any circular dependencies in creation forms. An example of a circular dependency is when the creation form for the object X contains a reference to the object Y, and the creation form for the object Y contains a reference to the object X. A simpler example would be when the creation form for the object X contains a reference to X itself. Initialization forms are not subject to any restriction against circular dependencies, which is the entire reason that initialization forms exist. See the example of circular data structures below. The creation form for an object is always evaluated before the initialization form for that object. When either the creation form or the initialization form references other objects of user-defined types that have not been referenced earlier in the COMPILE-FILE, the compiler collects all of the creation forms together and collects all of the initialization forms together. All of the creation forms are evaluated before any of the initialization forms. The order of evaluation of the creation forms is unspecified except when the ordering is forced by data dependencies. The order of evaluation of the initialization forms is unspecified. While these creation and initialization forms are being evaluated, the objects are possibly in an uninitialized state, analogous to the state of an object between the time it has been created by ALLOCATE-INSTANCE and it has been processed fully by INITIALIZE-INSTANCE. Programmers writing methods for MAKE-LOAD-FORM must take care in manipulating objects not to depend on slots that have not yet been initialized. It is unspecified whether LOAD calls EVAL on the forms or does some other operation that has an equivalent effect. For example, the forms might be translated into different but equivalent forms and then evaluated, they might be compiled and the resulting functions called by LOAD, or they might be interpreted by a special-purpose interpreter different from EVAL. All that is required is that the effect be equivalent to evaluating the forms. COMPILE-FILE calls MAKE-LOAD-FORM on any object that is referenced as a constant or as a self-evaluating form, if the object's metaclass is STANDARD-CLASS, STRUCTURE-CLASS, any user-defined metaclass (not a subclass of BUILT-IN-CLASS), or any of a possibly-empty implementation-defined list of other metaclasses. COMPILE-FILE will only call MAKE-LOAD-FORM once for any given object (compared with EQ) within a single file. It is valid for user programs to call MAKE-LOAD-FORM in other circumstances. The function MAKE-LOAD-FORM-USING-SLOTS can be useful in user-written MAKE-LOAD-FORM methods. Its first argument is the object. Its optional second argument is a list of the names of the slots to preserve; it defaults to all of the local slots. MAKE-LOAD-FORM-USING-SLOTS returns forms that construct an equivalent object using MAKE-INSTANCE and SETF of SLOT-VALUE for slots with values, or SLOT-MAKUNBOUND for slots without values, or using other functions of equivalent effect. MAKE-LOAD-FORM-USING-SLOTS returns two values, thus it can deal with circular structures. The default MAKE-LOAD-FORM method for STANDARD-OBJECT signals an error. The default MAKE-LOAD-FORM method for STRUCTURE-OBJECT returns forms that construct an equivalent structure based on the structure name and the slot values. This might be written using MAKE-LOAD-FORM-USING-SLOTS, but that is not required. Examples: ;; Example 1 (defclass my-class () ((a :initarg :a :reader my-a) (b :initarg :b :reader my-b) (c :accessor my-c))) (defmethod shared-initialize ((self my-class) ignore &rest ignore) (unless (slot-boundp self 'c) (setf (my-c self) (some-computation (my-a self) (my-b self))))) (defmethod make-load-form ((self my-class)) `(make-instance ',(class-name (class-of self)) :a ',(my-a self) :b ',(my-b self))) In this example, an equivalent instance of my-class is reconstructed by using the values of two of its slots. The value of the third slot is derived from those two values. Another way to write the last form in the above example would have been (defmethod make-load-form ((self my-class)) (make-load-form-using-slots self '(a b))) ;; Example 2 (defclass my-frob () ((name :initarg :name :reader my-name))) (defmethod make-load-form ((self my-frob)) `(find-my-frob ',(my-name self) :if-does-not-exist :create)) In this example, instances of my-frob are "interned" in some way. An equivalent instance is reconstructed by using the value of the name slot as a key for searching existing objects. In this case the programmer has chosen to create a new object if no existing object is found; alternatively she could have chosen to signal an error in that case. ;; Example 3 (defclass tree-with-parent () ((parent :accessor tree-parent) (children :initarg :children))) (defmethod make-load-form ((x tree-with-parent)) (values ;; creation form `(make-instance ',(class-of x) :children ',(slot-value x 'children)) ;; initialization form `(setf (tree-parent ',x) ',(slot-value x 'parent)))) In this example, the data structure to be dumped is circular, because each parent has a list of its children and each child has a reference back to its parent. Suppose make-load-form is called on one object in such a structure. The creation form creates an equivalent object and fills in the children slot, which forces creation of equivalent objects for all of its children, grandchildren, etc. At this point none of the parent slots have been filled in. The initialization form fills in the parent slot, which forces creation of an equivalent object for the parent if it was not already created. Thus the entire tree is recreated at load time. At compile time, MAKE-LOAD-FORM is called once for each object in the true. All of the creation forms are evaluated, in unspecified order, and then all of the initialization forms are evaluated, also in unspecified order. Rationale: Only the programmer who designed a class can know the correct way to reconstruct objects of that class at load time, therefore the reconstruction should be controlled by a generic function. Using EVAL as the interface for telling LOAD what to do provides full generality. MAKE-LOAD-FORM returns two values so that circular structures can be handled. If CONSTANT-CIRCULAR-COMPILATION is rejected, MAKE-LOAD-FORM will only return one value, although implementations that make an extension to support circular constants will probably also make the extension to accept two values from MAKE-LOAD-FORM. A default method, such as one that makes an object whose class has the same name and whose slots have equivalent contents, is not supplied for DEFCLASS-defined objects, because this is inappropriate for many objects and because it is easy to write for those objects where it is appropriate. The function MAKE-LOAD-FORM-USING-SLOTS makes it even easier to write. MAKE-LOAD-FORM has a natural resemblance to PRINT-OBJECT, as a hook for the programmer to control the system's actions. Current practice: Symbolics Flavors has something like this, but under a different name. The name Symbolics uses is not suitable for standardization. JonL reports that Lucid is getting more and more requests for this. Cost to Implementors: This seems like only a few one-line changes in the compiled-code file writer and reader. MAKE-LOAD-FORM-USING-SLOTS is a couple dozen lines of code, assuming the presence of the CLOS metaobject protocol or an implementation-dependent equivalent. Cost to Users: None. Cost of non-adoption: Serious impairment of the ability to use extended-type objects. Each implementation will probably make up its own version of this as an extension. Performance impact: None. Benefits: See Cost of non-adoption. Esthetics: No significant positive or negative impact. Discussion: It would be possible to define an additional level of protocol that allows multiple classes to contribute to the reconstruction of an object, combining initialization arguments contributed by each class. Since a user can easily define that in terms of MAKE-LOAD-FORM without modifying the Lisp system, it is not being proposed now. Any type that has a read syntax is likely to appear as a quoted constant or inside a quoted constant. Pathnames are one example, user programs often define others. Also many implementations provide a way to create a compiled-code file full of data (rather than compiled Lisp programs), and such data probably include extended-type objects. Moon supports this. David Gray and John Rose made major contributions to the discussion that produced this improved version 2 proposal. From CL-Cleanup-mailer@SAIL.STANFORD.EDU Fri Jan 13 16:10:02 1989 Received: from Sail.Stanford.EDU by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA01530; Fri, 13 Jan 89 16:10:02 PST Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 13 Jan 89 16:02:32 PST Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 521384; Fri 13-Jan-89 19:00:48 EST Date: Fri, 13 Jan 89 19:00 EST From: Kent M Pitman Subject: Issue: LOAD-OBJECTS (Version 2) To: Moon@STONY-BROOK.SCRC.Symbolics.COM Cc: CL-Cleanup@SAIL.STANFORD.EDU, Common-Lisp-Object-System@SAIL.STANFORD.EDU, CL-Compiler@SAIL.STANFORD.EDU In-Reply-To: <19890113225201.0.MOON@EUPHRATES.SCRC.Symbolics.COM> Message-Id: <890113190027.7.KMP@BOBOLINK.SCRC.Symbolics.COM> This looks mostly very good, but ... I'd like to see a name attached to the default function for making structure load forms, since you're requiring it to exist anyway, and also since there might be reason to need to revert to using it in some structure class for which the method is shadowed by a superior class that was not `thinking ahead.' [I call this problem the `DESCRIBE problem,' since the analagous problem comes up there, too.] I also think there needs to be a rationale given to making these functions not be the default. My personal feeling is that if it's undefined for structures, it should be undefined for instances, and vice versa. In my mind, they serve the same conceptual purpose, and differ only in degree of efficiency and syntax of interface. For me, they do not differ in weird ways like whether EQUAL or EQUALP should treat them differently, or whether MAKE-LOAD-FORM should know how to dump them. I think the argument you give for not having a default instance-dumping strategy applies equally to struct-dumping, so if you're going to make them differ, you need to say what your reasoning is. From Gregor.pa@Xerox.COM Fri Jan 13 16:26:44 1989 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA01722; Fri, 13 Jan 89 16:26:44 PST Received: from Semillon.ms by ArpaGateway.ms ; 13 JAN 89 11:06:24 PST Date: Fri, 13 Jan 89 11:03 PST From: Gregor.pa@Xerox.COM Subject: code walker -- ticl::let-if To: goldman@vaxa.isi.edu Cc: commonloops.pa@Xerox.COM Fcc: BD:>Gregor>mail>outgoing-mail-5.text.newest In-Reply-To: <8901131755.AA12097@vaxa.isi.edu> Message-Id: <19890113190308.8.GREGOR@SPIFF.parc.xerox.com> Line-Fold: no Does let-if in TICL only bind special variables? If so, the following should work. I haven't tested it though. Let us know so that we can add it to the sources. #+TI (define-walker-template TICL::LET-IF walk-let-if) #+TI (defun walk-let-if (form context env) (let ((test (cadr form)) (bindings (caddr form)) (body (cdddr form))) (walk-form-internal `(let () (declare (special ,@(mapcar #'(lambda (x) (if (listp x) (car x) x)) bindings))) (flet ((.let-if-dummy. () ,@body)) (if ,test (let ,bindings (.let-if-dummy.)) (.let-if-dummy.)))) context env))) ------- From Owners-commonloops.pa@Xerox.COM Fri Jan 13 16:36:58 1989 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA02011; Fri, 13 Jan 89 16:36:58 PST Received: from Salvador.ms by ArpaGateway.ms ; 13 JAN 89 13:14:18 PST Return-Path: Redistributed: commonloops.pa Received: from cs2.wsu.edu ([192.31.216.52]) by Xerox.COM ; 13 JAN 89 13:12:03 PST Received: by cs2.wsu.edu (5.59/25-eef) id AA09539; Fri, 13 Jan 89 13:12:06 PST Message-Id: <8901132112.AA09539@cs2.wsu.edu> To: commonloops.pa@Xerox.COM Subject: CLOS/KCL - New KCL? Date: Fri, 13 Jan 89 13:12:04 -0800 From: cross@cs2.wsu.edu Hi, I am trying to get the 12/7 version running on our KCL on an ATT 3B2. However, I get compilation errors. But our KCL is dated 86 and the one CLOS works on is dated October 15, 1987 in the PCL notes file. Can someone tell me how to get this later KCL via FTP or whatever? Thanks. ---- George - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - George R. Cross Computer Science Department cross@cs2.wsu.edu Washington State University cross%wsuvm1.bitnet@cunyvm.cuny.edu Pullman, WA 99164-1210 Phone: 509-335-6319 or 509-335-6636 Acknowledge-To: From Owners-commonloops.pa@Xerox.COM Fri Jan 13 16:43:46 1989 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA02301; Fri, 13 Jan 89 16:43:46 PST Received: from Cabernet.ms by ArpaGateway.ms ; 13 JAN 89 09:55:44 PST Return-Path: Redistributed: commonloops.pa Received: from vaxa.isi.edu ([128.9.0.33]) by Xerox.COM ; 13 JAN 89 09:54:00 PST Posted-Date: Fri, 13 Jan 89 09:55:09 PST Message-Id: <8901131755.AA12097@vaxa.isi.edu> Received: from LOCALHOST by vaxa.isi.edu (5.59/5.51) id AA12097; Fri, 13 Jan 89 09:55:14 PST To: commonloops.pa@Xerox.COM From: goldman@vaxa.isi.edu Subject: code walker -- ticl::let-if Date: Fri, 13 Jan 89 09:55:09 PST Sender: goldman@vaxa.isi.edu The TI explorer common lisp has a macro IGNORE-ERRORS whose macro expansion involves a ti special form called TICL::LET-IF. This causes the PCL code walker to die, [without even the right error message, because (fboundp 'ticl::let-if) is true, and PCL's code walker does not catch alien special forms if they are fboundp. Although it seems strange for a special form to be fboundp, apparently it can make sense in ti common lisp because there is yet another extension to CL, "e as a lambda list keyword!] Does anyone have a proper extension for the PCL code walker to handle TICL:LET-IF? neil From Owners-CommonLoops.pa@Xerox.COM Fri Jan 13 16:55:41 1989 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA02613; Fri, 13 Jan 89 16:55:41 PST Received: from Cabernet.ms by ArpaGateway.ms ; 13 JAN 89 15:06:12 PST Return-Path: Redistributed: CommonLoops.pa Received: from mbunix.mitre.org ([192.12.120.1]) by Xerox.COM ; 13 JAN 89 15:03:38 PST Posted-From: The MITRE Corp., Bedford, MA X-Alternate-Route: user%node@mbunix.mitre.org Return-Path: Received: from faron.MITRE.ORG by linus.MITRE.ORG (5.59/RCF-3S) id AA10977; Fri, 13 Jan 89 17:56:45 EST Posted-Date: Fri, 13 Jan 89 17:56:42 EST Received: by faron.mitre.org (4.12/RCF-3C) id AA19459; Fri, 13 Jan 89 17:56:44 est From: rich@linus.MITRE.ORG Message-Id: <8901132256.AA19459@faron.mitre.org> To: CommonLoops.pa@Xerox.COM Subject: I think there is a bug in the reader decoder Date: Fri, 13 Jan 89 17:56:42 EST I am getting some very strange behavior when using a standard accessor generic function because it sometimes never returns from the access. After a lot of debugging I was able to figure out why, sort of... When tracing DCODE-CACHE-MISS I noticed that is was being called again and again, always returning the same value (a number). I think that I may have figured out why the generic function is in the infinite loop. Below is the code that is used to build the generic function... (the standard reader decoder -- from file dcode.lisp): (define-function-template all-std-class-readers-dcode (cache-size cache-mask) '(.GENERIC-FUNCTION. .CACHE. .NEXT-SCAN-LIMIT.) (let () `(function (lambda (arg) (declare (optimize (speed 3) (safety 0))) (let ((value nil)) (all-std-class-accessors-dcode-internal nil index ,cache-size ,cache-mask #'all-std-class-readers-tertiary-miss #'make-all-std-class-readers-dcode X (progn X (setq value (%svref (iwmc-class-static-slots arg) index)) X (if (eq value ',*slot-unbound*) X (go miss) X (return-from accessor-dcode value))) (return-from accessor-dcode (slot-value arg index)))))))) If you expand this, the argument labeled with the X's is the "fast-form" argument to the macro ALL-STD-CLASS-ACCESSORS-DCODE-INTERNAL. This is the form that you call when you have a "hit" in the cache. Looking at this code, it seems strange that the slot being unbound is treated like a "miss". After all the slot could actually be unbound. Therefore the contents of the slot would be equal to whatever *slot-unbound* is set to. But not knowing all of the details of caching in PCL this might be the correct course of events. However, if we DO go to the MISS tag (see code below), we call DCODE-CACHE-MISS, which in this case returns the number of the slot. (It seems as if DCODE-CACHE-MISS returns either the slot-name or the slot-position). miss (progn (unlock-cache) (setq ,index (dcode-cache-miss .GENERIC-FUNCTION. ,tertiary-miss .CACHE. ,cache-size ,cache-mask 2 ;line size 1 ;nkeys .NEXT-SCAN-LIMIT. (< ,cache-size *all-std-class-accessors-max-cache-size*) ,dcode-constructor wrapper ,@(and writerp '(new-value)) arg)) (cond ((eq ,index '..no-applicable-method..) (return-from accessor-dcode (no-applicable-method .GENERIC-FUNCTION. arg))) ((not (symbolp ,index)) (go hit)) (t (return-from accessor-dcode ,slow-form))))))))))) Finally, this COND is executed. Since index is not ..no-applicable-method.. and it IS a number, we go to HIT. The slot is again accessed, it is still equal to whatever *slot-unbound* is equal to, so we jump to MISS, and this continues forever..... Unfortunately, this doesn't seem to happen if I just create a class on the fly, and then execute the accessor function. Additional information:, 1. A method for SLOT-UNBOUND is defined for the root object type in our hierarchy. It sets the slot to nil. 2. We are using defconstructors. I don't know if these facts will be useful..... I finally gave up because I couldn't understand why slot-unbound isn't called from the "fast-form" but instead the slot being unbound is treated like a miss in the cache. Does this make sense to anyone out there? On a lighter note, I'm surprised that nobody notice that Dec. 7 PCL should be called "Pearl Harbor Day PCL". I guess everybody has become George Bush...... From Owners-commonloops.pa@Xerox.COM Fri Jan 13 16:59:47 1989 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA02735; Fri, 13 Jan 89 16:59:47 PST Received: from Chardonnay.ms by ArpaGateway.ms ; 13 JAN 89 16:27:11 PST Return-Path: Redistributed: commonloops.pa Received: from ucbarpa.Berkeley.EDU ([128.32.137.8]) by Xerox.COM ; 13 JAN 89 16:24:10 PST Received: by ucbarpa.Berkeley.EDU (5.61/1.33) id AA20911; Fri, 13 Jan 89 16:24:08-0800 Received: from frisky by franz (3.2/3.14) id AA12928; Fri, 13 Jan 89 13:56:23 PST Received: by frisky (3.2/3.14) id AA20660; Fri, 13 Jan 89 13:51:43 PST From: jkf%frisky%franz@ucbarpa.Berkeley.EDU (John Foderaro) Return-Path: Message-Id: <8901132151.AA20660@frisky> To: commonloops.pa@Xerox.COM Subject: new fin.cl Date: Fri, 13 Jan 89 13:51:42 PST I've submitted to Xerox for distribution a version of fin.lisp with machine-dependent code permitting the Allegro (ExCL) version of PCL to run on the Cray X-MP, Amdahl (UTS), and Intel 386 machines (with the generation scavenging garbage collector). This fin.c is for the 12/7/88 (no cute name) pcl. Write me if you need the file before it is posted at Xerox. John Foderaro Franz Inc jkf%franz@berkeley.edu From Owners-commonloops.pa@Xerox.COM Fri Jan 13 18:33:52 1989 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA03729; Fri, 13 Jan 89 18:33:52 PST Received: from Cabernet.ms by ArpaGateway.ms ; 13 JAN 89 18:26:34 PST Return-Path: Redistributed: commonloops.pa Received: from WILMA.BBN.COM ([128.89.1.216]) by Xerox.COM ; 13 JAN 89 18:24:50 PST To: cross@cs2.wsu.edu Cc: commonloops.pa@Xerox.COM Subject: Re: CLOS/KCL - New KCL? In-Reply-To: Your message of Fri, 13 Jan 89 13:12:04 -0800. <8901132112.AA09539@cs2.wsu.edu> Date: Fri, 13 Jan 89 21:19:46 -0500 From: kanderso@WILMA.BBN.COM Message-Id: <890113-182634-4397@Xerox> I had similar problems until i got the lastest version of KCL. k From CL-Compiler-mailer@SAIL.STANFORD.EDU Fri Jan 13 19:39:14 1989 Received: from Sail.Stanford.EDU by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA05463; Fri, 13 Jan 89 19:39:14 PST Received: from ti.com by SAIL.Stanford.EDU with TCP; 13 Jan 89 19:36:04 PST Received: by ti.com id AA21295; Fri, 13 Jan 89 19:07:05 CST Received: from Kelvin by tilde id AA00249; Fri, 13 Jan 89 18:52:39 CST Message-Id: <2809731258-5200907@Kelvin> Sender: GRAY@Kelvin.csc.ti.com Date: Fri, 13 Jan 89 18:54:18 CST From: David N Gray To: "David A. Moon" Cc: Common-Lisp-Object-System@SAIL.STANFORD.EDU, CL-Compiler@SAIL.STANFORD.EDU Subject: Re: Issue: LOAD-OBJECTS (Version 2) In-Reply-To: Msg of Fri, 13 Jan 89 17:52 EST from David A. Moon This looks good. The only thing I have doubts about is: > The function MAKE-LOAD-FORM-USING-SLOTS can be useful in user-written > MAKE-LOAD-FORM methods. Its first argument is the object. Its > optional second argument is a list of the names of the slots to > preserve; it defaults to all of the local slots. > MAKE-LOAD-FORM-USING-SLOTS returns forms that construct an equivalent > object using MAKE-INSTANCE and SETF of SLOT-VALUE for slots with > values, or SLOT-MAKUNBOUND for slots without values, or using other > functions of equivalent effect. Rather than having the second argument default to a list of all instance slots, it might be better to consider two separate cases: 1. If a second argument is supplied, then MAKE-INSTANCE will be used to create the object, (using INITIALIZE-INSTANCE to default the slot values), and then the designated slots will be forced to have the proper value. 2. Without a second argument, ALLOCATE-INSTANCE will be used to create the object (without invoking INITIALIZE-INSTANCE or SHARED-INITIALIZE), and then all the slots will be filled in. If you are going to specify all of the slot values, then there shouldn't be a need to compute default values, and it may be undesirable to invoke INITIALIZE-INSTANCE -- for example, it might complain about missing required arguments or perform undesired side-effects. > The default MAKE-LOAD-FORM method for STANDARD-OBJECT signals an > error. Wouldn't it be permissible to just not have a default method, so that a "no applicable method" error is signalled? From CL-Cleanup-mailer@SAIL.STANFORD.EDU Fri Jan 13 21:03:34 1989 Received: from Sail.Stanford.EDU by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA06010; Fri, 13 Jan 89 21:03:34 PST Received: from Sun.COM by SAIL.Stanford.EDU with TCP; 13 Jan 89 20:58:12 PST Received: from snail.Sun.COM by Sun.COM (4.1/SMI-4.0) id AA04397; Fri, 13 Jan 89 20:59:34 PST Received: from lukasiewicz.sun.com by snail.Sun.COM (4.1/SMI-4.0) id AA22496; Fri, 13 Jan 89 20:56:15 PST Received: by lukasiewicz.sun.com (4.0/SMI-4.0) id AA18401; Fri, 13 Jan 89 20:58:49 PST Date: Fri, 13 Jan 89 20:58:49 PST From: jrose@Sun.COM (John Rose) Message-Id: <8901140458.AA18401@lukasiewicz.sun.com> To: Moon@STONY-BROOK.SCRC.Symbolics.COM Cc: CL-Cleanup@SAIL.STANFORD.EDU, Common-Lisp-Object-System@SAIL.STANFORD.EDU, CL-Compiler@SAIL.STANFORD.EDU In-Reply-To: David A. Moon's message of Fri, 13 Jan 89 17:52 EST <19890113225201.0.MOON@EUPHRATES.SCRC.Symbolics.COM> Subject: Issue: LOAD-OBJECTS (Version 2) ... The creation form for an object is always evaluated before the initialization form for that object. When either the creation form or the initialization form references other objects of user-defined types that have not been referenced earlier in the COMPILE-FILE, the compiler collects all of the creation forms together and collects all of the initialization forms together. All of the creation forms are evaluated before any of the initialization forms. The order of evaluation of the creation forms is unspecified except when the ordering is forced by data dependencies. The order of evaluation of the initialization forms is unspecified. ... Why does the proposal restrict the evaluation initialization forms to such a late time? Data dependencies would allow an object X's initialization form to be executed any time after X's creation form had finished. Is there a reason to be more strict? I can't think of one, but if there is one, it should be stated on the rationale. Actually, it would be better (and no more difficult, it seems to me) to be strict in the other direction: Objects should be initialized as early as possible, and hence at a deterministic time. This would allow nodes in non-circular structures to be built out of fully initialized subparts, which is clearly something an application could need. Here's what your paragraph would look like, given that point: The creation form for an object X is always fully evaluated before the initialization form for that object. This evaluation includes the evaluation of the creation form of any user-defined object Y contained in X's creation form, and will also include the evaluation of Y's initialization form, if X and Y are not part of a circular chain of initialization forms. Any circular substructures of X will be fully initialized. Initialization forms of circular structures are evaluated in an implementation-defined order, subject to the previous restrictions. These rules are intended to ensure that initialization follows creation as quickly as possible, subject to data flow. Under these rules, noncircular data structures will be treated as if all the initialization forms will immediately follow the creation forms this way: (eval `(let ((obj ,)) ,(subst 'obj ) obj)) Furthermore, circular sub-structures will not impair the timely initialization of non-circular containing structures. Such guarantees will give programmers a sense of security in breaking out as much processing as possible into the initialization form. If this point of view is not adopted, a laissez-faire position is probably better, and I think your paragraph above could be deleted, or rewritten thus: The creation form for an object is always fully evaluated before the initialization form for that object. This evaluation includes the evaluation of creation forms of any user-defined objects contained in the creation form, and may or may not include the evaluation of initialization forms. However, when a "top-level object" is loaded, all creation and initialization forms of that object must be fully evaluated before any further loading actions are taken. These rules are intended to allow implementations a high degree of freedom in ordering the evaluation of creation and initialization forms, subject to the requirements of data flow. This paragraph needs to define the the specially-treated "top-level object", which seems to be a concept implicit in your original paragraph. But I'd rather see my first point adopted, and be done with top-level objects. -- John From Owners-CommonLoops.pa@Xerox.COM Sun Jan 15 18:13:20 1989 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA24806; Sun, 15 Jan 89 18:13:20 PST Received: from Chardonnay.ms by ArpaGateway.ms ; 15 JAN 89 18:13:23 PST Return-Path: Redistributed: CommonLoops.pa Received: from umbc3.umbc.edu ([130.85.1.3]) by Xerox.COM ; 15 JAN 89 18:11:16 PST Received: by umbc3.umbc.edu (5.57/Ultrix2.4-C) id AA09331; Sun, 15 Jan 89 21:11:07 EST Date: Sun, 15 Jan 89 21:11:07 EST From: alex@umbc3.umbc.edu (Alex S. Crain) Message-Id: <8901160211.AA09331@umbc3.umbc.edu> To: CommonLoops.pa@Xerox.COM Subject: Address change Please change my domain in the mailing list list... alex@umbc3.umd.edu has become alex@umbc3.umbc.edu ThanX... :alex Alex Crain Systems Programmer alex@umbc3.umbc.edu (NEW DOMAIN!) Univ Md Baltimore County nerwin!alex@umbc3.umbc.edu From Owners-commonloops.pa@Xerox.COM Mon Jan 16 13:03:05 1989 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA04865; Mon, 16 Jan 89 13:03:05 PST Received: from Riesling.ms by ArpaGateway.ms ; 16 JAN 89 12:47:00 PST Return-Path: Redistributed: commonloops.pa Received: from tut.cis.ohio-state.edu ([128.146.8.60]) by Xerox.COM ; 16 JAN 89 12:24:24 PST Received: by tut.cis.ohio-state.edu (5.59/2.881128) id AA17798; Mon, 16 Jan 89 15:23:58 EST Date: Mon, 16 Jan 89 15:23:58 EST From: Arun Welch Message-Id: <8901162023.AA17798@tut.cis.ohio-state.edu> To: commonloops.pa@Xerox.COM Subject: Bug in Xerox-Medley Dec PCL We've noticed the following behaviour in the Xerox-Medley version of the latest (no cute name) pcl. 3/1> (defclass poodle nil ((ears :type number) (tail :type symbol))) 3/2> (setf fifi (*make-instance 'poodle)) 3/3> (slot-boundp fifi 'ears) returns NIL 3/4> (slot-value fifi 'ears) prints "The slot EARS is unbound in the object #" (it does *not* give an error/break) 3/5> (setf (slot-value fifi 'ears) 4) prints "The slot EARS is unbound in the object #" (it does *not* give an error/break) Shouldn't clause 3/4 signal an error instead of returning? And, shouldn't 3/5 return 4? The cause of all this turns out to be: >...But I have no idea of a workaround. Here's what happens: you do a >(setf (slot-value foo 'tentacles) 'slimy). The xerox says: hah, I know what >she's up to -- she wants to do a value-setting thing. But then she >might change her mind later, so instead of just doing the appropriate >setf-method, first I'll call undoably-save, which will squirrel away >for her protection both the thing whose value she's changing *and the >original pre-set value*. So, I'll take the setf form around the >form and just do a l'il old slot-value to get the original value that >she's about to change... >Voila. Undoably-save (or undoably-store or whatever its called) magically >goes ahead and does a slot-value on an unbound slot... Has anyone else noticed this, and have a patch? ...arun From cutting.pa@Xerox.COM Mon Jan 16 15:19:33 1989 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA07141; Mon, 16 Jan 89 15:19:33 PST Received: from Semillon.ms by ArpaGateway.ms ; 16 JAN 89 15:12:55 PST Date: 16 Jan 89 15:05 PST From: cutting.pa@Xerox.COM Subject: Re: Bug in Xerox-Medley Dec PCL In-Reply-To: Arun Welch's message of Mon, 16 Jan 89 15:23:58 EST To: Arun Welch Cc: commonloops.pa@Xerox.COM Message-Id: <890116-151255-1907@Xerox> 3/4> (slot-value fifi 'ears) prints "The slot EARS is unbound in the object #" (it does *not* give an error/break) 3/5> (setf (slot-value fifi 'ears) 4) prints "The slot EARS is unbound in the object #" (it does *not* give an error/break) I suspect that errors are being signalled, but due to the IL:HELPDEPTH feature a break window is not being created. Try "retry 4" and you should get a break. If the problem is in the undo facility, then the quick workaround is to (SETQ XCL:*EXEC-MAKE-UNDOABLE-P* NIL). How often do you really use the undo facility? If the answer is 'quite' then you might try something like (untested): (defun undoably-setf-slot-value (object slot-name new-value) (if (slot-boundp object slot-name) (il:undosave `(setf (slot-value ',object ',slot-name) ',(slot-value object slot-name))) (il:undosave `(slot-makeunbound ',object ',slot-name))) (setf (slot-value object slot-name) new-value)) (setf (get 'slot-value :undoable-setf-inverse) 'undoably-setf-slot-value) Doug From Owners-commonloops.pa@Xerox.COM Mon Jan 16 15:43:14 1989 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA07297; Mon, 16 Jan 89 15:43:14 PST Received: from Cabernet.ms by ArpaGateway.ms ; 16 JAN 89 15:41:55 PST Return-Path: Redistributed: commonloops.pa Received: from tut.cis.ohio-state.edu ([128.146.8.60]) by Xerox.COM ; 16 JAN 89 15:37:37 PST Received: by tut.cis.ohio-state.edu (5.59/2.881128) id AA24534; Mon, 16 Jan 89 18:36:58 EST Date: Mon, 16 Jan 89 18:36:58 EST From: Arun Welch Message-Id: <8901162336.AA24534@tut.cis.ohio-state.edu> To: commonloops.pa@Xerox.COM Subject: Hack to make the previous bug work (setf (slot-value fifi 'ears) 4) expands into (set-slot-value fifi 'ears 4), so using the latter instead works. Obviously not a long-term solution, but if you're really need to give fifi 4 ears, it works. ...arun From lanning.pa@Xerox.COM Mon Jan 16 17:56:06 1989 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA09236; Mon, 16 Jan 89 17:56:06 PST Received: from Salvador.ms by ArpaGateway.ms ; 16 JAN 89 17:48:46 PST Date: 16 Jan 89 13:59 PST From: Stanley's Tool Works Subject: Re: Bug in Xerox-Medley Dec PCL In-Reply-To: Arun Welch 's message of Mon, 16 Jan 89 15:23:58 EST To: Arun Welch Cc: commonloops.pa@Xerox.COM Message-Id: <890116-174846-2341@Xerox> I believe your analysis of event [3/5] is correct. The following should fix that problem: (defun undoable-setf-slot-value (object slot-name new-value) (if (slot-boundp object slot-name) (il:undosave (list 'undoable-setf-slot-value object slot-name (slot-value object slot-name))) (il:undosave (list 'slot-makunbound object slot-name))) (setf (slot-value object slot-name) new-value)) (setf (get 'slot-value :undoable-setf-inverse) 'undoable-setf-slot-value) As for event [3/4], this is being caused by the DWIM holdover that prevents breaks caused near the top-level. This can be "fixed" by (setq il:helpflag 'il:break!) in each and every exec. Also, check out the var xcl:*per-exec-variables* -- this determines the initial value of il:helpflag in a new exec. ----- smL From Owners-commonloops.pa@Xerox.COM Mon Jan 16 19:20:34 1989 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA10229; Mon, 16 Jan 89 19:04:56 PST Received: from Semillon.ms by ArpaGateway.ms ; 16 JAN 89 18:37:34 PST Return-Path: Redistributed: commonloops.pa Received: from shrike.Austin.Lockheed.COM ([192.31.24.65]) by Xerox.COM ; 16 JAN 89 18:35:22 PST Received: by shrike.Austin.Lockheed.COM (4.0/1.41); Mon, 16 Jan 89 20:34:21 CST Received: by opal.STC.LOCKHEED.COM (3.2/1.27); Mon, 16 Jan 89 20:29:08 CST Received: by topaz.STC.LOCKHEED.COM (3.2/1.1); Mon, 16 Jan 89 20:29:06 CST Date: Mon, 16 Jan 89 20:29:06 CST From: Jacky Combs Message-Id: <8901170229.AA04700@topaz.STC.LOCKHEED.COM> To: commonloops.pa@Xerox.COM Subject: meta-object protocol I would like to know where can I get a copy of the current draft of chapter 3 of the CLOS spec (the one on the meta-object protocol). I am really having problems trying to setup metalevel object base. For example, I have defined "my-meta-class" as a subclass of "standard-class" so that I can define additional slots and methods for "my-meta-class". This definition works fine, but when I try to define a class as an instance of "my-meta-class" I get an error message from the method "check-super-metaclass-compatibility" telling me that a class and it's super have to be instances of the same class. Does this mean that PCL only supports a single metaclass and that ALL classes (including system classes have to be instances of the same class)? Thanks -- Jacky combs@stc.lockheed.com From Owners-commonloops.pa@Xerox.COM Mon Jan 16 20:42:32 1989 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA11412; Mon, 16 Jan 89 20:42:32 PST Received: from Chardonnay.ms by ArpaGateway.ms ; 16 JAN 89 20:22:24 PST Return-Path: Redistributed: commonloops.pa Received: from PEBBLES.BBN.COM ([128.89.1.5]) by Xerox.COM ; 16 JAN 89 20:20:06 PST To: Jacky Combs Cc: commonloops.pa@Xerox.COM Subject: Re: meta-object protocol In-Reply-To: Your message of Mon, 16 Jan 89 20:29:06 -0600. <8901170229.AA04700@topaz.STC.LOCKHEED.COM> Date: Mon, 16 Jan 89 23:17:24 -0500 From: kanderso@BBN.COM Message-Id: <890116-202224-2550@Xerox> Date: Mon, 16 Jan 89 20:29:06 CST From: Jacky Combs Message-Id: <8901170229.AA04700@topaz.STC.LOCKHEED.COM> To: commonloops.pa@Xerox.COM Subject: meta-object protocol I would like to know where can I get a copy of the current draft of chapter 3 of the CLOS spec (the one on the meta-object protocol). I am really having problems trying to setup metalevel object base. For example, I have defined "my-meta-class" as a subclass of "standard-class" so that I can define additional slots and methods for "my-meta-class". This definition works fine, but when I try to define a class as an instance of "my-meta-class" I get an error message from the method "check-super-metaclass-compatibility" telling me that a class and it's super have to be instances of the same class. Does this mean that PCL only supports a single metaclass and that ALL classes (including system classes have to be instances of the same class)? Thanks -- Jacky combs@stc.lockheed.com Add the following mixin to your meta class: (defclass compatible-class-mixin () () (:documentation "A metaclass mixin that provides compatibility with standard-class.")) (defmethod check-super-metaclass-compatibility ((class compatibile-class-mixin) (super standard-class)) t) An unstated part of the PCL metaclass protocal is that you must respond positively to this message if you can be used with standard-class. This is to prevent you from mixing water and oil. The problem is that the default compatibility is NIL and most people expect it to be T, perhaps it should be T. k From Owners-commonloops.pa@Xerox.COM Tue Jan 17 11:54:39 1989 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA28691; Tue, 17 Jan 89 11:54:39 PST Received: from Chardonnay.ms by ArpaGateway.ms ; 17 JAN 89 11:44:43 PST Return-Path: Redistributed: commonloops.pa Received: from hplms2.hpl.hp.com ([15.255.16.26]) by Xerox.COM ; 17 JAN 89 11:38:35 PST Received: from hplwhh.HPL.HP.COM (hplwhh.hpl.hp.com) by hplms2.hp.com; Tue, 17 Jan 89 11:38:34 pst Received: from loopback by hplwhh.HPL.HP.COM; Tue, 17 Jan 89 11:38:22 pst To: kanderso@BBN.COM, Jacky Combs Cc: commonloops.pa@Xerox.COM Subject: Re: meta-object protocol In-Reply-To: Your message of "Mon, 16 Jan 89 23:17:24 EST." <890116-202224-2550@Xerox> Date: Tue, 17 Jan 89 11:38:19 PST Message-Id: <4146.601069099@hplwhh> From: Warren Harris I brought up this same issue about a year and a half ago. What I wanted to write was: (defclass my-class (standard-class) ()) (defclass my-object (object) () (:metaclass my-class)) (Actually I wanted to add one more slot to MY-CLASS, but I left it out here to make a point.) In this example I saw no reason why the super of OBJECT should be incompatible with MY-OBJECT. *All* functionality of STANDARD-CLASS has been inherited into MY-CLASS. The argument against it then, as I recall, was that subclassing a meta-class (1) by definition causes an incompatibility between super-classes that use them (subtrees of the hierarchy must be instances of the same meta-class) and (2) is only intended for the implementors of new languages. Therefore the CHECK-SUPER-METACLASS-COMPATIBILITY method returns NIL. From Owners-commonloops.pa@Xerox.COM Mon Jan 23 09:22:59 1989 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA01826; Mon, 23 Jan 89 09:22:59 PST Received: from Chardonnay.ms by ArpaGateway.ms ; 23 JAN 89 08:34:08 PST Return-Path: Redistributed: commonloops.pa Received: from shrike.Austin.Lockheed.COM ([192.31.24.65]) by Xerox.COM ; 23 JAN 89 08:21:58 PST Received: by shrike.Austin.Lockheed.COM (4.0/1.41); Mon, 23 Jan 89 10:20:23 CST Received: by opal.STC.LOCKHEED.COM (3.2/1.27); Fri, 20 Jan 89 21:00:13 CST Received: by topaz.STC.LOCKHEED.COM (3.2/1.1); Fri, 20 Jan 89 21:00:13 CST Date: Fri, 20 Jan 89 21:00:13 CST From: Jacky Combs Message-Id: <8901210300.AA00297@topaz.STC.LOCKHEED.COM> To: commonloops.pa@Xerox.COM Subject: *make-instance vs. make-instance I am running the AAAI 8/28/88 version of PCL on a Symbolics 7.2 and I am having some problems with MAKE-INSTANCE. If you define a class slot with both an INITFORM value and DEFAULT-ARGS value and create an instance without supplying a value for the slot, the INITFORM value is used (not the DEFAULT-ARGS value). The reverse is true if you use *MAKE-INSTANCE. I am also having problems using the INITARG of a slot with MAKE-INSTANCE. It appears to work only if the INITARG is the slot name preceeded by a colon. This is not the case with *MAKE-INSTANCE of course because *MAKE-INSTANCE does not call INITIALIZE-FROM-INIT-PLIST. Can someone please give me a clue as to what is going on between the method *MAKE-INSTANCE and the function MAKE-INSTANCE? Thanks -- Jacky From CL-Compiler-mailer@SAIL.STANFORD.EDU Mon Jan 23 11:57:09 1989 Received: from Sail.Stanford.EDU by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA04835; Mon, 23 Jan 89 11:57:09 PST Received: from ti.com by SAIL.Stanford.EDU with TCP; 23 Jan 89 11:52:44 PST Received: by ti.com id AA28832; Mon, 23 Jan 89 13:52:14 CST Received: from dsg by tilde id AA23248; Mon, 23 Jan 89 13:38:15 CST Received: From Kelvin By dsg Via CHAOS-NET With CHAOS-MAIL; Mon, 23 Jan 89 11:15:29 CST Message-Id: <2810567730-15432385@Kelvin> Sender: GRAY@Kelvin.csc.ti.com Date: Mon, 23 Jan 89 11:15:30 CST From: David N Gray To: Common-Lisp-Object-System@SAIL.STANFORD.EDU Cc: CL-Compiler@SAIL.STANFORD.EDU Subject: DEFMETHOD compile-time processing In the Meta Object Protocol draft number 10 [89-003], on page 3-16 it says that "At compile time: ... (5) The method function is computed by evaluating the special form (FUNCTION ) in the lexical environment of the DEFMETHOD. ... (7) The function ADD-METHOD is called ..." This isn't going to work. You can install the function at load time in its lexical environment, or you can install it at compile time in the null lexical environment, but you can't evaluate something at compile-time in its run-time lexical environment. Possible remedies include: * Do the compile-time call to ADD-METHOD only if the DEFMETHOD appears at top-level in a null lexical environment. This would be consistent with the treatment of DEFMACRO in proposal DEFINING-MACROS-NON-TOP-LEVEL. * Don't ever do a compile-time call to ADD-METHOD. I haven't seen a reason why methods would need to be installed in the compile-time environment. Apparently at least some information about generic function definitions needs to be remembered for use when invoking MAKE-METHOD-LAMBDA, but that wouldn't require being able to actually call the generic function at compile-time. From kiuchi.pa@Xerox.COM Mon Jan 23 12:06:48 1989 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA04924; Mon, 23 Jan 89 12:06:48 PST Received: from Salvador.ms by ArpaGateway.ms ; 23 JAN 89 11:55:59 PST Date: 23 Jan 89 11:44 PST From: kiuchi.pa@Xerox.COM Subject: Re: *make-instance vs. make-instance In-Reply-To: Jacky Combs 's message of Fri, 20 Jan 89 21:00:13 CST To: Jacky Combs Cc: CommonLoops.pa@Xerox.COM Message-Id: <890123-115559-1210@Xerox> From the notes.text(AAAI version). This file was renamed to 8-28-88-notes.text in arisia.xerox.com. Initialization argument check bug will be fixed in the next release of PCL. MAKE-INSTANCE and INITIALIZE-FROM-INIT-PLIST is the obsolete functions just for backward compatibility of PCL. Thanks. Yasuhiko Kiuchi (kiuchi.pa@Xerox.ocm) ---------- These notes correspond to the "8/24/88 (beta) AAAI PCL" version of PCL. Please read this entire document carefully. . . . - the initialization protocol specified in 88-002R is now almost completely implemented. The only difference is that the current implementation does not currently check the validity of initargs. So, no errors are signalled in improper initargs are supplied. Because of name conflicts with the two other initialization protocols PCL currently supports, some of the specified initialization functions do not have their proper name. The mapping between names in the specification and names in this version of PCL is as follows: SPECIFIED IN PCL make-instance *make-instance initialize-instance *initialize-instance reinitialize-instance update-instance-for-different-class update-instance-for-redefined-class shared-initialize In a future release of PCL, these functions will have their proper names, and all the old, obsolete initialization protocols will disappear. . . . ---------- From CL-Compiler-mailer@SAIL.STANFORD.EDU Tue Jan 24 09:32:40 1989 Received: from Sail.Stanford.EDU by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA20749; Tue, 24 Jan 89 09:32:40 PST Received: from lucid.com by SAIL.Stanford.EDU with TCP; 24 Jan 89 09:28:47 PST Received: from challenger ([192.9.200.17]) by heavens-gate.lucid.com id AA01394g; Tue, 24 Jan 89 09:23:52 PST Received: by challenger id AA18054g; Tue, 24 Jan 89 09:19:45 PST Date: Tue, 24 Jan 89 09:19:45 PST From: Patrick Dussud Message-Id: <8901241719.AA18054@challenger> To: Gray@DSG.csc.ti.com Cc: Common-Lisp-Object-System@SAIL.STANFORD.EDU, CL-Compiler@SAIL.STANFORD.EDU In-Reply-To: David N Gray's message of Mon, 23 Jan 89 11:15:30 CST <2810567730-15432385@Kelvin> Subject: DEFMETHOD compile-time processing Sender: GRAY@Kelvin.csc.ti.com Date: Mon, 23 Jan 89 11:15:30 CST From: David N Gray In the Meta Object Protocol draft number 10 [89-003], on page 3-16 it says that "At compile time: ... (5) The method function is computed by evaluating the special form (FUNCTION ) in the lexical environment of the DEFMETHOD. ... (7) The function ADD-METHOD is called ..." This isn't going to work. You can install the function at load time in its lexical environment, or you can install it at compile time in the null lexical environment, but you can't evaluate something at compile-time in its run-time lexical environment. you're right. The general issue that we try to address is that it should be possible for some implementations to precompute a certain number of characteristic of CLOS programs at compile-file time. These precomputation involve metaobjects (looking at user class definitions, method object, generic functions) in a state that should be close enough to their state when the program is loaded in the remote environment. It is not generally possible to simulate the remote environment as far as running remote code. Therefore, precomputation at compile time, by doing metaprogramming on remote environment objects is more restrictive that doing metaprogramming on local environment objects. However, we don't want to introduce two distinct metaprogrammings. Chapter 3 is trying to unify remote and local metaprogramming. All the side effect that are done when the program is loaded, is simulated in the remote environment( Add-method, ensure-class...). As Gray noticed, it does not always work. In particular, we should acknowledge the difference as far as function objects are concerned: Local function object can be executed, remote functions can only be looked at. Possible remedies include: * Do the compile-time call to ADD-METHOD only if the DEFMETHOD appears at top-level in a null lexical environment. This would be consistent with the treatment of DEFMACRO in proposal DEFINING-MACROS-NON-TOP-LEVEL. I don't consider this solution very satisfying, because it hides the problem. It is possible to represent functions for the remote environment by normal functions if the lexical environment is null, but still, they can't be executed. The problem remains. * Don't ever do a compile-time call to ADD-METHOD. I haven't seen a reason why methods would need to be installed in the compile-time environment. Apparently at least some information about generic function definitions needs to be remembered for use when invoking MAKE-METHOD-LAMBDA, but that wouldn't require being able to actually call the generic function at compile-time. This will lead to two different metaprogramming styles. Note that this is more or less what Flavors does. It is workable, but not pretty. Maybe a better solution is to standardize a representation for objects in the remote environment, and have the compile-file time expansion create them. Add-method and such work as before, function slots don't always contain real functions. Patrick. From Common-Lisp-Object-System-mailer@SAIL.STANFORD.EDU Tue Jan 24 14:15:09 1989 Received: from [36.86.0.194] by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA24861; Tue, 24 Jan 89 14:15:09 PST Received: from Sun.COM by SAIL.Stanford.EDU with TCP; 24 Jan 89 14:15:08 PST Received: from snail.Sun.COM by Sun.COM (4.1/SMI-4.0) id AA20353; Tue, 24 Jan 89 14:16:20 PST Received: from lukasiewicz.sun.com by snail.Sun.COM (4.1/SMI-4.0) id AA14503; Tue, 24 Jan 89 14:12:36 PST Received: by lukasiewicz.sun.com (4.0/SMI-4.0) id AA03288; Tue, 24 Jan 89 14:15:11 PST Date: Tue, 24 Jan 89 14:15:11 PST From: jrose@Sun.COM (John Rose) Message-Id: <8901242215.AA03288@lukasiewicz.sun.com> To: dussud@lucid.com Cc: Gray@DSG.csc.ti.com, Common-Lisp-Object-System@SAIL.STANFORD.EDU, CL-Compiler@SAIL.STANFORD.EDU In-Reply-To: Patrick Dussud's message of Tue, 24 Jan 89 09:19:45 PST <8901241719.AA18054@challenger> Subject: DEFMETHOD compile-time processing Date: Tue, 24 Jan 89 09:19:45 PST From: Patrick Dussud Sender: GRAY@Kelvin.csc.ti.com Date: Mon, 23 Jan 89 11:15:30 CST From: David N Gray In the Meta Object Protocol draft number 10 [89-003], on page 3-16 it says that "At compile time: ... (5) The method function is computed by evaluating the special form (FUNCTION ) in the lexical environment of the DEFMETHOD. ... (7) The function ADD-METHOD is called ..." This isn't going to work. You can install the function at load time in its lexical environment, or you can install it at compile time in the null lexical environment, but you can't evaluate something at compile-time in its run-time lexical environment. you're right. [A paraphase of your next paragraph: At compile time, a "remote environment" data structure must be set up to model the eventual state of the "local environment" which results from loading the compiled code. A design goal of CLOS is to make these two kinds of environments as similar as possible, having the same programmatic interface if possible. Yet, there are objects which cannot be represented completely in a remote environment, such as pieces of compiled code.] ... Possible remedies include: * Do the compile-time call to ADD-METHOD only if the DEFMETHOD appears at top-level in a null lexical environment. This would be consistent with the treatment of DEFMACRO in proposal DEFINING-MACROS-NON-TOP-LEVEL. I don't consider this solution very satisfying, because it hides the problem. It is possible to represent functions for the remote environment by normal functions if the lexical environment is null, but still, they can't be executed. The problem remains. * Don't ever do a compile-time call to ADD-METHOD. I haven't seen a reason why methods would need to be installed in the compile-time environment. Apparently at least some information about generic function definitions needs to be remembered for use when invoking MAKE-METHOD-LAMBDA, but that wouldn't require being able to actually call the generic function at compile-time. This will lead to two different metaprogramming styles. Note that this is more or less what Flavors does. It is workable, but not pretty. Maybe a better solution is to standardize a representation for objects in the remote environment, and have the compile-file time expansion create them. Add-method and such work as before, function slots don't always contain real functions. Patrick. In Lisp, remote function objects are usually represented by their names. For example, if we want at compile time to get hold of a function FOO to insert it into code or data structure (in the course of macroexpansion, say), we naturally don't attempt to grab hold of the function object itself, or any compile-time representation of it; we use the name FOO itself as a reference to the function. At compile time, the name may not be defined, but we assume that it will be at load time. Lisp's dynamic linking will ensure that we will access the code we want. I'd like to present some generalizations of this which apply to CLOS. Interestingly, Lisp already unifies the treatment of remote functions (i.e., their names) and local ones (compiled code objects), in the following way: All operations which work on compiled code objects also work on their names __if__ those names are bound in the local environment. For example, you can funcall or disassemble an FBOUNDP symbol as easily as its binding, if it's bound. A remote reference is coerced to a local one, for local operations. This is a principle of unity which can address the problem at hand. The proposals for non-symbolic function names (some of which are motivated by CLOS work) generalize the set of names you can give to functions. So, for example, if (SETF ) might be a valid function name, so it can occur syntactically wherever a symbolic function name might. The semantics of non-symbolic function names (I contend) should tend to preserve the unification between remote and local objects described above. For example, a list like (SETF ) should support the programmatic operations common to symbols and code objects: DISASSEMBLE, SYMBOL-FUNCTION, FBOUNDP and (yes) FUNCALL. Did you hear me suggest allowing FBOUNDP and FUNCALL on lists? You did. Consider this: Common Lisp already allows FUNCALL on lists, in what turns out to be another case of remote-to-local coercion. If you FUNCALL a list whose car is LAMBDA, the list is coerced to (or interpreted as, which amounts to the same thing) the function it specifies. In other word, the cons tree which names a function remotely can serve as that function's. (By the way, an "anonymous" lambda is really named by its cons tree.) The reference is validated late, at the point of call: Just as symbols are checked for fboundp-ness, lambda forms are walked by the interpreter when called, and not earlier. Nevertheless, the reference, once validated, is equivalent to the object itself. Given function specifiers for method code, and given the unification supplied by remote-to-local coercion of all function specifiers, we can then store remote function specifiers in method objects, to refer to code, and both local and remote operations will work on them. The paragraph David Gray mentioned above would then look something like this: At compile time: ... (5) The method function is set to the name of the method, e.g., (METHOD ). (This name may or may not be FBOUNDP at compile time.) The form (DEFUN ) is compiled in the lexical environment of the DEFMETHOD. ... (7) The function ADD-METHOD is called ..." ... At load time, the DEFUN form for the method causes the method's name to become bound to the specified code. At both compile and load time, the method's function would be the name of the actual function, which would be reliably FBOUNDP at load time. Doing something like (FUNCALL (METHOD-FUNCTION M) X Y Z) would work whenever reasonable, and cause an unbound function error at other times. Note: As I've said before, nonsymbolic names can be useful for referring to other things than functions. For example, mixture classes are usefully named by cons trees of some sort. Consider extending the type constructor AND to classes: (AND MY-VIEWPORT-CLASS BORDERS-MIXIN CANVAS-STREAM-MIXIN). This could be implemented by extending SYMBOL-CLASS to accept non-symbolic names, with a mixin manager which builds and caches an otherwise-anonymous class for each mixture it sees. Note also that a user-defined function specifier facility, with the remote-to-local coercion rule, lets you build lambda-macros. (Remember those?) -- John From Owners-commonLoops.pa@Xerox.COM Tue Jan 24 15:31:39 1989 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA25583; Tue, 24 Jan 89 15:31:39 PST Received: from Chardonnay.ms by ArpaGateway.ms ; 24 JAN 89 12:40:35 PST Return-Path: Redistributed: commonLoops.pa Received: from Score.Stanford.EDU ([10.3.0.11]) by Xerox.COM ; 24 JAN 89 12:35:03 PST Date: Tue, 24 Jan 89 12:34:50 PST From: Dan Larner Subject: Return value of defclass To: commonLoops.pa@Xerox.COM Message-Id: <12465171996.19.LARNER@Score.Stanford.EDU> Perhaps this has appeared before, but defclass doesn't return the new class object as its result. Problem appears to be down in the function make-top-level-form, where an (eval-when ()) is generated for non GCLisp and coral versions. -- Dan ------- From CL-Compiler-mailer@SAIL.STANFORD.EDU Tue Jan 24 17:50:22 1989 Received: from Sail.Stanford.EDU by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA28030; Tue, 24 Jan 89 17:50:22 PST Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 24 Jan 89 17:46:47 PST Received: from defun.utah.edu by cs.utah.edu (5.59/utah-2.1-cs) id AA21651; Tue, 24 Jan 89 18:43:37 MST Received: by defun.utah.edu (5.59/utah-2.0-leaf) id AA20013; Tue, 24 Jan 89 18:43:23 MST From: sandra%defun@cs.utah.edu (Sandra J Loosemore) Message-Id: <8901250143.AA20013@defun.utah.edu> Date: Tue, 24 Jan 89 18:43:21 MST Subject: Re: DEFMETHOD compile-time processing To: dussud@lucid.com Cc: jrose@Sun.COM (John Rose), Gray@DSG.csc.ti.com, Common-Lisp-Object-System@SAIL.STANFORD.EDU, CL-Compiler@SAIL.STANFORD.EDU In-Reply-To: jrose@Sun.COM (John Rose), Tue, 24 Jan 89 14:15:11 PST > * Do the compile-time call to ADD-METHOD only if the DEFMETHOD appears at > top-level in a null lexical environment. This would be consistent with > the treatment of DEFMACRO in proposal DEFINING-MACROS-NON-TOP-LEVEL. > > I don't consider this solution very satisfying, because it hides the problem. > It is possible to represent functions for the remote environment by normal > functions if the lexical environment is null, but still, they can't be > executed. The problem remains. This may not be very satisfying, but it is probably the only practical solution. We have already had a lot of debate on this regarding DEFMACRO and the other defining macros. A number of people raised very strong objections to things like DEFMACRO causing the definition to appear in the compile-time environment when buried inside a control construct such as IF, or inside a DEFUN. I don't see any reason why those same arguments are not just as applicable to the CLOS defining macros. It seems exceedingly unlikely that we compiler people would be able to agree on any major reversal of the current proposal on issue DEFINING-MACROS-NON-TOP-LEVEL in the 6 weeks or so we have remaining. It also seems unlikely that you CLOS people are going to have the time to work out any alternative semantics before then. Even if we did have more time to work out alternatives, to me it seems that restricting the compile-time magic to top-level situations is the simplest solution for all of us. I don't see that it would affect other parts of CLOS, and it would just allow us to take the description of the compile-time behavior of DEFMETHOD directly from the MOP document. Incidentally, I notice that the same considerations also affect DEFCLASS and DEFGENERIC, both of which also want to create functional objects. The MOP document doesn't seem to say anything about DEFINE-METHOD-COMBINATION -- does anyone care to take a shot at specifying its expansion? What does PCL do with it? -Sandra ------- From CL-Compiler-mailer@SAIL.STANFORD.EDU Wed Jan 25 08:44:33 1989 Received: from Sail.Stanford.EDU by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA06519; Wed, 25 Jan 89 08:44:33 PST Received: from lucid.com by SAIL.Stanford.EDU with TCP; 25 Jan 89 08:40:16 PST Received: from challenger ([192.9.200.17]) by heavens-gate.lucid.com id AA02375g; Wed, 25 Jan 89 08:35:13 PST Received: by challenger id AA19066g; Wed, 25 Jan 89 08:31:05 PST Date: Wed, 25 Jan 89 08:31:05 PST From: Patrick Dussud Message-Id: <8901251631.AA19066@challenger> To: sandra%defun@cs.utah.edu Cc: Common-Lisp-Object-System@SAIL.STANFORD.EDU, CL-Compiler@SAIL.STANFORD.EDU In-Reply-To: Sandra J Loosemore's message of Tue, 24 Jan 89 18:43:21 MST <8901250143.AA20013@defun.utah.edu> Subject: DEFMETHOD compile-time processing From: sandra%defun@cs.utah.edu (Sandra J Loosemore) Date: Tue, 24 Jan 89 18:43:21 MST > * Do the compile-time call to ADD-METHOD only if the DEFMETHOD appears at > top-level in a null lexical environment. This would be consistent with > the treatment of DEFMACRO in proposal DEFINING-MACROS-NON-TOP-LEVEL. > > I don't consider this solution very satisfying, because it hides the problem. > It is possible to represent functions for the remote environment by normal > functions if the lexical environment is null, but still, they can't be > executed. The problem remains. This may not be very satisfying, but it is probably the only practical solution. We have already had a lot of debate on this regarding DEFMACRO and the other defining macros. A number of people raised very strong objections to things like DEFMACRO causing the definition to appear in the compile-time environment when buried inside a control construct such as IF, or inside a DEFUN. I don't see any reason why those same arguments are not just as applicable to the CLOS defining macros. It seems exceedingly unlikely that we compiler people would be able to agree on any major reversal of the current proposal on issue DEFINING-MACROS-NON-TOP-LEVEL in the 6 weeks or so we have remaining. It also seems unlikely that you CLOS people are going to have the time to work out any alternative semantics before then. Even if we did have more time to work out alternatives, to me it seems that restricting the compile-time magic to top-level situations is the simplest solution for all of us. I don't see that it would affect other parts of CLOS, and it would just allow us to take the description of the compile-time behavior of DEFMETHOD directly from the MOP document. Even if we decide to take this stand, the problem won't be entirely solved. Metaprogrammers won't be able to blindly get their paws on a method object, and do something that will cause the method-function to be called. If the method-function is a remote environment function, it may not be able to run in the local environment. I consider the semantics of the macros and the representation of remote environment objects being two distincts issues. My objections were not directed at the semantics issue, but at the representation issue. I expect that other CLOS members will give opinions on the semantics issue. Incidentally, I notice that the same considerations also affect DEFCLASS and DEFGENERIC, both of which also want to create functional objects. The MOP document doesn't seem to say anything about DEFINE-METHOD-COMBINATION -- does anyone care to take a shot at specifying its expansion? What does PCL do with it? That's right, all those macros create functional object, therefore are subject to the ruling concerning macros in non null lexical environment. Patrick. From Owners-commonloops.pa@Xerox.COM Wed Jan 25 09:17:42 1989 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA07791; Wed, 25 Jan 89 09:17:42 PST Received: from Chardonnay.ms by ArpaGateway.ms ; 25 JAN 89 09:13:43 PST Return-Path: Redistributed: commonloops.pa Received: from tut.cis.ohio-state.edu ([128.146.8.60]) by Xerox.COM ; 25 JAN 89 09:06:28 PST Received: from coracle.cis.ohio-state.edu by tut.cis.ohio-state.edu (5.59/2.890120) id ; Wed, 25 Jan 89 12:05:41 EST Received: by coracle.cis.ohio-state.edu (3.2/2.890120) id ; Wed, 25 Jan 89 12:04:41 EST Date: Wed, 25 Jan 89 12:04:41 EST From: Diana Smetters Message-Id: <8901251704.AA06620@coracle.cis.ohio-state.edu> To: commonloops.pa@Xerox.COM Subject: bug in 12/7 pcl under ibcl and kcl In the 12/7 release of pcl I get the following bug under kcl (June 3, 1987 version) and ibcl (release 01/01, on both sun 3's and sun 4's): If you load pcl as source, there are no problems. If you compile it, you get no errors in compiling pkg.lsp. However, if you load the compiled pcl, it breaks while loading pkg.o when trying to evaluate the form (export *exports* *the-pcl-package*) saying that *exports* is unbound. *Exports* is defvar'ed immediately previous to this form, and the defvar is wrapped inside an (eval-when (compile load eval)...). If you load the source of pkg form inside the break, then continue retrying the access of the value of *exports*, everything is fine. From what I can see with the tests I've tried, kcl and ibcl seem to try to set up the export before eval'ing anything else in the file, and the value of the kcl/ibcl variable *eval-when-compile* seems to make no difference. Have I just missed something obvious? --Diana Smetters OSU LAIR From Gregor.pa@Xerox.COM Wed Jan 25 15:45:26 1989 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA15702; Wed, 25 Jan 89 15:45:26 PST Received: from Semillon.ms by ArpaGateway.ms ; 25 JAN 89 15:41:48 PST Date: Wed, 25 Jan 89 15:39 PST From: Gregor.pa@Xerox.COM Subject: bug in constructors in Franz To: CommonLoops.PA@Xerox.COM, Rao.PA@Xerox.COM Fcc: BD:>Gregor>mail>outgoing-mail-5.text.newest Message-Id: <19890125233902.6.GREGOR@SPIFF.parc.xerox.com> Line-Fold: no In certain cases, constructors can signal strange, hard to reproduce errors in Franz Common Lisp. These errors are caused by a strange interaction with funcallable instances in that port. The following code patches this problem. A subsequent fix may use another solution, but this one works fine for now. ;from construct.lisp (defmethod install-lazy-constructor-installer ((constructor constructor)) (let ((class (constructor-class constructor))) (set-constructor-code constructor #'(lambda (&rest args) (multiple-value-bind (code type) (compute-constructor-code class constructor) (prog1 (apply code args) (set-constructor-code constructor code type)))) 'lazy))) ------- From Owners-commonloops.pa@Xerox.COM Wed Jan 25 16:15:54 1989 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA16126; Wed, 25 Jan 89 16:15:54 PST Received: from Salvador.ms by ArpaGateway.ms ; 25 JAN 89 16:09:54 PST Return-Path: Redistributed: commonloops.pa Received: from A.GP.CS.CMU.EDU ([128.2.242.7]) by Xerox.COM ; 25 JAN 89 16:07:12 PST Date: Wed, 25 Jan 89 19:06:28 EST From: Christopher.McConnell@A.GP.CS.CMU.EDU To: commonloops.pa@Xerox.COM Subject: Has anyone redone the KCL Turbo patch for Ibuki on an IRIS? Message-Id: <890125-160954-7426@Xerox> The code in gbc.c is very different from the code in kcl-mods.text. Thanks From Owners-commonloops.pa@Xerox.COM Wed Jan 25 18:35:20 1989 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA17296; Wed, 25 Jan 89 17:13:17 PST Received: from Riesling.ms by ArpaGateway.ms ; 25 JAN 89 17:12:25 PST Return-Path: Redistributed: commonloops.pa Received: from psuvax1.cs.psu.edu ([128.118.6.2]) by Xerox.COM ; 25 JAN 89 17:09:01 PST Received: from sol4.cs.psu.edu by psuvax1.cs.psu.edu (5.59/Psu2.1) id AA07561; Wed, 25 Jan 89 19:59:47 EST Received: by sol4 (4.0/SMI-4.0) id AA12908; Wed, 25 Jan 89 19:58:38 EST Date: Wed, 25 Jan 89 19:58:38 EST From: maida@sol4.ARPA (Anthony Maida) Message-Id: <8901260058.AA12908@sol4> To: commonloops.pa@Xerox.COM Subject: re: (export *exports* ...) Just to confirm, I have also encountered the problem described below. Tony Maida Penn State, CS ------- Date: Wed, 25 Jan 89 12:04:41 EST From: Diana Smetters Message-Id: <8901251704.AA06620@coracle.cis.ohio-state.edu> To: commonloops.pa@xerox.com Subject: bug in 12/7 pcl under ibcl and kcl Status: R In the 12/7 release of pcl I get the following bug under kcl (June 3, 1987 version) and ibcl (release 01/01, on both sun 3's and sun 4's): If you load pcl as source, there are no problems. If you compile it, you get no errors in compiling pkg.lsp. However, if you load the compiled pcl, it breaks while loading pkg.o when trying to evaluate the form (export *exports* *the-pcl-package*) saying that *exports* is unbound. *Exports* is defvar'ed immediately previous to this form, and the defvar is wrapped inside an (eval-when (compile load eval)...). If you load the source of pkg form inside the break, then continue retrying the access of the value of *exports*, everything is fine. >From what I can see with the tests I've tried, kcl and ibcl seem to try to set up the export before eval'ing anything else in the file, and the value of the kcl/ibcl variable *eval-when-compile* seems to make no difference. Have I just missed something obvious? --Diana Smetters OSU LAIR From Owners-commonloops.pa@Xerox.COM Wed Jan 25 19:31:09 1989 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA19518; Wed, 25 Jan 89 19:31:09 PST Received: from Chardonnay.ms by ArpaGateway.ms ; 25 JAN 89 19:26:20 PST Return-Path: Redistributed: commonloops.pa Received: from arisia.Xerox.COM ([13.1.100.206]) by Xerox.COM ; 25 JAN 89 19:22:42 PST Received: by arisia.Xerox.COM (5.59++/IDA-1.2.6) id AA19436; Wed, 25 Jan 89 19:22:13 PST Date: Wed, 25 Jan 89 19:22:13 PST From: Dan Rabin Message-Id: <8901260322.AA19436@arisia.Xerox.COM> To: commonloops.pa@Xerox.COM Subject: Omitted walker template for Coral Common Lisp 1.2.1 Coral Common Lisp 1.2.1 has the additional special form %stack-block, into which Macintosh toolbox calls from Lisp expand. The following walker-template definition seems to correct the problem of the walker complaining of no template found while trying to expand PCL macros: #+Coral (define-walker-template ccl:%stack-block walk-let) This observation applies to 12/7/88 PCL. --- Dan Rabin From Owners-CommonLoops.pa@Xerox.COM Thu Jan 26 01:41:12 1989 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA24597; Thu, 26 Jan 89 01:41:12 PST Received: from Semillon.ms by ArpaGateway.ms ; 26 JAN 89 01:41:07 PST Return-Path: Redistributed: CommonLoops.pa Received: from PEBBLES.BBN.COM ([128.89.1.5]) by Xerox.COM ; 26 JAN 89 01:38:21 PST To: CommonLoops.pa@Xerox.COM Subject: Re: (export *exports* ...) In-Reply-To: Your message of Wed, 25 Jan 89 19:58:38 -0500. <8901260058.AA12908@sol4> Date: Thu, 26 Jan 89 04:39:49 -0500 From: kanderso@BBN.COM Message-Id: <890126-014107-8338@Xerox> A solution is to load pkg.lisp before you compile it. I don't know why it is necessary. k From Owners-commonloops.pa@Xerox.COM Thu Jan 26 14:28:50 1989 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA03466; Thu, 26 Jan 89 14:28:50 PST Received: from Salvador.ms by ArpaGateway.ms ; 26 JAN 89 13:44:27 PST Return-Path: Redistributed: commonloops.pa Received: from Score.Stanford.EDU ([10.3.0.11]) by Xerox.COM ; 26 JAN 89 13:42:10 PST Date: Thu, 26 Jan 89 13:41:50 PST From: Dan Larner Subject: Return Value of Defclass To: commonloops.pa@Xerox.COM Cc: larner@SCORE.STANFORD.EDU Message-Id: <12465708479.20.LARNER@Score.Stanford.EDU> Parhaps this has appeared somewhere before, but defclass doesn't return the nes class object as its result. Problem appears to be down in the function make-top-level-form, where an (eval-when ()) is generated for non GCLisp and Coral versions. Also MakeInstance doesnt't seem to call initialize- instance as advertized in the spec (at least in the AAAI version). -- Dan ------- From Gregor.pa@Xerox.COM Thu Jan 26 14:57:07 1989 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA04247; Thu, 26 Jan 89 14:57:07 PST Received: from Semillon.ms by ArpaGateway.ms ; 26 JAN 89 14:54:41 PST Date: Thu, 26 Jan 89 14:51 PST From: Gregor.pa@Xerox.COM Subject: Return Value of Defclass To: Dan Larner Cc: commonloops.pa@Xerox.COM Fcc: BD:>Gregor>mail>outgoing-mail-5.text.newest In-Reply-To: <12465708479.20.LARNER@Score.Stanford.EDU> Message-Id: <19890126225113.4.GREGOR@SPIFF.parc.xerox.com> Line-Fold: no Date: Thu, 26 Jan 89 13:41:50 PST From: Dan Larner Parhaps this has appeared somewhere before, but defclass doesn't return the nes class object as its result. Problem appears to be down in the function make-top-level-form, where an (eval-when ()) is generated for non GCLisp and Coral versions. This is on our list of bugs to fix. Also MakeInstance doesnt't seem to call initialize- instance as advertized in the spec (at least in the AAAI version). This question has been asked repeatedly. As near as I can tell, people ask it because they haven't read the xxx-notes.text file which discusses this point. To all PCL users: Whenever there is a new PCL, it is important to read the notes.text file completely and carefully. If you skip releases, you should go back to read the interim xxx-notes.text files. PCL has too little documentation. To compensate, you have to read what little there is completely! ------- From Owners-commonloops.PA@Xerox.COM Thu Jan 26 15:02:56 1989 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA03501; Thu, 26 Jan 89 14:31:52 PST Received: from Cabernet.ms by ArpaGateway.ms ; 26 JAN 89 13:54:04 PST Return-Path: Redistributed: commonloops.PA Received: from cs2.wsu.edu ([192.31.216.52]) by Xerox.COM ; 26 JAN 89 13:51:39 PST Received: by cs2.wsu.edu (5.59/25-eef) id AA09953; Thu, 26 Jan 89 13:52:22 PST Message-Id: <8901262152.AA09953@cs2.wsu.edu> To: commonloops.PA@Xerox.COM Subject: Tektronix ExCL vs PCL Date: Thu, 26 Jan 89 13:52:20 -0800 From: "George R. Cross" I am having trouble getting the latest version of PCL (12/7/88) running on ExCl 3.0.0.1 on a Tektronix 4317. The version of PCL shipped with the distribution is 5-87, an antique, so I got the latest. Where it matters, in fin.cl, the system is being treated as a sun3 since the test is for gsgc and not sun4. If I force sun4, fin.cl won't compile. Anyway, the compilation is halted in vector.cl with the following error. Any ideas? Compiling VECTOR... ; --- Compiling file /usr/lib/cl/lib/newpcl/vector.cl --- ; Compiling GET-NEXT-WRAPPER-CACHE-NO ; Note: doing tail merge ; Note: doing tail merge ; Compiling MAKE-WRAPPER-CACHE-MASK ; Compiling SHIFT-WRAPPER-CACHE-LOCATION ; Compiling COMPUTE-LINE-SIZE ; Compiling COMPUTE-WRAPPER-CACHE-LOCATION ; Compiling COMPUTE-WRAPPER-CACHE-LOCATION-1 Error: Attempt to create an integer which is too large to represent [changing package from "USER" to "PCL"] [1] George R. Cross Computer Science Department cross@cs2.wsu.edu Washington State University cross%wsuvm1.bitnet@cunyvm.cuny.edu Pullman, WA 99164-1210 Phone: 509-335-6319 or 509-335-6636 From Owners-commonloops.pa@Xerox.COM Thu Jan 26 16:11:44 1989 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA05945; Thu, 26 Jan 89 16:11:44 PST Received: from Chardonnay.ms by ArpaGateway.ms ; 26 JAN 89 16:03:37 PST Return-Path: Redistributed: commonloops.pa Received: from IBM.COM ([192.5.58.7]) by Xerox.COM ; 26 JAN 89 15:58:09 PST Date: Thu, 26 Jan 89 15:01:00 PST From: David Alpern To: rik%cs@UCSD.EDU, commonloops.pa@Xerox.COM Subject: PCL under Lucid Message-Id: <890126-160337-10069@Xerox> I'm trying (first time) to get PCL (version of 12/7/88) up under Lucid, on an IBM RT. It's Lucid's 1.01 for the RT, which I think is roughly equivalent to the 2.1 Sun version. Anyhow, I also get the error Richard has reported (his message of 12/21) when compile-pcl tries to load lucid-low. Has a solution to this been found? Also, I originally installed Lucid with their flavors system. Will PCL and flavors coexist in the same workspace, allowing the choice of used packages to chose which is seen? If not, does that explain the above problem? - Dave David M. Alpern IBM Almaden Research Center, K31/802 650 Harry Road, San Jose, CA 95120-6099 Phone: (408) 927-2067 Internet: ALPERN@IBM.COM Bitnet: ALPERN at ALMVMC From CL-Compiler-mailer@SAIL.STANFORD.EDU Thu Jan 26 17:01:20 1989 Received: from Sail.Stanford.EDU by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA06543; Thu, 26 Jan 89 17:01:20 PST Received: from ti.com by SAIL.Stanford.EDU with TCP; 26 Jan 89 16:53:20 PST Received: by ti.com id AA14157; Thu, 26 Jan 89 18:47:38 CST Received: from Kelvin by tilde id AA23034; Thu, 26 Jan 89 18:38:20 CST Message-Id: <2810853419-16115524@Kelvin> Sender: GRAY@Kelvin.csc.ti.com Date: Thu, 26 Jan 89 18:36:59 CST From: David N Gray To: Patrick Dussud Cc: Common-Lisp-Object-System@SAIL.STANFORD.EDU, CL-Compiler@SAIL.STANFORD.EDU Subject: Re: DEFMETHOD compile-time processing In-Reply-To: Msg of Tue, 24 Jan 89 09:19:45 PST from Patrick Dussud > The general issue that we try to address is that it should be possible for > some implementations to precompute a certain number of characteristic of CLOS > programs at compile-file time. These precomputation involve metaobjects > (looking at user class definitions, method object, generic functions) in a > state that should be close enough to their state when the program is loaded in > the remote environment. It is not generally possible to simulate the remote > environment as far as running remote code. Therefore, precomputation at > compile time, by doing metaprogramming on remote environment objects is more > restrictive that doing metaprogramming on local environment objects. However, > we don't want to introduce two distinct metaprogrammings. Chapter 3 is trying > to unify remote and local metaprogramming. All the side effect that are done > when the program is loaded, is simulated in the remote environment( > Add-method, ensure-class...). I think I see the principle you're presenting here, but I'm still not clear on how it applies to this case. The calls to MAKE-METHOD-LAMBDA and ADD-METHOD are done by the implementation of the DEFMETHOD macro or its expansion, and the Meta-Object Protocol doesn't specify any intermediate points at which the user can get involved. Under what circumstances would the user know or care whether the compiler called ADD-METHOD? Sure, I suppose that a macro could use ENSURE-GENERIC-FUNCTION to look up the compile-time definition, invoke FIND-METHOD or GENERIC-FUNCTION-METHODS, and then look at the method objects, but is there really any reason to want to do that? Given the precedent that certain operations are not valid on uninitialized objects or un-finalized classes, who would be hurt if we said that FIND-METHOD and GENERIC-FUNCTION-METHODS were not valid on generic functions in the remote environment? Looking some more at pages 3-16 and 3-17, I think it's interesting that it doesn't really say anything about compilation, just about the side effects of what the compiler does. Presumably the lambda expression computed at compile time by MAKE-METHOD-LAMBDA is compiled, and the resulting compiled function is what is actually used in the run-time call to MAKE-INSTANCE for the method. There appears to be an additional problem, though, in that the compile-time call to MAKE-METHOD-LAMBDA depends on the result of GENERIC-FUNCTION-METHOD-CLASS, yet it is specified that GENERIC-FUNCTION-METHOD-CLASS is called again at load time. If we can't assume that the value will be the same, then what does that say about the validity of the compiled method function? It looks like either you don't want to do it again at load time, or else you do it again in order to signal an error if it doesn't match the compile-time value. Also aside from the question of lexical environments is the issue of control flow context. There has been discussion in the compiler committee that seems to have come to the conclusion that we don't want things like DEFMACRO side-effecting the compile-time environment if they are embedded in a function or conditional such that they really happen at some indeterminate run time rather than when the file is loaded. The same consideration would apply to DEFCLASS, DEFGENERIC, and DEFMETHOD. This requires being able to conceptually separate the actions needed to compile the run-time code from the actions simulating what happens at load time. And yet another issue: if the user says (EVAL-WHEN (EVAL COMPILE LOAD) (DEFMETHOD ...)) because he really does want to call that generic function from one of his macros, does that mean that the compile-time ADD-METHOD in this case needs to be to the resident installed definition instead of the remote environment? Or is this not legal? From Owners-commonloops.pa@Xerox.COM Thu Jan 26 19:31:12 1989 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA09091; Thu, 26 Jan 89 19:31:12 PST Received: from Riesling.ms by ArpaGateway.ms ; 26 JAN 89 19:30:35 PST Return-Path: Redistributed: commonloops.pa Received: from IBM.COM ([192.5.58.7]) by Xerox.COM ; 26 JAN 89 19:28:43 PST Date: Thu, 26 Jan 89 18:53:02 PST From: David Alpern To: commonloops.pa@Xerox.COM Subject: PCL on LUCID Message-Id: <890126-193035-10567@Xerox> The problem is due to the call to sys::defadvice at the bottom of lucid-low. Is it safe to just conditionalize this on LCL3.0 and exclude the whole function call otherwise? - Dave From Owners-CommonLoops.pa@Xerox.COM Thu Jan 26 23:09:18 1989 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA13263; Thu, 26 Jan 89 23:09:18 PST Received: from Semillon.ms by ArpaGateway.ms ; 26 JAN 89 23:09:23 PST Return-Path: Redistributed: CommonLoops.pa Received: from uunet.UU.NET ([192.12.141.129]) by Xerox.COM ; 26 JAN 89 23:05:18 PST Received: from mcvax.UUCP by uunet.UU.NET (5.61/1.14) with UUCP id AA07278; Fri, 27 Jan 89 02:05:00 -0500 Received: by mcvax.cwi.nl via EUnet; Thu, 26 Jan 89 19:20:33 +0100 (MET) Received: by inria.inria.fr via Fnet-EUnet; Fri, 20 Jan 89 16:23:53 +0100 (MET) Received: from magnon.laas.fr (magnon.ARPA) by laas.laas.fr, Fri, 20 Jan 89 13:52:25 -0100 Received: by magnon.laas.fr, Fri, 20 Jan 89 16:22:02 +0100 Received: by lasso.laas.fr (5.51/5.17) id AA03999; Fri, 20 Jan 89 17:22:08 +0100 Date: Fri, 20 Jan 89 17:22:08 +0100 From: ralph%lasso%mcvax@uunet.UU.NET (Ralph P. Sobek) Message-Id: <8901201622.AA03999@lasso.laas.fr> To: CommonLoops.pa@Xerox.COM Subject: defsys problem w/Medley 1.0S Cc: ericd@idefix.laas.fr We have here on test till the end of Jan., Envos Medley 1.0S Common Lisp. As a test we tried to install `AAAI-88 beta release 2' pcl. Unfortunately, the `defvar' for *pcl-directory* ALWAYS returns NIL, rather than the cons-pair of source and binary directories. As far as I can tell the problem is NOT with #+/- conditional evaluation. Taking out all the #+/-'s for *pcl-directory* still did not work. Does anybody have a quick patch for this? Or is it Medley's fault. Excuse our ignorance and e-mail me directly since this concerns commonloops indirectly. Ralph P. Sobek | UUCP: uunet!mcvax!inria!laas!ralph, or | ralph@laas.uucp LAAS-CNRS | Internet: ralph@laas.laas.fr, or 7, avenue du Colonel-Roche | ralph%laas.laas.fr@uunet.UU.NET F-31077 Toulouse Cedex, FRANCE | ARPA: sobek@eclair.Berkeley.EDU (forwarded\ +(33) 61-33-62-66 | BITNET/EARN: SOBEK@FRMOP11 \ to UUCP ) From Owners-commonloops.pa@Xerox.COM Fri Jan 27 00:57:52 1989 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA14079; Fri, 27 Jan 89 00:57:52 PST Received: from Cabernet.ms by ArpaGateway.ms ; 27 JAN 89 00:57:52 PST Return-Path: <@RELAY.CS.NET:roman@fb10vax.informatik.uni-saarland.dbp.de> Redistributed: commonloops.pa Received: from RELAY.CS.NET ([192.31.103.4]) by Xerox.COM ; 27 JAN 89 00:56:02 PST Received: from relay2.cs.net by RELAY.CS.NET id ab14235; 27 Jan 89 3:52 EST Received: from zix.gmd.dbp.de by RELAY.CS.NET id aw02185; 27 Jan 89 3:48 EST Received: from zix.gmd.dbp.de by .zix.gmd.dbp.de id a002437; 27 Jan 89 9:32 MET Date: 27 Jan 89 09:16 GMT-0100 From: roman@fb10vax.informatik.uni-saarland.dbp.de To: commonloops.PA@Xerox.COM Message-Id: <<8901270816.AA21971@fb10vax.sbsvax.uucp>> Subject: FLAVOR-Interface to PCL Date: Fri, 27 Jan 89 09:16:16 N ---------- Hi, we are looking for an implementation of FLAVORS using PCL. It need not to be perfect. An implementation of FLAVORS most important functions is sufficient for our purpose. Source Code (via E-Mail, no ftp access), Hints etc. are welcome. Thanks roman ------------------------------------------------------------------ |NET: roman%sbsvax@unido.uucp (via uunet, relay.cs.net,...) | | roman@fb10vax.informatik.uni-saarland.dbp.de | | (via relay.cs.net, if some mailer doesn't understand '.de')| | It's a long address, but it's X400! (;-) | |----------------------------------------------------------------| |POST: Roman M. Jansen-Winkeln | PHONE: +49-681-302-4135| | FB 10 - Informatik IV |------------------------| | Universitaet des Saarlandes | | | Im Stadtwald 15 | | | D-6600 Saarbruecken 11 | | | Federal Republic of Germany | | ------------------------------------------------------------------ From Owners-commonloops.pa@Xerox.COM Fri Jan 27 01:40:05 1989 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA14398; Fri, 27 Jan 89 01:40:05 PST Received: from Cabernet.ms by ArpaGateway.ms ; 27 JAN 89 01:40:07 PST Return-Path: Redistributed: commonloops.pa Received: from siemens.siemens.com ([129.73.7.1]) by Xerox.COM ; 27 JAN 89 01:38:15 PST Received: by siemens.siemens.com (5.54/1.15) id AA19813; Fri, 27 Jan 89 04:38:25 EST From: msch@ztivax.siemens.com (Matthias Schneider-Hufschmidt) Date: Fri, 27 Jan 89 10:37:29 -0100 Message-Id: <8901270937.AA02981@ztivax.uucp> Received: by ztivax.uucp; Fri, 27 Jan 89 10:37:29 -0100 To: commonloops.pa@Xerox.COM Subject: pcl-env.lisp This message is for LYRIC-PCL-users, who use pcl-env.lisp on no-cute-name-pcl. I keep having problems with the structure-editor when trying to edit eql-specified methods. The reason for this seems to be that the source code cannot be found by the editor. Example: (setf a (make-instance 'c2)) (defmethod foo ((par1 c1)(par2 (eql a))) ) (ed 'foo) will not find the definition of this method since in the methodobject the specializer-list is (c1 (eql #)) and the source code editor looks for a definition for (foo (c1 (eql #))) via il:{get|has}def, while the definiton of the method is stored under (foo (c1 (eql a))) Since I don't know about the internals of the editor I have made an attempt to patch this behaviour in pcl-env.lisp. See below. The idea is that whenever possible I store the definition under (foo (c1 (eql #))) in the first place. If anyone has a better solution I'd be glad to hear about it. Here is my solution. I only inserted the two mapcars. Matthias ;;; in File pcl-env.lisp (defun full-method-name (method) "Return the full name of the method" ; this mapcar inserted (let ((specializers (mapcar #'(lambda (x) (cond ((eq x 't) 't) ((and (listp x)(eq (car x) 'eql)) x) (T (class-name x)))) (method-type-specifiers method)))) ;; Now go through some hair to make sure that specializer is ;; really right. Once PCL returns the right value for ;; specializers this can be taken out. (let* ((arglist (method-arglist method)) (number-required (or (position-if #'(lambda (x) (member x lambda-list-keywords)) arglist) (length arglist))) (diff (- number-required (length specializers)))) (when (> diff 0) (setq specializers (nconc (copy-list specializers) (make-list diff :initial-element 't))))) (make-full-method-name (generic-function-name (method-generic-function method)) (method-qualifiers method) specializers))) (defun make-full-method-name (generic-function-name qualifiers arg-types) "Return the full name of a method, given the generic-function name, the method qualifiers, and the arg-types" ;; The name of the method is: ;; ( .. ;; ..) (labels ((remove-trailing-ts (l) (if (null l) nil (let ((tail (remove-trailing-ts (cdr l)))) (if (null tail) (if (eq (car l) 't) nil (list (car l))) (if (eq l tail) l (cons (car l) tail))))))) `(,generic-function-name ,@qualifiers ; this mapcar inserted ,(remove-trailing-ts (mapcar #'(lambda (elem) (cond ((and (listp elem) (eq (car elem) 'eql) (boundp (cadr elem))) `(eql ,(eval (cadr elem)))) (T elem))) arg-types))))) From Owners-CommonLoops.PA@Xerox.COM Fri Jan 27 07:28:12 1989 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA17231; Fri, 27 Jan 89 07:28:12 PST Received: from Chardonnay.ms by ArpaGateway.ms ; 27 JAN 89 07:28:17 PST Return-Path: <@arisia.Xerox.COM,@lll-winken.UUCP,@att:milich@whuts> Redistributed: CommonLoops.PA Received: from arisia.Xerox.COM ([13.1.100.206]) by Xerox.COM ; 27 JAN 89 07:24:40 PST Received: from lll-winken.UUCP by arisia.Xerox.COM with UUCP (5.59++/IDA-1.2.6) id AA17142; Fri, 27 Jan 89 07:24:10 PST Date: Fri, 27 Jan 89 07:24:10 PST From: "@lll-winken.UUCP"@Xerox.COM, milich%whuts@att.ARPA Message-Id: <8901271524.AA17142@arisia.Xerox.COM> Received: by lll-winken.llnl.gov (smail2.5) id AA13802; 27 Jan 89 06:52:02 PST (Fri) Received: by att.ATT.COM (smail2.6 - att-ih) id AA00447; 27 Jan 89 08:45:56 CST (Fri) To: CommonLoops.PA@Xerox.COM Subject: MetaClass I am trying to define my own metaclass using the (:metaclass my-meta-class) option. I'm not having much success. Below is a simple example: (defclass my-meta-class (standard-class) (mc-a mc-b) ) (defclass my-class () (a b) ) (defclass my-class1 (my-class) (c d) (:metaclass my-meta-class)) Why doesn't this work!! What am I doing wrong? I am using the latest version of pcl (12/7/88). Please Help. Thank you, greg milich milich@whuts.att.com From Owners-CommonLoops.PA@Xerox.COM Fri Jan 27 09:32:42 1989 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA18139; Fri, 27 Jan 89 09:32:42 PST Received: from Chardonnay.ms by ArpaGateway.ms ; 27 JAN 89 09:28:35 PST Return-Path: Redistributed: CommonLoops.PA Received: from PEBBLES.BBN.COM ([128.89.1.5]) by Xerox.COM ; 27 JAN 89 09:24:19 PST To: "@lll-winken.UUCP"@arisia.xerox.com, milich%whuts@att.arpa Cc: CommonLoops.PA@Xerox.COM Subject: Re: MetaClass In-Reply-To: Your message of Fri, 27 Jan 89 07:24:10 -0800. <8901271524.AA17142@arisia.Xerox.COM> Date: Fri, 27 Jan 89 12:20:16 -0500 From: kanderso@BBN.COM Message-Id: <890127-092835-11478@Xerox> Date: Fri, 27 Jan 89 07:24:10 PST From: "@lll-winken.UUCP"@Xerox.COM, milich%whuts@att.ARPA Message-Id: <8901271524.AA17142@arisia.Xerox.COM> Received: by lll-winken.llnl.gov (smail2.5) id AA13802; 27 Jan 89 06:52:02 PST (Fri) Received: by att.ATT.COM (smail2.6 - att-ih) id AA00447; 27 Jan 89 08:45:56 CST (Fri) To: CommonLoops.PA@Xerox.COM Subject: MetaClass I am trying to define my own metaclass using the (:metaclass my-meta-class) option. I'm not having much success. Below is a simple example: (defclass my-meta-class (standard-class) (mc-a mc-b) ) (defclass my-class () (a b) ) (defclass my-class1 (my-class) (c d) (:metaclass my-meta-class)) Why doesn't this work!! What am I doing wrong? I am using the latest version of pcl (12/7/88). Please Help. Thank you, greg milich milich@whuts.att.com Many people ask me this. As it stands, your metaclass is incompatiable with standard-class (the metaclass of my-class1). Add this mixin to metaclasses that can be mixed with standard-class: (defclass compatible-class-mixin () () (:documentation "A metaclass mixin that provides compatibility with standard-class.")) (defmethod check-super-metaclass-compatibility ((class compatibile-class-mixin) (super standard-class)) t) By default metaclasses are not compatible unless you say they are. This prevents oil from fixing with water. k From Owners-CommonLoops.PA@Xerox.COM Fri Jan 27 13:19:57 1989 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA23595; Fri, 27 Jan 89 13:05:03 PST Received: from Chardonnay.ms by ArpaGateway.ms ; 27 JAN 89 12:59:57 PST Return-Path: Redistributed: CommonLoops.PA Received: from hplms2.hpl.hp.com ([15.255.16.26]) by Xerox.COM ; 27 JAN 89 12:55:35 PST Received: from hpljsm.HPL.HP.COM (hpljsm.hpl.hp.com) by hplms2.hp.com; Fri, 27 Jan 89 12:55:24 pst Received: by hpljsm.HPL.HP.COM; Fri, 27 Jan 89 12:55:10 pst Date: Fri, 27 Jan 89 12:55:10 pst From: Joe Mohan Message-Id: <8901272055.AA04723@hpljsm.HPL.HP.COM> To: kanderso@BBN.COM Cc: "@lll-winken.UUCP"@arisia.xerox.com, milich%whuts@att.arpa, CommonLoops.PA@Xerox.COM In-Reply-To: kanderso@BBN.COM's message of Fri, 27 Jan 89 12:20:16 -0500 <890127-092835-11478@Xerox> Subject: MetaClass > Many people ask me this. As it stands, your metaclass is > incompatiable with standard-class (the metaclass of my-class1). Add Does the fact that many people ask this question say something about the intuitiveness of this design "feature"? Joe From Owners-commonloops.PA@Xerox.COM Fri Jan 27 15:52:28 1989 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA27177; Fri, 27 Jan 89 15:52:28 PST Received: from Cabernet.ms by ArpaGateway.ms ; 27 JAN 89 15:51:50 PST Return-Path: Redistributed: commonloops.PA Received: from ucbarpa.Berkeley.EDU ([128.32.137.8]) by Xerox.COM ; 27 JAN 89 15:48:48 PST Received: from franz.UUCP by ucbarpa.Berkeley.EDU (5.61/1.33) id AA00564; Fri, 27 Jan 89 15:22:40 -0800 Received: from ficl by franz (3.2/3.14) id AA15584; Fri, 27 Jan 89 15:16:02 PST Received: by ficl (4.0/3.14) id AA05213; Fri, 27 Jan 89 15:12:11 PST From: georgej%ficl%franz@ucbarpa.Berkeley.EDU (George Jacob) Return-Path: Message-Id: <8901272312.AA05213@ficl> To: "George R. Cross" Cc: commonloops.PA@Xerox.COM, cl-bugs%franz@ucbarpa.Berkeley.EDU, georgej%franz@ucbarpa.Berkeley.EDU Subject: Re: Tektronix ExCL vs PCL Date: Fri, 27 Jan 89 15:12:10 PST >> I am having trouble getting the latest version of PCL (12/7/88) running >> on ExCl 3.0.0.1 on a Tektronix 4317. The version of PCL shipped with the >> distribution is 5-87, an antique, so I got the latest. I've just mailed you a new fin.cl and a patch file that should allow you to compile the 12-7-88 PCL without incident. We apologize for the antiquity of the PCL that you got with the distribution, but it's a result of PCL versions being released more frequently than ExCL distributions. >> Where it matters, in fin.cl, the >> system is being treated as a sun3 since the test is for gsgc and not sun4. >> If I force sun4, fin.cl won't compile. >> Anyway, the compilation is halted in vector.cl with the following error. >> Any ideas? The comment about the sun3 (in the file fin.cl) is a relic from the days of the 5-87 PCL. It was intended, at the time, to include all Motorola 68K-based machines (such as the Tektronix 4317). It should now be updated to read "Everything except Sun4 and CRAY" to avoid creating the sort of confusion you have found yourself in. We will correct this as well. Thanks for bringing this to our attention. Please send mail to franz!cl-bugs if you have any further problems with ExCL. George Jacob Franz Inc. From Gregor.pa@Xerox.COM Fri Jan 27 17:39:02 1989 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA29131; Fri, 27 Jan 89 17:39:02 PST Received: from Semillon.ms by ArpaGateway.ms ; 27 JAN 89 17:35:29 PST Date: Fri, 27 Jan 89 17:31 PST From: Gregor.pa@Xerox.COM Subject: meta-object protocol To: Jacky Combs , Warren Harris , @.lll-winken.UUCP@Xerox.COM, milich%whuts@att.ARPA, kanderso@BBN.COM, Joe Mohan Cc: commonloops.pa@Xerox.COM Fcc: BD:>Gregor>mail>outgoing-mail-5.text.newest In-Reply-To: <8901170229.AA04700@topaz.STC.LOCKHEED.COM>, <4146.601069099@hplwhh>, <8901271524.AA17142@arisia.Xerox.COM>, The message of 27 Jan 89 09:20 PST from kanderso@BBN.COM, <8901272055.AA04723@hpljsm.HPL.HP.COM> Message-Id: <19890128013109.1.GREGOR@SPIFF.parc.xerox.com> Line-Fold: no Date: Mon, 16 Jan 89 20:29:06 CST From: Jacky Combs For example, I have defined "my-meta-class" as a subclass of "standard-class" so that I can define additional slots and methods for "my-meta-class". This definition works fine, but when I try to define a class as an instance of "my-meta-class" I get an error message from the method "check-super-metaclass-compatibility" telling me that a class and it's super have to be instances of the same class. Does this mean that PCL only supports a single metaclass and that ALL classes (including system classes have to be instances of the same class)? Date: Fri, 27 Jan 89 07:24:10 PST From:"@lll-winken.UUCP", milich%whuts@att.ARPA I am trying to define my own metaclass using the (:metaclass my-meta-class) option. I'm not having much success. Below is a simple example: Jacky Combs and Greg Milich both report the same problem. As Ken Anderson has pointed out to both of them, all that is happening is that the default behavior of check-super-metaclass-compatibility is to signal an error. All that needs to be done to solve this problem is to define a method on check-super-metaclass-compatibility that returns true rather than signalling an error. Some comments on why this is: The key point, is that when two incompatible metaclasses are mixed improperly, the results are undefined. (Note that I am using "results are undefined" as a technical term with the meaning defined in the CLOS specification). This is an important part of the design of the metaobject protocol. This allows the implementor of a metaclass to simply assume that all "super-metaclasses" of that metaclass will obey whatever special contract is required. Once two metaclasses enter into the super metaclasses contract, neither has to check to see if the other is violating the contract, they assume validity on the other's part. This is why the willingess of the two metaclasses to enter into the contract must be checked up front, before the classes are linked. So, the check-super-metaclass-compatibility generic function is called before the classes are linked. Date: Tue, 17 Jan 89 11:38:19 PST From: Warren Harris In this example I saw no reason why the super of OBJECT should be incompatible with MY-OBJECT. *All* functionality of STANDARD-CLASS has been inherited into MY-CLASS. It is true that in many common cases, the newly defined metaclass is compatible. But, CLOS has no way of knowing that. After all, it can't analyze your code to determine it! So, the decision we made was to have the standard method on check-super-metaclass-compatibility signal an error. The rationale is that since defining a new metaclass requires thinking so much about whether you are going to break the contract with standard-class anyways, the programmer should be forced to explicitly claim compatibility in this way. In some cases, the super-metaclass can be frobbed in some way and only then can the classes be compatible. ------- From CL-Cleanup-mailer@SAIL.STANFORD.EDU Fri Jan 27 20:39:47 1989 Received: from Sail.Stanford.EDU by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA01386; Fri, 27 Jan 89 20:39:47 PST Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 27 Jan 89 19:49:46 PST Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 528674; Fri 27-Jan-89 22:47:46 EST Date: Fri, 27 Jan 89 22:48 EST From: David A. Moon Subject: Issue: FUNCTION-NAME (Version 1) To: CL-Cleanup@SAIL.STANFORD.EDU, CL-Compiler@SAIL.STANFORD.EDU, Common-Lisp-Object-System@SAIL.STANFORD.EDU Message-Id: <19890128034814.6.MOON@EUPHRATES.SCRC.Symbolics.COM> Here is the new proposal for the SETF issue that I put up on slides at the X3J13 meeting. It's been refined a bit, according to the suggestions various people made. Assuming this remains in the Cleanup subcommittee, perhaps Larry should put this on the forthcoming letter ballot so we don't necessarily have to wait until March to deal with it. Issue: FUNCTION-NAME References: SETF rules for what -place- can be (pp.94-7) FBOUNDP function (p.90) FMAKUNBOUND function (p.92) FUNCTION special form (p.87) SYMBOL-FUNCTION and setf of symbol-function (p.90) 88-002R pages 1-21, 2-21, 2-26, 2-39, 2-44, 2-46, 2-51, and 2-55 (There are additional references for the MEDIUM and LARGE proposals, but they are not listed here. They're obvious.) Related issues: SETF-FUNCTION-VS-MACRO, SETF-PLACES (both subsumed by this) Category: ADDITION Edit history: Version 1, 23-Jan-89, by Moon (based on discussion at X3J13 meeting) Problem description: The Common Lisp Object System needs a well-defined way to relate the name and arguments of a writer function to those of a reader function, because both functions can be generic and can have user-defined methods. The way that was adopted into Common Lisp when X3J13 voted to accept document 88-002R was to use a list (SETF reader) as the name of the writer function. Some changes to the non-object-oriented portion of Common Lisp are required in order to support this. This issue has three proposals. Proposal (FUNCTION-NAME:SMALL): Add a new concept "function-name" (called "function-specifier" in 88-002R). A function-name is either a symbol or a 2-element list whose first element is the symbol SETF and whose second element is a symbol. Implementations are free to extend the syntax of function-names to include lists beginning with additional symbols other than SETF. Add a new function (FDEFINITION function-name), which returns the current global function definition named by function-name, or signals an error if there is no global function definition. This follows all the same rules listed for SYMBOL-FUNCTION in CLtL p.90. Add SETF of FDEFINITION to change the current global function definition named by a function-name. This follows all the same rules listed for SETF of SYMBOL-FUNCTION in CLtL p.90. Change the FBOUNDP and FMAKUNBOUND functions, and the FUNCTION special form, to accept function-names in place of symbols. Implementation defined extensions to the syntax of function-names cannot use the symbol LAMBDA, since FUNCTION already uses that symbol. Change the rules for SETF places (CLtL pp.94-7) by adding the following clause after all the existing clauses: - Any other list whose first element is a symbol, call it reader. In this case, SETF expands into a call to the function named by the list (SETF reader). The first argument is the new value and the remaining arguments are the values of the remaining elements of -place-. This expansion occurs regardless of whether reader or (SETF reader) is defined as a function locally, globally, or not at all. For example, (SETF (reader arg1 arg2...) new-value) expands into a form with the same effect and value as (LET ((#:temp-1 arg1) ;force correct order of evaluation (#:temp-2 arg2) ... (#:temp-0 new-value)) (FUNCALL (FUNCTION (SETF reader)) #:temp-0 #:temp-1 #:temp-2...)). Change the functions GET-SETF-METHOD and GET-SETF-METHOD-MULTIPLE-VALUE to implement the above change to the rules. Document that a function named (SETF reader) should return its first argument as its only value, in order to preserve the semantics of SETF. Change the macro DEFGENERIC and the function ENSURE-GENERIC-FUNCTION to refer to the function FDEFINITION where they now refer to the function SYMBOL-FUNCTION. Change the macros DEFCLASS, DEFGENERIC, and DEFMETHOD, the special forms GENERIC-FLET and GENERIC-LABELS, and the functions DOCUMENTATION and ENSURE-GENERIC-FUNCTION to use the term "function-name" where they now use the term "function-specifier" or "function specifier". Rationale for FUNCTION-NAME:SMALL: This is the minimum change to Common Lisp needed to do what 88-002R says about (SETF reader). Giving implementations freedom to extend the syntax of function-names allows for current practice. Changing the name from "function-specifier" to "function-name" avoids confusion and improves consistency with the rest of the language, at the cost of a few small changes to 88-002R. Proposal (FUNCTION-NAME:MEDIUM): Everything in FUNCTION-NAME:SMALL, and in addition: Change the DEFUN macro to accept a function-name for its name argument, instead of only accepting a symbol. If function-name is (SETF sym), the body is surrounded by an implicit block named sym. Rationale for FUNCTION-NAME:MEDIUM: Keeping DEFUN consistent with DEFMETHOD is a good idea. Also 88-002R says "The name of a generic function, like the name of an ordinary function, can be either a symbol or a two-element list whose...", which implies this change to DEFUN. Proposal (FUNCTION-NAME:LARGE): Everything in FUNCTION-NAME:MEDIUM, and in addition the following numbered points, each of which could be adopted independently, except where explicitly noted: 1. Change the function COMPILE to accept a function-name as its name argument. 2. Change the function DISASSEMBLE to accept a function-name as its name argument. 3. Change the FTYPE, INLINE, and NOTINLINE declarations and proclamations to accept function-names, not just symbols, as function names. 4. Change the FLET and LABELS special forms to accept a function-name in the name position, not just a symbol. 5. Change the TRACE and UNTRACE macros to accept function-names, not just symbols, in the function name positions. 6. Change the ED function to accept (ED function-name) in place of (ED symbol). 7. Change the syntax of a function call to allow a function-name as the first element of the list, rather than allowing only a symbol. 8. Change the DEFMACRO macro and the MACROLET special form to accept a function-name in the name position, not just a symbol. Change the MACRO-FUNCTION function to accept function-names, not just symbols. Change the last rule for SETF places to use ((SETF reader) #:temp-0 #:temp-1 #:temp-2...) in place of (FUNCALL (FUNCTION (SETF reader)) #:temp-0 #:temp-1 #:temp-2...) so that (SETF reader) can be defined as a macro. This depends on item 7. If item 4 is rejected, MACROLET should be stricken from this item. 9. Add an optional environment argument to FDEFINITION, SETF of FDEFINITION, FBOUNDP, and FMAKUNBOUND. This is the same as the &environment argument to a macroexpander. This argument can be used to access local function definitions, to access function definitions in the compile-time remote environment, and to modify function definitions in the compile-time remote environment. 10. Change the second, third, fourth, fifth, seventh, and ninth rules for SETF places so that they only apply when the function-name refers to the global function definition, rather than a locally defined function or macro. (The ninth rule is the one that refers to DEFSETF and DEFINE-SETF-METHOD; the other rules listed are the ones that list specific built-in functions). The effect of this change is that SETF methods defined for global functions are ignored when there is a local function binding; instead, the function named (SETF reader), which may have a local function binding, is called. This change is most useful in connection with item 4, but does not actually depend on it. 11. Clarify that the eighth rule for SETF places (the one for macros) uses MACROEXPAND-1, not MACROEXPAND. Rationale for FUNCTION-NAME:LARGE: This extends the new feature throughout the language, in order to make things generally more consistent and powerful. Point by point: 1,2,3 - one should be able to compile, examine, and make declarations about functions regardless of whether they are named with symbols or with lists. 4 - locally defined non-generic SETF functions are a logical companion to locally defined generic SETF functions, which can be defined with GENERIC-FLET or GENERIC-LABELS. They make sense on their own, since one might define a local reader function and want a local writer function to go with it. 5,6 - one should be able to apply development tools to functions regardless of how they are named. The function DOCUMENTATION was already updated to work for function-names by 88-002R. There might be some difficulty with implementation-dependent syntax extensions to TRACE and UNTRACE conflicting with this new syntax. 7 - this restores consistency between the FUNCTION special form and the first element of a function call form. 8 - it seems more consistent to allow macros to be named the same way that ordinary functions are named. However, this might be considered redundant with DEFSETF. 9 - this is not needed by the "chapter 1 and 2" level of CLOS, but might be used by the metaobject based implementation of ENSURE-GENERIC-FUNCTION. 10 - this change was in SETF-FUNCTION-VS-MACRO and makes item 4 more useful. 11 - this change was in SETF-FUNCTION-VS-MACRO and is a good idea, but actually is independent of everything else being proposed here. Examples: ;This is an example of the sort of syntax 88-002R allows (defmethod (setf child) (new-value (parent some-class)) (setf (slot-value 'child parent) new-value) (update-dependencies parent) new-value) (setf (child foo) bar) ;If SETF of SUBSEQ was not already built into Common Lisp, ;it could have been defined like this, if the MEDIUM or LARGE ;proposal is adopted. (defun (setf subseq) (new-value sequence start &optional end) (unless end (setq end (length sequence))) (setq end (min end (+ start (length new-value)))) (do ((i start (1+ i)) (j 0 (1+ j))) ((= i end) new-value) (setf (elt sequence i) (elt new-value j)))) ;The preceding example would have to be defined like this ;if only the SMALL proposal is adopted. This is a method ;all of whose parameter specializer names are T. (defmethod (setf subseq) (new-value sequence start &optional end) (unless end (setq end (length sequence))) (setq end (min end (+ start (length new-value)))) (do ((i start (1+ i)) (j 0 (1+ j))) ((= i end) new-value) (setf (elt sequence i) (elt new-value j)))) ;Another example, showing a locally defined setf function (defun frobulate (mumble) (let ((table (mumble-table mumble))) (flet ((foo (x) (gethash x table)) ((setf foo) (new x) (setf (gethash x table) new))) .. (foo a) .. (setf (foo a) b)))) ;get-setf-method could implement setf functions by calling ;this function when the earlier rules do not apply (defun get-setf-method-for-setf-function (form) (let ((new-value (gensym)) (temp-vars (do ((a (cdr form) (cdr a)) (v nil (cons (gensym) v))) ((null a) v)))) (values temp-vars (cdr form) (list new-value) `(funcall #'(setf ,(car form)) ,new-value ,@temp-vars) `(,(car form) ,@temp-vars)))) Current practice: No implementation supports exactly what is proposed. Symbolics Genera and the TI Explorer support something close to the MEDIUM proposal, but differing in a number of details. Symbolics Genera supports items 1, 2, 3, 6, and 11, and modified forms of items 5 and 8, of the LARGE proposal. Moon considers this proposal's variations from Symbolics current practice to be an improvement, although incompatible in some cases. Many implementations currently support only symbols as function names. Symbolics Genera and the TI Explorer have some additional function-name syntaxes. Cost to Implementors: The SMALL and MEDIUM proposals are estimated to be no more than 50 lines of code and require no changes to the "guts" of the interpreter and compiler. Most of the code for this can be written portably and was shown on two slides at the X3J13 meeting. Some of the changes in the LARGE proposal are trivial, some require the compiler to use EQUAL instead of EQ to compare function names, and items 4, 7, and 8 might require a more substantial implementation effort. Even that effort is estimated to be negligible compared to the effort required to implement CLOS. Cost to Users: No cost to users, other than program-understanding programs, since this is an upward compatible addition. As with any language extension, some program-understanding programs may need to be enhanced. A particular issue here is programs that assume that all function names are symbols. They may use GET to access properties of a function name or use EQ or EQL (perhaps via MEMBER or ASSOC) to compare function names for equality. Such programs will need improvement before they can understand programs that use the new feature, but otherwise they will still work. Cost of non-adoption: We would have to make some other language change since the language became inconsistent when 88-002R was adopted. Performance impact: This has no effect on performance of compiled code. It might slow down the compiler and interpreter but not by very much. Benefits: CLOS will work as designed. Esthetics: Some people dislike using anything but symbols to name functions. Other people would prefer that if the change is to be made at all, the LARGE proposal be adopted so that the language is uniform in its treatment of the new extended function names. Other proposals for how to deal with SETF in CLOS were considerably less esthetic, especially when package problems are taken into account. SETF would be more esthetic, but less powerful, if it had only the proposed setf functions and did not have setf macros. Such a major incompatible change is of course out of the question; however, if setf functions are stressed over setf macros, SETF will be much easier to teach. Discussion: Moon supports at least FUNCTION-NAME:MEDIUM. He does not necessarily approve of all parts of FUNCTION-NAME:LARGE. From Common-Lisp-Object-System-mailer@SAIL.STANFORD.EDU Sun Jan 29 13:23:57 1989 Received: from Sail.Stanford.EDU by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA21652; Sun, 29 Jan 89 13:23:57 PST Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 29 Jan 89 13:24:54 PST Received: from defun.utah.edu by cs.utah.edu (5.59/utah-2.1-cs) id AA22781; Sun, 29 Jan 89 14:23:25 MST Received: by defun.utah.edu (5.59/utah-2.0-leaf) id AA23486; Sun, 29 Jan 89 14:22:46 MST From: sandra%defun@cs.utah.edu (Sandra J Loosemore) Message-Id: <8901292122.AA23486@defun.utah.edu> Date: Sun, 29 Jan 89 14:22:45 MST Subject: Re: Issue: FUNCTION-NAME (Version 1) To: David A. Moon Cc: CL-Cleanup@SAIL.STANFORD.EDU, Common-Lisp-Object-System@SAIL.STANFORD.EDU In-Reply-To: David A. Moon , Fri, 27 Jan 89 22:48 EST On the whole, I like this presentation much better than either of the other two writeups that were circulated previously. I suspect that it might be necessary to vote on each of the items in the LARGE proposal individually, though. I think I would support items 1, 2, and 11, and don't have any particular objections to 3, 5, and 6. For item 4, if consistency with GENERIC-FLET and GENERIC-LABELS is an object, another alternative is to change those two special forms to be like ordinary FLET and LABELS, instead of vice versa. -Sandra ------- From CL-Cleanup-mailer@SAIL.STANFORD.EDU Mon Jan 30 07:26:51 1989 Received: from Sail.Stanford.EDU by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA00048; Mon, 30 Jan 89 07:26:51 PST Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 30 Jan 89 07:20:34 PST Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 529874; Mon 30-Jan-89 10:18:34 EST Date: Mon, 30 Jan 89 10:18 EST From: Kent M Pitman Subject: Issue: FUNCTION-NAME (Version 1) To: Moon@STONY-BROOK.SCRC.Symbolics.COM Cc: CL-Cleanup@SAIL.STANFORD.EDU, CL-Compiler@SAIL.STANFORD.EDU, Common-Lisp-Object-System@SAIL.STANFORD.EDU In-Reply-To: <19890128034814.6.MOON@EUPHRATES.SCRC.Symbolics.COM> Message-Id: <890130101826.4.KMP@BOBOLINK.SCRC.Symbolics.COM> I'm still thinking about this, but while I am I wanted point out that MEDIUM is unacceptable to me because I don't think FLET and DEFUN should disagree on what they permit as defined names. If FLET were added to MEDIUM, I suspect I'd think it was an internally consistent position. LARGE has an appeal to me in general, but I'm still mulling over the specifics. I'll reply in more detail later. From Common-Lisp-Object-System-mailer@SAIL.STANFORD.EDU Mon Jan 30 10:02:23 1989 Received: from Sail.Stanford.EDU by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA03987; Mon, 30 Jan 89 10:02:23 PST Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 30 Jan 89 10:03:07 PST Received: from Semillon.ms by ArpaGateway.ms ; 30 JAN 89 10:00:38 PST Date: Mon, 30 Jan 89 10:00 PST From: Gregor.pa@Xerox.COM Subject: Issue: FUNCTION-NAME (Version 1) To: David A. Moon Cc: CL-Cleanup@SAIL.STANFORD.EDU, CL-Compiler@SAIL.STANFORD.EDU, Common-Lisp-Object-System@SAIL.STANFORD.EDU Fcc: BD:>Gregor>mail>outgoing-mail-5.text.newest In-Reply-To: <19890128034814.6.MOON@EUPHRATES.SCRC.Symbolics.COM> Message-Id: <19890130180031.2.GREGOR@SPIFF.parc.xerox.com> Line-Fold: no I support FUNCTION-NAME:MEDIUM and may support LARGE once I think about it some more. As I explained in Hawaii, support for either of these is based on the :conc-name bugs being removed from the condition system. Of course, I believe the best way to do that is to CLOSify it. ------- From Owners-commonloops.pa@Xerox.COM Mon Jan 30 10:55:13 1989 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA04004; Mon, 30 Jan 89 10:03:31 PST Received: from Chardonnay.ms by ArpaGateway.ms ; 30 JAN 89 10:03:10 PST Return-Path: <@EN-C06.Prime.COM,@NET.Prime.COM,@s66.Prime.COM:BARRYN@s66.prime.com> Redistributed: commonloops.pa Received: from EN-C06.Prime.COM ([192.5.58.32]) by Xerox.COM ; 30 JAN 89 09:01:30 PST Received: from NET.Prime.COM by EN-C06.Prime.COM; 30 Jan 89 12:02:18 EST Received: from s66.Prime.COM by NET.Prime.COM; 30 Jan 89 12:00:14 EST Received: (from user BARRYN) by s66.Prime.COM; 30 Jan 89 12:00:31 EDT Subject: meta-object protocol To: commonloops.pa@Xerox.COM From: BARRYN@s66.prime.com Date: 30 Jan 89 12:00:31 EDT Message-Id: <890130-100310-5244@Xerox> The problem with the default behavior of check-super-metaclass-compatibility is NOT that it gives an error. The problem is that the error message gives no clue as to how to fix the problem! If the error message revealed that a redefinition of check-super-metatclass-compatibility is required when inheriting from standard-class then the misunderstanding would go away. check-super-metaclass-compatibility should be coded as a "must be implemented" method. If you reach the standard one, you get an error message telling you that your subclass must implement, rather than inherit, this particular method. I believe Smalltalk has this concept. From Owners-commonloops.pa@Xerox.COM Mon Jan 30 11:42:33 1989 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA06561; Mon, 30 Jan 89 11:42:33 PST Received: from Riesling.ms by ArpaGateway.ms ; 30 JAN 89 11:41:47 PST Return-Path: Redistributed: commonloops.pa Received: from shrike.Austin.Lockheed.COM ([192.31.24.65]) by Xerox.COM ; 30 JAN 89 11:38:21 PST Received: by shrike.Austin.Lockheed.COM (4.0/1.41); Mon, 30 Jan 89 13:37:45 CST Received: by opal.STC.LOCKHEED.COM (3.2/1.27); Mon, 30 Jan 89 13:29:00 CST Received: by topaz.STC.LOCKHEED.COM (3.2/1.1); Mon, 30 Jan 89 13:28:59 CST Date: Mon, 30 Jan 89 13:28:59 CST From: Jacky Combs Message-Id: <8901301928.AA20597@topaz.STC.LOCKHEED.COM> To: gregor.pa@Xerox.COM Subject: RE:metaclass Cc: commonloops.pa@Xerox.COM Thanks for responding to my metaobject query, but I still have a question. I have no problem with PCL's "compatibility checking" in the metaobject protocol, but to say that defining a corresponding check-super-metaclass-compatibility method is all that one needs to do in order to define another metaclass is a bit misleading. For example if the new metaclass is to be redefined correctly one needs to also define the necesary class-for-redefinition methods. My question is, other than the source code, how can I find out what PCL's design of the metaobject protocol is? It is my understanding that Chapter Three (MetaObject Protocol) of the CLOS Specifications is not available. Since defining metaclasses in PCL seems to be a poorly understood task right now, it would really help to have some general information about the topic. I realize that the specific behavior of a user-defined metaclass dictates what some of the method definitions must be. For example I have defined the metaclass EXTENSION-META for classes that maintain a list of their current instances; therefore I needed to add methods to *make-instance, update-instances-for-different-class, and update-instances-for-redefined-class. Any information on metaobject creation would be most helpful. Thanks. Jacky combs@stc.lockeed.com From Owners-commonloops.pa@Xerox.COM Mon Jan 30 14:40:04 1989 Received: from Xerox.COM by arisia with SMTP (5.59++/IDA-1.2.6) id AA00244; Mon, 30 Jan 89 14:40:04 PST Received: from Riesling.ms by ArpaGateway.ms ; 30 JAN 89 12:48:36 PST Return-Path: Redistributed: commonloops.pa Received: from shrike.Austin.Lockheed.COM ([192.31.24.65]) by Xerox.COM ; 30 JAN 89 12:46:14 PST Received: by shrike.Austin.Lockheed.COM (4.0/1.41); Mon, 30 Jan 89 14:45:39 CST Received: by opal.STC.LOCKHEED.COM (3.2/1.27); Mon, 30 Jan 89 14:33:26 CST Received: by topaz.STC.LOCKHEED.COM (3.2/1.1); Mon, 30 Jan 89 14:33:26 CST Date: Mon, 30 Jan 89 14:33:26 CST From: Jacky Combs Message-Id: <8901302033.AA21004@topaz.STC.LOCKHEED.COM> To: commonloops.pa@Xerox.COM Subject: extension metaclass I am enclosing some code defining the metaclass EXTENSION-META. I wanted to be able to define classes with the slot CLASS-INSTANCES whose value was a list of current instances of the class. I would appreciate any comments or suggestions. Also any examples of defining metaclasses with other specific behavior. Thanks Jacky ;;;-*-Mode:LISP; Package:(PCL LISP 1000); Base:10; Syntax:Common-lisp -*- ;;; This file contains an example of the additional code needed to implement a ;;; user defined META CLASS. In order to inherit the functionality (slots and ;;; methods) of the system META class STANDARD-CLASS, a user defined META class ;;; must have STANDARD-CLASS in its list of SUPERS. ;;; Here we have defined the metaclass, EXTENSION-META, and added the new slot, ;;; EXTENSIONS, that will maintain a list of INSTANCE-OBJECTS. (defclass extension-meta (standard-class) ((extensions :initform nil :accessor class-instances))) ;;; We need an additional definition (a more specific definition) of ;;; CHECK-SUPER-METACLASS-COMPATIBILITY to handle our EXTENSION-META metaclass. (defmethod check-super-metaclass-compatibility ((x extension-meta) (y standard-class)) 't) ;;; We need to define additional methods for CLASS-FOR-REDEFINITION to handle ;;; cases when the new metaclass and old metaclass are not the same. And ;;; because of the specific behavior of EXTENSION-META we need to mark the ;;; instances of the redefined class obsolete if it's previous class were ;;; STANDARD-CLASS and its current class EXTENSION-META. (defmethod class-for-redefinition ((old-class extension-meta) (proto-class standard-class) name local-supers local-slot-slotds extra) (declare (ignore name local-supers local-slot-slotds extra)) (change-class old-class (class-of proto-class)) old-class) (defmethod class-for-redefinition ((old-class standard-class) (proto-class extension-meta) name local-supers local-slot-slotds extra) (declare (ignore name local-supers local-slot-slotds extra)) (change-class old-class (class-of proto-class)) (make-instances-obsolete old-class) old-class) ;;; Here is the additional *MAKE-INSTANCE definition to handle EXTENSION-META ;;; classes so that as instances are created, they are added to the class' ;;; EXTENSION slot. (defmethod *make-instance ((class extension-meta) &rest args) (declare (ignore args)) (let ((new-instance (call-next-method))) (setf (class-instances class) (push new-instance (class-instances class))) new-instance)) ;;; Here are additions to the UPDATE-INSTANCE-FOR-DIFFERENT-CLASS method along ;;; with defintions for a new method UPDATE-EXTENSIONS-DIFF-CLASS that we need ;;; to handle EXTENSION-META class. (defmethod update-instance-for-different-class :after ((previous object)(current object) &rest args) (declare (ignore args)) (let ((old-class (class-of previous)) (new-class (class-of current))) (update-extensions-diff-class old-class new-class current))) (defmethod update-extensions-diff-class ((old standard-class)(new standard-class) cur) (declare (ignore cur)) t) (defmethod update-extensions-diff-class ((old standard-class)(new extension-meta) cur) (setf (class-instances new) (cons cur (class-instances new)))) (defmethod update-extensions-diff-class ((old extension-meta)(new extension-meta) cur) (setf (class-instances old) (remove cur (class-instances old) :test 'equal)) (setf (class-instances new) (cons cur (class-instances new)))) (defmethod update-extensions-diff-class ((old extension-meta)(new standard-class) cur) (setf (class-instances old) (remove cur (class-instances old) :test 'equal))) ;;; Here is the addition to the UPDATE-INSTANCE-FOR-REDEFINED-CLASS method ;;; along with definitions for a new method UPDATE-INSTNACE-FOR-REDEFINED-CLASS ;;; that we need to handle EXTENSION-META class. (defmethod update-instance-for-redefined-class :after ((instance object) &rest args) (declare (ignore args)) (let ((redef-class (class-of instance))) (update-extensions-redef-class redef-class instance))) (defmethod update-extensions-redef-class ((redef-class standard-class) instance) (declare (ignore instance)) t) (defmethod update-extensions-redef-class ((redef-class extension-meta) instance) (if (member instance (class-instances redef-class) :test 'equal) nil (setf (class-instances redef-class) (cons instance (class-instances redef-class))))) From Owners-commonloops.pa@Xerox.COM Mon Jan 30 14:54:30 1989 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA06561; Mon, 30 Jan 89 11:42:33 PST Received: from Riesling.ms by ArpaGateway.ms ; 30 JAN 89 11:41:47 PST Return-Path: Redistributed: commonloops.pa Received: from shrike.Austin.Lockheed.COM ([192.31.24.65]) by Xerox.COM ; 30 JAN 89 11:38:21 PST Received: by shrike.Austin.Lockheed.COM (4.0/1.41); Mon, 30 Jan 89 13:37:45 CST Received: by opal.STC.LOCKHEED.COM (3.2/1.27); Mon, 30 Jan 89 13:29:00 CST Received: by topaz.STC.LOCKHEED.COM (3.2/1.1); Mon, 30 Jan 89 13:28:59 CST Date: Mon, 30 Jan 89 13:28:59 CST From: Jacky Combs Message-Id: <8901301928.AA20597@topaz.STC.LOCKHEED.COM> To: gregor.pa@Xerox.COM Subject: RE:metaclass Cc: commonloops.pa@Xerox.COM Thanks for responding to my metaobject query, but I still have a question. I have no problem with PCL's "compatibility checking" in the metaobject protocol, but to say that defining a corresponding check-super-metaclass-compatibility method is all that one needs to do in order to define another metaclass is a bit misleading. For example if the new metaclass is to be redefined correctly one needs to also define the necesary class-for-redefinition methods. My question is, other than the source code, how can I find out what PCL's design of the metaobject protocol is? It is my understanding that Chapter Three (MetaObject Protocol) of the CLOS Specifications is not available. Since defining metaclasses in PCL seems to be a poorly understood task right now, it would really help to have some general information about the topic. I realize that the specific behavior of a user-defined metaclass dictates what some of the method definitions must be. For example I have defined the metaclass EXTENSION-META for classes that maintain a list of their current instances; therefore I needed to add methods to *make-instance, update-instances-for-different-class, and update-instances-for-redefined-class. Any information on metaobject creation would be most helpful. Thanks. Jacky combs@stc.lockeed.com From Owners-commonloops.pa@Xerox.COM Tue Jan 31 07:18:54 1989 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA13044; Tue, 31 Jan 89 07:18:54 PST Received: from Cabernet.ms by ArpaGateway.ms ; 31 JAN 89 06:41:54 PST Return-Path: Redistributed: commonloops.pa Received: from lucid.com ([192.26.25.1]) by Xerox.COM ; 31 JAN 89 06:39:02 PST Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA04051g; Tue, 31 Jan 89 06:34:59 PST Received: by bhopal id AA15178g; Tue, 31 Jan 89 06:37:19 PST Date: Tue, 31 Jan 89 06:37:19 PST From: Jon L White Message-Id: <8901311437.AA15178@bhopal> To: Alpern@IBM.COM Cc: rik%cs@UCSD.EDU, commonloops.pa@Xerox.COM In-Reply-To: David Alpern's message of Thu, 26 Jan 89 15:01:00 PST <890126-160337-10069@Xerox> Subject: PCL under Lucid re: It's Lucid's 1.01 for the RT, which I think is roughly equivalent to the 2.1 Sun version. I've be very surprised if the Lucid 1.01 release on the RT is really enough like the Sun3/2.1 release so that no further conditionalizations are required. I notice that the current PCL release seems to be trying to compensate for something by "snooping" at the results of (machine-type), and creating a :IBM-RT-PC feature under certain conditions. re: Anyhow, I also get the error Richard has reported (his message of 12/21) I don't seem to have that report handy -- could you be more specific? If it's about the early compiler bug that shows up while compiling 'describe-instance', then I have a simple soluton for that. -- JonL -- From Owners-commonloops.pa@Xerox.COM Tue Jan 31 07:21:17 1989 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA13087; Tue, 31 Jan 89 07:21:17 PST Received: from Salvador.ms by ArpaGateway.ms ; 31 JAN 89 06:50:58 PST Return-Path: Redistributed: commonloops.pa Received: from lucid.com ([192.26.25.1]) by Xerox.COM ; 31 JAN 89 06:48:11 PST Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA04054g; Tue, 31 Jan 89 06:44:30 PST Received: by bhopal id AA15197g; Tue, 31 Jan 89 06:46:50 PST Date: Tue, 31 Jan 89 06:46:50 PST From: Jon L White Message-Id: <8901311446.AA15197@bhopal> To: Alpern@IBM.COM Cc: commonloops.pa@Xerox.COM In-Reply-To: David Alpern's message of Thu, 26 Jan 89 18:53:02 PST <890126-193035-10567@Xerox> Subject: PCL on LUCID re: The problem is due to the call to sys::defadvice at the bottom of lucid-low. Is it safe to just conditionalize this on LCL3.0 and exclude the whole function call otherwise? DEFADVICE is only present in 3.0 releases; by all means, that code should be under #+LCL3.0. Apparently, its purpose is merely to make the function ARGLIST useable in place of GENERIC-FUNCTION-PRETTY-ARGLIST. -- JonL -- From Owners-commonloops.pa@Xerox.COM Tue Jan 31 08:25:36 1989 Received: from [13.0.12.232] by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA13548; Tue, 31 Jan 89 08:25:36 PST Received: from Semillon.ms by ArpaGateway.ms ; 31 JAN 89 08:24:37 PST Return-Path: Redistributed: commonloops.pa Received: from Score.Stanford.EDU ([10.3.0.11]) by Xerox.COM ; 31 JAN 89 08:21:51 PST Date: Tue, 31 Jan 89 08:21:25 PST From: Dan Larner Subject: :allocation of :class, ... To: commonloops.pa@Xerox.COM Message-Id: <12466960868.24.LARNER@Score.Stanford.EDU> I'm encountering a difficulty (illustrated below) with the inheritance of slots having :allocation of :class (using AAAI88 PCL). Is this a problem, or am I misinterpreting the CLOS spec? Also, the use of subtype to determine relationships between classes appears to be unavailable. (I've been unable to find anything on these in either the xxx-notes files or the recent items on the mailing list. Is there a public list of known problems and as yet unimplemented features (beyond reading the xxx-notes files) so that one can easily check for an existing notice of a seemingly new observation?) Finally, the last item is a HACK to defclass so that it returns the newly defined class, and so far this HACK has not caused me any problems. ;;; define a class 'a', with one class slot called shared > (defclass a () ((shared :allocation :class :accessor shared :initform nil))) NIL ;;; define a simple subclass 'b' of 'a' > (defclass b (a) ()) NIL ;;; make instances of both 'a' and 'b' > (setf ai (*make-instance 'a) bi (*make-instance 'b)) # ;;; put a value into the shared slot of ai > (setf (shared ai) '(hello)) (HELLO) ;;; show ai and bi, and find that bi's class slot is different from ai's, ;;; even though the b class did not redefine the slot > (describe ai) # is an instance of class #: The following slots have :CLASS allocation: SHARED (HELLO) > (describe bi) # is an instance of class #: The following slots have :CLASS allocation: SHARED NIL ;;; Also, am unable to determine type relationships > (subtypep 'b 'a) NIL NIL > ;;; but now, try it again using a surgical operation, - it seems like the ;;; class slots start out pointing to the same place, but then get corrupted ;;; when the entire value is replaced > (defclass x () ((shared :allocation :class :initform '(1 2 3) :accessor shared))) NIL > (defclass y (x) ()) NIL > (setf xi (*make-instance 'x) yi (*make-instance 'y)) # > (rplacd (shared xi) '(hello)) (1 HELLO) > (describe xi) # is an instance of class #: The following slots have :CLASS allocation: SHARED (1 HELLO) > (describe yi) # is an instance of class #: The following slots have :CLASS allocation: SHARED (1 HELLO) > (setf (shared yi) 45) 45 > (describe yi) # is an instance of class #: The following slots have :CLASS allocation: SHARED 45 > (describe xi) # is an instance of class #: The following slots have :CLASS allocation: SHARED (1 HELLO) > ;;; Hacked defclass - so that it returns the new class object (defmacro DEFCLASS (name includes slots &rest options) (declare (indentation 2 4 3 1)) (let ((metaclass 'standard-class)) ;; Now go see if there is a :metaclass option. We need that before we ;; can do anything else. If there is a :metaclass option, we remove it ;; from the options -- it isn't needed anymore since the class-protype ;; communicates the same information. (dolist (option options) (if (not (listp option)) (error "~S is not a legal defclass option." option) (when (eq (car option) ':metaclass) (unless (legal-class-name-p (cadr option)) (error "The value of the :metaclass option (~S) is not a~%~ legal class name." (cadr option))) (unless (find-class (cadr option) nil) (error "The value of the :metaclass option (~S) does not name~%~ a currently defined class. The metaclass must be~%~ defined at the time the defclass form is compiled or~%~ evaluated." (cadr option))) (setq metaclass (cadr option) options (remove option options))))) ;; A HACK - append a find-class form to the returned form so that the ;; class will be returned instead of NIL (append (let ((prototype-class (class-prototype (find-class metaclass)))) (make-top-level-form `(defclass ,name) '(compile load eval) (expand-defclass prototype-class name includes slots options))) `((find-class ,(list 'quote name)))))) ------- From Owners-CommonLoops.PA@Xerox.COM Tue Jan 31 19:08:33 1989 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA23996; Tue, 31 Jan 89 19:08:33 PST Received: from Chardonnay.ms by ArpaGateway.ms ; 31 JAN 89 18:13:43 PST Return-Path: Redistributed: CommonLoops.PA Received: from vaxa.isi.edu ([128.9.0.33]) by Xerox.COM ; 31 JAN 89 18:10:29 PST Posted-Date: Tue, 31 Jan 89 18:11:04 PST Received: from LOCALHOST by vaxa.isi.edu (5.59/5.51) id AA09090; Tue, 31 Jan 89 18:11:08 PST To: CommonLoops.PA@Xerox.COM Subject: "advise" in 12/7 3600-low.lisp Date: Tue, 31 Jan 89 18:11:04 PST Message-Id: <9086.602302264@vaxa.isi.edu> From: Dave Brill On a Symbolics 3600, running Genera 7.2, the following advice (from file 3600-low) seems to be the cause of trouble in the scheduler. (Immediate symptom: attempt to apply RPLACD to 2 causes the scheduler to drop into the cold load stream; the RPLACD is buried in the advice.) If any other sites have reported this problem, we would like to know that we are not alone; if it has not appeared anywhere else, we may begin to suspect an arcane hardware defect. It seems only to affect one 3600--a file server--here. (defun pcl-function-name-advice-1 (arglist values &aux temp) (if (and (fboundp 'funcallable-instance-p) (funcallable-instance-p (car arglist)) (fboundp 'generic-function-p) (generic-function-p (car arglist)) (fboundp 'generic-function-name) (setq temp (generic-function-name (car arglist)))) (list temp) values)) (zl:advise si:function-name :after pcl-function-name-advice () (setq values (pcl-function-name-advice-1 zl:arglist values))) If no one can suggest a patch, can anyone tell us what might happen if we just deleted the "advise" call? From Owners-CommonLoops.PA@Xerox.COM Tue Jan 31 20:10:30 1989 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA23996; Tue, 31 Jan 89 19:08:33 PST Received: from Chardonnay.ms by ArpaGateway.ms ; 31 JAN 89 18:13:43 PST Return-Path: Redistributed: CommonLoops.PA Received: from vaxa.isi.edu ([128.9.0.33]) by Xerox.COM ; 31 JAN 89 18:10:29 PST Posted-Date: Tue, 31 Jan 89 18:11:04 PST Received: from LOCALHOST by vaxa.isi.edu (5.59/5.51) id AA09090; Tue, 31 Jan 89 18:11:08 PST To: CommonLoops.PA@Xerox.COM Subject: "advise" in 12/7 3600-low.lisp Date: Tue, 31 Jan 89 18:11:04 PST Message-Id: <9086.602302264@vaxa.isi.edu> From: Dave Brill On a Symbolics 3600, running Genera 7.2, the following advice (from file 3600-low) seems to be the cause of trouble in the scheduler. (Immediate symptom: attempt to apply RPLACD to 2 causes the scheduler to drop into the cold load stream; the RPLACD is buried in the advice.) If any other sites have reported this problem, we would like to know that we are not alone; if it has not appeared anywhere else, we may begin to suspect an arcane hardware defect. It seems only to affect one 3600--a file server--here. (defun pcl-function-name-advice-1 (arglist values &aux temp) (if (and (fboundp 'funcallable-instance-p) (funcallable-instance-p (car arglist)) (fboundp 'generic-function-p) (generic-function-p (car arglist)) (fboundp 'generic-function-name) (setq temp (generic-function-name (car arglist)))) (list temp) values)) (zl:advise si:function-name :after pcl-function-name-advice () (setq values (pcl-function-name-advice-1 zl:arglist values))) If no one can suggest a patch, can anyone tell us what might happen if we just deleted the "advise" call? From Common-Lisp-Object-System-mailer@SAIL.STANFORD.EDU Wed Feb 1 10:34:06 1989 Received: from Sail.Stanford.EDU by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA09065; Wed, 1 Feb 89 10:34:06 PST Received: from ti.com by SAIL.Stanford.EDU with TCP; 1 Feb 89 10:34:04 PST Received: by ti.com id AA05320; Wed, 1 Feb 89 12:32:56 CST Received: from Kelvin by tilde id AA23091; Wed, 1 Feb 89 12:19:06 CST Message-Id: <2811349106-616742@Kelvin> Sender: GRAY@Kelvin.csc.ti.com Date: Wed, 1 Feb 89 12:18:26 CST From: David N Gray To: Gregor.pa@Xerox.COM Cc: Common-Lisp-Object-System@SAIL.STANFORD.EDU Subject: editorial comments on chapter 3 Following are some questions, comments, and suggestions about Meta Object Protocol draft 10 [document 89-003 dated 12/15/88]. This message is limited to comments on the document itself; questions about the protocol design will be raised in separate messages to follow. page 3-9 -- class METAOBJECT is shown as a subclass of FUNCTION; that must be a mistake since it would imply that class objects and slot definitions are funcallable. p. 3-16 and 3-17 - don't the calls to ENSURE-GENERIC-FUNCTION require a :LAMBDA-LIST argument? Generic function EFFECTIVE-SLOT-DEFINITION-CLASS is mentioned on pages 3-24, 3-45, and 3-47, but it is not included in the individual function specifications. On page 3-24, it appears that "class finalization protocol" and "instance structure protocol" ought to be section headings. Bottom of page 3-25 "location must be a positive integer" -- does that mean not negative or greater than zero? Page 3-26 mentions functions STANDARD-INSTANCE-ACCESS, FUNCALLABLE-STANDARD-INSTANCE-ACCESS, and STRUCTURE-INSTANCE-ACCESS, which are not detailed later. p. 3-26, SET-FUNCALLABLE-INSTANCE --> SET-FUNCALLABLE-INSTANCE-FUNCTION p. 3-27 -- FUNCALLABLE-STANDARD-CLASS is mentioned in several places, but there is still no definition of just what it is. p. 3-33 - Shouldn't ADD-METHOD be specified to alter the method object by storing the value to be returned by METHOD-GENERIC-FUNCTION? I assume that "if the method object is a method object of another generic function ..." means to check the value returned by METHOD-GENERIC-FUNCTION before storing the new value? p. 3-33 not clear what "... readers of the method object are expected to be invariant ..." means; is this talking about the definition of the accessor methods or the values that they access? Or both? p. 3-35 - Description of ALLOCATE-INSTANCE should mention that it is called by MAKE-INSTANCE. (not shown on graph either; the only place this appears is page 1-41.) p. 3-41 mentions function UPDATE-DISCRIMINATING-FUNCTION in the "purpose" section and UPDATE-DISCRIMINATOR-CODE in the "remarks" section; neither of these is included in the function specifications. The graph shows UPDATE-DISCRIMINATING-FUNCTION. Page 3-67 says that "UPDATE-DISMCRINATING-FUNCTION" [sic] is called by the SHARED-INITIALIZE method, but that call isn't shown on the graph. p. 3-43 COMPUTE-EFFECTIVE-METHOD - doesn't specify the value returned; presumably a method object. Is it a STANDARD-METHOD or should there be a subclass for effective methods? p. 3-45, 2nd line from bottom, "options is follows" -> "options follows" p 3-46, the top six lines are a duplicate of material on the previous page. p 3-47, COMPUTE-SLOTS -- it isn't clear where the result of this is. Does it return a list of effective slots, or does it store the list in the class object? p. 3-60 mentions function SLOT-ACCESSES-TO-DEOPTIMIZE which isn't defined elsewhere. p. 3-62 "No method applicable to class objects is specified for the INITIALIZE-INSTANCE generic function." -- Don't you mean no method more specific than the one for STANDARD-OBJECT specified on page 2-57? Surely that method is applicable. Likewise on pages 3-65, 3-68, and 3-71. p. 3-63, fourth bullet, reference to "REMOVE-DIRECT-SUPERCLASS" should be "REMOVE-DIRECT-SUBCLASS". p. 3-69 -- the boxed table has the wrong set of function names [should be METHOD-QUALIFIERS, etc.] and does not list all of the relevant arguments. p. 3-70 -- the reference to MAP-DEPENDENTS here appears to be bogus since page 3-22 says that "method combination objects cannot be redefined" and "the REINITIALIZE-INSTANCE generic function signals an error ...". p. 3-72 mentions function SLOT-DEFINITION-DOCUMENTATION, which is not listed among the slot readers on page 3-90; shouldn't that just be DOCUMENTATION ? p. 3-75, MAKE-METHOD-LAMBDA, says "The generic function and method the method function will be used with are not required to be the specified ones." In fact, the method can not be the actual one since it can't be created until after MAKE-METHOD-LAMBDA has been used to construct a value for the :FUNCTION initarg [p. 3-68]. It would be clearer to say that the second argument of MAKE-METHOD-LAMBDA is a prototype that is only used for dispatching to the right method. p. 3-86 mentions a method for (SETF GENERIC-FUNCTION-NAME), but that isn't listed with the generic functions on page 3-85. Is it correct to assume that this is the only one of these accessors which is SETF-able? p. 3-88 - Does METHOD-GENERIC-FUNCTION return NIL if no ADD-METHOD has been done? p. 3-89 -- A number of details yet to be filled in here, like what does METHOD-COMBINATION-OPTIONS return -- a P-list, or an A-list, or what? p. 3-90 says that generic function SLOT-DEFINITION-NAME can return "any object", but page 3-72 says that initialization of a slot signals an error if the name "is not a symbol which can be used as a variable name." So how can the name get to be anything other than a symbol? p. 3-91 SLOT-DEFINITION-INITARGS -- I assume this returns a list of symbols? p. 3-91, 1st line under "Methods", "functions has a" -> "functions have a" p. 3-91 under the heading "Direct Slot Definition Objects", there are methods specified for class SLOT-DEFINITION; that should be DIRECT-SLOT-DEFINITION to be consistent with page 3-73. Or should it be STANDARD-DIRECT-SLOT-DEFINITION ? The graph shows that REMOVE-DIRECT-METHOD is called by REMOVE-METHOD, but neither page 3-94 or page 3-97 says that. p. 99 needs some more words. p. 3-102 DIRECT-SLOT-DEFINITION-CLASS -- what is this doing in this place in the document? It should either be placed in alphabetical order between pages 47 and 48, or included with the class accessors starting on page 79. p. 3-102 -- I assume that DIRECT-SLOT-DEFINITION-CLASS is supposed to have a specified method for class STANDARD-CLASS that returns class STANDARD-DIRECT-SLOT-DEFINITION ? p. 3-109 is unfinished. The spec doesn't say who calls FINALIZE-INHERITANCE, although the graph shows it called by ALLOCATE-INSTANCE. (I'm talking here about finalizing the class being allocated, not the special cases described in class initialization.) Presumably ALLOCATE-INSTANCE also calls CLASS-FINALIZED-P, although that is not shown on the graph. The organization of this document in a semi-alphabetical order is rather awkward. I think it would be better to have the material grouped by subject and add an index. From Owners-commonloops.pa@Xerox.COM Wed Feb 1 11:32:47 1989 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA09735; Wed, 1 Feb 89 11:32:47 PST Received: from Riesling.ms by ArpaGateway.ms ; 01 FEB 89 11:29:52 PST Return-Path: Redistributed: commonloops.pa Received: from shrike.Austin.Lockheed.COM ([192.31.24.65]) by Xerox.COM ; 01 FEB 89 11:27:07 PST Received: by shrike.Austin.Lockheed.COM (4.0/1.41); Wed, 1 Feb 89 13:25:34 CST Received: by opal.STC.LOCKHEED.COM (3.2/1.27); Wed, 1 Feb 89 13:19:17 CST Received: by topaz.STC.LOCKHEED.COM (3.2/1.1); Wed, 1 Feb 89 13:19:16 CST Date: Wed, 1 Feb 89 13:19:16 CST From: Jacky Combs Message-Id: <8902011919.AA28772@topaz.STC.LOCKHEED.COM> To: commonloops.pa@Xerox.COM Subject: PCL on VAX VMS Has anyone compiled the latest version of PCL (12/88) on a VAX under VMS? We are having all kinds of problems and need help fast!! Thanks -- Jacky combs@stc.lockheed.com or call (512) 448-5783 From Common-Lisp-Object-System-mailer@SAIL.STANFORD.EDU Wed Feb 1 11:48:26 1989 Received: from Sail.Stanford.EDU by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA10221; Wed, 1 Feb 89 11:48:26 PST Received: from ti.com by SAIL.Stanford.EDU with TCP; 1 Feb 89 11:49:15 PST Received: by ti.com id AA05669; Wed, 1 Feb 89 13:48:24 CST Received: from Kelvin by tilde id AA25360; Wed, 1 Feb 89 13:36:09 CST Message-Id: <2811353741-895226@Kelvin> Sender: GRAY@Kelvin.csc.ti.com Date: Wed, 1 Feb 89 13:35:41 CST From: David N Gray To: Common-Lisp-Object-System@SAIL.STANFORD.EDU Subject: classes and environments Page 3-48 of document 89-003, regarding ENSURE-CLASS, says "If the class name _name_ names a class in the environment :ENVIRONMENT use that class." Need to clarify that this doesn't just mean calling (FIND-CLASS NAME NIL ENVIRONMENT) because for a remote environment you don't want to use any definition inherited from the resident environment. Maybe something like: (defun ensure-class (name &rest args &key environment &allow-other-keys) (let ((class (find-class name nil environment))) (apply #'ensure-class-using-class (and (not (null class)) (not (and (environment-remote-p environment) (eq class (find-class name nil nil)))) class) name args))) However, this shadowing of class definitions raises a host of questions that don't seem to be addressed in this document. For example, suppose the resident environment contains the following: (defclass plant () ...) (defclass tree (plant) ...) (defclass oak (tree) ...) and then I compile a file that contains new definitions for PLANT and OAK, with the same class inheritance but different slot options; does the remote definition of OAK inherit from both the resident definition of TREE and the remote definition of PLANT? How do you keep track of the fact that TREE has two different definitions of its superclass? Our current implementation handles that by having each class know the _names_ of its direct supers and the environment in which it is defined, but 3-50 says that the environment is not to be passed to MAKE-INSTANCE. Similar questions arise about shadowing of generic function definitions. When COMPILE-FILE processes a DEFMETHOD for a generic function which is defined in the resident environment, but not yet shadowed in the remote environment, does it use the attributes of the resident definition, or does it create a shadowing definition in the remote environment? I think you probably want to use the resident definition, but that would mean that the :ENVIRONMENT argument of ENSURE-GENERIC-FUNCTION isn't used quite the same way as it is in ENSURE-CLASS. From Common-Lisp-Object-System-mailer@SAIL.STANFORD.EDU Wed Feb 1 12:03:25 1989 Received: from Sail.Stanford.EDU by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA10509; Wed, 1 Feb 89 12:03:25 PST Received: from ti.com by SAIL.Stanford.EDU with TCP; 1 Feb 89 12:04:02 PST Received: by ti.com id AA05760; Wed, 1 Feb 89 14:03:15 CST Received: from Kelvin by tilde id AA25807; Wed, 1 Feb 89 13:53:43 CST Message-Id: <2811354795-958597@Kelvin> Sender: GRAY@Kelvin.csc.ti.com Date: Wed, 1 Feb 89 13:53:15 CST From: David N Gray To: Common-Lisp-Object-System@SAIL.STANFORD.EDU Subject: chapter 3 comments Here are some more assorted questions, comments, and suggestions regarding the Meta Object Protocol, with reference to draft 10 [document 89-003 dated 12/15/88]. Page 3-9 says the "metaclass of every class shown is STANDARD-CLASS ..." -- shouldn't STRUCTURE-OBJECT be of metaclass BUILT-IN-CLASS or STRUCTURE-CLASS ? p. 3-16 - why is the doc string a separate argument to making a method instead of being included in the function lambda expression? p 3-19,20 in canonicalized initial-method, can't the :QUALIFIERS entry be omitted when the value is NIL? Function STANDARD-INSTANCE-ACCESS appears to have been redefined incompatibly from the March 1988 draft. Isn't some primitive function still needed for access by name? Regarding ADD-DIRECT-METHOD and SPECIALIZER-DIRECT-METHODS; do we really have to do that when the specializer is class T? That seems like it would be just a waste of space. I wonder about the methods on ADD-DIRECT-METHOD, REMOVE-DIRECT-METHOD, SPECIALIZER-DIRECT-METHODS, and SPECIALIZER-DIRECT-GENERIC-FUNCTIONS for class T; since they apparently exist only to support use of (EQL object) specializers, wouldn't it be better for those methods to specialize on class CONS ? P. 3-36 - APPLY-METHOD-FUNCTION "is called whenever a method function must be applied to arguments." -- it surely must be permissible for an implementation to bypass this for the sake of efficiency. [Otherwise, how would you invoke the methods for APPLY-METHOD-FUNCTION ?] The reason isn't apparent for wanting to separate UPDATE-DISCRIMINATING-FUNCTION from COMPUTE-DISCRIMINATING-FUNCTION; it seems like the question of whether the function needs to be recomputed would be inseparably connected to the nature of the code generated. How come MAKE-METHOD-LAMBDA returns a lambda expression but COMPUTE-DISCRIMINATING-FUNCTION returns a function? Is the assumption that the code for a generic function will always be computed at run time rather than compile time? This isn't true since GENERIC-FLET and GENERIC-LABELS can often be optimized to fully build the generic function at compile time when it can be seen that the methods are not changing at run time. It seems like COMPUTE-DISCRIMINATING-FUNCTION should instead return a lambda expression and be called something like COMPUTE-DISCRIMINATING-LAMBDA. p. 3.43 - How is COMPUTE-EFFECTIVE-METHOD going to know what value to store for METHOD-SPECIALIZERS ? Looks like that needs to be an additional argument. p. 3-58 EXTRACT-LAMBDA-LIST and p. 3-59 EXTRACT-SPECIALIZER-NAMES - "If the specialized-lambda-list argument does not have legal syntax, an error is signalled." -- it isn't clear what amount of error checking is required here. Is it just expected to report an error if it happens to come across one while stripping out the specializers, or is it supposed to scan all of the optional arguments for valid syntax according to page 60 of CLtL? p. 3-61 FIND-METHOD-COMBINATION - I don't understand this. DEFINE-METHOD-COMBINATION returns a method combination object which was created without reference to any particular generic function or argument values. Does FIND-METHOD-COMBINATION return something different from that, or why does it depend on the generic function? Pages 3-62 and 3-65 specify :AFTER methods on REINITIALIZE-INSTANCE for classes CLASS and GENERIC-FUNCTION that don't do anything but call MAP-DEPENDENTS. Couldn't both cases be handled by a single method on class DEPENDEE-MIXIN ? p. 3-62 SHARED-INITIALIZE method - "If class has not previously been initialized ..." -- How does it determine that? The March draft had a CLASS-INITIALIZED-P function which doesn't seem to be here anymore. Shouldn't any behavior that depends on whether the object is previously initialized be handled by separate methods for INITIALIZE-INSTANCE and REINITIALIZE-INSTANCE ? Also, it seems a little odd to specify using an :AFTER method on SHARED-INITIALIZE when the primary method won't have anything to do. Likewise for GENERIC-FUNCTIONs on page 3-65. p. 3-66, 3rd bullet: "The :DECLARATIONS argument is a list of declarations. An error is signalled otherwise." -- The SHARED-INITIALIZE method could make sure this is a list, but wouldn't it be better to let COMPUTE-DISCRIMINATING-FUNCTION decide whether the declarations are meaningful? A portable SHARED-INITIALIZE method doesn't have any way to know what declarations the implementation will permit. p. 3-68 -- since REINITIALIZE-INSTANCE is not permitted for methods, wouldn't it be simpler to initialize them with an INITIALIZE-INSTANCE method instead of using SHARED-INITIALIZE? Likewise for slots on page 3-71. p. 3-75, the arguments shown for generic function MAKE-METHOD-LAMBDA and its primary method are not consistent. One shows and the other shows and . Which is right? p. 3-80, shouldn't the blank space at the bottom of the page contain something to the effect that the next three functions [CLASS-PRECEDENCE-LIST, CLASS-PROTOTYPE, and CLASS-SLOTS] signal an error if the class is not finalized? Shouldn't that also apply to CLASS-DEFAULT-INITARGS [currently on page 3-79]? P. 3-83 specifies a CLASS-PROTOTYPE method for BUILT-IN-CLASS -- is that really useful? Is it even meaningful? Sure, a meaningful prototype could be returned for a representation class such as FIXNUM or SYMBOL, but what would be a meaningful prototype for an abstract class such as NUMBER, SEQUENCE, STREAM, or FUNCTION ? What should (CLASS-PROTOTYPE (FIND-CLASS 'T)) return? p. 3-83 says that CLASS-PROTOTYPE returns a value which is maintained by FINALIZE-INHERITANCE. The March draft said that the prototype instance did not have to be allocated until the first time CLASS-PROTOTYPE is called, which seems like the way it should be. It is not uncommon to define a class which will only have one large instance and for which the prototype will never be needed. Or maybe page 83 just means that FINALIZE-INHERITANCE ensures that CLASS-PROTOTYPE won't return an obsolete value? Regarding SLOT-DEFINITION-INITFORM, since it appears that it would only be used for debugging or informational purposes, I wonder if it shouldn't have the same implementation freedom as in proposal FUNCTION-DEFINITION to not always have to save the source form. p. 3-117 VALIDATE-SUPERCLASS, reference to whether "the superclass has no slots" -- does this mean forcing the superclass to be finalized, or is a traversal of its supers intended? It seems a little odd that the March draft had a function named VALID-SUPERCLASS-P which signalled an error, while this draft has a predicate named VALIDATE-SUPERCLASS; seems like those names are interchanged. p. 3-35, 3-107 methods for BUILT-IN-CLASS -- "this method signals an error" - is it permissible for that method to simply not be defined, resulting in a "no applicable method" error, or does that method actually have to be defined in a conforming implementation? Perhaps the real point is that users should not be permitted to define those methods? Is the concept of initial methods useful for local generic functions? The only use of GENERIC-FUNCTION-INITIAL-METHODS appears to be for redefinition of named generic functions, which is not applicable to the anonymous generic functions created by the forms GENERIC-FUNCTION, GENERIC-FLET, and GENERIC-LABELS. From Owners-commonloops.pa@Xerox.COM Wed Feb 1 13:56:49 1989 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA12253; Wed, 1 Feb 89 13:56:49 PST Received: from Salvador.ms by ArpaGateway.ms ; 01 FEB 89 13:42:49 PST Return-Path: Redistributed: commonloops.pa Received: from vaxa.isi.edu ([128.9.0.33]) by Xerox.COM ; 01 FEB 89 13:41:02 PST Posted-Date: Wed, 01 Feb 89 13:41:35 PST Message-Id: <8902012141.AA02797@vaxa.isi.edu> Received: from LOCALHOST by vaxa.isi.edu (5.59/5.51) id AA02797; Wed, 1 Feb 89 13:41:38 PST To: commonloops.pa@Xerox.COM From: goldman@vaxa.isi.edu Subject: bug in WITH-SLOTS macro Date: Wed, 01 Feb 89 13:41:35 PST Sender: goldman@vaxa.isi.edu Consider the following (macroexpand-1 '(PCL:WITH-SLOTS (FROM) SELF (multiple-value-setq (a b) (foo from)))) (LET ((#:G16320 SELF)) (DECLARE (PCL:VARIABLE-REBINDING #:G16320 SELF)) #:G16320 (MULTIPLE-VALUE-BIND (#:G16321 #:G16322) (FOO (SLOT-VALUE #:G16320 'FROM)) (SETQ A #:G16321) (SETQ B #:G16322))) According to CLtL, MULTIPLE-VALUE-SETQ returns the FIRST value returned by its body -- that is, the value that A gets set to. This expansion produces a form that returns (in this case) the SECOND value -- the value that B is set to. I am running symbolics genera 7.2 (no cute name) PCL. It looks like the problem is in EXPAND-WITH-SLOTS-INTERNAL in BOOT.LISP, and is probably not symbolics-specific. Neil From CL-Cleanup-mailer@SAIL.STANFORD.EDU Thu Feb 2 12:52:42 1989 Received: from Sail.Stanford.EDU by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA27139; Thu, 2 Feb 89 12:52:42 PST Received: from Sun.COM by SAIL.Stanford.EDU with TCP; 2 Feb 89 12:39:51 PST Received: from snail.Sun.COM by Sun.COM (4.1/SMI-4.0) id AA12354; Thu, 2 Feb 89 12:39:31 PST Received: from lukasiewicz.sun.com by snail.Sun.COM (4.1/SMI-4.0) id AA28202; Thu, 2 Feb 89 12:36:18 PST Received: by lukasiewicz.sun.com (4.0/SMI-4.0) id AA00560; Thu, 2 Feb 89 12:39:12 PST Date: Thu, 2 Feb 89 12:39:12 PST From: jrose@Sun.COM (John Rose) Message-Id: <8902022039.AA00560@lukasiewicz.sun.com> To: Moon@STONY-BROOK.SCRC.Symbolics.COM Cc: CL-Cleanup@SAIL.STANFORD.EDU, CL-Compiler@SAIL.STANFORD.EDU, Common-Lisp-Object-System@SAIL.STANFORD.EDU In-Reply-To: David A. Moon's message of Fri, 27 Jan 89 22:48 EST <19890128034814.6.MOON@EUPHRATES.SCRC.Symbolics.COM> Subject: Issue: FUNCTION-NAME (Version 1) I favor the FUNCTION-NAME:LARGE proposal, because it defines a single, useful notion of what a function name is. The other proposals have the flaw that there are two kinds of function names: symbols, and extended names, with only some of the Lisp primitives accepting the latter. This may be convenient for some implementations, for the short term, but it fragments the language. I have two other comments on the proposal. A. Reducing the Cost to Implementors One observation you could put in the Cost To Implementors section is that none of the SMALL, MEDIUM, or LARGE proposals require changes to the "guts" of the interpreter and compiler. This is because an implementation is free to use plain symbols internally to name functions, and use a hack like JonL's SETF:|3.FOO.BAR| mapping to convert non-symbol names to symbols. This conversion would be done as a part of parsing the handful of forms which accept function names, and then all other passes of the interpreter and compiler (the "guts") would just see symbols. (By "parsing" I mean ensuring the right number and type of syntactic subforms. You can see that this is a very early and simple stage of processing.) Or, Lisp compilers with an "alphatization" phase could perform function name symbolization at that phase. B. Finishing the Job of Regularization I'd like to suggest two additions to your smorgasbord of options in the FUNCTION-NAME:LARGE section of the proposal. One addition would regularize a major special case of functions--lambda expressions. The other addition would reaffirm an unstated regularity in the language, that function names can stand in for functions under FUNCALL and APPLY. Not only can the treatment of symbolic and setf-list function names be regularized, but lambda too can be treated in a consistent manner. If these two points are added to your proposal, the language as a whole would have a completely uniform treatment of functions and function names. Here they are: 13. Declare that any function name is a suitable argument to FUNCALL and APPLY. In such a case, the function name is passed to FDEFINITION, and the result (which may in turn be a function name) is called. That is, the following two expressions are equivalent, when fname is a function name: (FUNCALL fname x y) <==> (FUNCALL (FDEFINITION fname) x y) Note that the definition is sought in the global environment. Compare with the rule which applies to a function name occurs, syntactically, as the car of a list in code: (fname x y) <==> (FUNCALL (FUNCTION fname) x y) <==> (under proposal item 9) (FUNCALL (FDEFINITION fname ) x y) 12. Declare that any lamba expression (i.e., a list whose car is LAMBDA and whose cdr is a well-formed lambda argument list and body) is a function name. The effects of the function name accessors on lambda expressions are as follows. FDEFINITION returns an implementation-defined value which is the function specified the lambda expression, closed in the global environment. This FDEFINITION value cannot be changed by SETF. FBOUNDP always returns T, and MAKUNBOUND is an error. Esthetics: The effect of items 11 and 12 is to complete the regularization of Common Lisp's treatment of functions and function names. The total effect of proposal items 1 through 12 is that Lisp has just two notions for referencing function objects: FUNCTIONS, which are Lisp objects that directly represent executable code, and FUNCTION NAMES, which can denote functions. Symbols, SETF function names, and lambda expressions are all examples of the latter notion. The former notion is highly implementation dependent. Function names can occur as syntactic entities in code. FUNCALL and APPLY work uniformly on both functions and function names, with a consistent semantics. Lambda expressions are often thought to denote "anonymous" functions, so it may seem paradoxical to treat them as names. The paradox is only apparent, since the expression itself has the properties of a Lisp function name: It is (typically) a cons tree which can be read, printed, and stored in source files, and it denotes a well-defined Lisp function. Benefit to Users: Function names are useful for representing objects in remote environments, because they need not be bound at all times to the same function, or to any function, and because they are typically stable in meaning across reads and prints, where plain functions are not. Programs which deal simultaneously with remote and local environments, such as CLOS, can probably be simplified, since function names can be used uniformly, rather than an ad-hoc mixture of functions and function names. The language as a whole become more uniform from these additions and clarifications, making it easier to learn and use. (See Esthetics.) Cost to Implementors: Interpreters which currently have a special case check for application of lambda expressions would need to modify this check to call FDEFINITION when a list of any sort is encountered. Note that all Common Lisps already must perform some such check, since lambda expressions can be funcalled (and this is currently a very special case, the only standard case of a list being funcalled). This means that every Lisp already has a place to insert the required call to FDEFINITION. In some implementations, FDEFINITION of a lambda expression could be that lambda-expression itself. In others featuring a pre-eval codewalk, the walk would be done by FDEFINITION, which would return an appropriate closure. Cost of Non-adoption: Rather than two notions for function references (functions and function names), there would be several notions, each corresponding to the valid inputs for particular group of primitives. APPLY and FUNCALL would accept functions, symbolic names, and lambda expressions, but not setf function names. FDEFINITION and its kind would accept symbols and setf function names but not lambda expressions. If the :LARGE proposal is not adopted, this fragmentation would also apply to the various syntaxes involving function names; some names would be acceptable to DEFUN but not to FLET, etc. -- John From Owners-COMMONLOOPS.PA@Xerox.COM Thu Feb 2 14:57:44 1989 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA28750; Thu, 2 Feb 89 14:57:44 PST Received: from Cabernet.ms by ArpaGateway.ms ; 02 FEB 89 14:46:59 PST Return-Path: <@CUNYVM.CUNY.EDU:AKMAL@ARIZEVAX.BITNET> Redistributed: COMMONLOOPS.PA Received: from CUNYVM.CUNY.EDU ([128.228.1.2]) by Xerox.COM ; 02 FEB 89 14:44:44 PST Received: from ARIZEVAX.BITNET by CUNYVM.CUNY.EDU (IBM VM SMTP R1.1) with BSMTP id 3133; Thu, 02 Feb 89 17:42:35 EST Date: Thu, 2 Feb 89 15:39 MST From: Subject: CLOS ON TI To: COMMONLOOPS.PA@Xerox.COM X-Original-To: COMMONLOOPS@XEROX.COM, AKMAL Message-Id: <890202-144659-14183@Xerox> Hi , I am having some problems when trying to run CLOS on TI-CommonLisp.The p roblem seems to be in COnstruct.lisp. It mentions Constructor. May be the probel m has something to do with constructor. I will really appreciate if you can send some information about it, and help me out here. I 'll love to run CLOS on TI-commonLisp.Also If you can include me in your mailing list that will be great. So that I could information about all the updates. Thanks From Owners-COMMONLOOPS.PA@Xerox.COM Thu Feb 2 21:32:32 1989 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA03726; Thu, 2 Feb 89 21:32:32 PST Received: from Cabernet.ms by ArpaGateway.ms ; 02 FEB 89 21:33:04 PST Return-Path: Redistributed: COMMONLOOPS.PA Received: from VAX.BBN.COM ([128.89.0.91]) by Xerox.COM ; 02 FEB 89 21:31:34 PST From: Dan Cerys Sender: cerys@BBN.COM To: AKMAL@arizevax.bitnet Cc: COMMONLOOPS.PA@Xerox.COM In-Reply-To: AKMAL%arizevax.bitnet@wilma.bbn.com's message of Thu, 2 Feb 89 15:39 MST <890202-144659-14183@Xerox> Subject: CLOS ON TI Date: Fri, 3 Feb 89 0:16:08 EST Message-Id: <890202-213304-14958@Xerox> I've had no problem compiling or using the 12/7/88 version of PCL on Explorer Release 4.1 (other than speed). There were problems with some earlier versions, so be sure to get the latest version. Dan From Owners-commonloops.pa@Xerox.COM Fri Feb 3 06:48:39 1989 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA08019; Fri, 3 Feb 89 06:48:39 PST Received: from Semillon.ms by ArpaGateway.ms ; 03 FEB 89 06:48:07 PST Return-Path: Redistributed: commonloops.pa Received: from shrike.Austin.Lockheed.COM ([192.31.24.65]) by Xerox.COM ; 03 FEB 89 06:45:55 PST Received: by shrike.Austin.Lockheed.COM (4.0/1.41); Fri, 3 Feb 89 08:45:02 CST Received: by opal.STC.LOCKHEED.COM (3.2/1.27); Fri, 3 Feb 89 07:14:36 CST Received: by topaz.STC.LOCKHEED.COM (3.2/1.1); Fri, 3 Feb 89 07:14:35 CST Date: Fri, 3 Feb 89 07:14:35 CST From: Jacky Combs Message-Id: <8902031314.AA05800@topaz.STC.LOCKHEED.COM> To: commonloops.pa@Xerox.COM Subject: PCL on VAX/VMS I have some more details about the problem we are having with the new version of PCL on a VAX/VMS. We get error messages when the function EXPAND-DCODE-CACHE is compiling, and then it breaks early on when it tries to execute that function in the test.lisp. Anybody have any suggestions? Jacky combs@stc.lockheed.com From Common-Lisp-Object-System-mailer@SAIL.STANFORD.EDU Mon Feb 6 13:06:23 1989 Received: from Sail.Stanford.EDU by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA27670; Mon, 6 Feb 89 13:06:23 PST Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 6 Feb 89 13:07:28 PST Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs) id AA20453; Mon, 6 Feb 89 14:05:56 -0700 Received: by defun.utah.edu (5.61/utah-2.0-leaf) id AA00450; Mon, 6 Feb 89 14:05:54 -0700 From: sandra%defun@cs.utah.edu (Sandra J Loosemore) Message-Id: <8902062105.AA00450@defun.utah.edu> Date: Mon, 6 Feb 89 14:05:52 MST Subject: issue SYMBOL-MACROLET-SEMANTICS To: cl-cleanup@SAIL.STANFORD.EDU, common-lisp-object-system@SAIL.STANFORD.EDU This proposal, which passed at the January meeting, contains the phrase: "Specify that the expansion of a symbol macro IS subject to further macro expansion in the same lexical environment as the symbol macro invocation." Just to clarify this, does this mean that the second example from p 2-81 of 88-002R is now incorrect? -Sandra ------- From CL-Cleanup-mailer@SAIL.STANFORD.EDU Mon Feb 6 13:21:39 1989 Received: from Sail.Stanford.EDU by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA27750; Mon, 6 Feb 89 13:21:39 PST Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 6 Feb 89 13:16:12 PST Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 534374; Mon 6-Feb-89 16:13:53 EST Date: Mon, 6 Feb 89 16:14 EST From: David A. Moon Subject: issue SYMBOL-MACROLET-SEMANTICS To: Sandra J Loosemore Cc: cl-cleanup@SAIL.STANFORD.EDU, common-lisp-object-system@SAIL.STANFORD.EDU In-Reply-To: <8902062105.AA00450@defun.utah.edu> Message-Id: <19890206211426.9.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Mon, 6 Feb 89 14:05:52 MST From: sandra%defun@cs.utah.edu (Sandra J Loosemore) This proposal, which passed at the January meeting, contains the phrase: "Specify that the expansion of a symbol macro IS subject to further macro expansion in the same lexical environment as the symbol macro invocation." Just to clarify this, does this mean that the second example from p 2-81 of 88-002R is now incorrect? Yes. From CL-Windows-mailer@SAIL.STANFORD.EDU Tue Feb 7 09:43:12 1989 Received: from Sail.Stanford.EDU by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA08348; Tue, 7 Feb 89 09:43:12 PST Received: from ti.com by SAIL.Stanford.EDU with TCP; 7 Feb 89 08:19:17 PST Received: by ti.com id AA26003; Tue, 7 Feb 89 10:18:11 CST Received: from Kelvin by tilde id AA12256; Tue, 7 Feb 89 10:04:42 CST Message-Id: <2811859381-15005799@Kelvin> Sender: GRAY@Kelvin.csc.ti.com Date: Tue, 7 Feb 89 10:03:01 CST From: David N Gray To: CL-Cleanup@SAIL.STANFORD.EDU Cc: Common-Lisp-Object-System@SAIL.STANFORD.EDU, CL-Windows@SAIL.STANFORD.EDU, Kimbrough@DSG.csc.ti.com, Bartley@MIPS.csc.ti.com Subject: I/O generic functions It would be nice if the Common Lisp input and output functions could be defined in terms of primitives which are generic functions so that users would have a portable way to create their own streams by defining classes and methods and have those streams be acceptable to the standard I/O functions. This would be especially valuable for supporting the development of window systems for Common Lisp. It may be too late to include this in the standard, but it would be useful to at least establish some common practice guidelines to avoid unnecessary incompatibilities between implementations that will want to do something like this anyway. In order to get some discussion started, following is a preliminary outline showing what might be done. Shown below are a few primitive generic functions which would need to have methods defined for each stream class, and a few more which the user could either define himself, or use a default method provided by an included class. [This does not yet include non-character streams.] Finally, it shows how the I/O functions of CLtL could be implemented using these generic functions. Note that the Common Lisp I/O functions themselves cannot be made into generic functions because in nearly every case the stream argument is optional and thus can't be specialized. Note also that the existing generic function PRINT-OBJECT is a higher-level operation since even when the first argument is just a character or string, it still needs to format the output in accordance with *PRINT-ESCAPE*. ;;;; Implementation of Common Lisp I/O routines using generic functions ;;; Generic functions for primitive input operations that must be defined for each stream. (defgeneric STREAM-READ-CHAR (stream &optional eof-error-p eof-value)) (defgeneric STREAM-UNREAD-CHAR (stream character)) (defgeneric STREAM-LISTEN (stream)) ;;; Other input operations which can be defaulted by including the following class. (defclass DEFAULT-INPUT-STREAM (stream) ()) (defgeneric STREAM-READ-CHAR-NO-HANG (stream &optional eof-error-p eof-value) (:method ((stream default-input-stream) &optional eof-error-p eof-value) (stream-read-char stream eof-error-p eof-value))) (defgeneric STREAM-PEEK-CHAR (stream &optional eof-error-p eof-value) (:method ((stream default-input-stream) &optional (eof-error-p t) eof-value) (let ((character (stream-read-char stream eof-error-p eof-value))) (unless (eql character eof-value) (stream-unread-char stream character)) character))) (defgeneric STREAM-READ-LINE (stream &optional eof-error-p eof-value) (:method ((stream default-input-stream) &optional eof-error-p eof-value) (let ((line (make-array 60 :element-type 'string-char :fill-pointer 0))) (loop (let ((character (stream-read-char stream eof-error-p eof-value))) (if (eql character eof-value) (return (values line eof-value)) (if (eql character #\newline) (return (values line nil)) (vector-push-extend character line)))))))) (defgeneric STREAM-CLEAR-INPUT (stream) (:method ((stream default-input-stream)) nil)) (defgeneric STREAM-CLOSE (stream)) (defmethod STREAM-CLOSE ((stream default-input-stream)) nil) ; or is it T? ;;; Generic functions for primitive output operations that must be defined for each stream. (defgeneric STREAM-WRITE-CHAR (stream character)) (defgeneric STREAM-START-LINE-P (stream)) ; returns true if positioned at beginning of line. (defgeneric STREAM-LINE-COLUMN (stream)) ; returns current column number if meaningful, else nil ;;; Other output operations which can be defaulted by including the following class. (defclass DEFAULT-OUTPUT-STREAM (stream) ()) (defgeneric STREAM-WRITE-STRING (stream string &optional start end) (:method ((stream default-output-stream) string &optional (start 0) end) (let ((limit (or end (length string)))) (do ((i start (1+ i))) ((< i limit)) (stream-write-char stream (char string i)))) string)) (defgeneric STREAM-TERPRI (stream) (:method ((stream default-output-stream)) (stream-write-char stream #\newline) nil)) (defgeneric STREAM-FRESH-LINE (stream) (:method ((stream default-output-stream)) (if (stream-start-line-p stream) nil (progn (stream-terpri stream) t)))) (defgeneric STREAM-FINISH-OUTPUT (stream) (:method ((stream default-output-stream)) nil)) (defgeneric STREAM-FORCE-OUTPUT (stream) (:method ((stream default-output-stream)) nil)) (defgeneric STREAM-CLEAR-OUTPUT (stream) (:method ((stream default-output-stream)) nil)) ;; useful for pprint and format ~T (defgeneric STREAM-ADVANCE-TO-COLUMN (stream column) (:method ((stream default-output-stream) column) (let ((current (stream-line-column stream))) (unless (null current) (dotimes (i (- current column)) (stream-write-char stream #\space)) t)))) (defmethod STREAM-CLOSE ((stream default-output-stream)) nil) ;;; Internal helper functions [not intended to be standardized] (proclaim '(inline decode-read-arg)) (defun decode-read-arg (arg) (cond ((null arg) *standard-input*) ((eq arg t) *terminal-io*) (t arg))) (proclaim '(inline decode-print-arg)) (defun decode-print-arg (arg) (cond ((null arg) *standard-output*) ((eq arg t) *terminal-io*) (t arg))) ;;; Common Lisp query functions (defgeneric INPUT-STREAM-P (stream) (:method ((stream default-input-stream)) t) (:method ((stream default-output-stream)) nil)) (defgeneric OUTPUT-STREAM-P (stream) (:method ((stream default-output-stream)) t) (:method ((stream default-input-stream)) nil)) (defgeneric STREAM-ELEMENT-TYPE (stream) (:method ((stream default-output-stream)) 'character) (:method ((stream default-input-stream)) 'character)) ;;; Common Lisp input functions (defun READ-CHAR (&optional input-stream (eof-errorp t) eof-value recursive-p) (declare (ignore recursive-p)) ; This appears to have been a mistake in CLtL. (stream-read-char (decode-read-arg input-stream) eof-errorp eof-value)) (defun PEEK-CHAR (&optional peek-type input-stream (eof-errorp t) eof-value recursive-p) (declare (ignore recursive-p)) (let ((stream (decode-read-arg input-stream))) (if (null peek-type) (stream-peek-char stream eof-errorp eof-value) ...))) (defun UNREAD-CHAR (character &optional input-stream) (stream-unread-char (decode-read-arg input-stream) character)) (defun LISTEN (&optional input-stream) (stream-listen (decode-read-arg input-stream))) (defun READ-LINE (&optional input-stream (eof-error-p t) eof-value recursive-p) (declare (ignore recursive-p)) (stream-read-line (decode-read-arg input-stream) eof-error-p eof-value)) (defun CLEAR-INPUT (&optional input-stream) (stream-clear-input (decode-read-arg input-stream))) (defun READ-CHAR-NO-HANG (&optional input-stream (eof-errorp t) eof-value recursive-p) (declare (ignore recursive-p)) (stream-read-char-no-hang (decode-read-arg input-stream) eof-errorp eof-value)) ;;; Common Lisp output functions (defun WRITE-CHAR (character &optional output-stream) (stream-write-char (decode-print-arg output-stream) character)) (defun FRESH-LINE (&optional output-stream) (stream-fresh-line (decode-print-arg output-stream))) (defun WRITE-STRING (string &optional output-stream &key (start 0) end) (stream-write-string (decode-print-arg output-stream) string start end)) (defun WRITE-LINE (string &optional output-stream &key (start 0) end) (let ((stream (decode-print-arg output-stream))) (stream-write-string stream string start end) (stream-terpri stream) string)) (defun FORCE-OUTPUT (&optional stream) (stream-force-output (decode-print-arg stream))) (defun FINISH-OUTPUT (&optional stream) (stream-finish-output (decode-print-arg stream))) (defun CLEAR-OUTPUT (&optional stream) (stream-clear-output (decode-print-arg stream))) From Common-Lisp-Object-System-mailer@SAIL.STANFORD.EDU Tue Feb 7 10:14:55 1989 Received: from Sail.Stanford.EDU by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA08758; Tue, 7 Feb 89 10:14:55 PST Received: from hplms2.hpl.hp.com by SAIL.Stanford.EDU with TCP; 7 Feb 89 10:15:49 PST Received: from hplwhh.HPL.HP.COM (hplwhh.hpl.hp.com) by hplms2.hp.com; Tue, 7 Feb 89 10:14:20 pst Received: from loopback by hplwhh.HPL.HP.COM; Tue, 7 Feb 89 10:13:10 pst To: David N Gray Cc: Common-Lisp-Object-System@SAIL.STANFORD.EDU, CL-Windows@SAIL.STANFORD.EDU, Kimbrough@DSG.csc.ti.com, Bartley@MIPS.csc.ti.com, CL-Cleanup@SAIL.STANFORD.EDU Subject: Re: I/O generic functions In-Reply-To: Your message of "Tue, 07 Feb 89 10:03:01 CST." <2811859381-15005799@Kelvin> Date: Tue, 07 Feb 89 10:13:06 PST Message-Id: <26670.602878386@hplwhh> From: Warren Harris I just wanted to point out that there is an entire section of Sonya Keene's book "Object Oriented Programming in Common Lisp" dedicated to an implementation of streams as objects. Perhaps this implementation would be a good starting point for a formal proposal on generic i/o routines. Can anyone summarize what might be missing in a "real" implementation? Warren From Common-Lisp-Object-System-mailer@SAIL.STANFORD.EDU Tue Feb 7 10:32:10 1989 Received: from Sail.Stanford.EDU by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA09085; Tue, 7 Feb 89 10:32:10 PST Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 7 Feb 89 10:33:15 PST Received: from JUNCO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 534937; Tue 7-Feb-89 13:29:52 EST Date: Tue, 7 Feb 89 13:28 EST From: Sonya Keene Subject: Re: I/O generic functions To: harris%hplwhh@hplabs.hp.com Cc: Gray@DSG.csc.ti.com, Common-Lisp-Object-System@SAIL.STANFORD.EDU, CL-Windows@SAIL.STANFORD.EDU, Kimbrough@DSG.csc.ti.com, Bartley@MIPS.csc.ti.com, CL-Cleanup@SAIL.STANFORD.EDU In-Reply-To: <26670.602878386@hplwhh> Message-Id: <19890207182849.1.SKEENE@JUNCO.SCRC.Symbolics.COM> Date: Tue, 07 Feb 89 10:13:06 PST From: Warren Harris I just wanted to point out that there is an entire section of Sonya Keene's book "Object Oriented Programming in Common Lisp" dedicated to an implementation of streams as objects. Perhaps this implementation would be a good starting point for a formal proposal on generic i/o routines. Can anyone summarize what might be missing in a "real" implementation? Warren I'd like to recommend against this idea! My goals in developing that example for my book were very different from your goals in designing a real stream implementation. I wanted to keep the example as simple as possible, while illustrating a lot of the sharing that can happen when streams are done in an object-oriented way. My main interest was not in doing streams the right way, but just to find something that could illustrate good modularity and inheritance. I agree that streams are ripe for an object-oriented design, but your design should probably start from scratch. Actually, there are some object-oriented streams implementations out there (Symbolics has one, and there must be others), and you could look into those as a starting point. Sonya From Common-Lisp-Object-System-mailer@SAIL.STANFORD.EDU Tue Feb 7 13:41:43 1989 Received: from Sail.Stanford.EDU by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA11836; Tue, 7 Feb 89 13:41:43 PST Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 7 Feb 89 13:41:39 PST Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs) id AA05101; Tue, 7 Feb 89 14:39:59 -0700 Received: by defun.utah.edu (5.61/utah-2.0-leaf) id AA00904; Tue, 7 Feb 89 14:39:57 -0700 From: sandra%defun@cs.utah.edu (Sandra J Loosemore) Message-Id: <8902072139.AA00904@defun.utah.edu> Date: Tue, 7 Feb 89 14:39:55 MST Subject: issue COMPILE-ENVIRONMENT-CONSISTENCY To: Common-Lisp-Object-System@SAIL.STANFORD.EDU Cc: CL-Compiler@SAIL.STANFORD.EDU In-Reply-To: David N Gray , Thu, 26 Jan 89 18:36:59 CST Just a reminder -- at last month's meeting there was a comment that the part of this proposal dealing with CLOS is "wrong". Can somebody please supply more specifics about the complaint and/or suggest some alternate wording? If I don't hear from anybody, the existing wording will remain. -Sandra ------- From CL-Cleanup-mailer@SAIL.STANFORD.EDU Tue Feb 7 20:14:05 1989 Received: from Sail.Stanford.EDU by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA17684; Tue, 7 Feb 89 20:14:05 PST Received: from PORSCHE.SCRC.Symbolics.COM ([128.81.41.69]) by SAIL.Stanford.EDU with TCP; 7 Feb 89 19:39:53 PST Received: from OWL.SCRC.Symbolics.COM by PORSCHE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 230; Tue 7-Feb-89 22:03:09 EST Date: Tue, 7 Feb 89 22:02 EST From: Mike McMahon Subject: I/O generic functions To: David N Gray Cc: CL-Cleanup@SAIL.STANFORD.EDU, Common-Lisp-Object-System@SAIL.STANFORD.EDU, CL-Windows@SAIL.STANFORD.EDU, Kimbrough@DSG.csc.ti.com, Bartley@MIPS.csc.ti.com In-Reply-To: <2811859381-15005799@Kelvin> Message-Id: <19890208030248.1.MMCM@OWL.SCRC.Symbolics.COM> This is the right sort of start. I have a few observations which are not meant to be comprehensive. They might help stimulate further careful design. STREAM-LISTEN is actually not mandatory: you can implement it using READ-CHAR-NO-HANG and UNREAD-CHAR. If people are going to start defining well behaved streams, some protocols need to be firmed up. For instance, if LISTEN is true, must READ-CHAR-NO-HANG return a character? Or is it only that READ-CHAR-NO-HANG returns a character or clears the LISTEN condition? You can see the difference in the behavior of an encapsulated stream with escape characters. In the one case, LISTEN can just do LISTEN on the inside stream, which is presumably fast (e.g. checks some network buffer pointers). If the buffer contains only the start of an escape sequence, READ-CHAR-NO-HANG will still not return a character. In the other case, LISTEN must run the entire decoding machinery right away and unread any character it produces. The key decision is whether you want LISTEN to be complete or efficient. Wouldn't it be better to have just one centralized implementation of eof-error-p eof-value handling? The internal stream methods could obey just one protocol for returning EOF which the outer would process independently. From Common-Lisp-Object-System-mailer@SAIL.STANFORD.EDU Wed Feb 8 12:48:29 1989 Received: from Sail.Stanford.EDU by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA28740; Wed, 8 Feb 89 12:48:29 PST Received: from ti.com by SAIL.Stanford.EDU with TCP; 8 Feb 89 12:49:36 PST Received: by ti.com id AA02394; Wed, 8 Feb 89 14:48:22 CST Received: from Kelvin by tilde id AA18494; Wed, 8 Feb 89 14:39:33 CST Message-Id: <2811962330-5851625@Kelvin> Sender: GRAY@Kelvin.csc.ti.com Date: Wed, 8 Feb 89 14:38:50 CST From: David N Gray To: Gregor.pa@Xerox.COM Cc: Common-Lisp-Object-System@SAIL.STANFORD.EDU Subject: omissions from chapter 3 I'm puzzled by some of the things that were in document 88-003 [the March draft of the MOP] but disappeared in document 89-003 [December]. CHECK-INITARGS and DEFAULT-INITARGS [88-003 p. 3-12] have disappeared. OK, maybe these don't need to be standardized, but note that pages 1-41 and 42 will need to be updated -- it mentions DEFAULT-INITARGS and CLASS-SLOT-INITARGS, which has also disappeared. Also gone are CLASS-DIRECT-SLOT-INITARGS [p. 3-17], CLASS-SLOT-INITARGS, CLASS-DIRECT-INITARGS, and CLASS-INITARGS [p. 3-18]; is that intentional? Generic functions VALID-CLASS-OPTION-P, VALID-SLOT-DESCRIPTION-P, and VALID-SLOT-OPTION-P [all on page 3-15 of 88-003] are gone. The new document doesn't discuss how extensions to the options are to be handled. Is the idea that all class and slot options appearing in a DEFCLASS will simply be passed on to MAKE-INSTANCE and it will decide what is legal? If so, does that mean that MAKE-INSTANCE of a class will see :DOCUMENTATION '"string" or :DOCUMENTATION '("string") ? Starting on page 3-43 of 88-003 is a three page discussion of the expansion of DEFINE-METHOD-COMBINATION, while document 89-003 has nothing. Should I assume from this that you have decided that the old description was wrong, but don't yet know what the right answer is? The "instance access optimization protocol" [88-003 p. 56] has disappeared. We had already implemented DEFINE-INSTANCE-ACCESS-OPTIMIZATION, OPTIMIZE-SLOT-VALUE, OPTIMIZE-SETF-SLOT-VALUE, STANDARD-INSTANCE-ACCESS, and (SETF STANDARD-INSTANCE-ACCESS), and it all seemed to be working quite nicely. This seems like a significant loss in functionality for the metaclass writer. From Owners-commonloops.pa@Xerox.COM Thu Feb 9 06:57:53 1989 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA09922; Thu, 9 Feb 89 06:57:53 PST Received: from Cabernet.ms by ArpaGateway.ms ; 09 FEB 89 06:58:02 PST Return-Path: Redistributed: commonloops.pa Received: from siemens.siemens.com ([129.73.7.1]) by Xerox.COM ; 09 FEB 89 06:55:56 PST Received: by siemens.siemens.com (5.54/1.15) id AA02145; Thu, 9 Feb 89 09:54:57 EST From: adf@ztivax.siemens.com (Angela Dappert-Farquhar) Date: Thu, 9 Feb 89 15:54:15 -0100 Message-Id: <8902091454.AA09942@ztivax.uucp> Received: by ztivax.uucp; Thu, 9 Feb 89 15:54:15 -0100 To: commonloops.pa@Xerox.COM Subject: design of update-instance-for-redefined-class and bug in PCL Subject: Design of update-instance-for-redefined-class and bug in PCL In 8-28-88-notes.text it says - the initialization protocol specified in 88-002R is now almost completely implemented. The only difference is that the current implementation does not currently check the validity of initargs. So, no errors are signalled in improper initargs are supplied. There are several points, though, that either don't work yet or are not clearly specified. 1. In update-instance-for-redefined-class (chapter 2) the argument description for initargs says 'The initargs argument consists of alternating initialization argument names and values.' This is not clear enough for me. Does that mean that the implementor has to / is allowed to pass the new classes default-initargs here? Or is it even meant for the user who can hand in some arguments here? I think that default-initargs definitely should be passed here. See the following example: (defclass a () ()) (setq inst (*make-instance 'a)) (defclass a () ((s3 :initarg :s3)) (:default-initargs :s3 'default-s3)) (slot-value inst 's3) ;(after the error that is mentioned in point 3, ; see below) ; --> unbound, because only the initforms of added ; slots are evaluated 2. The spec also says that update-inheritance-for-redefined-class calls shared-initialize with "a list of names of the newly added slots", which then are used for deciding whether initforms will be evaluated. For Slots that are already there but are unbound in an instance a newly added initform won't be evaluated. (defclass a () (s1)) (setq inst (*make-instance 'a)) (defclass a () ((s1 :initform 's1))) (slot-value inst 's1) ; --> unbound I would expect, that the newly added initform of the transfered slot would be evaluated if the slot was unbound in the instance at the time of class redefinition. Is this intented? 3. Now, the following is a bug in the PCL code. - If you redefined a class slot update doesn't take place before you access an *added* slot. So in the example below you can access s1 and even the discarded slot s2 and get their old values. Update-instance-for-redefined-class isn't executed before accessing s3. - If you access the newly added slot s3 the first time you get a slot-missing message. In spite of that the update takes place *after* the error message and results in a correct update. (defmethod update-instance-for-redefined-class :around ((instance object) added-slots discarded-slots plist &rest initargs) (format t "instance ~S~%" instance) (format t "added-slots ~S~%" added-slots) (format t "discarded-slots ~S~%" discarded-slots) (format t "plist ~S~%" plist) (apply #'call-next-method instance added-slots discarded-slots plist initargs) (Inspect (iwmc-class-static-slots instance))) (defclass b () ((s1 :initarg :s1 ) (s2 :initarg :s2 ))) (setq inst (*make-instance 'b :s1 1 :s2 2 )) (Inspect (iwmc-class-static-slots inst)) (defclass b () (s1 s3)) (Inspect (iwmc-class-static-slots inst)) (slot-value inst 's1) ;;; 1 (slot-value inst 's2) ;;; 2 - should be missing (slot-value inst 's3) ;;; missing and update From Common-Lisp-Object-System-mailer@SAIL.STANFORD.EDU Thu Feb 9 13:03:49 1989 Received: from Sail.Stanford.EDU by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA13463; Thu, 9 Feb 89 13:03:49 PST Received: from ti.com by SAIL.Stanford.EDU with TCP; 9 Feb 89 13:04:44 PST Received: by ti.com id AA06876; Thu, 9 Feb 89 15:03:34 CST Received: from Kelvin by tilde id AA17405; Thu, 9 Feb 89 14:46:33 CST Message-Id: <2812049147-11196035@Kelvin> Sender: GRAY@Kelvin.csc.ti.com Date: Thu, 9 Feb 89 14:45:47 CST From: David N Gray To: Common-Lisp-Object-System@SAIL.STANFORD.EDU Subject: local generic functions Is the list returned by SPECIALIZER-DIRECT-GENERIC-FUNCTIONS supposed to include local functions defined by GENERIC-FLET or anonymous functions created by the GENERIC-FUNCTION macro? I haven't seen anything that says they are an exception, but if they need to be recorded here, then there would be no way to ever garbage-collect them once created. From Common-Lisp-Object-System-mailer@SAIL.STANFORD.EDU Fri Feb 10 13:19:02 1989 Received: from Sail.Stanford.EDU by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA28287; Fri, 10 Feb 89 12:56:34 PST Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 10 Feb 89 12:57:19 PST Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs) id AA25181; Fri, 10 Feb 89 13:55:39 -0700 Received: by defun.utah.edu (5.61/utah-2.0-leaf) id AA01721; Fri, 10 Feb 89 13:55:37 -0700 From: sandra%defun@cs.utah.edu (Sandra J Loosemore) Message-Id: <8902102055.AA01721@defun.utah.edu> Date: Fri, 10 Feb 89 13:55:36 MST Subject: Re: issue MACRO-ENVIRONMENT-EXTENT, version 1 To: David N Gray Cc: sandra%defun@cs.utah.edu (Sandra J Loosemore), cl-compiler@SAIL.STANFORD.EDU, common-lisp-object-system@SAIL.STANFORD.EDU In-Reply-To: David N Gray , Fri, 13 Jan 89 17:33:28 CST > Date: Fri, 13 Jan 89 17:33:28 CST > From: David N Gray > > > Proposal MACRO-ENVIRONMENT-EXTENT:INDEFINITE: > > > > State that macro environment objects received with the &ENVIRONMENT > > argument of a macro function have indefinite extent. > > That's fine for macro definitions, but this will not work for environments > containing class definitions. The compiler needs to be able to know when > those compile-time class definitions are no longer needed so that they can > be unlinked from the class data structures. > > This issue has a strong relationship with issue > SYNTACTIC-ENVIRONMENT-ACCESS since it proposes extending the use of > environments in ways that would make anything other than > MACRO-ENVIRONMENT-EXTENT:DYNAMIC difficult to retro-fit to existing > implementations. I am still trying to understand all of the implications of what CLOS wants to do with macro expansion environments. To me, it seems like this whole business would be difficult to retro-fit to existing implementations, regardless of what we decide to do about the extent of macro environments. My current mental picture of how this is supposed to work is that compile-time environment objects are supposed to contain a pointer to a database of all the class definitions. I don't see why the compiler would need to unlink anything; when there are no longer any pointers to the database, it would get "unlinked" automatically during garbage collection, just like any other object, right? -Sandra ------- From CL-Compiler-mailer@SAIL.STANFORD.EDU Fri Feb 10 14:51:57 1989 Received: from Sail.Stanford.EDU by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA01774; Fri, 10 Feb 89 14:51:57 PST Received: from PORSCHE.SCRC.Symbolics.COM ([128.81.41.69]) by SAIL.Stanford.EDU with TCP; 10 Feb 89 14:49:27 PST Received: from EUPHRATES.SCRC.Symbolics.COM by PORSCHE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 868; Fri 10-Feb-89 17:12:57 EST Date: Fri, 10 Feb 89 17:13 EST From: David A. Moon Subject: Re: issue MACRO-ENVIRONMENT-EXTENT, version 1 To: Sandra J Loosemore Cc: David N Gray , cl-compiler@SAIL.STANFORD.EDU, common-lisp-object-system@SAIL.STANFORD.EDU In-Reply-To: <8902102055.AA01721@defun.utah.edu> Message-Id: <19890210221326.7.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Fri, 10 Feb 89 13:55:36 MST From: sandra%defun@cs.utah.edu (Sandra J Loosemore) I am still trying to understand all of the implications of what CLOS wants to do with macro expansion environments. Resolving that is dependent on resolving EVAL-WHEN. You either already have the Symbolics proposal for EVAL-WHEN, or will have it soon (I'm not sure if Kent sent it yet). I think only Sandra will see this draft, the mailing lists should see it shortly afterwards. To me, it seems like this whole business would be difficult to retro-fit to existing implementations, regardless of what we decide to do about the extent of macro environments. My opinion is that anything in CLOS that seems to depend on indefinite extent for macro environments is broken and needs to be fixed. It's not broken because of the environment extent, but for other reasons. Thus I believe in dynamic extent for environments. > Date: Fri, 13 Jan 89 17:33:28 CST > From: David N Gray > That's fine for macro definitions, but this will not work for environments > containing class definitions. The compiler needs to be able to know when > those compile-time class definitions are no longer needed so that they can > be unlinked from the class data structures. My current mental picture of how this is supposed to work is that compile-time environment objects are supposed to contain a pointer to a database of all the class definitions. "pointer" is a key word that usually means you are thinking at too low a level of abstraction. Also that mental picture may or may not be wrong, depending on how we resolve how CLOS metaobjects work at compile time, which depends on resolving EVAL-WHEN first. I don't see why the compiler would need to unlink anything; when there are no longer any pointers to the database, it would get "unlinked" automatically during garbage collection, just like any other object, right? When Gray said "unlink" he was referring to the links between subclasses and superclasses, not the links between names and objects. From Common-Lisp-Object-System-mailer@SAIL.STANFORD.EDU Sun Feb 12 18:25:52 1989 Received: from Sail.Stanford.EDU by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA24163; Sun, 12 Feb 89 18:25:52 PST Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 12 Feb 89 18:26:21 PST Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs) id AA03819; Sun, 12 Feb 89 19:21:55 -0700 Received: by defun.utah.edu (5.61/utah-2.0-leaf) id AA02883; Sun, 12 Feb 89 19:20:31 -0700 From: sandra%defun@cs.utah.edu (Sandra J Loosemore) Message-Id: <8902130220.AA02883@defun.utah.edu> Date: Sun, 12 Feb 89 19:20:29 MST Subject: Re: issue MACRO-ENVIRONMENT-EXTENT, version 1 To: David A. Moon Cc: Sandra J Loosemore , David N Gray , cl-compiler@SAIL.STANFORD.EDU, common-lisp-object-system@SAIL.STANFORD.EDU In-Reply-To: David A. Moon , Fri, 10 Feb 89 17:13 EST Having seen the new proposal for EVAL-WHEN, I still don't have any idea why the extent of macro environment objects depends on it. Can you explain the connection? Also, I don't think anybody is arguing for requiring environments to have indefinite extent on the grounds that CLOS requires it. (The argument is that it's generally useful and for general symmetry with every other kind of Lisp data object having indefinite extent.) Just the opposite -- David Gray's question was whether that requirement would complicate the implementation of CLOS. At the January meeting, Gregor made a verbal suggestion that perhaps implementations ought to be allowed to support only dynamic extent, but that we should add a function to make a copy of the environment object which would have indefinite extent. If the problem is indeed that certain things must be "unlinked" at the end of compilation, it doesn't seem like this would solve the problem. -Sandra ------- From Owners-CommonLoops.PA@Xerox.COM Mon Feb 13 18:25:16 1989 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA02920; Mon, 13 Feb 89 18:25:16 PST Received: from Chardonnay.ms by ArpaGateway.ms ; 13 FEB 89 16:47:50 PST Return-Path: Redistributed: CommonLoops.PA Received: from june.cs.washington.edu ([128.95.1.4]) by Xerox.COM ; 13 FEB 89 16:43:03 PST Received: by june.cs.washington.edu (5.59/6.13+) id AA00877; Mon, 13 Feb 89 16:43:02 PST Date: Mon, 13 Feb 89 16:43:02 PST From: whaley@june.cs.washington.edu (Ken Whaley) Return-Path: Message-Id: <8902140043.AA00877@june.cs.washington.edu> To: CommonLoops.PA@Xerox.COM I'm trying to build the PCL I just ftpd' from arisia, and have run into some problems. I'm using AKCL-1-86, and seem to recall someone posting earlier some problems & fixes with building PCL in KCL. (I applied the speedup changes in kcl-mods.text). I moved all of the ".lisp" files to ".lsp" files, loaded defsys.lsp, and typed compile-pcl. I frequently got the warning message ;; Warning: The variable &ENVIRONMENT is not used. I presume this has something to do with the redefinition of defmacro in kcl-patches.lsp. The compile proceeded for a few files, then did this: Compiling FIN... Compiling /u4/whaley/skagit/pcl/fin.lsp. ; (DEFMACRO FUNCALLABLE-INSTANCE-DATA-1 ...) is being compiled. ;; Warning: The variable &ENVIRONMENT is not used. Error: Too few arguments are supplied to defmacro-lambda-list. Error signalled by IF. Backtrace: macroexpand > funcall > funcall > funcallable-instance-data-1 > if ; (DEFUN ALLOCATE-FUNCALLABLE-INSTANCE ...) is being compiled. ;;; The macro form (SETF (FUNCALLABLE-INSTANCE-WRAPPER FIN) WRAPPER (FUNCALLABLE-INSTANCE-STATIC-SLOTS FIN) STATIC-SLOTS) was not expanded successfully. Error: Too few arguments are supplied to defmacro-lambda-list. Error signalled by IF. Backtrace: funcall > funcall > funcall > funcallable-instance-data-1 > if ;;; The macro form (SETF ...) was not expanded successfully. ;; Warning: The variable STATIC-SLOTS is not used. I did't seen anything like this described in the notesfiles, so I am appealing to you all out there for suggestions. Ken whaley@june.cs.washington.edu From Common-Lisp-Object-System-mailer@SAIL.STANFORD.EDU Tue Feb 14 23:13:16 1989 Received: from Sail.Stanford.EDU by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA24289; Tue, 14 Feb 89 23:13:16 PST Received: from a.cs.uiuc.edu by SAIL.Stanford.EDU with TCP; 14 Feb 89 23:14:35 PST Received: from p.cs.uiuc.edu by a.cs.uiuc.edu with SMTP (5.61+/IDA-1.2.8) id AA07752; Wed, 15 Feb 89 01:12:50 -0600 Received: by p.cs.uiuc.edu (UIUC-5.52/9.7) id AA07620; Wed, 15 Feb 89 01:05:50 CST Date: Wed, 15 Feb 89 01:05:50 CST From: foote@p.cs.uiuc.edu (Brian Foote) Message-Id: <8902150705.AA07620@p.cs.uiuc.edu> To: common-lisp-object-system@SAIL.STANFORD.EDU Subject: CLOS Mailing List Please add my name to your mailing list. foote@p.cs.uiuc.edu Brian Foote, Dept. of CS, U. of Illinois, Urbana, IL 61801 (217) 333-3411 From Owners-commonloops.pa@Xerox.COM Wed Feb 15 09:54:33 1989 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA29110; Wed, 15 Feb 89 09:54:33 PST Received: from Salvador.ms by ArpaGateway.ms ; 15 FEB 89 08:56:32 PST Return-Path: Redistributed: commonloops.pa Received: from A.ISI.EDU ([26.3.0.103]) by Xerox.COM ; 15 FEB 89 08:52:42 PST Date: Wed, 15 Feb 89 11:45:35 EST From: Patrick D. Vye Subject: GCLISP Version 1.01 and PCL To: commonloops.pa@Xerox.COM Cc: cacda-c3i@A.ISI.EDU Message-Id: <12470897429.38.CACDA-C3I@A.ISI.EDU> Hi: I am trying to get some help. I downloaded a version of PCL for GCLISP. . .but I am having trouble installing it using GCLISP Version 1.01. The problem appears to be that some of the "package" functions were not fully defined in version 1.01. Has anyone been able to do any work arounds? Or any idea for how I might get PCL up and running? Thanks in advance for your help. Pat Vye ------- From Owners-commonloops.pa@Xerox.COM Thu Feb 16 08:53:44 1989 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA14858; Thu, 16 Feb 89 08:53:44 PST Received: from Salvador.ms by ArpaGateway.ms ; 16 FEB 89 08:53:48 PST Return-Path: Redistributed: commonloops.pa Received: from vaxa.isi.edu ([128.9.0.33]) by Xerox.COM ; 16 FEB 89 08:47:26 PST Posted-Date: Thu, 16 Feb 89 08:47:58 PST Message-Id: <8902161648.AA19977@vaxa.isi.edu> Received: from LOCALHOST by vaxa.isi.edu (5.59/5.51) id AA19977; Thu, 16 Feb 89 08:48:00 PST To: commonloops.pa@Xerox.COM From: goldman@vaxa.isi.edu Subject: pcl:FUNCTION-ARGLIST Date: Thu, 16 Feb 89 08:47:58 PST Sender: goldman@vaxa.isi.edu I was looking for a way to find the lambda list of a generic function in PCL, and found the (non-exported) function pcl::function-arglist. If there is something else I should be using, could someone tell me what (and ignore the rest of this message.) Incidentally, is there a function in CLOS (standard or meta) for this, or has common lisp cleanup approved an ARGLIST accessor for all functions? Otherwise, (in no-cute-name pcl) FUNCTION-ARGLIST seems to do what I expect in the symbolics implementation, but not in the ti explorer implementation, as shown below. Neil ---------------------------------------------------------------- (defclass my-class () ((my-slot :reader my-slot))) (pcl::function-arglist 'my-slot) ==> (MY-CLASS) ;on the symbolics pcl ==> (&REST PCL:ARGS) ;on the explorer pcl From Common-Lisp-Object-System-mailer@SAIL.STANFORD.EDU Thu Feb 16 12:02:28 1989 Received: from Sail.Stanford.EDU by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA17096; Thu, 16 Feb 89 12:02:28 PST Received: from ti.com by SAIL.Stanford.EDU with TCP; 16 Feb 89 12:03:49 PST Received: by ti.com id AA04355; Thu, 16 Feb 89 14:02:29 CST Received: from Kelvin by tilde id AA14786; Thu, 16 Feb 89 13:48:07 CST Message-Id: <2812650462-8421010@Kelvin> Sender: GRAY@Kelvin.csc.ti.com Date: Thu, 16 Feb 89 13:47:42 CST From: David N Gray To: Common-Lisp-Object-System@SAIL.STANFORD.EDU Subject: effective methods question Is the list returned by functions SPECIALIZER-DIRECT-METHODS and GENERIC-FUNCTION-METHODS intended to include effective methods, or just the explicitly defined methods? From Common-Lisp-Object-System-mailer@SAIL.STANFORD.EDU Thu Feb 16 12:48:27 1989 Received: from Sail.Stanford.EDU by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA17563; Thu, 16 Feb 89 12:48:27 PST Received: from ti.com by SAIL.Stanford.EDU with TCP; 16 Feb 89 12:49:30 PST Received: by ti.com id AA04642; Thu, 16 Feb 89 14:48:08 CST Received: from Kelvin by tilde id AA16733; Thu, 16 Feb 89 14:41:31 CST Message-Id: <2812653665-8613469@Kelvin> Sender: GRAY@Kelvin.csc.ti.com Date: Thu, 16 Feb 89 14:41:05 CST From: David N Gray To: Common-Lisp-Object-System@SAIL.STANFORD.EDU Cc: masinter.pa@Xerox.COM Subject: DEFSTRUCT and DEFCLASS I'm confused about the use of metaclass STRUCTURE-CLASS; a cleanup proposal to clarify this is needed. In X3J13 correspondence, I've seen mentions of using DEFCLASS instead of DEFSTRUCT to create structures, but document 88-002R does not say that you can do that. On the other hand, it doesn't say that you can't either. Basically the question is whether (DEFSTRUCT ... (:METACLASS STRUCTURE-CLASS)) is legal and, if so, just what it means. What the document _does_ say on page 1-15: "Calling MAKE-INSTANCE to create an instance of a built-in class signals an error. Calling SLOT-VALUE on an instance of a built-in class signals an error." No such error is specified for STRUCTURE-CLASS; is that intended to imply that SLOT-VALUE of a structure _is_ legal? Page 2-80 does not shed any light on this. It isn't until page 3-107 of document 89-003 that we see that, yes, it is supposed to be supported. Also on page 1-15: "Calling MAKE-INSTANCE to create an instance of STRUCTURE-CLASS signals an error." I had always thought that this meant that MAKE-INSTANCE couldn't be used to create an instance of a structure type, but looking at it again now, it looks like it just means that you can't create the structure type by (MAKE-INSTANCE 'STRUCTURE-CLASS); perhaps a clarification of the wording would be in order. But since DEFCLASS uses ENSURE-CLASS which uses MAKE-INSTANCE, does that imply that DEFCLASS can't be used either? Page 3-35 of 89-003 does specify an ALLOCATE-INSTANCE method for STRUCTURE-CLASS, which would imply that MAKE-INSTANCE _can_ be used to create instances of structure types. But if chapter 3 is not going to make it into the standard, then it is even more important to clarify this in chapters 1 and 2 -- is the use of DEFCLASS, MAKE-INSTANCE, SLOT-VALUE etc. for structures * Required to be supported? or * Required to signal an error? or * A permissible extension? Also, if (DEFSTRUCT ... (:METACLASS STRUCTURE-CLASS)) is permitted, what limitations or extensions apply to the slot and class options? Does it create a MAKE-... function? Does it accept a :CONSTRUCTOR class option? What kind of accessors does it create -- inline functions like DEFSTRUCT, or generic function methods like STANDARD-CLASS? Is :ALLOCATION :CLASS permitted? From Common-Lisp-Object-System-mailer@SAIL.STANFORD.EDU Thu Feb 16 13:47:18 1989 Received: from Sail.Stanford.EDU by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA18094; Thu, 16 Feb 89 13:47:18 PST Received: from ti.com by SAIL.Stanford.EDU with TCP; 16 Feb 89 13:48:40 PST Received: by ti.com id AA04891; Thu, 16 Feb 89 15:47:16 CST Received: from Kelvin by tilde id AA18131; Thu, 16 Feb 89 15:31:24 CST Message-Id: <2812656663-8793592@Kelvin> Sender: GRAY@Kelvin.csc.ti.com Date: Thu, 16 Feb 89 15:31:03 CST From: David N Gray To: Common-Lisp-Object-System@SAIL.STANFORD.EDU Subject: CLOS questions I have still more questions, this time about chapters 1 and 2. Page 1-15 of 88-002R says that "Each class that corresponds to a predefined Common Lisp type specifier can be implemented in one of three ways ... a standard class ..., a structure class ..., or a built-in class ..." Shouldn't this also permit the possibility of other implementation-specific metaclasses? For example, in our current implementation the class PATHNAME is an instance of metaclass FLAVOR-CLASS. Page 1-27 says that the default argument precedence order is left to right, but I wonder if in the case of (SETF ...) functions it wouldn't make more sense for the default order to put the new-value argument last instead of first? This wouldn't normally change the semantics, but it could affect efficiency. I'm a little confused by the way that SLOT-BOUNDP [p. 2-75], SLOT-EXISTS-P [p. 2-76], and SLOT-MAKUNBOUND [p. 2-77] are specified as generic functions with a primary method on class STANDARD-OBJECT which just invokes a SLOT-...-USING-CLASS generic function. Do these really need to be generic at both levels? According to the specification, SLOT-BOUNDP, for example, should be implemented as (defgeneric slot-boundp (instance slot-name)) (defmethod slot-boundp ((instance STANDARD-OBJECT) slot-name) (slot-boundp-using-class (class-of instance) instance slot-name)) but it seems like it would make more sense to do either (defgeneric slot-boundp (instance slot-name)) (defmethod slot-boundp ((instance T) slot-name) (slot-boundp-using-class (class-of instance) instance slot-name)) or just (DEFUN slot-boundp (instance slot-name) (slot-boundp-using-class (class-of instance) instance slot-name)) Note that the latter parallels the way that SLOT-VALUE is specified. The syntax template for WITH-ADDED-METHODS [p. 2-90] differs from GENERIC-LABELS [p. 2-55] by defining exactly one function instead of an arbitrary number of functions. This is not mentioned anywhere in the text, which makes me wonder if that is intentional or if it might be just a typographical error? For functions INVALID-METHOD-ERROR and and METHOD-COMBINATION-ERROR to be fully portable, it would be helpful to have some sort of guideline on message formats. For example, should it be a phrase, or a complete sentence? Otherwise, a message that looks elegant on one implementation could look bad on another because it is displayed in a different context. Page 2-19 should be updated to show COMPUTE-APPLICABLE-METHODS being a generic function to match page 3-38. Is someone planning to specify exactly which conditions are supposed to be signalled for the various "signals an error" situations? What package are these symbols in? Also, given the emphasis on having the standard package contain exactly the standard set of symbols, it would be helpful to have an official list of the exported CLOS symbols. For example, I had trouble deciding whether STANDARD was supposed to be a defined symbol [until I found the reference on page 1-31]. From Common-Lisp-Object-System-mailer@SAIL.STANFORD.EDU Thu Feb 16 16:13:51 1989 Received: from Sail.Stanford.EDU by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA20074; Thu, 16 Feb 89 16:13:51 PST Received: from lucid.com by SAIL.Stanford.EDU with TCP; 16 Feb 89 16:14:32 PST Received: from challenger ([192.9.200.17]) by heavens-gate.lucid.com id AA03690g; Thu, 16 Feb 89 15:51:20 PST Site: Received: by challenger id AA06638g; Thu, 16 Feb 89 15:46:56 PST Date: Thu, 16 Feb 89 15:46:56 PST From: Patrick Dussud Message-Id: <8902162346.AA06638@challenger> To: Gray@DSG.csc.ti.com Cc: Common-Lisp-Object-System@SAIL.STANFORD.EDU In-Reply-To: David N Gray's message of Thu, 16 Feb 89 13:47:42 CST <2812650462-8421010@Kelvin> Subject: effective methods question Sender: GRAY@Kelvin.csc.ti.com Date: Thu, 16 Feb 89 13:47:42 CST From: David N Gray Is the list returned by functions SPECIALIZER-DIRECT-METHODS and GENERIC-FUNCTION-METHODS intended to include effective methods, or just the explicitly defined methods? It should return only the explicitly defined methods, since it is not specified what an effective method is, or if it should exist. Patrick. From Common-Lisp-Object-System-mailer@SAIL.STANFORD.EDU Thu Feb 16 22:18:38 1989 Received: from Sail.Stanford.EDU by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA24602; Thu, 16 Feb 89 22:18:38 PST Message-Id: <8902170618.AA24602@arisia.Xerox.COM> Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 16 Feb 89 22:19:47 PST Received: from PEGASUS.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 541002; Fri 17-Feb-89 01:17:42 EST Received: by Pegasus.SCRC.Symbolics.COM id AA23272; Fri, 17 Feb 89 01:05:53 est Date: Fri, 17 Feb 89 01:05:53 est From: David Moon To: Common-Lisp-Object-System@SAIL.STANFORD.EDU Subject: Comments on metaobject draft 10 Comments from Moon on 89-003 MOP draft number 10 I didn't make it all the way through the document, but here are the comments I was able to come up with. This is a big advance over the previous draft I read, some time in early fall. 3-6..8: A few attributes of metaobjects seem to be missing here. Names for classes and generic functions, documentation strings for classes, generic functions, and methods. Is this just an oversight or does it represent some kind of modularity decision where there is a level that does not have these attributes? 3-7: How come direct slot definitions have names of generic functions in them, rather than generic function objects? 3-9: Some problems with the inheritance structure table: It claims metaobject is a subclass of function, which is surely untrue. What is the metaclass of structure-object? The caption implies standard-class, but I would expect that it is really structure-class. Also I would really expect the metaclass of t to be a special metaclass just for t, rather than built-in-class; is it allowed to be a subclass of built-in-class? I don't like the name "dependee-mixin", I think "redefinable" might be a better word than "dependee." 3-10: "The default class of method combination objects is not specified." This seems inconsistent, I wonder if we want to change it. The short form and the long form of define-method-combination would likely use different classes. 3-11: I think rule 3 doesn't work, for the same reason I complained about last time. I haven't rechecked this. 3-11: Rule 5 says implementations can define unspecified :before and :after methods, what about :around? 3-11: Rule 8 is slightly wrong, see the cleanup issue PACKAGE-CLUTTER. The way you say that slot names can't be in packages the user knows about is more complex. It would be better if ANSI Common Lisp just had a word for it so we didn't have to keep saying it over and over. This issue also arises in the section on expansion of the user interface macros. 3-13ff: The whole section on expansion of the user interface macros is totally screwed up, as I think you know. Straightening out the Common Lisp issues with EVAL-WHEN and lexical environments is a prerecquisite for fixing this. The biggest problem is deciding what happens at macro expansion time versus what happens when the macro expansion is evaluated. These days I believe that nothing "essential" should happen at macro expansion time. I think compile-time method and slot-description metaobjects should have their function slots unbound -- except since the MOP doesn't define them to be slots, this has to be said differently. But it is an error to access the function. A more difficult problem (I think this has been discussed inconclusively in the mail) is the relation of the local and remote metaobjects in compile-file; ideally creating a remote class should create remote objects for all its superclasses and subclasses, so there are no cross-environment links, but that would copy the entire meta-object world, which would be too slow. Hence you either have to indirect through names, as Flavors does, or use a virtual-copy mechanism of some sort. I don't know whether a virtual copy mechanism will require some kind of change of protocol, with some more user interface functions taking an environment argument; indirecting through names avoids that issue since the indirection is a name-to-object translation that -always- requires an environment argument. Comments? 3-17: Still on the user interface macros: there is something fundamentally wrong with specifying load time and eval time separately. What they do should be equivalent at the level of abstraction used in the spec. 3-22: I believe the expansion of define-method-combination was pretty well outlined in 88-002, unless that was only in our mail discussions and did not get into the final document. 3-25: The whole slot-definition-elide-access-method-p (and relatives) mechanism seems inconsistent with the rest of CLOS. I would have expected this to be handled by making the slot-descriptor and argument to functions at the level of slot-value-using-class, then the class of the slot descriptor contributes to selecting the applicable methods and the optimization can be performed if and only if the built-in method is the only applicable method. 3-26: The restriction mentioned against using an obsolete instance that has not yet been updated may be unimplementable, or even meaningless, in multiprocess systems (where a class can be redefined at any instant that user code can be running). 3-29: The first object to add-dependent shouldn't be specified to be a metaobject, since not all metaobjects work and some non-metaobjects work. It should be an object that you call "dependee" or I call "redefinable". 3-32: This says add-direct-subclass is called when a class is redefined. Is it also called when a class is initially defined? 3-33: For functions like add-method that appear in both chapter 2 and chapter 3, should Common Lisp be amended to delete the chapter 2 version? Or is it really intended to have two probably non-identical definitions of these functions? 3-50: The ensure-class-using-class generic function should not have &allow-other-keys in its arglist. Recall that this means that there should never be any argument checking on calls to this generic function, which seems unlikely to be what you want. I guess that's as far as I have gotten so far. I suppose it would be more useful for me to think about the expansion of the user interface macros than to try to plow through the rest of the document (yet more function descriptions). From Common-Lisp-Object-System-mailer@SAIL.STANFORD.EDU Tue Feb 21 10:52:40 1989 Received: from Sail.Stanford.EDU by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA04228; Tue, 21 Feb 89 10:52:40 PST Received: from lucid.com by SAIL.Stanford.EDU with TCP; 21 Feb 89 10:53:40 PST Received: from challenger ([192.9.200.17]) by heavens-gate.lucid.com id AA07349g; Tue, 21 Feb 89 10:47:29 PST Received: by challenger id AA05756g; Tue, 21 Feb 89 10:43:04 PST Date: Tue, 21 Feb 89 10:43:04 PST From: Patrick Dussud Message-Id: <8902211843.AA05756@challenger> To: Gray@DSG.csc.ti.com Cc: Common-Lisp-Object-System@SAIL.STANFORD.EDU In-Reply-To: David N Gray's message of Thu, 16 Feb 89 15:31:03 CST <2812656663-8793592@Kelvin> Subject: CLOS questions Sender: GRAY@Kelvin.csc.ti.com Date: Thu, 16 Feb 89 15:31:03 CST From: David N Gray Page 1-15 of 88-002R says that "Each class that corresponds to a predefined Common Lisp type specifier can be implemented in one of three ways ... a standard class ..., a structure class ..., or a built-in class ..." Shouldn't this also permit the possibility of other implementation-specific metaclasses? For example, in our current implementation the class PATHNAME is an instance of metaclass FLAVOR-CLASS. There is a compatibility question that needs to be answered. Right now, pathname is not supposed to be a class, so the question is mute, but when it will be, its metaclass has to be compatible with standard-class, so a portable program can inherit from it, and specialize some methods on it, as if it were a standard-class instance. Page 1-27 says that the default argument precedence order is left to right, but I wonder if in the case of (SETF ...) functions it wouldn't make more sense for the default order to put the new-value argument last instead of first? This wouldn't normally change the semantics, but it could affect efficiency. Maybe it does affect efficiency in some implementations, but I don't think it has to. I think that the user would be confused if we establish different default rules for setf generic functions. I except user changing the default procedence order if they know that the value is not significant for discrimination. I'm a little confused by the way that SLOT-BOUNDP [p. 2-75], SLOT-EXISTS-P [p. 2-76], and SLOT-MAKUNBOUND [p. 2-77] are specified as generic functions with a primary method on class STANDARD-OBJECT which just invokes a SLOT-...-USING-CLASS generic function. Do these really need to be generic at both levels? According to the specification, SLOT-BOUNDP, for example, should be implemented as Note that the latter parallels the way that SLOT-VALUE is specified. I think we said that was a bug. They all should be functions like slot-value. From Common-Lisp-Object-System-mailer@SAIL.STANFORD.EDU Tue Feb 21 14:59:57 1989 Received: from Sail.Stanford.EDU by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA11593; Tue, 21 Feb 89 14:59:57 PST Received: from ECLC.USC.EDU by SAIL.Stanford.EDU with TCP; 21 Feb 89 15:01:07 PST Date: Sun 19 Feb 89 15:54:36-PST From: Kim A. Barrett Subject: Issue MACRO-ENVIRONMENT-EXTENT To: sandra%defun@CS.UTAH.EDU Cc: Moon@SCRC-STONY-BROOK.ARPA, iim%ECLA@ECLC.USC.EDU, cl-compiler@SAIL.STANFORD.EDU, common-lisp-object-system@SAIL.STANFORD.EDU Message-Id: <12472024104.5.IIM@ECLA.USC.EDU> > From: sandra%defun@cs.utah.edu (Sandra J Loosemore) > Date: Sun, 12 Feb 89 19:20:29 MST > > Having seen the new proposal for EVAL-WHEN, I still don't have any idea why > the extent of macro environment objects depends on it. Can you explain the > connection? > > Also, I don't think anybody is arguing for requiring environments to have > indefinite extent on the grounds that CLOS requires it. (The argument is > that it's generally useful and for general symmetry with every other kind of > Lisp data object having indefinite extent.) Just the opposite -- David Gray's > question was whether that requirement would complicate the implementation of > CLOS. The extent of macro environment objects is related to EVAL-WHEN because macro expanders may wish to return forms which contain environments as quoted constants. For example: (defclass position (graphics-object) ((x :accessor position-x :initform 0 :type integer) (y :accessor position-y :initform 0 :type integer) (pen-color :allocation :class)) (:default-initargs :screen *position-screen*)) => `(progn (eval-when (compile) (ensure-class 'position :metaclass (find-class 'standard-class) :superclasses (list (find-class 'graphics-object t ',)) ; <= *** :direct-slots (list (make-instance 'standard-direct-slot :name 'x :initform '0 :readers '(position-x) :writers '((setf position-x)) :type 'integer) ... ) :default-initargs (list (list ':screen '*position-screen* nil)) :environment ',) ; <= *** ) (ensure-class 'position :metaclass (find-class 'standard-class) :superclasses (list (find-class 'graphics-object)) :direct-slots (list (make-instance 'standard-direct-slot :name 'x :initform '0 :initfunction #'(lambda () 0) :readers '(position-x) :writers '((setf position-x)) :type 'integer) ... ) :default-initargs (list (list ':screen '*position-screen* #'(lambda () *position-screen*)))) ) Not saying anything about their extent may make such an expansion invalid, because the expansion might be returned from the dynamic extent of the environment it points to. Requiring environments to have indefinite extent has problems for CLOS because at compile-time it wants to create remote metaobjects and link them into the right places, but then flush those links when the compilation is over. This is what I am trying to address with my recent comments about WITH-COMPILATION-UNIT. kab ------- From Common-Lisp-Object-System-mailer@SAIL.STANFORD.EDU Tue Feb 21 15:00:30 1989 Received: from Sail.Stanford.EDU by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA11610; Tue, 21 Feb 89 15:00:30 PST Received: from ECLC.USC.EDU by SAIL.Stanford.EDU with TCP; 21 Feb 89 15:01:51 PST Date: Sun 19 Feb 89 15:48:59-PST From: Kim A. Barrett Subject: Issue CONSTANT-COMPILABLE-TYPES To: JonL@LUCID.COM, sandra%defun@CS.UTAH.EDU Cc: Moon@SCRC-STONY-BROOK.ARPA, iim%ECLA@ECLC.USC.EDU, cl-cleanup@SAIL.STANFORD.EDU, cl-compiler@SAIL.STANFORD.EDU, common-lisp-object-system@SAIL.STANFORD.EDU Message-Id: <12472023082.5.IIM@ECLA.USC.EDU> The message that prompted this response was sent only to cl-compiler. Since my response touches on issues of more general interest, I've included cl-cleanup and common-lisp-object-system as well. Appologies in advance -- this turned out to be a bit of a tirade. > Date: Tue, 31 Jan 89 05:05:58 PST > From: Jon L White > > > I disagree with the idea of changing the handling for structures. > > Introducing the LOAD-OBJECTS protocol for standard-class instances is fine, > > but structures have been part of the language for a while already and I > > don't see any need to change their handling in an incompatible way. If > > people find that the default handling of structures is not sufficient for > > their needs, that's probably a sign that they really need to use the more > > complex protocol for standard-class objects instead. > > I very much agree with what you say here. Unfortunately, not enough > people objected at the right time -- when the vote on 88-002R was being > taken -- and this "trojan horse" sneaked in to destroy the defstruct > house. [in fact, I wonder how many people actualy read 88-002R before > voting on it?] It's possible that changing the default defstructs to be > CLOS instances will make it smoother for PCL transition; but I don't see > how the incompatible changes to the :PRINT-FUNCTION, :COPIER, and > EQUALP treatment on defstructs helps anyone. > > ... > > Unfortunately, the EQUAL-STRUCTURE amendment that passed at the Hawaii > meeting retracted this very useful action of EQUALP on defstructs, and > rendered it useless again. Hopefully, the final version of the LOAD- > OBJECTS proposal will specify a more useful default behaviour (e.g., > "just like the old CLtL behaviour"?), but note it this will have to > amend the already-passed EQUAL-STRUCTURE proposal. > > -- JonL -- I wish to strongly disagree with almost everything said above. There is a fundamental assumption being made, namely that structures are second-class citizens in the CLOS world. This is most clearly expressed by the statement "If people find that the default handling of structures is not sufficient for their needs, that's probably a sign that they really need to use the more complex protocol for standard-class objects instead." This is terrible! Awful! Totally wrong! Structures have certain restrictions (single inheritance, don't support CHANGE-CLASS, ...) in exchange for potentially very efficient access. When deciding whether to implement a data structure using STRUCTURE-CLASS vs STANDARD-CLASS, the question a programmer should be asking is "does this class need multiple inheritance ...", not "am I ever going to need to dump one of these things, or compare two of them using EQUALP, or ...". Moon keeps pointing out that only the programmers who define/use a class can know how to properly copy, dump, test for equality (whatever equality means), &etc. Unfortunately, under strong pressure from some people he occasionally sounds like he is willing to cave in on this point in the case of structures. Well I won't. Removing structure objects from these kinds of protocols and instead giving them trivial component-wise functionality is utter nonsense. By all means we should give the programmer mechanisms to help him specify that kind of behavior if that is what he wants. But it must be a concious decision, not a default behavior! (As an aside, if it were up to me, the default copier option for defstruct would be Nil.) With regard to the EQUAL-STRUCTURE amendment that passed at the Hawaii meeting, I insisted on EQ for structures because I firmly believe that is the right default. I would still like to see a proposal to make EQUALP a generic function; unfortunately, the group who said they would make such a proposal have not done so. I was thinking about making such a proposal myself, but I've been having trouble with the specification of the hash function, due to some ideas I've been working on with regard to hash-table implementations. kab ------- From Owners-commonloops.pa@Xerox.COM Tue Feb 21 17:27:32 1989 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA13997; Tue, 21 Feb 89 17:27:32 PST Received: from Semillon.ms by ArpaGateway.ms ; 21 FEB 89 14:14:20 PST Return-Path: Redistributed: commonloops.pa Received: from cu-arpa.cs.cornell.edu ([128.84.253.3]) by Xerox.COM ; 21 FEB 89 14:09:30 PST Received: from WRATH.CS.CORNELL.EDU by cu-arpa.cs.cornell.edu (5.61.1/1.91d) id AA20770; Tue, 21 Feb 89 17:09:24 -0500 Received: by wrath.cs.cornell.edu (5.61.1/1.91d) id AA13870; Tue, 21 Feb 89 17:09:17 -0500 Received: by oravax.UUCP (5.51/5.17) id AA10517; Tue, 21 Feb 89 16:08:43 EST Date: Tue, 21 Feb 89 16:08:43 EST From: esrig%oravax@wrath.cs.cornell.edu (Bruce Esrig) Message-Id: <8902212108.AA10517@oravax.UUCP> To: commonloops.pa@Xerox.COM Subject: spurious "defined twice" msgs We are using PCL in conjunction with our own macro-based language extensions which may be causing confusion. The code described below runs fine but there are unexpected messages at compile time. We often get a message reporting a function defined twice in a file. Is this an essential feature of PCL or is it avoidable ? We are using 8/28/88 (beta rev 1) AAAI PCL under Lucid 3.0.1 and Genera 7.1. As an example, on the Symbolics we get: For Function (PCL:METHOD TREEPRINT (STRING)) Function (PCL:METHOD TREEPRINT (STRING)) is defined twice in the file UL1:>... The code contains a number of method definitions for treeprint. For example, (defclass primitive_constant (...) ((p_constant :accessor p_constant ... )) ) (defclass binder_name_or_index (...) ((isl ... )) ) (defmethod treeprint ((x string)) (princ x)) (defmethod treeprint ((prim_constant_term primitive_constant)) (case (p_constant prim_constant_term) ('all ...) ... )) (defmethod-pattern treeprint ((x binder_name_or_index)) (pattern-let x (((binder_name_or_index isl ...)) ...) )) The defmethod-pattern expression is a macro which expands to a defmethod via (defmacro defmethod-pattern (m args &rest forms) `(lisp_plus_eval ( defmethod ,m ,args ,@forms)) ) (defmacro lisp_plus_eval (S-exp) (let ((code (lisp_plus_translate S-exp))) `,code) ) where lisp_plus_translate is a function defined using defun. Lisp_plus_translate is a function from lisp forms to lisp forms which respects the word defmethod, respects the name of the fn, respects the arguments, and reads through the remaining forms to find places where make-instance calls are specified or recursive analysis using the pattern-let keyword is performed. The make-instance calls and pattern-let constructs are expanded in suitable ways and the function returns the form as a whole, starting with '(defmethod ...). Bruce Esrig Odyssey Research Associates esrig%oravax.uucp@cu-arpa.cs.cornell.edu From Common-Lisp-Object-System-mailer@SAIL.STANFORD.EDU Thu Feb 23 13:14:21 1989 Received: from Sail.Stanford.EDU by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA19399; Thu, 23 Feb 89 13:14:21 PST Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 23 Feb 89 13:15:57 PST Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs) id AA23821; Thu, 23 Feb 89 14:14:01 -0700 Received: by defun.utah.edu (5.61/utah-2.0-leaf) id AA10372; Thu, 23 Feb 89 14:13:59 -0700 From: sandra%defun@cs.utah.edu (Sandra J Loosemore) Message-Id: <8902232113.AA10372@defun.utah.edu> Date: Thu, 23 Feb 89 14:13:57 MST Subject: CLOS defining macros & compilation To: cl-compiler@SAIL.STANFORD.EDU, common-lisp-object-system@SAIL.STANFORD.EDU This is an attempt to summarize the problems that have been raised so far about the compilation semantics of the various CLOS defining macros. The descriptions of the expansions of the DEFCLASS, DEFMETHOD, and DEFGENERIC macros in the meta-object protocol document specify that subforms be evaluated at compile-time in the lexical environment in which the defining macro appears, which is not fully defined until run-time. The obvious solution to this problem is to say that the compile-time evaluation happens only when the defining macro call appears at top-level, the same as for all the other defining macros. However, some people have questioned whether compile-time evaluation is even necessary at all, especially in the case of DEFMETHOD and DEFGENERIC. The meta-object protocol does not say anything about whether DEFINE-METHOD-COMBINATION has compile-time side-effects. The CLOS spec assumes that compile-time class and method definitions are made available through a remote lexical environment object. The full implications of this are not well-understood and we have little or no experience with actual implementation. The descriptions of the expansions of the DEFCLASS, DEFMETHOD, and DEFGENERIC macros in the meta-object protocol document assume that lexical environment objects received with &ENVIRONMENT have indefinite extent. Some people have argued that it ought to be legal for environment objects to have only dynamic extent (issue MACRO-ENVIRONMENT-EXTENT). There have also been concerns expressed about how COMPILE-FILE should "clean up" the class structure to remove definitions made during compilation. Now, as to what I suggest we do about all of this. I believe that there are enough serious problems with the compilation semantics presented in the meta-object protocol document distributed before the January meeting that it would be a mistake to try to standardize that behavior. It does not appear that any alternate proposal is forthcoming from the CLOS committee in time for us to make the March 15th deadline (that's less than 3 weeks away, folks). To me it appears that the only practical solution for the near term is a minimal proposal that leaves many aspects of the behavior explicitly vague. (Basically, that DEFCLASS makes the class name recognizable as a valid type name in subsequent declarations, but leaving unspecified whether or not real class, method, etc. objects are fully defined at compile-time.) It may well happen that at some point the MOP compilation semantics will be fixed and the behavior can be specified more tightly, but I don't see any sign of that happening within the next couple of weeks. I think that one of the things we must leave explicitly vague is the use of remote lexical environment objects to contain compile-time definitions. Proposal COMPILE-TIME-HANDLING-OF-TOP-LEVEL-FORMS allows implementations considerable freedom in how other kinds of definitions (DEFMACRO, DEFSTRUCT, etc.) are made available to the compiler; it says only that such definitions *are* made available. Why not do the same thing for the CLOS defining macros? I certainly don't want to discourage people from continuing to pursue the issues involved, but the work seems too experimental yet at the stage to fall into the domain of a standards committee. -Sandra ------- From Common-Lisp-Object-System-mailer@SAIL.STANFORD.EDU Thu Feb 23 15:18:23 1989 Received: from Sail.Stanford.EDU by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA21844; Thu, 23 Feb 89 15:18:23 PST Received: from Sun.COM by SAIL.Stanford.EDU with TCP; 23 Feb 89 15:19:44 PST Received: from snail.Sun.COM by Sun.COM (4.1/SMI-4.0) id AA04040; Thu, 23 Feb 89 15:20:06 PST Received: from suntana.sun.com by snail.Sun.COM (4.1/SMI-4.0) id AA03709; Thu, 23 Feb 89 15:16:36 PST Received: from localhost by suntana.sun.com (4.0/SMI-4.0) id AA18092; Thu, 23 Feb 89 15:17:04 PST Message-Id: <8902232317.AA18092@suntana.sun.com> To: sandra%defun@cs.utah.edu (Sandra J Loosemore) Cc: cl-compiler@SAIL.STANFORD.EDU, common-lisp-object-system@SAIL.STANFORD.EDU Subject: Re: CLOS defining macros & compilation In-Reply-To: Your message of Thu, 23 Feb 89 14:13:57 -0700. <8902232113.AA10372@defun.utah.edu> Date: Thu, 23 Feb 89 15:16:58 PST From: kempf@Sun.COM >vague. (Basically, that DEFCLASS makes the class name recognizable as >a valid type name in subsequent declarations, but leaving unspecified >whether or not real class, method, etc. objects are fully defined at >compile-time.) It may well happen that at some point the MOP This is going to put a crimp in the usual style of OO programming, namely to define classes at the top of a file, then the methods applicable to them thereafter. What you're saying is that this style would be potentially nonportable. jak From Common-Lisp-Object-System-mailer@SAIL.STANFORD.EDU Thu Feb 23 15:30:58 1989 Received: from Sail.Stanford.EDU by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA22083; Thu, 23 Feb 89 15:30:58 PST Received: from lucid.com by SAIL.Stanford.EDU with TCP; 23 Feb 89 15:32:22 PST Received: from challenger ([192.9.200.17]) by heavens-gate.lucid.com id AA00718g; Thu, 23 Feb 89 15:25:39 PST Received: by challenger id AA09808g; Thu, 23 Feb 89 15:21:13 PST Date: Thu, 23 Feb 89 15:21:13 PST From: Patrick Dussud Message-Id: <8902232321.AA09808@challenger> To: kempf@Sun.COM Cc: sandra%defun@cs.utah.edu, cl-compiler@SAIL.STANFORD.EDU, common-lisp-object-system@SAIL.STANFORD.EDU In-Reply-To: kempf@Sun.COM's message of Thu, 23 Feb 89 15:16:58 PST <8902232317.AA18092@suntana.sun.com> Subject: CLOS defining macros & compilation Date: Thu, 23 Feb 89 15:16:58 PST From: kempf@Sun.COM >vague. (Basically, that DEFCLASS makes the class name recognizable as >a valid type name in subsequent declarations, but leaving unspecified >whether or not real class, method, etc. objects are fully defined at >compile-time.) It may well happen that at some point the MOP This is going to put a crimp in the usual style of OO programming, namely to define classes at the top of a file, then the methods applicable to them thereafter. What you're saying is that this style would be potentially nonportable. jak Not necessarily. Flavors classes do not get fully defined at compile time. The compiler notices so much about them so methods can be added to them, and method combination can be executed. The style that we all use and love can me made portable, but what happens in the brain of the compiler, and the CLOS interpreter during a compile-file might not be specified. I think that's what Sandra is proposing. Patrick. From Common-Lisp-Object-System-mailer@SAIL.STANFORD.EDU Thu Feb 23 15:44:55 1989 Received: from Sail.Stanford.EDU by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA22319; Thu, 23 Feb 89 15:44:55 PST Received: from Sun.COM by SAIL.Stanford.EDU with TCP; 23 Feb 89 15:46:19 PST Received: from snail.Sun.COM by Sun.COM (4.1/SMI-4.0) id AA05145; Thu, 23 Feb 89 15:46:48 PST Received: from suntana.sun.com by snail.Sun.COM (4.1/SMI-4.0) id AA04970; Thu, 23 Feb 89 15:43:18 PST Received: from localhost by suntana.sun.com (4.0/SMI-4.0) id AA18162; Thu, 23 Feb 89 15:43:40 PST Message-Id: <8902232343.AA18162@suntana.sun.com> To: Patrick Dussud Cc: kempf@Sun.COM, sandra%defun@cs.utah.edu, cl-compiler@SAIL.STANFORD.EDU, common-lisp-object-system@SAIL.STANFORD.EDU Subject: Re: CLOS defining macros & compilation In-Reply-To: Your message of Thu, 23 Feb 89 15:21:13 -0800. <8902232321.AA09808@challenger> Date: Thu, 23 Feb 89 15:43:37 PST From: kempf@Sun.COM >Not necessarily. Flavors classes do not get fully defined at compile time. The >compiler notices so much about them so methods can be added to them, and method >combination can be executed. The style that we all use and love can me made >portable, but what happens in the brain of the compiler, and the CLOS >interpreter during a compile-file might not be specified. >I think that's what Sandra is proposing. I guess defining the type at compile time would be OK, but I think the spec will have to be changed to allow method definition on the type rather than the class. Technically, the compiler should only need the type and not the class anyway. This might have ramifications, however, so it's best to think it over. jak From Common-Lisp-Object-System-mailer@SAIL.STANFORD.EDU Thu Feb 23 15:48:50 1989 Received: from Sail.Stanford.EDU by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA22459; Thu, 23 Feb 89 15:48:50 PST Received: from ti.com by SAIL.Stanford.EDU with TCP; 23 Feb 89 15:50:12 PST Received: by ti.com id AA10726; Thu, 23 Feb 89 17:49:15 CST Received: from Kelvin by tilde id AA21083; Thu, 23 Feb 89 17:43:00 CST Message-Id: <2813269367-7648607@Kelvin> Sender: GRAY@Kelvin.csc.ti.com Date: Thu, 23 Feb 89 17:42:47 CST From: David N Gray To: sandra%defun@cs.utah.edu (Sandra J Loosemore) Cc: cl-compiler@SAIL.STANFORD.EDU, common-lisp-object-system@SAIL.STANFORD.EDU Subject: Re: CLOS defining macros & compilation In-Reply-To: Msg of Thu, 23 Feb 89 14:13:57 MST from sandra%defun@cs.utah.edu (Sandra J Loosemore) > The descriptions of the expansions of the DEFCLASS, DEFMETHOD, and > DEFGENERIC macros in the meta-object protocol document assume that > lexical environment objects received with &ENVIRONMENT have indefinite > extent. Not really, unless you've noticed something I missed. Some objects in the environment (class definitions in particular) have an extent corresponding to the duration of the invocation of COMPILE-FILE, but the environment objects themselves, as received by a macro, do not need to be used outside the extent of that macro invocation. From Common-Lisp-Object-System-mailer@SAIL.STANFORD.EDU Thu Feb 23 15:57:07 1989 Received: from Sail.Stanford.EDU by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA22535; Thu, 23 Feb 89 15:57:07 PST Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 23 Feb 89 15:57:52 PST Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs) id AA28812; Thu, 23 Feb 89 16:55:49 -0700 Received: by defun.utah.edu (5.61/utah-2.0-leaf) id AA10511; Thu, 23 Feb 89 16:55:46 -0700 From: sandra%defun@cs.utah.edu (Sandra J Loosemore) Message-Id: <8902232355.AA10511@defun.utah.edu> Date: Thu, 23 Feb 89 16:55:45 MST Subject: Re: CLOS defining macros & compilation To: kempf@Sun.COM Cc: sandra%defun@cs.utah.edu (Sandra J Loosemore), cl-compiler@SAIL.STANFORD.EDU, common-lisp-object-system@SAIL.STANFORD.EDU In-Reply-To: kempf@Sun.COM, Thu, 23 Feb 89 15:16:58 PST > Date: Thu, 23 Feb 89 15:16:58 PST > From: kempf@Sun.COM > > This is going to put a crimp in the usual style of OO programming, namely > to define classes at the top of a file, then the methods applicable to > them thereafter. What you're saying is that this style would be > potentially nonportable. That certainly isn't my intent -- I want to legitimize current programming practice while glossing over the details of how it's actually implemented. I can't find any reference in 88-002R to whether classes named as parameter specializers in a DEFMETHOD must be defined before the DEFMETHOD is "evaluated", much less in advance of when the DEFMETHOD is macroexpanded. (It says a parameter specializer is a symbol that names a class.) The MOP document does seem to imply that there must be real class objects defined at compile time, but only so it can create a real method object at compile time. We could put in an explicit statement that classes that appear as DEFMETHOD's parameter specializers must be known at compile time and that compiling a DEFCLASS will make the class name known to the compiler for this purpose. We probably need to say something similar about class names defined by DEFSTRUCT as well, right? We could also put in a statement that DEFCLASS makes the class name known to the compiler so it can appear as a superclass in another DEFCLASS, analogous to the language about the DEFSTRUCT :INCLUDE option in proposal COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS. But 88-002R already says that superclasses don't need to be defined at all if the metaclass is STANDARD-CLASS, so this might be unnecessary. -Sandra ------- From Common-Lisp-Object-System-mailer@SAIL.STANFORD.EDU Thu Feb 23 16:06:31 1989 Received: from Sail.Stanford.EDU by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA22629; Thu, 23 Feb 89 16:06:31 PST Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 23 Feb 89 16:07:39 PST Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs) id AA29059; Thu, 23 Feb 89 17:05:38 -0700 Received: by defun.utah.edu (5.61/utah-2.0-leaf) id AA10531; Thu, 23 Feb 89 17:05:36 -0700 From: sandra%defun@cs.utah.edu (Sandra J Loosemore) Message-Id: <8902240005.AA10531@defun.utah.edu> Date: Thu, 23 Feb 89 17:05:35 MST Subject: Re: CLOS defining macros & compilation To: David N Gray Cc: sandra%defun@cs.utah.edu (Sandra J Loosemore), cl-compiler@SAIL.STANFORD.EDU, common-lisp-object-system@SAIL.STANFORD.EDU In-Reply-To: David N Gray , Thu, 23 Feb 89 17:42:47 CST > Date: Thu, 23 Feb 89 17:42:47 CST > From: David N Gray > > > The descriptions of the expansions of the DEFCLASS, DEFMETHOD, and > > DEFGENERIC macros in the meta-object protocol document assume that > > lexical environment objects received with &ENVIRONMENT have indefinite > > extent. > > Not really, unless you've noticed something I missed. Some objects in > the environment (class definitions in particular) have an extent > corresponding to the duration of the invocation of COMPILE-FILE, but the > environment objects themselves, as received by a macro, do not need to > be used outside the extent of that macro invocation. We all seem to be converging on the idea that compile-time side-effects from macros should be handled by having the macro expand into an (EVAL-WHEN (COMPILE) ...). The MOP document specifies that the environment object be passed as an argument to calls to FIND-CLASS (or whatever) that happen as a compile-time side-effect. This implies that the environment object would have to appear as a quoted constant in the macro expansion. The proposal to give macro environment objects dynamic scope would give them dynamic scope *within the macro function*, which means it would not be legitimate for them to appear at all in the expansion returned from the macro. -Sandra ------- From CL-Compiler-mailer@SAIL.STANFORD.EDU Thu Feb 23 16:56:09 1989 Received: from Sail.Stanford.EDU by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA23379; Thu, 23 Feb 89 16:56:09 PST Received: from ti.com by SAIL.Stanford.EDU with TCP; 23 Feb 89 16:48:49 PST Received: by ti.com id AA11038; Thu, 23 Feb 89 18:48:24 CST Received: from Kelvin by tilde id AA22434; Thu, 23 Feb 89 18:38:13 CST Message-Id: <2813272681-7847725@Kelvin> Sender: GRAY@Kelvin.csc.ti.com Date: Thu, 23 Feb 89 18:38:01 CST From: David N Gray To: Common-Lisp-Object-System@SAIL.STANFORD.EDU Cc: CL-Compiler@SAIL.STANFORD.EDU Subject: remote environments I think it might help to focus the discussion about remote environments and meta object programming if we had a clearer picture of what the goals are. The basic question is what kinds of things can be defined and then used during compilation of the same file that defines them, and what restrictions might apply. DEFCLASS * Can the class be used as a superclass of a later DEFCLASS? [clearly yes] * Can it be used as a specializer in a DEFMETHOD? [clearly yes] * Can a MAKE-INSTANCE be done by a macro expander, DEFCONSTANT, or "#."? - If so, do initforms have access to macros and constants defined earlier in the file? * Can the class be used as the :METACLASS option of a later DEFCLASS? - Can that second class be instantiated? * Can it be used as the :GENERIC-FUNCTION-CLASS option of a DEFGENERIC, GENERIC-FUNCTION, GENERIC-FLET, or GENERIC-LABELS? * Can it be used as the :METHOD-CLASS option of a DEFGENERIC etc.? - Can DEFMETHODs then be done for that generic function? DEFGENERIC * Referenced by later DEFMETHOD? [clearly yes] * Is the function defined such that it can be called at compile time? DEFMETHOD * Can it be invoked at compile-time? * In particular, will methods added to standard generic functions be invoked by the system at compile time? DEFINE-METHOD-COMBINATION * Used in a later DEFGENERIC? - Callable at compile-time? Are there other interactions that need to be considered? I think that the standard could take a simple, minimal, approach that would still satisfy the most common usages. Suppose we said: DEFCLASS If it appears at top-level, then the class name is defined for use as a type specifier or method specializer. It can also be used as a superclass of a later DEFCLASS since they don't have to be defined before being referenced anyway. The class object can be obtained by calling FIND-CLASS with an environment argument, but it can only be used in ways that do not require the class to be finalized. For example, one could ask for its CLASS-DIRECT-SUPERCLASSES, but not its CLASS-PRECEDENCE-LIST. Other uses, which could involve the need to instantiate the class, could not be portably done in the same file without wrapping an (EVAL-WHEN (EVAL COMPILE LOAD) ...) around the DEFCLASS. Implementations would be free to support compile-time instantiation as an extension. One way to look at this would be to say that it is implementation-dependent whether FINALIZE-INHERITANCE works or signals an error when given a class defined in the compile-time environment. DEFGENERIC The attributes of the generic function that affect DEFMETHOD will be recorded for use by definitions of methods for that generic function later in the file. This includes the lambda-list and method class. It is implementation-dependent whether this is actually put in the form of a generic function object and whether other operations on that generic function are possible at compile-time. DEFMETHOD Method definitions are not required to have any compile-time side-effects, but the compiler may warn about things like undefined specializer classes or non-congruent lambda-lists. ADD-METHOD is not invoked at compile-time unless forced by using EVAL-WHEN. DEFINE-METHOD-COMBINATION No compile-time side-effect is required. The new combination can still be referenced in DEFGENERICs and DEFMETHODs later in the file since the definition is not really needed until the generic function is called and an effective method needs to be computed. A compiler could, however, notice what combination names have been defined and issue a warning on a DEFGENERIC with an undefined combination or a DEFMETHOD using an undefined qualifier. From CL-Compiler-mailer@SAIL.STANFORD.EDU Thu Feb 23 17:50:51 1989 Received: from Sail.Stanford.EDU by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA24027; Thu, 23 Feb 89 17:50:51 PST Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 23 Feb 89 17:46:12 PST Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs) id AA01793; Thu, 23 Feb 89 18:44:16 -0700 Received: by defun.utah.edu (5.61/utah-2.0-leaf) id AA10622; Thu, 23 Feb 89 18:44:12 -0700 From: sandra%defun@cs.utah.edu (Sandra J Loosemore) Message-Id: <8902240144.AA10622@defun.utah.edu> Date: Thu, 23 Feb 89 18:44:11 MST Subject: Re: remote environments To: David N Gray Cc: Common-Lisp-Object-System@SAIL.STANFORD.EDU, CL-Compiler@SAIL.STANFORD.EDU In-Reply-To: David N Gray , Thu, 23 Feb 89 18:38:01 CST Thanks for putting together a list of all the questions involved. I can't claim to be an expert on the subject, but perhaps my answers would be useful as a representation of the expectations of a naive user with few preconceived notions. > DEFCLASS > * Can the class be used as a superclass of a later DEFCLASS? [clearly yes] > * Can it be used as a specializer in a DEFMETHOD? [clearly yes] So far, so good. > * Can a MAKE-INSTANCE be done by a macro expander, DEFCONSTANT, or "#."? Probably not. We allow other kinds of definitions seen by the compiler (macros, for example), to be hidden somewhere where they are not visible in these circumstances. If you really want the class to be fully defined at compile time, you should wrap the definition in an (EVAL-WHEN (EVAL COMPILE LOAD)...). > * Can the class be used as the :METACLASS option of a later DEFCLASS? > - Can that second class be instantiated? I'm not sure on this one. I'm inclined to think that users would put the metaclass definition and all its methods off in a separate file anyway, so I don't see any compelling reason to -require- that a class be usable as a metaclass in the same file it is defined in. > * Can it be used as the :GENERIC-FUNCTION-CLASS option of a > DEFGENERIC, GENERIC-FUNCTION, GENERIC-FLET, or GENERIC-LABELS? > * Can it be used as the :METHOD-CLASS option of a DEFGENERIC etc.? > - Can DEFMETHODs then be done for that generic function? I don't know enough about the issues involved here. > DEFGENERIC > * Referenced by later DEFMETHOD? [clearly yes] Right. > * Is the function defined such that it can be called at compile time? I'd have to say no. DEFGENERIC is analagous to DEFUN, and DEFUN only makes the function definition available at load time. > DEFMETHOD > * Can it be invoked at compile-time? > * In particular, will methods added to standard generic functions be > invoked by the system at compile time? No to both questions. > DEFINE-METHOD-COMBINATION > * Used in a later DEFGENERIC? > - Callable at compile-time? I'm not quite sure what all the issues involved are here. I think that I would expect a method combination to be usable later on in the file. To me they seem kind of similar to SETF methods (but maybe that's just a random coincidence). > Are there other interactions that need to be considered? Yes. How about specifying when checks for lambda-list congruence are made for DEFMETHOD? In particular, suppose I have a generic function FOO fully defined in the compilation environment, but a file I'm compiling has a method for FOO with a lambda list that is not congruent. (Maybe I just fixed the file and I want to recompile and reload it.) I think it is reasonable for the compiler to issue a warning but I don't think this is an error or that an error should be signalled -- that should happen only at run time. This would be in keeping with the general philosophy of allowing functions to be freely redefined. -Sandra ------- From Common-Lisp-Object-System-mailer@SAIL.STANFORD.EDU Thu Feb 23 21:02:03 1989 Received: from Sail.Stanford.EDU by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA27315; Thu, 23 Feb 89 21:02:03 PST Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 23 Feb 89 21:03:45 PST Received: from Semillon.ms by ArpaGateway.ms ; 23 FEB 89 20:23:23 PST Date: Thu, 23 Feb 89 20:23 PST From: Gregor.pa@Xerox.COM Subject: CLOS defining macros & compilation To: Sandra J Loosemore Cc: cl-compiler@SAIL.STANFORD.EDU, common-lisp-object-system@SAIL.STANFORD.EDU Fcc: BD:>Gregor>mail>outgoing-mail-5.text.newest In-Reply-To: <8902232113.AA10372@defun.utah.edu> Message-Id: <19890224042316.2.GREGOR@SPIFF.parc.xerox.com> Line-Fold: no Date: Thu, 23 Feb 89 14:13:57 MST From: sandra%defun@cs.utah.edu (Sandra J Loosemore) I believe that there are enough serious problems with the compilation semantics presented in the meta-object protocol document distributed before the January meeting that it would be a mistake to try to standardize that behavior. It does not appear that any alternate proposal is forthcoming from the CLOS committee in time for us to make the March 15th deadline (that's less than 3 weeks away, folks). No one believes that what is written in draft 10 of the MOP is valid. I am certainly sorry if that wasn't communicated to you clearly. A couple of weeks ago I sent a summary analysis to a small group of people familiar with this problem. My message outlines three courses of action to take. Among these is a proposal which, while it is minimal in certain metaobject programming respects, does not restrict ordinary programming. My belief is that resolution of this issue cannot proceed until the EVAL-WHEN issue has been resolved. I have been waiting to see what the resolution would be on the Symbolics EVAL-WHEN proposal. I haven't said anything about it before, but that proposal looks right to me. I believe it has what it would take to implement any of the CLOS behaviors I outlined to the CLOS group. I don't understand how to provide reasonable CLOS semantics with the previous propsal. Once the status of EVAL-WHEN is clear, and I get some more feedback about the message I sent, I will be able to rewrite the relevant part of Chapter 3. That rewrite will cover more than what we want to put in the standard just now, but it will make it clear exactly what the behavior should be. It will give us a precise model with which to decide exactly what how much to put in the standard. Then it should be easy to reduce it to what the compiler committee report should say. ------- From Owners-CommonLoops.PA@Xerox.COM Thu Feb 23 21:43:55 1989 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA28412; Thu, 23 Feb 89 21:43:55 PST Received: from Salvador.ms by ArpaGateway.ms ; 23 FEB 89 16:09:13 PST Return-Path: Redistributed: CommonLoops.PA Received: from cesium ([128.32.156.140]) by Xerox.COM ; 23 FEB 89 16:05:32 PST Received: by cesium (5.57/1.16) id AA04351; Thu, 23 Feb 89 15:51:13 PST Date: Thu, 23 Feb 89 15:51:13 PST From: hcc@cesium.Berkeley.EDU (Norman Hung-Chia Chang) Message-Id: <8902232351.AA04351@cesium> To: CommonLoops.PA@Xerox.COM Subject: Pls. put me in the mail list Thanks. hcc@janus.Berkeley.Edu Norman From Common-Lisp-Object-System-mailer@SAIL.STANFORD.EDU Fri Feb 24 01:55:57 1989 Received: from Sail.Stanford.EDU by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA04388; Fri, 24 Feb 89 01:55:57 PST Received: from lucid.com by SAIL.Stanford.EDU with TCP; 24 Feb 89 01:57:23 PST Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA01286g; Fri, 24 Feb 89 01:43:50 PST Received: by bhopal id AA19679g; Fri, 24 Feb 89 01:46:12 PST Date: Fri, 24 Feb 89 01:46:12 PST From: Jon L White Message-Id: <8902240946.AA19679@bhopal> To: IIM%ECLA@ECLC.USC.EDU Cc: sandra%defun@CS.UTAH.EDU, Moon@SCRC-STONY-BROOK.ARPA, iim%ECLA@ECLC.USC.EDU, cl-cleanup@SAIL.STANFORD.EDU, cl-compiler@SAIL.STANFORD.EDU, common-lisp-object-system@SAIL.STANFORD.EDU In-Reply-To: Kim A. Barrett's message of Sun 19 Feb 89 15:48:59-PST <12472023082.5.IIM@ECLA.USC.EDU> Subject: Issue CONSTANT-COMPILABLE-TYPES re: ... only the programmers who define/use a class can know how to properly copy, dump, test for equality (whatever equality means), &etc. ... Removing structure objects from these kinds of protocols and instead giving them trivial component-wise functionality is utter nonsense. By all means we should give the programmer mechanisms to help him specify that kind of behavior if that is what he wants. But it must be a concious decision, not a default behavior! (As an aside, if it were up to me, the default copier option for defstruct would be Nil.) Kim, don't you have something turned around here? Previous mail referred to CLtL p81 to show that defstruct instances should be descended componentwise by EQUALP. This is not a statement about classes in general -- just about structure-class, and its historic meaning under EQUALP. Thus the Hawaii amendment was an *incompatible* change (which has already raised some question in Lucid's customer land!). This incompatible change unfortunately does nothing at all towards supplying the "mechanisms" you call for, and in fact breaks some existing code (in a very inscrutable way). Given the failure to make EQUALP generic, wouldn't it be far better to leave it alone and not make backwards-incompatible changes which do no one any good? -- JonL -- From Common-Lisp-Object-System-mailer@SAIL.STANFORD.EDU Fri Feb 24 07:53:10 1989 Received: from Sail.Stanford.EDU by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA07794; Fri, 24 Feb 89 07:53:10 PST Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 24 Feb 89 07:54:50 PST Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs) id AA12042; Fri, 24 Feb 89 08:52:52 -0700 Received: by defun.utah.edu (5.61/utah-2.0-leaf) id AA11101; Fri, 24 Feb 89 08:52:49 -0700 From: sandra%defun@cs.utah.edu (Sandra J Loosemore) Message-Id: <8902241552.AA11101@defun.utah.edu> Date: Fri, 24 Feb 89 08:52:48 MST Subject: Re: CLOS defining macros & compilation To: Gregor.pa@Xerox.COM Cc: Sandra J Loosemore , cl-compiler@SAIL.STANFORD.EDU, common-lisp-object-system@SAIL.STANFORD.EDU In-Reply-To: Gregor.pa@Xerox.COM, Thu, 23 Feb 89 20:23 PST > Date: Thu, 23 Feb 89 20:23 PST > From: Gregor.pa@Xerox.COM > > My belief is that resolution of this issue cannot proceed until the > EVAL-WHEN issue has been resolved. I have been waiting to see what the > resolution would be on the Symbolics EVAL-WHEN proposal. I haven't said > anything about it before, but that proposal looks right to me. I > believe it has what it would take to implement any of the CLOS behaviors > I outlined to the CLOS group. I don't understand how to provide > reasonable CLOS semantics with the previous propsal. > > Once the status of EVAL-WHEN is clear, and I get some more feedback > about the message I sent, I will be able to rewrite the relevant part of > Chapter 3. That rewrite will cover more than what we want to put in the > standard just now, but it will make it clear exactly what the behavior > should be. It will give us a precise model with which to decide exactly > what how much to put in the standard. Then it should be easy to reduce > it to what the compiler committee report should say. I think you should go ahead and assume that the Symbolics EVAL-WHEN proposal, or something very much like it, will be accepted. I believe we are all pretty much in agreement with the goals Kent set out. I may still put together an alternate proposal but the changes would be more in the way it's presented than in the semantics. Do you have any idea how long it will take you to do this revision to Chapter 3? My understanding is that it will require truly exceptional circumstances to get anything into the standard after the upcoming meeting. We may need to do this all in parallel instead of series to get things done in time. Thanks for keeping us updated on this. -Sandra ------- From Owners-CommonLoops.pa@Xerox.COM Mon Feb 27 08:43:49 1989 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA24272; Mon, 27 Feb 89 08:43:49 PST Received: from Chardonnay.ms by ArpaGateway.ms ; 27 FEB 89 08:05:08 PST Return-Path: <@CUNYVM.CUNY.EDU:2ELETBONARIN@IPMCC2.POLIMI.IT> Redistributed: CommonLoops.pa Received: from CUNYVM.CUNY.EDU ([128.228.1.2]) by Xerox.COM ; 27 FEB 89 07:59:15 PST Received: from IMICLVX.BITNET by CUNYVM.CUNY.EDU (IBM VM SMTP R1.1) with BSMTP id 9503; Mon, 27 Feb 89 10:58:51 EST Date: Mon, 27 Feb 89 16:49 N From: 2ELETBONARIN@IPMCC2.POLIMI.IT Subject: PCL on HP and Mac To: CommonLoops.pa@Xerox.COM X-Vms-To: ICILVX::IN%"CommonLoops.pa@Xerox.com" Message-Id: <890227-080508-3782@Xerox> We are trying to install PCL on HP 9000-300 with HP Common LIsp 2.01, but the files contained in the distribution kit seems not to be OK. The WALK file does not contain the definition for ENVIRONMENT-MACRO with the HP compiler option. Can anyone help me? WE are trying also to install PCL on a MacII with Allegro, but we have problems when methods are called, obtaining an error related with a method call with NIL arguments. Is it T that PCL runs with Allegro. Has anyone exerienced it? Thank you, Andrea Bonarini From CL-Compiler-mailer@SAIL.STANFORD.EDU Mon Feb 27 08:59:53 1989 Received: from Sail.Stanford.EDU by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA24516; Mon, 27 Feb 89 08:59:53 PST Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 27 Feb 89 08:53:57 PST Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs) id AA20033; Mon, 27 Feb 89 09:52:01 -0700 Received: by defun.utah.edu (5.61/utah-2.0-leaf) id AA00761; Mon, 27 Feb 89 09:51:58 -0700 From: sandra%defun@cs.utah.edu (Sandra J Loosemore) Message-Id: <8902271651.AA00761@defun.utah.edu> Date: Mon, 27 Feb 89 09:51:57 MST Subject: issue COMPILE-ENVIRONMENT-CONSISTENCY To: cl-compiler@SAIL.STANFORD.EDU Cc: common-lisp-object-system@SAIL.STANFORD.EDU I have a new version of this proposal in the works. I've consulted with Kathy Chapman on how to handle the wording problems that were brought up earlier. But, there is still the paragraph that deals with CLOS that some people indicated there were problems with. This is the way it reads now: (h) The compiler may assume that a class name defined by DEFCLASS that is present in the compiletime environment will also be a class name at runtime, and that class will be an instance of the same metaclass. There may be additional conformance requirements imposed by the metaclass, but there are none for STANDARD-CLASS. Would anyone like to suggest some alternate wording? A problem with the existing language that occurs to me is that the previous paragraph of the proposal says that type specifiers introduced with DEFTYPE or DEFCLASS must be defined the same at runtime as at compiletime. The idea is that, if the compiler is allowed to "wire in" type information (by making use of declarations, for example), those types have to fit into the type hierarchy in the same way at runtime as at compiletime. To me it seems like these same considerations must also apply to types introduced by DEFCLASS, regardless of the metaclass involved. -Sandra ------- From Common-Lisp-Object-System-mailer@SAIL.STANFORD.EDU Mon Feb 27 09:48:05 1989 Received: from Sail.Stanford.EDU by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA25150; Mon, 27 Feb 89 09:48:05 PST Received: from ti.com by SAIL.Stanford.EDU with TCP; 27 Feb 89 09:49:36 PST Received: by ti.com id AA22922; Mon, 27 Feb 89 11:49:05 CST Received: from Kelvin by tilde id AA12476; Mon, 27 Feb 89 11:39:29 CST Message-Id: <2813593142-13589117@Kelvin> Sender: GRAY@Kelvin.csc.ti.com Date: Mon, 27 Feb 89 11:39:02 CST From: David N Gray To: David Moon Cc: Common-Lisp-Object-System@SAIL.STANFORD.EDU Subject: Re: Comments on metaobject draft 10 In-Reply-To: Msg of Fri, 17 Feb 89 01:05:53 est from David Moon > 3-50: The ensure-class-using-class generic function should not have > &allow-other-keys in its arglist. Recall that this means that there > should never be any argument checking on calls to this generic function, > which seems unlikely to be what you want. I was assuming that it shouldn't do argument checking at that level in order to permit user-defined metaclasses to extend the set of valid class options. Presumably the SHARED-INITIALIZE method [p. 3-62] will do the necessary error checking, but it would help to have that pointed out on page 3-50. From Common-Lisp-Object-System-mailer@SAIL.STANFORD.EDU Mon Feb 27 09:49:00 1989 Received: from Sail.Stanford.EDU by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA25160; Mon, 27 Feb 89 09:49:00 PST Received: from ti.com by SAIL.Stanford.EDU with TCP; 27 Feb 89 09:50:26 PST Received: by ti.com id AA22940; Mon, 27 Feb 89 11:49:30 CST Received: from Kelvin by tilde id AA12539; Mon, 27 Feb 89 11:41:02 CST Message-Id: <2813593245-13595305@Kelvin> Sender: GRAY@Kelvin.csc.ti.com Date: Mon, 27 Feb 89 11:40:45 CST From: David N Gray To: David Moon Cc: Common-Lisp-Object-System@SAIL.STANFORD.EDU Subject: Re: Comments on metaobject draft 10 In-Reply-To: Msg of Fri, 17 Feb 89 01:05:53 est from David Moon > 3-50: The ensure-class-using-class generic function should not have > &allow-other-keys in its arglist. Recall that this means that there > should never be any argument checking on calls to this generic function, > which seems unlikely to be what you want. I was assuming that it shouldn't do argument checking at that level in order to permit user-defined metaclasses to extend the set of valid class options. Presumably the SHARED-INITIALIZE method [p. 3-62] will do the necessary error checking, but it would help to have that pointed out on page 3-50. From Gregor.pa@Xerox.COM Tue Feb 28 20:57:22 1989 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA01525; Mon, 27 Feb 89 15:30:49 PST Received: from Semillon.ms by ArpaGateway.ms ; 27 FEB 89 15:30:22 PST Date: Mon, 27 Feb 89 15:26 PST From: Gregor.pa@Xerox.COM Subject: patch to 12/7/88 To: CommonLoops.pa@Xerox.COM Fcc: BD:>Gregor>mail>outgoing-mail-5.text.newest Message-Id: <19890227232631.1.GREGOR@SPIFF.parc.xerox.com> Line-Fold: no There is a nasty little bug in optimized slot access in 12/7/88 PCL. This bug probably exists in AAAI PCL as well, I don't have a set of sources to check. This bug manifests itself when: - a method has more than one specialized argument - and slot-value is used on a slot of more than one of the specialized arguments - and either one of the accessed slots is unbound or one of the slots is a :class slot or one of the slots doesn't exist In this case, you can get an error message from slot-value-using-class with a totally random slot name. Here is an example of a method that could have the bug: (defmethod foo ((p position) (r rectangle)) (with-slots (top left width height) r (with-slots (x y) p (setq top y left x) (values top left width height)))) If for example, the X slot of p is unbound, this would signal an error saying that p didn't have a height slot! The following patch fixes this problem. Take a running PCL, edit vector.lisp to have this fix, and compile and load vector. You don't need to use compile-pcl, it would do extra work. This will be installed on arisia shortly. Xerox internal users: I haven't installed this patch anywhere. ;from vector.lisp (defun pv-access-trap (instance offset isl &optional (new-value nil nvp)) (let* ((i 0) (slot-name (block lookup-slot-name (dolist (per-class-slots (cdr isl)) (dolist (slot per-class-slots) (if (= i offset) (return-from lookup-slot-name slot) (incf i))))))) (when (null slot-name) (error "Internal Error:~@ Unable to determine the name of the slot from the PV-OFFSET~@ and the ISL. This results from inconsistency between the~@ PV-OFFSET this access was told to use and the ISL for the~@ method.")) (if nvp (setf (slot-value-using-class (class-of instance) instance slot-name) new-value) (slot-value-using-class (class-of instance) instance slot-name)))) ------- From Owners-CommonLoops.pa@Xerox.COM Wed Mar 1 08:31:11 1989 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA12059; Wed, 1 Mar 89 08:31:11 PST Received: from Chardonnay.ms by ArpaGateway.ms ; 01 MAR 89 07:49:44 PST Return-Path: Redistributed: CommonLoops.pa Received: from Sun.COM ([10.7.0.2]) by Xerox.COM ; 01 MAR 89 07:45:08 PST Received: from snail.Sun.COM by Sun.COM (4.1/SMI-4.0) id AA02444; Wed, 1 Mar 89 07:47:46 PST Received: from suntana.sun.com by snail.Sun.COM (4.1/SMI-4.0) id AA21156; Wed, 1 Mar 89 07:44:12 PST Received: by suntana.sun.com (4.0/SMI-4.0) id AA02438; Wed, 1 Mar 89 07:39:11 PST Date: Wed, 1 Mar 89 07:39:11 PST From: kempf@Sun.COM (James Kempf) Message-Id: <8903011539.AA02438@suntana.sun.com> To: Gregor.pa@Xerox.COM Cc: CommonLoops.pa@Xerox.COM In-Reply-To: Gregor.pa@Xerox.COM's message of Mon, 27 Feb 89 15:26 PST <19890227232631.1.GREGOR@SPIFF.parc.xerox.com> Subject: patch to 12/7/88 Would it be possible to install patches in a patch directory in the future? This would make it possible for people to pick them up in bunches, instead of having to save them piecemeal from email. It would also assure that, if a mail connection got dropped for a couple days, people wouldn't end up missing critical patches. Thanx. jak From Owners-CommonLoops.PA@Xerox.COM Wed Mar 1 14:37:54 1989 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA21611; Wed, 1 Mar 89 14:18:41 PST Received: from Cabernet.ms by ArpaGateway.ms ; 01 MAR 89 14:05:46 PST Return-Path: Redistributed: CommonLoops.PA Received: from PULSAR.FAC.CS.CMU.EDU ([128.2.242.46]) by Xerox.COM ; 01 MAR 89 14:02:56 PST Received: from PULSAR.FAC.CS.CMU.EDU by PULSAR.FAC.CS.CMU.EDU; 1 Mar 89 17:01:52 EST From: Gripe@VEGA.FAC.CS.CMU.EDU Reply-To: Gripe@VEGA.FAC.CS.CMU.EDU To: CommonLoops.PA@Xerox.COM Subject: Unable to deliver mail Date: Wed, 01 Mar 89 17:01:51 EST Message-Id: <11940.604792911@PULSAR.FAC.CS.CMU.EDU> Sender: Ekaterini.Yannoulis@PULSAR.FAC.CS.CMU.EDU ------- Forwarded Message Return-Path: <@PT.CS.CMU.EDU:MAILER-DAEMON@CAD.CS.CMU.EDU> Received: from PT.CS.CMU.EDU by VEGA.FAC.CS.CMU.EDU; 24 Feb 89 21:00:34 EST Received: from CAD.CS.CMU.EDU by PT.CS.CMU.EDU; 24 Feb 89 20:57:55 EST Date: Fri, 24 Feb 89 20:14:19 EST From: MAILER-DAEMON@cad.cs.cmu.edu To: CMU-CommonLoops-Request@PT.CS.CMU.EDU Subject: Unable to deliver mail ----- Transcript of session follows ----- delivermail: ...qmail%mail: stat sig=9,exit=0 ----- Unsent message follows ----- Received: from PT.CS.CMU.EDU by CAD.CS.CMU.EDU; 24 Feb 89 05:28:20 EST Received: from ARISIA.XEROX.COM by PT.CS.CMU.EDU; 24 Feb 89 01:42:18 EST Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA28412; Thu, 23 Feb 89 21:43:55 PST Received: from Salvador.ms by ArpaGateway.ms ; 23 FEB 89 16:09:13 PST Return-Path: Redistributed: CommonLoops.PA Received: from cesium ([128.32.156.140]) by Xerox.COM ; 23 FEB 89 16:05:32 PST Received: by cesium (5.57/1.16) id AA04351; Thu, 23 Feb 89 15:51:13 PST Date: Thu, 23 Feb 89 15:51:13 PST From: hcc@cesium.Berkeley.EDU (Norman Hung-Chia Chang) Message-Id: <8902232351.AA04351@cesium> To: CommonLoops.PA@Xerox.COM Subject: Pls. put me in the mail list Thanks. hcc@janus.Berkeley.Edu Norman ------- End of Forwarded Message From Gregor.pa@Xerox.COM Wed Mar 1 18:45:22 1989 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA25024; Wed, 1 Mar 89 18:45:22 PST Received: from Semillon.ms by ArpaGateway.ms ; 01 MAR 89 18:42:53 PST Date: Wed, 1 Mar 89 18:39 PST From: Gregor.pa@Xerox.COM Subject: Re: patch to 12/7/88 To: James Kempf Cc: CommonLoops.pa@Xerox.COM Fcc: BD:>Gregor>mail>outgoing-mail-5.text.newest In-Reply-To: <8903011539.AA02438@suntana.sun.com> Message-Id: <19890302023934.4.GREGOR@SPIFF.parc.xerox.com> Line-Fold: no I have considered a patch directory for patches. In the past when people have asked for this, they have wanted to have some automatic facility that would load those patches. Problems associated with this automatic facility are what have kept me from doing it. Because of the nature of the PCL system, different patches have to be installed in different ways. Some can simply be loaded after PCL has been loaded, others require recompilation of a single file, still others require recompilation of large parts of the system or even user code. This makes it impractical to do an automatic patch system. If, at this point, you are asking for a place on arisia where all patches that are mailed out get filed that might be possible to do. I fail to see how it could be more convenient, but since I am not at the receiving end of these fixes I may not understand the situation. If that is really what people want, let me know and I will see if Yasuhiko and I can come up with an easy way to do it. ------- From Owners-CommonLoops.pa@Xerox.COM Thu Mar 2 08:33:18 1989 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA06032; Thu, 2 Mar 89 08:33:18 PST Received: from Riesling.ms by ArpaGateway.ms ; 02 MAR 89 07:04:45 PST Return-Path: Redistributed: CommonLoops.pa Received: from DINO.BBN.COM ([128.89.3.8]) by Xerox.COM ; 02 MAR 89 07:03:02 PST To: Gregor.pa@Xerox.COM Cc: James Kempf , CommonLoops.pa@Xerox.COM Subject: Re: patch to 12/7/88 In-Reply-To: Your message of Wed, 01 Mar 89 18:39:00 -0800. <19890302023934.4.GREGOR@SPIFF.parc.xerox.com> Date: Thu, 02 Mar 89 10:05:45 -0500 From: kanderso@DINO.BBN.COM Message-Id: <890302-070445-10137@Xerox> Since you keep the sources on arisia ~up to date relative to patches, we can always get the "best" version by snarfing all the sources. This is fine for people just starting to use PCL, or willing to start over from scratch. BBN and probably also others like Jim, have made patches to PCL in addition to the ones that come over the mailing list. So anytime we try to use a new version of PCL, we must carefully diff the sources and consider each change carefully. Our approach has been to have a pcl-patches.lisp file that has all the patches in it. It is loaded after all of PCL. Patches that can be loaded after PCL are just there in the file. Patches that must be compiled inside PCL are preceeded by #+patched-in-sources in the pcl-patches file and are placed in the PCL sources too. This way, we have all patches in one file which makes moving to a new version of PCL much easier. Having patches in one mail file or directory might be a place to start. That way you could compare the date of the patch to the date you snarfed PCL. k From Owners-CommonLoops.pa@Xerox.COM Thu Mar 2 08:37:16 1989 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA06064; Thu, 2 Mar 89 08:37:16 PST Received: from Salvador.ms by ArpaGateway.ms ; 02 MAR 89 07:04:34 PST Return-Path: Redistributed: CommonLoops.pa Received: from DINO.BBN.COM ([128.89.3.8]) by Xerox.COM ; 02 MAR 89 07:03:12 PST To: Gregor.pa@Xerox.COM Cc: James Kempf , CommonLoops.pa@Xerox.COM Subject: Re: patch to 12/7/88 In-Reply-To: Your message of Wed, 01 Mar 89 18:39:00 -0800. <19890302023934.4.GREGOR@SPIFF.parc.xerox.com> Date: Thu, 02 Mar 89 10:06:51 -0500 From: kanderso@DINO.BBN.COM Message-Id: <890302-070434-10134@Xerox> Since you keep the sources on arisia ~up to date relative to patches, we can always get the "best" version by snarfing all the sources. This is fine for people just starting to use PCL, or willing to start over from scratch. BBN and probably also others like Jim, have made patches to PCL in addition to the ones that come over the mailing list. So anytime we try to use a new version of PCL, we must carefully diff the sources and consider each change carefully. Our approach has been to have a pcl-patches.lisp file that has all the patches in it. It is loaded after all of PCL. Patches that can be loaded after PCL are just there in the file. Patches that must be compiled inside PCL are preceeded by #+patched-in-sources in the pcl-patches file and are placed in the PCL sources too. This way, we have all patches in one file which makes moving to a new version of PCL much easier. Having patches in one mail file or directory might be a place to start. That way you could compare the date of the patch to the date you snarfed PCL. k From Owners-CommonLoops.pa@Xerox.COM Thu Mar 2 10:13:57 1989 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA07469; Thu, 2 Mar 89 10:13:57 PST Received: from Chardonnay.ms by ArpaGateway.ms ; 02 MAR 89 10:09:04 PST Return-Path: Redistributed: CommonLoops.pa Received: from mbunix.mitre.org ([192.12.120.1]) by Xerox.COM ; 02 MAR 89 10:03:33 PST Posted-From: The MITRE Corp., Bedford, MA X-Alternate-Route: user%node@mbunix.mitre.org Return-Path: Received: from faron.mitre.org by linus.MITRE.ORG (5.59/RCF-3S) id AA25109; Thu, 2 Mar 89 13:02:17 EST Posted-Date: Thu, 02 Mar 89 13:02:04 EST Received: by faron.mitre.org (4.12/RCF-3C) id AA19826; Thu, 2 Mar 89 13:02:06 est From: rich@linus.MITRE.ORG Message-Id: <8903021802.AA19826@faron.mitre.org> To: CommonLoops.pa@Xerox.COM Subject: Patches and Symbolics Date: Thu, 02 Mar 89 13:02:04 EST Date: Thu, 02 Mar 89 10:05:45 -0500 From: kanderso@DINO.BBN.COM BBN and probably also others like Jim, have made patches to PCL in addition to the ones that come over the mailing list. So any time we try to use a new version of PCL, we must carefully diff the sources and consider each change carefully. Our approach has been to have a pcl-patches.lisp file that has all the patches in it. It is loaded after all of PCL. Patches that can be loaded after PCL are just there in the file. Here at Mitre we do something similar. We have a system called Mitre-PCL which contains all such patches, plus some home grown enhancements for PCL. It also loads PCL automatically. This has all of the advantages that any patchable system does on a Symbolics, i.e., you can save the pcl system in an incremental world, and then the patches to the system will be loaded automatically when booting. Having patches in one mail file or directory might be a place to start. That way you could compare the date of the patch to the date you snarfed PCL. I vote for this as long as you continue to also put the patches in the original files. Otherwise it would be necessary to "build" PCL if you "snarfed" it late. Our mailer is very flaky right now, and we could avoid missing out on some fixes but checking arisia every once in a while. From Owners-CommonLoops.pa@Xerox.COM Thu Mar 2 12:06:22 1989 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA08935; Thu, 2 Mar 89 12:06:22 PST Received: from Riesling.ms by ArpaGateway.ms ; 02 MAR 89 11:48:52 PST Return-Path: Redistributed: CommonLoops.pa Received: from Sun.COM ([10.7.0.2]) by Xerox.COM ; 02 MAR 89 11:46:07 PST Received: from snail.Sun.COM by Sun.COM (4.1/SMI-4.0) id AA04703; Thu, 2 Mar 89 11:13:20 PST Received: from suntana.sun.com by snail.Sun.COM (4.1/SMI-4.0) id AA16327; Thu, 2 Mar 89 07:39:46 PST Received: by suntana.sun.com (4.0/SMI-4.0) id AA03155; Thu, 2 Mar 89 07:34:44 PST Date: Thu, 2 Mar 89 07:34:44 PST From: kempf@Sun.COM (James Kempf) Message-Id: <8903021534.AA03155@suntana.sun.com> To: Gregor.pa@Xerox.COM Cc: CommonLoops.pa@Xerox.COM In-Reply-To: Gregor.pa@Xerox.COM's message of Wed, 1 Mar 89 18:39 PST <19890302023934.4.GREGOR@SPIFF.parc.xerox.com> Subject: patch to 12/7/88 >If, at this point, you are asking for a place on arisia where all >patches that are mailed out get filed that might be possible to do. I >fail to see how it could be more convenient, but since I am not at the >receiving end of these fixes I may not understand the situation. I think this would be sufficient. It is too much to expect that an automatic patch loading facility for PCL work in everybody's Lisp. The idea is simply to have a place where patches are stored, so people who experience mail interruptions or otherwise lose track of mail on them can periodically update. jak From Owners-CommonLoops.pa@Xerox.COM Thu Mar 2 12:39:52 1989 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA09294; Thu, 2 Mar 89 12:39:52 PST Received: from Salvador.ms by ArpaGateway.ms ; 02 MAR 89 12:33:29 PST Return-Path: Redistributed: CommonLoops.pa Received: from shrike.Austin.Lockheed.COM ([192.31.24.65]) by Xerox.COM ; 02 MAR 89 12:29:27 PST Received: by shrike.Austin.Lockheed.COM (4.0/1.41); Thu, 2 Mar 89 14:26:49 CST Received: by opal.STC.LOCKHEED.COM (3.2/1.27); Thu, 2 Mar 89 14:23:40 CST Received: by frege.STC.LOCKHEED.COM (3.2/1.1); Thu, 2 Mar 89 14:23:38 CST Date: Thu, 2 Mar 89 14:23:38 CST From: Jacky Combs Message-Id: <8903022023.AA03251@frege.STC.LOCKHEED.COM> To: CommonLoops.pa@Xerox.COM Subject: PCL on the VAX I have the following "fixes" for using PCL on a VAX/VMS with VAX Common Lisp. The EXPAND-DCODE-CACHE function should replace the one in the dcode.lisp file prior to compiling PCL. There is still a problem with the generic function representation when printing a description to the screen or when you end up in the debugger, but at least this code will keep you from ending up in an infinite loop. ;;; Modified expand-dcode-cache function for VAX Common Lisp. (defun expand-dcode-cache (generic-function old-cache old-size line-size nkeys next-scan-limit dcode-constructor) (let* ((new-size (* old-size 2)) (new-number-of-lines (floor new-size line-size)) (new-mask (make-wrapper-cache-mask new-number-of-lines)) (new-cache (get-generic-function-cache new-size)) (new-dcode nil) (wrappers ()) (value nil)) (flet ((collect-wrappers (loc) (block collect-wrappers ; need to explicitly create a ; collect-wrappers block for ; VAX Common Lisp in order to do a ; return-from collect-wrappers in the ; following if statement (when (%svref old-cache loc) (setq wrappers ()) (dotimes (i nkeys) (let ((wrapper (%svref old-cache (+ i loc)))) (if (zerop (wrapper-cache-no wrapper)) ;; This wrapper is obsolete, we don't have an instance ;; so there is no related trap. Just drop this line ;; on the floor. (return-from collect-wrappers nil) ; here is the return that ; was causing a problem in ; VAX CL (push wrapper wrappers)))) (setq wrappers (nreverse wrappers) value (and (< nkeys line-size) (%svref old-cache (+ loc nkeys)))) t)))) (flush-generic-function-caches-internal new-cache) (do ((old-location line-size (+ old-location line-size))) ((= old-location old-size)) (when (collect-wrappers old-location) (apply #'dcode-cache-miss generic-function #'(lambda (&rest ignore) (declare (ignore ignore)) value) new-cache new-size new-mask line-size nkeys next-scan-limit nil ;Means don't allow another ;expand while filling the ;new cache. This can only ;happen in one pathological ;case, but prevent it anyways. dcode-constructor wrappers))) (setq new-dcode (funcall dcode-constructor generic-function new-cache)) (setf (generic-function-cache generic-function) new-cache) (install-discriminating-function generic-function new-dcode) (free-generic-function-cache old-cache) new-cache))) ;;; ;;; No methods?? ;;; (defun make-no-methods-dcode (generic-function) #'(lambda (&rest ignore) (declare (ignore ignore)) (error "There are no methods on the generic-function ~S,~%~ so it is an error to call it." generic-function))) ;;; ;;; Default method only is pretty easy. ;;; (defun make-default-method-only-dcode (generic-function) (cddar (generic-function-combined-methods generic-function))) ;;; ;;; Individuals are a total loss. ;;; (defun make-individual-method-dcode (generic-function) #'(lambda (&rest args) (let ((m (apply #'lookup-method-internal generic-function (slot-value--fsc generic-function 'combined-methods) #'car args))) (if m (apply (cddr m) args) (apply #'no-applicable-method generic-function args))))) ;;; ;;; In the case where all the methods on a generic function are either writers ;;; or readers, we can win by pulling the slot-lookup caching that the methods ;;; would do when they are called directly into the discriminator code and its ;;; cache. ;;; For this case, the generic function cache is used as follows: ;;; ;;; ------------------- ;;; . | . | ;;; . | . | ;;; | | ;;; class-i --> | | ;;; index-i --> | 3 | ;;; | | ;;; . | . | ;;; . | . | ;;; | | ;;; class-j --> | | ;;; index-j --> | 1 | ;;; | | ;;; . | . | ;;; . | . | ;;; | | ;;; ------------------- ;;; ;;; It is a one key cache, the keys are the class-wrapper of the ;;; specialized argument. Writer methods only specialize the object ;;; argument. ;;; ;;; ;;; (defvar *all-std-class-accessors-default-number-of-cache-lines* 8) (defvar *all-std-class-accessors-default-cache-mask* *8-cache-mask*) (defvar *all-std-class-accessors-next-scan-limit* 4) (defvar *all-std-class-accessors-max-cache-size* 64) (defun make-all-std-class-readers-dcode (generic-function &optional cache) (let ((cache-size nil) (cache-mask nil)) (if cache (setq cache-size (generic-function-cache-size cache) cache-mask (make-wrapper-cache-mask (floor cache-size 2))) (progn (setq cache-size (* *all-std-class-accessors-default-number-of-cache-lines* 2)) (setq cache-mask *all-std-class-accessors-default-cache-mask*) (setq cache (ensure-generic-function-cache generic-function cache-size)))) (funcall (get-templated-function-constructor 'all-std-class-readers-dcode cache-size cache-mask) generic-function cache *all-std-class-accessors-next-scan-limit*))) (defun make-all-std-class-writers-dcode (generic-function &optional cache) (let ((cache-size nil) (cache-mask nil)) (if cache (setq cache-size (generic-function-cache-size cache) cache-mask (make-wrapper-cache-mask (floor cache-size 2))) (progn (setq cache-size (* *all-std-class-accessors-default-number-of-cache-lines* 2)) (setq cache-mask *all-std-class-accessors-default-cache-mask*) (setq cache (ensure-generic-function-cache generic-function cache-size)))) (funcall (get-templated-function-constructor 'all-std-class-writers-dcode cache-size cache-mask) generic-function cache *all-std-class-accessors-next-scan-limit*))) (define-function-template all-std-class-readers-dcode (cache-size cache-mask) '(.GENERIC-FUNCTION. .CACHE. .NEXT-SCAN-LIMIT.) (let () `(function (lambda (arg) (declare (optimize (speed 3) (safety 0))) (let ((value nil)) (all-std-class-accessors-dcode-internal nil index ,cache-size ,cache-mask #'all-std-class-readers-tertiary-miss #'make-all-std-class-readers-dcode (progn (setq value (%svref (iwmc-class-static-slots arg) index)) (if (eq value ',*slot-unbound*) (go miss) (return-from accessor-dcode value))) (return-from accessor-dcode (slot-value arg index)))))))) (define-function-template all-std-class-writers-dcode (cache-size cache-mask) '(.GENERIC-FUNCTION. .CACHE. .NEXT-SCAN-LIMIT.) (let () `(function (lambda (new-value arg) (declare (optimize (speed 3) (safety 0))) (all-std-class-accessors-dcode-internal t index ,cache-size ,cache-mask #'all-std-class-writers-tertiary-miss #'make-all-std-class-writers-dcode (setf (%svref (iwmc-class-static-slots arg) index) new-value) (setf (slot-value arg index) new-value)))))) (defmacro all-std-class-accessors-dcode-internal (writerp index cache-size cache-mask tertiary-miss dcode-constructor fast-form slow-form) `(block accessor-dcode (macrolet ((r/w-cache-key () '(%svref .CACHE. location)) (r/w-cache-val () '(%svref .CACHE. (%1+ location)))) (let* ((wrapper (and (iwmc-class-p arg) (iwmc-class-class-wrapper arg))) (location 0) (,index nil)) (if (null wrapper) (no-applicable-method .GENERIC-FUNCTION. arg) (with-cache-locked .CACHE. (tagbody (setq location (compute-wrapper-cache-location ,cache-mask 2 wrapper)) (cond ((eq (r/w-cache-key) wrapper) (setq ,index (r/w-cache-val)) (go hit)) (t (setq location (%- (- ,cache-size 2) location)) (cond ((eq (r/w-cache-key) wrapper) (setq ,index (r/w-cache-val)) (go hit)) (t (go miss))))) hit (return-from accessor-dcode ,fast-form) miss (progn (unlock-cache) (setq ,index (dcode-cache-miss .GENERIC-FUNCTION. ,tertiary-miss .CACHE. ,cache-size ,cache-mask 2 ;line size 1 ;nkeys .NEXT-SCAN-LIMIT. (< ,cache-size *all-std-class-accessors-max-cache-size*) ,dcode-constructor wrapper ,@(and writerp '(new-value)) arg)) (cond ((eq ,index '..no-applicable-method..) (return-from accessor-dcode (no-applicable-method .GENERIC-FUNCTION. arg))) ((not (symbolp ,index)) (go hit)) (t (return-from accessor-dcode ,slow-form))))))))))) (defun all-std-class-readers-tertiary-miss (generic-function arg) (let ((method (lookup-method-1 generic-function arg))) (if (null method) '..no-applicable-method.. (let* ((wrapper (wrapper-of arg)) (class (wrapper-class wrapper)) (slot-name (reader/writer-method-slot-name method)) (slot-pos (all-std-class-readers-miss-1 class wrapper slot-name)) (slots (iwmc-class-static-slots arg))) (if (and (not (null slot-pos)) (neq (svref slots slot-pos) *slot-unbound*)) slot-pos slot-name))))) (defun all-std-class-writers-tertiary-miss (generic-function new-value arg) (let ((method (lookup-method-1 generic-function new-value arg))) (if (null method) '..no-applicable-method.. (let* ((wrapper (wrapper-of arg)) (class (wrapper-class wrapper)) (slot-name (reader/writer-method-slot-name method)) (slot-pos (all-std-class-readers-miss-1 class wrapper slot-name))) (if (not (null slot-pos)) slot-pos slot-name))))) (defmethod all-std-class-readers-miss-1 ((class standard-class) wrapper slot-name) (instance-slot-position wrapper slot-name)) (defmacro pre-make-all-std-class-accessor-dcodes (&rest lines) (let ((forms ())) (dolist (nlines lines) (push (pre-make-all-std-class-accessors-1 nlines) forms)) `(progn ,.forms))) (defun pre-make-all-std-class-accessors-1 (nlines) (let ((cache-mask (make-wrapper-cache-mask nlines)) (cache-size (* nlines 2))) `(progn (pre-make-templated-function-constructor all-std-class-readers-dcode ,cache-size ,cache-mask) (pre-make-templated-function-constructor all-std-class-writers-dcode ,cache-size ,cache-mask)))) ;;; ;;; In the case where there is only one method on a generic function, we can ;;; use a cache which has no values, only keys. The existence of a set of ;;; keys in the cache means that that one method is in fact applicable. The ;;; advantage to this kind of cache is that we can save cache space. ;;; (defvar *checking-dcode-default-number-of-cache-lines* 8) (defvar *checking-dcode-default-next-scan-limit* 4) (defvar *checking-dcode-max-cache-size* 256) (defun checking-dcode-default-cache-size (nkeys) (declare (values size mask line-size)) (let* ((nlines *checking-dcode-default-number-of-cache-lines*) (line-size (compute-line-size nkeys)) (cache-size (* nlines line-size))) (values cache-size (case nlines ((8) *8-cache-mask*) ((16) *16-cache-mask*) ((32) *32-cache-mask*) (otherwise (make-wrapper-cache-mask nlines))) line-size))) (defun make-checking-dcode (generic-function &optional cache) (multiple-value-bind (required restp specialized-positions) (compute-discriminating-function-arglist-info generic-function) (let ((nkeys (length specialized-positions)) (cache-size nil) (cache-mask nil) (nlines nil) (line-size nil)) (cond ((null cache) (multiple-value-setq (cache-size cache-mask line-size) (checking-dcode-default-cache-size nkeys)) (setq cache (ensure-generic-function-cache generic-function cache-size))) (t (setq cache-size (generic-function-cache-size cache) line-size (compute-line-size nkeys) nlines (floor cache-size line-size) cache-mask (case nlines ((8) *8-cache-mask*) ((16) *16-cache-mask*) ((32) *32-cache-mask*) (otherwise (make-wrapper-cache-mask nlines)))))) (funcall (get-templated-function-constructor 'checking-dcode required restp specialized-positions cache-size cache-mask line-size) generic-function cache *checking-dcode-default-next-scan-limit* (cddar (generic-function-combined-methods generic-function)))))) (defmacro pre-make-checking-dcode (specs) `(progn ,@(gathering ((forms (collecting))) (dolist (spec specs) (destructuring-bind (required restp specialized-positions . lines) spec (let* ((nkeys (length specialized-positions)) (line-size (compute-line-size nkeys))) (dolist (nlines lines) (let ((size (* nlines line-size)) (mask (make-wrapper-cache-mask nlines))) (gather `(pre-make-templated-function-constructor checking-dcode ,required ,restp ,specialized-positions ,size ,mask ,line-size) forms))))))))) (defun checking-dcode-tertiary-miss (generic-function &rest required-args) (if (not (null (apply #'lookup-method-2 generic-function required-args))) 1 '..no-applicable-method..)) (define-function-template checking-dcode (required restp specialized-positions cache-size cache-mask line-size) '(.GENERIC-FUNCTION. .CACHE. .NEXT-SCAN-LIMIT. .METHOD-FUNCTION.) (let* ((nkeys (length specialized-positions)) (args (gathering ((args (collecting))) (dotimes (i required) (gather (dcode-arg-symbol i) args)))) (wrapper-bindings (gathering ((bindings (collecting))) (dolist (pos specialized-positions) (gather (list (dcode-wrapper-symbol pos) `(wrapper-of-2 ,(nth pos args))) bindings)))) (wrappers (mapcar #'car wrapper-bindings))) (flet ((make-call (fn &rest extra-args) (when (eq fn 'probe) (setq fn '.METHOD-FUNCTION.)) (if restp `(apply ,fn ,@extra-args ,@args rest-arg) `(funcall ,fn ,@extra-args ,@args))) (make-probe (loc) `(and ,@(gathering1 (collecting) (iterate ((wrapper (list-elements wrappers)) (key-no (interval :from 0))) (gather1 `(eq (%svref .CACHE. (%+ ,loc ,key-no)) ,wrapper))))))) `(function (lambda (,@args ,@(and restp '(&rest rest-arg))) (declare (optimize (speed 3) (safety 0))) #+genera-release-7-2 (declare (dbg:invisible-frame :clos-discriminator)) (let ,wrapper-bindings ,(make-caching-dcode-internal #'make-call #'make-probe '#'checking-dcode-tertiary-miss wrappers args cache-size cache-mask line-size nkeys '*checking-dcode-max-cache-size* '#'make-checking-dcode))))))) ;;; ;;; This is the case where there multiple methods. In this case the values ;;; are the actual method function. ;;; (defvar *caching-dcode-default-number-of-cache-lines* 8) (defvar *caching-dcode-default-next-scan-limit* 3) (defvar *caching-dcode-max-cache-size* 256) (defun caching-dcode-default-cache-size (nkeys) (declare (values size mask line-size)) (let* ((nlines *caching-dcode-default-number-of-cache-lines*) (line-size (compute-line-size (1+ nkeys))) (cache-size (* nlines line-size))) (values cache-size (case nlines ((8) *8-cache-mask*) ((16) *16-cache-mask*) ((32) *32-cache-mask*) (otherwise (make-wrapper-cache-mask nlines))) line-size))) (defun make-caching-dcode (generic-function &optional cache) (multiple-value-bind (required restp specialized-positions) (compute-discriminating-function-arglist-info generic-function) (let ((nkeys (length specialized-positions)) (cache-size nil) (cache-mask nil) (nlines nil) (line-size nil)) (cond ((null cache) (multiple-value-setq (cache-size cache-mask line-size) (caching-dcode-default-cache-size nkeys)) (setq cache (ensure-generic-function-cache generic-function cache-size))) (t (setq cache-size (generic-function-cache-size cache) line-size (compute-line-size (1+ nkeys)) nlines (floor cache-size line-size) cache-mask (case nlines ((8) *8-cache-mask*) ((16) *16-cache-mask*) ((32) *32-cache-mask*) (otherwise (make-wrapper-cache-mask nlines)))))) (funcall (get-templated-function-constructor 'caching-dcode required restp specialized-positions cache-size cache-mask line-size) generic-function cache *caching-dcode-default-next-scan-limit*)))) (defmacro pre-make-caching-dcode (specs) `(progn ,@(gathering ((forms (collecting))) (dolist (spec specs) (destructuring-bind (required restp specialized-positions . lines) spec (let* ((nkeys (length specialized-positions)) (line-size (compute-line-size (1+ nkeys)))) (dolist (nlines lines) (let* ((size (* nlines line-size)) (mask (make-wrapper-cache-mask nlines))) (gather `(pre-make-templated-function-constructor caching-dcode ,required ,restp ,specialized-positions ,size ,mask ,line-size) forms))))))))) (defun caching-dcode-tertiary-miss (generic-function &rest required-args) (or (apply #'lookup-method-2 generic-function required-args) '..no-applicable-method..)) (define-function-template caching-dcode (required restp specialized-positions cache-size cache-mask line-size) '(.GENERIC-FUNCTION. .CACHE. .NEXT-SCAN-LIMIT.) (let* ((nkeys (length specialized-positions)) (args (gathering ((args (collecting))) (dotimes (i required) (gather (dcode-arg-symbol i) args)))) (wrapper-bindings (gathering ((bindings (collecting))) (dolist (pos specialized-positions) (gather (list (dcode-wrapper-symbol pos) `(wrapper-of-2 ,(nth pos args))) bindings)))) (wrappers (mapcar #'car wrapper-bindings))) (flet ((make-call (fn &rest extra-args) (if restp `(apply ,fn ,@extra-args ,@args rest-arg) `(funcall ,fn ,@extra-args ,@args))) (make-probe (loc) `(and ,@(gathering1 (collecting) (iterate ((wrapper (list-elements wrappers)) (key-no (interval :from 0))) (gather1 `(eq (%svref .CACHE. (%+ ,loc ,key-no)) ,wrapper)))) (%svref .CACHE. (%+ ,loc ,(length wrappers)))))) `(function (lambda (,@args ,@(and restp '(&rest rest-arg))) (declare (optimize (speed 3) (safety 0))) #+genera-release-7-2 (declare (dbg:invisible-frame :clos-discriminator)) (let ,wrapper-bindings ,(make-caching-dcode-internal #'make-call #'make-probe '#'caching-dcode-tertiary-miss wrappers args cache-size cache-mask line-size nkeys '*caching-dcode-max-cache-size* '#'make-caching-dcode))))))) (defun make-caching-dcode-internal (make-call make-probe tertiary-miss wrappers args cache-size cache-mask line-size nkeys max-cache-size dcode-constructor) `(prog ((probe nil) (location (compute-wrapper-cache-location ,cache-mask ,line-size ,@wrappers))) (with-cache-locked .CACHE. (tagbody (if (setq probe ,(funcall make-probe 'location)) (progn (unlock-cache) (go hit)) (progn (setq location (%- ,(- cache-size line-size) location)) (if (setq probe ,(funcall make-probe 'location)) (progn (unlock-cache) (go hit)) (progn (unlock-cache) (setq probe (dcode-cache-miss .generic-function. ,tertiary-miss .CACHE. ,cache-size ,cache-mask ,line-size ,nkeys .NEXT-SCAN-LIMIT. (< ,cache-size ,max-cache-size) ,dcode-constructor ,@wrappers ,@args)) (if (eq probe '..no-applicable-method..) (return ,(funcall make-call '#'no-applicable-method '.GENERIC-FUNCTION.)) (go hit)))))) hit (return ,(funcall make-call 'probe)))))) ;;; The following is to correct the problem with printing generic function ;;; stuff (setq *print-pretty* t) (setq *print-level* 2) (setq *print-length* 5) (setq *debug-print-level* 2) (setq *debug-print-length* 5) (define-list-print-function system::%compiled-closure% (alist stream) (if (generic-function-p alist) (write (generic-function-name alist) :stream stream) (write alist :stream stream))) ;; For VAX Common Lisp we have to define a different DESCRIBE-INSTANCE function ;; in order to printout the description of a generic function without ;; getting into an infinite loop. (defun describe-instance (object &optional (stream t)) (let* ((class (class-of object)) (slotds (slots-to-inspect class object)) (max-slot-name-length 0) (instance-slotds ()) (class-slotds ()) (other-slotds ())) (flet ((adjust-slot-name-length (name) (setq max-slot-name-length (max max-slot-name-length (length (the string (symbol-name name)))))) (describe-slot (name value &optional (allocation () alloc-p)) (if alloc-p (format stream "~% ~A ~S ~VT ~S" name allocation (+ max-slot-name-length 7) value) (format stream "~% ~A~VT ~S" name max-slot-name-length value)))) ;; Figure out a good width for the slot-name column. (dolist (slotd slotds) ;; VAX Comon Lisp fix - don't print out DISCRIMINATOR-CODE slot, ;; it is a circular list (if (equalp (slotd-name slotd) 'discriminator-code) () (progn (adjust-slot-name-length (slotd-name slotd)) (case (slotd-allocation slotd) (:instance (push slotd instance-slotds)) (:class (push slotd class-slotds)) (otherwise (push slotd other-slotds)))))) (setq max-slot-name-length (min (+ max-slot-name-length 3) 30)) (format stream "~%~S is an instance of class ~S:" object class) (when instance-slotds (format stream "~% The following slots have :INSTANCE allocation:") (dolist (slotd (nreverse instance-slotds)) (describe-slot (slotd-name slotd) (slot-value-or-default object (slotd-name slotd))))) (when class-slotds (format stream "~% The following slots have :CLASS allocation:") (dolist (slotd (nreverse class-slotds)) (describe-slot (slotd-name slotd) (slot-value-or-default object (slotd-name slotd))))) (when other-slotds (format stream "~% The following slots have allocation as shown:") (dolist (slotd (nreverse other-slotds)) (describe-slot (slotd-name slotd) (slot-value-or-default object (slotd-name slotd)) (slotd-allocation slotd)))) (values))))