Received: from Xerox.COM (TCP 1500006350) by AI.AI.MIT.EDU 8 Dec 87 15:06:49 EST Received: from Catawba.ms by ArpaGateway.ms ; 08 DEC 87 11:45:38 PST Return-Path: Redistributed: commonloops.pa Received: from CAF.MIT.EDU by Xerox.COM ; 08 DEC 87 11:42:06 PST Received: by CAF.MIT.EDU (5.54/5.18) id AA24134; Tue, 8 Dec 87 14:41:54 EST Date: Tue, 8 Dec 87 14:41:54 EST From: Roberto Guerrieri Message-Id: <8712081941.AA24134@CAF.MIT.EDU> To: commonloops.pa@Xerox.COM Has anybody set up a bitnet site for getting pcl sources? Thank you Roberto Guerrieri  Received: from SAIL.Stanford.EDU (TCP 4425400302) by AI.AI.MIT.EDU 7 Dec 87 19:51:47 EST Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 7 Dec 87 16:42:53 PST Received: from Semillon.ms by ArpaGateway.ms ; 07 DEC 87 14:49:00 PST Date: Mon, 7 Dec 87 14:47 PST From: Gregor.pa@Xerox.COM Subject: MOP comments part 1. To: Patrick H Dussud cc: common-lisp-object-system@sail.stanford.edu Fcc: BD:>Gregor>mail>outgoing-mail-1.text In-Reply-To: <2774647634-6446503@Jenner> Message-ID: <871207144728.3.GREGOR@SPIFF.parc.xerox.com> Line-fold: no Date: Fri, 4 Dec 87 17:27:14 CST From: Patrick H Dussud I like this draft much better than the first draft that came out last march. Glad to hear it. - Section: Class Organization in the CLOS Kernel I find the argumentation in favor of common base design not very convincing. I agree that the argumentation presented in the current draft is not very convinving. See below. Having the mixins is fine if you have cut the world exactly right for the variation of class behavior one wants. However, if not, then one has the same type of problem with overriding unwanted behavior with multiple mixins I agree with this. If we think that we can't get it right in a reasonnable amount of time, then I want to suggest an alternative: (defclass basic-class ()) (defclass standard-allocation-class (basic-class)) (defclass structure-allocation-class (basic-class)) (defclass standard-class (standard-allocation-class) ...) (defclass structure-class (structure-allocation-class) ...) (defclass built-in-class (basic-class)) That's a minimal approach that preserves modularity (no turning off/on methods.) and conveys the fact that there is only two standard ways to represent instances. Well, I believe that we may want to go to a structure like: (defclass basic-class () ...) (defclass standard-class (basic-class) ...) (defclass structure-class (basic-class) ...) (defclass built-in-class (basic-class) ...) . . but I think doing even that will be hard in a "reasonable ampount of time". The point is this. In this organization, what behavior do you put in basic-class and what behavior do you put in standard-class? Can you make a lasting, satisfying argument for that breakdown? So far, we have been unable to come up with a division of behavior that we can make a lasting satisfying argument for. It may be that we will want to go to a structure like the one above, and just take a decent crack that the division without worrying about whether the division appears lasting. The real question seems to be: If you go to a separated class structure, must the division be appropriate just for the defined classes, or must it somehow be more 'correct' in general. That is, when making a decision about what should go in basic-class, should that decision be defended only with respect to the standard-class, structure-class and built-in-class or should it somehow be reconciled with some more abstract notion of class division. If we only reconcile the division with respect to the existing classes, we are a likely to get what looks like a good modularity, but as soon as someone tries to extend it they will discover it isn't so good. On the other hand, if we try to reconcile the division with all future programs in mind we will never be able to do the division. Clearly we must find a stable middle ground in this dimension. Having spent some time pursuing several different such middle grounds, I am starting to believe that a structure like the one I mention above is appropriate, but even in doing that, we will have to make some design decisions which in the future will appear more awkward than if we just have everything be a subclass of standard-class. - Section: The Named Class Definition Protocol Why would we have to parse the slots at load time instead of compile time? Add-named-class should be able to accept slot-descriptions as well. I suppose thats true. I wouldn't expect the efficiency gain to be tremendously significant since the slot specifiers can be canonicalized at compile time, and there is so much other work to do. This Class Update protocol based an eager evaluation model. I want to propose a lazy evaluation model. There is no need to propagate changes downward (to the subclasses) if the subclasses haven't computed anything from their superclasses. Computed properties are typically: PCL, effective slot-description, effective default-initargs... There is no reason for computing these properties if the class is not going have instances since a class cannot compute its effective propeties based on the effective property of its superclasses. Lazy evaluation is harder though, and this would force user mop code to have to be able to deal with lazy evaluation. I think an appropriate middle ground can be reached by having the full walk happen, but having it not do all the computations (like cpl and slots) until finalize inheritance time. I also propose to get rid of forward-reference-class. The direct-supers slot of a class is never mapped to class object. When finalize-inheritance is called, the mapping is done in order to compute the CPL and other effective properties but the direct-supers slot is not updated. I thinks it reflects better what the user expects if the mapping between name and class object changes. Actually, I think the semantics of using forward referenced class objects are much simpler and easier to define. I don't believe this affects the naive user (defclass only) model at all (or not very much) and it makes the sophisticated users model easier to deal with. Having an object to represent the forward referenced class makes it possible to store forward-declared information about that class; this makes it possible to implement interesting behavior like the declare-optimized example. -------  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 4 Dec 87 21:01:55 EST Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 4 Dec 87 17:54:51 PST Received: from Semillon.ms by ArpaGateway.ms ; 04 DEC 87 17:33:31 PST Date: Fri, 4 Dec 87 17:06 PST From: Gregor.pa@Xerox.COM Subject: the mop To: common-lisp-object-system@sail.stanford.edu Message-ID: <871204170622.0.GREGOR@SPIFF.parc.xerox.com> Line-fold: no There is a slightly improved version of the mop on sail in the usual place. As usual any comments appreciated. -------  Received: from Xerox.COM (TCP 1500006350) by AI.AI.MIT.EDU 4 Dec 87 15:09:43 EST Received: from Concord.ms by ArpaGateway.ms ; 04 DEC 87 11:47:31 PST Return-Path: Redistributed: commonloops.pa Received: from SPAR-20.SPAR.SLB.COM by Xerox.COM ; 04 DEC 87 11:44:44 PST Date: Thu, 3 Dec 87 01:08:57 PST From: Dan Carnese Subject: class-constant-form To: commonloops.pa@Xerox.COM Message-ID: <12355470940.16.CARNESE@SPAR-20.SPAR.SLB.COM> In the Xerox implementation, class-constant-form returns a form containing a class object. This will cause the compiler to blow out when compiling a defclass with a constructor. The class-constant-form definition used for kcl and gclisp works fine, so the patch couldn't be simpler. -------  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 3 Dec 87 22:22:24 EST Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 3 Dec 87 19:14:09 PST Received: from Semillon.ms by ArpaGateway.ms ; 03 DEC 87 19:12:41 PST Date: Thu, 3 Dec 87 19:11 PST From: Gregor.pa@Xerox.COM Subject: mop To: common-lisp-object-system@sail.stanford.edu Fcc: BD:>Gregor>mail>outgoing-mail-1.text Message-ID: <871203191130.8.GREGOR@SPIFF.parc.xerox.com> Line-fold: no It may help in your reading now to know that the sections Danny and I are working on now are class updating and method lookup. There were a number of problems in both those sections. We hope to have a new version on Sail tomorrow afternoon with rewritten versions of those sections. -------  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 2 Dec 87 00:21:01 EST Received: from SCORE.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 1 Dec 87 21:13:21 PST Received: from hplabs.HP.COM by SCORE.STANFORD.EDU with TCP; Tue 1 Dec 87 21:07:54-PST Received: from hplms2.HP.COM (hplms2) by hplabs.HP.COM with SMTP ; Mon, 30 Nov 87 14:48:17 PST Received: from hplabsz.hpl.hp.com by hplms2.HP.COM; Mon, 30 Nov 87 14:47:44 pst Return-Path: Received: from hplabsz by hplabsz; Mon, 30 Nov 87 15:47:20 pst To: "David A. Moon" Cc: Common-Lisp-Object-System@SAIL.STANFORD.EDU Subject: Re: :accessor slot option X-Mailer: mh6.5 In-Reply-To: Your message of Mon, 30 Nov 87 13:48:00 -0500. <19871130184852.9.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Mon, 30 Nov 87 15:47:17 MST Message-Id: <4168.565310837@hplabsz> From: kempf%hplabsz@hplabs.HP.COM > I agree that adding a :writer slot-option is a good idea. This would > make some of my users happier. This makes the CLOS specification slightly > larger, but it's probably worth it. It certainly doesn't make CLOS more > -conceptually- complex. > I agree that in cases where you want both a reader and a writer its > probably too verbose, so we probably need to keep the :accessor option, > but what if we renamed it, maybe to :reader-writer or perhaps > :accessors. > The name :accessors is definitely out; mixed singular and plural option > names always lead to trouble. I don't think :accessor is too bad a name > to imply a function that works for both reading and w> r> iting. If I was > teaching CLOS to someone, I think I would teach them :accessor first, > as the one that you usually use, and then later say "actually :accessor > can be broken down into its two component parts, :reader and :writer, > in case you have your special reasons to want to get at them separately." For what it's worth, I prefer just having a :reader and :writer option, and if people want both they can specify both. Sort of like file protections on some OS's. > The name :default-initargs can be justified on the basis that it can > default more than one "initarg", but it might be worth rethinking this > name to avoid plurality and to avoid the jargon word "initarg," which > has been demoted to a less prominent place in the CLOS specification > than it had originally. :default-initialization was the best name I > could come up with, maybe someone else can do better. Yes. jak  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 2 Dec 87 00:10:16 EST Received: from SCORE.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 1 Dec 87 21:03:07 PST Received: from hplabs.HP.COM by SCORE.STANFORD.EDU with TCP; Tue 1 Dec 87 20:57:39-PST Received: from hplms2.HP.COM (hplms2) by hplabs.HP.COM with SMTP ; Mon, 30 Nov 87 16:04:43 PST Received: from hplabsz.hpl.hp.com by hplms2.HP.COM; Mon, 30 Nov 87 16:04:14 pst Return-Path: Received: from hplabsz by hplabsz; Mon, 30 Nov 87 17:03:51 pst To: "David A. Moon" Cc: Gregor.pa@Xerox.COM, common-lisp-object-system@SAIL.STANFORD.EDU Subject: Re: symbol-macrolet X-Mailer: mh6.5 In-Reply-To: Your message of Mon, 23 Nov 87 15:19:00 -0500. <19871123201936.6.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Mon, 30 Nov 87 17:03:48 MST Message-Id: <5270.565315428@hplabsz> From: kempf%hplabsz@hplabs.HP.COM > Date: Thu, 19 Nov 87 17:13 PST > From: Gregor.pa@Xerox.COM > I suppose we should say explicitly that the symbol macros are recorded > in the macroexpansion environment so that macroexpand-1 of a symbol > which is a symbol-macro will expand it. > I thought we were going to allow SYMBOL-MACROLET to be implemented in a > portable way, as something that fully macroexpands the form given and > then makes substitutions for symbols in it. During macroexpansion the > symbol-macrolet'ed symbols would be just like other symbols, which seems > okay since they are (I think) supposed to be used in ways that are > semantically like variables; certainly that's true in the case of > WITH-SLOTS. This is, in fact, how LET-PSEUDO (our version of SYMBOL-MACROLET) works. First, all macros are expanded, and then the symbols are macroleted. User defined macros thus treat the symbols like regular symbols, which is what, I think, you want when considering them as variables, as you mentioned. The macroexpansion environment is left untouched. jak  Received: from Xerox.COM (TCP 1500006350) by AI.AI.MIT.EDU 1 Dec 87 21:00:54 EST Received: from Concord.ms by ArpaGateway.ms ; 01 DEC 87 09:33:39 PST Return-Path: Redistributed: CommonLoops.pa Received: from avalon.berkeley.edu by Xerox.COM ; 01 DEC 87 09:30:08 PST Received: by avalon.berkeley.edu (5.57/1.26) id AA10871; Tue, 1 Dec 87 09:32:03 PST Message-Id: <8712011732.AA10871@avalon.berkeley.edu> From: David C. Martin Organization: University of California at Berkeley - Dept of EECS/CS Division Email: dcmartin@postgres.Berkeley.EDU or {ihnp4,decvax}!ucbvax!dcmartin Phone: 415/642-9585 (O) To: Steve Strassmann Cc: CommonLoops.pa@Xerox.COM Precedence: special-delivery In-Reply-To: Your message of Tue, 1 Dec 87 04:40 EST <871201044017.5.STRAZ@ZAXXON.MEDIA.MIT.EDU> Subject: Re: initialize-instance Date: Tue, 01 Dec 87 09:32:00 PST Sender: dcmartin%avalon.Berkeley.EDU@Berkeley.EDU Richard's answer is correct, but I find it a little bit annoying to have the init-plist as my argument. What I have done is define a method on OBJECT which is called new-instance. The method defined on OBJECT does nothing, but will be called *after* the initialize method is called. The order of function is then initialize, initialize-from-defaults, initialize-from-init-plist and then new-instance. For example: (defclass foo (object) ((a :initform 10 :type integer :accessor foo-a) (b :initform 20 :type integer :accessor foo-b) (c :initform 30 :type integer :accessor foo-c)) (:constructor make-foo)) (defmethod new-instance ((self foo) &key (a nil ap) (b nil bp) (c nil cp) (all nil allp) &allow-other-keys) "Initialize a new-instance of the foo class" (when (and allp (integerp all)) (setf (slot-value self 'a) all) (setf (slot-value self 'b) all) (setf (slot-value self 'c) all))) This functionality makes it easy to define any additional initialization on the instances. The code is at the end of the file (I use a different initialize-from-init-plist function since the original did not allow you to specify keywords which didn't correspond to slots - Gregor, is this still true?) Hope this helps. dcm -------- (in-package 'pcl :use '(lisp)) ;;; ;;; Top-level new-instance function ;;; (defmethod new-instance ((self object) &key (ignore nil) &allow-other-keys) ;; do nothing (declare (ignore self ignore))) ;;; ;;; initialize-from-arg-list ;;; (defmethod initialize-from-arg-list ((self object) arg-list) (if (not (null arg-list)) (let* ((class (class-of self)) (instance-slots (class-instance-slots class)) (non-instance-slots (class-non-instance-slots class))) (macrolet ((find-slotd (keyword) `(or (find-slotd-1 ,keyword instance-slots) (find-slotd-1 ,keyword non-instance-slots))) (find-slotd-1 (keyword slotds) `(dolist (slotd ,slotds) (when (eq (slotd-keyword slotd) ,keyword) (return slotd))))) (do* ((keyword-loc arg-list (cdr value-loc)) (value-loc (cdr keyword-loc) (cdr keyword-loc)) (slotd () ())) (()) (cond ((null keyword-loc) (return nil)) ((null value-loc) (error "No value supplied for the init-keyword ~S." (car keyword-loc))) ((not (null (setq slotd (find-slotd (car keyword-loc))))) (setf (slot-value self (slotd-name slotd)) (car value-loc))))))))) ;;; ;;; Initialize an object ;;; (defmethod initialize ((self object) arg-list) ;; intialize from defaults (initialize-from-defaults self) ;; use my initialize from argument list (initialize-from-arg-list self arg-list) ;; call user specifiable new method (apply #'new-instance self arg-list) ;; return object self)  Received: from Xerox.COM (TCP 1500006350) by AI.AI.MIT.EDU 1 Dec 87 21:00:28 EST Received: from Catawba.ms by ArpaGateway.ms ; 01 DEC 87 05:07:53 PST Return-Path: Redistributed: CommonLoops.pa Received: from burdvax.PRC.Unisys.COM (PRC-GW.PRC.UNISYS.COM) by Xerox.COM ; 01 DEC 87 05:06:25 PST Received: from bigburd.PRC.Unisys.COM by burdvax.PRC.Unisys.COM (burdvax) [5.54/1.0] id AA20677; Tue, 1 Dec 87 08:05:16 EST Received: by bigburd.PRC.Unisys.COM (bigburd) [5.54/1.0] id AA01850; Tue, 1 Dec 87 08:05:13 EST From: fritzson@PRC.Unisys.COM (Richard Fritzson) Message-Id: <8712011305.AA01850@bigburd.PRC.Unisys.COM> Received: from Ringmaster by bigburd with PUP; Tue, 1 Dec 87 08:05 EST Date: 1 Dec 87 08:05 EST (Tuesday) Subject: Re: initialize-instance In-Reply-To: straz@MEDIA-LAB.MEDIA.MIT.EDU's message of Tue, 1 Dec 87 04:40 EST To: straz@media-lab.media.mit.edu Cc: CommonLoops.pa@Xerox.COM > Date: Tue, 1 Dec 87 04:40 EST > From: Steve Strassmann > Subject: initialize-instance > > I'm trying to run some code which initializes instances after creation. > >From the CLOS documentation, it looks like I should be putting this in > initialize-instance. However, this doesn't seem to be working in the Aug.27 > release. > "initialize-instance" was added to the CLOS spec a little too recently to have appeared in PCL yet. I don't know what the "standard" replacement is, but we have been defining a method "initialize" on the new type which does the specialized initialization and does a "call-next-method" to do the more general initialization. The lambda list for initialize is: (defmethod initialize ((object ) init-plist)... the source for (initialize (object object) init-plist) is in the file slots.lisp.  Received: from Xerox.COM (TCP 1500006350) by AI.AI.MIT.EDU 1 Dec 87 06:29:04 EST Received: from Catawba.ms by ArpaGateway.ms ; 01 DEC 87 01:48:48 PST Return-Path: Redistributed: CommonLoops.pa Received: from media-lab.MIT.EDU (media-lab.media.mit.edu) by Xerox.COM ; 01 DEC 87 01:47:16 PST Received: from zaxxon.media.mit.edu by media-lab.MIT.EDU (5.54/4.8) via CHAOS with CHAOS id AA13921; Tue, 1 Dec 87 04:40:47 EST Date: Tue, 1 Dec 87 04:40 EST From: Steve Strassmann Subject: initialize-instance To: CommonLoops.pa@Xerox.COM Message-Id: <871201044017.5.STRAZ@ZAXXON.MEDIA.MIT.EDU> I'm trying to run some code which initializes instances after creation. From the CLOS documentation, it looks like I should be putting this in initialize-instance. However, this doesn't seem to be working in the Aug.27 release. Am I doing something wrong, or is initialize-instance just not installed yet? What can I use in the meantime? Thanks.  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 30 Nov 87 13:57:47 EST Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 30 Nov 87 10:48:59 PST Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 290722; 30 Nov 87 13:48:49 EST Date: Mon, 30 Nov 87 13:48 EST From: David A. Moon Subject: :accessor slot option To: Common-Lisp-Object-System@SAIL.STANFORD.EDU In-Reply-To: <871102133014.0.GREGOR@SPIFF.isl.parc.xerox.com> Message-ID: <19871130184852.9.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Mon, 2 Nov 87 13:30 PST From: Gregor.pa@Xerox.COM I have become uncomfortable with the :reader and :accessor slot options. Right now, at the very least, I would like to add a :writer option, I may also want to remove or rename the :accessor option. The :writer option would work in the obvious way: (defclass foo () ((a :reader foo-a :writer (setf foo-a)))) This would allow someone who wanted to define a writer but no reader to do it, it also makes the mapping onto the new setf proposal more explicit. I agree that adding a :writer slot-option is a good idea. This would make some of my users happier. This makes the CLOS specification slightly larger, but it's probably worth it. It certainly doesn't make CLOS more -conceptually- complex. I agree that in cases where you want both a reader and a writer its probably too verbose, so we probably need to keep the :accessor option, but what if we renamed it, maybe to :reader-writer or perhaps :accessors. The name :accessors is definitely out; mixed singular and plural option names always lead to trouble. I don't think :accessor is too bad a name to imply a function that works for both reading and writing. If I was teaching CLOS to someone, I think I would teach them :accessor first, as the one that you usually use, and then later say "actually :accessor can be broken down into its two component parts, :reader and :writer, in case you have your special reasons to want to get at them separately." What about the plural option name :default-initargs? I think this is the only plural option we have, except for :qualifiers and :specializers arguments when making a method, and those are legitimately plural to show that their values are lists. The name :default-initargs can be justified on the basis that it can default more than one "initarg", but it might be worth rethinking this name to avoid plurality and to avoid the jargon word "initarg," which has been demoted to a less prominent place in the CLOS specification than it had originally. :default-initialization was the best name I could come up with, maybe someone else can do better.  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 24 Nov 87 14:52:55 EST Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 24 Nov 87 11:44:03 PST Received: from Semillon.ms by ArpaGateway.ms ; 24 NOV 87 11:39:14 PST Date: Tue, 24 Nov 87 11:36:03 PST From: Ken Kahn Subject: Re: making gf lambda lists In-Reply-To: <19871124015712.1.MOON@EUPHRATES.SCRC.Symbolics.COM> To: David A. Moon cc: Gregor.pa@Xerox.COM, common-lisp-object-system@SAIL.STANFORD.EDU Message-ID: <871124-113914-4047@Xerox> > It's always a metter of philosophy whether to bring functions like this > that we know are in there someplace out into the open and give them documented > names. I like the SETF approach, which says to document only the ones > that the user really has to know about. I agree with the philosophy but find it curious that the proposal to have SETF named functions is to remedy the fact that the SETF macro approach hides things which people discovered they sometimes need. References Moon@STONY-BROOK.SCRC.Symbolics.COM's message of Mon, 23 Nov 87 20:57:00 EST -- making gf lambda lists  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 23 Nov 87 21:06:27 EST Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 23 Nov 87 17:57:54 PST Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 287364; Mon 23-Nov-87 20:57:15 EST Date: Mon, 23 Nov 87 20:57 EST From: David A. Moon Subject: making gf lambda lists To: Gregor.pa@Xerox.COM cc: common-lisp-object-system@SAIL.STANFORD.EDU In-Reply-To: <871111144109.3.GREGOR@SPIFF.isl.parc.xerox.com> Message-ID: <19871124015712.1.MOON@EUPHRATES.SCRC.Symbolics.COM> Line-fold: No Date: Wed, 11 Nov 87 14:41 PST From: Gregor.pa@Xerox.COM I believe that we are going to want to introduce a support function called something like: make-generic-function-lambda-list-from-specialized-method-lambda-list This function will make it easier for programmers who are constructing their own methods and generic functions to get themselves a congruent generic function lambda list. This functions will strip out specializers and optional defaults and remove uses of &key and &aux (and anything else I might have forgotten). Can anyone think of a better name for this function? No name. I have too much mail backlog to find it now, but I think I suggested that the making of a generic function should accept any form of lambda list and should strip it itself. Maybe I only suggested that for methods, but I think it should apply to both methods and generic functions that you can hand in anything that can be coerced into the right thing. "Hand in" means as a :lambda-list argument to ensure-generic-function or to make-instance of the appropriate class. It's always a metter of philosophy whether to bring functions like this that we know are in there someplace out into the open and give them documented names. I like the SETF approach, which says to document only the ones that the user really has to know about.  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 23 Nov 87 16:15:32 EST Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 23 Nov 87 13:06:30 PST Received: from Semillon.ms by ArpaGateway.ms ; 23 NOV 87 13:05:11 PST Date: Mon, 23 Nov 87 13:04 PST From: Gregor.pa@Xerox.COM Subject: symbol-macrolet To: David A. Moon cc: common-lisp-object-system@SAIL.STANFORD.EDU In-Reply-To: <19871123201936.6.MOON@EUPHRATES.SCRC.Symbolics.COM> Message-ID: <871123130424.8.GREGOR@SPIFF.parc.xerox.com> Line-fold: no Date: Mon, 23 Nov 87 15:19 EST From: David A. Moon Date: Thu, 19 Nov 87 17:13 PST From: Gregor.pa@Xerox.COM I suppose we should say explicitly that the symbol macros are recorded in the macroexpansion environment so that macroexpand-1 of a symbol which is a symbol-macro will expand it. I thought we were going to allow SYMBOL-MACROLET to be implemented in a portable way, as something that fully macroexpands the form given and then makes substitutions for symbols in it. During macroexpansion the symbol-macrolet'ed symbols would be just like other symbols, which seems okay since they are (I think) supposed to be used in ways that are semantically like variables; certainly that's true in the case of WITH-SLOTS. You seem to be suggesting that instead we will require every implementation to change its macro mechanism to support symbol macros directly. Does this also require that every implementation must change its interpreter and compiler to macroexpand symbols as well as lists before attempting to evaluate them? Whether the answer to that is yes or no, it seems likely that every implementation would have to change its internal representation of lexical environments, to allow for symbols to be "bound" to macros as well as to values. We might get a great deal of resistance to that from some implementations. Unless we can come up with some more compelling examples than so far, I don't think CLOS should require SYMBOL-MACROLET to do anything to the macroexpansion environment. I think we should stick with the very simple and easy to understand definition of SYMBOL-MACROLET that we have now: "Each reference to -symbol- as a variable within the lexical scope of symbol-macrolet is replaced by -expansion-." Both examples so far appear to be predicated on the assumption that a call to SLOT-VALUE is much less efficient than accessing a variable, and therefore we want to allow for common subexpression optimization to be done by hand for these in a funny way. I for one see no reason to stipulate that inefficiency, nor to assume that CSE optimizations must be done by hand. Well, my concern was that there were macros which use once-only for semanic reasons rather than purely optimization reasons. These macros assume that if a variable is lexical, they can know whether that variable is being modified in their scope, they can perform some optimizations. Granted, this is bad macro writing style, but I claim that it is common. Its also true that the cases where these macros will break is rare, but they do exist, and it makes me uncomfortable to think there will be no way of fixing them. On the other hand, I agree that it makes me unhappy to have to modify the behavior of macroexpand-1 this way, and to modify the behavior of the interpreter this way. I had not realized that this was such a radical change. I guess now I am not sure. Maybe the best thing to do is leave symbol-macrolet the way you suggested and just document the exact form of lossage I am describing. Let me take this space to present one view of how macroexpansion environments could be made more useful. If they were themselves a function, which could be given an operation and arguments, and if the default function accepted operations to macroexpand-1, fboundp, etc. then I could just extend these things by wrapping my own function around them which carried additional information. That would make it possible to write a portable code walker in Common Lisp. But it would not solve this problem. -------  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 23 Nov 87 15:27:23 EST Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 23 Nov 87 12:20:26 PST Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 286861; Mon 23-Nov-87 15:19:41 EST Date: Mon, 23 Nov 87 15:19 EST From: David A. Moon Subject: symbol-macrolet To: Gregor.pa@Xerox.COM cc: common-lisp-object-system@SAIL.STANFORD.EDU In-Reply-To: <871119171306.3.GREGOR@SPIFF.isl.parc.xerox.com>, The message of 20 Nov 87 06:37 EST from kanderso@WILMA.BBN.COM, <871120094332.9.GREGOR@SPIFF.parc.xerox.com>, <871120145418.2.GREGOR@SPIFF.parc.xerox.com>, <2773675077-8251807@Jenner> Message-ID: <19871123201936.6.MOON@EUPHRATES.SCRC.Symbolics.COM> Line-fold: No Date: Thu, 19 Nov 87 17:13 PST From: Gregor.pa@Xerox.COM I suppose we should say explicitly that the symbol macros are recorded in the macroexpansion environment so that macroexpand-1 of a symbol which is a symbol-macro will expand it. I thought we were going to allow SYMBOL-MACROLET to be implemented in a portable way, as something that fully macroexpands the form given and then makes substitutions for symbols in it. During macroexpansion the symbol-macrolet'ed symbols would be just like other symbols, which seems okay since they are (I think) supposed to be used in ways that are semantically like variables; certainly that's true in the case of WITH-SLOTS. You seem to be suggesting that instead we will require every implementation to change its macro mechanism to support symbol macros directly. Does this also require that every implementation must change its interpreter and compiler to macroexpand symbols as well as lists before attempting to evaluate them? Whether the answer to that is yes or no, it seems likely that every implementation would have to change its internal representation of lexical environments, to allow for symbols to be "bound" to macros as well as to values. We might get a great deal of resistance to that from some implementations. Unless we can come up with some more compelling examples than so far, I don't think CLOS should require SYMBOL-MACROLET to do anything to the macroexpansion environment. I think we should stick with the very simple and easy to understand definition of SYMBOL-MACROLET that we have now: "Each reference to -symbol- as a variable within the lexical scope of symbol-macrolet is replaced by -expansion-." Both examples so far appear to be predicated on the assumption that a call to SLOT-VALUE is much less efficient than accessing a variable, and therefore we want to allow for common subexpression optimization to be done by hand for these in a funny way. I for one see no reason to stipulate that inefficiency, nor to assume that CSE optimizations must be done by hand.  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 23 Nov 87 13:50:06 EST Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 23 Nov 87 10:41:08 PST Received: from relay2.cs.net by RELAY.CS.NET id ae10335; 23 Nov 87 13:31 EST Received: from csl.ti.com by RELAY.CS.NET id au19978; 23 Nov 87 13:24 EST Received: from Jenner by tilde id AA17820; Mon, 23 Nov 87 11:21:58 CST Message-Id: <2773675077-8251807@Jenner> Date: Mon, 23 Nov 87 11:17:57 CST From: Patrick H Dussud To: Gregor.pa@XEROX.COM Cc: common-lisp-object-system@SAIL.STANFORD.EDU Subject: Re: symbol-macrolet In-Reply-To: Msg of Fri, 20 Nov 87 14:54 PST from Gregor.pa@xerox.com I suppose we should say explicitly that the symbol macros are recorded in the macroexpansion environment so that macroexpand-1 of a symbol which is a symbol-macro will expand it. In the text in my draft, this would correspond to including something like the following in remarks. Within the body of symbol-macrolet the macroexpansion environment is augmented to include a symbol-macro definition for the symbol. When given the symbol and the environment as arguments, macroexpand-1 will return the expansion. This means that a macro which appears in the scope of symbol-macrolet can use macroexpand-1 to determine whether or not a symbol names a symbol macro; this is particularly useful for macros which want to determine whether or not their argument is a symbol. It sounds good. Patrick.  Received: from Xerox.COM (TCP 1200400040) by AI.AI.MIT.EDU 22 Nov 87 17:10:14 EST Received: from Salvador.ms by ArpaGateway.ms ; 22 NOV 87 13:01:47 PST Return-Path: Redistributed: commonloops.pa Received: from hplabs.HP.COM by Xerox.COM ; 22 NOV 87 12:59:27 PST Received: from hplms2.HP.COM (hplms2) by hplabs.HP.COM with SMTP ; Sun, 22 Nov 87 12:58:31 PST Received: from hplabsz.hpl.hp.com by hplms2.HP.COM; Sun, 22 Nov 87 12:57:52 pst Return-Path: Received: from hplabsz by hplabsz; Sun, 22 Nov 87 13:57:26 pst To: commonloops.pa@Xerox.COM Cc: gregor.pa@Xerox.COM, harris%hplms2@hplabs.HP.COM Subject: Bug in 8/27/87 Reader/Writer Dcode Generation X-Mailer: mh6.5 Date: Sun, 22 Nov 87 13:57:23 MST Message-Id: <14535.564613043@hplabsz> From: kempf%hplabsz@hplabs.HP.COM The reader and writer dcode, generated in dcode.l by the calls to the DEFINE-FUNCTION-TEMPATE macro, has the following bug. If the argument is not an IWMC class, then the WRAPPER lexical variable is NIL, but WRAPPER is used throughout the following code as if it had a legitimate value. The fix is to check in the LET* whether the WRAPPER is NIL, and to move the no matching method check up to the beginning. There are probably faster ways to do this, but this one works. Anyway, the code is included below. Jim Kempf kempf@hplabs.hp.com ------------------------------------------------------------------------------- (define-function-template all-std-class-readers-dcode () '(.GENERIC-FUNCTION. .CACHE.) (let ((mask (make-generic-function-cache-mask 1))) `(function (lambda (arg) (let* ((wrapper (and (iwmc-class-p arg) (iwmc-class-class-wrapper arg))) ;;;Added the AND. JAK (offset (and wrapper (generic-function-cache-offset ,mask wrapper))) (method nil) (class nil)) ;;;Added check for NULL. JAK (cond ((null wrapper) (no-matching-method .GENERIC-FUNCTION.)) ((eq (r/w-cache-key) wrapper) (get-static-slot--class arg (r/w-cache-val))) ((setq class (class-wrapper-class wrapper) method (lookup-method .GENERIC-FUNCTION. class)) (let* ((slot-name (reader/writer-method-slot-name method)) (slot-pos (slotd-position slot-name (class-instance-slots class)))) (cond ((not (null slot-pos)) ;This is an instance slot. (setq slot-pos (%convert-slotd-position-to-slot-index slot-pos)) (without-interrupts (setf (r/w-cache-key) wrapper) (setf (r/w-cache-val) slot-pos)) (get-static-slot--class arg slot-pos)) (t (slot-value-using-class--class-internal class arg slot-name nil nil))))) (t (no-matching-method .GENERIC-FUNCTION.)))))))) (define-function-template all-std-class-writers-dcode () '(.GENERIC-FUNCTION. .CACHE.) (let ((mask (make-generic-function-cache-mask 1))) `(function (lambda (arg new-value) (let* ((wrapper (and (iwmc-class-p arg) (iwmc-class-class-wrapper arg))) ;;Added AND. JAK. (offset (and wrapper (generic-function-cache-offset ,mask wrapper))) (method nil) (class nil)) ;;Added check for NULL. JAK. (cond ((null wrapper) (no-matching-method .GENERIC-FUNCTION.)) ((eq (r/w-cache-key) wrapper) (setf (get-static-slot--class arg (r/w-cache-val)) new-value)) ((and wrapper (setq class (class-wrapper-class wrapper) method (lookup-method .GENERIC-FUNCTION. class))) (let* ((slot-name (reader/writer-method-slot-name method)) (slot-pos (slotd-position slot-name (class-instance-slots class)))) (cond ((not (null slot-pos)) ;This is an instance slot. (setq slot-pos (%convert-slotd-position-to-slot-index slot-pos)) (without-interrupts (setf (r/w-cache-key) wrapper) (setf (r/w-cache-val) slot-pos)) (setf (get-static-slot--class arg slot-pos) new-value)) (t (put-slot-using-class--class-internal class arg slot-name new-value nil))))) (t (no-matching-method .GENERIC-FUNCTION.))))))))  Received: from Xerox.COM (TCP 1200400040) by AI.AI.MIT.EDU 21 Nov 87 21:31:34 EST Received: from Burger.ms by ArpaGateway.ms ; 21 NOV 87 18:24:25 PST Return-Path: Redistributed: commonloops.pa Received: from hplabs.HP.COM by Xerox.COM ; 21 NOV 87 18:21:49 PST Received: from hplms2.HP.COM (hplms2) by hplabs.HP.COM with SMTP ; Sat, 21 Nov 87 18:21:54 PST Received: from hplabsz.hpl.hp.com by hplms2.HP.COM; Sat, 21 Nov 87 18:21:36 pst Return-Path: Received: from hplabsz by hplabsz; Sat, 21 Nov 87 19:21:13 pst To: commonloops.pa@Xerox.COM Subject: PRINT-OBJECT bug in 8/27 PCL X-Mailer: mh6.5 Date: Sat, 21 Nov 87 19:21:10 MST Message-Id: <9351.564546070@hplabsz> From: kempf%hplabsz@hplabs.HP.COM The default print-object method seems to have a bug. Instead of printing the class name followed by a unique id (as it used to) it now simply prints "Standard-Instance": (defclass foo () (bar)) # (setq f (make-instance 'foo)) # This should be: #  Received: from Xerox.COM (TCP 1200400040) by AI.AI.MIT.EDU 21 Nov 87 20:21:54 EST Received: from Catawba.ms by ArpaGateway.ms ; 21 NOV 87 17:05:00 PST Return-Path: Redistributed: commonloops.pa Received: from hplabs.HP.COM by Xerox.COM ; 21 NOV 87 17:02:23 PST Received: from hplms2.HP.COM (hplms2) by hplabs.HP.COM with SMTP ; Sat, 21 Nov 87 17:02:00 PST Received: from hplabsz.hpl.hp.com by hplms2.HP.COM; Sat, 21 Nov 87 17:01:33 pst Return-Path: Received: from hplabsz by hplabsz; Sat, 21 Nov 87 18:00:54 pst To: Warren Harris Cc: commonloops.pa@Xerox.COM, kempf%hplwhh@hplabs.HP.COM, dsouza%hplwhh@hplabs.HP.COM Subject: Re: :accessor-prefix bug X-Mailer: mh6.5 In-Reply-To: Your message of Tue, 22 Sep 87 13:24:12 -0700. <19804.559340652@hplwhh> Date: Sat, 21 Nov 87 18:00:52 MST Message-Id: <8934.564541252@hplabsz> From: kempf%hplabsz@hplabs.HP.COM > I have uncovered what seems to me to be a bug with :accessor-prefix. For > example: > (defclass foo () > ((this :initform 'a)) > (:accessor-prefix nil)) > (defmethod-setf this ((f foo)) (x) > (print 'here) > (setf (slot-value f 'this) x)) > (defclass bar (foo) > ((this :initform 'b) ; simply define a new initial value > (that :initform 'c)) > (:accessor-prefix nil)) > In class FOO I use :accessor-prefix to generate the THIS and SETF-THIS > methods. The SETF-THIS method is then specialized. In class BAR > :accessor-prefix is supposed to define THA> T and SETF-THAT methods, and > allow the THIS and specialized SETF-THIS methods to be inherited. It > however seems to redefine the SETF-THIS method: > (setq f (make-instance 'foo)) > # > (this f) > A > (setf (this f) 'k) > HERE ; specialized method was run > K > (this f) > K > (setq b (make-instance 'bar)) > # > (this b) > B > (that b) > C > (setf (this b) 'k) > K ; the HERE message is not printed!!! > (this b) > K > A temporary solution is to not use accessor prefix: > (defclass bar (foo) > ((this :initform 'b) > (that :initform 'c :accessor that))) > It would be nice to see :accessor-prefix work correctly though. In reviewing this report, the problem is rather that a SETF method is being generated for the THIS slot of the subclass. This is actually contrary to the 87-002 spec, in which is stated that reader and writer methods are only generated when requested. However, since this is a PCL bug, I would suggest you send the bug to the CommonLoops mailing list. jak  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 20 Nov 87 18:03:21 EST Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 20 Nov 87 14:55:13 PST Received: from Semillon.ms by ArpaGateway.ms ; 20 NOV 87 14:54:54 PST Date: Fri, 20 Nov 87 14:54 PST From: Gregor.pa@Xerox.COM Subject: Re: symbol-macrolet To: common-lisp-object-system@SAIL.STANFORD.EDU cc: kanderso@WILMA.BBN.COM In-Reply-To: <871120094332.9.GREGOR@SPIFF.parc.xerox.com> Message-ID: <871120145418.2.GREGOR@SPIFF.parc.xerox.com> Line-fold: no OK, lets try this again. Maybe I will get it right this time: I am not supposed to have the NOT, and environment is an &environment argument not an &optional argument. Also today is Friday, its daylight, and my name is Gregor. I think I have it now. (defmacro ^2 (form &environment environment) (if (and (symbolp form) (eq (macroexpand-1 form environment) form)) `(* ,form ,form) `(expt ,form 2))) -------  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 20 Nov 87 12:50:52 EST Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 20 Nov 87 09:44:27 PST Received: from Semillon.ms by ArpaGateway.ms ; 20 NOV 87 09:44:09 PST Date: Fri, 20 Nov 87 09:43 PST From: Gregor.pa@Xerox.COM Subject: Re: symbol-macrolet To: kanderso@WILMA.BBN.COM cc: common-lisp-object-system@SAIL.STANFORD.EDU In-Reply-To: The message of 20 Nov 87 03:37 PST from kanderso@WILMA.BBN.COM Message-ID: <871120094332.9.GREGOR@SPIFF.parc.xerox.com> Line-fold: no Date: Fri, 20 Nov 87 06:37:20 -0500 From: kanderso@WILMA.BBN.COM I think there was an obvious bug in your example. How about: (defmacro ^2 (form &optional environment) (if (and (symbolp form) (eq (macroexpand-1 form environment) form) ; <- `(* ,form ,form) `(expt ,form 2))) Oops, you're right. I forgot NOT. Instead it should be: (defmacro ^2 (form &optional environment) (if (and (symbolp form) (not (eq (macroexpand-1 form environment) form))) `(* ,form ,form) `(expt ,form 2))) -------  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 20 Nov 87 06:50:25 EST Received: from [128.89.1.216] by SAIL.STANFORD.EDU with TCP; 20 Nov 87 03:43:30 PST To: Gregor.pa@XEROX.COM cc: common-lisp-object-system@SAIL.STANFORD.EDU Subject: Re: symbol-macrolet In-reply-to: Your message of Thu, 19 Nov 87 17:13:00 -0800. <871119171306.3.GREGOR@SPIFF.isl.parc.xerox.com> Date: Fri, 20 Nov 87 06:37:20 -0500 From: kanderso@WILMA.BBN.COM I think there was an obvious bug in your example. How about: (defmacro ^2 (form &optional environment) (if (and (symbolp form) (eq (macroexpand-1 form environment) form) ; <- `(* ,form ,form) `(expt ,form 2))) I tried to come up with another example. This is more generic (dispatching on whether the form is a symbol or not) but it seems more lame. (defun dispatch (form &optional environment) (if (symbolp form) (setq form (macroexpand-1 form environment))) (if (and (symbolp form) (special-symbol form)) (dispatch-special-symbol form environment) (dispatch-form form envrionment))) k  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 19 Nov 87 20:20:56 EST Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 19 Nov 87 17:13:56 PST Received: from Semillon.ms by ArpaGateway.ms ; 19 NOV 87 17:13:45 PST Date: Thu, 19 Nov 87 17:13 PST From: Gregor.pa@Xerox.COM Subject: symbol-macrolet To: common-lisp-object-system@sail.stanford.edu Message-ID: <871119171306.3.GREGOR@SPIFF.isl.parc.xerox.com> Line-fold: no I suppose we should say explicitly that the symbol macros are recorded in the macroexpansion environment so that macroexpand-1 of a symbol which is a symbol-macro will expand it. In the text in my draft, this would correspond to including something like the following in remarks. Within the body of symbol-macrolet the macroexpansion environment is augmented to include a symbol-macro definition for the symbol. When given the symbol and the environment as arguments, macroexpand-1 will return the expansion. This means that a macro which appears in the scope of symbol-macrolet can use macroexpand-1 to determine whether or not a symbol names a symbol macro; this is particularly useful for macros which want to determine whether or not their argument is a symbol. Examples: (defmacro ^2 (form &optional environment) (if (and (symbolp form) (eq (macroexpand-1 form) environment)) `(* ,form ,form) `(expt ,form 2))) This is a pretty lame example. Hopefully we can come up with something else that is as simple but more compelling. Also, we may want to mention explicitly the zetalisp macro once-only. -------  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 14 Nov 87 18:59:21 EST Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 14 Nov 87 14:52:54 PST Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 279905; Sat 14-Nov-87 17:52:14 EST Date: Sat, 14 Nov 87 17:52 EST From: David A. Moon Subject: questions about CLOS [original subject: equality of structures] To: goldman@vaxa.isi.edu cc: COMMON-LISP@SAIL.STANFORD.EDU, Common-Lisp-Object-System@SAIL.STANFORD.EDU In-Reply-To: <8711092000.AA14975@vaxa.isi.edu> Message-ID: <19871114225202.0.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Mon, 09 Nov 87 12:00:35 PST From: goldman@vaxa.isi.edu Re: the suggestion that CLOS should subsume (by convention or otherwise) uses of un:TYPEed defstruct types? I presume that this takes care of the issue of EQUAL, because the CLOS specifies the semantics of EQUAL for its class instances? (What is the specification, by the way?) CLOS does not currently say anything about how the functions EQUAL, EQUALP, and EQL behave on instances of standard classes (you can read the last four words as equivalent to "user-defined objects"). It also doesn't say anything about the type-specific equality functions CHAR-EQUAL, CHAR-NOT-EQUAL, TREE-EQUAL, STRING-EQUAL, and STRING-NOT-EQUAL, nor the 6 type-specific = and /= functions. It would fit the structure of CLOS to say that EQUAL and EQUALP will be expanded to generic functions whose behavior can be extended by defining methods. I don't think we would want to allow extending EQL or the type-specific functions, since CLOS does not claim to be so powerful as to allow you to create new types of numbers, characters, or strings. Extending EQ would not make any sense, of course. I suspect the reason CLOS currently shys away from EQUAL and EQUALP is that the equality predicates in Common Lisp are clearly not very well chosen and beg for a lot of cleaning up based on a better theory of what we want. To give just one example, it's peculiar that comparing arrays element-by-element has been bundled together with ignoring alphabetic case. It's probably better to wait for Common Lisp to get its act together before extending CLOS into this area; clearly, equality methods can be added later to the standard or to an individual implementation without any incompatibilities, so there's no rush. A possible additional reason is that CLOS does not deal terribly well with symmetric two-argument functions such as EQUAL. It's possible to specialize them, but you usually have to define a lot of seemingly extraneous methods, since the generic function dispatch mechanism has no concept of commutativity nor of type translation. But I would be loathe to replace my un:TYPEed defstructs with DEFCLASSes if I gave up substantial efficiency when I only wanted the limited power provided by the "record structure" semantics. Are there enough declarations available in CLOS so that I could get my compiled accesses to slots of such instances down to the equivalent of an array element reference? As an implementation-independent language specification, CLOS does not and cannot directly address this issue. However, it's clear what would generally need to be declared to allow implementations to do something like that, although you would have to look at each individual implementation to see whether it was faster or slower than arrays with declarations; you might even find an implementation where slot access was faster than array access even without declarations. Basically what you need to declare is that the class cannot be redefined or subclassed. Some members of the CLOS subcommittee volunteered to propose declaration names and syntaxes to allow for this type of optimization, but they haven't finished yet. However, it is intended that most CLOS implementations either be very efficient or have a way to make them very efficient through declarations.  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 13 Nov 87 14:26:13 EST Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 13 Nov 87 11:19:11 PST Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 279096; Fri 13-Nov-87 14:19:05 EST Date: Fri, 13 Nov 87 14:18 EST From: David A. Moon Subject: optimization in the spec To: common-lisp-object-system@SAIL.STANFORD.EDU In-Reply-To: <871111150223.5.GREGOR@SPIFF.isl.parc.xerox.com> Message-ID: <19871113191855.2.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Wed, 11 Nov 87 15:02 PST From: Gregor.pa@Xerox.COM In the latest draft of the spec, there are several places which explicitly address legal optimizations an implementation might perform. I find these somewhat confusing, and I think that instead we might want to do the following: 1- Have an general, well worked out statement about what kinds of optimization are legal in CLOS implementations. This statement would be 'the optimization law'. 2- Have an appendix or implementation notes in the document reflecting places in the design where the intent was to allow optimizations that are in accordance with the 'the optimization law'. I think organizing it this way would be a good idea, although it could involve a lot of work for a relatively small benefit. Also, in some cases, such as object creation, it needs to be noted directly in the document that the semantics have been relaxed to allow for increased optimization. This was a very deliberate decision by the group, as I recall. I don't have a good feel for whether it's better to describe these things in terms of "optimization", as we do now, or simply to say that it is implementation-dependent. The former way has the advantage of motivating the reason for not requiring a particular behavior, while the latter is more like CLtL. As a start on this, here is a first crack on the law. In order to insure program portability, there are strict rules which must be followed when doing optimization of CLOS implementations. The rules governing when error checking and signalling can be optimized away have already been covered. Except where it is explicitly stated that under certain compilation conditions it is permissible not to signal an error, the rule governing optimizations is that no optimization can change the behavior of a program. All optimizations must preserve the semantics of the CLOS. This is just a motherhood statement and begs the question "what, precisely, are the semantics of CLOS." We need to make it clear that no user program will be able to detect optimization (except for the stuff about an error should be signalled). Of course user programs will be able to detect optimization, because we are giving access to implementation-dependent details, for instance through the meta-object protocol. Your statement is almost as strong as "it is impossible to write a Common Lisp program that is not portable." I think what you really mean is that CLOS defines a certain semantics that portable programs can depend on, and optimizations, like everything else, must conform to that semantics. That portable semantics does not fully specify every detail of CLOS execution.  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 13 Nov 87 11:41:26 EST Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 13 Nov 87 08:33:36 PST Received: from relay2.cs.net by RELAY.CS.NET id aa07028; 13 Nov 87 11:18 EST Received: from csl.ti.com by RELAY.CS.NET id aa12107; 13 Nov 87 11:18 EST Received: from Jenner by tilde id AA24782; Fri, 13 Nov 87 09:01:33 CST Message-Id: <2772802735-10721025@Jenner> Date: Fri, 13 Nov 87 08:58:55 CST From: Patrick H Dussud To: common-lisp-object-system@SAIL.STANFORD.EDU Subject: Scope of Call-next-method In-Reply-To: Msg of Thu, 12 Nov 87 14:10 EST from "David A. Moon" I believe it's simpler to say that call-next-method works anywhere in a method than to say it only works some places in a method, thus having to say that if you use it in argument defaulting, you have to do the argument defaulting a different way than you would ordinarily do it. Of course it is simpler to say that call-next-method works anywhere in a method. An example will be make clear the fact that CALL-NEXT-METHOD without arguments uses the method arguments, not its parameters. Patrick.  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 12 Nov 87 21:27:29 EST Received: from SCORE.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 12 Nov 87 18:20:43 PST Received: from hplabs.HP.COM (hplabs.hpl.hp.com.#Internet) by SCORE.STANFORD.EDU with TCP; Thu 12 Nov 87 17:36:47-PST Received: from hplms2.HP.COM (hplms2) by hplabs.HP.COM with SMTP ; Thu, 12 Nov 87 14:38:47 PST Received: from hplabsz.hpl.hp.com by hplms2.HP.COM; Thu, 12 Nov 87 14:38:25 pst Return-Path: Received: from hplabsz by hplabsz; Thu, 12 Nov 87 15:38:00 pst To: Gregor.pa@Xerox.COM Cc: common-lisp-object-system@sail.stanford.edu Subject: Re: optimization in the spec X-Mailer: mh6.5 In-Reply-To: Your message of Wed, 11 Nov 87 15:02:00 -0800. <871111150223.5.GREGOR@SPIFF.isl.parc.xerox.com> Date: Thu, 12 Nov 87 15:37:57 MST Message-Id: <27762.563755077@hplabsz> From: kempf%hplabsz@hplabs.HP.COM > 1- Have an general, well worked out statement about what kinds of > optimization are legal in CLOS implementations. This statement > would be 'the optimization law'. I think the general statement should be that no implementation should perform an optimization which could cause a change in CLOS semantics. This statement might, in fact, be TOO general, since it might rule out things like in-lining slot access, which would cause the class changing protocol to break. But in-lining slot access is a natural optimization to want to do after code has been developed and the class definition stabilizes, when the class changing protocol doesn't matter any more. . So maybe the statement needs to be tied to the safety level. > 2- Have an appendix or implementation notes in the document reflecting > places in the design where the intent was to allow optimizations > that are in accordance with the 'the optimization law'. This is a good idea. The hints on optimization scattered about the document should probably be gathered into an implementation notes appendix, or (less preferable) set off from the text as in CLtL.  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 12 Nov 87 17:18:52 EST Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 12 Nov 87 14:11:24 PST Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 278010; Thu 12-Nov-87 12:22:49 EST Date: Thu, 12 Nov 87 12:22 EST From: David A. Moon Subject: scope of call-next-method To: Gregor.pa@Xerox.COM cc: common-lisp-object-system@SAIL.STANFORD.EDU In-Reply-To: <871111145127.4.GREGOR@SPIFF.isl.parc.xerox.com> Message-ID: <19871112172228.3.MOON@EUPHRATES.SCRC.Symbolics.COM> Line-fold: No Date: Wed, 11 Nov 87 14:51 PST From: Gregor.pa@Xerox.COM This message concerns the scope of call-next-method and next-method-p. Recent drafts of the spec say that the scope of these functions include the default value forms for optional and keyword arguments. I believe that the scope of these should include only the body of the method. I don't see how what the spec currently says can work. The problem is that call-next-method is defined to have access to the bindings of the arguments to the method. No. Call-next-method has access to the arguments. It explicitly does not access the bindings of the parameters (-not- arguments) of the method. But if call-next-method is called during the process of doing those bindings what arguments will it have access to? What arguments will it pass to the next method? I think you've been misled by the arguments/parameters terminology. Even though I'm pretty sure CLtL uses those terms consistently, and I think the CLOS spec does as well, in informal talk people still often get them mixed up, and the two words sound so similar that this is not surprising, especially since other languages use other terminology. Here's a simple example of a way to implement it, although I imagine most implementations would find another way that is less simple but more efficient in that particular implementation. Several obvious improvements to the below will immediately spring to your mind. For instance, it isn't necessary to use &rest. (defmethod foo ((x boat) &optional (y (call-next-method))) (body x y)) ==> (add-method ... (make ... #'(lambda (... &rest #:arguments) (flet ((call-next-method (&rest #:c-n-m-arguments) (apply ... (or #:c-n-m-arguments #:arguments))) (next-method-p () ...)) (apply #'(lambda (x &optional (y (call-next-method))) (body x y)) #:arguments)))))  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 12 Nov 87 17:18:44 EST Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 12 Nov 87 14:11:43 PST Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 278125; Thu 12-Nov-87 14:11:04 EST Date: Thu, 12 Nov 87 14:10 EST From: David A. Moon Subject: scope of call-next-method To: Gregor.pa@Xerox.COM cc: common-lisp-object-system@SAIL.STANFORD.EDU In-Reply-To: <871112105535.3.GREGOR@SPIFF.isl.parc.xerox.com> Message-ID: <19871112191046.2.MOON@EUPHRATES.SCRC.Symbolics.COM> Line-fold: No Date: Thu, 12 Nov 87 10:55 PST From: Gregor.pa@Xerox.COM I would still rather have call-next-method only be valid in the body of the method and let users who want to do defaulting using it do the defaulting by hand in the obvious way. I believe that the model that defmethod wrap an flet around their body is a great deal simpler than the model required to explain the behavior you propose. I believe precisely the opposite, particularly since the way this is explained to users surely does not involve writing out lambda expressions and flets. That's only a way to explain it to implementors. I think you're concentrating too much on the implementation and not enough on the semantics. I propose that we leave call-next-method the way it is and not change it. I believe it's simpler to say that call-next-method works anywhere in a method than to say it only works some places in a method, thus having to say that if you use it in argument defaulting, you have to do the argument defaulting a different way than you would ordinarily do it. By the way, I tried the scoping you propose in Flavors, for the same reason I think: I was concentrating too much on the implementation and not enough on the semantics. My users forced me to change it to the scoping I propose. These were outside users, not Symbolics people.  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 12 Nov 87 16:36:42 EST Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 12 Nov 87 13:30:21 PST Received: from Semillon.ms by ArpaGateway.ms ; 12 NOV 87 10:56:14 PST Date: Thu, 12 Nov 87 10:55 PST From: Gregor.pa@Xerox.COM Subject: scope of call-next-method To: David A. Moon cc: common-lisp-object-system@SAIL.STANFORD.EDU In-Reply-To: <19871112172228.3.MOON@EUPHRATES.SCRC.Symbolics.COM> Message-ID: <871112105535.3.GREGOR@SPIFF.isl.parc.xerox.com> Line-fold: no I would still rather have call-next-method only be valid in the body of the method and let users who want to do defaulting using it do the defaulting by hand in the obvious way. I believe that the model that defmethod wrap an flet around their body is a great deal simpler than the model required to explain the behavior you propose. Just compare: (defmetod foo ((x class)) (body x)) call-next-method only available in body: . #'(lambda (x) (flet ((call-next-method (&rest r) ..)) (body x))) . call-next-method available in body and default value forms: . #'(lambda (&rest #:c-n-m-arguments) (flet ((call-next-method (&rest #:c-n-m-arguments) (apply ... (or #:c-n-m-arguments #:arguments)))) (apply #'(lambda (x) (body x)) #:c-n-m-arguments))) . -------  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 11 Nov 87 18:21:54 EST Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 11 Nov 87 15:06:08 PST Received: from Semillon.ms by ArpaGateway.ms ; 11 NOV 87 15:02:55 PST Date: Wed, 11 Nov 87 15:02 PST From: Gregor.pa@Xerox.COM Subject: optimization in the spec To: common-lisp-object-system@sail.stanford.edu Message-ID: <871111150223.5.GREGOR@SPIFF.isl.parc.xerox.com> Line-fold: no In the latest draft of the spec, there are several places which explicitly address legal optimizations an implementation might perform. I find these somewhat confusing, and I think that instead we might want to do the following: 1- Have an general, well worked out statement about what kinds of optimization are legal in CLOS implementations. This statement would be 'the optimization law'. 2- Have an appendix or implementation notes in the document reflecting places in the design where the intent was to allow optimizations that are in accordance with the 'the optimization law'. As a start on this, here is a first crack on the law. In order to insure program portability, there are strict rules which must be followed when doing optimization of CLOS implementations. The rules governing when error checking and signalling can be optimized away have already been covered. Except where it is explicitly stated that under certain compilation conditions it is permissible not to signal an error, the rule governing optimizations is that no optimization can change the behavior of a program. All optimizations must preserve the semantics of the CLOS. Examples of legal optimizations include: Where the system can determine what methods will be called for a particular invocation of a generic function, it might compile out the method lookup. Where methods have been declared inline (whatever that means) or are system supplied methods, the system might compile calls (like the one above) out entirely. This is just rough, but I hope you can see what I am trying to capture. That is that I am trying to make it clear that except where we say so explicitly, a program can be sure that optimizations won't have weird semantics. For example, the current text that talks about optimizing initarg defaulting makes it sound like I could write a program which could tell that some initarg defaulting had been optimized out. We need to make it clear that no user program will be able to detect optimization (except for the stuff about an error should be signalled). -------  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 11 Nov 87 17:58:02 EST Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 11 Nov 87 14:51:39 PST Received: from Semillon.ms by ArpaGateway.ms ; 11 NOV 87 14:51:59 PST Date: Wed, 11 Nov 87 14:51 PST From: Gregor.pa@Xerox.COM Subject: scope of call-next-method To: common-lisp-object-system@sail.stanford.edu Message-ID: <871111145127.4.GREGOR@SPIFF.isl.parc.xerox.com> Line-fold: no This message concerns the scope of call-next-method and next-method-p. Recent drafts of the spec say that the scope of these functions include the default value forms for optional and keyword arguments. I believe that the scope of these should include only the body of the method. I don't see how what the spec currently says can work. The problem is that call-next-method is defined to have access to the bindings of the arguments to the method. But if call-next-method is called during the process of doing those bindings what arguments will it have access to? What arguments will it pass to the next method? I believe the only model that can work reasonably is that call next method is defined only within the body of the method. So, my model (and proposal) is that: (defmethod foo ((x boat)) (body x)) expands to . . (lambda (x) (flet ((call-next-method (&rest args) ...) (next-method-p () ...)) (body x))) I realize that we could make the rules different for call-next-method and next-method-p, but I think that would be gratuitous complexity and incompatibility. -------  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 11 Nov 87 17:46:59 EST Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 11 Nov 87 14:41:00 PST Received: from Semillon.ms by ArpaGateway.ms ; 11 NOV 87 14:41:46 PST Date: Wed, 11 Nov 87 14:41 PST From: Gregor.pa@Xerox.COM Subject: making gf lambda lists To: common-lisp-object-system@sail.stanford.edu Message-ID: <871111144109.3.GREGOR@SPIFF.isl.parc.xerox.com> Line-fold: no I believe that we are going to want to introduce a support function called something like: make-generic-function-lambda-list-from-specialized-method-lambda-list This function will make it easier for programmers who are constructing their own methods and generic functions to get themselves a congruent generic function lambda list. This functions will strip out specializers and optional defaults and remove uses of &key and &aux (and anything else I might have forgotten). Can anyone think of a better name for this function? Can anyone think of a worse name? -------  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 11 Nov 87 11:04:15 EST Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 11 Nov 87 07:57:29 PST Received: from JUNCO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 277003; Wed 11-Nov-87 10:28:24 EST Date: Wed, 11 Nov 87 10:28 EST From: Sonya E. Keene Subject: Agenda for X3J13 To: RPG@SAIL.Stanford.EDU cc: common-lisp-object-system@SAIL.Stanford.EDU, mathis@C.ISI.EDU In-Reply-To: The message of 10 Nov 87 17:02 EST from Dick Gabriel Message-ID: <19871111152820.2.SKEENE@JUNCO.SCRC.Symbolics.COM> Date: 10 Nov 87 1402 PST From: Dick Gabriel As you know, we ran into a brick wall last week with the specification. The problem is with the question of how much the meta-object level should influence the format and content of chapter 2. The issue is how to decide what to say about the specification of a generic function versus what to say about specific methods. I think there is no question that this level of detail is worth specifying, but the question was how much to try to do before the X3 meeting. It turns out that the very question itself and our initial consideration of it broke our stride enough that we will not be able to have an extensive discussion at X3 because we will not have coherent draft of chapters 1 and 2 in the hands of the X3 members soon enough. Therefore, the following have been decided: 1. There will be no CLOS subcommittee meeting in Colorado. 2. Danny Bobrow, Sonya Keene, and Linda DeMichiel will not attend the meeting. I am going to the X3J13 meeting. 3. Gregor will present an overview of the decisions we made, such as initialization, class redefinition, etc. I'm sorry if this necessitates a change in your travel plans. -rpg-  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 10 Nov 87 17:09:50 EST Date: 10 Nov 87 1402 PST From: Dick Gabriel Subject: Agenda for X3J13 To: common-lisp-object-system@SAIL.Stanford.EDU CC: mathis@C.ISI.EDU As you know, we ran into a brick wall last week with the specification. The problem is with the question of how much the meta-object level should influence the format and content of chapter 2. The issue is how to decide what to say about the specification of a generic function versus what to say about specific methods. I think there is no question that this level of detail is worth specifying, but the question was how much to try to do before the X3 meeting. It turns out that the very question itself and our initial consideration of it broke our stride enough that we will not be able to have an extensive discussion at X3 because we will not have coherent draft of chapters 1 and 2 in the hands of the X3 members soon enough. Therefore, the following have been decided: 1. There will be no CLOS subcommittee meeting in Colorado. 2. Danny Bobrow, Sonya Keene, and Linda DeMichiel will not attend the meeting. 3. Gregor will present an overview of the decisions we made, such as initialization, class redefinition, etc. I'm sorry if this necessitates a change in your travel plans. -rpg-  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 9 Nov 87 17:58:53 EST Received: from SCORE.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 9 Nov 87 14:52:20 PST Received: from hplabs.HP.COM (hplabs.hpl.hp.com.#Internet) by SCORE.STANFORD.EDU with TCP; Mon 9 Nov 87 14:40:25-PST Received: from hplms2 by hplabs.HP.COM with SMTP ; Mon, 9 Nov 87 14:45:00 PST Received: from hplabsz.hpl.hp.com by hplms2; Mon, 9 Nov 87 14:44:45 pst Return-Path: Received: from hplabsz by hplabsz; Mon, 9 Nov 87 15:44:19 pst To: common-lisp-object-system@sail.stanford.edu Subject: Current State of CLOS Draft X-Mailer: mh6.5 Date: Mon, 09 Nov 87 15:44:12 MST Message-Id: <2268.563496252@hplabsz> From: kempf%hplabsz@hplabs.HP.COM Is the current CLOS draft on sail in tex-able source form? If so, are the files the usual ones, or different? Also, has the location, agenda, and time for the meeting next Monday in Fort Collins been set? Thanks. jak  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 6 Nov 87 20:35:35 EST Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 6 Nov 87 17:31:35 PST Received: from Cabernet.ms by ArpaGateway.ms ; 06 NOV 87 17:25:27 PST Date: 6 Nov 87 17:25 PST From: Masinter.pa@Xerox.COM Subject: Re: format for description of generic functions in chapter 2 In-reply-to: David A. Moon 's message of Wed, 4 Nov 87 20:38 EST To: Moon@STONY-BROOK.SCRC.Symbolics.COM cc: common-lisp-object-system@SAIL.STANFORD.EDU Message-ID: <871106-172527-1861@Xerox> "To me lambda-list congruence seems equally applicable to all generic functions and methods, and furthermore it's hard to see how generic functions could work or users could call them if there wasn't lambda-list congruence. . . ." There were numerous discussions of alternate rules for lambda-list congruence than the ones that made it into the spec. Generic functions could implicitly assume that they were defined with &rest, for example, yet allow some methods to have &REST and others &KEY or even a set of &OPTIONAL arguments. Allowing the number of arguments to vary by class seems possible, too, although it might require a run-time test at method entry to determine if the generic function handed on too many arguments for that particular method.  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 6 Nov 87 16:57:21 EST Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 6 Nov 87 13:52:27 PST Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 274069; Fri 6-Nov-87 16:51:53 EST Date: Fri, 6 Nov 87 16:52 EST From: David A. Moon Subject: Re: Defgeneric affects methods? To: Common-lisp-object-system@SAIL.STANFORD.EDU In-Reply-To: <871106-133128-1483@Xerox> Message-ID: <19871106215202.4.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: 6 Nov 87 13:31 PST From: Danny Bobrow RPG: ``Except it does affect existing methods if :method is specified, so....'' Here is an issue brought up by wording problems: do you mean that defgeneric affects the set of existing methods (such as replacing some of them) or that defgeneric affects some individuals because when one is ``replaced'' a method is destructively modified? I think that this is an example where documentation indirection would pay off. Describe what happens when one evaluates a defgeneric with no :method options, and thee is an existing generic function. No existing methods on the existing generic function is changed. Then state that defgeneric with :method options is equivalent to a defgeneric with no :method options follwoed by a set of defmethods. We have said what happens there as well. Similar methods get replaced. I agree with this approach. I think this is the same as what the document already says, provided we remove the one offending remark.  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 6 Nov 87 16:47:39 EST Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 6 Nov 87 13:43:18 PST Received: from Cabernet.ms by ArpaGateway.ms ; 06 NOV 87 13:31:28 PST Date: 6 Nov 87 13:31 PST Sender: Bobrow.pa@Xerox.COM From: Danny Bobrow Subject: Re: Defgeneric affects methods? In-reply-to: Dick Gabriel 's message of 06 Nov 87 10:17 PST To: Common-lisp-object-system@SAIL.Stanford.EDU Message-ID: <871106-133128-1483@Xerox> ``Except it does affect existing methods if :method is specified, so....'' Here is an issue brought up by wording problems: do you mean that defgeneric affects the set of existing methods (such as replacing some of them) or that defgeneric affects some individuals because when one is ``replaced'' a method is destructively modified? I think that this is an example where documentation indirection would pay off. Describe what happens when one evaluates a defgeneric with no :method options, and thee is an existing generic function. No existing methods on the existing generic function is changed. Then state that defgeneric with :method options is equivalent to a defgeneric with no :method options follwoed by a set of defmethods. We have said what happens there as well. Similar methods get replaced.  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 6 Nov 87 15:34:48 EST Received: from SCRC-RIVERSIDE.ARPA by SAIL.STANFORD.EDU with TCP; 6 Nov 87 12:29:23 PST Received: from JUNCO.SCRC.Symbolics.COM by Riverside.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 185747; Fri 6-Nov-87 15:29:00 EST Date: Fri, 6 Nov 87 15:28 EST From: Sonya E. Keene Subject: setf of class-name To: common-lisp-object-system@SAIL.STANFORD.EDU Included-msgs: <19871023233437.7.MOON@EUPHRATES.SCRC.Symbolics.COM>, The message of 23 Oct 87 19:34 EDT from Moon@STONY-BROOK.SCRC.Symbolics.COM, The message of 23 Oct 87 19:34 EDT from David A. Moon Included-References: <871023-154303-1550@Xerox> Message-ID: <19871106202846.9.SKEENE@JUNCO.SCRC.Symbolics.COM> As far as I know, we still believe that setf of class-name should work, but the writeup of class-name in Chapter 2 doesn't mention this. The following forwarded message is the last I've seen on this topic, and it looks like both Dave and Danny believe setf of class-name belongs in the spec. ---------------- Date: Fri, 23 Oct 87 19:34 EDT From: David A. Moon Subject: More on Class names To: Common-Lisp-Object-System@sail.stanford.edu In-Reply-To: <871023-154303-1550@Xerox> Date: 23 Oct 87 15:42 PDT From: Danny Bobrow It should be stated in chapter one that a many-one association from symbols to classes is implemented by symbol-class and (setf symbol-class). An INDEPENDENT association from class to symbol is maintained by class-name and (setf class-name). Neither of these setf functions effects the other association. defclass is specified to do both (setf symbol-class) and (setf class-name). I agree.  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 6 Nov 87 14:28:04 EST Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 6 Nov 87 11:09:16 PST Received: from Semillon.ms by ArpaGateway.ms ; 06 NOV 87 11:07:01 PST Date: Fri, 6 Nov 87 11:06 PST From: Gregor.pa@Xerox.COM Subject: CALL-NEXT-METHOD example To: David A. Moon cc: Gregor.pa@Xerox.COM, LGD@SAIL.STANFORD.EDU, Common-Lisp-Object-System@SAIL.STANFORD.EDU In-Reply-To: <19871106032706.1.MOON@EUPHRATES.SCRC.Symbolics.COM> Message-ID: <871106110624.7.GREGOR@SPIFF.isl.parc.xerox.com> Line-fold: no Date: Thu, 5 Nov 87 22:27 EST From: David A. Moon I don't see why (collect '(a b c)) isn't invalid for the same reason. The list method becomes inapplicable in the recursive call. Oops, your right. What I spaced on at the time was that I wasn't change the applicable set of next methods so it was OK. Should that in fact be the rule? If not, here is a corrected example. (defmethod collect (thing) thing) (defmethod collect ((n number)) (let ((l ())) (dotimes (i n) (push (call-next-method) l)) (reverse l))) (defmethod collect ((l list)) (mapcar #'call-next-method l)) (collect 5) ==> (5 5 5 5 5) (collect '(() () ())) ==> (() () ()) ;;; But note the following erroneous use of call-next-method. ;;; This example would cause an error to be signalled because ;;; the argument which is supplied to call-next-method would ;;; cause a different set of methods to be applicable. (collect '(1 2 3)) -------  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 6 Nov 87 13:22:22 EST Date: 06 Nov 87 1017 PST From: Dick Gabriel Subject: Defgeneric affects methods? To: Common-lisp-object-system@SAIL.Stanford.EDU ``Except it does affect existing methods if :method is specified, so....'' Here is an issue brought up by wording problems: do you mean that defgeneric affects the set of existing methods (such as replacing some of them) or that defgeneric affects some individuals because when one is ``replaced'' a method is destructively modified? -rpg-  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 6 Nov 87 04:26:55 EST Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 5 Nov 87 21:11:35 PST Received: from relay2.cs.net by RELAY.CS.NET id ac10117; 5 Nov 87 17:46 EST Received: from csl.ti.com by RELAY.CS.NET id aa25269; 5 Nov 87 17:45 EST Received: from Jenner by tilde id AA00248; Thu, 5 Nov 87 15:57:44 CST Message-Id: <2772136524-6882684@Jenner> Date: Thu, 5 Nov 87 15:55:24 CST From: Patrick H Dussud To: Common-Lisp-Object-System@SAIL.STANFORD.EDU Subject: Chapter 1 typos. 1-12 First defclass, ) missing. 1-24 Second paragraph, "When a method combination type is defined using the short form of DEFINE-METHOD-COMBINATION, primary methods are defined to include not only the methods qualified with the same name of the type of method combination, but certain others as well". This is not true. Primary methods include only those qualified with the name of the method combination type. Patrick.  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 6 Nov 87 04:07:07 EST Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 5 Nov 87 19:48:30 PST Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 273383; Thu 5-Nov-87 22:48:30 EST Date: Thu, 5 Nov 87 22:48 EST From: David A. Moon Subject: Re: ambiguity in defgeneric and method descriptions To: common-lisp-object-system@SAIL.STANFORD.EDU In-Reply-To: <871105-161832-1644@Xerox> Message-ID: <19871106034841.3.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: 5 Nov 87 16:18 PST From: Danny Bobrow The alternative would be to follow the model of defclass; if the old defclass defined readers or accessors and the new defclass does not, during the redefinition those old methods and generic functions go away. We could make old methods that were defined by the :method option to defgeneric go away, if the new defgeneric doesn't define those methods. Whichever one is right, it's worth another Remark. I agree that it's worth a Remark. I think that it is important that old methods stay around. Consider two applications that define a generic function. They are designed to work independently, and also together. Hence each will have a defgeneric (compatible of course, since they were meant to work together), and each will independently define methods, say with their :method options. The fact the the second one does not have the same methods as the first should not invalidate the first, I think. I have to agree with this argument, even though I feel that such a pair of applications is poorly structured and should have a shared "definitions" module that contains one defgeneric. Remember we're not forcing you to put all your method definitions into :method options (except in generic-flet, generic-labels, and generic-function). The model I have is that defgeneric updates the generic function with respect to its metaclass, method class, etc. but does not affect existing methods. Except it does affect existing methods if :method is specified, so this argument isn't going to tell us anything about the case that Sonya brought up. Instead we have to say: "Note, defgeneric can add methods, and can replace methods, but never removes a method." An error is signalled for any compatibility problem of course. This is the same as the old model. As you can see in some cases there are sources for the other methods, and in others not (what happens now when you simply edit a file to remove a defmethod or defun form?) That depends on how smart your editor is. But surely if it understands removing a defmethod it can understand removing a :method option from a defgeneric.  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 6 Nov 87 04:05:26 EST Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 5 Nov 87 19:27:14 PST Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 273360; Thu 5-Nov-87 22:26:51 EST Date: Thu, 5 Nov 87 22:27 EST From: David A. Moon Subject: CALL-NEXT-METHOD example To: Gregor.pa@Xerox.COM cc: LGD@SAIL.STANFORD.EDU, Common-Lisp-Object-System@SAIL.STANFORD.EDU In-Reply-To: <871105181642.6.GREGOR@SPIFF.isl.parc.xerox.com> Message-ID: <19871106032706.1.MOON@EUPHRATES.SCRC.Symbolics.COM> Line-fold: No Date: Thu, 5 Nov 87 18:16 PST From: Gregor.pa@Xerox.COM Here is an example which could be used for the call-next-method section. Its somewhat of a silly example, but I believe it captures several important points about call-next-method. Namely its basic behavior, how it defaults the argument when no arguments are passed, that it is a true lexical function, and that it is possible to pass it arguments, (defmethod collect (thing) thing) (defmethod collect ((n number)) (let ((l ())) (dotimes (i n) (push (call-next-method) l)) (reverse l))) (defmethod collect ((l list)) (mapcar #'call-next-method l)) (collect 5) ==> (5 5 5 5 5) (collect '(a b c)) ==> (A B C) ;;; But note the following erroneous use of call-next-method. ;;; This example would cause an error to be signalled because ;;; the argument which is supplied to call-next-method would ;;; cause a different set of methods to be applicable. (collect '(1 2 3)) ------- I don't see why (collect '(a b c)) isn't invalid for the same reason. The list method becomes inapplicable in the recursive call.  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 5 Nov 87 21:22:06 EST Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 5 Nov 87 18:17:23 PST Received: from Semillon.ms by ArpaGateway.ms ; 05 NOV 87 18:17:08 PST Date: Thu, 5 Nov 87 18:16 PST From: Gregor.pa@Xerox.COM Subject: CALL-NEXT-METHOD example To: LGD@SAIL.STANFORD.EDU cc: Common-Lisp-Object-System@SAIL.STANFORD.EDU Message-ID: <871105181642.6.GREGOR@SPIFF.isl.parc.xerox.com> Line-fold: no Here is an example which could be used for the call-next-method section. Its somewhat of a silly example, but I believe it captures several important points about call-next-method. Namely its basic behavior, how it defaults the argument when no arguments are passed, that it is a true lexical function, and that it is possible to pass it arguments, (defmethod collect (thing) thing) (defmethod collect ((n number)) (let ((l ())) (dotimes (i n) (push (call-next-method) l)) (reverse l))) (defmethod collect ((l list)) (mapcar #'call-next-method l)) (collect 5) ==> (5 5 5 5 5) (collect '(a b c)) ==> (A B C) ;;; But note the following erroneous use of call-next-method. ;;; This example would cause an error to be signalled because ;;; the argument which is supplied to call-next-method would ;;; cause a different set of methods to be applicable. (collect '(1 2 3)) -------  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 5 Nov 87 20:33:09 EST Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 5 Nov 87 17:26:39 PST Received: from relay2.cs.net by RELAY.CS.NET id ae08957; 5 Nov 87 16:34 EST Received: from csl.ti.com by RELAY.CS.NET id ad24858; 5 Nov 87 16:32 EST Received: from Jenner by tilde id AA28983; Thu, 5 Nov 87 15:08:06 CST Message-Id: <2772133532-6702890@Jenner> Date: Thu, 5 Nov 87 15:05:32 CST From: Patrick H Dussud To: common-lisp-object-system@SAIL.STANFORD.EDU Subject: Re: format for description of generic functions in chapter 2 In-Reply-To: Msg of Thu, 5 Nov 87 09:44 PST from Gregor.PA@xerox.com, Bobrow.PA@xerox.com Actually, I disagree with one detail of what Gregor said. I can't understand why lambda-list congruence should be restricted to standard generic functions and standard methods. To me lambda-list congruence seems equally applicable to all generic functions and methods, and furthermore it's hard to see how generic functions could work or users could call them if there wasn't lambda-list congruence. Thus I think congruence is part of the contract of add-method, and should not be demoted to association with a particular method. I (Gregor) still disagree with you about this. More in a separate message. I will be interested in seeing what prompted Gregor to disagree. It seems to me that it is bad if you have to know the class of a generic function, and find out about the lambda congruence rule for this class, in order to know that your program is calling it properly. I doubt that you will gain much power from changing the lambda list congruence rule and it seems that this "flexibility" will bring confusion. Here's the big problem with this new breakout of methods and generic functions: We are uncovering a significant amount of confusion about what is the contract of a generic function, versus what is a property of particular methods for that generic function. In effect all of the issues and uncertainties surrounding meta-objects have suddenly leaked into the part of the document that we thought was almost finished. I'm really opposed to that because I think it sets us back a long way. It's really not necessary to resolve all those issues to get something that is entirely useful to someone who is just going to call these generic functions and not define new methods for them. On the other hand, I do think the introduction of the method signatures was a good idea, and I think the format as described in the quotation from RPG above is a good idea. If we can keep the documentation in the style of the sample class-changed writeup, I'll be happy with the new format, but if we're going to get bogged down in all these modularity issues, I want no part of it. Its true that this new breakout causes us to confront some meta-object stuff which we don't really want to have to work out in the next 5 days. But, it may be alright if we just take our best stab at it and then fix it up later. Here's why. We believe that for the time being, the only kind of programming we are really sanctioning is programming that calls these generic functions (in cases like add-method). In these cases, we should take our best shot, but if in the course of writing the meta spec we decide we need to move something from method to gf or vice versa we can. Because as far as the user who just calls generic functions like add-method, the behavior of the generic function as a whole will be unchanged. As a point of strategy, where we are unsure, behavior should be ascribed to the generic function rather than the one of the methods. I like this strategy. I don't have any problems with the agreement reached in each case. Patrick.  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 5 Nov 87 19:38:55 EST Date: 05 Nov 87 1631 PST From: Dick Gabriel Subject: State of Affairs To: common-lisp-object-system@SAIL.Stanford.EDU I've completed the major pass on chapter 1 that Gregor's comments required. The result so cleaned it up that I made a second major pass and I now believe chapter 1 to be very close to complete. The state of affairs with chapter 2 now greatly concerns me. To illustrate this, let me comment on one of the comments that Moon made about the selected function pages that we put out for comment. Regarding CHANGE-CLASS Moon writes: ``change-class: the second remarks paragraph is a remark about the generic function as a whole, and has nothing to do with the specific method to which it is attached.'' That remarks paragraph states: ``This method on {\bf change-class} has several semantic difficulties. First, it performs a destructive operation that can be invoked within a method on an instance that was used to select that method. When multiple methods are involved because methods are being combined, the methods currently executing or about to be executed may no longer be applicable. Second, some implementations might use compiler optimizations of slot access, and when the class of an instance is changed the assumptions the compiler made might be violated. This implies that a programmer must not use this method on {\bf change-class} inside a method if any methods for that generic function access any slots, or else the results are undefined.'' The semantic problem is that the class of the instance is altered while the generic function is operating. One can argue that this is a change of identity in some semantic domain. The fact that this is related to a ``destructive operation'' depends on the representation of the instance, which depends on its metaclass which depends on the fact that the instance is an instance of standard-object, because its class is standard-class. This appears to be something specific to this method or constellation of methods. The same reasoning holds for the mention of the compiler messing around with optimizations of slot access - I've heard some metaclasses say ``what's a slot?'' Therefore, the semantic difficulty is best expressed in both places: There is a semantic difficulty with the generic function because we choose to specify that whatever else it does it alters the class of an instance. And this can happen in the middle of a method combination that might involve running those other methods on a now-non-applicable instance. This method happens to compound the problem by messing with the representation in some way, invalidating the compiler's assumptions. Therefore, the comment Moon makes serves to raise a much harder issue of how close to the bone we cut our distinctions. Notice that LGD and I gave this some amount of thought, because the Purpose entry for the generic function states that the generic function changes the class, while the one for this main method talks about the destructiveness of the operation. What has to be pointed out is that even if we choose to back out of any changes made to the format of chapter 2 in the last 4 days (this amounts to little or no work), we now know that the wording that we have been using is very imprecise with respect to a level of precision to which we could rationally aspire. This Remark, if left in a version of chapter 2 with the older format, mixes up the general activities and meaning of a very abstract entity (a generic function) with the activities and meaning of a specific method. Let me state at this point that LGD and I have neither interest nor motivation to want to take a shot at sorting this out by ourselves. And I can easily see this group, even in a face-to-face meeting, arguing for weeks about the wording and exact breakdown of what is said when and where. What's worse, our selection procedure was to pick the first 4 or 5 function pages in chapter 2 to try, not the hardest 4 or 5, and I'm not sure that we could totally resolve CHANGE-CLASS in under 4 days of discussion at the current bandwidth. Therefore, I leave it to you folks to decide how to proceed. -rpg-  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 5 Nov 87 19:30:43 EST Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 5 Nov 87 16:23:10 PST Received: from Cabernet.ms by ArpaGateway.ms ; 05 NOV 87 16:18:32 PST Date: 5 Nov 87 16:18 PST Sender: Bobrow.pa@Xerox.COM From: Danny Bobrow Subject: Re: ambiguity in defgeneric and method descriptions In-reply-to: Sonya E. Keene 's message of Thu, 5 Nov 87 15:31 EST To: skeene@STONY-BROOK.SCRC.Symbolics.COM cc: common-lisp-object-system@SAIL.STANFORD.EDU Message-ID: <871105-161832-1644@Xerox> That makes perfect sense, but I think it brings up another point to clarify. What happens if no method descriptions are specified in this defgeneric, but there is an existing generic function with methods? Have we decided what happens then? I don't remember any discussion about it. In the old days of defgeneric (before method descriptions), we said that no methods were affected when a generic function was redefined. If that still holds in the current scheme, the users might be faced with an interesting pitfall. If the old defgeneric included a method description and the new one doesn't, then the Lisp world will contain a method, but there won't be any source of that method. The alternative would be to follow the model of defclass; if the old defclass defined readers or accessors and the new defclass does not, during the redefinition those old methods and generic functions go away. We could make old methods that were defined by the :method option to defgeneric go away, if the new defgeneric doesn't define those methods. Whichever one is right, it's worth another Remark. I think that it is important thatold methods stay around. Consider two applications that define a generic function. They are designed to work independently, and also together. Hence each will have a defgeneric (compatible of course, since they were meant to work together), and each will independently define methods, say with their :method options. The fact the the second one does not have the same methods as the first should not invalidate the first, I think. The model I have is that defgeneric updates the generic function with respect to its metaclass, method class, etc. but does not affect existing methods. An error is signalled for any compatibility problem of course. This is the same as the old model. As you can see in some cases there are sources for the other methods, and in others not (what happens now when you simply edit a file to remove a defmethod or defun form?) danny  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 5 Nov 87 18:52:25 EST Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 5 Nov 87 15:44:53 PST Received: from Cabernet.ms by ArpaGateway.ms ; 05 NOV 87 15:38:10 PST Date: 5 Nov 87 15:37 PST Sender: Bobrow.pa@Xerox.COM From: Danny Bobrow Subject: Re: lambda-list in defgeneric, generic-flet, etc. In-reply-to: David A. Moon 's message of Thu, 5 Nov 87 12:25 EST To: Moon@STONY-BROOK.SCRC.Symbolics.COM cc: Bobrow.pa@Xerox.COM, Common-Lisp-Object-System@SAIL.STANFORD.EDU Message-ID: <871105-153810-1563@Xerox> Thank you for the longer answer. I find the arguments convincing enough (that is enough to stop arguing). I am convinced now that it is SMOT (small matter of taste), and with you, Dick and Gregor agreeing, my taste buds must be off. danny  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 5 Nov 87 16:55:10 EST Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 5 Nov 87 12:30:32 PST Received: from JUNCO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 272978; Thu 5-Nov-87 15:31:19 EST Date: Thu, 5 Nov 87 15:31 EST From: Sonya E. Keene Subject: ambiguity in defgeneric and method descriptions To: common-lisp-object-system@SAIL.STANFORD.EDU Message-ID: <19871105203106.7.SKEENE@JUNCO.SCRC.Symbolics.COM> Page 2-29: the defgeneric section, the first two paragraphs under Remarks: The first paragraph is: "If a method already exists on the given generic function with the same parameter specializers and the same qualifers, defgeneric replaces the existing method with the one now being defined." My question is, "the same as what?" I suggest clarifying it along these lines: "If a method already exists on the given generic function with the same parameter specializers and the same qualifers as any method description given in this defgeneric form, that existing method is replaced with the one now being defined." The second paragraph is: "If ano method descriptions are specified and a generic function of the same name does not already exist, a generic function with no methds is created." That makes perfect sense, but I think it brings up another point to clarify. What happens if no method descriptions are specified in this defgeneric, but there is an existing generic function with methods? Have we decided what happens then? I don't remember any discussion about it. In the old days of defgeneric (before method descriptions), we said that no methods were affected when a generic function was redefined. If that still holds in the current scheme, the users might be faced with an interesting pitfall. If the old defgeneric included a method description and the new one doesn't, then the Lisp world will contain a method, but there won't be any source of that method. The alternative would be to follow the model of defclass; if the old defclass defined readers or accessors and the new defclass does not, during the redefinition those old methods and generic functions go away. We could make old methods that were defined by the :method option to defgeneric go away, if the new defgeneric doesn't define those methods. Whichever one is right, it's worth another Remark.  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 5 Nov 87 12:57:07 EST Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 5 Nov 87 09:50:35 PST Received: from Semillon.ms by ArpaGateway.ms ; 05 NOV 87 09:44:49 PST Date: Thu, 5 Nov 87 09:44 PST From: Gregor.PA@Xerox.COM, Bobrow.PA@Xerox.COM Sender: Gregor.pa@GRAPEVINE.isl.parc.xerox.com Subject: format for description of generic functions in chapter 2 To: David A. Moon cc: common-lisp-object-system@SAIL.STANFORD.EDU In-Reply-To: <19871105013806.6.MOON@EUPHRATES.SCRC.Symbolics.COM> File-References: DOMAIN|SAIL.STANFORD.EDU:NEW.DVI[CLS], SCRC|S:>Moon>LSP].babyl.newest Message-ID: <871105094413.1.GREGOR@SPIFF.isl.parc.xerox.com> Line-fold: no Date: Wed, 4 Nov 87 20:38 EST From: David A. Moon First off, we want to say that we think the new method signature stuff is a good idea and looks good overall. Too much of the text in a method signature is italicized. Only the parameter names should be italicized; the parentheses, lambda-list keywords, and parameter specializer names should be in should be in a roman font or a typewriter font; this would be more consistent with the style used elsewhere. Right. I don't think we can reasonably restrict implementations from defining other methods. Such a restriction would be inutile in any case, since CLOS programs are obviously allowed to define other methods, and we want to allow multiple programs to coexist in the same Lisp. Thus any program that assumes that only the methods defined in this chapter exist is not going to be a good citizen of the Lisp world. However, what we can say is something like only the standard methods will be applicable to standard objects; I think that is not precisely what I mean, but something along those lines; the intent is that you can add new methods to extend the behavior of the functions, but you're not supposed to break the behavior of existing methods. Right, this is hard to word, but we are going to have to make some stab at it. We will try to take a stab at this later. Date: Wed, 4 Nov 87 10:58 PST Actually, I disagree with one detail of what Gregor said. I can't understand why lambda-list congruence should be restricted to standard generic functions and standard methods. To me lambda-list congruence seems equally applicable to all generic functions and methods, and furthermore it's hard to see how generic functions could work or users could call them if there wasn't lambda-list congruence. Thus I think congruence is part of the contract of add-method, and should not be demoted to association with a particular method. I (Gregor) still disagree with you about this. More in a separate message. This sounds very good to me, but the actual file doesn't seem to do it precisely this way. In particular, the values and remarks are frequently associated with a particular method where they should be associated with the generic function as a whole. To me, values have the same status as arguments, both are part of the interface that the generic function contracts to supply, and which all methods must conform to. Sometimes there will be additional method-specific things to say about arguments or values, and then the method can have one or both of those fields, but the generic function should always have the arguments and values fields, and I think the normal case will be that only the generic function will have these fields. Another problem is with ordering of fields. In several cases, method descriptions intervene between two parts of the generic function description. Often the remarks and the examples come after the methods. I think this is wrong, especially in light of Sonya's last comment above; I think the methods should always be at the end, with nothing after them except the See also field. Right. Here are some comments on specific pages of the sample new format, and then I'll address what I think is the general problem with this new format. add-method has too much in the method section and not enough in the generic-function section. In fact I don't think there is anything to be said about the method specifically; everything that is there now is the contract of the generic function as a whole, to which all methods must conform. Gregor disagrees with me about the congruence part, but not the rest of it. Not exactly. We think both the second paragraph of the arguments section and the second paragraph of the remarks section should be put under method remarks. Briefly, the point is that a user should be free to define a new kind of method that say doesn't have qualifiers or a new kind of generic function which uses different congruence rules. The value returned should be in the generic function, its has to be eq to the first argument. change-class: the second remarks paragraph is a remark about the generic function as a whole, and has nothing to do with the specific method to which it is attached. Right The first remarks paragraph, in contrast, applies just to this method, although I think it's important for the generic function as a whole to undertake to call class-changed; the only need for a method-specific remark about class-changed is to document exactly when class-changed is called by that particular method. Right Maybe that detailed remark is unnecessary? It is needed class-changed: I feel this page is an example of good organization, much better than the other pages. The division between generic-function and method is exactly right. Right class-name: I think the method signature is wrong; surely class-name works on all classes, not just standard ones. Surely (class-name (class-of (cons 1 2))) returns something, even though we don't guarantee that it returns the symbol CONS in all implementations (it could be the name of an implementation-dependent subclass of CONS). In the current meta object draft, all those classes are (believe it or not), subclasses of standard class. So, this is right according to that. We had a long discussion with Pierre Cointe about this, that is included in the meta-object draft we are (finally) writing. describe: again I think the method signatures are wrong. What we require is that there be an applicable method for every object that exists, not that there be a method on the class T. I complained about this before when it was in English, I think, and I'm complaining about it again when it's in method signatures. This started as a typo and now is turning into an explicit specification. I also don't think we want to require that a method exist for the exact class standard-object, although I feel less strongly about that. In the cases of describe and print-object, I think no method signatures should be listed, and then we should say that the implementation provides enough predefined methods to assure that there is always an applicable method, but we do not standardize the precise parameter specializers of these methods. If we do anything else we are dictating how the PRINT function is modularized, which is not our business. describe: the documentation of the methods here is useless. I suggest that the format should permit omission of documentation of methods when the documentation wouldn't say anything. Right, Right, Right... Here's the big problem with this new breakout of methods and generic functions: We are uncovering a significant amount of confusion about what is the contract of a generic function, versus what is a property of particular methods for that generic function. In effect all of the issues and uncertainties surrounding meta-objects have suddenly leaked into the part of the document that we thought was almost finished. I'm really opposed to that because I think it sets us back a long way. It's really not necessary to resolve all those issues to get something that is entirely useful to someone who is just going to call these generic functions and not define new methods for them. On the other hand, I do think the introduction of the method signatures was a good idea, and I think the format as described in the quotation from RPG above is a good idea. If we can keep the documentation in the style of the sample class-changed writeup, I'll be happy with the new format, but if we're going to get bogged down in all these modularity issues, I want no part of it. Its true that this new breakout causes us to confront some meta-object stuff which we don't really want to have to work out in the next 5 days. But, it may be alright if we just take our best stab at it and then fix it up later. Here's why. We believe that for the time being, the only kind of programming we are really sanctioning is programming that calls these generic functions (in cases like add-method). In these cases, we should take our best shot, but if in the course of writing the meta spec we decide we need to move something from method to gf or vice versa we can. Because as far as the user who just calls generic functions like add-method, the behavior of the generic function as a whole will be unchanged. As a point of strategy, where we are unsure, behavior should be ascribed to the generic function rather than the one of the methods. Generic functions like describe and print-object are different, these we have to try and get right this go around. Thats probably tractable, Moon's comments above seem to hit it on the nose. -------  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 5 Nov 87 12:29:56 EST Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 5 Nov 87 09:24:51 PST Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 272765; Thu 5-Nov-87 12:25:42 EST Date: Thu, 5 Nov 87 12:25 EST From: David A. Moon Subject: lambda-list in defgeneric, generic-flet, etc. To: Danny Bobrow cc: Common-Lisp-Object-System@SAIL.STANFORD.EDU In-Reply-To: <871104-180558-2820@Xerox> Supersedes: <19871105172001.2.MOON@EUPHRATES.SCRC.Symbolics.COM> Message-ID: <19871105172557.3.MOON@EUPHRATES.SCRC.Symbolics.COM> Line-fold: No Never mind the one-word answer. It's clear that the lambda-list is needed sometimes. It's needed for &key, it's needed for :argument-precedence-order, and it's needed when no methods are specified. It's also needed if the lambda-list serves as documentation and the most appropriate and explanatory parameter names are different for the generic function than for the method. The question is whether to allow the lambda-list to be omitted in some cases. You seem to be concerned about the redundancy when there is exactly one method specified. Obviously if there are no methods there is no redundant lambda-list, and if there is more than one method specified in the defgeneric or generic-flet or what have you, there is redundancy anyway. My feeling is that making the syntax more cumbersome and less consistent, by making the lambda-list optional, in order to eliminate this tiny bit of redundancy, is not worthwhile. Also I think the redundancy can be justified as a valuable sanity check. Another interesting piece of experience is that the syntax of :method in defgeneric in Flavors tries to avoid such redundancy. It has a lambda-list for the defgeneric, but no lambda-list for the methods, just a parameter specializer name (to use CLOS terminology). I think that experience with this has shown that it was a bad idea and that it would have been better to have the redundancy for the sake of a more consistent syntax.  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 5 Nov 87 12:23:56 EST Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 5 Nov 87 09:19:02 PST Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 272759; Thu 5-Nov-87 12:19:47 EST Date: Thu, 5 Nov 87 12:20 EST From: David A. Moon Subject: lambda-list in defgeneric To: Danny Bobrow cc: Common-Lisp-Object-System@SAIL.STANFORD.EDU In-Reply-To: <871104-180558-2820@Xerox> Message-ID: <19871105172001.2.MOON@EUPHRATES.SCRC.Symbolics.COM> Line-fold: No I'll try a one-word answer, and if that doesn't work, I'll try to find the time to write a detialed explanation. &key.  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 4 Nov 87 23:52:11 EST Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 4 Nov 87 20:45:57 PST Received: from Cabernet.ms by ArpaGateway.ms ; 04 NOV 87 18:05:58 PST Date: 4 Nov 87 18:05 PST Sender: Bobrow.pa@Xerox.COM From: Danny Bobrow Subject: Re: Comment on the chapter 2, Version of Nov 2. In-reply-to: David A. Moon 's message of Tue, 3 Nov 87 18:13 EST To: Moon@STONY-BROOK.SCRC.Symbolics.COM cc: Common-Lisp-Object-System@SAIL.STANFORD.EDU Message-ID: <871104-180558-2820@Xerox> Date: 3 Nov 87 10:29 PST From: Danny Bobrow 2-21 syntax replace {slot-option}* by [[^ slot-option]] and use {:accessor generic-function-name}* {:reader generic-function-name}* {:initarg name}* as the last three items of slot-option. Then the remarks on which options can appear more than once in Arguments are redundant. Stylistic comment: I hope we are not changing the style so that it is impossible for a reader who skips over the BNF syntax notation to understand the document. I think that would be most unfortunate. I'd much rather have a little redundancy than make it necessary to understand the fine points of this increasingly obscure notation in order to understand the document. I agree. I just wanted to make the syntax be complete. 2-26 The syntax of defgeneric now shows a lambda-list as a required argument. I thought :lambda-list was supposed to be a keyword argument. Similarly for generic-labels, generic-flet, generic-function, and with-added-methods. When there are method descriptions provided, the lambda-list is often redundant, and hence can be a cause for mistakes. My notes from the meeting show that there was no required lambda-list, at least for the generic-labels, generic-flet, generic-function, and with-added-methods. Hence by extension, there should not be a required lambda-list in defgeneric. I don't think we agreed in the meeting to remove these lambda-lists. My copies of the draft documents from the meeting show the lambda-list (along with a bunch of other stuff) missing in the first version of some writeups, but present in the second version that we produced after discussion and rationalization of the syntax of all the things having to do with generic functions. Perhaps you got mixed up on which version was newer? There are no dates on these pages but at the meeting I wrote "old" or something on the older ones. You are probably right about the cause for the mixup. But the issue remains whether lambda-list should be required. For most uses of these forms, I can't see really wanting a lambda-list e.g. just (ensure-generic-function 'foo) followed by defmethods, or where one has the methods for a generic-flet (etc) and hence doesn't need the lambda-list unless the :argument-precedence-order option is used. I still can't remember an argument for making it required. Can you remind me please.  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 4 Nov 87 20:44:33 EST Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 4 Nov 87 17:37:06 PST Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 272368; Wed 4-Nov-87 20:37:58 EST Date: Wed, 4 Nov 87 20:38 EST From: David A. Moon Subject: format for description of generic functions in chapter 2 To: common-lisp-object-system@SAIL.STANFORD.EDU In-Reply-To: The message of 4 Nov 87 13:18 EST from Dick Gabriel , <871104105832.6.GREGOR@SPIFF.isl.parc.xerox.com>, <19871104201026.2.SKEENE@JUNCO.SCRC.Symbolics.COM>, The message of 4 Nov 87 18:32 EST from Dick Gabriel File-References: SAIL.STANFORD.EDU:NEW.DVI[CLS], SCRC|S:>Moon>LSP].babyl.newest Message-ID: <19871105013806.6.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: 04 Nov 87 1018 PST From: Dick Gabriel I propose, then, that the policy of CLOS be that purpose statements be promoted to apply to generic functions whenever feasible. I agree with that. However, the new.dvi file that is a sample of the new format does not seem to be written that way. Lengthy comments about this below, but first a relatively minor comment on the format. Too much of the text in a method signature is italicized. Only the parameter names should be italicized; the parentheses, lambda-list keywords, and parameter specializer names should be in should be in a roman font or a typewriter font; this would be more consistent with the style used elsewhere. This brings up the second general point, which is are we going to require that a pristine CLOS have all and only the methods described in the specification? Danny's proposed rewrite of the description of CHANGE-CLASS implies he believes so. I tend to favor the restriction. Currently there is a statement in the introduction to Chapter 2 that states: ``Any implementation of the \CLOS\ is allowed to provide other methods for the generic functions described in this chapter.'' Opinions? I don't think we can reasonably restrict implementations from defining other methods. Such a restriction would be inutile in any case, since CLOS programs are obviously allowed to define other methods, and we want to allow multiple programs to coexist in the same Lisp. Thus any program that assumes that only the methods defined in this chapter exist is not going to be a good citizen of the Lisp world. However, what we can say is something like only the standard methods will be applicable to standard objects; I think that is not precisely what I mean, but something along those lines; the intent is that you can add new methods to extend the behavior of the functions, but you're not supposed to break the behavior of existing methods. Date: Wed, 4 Nov 87 10:58 PST From: Gregor.pa@Xerox.COM For example, in print-object, an implementation should be free to have methods on as many of its pre-defined classes as it likes, but it should not be allowed to define print-object methods on user-defined classes behind said user's back. Yes, that expresses it pretty well. Date: 04 Nov 87 10:18 PST From: Dick Gabriel I propose, then, that the policy of CLOS be that purpose statements be promoted to apply to generic functions whenever feasible. Whenever 'reasonable' is more like it. For example, the purpose of the add-method generic function is to add a method to a generic function. If there is already a similar method an error is signalled. The generic function is completely updated to know about the new method. The particular method on (standard-gf standard-method), has some of its own private behavior as well. For example, it defines what it means for methods to be similar in this case (same qualifiers and specializers). It also defines what the lambda-list congruence rules will be. So its not a matter of whenever feasible, its a matter of reasoning it out on a case by case basis. I agree with this. The new.dvi writeup for add-method isn't written this way, though. More about this below. Actually, I disagree with one detail of what Gregor said. I can't understand why lambda-list congruence should be restricted to standard generic functions and standard methods. To me lambda-list congruence seems equally applicable to all generic functions and methods, and furthermore it's hard to see how generic functions could work or users could call them if there wasn't lambda-list congruence. Thus I think congruence is part of the contract of add-method, and should not be demoted to association with a particular method. Date: Wed, 4 Nov 87 15:10 EST From: Sonya E. Keene I like the new method signatures. They give good information in a concise format. However, I don't believe that a Method Signature is redundant with Syntax. I agree. I think the new.dvi format addresses this pretty well. We should be recommending that people learn about the generic function first, and then (if necessary) learn about the individual methods. I agree 100% and I think the new.dvi format is deficient in this respect. More about this below. Date: 04 Nov 87 1532 PST From: Dick Gabriel The general format is to start the page with a description of what the generic function syntax, the method signatures of all methods specified, the purpose of the generic function, its values, and remarks about it. The reader should be able to look at the top 4 inches of a function page and see the generic function lambda list and the method signatures. Then there is a line that separates the generic function material from the method descriptions. Each method description repeats the signature, adds any method-specific purpose, values, remarks etc. This sounds very good to me, but the actual file doesn't seem to do it precisely this way. In particular, the values and remarks are frequently associated with a particular method where they should be associated with the generic function as a whole. To me, values have the same status as arguments, both are part of the interface that the generic function contracts to supply, and which all methods must conform to. Sometimes there will be additional method-specific things to say about arguments or values, and then the method can have one or both of those fields, but the generic function should always have the arguments and values fields, and I think the normal case will be that only the generic function will have these fields. Another problem is with ordering of fields. In several cases, method descriptions intervene between two parts of the generic function description. Often the remarks and the examples come after the methods. I think this is wrong, especially in light of Sonya's last comment above; I think the methods should always be at the end, with nothing after them except the See also field. Here are some comments on specific pages of the sample new format, and then I'll address what I think is the general problem with this new format. add-method has too much in the method section and not enough in the generic-function section. In fact I don't think there is anything to be said about the method specifically; everything that is there now is the contract of the generic function as a whole, to which all methods must conform. Gregor disagrees with me about the congruence part, but not the rest of it. change-class: the second remarks paragraph is a remark about the generic function as a whole, and has nothing to do with the specific method to which it is attached. The first remarks paragraph, in contrast, applies just to this method, although I think it's important for the generic function as a whole to undertake to call class-changed; the only need for a method-specific remark about class-changed is to document exactly when class-changed is called by that particular method. Maybe that detailed remark is unnecessary? class-changed: I feel this page is an example of good organization, much better than the other pages. The division between generic-function and method is exactly right. class-name: I think the method signature is wrong; surely class-name works on all classes, not just standard ones. Surely (class-name (class-of (cons 1 2))) returns something, even though we don't guarantee that it returns the symbol CONS in all implementations (it could be the name of an implementation-dependent subclass of CONS). describe: again I think the method signatures are wrong. What we require is that there be an applicable method for every object that exists, not that there be a method on the class T. I complained about this before when it was in English, I think, and I'm complaining about it again when it's in method signatures. This started as a typo and now is turning into an explicit specification. I also don't think we want to require that a method exist for the exact class standard-object, although I feel less strongly about that. In the cases of describe and print-object, I think no method signatures should be listed, and then we should say that the implementation provides enough predefined methods to assure that there is always an applicable method, but we do not standardize the precise parameter specializers of these methods. If we do anything else we are dictating how the PRINT function is modularized, which is not our business. describe: the documentation of the methods here is useless. I suggest that the format should permit omission of documentation of methods when the documentation wouldn't say anything. Here's the big problem with this new breakout of methods and generic functions: We are uncovering a significant amount of confusion about what is the contract of a generic function, versus what is a property of particular methods for that generic function. In effect all of the issues and uncertainties surrounding meta-objects have suddenly leaked into the part of the document that we thought was almost finished. I'm really opposed to that because I think it sets us back a long way. It's really not necessary to resolve all those issues to get something that is entirely useful to someone who is just going to call these generic functions and not define new methods for them. On the other hand, I do think the introduction of the method signatures was a good idea, and I think the format as described in the quotation from RPG above is a good idea. If we can keep the documentation in the style of the sample class-changed writeup, I'll be happy with the new format, but if we're going to get bogged down in all these modularity issues, I want no part of it.  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 4 Nov 87 19:55:30 EST Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 4 Nov 87 16:47:32 PST Received: from Cabernet.ms by ArpaGateway.ms ; 04 NOV 87 16:14:31 PST Date: 4 Nov 87 16:14 PST Sender: Bobrow.pa@Xerox.COM From: Danny Bobrow Subject: Re: Issues raised by comments on chapter 2 In-reply-to: Sonya E. Keene, Dick Gabriel To: common-lisp-object-system@sail.stanford.edu Message-ID: <871104-161431-2659@Xerox> After pondering Dick's and Sonya's messages, I take back my plea for non-redundancy (I usually favor redundancy anyway). Syntax is useful, and I think Method Signatures should include all the arguments, including keyword names, optionals (as they did for make-instance in the version of Nov 2). Sonya's characterization of the different questions answered by Syntax and Method Signatures is helpful. How do I call this g-f? --Answered by Syntax What methods are guaranteed to exist for this g-f? --Answered by Method Signature Some other comments: ---- RPG: One reason to describe the arguments in English is to introduce some simple noun phrase to use to talk about these arguments. I also agree with Dick's comment. The redundancy I found slightly distressing was where Arguments gave type restrictions on specialized arguments (e.g. The {\it method} argument is a method object.). I am all in favor of English. ---- RPG: I propose, then, that the policy of CLOS be that purpose statements be promoted to apply to generic functions whenever feasible. This is the place that the contract for the genric function is described. --- Danny writes about CHANGE-CLASS: ``Remove Syntax section, Remove first two lines of Arguments. The last sentence should read "... and then invokes the first method with the class returned as value from (symbol-class symbol)."'' Therefore the purpose of the second method must say something like: RPG answers: ``This method invokes CHANGE-CLASS on {\it instance} and (symbol-class {\it symbol}).'' I agree with Dick. A much better wording of what I intended. ------ RPG: This brings up the second general point, which is are we going to require that a pristine CLOS have all and only the methods described in the specification? Danny's proposed rewrite of the description of CHANGE-CLASS implies he believes so. I tend to favor the restriction. I don't know what I said to generate this idea. I think I believe the statement above. But I don't know what criteria are appropriate. What are the criteria for Common Lisp implementations. Must they have just the types and functions specified in CTtL. Or is it only the using up of symbols that count (i.e. Can an implementation have functions and types whose names the ordinary user doesn't see?). If so, are extra methods (which don't have names) more like types and functions whose names are in another package, or like symbols. For example, CLOS specifies only one method for describe. Could special methods for describe specialized to pathnames or streams etc. be defined. Isn't this an implemenation decision relative to putting the code to discriminate these types in the default method, or in separate methods? Finally, I appreciate the spirit in which Dick wrote his response: The points are made as a response to a message that Danny sent, but no one should interpret this as picking on his comments, which simply serve to bring some decisions to light.  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 4 Nov 87 15:16:32 EST Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 4 Nov 87 12:09:55 PST Received: from JUNCO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 272050; Wed 4-Nov-87 15:10:51 EST Date: Wed, 4 Nov 87 15:10 EST From: Sonya E. Keene Subject: method signatures To: common-lisp-object-system@sail.stanford.edu Message-ID: <19871104201026.2.SKEENE@JUNCO.SCRC.Symbolics.COM> I like the new method signatures. They give good information in a concise format. However, I don't believe that a Method Signature is redundant with Syntax. When readers look in the specification for a generic function such as ADD-METHOD, there are two different kinds of information they might be seeking: How do I call this g-f? --Answered by Syntax What methods are guaranteed to exist for this g-f? --Answered by Method Signature Yes, I know that the reader can divine the answer to the first question by looking at the Method Signature. But it takes a little bit of parsing with your eyes, and I think we should spare our readers from that. Actually, the more I think about this, the more strongly I feel about it. Here's more of my reasoning: If we remove Syntax for all generic functions that have Method Signatures, we are skewing our specification in a certain way. We are essentially suggesting that users should be able to divine information about a generic function by looking at one or more methods. But this is entirely backwards. We should be recommending that people learn about the generic function first, and then (if necessary) learn about the individual methods.  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 4 Nov 87 14:15:39 EST Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 4 Nov 87 11:04:21 PST Received: from Semillon.ms by ArpaGateway.ms ; 04 NOV 87 10:59:02 PST Date: Wed, 4 Nov 87 10:58 PST From: Gregor.pa@Xerox.COM Subject: Issues raised by comments on chapter 2 To: Dick Gabriel cc: common-lisp-object-system@SAIL.Stanford.EDU In-Reply-To: The message of 4 Nov 87 10:18 PST from Dick Gabriel Message-ID: <871104105832.6.GREGOR@SPIFF.isl.parc.xerox.com> Line-fold: no Date: 04 Nov 87 10:18 PST From: Dick Gabriel . . The spirit of object-oriented programming, I guess, states that users can define whatever the hell they like for methods. The spirit of reasonable abstraction states that users should be required to choose their own random names for their random methods, leaving ADD-METHOD for methods that add methods to generic functions. I propose, then, that the policy of CLOS be that purpose statements be promoted to apply to generic functions whenever feasible. Whenever 'reasonable' is more like it. For example, the purpose of the add-method generic function is to add a method to a generic function. If there is already a similar method an error is signalled. The generic function is completely updated to know about the new method. The particular method on (standard-gf standard-method), has some of its own private behavior as well. For example, it defines what it means for methods to be similar in this case (same qualifiers and specializers). It also defines what the lambda-list congruence rules will be. So its not a matter of whenever feasible, its a matter of reasoning it out on a case by case basis. . . ``Any implementation of the \CLOS\ is allowed to provide other methods for the generic functions described in this chapter.'' I think this should be changed so that we can make this statement about some generic functions and not others. Even in the cases where we say its OK to have more methods we are going to want some language for placing some restrictions on where there could be methods. For example, in print-object, an implementation should be free to have methods on as many of its pre-defined classes as it likes, but it should not be allowed to define print-object methods on user-defined classes behind said user's back. Of course what is really causing all the problem here is that none of us has any real idea what a 'protocol' is or how to specify one. -------  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 4 Nov 87 13:31:09 EST Date: 04 Nov 87 1025 PST From: Dick Gabriel Subject: Lambda-list in Defgeneric To: common-lisp-object-system@SAIL.Stanford.EDU In my notes I have the typeset version of the description of DEFGENERIC that we discussed at the Palo Alto meeting, and there are inked-in changes on it. The changes moved things around, but left the lambda-list as required. I also have the hand-written notes that Sonya, I think, took during the discussion before I produced the typeset version and from which the typeset version was derived, and it has the lambda-list as required. -rpg-  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 4 Nov 87 13:23:18 EST Date: 04 Nov 87 1018 PST From: Dick Gabriel Subject: Issues raised by comments on chapter 2 To: common-lisp-object-system@SAIL.Stanford.EDU This message is about the format for description of generic functions in chapter 2. The points are made as a response to a message that Danny sent, but no one should interpret this as picking on his comments, which simply serve to bring some decisions to light. Danny writes: ``I think that if there is a method signature, there should not be a section called Syntax. They are to some extent redundant, and where they are not, Syntax was almost always wrong.'' Hm. I should have written the class redefinition section `wrong', then we could have eliminated that too. Renaming ``Syntax'' to ``Generic Function Syntax'' is useful when the generic function lambda-list is important to know - that is, when it doesn't derive from the method lambda-lists. Think of INITIALIZE-INSTANCE. And maybe it's generally useful for people who are populating their CLOS with additional methods. `` This is the first example of the redundancy. Please take out Syntax, and the first two sentences under Arguments....'' If I do that, here's the result: ****************************************************************************** Method Signatures: add-method (generic-function standard-generic-function) (method standard-method) Arguments: The lambda-list of the method function must be congruent with the lambda-lists of all other methods associated with the generic function and with the lambda-list of the generic function, or else an error is signaled. ****************************************************************************** Unfortunately, there is no method function mentioned. There is a larger liklihood that this would mean the method function of the argument passed to {\it method}, I suppose. A rewording of this could be: ``The lambda-list of the method function of the method object passed as {\it method} must be congruent with the lambda-lists of all other methods associated with the generic function and with the lambda-list of the generic function, or else an error is signaled.'' One reason to describe the arguments in English is to introduce some simple noun phrase to use to talk about these arguments. Danny goes on: ``The signature specifies what the types of the arguments must be, and if people add another method the arguments need not be those objects.'' This brings up the interesting point. We have a heading called ``Purpose:''. Linda and I spent several hours last night trying to redesign the generic function pages, and the question of when the purpose should be written as the purpose of the generic function and when it should be the purpose of some method. Here is an example, again ADD-METHOD. **************************************************************************** Purpose: The generic function add-method adds a method to a generic function. It destructively modifies the generic function and returns the modified generic function as its result. **************************************************************************** ADD-METHOD has 1 method defined. This purpose could be moved to describe the purpose of that method. If we do that, then any additional methods are not constrained to have any particular behavior or purpose. For instance, ADD-METHOD when applied to 2 matrices could add them - it is the add method, after all. The purpose when left as a description of the generic function requires implementors to define only methods for ADD-METHOD that satisfy that purpose. The spirit of object-oriented programming, I guess, states that users can define whatever the hell they like for methods. The spirit of reasonable abstraction states that users should be required to choose their own random names for their random methods, leaving ADD-METHOD for methods that add methods to generic functions. I propose, then, that the policy of CLOS be that purpose statements be promoted to apply to generic functions whenever feasible. Danny writes about CHANGE-CLASS: ``Remove Syntax section, Remove first two lines of Arguments. The last sentence should read "... and then invokes the first method with the class returned as value from (symbol-class symbol)."'' The last sentence cannot say this unless you are imagining that the two methods on CHANGE-CLASS are defined as follows: Use LABELS to make two functions, one that assumes a class as its second argument and one that assumes a symbol as its second argument. Have the second invoke the first (as a function) with (symbol-class symbol) as its second argument. Now take these two functions and make method objects out of them with the usual paraphenalia and stuff them into CHANGE-CLASS using ADD-METHOD. I don't think this is what we mean. Therefore the purpose of the second method must say something like: ``This method invokes CHANGE-CLASS on {\it instance} and (symbol-class {\it symbol}).'' This is particularly relevant when the spirit of object-oriented programming encourages us to write random methods for CHANGE-CLASS, and we certainly want those methods to get a second crack at the instance in this case. This brings up the second general point, which is are we going to require that a pristine CLOS have all and only the methods described in the specification? Danny's proposed rewrite of the description of CHANGE-CLASS implies he believes so. I tend to favor the restriction. Currently there is a statement in the introduction to Chapter 2 that states: ``Any implementation of the \CLOS\ is allowed to provide other methods for the generic functions described in this chapter.'' Opinions? -rpg-  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 3 Nov 87 18:22:15 EST Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 3 Nov 87 15:12:29 PST Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 271203; Tue 3-Nov-87 18:13:30 EST Date: Tue, 3 Nov 87 18:13 EST From: David A. Moon Subject: Comment on the chapter 2, Version of Nov 2. To: Common-Lisp-Object-System@SAIL.STANFORD.EDU In-Reply-To: <871103-103734-2963@Xerox> Message-ID: <19871103231327.6.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: 3 Nov 87 10:29 PST From: Danny Bobrow 2-21 syntax replace {slot-option}* by [[^ slot-option]] and use {:accessor generic-function-name}* {:reader generic-function-name}* {:initarg name}* as the last three items of slot-option. Then the remarks on which options can appear more than once in Arguments are redundant. Stylistic comment: I hope we are not changing the style so that it is impossible for a reader who skips over the BNF syntax notation to understand the document. I think that would be most unfortunate. I'd much rather have a little redundancy than make it necessary to understand the fine points of this increasingly obscure notation in order to understand the document. 2-26 The syntax of defgeneric now shows a lambda-list as a required argument. I thought :lambda-list was supposed to be a keyword argument. Similarly for generic-labels, generic-flet, generic-function, and with-added-methods. When there are method descriptions provided, the lambda-list is often redundant, and hence can be a cause for mistakes. My notes from the meeting show that there was no required lambda-list, at least for the generic-labels, generic-flet, generic-function, and with-added-methods. Hence by extension, there should not be a required lambda-list in defgeneric. I don't think we agreed in the meeting to remove these lambda-lists. My copies of the draft documents from the meeting show the lambda-list (along with a bunch of other stuff) missing in the first version of some writeups, but present in the second version that we produced after discussion and rationalization of the syntax of all the things having to do with generic functions. Perhaps you got mixed up on which version was newer? There are no dates on these pages but at the meeting I wrote "old" or something on the older ones. More comments later, perhaps.  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 3 Nov 87 17:55:49 EST Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 3 Nov 87 14:47:12 PST Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 271163; Tue 3-Nov-87 17:48:12 EST Date: Tue, 3 Nov 87 17:47 EST From: David A. Moon Subject: CLOS mailing list To: mcvax!crin.crin.fr!masini@uunet.UU.NET, masini@crin.crin.fr cc: Common-Lisp-Object-System@SAIL.STANFORD.EDU In-Reply-To: <562946603/masini@crin.crin.fr> Message-ID: <19871103224748.5.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Tue, 3 Nov 87 16:04:18 +0200 From: mcvax!crin.crin.fr!masini@uunet.UU.NET We are currently making a study about Object Oriented Languages, their past, present and future. I've been told you were mailing news about the conception and the evolution of CLOS. Is it possible for me to be added to your mailing list ? This mailing list is a working group developing a specification for a proposed new object-oriented addition to Common Lisp. It's not really a news group. There is heavy traffic with a great amount of detail, so I suspect this isn't really the list you want to be on.  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 3 Nov 87 17:04:41 EST Received: from UUNET.UU.NET by SAIL.STANFORD.EDU with TCP; 3 Nov 87 13:54:48 PST Received: from mcvax.UUCP by uunet.UU.NET (5.54/1.14) with UUCP id AA08285; Tue, 3 Nov 87 16:55:32 EST From: mcvax!crin.crin.fr!masini@uunet.UU.NET Received: by mcvax.cwi.nl; Tue, 3 Nov 87 22:35:56 +0100 (MET) Received: by inria.inria.fr; Tue, 3 Nov 87 16:21:56 +0100 (MET) Date: Tue, 3 Nov 87 16:04:18 +0200 Received: by crin.crin.fr, Tue, 3 Nov 87 16:04:18 +0200 Subject: CLOS mailing list To: Common-Lisp-Object-System@sail.stanford.edu Message-Id: <562946603/masini@crin.crin.fr> We are currently making a study about Object Oriented Languages, their past, present and future. I've been told you were mailing news about the conception and the evolution of CLOS. Is it possible for me to be added to your mailing list ? Thanks in any case. Gerald MASINI, CRIN (Centre de Recherche en Informatique de Nancy) email: masini@crin.crin.fr post: CRIN B.P. 239 54506 Vandoeuvre-les-Nancy Cedex FRANCE phone: +33 83.91.21.45  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 3 Nov 87 13:58:12 EST Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 3 Nov 87 10:45:09 PST Received: from Cabernet.ms by ArpaGateway.ms ; 03 NOV 87 10:37:34 PST Date: 3 Nov 87 10:29 PST Sender: Bobrow.pa@Xerox.COM From: Danny Bobrow Subject: Comment on the chapter 2, Version of Nov 2. To: Common-Lisp-Object-System@SAIL.STANFORD.EDU cc: Bobrow.pa@Xerox.COM Message-ID: <871103-103734-2963@Xerox> General Comment: Much improved again. Having method signatures makes a big difference. I think that if there is a method signature, there should not be a section called Syntax. They are to some extent redundant, and where they are not, Syntax was almost always wrong. 2-8 This is the first example of the redundancy. Please take out Syntax, and the first two sentences under Arguments. The signature specifies what the types of the arguments must be, and if people add another method the arguments need not be those objects. For example, suppose someone wanted to add a method: add-method (s symbol) (lambda-exp listp) where s was supposed to name a generic function and lambda-exp was a list for a function, then the statements under arguments would be untrue. 2-9 Last sentence of third paragraph "It defines the next method ... " --> "The standard method combination type defines the next method ... " (I garden pathed on the "It") 2-11 The environment argument is only mentioned. There is no statement here, or later for symbol-class, etc about what it means to have the environment. So for example, "(cboundp 'foo e1) returns true if foo is bound to a class IN THE ENVIRONMENT DENOTED BY e1." 2-12 Second paragraph, first sentence should read "If in the old class there is ANY slot of the same name as any LOCAL slot in the new class, the value of that slot is unchanged" Remove Syntax section, Remove first two lines of Arguments. The last sentence should read "... and then invokes the first method with the class returned as value from (symbol-class symbol)." In Remarks section, you can put the comment (if you want) about possible extensions to objects that are not standard class. But I would just leave it out as redundant with the introductory statement about generic-functions being extendable. Examples: you need an :initarg :x and :initarg :y in the defclass to have the make-instance work on the next page. 2-13 Remarks: Second sentence "... can be used to assign values to slots in the transformed instance." Next paragraph: Third sentence might read better as "The methods currently executing may no longer be applicable." The complication of combined methods is not worth the confusion here, I think. 2-17 Purpose: Try "... and returns a symbol. This symbol is not guaranteed to be the name of this class. See remarks below." Remove Syntax. Remarks: It is possible that C /= (symbol-class(class-name C)). For example: (defclass foo () (a)) (defclass bar () (b)) (setq f1 (symbol-class foo)) (setq f2 (symbol-class bar)) (setf (symbol-class foo) f2) (class-name f1) --> foo (class-name (symbol-class 'foo)) --> bar 2-19 Purpose: "... name a class IN AN ENVIRONMENT". Remarks: It sounds like the symbol is somehow spoiled (" the symbol is no longer usable as the name of a type"). Why not say something like "the symbol is no longer associated with a class that defines a type." 2-21 syntax replace {slot-option}* by [[^ slot-option]] and use {:accessor generic-function-name}* {:reader generic-function-name}* {:initarg name}* as the last three items of slot-option. Then the remarks on which options can appear more than once in Arguments are redundant. 2-22 First paragraph. "... the definition of that class is replaced FOR INSTANCES OF STANDARD-CLASS." 2-23 para 2 "... is not allowed as an abbreviation for the syntax (slotname :initform). THIS IS DIFFERENT THAN DEFSTRUCT." 2-24 First sentence, same as for p 2-22 " ... class is guaranteeed to be redefined for classes that are instances of standard-class." 2-26 The syntax of defgeneric now shows a lambda-list as a required argument. I thought :lambda-list was supposed to be a keyword argument. Similarly for generic-labels, generic-flet, generic-function, and with-added-methods. When there are method descriptions provided, the lambda-list is often redundant, and hence can be a cause for mistakes. My notes from the meeting show that there was no required lambda-list, at least for the generic-labels, generic-flet, generic-function, and with-added-methods. Hence by extension, there should not be a required lambda-list in defgeneric. 2-27 "The :argument-precedence-order option has a value which is a permutation of the list of required arguments for generic function. It is used to specify the order in which the required arguments ... When the :argument-precedence-order is given, then an explicit lambda-list for the generic function must be given. ..." Example: (defgeneric char-to-stream (:lambda-list (char stream &optional font)) (:argument-precedence-order (stream char))) Is this the correct syntax, or should it be: (defgeneric char-to-stream (:lambda-list char stream &optional font) (:argument-precedence-order stream char)) I don't like this as well. 2-40 Remove Syntax for describe 2-41 Remove Syntax for documentation (Here it specifies that the second argument is optional and we cannot specialize on optional arguments). If Common Lisp has it as optional, then the signatures must only be on the first type, with constraints specified in English on the optional argument. 2-43 Purpose: Remove second sentence , that is "If name does not specify a generic function, an error is signalled." 2-44 "The keyword arguments correspond to the option arguments of defgeneric, except that the :method-class and the :generic-function-class can be class objects as well as names." 2-45, 2-47, 2-49 Remark about required lambda-list again. 2-55 This description of make-instance is just wrong. The signatures are wrong (they are off a metalevel). They would be appropriate signatures for initialize-instance It should say something like Method Signatures: make-instance (class standard-class) &key &rest initargs Arguments: The initargs arguments are explicitly checked within make-instance by the generic function check-initargs. These initargs are the union of the keyword arguments allowed for all applicable methods on initialize-instance, and the :initarg options of the class. See the section on Object Creation. For instances of particular classes, see the description of the initialize-instance method. --- Then if we want we can put in the remarks section on initialize-instance the arguments that each of the initialize-instance methods take. [[However, I would prefer to see these in Chapter 3 under the descriptions of the classes]] initialize-instance (class standard-class) &key :direct-superclasses :direct-slots :options The :direct-superclasses argument is a list of symbols (class names) or class objects. The :direct-slots argument is a list of slot-description objects (see chapter 3) and the :options is a list of the type accepted by defclass as class options, except :metaclass is not allowed. initialize-instance (gfn standard-generic-function) &key :lambda-list ... initialize-instance (method standard-method) &key ... 2-58 Purpose (Why is this one plural?) "... when defclass has been used to redefine an existing class WITH METACLASS standard-class." Remove Syntax Arguments: The class argument is a class object whose instances are to be made obsolete. 2-59 Next to last paragraph. "... the result is a form that calls the first method, M1, and arranges for call-next-method to reach the next method, M2, in the list. An invocation of call-next-method in M2 reaches the following method, M3, and this continues through the methods in the order they appear in method-list. If a call-next-method is invoked by the last method in method-list, an error is signaled." 2-64 Remove Syntax. Remove comment in purpose about method on standard-generic-function signals an error (It appears 6 lines below) 2-67 Remove syntax. Remove first two sentences of Arguments. 2-74 Again something needs to be said about relationship of name and environment. 2-80 It needs to be said that if name is bound to a macro, then an error is signalled. 2-82 There are quote marks that are missing around slot-entry in all calls to slot-value. e.g. (slot-value #:Temp 'slot-entry1)  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 3 Nov 87 11:13:21 EST Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 3 Nov 87 08:01:45 PST Received: from relay2.cs.net by RELAY.CS.NET id ae02430; 3 Nov 87 10:36 EST Received: from csl.ti.com by RELAY.CS.NET id af06989; 3 Nov 87 10:32 EST Received: from dsg by tilde id AA24093; Tue, 3 Nov 87 08:36:00 CST Received: From Jenner By dsg Via CHAOS-NET With CHAOS-MAIL; Tue, 3 Nov 87 08:01:35 CST Message-Id: <2771935258-3166612@Jenner> Date: Tue, 3 Nov 87 08:00:58 CST From: Patrick H Dussud To: Common-Lisp-Object-System@SAIL.STANFORD.EDU Subject: Comment on the chapter 2. In the Oct 26 draft, page 2-65(slot-boundp), 2-67(slot-makunbound), 2-70(slot-value), in the remarks field, the call to SLOT-MISSING is incorrect. INSTANCE must be added after (CLASS-OF INSTANCE). Patrick.  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 2 Nov 87 17:26:38 EST Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 2 Nov 87 14:17:28 PST Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 270177; Mon 2-Nov-87 17:18:28 EST Date: Mon, 2 Nov 87 17:18 EST From: David A. Moon Subject: Comments on chapter 2 To: Common-Lisp-Object-System@SAIL.STANFORD.EDU Message-ID: <19871102221820.9.MOON@EUPHRATES.SCRC.Symbolics.COM> Page numbers are from the Oct 26 10:17 draft, but I've omitted comments on things that are already fixed in the source in the latest version on SAIL. 2-10: Cross-reference to ``Changing Classes'', which has been renamed. Example hasn't been updated yet to realize that rho is the radius and theta is the angle. 2-11: First remarks paragraph: this could just speak of classes whose metaclass is standard-class, without worrying about whether or not the :metaclass option was specified, similar to the way some similar text was fixed up in chapter 1 recently. Not edited for standard-type-class removal yet. The phrase "After completing all other actions, {\bf change-class} invokes the generic function {\bf class-changed}." is somewhat unclear as to what "all other actions" are, maybe some text got lost here. This should be improved when the business of who evaluates the :initforms is straightened out. 2-12: Cross reference to ``Redefining Classes'' should be to ``Changing the Class of an Instance''. 2-14: Cross reference to ``Changing Classes'' should be to ``Changing the Class of an Instance''. 2-39: missing quote mark in (documentation (setf symbol) 'function). I forget if this one was already commented upon. 2-54: under make-instance, we have "The {\bf :function} argument is the method function. The length of the list of specializers must be equal to the number of required arguments of the method function, or else an error is signaled." Since Common Lisp doesn't require implementations to be able to determine the number of required arguments of a function, given the function, I don't see how this requirement to signal an error can be implemented. We might have to make this the same less stringent error checking that CLtL prescribes for calling a function with the wrong number of arguments. Also as mentioned before this section will need to discuss more about the relations between the method lambda-list and the method function lambda-list. 2-55: The first Purpose ("Purposes"?) sentence for make-instances-obsolete is misleading. Not every defclass redefinition calls this, it's only guaranteed to be called under the circumstances described on 1-13. Also there is a conflict between the value of make-instances-obsolete being eq to the class argument, and the class argument being allowed to be a name of a symbol; just needs the wording cleaned up a little. Also I'm not sure what the remark "The generic function {\bf make-instances-obsolete} is invoked only on classes that are instances of {\bf standard-class}." means; does this mean the user is not allowed to invoke it on other classes, or is this more of the statement under Purpose of when defclass invokes this? 2-70: I think we ought to mention that the typical implementation will compile slot-value inline, or somehow efficiently, in methods. Users need to have some rough idea of what sort of efficiency to expect, and reading the document the way it is right now would tend to lead the naive reader to think that CLOS slots are much less efficient to access than defstruct slots, whereas the intention has clearly been that there be only a minor efficiency cost for using CLOS slots, at least in the majority of implementations. We don't have to give the details (except maybe in the meta-object chapter), but we ought to mention the possibility of optimization. 2-72: In the first remarks paragraph for symbol-macrolet, "expansion" is probably supposed to be in italics. At least, I think what is intended here is to say that the scope does not include the -expansion- forms that are substituted for the -symbols-. At first I thought "expansion" referred to the result of expanding the invocation of symbol-macrolet. 2-73: First sentence for update-instance-structure is missing "be". Also this hasn't been updated yet to reflect the division of labor between caller and primary method that has been adopted in chapter 1. 2-77: The remarks for with-added-methods still speak of modifying an existing generic function. This needs to be rephrased in terms of defaulting the values of these options, for the newly-created generic function, from their values in the existing generic function. 2-79: "The macro {\bf with-slots} can be used inside a method or inside any function." implies it can't be used at top level, but that's not what we mean to say.  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 2 Nov 87 16:39:27 EST Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 2 Nov 87 13:29:52 PST Received: from Semillon.ms by ArpaGateway.ms ; 02 NOV 87 13:30:42 PST Date: Mon, 2 Nov 87 13:30 PST From: Gregor.pa@Xerox.COM Subject: :accessor slot option To: Common-Lisp-Object-System@Sail.Stanford.edu Message-ID: <871102133014.0.GREGOR@SPIFF.isl.parc.xerox.com> Line-fold: no I have become uncomfortable with the :reader and :accessor slot options. Right now, at the very least, I would like to add a :writer option, I may also want to remove or rename the :accessor option. The :writer option would work in the obvious way: (defclass foo () ((a :reader foo-a :writer (setf foo-a)))) This would allow someone who wanted to define a writer but no reader to do it, it also makes the mapping onto the new setf proposal more explicit. I agree that in cases where you want both a reader and a writer its probably too verbose, so we probably need to keep the :accessor option, but what if we renamed it, maybe to :reader-writer or perhaps :accessors. Or it may just be that re-reading that part of the spec will make me happy. -------  Received: from Xerox.COM (TCP 1200400040) by AI.AI.MIT.EDU 31 Oct 87 04:01:07 EST Received: from Chardonnay.ms by ArpaGateway.ms ; 31 OCT 87 00:46:32 PST Return-Path: Redistributed: commonloops.pa Received: from maui.cs.ucla.edu by Xerox.COM ; 31 OCT 87 00:44:17 PST Return-Path: Received: by maui.cs.ucla.edu (Sendmail 5.57.1/1.12) id AA03045; Sat, 31 Oct 87 00:32:56 PST Message-Id: <8710310832.AA03045@maui.cs.ucla.edu> To: CommonLoops.PA@Xerox.COM Subject: CLOS over KCL ... Date: Sat, 31 Oct 87 00:32:54 PST From: Leonid V. Belyaev Is anyone out there using CLOS over Kyoto CommonLISP? If so, please conatct me at the above e-mail address. Thanks. Leo Belyaev, UCLA/LCAIRC.  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 30 Oct 87 17:31:55 EST Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 30 Oct 87 14:22:23 PST Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 268751; Fri 30-Oct-87 17:23:14 EST Date: Fri, 30 Oct 87 17:22 EST From: David A. Moon Subject: comments on portions of the Oct 26 10:05 draft To: Common-Lisp-Object-System@SAIL.STANFORD.EDU Message-ID: <19871030222257.1.MOON@EUPHRATES.SCRC.Symbolics.COM> In general the document is greatly improved and I'm fairly happy with it, execpt for these last few points. I've excluded comments on things that appeared to be already fixed in the TEX source, since I was reading an unproofread draft. Also I tried to avoid duplications others' comments. 1-10: "A subclass inherits methods in the sense that any method applicable to an instance of a class is also applicable to instances of any subclass of that class (all other arguments to the method being the same)." At the beginning of the second line, should "an instance" be "all instances" so as to avoid any questions about methods-on-individuals? 1-17: "Note that instances of standard-type classes are disjoint with all other types." This is wrong, type disjointness of standard-type classes is controlled by CLtL, not by us. The previous draft said "Note that instances of standard classes are type disjoint with all other types" and I think the switch from standard classes to standard-type classes was an editing error. In the "built-in-class" stuff I mailed out last night, I included a suggested rewrite that more explicitly conveys the idea that I think this paragraph was hinting at. 1-19 top of page: the explanation of looping precedence order is too complicated, I don't think we really need double indices here. Can't we just say C1 through Cn, n>=2, where each precedes the next and also Cn precedes C1? I think trying to call Cn C2 was what complicated the notation. 1-19 last paragraph before examples: I still think this should be generalized to cover relatively separated subgraphs whose common element is not T, as I said in earlier comments. 1-23 2nd para: "When a new {\bf defgeneric} form is evaluated and a generic function of the given name already exists, the existing generic function object is modified. This does not modify any of the methods associated with the generic function." except for modifications as a result of :method options in the defgeneric. 1-23 2nd bullet: "The lambda-list of the new method must be congruent with the lambda-list of the generic function or else an error is signaled." applies to both new and redefined methods, i.e. both bullets, so this should not be inside the second bullet. It looks like it and the cross-referenced to congruence should be a separate paragraph immediately after the bullets, preceding the paragraph about what happens when no generic function by that name already exists. 1-24: "...parameter specializers are used in the functional interface to method creation ({\bf make-instance} of {\bf standard-method} and {\bf g