Received: from Xerox.COM (TCP 1500006350) by AI.AI.MIT.EDU 19 Feb 88 12:45:15 EST Received: from Semillon.ms by ArpaGateway.ms ; 19 FEB 88 09:33:47 PST Return-Path: Redistributed: CommonLoops.PA Received: from uxc.cso.uiuc.edu by Xerox.COM ; 19 FEB 88 09:29:03 PST Received: from ncsa.ncsa.uiuc.edu by uxc.cso.uiuc.edu with SMTP (UIUC-5.52/9.7) id AA16083; Fri, 19 Feb 88 11:28:29 CST Received: from mercury.ncsa.uiuc.edu by ncsa.ncsa.uiuc.edu (3.2/NCSA-1.2) id AA12038; Fri, 19 Feb 88 11:25:56 CST Return-Path: Received: by mercury.ncsa.uiuc.edu (3.2/NCSA-1.2) id AA05200; Fri, 19 Feb 88 11:25:52 CST Date: Fri, 19 Feb 88 11:25:52 CST From: baker@ncsa.uiuc.edu (Polly Baker 2nd signon) Message-Id: <8802191725.AA05200@mercury.ncsa.uiuc.edu> To: CommonLoops.PA@Xerox.COM Subject: Franz compile I'm having problems compiling pcl using Franz Extended CL Version 2.0, on a Sun 3/160. Gets as far as fixup.cl -- Compiling FIXUP... ; --- Compiling file /usr/LISP/franzCL/pcloops/src/fixup.cl --- Continuable Error: EXCL::X should hold an object of type INTEGER. If continued with :continue, prompt for a value to use. [1c] :zo 15 Evaluation stack: ->(EXCL::READ-EVAL-PRINT-LOOP "prompt for a value to use." "EXCL::X should hold an object of type INTEGER." ...) (CERROR "prompt for a value to use." "~s should hold an object of type ~a." ...) (EXCL::LOGAND_2OP # 30) (|.l.a5c5abd7| #) (|(METHOD MAKE-MULTI-METHOD-DCODE (STANDARD-GENERIC-FUNCTION))| #) (|.l.a5c5ab39| #) (COMPUTE-DISCRIMINATOR-CODE-1 #) (|(METHOD COMPUTE-DISCRIMINATOR-CODE (STANDARD-GENERIC-FUNCTION))| #) (|(METHOD UPDATE-DISCRIMINATOR-CODE (STANDARD-GENERIC-FUNCTION))| #) (NOTICE-METHODS-CHANGE-1 #) (NOTICE-METHODS-CHANGE #) (REAL-ADD-METHOD # #) (FIX-EARLY-GENERIC-FUNCTIONS NIL) (EXCL::%EVAL (FIX-EARLY-GENERIC-FUNCTIONS)) (EVAL (FIX-EARLY-GENERIC-FUNCTIONS)) ... 53 more ... Any ideas? Polly Baker baker@p.cs.uiuc.edu  Received: from Xerox.COM (TCP 1500006350) by AI.AI.MIT.EDU 18 Feb 88 13:31:36 EST Received: from Salvador.ms by ArpaGateway.ms ; 18 FEB 88 10:01:48 PST Return-Path: Redistributed: Commonloops.PA Received: from cpswh.cps.msu.EDU by Xerox.COM ; 18 FEB 88 09:59:23 PST Received: from cps45x.cps.msu.edu by cpswh.cps.msu.EDU (3.2/2.2); id AA14450; Thu, 18 Feb 88 12:59:24 EST Return-Path: Received: by cps45x.cps.msu.edu (3.2/SMI-2.0) id AA17412; Thu, 18 Feb 88 12:58:10 EST Date: Thu, 18 Feb 88 12:58:10 EST From: rang%cps45x@cpswh.cps.msu.EDU (Anton Rang) Message-Id: <8802181758.AA17412@cps45x.cps.msu.edu> To: Commonloops.PA@Xerox.COM Subject: PCL on the Explorer I've loaded the newest version of PCL onto our TI Explorer, and it refuses to compile. An error message something like 'NIL is not a function' appears when compiling ITERATE, and from then on anything that uses ITERATE (or DEFMETHOD, I believe--maybe another thing or two) fails with some weird error message ('ITERATE not expanded' or something like that). Is there something I'm doing wrong? Has anyone else run into this problem? Has anyone successfully loaded this version on an Explorer? Anton Rang rang@cpswh.cps.msu.edu  Received: from Xerox.COM (TCP 1500006350) by AI.AI.MIT.EDU 17 Feb 88 16:30:31 EST Received: from Cabernet.ms by ArpaGateway.ms ; 17 FEB 88 13:22:50 PST Return-Path: Redistributed: CommonLoops.pa Received: from EMS.MEDIA.MIT.EDU (EMS.MIT.EDU) by Xerox.COM ; 17 FEB 88 13:20:39 PST Received: by EMS.MEDIA.MIT.EDU (5.54/4.8) id AA04591; Wed, 17 Feb 88 16:19:50 EST Date: Wed, 17 Feb 88 16:19:50 EST From: smh@EMS.MEDIA.MIT.EDU (Steven Haflich) Message-Id: <8802172119.AA04591@EMS.MEDIA.MIT.EDU> To: Gregor.pa@Xerox.COM Cc: CommonLoops.pa@Xerox.COM In-Reply-To: Gregor.pa@xerox.com's message of Tue, 16 Feb 88 12:24 PST <880216122456.7.GREGOR@SPIFF.parc.xerox.com> Subject: state Some clarification: Date: Tue, 16 Feb 88 12:24 PST From: Gregor.pa@xerox.com 1) There is a new version of PCL on parcvax.xerox.com. For people who already have the Valentine's day version all you need to do is copy the methods.lisp file. Other should copy the whole system. This fixes an intermittent garbage collector bug in Franz Lisp. 2) I will be gone for a couple of weeks starting today, so I won't be able to fix any bugs during that time. I spoke with Gregor about this shortly before he left. The problem is not with the gc itself. PCL changes function objects on the fly, and when it modifies a function that is open on the stack, it overwrites information the generation scavenger needs to walk the stack. Anyway, Gregor's change didn't address the real problem. I'm working on the changes necessary to fin.lisp . In Gregor's absence, I'll try to leave the revisions on parcvax for FTP, or if that fails, to post the changed code. In any case, this problem only affects Franz Inc Allecro CL version 2.2 (and 3.0) with the new generation scavenging garbage collector. Version 2.0 is not affected by this problem. Steven Haflich Franz Inc  Received: from Xerox.COM (TCP 1500006350) by AI.AI.MIT.EDU 17 Feb 88 16:30:19 EST Received: from Chardonnay.ms by ArpaGateway.ms ; 17 FEB 88 13:10:31 PST Return-Path: Redistributed: commonloops.pa Received: from EMS.MEDIA.MIT.EDU (EMS.MIT.EDU) by Xerox.COM ; 17 FEB 88 13:07:39 PST Received: by EMS.MEDIA.MIT.EDU (5.54/4.8) id AA04488; Wed, 17 Feb 88 16:05:48 EST Date: Wed, 17 Feb 88 16:05:48 EST From: smh@EMS.MEDIA.MIT.EDU (Steven Haflich) Message-Id: <8802172105.AA04488@EMS.MEDIA.MIT.EDU> To: fritzson@prc.unisys.com Cc: commonloops.pa@Xerox.COM In-Reply-To: Richard Fritzson's message of 15 Feb 88 09:03 EST (Monday) <8802151403.AA14884@bigburd.PRC.Unisys.COM> Subject: Help running PCL under Franz From: fritzson@prc.unisys.com (Richard Fritzson) I'm trying to get PCL to run on our SUN 3/60s under Franz Extended Common Lisp 1.4 (12/18/86 12:33). I can't get through the compile because, in excl-low, in the function definition for set-function-name-1, I get Error: excl::fn_symdef is not a known location specifier for setf. Although excl-low was written for 1.1.2, it has since been changed to track later versions and now is maintained against 2.x . You could try the current pcl with 1.4 if you change just a couple things in your pcl sources. It might or might not work -- I don't have any easy way to test it right now: In excl-low.lisp, just comment out the SET-FUNCTION-NAME-1 definition. In fin.lisp, SET-FUNCALLABLE-INSTANCE-FUNCTION, comment out the setf for FN_SYMDEF and also FN_LOCALS (which is already conditionalized out for VAX). See if these changes get you any further. Steve Haflich Franz Inc  Received: from Xerox.COM (TCP 1500006350) by AI.AI.MIT.EDU 16 Feb 88 17:18:30 EST Received: from Cabernet.ms by ArpaGateway.ms ; 16 FEB 88 14:12:59 PST Return-Path: Redistributed: Commonloops.pa Received: from media-lab.MIT.EDU (media-lab.media.mit.edu) by Xerox.COM ; 16 FEB 88 14:05:12 PST Received: from ouroboros.media.mit.edu by media-lab.MIT.EDU (5.54/4.8) via CHAOS with CHAOS id AA13168; Tue, 16 Feb 88 16:58:56 EST Date: Tue, 16 Feb 88 16:58 EST From: Michael Travers Subject: Bug in walking setq of slot To: Commonloops.pa@Xerox.COM Message-Id: <880216165839.3.MT@OUROBOROS.MEDIA.MIT.EDU> Our most recent version of PCL (which I guess is the Valentine's day version--it was snarfed on the 15th) has a rather bad bug that causes setq of a slot-variable to fail to compile properly. Ie: (defclass thing () (x y)) (defmethod gazork ((a thing) b) (with-slots* (x) a (setq x b))) The gazork method will get compile errors. The following patch seems to fix things in the Symbolics version. ; from PCL:PCL;STD-CLASS pcl:: (defun with-slots-internal (specs form context translate-fn &aux entry) (cond ((not (eq context :eval)) form) ((symbolp form) (if (setq entry (assoc form specs)) (funcall translate-fn (cadr entry)) form)) ((not (listp form)) form) ((member (car form) '(setq setf)) ;; Have to be careful. We must only convert the form to a SETF ;; form when we convert one of the 'logical' variables to a form ;; Otherwise we will get looping in implementations where setf ;; is a macro which expands into setq. (let ((kind (car form))) (labels ((scan-setf (tail) (if (null tail) nil (walker::relist* tail (if (setq entry (assoc (car tail) specs)) (progn (setq kind 'setf) (funcall translate-fn (cadr entry))) (car tail)) (cadr tail) (scan-setf (cddr tail)))))) (let ((set-args (scan-setf (cdr form)))) (walker::recons form kind set-args))))) (t form)))  Received: from Xerox.COM (TCP 1500006350) by AI.AI.MIT.EDU 16 Feb 88 17:18:18 EST Received: from Chardonnay.ms by ArpaGateway.ms ; 16 FEB 88 14:09:40 PST Return-Path: Redistributed: CommonLoops.pa Received: from media-lab.MIT.EDU (media-lab.media.mit.edu) by Xerox.COM ; 16 FEB 88 14:05:33 PST Received: from zaxxon.media.mit.edu by media-lab.MIT.EDU (5.54/4.8) via CHAOS with CHAOS id AA13082; Tue, 16 Feb 88 16:57:07 EST Date: Tue, 16 Feb 88 16:56 EST From: Steve Strassmann Subject: state To: Gregor.pa@Xerox.COM, CommonLoops.pa@Xerox.COM In-Reply-To: <880216122456.7.GREGOR@SPIFF.parc.xerox.com> Message-Id: <880216165645.9.STRAZ@ZAXXON.MEDIA.MIT.EDU> Date: Tue, 16 Feb 88 12:24 PST From: Gregor.pa@xerox.com Subject: state To: CommonLoops.pa@xerox.com 1) There is a new version of PCL on parcvax.xerox.com. For people who already have the Valentine's day version all you need to do is copy the methods.lisp file. Other should copy the whole system. This fixes an intermittent garbage collector bug in Franz Lisp. 1) I just fetched methods.lisp. It has two typos: NOTICE-METHODS-CHANGE-1 refers to GENERIC-FUNCTIO [should be GENERIC-FUNCTION] LOOKUP-METHOD-INTERNAL refers to ORDER, but doesn't use it. 2) It looks like SETQ within WITH-SLOTS* forms are broken. For example, the DEFMETHOD below won't compile in Symbolics rel 7.1: (defclass blort () ((x nil) (y nil)) (:accessor-prefix blort-)) (defmethod zero ((thing blort)) (with-slots* (x y) thing (setq x 0) (setq y 0)))  Received: from Xerox.COM (TCP 1500006350) by AI.AI.MIT.EDU 16 Feb 88 15:37:02 EST Received: from Semillon.ms by ArpaGateway.ms ; 16 FEB 88 12:32:16 PST Date: Tue, 16 Feb 88 12:24 PST From: Gregor.pa@Xerox.COM Subject: state To: CommonLoops.pa@Xerox.COM Fcc: BD:>Gregor>mail>outgoing-mail-1.text Message-ID: <880216122456.7.GREGOR@SPIFF.parc.xerox.com> Line-fold: no Two things: 1) There is a new version of PCL on parcvax.xerox.com. For people who already have the Valentine's day version all you need to do is copy the methods.lisp file. Other should copy the whole system. This fixes an intermittent garbage collector bug in Franz Lisp. 2) I will be gone for a couple of weeks starting today, so I won't be able to fix any bugs during that time. Gregor -------  Received: from Xerox.COM (TCP 1500006350) by AI.AI.MIT.EDU 16 Feb 88 12:47:08 EST Received: from Semillon.ms by ArpaGateway.ms ; 16 FEB 88 09:22:19 PST Return-Path: Redistributed: commonloops.pa Received: from lll-crg.llnl.gov by Xerox.COM ; 16 FEB 88 09:18:49 PST Received: by lll-crg.llnl.gov (5.54/1.14) id AA18687; Tue, 16 Feb 88 09:17:40 PST Date: Tue, 16 Feb 88 09:17:40 PST From: daven@lll-crg.llnl.gov (Dave Nelson) Message-Id: <8802161717.AA18687@lll-crg.llnl.gov> To: commonloops.pa@Xerox.COM Subject: :accessor v. :type ??? Is there something simple I'm missing here? -------TRANSCRIPT HERE------------ (defclass foo () ((x :accessor foo-x))) ;;; no type option here! NIL (setq *foo* (make-instance 'foo)) # (foo-x *foo*) NIL (defclass foo () ((x :accessor foo-x :type symbol))) ;;; redefine slot with :type this time NIL (setq *foo1* (make-instance 'foo)) # (foo-x *foo1*) ;;; and now it can't find the accessor Error: There are no methods on the generic-function #, so it is an error to call it. ----------END OF TRANSCRIPT-------- I tried various variations on the theme, such as ensuring the instance was initialized with a value of the proper type, but the same pattern recurs. Was ist los, hier? David O. Nelson ARPA: daven@lll-crg.arpa | @crg.llnl.gov |- whichever one works THIS week  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 15 Feb 88 20:13:58 EST Date: 15 Feb 88 1705 PST From: Dick Gabriel Subject: SLOT-BOUNDP To: common-lisp-object-system@SAIL.Stanford.EDU I'm glad Pavel is reading the specification CLOSely, because he is a careful reader. As I mentioned, it is difficult to work on a document for over a year and not miss things staring you in the face. A similar remark that Pavel could have made is about the references to Chapter 3 when there is none supplied. SLOT-BOUNDP-USING-CLASS appeared in a skeleton chapter 3 that we circulated briefly. I assume that it will appear in the full blown chapter 3 that Danny and Gregor are writing. If not, we will either need to document that function or else eliminate reference to it. -rpg-  Received: from Xerox.COM (TCP 1500006350) by AI.AI.MIT.EDU 15 Feb 88 20:07:55 EST Received: from Chardonnay.ms by ArpaGateway.ms ; 15 FEB 88 16:56:14 PST Return-Path: Redistributed: commonloops.pa Received: from DREA-XX.ARPA by Xerox.COM ; 15 FEB 88 16:53:41 PST Date: Mon, 15 Feb 88 20:53:02 AST From: Gavin Hemphill Subject: Latest releases vs. Coral Lisp To: commonloops.pa@Xerox.COM cc: hemphill@DREA-XX.ARPA Message-ID: <12375041461.12.HEMPHILL@DREA-XX.ARPA> Is there any magic to getting the later releases (including the Feb 14th one) to compile under Coral/Franz Allegro. The last few releases have all bombed out during the compilation of fixup.lisp -- a call to svref is getting passed illegal args (I don't have the Mac here to get the backtrace etc.). The last version I have that sucessfully compiles is the 1/10/88 version. G++ -------  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 15 Feb 88 20:05:40 EST Date: 15 Feb 88 1701 PST From: Dick Gabriel Subject: Method Combination To: common-lisp-object-system@SAIL.Stanford.EDU The sentence Pavel pointed out should have read: ``For example, if -operator- is OR, the expression is evaluated only if , 1 <= j < i, returned NIL.'' This is a typical error when you've been staring at a chapter for over a year. -rpg-  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 15 Feb 88 19:31:22 EST Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 15 Feb 88 16:26:49 PST Received: from Salvador.ms by ArpaGateway.ms ; 15 FEB 88 16:27:25 PST Date: Mon, 15 Feb 88 16:27:14 PST From: Pavel.pa@Xerox.COM Subject: 88-002 Comment To: Common-Lisp-Object-System@SAIL.Stanford.Edu Message-ID: <880215-162725-2284@Xerox> On page 2-72 of 88-002, the following remark appears: `` The function SLOT-BOUNDP is implemented using SLOT-BOUNDP-USING-CLASS.'' Since SLOT-BOUNDP-USING-CLASS is not described in the document, the usefulness of this remark is lost on me. The same goes for the similar remarks for the functions SLOT-MAKUNBOUND and SLOT-VALUE. Pavel  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 15 Feb 88 18:53:54 EST Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 15 Feb 88 15:48:07 PST Received: from Salvador.ms by ArpaGateway.ms ; 15 FEB 88 15:45:21 PST Date: Mon, 15 Feb 88 15:45:11 PST From: Pavel.pa@Xerox.COM Subject: 88-002 question To: Common-Lisp-Object-System@SAIL.Stanford.Edu Message-ID: <880215-154521-2198@Xerox> On page 1-36 of 88-002, in the description of the simple built-in method combination types, this sentence appears: ``If -operator- is OR, the expression is evaluated only if , 1 <= j < i, returned NIL.'' Why is OR singled out here for a special description? It is not, for example, the only cases that doesn't necessarily evaluate all of the applicable methods (AND may not do so either). It seems like this special case can only serve to confuse the reader. Pavel  Received: from Xerox.COM (TCP 1500006350) by AI.AI.MIT.EDU 15 Feb 88 13:56:29 EST Received: from Chardonnay.ms by ArpaGateway.ms ; 15 FEB 88 09:58:58 PST Return-Path: Redistributed: CommonLoops.PA Received: from Sun.COM by Xerox.COM ; 15 FEB 88 09:54:48 PST Received: from snail.sun.com by Sun.COM (4.0/SMI-3.2) id AA06452; Mon, 15 Feb 88 09:54:37 PST Received: from clam.sun.com by snail.sun.com (4.0/SMI-3.2) id AA15221; Mon, 15 Feb 88 09:46:52 PST Received: by clam.sun.com (3.2/SMI-3.2) id AA10068; Mon, 15 Feb 88 09:55:43 PST Date: Mon, 15 Feb 88 09:55:43 PST From: cperdue@Sun.COM (Cris Perdue) Message-Id: <8802151755.AA10068@clam.sun.com> To: edsel!eb@labrea.Stanford.EDU Subject: Re: make-lexical-environment Cc: CommonLoops.PA@Xerox.COM, cl-cleanup@sail.stanford.edu Just a further note. CLtL, p. 322, does say that the values passed as the last argument to eval hook functions (or apply hook functions) "are suitable for the functions evalhook, applyhook, and macroexpand". This in turn means that these arguments are suitable as the second argument to a macro expander function. (See the discussion of macroexpand.) I guess I don't see anything that implies that all environment objects acceptable to macro expander functions have to be acceptable to evalhook, though the idea is attractive. -Cris  Received: from Xerox.COM (TCP 1500006350) by AI.AI.MIT.EDU 15 Feb 88 12:51:03 EST Received: from Salvador.ms by ArpaGateway.ms ; 15 FEB 88 09:30:38 PST Return-Path: Redistributed: CommonLoops.PA Received: from labrea.Stanford.EDU by Xerox.COM ; 15 FEB 88 09:28:27 PST Received: by labrea.Stanford.EDU; Mon, 15 Feb 88 09:27:51 PST Received: from kent-state.lucid.com by edsel id AA28423g; Mon, 15 Feb 88 09:15:40 PST Received: by kent-state id AA08272g; Mon, 15 Feb 88 09:20:16 PST Date: Mon, 15 Feb 88 09:20:16 PST From: Eric Benson Message-Id: <8802151720.AA08272@kent-state.lucid.com> To: cperdue@sun.com Cc: CommonLoops.PA@Xerox.COM, cl-cleanup@sail.stanford.edu In-Reply-To: Cris Perdue's message of Sun, 14 Feb 88 16:10:03 PST <8802150010.AA09197@clam.sun.com> Subject: make-lexical-environment Redistributed: CommonLoops.PA Date: Sun, 14 Feb 88 16:10:03 PST From: cperdue@sun.com (Cris Perdue) Is the following code adequate for make-lexical-environment (compared with the code in walk.lisp), and if not, is it inadequate for a good reason related to the definition of Common Lisp, or just because implementation quirks of some Lisps? This code is certainly a bit simpler. (defmacro current-env (&environment e) `',e) (defun make-lexical-environment (form env) (evalhook `(,(first form) ,(second form) ; Local macro defns () ; No declarations, though according to the ; PCL comments, they are illegal here. (current-env)) ; body of the macrolet nil nil env)) Thanks for any info on this. -Cris In some Common Lisp implementations, the environments used in EVALHOOK and those used in MACROEXPAND are not compatible. This code would take an existing EVALHOOK environment and return a MACROEXPAND environment. The result could not be passed to EVALHOOK again. Furthermore, some implementations allocate environment objects on the stack, so returning that object from CURRENT-ENV would result in garbage. You are probably correct in your assessment that these are "implementation quirks of some Lisps" and not intrinsic to the Common Lisp standard. The operative phrase in CLtL is "The hook feature is provided as an aid to debugging." EVALHOOK (unlike MACROEXPAND) is part of the programming environment rather than part of the programming language. This issue should be addressed by the cleanup committee.  Received: from Xerox.COM (TCP 1500006350) by AI.AI.MIT.EDU 15 Feb 88 12:50:51 EST Received: from Semillon.ms by ArpaGateway.ms ; 15 FEB 88 09:18:31 PST Date: Mon, 15 Feb 88 09:10 PST From: Gregor.pa@Xerox.COM Subject: make-lexical-environment To: Cris Perdue cc: CommonLoops.PA@Xerox.COM Fcc: BD:>Gregor>mail>outgoing-mail-1.text In-Reply-To: <8802150010.AA09197@clam.sun.com> Message-ID: <880215091013.6.GREGOR@SPIFF.parc.xerox.com> Line-fold: no There are Common Lisps in which this doesn't work right. Even in the ones it does work in it is excessively fragile and prone to breaking from release to release. -------  Received: from Xerox.COM (TCP 1500006350) by AI.AI.MIT.EDU 15 Feb 88 12:50:42 EST Received: from Semillon.ms by ArpaGateway.ms ; 15 FEB 88 08:43:41 PST Return-Path: Redistributed: commonloops.pa Received: from burdvax.PRC.Unisys.COM ([10.5.0.96]) by Xerox.COM ; 15 FEB 88 08:41:03 PST Received: from bigburd.PRC.Unisys.COM by burdvax.PRC.Unisys.COM (burdvax) [5.54/1.0] id AA01785; Mon, 15 Feb 88 09:03:55 EST Received: by bigburd.PRC.Unisys.COM (bigburd) [5.54/1.0] id AA14884; Mon, 15 Feb 88 09:03:52 EST From: fritzson@PRC.Unisys.COM (Richard Fritzson) Message-Id: <8802151403.AA14884@bigburd.PRC.Unisys.COM> Received: from Ringmaster by bigburd.PRC.Unisys.COM with PUP; Mon, 15 Feb 88 09:03 EST To: commonloops.pa@Xerox.COM Date: 15 Feb 88 09:03 EST (Monday) To: commonloops.pa@Xerox.COM Subject: Help running PCL under Franz I'm trying to get PCL to run on our SUN 3/60s under Franz Extended Common Lisp 1.4 (12/18/86 12:33). I can't get through the compile because, in excl-low, in the function definition for set-function-name-1, I get Error: excl::fn_symdef is not a known location specifier for setf. excl::fn_symdef does do what one would expect, e.g. (fn_symdef (symbol-function 'car)) ==> car, but it won't work as a location specifier for setf. I'm accustomed to PCL on the Xerox machines, but not on SUNs. Can someone in the know about Franz Common Lisp tell me if I'm running too old a version (or too new a version? The comment in excl-low says that it was written for excl version 1.1.2.) Thanks. -Rich Fritzson  Received: from Xerox.COM (TCP 1500006350) by AI.AI.MIT.EDU 15 Feb 88 03:28:33 EST Received: from Salvador.ms by ArpaGateway.ms ; 15 FEB 88 00:20:08 PST Return-Path: Redistributed: CommonLoops.PA Received: from Sun.COM by Xerox.COM ; 15 FEB 88 00:18:51 PST Received: from snail.sun.com by Sun.COM (4.0/SMI-3.2) id AA01164; Mon, 15 Feb 88 00:18:41 PST Received: from clam.sun.com by snail.sun.com (4.0/SMI-3.2) id AA06271; Sun, 14 Feb 88 16:01:14 PST Received: by clam.sun.com (3.2/SMI-3.2) id AA09197; Sun, 14 Feb 88 16:10:03 PST Date: Sun, 14 Feb 88 16:10:03 PST From: cperdue@Sun.COM (Cris Perdue) Message-Id: <8802150010.AA09197@clam.sun.com> To: CommonLoops.PA@Xerox.COM Subject: make-lexical-environment Is the following code adequate for make-lexical-environment (compared with the code in walk.lisp), and if not, is it inadequate for a good reason related to the definition of Common Lisp, or just because implementation quirks of some Lisps? This code is certainly a bit simpler. (defmacro current-env (&environment e) `',e) (defun make-lexical-environment (form env) (evalhook `(,(first form) ,(second form) ; Local macro defns () ; No declarations, though according to the ; PCL comments, they are illegal here. (current-env)) ; body of the macrolet nil nil env)) Thanks for any info on this. -Cris  Received: from Xerox.COM (TCP 1500006350) by AI.AI.MIT.EDU 14 Feb 88 19:15:55 EST Received: from Semillon.ms by ArpaGateway.ms ; 14 FEB 88 16:11:23 PST Date: Sun, 14 Feb 88 16:04 PST From: Gregor.pa@Xerox.COM Subject: Questions on new CLOS document To: Scott E. Fahlman cc: CommonLoops.pa@Xerox.COM Fcc: BD:>Gregor>mail>outgoing-mail-1.text In-Reply-To: Message-ID: <880214160423.5.GREGOR@SPIFF.parc.xerox.com> Line-fold: no Date: Sat, 13 Feb 88 22:33 EST From: "Scott E. Fahlman" [ This may not be the right place for queries about the draft CLOS spec itself. Is there a better place to send these? I think that the answer to some of these questions might be of interest to most current PCL users. ] Probably messages like this one should be sent to both the CommonLoops list and the common-lisp-object-system@sail.stanford.edu. That way they will be seen by all the CLOS designers and also by all the current PCL users. It appears that one can no longer do something like (defclass foo () (a b)) (setq inst (make-instance 'foo :a 1 :b 2)) As I read the document, you have to explicitly supply :a and :b as :initarg options in the defclass call if you want to be able to initialize them in Make-Instance. Is that true? I can see the reason for wanting the general initarg mechanism, but was it really necessary to flush the convenient default? This was done for the same reason there isn't a simple option to generate accessors for all the slots. We didn't want to endorse a particular convention for naming initargs. We felt that there were good reasons why a programmer might want to have all their initargs be symbols in the keyword package and also good reasons why they would want them to be symbols in some other package. So it seemed best to require that people specify the initargs one at a time. I don't have it, but several weeks ago Dave Moon sent a message to the CLX mailing list which I remember as providing an excellent description of the motivation for this decision. Second question: I notice that in the new With-Slots call, there is no longer any way to explicitly specify the class to which the instance in question belongs. I note also that With-Slots now is defined as expanding into a bunch of Slot-Value calls. Presumably if you use this form within a method that specifies the class of the instance, you can reasonably expect these Slot-Value calls to produce efficient inline access forms. But what about the case where With-Slots is used somewhere other than in a method? Will those access forms be grossly inefficient because they had to be compiled with no knowledge of the class to which the instance belongs? Is there some way for the user to declare this, or do you just have to avoid with-slots when you're not inside a method? The type declaration can be used to specify the class of (the value of) a variable. Implementations can use these type declarations to optimize these slot-value forms. (let ((pos (get-the-pos))) (declare (type position pos)) (with-slots (x y) pos (list x y))) CLOS provides greater latitude for optimizing calls to slot-value which appear inside of method bodies than it does in other contexts, but I think it is still possible to get high performance slot-value in a context where the class is declared with a type declaration. My expectation is that there would be some overhead on the first call to slot-value which would then not be incurred on subsequent calls. So the code fragment above might not average out so well, but if it had more calls to slot-value in it, the average performance of the calls would approach the best time provided by the given CLOS implementation. The current version of PCL only optimizes calls to slot-value which appear in method bodies. A future version may optimize other calls to slot-value, but it is not clear it will do so in all of its ports. -------  Received: from Xerox.COM (TCP 1500006350) by AI.AI.MIT.EDU 13 Feb 88 22:42:33 EST Received: from Chardonnay.ms by ArpaGateway.ms ; 13 FEB 88 19:36:43 PST Return-Path: Redistributed: CommonLoops.pa Received: from C.CS.CMU.EDU by Xerox.COM ; 13 FEB 88 19:34:18 PST Received: ID ; Sat 13 Feb 88 22:33:56-EST Date: Sat, 13 Feb 88 22:33 EST Message-ID: Sender: FAHLMAN@C.CS.CMU.EDU From: "Scott E. Fahlman" To: CommonLoops.pa@Xerox.COM Cc: fahlman@C.CS.CMU.EDU Subject: Questions on new CLOS document [ This may not be the right place for queries about the draft CLOS spec itself. Is there a better place to send these? I think that the answer to some of these questions might be of interest to most current PCL users. ] I was looking over the draft CLOS spec (my copy says Feb 4 on it), and I have a couple of questions. I'm sure I'll have a lot more questions once I get deeper into this. Anyway... It appears that one can no longer do something like (defclass foo () (a b)) (setq inst (make-instance 'foo :a 1 :b 2)) As I read the document, you have to explicitly supply :a and :b as :initarg options in the defclass call if you want to be able to initialize them in Make-Instance. Is that true? I can see the reason for wanting the general initarg mechanism, but was it really necessary to flush the convenient default? Second question: I notice that in the new With-Slots call, there is no longer any way to explicitly specify the class to which the instance in question belongs. I note also that With-Slots now is defined as expanding into a bunch of Slot-Value calls. Presumably if you use this form within a method that specifies the class of the instance, you can reasonably expect these Slot-Value calls to produce efficient inline access forms. But what about the case where With-Slots is used somewhere other than in a method? Will those access forms be grossly inefficient because they had to be compiled with no knowledge of the class to which the instance belongs? Is there some way for the user to declare this, or do you just have to avoid with-slots when you're not inside a method? I'd be interested in seeing a brief description of which forms can be reasonably efficient and which are inherently inefficient in the new CLOS (and also in the current PCL). -- Scott  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 13 Feb 88 02:24:55 EST Received: from labrea.Stanford.EDU by SAIL.Stanford.EDU with TCP; 12 Feb 88 23:20:34 PST Received: by labrea.Stanford.EDU; Fri, 12 Feb 88 23:21:00 PST Received: from bhopal.lucid.com by edsel id AA19631g; Fri, 12 Feb 88 23:13:20 PST Received: by bhopal id AA13395g; Fri, 12 Feb 88 23:18:18 PST Date: Fri, 12 Feb 88 23:18:18 PST From: Jon L White Message-Id: <8802130718.AA13395@bhopal.lucid.com> To: labrea!Common-Lisp-Object-System%SAIL@labrea.Stanford.EDU In-Reply-To: Jon L White's message of Fri, 12 Feb 88 15:11:26 PST <8802122311.AA12550@bhopal.lucid.com> Subject: Issue: SETF-SUB-METHODS My apologies [nuts! to the mailer] -- this message was intended for the CL-Cleanup mailing list rather than this one. -- JonL --  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 12 Feb 88 18:24:39 EST Received: from labrea.Stanford.EDU by SAIL.Stanford.EDU with TCP; 12 Feb 88 15:16:53 PST Received: by labrea.Stanford.EDU; Fri, 12 Feb 88 15:17:08 PST Received: from bhopal.lucid.com by edsel id AA18146g; Fri, 12 Feb 88 15:06:49 PST Received: by bhopal id AA12550g; Fri, 12 Feb 88 15:11:26 PST Date: Fri, 12 Feb 88 15:11:26 PST From: Jon L White Message-Id: <8802122311.AA12550@bhopal.lucid.com> To: labrea!Common-Lisp-Object-System%SAIL@labrea.Stanford.EDU Subject: Issue: SETF-SUB-METHODS Ken Olum and I [JonL White] have given some thought to the problem that spurred the issue SETF-METHOD-FOR-SYMBOLS, and feel that the issue as stated attacks a small manifestation of the problem rather than the root underlying case. Worse yet, the TEMPORARY-VARIABLE proposal requires a change which creates a bug in another area of SETF usage [see below]. We propose that the problem lies in understanding of how SETF works when the SETF expansion for a form like ( ...) involves the sub-recursive SETF expansion of , or in other words, when the accessing technique isn't fully specified just by looking at the get-setf-method of . The class of such 's is enumerated in CLtL, at the top of p. 96, except that GETF is missing from that list [we propose that it be added there in the next manual]. This message will propose a clarification the issues of left-to-right evaluation in such cases, and will also detail the actions that should be taken by SETF methods on each of these place-types. ! ISSUE: SETF-SUB-METHODS References: CLtL pp. 95-96, 99, 105-106, 166 Issue: PUSH-EVALUATION-ORDER Issue: SETF-METHOD-FOR-SYMBOLS Category: Clarification Edit history: Version 1 JonL & KDO 12-Feb-88 Problem description: Tim Daly of IBM noticed that several implementations do not observe left-to-right order of evaluation in the following form: (setq r '(a 1 b 2 c 3)) (setq s r) (setf (getf r 'b) (progn (setq r nil) 6)) In these implementations, the side-effect of the setq happens before the evaluation of the "subforms" necessary to fetch the list being updated. A typical result is that 'r' = (B 6), 's' = (A 1 B 2 C 3) after the operation. Surely, it should at least be the case that 's' = (A 1 B 6 C 3), since the expectation is that the B property in this list is being (destructively) changed. Similar problems exist with LDB and CHAR-BIT. It is not necessary to clarify that left-to-right order of evaluation semantics should be observed; CLtL p99 is quite explicit about that. Rather, a distinction needs to be made between the computations involved in "evaluation" of the subforms, and other computations that are implicit in the notion of "doing an access" or "doing a store". Proposal: SETF-SUB-METHODS:DELAYED-ACCESS-STORES Elaborate the documentation of SETF, especially in the case of access forms whose sub-forms are permitted to be generalized variable references [and thus which need to call GET-SETF-METHOD during setf macro expansion]. We remember that GET-SETF-METHOD returns the following: Some temporary variables A list of value-producing forms A list of store-variables (normally one). A storing form. An accessing form. Then we want to say that: Code generated using GET-SETF-METHOD does 2 or 3 of the following things: It evaluates the value-producting forms, and binds the temporary variables to them. This will be called "binding the temporaries." It evaluates the accessing form to get the old value of the place. This will be called "doing the access." It binds the store-variable to a new value and calls the storing form to install it in the place. This will be called "doing the store." The forms listed at the top of CLtL p96 permit recursive specifiers; for each one, we will describe how the sub-recursive information from GET-SETF-METHOD is used. LDB: In a form such as (SETF (LDB ) ) the place referred to by the must always be both accessed and updated. Even if the refers to a bignum, the bignum itself will not be modified but rather a new bignum stored in the . Thus this SETF should generate code to do the following: 1. Evaluate 2. Bind the temporaries for 3. Evaluate 4. Do the access to 5. Do the store into with the given bit-field replaced with the value from step 3. If the evaluation of in step 3 sets a different bit-field in the given place then since the access is done later at step 4 this change will be preserved. See ROTATEF example in discussion below. Nevertheless the evaluations required for binding the temporaries are done in step 2, and thus the expected left-to-right evaluation order is seen. GETF: The case of GETF is complicated by the fact that two different "place" locators are involved: one to use if the specified indicator is present in the property list, and another if not. For example, in (SETF (GETF (AREF ... I) 'B) 6), if the I'th slot of the array is NIL, then that slot must be changed, but if it contains a list with the property B then only the cons cell with that property value needs to be changed. This decision cannot be made at macro-expansion time. It depends entirely on the contents of the list in question, and so must be delayed until the last possible moment. More specifically, the expansion of (SETF (GETF ) ) should generate code to do the following: 1. Bind the temporaries for 2. Do the access to [Binding the temporaries and then doing the access is equivalent to evaluating the .] 3. Evaluate [and save the result in a temporary variable]. 4. Check whether the value from 2 has the indicator from 3. If so: 5A. Find cons-cell after indicator from above 6A. Evaluate 7A. RPLACA cons-cell from 5A with value from 6A [In this case, we do not do a store into . When the indicator is already present then the location specifed by doesn't need a new value.] If not: 5B. Evaluate 6B. Do the access to , using the temporaries saved from step 1 [this is not another evaluation -- but it may involve some non trivial computation, depending on how complex the access method really is.]. 7B. Do the store into , again using the temporaries saved from step 1, setting it to a list with indicator from 3, new value from 5B, and old list from 6B. Rationale: As a principle, (setf (foo-a x) (setf (foo-b x) ...)) should always set both of the "slots" of X, even if these slots are implemented as bit-fields, getf-properties, and so on. However, (setf (foo-a x) (setf (foo-a x) ...)) is an error. Current Practice: -- Xerox and Franz already operate on GETF according to this perscription. -- Symbolics and Lucid differ by always doing a setf on the variable rather than updating the appropriate cons cell of the property list; additionally, they fail to connect the new value put into 'r' to the original property list which was 'r's value initially. -- HP updates the cons cell, but then sets the variable 'r' again, nullifying the effect of the "(setq r nil)" in the computation. Adoption cost: Several implementations would require several hours of programmer and documentation time. Cost of non-adoption: Users will think SETF is unnatural in that left-to-right order of evaluation isn't always observed. Benefits: Uniform semantics and portability in the face of recursive "place specifiers" for SETF. Setf of (LDB ... ) and of (GETF ...) will behave uniformly no matter the nature of the . Anyone who has copied examples from p.105 and p.106 will continue to be able to use them. Conversion Cost: This is a clarification of a point not sufficiently elaborated in CLtL. Esthetics: See "Cost of non-adoption" Discussion: In the case that spurred this discussion, (setq r '(a 1 b 2 c 3)) (setq s r) (setf (getf r 'b) (progn (setq r nil) 6)) the consequent update is a RPLACA to some list cell -- not a setf of the variable 'r' -- and thus 'r' should be NIL and 's' should now be (A 1 B 6 C 3). There is an interesting parallel between this case for GETF and the very common mistake made by Lisp programmers with respect to the function DELETE. How often the complaint is filed that DELETE didn't do anything when it should have; but in fact the filer simply forgot that delete can either update some CAR slot of the list originally given it, or return some tail of the list originally give it, but not both! E.g. (setq l '(a a b c d)) ==> (a a b c d) (delete 'a l) ==> (b c d) l ==> (a a b c d) The unwary user thinks that because 'l' is still eq to the original value that "DELETE didn't do anything". The variability of action at runtime here parallels the variable choice of location specifier for (SETF (GETF ...) ...) A previous proposal to fix this problem was misdirected. It was phrased as follows: Proposal: SETF-METHOD-FOR-SYMBOLS:TEMPORARY-VARIABLE Change the result of (get-setf-method 'foo) from NIL NIL (#:G1174) (SETQ FOO #:G1174) FOO to (#:G1175) (FOO) (#:G1174) (SETQ FOO #:G1174) #:G1175 The problem with this is that it breaks a relatively simple client of setf technology: (setq integer #x69) (rotatef (ldb (byte 4 4) integer) (ldb (byte 4 0) integer)) no longer does the "right thing". Using the prescription for setf methods on symbols from CLtL p105, the result of this 'rotatef' is that integer = #x96; using that given by the TEMPORARY-VARIABLE proposal leads to either #x99 [or #x66 depending on which order the implementation chooses to do the actual stores in]. In addition if 'integer' is replaced by '(car x)' here then the behavior is different under the TEMPORARY-VARIABLE proposal because that only applies to symbols. Implicitly, two "places" are being specified here to be updated; but in fact the two places are not independent -- they both involve setq'ing the variable 'integer'. Furthermore, each store operation implicitly requires fetching the value from that place in order to combine it with DPB. It is necessary to delay the accesses until the last moment before combining with DPB in order to see the side-effects of the earlier store operations.  Received: from Xerox.COM (TCP 1500006350) by AI.AI.MIT.EDU 12 Feb 88 11:04:21 EST Received: from Salvador.ms by ArpaGateway.ms ; 12 FEB 88 07:59:47 PST Return-Path: Redistributed: commonloops.PA Received: from nprdc.arpa by Xerox.COM ; 12 FEB 88 07:57:24 PST Received: by nprdc.arpa (5.54/ 1.1) id AA03774; Fri, 12 Feb 88 07:56:43 PST Received: by pacific.ARPA (5.54/4.7) id AA28007; Fri, 12 Feb 88 07:57:19 PST From: stanonik@nprdc.arpa (Ron Stanonik) Message-Id: <8802121557.AA28007@pacific.ARPA> Date: 12 Feb 88 07:56 PST (Friday) To: commonloops.PA@Xerox.COM Subject: kcl and with-slots* with-accessors* Reply-To: stanonik@nprdc.arpa The "beta test release of February 3 1988" omitted the &environment shuffle, required by kcl, when defining with-slots* and with-accessors*. Here are diffs for that. Ron Stanonik stanonik@nprdc.arpa --- std-class.lsp Thu Feb 11 18:55:28 1988 *************** *** 680,688 **** ! (defmacro with-slots* (&whole whole ! slots instance &body body ! &environment env) (let ((gensym (gensym))) (expand-with-slots* whole (mapcar #'(lambda (ss) --- 680,689 ---- ! (defmacro with-slots* #-KCL(&whole whole slots instance &body body ! &environment env) ! #+KCL(&whole whole &environment env ! slots instance &body body) (let ((gensym (gensym))) (expand-with-slots* whole (mapcar #'(lambda (ss) *************** *** 694,702 **** instance #'(lambda (s) `(slot-value ,gensym ',s))))) ! (defmacro with-accessors* (&whole whole ! slot-accessor-pairs instance &body body ! &environment env) (let ((gensym (gensym))) (expand-with-slots* whole slot-accessor-pairs --- 695,705 ---- instance #'(lambda (s) `(slot-value ,gensym ',s))))) ! (defmacro with-accessors* #-KCL(&whole whole ! slot-accessor-pairs instance &body body ! &environment env) ! #+KCL(&whole whole &environment env ! slot-accessor-pairs instance &body body) (let ((gensym (gensym))) (expand-with-slots* whole slot-accessor-pairs ***************  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 12 Feb 88 03:23:23 EST Received: from labrea.Stanford.EDU by SAIL.Stanford.EDU with TCP; 12 Feb 88 00:18:39 PST Received: by labrea.Stanford.EDU; Fri, 12 Feb 88 00:18:41 PST Received: from bhopal.lucid.com by edsel id AA15210g; Fri, 12 Feb 88 00:09:42 PST Received: by bhopal id AA11046g; Fri, 12 Feb 88 00:14:36 PST Date: Fri, 12 Feb 88 00:14:36 PST From: Jon L White Message-Id: <8802120814.AA11046@bhopal.lucid.com> To: masinter.PA@xerox.com Cc: Common-Lisp-Object-System@sail.Stanford.EDU In-Reply-To: masinter.PA@Xerox.COM's message of 11 Feb 88 10:00:26 PST <880211-100052-7099@Xerox> Subject: Status of SETF functions in Common Lisp re: The issue SETF-FUNCTION-VS-SYMBOL was distributed and tentatively approved at the November 1987 meeting of X3J13. The issue name was SETF-FUNCTION-VS-MACRO:SETF-FUNCTIONS It had two parts: (1) Specify that the expansion of SETF is into a function rather than merely into a "macro"; (2) Allow a generalized name for this function. The discussion under this issue is what led to formation of the "definition specs" group. I doubt that anything that comes up under the broader scope could conflict with the minimal assumptions stated in that proposal. In particular, a nomenclature style like (SETF FN) must be acceptable, and #'(SETF FN) will designate the function so named. I certainly remember the overwhelming approval for this direction of extension, but I think the reason it didn't just end with this single proposal is that every place that accepts function names is involved, not just SETF methods. -- JonL --  Received: from Xerox.COM (TCP 1500006350) by AI.AI.MIT.EDU 11 Feb 88 23:24:41 EST Received: from Salvador.ms by ArpaGateway.ms ; 11 FEB 88 20:19:10 PST Return-Path: Redistributed: commonloops.PA Received: from uunet.UU.NET by Xerox.COM ; 11 FEB 88 20:17:27 PST Received: from mcvax.UUCP by uunet.UU.NET (5.54/1.14) with UUCP id AA23920; Thu, 11 Feb 88 23:16:50 EST Received: by mcvax.cwi.nl; Thu, 11 Feb 88 10:01:03 +0100 (MET) Received: from tcom.stc.co.uk by kestrel.Ukc.AC.UK with UUCP id aa09399; 10 Feb 88 18:13 GMT Received: from arran.Tcom.STC.co.UK by arran.Tcom.STC.co.UK (4.12/UK-1.4(stc)); Wed, 10 Feb 88 16:53:17 GMT Received: from mercury.ail.co.uk by ail.co.uk (3.2/SMI-3.2) Received: by mercury.ail.co.uk (3.2/SMI-3.2) id AA00406; Wed, 10 Feb 88 08:27:37 PST Date: Wed, 10 Feb 88 08:27:37 PST From: will Message-Id: <8802101627.AA00406@mercury.ail.co.uk> To: commonloops Subject: proposal for european workshop on pcl/clos We at AI Ltd in England have been making good progress with PCL on xerox machinery.We are interested in making contact with other users of pcl/clos on any hardware with a view to an 'experience sharing ' meeting here in Watford sometime in the late spring/early summer. Any interest? W William Pickles Artificial Intelligence Ltd Intelligence House Greycaine Road Watford Herts WD2 4JP England  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 11 Feb 88 17:43:12 EST Received: from labrea.Stanford.EDU by SAIL.Stanford.EDU with TCP; 11 Feb 88 14:37:14 PST Received: from AI.AI.MIT.EDU by labrea.Stanford.EDU with TCP; Thu, 11 Feb 88 14:35:56 PST Date: Thu, 11 Feb 88 17:36:46 EST From: "Robert W. Kerns" Subject: Comments on most recent draft: Chap 1 and 2 To: edsel!jonl@labrea.stanford.edu Cc: labrea!Common-Lisp-Object-System%SAIL@labrea.stanford.edu, labrea!Moon%STONY-BROOK.SCRC.Symbolics.COM@labrea.stanford.edu, labrea!rwk%ai.ai.mit.edu@labrea.stanford.edu, sun!franz!smh@labrea.stanford.edu In-Reply-To: Msg of Wed 10 Feb 88 00:14:17 PST from Jon L White Message-Id: <325169.880211.RWK@AI.AI.MIT.EDU> Date: Wed, 10 Feb 88 00:14:17 PST From: Jon L White We (this sub-sub-...) have met by conference phone, and discussed what to do; initially Bob Kerns is working on a "definition specs" proposal that will clean up and extend the LispMachine's functions specs somewhat. But we all feel that this is new development -- not just a simple "clarification", or "cleanup" or minor extension to Common Lisp, and more serious thought needs to be given to the question. Most likely there will much discussion about it in Palo Alto next month. Actually, it's Steve Haflick who's writing the proposal; I'm writing the example implementation. We did decide it would be inappropriate for SYMBOL-FUNCTION to take a list as its argument, because the name would be confusing. FUNCTION-DEFINITON is the name I believe we've chosen for the extended version of SYMBOL-FUNCTION. I expect we will have a detailed proposal by the March meeting, but we've obviously missed the deadline for voting on it this time around.  Received: from Xerox.COM (TCP 1500006350) by AI.AI.MIT.EDU 11 Feb 88 15:50:25 EST Received: from Semillon.ms by ArpaGateway.ms ; 11 FEB 88 12:34:47 PST Return-Path: Redistributed: CommonLoops.pa Received: from WILMA.BBN.COM by Xerox.COM ; 11 FEB 88 12:32:21 PST To: CommonLoops.pa@Xerox.COM, 3600-users@WILMA.BBN.COM Cc: kanderson@WILMA.BBN.COM Subject: mv *.lisp *.lsp on unix Date: Thu, 11 Feb 88 15:27:18 -0500 From: kanderso@WILMA.BBN.COM Message-ID: <880211-123447-7440@Xerox> defsys.lisp states: ;;; When you get a copy of PCL (by tape or by FTP), the sources files will ;;; have extensions of ".lisp" in particular, this file will be defsys.lisp. ;;; The preferred way to install pcl is to rename these files to have the ;;; extension which your lisp likes to use for its files. Alternately, it ;;; is possible not to rename the files. If the files are not renamed to ;;; the proper convention, the second line of the following defvar should ;;; be changed to: ;;; (let ((files-renamed-p nil) ;;; ;;; Note: Something people installing PCL on a machine running Unix ;;; might find useful. If you want to change the extensions ;;; of the source files from ".lisp" to ".lsp", *all* you have ;;; to do is the following: ;;; ;;; % foreach i (*.lisp) ;;; ? mv $i $i:r.lsp ;;; ? end ;;; % ;;; ;;; I am sure that a lot of people already know that, and some ;;; Unix hackers may say, "jeez who doesn't know that". Those ;;; same Unix hackers are invited to fix mv so that I can type ;;; "mv *.lisp *.lsp". ;;; This got me thinking and i came up with the following csh hack that i've been using for the past few months. It lets you say things like "bulk mv *.lsp *.lisp" to move a bunch of files or "bulk cmp old/*.lsp new/*.lisp" to compare files. To use it: in your .cshrc file add the line: alias bulk set noglob \; ~/bin/bulk \!\* \; unset noglob in the file ~/bin/bulk put ----- Start ~/bin/bulk ----- : bulk operation source-file-spec [ sink-file-spec ] : example: bulk mv '*.l' '*.lsp' : expand ~ for csh here. source1=`echo "$2" | sed "s/\./\\./g s;^~;$HOME; s;/;\\\\\\/;g s/[*?][*?]*/\\\\\\(.*\\\\\\)/"` source2=`echo "$2" | sed "s;^~;$HOME; s;/;\\\\\\/;g s;[*?][*?]*;\\\\\\1;"` sink=` echo "$3" | sed "s;^~;$HOME; s;/;\\\\\\/;g s/[*?][*?]*/\\\\\\1/"` : csh treats # as a comment echo ls "$2" | $SHELL | sed -n "s/#/\\\\#/g s@$source1@$1 '$source2' $sink@p" | sh -v ----- End ~/bin/bulk ---  Received: from Xerox.COM (TCP 1500006350) by AI.AI.MIT.EDU 11 Feb 88 14:38:02 EST Received: from Semillon.ms by ArpaGateway.ms ; 11 FEB 88 11:17:31 PST Date: Thu, 11 Feb 88 11:10 PST From: Gregor.pa@Xerox.COM Subject: Problem during pcl:compile-pcl on 3600 To: kanderso@WILMA.BBN.COM cc: CommonLoops.pa@Xerox.COM, kanderson@WILMA.BBN.COM Fcc: BD:>Gregor>mail>outgoing-mail-1.text In-Reply-To: The message of 11 Feb 88 04:28 PST from kanderso@WILMA.BBN.COM Message-ID: <880211111010.6.GREGOR@SPIFF.parc.xerox.com> Line-fold: no Date: Thu, 11 Feb 88 07:28:49 -0500 From: kanderso@WILMA.BBN.COM In Symbolics 3640 Compiler in Genera 7.1, IP-TCP 52.16, ... I was simply trying to (pcl:compile-pcl) and this happened during compiling fixup.lisp when evaling FIX-EARLY-GENERIC-FUNCTIONS. My guess is that the loop test in the DOLIST somehow gets the value of GET-CPL-1 rather than METHODS. There are two fixes for this problem. The trivial one is to go to the editor and compile the function lookup-method-internal to core. Whatever bug in the compiler causes this doesn't happen when the function is compiled to core. The more permanent fix is to FTP the new version of the methods.lisp file and use (compile-pcl) to recompile. -------  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 11 Feb 88 13:06:40 EST Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 11 Feb 88 10:01:40 PST Received: from Salvador.ms by ArpaGateway.ms ; 11 FEB 88 10:00:52 PST From: masinter.PA@Xerox.COM Date: 11 Feb 88 10:00:26 PST Subject: Re: Status of SETF functions in Common Lisp In-reply-to: Moon@STONY-BROOK.SCRC.Symbolics.COM's message of Wed, 10 Feb 88 11:57 EST, <19880210165749.0.MOON@EUPHRATES.SCRC.Symbolics.COM> To: David A. Moon cc: Jon L White , Common-Lisp-Object-System@SAIL.STANFORD.EDU, sun!franz!smh@labrea.Stanford.EDU, rwk@AI.AI.MIT.EDU, CL-Cleanup@SAIL.STANFORD.EDU Message-ID: <880211-100052-7099@Xerox> I've been out with the flu since last Friday afternoon (I thought it was just jet lag...) The issue SETF-FUNCTION-VS-SYMBOL was distributed and tentatively approved at the November 1987 meeting of X3J13. The larger question of generalizing this beyond SETF functions, and beyond merely DEFUN and FLET, seemed like it was open for another, larger, more comprehensive proposal. I'm still at home today and don't have easy access to all of the files. I'm hoping I am not too late to get the mailing out for X3J13 of all of the new issues.  Received: from Xerox.COM (TCP 1500006350) by AI.AI.MIT.EDU 11 Feb 88 07:50:27 EST Received: from Semillon.ms by ArpaGateway.ms ; 11 FEB 88 04:39:12 PST Return-Path: Redistributed: CommonLoops.pa Received: from WILMA.BBN.COM by Xerox.COM ; 11 FEB 88 04:36:26 PST To: CommonLoops.pa@Xerox.COM Cc: kanderson@WILMA.BBN.COM Subject: Problem during pcl:compile-pcl on 3600 Date: Thu, 11 Feb 88 07:28:49 -0500 From: kanderso@WILMA.BBN.COM Message-ID: <880211-043912-6754@Xerox> In Symbolics 3640 Compiler in Genera 7.1, IP-TCP 52.16, BBN site system 2.6, Color Support 11.4, Color 331.5, Color Editor 313.0, Fortran 6.27, Graph 13.0, Scientific Graphs 6.3, Window Support 10.1, Essential Window Support 9.2, PCI Data Loaded. 9.0, One More Nice Inheritance System for PCI 6.0, PCI Data-Loading Essentials. 1.0, Experimental Ken Anderson's Initial Environment 7, microcode 3640-FPA-MIC 396, FEP 127, fep0:>v127-lisp.flod(55), fep0:>v127-loaders.flod(55), fep0:>v127-debug.flod(34), fep0:>v127-info.flod(55), Machine serial number 4146, on Rhythm & Blues: I was simply trying to (pcl:compile-pcl) and this happened during compiling fixup.lisp when evaling FIX-EARLY-GENERIC-FUNCTIONS. My guess is that the loop test in the DOLIST somehow gets the value of GET-CPL-1 rather than METHODS. (labels ((get-class-1 (i a) (setf (svref classes i) (class-of a))) (get-cpl-1 (i a) (setf (svref cpls i) (slot-value--class (get-class i a) 'class-precedence-list)))) (dolist (method methods) (setq specializers (funcall key method)) Any suggestions? k Trap: The argument given to the SYS:BRANCH-ENDP instruction, #, was not a list, or NIL. While in the function LOOKUP-METHOD-INTERNAL  LOOKUP-METHOD-2  (:INTERNAL (:INTERNAL #:G13898 0) 0) The condition signalled was DBG:WRONG-TYPE-ARGUMENT-TRAP LOOKUP-METHOD-INTERNAL: (P.C. = 427) (from WILMA:/usr/kcl/pcl/new/methods.lsp) Arg 0 (GENERIC-FUNCTION): # Arg 1 (METHODS): (((#) . #)) Arg 2 (KEY): # Rest arg (ARGS): (#) Local 4: # Local 5: # Local 6: # Local 7: # Local 8 (ORDER): :DEFAULT Local 9 (CPLS): # Local 10 (CLASSES): # Local 11 (MOST-SPECIFIC-METHOD): NIL Local 12 (MOST-SPECIFIC-SPECIALIZERS): NIL Local 13 (SPECIALIZERS): NIL Local 14 (.GET-CLASS-1-FUNCTION-CELL.): 1 Local 15 (.GET-CPL-1-FUNCTION-CELL.): # Local 16: # Local 17 (METHOD): (((#) . #)) Special SYS:INHIBIT-SCHEDULING-FLAG: T LOOKUP-METHOD-2: (P.C. = 240) (from WILMA:/usr/kcl/pcl/new/methods.lsp) Arg 0 (GENERIC-FUNCTION): # Rest arg (ARGS): (#) (:INTERNAL (:INTERNAL #:G13898 0) 0): (P.C. = 127) Arg 0 (COMPILER:.LEXICAL-ENVIRONMENT-POINTER.): (# # NIL NIL NIL NIL NIL NIL NIL NIL ...) Arg 1: # (METHOD MAKE-MULTI-METHOD-DCODE (STANDARD-GENERIC-FUNCTION)): (P.C. = 3) Arg 0 (SELF): # (:INTERNAL FIX-EARLY-GENERIC-FUNCTIONS 1 TRAMPOLINE): (P.C. = 6) Arg 0 (COMPILER:.LEXICAL-ENVIRONMENT-POINTER.): (#) Rest arg (ARGS): (#) COMPUTE-DISCRIMINATOR-CODE-1: (P.C. = 144) (from WILMA:/usr/kcl/pcl/new/methods.lsp) Arg 0 (GENERIC-FUNCTION): # (METHOD COMPUTE-DISCRIMINATOR-CODE (STANDARD-GENERIC-FUNCTION)): (P.C. = 3) Arg 0 (GENERIC-FUNCTION): # (:INTERNAL MAKE-TRAMPOLINE 0): (P.C. = 5) Arg 0 (COMPILER:.LEXICAL-ENVIRONMENT-POINTER.): (# NIL NIL NIL NIL NIL NIL NIL NIL NIL ...) Rest arg (ARGS): (#) (METHOD UPDATE-DISCRIMINATOR-CODE (STANDARD-GENERIC-FUNCTION)): (P.C. = 4) Arg 0 (GENERIC-FUNCTION): # (:INTERNAL MAKE-TRAMPOLINE 0): (P.C. = 5) Arg 0 (COMPILER:.LEXICAL-ENVIRONMENT-POINTER.): (# NIL NIL NIL NIL NIL NIL NIL NIL NIL ...) Rest arg (ARGS): (#) NOTICE-METHODS-CHANGE-1: (P.C. = 7) (from WILMA:/usr/kcl/pcl/new/methods.lsp) Arg 0 (GENERIC-FUNCTION): # NOTICE-METHODS-CHANGE: (P.C. = 16) (from WILMA:/usr/kcl/pcl/new/methods.lsp) Arg 0: # REAL-ADD-METHOD: (P.C. = 46) (from WILMA:/usr/kcl/pcl/new/methods.lsp) Arg 0 (GENERIC-FUNCTION): # Arg 1 (METHOD): # FIX-EARLY-GENERIC-FUNCTIONS: (P.C. = 155) (from WILMA:/usr/kcl/pcl/new/boot.lsp) --Defaulted args:-- Arg 0 (NOISYP): NIL (:INTERNAL COMPILER:COMPILE-PROCESS-DEFAULT 0 (:EVAL-FORM)): (P.C. = 3) Arg 0 (SI:**DEFSELECT-OP**): :EVAL-FORM Arg 1 (SYS:FORM): (FIX-EARLY-GENERIC-FUNCTIONS) COMPILER:COMPILE-PROCESS-DEFAULT: (P.C. = 15) Arg 0 (SI:OPERATION): :EVAL-FORM Rest arg (SI:SELECT-METHOD-ARGS): ((FIX-EARLY-GENERIC-FUNCTIONS)) Local 1 (SI:SELECT-METHOD-ARGS): NIL COMPILER:COMPILE-TO-FILE: (P.C. = 121) Arg 0 (SI:OPERATION): :EVAL-FORM Rest arg (SI:SELECT-METHOD-ARGS): ((FIX-EARLY-GENERIC-FUNCTIONS)) COMPILER:COMPILE-FORM-FUNCTION: (P.C. = 22) Arg 0 (SYS:FORM): (FIX-EARLY-GENERIC-FUNCTIONS) Arg 1 (COMPILER:COMPILE-TIME-P): :FORCE Arg 2 (COMPILER:LOAD-TIME-P): T COMPILER:COMPILE-FROM-STREAM-1: (P.C. = 473) (from WILMA:/usr/kcl/pcl/new/rel-7-patches.lsp) Arg 0 (SYS:FORM): (FIX-EARLY-GENERIC-FUNCTIONS) Arg 1 (COMPILER:COMPILE-TIME-TOO): :FORCE COMPILER:COMPILE-FROM-STREAM-1: (P.C. = 140) (from WILMA:/usr/kcl/pcl/new/rel-7-patches.lsp) Arg 0 (SYS:FORM): (EVAL-WHEN (COMPILE LOAD EVAL) (FIX-EARLY-GENERIC-FUNCTIONS)) --Defaulted args:-- Arg 1 (COMPILER:COMPILE-TIME-TOO): NIL COMPILER:PROCESS-FORMS-FROM-STREAM: (P.C. = 115) Arg 0 (COMPILER:INPUT-STREAM): # Arg 1 (COMPILER:PROCESS-FUNCTION): COMPILER:COMPILE-FROM-STREAM-1 Arg 2 (COMPILER:FOR-FILE): T Arg 3 (COMPILER:AREA-FOR-READING): 4 COMPILER:COMPILE-FROM-STREAM: (P.C. = 231) Arg 0 (COMPILER:INPUT-STREAM): # Arg 1 (COMPILER:GENERIC-PATHNAME): #P"WILMA:/usr/kcl/pcl/new/fixup.lsp" Arg 2: COMPILER:COMPILE-TO-FILE Arg 3 (COMPILER:ADDITIONAL-BINDINGS): NIL COMPILER:COMPILE-FILE: (P.C. = 233) Arg 0 (COMPILER:INFILE): #P"WILMA:/usr/kcl/pcl/new/fixup.lsp" Arg 1 (COMPILER:OUTFILE): #P"CONGER:>pcl>880207>FIXUP.BIN" Local 1 (COMPILER:OUTFILE): #P"CONGER:>pcl>880207>FIXUP.BIN.newest" Arg 2 (COMPILER:IN-PACKAGE): NIL Arg 3 (COMPILER:DONT-SET-DEFAULT-P): NIL COMPILE-FILE: (P.C. = 40) Arg 0 (CLI::INPUT-FILE): #P"WILMA:/usr/kcl/pcl/new/fixup.lsp" Rest arg: (:OUTPUT-FILE #P"CONGER:>pcl>880207>FIXUP.BIN") (:INTERNAL OPERATE-ON-SYSTEM 3 COMPILE-MODULE): (P.C. = 20) Arg 0 (COMPILER:.LEXICAL-ENVIRONMENT-POINTER.): # Arg 1 (M): # OPERATE-ON-SYSTEM: (P.C. = 246) (from CONGER:>pcl>880207>defsys) Arg 0 (NAME): PCL Arg 1 (MODE): :COMPILE --Defaulted args:-- Arg 2: NIL Arg 3 (PRINT-ONLY): NIL COMPILE-PCL: (P.C. = 7) (from CONGER:>pcl>880207>defsys) --Defaulted args:-- Arg 0 (M): NIL CP::COMMAND-LOOP-EVAL-FUNCTION: (P.C. = 25) Arg 0 (CP::FORM): (COMPILE-PCL) (FLAVOR:METHOD SI:WITH-PROCESS-NON-INTERACTIVE-PRIORITY-INTERNAL SI:PROCESS): (P.C. = 43) Arg 0 (SCL:SELF): # Arg 1 (SYS:SELF-MAPPING-TABLE): SI:PROCESS Arg 2 (FLAVOR::.GENERIC.): # Arg 3 (SI:CONTINUATION): # Rest arg: NIL TV:WITH-NOTIFICATION-MODE-INTERNAL: (P.C. = 15) Arg 0 (TV:NEW-MODE): :BLAST Arg 1 (TV:STREAM): #:TERMINAL-IO-SYN-STREAM Arg 2 (TV:CONTINUATION): # (FLAVOR:METHOD SI:WITH-PROCESS-INTERACTIVE-PRIORITY-INTERNAL SI:PROCESS): (P.C. = 40) Arg 0 (SCL:SELF): # Arg 1 (SYS:SELF-MAPPING-TABLE): SI:PROCESS Arg 2 (FLAVOR::.GENERIC.): # Arg 3 (SI:CONTINUATION): # Rest arg: NIL SI:LISP-COMMAND-LOOP-INTERNAL: (P.C. = 27) Arg 0 (SI:NAME): "Lisp Top Level" Arg 1 (SI:ABORT-FUNCTION): NIL Arg 2 (SI:READ-FUNCTION): NIL Arg 3 (SI:EVAL-FUNCTION): NIL Arg 4 (SI:PRINT-FUNCTION): NIL Arg 5 (SI:INITIAL-FORM): NIL Arg 6 (SI:STANDARD-VALUE-BINDINGS): (NIL) SI:LISP-COMMAND-LOOP: (P.C. = 120) Arg 0: # Rest arg: (:NAME "Lisp Top Level" :STANDARD-VALUE-BINDINGS (NIL)) SI:LISP-TOP-LEVEL1: (P.C. = 27) Arg 0 (SI:STREAM): # SI:LISP-TOP-LEVEL2: (P.C. = 5) SI:PROCESS-TOP-LEVEL: (P.C. = 45) Arg 0 (IGNORE): NIL Special *FUNCALLABLE-INSTANCE-MARKER*: ("Funcallable Instance Marker") Special *LOOKUP-METHOD1*: # Special *LOOKUP-METHOD2*: # Special *THE-CLASS-T*: #  Received: from Xerox.COM (TCP 1500006350) by AI.AI.MIT.EDU 10 Feb 88 17:11:48 EST Received: from Semillon.ms by ArpaGateway.ms ; 10 FEB 88 14:06:09 PST Date: Wed, 10 Feb 88 13:58 PST From: Gregor.pa@Xerox.COM Subject: list administration To: CommonLoops.pa@Xerox.COM Fcc: BD:>Gregor>mail>outgoing-mail-1.text Message-ID: <880210135844.8.GREGOR@SPIFF.parc.xerox.com> Line-fold: no Once again its time to remind everyone that administrative messages about the mailing list should be addressed to: CommonLoops-Request@Xerox.com So if you: - want to be removed from the list - want to be added to the list - your address changes - you are receiving 19.5 copies of each message - you get back error messages when you mail to the list . . Send your message to CommonLoops-Request@Xerox.com. Send all technical messages and questions about PCL, its use, its status, the CLOS spec or anything like that to: CommonLoops@Xerox.com. -------  Received: from Xerox.COM (TCP 1500006350) by AI.AI.MIT.EDU 10 Feb 88 16:33:39 EST Received: from Cabernet.ms by ArpaGateway.ms ; 10 FEB 88 13:26:46 PST Return-Path: <@CUNYVM.CUNY.EDU:BORDEN@YALEMED.BITNET> Redistributed: commonloops.PA Received: from CUNYVM.CUNY.EDU by Xerox.COM ; 10 FEB 88 13:25:10 PST Received: from YALEMED.BITNET by CUNYVM.CUNY.EDU ; Wed, 10 Feb 88 16:24:51 EST Date: Wed, 10 Feb 88 16:24 EST From: (jonathan borden) Subject: UNSUBSCRIBE BORDEN@YALEMED.BITNET To: commonloops.PA@Xerox.COM X-Original-To: commonloops.PA@XEROX.COM Message-ID: <880210-132646-5806@Xerox>  Received: from Xerox.COM (TCP 1500006350) by AI.AI.MIT.EDU 10 Feb 88 13:25:45 EST Received: from Semillon.ms by ArpaGateway.ms ; 10 FEB 88 10:15:33 PST Date: Wed, 10 Feb 88 10:08 PST From: Gregor.pa@Xerox.COM Subject: CLOS specification To: CommonLoops.PA@Xerox.COM Message-ID: <880210100842.6.GREGOR@SPIFF.parc.xerox.com> Line-fold: no There is now a set of sources for the newest draft of the CLOS specification on parcvax.xerox.com. The directory /pub/pcl/doc contains TeX source files for the most recent draft of the CLOS specification. There are TeX source files for two documents called concep.tex and functi.tex. These correspond to chapter 1 and 2 of the CLOS specification. You will need all the files in this directory to TeX up a copy of the spec. -------  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 10 Feb 88 12:03:34 EST Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 10 Feb 88 08:58:45 PST Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 340430; Wed 10-Feb-88 11:57:41 EST Date: Wed, 10 Feb 88 11:57 EST From: David A. Moon Subject: Status of SETF functions in Common Lisp To: Jon L White cc: Common-Lisp-Object-System@SAIL.STANFORD.EDU, sun!franz!smh@labrea.Stanford.EDU, rwk@AI.AI.MIT.EDU, CL-Cleanup@SAIL.STANFORD.EDU In-Reply-To: <8802100814.AA05040@bhopal.lucid.com> Message-ID: <19880210165749.0.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Wed, 10 Feb 88 00:14:17 PST From: Jon L White Date: Thu, 4 Feb 88 14:46:35 PST From: Jon L White .... re: But, haven't we already extended symbol-function to take lists of the form (setf fn) as an argument. If not, how do we get hold of setf generic-functions? I don't recall how the recent discussions on this mailing list suggested to do it. This was in a cleanup proposal which the Cleanup committee already approved, submitted to X3J13 in November, and was approved by X3J13 at that time. I wasn't there, so I don't know for sure what happened, but I don't think there was any voting. Perhaps there was some kind of verbal approval. Anyway my point is that this is as settled an issue as any issue can be and there's a place where the answer is written down. I don't have a copy of it myself or I'd send it to you. You're jumping the gun here. The issue of (setf fn) as a function name came up as a need from CLOS, but was never presented for approval. Then I guess one of Larry's status reports saying that issue had been approved was mistaken, or I misread it. Larry assigned a sub-sub-committee to try to write up some proposal that would encompass "function specs". That's exactly what I did -not- want to happen. If setf functions, which CLOS needs, get bogged down in all kinds of extraneous issues about function specs, which CLOS does not need and does not want, CLOS could end up getting the shaft. I think standardizing function specs for Common Lisp is likely to be a fine thing, but I don't want CLOS to have to wait for it to be completed. We (this sub-sub-...) have met by conference phone, and discussed what to do; initially Bob Kerns is working on a "definition specs" proposal that will clean up and extend the LispMachine's functions specs somewhat. But we all feel that this is new development -- not just a simple "clarification", or "cleanup" or minor extension to Common Lisp, and more serious thought needs to be given to the question. Most likely there will much discussion about it in Palo Alto next month. The only thing that's been settled so far is that we all agree on the need to do something. The actual scope of what is done, the names of the constructs, and as Danny asks "how do we get hold of setf generic-functions?" are hardly a settled issues right now. At any rate, I think he (Danny) was just asking how "we", the CLOS development, proposed to get access to these things. I guess I should wait until there is a report of the sub-sub-committee to read, before drawing any conclusions or making any more intemperate statements.  Received: from Xerox.COM (TCP 1500006350) by AI.AI.MIT.EDU 10 Feb 88 08:41:38 EST Received: from Cabernet.ms by ArpaGateway.ms ; 10 FEB 88 05:31:40 PST Return-Path: <@MCC.COM:rcp%sw.MCC.COM@MCC.COM> Redistributed: commonloops.PA Received: from MCC.COM by Xerox.COM ; 10 FEB 88 05:29:54 PST Received: from milano.SW.MCC.COM by MCC.COM with TCP; Wed 10 Feb 88 07:29:11-CST Received: from perseus by milano.SW.MCC.COM (5.52/STP1.56) id AA04525; Wed, 10 Feb 88 07:29:29 CST Date: Wed, 10 Feb 88 07:28:46 CST From: Rob Pettengill Message-Id: <8802101328.AA09446@perseus> Received: by perseus (3.2/STP) id AA09446; Wed, 10 Feb 88 07:28:46 CST To: Gregor.pa@Xerox.COM Cc: commonloops.PA@Xerox.COM In-Reply-To: Gregor.pa@xerox.com's message of Tue, 9 Feb 88 17:16 PST <880209171608.4.GREGOR@SPIFF.parc.xerox.com> Subject: Re: bug in nested :around methods & TYPEP problem in 2/7/88 PCL I also observed the infinite loops just using call-next-method in a complicated class hierarchy without doing :around methods. The patch you sent out seems to fix my problem as well. There seems to be a problem with typep in excl-3.0.beta.68 with pcl::iwmc-class. I have been using (typep object 'pcl::iwmc-class) or (check-type object pcl::iwmc-class) to verify that an object is a pcl object before doing pcl specific things to it. Now I have the following problem: ->(ERROR "Attempt to call ~s which is defined as a macro." #) (TYPEP #[Canvas: 4 (0.05, 0.7, 0.15, 0.90999997) Parent: #[NX-WS-CONNECTION-ROOT-CANVAS: localhost,0 #], Children: ()] PCL::IWMC-CLASS) (EVAL (TYPEP C 'PCL::IWMC-CLASS)) Should iwmc-class-p be a function? Is there a more portable way to check that an object is a pcl object? Thanks, Rob Robert C. Pettengill, MCC Software Technology Program P. O. Box 200195, Austin, Texas 78720 ARPA: rcp@mcc.com PHONE: (512) 338-3533 UUCP: {ihnp4,seismo,harvard,gatech,pyramid}!ut-sally!im4u!milano!rcp  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 10 Feb 88 03:23:40 EST Received: from labrea.Stanford.EDU by SAIL.Stanford.EDU with TCP; 10 Feb 88 00:19:20 PST Received: by labrea.Stanford.EDU; Wed, 10 Feb 88 00:19:26 PST Received: from bhopal.lucid.com by edsel id AA04885g; Wed, 10 Feb 88 00:09:32 PST Received: by bhopal id AA05040g; Wed, 10 Feb 88 00:14:17 PST Date: Wed, 10 Feb 88 00:14:17 PST From: Jon L White Message-Id: <8802100814.AA05040@bhopal.lucid.com> To: labrea!Moon%STONY-BROOK.SCRC.Symbolics.COM@labrea.Stanford.EDU Cc: labrea!Common-Lisp-Object-System%SAIL@labrea.Stanford.EDU, sun!franz!smh@labrea.Stanford.EDU, labrea!rwk%ai.ai.mit.edu@labrea.Stanford.EDU In-Reply-To: David A. Moon's message of Mon, 8 Feb 88 13:33 EST <19880208183318.6.MOON@EUPHRATES.SCRC.Symbolics.COM> Subject: Comments on most recent draft: Chap 1 and 2 Date: Thu, 4 Feb 88 14:46:35 PST From: Jon L White .... re: But, haven't we already extended symbol-function to take lists of the form (setf fn) as an argument. If not, how do we get hold of setf generic-functions? I don't recall how the recent discussions on this mailing list suggested to do it. This was in a cleanup proposal which the Cleanup committee already approved, submitted to X3J13 in November, and was approved by X3J13 at that time. I wasn't there, so I don't know for sure what happened, but I don't think there was any voting. Perhaps there was some kind of verbal approval. Anyway my point is that this is as settled an issue as any issue can be and there's a place where the answer is written down. I don't have a copy of it myself or I'd send it to you. You're jumping the gun here. The issue of (setf fn) as a function name came up as a need from CLOS, but was never presented for approval. Larry assigned a sub-sub-committee to try to write up some proposal that would encompass "function specs". We (this sub-sub-...) have met by conference phone, and discussed what to do; initially Bob Kerns is working on a "definition specs" proposal that will clean up and extend the LispMachine's functions specs somewhat. But we all feel that this is new development -- not just a simple "clarification", or "cleanup" or minor extension to Common Lisp, and more serious thought needs to be given to the question. Most likely there will much discussion about it in Palo Alto next month. The only thing that's been settled so far is that we all agree on the need to do something. The actual scope of what is done, the names of the constructs, and as Danny asks "how do we get hold of setf generic-functions?" are hardly a settled issues right now. At any rate, I think he (Danny) was just asking how "we", the CLOS development, proposed to get access to these things. -- JonL --  Received: from Xerox.COM (TCP 1500006350) by AI.AI.MIT.EDU 9 Feb 88 22:36:36 EST Received: from Salvador.ms by ArpaGateway.ms ; 09 FEB 88 19:28:55 PST Return-Path: Redistributed: CommonLoops.pa Received: from WILMA.BBN.COM by Xerox.COM ; 09 FEB 88 19:27:58 PST To: CommonLoops.pa@Xerox.COM Cc: kanderson@WILMA.BBN.COM Subject: #+IBCL or #+KCL Date: Tue, 09 Feb 88 22:17:36 -0500 From: kanderso@WILMA.BBN.COM Message-ID: <880209-192855-4863@Xerox> in (defvar *pcl-system-date* "2/7/88 Febuary 7th 1988") Defsys.lisp contains: #+IBCL (push 'kcl *features*) I found that to make PCL in KCL i need to add: #+kcl (push 'IBCL *features*) also to get the #+IBCL in walk.lisp to work. Can we make things more consistant by saying somthing like #+(or kcl ibcl) where appropriate? k  Received: from Xerox.COM (TCP 1500006350) by AI.AI.MIT.EDU 9 Feb 88 20:32:24 EST Received: from Semillon.ms by ArpaGateway.ms ; 09 FEB 88 17:23:25 PST Date: Tue, 9 Feb 88 17:16 PST From: Gregor.pa@Xerox.COM Subject: bug in nested :around methods To: John Alan McDonald cc: commonloops.PA@Xerox.COM Fcc: BD:>Gregor>mail>outgoing-mail-1.text In-Reply-To: <8802092215.AA16980@entropy.ms.washington.edu> Message-ID: <880209171608.4.GREGOR@SPIFF.parc.xerox.com> Line-fold: no Date: Tue, 9 Feb 88 14:15:07 PST From: jam%entropy.ms@beaver.cs.washington.edu (John Alan McDonald) ;;; In PCL version 2-7-88, Symbolics Genera 7.1, ;;; nested :around methods cause infinite loops: The following patch to the file boot.lisp fixes this. To save yourself time installing this patch, it is alright to put it in a patches file which is loaded after all of PCL is loaded. In other words, there is no need to recompile all of PCL just to install this patch. (defun expand-defmethod-body-internal (generic-function-name lambda-list specializers body env) (multiple-value-bind (doc declares real-body) (extract-declarations body env) (declare (ignore doc)) ;We drop it on the floor ;since it gets recorded ;elsewhere. (let ((class-declarations `(declare ,@(mapcar #'(lambda (a s) (and (symbolp s) `(class ,a ,s))) lambda-list specializers))) (call-next-method-p nil) (save-original-args nil) (original-args ()) (applyp nil) (walked-lambda nil)) (flet ((walk-function (form context env &aux temp) (cond ((not (eq context ':eval)) form) ((not (listp form)) form) ((eq (car form) 'call-next-method) (setq call-next-method-p 't save-original-args (not (cdr form))) form) ((and (eq (car form) 'function) (eq (cadr form) 'call-next-method)) (setq call-next-method-p 't save-original-args 't) form) ((and (or (eq (car form) 'slot-value) (eq (car form) 'set-slot-value)) (symbolp (cadr form)) (constantp (caddr form)) (setq temp (variable-class (cadr form) env)) (or (not (symbolp temp)) (setq temp (class-named temp 't)))) (ecase (car form) (slot-value (optimize-slot-value temp form)) (set-slot-value (optimize-set-slot-value temp form)))) (t form)))) (setq walked-lambda (walk-form `(lambda ,lambda-list ,class-declarations ,@declares (block ,generic-function-name ,@real-body)) env #'walk-function)) (when save-original-args ;; We are going to have to be able to store away the original ;; arguments to the function. Get ourselves an argument list ;; to do this with. (dolist (a lambda-list) (if (member a lambda-list-keywords) (if (eq a '&aux) (return) (progn (setq applyp t) (push '&rest original-args) (push (gensym) original-args) (return))) (push (gensym) original-args))) (setq original-args (reverse original-args))) (multiple-value-bind (doc walked-declares walked-lambda-body) (extract-declarations (cddr walked-lambda)) (declare (ignore doc)) (cond ((null call-next-method-p) walked-lambda) ((null save-original-args) `(lambda ,lambda-list ,@walked-declares (let ((.next-method. (car *next-methods*)) (*next-methods* (cdr *next-methods*))) (flet ((call-next-method (&rest cnm-args) (apply .next-method. cnm-args))) ,@walked-lambda-body)))) ((null applyp) `(lambda ,original-args (let ((.next-method. (car *next-methods*)) (*next-methods* (cdr *next-methods*))) (flet ((call-next-method (&rest cnm-args) (if cnm-args (apply .next-method. cnm-args) (funcall .next-method. ,@original-args)))) (let ,(mapcar #'list lambda-list original-args) ,@walked-declares ,@walked-lambda-body))))) (t `(lambda ,original-args (let ((.next-method. (car *next-methods*)) (*next-methods* (cdr *next-methods*))) (flet ((call-next-method (&rest cnm-args) (if cnm-args (apply .next-method. cnm-args) (apply .next-method. ,@(remove '&rest original-args))))) (apply (function ,walked-lambda) ,@(remove '&rest original-args)))))))))))) -------  Received: from Xerox.COM (TCP 1500006350) by AI.AI.MIT.EDU 9 Feb 88 17:27:16 EST Received: from Salvador.ms by ArpaGateway.ms ; 09 FEB 88 14:17:27 PST Return-Path: Redistributed: commonloops.PA Received: from beaver.cs.washington.edu by Xerox.COM ; 09 FEB 88 14:15:49 PST Received: by beaver.cs.washington.edu (5.52.1/6.12) id AA08040; Tue, 9 Feb 88 14:13:32 PST Return-Path: Received: by entropy.ms.washington.edu (5.52.1/6.2) id AA16980; Tue, 9 Feb 88 14:15:07 PST Date: Tue, 9 Feb 88 14:15:07 PST From: jam%entropy.ms@beaver.cs.washington.edu (John Alan McDonald) Message-Id: <8802092215.AA16980@entropy.ms.washington.edu> To: commonloops.PA@Xerox.COM Subject: bug in nested :around methods ;;; -*- Package: PCL; Mode: Lisp; Syntax: Common-Lisp; -*- ;;; In PCL version 2-7-88, Symbolics Genera 7.1, ;;; nested :around methods cause infinite loops: (defclass class1 () ()) (defclass class2 (class1) ()) (defclass class3 (class2) ()) (defmethod fee ((x class1) &optional val) (print val)) (defmethod fee :around ((x class1) &optional (val 1)) (print val) (call-next-method)) (defmethod fee :around ((x class2) &optional (val 2)) (print val) (call-next-method)) (defmethod fee :around ((x class3) &optional (val 3)) (print val) (call-next-method)) (setf x3 (make-instance 'class3)) ;; evaluating: (fee x3) ;; never gets past (method fee :around (class2)) John Alan McDonald, Statistics, GN-22, U of W, Seattle, Wa. 98195 (206) 545 7438, 543 2517 jam@entropy.ms.washington.edu {decvax,ihnp4,ucbvax!lbl-csam}!uw-beaver!entropy!jam  Received: from Xerox.COM (TCP 1500006350) by AI.AI.MIT.EDU 9 Feb 88 17:27:05 EST Received: from Semillon.ms by ArpaGateway.ms ; 09 FEB 88 14:15:41 PST Date: Tue, 9 Feb 88 14:08 PST From: Gregor.pa@Xerox.COM Subject: Time to create :ACCESSORs and:READERs To: kanderso@WILMA.BBN.COM cc: CommonLoops.pa@Xerox.COM, kanderson@WILMA.BBN.COM, rshapiro@WILMA.BBN.COM, mthome@WILMA.BBN.COM, wsalter@WILMA.BBN.COM Fcc: BD:>Gregor>mail>outgoing-mail-1.text In-Reply-To: The message of 9 Feb 88 10:21 PST from kanderso@WILMA.BBN.COM Message-ID: <880209140859.3.GREGOR@SPIFF.parc.xerox.com> Line-fold: no Date: Tue, 09 Feb 88 13:21:47 -0500 From: kanderso@WILMA.BBN.COM This might not be the best way to perform such a test, but we're suprised that it takes an order of magnitude longer to create the SETF functions. It is bad, but given that Common Lisp doesn't provide access to the mechanism which underlies setf it isn't at all surprising. I will look into fixing this by defining a portable interface which PCL can use to get at the underlying setf machinery. -------  Received: from Xerox.COM (TCP 1500006350) by AI.AI.MIT.EDU 9 Feb 88 13:35:19 EST Received: from Semillon.ms by ArpaGateway.ms ; 09 FEB 88 10:30:19 PST Return-Path: Redistributed: CommonLoops.pa Received: from WILMA.BBN.COM by Xerox.COM ; 09 FEB 88 10:27:06 PST To: CommonLoops.pa@Xerox.COM Cc: kanderson@WILMA.BBN.COM, rshapiro@WILMA.BBN.COM, mthome@WILMA.BBN.COM, wsalter@WILMA.BBN.COM Subject: Time to create :ACCESSORs and:READERs Date: Tue, 09 Feb 88 13:21:47 -0500 From: kanderso@WILMA.BBN.COM Message-ID: <880209-103019-3960@Xerox> Using the 8/27/87 version of PCL on a Symbolics G7.1 machine we have the following timings for compiling a DEFCLASS with 219 instance variables. In the first case, :ACCESSOR is specified for each slot: (time (DEFCLASS SCHEDULE-D-2 (TAXFORM) ((D-BBN-ID-NUM :INITFORM NIL :ACCESSOR BBN-ID-NUM) (D-NAME :INITFORM NIL :ALLOCATION :INSTANCE :ACCESSOR NAME) (D-SSN :INITFORM NIL :ALLOCATION :INSTANCE :ACCESSOR SSN :TYPE T) ... (D-48 :INITFORM NIL :ALLOCATION :INSTANCE :ACCESSOR TOTAL-BART-INCOME)) (:METACLASS AIIS-CLASS))) Evaluation of (DEFCLASS SCHEDULE-D-2 (TAXFORM) (# # # # # ...) (:METACLASS AIIS-CLASS)) took 156.522006 seconds of elapsed time including 7.070 seconds waiting for the disk for 7 faults. The garbage collector has flipped, so consing was not measured. # In the second case, :READER was specified for each slot: (time (DEFCLASS SCHEDULE-D-3 (TAXFORM) ((D-BBN-ID-NUM :INITFORM NIL :READER BBN-ID-NUM) (D-NAME :INITFORM NIL :ALLOCATION :INSTANCE :READER NAME) (D-SSN :INITFORM NIL :ALLOCATION :INSTANCE :READER SSN :TYPE T) ... (D-48 :INITFORM NIL :ALLOCATION :INSTANCE :READER TOTAL-BART-INCOME)) (:METACLASS AIIS-CLASS))) Evaluation of (DEFCLASS SCHEDULE-D-3 (TAXFORM) (# # # # # ...) (:METACLASS AIIS-CLASS)) took 14.114444 seconds of elapsed time including 1.361 seconds waiting for the disk for 33 faults. 16,824 list, 9,082 structure words consed in WORKING-STORAGE-AREA. 9 list words consed in PROPERTY-LIST-AREA. 7 structure words consed in PNAME-AREA. 5 structure words consed in SYMBOL-AREA. # This might not be the best way to perform such a test, but we're suprised that it takes an order of magnitude longer to create the SETF functions. Sorry, i haven't been able to try this in the current version yet. k  Received: from Xerox.COM (TCP 1500006350) by AI.AI.MIT.EDU 9 Feb 88 06:10:12 EST Received: from Semillon.ms by ArpaGateway.ms ; 09 FEB 88 03:05:06 PST Return-Path: Redistributed: CommonLoops.pa Received: from GE-CRD.ARPA by Xerox.COM ; 09 FEB 88 03:03:34 PST Date: 9 Feb 88 06:03 EST From: simmons%algol.tcpip@ge-crd.arpa Subject: Fixing Lucid 2.1 Compilation Problem To: CommonLoops.pa@Xerox.COM Message-ID: <880209-030506-3434@Xerox> Received: by algol.steinmetz (3.2/1.1x Steinmetz) id AA29812; Tue, 9 Feb 88 05:40:52 EST Date: Tue, 9 Feb 88 05:40:52 EST From: simmons Posted-Date: Tue, 9 Feb 88 05:40:52 EST Message-Id: <8802091040.AA29812@algol.steinmetz> To: CommonLoops.pa@Xerox.com Subject: Fixing Lucid 2.1 Compilation Problem Yes. Many of the better Common Lisp compilers have bugs like this. Out of curiosity, does the following change (which is a little less ugly) also fix the bug? (defun with-slots-internal (specs form context translate-fn &aux entry) ... ... ... (scan-setf (cddr tail)))))) (walker::recons form kind (scan-setf (cdr form)))))) (t form))) No. That doesn't work in Lucid 2.1. It seems that we need to force the evaluation of the arguments such that evaluation of (scan-setf (cdr form)) comes BEFORE the evaluation of kind. The following slight variation on the original code seems to work, and is cleaner than my first fix. Perhaps the folks at Lucid could enlighten us as to the best way to control the compiler in such cases. -- Mel Simmons (defun with-slots-internal (specs form context translate-fn &aux entry) ... ... ... (scan-setf (cddr tail)))))) (let (new-tail) (setq new-tail (scan-setf (cdr form))) (walker::recons form kind new-tail))))) (t form)))  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 8 Feb 88 19:40:31 EST Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 8 Feb 88 16:36:12 PST Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 339201; 8 Feb 88 19:36:05 EST Date: Mon, 8 Feb 88 19:36 EST From: David A. Moon Subject: Re: defgeneric :method option To: Common-Lisp-Object-System@SAIL.STANFORD.EDU In-Reply-To: <880208-160010-2750@Xerox> Message-ID: <19880209003616.7.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: 8 Feb 88 15:59 PST From: Danny Bobrow Another argument for removing methods first is that when a method is added, but it is shadowed by a method to be removed, the generic function is in as much of an inconsistent state as when a method is removed and there is no method for a particlar set of arguments. It seems to me that doing the remove-method first answers Patrick's issue, and provides no more inconsistency. The case I had in mind is the one where the defgeneric has the same :method options both before and after.  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 8 Feb 88 19:23:58 EST Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 8 Feb 88 16:19:25 PST Received: from Cabernet.ms by ArpaGateway.ms ; 08 FEB 88 16:00:10 PST Date: 8 Feb 88 15:59 PST Sender: Bobrow.pa@Xerox.COM From: Danny Bobrow Subject: Re: defgeneric :method option In-reply-to: David A. Moon 's message of Mon, 8 Feb 88 13:21 EST To: Moon@STONY-BROOK.SCRC.Symbolics.COM cc: Common-Lisp-Object-System@SAIL.STANFORD.EDU Message-ID: <880208-160010-2750@Xerox> Another argument for removing methods first is that when a method is added, but it is shadowed by a method to be removed, the generic function is in as much of an inconsistent state as when a method is removed and there is no method for a particlar set of arguments. It seems to me that doing the remove-method first answers Patrick's issue, and provides no more inconsistency. danny  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 8 Feb 88 19:19:17 EST Date: 08 Feb 88 1613 PST From: Linda DeMichiel Subject: x3j13 draft To: common-lisp-object-system@SAIL.Stanford.EDU The concep and functi files for the x3j13 draft are now out on Sail. I have also updated the macros file to print out the document number. -lgd  Received: from Xerox.COM (TCP 1500006350) by AI.AI.MIT.EDU 8 Feb 88 16:54:48 EST Received: from Semillon.ms by ArpaGateway.ms ; 08 FEB 88 12:56:30 PST Date: Mon, 8 Feb 88 12:53 PST From: Gregor.pa@Xerox.COM Subject: Bugs in 2/4 Version with Lucid2.1 To: simmons%algol.tcpip@ge-crd.arpa cc: CommonLoops.pa@Xerox.COM Fcc: BD:>Gregor>mail>outgoing-mail-1.text In-Reply-To: The message of 8 Feb 88 11:32 PST from simmons%algol.tcpip@ge-crd.arpa Message-ID: <880208125325.3.GREGOR@SPIFF.parc.xerox.com> Line-fold: no Date: 8 Feb 88 14:32 EST From: simmons%algol.tcpip@ge-crd.arpa I have found two problems in trying to compile the Feb 4 version of PCL under Lucid 2.1. I have fixes, I think , but I am uncertain of just what happened here. Did others encounter these problems? First, in lucid-low.lisp at line 108 we had (defmacro cache-no (pointer mask) `(lucid::logand& ,mask ,pointer)) Yes, go ahead and change that to %logand& in your version of the low file. In the next release I will conditionalize that for #-LCL3.0. Second, with-slots* was broken -- it failed to change setq to setf when required. As an example of the problem, The problem seemed to arise in with-slots-internal. The original code would work interpreted, but not compiled. Is this due to overly zealous optimization in the Lucid compiler? Yes. Many of the better Common Lisp compilers have bugs like this. Out of curiosity, does the following change (which is a little less ugly) also fix the bug? (defun with-slots-internal (specs form context translate-fn &aux entry) (cond ((not (eq context :eval)) form) ((symbolp form) (if (setq entry (assoc form specs)) (funcall translate-fn (cadr entry)) form)) ((not (listp form)) form) ((member (car form) '(setq setf)) ;; Have to be careful. We must only convert the form to a SETF ;; form when we convert one of the 'logical' variables to a form ;; Otherwise we will get looping in implementations where setf ;; is a macro which expands into setq or vice versa. (let ((kind (car form))) (labels ((scan-setf (tail) (if (null tail) nil (walker::relist* tail (if (setq entry (assoc (car tail) specs)) (progn (setq kind 'setf) (funcall translate-fn (cadr entry))) (car tail)) (cadr tail) (scan-setf (cddr tail)))))) (walker::recons form kind (scan-setf (cdr form)))))) (t form))) If you could check this out I would appreciate it. I will then put whichever fix is appropriate in the sources. -------  Received: from Xerox.COM (TCP 1500006350) by AI.AI.MIT.EDU 8 Feb 88 15:50:42 EST Received: from Semillon.ms by ArpaGateway.ms ; 08 FEB 88 11:43:25 PST Date: Mon, 8 Feb 88 11:38 PST From: Gregor.pa@Xerox.COM Subject: new version of boot.lisp To: CommonLoops.pa@Xerox.COM Message-ID: <880208113805.0.GREGOR@SPIFF.parc.xerox.com> Line-fold: no Some of you may have experienced problems with the symbol &rest being used as an unbound variable. This happens in some defmethods where call-next-method is used. This was caused by a bug in the boot.lisp file. If you are running into this problem, you can fix it by getting yourself a new copy of the boot.lisp file from parcvax.xerox.com. -------  Received: from Xerox.COM (TCP 1500006350) by AI.AI.MIT.EDU 8 Feb 88 15:50:28 EST Received: from Cabernet.ms by ArpaGateway.ms ; 08 FEB 88 11:36:36 PST Return-Path: Redistributed: CommonLoops.pa Received: from GE-CRD.ARPA by Xerox.COM ; 08 FEB 88 11:33:46 PST Date: 8 Feb 88 14:32 EST From: simmons%algol.tcpip@ge-crd.arpa Subject: Bugs in 2/4 Version with Lucid2.1 To: CommonLoops.pa@Xerox.COM Message-ID: <880208-113636-2118@Xerox> Received: by algol.steinmetz (3.2/1.1x Steinmetz) id AA28953; Mon, 8 Feb 88 12:34:18 EST Date: Mon, 8 Feb 88 12:34:18 EST From: simmons Posted-Date: Mon, 8 Feb 88 12:34:18 EST Message-Id: <8802081734.AA28953@algol.steinmetz> To: CommonLoops.pa@Xerox.com Subject: Bugs in 2/4 Version with Lucid2.1 I have found two problems in trying to compile the Feb 4 version of PCL under Lucid 2.1. I have fixes, I think , but I am uncertain of just what happened here. Did others encounter these problems? First, in lucid-low.lisp at line 108 we had (defmacro cache-no (pointer mask) `(lucid::logand& ,mask ,pointer)) but it seems that the point of the subsequent code was to create a function %logand&, which was like logand&, but accepted any types of arguments. If I compile PCL with the above code, I get many messages about finding symbols where it expects fixnums. The following seems to be what was intended, and seems to work. (defmacro cache-no (pointer mask) `(lucid::%logand& ,mask ,pointer)) Second, with-slots* was broken -- it failed to change setq to setf when required. As an example of the problem, > (defclass foo () (x y)) NIL > (setq foo1 (make-instance 'foo)) # > (macroexpand '(with-slots* (x y) foo1 (setq x 0))) ((LAMBDA (#:G719) (SETQ # 0)) FOO1) T The problem seemed to arise in with-slots-internal. With the changes noted below (the lines with #+Lucid) it returned ((LAMBDA (#:G660) (SET-SLOT-VALUE #:G660 # 0)) FOO1) T The original code would work interpreted, but not compiled. Is this due to overly zealous optimization in the Lucid compiler? ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ;;;;Change made to std-class.lisp, starting at line 738 ;;;This nonsense is to avoid a bug(?) in the Lucid 2.1 compiler -- MKS #+Lucid (defvar *lucid-junk* nil) (defun with-slots-internal (specs form context translate-fn &aux entry) (cond ((not (eq context :eval)) form) ((symbolp form) (if (setq entry (assoc form specs)) (funcall translate-fn (cadr entry)) form)) ((not (listp form)) form) ((member (car form) '(setq setf)) ;; Have to be careful. We must only convert the form to a SETF ;; form when we convert one of the 'logical' variables to a form ;; Otherwise we will get looping in implementations where setf ;; is a macro which expands into setq. (let ((kind (car form))) (labels ((scan-setf (tail) (if (null tail) nil (walker::relist* tail (if (setq entry (assoc (car tail) specs)) (progn (setq kind 'setf) (funcall translate-fn (cadr entry))) (car tail)) (cadr tail) (scan-setf (cddr tail)))))) (let ((new-tail (scan-setf (cdr form)))) #+Lucid (setq *lucid-junk* new-tail) (walker::recons form kind new-tail))))) (t form)))  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 8 Feb 88 13:38:12 EST Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 8 Feb 88 10:33:37 PST Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 338700; Mon 8-Feb-88 13:33:07 EST Date: Mon, 8 Feb 88 13:33 EST From: David A. Moon Subject: Comments on most recent draft: Chap 1 and 2 To: Jon L White cc: Common-Lisp-Object-System@SAIL.STANFORD.EDU In-Reply-To: <8802042246.AA01035@bhopal.lucid.com> Message-ID: <19880208183318.6.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Thu, 4 Feb 88 14:46:35 PST From: Jon L White .... re: But, haven't we already extended symbol-function to take lists of the form (setf fn) as an argument. If not, how do we get hold of setf generic-functions? I don't recall how the recent discussions on this mailing list suggested to do it. This was in a cleanup proposal which the Cleanup committee already approved, submitted to X3J13 in November, and was approved by X3J13 at that time. I wasn't there, so I don't know for sure what happened, but I don't think there was any voting. Perhaps there was some kind of verbal approval. Anyway my point is that this is as settled an issue as any issue can be and there's a place where the answer is written down. I don't have a copy of it myself or I'd send it to you.  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 8 Feb 88 13:27:00 EST Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 8 Feb 88 10:21:41 PST Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 338675; Mon 8-Feb-88 13:21:33 EST Date: Mon, 8 Feb 88 13:21 EST From: David A. Moon Subject: Re: defgeneric :method option To: Common-Lisp-Object-System@SAIL.STANFORD.EDU In-Reply-To: <2780318934-287847@Jenner> Message-ID: <19880208182152.5.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Mon, 8 Feb 88 08:48:54 CST From: Patrick H Dussud A small detail. Since we remove the methods that were defined by :method in a DEFGENERIC, it would be consistent to allow the change of the lambda-list if the only methods defined for this generic function are the one defined by :method. Logically, we are in the case where there is no method on the updated generic function. That's a good point. I agree. What's in the current version (just looked at a few minutes ago) of chapters 1 and 2 doesn't really need to be changed for this, since it doesn't say in specific detail what the macroexpansion of defgeneric is; I guess that's chapter 3 material. It probably is a good idea to update the remark part of defgeneric. If we agree on this, it means that the remark part of defgeneric must be updated, and the following form cannot be the expansion of DEFGENERIC: (progn (ensure-generic-function 'name :blah blah blah) (let ((methods (list (defmethod name blah blah blah) (defmethod name blah blah blah) ...)) (generic (symbol-function 'name))) (dolist (method (generic-function-locally-defined-methods generic)) (remove-method generic method)) (setf (generic-function-locally-defined-methods generic) methods) generic)) I agree that your suggestion is right, even though at this moment I don't know what I think the precise macroexpansion to implement it ought to be.  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 8 Feb 88 13:23:17 EST Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 8 Feb 88 10:17:44 PST Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 338664; Mon 8-Feb-88 13:17:07 EST Date: Mon, 8 Feb 88 13:17 EST From: David A. Moon Subject: CONCEP and FUNCTI To: Dick Gabriel , Linda DeMichiel cc: common-lisp-object-system@SAIL.STANFORD.EDU In-Reply-To: The message of 5 Feb 88 12:48 EST from Dick Gabriel , The message of 7 Feb 88 21:00 EST from Dick Gabriel , The message of 7 Feb 88 20:22 EST from Linda DeMichiel Message-ID: <19880208181719.4.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: 05 Feb 88 0948 PST From: Dick Gabriel There are new CONCEP and FUNCTI .TEX and .DVI files on SAIL. These incorporate Danny's comments and the infamous (class-name ) = junk change. The impact of this latter change is minimal because many things deal with proper names, which are still symbols. For example, defclass and parameter specializers all either define proper names or take symbols as the names of classes. We hope to send these two chapters to X3J13 monday. Date: 07 Feb 88 1800 PST From: Dick Gabriel CONCEP.TEX and .DVI are on SAIL. Unless there is some objection, the versions of chapters 1 and 2 currently on SAIL will be mailed to X3J13 tomorrow. Date: 07 Feb 88 1722 PST From: Linda DeMichiel New functi files are out on Sail. Changes include the addition of call-method, make-method, related changes to define-method-combination, changes to defclass (:type), and changes to defgeneric (method descriptions). I read all of these changes and they are all fine, except note my comment sent in previous mail today that defgeneric should add new methods before it removes old one, to avoid transient inconsistent states. This applies to chapter 2 (chapter 1 is not specific about the order of operations here). Thanks for all the hard work you've put into this.  Received: from Xerox.COM (TCP 1500006350) by AI.AI.MIT.EDU 8 Feb 88 13:09:46 EST Received: from Cabernet.ms by ArpaGateway.ms ; 08 FEB 88 09:49:09 PST Date: Mon, 8 Feb 88 09:43 PST From: Gregor.pa@Xerox.COM Subject: Trouble compiling PCL in Lucid To: James Daniell cc: CommonLoops.PA@Xerox.COM Fcc: BD:>Gregor>mail>outgoing-mail-1.text In-Reply-To: <8802081431.AA29687@ohm.ece.cmu.edu> Message-ID: <880208094325.8.GREGOR@SPIFF.parc.xerox.com> Line-fold: no I sent one message out about this. I probably should have put a note in the notes.text file. You should ignore these warnings, as dire as they sound they are alright. The people at Lucid and I are working on including some mechanism in next version of Lucid Lisp to address this problem. As for your machine `failing' I don't know what could be causing this. What file was it compiling? What messages had it printed out before failing? Did it give an error message or just dump core? You may want to get the newest version of PCL before recompiling. In particular, in the newest version the file dcode-pre1 compiles much faster. -------  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 8 Feb 88 12:20:24 EST Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 8 Feb 88 09:13:35 PST Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 338573; Sun 7-Feb-88 21:54:32 EST Date: Mon, 8 Feb 88 12:13 EST From: David A. Moon Subject: DEFGENERIC To: Dick Gabriel cc: common-lisp-object-system@SAIL.STANFORD.EDU In-Reply-To: The message of 6 Feb 88 14:46 EST from Dick Gabriel Message-ID: <19880208171338.0.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: 06 Feb 88 1146 PST From: Dick Gabriel The material for the behavior Moon specified does not look too bad when presented this way: defgeneric does an ensure-generic-function, it removes all methods defined by any previous defgeneric, and then it adds the methods specified by the :methods. The DEFCLASS description is similar. The presentation is clear and more concise than the desciption of the previous behavior. I prefer to add new methods before removing old ones, to avoid a transient state in which methods are missing. Remove-method is specified not to error if the method is already gone. Defining a method is specified (page 1-27) to create a new method object and discard any existing method object, rather than modifying the object as defining a class does. Those two facts mean it's safe to do the add before the remove.  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 8 Feb 88 12:07:28 EST Received: from RELAY.CS.NET by SAIL.Stanford.EDU with TCP; 8 Feb 88 09:01:48 PST Received: from relay2.cs.net by RELAY.CS.NET id ad21046; 8 Feb 88 10:24 EST Received: from csc.ti.com by RELAY.CS.NET id ad22101; 8 Feb 88 10:18 EST Received: from Jenner by tilde id AA23016; Mon, 8 Feb 88 08:51:37 CST Message-Id: <2780318934-287847@Jenner> Date: Mon, 8 Feb 88 08:48:54 CST From: Patrick H Dussud To: Common-Lisp-Object-System@SAIL.STANFORD.EDU Subject: Re: defgeneric :method option In-Reply-To: Msg of Fri, 5 Feb 88 16:34 EST from "David A. Moon" A small detail. Since we remove the methods that were defined by :method in a DEFGENERIC, it would be consistent to allow the change of the lambda-list if the only methods defined for this generic function are the one defined by :method. Logically, we are in the case where there is no method on the updated generic function. If we agree on this, it means that the remark part of defgeneric must be updated, and the following form cannot be the expansion of DEFGENERIC: (progn (ensure-generic-function 'name :blah blah blah) (let ((methods (list (defmethod name blah blah blah) (defmethod name blah blah blah) ...)) (generic (symbol-function 'name))) (dolist (method (generic-function-locally-defined-methods generic)) (remove-method generic method)) (setf (generic-function-locally-defined-methods generic) methods) generic)) Patrick.  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 8 Feb 88 12:07:27 EST Received: from RELAY.CS.NET by SAIL.Stanford.EDU with TCP; 8 Feb 88 09:01:36 PST Received: from relay2.cs.net by RELAY.CS.NET id ac21041; 8 Feb 88 10:23 EST Received: from csc.ti.com by RELAY.CS.NET id ac22101; 8 Feb 88 10:18 EST Received: from Jenner by tilde id AA22994; Mon, 8 Feb 88 08:50:57 CST Message-Id: <2780318877-284364@Jenner> Date: Mon, 8 Feb 88 08:47:57 CST From: Patrick H Dussud To: Common-Lisp-Object-System@SAIL.STANFORD.EDU Subject: Re: defgeneric :method option In-Reply-To: Msg of Fri, 5 Feb 88 16:34 EST from "David A. Moon" A small detail. Since we remove the methods that were defined by :method in a DEFGENERIC, it would be consistent to allow the change of the lambda-list if the only methods defined for this generic function are the one defined by :method. Logically, we are in the case where there is no method on the updated generic function. If we agree on this, it means that the remark part of defgeneric must be updated, and the following form cannot be the expansion of DEFGENERIC: (progn (ensure-generic-function 'name :blah blah blah) (let ((methods (list (defmethod name blah blah blah) (defmethod name blah blah blah) ...)) (generic (symbol-function 'name))) (dolist (method (generic-function-locally-defined-methods generic)) (remove-method generic method)) (setf (generic-function-locally-defined-methods generic) methods) generic)) Patrick.  Received: from Xerox.COM (TCP 1500006350) by AI.AI.MIT.EDU 8 Feb 88 09:39:00 EST Received: from Salvador.ms by ArpaGateway.ms ; 08 FEB 88 06:32:19 PST Return-Path: Redistributed: CommonLoops.PA Received: from ohm.ece.cmu.edu by Xerox.COM ; 08 FEB 88 06:30:38 PST Received: by ohm.ece.cmu.edu (5.51/5.17) id AA29687; Mon, 8 Feb 88 09:31:13 EST Date: Mon, 8 Feb 88 09:31:13 EST From: James Daniell Message-Id: <8802081431.AA29687@ohm.ece.cmu.edu> To: CommonLoops.PA@Xerox.COM Subject: Trouble compiling PCL in Lucid I have tried many attempts to compile the 2/3/88 release of PCL in Lucid 2.1 for the Microvax (Unix OS). I get many warnings to the effect: Illegal Literal COMBINE-METHOD should satisfy (Lucid::lowtag-fixnump in Lucid::logand & (quote 30) (quote combined methods)). Is anyone else having trouble and/or is there a better proclamation for the compiler to fix this? At present, my machine eventually GC's about 20 times and then fails. Jim Daniell Carnegie Mellon Univ. 5000 Forbes Ave. Pittsburgh, PA. 15213 (412) 268-2687  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 7 Feb 88 22:11:43 EST Received: from labrea.Stanford.EDU by SAIL.Stanford.EDU with TCP; 7 Feb 88 19:06:49 PST Received: by labrea.Stanford.EDU; Sun, 7 Feb 88 19:07:09 PST Received: from bhopal.lucid.com by edsel id AA23377g; Sun, 7 Feb 88 18:57:20 PST Received: by bhopal id AA13999g; Sun, 7 Feb 88 19:01:56 PST Date: Sun, 7 Feb 88 19:01:56 PST From: Jon L White Message-Id: <8802080301.AA13999@bhopal.lucid.com> To: labrea!RPG%SAIL@labrea.Stanford.EDU Cc: labrea!common-lisp-object-system%SAIL@labrea.Stanford.EDU In-Reply-To: Dick Gabriel's message of 07 Feb 88 1228 PST <8802072131.AA22357@edsel.lucid.com> Subject: Typechecking re: I agree with Jonl that the right thing to do is to say that attempting to store a type-improper value in a slot should signal an error. . . . That's just a bit beyond what my opinion on this matter was. Date: Wed, 27 Jan 88 03:00:04 PST From: Jon L White To: labrea!Bobrow.pa%Xerox.COM@labrea.Stanford.EDU . . . My preference as stated before is to prohibit a rule *requiring* checking of slot values, except that under the extremal safety settings such checking *may* be required. Note that this phrasing grants permission for an implementation to do type-checking at all safety levels, if it so chooses. I think one reason we have spent so much time going around on this matter is that Moon started out by attacking the wrong paragraph -- the one from page 13 in which the phrase something like "because type checking occurs only under the most strict safety options and in the interpreter". The sole purpose of that paragraph was to warn the reader that a slot's value may in fact violate its :type specification; that paragraph by itself did not carry the burden of saying that slots must be type-checked. As the story unfolded, he really wanted to attack the part with the phrase you (erroneously) attribute to me -- "Attempting to store a value in a slot that does not satisfy the type should signal an error" -- and have it relaxed from the "should" imperative. CLtL itself is very weak in specifying the cases where an error "should" be signalled, particularly in regard to array and structure updates (and makes virtually no distinction between the various compiler safety levels). A programmer used to the surety of a strongly-typed language finds this situation intolerable; consequently, I've put this issue into my file of things which haven't yet reached the Cleanup committee but ought to. If ever such an issue should be approved by X3J13, then it most certainly would apply to CLOS slot stores also. -- JonL --  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 7 Feb 88 21:04:12 EST Date: 07 Feb 88 1800 PST From: Dick Gabriel Subject: Chapter 1 To: common-lisp-object-system@SAIL.Stanford.EDU CONCEP.TEX and .DVI are on SAIL. Unless there is some objection, the versions of chapters 1 and 2 currently on SAIL will be mailed to X3J13 tomorrow. -rpg-  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 7 Feb 88 20:29:25 EST Date: 07 Feb 88 1722 PST From: Linda DeMichiel Subject: Chapter 2 To: common-lisp-object-system@SAIL.Stanford.EDU New functi files are out on Sail. Changes include the addition of call-method, make-method, related changes to define-method-combination, changes to defclass (:type), and changes to defgeneric (method descriptions). -lgd  Received: from Xerox.COM (TCP 1500006350) by AI.AI.MIT.EDU 7 Feb 88 19:25:22 EST Received: from Semillon.ms by ArpaGateway.ms ; 07 FEB 88 16:22:03 PST Return-Path: Redistributed: CommonLoops.PA Received: from CS.COLUMBIA.EDU by Xerox.COM ; 07 FEB 88 16:19:48 PST Date: Sun, 7 Feb 88 19:17:57 EST From: Ben Olasov Subject: Loading PCL in a CL interpreter To: CommonLoops.PA@Xerox.COM Message-ID: <12372937925.16.G.OLASOV@CS.COLUMBIA.EDU> Hello, I've successfully loaded some of the PCL files on the Post-Penultimate CLisp system here, but it isn't clear to me which files should be loaded, and in what sequence. Also, in the absence of a manual or a file that would potentially demonstrate the features of PCL (and whose mechanisms could be analysed), I'm somewhat at a loss as to how one makes use of PCL. Has anyone written applications for PCL that might have some pedagogical value for the rest of us? Thank you. Benjamin -------  Received: from Xerox.COM (TCP 1500006350) by AI.AI.MIT.EDU 7 Feb 88 16:25:21 EST Received: from Semillon.ms by ArpaGateway.ms ; 07 FEB 88 13:20:19 PST Return-Path: Redistributed: commonloops.PA Received: from ncifcrf.gov (FCS280S.NCIFCRF.GOV) by Xerox.COM ; 07 FEB 88 13:18:01 PST Received: from fcs260h.ncifcrf.gov by ncifcrf.gov (4.0/NCIFCRF-1.0) id AA26026; Sun, 7 Feb 88 16:16:55 EST Received: by fcs260h.ncifcrf.gov (3.2/NCIFCRF-1.0) id AA02032; Sun, 7 Feb 88 16:14:58 EST Date: Sun, 7 Feb 88 16:14:58 EST From: lemkin@ncifcrf.gov Message-Id: <8802072114.AA02032@fcs260h.ncifcrf.gov> To: commonloops.PA@Xerox.COM Subject: plse remove me from the list. Thanks P. Lemkin  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 7 Feb 88 15:33:16 EST Date: 07 Feb 88 1228 PST From: Dick Gabriel Subject: Typechecking To: common-lisp-object-system@SAIL.Stanford.EDU I agree with Jonl that the right thing to do is to say that attempting to store a type-improper value in a slot should signal an error. The desire to be in harmony with CLtL in places like this where CLtL is clearly wrong is inappropriate. If one wants to argue that there should be no such thing as a :type option, that is a different matter. I suppose this will be one of those situations in which the behavior of stock-hardware CLOS implementations will be superior to that of the Lisp machines. The error will be caught at the point of error and not considerable later. I agreed to modify the document because I have decided to let nothing stand in the way of my desire to stop working on the specification. I don't care how stupid a suggestion is: If it's faster for me to edit the document than to argue against it, I'll edit. -rpg-  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 7 Feb 88 01:22:51 EST Received: from labrea.Stanford.EDU by SAIL.Stanford.EDU with TCP; 6 Feb 88 22:18:31 PST Received: by labrea.Stanford.EDU; Sat, 6 Feb 88 22:18:50 PST Received: from bhopal.lucid.com by edsel id AA20504g; Sat, 6 Feb 88 21:47:59 PST Received: by bhopal id AA12948g; Sat, 6 Feb 88 21:52:32 PST Date: Sat, 6 Feb 88 21:52:32 PST From: Jon L White Message-Id: <8802070552.AA12948@bhopal.lucid.com> To: labrea!Moon%STONY-BROOK.SCRC.Symbolics.COM@labrea.Stanford.EDU Cc: labrea!Common-lisp-object-system%SAIL@labrea.Stanford.EDU In-Reply-To: David A. Moon's message of Fri, 5 Feb 88 14:40 EST <19880205194056.1.MOON@EUPHRATES.SCRC.Symbolics.COM> Subject: Typechecking re: Is there anyone who actually wants "should signal an error" and won't accept "results are undefined"? If not, let's change it. If so, that person should be agitating to change Common Lisp as well. It's on my list of "Clarifications" which need to be written up into cleanup proposals. The intent DEMANDED by many users is that there be one mode of compilation/execution that insures memory integrity and type surety. CLtL's universal excuses "it is an error" and "the results are undefined", isn't good enough to satisfy that; but Dick's attempt at phraseology "should signal an error" is close to what's needed. Certainly CLOS and Common Lisp need to follow the same conventions. There are numerous other places where the CLOS development has laid cleanup issues at the Common Lisp door [type-disjointness of some basic data types, "function specs" for setf generic methods, etc]. -- JonL --  Received: from Xerox.COM (TCP 1500006350) by AI.AI.MIT.EDU 6 Feb 88 21:27:10 EST Received: from Semillon.ms by ArpaGateway.ms ; 06 FEB 88 18:21:10 PST Date: Sat, 6 Feb 88 18:18 PST From: Gregor.pa@Xerox.COM Subject: bug in 2-3-88 beta release? To: John Alan McDonald cc: commonloops.PA@Xerox.COM, jam@entropy.ms.washington.edu Fcc: BD:>Gregor>mail>outgoing-mail-1.text In-Reply-To: <8802070152.AA11694@entropy.ms.washington.edu> Message-ID: <880206181859.6.GREGOR@SPIFF.parc.xerox.com> Line-fold: no Date: Sat, 6 Feb 88 17:52:18 PST From: jam%entropy.ms@beaver.cs.washington.edu (John Alan McDonald) For "beta test release of Febuary 3rd 1988", the walker chokes on in the following, under Symbolics Genera 7.1. This didn't happen in the Aug 87 release. Right, although I suspect the real bug was in the earlier release. The problem here is that zl:named-lambda is a special form which doesn't exist in Common Lisp. Many lisps have named-lambda though so what I have done is to teach the walker about named lambda in general and then tell it specifically that zl:named-lambda is the name of the named-lambda in zetalisp. To fix this for yourself, make the following changes to the walk.lisp file: After the line: (define-walker-template COND ..) Add these 2 lines: #+Symbolics (define-walker-template zl::named-lambda walk-named-lambda) After the defun of walk-lambda, add this definition: (defun walk-named-lambda (form context old-env) (walker-environment-bind (new-env old-env) (let* ((name (cadr form)) (arglist (caddr form)) (body (cdddr form)) (walked-arglist (walk-arglist arglist context new-env)) (walked-body (walk-declarations body #'walk-repeat-eval new-env))) (relist* form (car form) name walked-arglist walked-body)))) Then replace the definition of walk-template with this one: (defun walk-template (form template context env) (if (atom template) (ecase template ((EVAL FUNCTION TEST EFFECT RETURN) (walk-form-internal form :EVAL env)) ((QUOTE NIL) form) (SET (walk-form-internal form :SET env)) ((LAMBDA CALL) (if (symbolp form) form (walk-form-internal form context env)))) (case (car template) (REPEAT (walk-template-handle-repeat form (cdr template) ;; For the case where nothing happens ;; after the repeat optimize out the ;; call to length. (if (null (cddr template)) () (nthcdr (- (length form) (length (cddr template))) form)) context env)) (IF (walk-template form (if (if (listp (cadr template)) (eval (cadr template)) (funcall (cadr template) form)) (caddr template) (cadddr template)) context env)) (REMOTE (walk-template form (cadr template) context env)) (otherwise (cond ((atom form) form) (t (recons form (walk-template (car form) (car template) context env) (walk-template (cdr form) (cdr template) context env)))))))) These changes will all appear in the next version of PCL as well. -------  Received: from Xerox.COM (TCP 1500006350) by AI.AI.MIT.EDU 6 Feb 88 20:55:33 EST Received: from Cabernet.ms by ArpaGateway.ms ; 06 FEB 88 17:54:13 PST Return-Path: Redistributed: commonloops.PA Received: from beaver.cs.washington.edu by Xerox.COM ; 06 FEB 88 17:53:00 PST Received: by beaver.cs.washington.edu (5.52.1/6.12) id AA10758; Sat, 6 Feb 88 17:52:27 PST Return-Path: Received: by entropy.ms.washington.edu (5.52.1/6.2) id AA11694; Sat, 6 Feb 88 17:52:18 PST Date: Sat, 6 Feb 88 17:52:18 PST From: jam%entropy.ms@beaver.cs.washington.edu (John Alan McDonald) Message-Id: <8802070152.AA11694@entropy.ms.washington.edu> To: commonloops.PA@Xerox.COM Subject: bug in 2-3-88 beta release? Cc: jam@entropy.ms.washington.edu For "beta test release of Febuary 3rd 1988", the walker chokes on in the following, under Symbolics Genera 7.1. This didn't happen in the Aug 87 release. (defmethod graph-subclasses ((root-class Class) &key (stream *standard-output*) (include-root? t)) (fresh-line) (scl:format-graph-from-root (if include-root? root-class (direct-subclasses root-class)) #'(lambda (thing stream) (scl:with-character-style ('(:fix :roman :very-small)) (scl:present thing 'class :stream stream))) #'direct-subclasses :stream stream :root-is-sequence (not include-root?) :dont-draw-duplicates t :orientation :horizontal :border '(:shape :rectangle) :column-spacing 8 :within-column-spacing -2 :default-drawing-mode :line :test #'eq)) John Alan McDonald, Statistics, GN-22, U of W, Seattle, Wa. 98195 (206) 545 7438, 543 2517 jam@entropy.ms.washington.edu {decvax,ihnp4,ucbvax!lbl-csam}!uw-beaver!entropy!jam  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 6 Feb 88 14:50:10 EST Date: 06 Feb 88 1146 PST From: Dick Gabriel Subject: DEFGENERIC To: common-lisp-object-system@SAIL.Stanford.EDU The material for the behavior Moon specified does not look too bad when presented this way: defgeneric does an ensure-generic-function, it removes all methods defined by any previous defgeneric, and then it adds the methods specified by the :methods. The DEFCLASS description is similar. The presentation is clear and more concise than the desciption of the previous behavior. Anything more to change? -rpg-  Received: from Xerox.COM (TCP 1500006350) by AI.AI.MIT.EDU 6 Feb 88 14:00:36 EST Received: from Semillon.ms by ArpaGateway.ms ; 06 FEB 88 10:56:16 PST Date: Sat, 6 Feb 88 10:54 PST From: Gregor.pa@Xerox.COM Subject: CLOS (PCL) Compile problem To: JASPER%PITTVMS.BITNET@CUNYVM.CUNY.EDU, SULLIVAN%A.LRDC.PITTSBURGH.EDU@VB.CC.CMU.EDU cc: CommonLoops.pa@Xerox.COM Fcc: BD:>Gregor>mail>outgoing-mail-1.text In-Reply-To: The message of 6 Feb 88 00:26 PST from JASPER@PITTVMS.BITNET Message-ID: <880206105418.1.GREGOR@SPIFF.parc.xerox.com> Line-fold: no Date: Sat, 6 Feb 88 00:26:19 FROM: JASPER@PITTVMS.BITNET The defsys.lisp *pcl-files* param requires a low.lisp file. None such exists in the ftp able directory. Are we to simply stub an empty low.lisp fil;e so that my coral-low.lisp (in my case since I am using Coral Allegro CL for the Mac) has a module to use? Or am I missing something big here? You must have the low.lisp file to be able to use PCL. I just checked the /pub/pcl directory on parcvax and that file is there, perhaps it just didn't get copied the first time you ftp'd. Also, certain files like dcode-pre2.lisp don't seem to be used anymore, and braid2.lisp, while mentioned in a note no longer exists. I assume it has been phased out. dcode-pre2 and braid2 are no longer used. I have deleted these files and all mention of them from the directory and the source files. Gregor -------  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 6 Feb 88 13:51:49 EST Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 6 Feb 88 10:34:10 PST Received: from Semillon.ms by ArpaGateway.ms ; 06 FEB 88 10:34:43 PST Date: Sat, 6 Feb 88 10:34 PST From: Gregor.pa@Xerox.COM Subject: Re: Typechecking To: Patrick H Dussud cc: common-lisp-object-system@SAIL.STANFORD.EDU Fcc: BD:>Gregor>mail>outgoing-mail-1.text In-Reply-To: <2780084688-71255@Jenner> Message-ID: <880206103419.0.GREGOR@SPIFF.parc.xerox.com> Line-fold: no Date: Fri, 5 Feb 88 15:44:48 CST From: Patrick H Dussud Date: 05 Feb 88 1230 PST From: Dick Gabriel Subject: Typechecking Moon's message caused me to unwedge about what he was talking about. I am happy to specify the behavior of CLOS when stores violate the :type option as undefined. Do we have consensus? I agree this. Patrick. This is fine with me as well. -------  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 6 Feb 88 01:11:50 EST Date: 05 Feb 88 2205 PST From: Dick Gabriel Subject: Defgeneric To: common-lisp-object-system@SAIL.Stanford.EDU Moon writes: ``Dick, I don't know if I have convinced you of anything in the above. However, I have convinced myself of something. I no longer think....'' It convinced me of something too: I no longer have an opinion about what defgeneric does with old or new methods. I will attempt to write down some description of what you propose and place it in the document. I don't believe that the activities of defclass in this regard are accurately stated either. I will similarly write that down, possibly in some common section to which defgeneric and defclass both refer. Your Friendly Writer -rpg-  Received: from Xerox.COM (TCP 1500006350) by AI.AI.MIT.EDU 6 Feb 88 00:42:06 EST Received: from Semillon.ms by ArpaGateway.ms ; 05 FEB 88 21:38:46 PST Return-Path: <@CUNYVM.CUNY.EDU:JASPER@pittvms.BITNET> Redistributed: CommonLoops.pa Received: from CUNYVM.CUNY.EDU by Xerox.COM ; 05 FEB 88 21:36:55 PST Received: from pittvms.BITNET by CUNYVM.CUNY.EDU ; Sat, 06 Feb 88 00:36:25 EST Date: Sat, 6 Feb 88 00:26:19 FROM: JASPER%PITTVMS.BITNET@CUNYVM.CUNY.EDU SUBJECT: CLOS (PCL) Compile problem TO: CommonLoops.pa@Xerox.COM Message-ID: <880205-213846-3729@Xerox> The defsys.lisp *pcl-files* param requires a low.lisp file. None such exists in the ftp able directory. Are we to simply stub an empty low.lisp fil;e so that my coral-low.lisp (in my case since I am using Coral Allegro CL for the Mac) has a module to use? Or am I missing something big here? Also, certain files like dcode-pre2.lisp don't seem to be used anymore, and braid2.lisp, while mentioned in a note no longer exists. I assume it has been phased out. Jeffrey Sullivan JASPER@PittVMS.BITNET jasst3@cisunx.UUCP SULLIVAN%A.LRDC.PITTSBURGH.EDU@VB.CC.CMU.EDU  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 5 Feb 88 22:41:04 EST Received: from RELAY.CS.NET by SAIL.Stanford.EDU with TCP; 5 Feb 88 19:35:58 PST Received: from relay2.cs.net by RELAY.CS.NET id ab27993; 5 Feb 88 19:39 EST Received: from csc.ti.com by RELAY.CS.NET id ab05375; 5 Feb 88 19:32 EST Received: from Jenner by tilde id AA03312; Fri, 5 Feb 88 16:41:13 CST Message-Id: <2780084688-71255@Jenner> Date: Fri, 5 Feb 88 15:44:48 CST From: Patrick H Dussud To: common-lisp-object-system@SAIL.STANFORD.EDU Subject: Re: Typechecking In-Reply-To: Msg of 05 Feb 88 1230 PST from Dick Gabriel Date: 05 Feb 88 1230 PST From: Dick Gabriel Subject: Typechecking Moon's message caused me to unwedge about what he was talking about. I am happy to specify the behavior of CLOS when stores violate the :type option as undefined. Do we have consensus? I agree this. Patrick.  Received: from Xerox.COM (TCP 1500006350) by AI.AI.MIT.EDU 5 Feb 88 20:09:58 EST Received: from Salvador.ms by ArpaGateway.ms ; 05 FEB 88 17:01:03 PST Return-Path: Redistributed: commonloops.PA Received: from csv.rpi.edu (cs.rpi.edu) by Xerox.COM ; 05 FEB 88 16:59:29 PST Received: by csv.rpi.edu (5.54/1.14) id AA23903; Fri, 5 Feb 88 20:00:15 EST Date: Fri, 5 Feb 88 20:00:15 EST From: verzullj@csv.rpi.edu (Joseph Verzulli) Message-Id: <8802060100.AA23903@csv.rpi.edu> To: commonloops.PA@Xerox.COM Please add my name to the CommonLoops mailing list. Joe Verzulli  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 5 Feb 88 16:42:20 EST Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 5 Feb 88 13:34:11 PST Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 337094; Fri 5-Feb-88 16:34:14 EST Date: Fri, 5 Feb 88 16:34 EST From: David A. Moon Subject: defgeneric :method option To: Common-Lisp-Object-System@SAIL.STANFORD.EDU In-Reply-To: <19880119164517.8.MOON@EUPHRATES.SCRC.Symbolics.COM>, <19880119195151.1.MOON@EUPHRATES.SCRC.Symbolics.COM>, <880119-154316-2487@Xerox>, The message of 21 Jan 88 17:28 EST from Dick Gabriel Message-ID: <19880205213415.6.MOON@EUPHRATES.SCRC.Symbolics.COM> This issue is still open: when a defgeneric is evaluated with a :method option, and then evaluated again without the :method option, does the method go away, reflecting the updated defgeneric, or does the method stay around? Date: Tue, 19 Jan 88 11:45 EST From: David A. Moon It wouldn't bother me a bit if we changed the language to require all implementations to remove methods that were created by a defgeneric, if the defgeneric were re-evaluated without the :method. We already do this for accessor methods created by defclass. We're now saying that the class remembers the specific method objects and removes them if they are still there; if they've already been replaced by a defmethod, it doesn't remove the method put there by the defmethod. What would bother me would be if we required all implementations to be stupid about this. So how about it? Shall we change CLOS so that re-evaluating a defgeneric removes methods that were previously defined by :method, but no longer appear in the new defgeneric form? I think we should. Date: Tue, 19 Jan 88 14:51 EST From: David A. Moon Date: 19 Jan 88 09:37 PST From: Danny Bobrow I think that's a good idea. Should we specify how defgeneric knows that a method was defined by :method. We could use a predicate or we could make :method specified methods be a subclass of defgeneric-method. This similar to how accessors methods are specified, and is what I reecommend. We decided at our last meeting that each class has a slot in which it remembers a list of the defclass-defined methods. Date: 19 Jan 88 15:40 PST From: Danny Bobrow From: Moon I think defgeneric should handle its specially-defined methods in exactly the same way that defclass handles its. I agree. We decided at our last meeting that each class has a slot in which it remembers a list of the defclass-defined methods. I'm not imagining this, am I? I remember that idea winning out over giving each method a slot that says how it was defined or having defclass-defined methods be a special subclass. I don't remember this, but my memory and notes are not to be trusted. Do you remember any of the arguments for this decision. An argument against this is that it implies that remove-method, and add-method that overrides must both be cognizant of (side-effect) this list in this slot. No, it doesn't imply that. The class remembers the method objects that it added to the generic function. It's not required that if someone else removes those method objects, they be removed from the class's list. Instead, when the class uses its list, it checks whether each method is still known by the generic function. This is what I remember us concluding at our last meeting. This works because Gregor argued down my idea that defmethod updates an existing method object, instead of creating a new one that replaces any previous one for the same generic function, specializers, and qualifiers. Date: 21 Jan 88 1428 PST From: Dick Gabriel I think defgeneric should handle its specially-defined methods in exactly the same way that defclass handles its. I'm not sure what the specially-defined methods might be for a defgeneric. All methods defined with the :method option. My reading of the specification states that if some method descriptions are supplied some methods are defined, but none of those are specially defined in the manner that they are using defclass - in the defclass case I suppose the specialness is tied up with the fact that they are implicitly defined, though at the behest of the :reader, :writer, or :accessor options. I notice no other methods mentioned. The model currently stated is clear - defgeneric is semantically equivalent to an ensure-generic-function and a series of defmethod's. It's true that the model currently stated is clear. However, it has a bad consequence, which is that evaluating a defgeneric form multiple times has a different effect from evaluating the final version once. None of CLOS's other defxxx forms have that property. I'm proposing to change the model to a different model, which is also clear: defgeneric is semantically equivalent to an ensure-generic-function, a series of defmethod's whose values (method objects) are remembered, a series of remove-method's of the remembered values from last time, and a setf to remember the values for next time. This model certainly involves more parts than the previous model, but that's not surprising. I don't think there is anything unclear about it. (progn (ensure-generic-function 'name :blah blah blah) (let ((methods (list (defmethod name blah blah blah) (defmethod name blah blah blah) ...)) (generic (symbol-function 'name))) (dolist (method (generic-function-locally-defined-methods generic)) (remove-method generic method)) (setf (generic-function-locally-defined-methods generic) methods) generic)) I see no obvious parallel with defclass. With defclass, the ``specially-defined'' methods are so defined according to a strong convention that we have imposed - we would all be surprised to see people write simple defclass forms and then a series of defmethod's to build up the readers and writers. Not at all. When I said exactly this, several months ago, someone (I think it was Gregor) called me wedged and said that it was very important that the user could just as well write reader and writer methods with defmethod and get the same performance as when using the slot-option. The only difference is that defgeneric lets you define any kind of method, whereas defclass only lets you define some very specific, stereotyped methods. But the method-defining parts of defgeneric are for completeness only - we do not advocate that people write method definitions within defgeneric forms. If people do not like the fact that re-loading defgeneric forms doesn't do what they want, then they can re-write them as simpler defgeneric's and defmethod's, and they will be obeying classic object-oriented style all the more if they do. I really object to that. What you're saying is that we're going to document this :method feature of defgeneric, but then we're going to tell them that it doesn't work very well, so they shouldn't use it. In that case we would be much better off removing it from the language entirely. So I am against treating these methods in a manner analogous to those defined by defclass. Dick, I don't know if I have convinced you of anything in the above. However, I have convinced myself of something. I no longer think that the current state of CLOS is acceptable. To be an acceptable standard, I now feel that we must either remove the :method feature from defgeneric, or else we must make defgeneric remember the methods that it defines and remove them when evaluated a second time. Either of those alternatives would be acceptable to me, although naturally I prefer the second since it makes defgeneric more consistent with generic-flet.  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 5 Feb 88 16:15:07 EST Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 5 Feb 88 13:10:08 PST Received: from Cabernet.ms by ArpaGateway.ms ; 05 FEB 88 13:00:34 PST Date: 5 Feb 88 13:00 PST Sender: Bobrow.pa@Xerox.COM From: Danny Bobrow Subject: Re: Typechecking In-reply-to: Dick Gabriel 's message of 05 Feb 88 12:30 PST To: RPG@SAIL.Stanford.EDU cc: common-lisp-object-system@SAIL.Stanford.EDU Message-ID: <880205-130034-2896@Xerox> Moon's message caused me to unwedge about what he was talking about. I am happy to specify the behavior of CLOS when stores violate the :type option as undefined. Do we have consensus? -rpg- Fine danny  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 5 Feb 88 15:35:34 EST Date: 05 Feb 88 1230 PST From: Dick Gabriel Subject: Typechecking To: common-lisp-object-system@SAIL.Stanford.EDU Moon's message caused me to unwedge about what he was talking about. I am happy to specify the behavior of CLOS when stores violate the :type option as undefined. Do we have consensus? -rpg-  Received: from Xerox.COM (TCP 1500006350) by AI.AI.MIT.EDU 5 Feb 88 15:29:08 EST Received: from Semillon.ms by ArpaGateway.ms ; 05 FEB 88 12:08:29 PST Date: Fri, 5 Feb 88 12:05 PST From: Gregor.pa@Xerox.COM Subject: new version of PCL To: CommonLoops.pa@Xerox.COM Message-ID: <880205120514.1.GREGOR@SPIFF.parc.xerox.com> Line-fold: no There is a new version of PCL on parcvax.xerox.com. This version has only a couple of changes from the one of a couple of days ago, but these changes may be significant to some users. - call-next-method is now a proper lexically defined function within the body of defmethod. It is possible to pass funargs which include it and all that stuff. - a potentially significant performance bug has been fixed. In some benchmarks, fixing this bug resulted in a 33% improvement in the running speed of the system. I don't think this bug will improve the problems with compilation speeds in some Lisps. -------  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 5 Feb 88 14:47:55 EST Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 5 Feb 88 11:40:49 PST Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 336904; Fri 5-Feb-88 14:40:48 EST Date: Fri, 5 Feb 88 14:40 EST From: David A. Moon Subject: Typechecking To: Common-lisp-object-system@SAIL.STANFORD.EDU In-Reply-To: The message of 28 Jan 88 00:28 EST from Dick Gabriel Message-ID: <19880205194056.1.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: 27 Jan 88 2128 PST From: Dick Gabriel I think Moon must have gotten a bad chapter 1, because I cannot find the quote he mentions in the file that I consider to be the definitive version. It's there, and you quoted it yourself. You were just misled because I extracted part of a sentence without putting in ellipses. But let's forget that. The important quote is "Attempting to store a value in a slot that does not satisfy the type should signal an error", as you pointed out. I never should have drawn attention to the later quote which is just amplifying on this. Chapter 1 defines "should signal an error" to mean "an error will be signaled at least in the interpreter and in code compiled under the safest compiler safety optimization level." I still object to what chapter 1 currently says about the :type slot option. To rephrase what I said before: Sometime between August and November the definition of the :type slot option was changed from "An implementation may or may not choose to check the type of the new value when initializing or assigning to a slot" to "Attempting to store a value in a slot that does not satisfy the type should signal an error". It is not consistent with CLtL's definition of the :type slot option in defstruct and the type declaration for variables. Violation of those type constraints "is an error" according to CLtL. The choices we have available to us are to require checking in all cases, to require checking in at least the safest compiler compilation setting and the interpreter, or to let the results be undefined. Stock hardware people reject the first, and special-purpose people reject the last (they want the results to be defined - to signal an error). This "special-purpose person" does not -- I want type-checking of slot values to be optional. I want the results to be undefined, as that phrase is defined in the front of chapter 1. What I -really- want is for CLOS and the rest of Common Lisp to be consistent on this issue. As long as the rest of Common Lisp continues to say that the results are undefined, CLOS should say the same. Therefore, it has to be ``should signal an error.'' We agreed long ago to abide by this error terminology, and I won't accept backing down on that now. I don't object to the terminology for describing the semantics, only to which semantics was chosen. Is there anyone who actually wants "should signal an error" and won't accept "results are undefined"? If not, let's change it. If so, that person should be agitating to change Common Lisp as well.  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 5 Feb 88 14:47:53 EST Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 5 Feb 88 11:41:13 PST Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 336905; Fri 5-Feb-88 14:41:17 EST Date: Fri, 5 Feb 88 14:41 EST From: David A. Moon Subject: Typechecking To: Common-lisp-object-system@SAIL.STANFORD.EDU In-Reply-To: The message of 28 Jan 88 00:28 EST from Dick Gabriel Supersedes: <19880205194056.1.MOON@EUPHRATES.SCRC.Symbolics.COM> Message-ID: <19880205194124.2.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: 27 Jan 88 2128 PST From: Dick Gabriel I think Moon must have gotten a bad chapter 1, because I cannot find the quote he mentions in the file that I consider to be the definitive version. It's there, and you quoted it yourself. You were just misled because I extracted part of a sentence without putting in ellipses. But let's forget that. The important quote is "Attempting to store a value in a slot that does not satisfy the type should signal an error", as you pointed out. I never should have drawn attention to the later quote which is just amplifying on this. Chapter 1 defines "should signal an error" to mean "an error will be signaled at least in the interpreter and in code compiled under the safest compiler safety optimization level." I still object to what chapter 1 currently says about the :type slot option. To rephrase what I said before: Sometime between August and November the definition of the :type slot option was changed from "An implementation may or may not choose to check the type of the new value when initializing or assigning to a slot" to "Attempting to store a value in a slot that does not satisfy the type should signal an error". It is not consistent with CLtL's definition of the :type slot option in defstruct and the type declaration for variables. Violation of those type constraints "is an error" according to CLtL. The choices we have available to us are to require checking in all cases, to require checking in at least the safest compiler compilation setting and the interpreter, or to let the results be undefined. Stock hardware people reject the first, and special-purpose people reject the last (they want the results to be defined - to signal an error). This "special-purpose person" does not -- I want type-checking of slot values to be optional. I want the results to be undefined, as that phrase is defined in the front of chapter 1. What I -really- want is for CLOS and the rest of Common Lisp to be consistent on this issue. As long as the rest of Common Lisp continues to say that the results are undefined, CLOS should say the same. Therefore, it has to be ``should signal an error.'' We agreed long ago to abide by this error terminology, and I won't accept backing down on that now. I don't object to the terminology for describing the semantics, only to which semantics was chosen. Is there anyone who actually wants "should signal an error" and won't accept "results are undefined"? If so, that person should be agitating to change Common Lisp as well. If not, let's change it (that is, let's change it -back-).  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 5 Feb 88 14:07:10 EST Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 5 Feb 88 11:01:25 PST Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 336877; Fri 5-Feb-88 13:59:14 EST Date: Fri, 5 Feb 88 13:59 EST From: David A. Moon Subject: Re: Type-checking of slot values To: kempf%hplabsz@hplabs.HP.COM cc: Jon L White , common-lisp-object-system@SAIL.STANFORD.EDU In-Reply-To: <352.570317112@hplabsz> Message-ID: <19880205185920.0.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Wed, 27 Jan 88 13:25:12 PST From: kempf%hplabsz@hplabs.HP.COM I had, at one time, proposed a set of primitives to freeze the class structure about a certain class, but there appeared to be little or no interest in this idea, and it somehow got dropped. This would allow an instance implementation with one level of indirection, but attempts to change the class would signal an error. I'm interested in this, and think it should not be dropped. I'm just not interested in personally contributing to writing it up, since I have no expertise in this area and plenty of other things to do instead. I'd like to encourage you to keep pursuing it.  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 5 Feb 88 13:54:26 EST Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 5 Feb 88 10:48:12 PST Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 336862; 5 Feb 88 13:48:14 EST Date: Fri, 5 Feb 88 13:48 EST From: David A. Moon Subject: Re: Naming To: common-lisp-object-system@SAIL.STANFORD.EDU In-Reply-To: <880204-165404-1377@Xerox> Supersedes: <19880205184244.7.MOON@EUPHRATES.SCRC.Symbolics.COM> Comments: Added a note in response to "At this point I believe that compelling arguments must be made for even small changes." Message-ID: <19880205184818.8.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: 4 Feb 88 16:53 PST From: Danny Bobrow We need to decide by the end of the weekend what to do about naming. I strongly hesitate to make the change (if it can be said that one can strongly hesitate). If we make the change I prefer the terms NAME- over SYMBOL-. I worry that we will make an ugly mistake in doing this. To avoid such ugliness, let us leave symbol-class and (setf symbol-class) with a restriction to symbols. However, let us take out any restriction about what can be stored/returned from class-name. Then the dynamic-class hack can work using its own class lookup mechanism, and class-name can contain the hint about what the class is. Yes. Only a symbol can be a proper name, and non-symbol values for class-name are only hints. In a discussion last fall (I think), we had already decided that class-name was a hint, and wasn't necessarily always the proper name. What Danny is proposing here is what I thought all along I was proposing, however I was too distracted to produce a coherent wording. I apologize for the digression, and thank Danny for bringing us back to earth. I never meant to propose some elaborate new naming scheme, only to propose that the hints returned by class-name need not be symbols. By the way, I don't think this is a change. I think class-name was not restricted in type up until recently when as a side-effect of making the document clearer and more specific, a type restriction was put in by accident. So we're just saying that that was an accident, rather than an intention, and hence should be undone before publication.  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 5 Feb 88 13:47:44 EST Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 5 Feb 88 10:42:34 PST Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 336852; Fri 5-Feb-88 13:42:36 EST Date: Fri, 5 Feb 88 13:42 EST From: David A. Moon Subject: Re: Naming To: common-lisp-object-system@SAIL.STANFORD.EDU In-Reply-To: <880204-165404-1377@Xerox> Message-ID: <19880205184244.7.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: 4 Feb 88 16:53 PST From: Danny Bobrow We need to decide by the end of the weekend what to do about naming. I strongly hesitate to make the change (if it can be said that one can strongly hesitate). If we make the change I prefer the terms NAME- over SYMBOL-. I worry that we will make an ugly mistake in doing this. To avoid such ugliness, let us leave symbol-class and (setf symbol-class) with a restriction to symbols. However, let us take out any restriction about what can be stored/returned from class-name. Then the dynamic-class hack can work using its own class lookup mechanism, and class-name can contain the hint about what the class is. Yes. Only a symbol can be a proper name, and non-symbol values for class-name are only hints. In a discussion last fall (I think), we had already decided that class-name was a hint, and wasn't necessarily always the proper name. What Danny is proposing here is what I thought all along I was proposing, however I was too distracted to produce a coherent wording. I apologize for the digression, and thank Danny for bringing us back to earth. I never meant to propose some elaborate new naming scheme, only to propose that the hints returned by class-name need not be symbols.  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 5 Feb 88 13:11:42 EST Date: 05 Feb 88 0948 PST From: Dick Gabriel Subject: CONCEP and FUNCTI To: common-lisp-object-system@SAIL.Stanford.EDU There are new CONCEP and FUNCTI .TEX and .DVI files on SAIL. These incorporate Danny's comments and the infamous (class-name ) = junk change. The impact of this latter change is minimal because many things deal with proper names, which are still symbols. For example, defclass and parameter specializers all either define proper names or take symbols as the names of classes. We hope to send these two chapters to X3J13 monday. -rpg-  Received: from Xerox.COM (TCP 1500006350) by AI.AI.MIT.EDU 5 Feb 88 13:10:14 EST Received: from Semillon.ms by ArpaGateway.ms ; 05 FEB 88 09:58:01 PST Date: Fri, 5 Feb 88 09:55 PST From: Gregor.pa@Xerox.COM Subject: test message To: CommonLoops.PA@Xerox.COM Message-ID: <880205095514.5.GREGOR@SPIFF.parc.xerox.com> Line-fold: no This is a test message, please delete it. #6 sent from Spiff, after fixing ida-cl address. All addresses should noW be OK except deferreds? -------  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 5 Feb 88 11:46:30 EST Received: from RELAY.CS.NET by SAIL.Stanford.EDU with TCP; 5 Feb 88 08:39:03 PST Received: from relay2.cs.net by RELAY.CS.NET id aa20259; 5 Feb 88 11:00 EST Received: from csc.ti.com by RELAY.CS.NET id ac00992; 5 Feb 88 10:52 EST Received: from Jenner by tilde id AA21556; Fri, 5 Feb 88 07:23:59 CST Message-Id: <2780054729-2276568@Jenner> Date: Fri, 5 Feb 88 07:25:29 CST From: Patrick H Dussud To: Danny Bobrow Cc: common-lisp-object-system@SAIL.STANFORD.EDU Subject: Re: Naming In-Reply-To: Msg of 4 Feb 88 16:53 PST from Danny Bobrow We need to decide by the end of the weekend what to do about naming. I strongly hesitate to make the change (if it can be said that one can strongly hesitate). If we make the change I prefer the terms NAME- over SYMBOL-. I worry that we will make an ugly mistake in doing this. To avoid such ugliness, let us leave symbol-class and (setf symbol-class) with a restriction to symbols. However, let us take out any restriction about what can be stored/returned from class-name. I agree. Patrick.  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 4 Feb 88 20:19:40 EST Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 4 Feb 88 17:14:39 PST Received: from Semillon.ms by ArpaGateway.ms ; 04 FEB 88 17:15:06 PST Date: Thu, 4 Feb 88 17:14 PST From: Gregor.pa@Xerox.COM Subject: Re: Naming To: Danny Bobrow cc: RPG@SAIL.STANFORD.EDU, common-lisp-object-system@SAIL.STANFORD.EDU Fcc: BD:>Gregor>mail>outgoing-mail-1.text In-Reply-To: <880204-165404-1377@Xerox> Message-ID: <880204171452.7.GREGOR@SPIFF.parc.xerox.com> Line-fold: no Date: 4 Feb 88 16:53 PST From: Danny Bobrow We need to decide by the end of the weekend what to do about naming. I strongly hesitate to make the change (if it can be said that one can strongly hesitate). If we make the change I prefer the terms NAME- over SYMBOL-. I worry that we will make an ugly mistake in doing this. To avoid such ugliness, let us leave symbol-class and (setf symbol-class) with a restriction to symbols. However, let us take out any restriction about what can be stored/returned from class-name. Then the dynamic-class hack can work using its own class lookup mechanism, and class-name can contain the hint about what the class is. Right. -------  Received: from Xerox.COM (TCP 1500006350) by AI.AI.MIT.EDU 4 Feb 88 20:12:51 EST Received: from Semillon.ms by ArpaGateway.ms ; 04 FEB 88 17:08:58 PST Date: Thu, 4 Feb 88 17:07 PST From: Gregor.pa@Xerox.COM Reply-To: Gregor@GRAPEVINE.parc.xerox.com Subject: performance of new PCL To: CommonLoops.PA@Xerox.COM Message-ID: <880204170727.4.GREGOR@SPIFF.parc.xerox.com> Line-fold: no Some people using the newest version of PCL have complained that their programs now compile and load much more slowly than they did before. I am trying to track down this problem, and in order to do I need to know exactly which Common Lisps it happens in. If you have noticed that in the new version of PCL your programs compile and load more slowly than before, please send me a message which includes: 1. The lisp implementation and version you are using. 2. About how much slower you think it compiles (a precise number would be even better if possible). 3. About how much slower you think it loads (a precise number would be even better if possible). Gregor -------  Received: from Xerox.COM (TCP 1500006350) by AI.AI.MIT.EDU 4 Feb 88 20:02:32 EST Received: from Semillon.ms by ArpaGateway.ms ; 04 FEB 88 16:58:50 PST Date: Thu, 4 Feb 88 16:56 PST From: Gregor.pa@Xerox.COM Subject: test message To: CommonLoops.PA@Xerox.COM Message-ID: <880204165654.2.GREGOR@SPIFF.parc.xerox.com> Line-fold: no This is a test message, please delete it. #4 Sent to CommonLoops from Spiff. After deleting some erroneous entries like the ones at xv.mit.edu. -------  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 4 Feb 88 20:00:45 EST Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 4 Feb 88 16:53:46 PST Received: from Cabernet.ms by ArpaGateway.ms ; 04 FEB 88 16:54:04 PST Date: 4 Feb 88 16:53 PST Sender: Bobrow.pa@Xerox.COM From: Danny Bobrow Subject: Re: Naming In-reply-to: Dick Gabriel 's message of 04 Feb 88 16:31 PST To: RPG@SAIL.Stanford.EDU cc: common-lisp-object-system@SAIL.Stanford.EDU Message-ID: <880204-165404-1377@Xerox> We need to decide by the end of the weekend what to do about naming. I strongly hesitate to make the change (if it can be said that one can strongly hesitate). If we make the change I prefer the terms NAME- over SYMBOL-. I worry that we will make an ugly mistake in doing this. To avoid such ugliness, let us leave symbol-class and (setf symbol-class) with a restriction to symbols. However, let us take out any restriction about what can be stored/returned from class-name. Then the dynamic-class hack can work using its own class lookup mechanism, and class-name can contain the hint about what the class is.  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 4 Feb 88 19:38:15 EST Date: 04 Feb 88 1631 PST From: Dick Gabriel Subject: Naming To: common-lisp-object-system@SAIL.Stanford.EDU We need to decide by the end of the weekend what to do about naming. I strongly hesitate to make the change (if it can be said that one can strongly hesitate). If we make the change I prefer the terms NAME- over SYMBOL-. I worry that we will make an ugly mistake in doing this. -rpg-  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 4 Feb 88 18:35:40 EST Received: from labrea.Stanford.EDU by SAIL.Stanford.EDU with TCP; 4 Feb 88 15:30:43 PST Received: by labrea.Stanford.EDU; Thu, 4 Feb 88 15:31:02 PST Received: from bhopal.lucid.com by edsel id AA09098g; Thu, 4 Feb 88 14:42:19 PST Received: by bhopal id AA01035g; Thu, 4 Feb 88 14:46:35 PST Date: Thu, 4 Feb 88 14:46:35 PST From: Jon L White Message-Id: <8802042246.AA01035@bhopal.lucid.com> To: labrea!Bobrow.pa%Xerox.COM@labrea.Stanford.EDU Cc: labrea!Common-Lisp-Object-System%Sail@labrea.Stanford.EDU In-Reply-To: Danny Bobrow's message of 3 Feb 88 18:22 PST <880203-182309-3472@Xerox> Subject: Comments on most recent draft: Chap 1 and 2 re: . . . Should it say that: "CLOS may be extended to cover situations in which foo is not a symbol." Very good. I think that is the preferred wording, given that page of chapter 1 about error conditions etc. re: But, haven't we already extended symbol-function to take lists of the form (setf fn) as an argument. If not, how do we get hold of setf generic-functions? I don't recall how the recent discussions on this mailing list suggested to do it. A reasonable user-extensible naming scheme, such as Interlisp's "typed definitions" system or the LispMachine's function specs, would have form-specific ways to access the created definitions. That is, when you defined (setf fn) to be a "function spec" or whatever, you would provide creator, accessor, (and possibly) modifer functions. -- JonL --  Received: from Xerox.COM (TCP 1500006350) by AI.AI.MIT.EDU 4 Feb 88 16:12:02 EST Received: from Salvador.ms by ArpaGateway.ms ; 04 FEB 88 13:04:26 PST Return-Path: Redistributed: commonloops.pa Received: from WILMA.BBN.COM by Xerox.COM ; 04 FEB 88 13:02:46 PST To: commonloops.pa@Xerox.COM Cc: kanderson@WILMA.BBN.COM Subject: PCL on LMI machines? Date: Thu, 04 Feb 88 15:53:56 -0500 From: kanderso@WILMA.BBN.COM Message-ID: <880204-130426-1128@Xerox> Does PCL run on LMI machines? k  Received: from Xerox.COM (TCP 1500006350) by AI.AI.MIT.EDU 4 Feb 88 12:42:46 EST Received: from Semillon.ms by ArpaGateway.ms ; 04 FEB 88 09:36:01 PST Date: Thu, 4 Feb 88 09:34 PST From: Gregor.pa@Xerox.COM Subject: test message To: CommonLoops.PA@Xerox.COM Message-ID: <880204093400.3.GREGOR@SPIFF.parc.xerox.com> Line-fold: no This is a test message, please delete it. #3, Sent to CommonLoops.pa from Spiff. After converting all bitnet and csnet entries and fixing uk entries. -------  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 4 Feb 88 01:39:07 EST Date: 03 Feb 88 2235 PST From: Dick Gabriel Subject: Names To: common-lisp-object-system@SAIL.Stanford.EDU If you don't think there is any reason to want to discriminate against non-symbols as names, then why call the function SYMBOL-CLASS? Why not name it NAME-CLASS? Then X is a proper name if (CLASS-NAME ) = X and (NAME-CLASS X) = . If you do this, isn't there some other functionailty you'd like to specify about names, like associating a name with an object, like registering names (default, intern), mapping over them (default, do-symbols), destroying them (default, ???)...? If you go beyond function specs into the realm of class names, what about the other naming contexts in Common Lisp: types, variables...? If you eliminate SYMBOL-CLASS and use NAME-CLASS, are implementations free to use SYMBOL-VALUE to implement NAME-CLASS? Or is there also the thing meant by the old SYMBOL-CLASS that is used when symbols are specified as the names? Does this mean that NAME-CLASS must be a generic function? Chapters 1 and 2 specify a possible world as implementable by chapter 3. mechanisms. By selecting that world we eliminate possibilities from it. This doesn't mean that an adjacent world cannot be different. I don't feel that we have considered enough of the can of worms opened by general naming to want to casually introduce it into our nice little world. -rpg-  Received: from Xerox.COM (TCP 1500006350) by AI.AI.MIT.EDU 3 Feb 88 22:29:58 EST Received: from Semillon.ms by ArpaGateway.ms ; 03 FEB 88 18:29:34 PST Date: Wed, 3 Feb 88 18:26 PST From: Gregor.pa@Xerox.COM Reply-To: Gregor@GRAPEVINE.parc.xerox.com Subject: 2 things To: CommonLoops.pa@Xerox.COM, CommonLoopsExternal^.x@Xerox.COM Message-ID: <880203182614.0.GREGOR@SPIFF.parc.xerox.com> Line-fold: no Many of you will receive two versions of this message. I apologize for the inconvenience. The mailing list is being moved from one machine to another and this is the only way to make sure everyone gets a copy of this message. If it makes you feel better, I think I will be getting 4 copies myself. In the next few days, if you send mail to the list, you may get error messages back. Please ignore them for now. Also, there is a new version of PCL on parcvax.xerox.com. This version fixes some minor problems people have been having. - the file test.lisp should now work. - some problems with method combination doing wild things in some Lisps should be fixed. Most of you probably didn't notice this unless you tried playing around with the combin-test file. - the :prefix option to the old with-slots macro was broken, now it is fixed again. - the file defsys has changed somewhat. It now defines a macro called defsystem and a function operate-on-system which you can use for compiling your own systems. The documentation of the precompile-random-code-segments facility is now written in terms of this defsystem facility. -------  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 3 Feb 88 21:28:06 EST Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 3 Feb 88 18:22:36 PST Received: from Cabernet.ms by ArpaGateway.ms ; 03 FEB 88 18:23:09 PST Date: 3 Feb 88 18:22 PST Sender: Bobrow.pa@Xerox.COM From: Danny Bobrow Subject: Re: Comments on most recent draft: Chap 1 and 2 In-reply-to: Jon L White 's message of Wed, 3 Feb 88 14:37:51 PST To: edsel!jonl@labrea.Stanford.EDU cc: Common-Lisp-Object-System@Sail.stanford.edu Message-ID: <880203-182309-3472@Xerox> X3J13 may take on the task of extending the naming schemes (such as "function specs', but possibly something else), so you probably wouldn't want to specify something in CLOS that would be at variance with that. In that light, I would say that requiring EQL for the name-equivalence predicate is a bad idea; EQUAL or something broader may be better. Best of all would be to avoid any unnecessary entanglements in CLOS for now by just not specifying what isn't really needed. I would be happy with this. Would this take the form of not saying what happens for (symbol-class foo) and (setf (symbol-class foo) bar) when foo is not a symbol. Should it say that: "CLOS may be extended to cover situations in which foo is not a symbol." Similarly for class-name. I would be happy to use the "extended" clause for symbol-class, and simply not say anything about class-name. But, haven't we already extended symbol-function to take lists of the form (setf fn) as an argument. If not, how do we get hold of setf generic-functions?  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 3 Feb 88 18:37:32 EST Received: from labrea.Stanford.EDU by SAIL.Stanford.EDU with TCP; 3 Feb 88 15:32:09 PST Received: by labrea.Stanford.EDU; Wed, 3 Feb 88 15:32:23 PST Received: from bhopal.lucid.com by edsel id AA01307g; Wed, 3 Feb 88 14:33:40 PST Received: by bhopal id AA11606g; Wed, 3 Feb 88 14:37:51 PST Date: Wed, 3 Feb 88 14:37:51 PST From: Jon L White Message-Id: <8802032237.AA11606@bhopal.lucid.com> To: labrea!Bobrow.pa%Xerox.COM@labrea.Stanford.EDU Cc: labrea!common-lisp-object-system%SAIL@labrea.Stanford.EDU In-Reply-To: Danny Bobrow's message of 2 Feb 88 10:16 PST <880202-101638-2198@Xerox> Subject: Comments on most recent draft: Chap 1 and 2 re: . . . Two names are the same if they are eql. The function symbol-class takes a name and returns the class associated with that name, or nil if there is none. X3J13 may take on the task of extending the naming schemes (such as "function specs', but possibly something else), so you probably wouldn't want to specify something in CLOS that would be at variance with that. In that light, I would say that requiring EQL for the name-equivalence predicate is a bad idea; EQUAL or something broader may be better. Best of all would be to avoid any unnecessary entanglements in CLOS for now by just not specifying what isn't really needed. Also, isn't it true that SYMBOL-CLASS only takes a symbol, not a "generalized" name? (In the broader sense, a better name for this functionality might be FIND-CLASS). At any rate, using a name like SYMBOL-CLASS, which implies parallels to SYMBOL-VALUE and SYMBOL-FUNCTION, and overgeneralizing it to whatever nomenclature scheme comes up seems like a real misdirection. Incidentally, having *no* name for a class (I'm not talking about symbols as names) makes it hard to talk about a type specifier that refers to that class. Is is really so bad that anonymous classes can't be named in type specifiers? if they can't be named at all (i.e., "has no name") then why should the conventions for type names be changed? -- JonL --  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 3 Feb 88 17:55:24 EST Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 3 Feb 88 14:49:17 PST Received: from Semillon.ms by ArpaGateway.ms ; 03 FEB 88 14:34:25 PST Date: Wed, 3 Feb 88 14:34:06 PST From: Ken Kahn Subject: Re: Names, Names In-Reply-To: <880203-102025-2482@Xerox> To: Danny Bobrow cc: RPG@SAIL.Stanford.EDU, Common-Lisp-object-system@SAIL.Stanford.EDU Message-ID: <880203-143425-3082@Xerox> > Not if the criterion is that symbol-class does an eql look-up, and class-name > is insensitive to type. Then ordinary users can write a structure to > eql intern for any structure they care to use, and use symbol-class to > find the associated class. If you do this, then I suggest you rename symbol-class. References Bobrow's message of Wed, 3 Feb 88 10:19:00 PST -- Re: Names, Names  Received: from Xerox.COM (TCP 1500006350) by AI.AI.MIT.EDU 3 Feb 88 16:01:06 EST Received: from Semillon.ms by ArpaGateway.ms ; 03 FEB 88 12:14:57 PST Return-Path: <@SPAR-20.SPAR.SLB.COM,@KATYDID.SPAR.SLB.COM:Carnese@SPAR.SLB.COM> Redistributed: commonloops.pa Received: from SPAR-20.SPAR.SLB.COM by Xerox.COM ; 03 FEB 88 12:12:52 PST Received: from KATYDID.SPAR.SLB.COM by SPAR-20.SPAR.SLB.COM with TCP; Wed 3 Feb 88 12:11:03-PST Date: Wed, 3 Feb 88 12:08 PST From: Dan Carnese Subject: package bug in lucid-low in the newest release To: commonloops.pa@Xerox.COM Message-ID: <880203120847.6.CARNESE@KATYDID.SPAR.SLB.COM> The section: #-LCL3.0 (progn (in-package 'lucid) (eval-when (compile load eval) (let* ((logand&-fdesc (get-fdesc 'logand&)) (%logand&-fdesc (copy-structure logand&-fdesc))) (setf (structure-ref %logand&-fdesc 0 t) '%logand&) (setf (structure-ref %logand&-fdesc 3 t) '(2 2)) (setf (structure-ref %logand&-fdesc 7 t) '(nil nil)) (setf (structure-ref %logand&-fdesc 8 t) nil) (set-fdesc '%logand& %logand&-fdesc)) ) (defun %logand& (x y) (%logand& x y)) (eval-when (eval) (compile '%logand&)) (in-package 'pcl) ) should be replaced with: #-LCL3.0 (in-package 'lucid) #-LCL3.0 (progn (eval-when (compile load eval) (let* ((logand&-fdesc (get-fdesc 'logand&)) (%logand&-fdesc (copy-structure logand&-fdesc))) (setf (structure-ref %logand&-fdesc 0 t) '%logand&) (setf (structure-ref %logand&-fdesc 3 t) '(2 2)) (setf (structure-ref %logand&-fdesc 7 t) '(nil nil)) (setf (structure-ref %logand&-fdesc 8 t) nil) (set-fdesc '%logand& %logand&-fdesc)) ) (defun %logand& (x y) (%logand& x y)) (eval-when (eval) (compile '%logand&)) ) #-LCL3.0 (in-package 'pcl)  Received: from Xerox.COM (TCP 1500006350) by AI.AI.MIT.EDU 3 Feb 88 14:20:36 EST Received: from Semillon.ms by ArpaGateway.ms ; 03 FEB 88 10:58:53 PST Date: Wed, 3 Feb 88 10:53 PST From: Gregor.pa@Xerox.COM Subject: Scoping of init-plist in initialize To: Rob Pettengill cc: CommonLoops.pa@Xerox.COM Fcc: BD:>Gregor>mail>outgoing-mail-1.text In-Reply-To: <8802030328.AA27247@perseus> Message-ID: <880203105321.7.GREGOR@SPIFF.parc.xerox.com> Line-fold: no Date: Tue, 2 Feb 88 21:28:26 CST From: Rob Pettengill In the new scheme my augmented init-plist isn't seen by any of the call-next-method calls at all. Is there any way to hack around this until initialize gets fixed up? The reason is that the arguments call-next-method passes are the original arguments received by the method. Setting them or defaulting them doesn't affect the arguments passed by call-next-method. This is as specified in the CLOS spec. But, you can pass arguments to call-next-method explicitly to get around this. Note that the new arguments are not allowed to change the method that would be called by call-next-method. So, in your case you could do: (defmethod INITIALIZE ((self NX-WS-CONNECTION) init-plist) (declare (special *window-server-connections*)) (setf (getf init-plist :ws-connection) self) (setf (getf init-plist :root-canvas) self) (call-next-method self init-plist) ... ) Note that for the time being, call-next-method is a macro, not a function so you can't apply it, you can just use it as the car of a form. -------  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 3 Feb 88 13:27:46 EST Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 3 Feb 88 10:22:38 PST Received: from Cabernet.ms by ArpaGateway.ms ; 03 FEB 88 10:20:25 PST Date: 3 Feb 88 10:19 PST Sender: Bobrow.pa@Xerox.COM From: Danny Bobrow Subject: Re: Names, Names In-reply-to: Dick Gabriel 's message of 02 Feb 88 20:40 PST To: RPG@SAIL.Stanford.EDU cc: Common-Lisp-object-system@SAIL.Stanford.EDU Message-ID: <880203-102025-2482@Xerox> Danny: ``There is no mechanism to handle names for classes specified in the metaobject protocol other than symbol-class and class-name.'' If non-symbols can be names, I'd say there had better be such a mechanism. -rpg- Not if the criterion is that symbol-class does an eql look-up, and class-name is insensitive to type. Then ordinary users can write a structure to eql intern for any structure they care to use, and use symbol-class to find the associated class. Thus for the dynamic-class application I mentioned: (defun get-dynamic-class (class-name-list) (let((pair (assoc class-name-list *dynamic-classes* :test #'equal))) (if pair (symbol-class (cdr pair)) (let((new-class (make-instance 'standard-class :direct-superclasses (mapcar #'symbol-class class-name-list) :direct-slots nil))) ;;; make class-name-list be proper name of new-class (setf (class-name new-class) class-name-list) (setf (symbol-class class-name-list) new-class) (setf (assoc class-name-list *dynamic-classes*) class-name-list) new-class))))  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 3 Feb 88 11:04:24 EST Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 3 Feb 88 07:57:11 PST Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 334293; Tue 2-Feb-88 21:50:39 EST Date: Tue, 2 Feb 88 21:50 EST From: David A. Moon Subject: Chapter 1 To: common-lisp-object-system@SAIL.STANFORD.EDU In-Reply-To: The message of 31 Jan 88 00:28 EST from Dick Gabriel Message-ID: <19880203025029.0.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: 30 Jan 88 2128 PST From: Dick Gabriel There are new CONCEP.TEX and CONCEP.DVI on [CLS,LSP] at SAIL. This ought to be the next to the last version. The changes that were made up to Monday evening, when I last copied the file, are fine. I didn't check whether every change that I thought should be made, had been made.  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 3 Feb 88 11:04:20 EST Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 3 Feb 88 07:57:31 PST Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 334295; Tue 2-Feb-88 21:59:55 EST Date: Tue, 2 Feb 88 21:59 EST From: David A. Moon Subject: Chapter 2 To: common-lisp-object-system@SAIL.STANFORD.EDU In-Reply-To: The message of 31 Jan 88 19:22 EST from Linda DeMichiel Message-ID: <19880203025952.1.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: 31 Jan 88 1622 PST From: Linda DeMichiel New FUNCTI.TEX and FUNCTI.DVI files are available on [CLS,LSP] at SAIL. The changes that were made up to Monday evening, when I last copied the file, are fine. I didn't check whether every change that I thought should be made, had been made, except to note that the removal of make-method-call and addition of call-method and make-method still needs to be done.  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 2 Feb 88 23:45:37 EST Date: 02 Feb 88 2040 PST From: Dick Gabriel Subject: Names, Names To: Common-Lisp-object-system@SAIL.Stanford.EDU Danny: ``There is no mechanism to handle names for classes specified in the metaobject protocol other than symbol-class and class-name.'' If non-symbols can be names, I'd say there had better be such a mechanism. -rpg-  Received: from Xerox.COM (TCP 1500006350) by AI.AI.MIT.EDU 2 Feb 88 23:16:12 EST Received: from Chardonnay.ms by ArpaGateway.ms ; 02 FEB 88 19:34:17 PST Return-Path: <@MCC.COM:rcp%sw.MCC.COM@MCC.COM> Redistributed: CommonLoops.pa Received: from MCC.COM by Xerox.COM ; 02 FEB 88 19:31:11 PST Received: from milano.SW.MCC.COM by MCC.COM with TCP; Tue 2 Feb 88 21:30:00-CST Received: from perseus by milano.SW.MCC.COM (5.52/STP1.56) id AA19521; Tue, 2 Feb 88 21:30:03 CST Date: Tue, 2 Feb 88 21:28:26 CST From: Rob Pettengill Message-Id: <8802030328.AA27247@perseus> Received: by perseus (3.2/STP) id AA27247; Tue, 2 Feb 88 21:28:26 CST To: Gregor.pa@Xerox.COM Cc: CommonLoops.pa@Xerox.COM Subject: Scoping of init-plist in initialize I finally got our window system to compile (compilation is very slow under excl3.0 beta!) and am getting to interesting problems. It turns out that (lacking a real init protocol) I have been playing close to the edge under previous releases of pcl. For example: (defmethod INITIALIZE ((self NX-WS-CONNECTION) init-plist) (declare (special *window-server-connections*)) (setf (getf init-plist :ws-connection) self) (setf (getf init-plist :root-canvas) self) (call-next-method) (nx-init-connection self) (cache-special-cursors SELF) (push self *window-server-connections*) ) ;and in the very last inherited method (defmethod initialize ((self region) init-plist) (ce:with-keys (location size x-origin y-origin width height) init-plist ;(call-next-method) doesn't pick up the augmented init-plist (pcl::initialize-from-defaults self) (pcl::initialize-from-init-plist self init-plist); but this did ...local key handling ...)) In any case by explicitly calling initialize-from-init-plist with init-plist, I was able to get my augmented plist info in the slots and then use it in the ":after" part of a specialized method on the way out. (hack, hack, hack ...) In the new scheme my augmented init-plist isn't seen by any of the call-next-method calls at all. Is there any way to hack around this until initialize gets fixed up? Thanks, Rob Robert C. Pettengill, MCC Software Technology Program P. O. Box 200195, Austin, Texas 78720 ARPA: rcp@mcc.com PHONE: (512) 338-3533 UUCP: {ihnp4,seismo,harvard,gatech,pyramid}!ut-sally!im4u!milano!rcp  Received: from Xerox.COM (TCP 1500006350) by AI.AI.MIT.EDU 2 Feb 88 23:15:54 EST Received: from Semillon.ms by ArpaGateway.ms ; 02 FEB 88 17:39:29 PST Date: Tue, 2 Feb 88 17:36 PST From: Gregor.pa@Xerox.COM Subject: Weird bug in IF statements while using PCL To: Steve Strassmann cc: Customer-Reports@STONY-BROOK.SCRC.Symbolics.COM, CommonLoops.pa@Xerox.COM Fcc: BD:>Gregor>mail>outgoing-mail-1.text In-Reply-To: <880202170811.8.STRAZ@ZAXXON.MEDIA.MIT.EDU> Message-ID: <880202173657.1.GREGOR@SPIFF.parc.xerox.com> Line-fold: no Date: Tue, 2 Feb 88 17:08 EST From: Steve Strassmann In Symbolics Rel 7.1, Commonloops January 29 release: I know CLtL [Steele] specifies that IF forms only have 3 arguments, but in Symbolics rel 7.1, you may have as many ELSE clauses as you want. Here's a weird bug where a PCL slot is found as long as it's one of the first 3 arguments in an IF form, but not after that. The next version of PCL will complain (vociferously) if you use more than 3 arguments to if inside of a with-slot or with-accessors form. You will have to use only three arguments to if but at least you will get a warning when you use more than three. -------  Received: from Xerox.COM (TCP 1500006350) by AI.AI.MIT.EDU 2 Feb 88 23:15:46 EST Received: from Semillon.ms by ArpaGateway.ms ; 02 FEB 88 17:15:53 PST Date: Tue, 2 Feb 88 17:09 PST From: Gregor.pa@Xerox.COM Subject: Problems with PCL Beta Test version 1/28/88 To: Rob Pettengill cc: CommonLoops.pa@Xerox.COM Fcc: BD:>Gregor>mail>outgoing-mail-1.text In-Reply-To: <8802022316.AA26838@perseus> Message-ID: <880202170900.8.GREGOR@SPIFF.parc.xerox.com> Line-fold: no Date: Tue, 2 Feb 88 17:16:16 CST From: Rob Pettengill Redistributed: CommonLoops.pa Date: Sat, 30 Jan 88 14:00:26 CST From: Rob Pettengill 2. The new with-slots* does not work when new name bindings are spedified for slots. For example: 3. I also have the following error which occurs on a trivial defmethod at the end of a long pcl file (which compiles fine under the August version of pcl): ->(ERROR "Received signal number ~s ~@[(~a)~]" 11 "Segmentation violation") Sorry, problem #2 was a red herring. It only occurs after I have gotten the segmentation violation error, #3, in the running lisp image. I am glad to hear this since I was unable to reproduce it here. I believe your segmentation violation may be happening because you are defining a method with a non-congruent lambda list. Admittedly you should get a better error message, but try checking to see if that is what is causing this. -------  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 2 Feb 88 21:22:47 EST Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 2 Feb 88 18:17:49 PST Received: from Cabernet.ms by ArpaGateway.ms ; 02 FEB 88 17:59:48 PST Date: 2 Feb 88 17:57 PST Sender: Bobrow.pa@Xerox.COM From: Danny Bobrow Subject: Re: Class Names (Again! Can't We Ever Stop?) In-reply-to: Dick Gabriel 's message of 02 Feb 88 14:01 PST To: RPG@SAIL.Stanford.EDU cc: common-lisp-object-system@SAIL.Stanford.EDU Message-ID: <880202-175948-1439@Xerox> The topic of naming objects in CLOS is addressed by an entire level of the meta-object protocol. I see no reason to introduce gratuitous and unmotivated generalizations into the base level when someone who wants to introduce a bizarre naming scheme will have all the mechanism laid at his feet with which to do it. There is no mechanism to handle names for classes specified in the metaobject protocol other than symbol-class and class-name. It is for this reason that one wants not to restrict the values of class-names. It introduces a bit of generality for which very few people will imagine a use, and while doing so it increases the complexity of an already too-complex specification that already has mechanisms to handle naming. In short: epsilon complexity increase, zero benefit. This removes a restriction rather than introducing a generality. The only property of symbols that is used, as far as I can see, is the ease of typing something in that will be EQL each time. With the EQL restriction on how names refer to classes, I see neither an implementation problem nor a conceptual one. Those users who can never think of a use for this feature will never have to encounter it (it never interferes). We have used this feature extensively for dynamically constructed class combinations, with mixins selected from carefully selected orthogonal sets, where to have to have a symbol for a name causes construction of long ugly concatenations. danny  Received: from Xerox.COM (TCP 1500006350) by AI.AI.MIT.EDU 2 Feb 88 20:11:59 EST Received: from Cabernet.ms by ArpaGateway.ms ; 02 FEB 88 15:54:38 PST Return-Path: <@MCC.COM:rcp%sw.MCC.COM@MCC.COM> Redistributed: CommonLoops.pa Received: from MCC.COM by Xerox.COM ; 02 FEB 88 15:52:09 PST Received: from milano.SW.MCC.COM by MCC.COM with TCP; Tue 2 Feb 88 17:51:05-CST Received: from perseus by milano.SW.MCC.COM (5.52/STP1.56) id AA17267; Tue, 2 Feb 88 17:51:56 CST Date: Tue, 2 Feb 88 17:51:02 CST From: Rob Pettengill Message-Id: <8802022351.AA26928@perseus> Received: by perseus (3.2/STP) id AA26928; Tue, 2 Feb 88 17:51:02 CST To: rcp%sw.MCC.COM@MCC.COM Cc: Gregor.pa@Xerox.COM, CommonLoops.pa@Xerox.COM In-Reply-To: Rob Pettengill's message of Sat, 30 Jan 88 14:00:26 CST <8801302000.AA22946@perseus> Subject: Problems with PCL Beta Test version 1/28/88 Redistributed: CommonLoops.pa Date: Sat, 30 Jan 88 14:00:26 CST From: Rob Pettengill I have had several problems with the new beta test version. .... 3. I also have the following error which occurs on a trivial defmethod at the end of a long pcl file (which compiles fine under the August version of pcl): ->(ERROR "Received signal number ~s ~@[(~a)~]" 11 "Segmentation violation") ;rob This problem was caused by a non congruent defmethod lambda list that was undetected under the 8/27/87 version of pcl (I guess we really must use that method alot!). It would be nice to have a friendlier warning about non-congruent lambda lists. Thanks for all the hard work! ;rob Robert C. Pettengill, MCC Software Technology Program P. O. Box 200195, Austin, Texas 78720 ARPA: rcp@mcc.com PHONE: (512) 338-3533 UUCP: {ihnp4,seismo,harvard,gatech,pyramid}!ut-sally!im4u!milano!rcp  Received: from Xerox.COM (TCP 1500006350) by AI.AI.MIT.EDU 2 Feb 88 20:11:50 EST Received: from Cabernet.ms by ArpaGateway.ms ; 02 FEB 88 15:22:57 PST Return-Path: Redistributed: commonloops.PA Received: from media-lab.MIT.EDU (media-lab.media.mit.edu) by Xerox.COM ; 02 FEB 88 15:16:53 PST Received: from zaxxon.media.mit.edu by media-lab.MIT.EDU (5.54/4.8) via CHAOS with CHAOS id AA25963; Tue, 2 Feb 88 18:10:37 EST Date: Tue, 2 Feb 88 18:11 EST From: Steve Strassmann Subject: arglist legibility suggestion To: commonloops.PA@Xerox.COM Message-Id: <880202181153.1.STRAZ@ZAXXON.MEDIA.MIT.EDU> The ARGLIST function is available in Symbolics 7.1 (ctrl-shift-A), and I imagine, in many other Lisps. There should be a way to make it return more reasonable values. Currently, for example, it gives uninformative and illegible things like this: PRINT-OBJECT: (Disc-Fn-Arg 0 Disc-Fn-Arg 1 Disc-Fn-Arg 2) Suggestion 1: Please make the symbol names more legible, i.e. instead of "Disc-Fn-Arg 0", use something like "Disc-Fn-Arg-0", or even "Arg-0". The spaces make it look like PRINT-OBJECT takes 6 arguments, not 3. PRINT-OBJECT: (Arg-0 Arg-1 Arg-2) would be an improvement. Suggestion 2: Instead of gensyming the arg names, you could at least see if all the methods agree on their names. If every method uses the same name (or IGNORE) for the name, use it. For example, the arglist to print-object should be: PRINT-OBJECT: (Arg-0 STREAM DEPTH) Suggestion 3: Symbolics allows you to DECLARE a function's arglist, but using DEFMETHOD ignores such declarations. It would be nice if this worked: (defmethod print-object ((self bagel) stream ignore) #+symbolics (declare (scl:arglist thing stream depth)) ...) PRINT-OBJECT: (THING STREAM DEPTH) In case multiple methods make such declarations, you could either accept the latest declaration, or take some kind of plurality vote, like in suggestion 2 above. DEFMETHOD should take care not to override such declarations if they exist.  Received: from Xerox.COM (TCP 1500006350) by AI.AI.MIT.EDU 2 Feb 88 20:11:37 EST Received: from Chardonnay.ms by ArpaGateway.ms ; 02 FEB 88 15:20:52 PST Return-Path: <@MCC.COM:rcp%sw.MCC.COM@MCC.COM> Redistributed: CommonLoops.pa Received: from MCC.COM by Xerox.COM ; 02 FEB 88 15:17:20 PST Received: from milano.SW.MCC.COM by MCC.COM with TCP; Tue 2 Feb 88 17:16:18-CST Received: from perseus by milano.SW.MCC.COM (5.52/STP1.56) id AA16898; Tue, 2 Feb 88 17:17:12 CST Date: Tue, 2 Feb 88 17:16:16 CST From: Rob Pettengill Message-Id: <8802022316.AA26838@perseus> Received: by perseus (3.2/STP) id AA26838; Tue, 2 Feb 88 17:16:16 CST To: rcp%sw.MCC.COM@MCC.COM Cc: Gregor.pa@Xerox.COM, CommonLoops.pa@Xerox.COM In-Reply-To: Rob Pettengill's message of Sat, 30 Jan 88 14:00:26 CST <8801302000.AA22946@perseus> Subject: Problems with PCL Beta Test version 1/28/88 Redistributed: CommonLoops.pa Date: Sat, 30 Jan 88 14:00:26 CST From: Rob Pettengill I have had several problems with the new beta test version. .... 2. The new with-slots* does not work when new name bindings are spedified for slots. For example: (defclass foo () ((a)(b))) NIL (defmethod foo-vals ((self foo)) (with-slots* (a b) self (list a b))) NIL (defmethod foo-vals ((self foo)) (with-slots* ((foo-a a) (oo-b b)) self (list foo-a foo-b))) Error: Attempt to take the car of A which is not a cons. .... 3. I also have the following error which occurs on a trivial defmethod at the end of a long pcl file (which compiles fine under the August version of pcl): ->(ERROR "Received signal number ~s ~@[(~a)~]" 11 "Segmentation violation") .... ;rob Sorry, problem #2 was a red herring. It only occurs after I have gotten the segmentation violation error, #3, in the running lisp image. ;rob Robert C. Pettengill, MCC Software Technology Program P. O. Box 200195, Austin, Texas 78720 ARPA: rcp@mcc.com PHONE: (512) 338-3533 UUCP: {ihnp4,seismo,harvard,gatech,pyramid}!ut-sally!im4u!milano!rcp  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 2 Feb 88 17:06:21 EST Date: 02 Feb 88 1401 PST From: Dick Gabriel Subject: Class Names (Again! Can't We Ever Stop?) To: common-lisp-object-system@SAIL.Stanford.EDU rpg: ``There is no tradition of using non-symbols for names in Lisp.'' Dussud: ``Actually there is, function specs are an example of this. The motivation for non symbol names in CLOS comes from the fact that we can deal with first class objects. '' This is part of a newly emerging tradition - that is, it's the latest thing as far as Common Lisp is concerned. It might be a tradition in Lisp machine Lisp, and in fact we adopted a reduced function specification notion for functions in the form of setf generic functions. This has nothing to do with the names of classes, which is the issue. If we generalize from function names to class names, why not continue on to slot names? Why restrict instances to look like structures? Why have slots? The topic of naming objects in CLOS is addressed by an entire level of the meta-object protocol. I see no reason to introduce gratuitous and unmotivated generalizations into the base level when someone who wants to introduce a bizarre naming scheme will have all the mechanism laid at his feet with which to do it. Here is the compelling reason for restricting class names: It introduces a bit of generality for which very few people will imagine a use, and while doing so it increases the complexity of an already too-complex specification that already has mechanisms to handle naming. In short: epsilon complexity increase, zero benefit. -rpg-  Received: from Xerox.COM (TCP 1500006350) by AI.AI.MIT.EDU 2 Feb 88 16:11:52 EST Received: from Semillon.ms by ArpaGateway.ms ; 02 FEB 88 13:04:01 PST Date: Tue, 2 Feb 88 12:56 PST From: Gregor.pa@Xerox.COM Subject: precompile-random-code-segments To: CommonLoops.PA@Xerox.COM Message-ID: <880202125640.8.GREGOR@SPIFF.parc.xerox.com> Line-fold: no The comments in notes.text about precompile-random-code-segments have confused quite a number of people. Looking back on them its no great suprise. This message attempts to straighten things out a a bit. The crucial point that was confused before is that the precom file must be compiled after your entire system is LOADED. It is not necessary for your system to have been compiled in the current image, just loaded. The rest of this message is the text from notes.text re-worked to attempt to make this more clear. I will also take a shot at abstracting out the defsys stuff so that people can use that and then I will send out a message saying how to do this using that stuff. In addition this release includes the beginnings of support for doing some of the compiling which PCL does a load time at compile time instead. To use this support, put the form: (pcl::precompile-random-code-segments) in a file which is compiled after all your other pcl using files are loaded. Then arrange for that file to be loaded before all your other pcl using files are loaded. For example, if your system has two files called "classes" and "methods", create a new file called "precom" that contains: (in-package 'pcl) (pcl::precompile-random-code-segments) Then you can compile your system with: (defun compile-my-system () (let ((compiled-a-file-p nil)) (when (source-newer-than-binary "classes") (compile-file "classes") (setq compiled-a-file-p t)) (load "classes") (when (source-newer-than-binary "methods") (compile-file "methods") (setq compiled-a-file-p t)) (load "methods") (when (or compiled-a-file-p (source-newer-than-binary "precom")) (compile-file "precom")))) and load your system with: (defun load-my-system () (load "precom") (load "classes") (load "methods")) -------  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 2 Feb 88 13:38:07 EST Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 2 Feb 88 10:32:01 PST Received: from Cabernet.ms by ArpaGateway.ms ; 02 FEB 88 10:16:38 PST Date: 2 Feb 88 10:16 PST Sender: Bobrow.pa@Xerox.COM From: Danny Bobrow Subject: Comments on most recent draft: Chap 1 and 2 To: common-lisp-object-system@SAIL.Stanford.EDU Message-ID: <880202-101638-2198@Xerox> CHAPTER 1 page 8: We have discussed extensively why we should not force a restriction on the value of class-name. The following text would reflect the looser condition. A class can have a name. The function class-name takes a class object and returns its name. The name of an anonymous class is nil. All the names used in this specification are symbols, though we place no restriction of the type of a name. Two names are the same if they are eql. The function symbol-class takes a name and returns the class associated with that name, or nil if there is none. p 1-20 There is a paragraph "Each class that corresponds to a predefined ..." which is a good specification of how Common Lisp classes may be implemented. Can we remove the paragraph "The Object System specifes that all predefined ..." which confuses the issue. At the bottom, it does not specify if make-instance can be used for objects defined by defstruct. We should say one way or the other. p 1-30 Rule 5 is incorrect as it stands. It is described corrctly in the text later on the page. This rule could be rephrased as: "If &allow-other-keys is mentioned in the lambda-list of a method, then that method is applicable, any keyword argument may be mentioned in the call to this generic function." p1-48 Shouldn't it say in this section that we are depending on an extension to Common Lisp to allow (symbol-function '(setf foo)) to return the corresponding function object. CHAPTER 2 p2-8 The method signature should use method instead of standard-method. Moon has argued that standard-accessor-method should be disjoint from standard-method. I pointed out some differences in behavior that would require negative inheritance if they are not disjoint. But both need to be able to be added to generic functions. P 2-17 class-name To correspond to the class-name change, remove the phrase "this result is a symbol." p2-19 To go along with the change to class-name "The function cmakunbound causes the given name to no longer refer to a class in the given environment; that is, (symbol-class name env) will now return nil for that name." And replace "symbol" by "name" in Syntax and Remarks. p2-28 Remarks spells out a number of cases for replacement and retention of methods, but omits the case where there are methods on an existing generic function, and there are method descriptions which do not overlap entirely. This paragraph might read: "If a generic function with the same name already exists, all methods on that generic function are retained, or replaced by a corresponding method specified in a method description. A method description corresponds to an existing method if it has the same parameter specializers and the same qualifiers. New methods are added to the generic function for method descriptions which do not correspond to any existing methods." p2-52 The description makes it clear that the default value of errorp is t. Shouldn't that be reflected in the method signature? EXCEPTION CONDITION HANDLERS Generic functions for handling exception conditions are defined in order to allow users to specialize their behavior. They only signal an error. Hence they ought have a method signature with no specialization. Moon made that point in an earlier message. Thus: p 2-64 no-applicable-method (generic-function t) &rest function-arguments This allows a programming environment (or a delegation hacker) to define the behavior for standard-generic-function without having to remove the system defined method (which under certain circumstances may still want to be invoked with call-next-method). Similarly p 2-71 slot-missing (class t) object slot-name operation &optional new-value It needs to say below that "the default method signals an error" and p 2-72 slot-unbound (class t) instance slot-name It needs to say below that "the default method signals an error" p 2-74 symbol-class The occurences of symbol should be replaced by name.  Received: from Xerox.COM (TCP 1500006350) by AI.AI.MIT.EDU 2 Feb 88 13:01:12 EST Received: from Semillon.ms by ArpaGateway.ms ; 02 FEB 88 09:51:45 PST Date: Tue, 2 Feb 88 09:43 PST From: Gregor.pa@Xerox.COM Subject: NOTE-PRIVATE-PATCH can't take multiple lines To: Steve Strassmann cc: commonloops.PA@Xerox.COM, customer-reports@riverside.scrc.symbolics.com Fcc: BD:>Gregor>mail>outgoing-mail-1.text In-Reply-To: <880202013008.1.STRAZ@ZAXXON.MEDIA.MIT.EDU> Message-ID: <880202094329.6.GREGOR@SPIFF.parc.xerox.com> Line-fold: no Date: Tue, 2 Feb 88 01:30 EST From: Steve Strassmann After the August release of PCL came out, I reported the following bug. It wasn't fixed, and it bit me again when I loaded the Jan 29 release. In Symbolics Release 7.1, you can't NOTE-PRIVATE-PATCH using a string longer than one line. The lispm will not put semicolons at the beginning of the latter lines within machine-generated comments. Fixed in the PCL sources here. -------  Received: from Xerox.COM (TCP 1500006350) by AI.AI.MIT.EDU 2 Feb 88 01:48:10 EST Received: from Catawba.ms by ArpaGateway.ms ; 01 FEB 88 22:39:28 PST Return-Path: Redistributed: commonloops.PA Received: from media-lab.MIT.EDU (media-lab.media.mit.edu) by Xerox.COM ; 01 FEB 88 22:36:39 PST Received: from zaxxon.media.mit.edu by media-lab.MIT.EDU (5.54/4.8) via CHAOS with CHAOS id AA06856; Tue, 2 Feb 88 01:28:52 EST Date: Tue, 2 Feb 88 01:30 EST From: Steve Strassmann Subject: NOTE-PRIVATE-PATCH can't take multiple lines To: commonloops.PA@Xerox.COM, customer-reports@riverside.scrc.symbolics.com Message-Id: <880202013008.1.STRAZ@ZAXXON.MEDIA.MIT.EDU> After the August release of PCL came out, I reported the following bug. It wasn't fixed, and it bit me again when I loaded the Jan 29 release. In Symbolics Release 7.1, you can't NOTE-PRIVATE-PATCH using a string longer than one line. The lispm will not put semicolons at the beginning of the latter lines within machine-generated comments. Therefore, I have commented out the following form from 7DEBUG.LISP: #| (NOTE-PRIVATE-PATCH "Changes to make rel 7 debugger know about associate the name of a closure with the actual closure (its environment) rather than the closure function.") |# For example, the machine-generated file PCL;PATCH;PCL.SYSTEM-DIR contains the following header. Symbolic's SCT (i.e. defsystem) chokes when it tries to read the line beginning with "closure": ;;; -*- Mode: LISP; Base: 10 -*- ;;; Written 2/02/88 00:55:18 by straz, ;;; while running on Zaxxon from FEP0:>amt-color.load.1 ;;; with Genera 7.1, IP-TCP 52.16, Experimental X-Window-System 17.4, ILA-NFS 7.1, ;;; 7-1-Patches 1.34, MAC 12.5, Experimental Completion 7 1, Color 331.9, ;;; Color Support 11.8, Color Demo 316.2, Images 310.20, microcode 3600-MIC 396, ;;; FEP 127, FEP0:>v127-lisp.flod(56), FEP0:>v127-loaders.flod(56), ;;; FEP0:>v127-debug.flod(34), FEP0:>v127-info.flod(56), ;;; Changes to make rel 7 debugger know about associate the name of a closure with the actual closure (its environment) rather than the closure function. (from PCL:PCL;7DEBUG.LISP.4).  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 1 Feb 88 18:02:22 EST Received: from RELAY.CS.NET by SAIL.Stanford.EDU with TCP; 1 Feb 88 14:57:11 PST Received: from relay2.cs.net by RELAY.CS.NET id ag26311; 1 Feb 88 14:31 EST Received: from csc.ti.com by RELAY.CS.NET id al26097; 1 Feb 88 14:17 EST Received: from Jenner by tilde id AA08087; Mon, 1 Feb 88 12:49:18 CST Message-Id: <2779728586-434545@Jenner> Date: Mon, 1 Feb 88 12:49:46 CST From: Patrick H Dussud To: common-lisp-object-system@SAIL.STANFORD.EDU Subject: Re: Remarks about Comments on Latest Draft Documents In-Reply-To: Msg of 30 Jan 88 0955 PST from Dick Gabriel At this point I believe that compelling arguments must be made for even small changes. There is no tradition of using non-symbols for names in Lisp. Actually there is, function specs are an example of this. The motivation for non symbol names in CLOS comes from the fact that we can deal with first class objects. Naming can be seen as a reflection of the access path to the object. Some implementations may arrange this name so it can be used for reading as well. I don't propose that we adopt anything like that, I am saying that the motivation is there. I wouldn't like that we explicitly disallow non symbol names. Patrick.  Received: from Xerox.COM (TCP 1500006350) by AI.AI.MIT.EDU 1 Feb 88 16:51:11 EST Received: from Semillon.ms by ArpaGateway.ms ; 01 FEB 88 13:20:16 PST Date: Mon, 1 Feb 88 13:09 PST From: Gregor.pa@Xerox.COM Subject: new version of coral-low.lisp To: CommonLoops.PA@Xerox.COM Message-ID: <880201130953.4.GREGOR@SPIFF.parc.xerox.com> Line-fold: no There is a new verion of coral-low.lisp on parcvax.xerox.com. People using PCL in coral-lisp should get a copy of this file and use: (compile-pcl 't) to recompile PCL right away. They should then recompile their code that uses PCL. This fix fixes a horrible bug which caused caching functions to bomb out in mysterious ways under mysterious circumunstances. It is conceivable that this bug could cause PCL to write in random parts of memory. -------  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 31 Jan 88 19:28:51 EST Date: 31 Jan 88 1622 PST From: Linda DeMichiel Subject: Chapter 2 To: common-lisp-object-system@SAIL.Stanford.EDU New FUNCTI.TEX and FUNCTI.DVI files are available on [CLS,LSP] at SAIL. -lgd  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 31 Jan 88 00:33:12 EST Date: 30 Jan 88 2128 PST From: Dick Gabriel Subject: Chapter 1 To: common-lisp-object-system@SAIL.Stanford.EDU There are new CONCEP.TEX and CONCEP.DVI on [CLS,LSP] at SAIL. This ought to be the next to the last version. -rpg-  Received: from Xerox.COM (TCP 1500006350) by AI.AI.MIT.EDU 30 Jan 88 22:01:22 EST Received: from Cabernet.ms by ArpaGateway.ms ; 30 JAN 88 18:53:07 PST Return-Path: <@MCC.COM:rcp%sw.MCC.COM@MCC.COM> Redistributed: CommonLoops.pa Received: from MCC.COM by Xerox.COM ; 30 JAN 88 18:50:03 PST Received: from milano.SW.MCC.COM by MCC.COM with TCP; Sat 30 Jan 88 20:48:55-CST Received: from perseus by milano.SW.MCC.COM (5.52/STP1.56) id AA17042; Sat, 30 Jan 88 20:49:42 CST Date: Sat, 30 Jan 88 20:49:06 CST From: Rob Pettengill Message-Id: <8801310249.AA23408@perseus> Received: by perseus (3.2/STP) id AA23408; Sat, 30 Jan 88 20:49:06 CST To: RPG@SAIL.Stanford.EDU Cc: rcp%sw.MCC.COM@MCC.COM, CommonLoops.pa@Xerox.COM In-Reply-To: Dick Gabriel's message of 30 Jan 88 1406 PST <8801302207.AA17294@SW.MCC.COM> Subject: Problems with CommonLoops Date: 30 Jan 88 1406 PST From: Dick Gabriel As time goes on PCL is becoming CLOS. Gregor mentioned in his release message that with-slots has changed to conform to the latest definition. Although I cannot speak for Gregor or Xerox, there will soon be increased pressure to conform to CLOS, and people using PCL should be aware that it will be changing to meet that specification. Such changes cannot be viewed as ``problems'' with PCL. Here is the latest specification of with-slots: with-slots Macro .... (with-slots ((x1 x) (y1 y)) position-1 (with-slots ((x2 x) (y2 y)) position-2 (psetf x1 x2 y1 y2)))) I'm sorry if I wasn't clear. We are eagerly looking forward to the convervence of PCL and the CLOS spec. However, according to the pcl/notes.text with-slots in the current version was to correspond to the old syntax and with-slots* was to correspond to the new syntax. The purpose of this was to allow a gradual conversion to the new syntax. The problem I found was that neither seems to be true. The old syntax is no longer full suppoted and the new syntax (in the example above) also causes an error. ;rob Robert C. Pettengill, MCC Software Technology Program P. O. Box 200195, Austin, Texas 78720 ARPA: rcp@mcc.com PHONE: (512) 338-3533 UUCP: {ihnp4,seismo,harvard,gatech,pyramid}!ut-sally!im4u!milano!rcp  Received: from Xerox.COM (TCP 1500006350) by AI.AI.MIT.EDU 30 Jan 88 17:42:43 EST Received: from Chardonnay.ms by ArpaGateway.ms ; 30 JAN 88 14:09:21 PST Return-Path: Redistributed: CommonLoops.pa Received: from SAIL.Stanford.EDU by Xerox.COM ; 30 JAN 88 14:07:12 PST Date: 30 Jan 88 14:06 PST From: Dick Gabriel Subject: Problems with CommonLoops To: rcp%sw.MCC.COM@MCC.COM, CommonLoops.pa@Xerox.COM Message-ID: <880130-140921-1006@Xerox> As time goes on PCL is becoming CLOS. Gregor mentioned in his release message that with-slots has changed to conform to the latest definition. Although I cannot speak for Gregor or Xerox, there will soon be increased pressure to conform to CLOS, and people using PCL should be aware that it will be changing to meet that specification. Such changes cannot be viewed as ``problems'' with PCL. Here is the latest specification of with-slots: with-slots Macro Purpose: The macro with-slots creates a lexical context for referring to specified slots as though they were variables. Within such a context the value of the slot can be specified by using its slot name, as if it were a lexically bound variable. Both setf and setq can be used to set the value of the slot. The macro with-slots translates an appearance of the slot name as a variable into a call to slot-value. Syntax: with-slots ({slot-entry}*) instance-form body) slot-entry::= slot-name | (variable-name slot-name) Examples: (with-slots (x y) position-1 (sqrt (+ (* x x) (* y y)))) (with-slots ((x1 x) (y1 y)) position-1 (with-slots ((x2 x) (y2 y)) position-2 (psetf x1 x2 y1 y2)))) (with-slots (x y) position (setq x (1+ x) y (1+ y))) Remarks: A with-slots expression of the form: (with-slots (slot-entry1...slot-entryn) instance form1...formk) expands into the equivalent of (let ((I instance)) (symbol-macrolet (Q1...Qn) form1...formk)) where Qi is (slot-entryi (slot-value I 'slot-entryi)) if slot-entryi is a symbol, and is (variable-namei (slot-value I 'slot-namei)) if slot-entryi is of the form (variable-namei slot-namei) See Also: symbol-macrolet  Received: from Xerox.COM (TCP 1500006350) by AI.AI.MIT.EDU 30 Jan 88 17:42:33 EST Received: from Chardonnay.ms by ArpaGateway.ms ; 30 JAN 88 13:01:55 PST Return-Path: <@MCC.COM:rcp%sw.MCC.COM@MCC.COM> Redistributed: CommonLoops.pa Received: from MCC.COM by Xerox.COM ; 30 JAN 88 12:50:00 PST Received: from milano.SW.MCC.COM by MCC.COM with TCP; Sat 30 Jan 88 14:22:36-CST Received: from perseus by milano.SW.MCC.COM (5.52/STP1.56) id AA11611; Sat, 30 Jan 88 14:23:22 CST Date: Sat, 30 Jan 88 14:22:47 CST From: Rob Pettengill Message-Id: <8801302022.AA22968@perseus> Received: by perseus (3.2/STP) id AA22968; Sat, 30 Jan 88 14:22:47 CST To: rcp%sw.MCC.COM@MCC.COM Cc: Gregor.pa@Xerox.COM, CommonLoops.pa@Xerox.COM In-Reply-To: Rob Pettengill's message of Sat, 30 Jan 88 14:00:26 CST <8801302000.AA22946@perseus> Subject: Problems with PCL Beta Test version 1/28/88 I forgot to mention that I observed these problems running with Franz version 3.0.beta.68 [sun3 with patch level 6] (1/18/88 18:27). A couple of other things I noticed about the Beta test version are: 1. Compilation seems to be much slower now than with the August release. 2. I get lots of warnings during compilation like these: Warning: Ignoring unrecognized declaration: (CLASS SELF NX-WS-CONNECTION) Warning: Ignoring unrecognized declaration: (CLASS CANVAS T) Warning: Ignoring unrecognized declaration: (CLASS EVENT-DESCRIPTION-LIST T) ;rob Robert C. Pettengill, MCC Software Technology Program P. O. Box 200195, Austin, Texas 78720 ARPA: rcp@mcc.com PHONE: (512) 338-3533 UUCP: {ihnp4,seismo,harvard,gatech,pyramid}!ut-sally!im4u!milano!rcp  Received: from Xerox.COM (TCP 1500006350) by AI.AI.MIT.EDU 30 Jan 88 15:43:14 EST Received: from Salvador.ms by ArpaGateway.ms ; 30 JAN 88 12:28:43 PST Return-Path: <@MCC.COM:rcp%sw.MCC.COM@MCC.COM> Redistributed: CommonLoops.pa Received: from MCC.COM by Xerox.COM ; 30 JAN 88 12:16:48 PST Received: from milano.SW.MCC.COM by MCC.COM with TCP; Sat 30 Jan 88 14:00:14-CST Received: from perseus by milano.SW.MCC.COM (5.52/STP1.56) id AA11456; Sat, 30 Jan 88 14:01:02 CST Date: Sat, 30 Jan 88 14:00:26 CST From: Rob Pettengill Message-Id: <8801302000.AA22946@perseus> Received: by perseus (3.2/STP) id AA22946; Sat, 30 Jan 88 14:00:26 CST To: Gregor.pa@Xerox.COM Cc: CommonLoops.pa@Xerox.COM Subject: Problems with PCL Beta Test version 1/28/88 I have had several problems with the new beta test version. 1. With-slots no longer supports multiple instance declarations in a single with-slots construct. For example: (with-slots ((SELF :use-accessors nil :prefix ws=) (CANVAS :use-accessors nil :class canvas :prefix canvas=)) fails now. 2. The new with-slots* does not work when new name bindings are spedified for slots. For example: (defclass foo () ((a)(b))) NIL (defmethod foo-vals ((self foo)) (with-slots* (a b) self (list a b))) NIL (defmethod foo-vals ((self foo)) (with-slots* ((foo-a a) (foo-b b)) self (list foo-a foo-b))) Error: Attempt to take the car of A which is not a cons. 3. I also have the following error which occurs on a trivial defmethod at the end of a long pcl file (which compiles fine under the August version of pcl): ->(ERROR "Received signal number ~s ~@[(~a)~]" 11 "Segmentation violation") (CLASS-PRECEDENCE-LIST NIL) (PCL::GREATEST-JOIN-POINTS # NIL) (PCL::CROSS-COMBINATION-POINTS (# #) (#)) (PCL::COMPUTE-COMBINATION-POINTS #) (PCL::COMPUTE-COMBINED-METHODS #) (PCL::|(METHOD GENERIC-FUNCTION-CHANGED (STANDARD-GENERIC-FUNCTION T T))| # T) (PCL::GENERIC-FUNCTION-CHANGED # # T) ;rob Robert C. Pettengill, MCC Software Technology Program P. O. Box 200195, Austin, Texas 78720 ARPA: rcp@mcc.com PHONE: (512) 338-3533 UUCP: {ihnp4,seismo,harvard,gatech,pyramid}!ut-sally!im4u!milano!rcp  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 30 Jan 88 12:59:56 EST Date: 30 Jan 88 0955 PST From: Dick Gabriel Subject: Remarks about Comments on Latest Draft Documents To: common-lisp-object-system@SAIL.Stanford.EDU The name of a class is restricted to be a symbol in chapter 1, and that text has been there for a long time. That restriction appears in the paragraph about proper names. As you recall, that paragraph was discussed at great length in person and by netmail during rounds of review of the chapters earlier this fall. Apparently no one thought to criticize the restriction at that point. The restriction and the implementation of the restriction are two different topics. I believe the restriction is fine, and I am also perturbed that sections of the specification that have been reviewed extensively are often subject to later changes. At some point we need to decide that something is final so that the entire document can be made consistent. Linda was simply trying to make the descriptions in chapter 2 coincide with statements in chapter 1. At this point I believe that compelling arguments must be made for even small changes. There is no tradition of using non-symbols for names in Lisp. Non-symbols are used as keys for various purposes, but not as names. Defstruct restricts names to symbols. Therefore, I can see no compelling reason to break the tradition and allow non-symbols to be the names of classes. I do not find silly the use of parameter specializers to do typechecking. I find it hard to imagine what sort of argument one could make to show that point of view. That issue is different from the one about whether we ought to use parameter specializers in the document for that purpose. On this point I suppose it is better to simply state the restrictions in English in the remarks. Therefore, I suggest that chapter 2 reflect chapter 1 on this point in the remarks. saying that the parameter specializer for the new value is T. On the topic of the DOCUMENTATION generic function, my opinion is that the remarks ought to state in English the restriction that the new value in a SETF of DOCUMENTATION must be a string or it must be NIL to signify that the association between any existing documentation and the object in question must be eliminated. This restriction is stronger than any that can be conservatively deduced from CLtL, though it is not stronger can be reasonably deduced. The following reasoning was stated against this restriction: CLtL doesn't say anywhere what values are allowed, but a reasonable inference is that NIL is allowed, and "documentation information" might have been meant to include some sort of structures as well. CLtL states four times that strings are the things that are associated with symbols as documentation. It never states that anything else can be associated with symbols as documentation. CLtL does state that the function DOCUMENTATION will return NIL if no documentation exists. The statement ``SETF may be used with DOCUMENTATION to update documentation information'' in the context of the documentation section and the section on SETF does not imply anything about the types of new values, but it similarly does not imply anything about the nature of the update except that whatever happens, DOCUMENTATION returns a string or NIL. So if a structure is given as the new value in a SETF expression, DOCUMENTATION will return a string or NIL - one cannot be sure that if it returns a string that the string is related to the structure. It is reasonable to conclude that NIL can be given to SETF of DOCUMENTATION, but the reasonable conclusion about the effect of this is to remove any association between an existing documentation string and the symbol. I therefore favor introducing the restriction. -rpg-  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 29 Jan 88 22:07:58 EST Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 29 Jan 88 19:03:20 PST Received: from Cabernet.ms by ArpaGateway.ms ; 29 JAN 88 19:01:36 PST Date: 29 Jan 88 19:01 PST Sender: Bobrow.pa@Xerox.COM From: Danny Bobrow Subject: Re: Comments on latest draft documents In-reply-to: David A. Moon 's message of Fri, 29 Jan 88 14:06 EST To: Moon@STONY-BROOK.SCRC.Symbolics.COM cc: LGD@SAIL.STANFORD.EDU, Common-Lisp-Object-System@SAIL.STANFORD.EDU Message-ID: <880129-190136-2313@Xerox> I don't think anything was decided. My point is that it's silly, in my opinion, to use parameter specializers on new-value arguments to setf methods as a way of doing type-checking (rather than specialization), and more importantly that I don't think the CLOS specification should imply that if you need to store a different type of value, you have to define your own method. I suppose this comes down to the issue of what is the contract of the method and what is the contract of the generic function, again. Since we agreed not to try to solve that in chapter 2 this time around, I would be happier if the method signatures didn't specialize the new-value arguments. I agree with this point. I think that in general it is a bad way of doing business to specialize arguments in CLOS just for type checking purposes. It implies that there might be other specializations, not that some of the arguments determine the type for the rest of the arguments. If anyone wants to argue for or against the class-name function being restricted by the CLOS specification to return only symbols, this is the place to speak up about it. I would strongly prefer not to put this restriction on class-name at this time.  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 29 Jan 88 16:36:02 EST Received: from RELAY.CS.NET by SAIL.Stanford.EDU with TCP; 29 Jan 88 13:31:47 PST Received: from relay2.cs.net by RELAY.CS.NET id ac08902; 29 Jan 88 14:45 EST Received: from csc.ti.com by RELAY.CS.NET id ai06767; 29 Jan 88 14:29 EST Received: from Jenner by tilde id AA03005; Fri, 29 Jan 88 12:34:53 CST Message-Id: <2779468561-913565@Jenner> Date: Fri, 29 Jan 88 12:36:01 CST From: Patrick H Dussud To: common-lisp-object-system@SAIL.STANFORD.EDU Subject: Re: class updating protocol In-Reply-To: Msg of 29 Jan 88 09:23 PST from Danny Bobrow Date: 29 Jan 88 09:23 PST From: Danny Bobrow Subject: Re: class updating protocol Does update-dependent call update-dependent on its dependents, or is the dependent structure flat? This probably needs to be specified. The intent was that update-dependent would flat. Of course, if the way a particlar method on update-dependent works is to call reinitinaize-instance then ... Why does finalize-inheritance have to do its work by calling (UPDATE-DEPENDENT class class)? It seems backward to me. Why can't UPDATE-DEPENDENT call (FINALIZE-INHERITANCE dependent), and FINALIZE-INHERITANCE do the slot and CPL computation? Because finalize-inheritance is defined to do nothing after the first time that inheritance is finalized. This is to avoid having redundant calls to finalize-inheritance recompute each time. I understand that, but why does finalize-inheritance have to be called redundantly? the code that calls it can check the status of the class before. This seems cleaner. Patrick.  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 29 Jan 88 15:52:22 EST Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 29 Jan 88 12:47:16 PST Received: from Semillon.ms by ArpaGateway.ms ; 29 JAN 88 12:47:47 PST Date: Fri, 29 Jan 88 12:45 PST From: Gregor.pa@Xerox.COM Subject: call-method proposal prime prime To: David A. Moon cc: common-lisp-object-system@SAIL.STANFORD.EDU Fcc: BD:>Gregor>mail>outgoing-mail-1.text In-Reply-To: <19880129023837.1.MOON@EUPHRATES.SCRC.Symbolics.COM> Message-ID: <880129124557.4.GREGOR@SPIFF.parc.xerox.com> Line-fold: no Date: Thu, 28 Jan 88 21:38 EST From: David A. Moon I noticed that MAKE-METHOD is never actually macroexpanded, but I think it is easier for the user to think of it as a local macro that changes a form into a method, even though it's not implemented that way. I don't feel real strongly about this, but unless you feel strongly let's leave it alone. I don't know how strongly I feel, but let me show you the case that bothers me, and if it doesn't bother you too much we'll leave it. The general form of the case is when you don't construct the second argument to call-next-method in a special place, so you have the whole call-method form laid out in front of you. Suppose you knew there was one around method and two or methods. Lets just say that was a special kind of method combination you had. It would look like: (define-method-combination 1-n-2 () ((around (:around)) (or (:or))) (let ((around (car around)) (or-1 (car or)) (or-2 (cadr or))) `(call-method ,around ((make-method (or ,or-1 ,or-2)))))) It seems like when the user sees that case they are going to start realizing pretty quick that make-method isn't really a lexical macro. There is this whole question of when naivete is helpful and when it is confusing. I kind of believe that in this case, the naive model we are proposing might confuse people without them knowing why. But as I said before if this doesn't bother anyone else I am will to let it go. -------  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 29 Jan 88 14:55:23 EST Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 29 Jan 88 11:51:37 PST Received: from Semillon.ms by ArpaGateway.ms ; 29 JAN 88 11:48:28 PST Date: Fri, 29 Jan 88 11:46 PST From: Gregor.pa@Xerox.COM Subject: Re: reinitialization protocol To: kempf%hplabsz@hplabs.HP.COM cc: common-lisp-object-system@SAIL.STANFORD.EDU Fcc: BD:>Gregor>mail>outgoing-mail-1.text In-Reply-To: <27799.570473593@hplabsz> Message-ID: <880129114646.2.GREGOR@SPIFF.parc.xerox.com> Line-fold: no Date: Fri, 29 Jan 88 08:53:13 PST From: kempf%hplabsz@hplabs.HP.COM > ;;; Generic functions for managing the dependents of an object. This is Perhaps this is in the mop document, but, can you give a short, high level description of what exactly a "dependent" is? With an example? I briefly looked over my back mail and couldn't find anything. Thanks. Dependents are based on the idea Patrick proposed in Boston that a class, when it depends on the state of another class, would record itself as a dependent to be notified of any changes. The standard methods arrange that: For all C1,C2 if member(C2, cpl(C1)) then C1 is a dependent of C2. In english, whenever a class C1 inherits from another class C2, C1 is a dependent of C2. The fact that C1 is recorded as a dependent of C2 means that whenever C2 changes, C1 will have update dependent called on it. -------  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 29 Jan 88 14:50:53 EST Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 29 Jan 88 11:46:18 PST Received: from Semillon.ms by ArpaGateway.ms ; 29 JAN 88 11:45:11 PST Date: Fri, 29 Jan 88 11:42 PST From: Gregor.pa@Xerox.COM Subject: Re: class updating protocol To: Patrick H Dussud cc: common-lisp-object-system@SAIL.STANFORD.EDU Fcc: BD:>Gregor>mail>outgoing-mail-1.text In-Reply-To: <2779452680-5011654@Jenner> Message-ID: <880129114214.1.GREGOR@SPIFF.parc.xerox.com> Line-fold: no Date: Fri, 29 Jan 88 08:11:20 CST From: Patrick H Dussud Does update-dependent call update-dependent on its dependents, or is the dependent structure flat? This probably needs to be specified. The dependent structure is flat. Why does finalize-inheritance have to do its work by calling (UPDATE-DEPENDENT class class)? It seems backward to me. Why can't UPDATE-DEPENDENT call (FINALIZE-INHERITANCE dependent), and FINALIZE-INHERITANCE do the slot and CPL computation? The idea was that finalize-inheritance was a stupid function the user could call. Update dependent is a function that gets called with keyword arguments telling it what happened. When it gets called with no keyword arguments it means "something happened just make sure everything is OK". Users could add keywords to the list it gets called with to make it even smarter. -------  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 29 Jan 88 14:39:33 EST Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 29 Jan 88 11:34:24 PST Received: from Cabernet.ms by ArpaGateway.ms ; 29 JAN 88 11:32:35 PST Date: 29 Jan 88 11:31 PST Sender: Bobrow.pa@Xerox.COM From: Danny Bobrow Subject: Re: reinitialization protocol In-reply-to: kempf%hplabsz@hplabs.HP.COM's message of Fri, 29 Jan 88 08:53:13 PST To: kempf%hplabsz@hplabs.HP.COM cc: Gregor.pa@Xerox.COM, common-lisp-object-system@sail.stanford.edu Message-ID: <880129-113235-1700@Xerox> > ;;; Generic functions for managing the dependents of an object. This is Perhaps this is in the mop document, but, can you give a short, high level description of what exactly a "dependent" is? With an example? I briefly looked over my back mail and couldn't find anything. Thanks. The concept of dependent is not in the document that you received. Patrick and Dave suggested at the Cambridge meeting that only some subclasses of a given class need be updated when the class changes (A class that never has had its inheritance finalized need not be updated). They suggested that a subclass could register itself with a superclass when it wanted to be notified of changes to that superclass. The generalization is as follows. An object O2 is dependent on O1 if it registers itself as such. The intent is that O2 will be notified if O1 changes in certain ways. Of course, methods on O1 must cooperate to the extent that they call update-dependent for each dependent, but they need not know anything about what update-dependent will do to O2. This use of registered dependents has had a long and successful history in Smalltalk in their model view controller paradigm, where views are dependents on the objects they are viewing.  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 29 Jan 88 14:10:42 EST Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 29 Jan 88 11:06:33 PST Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 331555; Fri 29-Jan-88 14:06:48 EST Date: Fri, 29 Jan 88 14:06 EST From: David A. Moon Subject: Re: Comments on latest draft documents To: Linda DeMichiel cc: Common-Lisp-Object-System@SAIL.STANFORD.EDU In-Reply-To: The message of 28 Jan 88 18:26 EST from Linda DeMichiel Message-ID: <19880129190654.7.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: 28 Jan 88 1526 PST From: Linda DeMichiel In your message ``Comments on latest draft documents,'' you write: 2-17 class-name: The name of a class should not be restricted in type. The method signature should specialize new-value with t, the arguments should say new-value is typically a symbol, and the semicolon clause under values should be deleted. While a class's proper name is a symbol unless symbol-class is somehow extended, class-name should be allowed to be any object. One proposed extension we discussed earlier has class-name a list of classes. Neither Dick nor I recall this having been decided. If this is really what you want, I think you should bring this up for a vote on the list. I don't think anything was decided. My point is that it's silly, in my opinion, to use parameter specializers on new-value arguments to setf methods as a way of doing type-checking (rather than specialization), and more importantly that I don't think the CLOS specification should imply that if you need to store a different type of value, you have to define your own method. I suppose this comes down to the issue of what is the contract of the method and what is the contract of the generic function, again. Since we agreed not to try to solve that in chapter 2 this time around, I would be happier if the method signatures didn't specialize the new-value arguments. If anyone wants to argue for or against the class-name function being restricted by the CLOS specification to return only symbols, this is the place to speak up about it. 2-41 documentation method signatures: The parameter specializer name for new-value should be t, not string. CLtL doesn't say anywhere what values are allowed, but a reasonable inference is that NIL is allowed, and "documentation information" might have been meant to include some sort of structures as well. The allowable types here are a matter for CL to define, not for CLOS to legislate. t doesn't strike us as a reasonable generalization of string and nil. It's the only one that CLOS has, since it doesn't allow OR. But my point wasn't that the specializer should be (OR STRING NULL); my point was that it's not up to CLOS to define the allowable types here, and as far as the CLOS specification goes, the new-value parameter should not be restricted. It seems to us that adding signatures for setf methods for (eql nil) is a more sensible thing to do. To me that's a much less sensible thing to do! The need to duplicate the method shows that using the parameter specializer to do type-checking, rather than specialization, was a mistake. At least that's how I see it. I suppose none of this really matters, because it's only the method signatures in the document, and we already agreed that those are going to be discovered to be incorrect in the future.  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 29 Jan 88 12:31:17 EST Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 29 Jan 88 09:27:15 PST Received: from Cabernet.ms by ArpaGateway.ms ; 29 JAN 88 09:27:24 PST Date: 29 Jan 88 09:23 PST Sender: Bobrow.pa@Xerox.COM From: Danny Bobrow Subject: Re: class updating protocol In-reply-to: Patrick H Dussud 's message of Fri, 29 Jan 88 08:11:20 CST To: DUSSUD@jenner.csc.ti.com cc: common-lisp-object-system@SAIL.STANFORD.EDU Message-ID: <880129-092724-1477@Xerox> Does update-dependent call update-dependent on its dependents, or is the dependent structure flat? This probably needs to be specified. The intent was that update-dependent would flat. Of course, if the way a particlar method on update-dependent works is to call reinitinaize-instance then ... Why does finalize-inheritance have to do its work by calling (UPDATE-DEPENDENT class class)? It seems backward to me. Why can't UPDATE-DEPENDENT call (FINALIZE-INHERITANCE dependent), and FINALIZE-INHERITANCE do the slot and CPL computation? Because finalize-inheritance is defined to do nothing after the first time that inheritance is finalized. This is to avoid having redundant calls to finalize-inheritance recompute each time. danny  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 29 Jan 88 12:09:37 EST Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 29 Jan 88 09:05:21 PST Received: from hplabs.HP.COM by SCORE.STANFORD.EDU with TCP; Fri 29 Jan 88 08:48:59-PST Received: from hplms2.HP.COM (hplms2) by hplabs.HP.COM with SMTP ; Fri, 29 Jan 88 08:51:33 PST Received: from hplabsz.hpl.hp.com (hplabsz.hpl.hp.com) by hplms2.HP.COM; Fri, 29 Jan 88 08:51:08 pst Received: from hplabsz by hplabsz; Fri, 29 Jan 88 08:53:16 pst To: Gregor.pa@Xerox.COM Cc: common-lisp-object-system@sail.stanford.edu Subject: Re: reinitialization protocol In-Reply-To: Your message of Thu, 28 Jan 88 11:45:00 -0800. <880128114541.6.GREGOR@SPIFF.parc.xerox.com> Date: Fri, 29 Jan 88 08:53:13 PST Message-Id: <27799.570473593@hplabsz> From: kempf%hplabsz@hplabs.HP.COM > ;;; Generic functions for managing the dependents of an object. This is Perhaps this is in the mop document, but, can you give a short, high level description of what exactly a "dependent" is? With an example? I briefly looked over my back mail and couldn't find anything. Thanks. jak  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 29 Jan 88 11:05:13 EST Received: from RELAY.CS.NET by SAIL.Stanford.EDU with TCP; 29 Jan 88 08:00:11 PST Received: from relay2.cs.net by RELAY.CS.NET id af05245; 29 Jan 88 10:46 EST Received: from csc.ti.com by RELAY.CS.NET id aj05448; 29 Jan 88 10:33 EST Received: from Jenner by tilde id AA26800; Fri, 29 Jan 88 08:10:14 CST Message-Id: <2779452680-5011654@Jenner> Date: Fri, 29 Jan 88 08:11:20 CST From: Patrick H Dussud To: common-lisp-object-system@SAIL.STANFORD.EDU Subject: Re: class updating protocol In-Reply-To: Msg of Thu, 28 Jan 88 11:51 PST from Gregor.pa@xerox.com ;;;; The class updating protocol. I don't object to the principles of this protocol. I have some specific comment here, and I sent some comments about reinitialize-instance earlier this week. ;;; ;;; This is called when a class is reinitialized, and the dependent has ;;; been recorded as one of the dependents of that class. It is supposed ;;; to make sure the dependent class is updated to take the change into ;;; account. ;;; (defmethod update-dependent :around ((reinitialized-class standard-class) (dependent standard-class) &allow-other-keys) (let ((old-access-keys (class-access-keys dependent))) (call-next-method) (unless (equal old-access-keys (class-access-keys dependent)) ;; Implementation specific code to account for the fact that ;; the access keys for this class have changed. This will ;; cause the optimization of standard-instance-access to ;; continue to work. ;; This may include a call to make-instance-obsolete. ))) (defmethod update-dependent ((reinitialized-class standard-class) (dependent standard-class) &key direct-superclasses direct-slots direct-options) ;; When we are called, dependent is finalized since our finalize ;; inheritance method is what recorded us as a dependent. We ;; have to do whatever updating is required to keep us finalized. ;; This includes: ;; - recomputing our class-precedence-list ;; go through the old and new cpls, calling remove-dependent ;; and add-dependent to update our dependents. ;; - recomputing our slots, this may change the value that ;; class-access-keys will be returning. ;; - go through the old and new slots adding and removing ;; automatically generated reader and writer methods as ;; required. ) Does update-dependent call update-dependent on its dependents, or is the dependent structure flat? This probably needs to be specified. (defmethod finalize-inheritance ((class standard-class)) ;; When we are called, the class is supposed to not be finalized. ;; We are supposed to ensure that it is finalized, that an instance ;; can be created. But sometimes we are called redundantly. First ;; we check to see if we are already finalized, if we are, we do ;; nothing. If we aren't, we set cpl and slots to NIL and then call ;; update-dependent with only two arguments, each of which is the ;; class. Once update dependent returns, we set class-finalized-p ;; of the class to T. ) Why does finalize-inheritance have to do its work by calling (UPDATE-DEPENDENT class class)? It seems backward to me. Why can't UPDATE-DEPENDENT call (FINALIZE-INHERITANCE dependent), and FINALIZE-INHERITANCE do the slot and CPL computation? Patrick.  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 28 Jan 88 21:42:47 EST Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 28 Jan 88 18:38:27 PST Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 331156; Thu 28-Jan-88 21:38:37 EST Date: Thu, 28 Jan 88 21:38 EST From: David A. Moon Subject: call-method proposal prime prime To: common-lisp-object-system@SAIL.STANFORD.EDU In-Reply-To: <880128172740.3.GREGOR@SPIFF.parc.xerox.com> Message-ID: <19880129023837.1.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Thu, 28 Jan 88 17:27 PST From: Gregor.pa@Xerox.COM This is all fine except for one small thing. Since I sent this proposal out, I have realized that (what you are calling) make-method isn't really a lexical macro, it is just a special symbol which marks the car of lists which appear in the second argument to call-method. There is no problem with that particularly. I do think it means we should switch the name back to EFFECTIVE-METHOD or just METHOD since it really doesn't make anything at all. I noticed that MAKE-METHOD is never actually macroexpanded, but I think it is easier for the user to think of it as a local macro that changes a form into a method, even though it's not implemented that way. I don't feel real strongly about this, but unless you feel strongly let's leave it alone.  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 28 Jan 88 21:08:44 EST Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 28 Jan 88 18:04:08 PST Received: from Semillon.ms by ArpaGateway.ms ; 28 JAN 88 17:29:42 PST Date: Thu, 28 Jan 88 17:27 PST From: Gregor.pa@Xerox.COM Subject: call-method proposal prime prime To: David A. Moon cc: common-lisp-object-system@SAIL.STANFORD.EDU Fcc: BD:>Gregor>mail>outgoing-mail-1.text In-Reply-To: <19880128041515.6.MOON@EUPHRATES.SCRC.Symbolics.COM> Message-ID: <880128172740.3.GREGOR@SPIFF.parc.xerox.com> Line-fold: no Date: Wed, 27 Jan 88 23:15 EST From: David A. Moon I take it we have agreed on this. Here are the changes to the document. In cases where the mail was unclear, I made some decisions. I hope there is time to make these changes before we have to ship the documents to X3J13. I apologize for the delay in getting this out; pulling it all together has been a bigger job than I expected, and I had some other things that had to be done first. This is all fine except for one small thing. Since I sent this proposal out, I have realized that (what you are calling) make-method isn't really a lexical macro, it is just a special symbol which marks the car of lists which appear in the second argument to call-method. There is no problem with that particularly. I do think it means we should switch the name back to EFFECTIVE-METHOD or just METHOD since it really doesn't make anything at all. -------  Received: from Xerox.COM (TCP 1500006350) by AI.AI.MIT.EDU 28 Jan 88 20:30:56 EST Received: from Cabernet.ms by ArpaGateway.ms ; 28 JAN 88 16:36:06 PST Date: Thu, 28 Jan 88 16:31 PST From: Gregor.pa@Xerox.COM Subject: Ibuki Common Lisp To: CommonLoops.PA@Xerox.COM Message-ID: <880128163147.1.GREGOR@SPIFF.parc.xerox.com> Line-fold: no Let me clarify that the newest version of PCL was not tested in KCL, it was tested in Ibuki Common Lisp version 01/01. It works fine in that Lisp as well as the others mentioned: Symbolics, Lucid, Franz, Coral, Xerox and TI Common Lisps. -------  Received: from Xerox.COM (TCP 1500006350) by AI.AI.MIT.EDU 28 Jan 88 19:21:53 EST Received: from Semillon.ms by ArpaGateway.ms ; 28 JAN 88 16:05:35 PST Date: Thu, 28 Jan 88 16:01 PST From: Gregor.pa@Xerox.COM Subject: new new version of pcl To: CommonLoops.PA@Xerox.COM Message-ID: <880128160143.0.GREGOR@SPIFF.parc.xerox.com> Line-fold: no If you were all gung ho, and you snarfed the new version of PCL off of parcvax.xerox.com before 4:00pm PDT, you should copy yourself another version. Also note that the new version runs in KCL. The notes.text file has been updated to take this into account. -------  Received: from Xerox.COM (TCP 1500006350) by AI.AI.MIT.EDU 28 Jan 88 17:47:22 EST Received: from Semillon.ms by ArpaGateway.ms ; 28 JAN 88 14:34:38 PST Date: Thu, 28 Jan 88 14:27 PST From: Gregor.pa@Xerox.COM Subject: new version of PCL To: CommonLoops.pa@Xerox.COM Fcc: BD:>Gregor>mail>outgoing-mail-1.text Message-ID: <880128142739.9.GREGOR@SPIFF.parc.xerox.com> Line-fold: no There is a new version of PCL on parcvax.xerox.com. This version includes various fixes, including the fix to make call-next-method arguments work correctly. It also includes new macros with-slots* and with-accessors*. Please read the documentation in notes.text carefully. These macros don't work the way they did in the December draft of the CLOS spec, they work the newer way. This release also includes :around methods. This release also includes an even more revised walker, people using the walker will want to check walk.lisp for details. Gregor -------  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 28 Jan 88 14:58:11 EST Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 28 Jan 88 11:52:37 PST Received: from Semillon.ms by ArpaGateway.ms ; 28 JAN 88 11:53:27 PST Date: Thu, 28 Jan 88 11:51 PST From: Gregor.pa@Xerox.COM Subject: class updating protocol To: common-lisp-object-system@SAIL.STANFORD.EDU Fcc: BD:>Gregor>mail>outgoing-mail-1.text Message-ID: <880128115133.7.GREGOR@SPIFF.parc.xerox.com> Line-fold: no Here is some pseudo code for the new class updating protocol. This code tries to take all the comments we got in Boston into account. Please try to comment on this soon as the rest of the mop re-design depends on it. As you read this, some things which are not specifically specified are: class-access-keys is a generic function which returns the access keys for a class. This is used to interface to the symbolic access layer. As we discussed in Boston, there is no longer any reference to index numbers, instead, access-keys (often symbols) are used to talk symbolically about the `cells' which standard-instance-access references. Also notes that this is based on the instance re-initialization stuff we sent out in a previous message. ;;;; The class updating protocol. ;;; ;;; This is called when a class is reinitialized, and the dependent has ;;; been recorded as one of the dependents of that class. It is supposed ;;; to make sure the dependent class is updated to take the change into ;;; account. ;;; (defmethod update-dependent :around ((reinitialized-class standard-class) (dependent standard-class) &allow-other-keys) (let ((old-access-keys (class-access-keys dependent))) (call-next-method) (unless (equal old-access-keys (class-access-keys dependent)) ;; Implementation specific code to account for the fact that ;; the access keys for this class have changed. This will ;; cause the optimization of standard-instance-access to ;; continue to work. ;; This may include a call to make-instance-obsolete. ))) (defmethod update-dependent ((reinitialized-class standard-class) (dependent standard-class) &key direct-superclasses direct-slots direct-options) ;; When we are called, dependent is finalized since our finalize ;; inheritance method is what recorded us as a dependent. We ;; have to do whatever updating is required to keep us finalized. ;; This includes: ;; - recomputing our class-precedence-list ;; go through the old and new cpls, calling remove-dependent ;; and add-dependent to update our dependents. ;; - recomputing our slots, this may change the value that ;; class-access-keys will be returning. ;; - go through the old and new slots adding and removing ;; automatically generated reader and writer methods as ;; required. ) (defmethod finalize-inheritance ((class standard-class)) ;; When we are called, the class is supposed to not be finalized. ;; We are supposed to ensure that it is finalized, that an instance ;; can be created. But sometimes we are called redundantly. First ;; we check to see if we are already finalized, if we are, we do ;; nothing. If we aren't, we set cpl and slots to NIL and then call ;; update-dependent with only two arguments, each of which is the ;; class. Once update dependent returns, we set class-finalized-p ;; of the class to T. ) (defmethod reinitialize-instance :before ((class standard-class) &key direct-superclasses direct-slots direct-options) ;; unhook old direct-subclass pointers ) ;;; ;;; When this is called, direct-superclasses must be a list of class ;;; objects, direct-slots must be a list of slot description objects ;;; and direct options is a list of class options as in defclass. ;;; (defmethod initialize-instance :after ((class standard-class) &key direct-superclasses direct-slots direct-options) ;; hook up new direct-subclass pointers ;; Store the values we get passed in the instance. ) -------  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 28 Jan 88 14:51:57 EST Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 28 Jan 88 11:47:20 PST Received: from Semillon.ms by ArpaGateway.ms ; 28 JAN 88 11:47:45 PST Date: Thu, 28 Jan 88 11:45 PST From: Gregor.pa@Xerox.COM Subject: reinitialization protocol To: common-lisp-object-system@SAIL.STANFORD.EDU Fcc: BD:>Gregor>mail>outgoing-mail-1.text Message-ID: <880128114541.6.GREGOR@SPIFF.parc.xerox.com> Line-fold: no Here is some pseudo code for the re-initialization protocol that Danny and I worked out. ;;;; The re-initialization protocol. (defmethod reinitialize-instance ((object standard-object) &rest reinit-args) (let* ((arglist (list object)) (acceptable-args (union (method-keyword-arguments #'initialize-instance arglist) (method-keyword-arguments #'reinitialize-instance arglist) (class-all-slot-initargs (class-of object))))) ;; check the keyword arguments (zl:loop (key in reinit-args by cddr) (or (member key acceptable-args) (error ...))) ;; now initialize the instance (apply #'initialize-instance object :allow-other-keys 't (default-init-args object reinit-args)) ;; update all dependents (loop (dep in (all-dependents object)) (apply #'update-dependent object dependent reinit-args)) nil)) ;;; ;;; Generic functions for managing the dependents of an object. This is ;;; part of the instance re-initialization protocol. How dependents are ;;; stored is implementation dependent. Some subclasses of ;;; standard-object which know that they are in fact going to have lots ;;; of dependents may want to replace this triad of methods with methods ;;; which actually store the value in a slot. ;;; (defmethod add-dependent ((object standard-object) (dependent standard-object)) ;; Add dependent as a dependent of object. ) (defmethod remove-dependent ((object standard-object) (dependent standard-object)) ;; Remove dependent as a dependent of object. ) (defmethod all-dependents ((object standard-object)) ;; Returns the list of all dependents of the object. ) -------  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 28 Jan 88 12:55:41 EST Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 28 Jan 88 09:11:04 PST Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 330415; Thu 28-Jan-88 11:59:35 EST Date: Thu, 28 Jan 88 11:59 EST From: David A. Moon Subject: Method Combination Objects To: Common-Lisp-Object-System@SAIL.STANFORD.EDU References: <19880127173423.8.MOON@EUPHRATES.SCRC.Symbolics.COM>, <19880127210152.5.MOON@EUPHRATES.SCRC.Symbolics.COM> Message-ID: <19880128165933.0.MOON@EUPHRATES.SCRC.Symbolics.COM> Revised, based on Gregor's and Jim's comments. Nothing new here, just amalgamation of previous mail. First, the impact on chapters 1 and 2. Page numbers refer to the 20 Jan 1988 drafts. 1-33 last paragraph (excluding the implementation note), second sentence. Replace this sentence with: "The generic function {\bf compute-effective-method} receives as arguments the generic function, the method combination object, and the sorted list of applicable methods." Append to the paragraph: "A method combination object is a meta-object that encapsulates the method combination type and options specified by the {\bf :method-combination} option to forms that specify generic function options." 1-40: This is optional, but I think we should add method combination objects to the list of meta-objects. Each method combination object is an instance of a subclass of the class {\bf method-combination}. I don't think we need to name any of the subclasses here, not even {\bf standard-method-combination}; that's chapter 3 material for now. 2-42 documentation method signatures: Add two for method-combination (italic) method-combination (bold), for documentation and for setf of documentation. On the next page, under arguments, the first bullet should mention method combination objects too. 2-43 ensure-generic-function arguments: Nothing really needs to be changed, since the value of the :method-combination argument is not described at all in the latest draft. However, I suggest two sentences should be added: "The {\bf :method-combination} argument is a method combination object. A method combination object is a meta-object that encapsulates the method combination type and options specified by the {\bf :method-combination} option to forms that specify generic function options." That's all that has to be changed in chapters 1 and 2. Here's an approximation of what goes into chapter 3. I have done no editing for style here, only content. I've left out the design rationale this time, to keep this small. Consult the referenced messages of the referenced messages if you want to see it again. Method Combination Naming Layer This layer is concerned with mapping method combination names and options, as seen in the :method-combination option to defgeneric, to method combination meta-objects. (method-combination-object method-combination-name method-combination-options) => method-combination is how a method combination name and a list of options are converted into an object. define-method-combination expands into a defmethod for method-combination-object. remove-method can be used to undefine a method combination type. method-combination-object signals an error if method-combination-name is unrecognized. Each method for method-combination-object signals an error if the method-combination-options are unrecognized or there are too many or too few of them. method-combination-object might return the same object each time it is called with given arguments, or it might make a new object. (method-combination-name method-combination) => symbol (method-combination-options method-combination) => list These two generic functions perform the inverse mapping. Method Combination Object Layer method-combination This class is a superclass of all classes of method combination. standard-method-combination This class is the class of the method combination object used by default when :method-combination is not specified. Other implementation-dependent subclasses of method-combination exist. For example, all invocations of the short form of define-method-combination probably use one class, and each invocation of the long form of define-method-combination probably defines a new class which has a superclass in common with standard-method-combination. CLOS does not specify how many of these classes there are nor what their names are. (compute-effective-method generic-function method-combination method-list) => effective-method-form This generic function performs part 3 of the determination of the effective method. define-method-combination works through methods that specialize the second parameter. (describe-method-role-concisely generic-function method method-combination) This generic function prints a description of the method's role onto *standard-output*. The value returned is ignored. The description is generally determined jointly by the method-combination and the method's qualifiers. The description describes only the method's role, not its generic function and not its parameter specializers; those would be described by the caller or implied by context (e.g. if the caller is printing a table of methods for a particular generic function). define-method-combination defines a method for describe-method-role-concisely that uses the :description option of the long form to control what it prints. Other generic functions specialized by method combinations are not currently defined by CLOS, but program development environments are likely to have some. A generic function object records a method combination object, rather than the name and options of a method combination type. This changes the initialization arguments and structural access functions for generic functions from what is in chapter 3 now. There will be a structural access function that, given a generic function object, returns a method combination object. defgeneric calls method-combination-object before it calls ensure-generic-function. Example The short form of define-method-combination could have been defined as follows: (defclass short-form-method-combination (method-combination) ((name :initarg name :reader method-combination-name) (order :initarg order) (documentation :initarg documentation :reader documentation) (operator :initarg operator) (identity-with-one-argument :initarg identity-with-one-argument))) (defmethod method-combination-options ((mc short-form-method-combination)) (list (slot-value mc 'order))) (defmethod compute-effective-method (generic-function (mc short-form-method-combination) methods) (let ((primary-methods (remove (list (slot-value mc 'name)) methods :key #'method-qualifiers :test-not #'equal)) (around-methods (remove '(:around) methods :key #'method-qualifiers :test-not #'equal))) (when (eq (slot-value mc 'order) ':most-specific-last) (setq primary-methods (reverse primary-methods))) (dolist (method (set-difference methods (union primary-methods around-methods))) (invalid-method-error method "The qualifiers of ~S, ~:S, are not ~S or ~S" method (method-qualifiers method) (list (slot-value mc 'name)) '(:around))) (let ((form (if (or (rest primary-methods) (not (slot-value mc 'identity-with-one-argument))) `(,(slot-value mc 'operator) ,@(mapcar #'(lambda (method) `(call-method ,method ())) primary-methods)) `(call-method ,(first primary-methods) ())))) (if around-methods `(call-method ,(first around-methods) (,@(rest around-methods) (make-method ,form))) form)))) (defmethod describe-method-concisely (generic-function method (method-combination short-form-method-combination)) (declare (ignore generic-function)) (write-string (string-downcase (string (first (method-qualifiers method)))))) (defmacro define-method-combination (name &key (documentation nil) (operator name) (identity-with-one-argument nil)) `(defmethod method-combination-object ((name (eql ',name)) options) (apply #'(lambda (&optional (order ':most-specific-first)) (check-type order (member :most-specific-first :most-specific-last)) (make-instance 'short-form-method-combination 'name ',name 'order order 'documentation ',documentation 'operator ',operator 'identity-with-one-argument ',identity-with-one-argument)) options))) Example of Defining a Method Combination Type via Inheritance ;This example defines a method combination type that is similar ;to standard method combination, except that it also allows :or ;methods. The :or methods are executed after the :before methods, ;before the :after methods, inside the :around methods, and before ;the primary method. The primary method is only called if all the ;:or methods return nil; if any :or method returns non-nil, its ;value becomes the value of the generic function (or the value ;returned by call-next-method in the least specific :around method) ;in place of the values of the most specific primary method. ;This assumes one particular code analysis tool, whose ;details I will not try to explain here. ;Those assumptions are not critical. ;I'm assuming we don't want to try to extend the define-method-combination ;macro so that it could exploit inheritance. Instead I will ;define the example directly in terms of the next layer down. (defclass standard-method-combination-with-or (standard-method-combination) ()) (defmethod method-combination-object ((name (eql 'standard-with-or)) options) (unless (null options) (error "standard-with-or method combination does not accept options")) (make-instance 'standard-method-combination-with-or)) ;This uses call-next-method to get the effective method in the absence ;of any :or methods, then it modifies the effective method form to ;incorporate the :or methods in an OR special form wrapped around the ;call to the most specific primary method. (defmethod compute-effective-method (generic-function (mc standard-method-combination-with-or) methods) (let ((or-methods (remove '(:or) methods :key #'method-qualifiers :test-not #'equal)) (other-methods (remove '(:or) methods :key #'method-qualifiers :test #'equal))) (lt:copyforms #'(lambda (subform kind usage) (declare (ignore usage)) (if (and (listp kind) (listp subform) (eq (first subform) 'call-method) (null (method-qualifiers (second subform)))) ;; Put or methods before primary method (values `(or ,@(mapcar #'(lambda (method) `(call-method ,method ())) or-methods) ,subform) t) ;; Leave all other subforms of effective method alone subform)) (call-next-method generic-function mc other-methods))))  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 28 Jan 88 12:52:20 EST Received: from RELAY.CS.NET by SAIL.Stanford.EDU with TCP; 28 Jan 88 08:04:32 PST Received: from relay2.cs.net by RELAY.CS.NET id ac17775; 28 Jan 88 10:53 EST Received: from csc.ti.com by RELAY.CS.NET id ad27897; 28 Jan 88 10:41 EST Received: from Jenner by tilde id AA03795; Thu, 28 Jan 88 08:21:29 CST Message-Id: <2779366878-5179661@Jenner> Date: Thu, 28 Jan 88 08:21:18 CST From: Patrick H Dussud To: common-lisp-object-system@SAIL.STANFORD.EDU Subject: call-method proposal In-Reply-To: Msg of Wed, 27 Jan 88 23:15 EST from "David A. Moon" Date: Wed, 27 Jan 88 23:15 EST From: "David A. Moon" Subject: call-method proposal prime prime I take it we have agreed on this. Here are the changes to the document. In cases where the mail was unclear, I made some decisions. I hope there is time to make these changes before we have to ship the documents to X3J13. I apologize for the delay in getting this out; pulling it all together has been a bigger job than I expected, and I had some other things that had to be done first. I basically agree with the text, I noticed that the distinction between "there are no more next methods" and "call-next-method cannot be called" is not there anymore. I don't object though. Patrick.  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 28 Jan 88 12:52:08 EST Received: from RELAY.CS.NET by SAIL.Stanford.EDU with TCP; 28 Jan 88 08:03:06 PST Received: from relay2.cs.net by RELAY.CS.NET id aa17775; 28 Jan 88 10:53 EST Received: from csc.ti.com by RELAY.CS.NET id ab27897; 28 Jan 88 10:41 EST Received: from Jenner by tilde id AA03536; Thu, 28 Jan 88 08:07:15 CST Message-Id: <2779366011-5127571@Jenner> Date: Thu, 28 Jan 88 08:06:51 CST From: Patrick H Dussud To: Common-Lisp-Object-System@SAIL.STANFORD.EDU Subject: Re: Method Combination Objects In-Reply-To: Msg of Wed, 27 Jan 88 16:01 EST from "David A. Moon" Since method-combination-instance (method-combination-object) must be called before ensure-generic-function is called, its first argument is actually a prototype of the generic function. On 13 January, Danny said [method-combination-instance] allows specialization on the class of the generic function as well as on the name. Although useful, this might not be important because compute-effective-method also allows specialization on both the generic function and method combination object. Given this, and what you just pointed out, I think it was a mistake to make the generic function an argument here. Thus I think the arguments should be (method-combination-object name options) => object. This doesn't affect chapter 1 or 2. I think this is right. Patrick.  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 28 Jan 88 06:48:02 EST Received: from labrea.Stanford.EDU by SAIL.Stanford.EDU with TCP; 28 Jan 88 03:44:59 PST Received: by labrea.Stanford.EDU; Thu, 28 Jan 88 03:45:07 PST Received: from bhopal.lucid.com by edsel id AA23698g; Thu, 28 Jan 88 03:24:42 PST Received: by bhopal id AA03293g; Thu, 28 Jan 88 03:28:33 PST Date: Thu, 28 Jan 88 03:28:33 PST From: Jon L White Message-Id: <8801281128.AA03293@bhopal.lucid.com> To: labrea!kempf%hplabs.HP.COM@labrea.Stanford.EDU Cc: labrea!common-lisp-object-system%sail.stanford.edu@labrea.Stanford.EDU In-Reply-To: kempf%hplabsz@hplabs.HP.COM's message of Wed, 27 Jan 88 13:25:12 PST <352.570317112@hplabsz> Subject: Type-checking of slot values re: Alternatively, one could modify DEFCONSTANT to allow declaration of constant structure as well as constant binding. I like that idea [of having declared constant classes]. A related topic is "lexical" structures so that can be allocated/de-allocated in a "stack" discipline [akin to how the strongly-typed languages would do it]. However, given the current problems and focus of CLOS specification, this may not be the right time to bring such issues up. Ultimately, the quest for performance may require some thinking along these lines. But (sigh) another time, another place . . . -- JonL --  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 28 Jan 88 00:32:28 EST Date: 27 Jan 88 2128 PST From: Dick Gabriel Subject: Typechecking To: Common-lisp-object-system@SAIL.Stanford.EDU I think Moon must have gotten a bad chapter 1, because I cannot find the quote he mentions in the file that I consider to be the definitive version. The closest I can come is this: ``Because an implementation is required to check the type of the value being stored in a slot only under the safest compiler safety setting and in the interpreter, the value in a slot might fail to satisfy its type constraint.'' I believe this clearly states that violating the type constraint should signal an error. There is no particularly pretty way to use the ``should signal an error'' phrase here, so I expanded the definition of the phrase inline. The use of the word ``only'' in the dependent clause beginning with ``because'' combines with that ``because'' to state that the reason that the value of the slot might fail to live up to the constraint is that an implementation may or may not check the type on initialization and stores. The choices we have available to us are to require checking in all cases, to require checking in at least the safest compiler compilation setting and the interpreter, or to let the results be undefined. Stock hardware people reject the first, and special-purpose people reject the last (they want the results to be defined - to signal an error). Therefore, it has to be ``should signal an error.'' We agreed long ago to abide by this error terminology, and I won't accept backing down on that now. About 2 or 3 paragraphs above the quote I reproduced is the following statement about the :type option: ``Attempting to store a value in a slot which does not satisfy the type should signal an error.'' -rpg-  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 27 Jan 88 23:20:42 EST Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 27 Jan 88 20:15:06 PST Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 330153; Wed 27-Jan-88 23:15:15 EST Date: Wed, 27 Jan 88 23:15 EST From: David A. Moon Subject: call-method proposal prime prime To: common-lisp-object-system@SAIL.STANFORD.EDU References: <19880115034035.4.MOON@EUPHRATES.SCRC.Symbolics.COM>, <19880115034855.5.MOON@EUPHRATES.SCRC.Symbolics.COM>, <2778248738-2219223@Jenner>, <880115133053.3.GREGOR@SPIFF.parc.xerox.com> Message-ID: <19880128041515.6.MOON@EUPHRATES.SCRC.Symbolics.COM> I take it we have agreed on this. Here are the changes to the document. In cases where the mail was unclear, I made some decisions. I hope there is time to make these changes before we have to ship the documents to X3J13. I apologize for the delay in getting this out; pulling it all together has been a bigger job than I expected, and I had some other things that had to be done first. Chapter 1: No changes. Chapter 2: 2-5: In "Tools for declarative method combination", remove make-method-call, add call-method and make-method. 2-30 long form syntax of define-method-combination changes to: \Defmac {define-method-combination} {\vtop{\hbox{name lambda-list } \hbox{\paren{\star{\curly{method-group-specifier}}} } \hbox{\brack{\paren {{\bf :arguments} \dot {\it lambda-list }}}} \hbox{\star{\curly {declaration $\vert$ doc-string}}} \hbox{\star{\curly{form}}}}} or, in English, the list (:arguments . lambda-list) can optionally appear before any declarations or documentation string. I've almost certainly gotten the TeX wrong. 2-33 fifth paragraph: Remove the following sentences: The function {\bf make-method-call} is also used in constructing the Lisp form; it hides the implementation-dependent details of how methods are called. Programmers always use {\bf make-method-call} to translate from the lists of method objects produced by the method-group specifiers to Lisp forms that invoke those methods. Replace them with: The effective method uses the macros {\bf call-method} and {\bf make-method}. They hide the implementation-dependent details of how methods are called. These macros have lexical scope and are only available in an effective method Lisp form. Programmers always translate a method object, an element of one of the lists produced by the method-group specifiers, into a Lisp form that invokes the method by constructing a form that invokes the {\bf call-method} macro with the method object as its first subform and a list of next-method objects as its second subform. Programmers translate a Lisp form into a method object whose body is that form with the {\bf make-method} macro. An invocation of {\bf make-method} can only be used inside of an invocation of {\bf call-method}. Append the following new paragraph: When an effective method has no effect other than to call a single method, some implementations employ an optimization that uses the single method directly as the effective method, thus avoiding the need to create a new effective method. This optimization is active when the effective method Lisp form consists entirely of an invocation of the {\bf call-method} macro whose first subform is a method object and whose second subform is {\bf nil}. Each {\bf define-method-combination} body is responsible for stripping off redundant invocations of {\bf progn}, {\bf and}, {\bf multiple-value-prog1}, and the like, if this optimization is desired. Append the following paragraph: The list {\bf (:arguments . {\it lambda-list\/})} can optionally appear before any declarations or documentation string. This is useful when the method combination type performs some specific behavior as part of the combined method and that behavior needs access to the arguments to the generic function. Each parameter variable defined by {\it lambda-list\/} is bound to a form that can be inserted into the effective method. When this form is evaluated during execution of the effective method, its value is the corresponding argument to the generic function. If {\it lambda-list\/} is not congruent to the generic function's lambda-list, additional ignored parameters are automatically inserted until it is congruent. Thus it is permissible for {\it lambda-list\/} to receive fewer arguments than the number the generic function expects. 2-34 first paragraph: Replace the whole paragraph with: The functions {\bf method-combination-error} and {\bf invalid-method-error} can be called from the body {\it forms\/} or from functions called by the body {\it forms\/}. The actions of these two functions can depend on implementation-dependent dynamic variables automatically bound before the generic function {\bf compute-effective-method} is called. 2-34 through 2-36: Replace the entire Examples section with the following: Most examples of the long form of {\bf define-method-combination} also illustrate the use of the related functions that are provided as part of the declarative method combination facility. \screen! ;;; Examples of the short form of define-method-combination (define-method-combination and :identity-with-one-argument t) (defmethod func and ((x class1) y) ...) ;;; The equivalent of this example in the long form is: (define-method-combination and (&optional (order ':most-specific-first)) ((around (:around)) (primary (and) :order order :required t)) (let ((form (if (rest primary) `(and ,@(mapcar #'(lambda (method) `(call-method ,method ())) primary)) `(call-method ,(first primary) ())))) (if around `(call-method ,(first around) (,@(rest around) (make-method ,form))) form))) ;;; Examples of the long form of define-method-combination ;The default method-combination technique (define-method-combination standard () ((around (:around)) (before (:before)) (primary () :required t) (after (:after))) (flet ((call-methods (methods) (mapcar #'(lambda (method) `(call-method ,method ())) methods))) (let ((form (if (or before after (rest primary)) `(multiple-value-prog1 (progn ,@(call-methods before) (call-method ,(first primary) ,(rest primary))) ,@(call-methods (reverse after))) `(call-method ,(first primary) ())))) (if around `(call-method ,(first around) (,@(rest around) (make-method ,form))) form)))) ;A simple way to try several methods until one returns non-nil (define-method-combination or () ((methods (or))) `(or ,@(mapcar #'(lambda (method) `(call-method ,method ())) methods))) ;A more complete version of the preceding (define-method-combination or (&optional (order ':most-specific-first)) ((around (:around)) (primary (or))) ;; Process the order argument (case order (:most-specific-first) (:most-specific-last (setq primary (reverse primary))) (otherwise (method-combination-error "~S is an invalid order.~@ :most-specific-first and :most-specific-last are the possible values." order))) ;; Must have a primary method (unless primary (method-combination-error "A primary method is required.")) ;; Construct the form that calls the primary methods (let ((form (if (rest primary) `(or ,@(mapcar #'(lambda (method) `(call-method ,method ())) primary)) `(call-method ,(first primary) ())))) ;; Wrap the around methods around that form (if around `(call-method ,(first around) (,@(rest around) (make-method ,form))) form))) ;The same thing, using the :order and :required keyword options (define-method-combination or (&optional (order ':most-specific-first)) ((around (:around)) (primary (or) :order order :required t)) (let ((form (if (rest primary) `(or ,@(mapcar #'(lambda (method) `(call-method ,method ())) primary)) `(call-method ,(first primary) ())))) (if around `(call-method ,(first around) (,@(rest around) (make-method ,form))) form))) ;This short-form call is behaviorally identical to the preceding (define-method-combination or :identity-with-one-argument t) ;Order methods by positive integer qualifiers ;:around methods are disallowed to keep the example small (define-method-combination example-method-combination () ((methods positive-integer-qualifier-p)) `(progn ,@(mapcar #'(lambda (method) `(call-method ,method ())) (stable-sort methods #'< :key #'(lambda (method) (first (method-qualifiers method))))))) (defun positive-integer-qualifier-p (method-qualifiers) (and (= (length method-qualifiers) 1) (typep (first method-qualifiers) '(integer 0 *)))) ;;; Example of the use of :arguments (define-method-combination progn-with-lock () ((methods ())) (:arguments object) `(unwind-protect (progn (lock (object-lock ,object)) ,@(mapcar #'(lambda (method) `(call-method ,method ())) methods)) (unlock (object-lock ,object)))) \endscreen! 2-36: In the See Also field, remove make-method-call, add call-method and make-method. 2-58 through 2-59: Delete the writeup for make-method-call. Replace it with the following two writeups: \begincom{call-method}\ftype{Macro} \label Purpose: The macro {\bf call-method} is used in method combination. It has lexical scope and is only available within an effective method Lisp form. It hides the implementation-dependent details of how methods are called. Programmers always translate a method object into a Lisp form that invokes the method by constructing a form that invokes the {\bf call-method} macro with the method object as its first subform and a list of next-method objects as its second subform. The {\bf call-next-method} function available to the method that is the first subform will call the first method in the list that is the second subform. The {\bf call-next-method} function available in that method, in turn, will call the second method in the list that is the second subform, and so on until the list of next-methods is exhausted. In place of a method object, as the first subform of {\bf call-method} or as an element of the second subform of {\bf call-method}, a list can be used that is an invocation of the {\bf make-method} macro. \label Syntax: \Defun {call-method} {method next-method-list} \label See Also: {\bf call-next-method} {\bf define-method-combination} {\bf make-method} \endcom \begincom{make-method}\ftype{Macro} \label Purpose: The macro {\bf make-method} is used in method combination. It has lexical scope and is only available within an effective method Lisp form. An invocation of {\bf make-method} can only be used inside of an invocation of {\bf call-method}. Programmers translate a Lisp form into a method object whose body is that form with the {\bf make-method} macro. This is primarily used when the next-method for {\bf call-next-method} is defined by a form that calls several methods, rather than being a single method object. \label Syntax: \Defun {make-method} {form} \label See Also: {\bf call-method} {\bf call-next-method} {\bf define-method-combination} \endcom  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 27 Jan 88 20:50:42 EST Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 27 Jan 88 17:46:48 PST Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 330071; Wed 27-Jan-88 20:46:45 EST Date: Wed, 27 Jan 88 20:46 EST From: David A. Moon Subject: Re: Method Combination Objects To: kempf%hplabsz@hplabs.HP.COM cc: common-lisp-object-system@SAIL.STANFORD.EDU In-Reply-To: <866.570319039@hplabsz> Message-ID: <19880128014644.1.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Wed, 27 Jan 88 13:57:19 PST From: kempf%hplabsz@hplabs.HP.COM > Append to the paragraph: > "A method combination instance is a meta-object that encapsulates > the method combination type and options specified by the ^^^^ > {\bf :method-combination} option to forms that specify generic > function options." I don't think you mean "type" in the sense of Common Lisp type here, do you? Isn't "role" the correct technical term? I mean "type", but not in the sense of Common Lisp type. "Type" is the word other parts of the document use, e.g. 1-5 last paragraph, 1-36 heading near bottom of page, 2-28 fourth bullet. I'm not enamored of the term, since it's easy to confuse with the formal notion of type, but it's the term that the document uses. Role is certainly not the correct term; at least, the way we've been using it, it is an attribute of a method that is defined by a method-combination [type]; it's not a synonym for a method-combination [type]. > (describe-method-concisely generic-function method method-combination) Why is this any different from DESCRIBE? Presumably, a DESCRIBE method could give the same information for a method object. DESCRIBE would talk all about the method object at length, whereas describe-method-concisely prints just one or two words that crisply identify this method's role. In fact, do you think describe-method-role-concisely would be a better name?  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 27 Jan 88 17:03:31 EST Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 27 Jan 88 13:58:47 PST Received: from hplabs.HP.COM by SCORE.STANFORD.EDU with TCP; Wed 27 Jan 88 13:53:07-PST Received: from hplms2.HP.COM (hplms2) by hplabs.HP.COM with SMTP ; Wed, 27 Jan 88 13:55:36 PST Received: from hplabsz.hpl.hp.com (hplabsz.hpl.hp.com) by hplms2.HP.COM; Wed, 27 Jan 88 13:55:16 pst Received: from hplabsz by hplabsz; Wed, 27 Jan 88 13:57:23 pst To: "David A. Moon" Cc: common-lisp-object-system@sail.stanford.edu Subject: Re: Method Combination Objects In-Reply-To: Your message of Wed, 27 Jan 88 12:34:00 -0500. <19880127173423.8.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Wed, 27 Jan 88 13:57:19 PST Message-Id: <866.570319039@hplabsz> From: kempf%hplabsz@hplabs.HP.COM > Append to the paragraph: > "A method combination instance is a meta-object that encapsulates > the method combination type and options specified by the ^^^^ > {\bf :method-combination} option to forms that specify generic > function options." I don't think you mean "type" in the sense of Common Lisp type here, do you? Isn't "role" the correct technical term? > (describe-method-concisely generic-function method method-combination) Why is this any different from DESCRIBE? Presumably, a DESCRIBE method could give the same information for a method object. jak  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 27 Jan 88 16:28:44 EST Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 27 Jan 88 13:25:28 PST Received: from hplabs.HP.COM by SCORE.STANFORD.EDU with TCP; Wed 27 Jan 88 13:20:41-PST Received: from hplms2.HP.COM (hplms2) by hplabs.HP.COM with SMTP ; Wed, 27 Jan 88 13:23:34 PST Received: from hplabsz.hpl.hp.com (hplabsz.hpl.hp.com) by hplms2.HP.COM; Wed, 27 Jan 88 13:23:08 pst Received: from hplabsz by hplabsz; Wed, 27 Jan 88 13:25:15 pst To: Jon L White Cc: common-lisp-object-system@sail.stanford.edu Subject: Re: Type-checking of slot values In-Reply-To: Your message of Wed, 27 Jan 88 03:00:04 -0800. <8801271100.AA25486@bhopal.lucid.com> Date: Wed, 27 Jan 88 13:25:12 PST Message-Id: <352.570317112@hplabsz> From: kempf%hplabsz@hplabs.HP.COM > My preference as stated before is to > prohibit a rule *requiring* checking of slot values, except that under the > extremal safety settings such checking *may* be required. Note that this > phrasing grants permission for an implementation to do type-checking at all > safety levels, if it so chooses. This sounds consistent with CLtL policy on declarations to me. > Incidentally, I would propose a benchmark of using defclass for defstruct, > and see if there is *any* mode where the user suffers no slowdown [:type > specifiers aren't the only hinderence to success here!]. Conversely, there > should be a test case that asks whether there is *any* mode where all slot > :type specifiers are always satisfied. Well, since the change class protocol requires that an implementation be able to modify the structure of an object while maintaining EQ identity, there are implementations which could impose an extra level of indirection into slot lookup. Alternatively, a class could keep track of all its instances, but garbage collection becomes complicated. I had, at one time, proposed a set of primitives to freeze the class structure about a certain class, but there appeared to be little or no interest in this idea, and it somehow got dropped. This would allow an instance implementation with one level of indirection, but attempts to change the class would signal an error. Alternatively, one could modify DEFCONSTANT to allow declaration of constant structure as well as constant binding. As a general tool, this obviously would be very difficult to implement, but for things like classes and functions, which are named but for which the name/object binding does not go through the symbol value cell, enforcing it would be straightforward. Of course, with real forwarding pointers, the amount of overhead in slot lookup becomes much less, since the virtual memory system is helping you. jak  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 27 Jan 88 16:06:03 EST Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 27 Jan 88 13:01:47 PST Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 329731; Wed 27-Jan-88 16:02:00 EST Date: Wed, 27 Jan 88 16:01 EST From: David A. Moon Subject: Method Combination Objects To: Common-Lisp-Object-System@SAIL.STANFORD.EDU In-Reply-To: <880127111739.7.GREGOR@SPIFF.parc.xerox.com> Message-ID: <19880127210152.5.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Wed, 27 Jan 88 11:17 PST From: Gregor.pa@Xerox.COM Basically, I agree with all your suggestions. Details below. Dick and/or Linda: if you want me to send out a revised version of what I just sent out, with Gregor's suggestions incorporated, please let me know. Otherwise I'll assume that you'll do the merging. First off, I really don't like the name method-combination-instance. I think it should be method-combination-object. I agree. This doesn't affect chapter 1 or 2. I would prefer the order of arguments: [for compute-effective-method] ( ) I agree. This affects chapter 1. Since method-combination-instance (method-combination-object) must be called before ensure-generic-function is called, its first argument is actually a prototype of the generic function. On 13 January, Danny said [method-combination-instance] allows specialization on the class of the generic function as well as on the name. Although useful, this might not be important because compute-effective-method also allows specialization on both the generic function and method combination object. Given this, and what you just pointed out, I think it was a mistake to make the generic function an argument here. Thus I think the arguments should be (method-combination-object name options) => object. This doesn't affect chapter 1 or 2. Also, are you proposing that once a generic function has a method combination object it is not possible to extract that object from it? What exactly happens with the :method-combination argument to ensure generic function? It seems to me that argument should be stored away `inside' the generic function and that it should be possible to extract it and modify it. This would mean that there would be an accessor for generic function called something like generic-function-method-combination-object. It would also mean that method-combination-object should return a new object each time and that perhaps it should be called make-method-combination-object. I agree with all this. I said somewhere in my message that the existing chapter 3 accessors for generic function objects need to be adjusted, but I didn't try to give any details since I don't have access to the current version of chapter 3. Anything that returns the method combination name or options, given a generic function, should be removed, and something that returns the method combination object, given a generic function, should be added. This doesn't affect chapter 1 or 2.  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 27 Jan 88 14:33:22 EST Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 27 Jan 88 11:23:45 PST Received: from Semillon.ms by ArpaGateway.ms ; 27 JAN 88 11:19:26 PST Date: Wed, 27 Jan 88 11:17 PST From: Gregor.pa@Xerox.COM Subject: Method Combination Objects To: David A. Moon cc: Common-Lisp-Object-System@SAIL.STANFORD.EDU Fcc: BD:>Gregor>mail>outgoing-mail-1.text In-Reply-To: <19880127173423.8.MOON@EUPHRATES.SCRC.Symbolics.COM> Message-ID: <880127111739.7.GREGOR@SPIFF.parc.xerox.com> Line-fold: no Date: Wed, 27 Jan 88 12:34 EST From: David A. Moon There haven't been any dissenting comments, as I assume the design for method combination meta objects agreed on by Danny and me is accepted by everyone else. I have just a few problems with this. I have included only the parts of your message I have problems with, all the other parts are just fine. First off, I really don't like the name method-combination-instance. I think it should be method-combination-object. I think the sentence "A method combination instance is a meta object which..." shows why this name is better. We call methods "method objects" and classes "class objects" etc. First, the impact on chapters 1 and 2. Page numbers refer to the 20 Jan 1988 drafts. 1-33 last paragraph (excluding the implementation note), second sentence. Replace this sentence with: "The generic function {\bf compute-effective-method} receives as arguments the generic function, the sorted list of applicable methods, and the method combination instance." I would prefer the order of arguments: ( ) When its clear that only some arguments are intended to be specialized, I like putting them up from. Also, those two arguments are the ones that are going to consiper to work on the third so I like that order of arguments for that reason too. 2-43 ensure-generic-function arguments: Nothing really needs to be changed, since the value of the :method-combination argument is not described at all in the latest draft. However, I suggest two sentences should be added: "The {\bf :method-combination} argument is a method combination instance. A method combination instance is a meta-object that encapsulates the method combination type and options specified by the {\bf :method-combination} option to forms that specify generic function options." Method Combination Naming Layer This layer is concerned with mapping method combination names and options, as seen in the :method-combination option to defgeneric, to method combination meta-objects. (method-combination-instance generic-function method-combination-name method-combination-options) => method-combination is how a method combination name and a list of options are converted into an object. define-method-combination expands into a defmethod for method-combination-instance. remove-method can be used to undefine a method combination type. method-combination-instance signals an error if method-combination-name is unrecognized. Each method for method-combination-instance signals an error if the method-combination-options are unrecognized or there are too many or too few of them. method-combination-instance might return the same object each time it is called with given arguments, or it might make a new object. (method-combination-name method-combination) => symbol (method-combination-options method-combination) => list Since method-combination-instance (method-combination-object) must be called before ensure-generic-function is called, its first argument is actually a prototype of the generic function. Also, are you proposing that once a generic function has a method combination object it is not possible to extract that object from it? What exactly happens with the :method-combination argument to ensure generic function? It seems to me that argument should be stored away `inside' the generic function and that it should be possible to extract it and modify it. This would mean that there would be an accessor for generic function called something like generic-function-method-combination-object. It would also mean that method-combination-object should return a new object each time and that perhaps it should be called make-method-combination-object. -------  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 27 Jan 88 12:39:45 EST Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 27 Jan 88 09:34:07 PST Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 329494; Wed 27-Jan-88 12:34:17 EST Date: Wed, 27 Jan 88 12:34 EST From: David A. Moon Subject: Method Combination Objects To: Common-Lisp-Object-System@SAIL.STANFORD.EDU References: <19871229222722.4.MOON@EUPHRATES.SCRC.Symbolics.COM>, <880113-103639-2495@Xerox>, <19880115035749.6.MOON@EUPHRATES.SCRC.Symbolics.COM>, <880115-135338-5966@Xerox> Message-ID: <19880127173423.8.MOON@EUPHRATES.SCRC.Symbolics.COM> There haven't been any dissenting comments, as I assume the design for method combination meta objects agreed on by Danny and me is accepted by everyone else. First, the impact on chapters 1 and 2. Page numbers refer to the 20 Jan 1988 drafts. 1-33 last paragraph (excluding the implementation note), second sentence. Replace this sentence with: "The generic function {\bf compute-effective-method} receives as arguments the generic function, the sorted list of applicable methods, and the method combination instance." Append to the paragraph: "A method combination instance is a meta-object that encapsulates the method combination type and options specified by the {\bf :method-combination} option to forms that specify generic function options." 1-40: This is optional, but I think we should add method combination instances to the list of meta-objects. Each method combination instance is an instance of a subclass of the class {\bf method-combination}. I don't think we need to name any of the subclasses here, not even {\bf standard-method-combination}; that's chapter 3 material for now. 2-42 documentation method signatures: Add two for method-combination (italic) method-combination (bold), for documentation and for setf of documentation. On the next page, under arguments, the first bullet should mention method combination objects too. 2-43 ensure-generic-function arguments: Nothing really needs to be changed, since the value of the :method-combination argument is not described at all in the latest draft. However, I suggest two sentences should be added: "The {\bf :method-combination} argument is a method combination instance. A method combination instance is a meta-object that encapsulates the method combination type and options specified by the {\bf :method-combination} option to forms that specify generic function options." That's all that has to be changed in chapters 1 and 2. Here's an approximation of what goes into chapter 3. I have done no editing for style here, only content. I've left out the design rationale this time, to keep this small. Consult the referenced messages if you want to see it again. Method Combination Naming Layer This layer is concerned with mapping method combination names and options, as seen in the :method-combination option to defgeneric, to method combination meta-objects. (method-combination-instance generic-function method-combination-name method-combination-options) => method-combination is how a method combination name and a list of options are converted into an object. define-method-combination expands into a defmethod for method-combination-instance. remove-method can be used to undefine a method combination type. method-combination-instance signals an error if method-combination-name is unrecognized. Each method for method-combination-instance signals an error if the method-combination-options are unrecognized or there are too many or too few of them. method-combination-instance might return the same object each time it is called with given arguments, or it might make a new object. (method-combination-name method-combination) => symbol (method-combination-options method-combination) => list These two generic functions perform the inverse mapping. Method Combination Object Layer method-combination This class is a superclass of all classes of method combination. standard-method-combination This class is the class of the method combination object used by default when :method-combination is not specified. Other implementation-dependent subclasses of method-combination exist. For example, all invocations of the short form of define-method-combination probably use one class, and each invocation of the long form of define-method-combination probably defines a new class which has a superclass in common with standard-method-combination. CLOS does not specify how many of these classes there are nor what their names are. (compute-effective-method generic-function method-list method-combination) => effective-method-form This generic function performs part 3 of the determination of the effective method. define-method-combination works through methods that specialize the third parameter. (describe-method-concisely generic-function method method-combination) This generic function prints a description of the method onto *standard-output*. The value returned is ignored. define-method-combination defines a method for describe-method-concisely that uses the :description option of the long form to control what it prints. Other generic functions specialized by method combinations are not currently defined by CLOS, but program development environments are likely to have some. A generic function object records a method combination object, rather than the name and options of a method combination type. This changes the initialization arguments and structural access functions for generic functions from what is in chapter 3 now. defgeneric calls method-combination-instance before it calls ensure-generic-function. Example The short form of define-method-combination could have been defined as follows: (defclass short-form-method-combination (method-combination) ((name :initarg name :reader method-combination-name) (order :initarg order) (documentation :initarg documentation :reader documentation) (operator :initarg operator) (identity-with-one-argument :initarg identity-with-one-argument))) (defmethod method-combination-options ((mc short-form-method-combination)) (list (slot-value mc 'order))) (defmethod compute-effective-method (generic-function methods (mc short-form-method-combination)) (let ((primary-methods (remove (list (slot-value mc 'name)) methods :key #'method-qualifiers :test-not #'equal)) (around-methods (remove '(:around) methods :key #'method-qualifiers :test-not #'equal))) (when (eq (slot-value mc 'order) ':most-specific-last) (setq primary-methods (reverse primary-methods))) (dolist (method (set-difference methods (union primary-methods around-methods))) (invalid-method-error method "The qualifiers of ~S, ~:S, are not ~S or ~S" method (method-qualifiers method) (list (slot-value mc 'name)) '(:around))) ;;--- Note: this example has not been updated to reflect the removal ;;--- of make-method-call. If we do that, the update should be ;;--- straightforward. (make-method-call `(,@around-methods ,(make-method-call primary-methods :operator (slot-value mc 'operator) :identity-with-one-argument (slot-value mc 'identity-with-one-argument))) :operator :call-next-method))) (defmethod describe-method-concisely (generic-function method (method-combination short-form-method-combination)) (declare (ignore generic-function)) (write-string (string-downcase (string (first (method-qualifiers method)))))) (defmacro define-method-combination (name &key (documentation nil) (operator name) (identity-with-one-argument nil)) `(defmethod method-combination-instance (generic-function (name (eql ',name)) options) (declare (ignore generic-function)) (apply #'(lambda (&optional (order ':most-specific-first)) (check-type order (member :most-specific-first :most-specific-last)) (make-instance 'short-form-method-combination 'name ',name 'order order 'documentation ',documentation 'operator ',operator 'identity-with-one-argument ',identity-with-one-argument)) options))) Example of Defining a Method Combination Type via Inheritance ;This example defines a method combination type that is similar ;to standard method combination, except that it also allows :or ;methods. The :or methods are executed after the :before methods, ;before the :after methods, inside the :around methods, and before ;the primary method. The primary method is only called if all the ;:or methods return nil; if any :or method returns non-nil, its ;value becomes the value of the generic function (or the value ;returned by call-next-method in the least specific :around method) ;in place of the values of the most specific primary method. ;This assumes approach 2 or 3 to making effective method code ;analyzable, and assumes one particular code analysis tool, whose ;details I will not try to explain here. ;Those assumptions are not critical. ;I'm assuming we don't want to try to extend the define-method-combination ;macro so that it could exploit inheritance. Instead I will ;define the example directly in terms of the next layer down. (defclass standard-method-combination-with-or (standard-method-combination) ()) (defmethod method-combination-instance (generic-function (name (eql 'standard-with-or)) options) (declare (ignore generic-function)) (unless (null options) (error "standard-with-or method combination does not accept options")) (make-instance 'standard-method-combination-with-or)) ;This uses call-next-method to get the effective method in the absence ;of any :or methods, then it modifies the effective method form to ;incorporate the :or methods in an OR special form wrapped around the ;call to the most specific primary method. (defmethod compute-effective-method (generic-function methods (mc standard-method-combination-with-or)) (let ((or-methods (remove '(:or) methods :key #'method-qualifiers :test-not #'equal)) (other-methods (remove '(:or) methods :key #'method-qualifiers :test #'equal))) (lt:copyforms #'(lambda (subform kind usage) (declare (ignore usage)) (if (and (listp kind) (listp subform) (eq (first subform) 'method-call) (null (method-qualifiers (second subform)))) ;; Put or methods before primary method (values `(or ,@(mapcar #'(lambda (method) `(method-call ,method)) or-methods) ,subform) t) ;; Leave all other subforms of effective method alone subform)) (call-next-method generic-function other-methods mc))))  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 27 Jan 88 06:21:27 EST Received: from labrea.Stanford.EDU by SAIL.Stanford.EDU with TCP; 27 Jan 88 03:18:03 PST Received: by labrea.Stanford.EDU; Wed, 27 Jan 88 03:18:16 PST Received: from bhopal.lucid.com by edsel id AA18439g; Wed, 27 Jan 88 02:56:18 PST Received: by bhopal id AA25486g; Wed, 27 Jan 88 03:00:04 PST Date: Wed, 27 Jan 88 03:00:04 PST From: Jon L White Message-Id: <8801271100.AA25486@bhopal.lucid.com> To: labrea!Bobrow.pa%Xerox.COM@labrea.Stanford.EDU Cc: labrea!Common-Lisp-Object-System%SAIL.STANFORD.EDU@labrea.Stanford.EDU In-Reply-To: Danny Bobrow's message of 26 Jan 88 18:48 PST <880126-184910-2818@Xerox> Subject: Type-checking of slot values re: Would it be better to say: (2) "An implementation is allowed to check the type of the value being stored in a slot only under the safest compiler safety setting and in the interpreter." This would stop it from being checked at other times. What is the intent? This may be the interpretation that Moon et al are objecting to; and I wouldn't approve of it either. I certainly read the offending sentence of CLOS 1-13 " is required only when " as if it were " is required at most when , and nothing is said about the case of when not ." The intent of that paragraph is only to say that a slot value is permitted to violate its corresponding :type specifier. With respect to type-checking the slot values, there is clearer language elsewhere in the CLOS documents; and it isn't nearly so ambiguous as CLtL's universal excuse "it is an error". My preference as stated before is to prohibit a rule *requiring* checking of slot values, except that under the extremal safety settings such checking *may* be required. Note that this phrasing grants permission for an implementation to do type-checking at all safety levels, if it so chooses. Incidentally, I would propose a benchmark of using defclass for defstruct, and see if there is *any* mode where the user suffers no slowdown [:type specifiers aren't the only hinderence to success here!]. Conversely, there should be a test case that asks whether there is *any* mode where all slot :type specifiers are always satisfied. Linda thinks Dick put in the wording that Dave proposes to change; maybe we should give him a chance to explain his intent. -- JonL --  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 26 Jan 88 21:50:55 EST Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 26 Jan 88 18:48:41 PST Received: from Cabernet.ms by ArpaGateway.ms ; 26 JAN 88 18:49:10 PST Date: 26 Jan 88 18:48 PST Sender: Bobrow.pa@Xerox.COM From: Danny Bobrow Subject: Re: Type-checking of slot values In-reply-to: Jon L White 's message of Tue, 26 Jan 88 17:52:51 PST To: edsel!jonl@labrea.Stanford.EDU cc: Common-Lisp-Object-System@SAIL.STANFORD.EDU Message-ID: <880126-184910-2818@Xerox> FROM JONL " The two sentences you are comparing here aren't really that different: (1) "An implementation may or may not choose to check the type of the new value when initializing or assigning to a slot" (2) "An implementation is required to check the type of the value being stored in a slot only under the safest compiler safety setting and in the interpreter." If I read (2), a type check is required when the SAFETY compiler switch is set to 3. No such thing is said in (1). Not as I read it! The phrase " is required only when " is definitely not equivalent to the phrase " is required whenever ". Could this variant reading of "only when" be the source of all our disagreement?" I certainly misread it that way. If it said An implementation is required to check the type of the value being stored in a slot at most when under the safest compiler safety setting and in the interpreter." Then it would be saying the same thing. But why should one use the word require if the intent is to not require, but allow under certain safetey conditions. Would it be better to say: (2) "An implementation is allowed to check the type of the value being stored in a slot only under the safest compiler safety setting and in the interpreter." This would stop it from being checked at other times. What is the intent?  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 26 Jan 88 21:12:41 EST Received: from labrea.Stanford.EDU by SAIL.Stanford.EDU with TCP; 26 Jan 88 18:08:58 PST Received: by labrea.Stanford.EDU; Tue, 26 Jan 88 18:09:09 PST Received: from bhopal.lucid.com by edsel id AA15378g; Tue, 26 Jan 88 17:49:07 PST Received: by bhopal id AA23379g; Tue, 26 Jan 88 17:52:51 PST Date: Tue, 26 Jan 88 17:52:51 PST From: Jon L White Message-Id: <8801270152.AA23379@bhopal.lucid.com> To: labrea!Moon%STONY-BROOK.SCRC.Symbolics.COM@labrea.Stanford.EDU, labrea!DUSSUD%jenner.csc.ti.com@labrea.Stanford.EDU Cc: labrea!Common-Lisp-Object-System%SAIL.STANFORD.EDU@labrea.Stanford.EDU In-Reply-To: David A. Moon's message of Tue, 26 Jan 88 11:31 EST <19880126163134.3.MOON@EUPHRATES.SCRC.Symbolics.COM> Subject: Type-checking of slot values Date: Tue, 26 Jan 88 11:31 EST From: David A. Moon Date: Tue, 26 Jan 88 01:28:37 PST From: Jon L White The two sentences you are comparing here aren't really that different: (1) "An implementation may or may not choose to check the type of the new value when initializing or assigning to a slot" (2) "An implementation is required to check the type of the value being stored in a slot only under the safest compiler safety setting and in the interpreter." As I read these two, they require absolutely nothing in the way of error checking. If you read CLOS pages 1-6 and 2-23, that is clearly not the case. The second one requires every implementation to signal an error in certain circumstances. Just what is it that you think is "clearly not the case"? The two alternative specifications above were under discussion -- not error checking in general -- and nothing I've seen so far changes the meaning of either of those two sentences. In fact, CLOS pages 1-6 and 2-23 support exactly the summary I proposed, but which you omitted from your excerpt of my message: ". . . to constrain future requirements; that is, the requirement for type checking will never be more strict than requireing it at the most strict compiler safety settings." See also my comments below on Patrick's confusion betewen "if" and "only-if". ...nor does it even imply that an implementation has to provide "compiler safety settings". CLtL page 160. Sorry, that page doesn't say that *any* declaration at all has to affect the compiler's behaviour. [I suppose we could keep this discussion up if someone wants to imagine yet more unspoken meanings for "provide", but I'll gracely bow out now]. I'd rather not get into a discussion on this mailing list of whether Lisp should or should not be changed into a strongly-typed language. That belongs on some other list. No one has ever suggested changeing Lisp into a strongly-typed language. We can cut this discussion short by eliminating the bogeymen. Date: Tue, 26 Jan 88 08:45:39 CST From: Patrick H Dussud Date: Tue, 26 Jan 88 01:28:37 PST From: Jon L White Subject: Type-checking of slot values The two sentences you are comparing here aren't really that different: (1) "An implementation may or may not choose to check the type of the new value when initializing or assigning to a slot" (2) "An implementation is required to check the type of the value being stored in a slot only under the safest compiler safety setting and in the interpreter." If I read (2), a type check is required when the SAFETY compiler switch is set to 3. No such thing is said in (1). Not as I read it! The phrase " is required only when " is definitely not equivalent to the phrase " is required whenever ". Could this variant reading of "only when" be the source of all our disagreement? I don't think that the type checking has anything to do with good performance. The important thing for good performance is that . . . Patrick. Unfortunately, "type checking" does have something to do with performance, if you take the view of the structured programming folks. That view says that *no* data access is permitted unless it is proven correct; it doesn't forbid runtime checks, but it biases towards compile time checks. These folks are particularly aghast at languages like C where you have virtually no compile time type checking, and none at all a runtime. The phrase "type checking" is a slogan that often differentiates these two camps. There *appears* to be a runtime cost for runtime type checking, and this is not just a Lisp issue [however, few special-purose machines for languages like functional-programming ML, or for super-strongly-typed languages like Mesa, seem to have been commercial successes]. CLtL permits implementations to range anywhere between the extremes of "No access until proven correct" and "Anything goes". Caveat Luser. It would be inconsistent with this CL philosophy for CLOS to insert a bias, or requirement, for the former more "costly" approach. -- JonL -- P.S. Since Moon failed to resist carping about the SPARC, I'll fail to resist making the following challenge: "SPARC does not have a Common Lisp + instruction, nor does it have any special-purpose hardware for Lisp. Neither does the 'other' RISC chip that nobody knows about. I'll debate this issue anytime, anyplace." [but hopefully, not here in the mails of CLOS].  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 26 Jan 88 17:42:16 EST Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 26 Jan 88 14:38:25 PST Received: from hplabs.HP.COM by SCORE.STANFORD.EDU with TCP; Tue 26 Jan 88 14:08:17-PST Received: from hplms2.HP.COM (hplms2) by hplabs.HP.COM with SMTP ; Tue, 26 Jan 88 14:10:45 PST Received: from hplabsz.hpl.hp.com (hplabsz.hpl.hp.com) by hplms2.HP.COM; Tue, 26 Jan 88 14:10:19 pst Received: from hplabsz by hplabsz; Tue, 26 Jan 88 14:12:27 pst To: "David A. Moon" Cc: common-lisp-object-system@sail.stanford.edu Subject: Re: Type-checking of slot values In-Reply-To: Your message of Tue, 26 Jan 88 16:44:00 -0500. <19880126214430.9.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Tue, 26 Jan 88 14:12:23 PST Message-Id: <15831.570233543@hplabsz> From: kempf%hplabsz@hplabs.HP.COM > > I don't think that the type checking has anything to do with good > > performance. The important thing for good performance is that an > > implementation an optimize slot access based on :type information. I > > don't want to take that away from CLOS, or CLtL. > Sorry, but I think you're wrong. On stock hardware, FIXNUM + is one > instruction, and a compiler which can deduce when to use it will always > win over one that can't. > What does this have to do with a requirement that a particular construct > shall signal an error in a particular circumstance? Nothing, which is probably as good a reason as any to terminate the discussion. > I think you two are using the phrase "type checking" to mean two different > things. Right: 1) to check for errors 2) to help optimize performance. The current Common Lisp declaration framework can do 2), though the compiler may have to be smarter in some cases (which could be simpilified by adding some declarations). Since the Common Lisp specification makes declarations optional, however, the results of declaring things may be nonportable. I presume by "should CL become statically typed" is meant 1), to which my feeling is no, but this is not the right place to discuss it. > Note how I resist the urge to point out that a certain vendor's > processor, which said vendor claims is the only stock hardware anyone > would ever want to use, and has in fact succeeded in convincing several > other corporations of the merits of that idea, has a Common Lisp + > instruction. I'll refrain from asking specifics [ :-) ], but I don't oppose the idea of having instructions for high use operations like Common Lisp +. I think the language design should make it possible to implement with relative efficiency (at perhaps larger compilation cost) even on architectures which are less enlightened, however. jak  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 26 Jan 88 16:46:43 EST Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 26 Jan 88 13:44:22 PST Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 328911; Tue 26-Jan-88 16:44:31 EST Date: Tue, 26 Jan 88 16:44 EST From: David A. Moon Subject: Re: Type-checking of slot values To: kempf%hplabsz@hplabs.HP.COM cc: Patrick H Dussud , common-lisp-object-system@SAIL.STANFORD.EDU In-Reply-To: <14255.570231023@hplabsz> Message-ID: <19880126214430.9.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Tue, 26 Jan 88 13:30:23 PST From: kempf%hplabsz@hplabs.HP.COM > > If CLOS is defined is such a way that acceptable performance is only > achievable on "special purpose" hardware [e.g., a defclass is far too > slow to be a substitute for defstruct], then I suspect it will be subject > to Deutsch's Dictum: > I don't think that the type checking has anything to do with good > performance. The important thing for good performance is that an > implementation an optimize slot access based on :type information. I > don't want to take that away from CLOS, or CLtL. Sorry, but I think you're wrong. On stock hardware, FIXNUM + is one instruction, and a compiler which can deduce when to use it will always win over one that can't. What does this have to do with a requirement that a particular construct shall signal an error in a particular circumstance? I think you two are using the phrase "type checking" to mean two different things. Note how I resist the urge to point out that a certain vendor's processor, which said vendor claims is the only stock hardware anyone would ever want to use, and has in fact succeeded in convincing several other corporations of the merits of that idea, has a Common Lisp + instruction.  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 26 Jan 88 16:38:36 EST Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 26 Jan 88 13:35:50 PST Received: from hplabs.HP.COM by SCORE.STANFORD.EDU with TCP; Tue 26 Jan 88 13:26:01-PST Received: from hplms2.HP.COM (hplms2) by hplabs.HP.COM with SMTP ; Tue, 26 Jan 88 13:28:43 PST Received: from hplabsz.hpl.hp.com (hplabsz.hpl.hp.com) by hplms2.HP.COM; Tue, 26 Jan 88 13:28:21 pst Received: from hplabsz by hplabsz; Tue, 26 Jan 88 13:30:27 pst To: Patrick H Dussud Cc: common-lisp-object-system@sail.stanford.edu Subject: Re: Type-checking of slot values In-Reply-To: Your message of Tue, 26 Jan 88 08:45:39 -0600. <2779195539-5273381@Jenner> Date: Tue, 26 Jan 88 13:30:23 PST Message-Id: <14255.570231023@hplabsz> From: kempf%hplabsz@hplabs.HP.COM > > If CLOS is defined is such a way that acceptable performance is only > achievable on "special purpose" hardware [e.g., a defclass is far too > slow to be a substitute for defstruct], then I suspect it will be subject > to Deutsch's Dictum: > I don't think that the type checking has anything to do with good > performance. The important thing for good performance is that an > implementation an optimize slot access based on :type information. I > don't want to take that away from CLOS, or CLtL. Sorry, but I think you're wrong. On stock hardware, FIXNUM + is one instruction, and a compiler which can deduce when to use it will always win over one that can't. Similiarly, with CLOS, a compiler which can substitute two memory references for a call to SLOT-VALUE will win, modulo concerns about SAFETY. Type checking is important for performance on stock hardware, unfortunately, Common Lisp is defined such that type checking is completely optional, guaranteeing divergence between what different vendors supply. Whether or not that should be fixed is a different story, and, as has been pointed out, this is not the place to discuss it. jak  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 26 Jan 88 11:51:21 EST Received: from RELAY.CS.NET by SAIL.Stanford.EDU with TCP; 26 Jan 88 08:47:57 PST Received: from relay2.cs.net by RELAY.CS.NET id ac01417; 26 Jan 88 11:22 EST Received: from csc.ti.com by RELAY.CS.NET id ac13544; 26 Jan 88 11:10 EST Received: from Jenner by tilde id AA13180; Tue, 26 Jan 88 08:46:52 CST Message-Id: <2779195539-5273381@Jenner> Date: Tue, 26 Jan 88 08:45:39 CST From: Patrick H Dussud To: "David A. Moon" Cc: Common-Lisp-Object-System@SAIL.STANFORD.EDU Subject: Re: Type-checking of slot values In-Reply-To: Msg of Mon, 25 Jan 88 22:18 EST from "David A. Moon" In-Reply-To: Msg of Tue, 26 Jan 88 01:28:37 PST from Jon L White Date: Mon, 25 Jan 88 22:18 EST From: "David A. Moon" Subject: Type-checking of slot values Reference: pages 1-13 and 2-23 of 20 Jan 88 draft. CLtL p.158, p.310, p.6. Sometime between August and November the definition of the :type slot option was changed from "An implementation may or may not choose to check the type of the new value when initializing or assigning to a slot" to "An implementation is required to check the type of the value being stored in a slot only under the safest compiler safety setting and in the interpreter." I don't think this change was every publically discussed. I don't remember such discussion. It's perfectly legitimate to argue against the current definition of type declarations in Common Lisp. I have no problem with that. However, I don't think it's appropriate for this issue to be decided by CLOS rather than by CL, nor do I think it a good idea for type declarations in CLOS to have different semantics from type declarations in the rest of CL. I feel the definition of CLOS's :type slot-option must be changed back, unless there is an agreed upon change to Common Lisp to accompany it. I agree. Date: Tue, 26 Jan 88 01:28:37 PST From: Jon L White Subject: Type-checking of slot values The two sentences you are comparing here aren't really that different: (1) "An implementation may or may not choose to check the type of the new value when initializing or assigning to a slot" (2) "An implementation is required to check the type of the value being stored in a slot only under the safest compiler safety setting and in the interpreter." As I read these two, they require absolutely nothing in the way of error checking. If I read (2), a type check is required when the SAFETY compiler switch is set to 3. No such thing is said in (1). I vaguely remember this issue being thrashed out on CLOS mailing list just after there was a round of complaints on the general common-lisp mailing list about the loopholes in CLtL's frequent phrase "it is an error". If anything, there seemed to be consensus *not* to leave CLOS so underspecified that any old tune could be played on its fiddle. The alternative of requiring safety checking on every slot initialization or updating is clearly incompatible with the pages of CLtL you cite (p.310, p.158 and p.6), and with the performance goals of a majority of Common Lisp vendors. I believe that (1) is close to what CLtL says (p. 158), agrees with CLtL type declaration semantics, and is quite specific about it. Now, concerning your apology for carping presumably about the phrase "safest compiler safety setting": Perhaps this is my bias that type declarations are only a crutch for crippled machines showing . . . There is a whole world out there that firmly *believes* in structured, strongly-typed programming. The roots of their beliefs have nothing at all to do with machine architectures, crippled or otherwise. Of course, some would say that their philosophy makes better performance *possible* on standard ("stock") hardware, but that really isn't the whole issue. The question for us really is whether or not Common Lisp will acknowledge and accept some of this "strongly typed" technology, and put it to good work in a fruitful way. I don't think that it is up to us [CLOS working group] to decide this. If CLOS is defined is such a way that acceptable performance is only achievable on "special purpose" hardware [e.g., a defclass is far too slow to be a substitute for defstruct], then I suspect it will be subject to Deutsch's Dictum: I don't think that the type checking has anything to do with good performance. The important thing for good performance is that an implementation can optimize slot access based on :type information. I don't want to take that away from CLOS, or CLtL. Patrick.  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 26 Jan 88 11:33:32 EST Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 26 Jan 88 08:32:00 PST Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 328522; Tue 26-Jan-88 11:31:33 EST Date: Tue, 26 Jan 88 11:31 EST From: David A. Moon Subject: Type-checking of slot values To: Jon L White cc: Common-Lisp-Object-System@SAIL.STANFORD.EDU In-Reply-To: <8801260928.AA18453@bhopal.lucid.com> Message-ID: <19880126163134.3.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Tue, 26 Jan 88 01:28:37 PST From: Jon L White The two sentences you are comparing here aren't really that different: (1) "An implementation may or may not choose to check the type of the new value when initializing or assigning to a slot" (2) "An implementation is required to check the type of the value being stored in a slot only under the safest compiler safety setting and in the interpreter." As I read these two, they require absolutely nothing in the way of error checking. If you read CLOS pages 1-6 and 2-23, that is clearly not the case. The second one requires every implementation to signal an error in certain circumstances. ...nor does it even imply that an implementation has to provide "compiler safety settings". CLtL page 160. I'd rather not get into a discussion on this mailing list of whether Lisp should or should not be changed into a strongly-typed language. That belongs on some other list.  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 26 Jan 88 04:38:44 EST Received: from labrea.Stanford.EDU by SAIL.Stanford.EDU with TCP; 26 Jan 88 01:37:33 PST Received: by labrea.Stanford.EDU; Tue, 26 Jan 88 01:37:46 PST Received: from bhopal.lucid.com by edsel id AA11428g; Tue, 26 Jan 88 01:25:03 PST Received: by bhopal id AA18453g; Tue, 26 Jan 88 01:28:37 PST Date: Tue, 26 Jan 88 01:28:37 PST From: Jon L White Message-Id: <8801260928.AA18453@bhopal.lucid.com> To: labrea!Moon%STONY-BROOK.SCRC.Symbolics.COM@labrea.Stanford.EDU Cc: labrea!Common-Lisp-Object-System%SAIL.STANFORD.EDU@labrea.Stanford.EDU In-Reply-To: David A. Moon's message of Mon, 25 Jan 88 22:18 EST <19880126031814.6.MOON@EUPHRATES.SCRC.Symbolics.COM> Subject: Type-checking of slot values The two sentences you are comparing here aren't really that different: (1) "An implementation may or may not choose to check the type of the new value when initializing or assigning to a slot" (2) "An implementation is required to check the type of the value being stored in a slot only under the safest compiler safety setting and in the interpreter." As I read these two, they require absolutely nothing in the way of error checking. The second one seems to be trying to constrain future requirements; that is, the requirement for type checking will never be more strict than requireing it at the most strict compiler safety settings. That certainly doesn't say that an implementation can't do it at other compiler settings, nor does it even imply that an implementation has to provide "compiler safety settings". Further, it doesn't introduce any inconsistency with Common Lisp semantics of variable declarations [because both wordings, at present, require nothing]. I vaguely remember this issue being thrashed out on CLOS mailing list just after there was a round of complaints on the general common-lisp mailing list about the loopholes in CLtL's frequent phrase "it is an error". If anything, there seemed to be consensus *not* to leave CLOS so underspecified that any old tune could be played on its fiddle. The alternative of requiring safety checking on every slot initialization or updating is clearly incompatible with the pages of CLtL you cite (p.310, p.158 and p.6), and with the performance goals of a majority of Common Lisp vendors. [I know Dick had a strong interest in seeing this loophole plugged up; he is out of town now and may not be able to give his views for a few days -- I'm sorry if I've not remembered his "side" of it correctly]. Now, concerning your apology for carping presumably about the phrase "safest compiler safety setting": Perhaps this is my bias that type declarations are only a crutch for crippled machines showing . . . There is a whole world out there that firmly *believes* in structured, strongly-typed programming. The roots of their beliefs have nothing at all to do with machine architectures, crippled or otherwise. Of course, some would say that their philosophy makes better performance *possible* on standard ("stock") hardware, but that really isn't the whole issue. The question for us really is whether or not Common Lisp will acknowledge and accept some of this "strongly typed" technology, and put it to good work in a fruitful way. If CLOS is defined is such a way that acceptable performance is only achievable on "special purpose" hardware [e.g., a defclass is far too slow to be a substitute for defstruct], then I suspect it will be subject to Deutsch's Dictum: "Any computer language that runs on only one manufacturer's hardware is doomed to failure . . . --- unless that manufacturer is IBM." [Quotation of opinion given by L. Peter Deutsch in public forums during 1983 and 1984]. -- JonL --  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 25 Jan 88 22:20:36 EST Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 25 Jan 88 19:17:57 PST Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 328290; Mon 25-Jan-88 22:18:06 EST Date: Mon, 25 Jan 88 22:18 EST From: David A. Moon Subject: Type-checking of slot values To: Common-Lisp-Object-System@SAIL.STANFORD.EDU Message-ID: <19880126031814.6.MOON@EUPHRATES.SCRC.Symbolics.COM> Reference: pages 1-13 and 2-23 of 20 Jan 88 draft. CLtL p.158, p.310, p.6. Sometime between August and November the definition of the :type slot option was changed from "An implementation may or may not choose to check the type of the new value when initializing or assigning to a slot" to "An implementation is required to check the type of the value being stored in a slot only under the safest compiler safety setting and in the interpreter." I don't think this change was every publically discussed. Perhaps this is my bias that type declarations are only a crutch for crippled machines showing, but I don't think this change was appropriate. It is not consistent with CLtL's definition of the :type slot option in defstruct and the type declaration for variables. Violation of these type constraints "is an error." It's perfectly legitimate to argue against the current definition of type declarations in Common Lisp. I have no problem with that. However, I don't think it's appropriate for this issue to be decided by CLOS rather than by CL, nor do I think it a good idea for type declarations in CLOS to have different semantics from type declarations in the rest of CL. I feel the definition of CLOS's :type slot-option must be changed back, unless there is an agreed upon change to Common Lisp to accompany it.  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 25 Jan 88 19:53:15 EST Received: from RELAY.CS.NET by SAIL.Stanford.EDU with TCP; 25 Jan 88 16:48:39 PST Received: from relay2.cs.net by RELAY.CS.NET id ae18896; 25 Jan 88 17:34 EST Received: from csc.ti.com by RELAY.CS.NET id ah07944; 25 Jan 88 17:10 EST Received: from dsg by tilde id AA28636; Mon, 25 Jan 88 15:56:06 CST Received: From Jenner By dsg Via CHAOS-NET With CHAOS-MAIL; Mon, 25 Jan 88 10:39:50 CST Message-Id: <2779115850-485522@Jenner> Date: Mon, 25 Jan 88 10:37:30 CST From: Patrick H Dussud To: Common-Lisp-Object-System@SAIL.STANFORD.EDU Subject: Alternative Proposal for class updating In-Reply-To: Msg of 15 Jan 88 14:17 PST from Bobrow.pa@xerox.com The generic functions used are: Reintialization: reinitialize-instance (object &rest reinit-args) This generic function is intended to initialize again the object. The default method augments the given reinit-args using default-initargs, checks the arguments, and calls initialize-instance. It then updates any dependents I like the concept. I would like it to be more parallel to make-instance though. reinitialize-instance could accept allocate-instance keywords as well. We can imagine cases where we would want to reallocate the instance, i.e update the instance allocation characteristics without affecting the slots. We could re-use the MAKE-INSTANCE model: (defmethod reinitialize-instance ((object standard-object) &rest reinitargs) (setq reinitargs (default-initargs (class-of object) reinitargs)) (check-initargs (class-of object) reinitargs) (apply #'reallocate-instance (class-of object ) reinitargs) (apply #'intialize-instance object reinitargs)) We also have to tell what happens if a slot is unbound. Do we reinitialize it to its initform when there is no reinitargs to reinitialize it? method-keyword-arguments (generic-function list-of-arguments) This generic function provides an facility to help users to write code for checking legality of keyword arguments. Maybe this facility is not necessary for reinitialize-instance? Recording dependencies. add-dependent(object dependent &key) remove-dependent(object dependent &key) all-dependents(object) These three generic functions allow the recording of dependencies. Nothing is specified about what the dependencies are. The real work is done here: update-dependent(object dependent &key) Here again, I like the concept. What bothers me is that update-dependent is not called by make-instance but is called by reinitialize-instance. I wonder if update-dependent shouldn't be called outside of reinitialize-instance. Patrick.  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 25 Jan 88 17:11:02 EST Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 25 Jan 88 13:49:45 PST Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 327422; Sun 24-Jan-88 22:22:19 EST Date: Sun, 24 Jan 88 22:22 EST From: David A. Moon Subject: Comments on latest draft documents To: Common-Lisp-Object-System@SAIL.STANFORD.EDU Message-ID: <19880125032225.6.MOON@EUPHRATES.SCRC.Symbolics.COM> Jan 20, 1988 20:06 draft of chapter 1: 1-15: The first paragraph under "Initializng Newly-added Shared Slots" needs to clarify that if there is no :initform, the shared slot remains unbound. The remaining two paragraphs under that heading belong under the next heading. 1-17: The first bullet under "Extensions" refers to the new class being an instance of the old class, which doesn't make sense. I think it meant to say "the old metaclass." 1-27: The list of method-defining forms should include defclass (because of the :reader, :writer, and :accessor slot-options). 1-28 first non-bullet paragraph: The reference to method defining forms that create generic functions really only applies to those method defining forms that are not also generic function defining forms. Perhaps you need a term for these. They are defmethod and defclass. 1-28 last bullet: In the reference to "The form (eql form)", the first use of the word "form" is incorrect, since this is not technically a form. I'd prefer either "The list (eql form)" or "The parameter specializer name (eql form)". 1-29 paragraph numbered "2": P sub 1,i is a parameter specializer, not a parameter specializer name; in the same sentence, the word "denote" should be "are", for the same reason. 1-30 first line: This incorrectly assumes qualifiers have to be symbols. Elsewhere we have indicated that qualifiers are compared with EQUAL. Thus this line should be changed to "3. The lists of qualifiers of both methods are {\bf equal}." 1-30 after rule 6: The reference to method-defining forms creating generic functions applies only to the ones that are not also generic function defining forms. 1-37: The list of names of built-in method combination types should include STANDARD, or else the text should say this is the list of the m-c types described just above, rather than all of them. Probably the former is better, since the next sentence mentions the semantics of STANDARD m-c. 1-37 last bullet second sentence: "applicable methods" should be "applicable primary methods". 1-40 first bullet: I assume generic functions created by defclass also have class standard-generic-function, so add defclass to this list. 1-43 third paragraph third sentence: Add "and is not defaulted by a more specific class." At most one default initial value form will be evaluated for a given initialization argument, the form supplied by the most specific of the classes that supply them. 1-44 fourth bullet second sentence: I fin the phrase "and the values of the remaining default value forms are ignored" to be misleading. I think it would be better just to delete it. Otherwise the conflict of number (the earlier portion of the sentence indicated just two default value forms were being discussed) and the risk of the reader misinterpreting this to say that the other default value form is not evaluated would have to be dealt with. 1-45 fourth bullet third sentence: "less specific primary method" is a typo for "more specific primary method". Jan 21, 1988 17:39 draft of Chapter 2: 2-17 class-name: The name of a class should not be restricted in type. The method signature should specialize new-value with t, the arguments should say new-value is typically a symbol, and the semicolon clause under values should be deleted. While a class's proper name is a symbol unless symbol-class is somehow extended, class-name should be allowed to be any object. One proposed extension we discussed earlier has class-name a list of classes. 2-18 class-of remarks: If we're going to cross-reference figure 1-1, we have to point out that class-of does not necessarily return the classes listed there. It could return an implementation-dependent subclass. However, we are adding a restriction beyond Common Lisp's TYPE-OF, because for members of the classes in 1-1, it is not permitted for CLASS-OF to return a superclass of the class listed. It might be worth pointing that out explicitly here; to deduce this from what is already documented the reader would need to know that generic function to method dispatching calls CLASS-OF. 2-41 documentation method signatures: The parameter specializer name for new-value should be t, not string. CLtL doesn't say anywhere what values are allowed, but a reasonable inference is that NIL is allowed, and "documentation information" might have been meant to include some sort of structures as well. The allowable types here are a matter for CL to define, not for CLOS to legislate. 2-52 initialize-instance method signature: &key &allow-other-keys can't be right for the method; this would prevent check-initargs from doing anything. It should be &rest initargs. Note that &key &allow-other-keys -is- correct for the generic function (the syntax field). 2-81 with-added-methods remarks: The second paragraph and the two bullets that follow it are slightly garbled. I believe this means to say what happens when with-added-methods does -not- specify an option (the value in the existing generic function is retained, rather than defaulting to the default that efgeneric would use), however it doesn't say that. What it does say doesn't really make sense, because it speaks of option inheritance and then says how the options of the existing generic function are all replaced. That's it for now, but a small number of additional comments will follow, tomorrow.  Received: from Xerox.COM (TCP 1500006350) by AI.AI.MIT.EDU 24 Jan 88 12:59:16 EST Received: from Chardonnay.ms by ArpaGateway.ms ; 24 JAN 88 09:52:20 PST Return-Path: <@MCC.COM:rcp%sw.MCC.COM@MCC.COM> Redistributed: CommonLoops.pa Received: from MCC.COM by Xerox.COM ; 24 JAN 88 09:48:44 PST Received: from milano.SW.MCC.COM by MCC.COM with TCP; Sun 24 Jan 88 11:47:55-CST Received: from perseus by milano.SW.MCC.COM (5.52/STP1.55) id AA05474; Sun, 24 Jan 88 11:48:26 CST Date: Sun, 24 Jan 88 11:47:06 CST From: Rob Pettengill Message-Id: <8801241747.AA14494@perseus> Received: by perseus (3.2/STP) id AA14494; Sun, 24 Jan 88 11:47:06 CST To: Gregor.pa@Xerox.COM Cc: CommonLoops.pa@Xerox.COM Subject: &allow-other-keys and call-next-method bug Keywords defined in inherited methods are not passed to the inherited method when they are not explicitly defined in subclass methods as well. The following example with &allow-other-keys illustrates the problem. Sun Common Lisp 3.0.beta.68 [sun3 with patch level 6] (12/28/87 15:49) Copyright (C) 1985-1987, Franz Inc., Berkeley, CA, USA pcl::*PCL-SYSTEM-DATE* "8/27/87 August 27th, 1987" (defclass foo () ()) # (defmethod test ((self foo) &key (foo t) &allow-other-keys) (print foo)) # (defclass bar (foo) ()) # (defmethod test ((self bar) &key (bar t) &allow-other-keys) (call-next-method) (print bar)) # (setq foo (make-instance 'foo)) # (test foo) T T (setq bar (make-instance 'bar)) # (test bar) T T T (test foo :foo :hello-foo) :HELLO-FOO :HELLO-FOO (test bar :bar :hello-bar) T :HELLO-BAR :HELLO-BAR (test bar :bar :hello-bar :foo :hello-foo) T :HELLO-BAR :HELLO-BAR As you can see we are missing :HELLO-FOO and only seeing the default :foo = T. ;rob Robert C. Pettengill, MCC Software Technology Program P. O. Box 200195, Austin, Texas 78720 ARPA: rcp@mcc.com PHONE: (512) 338-3533 UUCP: {ihnp4,seismo,harvard,gatech,pyramid}!ut-sally!im4u!milano!rcp  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 23 Jan 88 11:12:38 EST Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 23 Jan 88 08:10:49 PST Received: from Cabernet.ms by ArpaGateway.ms ; 23 JAN 88 08:11:20 PST Date: 23 Jan 88 08:10 PST From: Bobrow.pa@Xerox.COM Subject: Re: Class organization for CLOS kernel In-reply-to: mcvax!delphi!chicca@uunet.UU.NET (M.R. Boscotrecase)'s message of Thu, 21 Jan 88 13:00:36 +0100 To: mcvax!delphi!chicca@uunet.UU.NET cc: Bobrow.pa@Xerox.COM, blue!chicca@uunet.UU.NET, common-lisp-object-system@sail.stanford.edu Message-ID: <880123-081120-2731@Xerox> From: mcvax!delphi!chicca@uunet.UU.NET (M.R. Boscotrecase) Date: Thu, 21 Jan 88 13:00:36 +0100 Hello! I work in the DELPHI team that is implementing CLOS on the ObjVlisp model. In our architecture the class structure-class is an instance of the class structure-metaclass and inherits from the class built-in-class. The class structure-metaclass is necessary in order to override the behavior of the class built-in-class (its make-instance method that produce an error message). What we have is the following (defclass structure-metaclass (class) () (:metaclass class)) (defmethod make-instance ((class structure-metaclass) &rest initargs) (...)) (defclass structure-class (built-in-metaclass class t) (slotds conc-name constructors copier predicate include print-function type named initial-offset documentation)) (:metaclass structure-metaclass)) (defmethod initialize-instance ((class structure-class) ..) (..)) In the mail I read that structure-class is instance of standard-class and I think this causes a bootstraping problem. Can you explain me why you want it? There are three disjoint metaclasses which represent the two old ways of having structures in Common Lisp (built-in and structure) and one for the new class structure. These metaclasses themselves are all instances of standard-class. Thus we have (approximately): (defclass built-in-class (class) ()) (defclass structure-class (class) (slotds conc-name constructors copier predicate include print-function type named initial-offset documentation)) (defclass standard-class (class) (direct-slots direct-superclasses direct-class-options)) The class named "class" is a "taxonomic" class that serves to identify the common type of all these We also have two other "taxonomic" classes, standard-object and structure-object, that serve as holders of default methods for instances generated by standard-class and structure-class respectively. It is guaranteed by the system that any instance of any class that is a standard-class has standard-object in its class precedence list. Any class that is an instance of structure-class will have structure-object in its class precedence list. The methods for making instances are: (defmethod make-instance ((class built-in-class) &ret initargs) (error "can't make a builtin class this way")) (defmethod make-instance ((class structure-class) &rest initargs) ;;; do what it takes to make structures ;;; call initialize-instance on the structure) (defmethod make-instance ((class standard-class) &rest initargs) ;;; do what it takes to make standard instances ;;; call initialize-instance on the object) ) (defmethod initialize-instance ((object standard-object) &rest initargs) ...) (defmethod initialize-instance ((object structure-object) &rest initargs) ...) We do not see the need to have an extra level of metaclass like your structure-metaclass. structure-class is not a subclass of built-in-class. If we have (defclass x-y-point ()(x y) (:metaclass structure-class)) then (make-instance 'x-y-point ...) will invoke the method above on structure-class. The class of structure-class will not be involved. ---- The following is the most current version of the CLOS class lattice. Indentation is used to indicate subclass relationships. Class names surround by <..> indicate classes used for type determination. In general, these "taxonomic" classes are abstract classes in the sense that they are not expected to be instantiated. T (built-in-class) standard-generic-function (funcallable-standard-class) standard-method standard-accessor-method standard-reader-method standard-writer-method standard-method-combination simple-method-combination standard-slot-description standard-structure-slot-description built-in-class structure-class forward-referenced-class standard-class funcallable-standard-class A link not shown in the diagram is the subclass link from generic-function to function. We are also still discussing whether standard-accessor-method should be a subclass of standard-method, or only of method.  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 23 Jan 88 10:27:44 EST Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 23 Jan 88 07:25:45 PST Received: from Cabernet.ms by ArpaGateway.ms ; 23 JAN 88 07:26:14 PST Date: 23 Jan 88 07:25 PST Sender: Bobrow.pa@Xerox.COM From: Danny Bobrow Subject: Re: New Class Organization for CLOS Kernel In-reply-to: David A. Moon 's message of Mon, 28 Dec 87 15:51 EST To: Moon@STONY-BROOK.SCRC.Symbolics.COM cc: common-lisp-object-system@SAIL.STANFORD.EDU Message-ID: <880123-072614-2701@Xerox> Date: 23 Dec 87 14:34 PST From: Danny Bobrow The following is my understanding of what we agreed to in Cambridge. Date: Mon, 28 Dec 87 15:51 EST From: David A. Moon Agreed, except for some problems with the class relationships: standard-accessor-method and standard-method should be disjoint for the same reason that standard-class, built-in-class, and structure-class are now disjoint. I agree with the principle stated below. At first I disagreed with the application of the principle to accessor methods based on Gregor's message, but now I see it more as an open question. Here are some issues I see. Can one use an accessor to change (or fetch) the method-function of an accessor? Is the contract of an accessor to be effectively just a call to slot-value? Or can a user insert a random function in an instance of type accessor method. If the issue of method-function is the only difference, then won't a specialized method on method-function and (setf method-function) do the trick. After all, these accessors must combine in all the same ways that ordinary methods do, etc. The principle underlying this is that we need to distinguish between the class that is used by default by the various macros, and the class from which other classes inherit. This allows a programmer defining a new method to choose whether this method is to be applicable to the default kind of object that the macros make or to all objects (of the relevant general kind). For example, standard-class is distinct from structure-class, and they both inherit from class, so that a programmer can put a method on standard-class to affect classes made by defclass, or on class to affect all classes. Probably this principle should be in your list of principles. In thinking about this principle further I realized that we were missing from the class lattice a type that allows us to distinguish objects whose metaclass is structure-class. I propose that we include a class structure-object disjoint from standard-object, that is a guaranteed superclass of all objects whose metaclass is structure-class. It's okay for standard-class-slot-description to be a subclass of standard-slot-description, provided the idea is that standard-class-slot-description is a kludge to avoid putting the :allocation into a slot. I now believe that it would be fine to have :allocation be part of the standard-slot-description class. After our discussion in Cambridge, I think that the value of a class slot is a joint association of the class and the slot, not a property of the class-slot-description object. This allows us to eliminate the class standard-class-slot-description. Missing from the specification is (class-slot-value class class-slot-name) which returns the value associated with the class slot with name . It signals an error if class-slot-name does not specify a class-slot (inherited or direct) at the given class. ((Should this have gone in Chapter 2???)) Forward-referenced-class should be disjoint from standard-class for the same reason, except that forward-referenced-class should not exist at all,in my opinion. In order to have a complete separation of the anonymous and named class parts of the protocol, we need to convert names to classes before they are stored as direct superclasses of a class. One way to avoid having forward-referenced-class would be to use an instance of standard-class that did not have its direct-superclasses or direct-slots specified, such as one created by: (make-instance 'standard-class) Any attempt to use such a class in computing the class precedence list of a subclass (a necessary prerequistite to making instances or defining methods) would result in an error message of the form "Attempt to use a class with no direct-superclasses specified" giving the class name if the class had one. The advantage of using an uninitialized standard-classes for a forward-referenced-class is that we need this protection anyway. A disadvantage is that we would need to provide (if we do not specify direct-superclasses as a slot) a predicate initialized-direct-superclasses-p (class) With instances of forward-referenced-class we could use a type test those classes created by forward reference. Programming environment tools may want special methods on forward-referenced-class for display in browsers etc that would be more difficult to write the other way. If we have forward-referenced-class, I agree it should be disjoint from standard-class. I am undecided which of these alternatives I like better.  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 22 Jan 88 16:04:49 EST Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 22 Jan 88 13:02:28 PST Received: from Semillon.ms by ArpaGateway.ms ; 22 JAN 88 12:56:34 PST Date: Fri, 22 Jan 88 12:55 PST From: Gregor.pa@Xerox.COM Subject: ADD-METHOD To: Dick Gabriel cc: common-lisp-object-system@SAIL.STANFORD.EDU Fcc: BD:>Gregor>mail>outgoing-mail-1.text In-Reply-To: The message of 21 Jan 88 16:46 PST from Dick Gabriel Message-ID: <880122125523.8.GREGOR@SPIFF.parc.xerox.com> Line-fold: no Date: 21 Jan 88 16:46 PST From: Dick Gabriel I was under the impression that only freshly-created method objects could be added to generic functions, and that in order to move an existing method from one generic function to another required a step of MAKE-INSTANCE using the method function. If that's not true, then we ought to leave add-method in chapter 2. I believe that a method can only be on one generic function at a time, but that it is perfectly alright to use add-method to add a method somewhere once you have used remove-method to remove it from where it used to be. -------  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 21 Jan 88 21:46:34 EST Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 21 Jan 88 18:44:28 PST Received: from Cabernet.ms by ArpaGateway.ms ; 21 JAN 88 18:23:19 PST Date: 21 Jan 88 18:23 PST Sender: Bobrow.pa@Xerox.COM From: Danny Bobrow Subject: Re: ADD-METHOD In-reply-to: Dick Gabriel 's message of 21 Jan 88 16:46 PST To: RPG@SAIL.Stanford.EDU cc: common-lisp-object-system@SAIL.Stanford.EDU Message-ID: <880121-182319-1013@Xerox> I was under the impression that only freshly-created method objects could be added to generic functions, and that in order to move an existing method from one generic function to another required a step of MAKE-INSTANCE using the method function. If that's not true, then we ought to leave add-method in chapter 2. There are several other simple documented ways to make methods, and I thought of them all. It happens that all of them except MAKE-INSTANCE install the method objects in generic functions. -rpg- Methods removed from generic-functions are as naked as the day they were born.  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 21 Jan 88 20:53:41 EST Date: 21 Jan 88 1751 PST From: Linda DeMichiel Subject: functi To: common-lisp-object-system@SAIL.Stanford.EDU There is a new functi.tex and functi.dvi on sail. -lgd  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 21 Jan 88 19:48:49 EST Date: 21 Jan 88 1646 PST From: Dick Gabriel Subject: ADD-METHOD To: common-lisp-object-system@SAIL.Stanford.EDU I was under the impression that only freshly-created method objects could be added to generic functions, and that in order to move an existing method from one generic function to another required a step of MAKE-INSTANCE using the method function. If that's not true, then we ought to leave add-method in chapter 2. There are several other simple documented ways to make methods, and I thought of them all. It happens that all of them except MAKE-INSTANCE install the method objects in generic functions. -rpg-  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 21 Jan 88 19:10:40 EST Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 21 Jan 88 16:09:14 PST Received: from Semillon.ms by ArpaGateway.ms ; 21 JAN 88 15:16:46 PST Date: Thu, 21 Jan 88 15:15 PST From: Gregor.pa@Xerox.COM Subject: Remarks To: Dick Gabriel cc: common-lisp-object-system@SAIL.STANFORD.EDU Fcc: BD:>Gregor>mail>outgoing-mail-1.text In-Reply-To: The message of 21 Jan 88 14:28 PST from Dick Gabriel Message-ID: <880121151504.9.GREGOR@SPIFF.parc.xerox.com> Line-fold: no Date: 21 Jan 88 14:28 PST From: Dick Gabriel On ADD-METHOD: Since there are ways of getting methods, and moving methods is a reasonable thing to do, I think it is still reasonable to have add-method in chapter 2. I know one can get methods, but I thought it was not possible to take a method from one generic function and move it to another - that all one could do is grab a method, grab its method function, make up a method object from that, and then put that on a generic function. The step of making the method object is achieved by make-instance of standard-method, which is in chapter 3. Therefore, I believe it belongs in chapter 3. I sort of agree except that there is a simple documented way to create a method. (get-method (generic-function (x) (:method ((x position)) (with-slots (x y) position (incf x) (incf y)))) () (list (class-named 'position))) Given that method, one could use remove-method and add-method to move it around. This example brings up an interesting question. Should CLtL specify a way to compile a method function if it is not already compiled? Sure one could do: (setf (method-function (get-method ..)) (compile ni (method-function (get-method ..)))) but perhaps we should specify that compile with a method object as its first (and only) argument compiles that methods function if it is uncompiled. Compile with a method as its first argument and a lambda as its second would compile and install the lambda? -------  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 21 Jan 88 17:30:24 EST Date: 21 Jan 88 1428 PST From: Dick Gabriel Subject: Remarks To: common-lisp-object-system@SAIL.Stanford.EDU Here are some remarks on the topics discussed recently. By the way, there is a new CONCEP.TEX and CONCEP.DVI on SAIL. These remarks treat the issues in reverse order to how they were sent to the list: I think defgeneric should handle its specially-defined methods in exactly the same way that defclass handles its. I'm not sure what the specially-defined methods might be for a defgeneric. My reading of the specification states that if some method descriptions are supplied some methods are defined, but none of those are specially defined in the manner that they are using defclass - in the defclass case I suppose the specialness is tied up with the fact that they are implicitly defined, though at the behest of the :reader, :writer, or :accessor options. I notice no other methods mentioned. The model currently stated is clear - defgeneric is semantically equivalent to an ensure-generic-function and a series of defmethod's. I see no obvious parallel with defclass. With defclass, the ``specially-defined'' methods are so defined according to a strong convention that we have imposed - we would all be surprised to see people write simple defclass forms and then a series of defmethod's to build up the readers and writers. But the method-defining parts of defgeneric are form completeness only - we do not advocate that people write method definitions within defgeneric forms. If people do not like the fact that re-loading defgeneric forms doesn't do what they want, then they can re-write them as simpler defgeneric's and defmethod's, and they will be obeying classic object-oriented style all the more if they do. So I am against treating these methods in a manner analogous to those defined by defclass. On ADD-METHOD: Since there are ways of getting methods, and moving methods is a reasonable thing to do, I think it is still reasonable to have add-method in chapter 2. I know one can get methods, but I thought it was not possible to take a method from one generic function and move it to another - that all one could do is grab a method, grab its method function, make up a method object from that, and then put that on a generic function. The step of making the method object is achieved by make-instance of standard-method, which is in chapter 3. Therefore, I believe it belongs in chapter 3. Didn't we agree that in the long run, there will only be two chapters - with extensions to chapters 1 and 2. I think we agreed that in the long run this is desireable. We are currently not trying to accomplish this merger, and I think it is reasonable to to alter that to trying to not accomplish the merger. The point of this is to make sure that the X3J13 troops can see what they get and don't get if they think they don't like meta-object stuff. I'm sure that they will desire inclusion of chapter 3, and at that point someone can make the enormous effort to merge them. I think that it would be easier for that person if they have a cleanly separated base level and meta level to start with, especially if that is so easy to accomplish right now. Remember, I want to go to the next meeting with a chapter 1-2 package that stands alone and a chapter 3 package that can be easily added. I think that having such a separation can help our strategy at X3J13, which would be to state that here is chapters 1 and 2 neatly wrapped up as we promised, and all that needs to be really discussed is chapter 3. We can avoid unnecessary yapping by the hangers on that this or that detail in chapter 1-2 is unpalatable, and we can have that important chapter 3 discussion in which we sell it to them.  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 21 Jan 88 14:35:31 EST Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 21 Jan 88 11:32:42 PST Received: from hplabs.HP.COM by SCORE.STANFORD.EDU with TCP; Thu 21 Jan 88 11:28:20-PST Received: from hplms2.HP.COM (hplms2) by hplabs.HP.COM with SMTP ; Thu, 21 Jan 88 11:30:45 PST Received: from hplabsz.hpl.hp.com (hplabsz.hpl.hp.com) by hplms2.HP.COM; Thu, 21 Jan 88 11:30:25 pst Received: from hplabsz by hplabsz; Thu, 21 Jan 88 11:32:29 pst To: common-lisp-object-system@sail.stanford.edu Subject: Re: CALL-NEXT-METHOD and funcall-qua/send-as In-Reply-To: Your message of Tue, 12 Jan 88 22:08:44 -0800. <8801130608.AA15662@bhopal.lucid.com> Date: Thu, 21 Jan 88 11:32:26 PST Message-Id: <6284.569791946@hplabsz> From: kempf%hplabsz@hplabs.HP.COM Sorry it's taken so long to reply. I've been out of town for two weeks. In fact, the original question was one of exactly what the semantics were for CALL-NEXT-METHOD with arguments. This came up when we were modifying the algebraic specification for method combination to include arguments. The precise question was whether the classes of the actual parameters to CALL-NEXT-METHOD could be superclasses of the actual parameters to the calling method (in which case a more general method would be invoked) or whether they had to be exactly the same (in which case only the next most general method would be invoked). The reply which Danny and Dave gave was the latter. This limits CALL-NEXT-METHOD with arguments to being able to supply different actual parameter values to the next most general method, but, as Dave pointed out, simplifies understanding of control flow. I agree with Dave's point that this semantics is the simplist, and thus probably the best. jak  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 21 Jan 88 14:32:09 EST Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 21 Jan 88 11:25:25 PST Received: from hplabs.HP.COM by SCORE.STANFORD.EDU with TCP; Thu 21 Jan 88 11:21:12-PST Received: from hplms2.HP.COM (hplms2) by hplabs.HP.COM with SMTP ; Thu, 21 Jan 88 11:23:34 PST Received: from hplabsz.hpl.hp.com (hplabsz.hpl.hp.com) by hplms2.HP.COM; Thu, 21 Jan 88 11:23:16 pst Received: from hplabsz by hplabsz; Thu, 21 Jan 88 11:25:23 pst To: Gregor.pa@Xerox.COM Cc: common-lisp-object-system@sail.stanford.edu Subject: METHOD-LAMBDA and Removing parsing In-Reply-To: Your message of Fri, 15 Jan 88 13:11:00 -0800. <880115131101.2.GREGOR@SPIFF.parc.xerox.com> Date: Thu, 21 Jan 88 11:25:20 PST Message-Id: <6211.569791520@hplabsz> From: kempf%hplabsz@hplabs.HP.COM I agree that the DEFMETHOD and DEFCLASS parsing stuff should be removed. I'd like to see more on METHOD-LAMBDA and METHOD-APPLY before passing judgement on their suitability, however. jak  Received: from Xerox.COM (TCP 1500006350) by AI.AI.MIT.EDU 21 Jan 88 07:04:48 EST Received: from Concord.ms by ArpaGateway.ms ; 21 JAN 88 03:56:08 PST Return-Path: Redistributed: CommonLoops.PA Received: from uunet.UU.NET by Xerox.COM ; 21 JAN 88 03:52:40 PST Received: from mcvax.UUCP by uunet.UU.NET (5.54/1.14) with UUCP id AA03082; Thu, 21 Jan 88 06:51:57 EST From: mcvax!eiger!mr@uunet.UU.NET Received: by mcvax.cwi.nl; Wed, 20 Jan 88 22:00:33 +0100 (MET) Received: by cernvax.uucp (1.2/Ultrix2.0-B) id AA24035; Wed, 20 Jan 88 20:44:59 +0100 Message-Id: <8801201944.AA24035@cernvax.uucp> Date: 19 Jan 88 16:05 GMT (Tuesday) To: CommonLoops.PA@Xerox.COM Fcc: outbox Subject: PCL for KCL >These notes correspond to *pcl-system-date* 3/19/87 prime. >This release runs in: > ExCL > Lucid > Symbolics Common Lisp (Genera) > Vaxlisp (2.0) > Xerox Common Lisp (Lyric Release) >CMU Lisp (nee Spice) and KCL should be working soon. ... We are trying to get a useable LISP environment on SUN workstations for our students. We've already installed KCL. It would be very helpful to get a version of PCL for it. Did you already manage to get this version finished ? And if so, how can we get hold of the new files ? (The above is our current version of PCL). Thanks for any hints. Marc Raths Integrated Systems Laboratory Phone: +41 1 256 22 11 Swiss Federal Institute for Technology GENERAL: mr@iis.uucp CH-8092 Zurich UUCP: ...!seismo!mcvax!iis!mr SWITZERLAND ARPA: mr%iis.uucp@seismo.css.gov  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 19 Jan 88 18:47:37 EST Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 19 Jan 88 15:46:08 PST Received: from Cabernet.ms by ArpaGateway.ms ; 19 JAN 88 15:43:16 PST Date: 19 Jan 88 15:40 PST Sender: Bobrow.pa@Xerox.COM From: Danny Bobrow Subject: Re: some questions on your chapter 2 comments In-reply-to: David A. Moon 's message of Tue, 19 Jan 88 14:51 EST To: Moon@STONY-BROOK.SCRC.Symbolics.COM cc: Common-Lisp-Object-System@SAIL.STANFORD.EDU Message-ID: <880119-154316-2487@Xerox> I think defgeneric should handle its specially-defined methods in exactly the same way that defclass handles its. I agree. We decided at our last meeting that each class has a slot in which it remembers a list of the defclass-defined methods. I'm not imagining this, am I? I remember that idea winning out over giving each method a slot that says how it was defined or having defclass-defined methods be a special subclass. I don't remember this, but my memory and notes are not to be trusted. Do you remember any of the arguments for this decision. An argument against this is that it implies that remove-method, and add-method that overrides must both be cognizant of (side-effect) this list in this slot.  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 19 Jan 88 16:25:57 EST Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 19 Jan 88 12:49:55 PST Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 323580; Tue 19-Jan-88 14:51:57 EST Date: Tue, 19 Jan 88 14:51 EST From: David A. Moon Subject: Re: some questions on your chapter 2 comments To: Common-Lisp-Object-System@SAIL.STANFORD.EDU In-Reply-To: <880119-093814-1652@Xerox> Message-ID: <19880119195151.1.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: 19 Jan 88 09:37 PST From: Danny Bobrow So how about it? Shall we change CLOS so that re-evaluating a defgeneric removes methods that were previously defined by :method, but no longer appear in the new defgeneric form? I think we should. I think that's a good idea. Should we specify how defgeneric knows that a method was defined by :method. We could use a predicate or we could make :method specified methods be a subclass of defgeneric-method. This similar to how accessors methods are specified, and is what I reecommend. We decided at our last meeting that each class has a slot in which it remembers a list of the defclass-defined methods. I'm not imagining this, am I? I remember that idea winning out over giving each method a slot that says how it was defined or having defclass-defined methods be a special subclass. I think defgeneric should handle its specially-defined methods in exactly the same way that defclass handles its.  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 19 Jan 88 16:19:03 EST Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 19 Jan 88 13:17:37 PST Received: from Cabernet.ms by ArpaGateway.ms ; 19 JAN 88 13:16:18 PST Date: 19 Jan 88 13:16 PST Sender: Bobrow.pa@Xerox.COM From: Danny Bobrow Subject: Re: add-method In-reply-to: Linda DeMichiel 's message of 18 Jan 88 18:03 PST To: LGD@SAIL.Stanford.EDU cc: common-lisp-object-system@SAIL.Stanford.EDU Message-ID: <880119-131618-2133@Xerox> Now that we've moved (make-instance 'standard-method ...) to the meta-object protocol chapter, I'd like to suggest that we move add-method there as well. add-method no longer seems to belong in with the programmer interface functions, since there is no longer a programmer interface level way of creating its second argument (a method object). (The only way one can currently get one's hands on a method object using the programmer interface level functions is to call get-method on another generic function, or, of course, to call defmethod). Since there are ways of getting methods, and moving methods is a reasonable thing to do, I think it is still reasonable to have add-method in chapter 2. Didn't we agree that in the long run, there will only be two chapters - with extensions to chapters 1 and 2.  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 19 Jan 88 12:41:57 EST Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 19 Jan 88 09:39:02 PST Received: from Cabernet.ms by ArpaGateway.ms ; 19 JAN 88 09:38:14 PST Date: 19 Jan 88 09:37 PST Sender: Bobrow.pa@Xerox.COM From: Danny Bobrow Subject: Re: some questions on your chapter 2 comments In-reply-to: David A. Moon 's message of Tue, 19 Jan 88 11:45 EST To: Moon@STONY-BROOK.SCRC.Symbolics.COM cc: LGD@SAIL.STANFORD.EDU, Common-Lisp-Object-System@SAIL.STANFORD.EDU Message-ID: <880119-093814-1652@Xerox> So how about it? Shall we change CLOS so that re-evaluating a defgeneric removes methods that were previously defined by :method, but no longer appear in the new defgeneric form? I think we should. I think that's a good idea. Should we specify how defgeneric knows that a method was defined by :method. We could use a predicate or we could make :method specified methods be a subclass of defgeneric-method. This similar to how accessors methods are specified, and is what I reecommend.  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 19 Jan 88 11:52:21 EST Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 19 Jan 88 08:45:55 PST Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 323377; Tue 19-Jan-88 11:45:23 EST Date: Tue, 19 Jan 88 11:45 EST From: David A. Moon Subject: some questions on your chapter 2 comments To: Linda DeMichiel cc: Common-Lisp-Object-System@SAIL.STANFORD.EDU In-Reply-To: The message of 18 Jan 88 21:08 EST from Linda DeMichiel Message-ID: <19880119164517.8.MOON@EUPHRATES.SCRC.Symbolics.COM> [Added back the rest of the mailing list for this question, which is of general interest.] Date: 18 Jan 88 1808 PST From: Linda DeMichiel In your comments on chapter 2 you mention: 2-29 first line: This says that removing a :method from a defgeneric and re-evaluating the defgeneric does not remove the old method. While that's a good default behavior, we should make sure not to rule out smart program development environments that know better what is going on and remove the old method in cases where the user thinks that's appropriate. In the Error Terminology introduced in chapter 1, implementations should be free to extend this. Redefinition is a program development environment issue, not really a language issue, anyway. This suggested change doesn't sound right to me. The problem is that if this behavior on the part of defgeneric is extensible, programs that rely on the "default" behavior from defgeneric won't be portable. Or did you intend something else here? Redefining a definition is a program development operation, not a programming language operation. Portable programs, with the possible exception of portable program development tools, wouldn't depend on what happens when a defgeneric is evaluated twice. It wouldn't bother me a bit if we changed the language to require all implementations to remove methods that were created by a defgeneric, if the defgeneric were re-evaluated without the :method. We already do this for accessor methods created by defclass. We're now saying that the class remembers the specific method objects and removes them if they are still there; if they've already been replaced by a defmethod, it doesn't remove the method put there by the defmethod. What would bother me would be if we required all implementations to be stupid about this. So how about it? Shall we change CLOS so that re-evaluating a defgeneric removes methods that were previously defined by :method, but no longer appear in the new defgeneric form? I think we should.  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 19 Jan 88 05:17:41 EST Received: from labrea.Stanford.EDU by SAIL.Stanford.EDU with TCP; 19 Jan 88 02:13:36 PST Received: by labrea.Stanford.EDU; Tue, 19 Jan 88 02:13:35 PST Received: from bhopal.lucid.com by edsel id AA08727g; Tue, 19 Jan 88 02:07:03 PST Received: by bhopal id AA13774g; Tue, 19 Jan 88 02:10:16 PST Date: Tue, 19 Jan 88 02:10:16 PST From: Jon L White Message-Id: <8801191010.AA13774@bhopal.lucid.com> To: labrea!Common-Lisp-Object-System%Sail@labrea.Stanford.EDU Subject: Object Lisp vs CLOS in BYTE (Jan 88) In the current issue of BYTE magazine, there is a review of Allegro Common Lisp [the Coral/Franz collusion for the MacIntosh]. Although the reviewer isn't a Lisp Wizard (he says things like "The compiler uses tail recursion to minimize stack space." where he probably should have said "tail recursion elimination"), still he seems to have the knowledge level of an AI user. He goes on at length about how the CLOS specification isn't complete yet, and how Object LISP is offered instead. He knows enough to compare CLOS with "Xerox CommonLoops" and Symbolics "New Flavors". But he praises Object LISP to a large degree: "However, Object LISP is an interesting way to implement objects in Common LISP. I particularly like the way it places classes and instances on the same level. It has always seemed artificial to be able to create objects only as instances of already existing classes. . . . I would like Object LISP to be included with Allegro CL wven when CLOS becomes available. . . ." This looks like a case for cleaning up the documentation relating CLOS to "delagation" type systems. -- JonL --  Received: from Xerox.COM (TCP 1500006350) by AI.AI.MIT.EDU 18 Jan 88 22:26:46 EST Received: from Cabernet.ms by ArpaGateway.ms ; 18 JAN 88 19:27:16 PST Date: 18 Jan 88 19:27 PST From: Kohlsaat.pa@Xerox.COM Subject: Edited AR 914: Want common mechanism instead of IMAGEOBJPROP, PROCESSPROP, WINDOWPROP To: CommonLoopsCore^.PA@Xerox.COM Message-ID: <880118-192716-1074@Xerox> ["Kohlsaat.pa" "18-Jan-88 19:26:14" Difficulty%:(Easy->Moderate)]  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 18 Jan 88 21:05:12 EST Date: 18 Jan 88 1803 PST From: Linda DeMichiel Subject: add-method To: common-lisp-object-system@SAIL.Stanford.EDU Now that we've moved (make-instance 'standard-method ...) to the meta-object protocol chapter, I'd like to suggest that we move add-method there as well. add-method no longer seems to belong in with the programmer interface functions, since there is no longer a programmer interface level way of creating its second argument (a method object). (The only way one can currently get one's hands on a method object using the programmer interface level functions is to call get-method on another generic function, or, of course, to call defmethod). -lgd  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 15 Jan 88 23:56:40 EST Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 15 Jan 88 20:50:39 PST Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 322130; Fri 15-Jan-88 23:41:53 EST Date: Fri, 15 Jan 88 23:41 EST From: David A. Moon Subject: DEFMETHOD Specification To: Patrick H Dussud cc: Common-Lisp-Object-System@SAIL.STANFORD.EDU In-Reply-To: <2778251512-2385869@Jenner> Message-ID: <19880116044142.5.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Fri, 15 Jan 88 10:31:52 CST From: Patrick H Dussud If the DEFMETHOD spec, in the second paragraph [ If (fboundp function-specifier) is nil], it says that the lambda-list of the [created] generic function is congruent with the lambda-list of the method. This is not specific enough, given our rules on lambda-list congruence. The issue is: If the method lambda-list contains some keys, do we create the generic function lambda-list with these keys present? If we do, then we enforce the fact that every method for this generic function must accept these keys. I think that we shouldn't put them in the generic function lambda-list, but either way, this needs to be specified. Good point. The generic function lambda-list should have &key with no parameter specifiers after it in this case. The document should say this explicitly.  Received: from Xerox.COM (TCP 1500006350) by AI.AI.MIT.EDU 15 Jan 88 18:56:24 EST Received: from Salvador.ms by ArpaGateway.ms ; 15 JAN 88 15:39:45 PST Return-Path: <@SUMEX-AIM.Stanford.EDU:HASTINGS@KSL-EXP-19> Redistributed: commonloops.pa Received: from SUMEX-AIM.Stanford.EDU by Xerox.COM ; 15 JAN 88 15:38:05 PST Received: from KSL-EXP-17 by SUMEX-AIM.Stanford.EDU with TCP; Fri, 15 Jan 88 15:36:28 PST Message-Id: <2778276887-4102803@KSL-EXP-17> Sender: HASTINGS@KSL-EXP-17.ARPA Date: Fri, 15 Jan 88 15:34:47 PST From: hastings@sumex.ARPA To: commonloops.pa@Xerox.COM Cc: gregor.pa@Xerox.COM, acuff@sumex.ARPA Subject: Explorer patch for beta PCL Reply-To: hastings@SUMEX-AIM.Stanford.EDU Add the following forms to walk.lisp to have the new beta version of PCL run on a TI Explorer. ;;; --- TI Explorer -- ;;;An environment is a two element list, whose car we can ;;;ignore and whose cadr is list of the ;;;local-definitions-frames. Each local-definitions-frame ;;;holds either macros or functions, but not both. ;;;Each frame is a plist of ... ;;;where is a locative to the function cell of ;;;the symbol that names the function or macro, and ;;; is either NIL if this is function redefinition ;;;or the macro-expansion function if this is a macro ;;;redefinition. ;;; Here's an example. For the form ;;;(defun foo () ;;; (macrolet ((bar (a b) (list a b)) ;;; (bar2 (a b) (list a b))) ;;; (flet ((some-local-fn (c d) (print (list c d))) ;;; (another (c d) (print (list c d)))) ;;; (bar (some-local-fn 1 2) 3)))) ;;;the environment arg to macroexpand-1 when called on (bar (some-local-fn 1 2) 3) ;;;is ;;;(NIL ((# NIL ;;; # NIL) ;;; (# ;;; (TICL:MACRO TICL:NAMED-LAMBDA (BAR (:DESCRIPTIVE-ARGLIST (A B))) ;;; (SYS::*MACROARG* &OPTIONAL SYS::*MACROENVIRONMENT*) ;;; (BLOCK BAR ....)) ;;; # ;;; (TICL:MACRO TICL:NAMED-LAMBDA (BAR2 (:DESCRIPTIVE-ARGLIST (A B))) ;;; (SYS::*MACROARG* &OPTIONAL SYS::*MACROENVIRONMENT*) ;;; (BLOCK BAR2 ....)))) #+TI (progn ;;; from sys:site;macros.lisp (eval-when (compile load eval) (DEFMACRO MACRO-DEF? (thing) `(AND (CONSP ,thing) (EQ (CAR ,thing) 'MACRO))) ;; the following macro generates code to check the 'local' environment for a macro definition for ;; THE SYMBOL . Such a definition would be set up only by a MACROLET. If a macro definition ;; for is found, its expander function is returned. (DEFMACRO FIND-LOCAL-DEFINITION (name local-function-environment) `(IF ,local-function-environment (LET ((vcell (ticl::LOCF (SYMBOL-FUNCTION ,name)))) (DOLIST (frame ,local-function-environment) (LET ((value (sys::GET-LOCATION-OR-NIL (ticl::LOCF frame) vcell))) ;; is nil or a locative (When value (RETURN (CAR value)))))) nil))) ;;;Edited by Reed Hastings 13 Jan 88 16:29 (defun environment-macro (env macro) ;;some code picked off macroexpand-1 (let* ((local-definitions (cadr env)) (local-def (find-local-definition macro local-definitions))) (if (macro-def? local-def) local-def))) ;;;Edited by Reed Hastings 13 Jan 88 16:29 (defun environment-function (env fn) (let* ((local-definitions (cadr env))) (dolist (frame local-definitions) (when (not (getf (ticl::locf (symbol-function fn)) frame :not-found-marker)) (return t))))) ;;;Edited by Reed Hastings 13 Jan 88 16:29 (defun with-augmented-environment-internal (env functions macros) (let ((local-definitions (cadr env)) (new-local-fns-frame (mapcan #'(lambda (fn) (list (ticl:locf (symbol-function (car fn))) nil)) functions)) (new-local-macros-frame (mapcan #'(lambda (m) (list (ticl:locf (symbol-function (car m))) (cadr m))) macros))) (when new-local-fns-frame (push new-local-fns-frame local-definitions)) (when new-local-macros-frame (push new-local-macros-frame local-definitions)) `(,(car env) ,local-definitions))) (defmacro with-augmented-environment ((new-env old-env &key functions macros) &body body) `(let ((,new-env (with-augmented-environment-internal ,old-env ,functions ,macros))) ,@body)) ) ;#+TI  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 15 Jan 88 17:24:22 EST Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 15 Jan 88 14:20:56 PST Received: from Cabernet.ms by ArpaGateway.ms ; 15 JAN 88 14:21:05 PST Date: 15 Jan 88 14:17 PST From: Bobrow.pa@Xerox.COM Subject: Alternative Proposal for class updating To: Common-Lisp-Object-System@Sail.stanford.edu Message-ID: <880115-142105-6052@Xerox> The follwoing is based on suggstions made at the meeting by Gabriel, Dussud and Moon. It is still a sketch. If it seems about right I will send a more complete writeup. It replaces the class specific generic functions It replaces the . I want to consider the following as a replacement for update-class, propagate-class-update, and update-class-locally with some general mechanisms that have wider applicability. These include a facility for reinitialization, a facility for recording dependents for a specific object, and a protocol for updating those dependents. The generic functions used are: Reintialization: reinitialize-instance (object &rest reinit-args) This generic function is intended to initialize again the object. The default method augments the given reinit-args using default-initargs, checks the arguments, and calls initialize-instance. It then updates any dependents method-keyword-arguments (generic-function list-of-arguments) This generic function provides an facility to help users to write code for checking legality of keyword arguments. Recording dependencies. add-dependent(object dependent &key) remove-dependent(object dependent &key) all-dependents(object) These three generic functions allow the recording of dependencies. Nothing is specified about what the dependencies are. The real work is done here: update-dependent(object dependent &key) ----- Here are some sketches of methods: (defmethod reinitialize-instance ((object standard-object) &rest reinit-args) (let*((arglist (list object) (acceptable-args (union (method-keyword-arguments #'initialize-instance arglist) (method-keyword-arguments #'reinitialize-instance arglist) (class-all-slot-initargs (class-of object))))) ;;; check the keyword arguments (loop (key in reinit-args by cddr) (or (member key acceptable-args) (error ...)) ;;; now initialize the instance (apply #'initialize-instance object (default-init-args object reinit-args) ;;; update all dependents (loop (dep in (all-dependents object)) (apply #'update-dependent object dependent reinit-args)) object) (defmethod update-dependent ((class standard-class) (dependent standard-class) &key direct-superclasses direct-slots direct-options) ;;; mark-inheritance as unfinalized, ;;; potentially make-instances-obsolete.) (defmethod finalize-inheritance ((class standard-class)) ;;; compute-cpl ;;; compute-slots ;;; add us as dependent to all classes on ;;; class-precedence-list. Note that this includes us. ;;; mark as finalized.) (defmethod reinitialize-instance :before ((class standard-class) &key direct-superclasses direct-slots direct-options) ;;; unhook old direct-subclass pointers and add new ones ;;; undefine old accessors that are no longer needed)  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 15 Jan 88 16:59:31 EST Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 15 Jan 88 13:56:29 PST Received: from Cabernet.ms by ArpaGateway.ms ; 15 JAN 88 13:53:38 PST Date: 15 Jan 88 13:52 PST Sender: Bobrow.pa@Xerox.COM From: Danny Bobrow Subject: Re: Method Combination Objects In-reply-to: David A. Moon 's message of Thu, 14 Jan 88 22:57 EST To: Moon@STONY-BROOK.SCRC.Symbolics.COM cc: Common-Lisp-Object-System@SAIL.STANFORD.EDU Message-ID: <880115-135338-5966@Xerox> Date: 13 Jan 88 10:36 PST From: Danny Bobrow I have no problem at all with the Method Combination Object Layer. It seems just right. Here is an alternative proposal for a "naming" layer. (method-combination-instance g-fn name :options options) is how a method combination name and options are converted into an object. This looks good to me except for two fairly minor points. One is that I think the options should be a required argument rather than a keyword argument. There is no reason ever to omit this. Fine with me. Secondly, I'm not sure about the name method-combination-instance; it doesn't seem consistent with the rest of chapter 3. I don't know if you've changed the naming conventions since the last version I saw, but in that version the consistent name would be something like expand-method-combination. Personally I prefer parse-xxx for names of functions that convert specifications into objects, rather than expand-xxx. I saw method-combination-instance as being parallel with the generic function slot-description-class, since both participate in the creation of "secondary" objects, i.e. slot-descriptions associated with a class, and method-combination-objects associated with a generic function. Hence the name. In recent days Gregor has come to believe that we need not specify any of the expand-xxx objects which are macroexpander helpers. He claims that to change the macroexpansions users "should" write there own macros. What is your feeling about these expand-xxx or parse-xxx generic functions (I have become neutral on them). Let me know what name is consistent with what you're doing and I'll mail out a modified proposal when I get a chance. Thank you.  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 15 Jan 88 16:59:11 EST Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 15 Jan 88 13:56:22 PST Received: from Semillon.ms by ArpaGateway.ms ; 15 JAN 88 13:53:35 PST Date: Fri, 15 Jan 88 14:22:28 PST From: vijay Subject: Re: call-method proposal prime prime In-Reply-To: <880115133053.3.GREGOR@SPIFF.parc.xerox.com> To: Gregor.pa@Xerox.COM cc: Patrick H Dussud , David A. Moon , common-lisp-object-system@SAIL.STANFORD.EDU Message-ID: <880115-135335-5965@Xerox> Hi Gregor: Will you take me (saraswat.pa and saraswat@c.cs.cmu.edu) off the list please? I am afriad I have fallen too far behind to understand current message traffic. Vijay. References Gregor's message of Fri, 15 Jan 88 13:30:00 PST -- Re: call-method proposal prime prime  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 15 Jan 88 16:35:56 EST Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 15 Jan 88 13:32:54 PST Received: from Semillon.ms by ArpaGateway.ms ; 15 JAN 88 13:32:29 PST Date: Fri, 15 Jan 88 13:30 PST From: Gregor.pa@Xerox.COM Subject: Re: call-method proposal prime prime To: Patrick H Dussud , David A. Moon cc: common-lisp-object-system@SAIL.STANFORD.EDU Fcc: BD:>Gregor>mail>outgoing-mail-1.text In-Reply-To: <2778248738-2219223@Jenner>, <19880115034035.4.MOON@EUPHRATES.SCRC.Symbolics.COM>, <19880115034855.5.MOON@EUPHRATES.SCRC.Symbolics.COM>, <19880115035749.6.MOON@EUPHRATES.SCRC.Symbolics.COM> Message-ID: <880115133053.3.GREGOR@SPIFF.parc.xerox.com> Line-fold: no Date: Thu, 14 Jan 88 22:40 EST From: David A. Moon We're running low on time to decide to adopt this and update the documentation accordingly; can we make a quick decision? I guess I can volunteer to help with the rewriting of existing text, if needed. With the comments I make below I am happy with this and can promise you fast turnaround on comments for anything you write. The technique that MAKE-METHOD-CALL used can't work here. We simply have to decide whether it's the responsibility of the method-combination function or of programs that analyze effective-method forms to know that AND with one subform can be optimized. They also have to know about PROGN, MULTIPLE-VALUE-PROG1, etc. Either way will work and is easy enough to do. In Flavors it's the responsibility of the analyzing programs rather than the synthesizing programs, so that's my suggestion. Either way, the CLOS specification must be explicit about this. I think it should be the resposibility of the analyzing program, but I believe we should make an explicit comment that has the effect of standardizing the 'simple' value that can be returned by the synthesizing program. We should say that analyzing programs will catch the case: (call-method ) This will make people who have some weird special function, and who want to clue the system in to the fact that they are just returning a call to a single method have a standard way of doing that. This doesn't distinguish between "no next method" and "call-next-method not allowed." MAKE-METHOD-CALL made that distinction. If we need to make that distinction, then I suggest one required argument and one keyword argument, :NEXT-METHODS. I don't think the Symbolics implementation will need that distinction, but I don't know about others. It seems like the call-next-method not allowed distinction needs to (mostly) be made at a different time anyways (specifically defmethod time). But if we do make that distinction I agree with Patrick that the argument should be optional rather than keyword. They look right except for one or two comma errors. They are awfully verbose, but I think I agree that in this particular case it's better to be more verbose than to have a more obscure primitive for people to learn. Much of the verbosity is caused by the expressive poverty of Common Lisp, not by your two macros themselves. Fortunately, the short form of define-method-combination eliminates the need for most people to deal with the verbosity. I agree. Date: Thu, 14 Jan 88 22:48 EST From: David A. Moon Date: Tue, 5 Jan 88 12:54 PST From: Gregor.pa@Xerox.COM ....we also need some facility which lets the user call a random function on the same arguments the generic function received. This facility might be called MAKE-FUNCTION-CALL or FUNCTION-CALL or hopefully we could come up with a better name. I assume you decided we don't really need to do anything about this, since it wasn't in your later message. If we do, here's a suggestion. In Flavors, we just put (:ARGLIST . lambda-list) I still think this is very important. I just left it out of my last message for simplicity. Your suggestion about :arglist seems fine to me, but I think :lambda-list is a better name. Date: Thu, 14 Jan 88 22:57 EST From: David A. Moon This looks good to me except for two fairly minor points. One is that I think the options should be a required argument rather than a keyword argument. There is no reason ever to omit this. Secondly, I'm not sure about the name method-combination-instance; it doesn't seem consistent with the rest of chapter 3. I don't know if you've changed the naming conventions since the last version I saw, but in that version the consistent name would be something like expand-method-combination. Personally I prefer parse-xxx for names of functions that convert specifications into objects, rather than expand-xxx. In the message I sent out moments ago, I now believe the expand-xxx functions that were in the mop are not yet well enough understood to be standardized. I do believe we can and should standardize this function though; I like the name method-combination-object. I agree that the options argument should be required rather than keyword or optional. -------  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 15 Jan 88 16:18:24 EST Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 15 Jan 88 13:13:41 PST Received: from Semillon.ms by ArpaGateway.ms ; 15 JAN 88 13:12:39 PST Date: Fri, 15 Jan 88 13:11 PST From: Gregor.pa@Xerox.COM Subject: method-lambda To: common-lisp-object-system@SAIL.STANFORD.EDU Fcc: BD:>Gregor>mail>outgoing-mail-1.text Message-ID: <880115131101.2.GREGOR@SPIFF.parc.xerox.com> Line-fold: no A problem we have never quite resolved is how to abstract out the information about call-next-method (and slot optimization) that needs to be passed to method functions. I have said on several occaisons that I would like for it to be possible to apply method functions to the 'natural' arguments; I would also like it to be possible to construct method functions. Moon has countered quite rightly that this makes it difficult to implement call-next-method. This message proposes a solution to this problem and proposes some significant reduction in some contentious parts of chapter 3. Briefly I propose that we introduce a constructs called method-lambda and method-apply. In addition I propose that we eliminate the defmethod parsing (and defclass parsing) parts of the mop. method lambda is like lambda except that the functions it 'produces' are designed to be called with method-apply. The results of calling a method lambda with ordinary apply are undefined. There might also have to be a method-function-p predicate. method-apply is like apply, it takes the 'natural' arguments that want to be passed to the method function. It does anything else that needs to be done to call the method-function properly. I don't know whether or not it wants to take a list of next methods, I suspect it doesn't. call-next-method inside of the called method-function would just say there were no next methods. Here is some sample code. (defun trace-gf (gf) (let ((nargs (generic-function-required-arguments gf)) (lambda-list (generic-function-congruent-lambda-list gf)) (specializers (make-list nargs :initial-element (symbol-class 't))) (qualifiers '(:around)) (function (compile () `(method-lambda ,lambda-list (format *trace-output* "~&Hi there.") (call-next-method))))) (add-method gf (make-instance 'standard-method :lambda-list lambda-list :specializers specializers :qualifiers qualifiers :function function)))) This code itself is kind of silly, but it shows why it must be possible to construct a function that can be used as the function of a standard-method. Other obvious examples (like steppers) show why it must be possible to call a function that was constructed by defmethod. I propose that we eliminate the defmethod parsing stuff because this provides a significant part of the functionality that was going after and because the defmethod parsing stuff is one of the least well worked out parts of the mop. I do think we should be able to agree on method-lambda, method-function-p and method-apply pretty quickly though. -------  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 15 Jan 88 12:24:40 EST Received: from RELAY.CS.NET by SAIL.Stanford.EDU with TCP; 15 Jan 88 09:23:08 PST Received: from relay2.cs.net by RELAY.CS.NET id ai10935; 15 Jan 88 12:03 EST Received: from csc.ti.com by RELAY.CS.NET id an21503; 15 Jan 88 11:48 EST Received: from Jenner by tilde id AA17626; Fri, 15 Jan 88 10:30:49 CST Message-Id: <2778251512-2385869@Jenner> Date: Fri, 15 Jan 88 10:31:52 CST From: Patrick H Dussud To: Common-Lisp-Object-System@SAIL.STANFORD.EDU Subject: DEFMETHOD Specification If the DEFMETHOD spec, in the second paragraph [ If (fboundp function-specifier) is nil], it says that the lambda-list of the [created] generic function is congruent with the lambda-list of the method. This is not specific enough, given our rules on lambda-list congruence. The issue is: If the method lambda-list contains some keys, do we create the generic function lambda-list with these keys present? If we do, then we enforce the fact that every method for this generic function must accept these keys. I think that we shouldn't put them in the generic function lambda-list, but either way, this needs to be specified. Patrick.  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 15 Jan 88 12:09:41 EST Received: from RELAY.CS.NET by SAIL.Stanford.EDU with TCP; 15 Jan 88 09:07:29 PST Received: from relay2.cs.net by RELAY.CS.NET id ae10723; 15 Jan 88 11:53 EST Received: from csc.ti.com by RELAY.CS.NET id ac21503; 15 Jan 88 11:43 EST Received: from Jenner by tilde id AA16581; Fri, 15 Jan 88 09:44:39 CST Message-Id: <2778248738-2219223@Jenner> Date: Fri, 15 Jan 88 09:45:38 CST From: Patrick H Dussud To: common-lisp-object-system@SAIL.STANFORD.EDU Subject: Re: call-method proposal prime prime In-Reply-To: Msg of Thu, 14 Jan 88 22:40 EST from "David A. Moon" on first examination it appears to be missing the single method optimization but I believe that can be fixed quite easily. The technique that MAKE-METHOD-CALL used can't work here. We simply have to decide whether it's the responsibility of the method-combination function or of programs that analyze effective-method forms to know that AND with one subform can be optimized. They also have to know about PROGN, MULTIPLE-VALUE-PROG1, etc. Either way will work and is easy enough to do. In Flavors it's the responsibility of the analyzing programs rather than the synthesizing programs, so that's my suggestion. Either way, the CLOS specification must be explicit about this. I thought the synthesizing program (the method combination function) would be the natural place for this optimization. I say that because the short form of DEFINE-METHOD-COMBINATION has the optimization option, :identity-with-one-arg that enables the method function to perform the optimization. This proposal uses two lexical macros, CALL-METHOD and EFFECTIVE-METHOD. These macros are lexically bound within the scope of an effective method body. That means that the body of define-method-combination is allowed to return code that uses these macros. Code walkers can understand these macros quite easily, I believe their semantics is also easier for programmers to understand. - call-method accepts two required arguments. The method to call is the first argument. The next methods accesible from that method is the second argument. This doesn't distinguish between "no next method" and "call-next-method not allowed." MAKE-METHOD-CALL made that distinction. If we need to make that distinction, then I suggest one required argument and one keyword argument, :NEXT-METHODS. I don't think the Symbolics implementation will need that distinction, but I don't know about others. Why can't we use an optional second argument instead of a keyword?, I don't think that we want to allow extensions. Besides these points, I am happy with Gregor's proposal. I don't think that MAKE-METHOD-CALL will be used widely enough to justify its existence. Patrick.  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 14 Jan 88 23:56:59 EST Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 14 Jan 88 20:08:24 PST Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 321328; Thu 14-Jan-88 22:57:53 EST Date: Thu, 14 Jan 88 22:57 EST From: David A. Moon Subject: Re: Method Combination Objects To: Common-Lisp-Object-System@SAIL.STANFORD.EDU In-Reply-To: <880113-103639-2495@Xerox> Message-ID: <19880115035749.6.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: 13 Jan 88 10:36 PST From: Danny Bobrow I have no problem at all with the Method Combination Object Layer. It seems just right. Here is an alternative proposal for a "naming" layer. (method-combination-instance g-fn name :options options) is how a method combination name and options are converted into an object. This looks good to me except for two fairly minor points. One is that I think the options should be a required argument rather than a keyword argument. There is no reason ever to omit this. Secondly, I'm not sure about the name method-combination-instance; it doesn't seem consistent with the rest of chapter 3. I don't know if you've changed the naming conventions since the last version I saw, but in that version the consistent name would be something like expand-method-combination. Personally I prefer parse-xxx for names of functions that convert specifications into objects, rather than expand-xxx. Let me know what name is consistent with what you're doing and I'll mail out a modified proposal when I get a chance.  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 14 Jan 88 23:56:44 EST Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 14 Jan 88 20:08:06 PST Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 321324; Thu 14-Jan-88 22:40:43 EST Date: Thu, 14 Jan 88 22:40 EST From: David A. Moon Subject: call-method proposal prime prime To: common-lisp-object-system@SAIL.STANFORD.EDU In-Reply-To: <880111211858.6.GREGOR@SPIFF.parc.xerox.com> Message-ID: <19880115034035.4.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Mon, 11 Jan 88 21:18 PST From: Gregor.pa@Xerox.COM I spent some time thinking about how to solve the problem with make-method-call and concluded that make-method-call was a really complex little bugger. I have come up with a mechanism I believe is simpler, This is pretty similar to a mechanism we rejected a year or so ago, which is where MAKE-METHOD-CALL came from. However, I think we made a mistake back then, and I'm happy with your proposed mechanism, except for a couple of details I'll note below. We're running low on time to decide to adopt this and update the documentation accordingly; can we make a quick decision? I guess I can volunteer to help with the rewriting of existing text, if needed. on first examination it appears to be missing the single method optimization but I believe that can be fixed quite easily. The technique that MAKE-METHOD-CALL used can't work here. We simply have to decide whether it's the responsibility of the method-combination function or of programs that analyze effective-method forms to know that AND with one subform can be optimized. They also have to know about PROGN, MULTIPLE-VALUE-PROG1, etc. Either way will work and is easy enough to do. In Flavors it's the responsibility of the analyzing programs rather than the synthesizing programs, so that's my suggestion. Either way, the CLOS specification must be explicit about this. This proposal uses two lexical macros, CALL-METHOD and EFFECTIVE-METHOD. These macros are lexically bound within the scope of an effective method body. That means that the body of define-method-combination is allowed to return code that uses these macros. Code walkers can understand these macros quite easily, I believe their semantics is also easier for programmers to understand. - call-method accepts two required arguments. The method to call is the first argument. The next methods accesible from that method is the second argument. This doesn't distinguish between "no next method" and "call-next-method not allowed." MAKE-METHOD-CALL made that distinction. If we need to make that distinction, then I suggest one required argument and one keyword argument, :NEXT-METHODS. I don't think the Symbolics implementation will need that distinction, but I don't know about others. Here are implementations of standard and and method combination written using this mechanism. They look right except for one or two comma errors. They are awfully verbose, but I think I agree that in this particular case it's better to be more verbose than to have a more obscure primitive for people to learn. Much of the verbosity is caused by the expressive poverty of Common Lisp, not by your two macros themselves. Fortunately, the short form of define-method-combination eliminates the need for most people to deal with the verbosity. For fun: (defun make-method-call (methods &key (operator 'progn) (identity-with-one-argument (eq operator 'progn))) (unless (listp methods) (setq methods (list methods))) (let ((forms (mapcar #'(lambda (method) (if (listp method) method `(call-method ,method ()))) methods)) (methods (mapcar #'(lambda (method) (if (listp method) `(effective-method ,method) method)) methods))) (cond ((eq operator ':call-next-method) (and methods `(method-call ,(first methods) ,(rest methods)))) ((and identity-with-one-argument (= (length methods) 1)) (first forms)) (t `(,operator ,@forms))))) That wasn't so bad, was it? In fact it's the same number of lines as your new definition of standard method combination.  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 14 Jan 88 23:56:28 EST Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 14 Jan 88 20:08:06 PST Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 321325; Thu 14-Jan-88 22:48:59 EST Date: Thu, 14 Jan 88 22:48 EST From: David A. Moon Subject: Standardizing the macroexpansion of make-method-call To: Gregor.pa@Xerox.COM cc: Common-Lisp-Object-System@SAIL.STANFORD.EDU In-Reply-To: <880105125449.1.GREGOR@SPIFF.parc.xerox.com> Message-ID: <19880115034855.5.MOON@EUPHRATES.SCRC.Symbolics.COM> Line-fold: No Date: Tue, 5 Jan 88 12:54 PST From: Gregor.pa@Xerox.COM ....we also need some facility which lets the user call a random function on the same arguments the generic function received. This facility might be called MAKE-FUNCTION-CALL or FUNCTION-CALL or hopefully we could come up with a better name. We have seen several examples of people who want a method combination type which performs some specific behavior as part of the combined method but that behavior needs access to the arguments to the generic function. Inventing this might even lead us out of the mess we have with make-method-call because it might force us to come up with a real abstraction for 'captured calls' and for 'access to the generic function arguments'. More on this later if I can think of anything, I sent this now hoping it might help someone else think of something. I assume you decided we don't really need to do anything about this, since it wasn't in your later message. If we do, here's a suggestion. In Flavors, we just put (:ARGLIST . lambda-list) in front of the body of the define-method-combination, and parameter variables in the lambda-list are bound to forms that can be inserted into the effective-method to access the corresponding arguments to the generic function (I guess they are gensyms or something). Extra arguments to the generic function can be ignored. This seems simpler for the application you described than introducing a function call. Here's a simple example: (define-method-combination progn-with-lock () ((methods ())) (:arglist object) `(unwind-protect (progn (lock (object-lock ,object)) ,@(mapcar #'(lambda (m) `(call-method ,m ())) methods)) (unlock (object-lock ,object))))  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 14 Jan 88 09:57:12 EST Received: from RELAY.CS.NET by SAIL.Stanford.EDU with TCP; 14 Jan 88 06:56:27 PST Received: from relay2.cs.net by RELAY.CS.NET id aa07671; 14 Jan 88 9:52 EST Received: from csc.ti.com by RELAY.CS.NET id aa13381; 14 Jan 88 9:42 EST Received: from Jenner by tilde id AA04504; Thu, 14 Jan 88 08:14:42 CST Message-Id: <2778156951-13219609@Jenner> Date: Thu, 14 Jan 88 08:15:51 CST From: Patrick H Dussud To: common-lisp-object-system@SAIL.STANFORD.EDU Subject: Re: add-method when method exists In-Reply-To: Msg of Mon, 28 Dec 87 14:53 EST from "David A. Moon" Date: Mon, 28 Dec 87 14:53 EST From: "David A. Moon" Subject: Re: add-method when method exists 3)Should add-method become add-or-replace-method I agree with the semantics, I would propose to keep the name as simple as possible. If we qualify the name, people will expect to find other variations like add-or-complain-method.... 4) Precisely when are errors signaled Since we allow forward references for classes, we need to allow illegal states for generic functions temporarily. The following code should be allowed: (defgeneric trash (object) (:documentation "destroy the contents of object")) (defclass foo (bar) ...) (defmethod trash :after ((object foo)) ...) (defclass bar () ...) (defmethod trash ((object bar)) ...) At least add-method shouldn't complain if a daemon method is added and there is no primary method. Patrick.  Received: from Xerox.COM (TCP 1500006350) by AI.AI.MIT.EDU 14 Jan 88 01:43:55 EST Received: from Concord.ms by ArpaGateway.ms ; 13 JAN 88 22:35:42 PST Return-Path: Redistributed: commonloops.PA Received: from media-lab.MIT.EDU (media-lab.media.mit.edu) by Xerox.COM ; 13 JAN 88 22:34:04 PST Received: from zaxxon.media.mit.edu by media-lab.MIT.EDU (5.54/4.8) via CHAOS with CHAOS id AA16551; Thu, 14 Jan 88 01:29:21 EST Date: Thu, 14 Jan 88 01:28 EST From: Steve Strassmann Subject: bugs printing CLOS documentation To: commonloops.PA@Xerox.COM Message-Id: <880114012843.1.STRAZ@ZAXXON.MEDIA.MIT.EDU> (1) The file "PARCVAX.XEROX.COM:/pub/pcl/doc/amfont.tex" has some incorrect references to cmfont. To fix this, please replace every occurrence of "cm" with "am". (2) In the file "PARCVAX.XEROX.COM:/pub/pcl/doc/macros.tex", please fix a typo: Wrong: \obeylines\catcode`\!=0\relax\input\jobname.tc\relax} Right: \obeylines\catcode`\!=0\relax\input\jobname.toc\relax}  Received: from Xerox.COM (TCP 1500006350) by AI.AI.MIT.EDU 13 Jan 88 23:31:54 EST Received: from Salvador.ms by ArpaGateway.ms ; 13 JAN 88 20:22:25 PST Return-Path: Redistributed: CommonLoops.pa Received: from ucbarpa.Berkeley.EDU by Xerox.COM ; 13 JAN 88 20:20:02 PST Received: by ucbarpa.Berkeley.EDU (5.58/1.26) id AA01015; Wed, 13 Jan 88 20:20:08 PST Received: from akbar by franz (5.5/3.14) id AA21897; Wed, 13 Jan 88 17:17:13 PST Received: by akbar (5.5/3.14) id AA20507; Wed, 13 Jan 88 17:21:02 PST From: franz!akbar!layer@ucbarpa.Berkeley.EDU (Kevin Layer) Return-Path: Message-Id: <8801140121.AA20507@akbar> To: Rob Pettengill Cc: Gregor.pa@Xerox.COM, CommonLoops.pa@Xerox.COM Subject: Re: Problem specializing default methods in PCL 1/11/88 In-Reply-To: Your message of Wed, 13 Jan 88 16:20:39 CST. <8801132220.AA02114@perseus> Date: Wed, 13 Jan 88 17:21:01 PST >> Implementation: Sun Common Lisp version 3.0.beta.68 [sun3 with patch level 6] >> (12/28/87 15:49) >> >> (use-package 'pcl) >> >> T >> (defmethod bar (self) (+ self 2)) >> >> NIL >> (bar 3) >> >> 5 >> (defclass foo () ((a :initform 0 :accessor foo-a))) >> >> NIL >> (defmethod bar ((self foo)) (+ (foo-a self) 2)) >> Error: Received signal number 11 (Segmentation violation) >> [1] :zo I tried it locally (on version 3.0.beta.82), and I got: (use-package 'pcl) t (defmethod bar (self) (+ self 2)) # (bar 3) 5 (defclass foo () ((a :initform 0 :accessor foo-a))) # (defmethod bar ((self foo)) (+ (foo-a self) 2)) # I using a modified 8/27/87 version, and I've given my changes to Gregor--they may not be in the ftp'able version yet. Kevin  Received: from SAIL.Stanford.EDU (TCP 4425400302) by AI.AI.MIT.EDU 13 Jan 88 20:17:20 EST Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 13 Jan 88 17:16:00 PST Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 320557; Wed 13-Jan-88 20:15:38 EST Date: Wed, 13 Jan 88 20:15 EST From: David A. Moon Subject: Sonya's problem with functi.dvi To: common-lisp-object-system@SAIL.STANFORD.EDU In-Reply-To: The message of 13 Jan 88 17:37 EST from Linda DeMichiel Message-ID: <19880114011548.2.MOON@EUPHRATES.SCRC.Symbolics.COM> The source of at least the immediate symptom turned out to be that someone had trashed the information about SAIL.STANFORD.EDU in the Internet domain database, specifically what operating system it runs. Since this is a distributed database with no audit trails, it's a bit difficult to find out who was responsible. We have a way to get around it, now that we know that that was the problem.  Received: from Xerox.COM (TCP 1500006350) by AI.AI.MIT.EDU 13 Jan 88 18:46:53 EST Received: from Chardonnay.ms by ArpaGateway.ms ; 13 JAN 88 15:36:30 PST Return-Path: <@MCC.COM:rcp%sw.MCC.COM@MCC.COM> Redistributed: CommonLoops.pa Received: from MCC.COM by Xerox.COM ; 13 JAN 88 15:33:33 PST Received: from milano.SW.MCC.COM by MCC.COM with TCP; Wed 13 Jan 88 17:32:57-CST Received: from perseus by milano.SW.MCC.COM (5.52/STP1.55) id AA15868; Wed, 13 Jan 88 11:43:03 CST Date: Wed, 13 Jan 88 11:42:49 CST From: Rob Pettengill Message-Id: <8801131742.AA01798@perseus> Received: by perseus (3.2/STP) id AA01798; Wed, 13 Jan 88 11:42:49 CST To: Gregor.pa@Xerox.COM Cc: CommonLoops.pa@Xerox.COM Subject: Bug in defaulted keyword arguments to setf methods Example: (use-package 'pcl) T (defclass foo () ((a))) # (defmethod n-a ((self foo) &key (n 2)) (* n (slot-value self 'a))) # (defmethod-setf n-a ((self foo) &key (n 2)) (new-val) (setf (slot-value self 'a) (/ new-val n))) # (setq foo (make-instance 'foo :a 7)) # (n-a foo) 14 (n-a foo :n 3) 21 (setf (n-a foo) 24) Continuable error: attempt to call `N' which is an undefined function. If continued with :continue, prompt for a new function. [1c] :zo Evaluation stack: ->(CERROR "prompt for a new function." "attempt to call `~s' which is an undefined function." N) (LET* ((SELF (CAR (CDR EXCL::%ACCESS-ARGLIST))) (#:G229 (CDR (CDR EXCL::%ACCESS-ARGLIST))) #:G230 (N (COND ((SETQ #:G230 (EXCL::FIND-KEYWORD # #:G229)) (CAR #:G230)) (T 2)))) (EXCL::KEYWORD-TEST #:G229 '(:N)) (LIST '|setf N-A| SELF NEW-VAL (N 2))) ... more older frames ... The problem is that the setf function is trying to eval (n 2) rather than n. I traced this problem to do-do-defmethod-setf-defsetf in the file defs.lisp. This function appears to deal only with the "&key foo" case and not the "&key (foo t)" or the "&key ((:foo-key foo) t)" case. I came up with the following quick fix. I also think that there may be a problem when &allow-other-keys are used with several setf methods for the same generic function. The problem and fix appear to be the same in both the 8/27/87 and 1/11/88 versions of pcl. (IN-PACKAGE 'PCL) ; in this package ;;; fix for pcl file defs.lisp in the 8/27/87 and 1/11/88 versions so ;;; that &key arguments in setf methods are more correctly handled (defun do-defmethod-setf-defsetf (generic-function-name arglist &optional (new-value-arglist '(new-value))) (when (member '&aux arglist) (setq arglist (reverse arglist)) (loop (when (eq (pop arglist) '&aux) (return (setq arglist (nreverse arglist)))))) (let* ((setf-name (pcl::get-setf-generic-function-name generic-function-name)) (setf-ll (pcl::make-setf-method-lambda-list arglist new-value-arglist))) (do-defsetf generic-function-name arglist new-value-arglist ``(,',setf-name ;; formerly we had ;; ,,@(remove-if #'(lambda (x) ;; (member x lambda-list-keywords)) ;; setf-ll) ;; which did not handle keyword args with initial values ;; There is probably still a problem with ;; &allow-other-keys keywords from previously defined ;; setf methods. ,,@(let ((optional-or-key nil)) (mapcan #'(lambda (arg) (cond ((eq arg '&optional) (setq optional-or-key :opt) nil) ((eq arg '&key) (setq optional-or-key :key) nil) ((member arg lambda-list-keywords) nil) (t (let ((karg (if (listp arg) (first arg) arg))) (case optional-or-key (:opt (list karg)) (:key (if (listp karg) karg (list (intern (symbol-name karg) (find-package :keyword)) karg))) ( t (list karg))))))) setf-ll)))))) ;rob Robert C. Pettengill, MCC Software Technology Program P. O. Box 200195, Austin, Texas 78720 ARPA: rcp@mcc.com PHONE: (512) 338-3533 UUCP: {ihnp4,seismo,harvard,gatech,pyramid}!ut-sally!im4u!milano!rcp  Received: from Xerox.COM (TCP 1500006350) by AI.AI.MIT.EDU 13 Jan 88 18:46:37 EST Received: from Chardonnay.ms by ArpaGateway.ms ; 13 JAN 88 15:20:24 PST Return-Path: <@MCC.COM:rcp%sw.MCC.COM@MCC.COM> Redistributed: CommonLoops.pa Received: from MCC.COM by Xerox.COM ; 13 JAN 88 15:13:39 PST Received: from milano.SW.MCC.COM by MCC.COM with TCP; Wed 13 Jan 88 17:09:59-CST Received: from perseus by milano.SW.MCC.COM (5.52/STP1.55) id AA19147; Wed, 13 Jan 88 16:20:54 CST Date: Wed, 13 Jan 88 16:20:39 CST From: Rob Pettengill Message-Id: <8801132220.AA02114@perseus> Received: by perseus (3.2/STP) id AA02114; Wed, 13 Jan 88 16:20:39 CST To: Gregor.pa@Xerox.COM Cc: CommonLoops.pa@Xerox.COM Subject: Problem specializing default methods in PCL 1/11/88 In prior versions of pcl we have used a defmethod with an unspeciallized lambda list to define a default method handler. This doesn't seem to work in the new version running under Franz on the Sun. Implementation: Sun Common Lisp version 3.0.beta.68 [sun3 with patch level 6] (12/28/87 15:49) (use-package 'pcl) T (defmethod bar (self) (+ self 2)) NIL (bar 3) 5 (defclass foo () ((a :initform 0 :accessor foo-a))) NIL (defmethod bar ((self foo)) (+ (foo-a self) 2)) Error: Received signal number 11 (Segmentation violation) [1] :zo Evaluation stack: ->(ERROR "Received signal number ~s ~@[(~a)~]" 11 ...) (PCL::CLASS-PRECEDENCE-LIST NIL) (PCL::GREATEST-JOIN-POINTS # NIL) (PCL::CROSS-COMBINATION-POINTS (#) NIL) (PCL::COMPUTE-COMBINATION-POINTS #) (PCL::COMPUTE-COMBINED-METHODS #) (PCL::|(METHOD GENERIC-FUNCTION-CHANGED (STANDARD-GENERIC-FUNCTION))| # # ...) (#:|.l.a59668e6| # # ...) ... more older frames ... [1] ;rob Robert C. Pettengill, MCC Software Technology Program P. O. Box 200195, Austin, Texas 78720 ARPA: rcp@mcc.com PHONE: (512) 338-3533 UUCP: {ihnp4,seismo,harvard,gatech,pyramid}!ut-sally!im4u!milano!rcp  Received: from SAIL.Stanford.EDU (TCP 4425400302) by AI.AI.MIT.EDU 13 Jan 88 17:38:40 EST Date: 13 Jan 88 1437 PST From: Linda DeMichiel Subject: functi.dvi To: skeene@SCRC-STONY-BROOK.ARPA CC: common-lisp-object-system@SAIL.Stanford.EDU I retexed functi and as far as I can tell the .dvi file is fine. Sail has been having arpanet trouble lately, so perhaps there was ftp lossage in the copy you got. Note: the current copy on sail pre-dates our Cambridge meeting. I'll be putting out a new copy to reflect recent comments around the beginning of next week. -l  Received: from SAIL.Stanford.EDU (TCP 4425400302) by AI.AI.MIT.EDU 13 Jan 88 15:41:41 EST Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 13 Jan 88 12:39:25 PST Received: from Semillon.ms by ArpaGateway.ms ; 13 JAN 88 10:53:45 PST Date: Wed, 13 Jan 88 10:52 PST From: Gregor.pa@Xerox.COM Subject: Defmethod-setf To: Dick Gabriel cc: common-lisp-object-system@SAIL.STANFORD.EDU Fcc: BD:>Gregor>mail>outgoing-mail-1.text In-Reply-To: The message of 13 Jan 88 08:04 PST from Dick Gabriel Message-ID: <880113105230.8.GREGOR@SPIFF.parc.xerox.com> Line-fold: no Oops, I am on mars. We already flushed defmethod-setf and friends. Well I knew it was a good idea. Gregor -------  Received: from SAIL.Stanford.EDU (TCP 4425400302) by AI.AI.MIT.EDU 13 Jan 88 14:52:44 EST Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 13 Jan 88 10:37:40 PST Received: from Cabernet.ms by ArpaGateway.ms ; 13 JAN 88 10:36:39 PST Date: 13 Jan 88 10:36 PST Sender: Bobrow.pa@Xerox.COM From: Danny Bobrow Subject: Re: Method Combination Objects In-reply-to: David A. Moon 's message of Tue, 29 Dec 87 17:27 EST To: Moon@STONY-BROOK.SCRC.Symbolics.COM cc: Common-Lisp-Object-System@SAIL.STANFORD.EDU Message-ID: <880113-103639-2495@Xerox> I have no problem at all with the Method Combination Object Layer. It seems just right. Here is an alternative proposal for a "naming" layer. There is a generic function: (defgeneric method-combination-instance (generic-function method-combination &key options) ...) This generic function combines the capabilities of method-combination-maker and the application of the resulting function to produce the method combination object. (method-combination-instance g-fn name :options options) is how a method combination name and options are converted into an object. (defmethod method-combination-instance ((g-fn standard-generic-function) (name (eql ') &key options) ....) is how a method combination type is defined. remove-method is how it is undefined. Comparison to method-combination-maker It has the same advantages with respect to: 1) It provides a separate name space for method combination names. 2) Several method combination types might share a single class. 3) A call to method-combination-instance might return the same object each time it is called, instead of making a new object. Advantages of method-combination-instance: It uses a mechanism already in CLOS, namely methods on individuals, and does not add a new function for associating a name with an object, or a way to unset that association. It allows specialization on the class of the generic function as well as on the name. Although useful, this might not be important because compute-effective-method also allows specialization on both the generic function and method combination object. Disadvantage: As pointed out by Moon: The options seen in the :method-combination option to defgeneric are defined by a lambda-list in define-method-combination, rather than being just keyword arguments. ... Passing the whole list of options as one :options initialization argument, we wouldn't be exploiting any Lisp mechanism to parse the options. As Moon points out we could change the options arguments into keywords. Alternatively, this can be programmed around by using an application of a lambda-list internal to the method to check the arguments. In Moons message, he provides the following macro definition: (defmacro define-method-combination (name &key (documentation nil) (operator name) (identity-with-one-argument nil)) `(setf (method-combination-maker ',name) #'(lambda (&optional (order ':most-specific-first)) (make-instance 'short-form-method-combination 'name ',name 'order order 'documentation ',documentation 'operator ',operator 'identity-with-one-argument ',identity-with-one-argument)))) The comparable code is approximately: (defmacro define-method-combination (name &key (documentation nil) (operator name) (identity-with-one-argument nil)) `(defmethod method-combination-instance ((g-fn standard-generic-function) (eql ',name) &key options) (apply #'(lambda (&optional (order ':most-specific-first)) (make-instance 'short-form-method-combination 'name ',name 'order order 'documentation ',documentation 'operator ',operator 'identity-with-one-argument ',identity-with-one-argument)) options)))  Received: from SAIL.Stanford.EDU (TCP 4425400302) by AI.AI.MIT.EDU 13 Jan 88 14:49:27 EST Date: 13 Jan 88 1009 PST From: Linda DeMichiel Subject: defmethod-setf To: gregor@XEROX.COM CC: common-lisp-object-system@SAIL.Stanford.EDU defmethod-setf and defgeneric-setf were flushed several months ago. -lgd  Received: from SAIL.Stanford.EDU (TCP 4425400302) by AI.AI.MIT.EDU 13 Jan 88 14:48:40 EST Received: from RELAY.CS.NET by SAIL.Stanford.EDU with TCP; 13 Jan 88 09:26:26 PST Received: from relay2.cs.net by RELAY.CS.NET id aa22672; 13 Jan 88 11:37 EST Received: from csc.ti.com by RELAY.CS.NET id aa06619; 13 Jan 88 11:27 EST Received: from Jenner by tilde id AA07755; Wed, 13 Jan 88 07:16:55 CST Message-Id: <2778067032-7820945@Jenner> Date: Wed, 13 Jan 88 07:17:12 CST From: Patrick H Dussud To: Gregor.pa@XEROX.COM Cc: common-lisp-object-system@SAIL.STANFORD.EDU Subject: Re: defmethod-setf In-Reply-To: Msg of Tue, 12 Jan 88 19:16 PST from Gregor.pa@xerox.com Date: Tue, 12 Jan 88 19:16 PST From: Gregor.pa@xerox.com Subject: defmethod-setf A while ago, we developed a proposal for real setf functions and a simple rule for when setf should expand into a call to them. That proposal was well received by the cleanup committee. Given that proposal, people can program like this: (defun foo (x) (gethash x *foo*)) (defun (foo setf) (nv x) (setf (gethash x *foo*) nv)) Which is great. I think we should get rid of defmethod-setf and defgeneric-setf. I think they are just superfluous and confusing. ------- I agree with this. As a matter of fact, I thought we already got rid of them. Patrick.  Received: from SAIL.Stanford.EDU (TCP 4425400302) by AI.AI.MIT.EDU 13 Jan 88 12:26:52 EST Received: from RELAY.CS.NET by SAIL.Stanford.EDU with TCP; 13 Jan 88 09:26:26 PST Received: from relay2.cs.net by RELAY.CS.NET id aa22672; 13 Jan 88 11:37 EST Received: from csc.ti.com by RELAY.CS.NET id aa06619; 13 Jan 88 11:27 EST Received: from Jenner by tilde id AA07755; Wed, 13 Jan 88 07:16:55 CST Message-Id: <2778067032-7820945@Jenner> Date: Wed, 13 Jan 88 07:17:12 CST From: Patrick H Dussud To: Gregor.pa@XEROX.COM Cc: common-lisp-object-system@SAIL.STANFORD.EDU Subject: Re: defmethod-setf In-Reply-To: Msg of Tue, 12 Jan 88 19:16 PST from Gregor.pa@xerox.com Date: Tue, 12 Jan 88 19:16 PST From: Gregor.pa@xerox.com Subject: defmethod-setf A while ago, we developed a proposal for real setf functions and a simple rule for when setf should expand into a call to them. That proposal was well received by the cleanup committee. Given that proposal, people can program like this: (defun foo (x) (gethash x *foo*)) (defun (foo setf) (nv x) (setf (gethash x *foo*) nv)) Which is great. I think we should get rid of defmethod-setf and defgeneric-setf. I think they are just superfluous and confusing. ------- I agree with this. As a matter of fact, I thought we already got rid of them. Patrick.  Received: from SAIL.Stanford.EDU (TCP 4425400302) by AI.AI.MIT.EDU 13 Jan 88 11:23:07 EST Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 13 Jan 88 08:21:54 PST Received: from JUNCO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 320057; Wed 13-Jan-88 11:21:58 EST Date: Wed, 13 Jan 88 11:21 EST From: Sonya E. Keene Subject: is the functi.dvi file trashed? To: common-lisp-object-system@SAIL.STANFORD.EDU Message-ID: <19880113162140.4.SKEENE@JUNCO.SCRC.Symbolics.COM> When I print it, it looks completely trashed. Could someone reformat it? Thanks.  Received: from SAIL.Stanford.EDU (TCP 4425400302) by AI.AI.MIT.EDU 13 Jan 88 04:40:41 EST Received: from labrea.Stanford.EDU by SAIL.Stanford.EDU with TCP; 12 Jan 88 22:15:21 PST Received: by labrea.Stanford.EDU; Tue, 12 Jan 88 22:15:21 PST Received: from bhopal.lucid.com by edsel id AA27808g; Tue, 12 Jan 88 22:06:00 PST Received: by bhopal id AA15662g; Tue, 12 Jan 88 22:08:44 PST Date: Tue, 12 Jan 88 22:08:44 PST From: Jon L White Message-Id: <8801130608.AA15662@bhopal.lucid.com> To: labrea!Moon%STONY-BROOK.SCRC.Symbolics.COM@labrea.Stanford.EDU Cc: labrea!common-lisp-object-system%SAIL@labrea.Stanford.EDU In-Reply-To: David A. Moon's message of Mon, 11 Jan 88 20:22 EST <19880112012217.5.MOON@EUPHRATES.SCRC.Symbolics.COM> Subject: CALL-NEXT-METHOD and funcall-qua/send-as re: . . . In that old class system, and in all versions of Flavors I am aware of, the body of a method can do things that the body of a function can't, such as reference instance variables, which is the argument for having a special way to name subroutines of methods that is different from DEFUN. An explicit goal of the EXTEND system was to unify the functional programming syntax with a smalltalk like class system; indeed, the early versions of the Lisp Machine CLASS system (and even FLAVORS) were so much like smalltalk that they perpetuated the special metavariable status of 'self' (and 'super' too, I think?) and thus didn't look like functions. [Instance variables were referenced with normal macros, since pdp10 Maclisp didn't support "symbol macros"]. CLOS follows the EXTEND lead here. As to how this relates to the funcall-qua/send-as issue -- the motivating problem was really ease of implementing "delagation". This is probably best not handled as a kludge on CALL-NEXT-METHOD; however, maybe some thought out to be given to this area in the concepts section of the spec? On the other hand, you seem to be concerned about the more general problem of code-sharing in your comment: the problem [with SEND-AS] is that it is a way to name a function that is different from the normal way to name functions. Instead of SEND-AS, I prefer to say that if two methods have a subroutine in common, that subroutine should be given a name with DEFUN in the normal way and then they both should call it. . . . I don't think this is releated to "delegation". Do you? -- JonL --  Received: from SAIL.Stanford.EDU (TCP 4425400302) by AI.AI.MIT.EDU 13 Jan 88 04:38:23 EST Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 12 Jan 88 20:06:23 PST Received: from Semillon.ms by ArpaGateway.ms ; 12 JAN 88 19:17:21 PST Date: Tue, 12 Jan 88 19:16 PST From: Gregor.pa@Xerox.COM Subject: defmethod-setf To: common-lisp-object-system@SAIL.STANFORD.EDU Fcc: BD:>Gregor>mail>outgoing-mail-1.text Message-ID: <880112191617.4.GREGOR@SPIFF.parc.xerox.com> Line-fold: no A while ago, we developed a proposal for real setf functions and a simple rule for when setf should expand into a call to them. That proposal was well received by the cleanup committee. Given that proposal, people can program like this: (defun foo (x) (gethash x *foo*)) (defun (foo setf) (nv x) (setf (gethash x *foo*) nv)) Which is great. I think we should get rid of defmethod-setf and defgeneric-setf. I think they are just superfluous and confusing. -------  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 12 Jan 88 01:13:41 EST Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 11 Jan 88 21:21:17 PST Received: from Semillon.ms by ArpaGateway.ms ; 11 JAN 88 21:20:04 PST Date: Mon, 11 Jan 88 21:18 PST From: Gregor.pa@Xerox.COM Subject: call-method proposal prime prime To: common-lisp-object-system@SAIL.STANFORD.EDU Fcc: BD:>Gregor>mail>outgoing-mail-1.text Supersedes: <880111184514.5.GREGOR@SPIFF.parc.xerox.com> Message-ID: <880111211858.6.GREGOR@SPIFF.parc.xerox.com> Line-fold: no Pavel pointed out that I lost while trying to compensate for previous lossage. At least I know Pavel is reading these messages. This message entirely supersedes the messages I sent earlier. I spent some time thinking about how to solve the problem with make-method-call and concluded that make-method-call was a really complex little bugger. I have come up with a mechanism I believe is simpler, on first examination it appears to be missing the single method optimization but I believe that can be fixed quite easily. This description is not entirely adequate, but I hope its enough to convey the flavor of this proposal. This proposal uses two lexical macros, CALL-METHOD and EFFECTIVE-METHOD. These macros are lexically bound within the scope of an effective method body. That means that the body of define-method-combination is allowed to return code that uses these macros. Code walkers can understand these macros quite easily, I believe their semantics is also easier for programmers to understand. The differences between this and make-method-call in the spec are: - these are lexical macros - the functionality of automatically converting lists to combined methods provided by make-method-call is not provided by call-method. Instead, the effective method lexical macro must be used to declare that a form is itself an effective method being used in the call-next-method list. - call-method accepts two required arguments. The method to call is the first argument. The next methods accesible from that method is the second argument. - support for :operation and :identity-with-one-argument is missing. I believe this makes things simpler. I also believe we can get that optimization back quite easily. The biggest difference is that I find this conceptually simpler to understand. When I see call-method, I don't have to think about the three different forms the first argument to make-method-call can have, I know the first argument must be a method. I know the second argument must be a list of methods or effective-method forms. Here are implementations of standard and and method combination written using this mechanism. I have read them over, I believe they are right, but I don't have an implementation of this so I can't be sure. (define-method-combination standard () ((around (:around)) (before (:before)) (primary () :required t) (after (:after))) (let ((effective ;; This is the real method that gets run once all of the ;; :around methods have call-next-method'ed to get to it. `(effective-method (multiple-value-prog1 (progn ,@(mapcar #'(lambda (m) `(call-method ,m ())) before) (call-method ,(car primary) ,(cdr primary))) ,@(mapcar #'(lambda (m) `(call-method ,m ())) (reverse after)))))) (if around `(call-method ,(car around) ,(append (cdr around) (list effective))) `(call-method ,effective ())))) (define-method-combination and (&optional (order ':most-specific-first)) ((around (:around)) (primary (and) :order order :required t)) (let ((effective `(effective-method (and (mapcar #'(lambda (m) `(call-method ,m ())) primary))))) (if around `(call-method ,(car around) ,(append (cdr around) (list effective))) `(call-method ,effective)))) -------  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 11 Jan 88 22:19:30 EST Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 11 Jan 88 19:17:42 PST Received: from Semillon.ms by ArpaGateway.ms ; 11 JAN 88 18:46:17 PST Date: Mon, 11 Jan 88 18:45 PST From: Gregor.pa@Xerox.COM Subject: call-method proposal prime To: common-lisp-object-system@SAIL.STANFORD.EDU Fcc: BD:>Gregor>mail>outgoing-mail-1.text Message-ID: <880111184514.5.GREGOR@SPIFF.parc.xerox.com> Line-fold: no Pavel pointed out a couple of bugs in my examples. They are fixed in here. This message entirely supersedes the one I sent out earlier. I spent some time thinking about how to solve the problem with make-method-call and concluded that make-method-call was a really complex little bugger. I have come up with a mechanism I believe is simpler, on first examination it appears to be missing the single method optimization but I believe that can be fixed quite easily. This description is not entirely adequate, but I hope its enough to convey the flavor of this proposal. This proposal uses two lexical macros, CALL-METHOD and EFFECTIVE-METHOD. These macros are lexically bound within the scope of an effective method body. That means that the body of define-method-combination is allowed to return code that uses these macros. Code walkers can understand these macros quite easily, I believe their semantics is also easier for programmers to understand. The differences between this and make-method-call in the spec are: - these are lexical macros - the functionality of automatically converting lists to combined methods provided by make-method-call is not provided by call-method. Instead, the effective method lexical macro must be used to declare that a form is itself an effective method being used in the call-next-method list. - call-method accepts two required arguments. The method to call is the first argument. The next methods accesible from that method is the second argument. - support for :operation and :identity-with-one-argument is missing. I believe this makes things simpler. I also believe we can get that optimization back quite easily. The biggest difference is that I find this conceptually simpler to understand. When I see call-method, I don't have to think about the three different forms the first argument to make-method-call can have, I know the first argument must be a method. I know the second argument must be a list of methods or effective-method forms. Here are implementations of standard and and method combination written using this mechanism. I have read them over, I believe they are right, but I don't have an implementation of this so I can't be sure. (define-method-combination standard () ((around (:around)) (before (:before)) (primary () :required t) (after (:after))) (let ((effective ;; This is the real method that gets run once all of the ;; :around methods have call-next-method'ed to get to it. `(effective-method (progn ,@(mapcar #'(lambda (m) `(call-method ,m ())) before)) (call-method ,(car primary) ,(cdr primary)) (progn ,@(mapcar #'(lambda (m) `(call-method ,m ())) after))))) (if around `(call-method ,(car around) ,(append (cdr around) (list effective))) `(call-method ,effective ())))) (define-method-combination and (&optional (order ':most-specific-first)) ((around (:around)) (primary (and) :order order :required t)) (let ((effective `(effective-method (and (mapcar #'(lambda (m) `(call-method ,m ())) primary))))) (if around `(call-method ,(car around) ,(append (cdr around) (list effective))) `(call-method ,effective)))) ------- -------  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 11 Jan 88 21:03:38 EST Received: from MEAD.SCRC.Symbolics.COM ([128.81.41.234]) by SAIL.Stanford.EDU with TCP; 11 Jan 88 17:59:46 PST Received: from EUPHRATES.SCRC.Symbolics.COM by MEAD.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 126459; Mon 11-Jan-88 20:22:07 EST Date: Mon, 11 Jan 88 20:22 EST From: David A. Moon Subject: CALL-NEXT-METHOD To: Jon L White cc: common-lisp-object-system@SAIL.STANFORD.EDU In-Reply-To: <8801080232.AA19088@bhopal.lucid.com> Message-ID: <19880112012217.5.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Thu, 7 Jan 88 18:32:38 PST From: Jon L White re: funcall-qua In the smalltalk-like object system that Bob Kerns and I did for PDP10 MacLisp and NIL in 1980 (called the EXTEND feature), we actually included a primitive named SEND-AS. This function took just one more argument than SEND, and defeated the CLASS-OF lookup that a normal SEND would do; it supplied the starting point for method-lookup directly. You copied SEND-AS from the class system extant on the Lisp Machine at the time (I'm not complaining, that was a perfectly reasonable thing to do). Later on, SEND-AS was discredited as a bad idea that just turned programs into messes. At least, that was the experience of the Lisp Machine folks. I realize that with multi-methods and generic functions, the syntax for such a thing would be tricker -- maybe not even workable at all. But the actual use of SEND-AS was for "delegation"; and if that is the intended use that Kempf and Gabriel have in mind, then perhaps a more limited extension is all that is needed. Let me be very clear: I don't think the problem with SEND-AS is the syntax. I think the problem is that it is a way to name a function that is different from the normal way to name functions. Instead of SEND-AS, I prefer to say that if two methods have a subroutine in common, that subroutine should be given a name with DEFUN in the normal way and then they both should call it. In that old class system, and in all versions of Flavors I am aware of, the body of a method can do things that the body of a function can't, such as reference instance variables, which is the argument for having a special way to name subroutines of methods that is different from DEFUN. CLOS has fixed that. I believe that no extension to CALL-NEXT-METHOD is desirable.  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 11 Jan 88 19:54:18 EST Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 11 Jan 88 16:52:15 PST Received: from Semillon.ms by ArpaGateway.ms ; 11 JAN 88 16:06:12 PST Date: Mon, 11 Jan 88 16:05 PST From: Gregor.pa@Xerox.COM Subject: call-method proposal To: common-lisp-object-system@SAIL.STANFORD.EDU Fcc: BD:>Gregor>mail>outgoing-mail-1.text Message-ID: <880111160509.2.GREGOR@SPIFF.parc.xerox.com> Line-fold: no I spent some time thinking about how to solve the problem with make-method-call and concluded that make-method-call was a really complex little bugger. I have come up with a mechanism I believe is simpler, on first examination it appears to be missing the single method optimization but I believe that can be fixed quite easily. This description is not entirely adequate, but I hope its enough to convey the flavor of this proposal. This proposal uses two lexical macros, CALL-METHOD and EFFECTIVE-METHOD. These macros are lexically bound within the scope of an effective method body. That means that the body of define-method-combination is allowed to return code that uses these macros. Code walkers can understand these macros quite easily, I believe their semantics is also easier for programmers to understand. The differences between this and make-method-call in the spec are: - these are lexical macros - the functionality of automatically converting lists to combined methods provided by make-method-call is not provided by call-method. Instead, the effective method lexical macro must be used to declare that a form is itself an effective method being used in the call-next-method list. - call-method accepts two required arguments. The method to call is the first argument. The next methods accesible from that method is the second argument. - support for :operation and :identity-with-one-argument is missing. I believe this makes things simpler. I also believe we can get that optimization back quite easily. The biggest difference is that I find this conceptually simpler to understand. When I see call-method, I don't have to think about the three different forms the first argument to make-method-call can have, I know the first argument must be a method. I know the second argument must be a list of methods or effective-method forms. Here are implementations of standard and and method combination written using this mechanism. I have read them over, I believe they are right, but I don't have an implementation of this so I can't be sure. (define-method-combination standard () ((around (:around)) (before (:before)) (primary () :required t) (after (:after))) (let ((effective ;; This is the real method that gets run once all of the ;; :around methods have call-next-method'ed to get to it. `(effective-method (progn ,@(mapcar #'(lambda (m) `(call-method ,m ())) before)) (call-method ,(car primary) ,(cdr primary)) (progn ,@(mapcar #'(lambda (m) `(call-method ,m ())) after))))) (if around `(call-method ,(car around) ,(append (cdr around) (list effective))) `(call-method ,effective ())))) (define-method-combination and (&optional (order ':most-specific-first)) ((around (:around)) (primary (and) :order order :required t)) (let ((effective `(effective-method (and (mapcar #'(lambda (m) `(call-method ,m ())) primary))))) (if around `(call-method ,(car around) ,(append (cdr around) (list effective))) `(call-method ,effective)))) -------  Received: from Xerox.COM (TCP 1500006350) by AI.AI.MIT.EDU 11 Jan 88 17:42:49 EST Received: from Semillon.ms by ArpaGateway.ms ; 11 JAN 88 14:31:09 PST Date: Mon, 11 Jan 88 14:26 PST From: Gregor.pa@Xerox.COM Subject: new version of PCL To: CommonLoops.pa@Xerox.COM Fcc: BD:>Gregor>mail>outgoing-mail-1.text Message-ID: <880111142649.1.GREGOR@SPIFF.parc.xerox.com> Line-fold: no There is a new version of PCL on parcvax.xerox.com. This is a BETA TEST VERSION only. This version includes standard method combination. This will make it possible to use :before and :after methods with this version. This version also has a faster implementation of call-next-method, but there are some known problems with it. This BETA TEST VERSION runs in Symbolics, Lucid, Franz and Coral Common Lisps only. Subsequent releases will run in all the rest of the Common Lisps. The primary purpose of this release is to get some initial feedback from people who want to use standard method combination. See the notes.text file for more information. Gregor -------  Received: from Xerox.COM (TCP 1500006350) by AI.AI.MIT.EDU 8 Jan 88 18:23:46 EST Received: from Concord.ms by ArpaGateway.ms ; 08 JAN 88 15:11:05 PST Return-Path: Redistributed: commonloops.pa Received: from Sun.COM by Xerox.COM ; 08 JAN 88 15:09:32 PST Received: from suntoo.sun.com (suntoo-bb.sun.com) by Sun.COM (4.0/SMI-3.2) id AA13192; Fri, 8 Jan 88 14:45:24 PST Received: by suntoo.sun.com (3.2/SMI-3.2) id AA10829; Fri, 8 Jan 88 14:47:35 PST Received: by sunpitt.uucp (3.2/SMI-2.0) id AA02610; Fri, 8 Jan 88 16:27:54 EST Received: from psilocybin.sun.com by eti.com (3.2/SMI-3.2) id AA16439; Fri, 8 Jan 88 16:29:30 EST Received: by psilocybin.sun.com (3.2/SMI-3.2) id AA03774; Fri, 8 Jan 88 16:30:09 EST Date: Fri, 8 Jan 88 16:30:09 EST From: sunpitt!eti!psilocybin!rick@Sun.COM (Rick Busdiecker) Message-Id: <8801082130.AA03774@psilocybin.sun.com> To: sunpitt!sun!xerox.com!commonloops.pa@Sun.COM Subject: lambda congruency bug If I make a file containing the following forms . . . (in-package "ZAP" :use '("LISP" "CLOS")) (defclass foo () ()) (defclass bar (foo) ()) (defmethod baz ((foo foo)) t) (defmethod baz ((bar bar)) nil) (setf f (make-instance 'foo)) (setf b (make-instance 'bar)) (defmethod baz ((bar bar) &optional (quux t)) :quack) (print (baz f)) (print (baz b t)) . . . I would expect an error at the second to last form because the last DEFMETHOD form should have caused the previously defined methods to go away, however in my environment (Sun/Lucid "Development Environment 2.1.1" with a PCL::*PCL-SYSTEM-DATE* of "8/27/87 August 27th, 1987" I get the following output when I load this file . . . > (load "clos-bogosity.lisp") ;;; Loading source file "clos-bogosity.lisp" t :quack #P"/usr2/rick/VIEWPORTS/clos-bogosity.lisp" > . . . which appears to indicate a bug. Rick Busdiecker Expert Technologies Incorporated sunpitt!eti!rick@sun.com or rfb@cs.cmu.edu  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 7 Jan 88 21:35:35 EST Received: from LABREA.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 7 Jan 88 18:35:38 PST Received: by labrea.stanford.edu; Thu, 7 Jan 88 18:35:42 PST Received: from bhopal.lucid.com by edsel id AA05075g; Thu, 7 Jan 88 18:30:15 PST Received: by bhopal id AA19088g; Thu, 7 Jan 88 18:32:38 PST Date: Thu, 7 Jan 88 18:32:38 PST From: Jon L White Message-Id: <8801080232.AA19088@bhopal.lucid.com> To: labrea!bobrow.pa%Xerox.COM@labrea.stanford.edu Cc: labrea!common-lisp-object-system%SAIL@labrea.stanford.edu In-Reply-To: Danny bobrow's message of 7 Jan 88 14:59 PST <880107-150044-7614@Xerox> Subject: CALL-NEXT-METHOD re: funcall-qua In the smalltalk-like object system that Bob Kerns and I did for PDP10 MacLisp and NIL in 1980 (called the EXTEND feature), we actually included a primitive named SEND-AS. This function took just one more argument than SEND, and defeated the CLASS-OF lookup that a normal SEND would do; it supplied the starting point for method-lookup directly. I realize that with multi-methods and generic functions, the syntax for such a thing would be tricker -- maybe not even workable at all. But the actual use of SEND-AS was for "delegation"; and if that is the intended use that Kempf and Gabriel have in mind, then perhaps a more limited extension is all that is needed. -- JonL -- P.S.: R.I.P. EXTEND. It had multiple inheritance, but no method combination. The first flavors implemetations for NIL were built on top of it, and another non-flavor system that some MacSyma'ers wanted to play with also went "on top" of it. But by 1983 there was a "rush to judgement" in favor of FLAVORS; and KMP in particular helped discourage further use by excising the documentation out of the revised MacLisp manual. But the hooks for it are still in there, in about 30 primitive functions like EQUAL, COPY, PURCOPY (used by compiled-code loader) etc.  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 7 Jan 88 19:54:52 EST Date: 07 Jan 88 1652 PST From: Dick Gabriel Subject: Chapter 3 and the Cambridge Meeting To: common-lisp-object-system@SAIL.Stanford.EDU Here is a brief summary of what I think are the important points of my feelings about chapter 3, some of which were expressed poorly in Cambridge last month: 1. I believe a specification that is mute on the topics covered in chapter 3 is not acceptable. 2. I believe that the material that Danny and Gregor put together for our meeting is acceptable (with the problems we discussed in Cambridge resolved) if there is a careful statement about what degree of alterations the meta-object procotol is able to achieve. I think we saw enough variations on object-oriented programming in Cambridge to see that it is possibly unrealistic to expect to completely parameterize the meta-object level while achieving expressibility of (possibly unforseen) optimizations. However, there is a degree of variability that we can achieve with the current level of protocol, which I believe is necessary to present. 3. I want to make sure that we have a reasonable version of chapters 1 and 2 to present to X3J13 for the next meeting, which is why I insisted we spend the 3 hours getting it out of the way in Cambridge before the Chapter 3 discussion. I expect to have Moon's comments incorporated into Chapter 1 by the end of mext week (2 writing projects are ahead of it on the queue), and I will place it out on SAIL at that time. 4. I liked Danny and Gregor's proposed new outline reasonably well. My only question was whether some of the class-centered operations really were class-specific or could be generalized to instances - for example, propagate-class-update and update-class-locally. I would also favor a reduced-ambition proposal that only revealed some important parts of the mechanism. -rpg-  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 7 Jan 88 18:02:59 EST Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 7 Jan 88 15:02:36 PST Received: from Cabernet.ms by ArpaGateway.ms ; 07 JAN 88 15:00:44 PST Date: 7 Jan 88 14:59 PST Sender: bobrow.pa@Xerox.COM From: Danny bobrow Subject: Re: CALL-NEXT-METHOD In-reply-to: Dick Gabriel 's message of 07 Jan 88 10:55 PST To: RPG@SAIL.Stanford.EDU cc: common-lisp-object-system@SAIL.Stanford.EDU Message-ID: <880107-150044-7614@Xerox> Jim Kempf would like to invoke a more general method but not specifically the next method via CALL-NEXT-METHOD. I hadn't understood that this is what Jim wanted. I thought it was a misunderstanding of what would happen with call-next-method. This could be done by invoking the generic function again if there were some way to tell CLASS-OF to consider that instances of class C1 are instances of a superclass C2 or if there were some linguistic means of indicating this at generic function invocation time. That is, if C2 is a superclass of C1 and I1 is an instance of C1, then one could invoke a more general method if you could specifiy that I1 should be considered a direct instance of C2 (assuming C2 is the correct level of generality). For instance, (defmethod f ((c c1)) 'c1) (defmethod f ((c c2)) 'c2) (setq i (make-instance 'c1)) (f i) => c1 (f (the c2 i)) => c2 However, CALL-NEXT-METHOD does not seem the proper mechanism for this. I agree. If we want to support this feature in the standard (Henry Lieberman has argued for a facility like this), I think we need a construct more like: (funcall-qua #'f (the c2 i)) where the funcall-qua is the responsible mechanism for interpreting construct like "the". danny  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 7 Jan 88 13:57:03 EST Date: 07 Jan 88 1055 PST From: Dick Gabriel Subject: CALL-NEXT-METHOD To: common-lisp-object-system@SAIL.Stanford.EDU Jim Kempf would like to invoke a more general method but not specifically the next method via CALL-NEXT-METHOD. This could be done by invoking the generic function again if there were some way to tell CLASS-OF to consider that instances of class C1 are instances of a superclass C2 or if there were some linguistic means of indicating this at generic function invocation time. That is, if C2 is a superclass of C1 and I1 is an instance of C1, then one could invoke a more general method if you could specifiy that I1 should be considered a direct instance of C2 (assuming C2 is the correct level of generality). For instance, (defmethod f ((c c1)) 'c1) (defmethod f ((c c2)) 'c2) (setq i (make-instance 'c1)) (f i) => c1 (f (the c2 i)) => c2 However, CALL-NEXT-METHOD does not seem the proper mechanism for this. -rpg-  Received: from Xerox.COM (TCP 1500006350) by AI.AI.MIT.EDU 7 Jan 88 10:47:26 EST Received: from Cabernet.ms by ArpaGateway.ms ; 07 JAN 88 07:41:14 PST Return-Path: Redistributed: commonloops.pa Received: from ohm.ece.cmu.edu by Xerox.COM ; 07 JAN 88 07:39:25 PST Received: by ohm.ece.cmu.edu (5.51/5.17) id AA08268; Thu, 7 Jan 88 10:39:27 EST Date: Thu, 7 Jan 88 10:39:27 EST From: James Daniell Message-Id: <8801071539.AA08268@ohm.ece.cmu.edu> To: commonloops.pa@Xerox.COM Subject: Inspecting Common Loops with Lucid I am interested in finding out if a good Common Loops inspection routine exists that works with Lucid Common Lisp (preferably on a vax). If you or anyone you know has some spare code that needs a good home, I would appreciate the pointer. Jim Daniell (daniell@ohm.ece.cmu.edu)  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 6 Jan 88 16:13:38 EST Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 6 Jan 88 13:13:05 PST Received: from Cabernet.ms by ArpaGateway.ms ; 06 JAN 88 13:13:10 PST Date: 6 Jan 88 13:12 PST Sender: bobrow.pa@Xerox.COM From: Danny bobrow Subject: Re: New Specializers For CLOS In-reply-to: kempf%hplabsz@hplabs.HP.COM's message of Mon, 28 Dec 87 11:38:45 MST To: kempf%hplabsz@hplabs.HP.COM cc: Bobrow.pa@Xerox.COM, common-lisp-object-system@SAIL.STANFORD.EDU Message-ID: <880106-131310-5662@Xerox> > Proposal: > Add a specializer form > (metaclass ) > A method with such a specializer would be applicable if the metaclass of the > object bound to the argument is of type specified by . > Proposal: > Add a specializer > (subclass ) > A method with a subclass specializer on an argument is applicable if the > argument is of type and is a subtype of the given class. jak says: The outlined problems are largely in Chapter 3 and the suggested solution will impact Chapters 1 & 2 as well. It might be better to look for a solution which does not impact Chapters 1 & 2, to avoid having to retrofit the changes. Since one of the characteristics of these new specializers outlined in the proposal was that all methods on a generic function must agree on these new specializers (i.e. either have them or the regular set, but not both), a new class of generic function is suggested and, with it, perhaps a set of associated macros (DEFINE-METACLASS-METHOD ?) for conveniently defining the methods. This can't be the case since you can have these kinds of specializers mixed with ordinary specializers e.g. (defmethod slot-value ((obj (metaclass standard-class))(name (eql 'foo))) ...) The most compelling example for the "metaclass" specializer that we have come up with is slot-value; but slot-value-using-class allows specialization on either/both the metaclass and class. This can be important in some cases. Here is a simple example. (defmethod slot-value-using-class ((class standard-class) (object monitored-object) slot-name) (wait-until-object-is-not-write-locked object) (call-next-method)) Thus I think it is useful to continue to have slot-value-using-class. In this case, and because the new specializers affect chapters 1 and 2, I would say we should leave these out, and keep in class-prototype and -using-class  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 5 Jan 88 16:01:00 EST Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 5 Jan 88 12:56:16 PST Received: from Semillon.ms by ArpaGateway.ms ; 05 JAN 88 12:56:43 PST Date: Tue, 5 Jan 88 12:54 PST From: Gregor.pa@Xerox.COM Subject: Standardizing the macroexpansion of make-method-call To: David A. Moon cc: Common-Lisp-Object-System@SAIL.STANFORD.EDU Fcc: BD:>Gregor>mail>outgoing-mail-1.text In-Reply-To: <19871229034700.8.MOON@EUPHRATES.SCRC.Symbolics.COM> Message-ID: <880105125449.1.GREGOR@SPIFF.parc.xerox.com> Line-fold: no Date: Mon, 28 Dec 87 22:47 EST From: David A. Moon Gregor pointed out that in order to be able to analyze effective method forms, which is something we claim can be done, it is necessary to be able to recognize the macroexpansion of MAKE-METHOD-CALL. This is true. This message is a fairly long discussion of the issues. You needn't include all of it in replies. I see three possible approaches: Offhand, I prefer approach 3 although the gruesomeness of the examples is pretty frightening. I think I want to think about this a bit more. The purpose of this message is to say that we also need some facility which lets the user call a random function on the same arguments the generic function received. This facility might be called MAKE-FUNCTION-CALL or FUNCTION-CALL or hopefully we could come up with a better name. We have seen several examples of people who want a method combination type which performs some specific behavior as part of the combined method but that behavior needs access to the arguments to the generic function. Inventing this might even lead us out of the mess we have with make-method-call because it might force us to come up with a real abstraction for 'captured calls' and for 'access to the generic function arguments'. More on this later if I can think of anything, I sent this now hoping it might help someone else think of something. -------  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 5 Jan 88 15:49:03 EST Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 5 Jan 88 12:43:32 PST Received: from Semillon.ms by ArpaGateway.ms ; 05 JAN 88 12:43:46 PST Date: Tue, 5 Jan 88 12:41 PST From: Gregor.pa@Xerox.COM Subject: New Class Organization for CLOS Kernel To: David A. Moon cc: common-lisp-object-system@SAIL.STANFORD.EDU Fcc: BD:>Gregor>mail>outgoing-mail-1.text In-Reply-To: <19871228205157.8.MOON@EUPHRATES.SCRC.Symbolics.COM> Message-ID: <880105124145.0.GREGOR@SPIFF.parc.xerox.com> Line-fold: no Date: Mon, 28 Dec 87 15:51 EST From: David A. Moon Date: 23 Dec 87 14:34 PST From: Danny Bobrow The following is my understanding of what we agreed to in Cambridge. Agreed, except for some problems with the class relationships: standard-accessor-method and standard-method should be disjoint for the same reason that standard-class, built-in-class, and structure-class are now disjoint. The principle underlying this is that we need to distinguish between the class that is used by default by the various macros, and the class from which other classes inherit. This allows a programmer defining a new method to choose whether this method is to be applicable to the default kind of object that the macros make or to all objects (of the relevant general kind). For example, standard-class is distinct from structure-class, and they both inherit from class, so that a programmer can put a method on standard-class to affect classes made by defclass, or on class to affect all classes. Probably this principle should be in your list of principles. I agree with this principle, but I don't see why standard-accessor-method should be disjoint from standard-method. It seems to me that standard-accessor-method is a kind of method a lot like standard-method. It has qualifiers and specializers, it has a method function. It may also have some other information like slot-name or other implementation specific stuff but all in all it seems a lot like standard method. It definitely seems to be a specialization of standard-method. I guess my question is, given: (defclass method () ..) (defclass standard-method (method) ..) (defclass standard-accessor-method (standard-method) ..) What methods could you want to put on standard-method that you wouldn't want standard-accessor-method to inherit. It seems to me that for any cases like that what you really want to do is make another subclass of either standard-method or method and put your methods there. It's okay for funcallable-standard-class to be a subclass of standard-class if we really mean that funcallable-standard-class is a specialization of the class you get with defclass, not something distinct that wants to inherit some of the same methods. I haven't seen a written description of funcallable-standard-class yet, but my understanding is that that is the nature of it. That's the nature of it. -------  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 4 Jan 88 18:17:16 EST Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 4 Jan 88 15:10:47 PST Received: from relay2.cs.net by RELAY.CS.NET id af01627; 4 Jan 88 17:31 EST Received: from csc.ti.com by RELAY.CS.NET id ax08411; 4 Jan 88 17:14 EST Received: from Jenner by tilde id AA01592; Mon, 4 Jan 88 15:39:32 CST Message-Id: <2777319424-9830357@Jenner> Date: Mon, 4 Jan 88 15:37:04 CST From: Patrick H Dussud To: common-lisp-object-system@SAIL.STANFORD.EDU Subject: Re: with-accessors In-Reply-To: Msg of Mon, 28 Dec 87 12:40 PST from Gregor.pa@xerox.com Date: Mon, 28 Dec 87 12:40 PST From: Gregor.pa@xerox.com Subject: with-accessors Date: Mon, 28 Dec 87 14:29 EST From: David A. Moon Date: Tue, 22 Dec 87 18:18 PST From: Gregor.pa@Xerox.COM (with-accessors ((x position-x) (y position-y)) p1 (setq x y)) I like this. I think we should put it in. Is (with-accessors (x y) p1 (setq x y)) allowed for consistency with with-slots? It would only work for classes that use the naming convention that accessor function names are the same as slot names, which might mean that its existence leads to confusion. Hence I suggest that we should not allow this abbreviated syntax. I agree that we should not allow this abbreviated syntax. I meant to address that specifically in my message but I seem to have forgotten. ------- That sounds good. Patrick.  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 30 Dec 87 12:32:01 EST Received: from [128.81.41.234] by SAIL.STANFORD.EDU with TCP; 30 Dec 87 09:23:53 PST Received: from EUPHRATES.SCRC.Symbolics.COM by MEAD.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 123561; Tue 29-Dec-87 20:09:18 EST Date: Tue, 29 Dec 87 20:08 EST From: David A. Moon Subject: Comments on Chapter 2 To: Common-Lisp-Object-System@SAIL.STANFORD.EDU Message-ID: <19871230010835.1.MOON@EUPHRATES.SCRC.Symbolics.COM> Comments on Chapter 2, draft dated Nov 11 1987 15:57 (when I checked yesterday, this was still the most recent on SAIL). This is a mixture of editorial comments and several comments on the substance of the specification. I apologize for not having time to separate them. 2-3: It looks like this is the place for the disclaimer that says the current version of chapter 2 doesn't try to be careful about the division of labor between the generic functions it describes and their methods, and that this will be revisited and revised when chapter 3 is finished. 2-3: The method signature example has &opt where it should have &optional. The description implies that M is the name of a method, whatever that is, but examination of method signatures in the text shows that M is really the name of a generic function. Also in all the method signatures, the text in brackets naming the kind of method should be flush right. 2-5: cboundp, class-name, cmakunbound, and symbol-class aren't really general Common Lisp support tools. I would move them to the "functions underlying" table. 2-6: I find this notation inordinately confusing, but I don't have any suggestions for improving it. I could suggest getting rid of the extensions and using only standard BNF. That would mean that we would not be able to specify in the BNF syntax restrictions that an item can appear only once; that would have to be left to the text. If people feel that editorially it's worth having that information in the BNF and that therefore we need this idiosyncratic notation, I can live with it. 2-8 add-method arguments: I don't understand the reference to a generic function not having a lambda-list. How is that possible? 2-9 call-next-method second dash bullet: "and there is no applicable primary method" should be "and there are no more primary methods" or words to that effect. Actually I'm not sure if these bullets are really needed here, or if it would be better to leave all that stuff up to chapter 1. 2-11 cboundp arguments: I'm not sure what "the null environment" this refers to is. Since chapter 2 isn't really trying to explain how these environments work (I assume we're going to do that in chapter 3?) maybe it would be best not to say anything more than the analogy to &environment in macros. 2-12 change-class arguments last sentence: (symbol-class symbol) should be (symbol-class new-class) since the method signature uses new-class as the parameter name. 2-15 class-changed: Since users can write methods for this, and this is not a meta object generic function, we can't get away here with obscuring the division of labor between the generic function and its methods. This is explained pretty well in chapter 1 now, so the explanation of what the standard primary method can be relied upon by other methods to do can be lifted from there. 2-15 class-changed purpose: "evalued" should be "evaluated". 2-18 class-of purpose and values: There is a terminology problem here. An object is an instance of only one class, we can't speak of the most specific class of which the object is an instance. The terminology I prefer is that an object "is a member" of the class of which it "is an instance" and also "is a member" of each superclass of that class. This comes from the use of "member" with types. I don't think chapter 1 has introduced that term, however; perhaps it ought to. The easiest way to fix the writeup of class-of is simply to say "The function class-of returns the class of which the given object is an instance." It's for reasons like this that we need a glossary. Is the glossary file on SAIL up to date? We should include it in the X3J13 88-002 document. 2-19 cmakunbound: see comment on 2-11 2-21 defclass syntax: generic-function-name is a bit trickier once :writer is added here. For :reader and :accessor generic-function-name is a symbol, but for :writer it's either a symbol or a list (setf symbol). I suggest calling the argument to :reader and :accessor reader-function-name and calling the argument to :writer writer-function-name. The next page contains italicized words with no obvious referent other than this syntax table, so don't forget to keep the next page consistent with any changed names. 2-23 defclass :initarg slot option: This paragraph refers twice to a ":initform argument". I think this is a typo for ":initform slot option." 2-23 defclass :initform and :default-initargs: The dynamic environment of evaluation is the same for both of these, but the wording of the description differs. I like the wording used with :default-initargs better and I suggest that :initform be changed. 2-23 defclass :default-initargs option: An initialization argument name isn't allowed to appear more than once in a single :default-initargs option, delete the reference to that (second to last sentence). 2-24, 1-15: 2-24 defines exactly when defclass redefines a class, in terms of the "proper name" concept. 1-15 is vague on this. We should make sure the two chapters agree. What 2-24 says is what we want, right? Editorial comment: the wording on 2-24 isn't so hot, because it's a run-on sentence and because the word "class" appears enough times to make my head spin. 2-24: With the introduction of :writer, occurrences of "accessor" on this page should probably be "writer", since :accessor is now understood as an abbreviation for :reader plus :writer. 2-26: I don't understand why method-specifier is a separate nonterminal. With method-description, -specifier, and -qualifier, things get confusing. Why not make method-description include the complete syntax directly? method-specifier isn't referenced anywhere else. 2-27 last line: "proclain proclamation" should be "declaration proclamation", "declaration" in boldface. 2-29 first line: This says that removing a :method from a defgeneric and re-evaluating the defgeneric does not remove the old method. While that's a good default behavior, we should make sure not to rule out smart program development environments that know better what is going on and remove the old method in cases where the user thinks that's appropriate. In the Error Terminology introduced in chapter 1, implementations should be free to extend this. Redefinition is a program development environment issue, not really a language issue, anyway. 2-30 define-method-combination syntax: I guess this should be using that double-bracket notation I said I didn't like for short-form-option and for long-form-option. None of the options is allowed to appear multiple times. 2-33 last line: Delete the word "argument", it's confusing to call the doc-string an argument. 2-35, 2-36: The examples headed ";A simple way to try several methods until one returns non-nil" are actually examples of trying several methods until one returns nil. In addition, it's confusing that these are 'and' method combination just like the examples on 2-34. "and" should be changed to "or" throughout the four examples on pp. 2-35 and 2-36. 2-36 last example: It's probably better style to use length rather than list-length. 2-37 defmethod purpose: Starting off the purpose discussion with lambda-list congruence seems odd. Perhaps that paragraph should be moved to Remarks. 2-38 defmethod second remarks paragraph: This implies that equality of parameter specializers is defined by the Lisp EQUAL function, but that can't really be true. In an EQL parameter specializer, the objects are compared with EQL, not EQUAL. There is no Lisp function that directly implements the test for equality of parameter specializers. Of course the function is very easy to write. I would just delete "(equal)" here. 2-40 describe purpose and method signatures: Requiring a method for the class t is wrong. What CLOS actually requires is that for any object that exists, there is always an applicable method. The language of method signatures doesn't provide any way to say this, so I think we should simply say that there is a standard-object method, and there are enough other methods to ensure that there is always an applicable method. Note that if there were a method on the class t, it would not be able to describe anything about its argument, unless it started with a type dispatch, since it could not know anything about the type of the argument. 2-42 second bullet: Implementations should be allowed to extend the set of symbols acceptable as the second argument to documentation, in line with the error terminology outlined in chapter 1. 2-43 ensure-generic-function second arguments paragraph: "and and" 2-45 generic-flet syntax: In the list of suggested changes he handed out two years ago, Guy Steele suggested allowing declarations before the body of flet, labels, and macrolet. The cleanup committee doesn't seem to have picked up on this (I checked the latest issue status list I had, which is only a month old). If FLET and LABELS change, of course GENERIC-FLET and GENERIC-LABELS should change too, so we need to stay on top of this. If I get a chance I'll send a cleanup reminder. 2-46, 2-47, 2-49: See comment on 2-26. 2-47 generic-function syntax: This takes the same restricted lambda-list as defgeneric, generic-flet, etc. so the syntax for that should be copied here. Alternatively the cross-reference under Arguments could be updated, but that isn't the style in which generic-flet was done. 2-49 generic-labels syntax: See comment on 2-45. 2-51 get-method remarks: See comment on 2-38. Qualifiers are compared with EQUAL, but specializers have to be compared a different way. 2-52, 2-53, 2-54 initialize-instance: The stuff about initialize-instance methods on various meta object classes should be moved into chapter 3. Also it contains some errors, for instance the methods are :after methods, not primary methods, I'm fairly sure. 2-54 initialize-instance values: I think the value should be a don't care, since that's what 1-43 implies. Why run the risk of someone writing a method that returns the wrong value? 2-56 invalid-method-error: This function should not be generic. It was not generic in the last version I reviewed; I don't know how genericness accidentally crept in. Once the genericness and method signature are removed, the rest of the writeup is okay. 2-57 make-instance: The method signatures for standard-method and standard-generic-function are mistakes and should be removed. The stuff about making instances of these classes in the remarks section should be moved to chapter 3. By the way, I believe that the initialization arguments for a class should be documented with the class, rather than lumping all classes together under initialize-instance and make-instance. Right now chapter 2 doesn't document any classes, but certainly chapter 3 will include pages for several classes. 2-58 make-instance first remarks paragraph: boring. 2-59 make-instances-obsolete second purpose paragraph: Cross out "newly-redefined"; it might not be if the user called the function explicitly. In the last sentence, change "may" to "will"; once make-instances-obsolete has been called, it is guaranteed that update-instance-structure will be called on each instance some time before the next time a slot value of that instance is accessed. 2-59 make-instances-obsolete second arguments paragraph: Cross out "symbol and". 2-65 no-applicable-method: I'm not sure that the default method should be on standard-generic-function, rather than generic-function or t. Why would we want the default method to be on a more specialized class? 2-66 print-object: See comment on 2-40. 2-68 remove-method method signatures: I don't think the second parameter should be specialized. I think there are a few other generic functions in here whose method signatures are overzealously specialized. Only chapter 3 knows for sure, of course, but it seems to me that most of these should accept any value for arguments other than the main specialized one. 2-72 slot-missing method signatures: As on 2-65, shouldn't the default method be on a less specialized class? 2-73 slot-unbound method signatures: see comment on 2-72 2-74 slot-value second remarks paragraph: The fourth argument to slot-missing in this case is the symbol setf, not the list (setf slot-value). 2-75 symbol-class last arguments paragraph: see comment on 2-11 2-76 symbol-macrolet second remarks paragraph: clarify that symbol-macrolet can be shadowed by let. In other words, symbol-macrolet only substitutes for occurrences of -symbol- that would be in the scope of a lexical binding of -symbol- surrounding the body. Also symbol-macrolet does not substitute for occurrences of a -symbol- inside an -expansion-. Illustrative examples: (symbol-macrolet ((x 'foo)) (list x (let ((x 'bar)) x))) => (foo bar), not (foo foo) and ==> (list 'foo (let ((x 'bar)) x)), not (let 'foo (let (('foo 'bar)) 'foo)). (symbol-macrolet ((x (1+ x))) (print x)) ==> (print (1+ x)), not (print (1+ (1+ (1+ .... 2-77 update-instance-structure second purpose paragraph: Since users can write methods for this, and this is not a meta object generic function, we can't get away here with obscuring the division of labor between the generic function and its methods. This is explained pretty well in chapter 1 now, so the explanation of what the standard primary method can be relied upon by other methods to do can be lifted from there. Also change "evalued" to "evaluated". 2-77 update-instance-structure: change "deleted-slots" to "discarded-slots" to be consistent with 1-16. Slots that used to be local but are now shared are included in the discarded-slots. 2-78 update-instance-structure example: In two places in the first defmethod, "new" should be "pos". Also the comment was erroneously copied from a class-changed example and a new comment is needed saying something like transform the coordinates to polar and store into the new slots. Use of with-slots in the example needs to be updated to the new with-slots syntax. Also the indentation could be standardized, some things are indented one space where the style used everywhere else would have them indented two spaces. 2-80: See comment on 2-26  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 29 Dec 87 17:44:37 EST Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 29 Dec 87 14:35:19 PST Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 311848; Tue 29-Dec-87 17:27:38 EST Date: Tue, 29 Dec 87 17:27 EST From: David A. Moon Subject: Method Combination Objects To: Common-Lisp-Object-System@SAIL.STANFORD.EDU Supersedes: <19871229180330.0.MOON@EUPHRATES.SCRC.Symbolics.COM> Comments: I forgot to include the describe-method-concisely generic function. Message-ID: <19871229222722.4.MOON@EUPHRATES.SCRC.Symbolics.COM> At the Cambridge meeting I promised to mail this out. Currently method combination types are represented in a kludgey fashion, as a pair of objects: a symbol that names the type, and a list of options. It would be better to do this in an object-oriented way, the same as everything else. Here is a proposal for how it would look. Method combination objects are meta objects, so this is all chapter 3 material. There are a couple of minor modifications to chapters 1 and 2, which I will note at the end. Method Combination Naming Layer This layer is concerned with mapping method combination type names, as seen in the :method-combination option to defgeneric, to method combination objects. (method-combination-maker name) => function This function maps the name of a method combination type into a function that accepts the options seen in the :method-combination option to defgeneric and returns the method combination object. method-combination-maker signals an error if -name- is unrecognized. -function- should signal an error if the options are unrecognized. (apply (method-combination-maker name) options) is how a method combination name and options are converted into an object. (setf (method-combination-maker name) function) is how a method combination type is defined. (setf (method-combination-maker name) nil) is how a method combination type is undefined. (Or we could have a separate function for this.) (method-combination-name method-combination) => symbol (method-combination-options method-combination) => list These two generic functions perform the inverse mapping. Why we have method-combination-maker instead of just using make-instance: - The names of method combination types that we have chosen are not appropriate as names of classes. These names were chosen on the assumption that they would be in their own namespace. Thus either we have to have a new function to map from the method combination name to the class object, or we have to change all the names. Changing all the names would make the programmer interface awkward. - The options seen in the :method-combination option to defgeneric are defined by a lambda-list in define-method-combination, rather than being just keyword arguments. Hence it makes sense to receive these options with a function. We could change these options into keywords suitable for use as initialization arguments, but this might make the programmer interface awkward. If we just passed the whole list of options as one :options initialization argument, we wouldn't be exploiting any Lisp mechanism to parse the options. - Several method combination types might share a single class. - A single method combination type name might map into several different classes, depending on the options. - A function returned by method-combination-maker might return the same object each time it is called, instead of making a new object. For these reasons it seems better to interpose an extra layer between make-instance and the name and options of a method combination type. Method Combination Object Layer method-combination This class is a superclass of all classes of method combination. standard-method-combination This class is the class of the method combination object used by default when :method-combination is not specified. Other implementation-dependent subclasses of method-combination exist. For example, all invocations of the short form of define-method-combination probably use one class, and each invocation of the long form of define-method-combination probably defines a new class which has a superclass in common with standard-method-combination. CLOS does not specify how many of these classes there are nor what their names are. (compute-effective-method generic-function method-list method-combination) => effective-method-form This generic function performs part 3 of the determination of the effective method. define-method-combination works through methods that specialize the third parameter. (describe-method-concisely generic-function method method-combination) This generic function prints a description of the method onto *standard-output*. The value returned is ignored. define-method-combination defines a method for describe-method-concisely that uses the :description option of the long form to control what it prints. Other generic functions specialized by method combinations are not currently defined by CLOS, but program development environments are likely to have some. A generic function object records a method combination object, rather than the name and options of a method combination type. This changes the initialization arguments and structural access functions for generic functions from what is in chapter 3 now. defgeneric calls method-combination-maker before it calls ensure-generic-function. Example The short form of define-method-combination could have been defined as follows: (defclass short-form-method-combination (method-combination) ((name :initarg name :reader method-combination-name) (order :initarg order) (documentation :initarg documentation :reader documentation) (operator :initarg operator) (identity-with-one-argument :initarg identity-with-one-argument))) (defmethod method-combination-options ((mc short-form-method-combination)) (list (slot-value mc 'order))) (defmethod compute-effective-method (generic-function methods (mc short-form-method-combination)) (let ((primary-methods (remove (list (slot-value mc 'name)) methods :key #'method-qualifier :test-not #'equal)) (around-methods (remove '(:around) methods :key #'method-qualifier :test-not #'equal))) (when (eq (slot-value mc 'order) ':most-specific-last) (setq primary-methods (reverse primary-methods))) (dolist (method (set-difference methods (union primary-methods around-methods))) (invalid-method-error method "The qualifiers of ~S, ~:S, are not ~S or ~S" method (method-qualifiers method) (list (slot-value mc 'name)) '(:around))) (make-method-call `(,@around-methods ,(make-method-call primary-methods :operator (slot-value mc 'operator) :identity-with-one-argument (slot-value mc 'identity-with-one-argument))) :operator :call-next-method))) (defmethod describe-method-concisely (generic-function method (method-combination short-form-method-combination)) (declare (ignore generic-function)) (write-string (string-downcase (string (first (method-qualifiers method)))))) (defmacro define-method-combination (name &key (documentation nil) (operator name) (identity-with-one-argument nil)) `(setf (method-combination-maker ',name) #'(lambda (&optional (order ':most-specific-first)) (make-instance 'short-form-method-combination 'name ',name 'order order 'documentation ',documentation 'operator ',operator 'identity-with-one-argument ',identity-with-one-argument)))) Example of Defining a Method Combination Type via Inheritance ;This example defines a method combination type that is similar ;to standard method combination, except that it also allows :or ;methods. The :or methods are executed after the :before methods, ;before the :after methods, inside the :around methods, and before ;the primary method. The primary method is only called if all the ;:or methods return nil; if any :or method returns non-nil, its ;value becomes the value of the generic function (or the value ;returned by call-next-method in the least specific :around method) ;in place of the values of the most specific primary method. ;This assumes approach 2 or 3 to making effective method code ;analyzable, and assumes one particular code analysis tool, whose ;details I will not try to explain here. ;Those assumptions are not critical. ;I'm assuming we don't want to try to extend the define-method-combination ;macro so that it could exploit inheritance. Instead I will ;define the example directly in terms of the next layer down. (defclass standard-method-combination-with-or (standard-method-combination) ()) (setf (method-combination-maker 'standard-with-or) #'(lambda () (make-instance 'standard-method-combination-with-or))) ;This uses call-next-method to get the effective method in the absence ;of any :or methods, then it modifies the effective method form to ;incorporate the :or methods in an OR special form wrapped around the ;call to the most specific primary method. (defmethod compute-effective-method (generic-function methods (mc standard-method-combination-with-or)) (let ((or-methods (remove '(:or) methods :key #'method-qualifiers :test-not #'equal)) (other-methods (remove '(:or) methods :key #'method-qualifiers :test #'equal))) (lt:copyforms #'(lambda (subform kind usage) (declare (ignore usage)) (if (and (listp kind) (listp subform) (eq (first subform) 'method-call) (null (method-qualifiers (second subform)))) ;; Put or methods before primary method (values `(or ,@(mapcar #'(lambda (method) `(method-call ,method)) or-methods) ,subform) t) ;; Leave all other subforms of effective method alone subform)) (call-next-method generic-function other-methods mc)))) Modifications to Chapters 1 and 2 1-31: The arguments to compute-effective-method have been changed. 2-43: The value of the :method-combination argument to ensure-generic-function becomes a method combination object. Currently, the value of this argument isn't really documented at all.  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 29 Dec 87 17:44:33 EST Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 29 Dec 87 14:35:23 PST Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 311658; Tue 29-Dec-87 13:03:40 EST Date: Tue, 29 Dec 87 13:03 EST From: David A. Moon Subject: Method Combination Objects To: Common-Lisp-Object-System@SAIL.STANFORD.EDU Message-ID: <19871229180330.0.MOON@EUPHRATES.SCRC.Symbolics.COM> At the Cambridge meeting I promised to mail this out. Currently method combination types are represented in a kludgey fashion, as a pair of objects: a symbol that names the type, and a list of options. It would be better to do this in an object-oriented way, the same as everything else. Here is a proposal for how it would look. Method combination objects are meta objects, so this is all chapter 3 material. There are a couple of minor modifications to chapters 1 and 2, which I will note at the end. Method Combination Naming Layer This layer is concerned with mapping method combination type names, as seen in the :method-combination option to defgeneric, to method combination objects. (method-combination-maker name) => function This function maps the name of a method combination type into a function that accepts the options seen in the :method-combination option to defgeneric and returns the method combination object. method-combination-maker signals an error if -name- is unrecognized. -function- should signal an error if the options are unrecognized. (apply (method-combination-maker name) options) is how a method combination name and options are converted into an object. (setf (method-combination-maker name) function) is how a method combination type is defined. (setf (method-combination-maker name) nil) is how a method combination type is undefined. (Or we could have a separate function for this.) (method-combination-name method-combination) => symbol (method-combination-options method-combination) => list These two generic functions perform the inverse mapping. Why we have method-combination-maker instead of just using make-instance: - The names of method combination types that we have chosen are not appropriate as names of classes. These names were chosen on the assumption that they would be in their own namespace. Thus either we have to have a new function to map from the method combination name to the class object, or we have to change all the names. Changing all the names would make the programmer interface awkward. - The options seen in the :method-combination option to defgeneric are defined by a lambda-list in define-method-combination, rather than being just keyword arguments. Hence it makes sense to receive these options with a function. We could change these options into keywords suitable for use as initialization arguments, but this might make the programmer interface awkward. If we just passed the whole list of options as one :options initialization argument, we wouldn't be exploiting any Lisp mechanism to parse the options. - Several method combination types might share a single class. - A single method combination type name might map into several different classes, depending on the options. - A function returned by method-combination-maker might return the same object each time it is called, instead of making a new object. For these reasons it seems better to interpose an extra layer between make-instance and the name and options of a method combination type. Method Combination Object Layer method-combination This class is a superclass of all classes of method combination. standard-method-combination This class is the class of the method combination object used by default when :method-combination is not specified. Other implementation-dependent subclasses of method-combination exist. For example, all invocations of the short form of define-method-combination probably use one class, and each invocation of the long form of define-method-combination probably defines a new class which has a superclass in common with standard-method-combination. CLOS does not specify how many of these classes there are nor what their names are. (compute-effective-method generic-function method-list method-combination) => effective-method-form This generic function performs part 3 of the determination of the effective method. define-method-combination works through methods that specialize the third parameter. Other generic functions specialized by method combinations are not currently defined by CLOS, but program development environments are likely to have some. A generic function object records a method combination object, rather than the name and options of a method combination type. This changes the initialization arguments and structural access functions for generic functions from what is in chapter 3 now. defgeneric calls method-combination-maker before it calls ensure-generic-function. Example The short form of define-method-combination could have been defined as follows: (defclass short-form-method-combination (method-combination) ((name :initarg name :reader method-combination-name) (order :initarg order) (documentation :initarg documentation :reader documentation) (operator :initarg operator) (identity-with-one-argument :initarg identity-with-one-argument))) (defmethod method-combination-options ((mc short-form-method-combination)) (list (slot-value mc 'order))) (defmethod compute-effective-method (generic-function methods (mc short-form-method-combination)) (let ((primary-methods (remove (list (slot-value mc 'name)) methods :key #'method-qualifier :test-not #'equal)) (around-methods (remove '(:around) methods :key #'method-qualifier :test-not #'equal))) (when (eq (slot-value mc 'order) ':most-specific-last) (setq primary-methods (reverse primary-methods))) (dolist (method (set-difference methods (union primary-methods around-methods))) (invalid-method-error method "The qualifiers of ~S, ~:S, are not ~S or ~S" method (method-qualifiers method) (list (slot-value mc 'name)) '(:around))) (make-method-call `(,@around-methods ,(make-method-call primary-methods :operator (slot-value mc 'operator) :identity-with-one-argument (slot-value mc 'identity-with-one-argument))) :operator :call-next-method))) (defmacro define-method-combination (name &key (documentation nil) (operator name) (identity-with-one-argument nil)) `(setf (method-combination-maker ',name) #'(lambda (&optional (order ':most-specific-first)) (make-instance 'short-form-method-combination 'name ',name 'order order 'documentation ',documentation 'operator ',operator 'identity-with-one-argument ',identity-with-one-argument)))) Example of Defining a Method Combination Type via Inheritance ;This example defines a method combination type that is similar ;to standard method combination, except that it also allows :or ;methods. The :or methods are executed after the :before methods, ;before the :after methods, inside the :around methods, and before ;the primary method. The primary method is only called if all the ;:or methods return nil; if any :or method returns non-nil, its ;value becomes the value of the generic function (or the value ;returned by call-next-method in the least specific :around method) ;in place of the values of the most specific primary method. ;This assumes approach 2 or 3 to making effective method code ;analyzable, and assumes one particular code analysis tool, whose ;details I will not try to explain here. ;Those assumptions are not critical. ;I'm assuming we don't want to try to extend the define-method-combination ;macro so that it could exploit inheritance. Instead I will ;define the example directly in terms of the next layer down. (defclass standard-method-combination-with-or (standard-method-combination) ()) (setf (method-combination-maker 'standard-with-or) #'(lambda () (make-instance 'standard-method-combination-with-or))) ;This uses call-next-method to get the effective method in the absence ;of any :or methods, then it modifies the effective method form to ;incorporate the :or methods in an OR special form wrapped around the ;call to the most specific primary method. (defmethod compute-effective-method (generic-function methods (mc standard-method-combination-with-or)) (let ((or-methods (remove '(:or) methods :key #'method-qualifiers :test-not #'equal)) (other-methods (remove '(:or) methods :key #'method-qualifiers :test #'equal))) (lt:copyforms #'(lambda (subform kind usage) (declare (ignore usage)) (if (and (listp kind) (listp subform) (eq (first subform) 'method-call) (null (method-qualifiers (second subform)))) ;; Put or methods before primary method (values `(or ,@(mapcar #'(lambda (method) `(method-call ,method)) or-methods) ,subform) t) ;; Leave all other subforms of effective method alone subform)) (call-next-method generic-function other-methods mc)))) Modifications to Chapters 1 and 2 1-31: The arguments to compute-effective-method have been changed. 2-43: The value of the :method-combination argument to ensure-generic-function becomes a method combination object. Currently, the value of this argument isn't really documented at all.  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 28 Dec 87 22:51:21 EST Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 28 Dec 87 19:47:00 PST Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 311434; Mon 28-Dec-87 22:47:16 EST Date: Mon, 28 Dec 87 22:47 EST From: David A. Moon Subject: Standardizing the macroexpansion of make-method-call To: Common-Lisp-Object-System@SAIL.STANFORD.EDU Message-ID: <19871229034700.8.MOON@EUPHRATES.SCRC.Symbolics.COM> Gregor pointed out that in order to be able to analyze effective method forms, which is something we claim can be done, it is necessary to be able to recognize the macroexpansion of MAKE-METHOD-CALL. This is true. This message is a fairly long discussion of the issues. You needn't include all of it in replies. I see three possible approaches: (1) Leave MAKE-METHOD-CALL the way it is and add a new function METHOD-CALL-P. Given a form this returns the method it calls, or NIL if the form is not an invocation of a method. METHOD-CALL-P returns a second value which is an ordered list of the methods reachable by CALL-NEXT-METHOD when this method is called. If the first value is NIL the second value is also NIL. (2) Add a macro METHOD-CALL, which only expands correctly in the same special environment that MAKE-METHOD-CALL is documented to depend on. Define MAKE-METHOD-CALL to expand into METHOD-CALL. The syntax of METHOD-CALL is (METHOD-CALL method [:NEXT-METHODS (next-method*)]), i.e. if the :NEXT-METHODS option is present, it is a possibly empty ordered list of methods reachable by CALL-NEXT-METHOD. If the :NEXT-METHODS option is absent, CALL-NEXT-METHOD is not available in the method. (3) Add a macro METHOD-CALL, which only expands correctly in the same special environment that MAKE-METHOD-CALL is documented to depend on. Get rid of MAKE-METHOD-CALL and require writers of method combination procedures to generate METHOD-CALL forms directly. The advantage of approach 1 is that the structure of a method invocation form is completely up to the implementation. Also, the interpretation of an effective method form does not have to be dependent on an environment. By the way, this is what Flavors does, thus this is a use-tested approach. The advantage of approaches 2 and 3 is that MAKE-METHOD-CALL's special dynamic environment could be eliminated, in favor of wrapping a MACROLET of METHOD-CALL to an implementation-dependent definition around the effective method form, when actually compiling it. The advantage of approach 3 is that it leaves CLOS the simplest. The disadvantage of approach 3 is that MAKE-METHOD-CALL provides a bunch of convenience features that would now have to be done by hand. Approach 2 solves this at the cost of some evident redundancy. None of this deals with the fact that a thing reachable by CALL-NEXT-METHOD can be not only a regular method, but a grouping of before, primary, and after methods; currently this works by MAKE-METHOD-CALL accepting forms in place of methods and somehow translating them. In Flavors no formal method is required for this, but it sounds like CLOS is going to need an actual method object of some new class? Or can we get away with just returning a form as an element of the second value of METHOD-CALL-P (approach 1) or including a form as an element of the :NEXT-METHODS option (approaches 2&3)? We need to figure out the answers to those questions before we can proceed. Flavors used to use something like approach 3, and switched to approach 1 to speed up method combination. I haven't been able to reconstruct the full details of what happened (it was years ago), but if the efficiency concern there was not relevant to CLOS, I would prefer approach 2. To judge your opinion on approach 3, here are the examples from 2-34 through 2-36 rewritten in approach 3; consult your hardcopy for the originals. This is assuming we can just put a form where a method object belongs. ;;; Examples of the short form of define-method-combination (define-method-combination and :identity-with-one-argument t) (defmethod func and ((x class1) y) ...) ;;; The equivalent of this example in the long form is: (define-method-combination and (&optional (order ':most-specific-first)) ((around (:around)) (primary (and) :order order :required t)) (if around `(method-call ,(first around) :next-methods `(,@(rest around) ,(if (rest primary) `(and ,@(mapcar #'(lambda (p) `(method-call ,p)) primary)) (first primary)))) (if (rest primary) `(and ,@(mapcar #'(lambda (p) `(method-call ,p)) primary)) (method-call ,(first primary))))) ;;; Examples of the long form of define-method-combination ;The default method-combination technique (define-method-combination standard () ((around (:around)) (before (:before)) (primary () :required t) (after (:after))) (if around `(method-call ,(first around) :next-methods `(,@(rest around) (multiple-value-prog1 (progn ,@(mapcar #'(lambda (b) `(method-call ,b)) before) ,(if (rest primary) `(and ,@(mapcar #'(lambda (p) `(method-call ,p)) primary)) (first primary))) ,@(mapcar #'(lambda (a) `(method-call ,a)) (reverse after))))) `(multiple-value-prog1 (progn ,@(mapcar #'(lambda (b) `(method-call ,b)) before) ,(if (rest primary) `(and ,@(mapcar #'(lambda (p) `(method-call ,p)) primary)) (first primary))) ,@(mapcar #'(lambda (a) `(method-call ,a)) (reverse after))))) [several examples skipped] ;Order methods by positive integer qualifiers ;:around methods are disallowed to keep the example small (define-method-combination example-method-combination () ((methods positive-integer-qualifier-p)) `(progn ,@(mapcar #'(lambda (m) `(method-call ,m)) (stable-sort methods #'< :key #'(lambda (method) (first (method-qualifiers method))))))) (defun positive-integer-qualifier-p (method-qualifiers) (and (= (list-length method-qualifiers) 1) (typep (first method-qualifiers) '(integer 0 *))))  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 28 Dec 87 21:56:58 EST Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 28 Dec 87 18:51:11 PST Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 311406; Mon 28-Dec-87 21:51:28 EST Date: Mon, 28 Dec 87 21:51 EST From: David A. Moon Subject: Comments on Chapter 1 To: Common-Lisp-Object-System@SAIL.STANFORD.EDU Message-ID: <19871229025115.7.MOON@EUPHRATES.SCRC.Symbolics.COM> Comments on the draft of chapter 1 dated Dec 23, 1987 13:37. This is probably my last round of comments for chapter 1. 1-10 and several others: I'm not sure that the introduction of the new term "captured :initform form" really adds anything to understandability. It ends up that "captured" is the only kind there is. 1-11 3rd paragraph last sentence: "Accessors are implemented using readers and writers, and readers, writers, and accessors are implemented using {\bf slot-value}." If there is such a thing as an accessor, it is either a reader or writer, it isn't implemented using readers or writers. I'd rather see "Reader and writer methods are implemented using {\bf slot-value}." 1-11 4th paragraph: several editing errors in switching between writer and accessor here. I suggest "When a reader or writer is specified for a slot, the name of the generic function to which the generated method belongs is directly specified. If the name specified for the accessor option is the symbol {\it name}, then the name of the generic function for reading the slot is the symbol {\it name\/} and the name of the generic function for writing the slot is the list {\tt (setf {\it name\/})}." Also the last sentence, "It is possible to modify the behavior of these generic functions by writing methods for them.", seems like a non-sequitur. The point this is trying to make is that you can write methods explicitly with defmethod, as well as writing methods implicitly with the slot options, and you can mix both kinds of methods on the same generic function. Perhaps the sentence should be in its own paragraph and should be rephrased slightly. 1-11 last paragraph: This is a good place to mention with-accessors, assuming that we are adding it. 1-12: The second paragraph under "Inheritance of Slots and Slot Options" no longer says what happens if the :allocation slot option is omitted. It used to. Delaying that until later seems confusing to me. 1-13: "Reader and accessor methods are inherited in the sense described in the section ``Inheritance of Methods.''" should say "writer" rather than "accessor" now. 1-13 last paragraph: "If a given {\bf :default-initargs} class option specifies an initialization argument of the same name more than once, the leftmost supplies the value and the remaining occurrences are ignored." I don't think this is right; it should be an error to specify the same initialization argument name more than once in a single :default-initargs class option. 1-14 last sentence: "there is also a method for {\tt setf} of {\tt S3} that writes the value of {\tt S3}." This is wrong, it's a method for {\tt setf} of {\tt C2-S3}. Perhaps the first half of the sentence should mention explicitly that the reader method is on the generic function named C2-S3. 1-15 last paragraph in first section: In "discarding local slots that are not defined in the new version of the instance", the last word is probably supposed to be "class", not "instance", since "defined" refers to classes. Alternatively, perhaps the word "defined" was supposed to be "accessible". Also "and initializing newly-added shared slots" can't be part of the two-step process of updating an instance. This phrase belongs two paragraphs earlier, where we are discussing shared slots. 1-15 first paragraph in second section: "defined by old class" is missing "the". Also this whole paragraph bothers me because it uses "defined" and "specified" interchangeably, or else there is a subtle difference between the two words that I haven't grasped. Earlier (1-12) "defined" meant only local definitions of slots, as opposed to inherited ones, so a different word should be used. "Accessible" if it fits, otherwise "specified" I guess. 1-16 first paragraph: "declass" should be "defclass". The meta object folks could rightly point out that there is too much emphasis on defclass forms here, that there are other ways to define classes, and that we could be clearer about the distinction between the name layer and the object layer. However, perhaps being pedantic about that would just make the writeup harder to read for no real benefit. With the above corrections I think the new description of class redefinition is a definite improvement. 1-17: same specified/defined wording issue. 1-19 first sentence: Isn't the mapping from classes into types, rather than the inverse as it says here? Not all types are mapped to a class. 1-20 in the table: "sequnce" should be "sequence". 1-20 bottom: The incomprehensible sentence "However, individual implementations are not free to add subclass relationships involving user-defined standard classes." was removed. I think what this meant to say is that a standard class defined with no direct superclasses is guaranteed to be disjoint with all of the classes in the table, except for t. That probably needs to be said. Note: my little phrase "with no direct superclasses" there seems like the cleanest way to rule out the loophole of the user explicitly defining a subclass of one of the potentially built-in classes that doesn't happen to be built-in. 1-20: Do we want to say in this document that we plan to add the following types/classes to the table whenever Common Lisp is fixed to define their relations to other types properly? It seems like that intention ought to be documented someplace. function hash-table package pathname random-state readtable stream 1-23 second paragraph: "The class {\tt apple} is a direct subclass of {\tt fruit} and is rightmost in the precedence list." leads to an unfortunate ambiguity where a reader might think that the direct subclass has to be the very last element of the precedence list computed so far. A better way to say it that avoids this ambiguity would be "The class {\tt apple} is a direct subclass of {\tt fruit} and the class {\tt pie} is a direct subclass of {\tt cinnamon}. Since {\tt apple} appears to the right of {\tt pie} in the precedence list, {\tt fruit} goes next ..." 1-24 with-added-methods paragraph: In "If there is a lexically visible ordinary function of the same name as one of the method definitions, that function becomes the method function of the default method for the new generic function of that name.", "as one of the method definitions" should be deleted, or replaced by "as the specified generic function name." 1-27 rule 4: This could be misinterpreted as implying that if a method has an &rest parameter, the value of that parameter will include the symbols :allow-other-keys and t even if the arguments supplied by the caller of the generic function did not include those symbols. We should say explicitly that that is not the case; a method's &rest parameter will see only the actual arguments. I think it would be clearer to go back to saying that a method function receives keyword arguments in the same way that it would if the method lambda-list had included &allow-other-keys. 1-31 second to last paragraph: "A method for {\bf compute-effective-method} can be defined directly by using {\bf defmethod} or any of the other method-defining forms..." is not really true. The other method-defining forms can define a method for a generic function named compute-effective-method, but it won't actually be the same generic function that the method combination mechanism calls; that mechanism calls the generic function that has that name globally, not any generic function that has that name lexically. I'd let this refer only to defmethod and define-method-combination. 1-32 first paragraph: A period is missing in "procedure Some illustrative examples". 1-34 first bullet: "those those" 1-34: How come "An error is signaled if {\bf call-next-method} is used in a {\bf :before} or {\bf :after} method." was removed? I think we need to make it clear that call-next-method isn't allowed in before and after methods. 1-34 last paragraph of first section: "shadowed" should be "shadow". 1-37 first bullet: I think "method-defining forms" here is a typo for something else. 1-40 last paragraph of first section: "The \OS\ does not guarantee any given order of evaluation of default value and {\bf :initform} forms." is ambiguous. This could be interpreted as saying that CLOS doesn't guarantee that all the default value forms are evaluated before any of the :initform forms. But I think it does guarantee that. What we really mean to say here is that CLOS doesn't guarantee which of two default value forms is evaluated first, and furthermore CLOS doesn't guarantee which of two :initform forms is evaluated first. Perhaps it could be better said as two sentences. 1-41 fourth bullet: "If a given {\bf :default-initargs} class option specifies an initialization argument of the same name more than once, the leftmost supplies the value and the remaining occurrences are ignored." should be deleted and replaced by: "If a given {\bf :default-initargs} class option specifies two initialization arguments that initialize the same slot, the leftmost supplies the value and the values of the remaining default value forms are ignored."  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 28 Dec 87 17:03:50 EST Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 28 Dec 87 13:59:19 PST Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 311260; Mon 28-Dec-87 16:59:27 EST Date: Mon, 28 Dec 87 16:59 EST From: David A. Moon Subject: partial results of Cambridge meeting To: Common-Lisp-Object-System@SAIL.STANFORD.EDU Message-ID: <19871228215909.9.MOON@EUPHRATES.SCRC.Symbolics.COM> Here are some of my notes on things we decided at the meeting in Cambridge earlier this month. I'm leaving out everything that is specifically about meta objects, which was the bulk of the discussion. This message is aimed just at finishing chapters 1 and 2. If there are any disagreements, sing out. In cases where the documentation has already been updated, I've noted that fact. We decided to leave chapter 2 in its present format but add to its introductory material a note that the present form of chapter 2 does not attempt to address the division of a labor between what a generic function does and what its standard methods do, and that that will be changed in a later revision when meta-objects are finished. A few things now in chapter 2 that really belong in chapter 3, such as the descriptions of specific initialize-instance methods, will be moved. We're all supposed to get in any final comments on chapters 1 and 2 as soon as possible, so that they can be mailed to the X3J13 committee in January. I'll be sending mine in in a day or two. For standard objects, EQL, EQUAL, and EQUALP are all the same as EQ. Other equality functions treat standard objects the same as other unrecognized objects, thus TREE-EQUAL uses EQL to compare standard objects, and it is an error to use a standard object as an argument to =, /=, CHAR-EQUAL, STRING-EQUAL, CHAR=, etc. Add a :WRITER slot option and specify that :ACCESSOR foo is an abbreviation for :READER foo :WRITER (SETF foo) This is already in chapter 1 (1-11), but with some editing mistakes, which I'll send separate mail about. Change the syntax of WITH-SLOTS to be like MULTIPLE-VALUE-BIND, by interchanging the instance form and the list of slot names. Do not provide a way to have more than one instance form in a single WITH-SLOTS. SYMBOL-MACROLET definitely doesn't do anything special to the macroexpansion environment, so a macro that's invoked in the body of a SYMBOL-MACROLET (or WITH-SLOTS) cannot(emphasis!) tell whether a symbol as a subform of an invocation of the macro is really a variable or is going to get substituted. The remarks for SYMBOL-MACROLET thus recommend that the forms should behave like variables, that is, reading should be free of side-effects and evaluating either a read or a write multiple times should be equivalent, except for speed, to doing it once. We should supply examples of right and wrong ways to use SYMBOL-MACROLET. For example, (symbol-macrolet ((x (slot-value object 'x))) ...) ;good (symbol-macrolet ((x (aref a (incf i)))) ...) ;bad, not idempotent (symbol-macrolet ((x (aref a (1+ i)))) ...) ;good (symbol-macrolet ((x (+ oldx offset))) ...) ;good, but read-only (symbol-macrolet ((x (incf oldx offset))) ...) ;highly bad (symbol-macrolet ((x (cons y z))) ...) ;bad, reading isn't idempotent (symbol-macrolet ((x (caddr z))) ...) ;good (symbol-macrolet ((x (throw 'tag))) ...) ;horrible We don't have to use all these examples, I just quickly came up with a bunch so there would be something to work from. We discussed constructors for a while and I will send out a revised, complete proposal in a couple days.  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 28 Dec 87 16:20:07 EST Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 28 Dec 87 13:16:42 PST Received: from Semillon.ms by ArpaGateway.ms ; 28 DEC 87 12:41:47 PST Date: Mon, 28 Dec 87 12:40 PST From: Gregor.pa@Xerox.COM Subject: with-accessors To: David A. Moon cc: common-lisp-object-system@SAIL.STANFORD.EDU Fcc: BD:>Gregor>mail>outgoing-mail-1.text In-Reply-To: <19871228192947.3.MOON@EUPHRATES.SCRC.Symbolics.COM> Message-ID: <871228124037.3.GREGOR@SPIFF.parc.xerox.com> Line-fold: no Date: Mon, 28 Dec 87 14:29 EST From: David A. Moon Date: Tue, 22 Dec 87 18:18 PST From: Gregor.pa@Xerox.COM (with-accessors ((x position-x) (y position-y)) p1 (setq x y)) I like this. I think we should put it in. Is (with-accessors (x y) p1 (setq x y)) allowed for consistency with with-slots? It would only work for classes that use the naming convention that accessor function names are the same as slot names, which might mean that its existence leads to confusion. Hence I suggest that we should not allow this abbreviated syntax. I agree that we should not allow this abbreviated syntax. I meant to address that specifically in my message but I seem to have forgotten. -------  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 28 Dec 87 15:55:44 EST Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 28 Dec 87 12:51:59 PST Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 311191; Mon 28-Dec-87 15:52:11 EST Date: Mon, 28 Dec 87 15:51 EST From: David A. Moon Subject: New Class Organization for CLOS Kernel To: common-lisp-object-system@SAIL.STANFORD.EDU In-Reply-To: <871223-143619-8688@Xerox> Message-ID: <19871228205157.8.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: 23 Dec 87 14:34 PST From: Danny Bobrow The following is my understanding of what we agreed to in Cambridge. Agreed, except for some problems with the class relationships: standard-accessor-method and standard-method should be disjoint for the same reason that standard-class, built-in-class, and structure-class are now disjoint. The principle underlying this is that we need to distinguish between the class that is used by default by the various macros, and the class from which other classes inherit. This allows a programmer defining a new method to choose whether this method is to be applicable to the default kind of object that the macros make or to all objects (of the relevant general kind). For example, standard-class is distinct from structure-class, and they both inherit from class, so that a programmer can put a method on standard-class to affect classes made by defclass, or on class to affect all classes. Probably this principle should be in your list of principles. It's okay for standard-class-slot-description to be a subclass of standard-slot-description, provided the idea is that standard-class-slot-description is a kludge to avoid putting the :allocation into a slot. Otherwise there should be both standard-class-slot-description and standard-instance-slot-description, disjoint, and if we want we could also define a common superclass of them. I don't have an opinion on which of those alternatives is right since I don't yet understand exactly what you're trying to do with slot-descriptions. Forward-referenced-class should be disjoint from standard-class for the same reason, except that forward-referenced-class should not exist at all, in my opinion. It's okay for funcallable-standard-class to be a subclass of standard-class if we really mean that funcallable-standard-class is a specialization of the class you get with defclass, not something distinct that wants to inherit some of the same methods. I haven't seen a written description of funcallable-standard-class yet, but my understanding is that that is the nature of it.  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 28 Dec 87 15:11:40 EST Received: from [128.81.41.234] by SAIL.STANFORD.EDU with TCP; 28 Dec 87 12:04:40 PST Received: from EUPHRATES.SCRC.Symbolics.COM by MEAD.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 123190; Mon 28-Dec-87 14:54:41 EST Date: Mon, 28 Dec 87 14:53 EST From: David A. Moon Subject: Re: add-method when method exists To: Gregor.pa@XEROX.COM, kanderso@WILMA.BBN.COM cc: common-lisp-object-system@SAIL.STANFORD.EDU In-Reply-To: The message of 28 Dec 87 09:26 EST from kanderso@WILMA.BBN.COM Message-ID: <19871228195358.4.MOON@EUPHRATES.SCRC.Symbolics.COM> Line-fold: No Summary of issues raised in this message: 1) Ambiguity in the documentation of add-method 2) General ambiguity in the language used in the spec 3) Should add-method become add-or-replace-method 4) Precisely when are errors signaled 5) Do we really want to make it an error to omit the primary method Date: Mon, 28 Dec 87 09:26:37 -0500 From: kanderso@WILMA.BBN.COM Date: Wed, 23 Dec 87 13:04 PST From: Gregor.pa@XEROX.COM In the current version of the spec, if add-method is used to add a method to a generic function and there is already a method with the same specializers and qualifiers an error is signaled.... Actually the language in the version of the spec that I have is ambiguous, and may not mean what you said. It says (2-8) "If the given method is already one of the methods on the generic function, as determined by get-method, or if the method object is a method object of another generic function, an error is