Received: from Xerox.COM (TCP 1200400040) by AI.AI.MIT.EDU 21 May 87 22:31:31 EDT Received: from Cabernet.ms by ArpaGateway.ms ; 21 MAY 87 18:30:09 PDT Date: 21 May 87 18:28 PDT From: Gregor.pa@Xerox.COM Subject: Re: EXCL 2.0 FASL FILE ORDERING BUG WITH PCL In-reply-to: Rob Pettengill 's message of Tue, 19 May 87 16:39:32 CDT To: rcp@MCC.COM cc: CommonLoops.pa@Xerox.COM Message-ID: <870521-183009-1973@Xerox> The new version of PCL deals with this problem automatically. Unless you are describing a different problem, the problems isn't really that ExCL (or any of the other lisps which have this problem) reorder forms in the FASL file, its that they allow themselves to group forms. This can cause a load-time-eval which follows a defclass to actually be evaluated before a defclass. This happens when you use call-next-method. The canonical way to lose is: (defclass foo () ()) (defmethod bar ((x foo)) (call-next-method))  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 21 May 87 22:21:33 EDT Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 21 May 87 19:08:50 PDT Received: from Cabernet.ms by ArpaGateway.ms ; 21 MAY 87 18:22:41 PDT Date: 21 May 87 18:22 PDT From: Gregor.pa@Xerox.COM Subject: Re: Object creation discussion (at last!) In-reply-to: David A. Moon 's message of Mon, 27 Apr 87 01:30 EDT To: Moon@STONY-BROOK.SCRC.Symbolics.COM cc: Common-Lisp-Object-System@sail.stanford.edu Message-ID: <870521-182241-1963@Xerox> I have elided parts of your message which I am not going to comment on directly. Date: Mon, 27 Apr 87 01:30 EDT From: David A. Moon Complexity and simplicity are partly matters of taste, and largely matters of point of view. I think this notion of what complexity and simplicity are is very important to this discussion so, despite the fact that this is a potential tarpit, I will try to make some comments about this. I try to take the point of view of the majority of programmers, who are using the outer interfaces of the system without necessarily understanding everything that's going on inside. No matter how beautifully we explain it, most programmers simply won't read beyond the point where they think they know everything they need to know to get their immediate job done. I agree. Now, it may be that we will decide that we would rather make life more complicated for people writing initialization methods in order to make the conceptual explanation shorter. Another way of saying this is "it may be that we will decide that we would rather make it syntactically more complicated for people writing initialization methods in order to make the conceptual explanation of the system simpler". Let me try to explain why I would say it that way. Because I agree with you that people will not read any more of the documentation than they think they can get away with, I think it is important for people to be able to develop mental models of the system which have significant predictive power. By predictive power I mean (among other things) it should be possible for a user to figure out how to do something they haven't done before based on what they already know. This means I believe it is often more important for a user to be able to figure out how to do something than it is for there to be some concise abbreviation for doing this 'new trick'. Thus I believe that an important measure of a system's simplicity is the ease with which users can develop a model of the system which has this kind of predictive power. In the example of initialization methods, my esthetic says that it would be better for someone to be able to figure out how to write initialization methods based on what they already know about ordinary methods (without having to read any additional documentation) than it would be for there to be some concise syntax for defining initialization methods. Note that this biases 'ease' away from the expert programmer. For the record, I acknowledge this and this is consistent with my belief that it is very difficult for an expert programmer to design something which is really easy to understand. Expert programmers tend to design things which have lots of 'bells and whistles' which make things simpler for the expert user, but more complicated for everyone else. I will cite as examples the Interlisp-D and LispM systems. One key point that I was trying to convey, and I think partially succeeded, was the need for information hiding (abstraction) in the arguments to make-instance and in relations among the various initialization specifications attached to a class and its superclasses. I agree that this is important, and your message does a good job of collecting a lot of the reasons why this abstraction is important. Remote initarg defaulting is related to this and your message does a good job of describing why that is important. Another key point, which I don't think came through, was that each initarg should be explicitly defined, and should be defined in exactly one place. This is simply good modularity. I am not sure I agree with this. In fact, there are places later in your message where you seem to disagree with this for the same reasons I do. Specifically, its not entirely clear to me what it means to 'define an initarg'. Defining an initarg can mean specifying that this is a legal initarg for a class (and its subclasses), or it can mean specifying what the implementation of the processing this initarg should be. This is like the protocol/implementation distinction. It would certainly be 'clean' for some sense of clean to require that legal initargs for a class be specified in on option, and then there be other independent mechanisms for specifying the implementation of those initargs (corresponding to your types 1-4). One might argue that this is cumbersome, but its important to understand that it would be simpler in some senses. --- reference --- For reference, I am including the part of your message of April 16th which defines initarg types 1-4. From: David A. Moon Date: Thu, 16 Apr 87 00:22 EDT 1. :allow-other-keys serves its usual function, as in all &key argument lists. It isn't possible to define additional initargs for step 1. 2. Initargs that control storage allocation are defined by defining an allocate-instance method that accepts the initarg as an &key argument. For example, in systems with areas :area is an initarg for step 2. The standard does not require any initargs to exist for step 2. 3. Initargs that fill slots are defined by the :initarg slot-option. 4. Initargs for initialization methods are defined by defining an initialize-instance method that accepts the initarg as an &key argument. --- reference --- All this leads to the idea that initargs of types 2 and 4 (in the nomenclature of my 16 Apr message) should be defined by methods, since their meaning is implemented by methods. Similarly, type 3 should be defined by slot-options, since their meaning is entirely involved with slots. In Flavors, type 4 have the ugly property that they have to be defined in two places, once in the method that implements them and again in a defflavor form; it's easy to get these two places out of sync. Hence the proposal to use the lambda-list of a defmethod as the way to define these initargs. As I said above, 'defining' in this paragraph can have two meanings. The part of 'defining' which implements the behavior of the initarg should definitely be close to 'the place that behavior affects or happens'. So, slot setting initargs should have their behavior defined in slots, initargs handled by methods should be in methods etc. Along with this, I tried to eliminate clunky syntax from initialization methods, hence the elimination of &allow-other-keys and the elimination of having to write :before all the time. If this is too confusing, we could invent a new syntax that both defines initargs and defines the method that implements them. Clearly this is the weakest part of my proposal. As I said in my comments on what constitutes simplicity, I don't necessarily agree that minor improvements in syntax (like removing &allow-other-keys) always make for improvements in simplicity. We could obviously simplify things a lot by getting rid of the :constructor option to defclass. I didn't put it in, at least not this year. I do think it ought to remain, in spite of its inherent complexity in any initialization proposal (previous ones I've seen have glossed over this rather than solving it), because I believe many users will find it quite useful. I don't know whether I like constructors yet or not. In my message last week I tried to show that I think constructors are deceptively confsuing because they contain a hidden performance optimization. I also think they are deceptively confusing because the rules for breaking the lambda-list down into initargs and setf of slot-value(s) are complicated. Because :constructors are just an abbreviation for a defun with a make instance and some setf of slot-values, I have separated them from the rest of initialization for the time being. I want to think about putting them back once we understand the rest better. Date: Wed, 22 Apr 87 13:42 PDT From: Gregor.pa@Xerox.COM The special method combination type for initialize instance adds considerable conceptual overhead for very little functional gain. The goal was not functional gain, that is, the ability to program something you couldn't program before, but rather syntactic simplicity. Perhaps in the end we'll decide it's not worth it, but I'd like us to keep considering the question a bit longer. My description of simplicity at the beginning of this message shows why I think this extra method-combination type is not a net gain. Date: Wed, 22 Apr 87 17:28 PDT From: Gregor.pa@Xerox.COM The default-initargs defclass option serves two purposes. It specifies all the initargs which can be passed to make-instance of this class, and it specifies default values for some of those initargs. This is an important modularity mistake, in my opinion. By combining these two things, which ought to be separate, you have lost the ability for one class to specify a default value for an initarg defined by another class. If specifying a default value always defines an initarg, there is no way to check the consistency of the set of initargs with default values specified against the set of initargs actually defined. If there is a misspelling, the default value will simply be discarded, since no method will receive it and do something with it. I agree with this reasoning. This is the reasoning I was making reference to earlier in this message when I said that there were reasons not to 'define' initargs in one place.  Received: from Xerox.COM (TCP 1200400040) by AI.AI.MIT.EDU 21 May 87 19:08:33 EDT Received: from Cabernet.ms by ArpaGateway.ms ; 21 MAY 87 14:42:38 PDT Date: 21 May 87 14:41 PDT From: Gregor.pa@Xerox.COM Subject: Re: with-slots, :use-accessors In-reply-to: Timothy.Freeman@theory.cs.cmu.edu's message of Wed, 20 May 87 23:08:31 EDT To: Timothy.Freeman@theory.cs.cmu.edu cc: commonloops.pa@Xerox.COM Message-ID: <870521-144238-1675@Xerox> In the next release of PCL, with-slots supports the :use-accessors option as specified by CLOS. It also supports :use-slot-value for backwards compatibility, but it warns that :use-slot-value is obsolete.  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 21 May 87 16:44:07 EDT Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 21 May 87 13:38:33 PDT Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 146801; Thu 21-May-87 16:37:36 EDT Date: Thu, 21 May 87 16:37 EDT From: David A. Moon Subject: Re: CLOS vs. subtypes of FLOAT To: Common-Lisp-Object-System@SAIL.Stanford.Edu In-Reply-To: <870521-120802-1365@Xerox> Message-ID: <870521163738.8.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: 21 May 87 12:07 PDT From: Masinter.pa@Xerox.COM You omitted the possibility where all the classes exist in all implementations, but that some of the classes might be empty (have no instances) in some implementations. Unfortunately this elegant-sounding choice can't be taken without changing Common Lisp incompatibly. The problem is that Common Lisp specifies (CLtL p.19) that in an implementation without short-floats, (typep x 'short-float) does the same thing as (typep x 'single-float), rather than always returning nil. We want to keep typep consistent with class-instance relationships, to avoid giving Common Lisp too subtly-incompatible type systems.  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 21 May 87 15:34:12 EDT Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 21 May 87 12:27:38 PDT Received: from Cabernet.ms by ArpaGateway.ms ; 21 MAY 87 12:08:02 PDT Date: 21 May 87 12:07 PDT From: Masinter.pa@Xerox.COM Subject: Re: CLOS vs. subtypes of FLOAT In-reply-to: Pavel.pa's message of Wed, 20 May 87 18:52:23 PDT To: Pavel.pa@Xerox.COM cc: Common-Lisp-Object-System@SAIL.Stanford.Edu Message-ID: <870521-120802-1365@Xerox> You omitted the possibility where all the classes exist in all implementations, but that some of the classes might be empty (have no instances) in some implementations.  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 21 May 87 15:33:25 EDT Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 21 May 87 12:27:47 PDT Received: from Salvador.ms by ArpaGateway.ms ; 21 MAY 87 12:20:51 PDT Date: Thu, 21 May 87 12:20:50 PDT From: Pavel.pa@Xerox.COM Subject: Re: CLOS vs. subtypes of FLOAT In-reply-to: "Masinter's message of 21 May 87 12:07 PDT" To: Masinter.pa@Xerox.COM Cc: Common-Lisp-Object-System@SAIL.Stanford.Edu Message-ID: <870521-122051-1382@Xerox> Date: 21 May 87 12:07 PDT From: Masinter.pa You omitted the possibility where all the classes exist in all implementations, but that some of the classes might be empty (have no instances) in some implementations. In putting together the proposals, I had two (unfortunately unstated) design criteria: 1) Discrimination on the subtypes of FLOAT should be allowed 2) Discriminations that cannot work in a given implementation (due to collapsing together some of the subtypes) should signal an error so that the user doesn't lose quietly. Proposal NONE loses on the first criterion and your proposal violates the second. Pavel  Received: from Xerox.COM (TCP 1200400040) by AI.AI.MIT.EDU 20 May 87 23:28:06 EDT Received: from Salvador.ms by ArpaGateway.ms ; 20 MAY 87 20:10:25 PDT Return-Path: Received: from THEORY.CS.CMU.EDU ([128.2.254.182]) by Xerox.COM ; 20 MAY 87 20:08:51 PDT Date: Wed, 20 May 87 23:08:31 EDT From: Timothy.Freeman@theory.cs.cmu.edu To: commonloops.pa@Xerox.COM Subject: with-slots, :use-accessors Message-ID: <1987.5.21.3.5.52.Timothy.Freeman@theory.cs.cmu.edu> The CLOS document says that with-slots takes a keyword parameter for each object named :use-accessors, but PCL version 4/29/87 prime calls it :use-slot-value. Which is right?  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 20 May 87 22:40:35 EDT Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 20 May 87 19:34:14 PDT Received: from Salvador.ms by ArpaGateway.ms ; 20 MAY 87 18:52:30 PDT Date: Wed, 20 May 87 18:52:23 PDT From: Pavel.pa@Xerox.COM Subject: CLOS vs. subtypes of FLOAT To: Common-Lisp-Object-System@SAIL.Stanford.Edu Cc: Pavel.pa@Xerox.COM Message-ID: <870520-185230-2840@Xerox> Here it is, finally, my proposal(s) for the treatment of the subtypes of FLOAT for discrimination in CLOS. The issue, to refresh folks' memories, is what to do with code like the following: (defmethod foo ((x single-float)) ...) (defmethod foo ((x double-float)) ...) There are three major questions: 1) Is this code legal at all? That is, is it okay to discriminate on the subtypes of FLOAT? 2) What is the effect of such code in an implementation that does not represent the two types differently (such as one that has only one representation of floating-point numbers)? Is it legal in such implementations? 3) Which of the symbols naming subtypes of FLOAT also name classes? Can this vary from implementation to implementation? I have come up with three different proposals to answer these questions. I will first lay them out and then discuss their relative advantages and disadvantages. Proposal 1 "NONE": It is illegal to discriminate on any of the subtypes of FLOAT. None of them name classes at all, in any implementation. Proposal 2 "SOME": In a given implementation, exactly as many of the subtype-symbols name classes as there are different representations of floating-point numbers. The ones that name classes are derived from the list of allowable representation-naming schemes given on pages 18-19 of CLtL: -- If there is only one representation, then SINGLE-FLOAT names a class. -- If there are exactly two representations, then either SHORT-FLOAT and SINGLE-FLOAT, or SINGLE-FLOAT and DOUBLE-FLOAT, name classes. -- If there are exactly three representations, then either SHORT-FLOAT and SINGLE-FLOAT and DOUBLE-FLOAT, or SINGLE-FLOAT and DOUBLE-FLOAT and LONG-FLOAT, name classes. -- If four representations exist, then all four symbols name classes. The classes named by such symbols are all subclasses of FLOAT. Clearly, those symbols that do not name classes cannot be used for discrimination. Proposal 3 "ALL": All of the subtype-symbols name classes, and all of those classes are subclasses of FLOAT. In some implementations, some of the classes named by those symbols are "synonyms" for other classes, according to the following scheme (again derived from pages 18-19 of CLtL): -- If there is only one representation, then the classes named by SHORT-FLOAT, DOUBLE-FLOAT and LONG-FLOAT are all synonyms for the class named by SINGLE-FLOAT. -- If there are exactly two representations, then either - the classes named by DOUBLE-FLOAT and LONG-FLOAT are synonyms for the class named by SINGLE-FLOAT, or - the class named by SHORT-FLOAT is a synonym for the class named by SINGLE-FLOAT and the class named by LONG-FLOAT is a synonym for the class named by DOUBLE-FLOAT -- If there are exactly three representations, then either - the class named by LONG-FLOAT is a synonym for the class named by DOUBLE-FLOAT, or - the class named by SHORT-FLOAT is a synonym for the class named by SINGLE-FLOAT -- If there are four representations, then no classess are synonyms of others. If a class A is a synonym of another class B, then A and B are not EQ, they have different names, and they may have different metaclasses. No instances may exist of class A. Defining a method on a generic function F that discriminates on A has the same general effect as defining one that discriminates on B. However, if a method already exists on F that discriminates on B or a different synonym of B (i.e., not A), then a correctable error is signalled, allowing the user to choose which one of the two methods will remain on F. Under the NONE proposal, the pair of DEFMETHOD's above would be illegal in all implementations. Under the SOME proposal, the pair would be legal in those implementations that had distinct representations called SINGLE-FLOAT and DOUBLE-FLOAT. In other implementations, an "Unknown class name" error would be signalled. Under the ALL proposal, the pair would compile and evaluate quietly and correctly in those implementations that had distinct representations called SINGLE-FLOAT and DOUBLE-FLOAT. In other implementations, a correctable error would be signalled upon encountering the second DEFMETHOD and the user would have to choose between the two methods. I have been convinced by conversations with a number of floating-point users around here that algorithms exist that can go much more quickly if they can be guaranteed a certain minimum amount of precision in the numbers. These algorithms would have to make checks for certain conditions only if less precision is available. While these programs would have to be conditionalized (using #+/#-) for different implementations to patch in the name of the sufficiently-precise representation (since CLtL does not give a required bit count for each representation), this isn't very hard to do and should be allowed. One can also imagine users who wish to use the very same source code for some floating-point-intensive computation in two methods, one for SINGLE-FLOAT arguments and one for DOUBLE-FLOAT arguments. The idea here is that the compiler could generate much better code given the implicit declaration of the argument type. Each of the two copies might perform much better than an undeclared version. This user would be letting the object system make a single check upon entry to the generic function before dispatching to the representation-specific version of the code. I am convinced by arguments like these that reasonable uses exist for discrimination on subtypes of FLOAT. Thus, I believe that the NONE proposal is a bad idea. The SOME proposal is very easy to implement, but has the (perhaps only aesthetic) flaw that the existence of classes for certain built-in types would vary between implementations. I find this notion disturbing and would prefer not to see it. The ALL proposal solves this problem but introduces, for almost all implementations, the extra mechanism implied by the synonym classes. It may be that this could be very easily implemented, but Gregor would probably know better. An alternative to synonym classes would be making the name -> class mapping be many-to-one. Gregor claims that this cannot be allowed, but I'm not sure that I understand why. Another way to avoid synonyms is to make the classes that would be synonyms into subclasses of the other class. This, on the other hand, has the problem that methods defined on such classes would never be called, since no instances of them can be created. It also establishes an asymmetric subclass relation for pairs with a symmetric subtype relation. This is getting pretty long for such a relatively minor issue. I'll stop here and see if anyone can make any sense of this. Pavel  Received: from Xerox.COM (TCP 1200400040) by AI.AI.MIT.EDU 20 May 87 20:45:18 EDT Received: from Cabernet.ms by ArpaGateway.ms ; 20 MAY 87 16:08:56 PDT Date: 20 May 87 16:07 PDT From: Gregor.pa@Xerox.COM Subject: Re: Problems with :METACLASS option In-reply-to: Jim Kempf 's message of Tue, 19 May 87 10:02:22 pdt To: kempf%hplabsc@hplabs.HP.COM cc: commonloops.pa@Xerox.COM Message-ID: <870520-160856-2635@Xerox> Date: Tue, 19 May 87 10:02:22 pdt From: Jim Kempf The :METACLASS option to DEFCLASS is causing some circularity problems. Supposing I want to have a class at the top of the class hierarchy, but the metaclass is not ESSENTIAL-CLASS (or STANDARD-CLASS in the CLOS spec). Then, after defining the metaclass, I might try to define it as: (defclass top-class () () (:metaclass new-metaclass)) But this gives me a meta/super incompatibility error in CHECK-SUPER-METACLASS-COMPATIBILITY, because class OBJECT is included by default, even if the inheritance list is NIL (as in this case). Well, there are at least two ways to fix this. 1. put a method on class-default-includes for your new metaclass that will cause your class not to include OBJECT when it has no other includes. Of course you will probably want to include T, at which point you will get a similar error, then you can. 2.a put a method on CHECK-SUPER-METACLASS-COMPATIBILITY that says that OBJECT is an OK super. 2.b put a method on CHECK-SUPER-METACLASS-COMPATIBILITY that says that CLASS (soon to be standard-class) is an OK super-metaclass.  Received: from Xerox.COM (TCP 1200400040) by AI.AI.MIT.EDU 20 May 87 18:20:51 EDT Received: from Cabernet.ms by ArpaGateway.ms ; 20 MAY 87 13:20:04 PDT Date: 20 May 87 13:18 PDT From: Gregor.pa@Xerox.COM Subject: initialize, make-instance ... To: CommonLoops.pa@Xerox.COM Message-ID: <870520-132004-2378@Xerox> Recently, there have been a number of messages about problems with the current PCL initialization protocol. The current PCL initialization protocol is doo-doo. As mentioned in 87-002 initialization (instance creation) protocol is one of the items the CLOS committee hasn't yet worked out. We are trying to work on that quite hard. As soon as we (the CLOS committee) have this worked out, I will implement it in PCL. I would hope that would be soon (a couple of weeks) but I can't be certain.  Received: from Xerox.COM (TCP 1200400040) by AI.AI.MIT.EDU 20 May 87 18:20:44 EDT Received: from Cabernet.ms by ArpaGateway.ms ; 20 MAY 87 13:14:22 PDT Date: 20 May 87 13:12 PDT From: Gregor.pa@Xerox.COM Subject: Re: call-next-method bug In-reply-to: Rick.Busdiecker@h.cs.cmu.edu's message of 18 May 87 10:08 EDT To: Rick.Busdiecker@h.cs.cmu.edu cc: CommonLoops.PA@Xerox.COM Message-ID: <870520-131422-2368@Xerox> Date: 18 May 87 10:08 EDT From: Rick.Busdiecker@h.cs.cmu.edu . . The following variables, assumed to be special, are referenced but never declared: (#:g2628) t Functionally, things are correct, but something is still wrong. Do you mean your code works but this warning bugs you? I will fix this so that the gensym gets declared special and the warning doesn't appear.  Received: from Xerox.COM (TCP 1200400040) by AI.AI.MIT.EDU 20 May 87 18:20:36 EDT Received: from Cabernet.ms by ArpaGateway.ms ; 20 MAY 87 12:52:53 PDT Date: 20 May 87 12:51 PDT From: Gregor.pa@Xerox.COM Subject: Re: uses of call-next-method In-reply-to: Richard Fritzson 's message of 20 May 87 14:55 EDT (Wednesday) To: fritzson@bigburd.PRC.Unisys.Com cc: commonloops.pa@Xerox.COM Message-ID: <870520-125253-2313@Xerox> From: Richard Fritzson I hate to post what seems to be a simple question, but I must be missing something. I would appreciate anyone's comments on this. I want to define a method which uses a preexisting less specific method using call-next-method. A simple example is: (defclass position () ((x :initform 0 :type number) (y :initform 0 :type number))) (defmethod move ((point position) dx dy) (with-slots (point) (setf x (+ x dx) y (+ y dy))) point) (defclass 3d-position (position) ((z :initform 0 :type number))) ; and now, define a version of 3d-move which uses the 2d move (defmethod move ((point 3d-position) dx dy dz) (with-slots (point) (setf z (+ z dz)) (call-next-method))) This doesn't work because it passes three arguments to the (move (position)) method when only two are expected. Actually, your real problem is that PCL is not signalling the correct error. According to CLOS, your two methods definitions for MOVE are incompatible. Evaluating the second method definition should signal an error. This is because the two methods do not have congruent argument lists. An alternate way to write this code would be. (defmethod move ((point position) dx dy dz) (declare (ignore dz)) (with-slots (point) (setf x (+ x dx) y (+ y dy))) point) (defmethod move ((point 3d-position) dx dy dz) (with-slots (point) (setf z (+ z dz)) (call-next-method)))  Received: from Xerox.COM (TCP 1200400040) by AI.AI.MIT.EDU 20 May 87 15:31:45 EDT Received: from Salvador.ms by ArpaGateway.ms ; 20 MAY 87 11:58:09 PDT Return-Path: Received: from burdvax.PRC.Unisys.Com (BIGBURD.PRC.UNISYS.COM) by Xerox.COM ; 20 MAY 87 11:56:29 PDT Received: by burdvax.PRC.Unisys.Com (5.54/4.7) id AA20379; Wed, 20 May 87 14:56:09 EDT Received: by bigburd.PRC.Unisys.Com (5.54/4.7) id AA17226; Wed, 20 May 87 14:56:04 EDT From: Richard Fritzson Message-Id: <8705201856.AA17226@bigburd.PRC.Unisys.Com> Received: from Ringmaster by bigburd with PUP; Wed, 20 May 87 14:56 EDT Date: 20 May 87 14:55 EDT (Wednesday) To: commonloops.pa@Xerox.COM Subject: uses of call-next-method Cc: fritzson@bigburd.prc.unisys.com I hate to post what seems to be a simple question, but I must be missing something. I would appreciate anyone's comments on this. I want to define a method which uses a preexisting less specific method using call-next-method. A simple example is: (defclass position () ((x :initform 0 :type number) (y :initform 0 :type number))) (defmethod move ((point position) dx dy) (with-slots (point) (setf x (+ x dx) y (+ y dy))) point) (defclass 3d-position (position) ((z :initform 0 :type number))) ; and now, define a version of 3d-move which uses the 2d move (defmethod move ((point 3d-position) dx dy dz) (with-slots (point) (setf z (+ z dz)) (call-next-method))) This doesn't work because it passes three arguments to the (move (position)) method when only two are expected. I know that the example is silly, but there must be a way to do this. Any suggestions? ------------ In the Xerox version of PCL, I can define all of the above and then do (setq foo (make-instance 'position)) (move foo 1 1 1) and I won't get an error, UNTIL I try running (setq bar (make-instance '3d-position)) (move bar 1 1 1) Once this fails, calls to (move foo 1 1 1) will also fail (too many arguments). I don't know how any other versions of PCL behave.  Received: from Xerox.COM (TCP 1200400040) by AI.AI.MIT.EDU 20 May 87 13:20:40 EDT Received: from Salvador.ms by ArpaGateway.ms ; 20 MAY 87 09:34:34 PDT Return-Path: Received: from EDDIE.MIT.EDU ([18.62.0.6]) by Xerox.COM ; 20 MAY 87 09:32:04 PDT Received: by EDDIE.MIT.EDU with UUCP with smail2.3 with sendmail-5.31/4.7 id ; Wed, 20 May 87 12:31:07 EDT Received: from zaphod.prime.com by primerd.prime.com (1.1/SMI-3.0DEV3/smail) id AA09917; Wed, 20 May 87 11:58:19 EDT Received: by zaphod.prime.com (1.1/SMI-3.0DEV3/smail) id AA05695; Wed, 20 May 87 11:58:05 EDT Date: Wed, 20 May 87 11:58:05 EDT From: primerd!zaphod!doug@EDDIE.MIT.EDU (Douglas Rand) Message-Id: <8705201558.AA05695@zaphod.prime.com> To: commonloops.pa@Xerox.COM, alamo!prime-support@EDDIE.MIT.EDU Subject: Lucid bug and fix for Prime CL version 1.0 Timothy's fix will work fine in Prime CL 1.0 but you must also do the additional fix in slots.lisp: In method initialize-from-init-plist: (flet ((find-slotd (keyword) --to-- (flet ((find-slotd-x (keyword) ((null (setq slotd (find-slotd (car keyword-loc)))) --to-- ((null (setq slotd (find-slotd-x (car keyword-loc)))) The apparent problem is that the compiler is confusing the flet definition with the earlier macro definition. Is it really reasonable to have both a macro and a function with the same name? Doug  Received: from Xerox.COM (TCP 1200400040) by AI.AI.MIT.EDU 20 May 87 11:54:07 EDT Received: from Salvador.ms by ArpaGateway.ms ; 20 MAY 87 08:40:58 PDT Return-Path: Received: from VAX.BBN.COM by Xerox.COM ; 20 MAY 87 08:39:18 PDT To: Ed Krall cc: commonloops.pa@Xerox.COM, kanderso@VAX.BBN.COM Subject: Re: Keyword problem in PCL In-reply-to: Your message of Fri, 15 May 87 08:20 CDT. <8705151321.AA10737@pp.mcc.com> Date: 20 May 87 11:37:58 EDT (Wed) From: kanderso@VAX.BBN.COM Message-ID: <870520-084058-1768@Xerox> Return-Path: <@MCC.COM:krall%pp.mcc.com@mcc.com> 08:20:56-CDT Posted-Date: Friday, 15 May 1987, 08:20-CDT Message-Id: <8705151321.AA10737@pp.mcc.com> Date: Fri, 15 May 87 08:20 CDT From: Ed Krall MMDF-Warning: Parse error in original version of preceding line at VAX.BBN.COM Sender: krall%pp.mcc.com@MCC.COM Subject: Keyword problem in PCL To: commonloops.pa@XEROX.COM Perhaps I am missing something, but the following behavior is a bit of a problem: Class AAA has an instance variable or slot called "name". Therefore subclass AA of AAA also has this slot. When I do a (make-instance 'AA :name "joe"), the slot that gets initialized is the one named pcl::name not user::name. Why is this? Because 1. the keyword lookup procedure (referenced from initialize-from-init-plist in the file slots.lsp) does a simple forward search on the value returned by class-instance-slots, and 2. this value lists the instance slots in ancestral order, and 3. the slots pcl::name and user::name have the same keyword, :name. I wonder if this is the optimal behavior. Shouldn't the more recent or local declaration (user::name) shadow the older and more general one (pcl::name)? The problem is that the decision to use keywords to initialize variables (in flavors and PCL) collapses the symbol namespace as described above. In the original Flavors documentation, this was considered a good thing because messages were generic operations, and you shouldn't have to remember what package every message is in. In the more recent view of object oriented programming as described in CLOS, i'm not so sure using keywords is still so good an idea. In Symbolics General 7 Flavors, at least you are warned of the symbol name clash, and this should happen in PCL too. Whenever i get such a warning, i rename one of the slots. k  Received: from Xerox.COM (TCP 1200400040) by AI.AI.MIT.EDU 20 May 87 02:19:10 EDT Received: from Salvador.ms by ArpaGateway.ms ; 19 MAY 87 22:56:22 PDT Return-Path: Received: from THEORY.CS.CMU.EDU ([128.2.254.182]) by Xerox.COM ; 19 MAY 87 22:53:41 PDT Date: Wed, 20 May 87 01:53:35 EDT From: Timothy.Freeman@theory.cs.cmu.edu To: commonloops.pa@Xerox.COM Subject: Workaround for Lucid Lisp 2.0.4 bug Message-ID: <1987.5.20.5.41.29.Timothy.Freeman@theory.cs.cmu.edu> The bug is that the Lucid compiler passes something useless as the &environment parameter to macros that are expanded at compile time. This little file illustrates the bug because a segmentation violation happens when we try to compile it: (defun make-lexical-environment (environment) (evalhook '(labels ((bar ())) (make-lexical-environment-2)) 'make-lexical-environment-1 () environment)) (defun make-lexical-environment-1 (form env) (setq form (macroexpand form env)) (evalhook form 'make-lexical-environment-1 nil env)) (defmacro make-lexical-environment-2 (&environment env) (list 'quote (copy-tree env))) (defun foo () (macrolet ((baz (&environment env) (format t "Env is ~S.~%" env) (inspect env) (make-lexical-environment env) 3)) (baz))) The bug causes PCL (dated 4/29/87 prime) to get a segmentation violation when it tries to walk forms with labels constructs. The workaround I found is to change the definition of expand-defmethod in boot.lisp as follows. The surplus call to walk-form prevents the macros from being called directly by the compiler. *************** *** 142,148 (defun expand-defmethod (name qualifiers arglist body) ! (let ((defmethod-uid (gensym)) (load-method-1 ())) (multiple-value-bind (parameters lambda-list specializers) (parse-specialized-lambda-list arglist) --- 142,149 ----- (defun expand-defmethod (name qualifiers arglist body) ! (walker:walk-form ! (let ((defmethod-uid (gensym)) (load-method-1 ())) (multiple-value-bind (parameters lambda-list specializers) (parse-specialized-lambda-list arglist) *************** *** 199,205 name defmethod-uid load-method-1 ! real-body))))))))) (defun make-top-level-form (form) #-Symbolics form --- 200,206 ----- name defmethod-uid load-method-1 ! real-body)))))))))) (defun make-top-level-form (form) #-Symbolics form  Received: from Xerox.COM (TCP 1200400040) by AI.AI.MIT.EDU 19 May 87 17:58:23 EDT Received: from Cabernet.ms by ArpaGateway.ms ; 19 MAY 87 14:42:02 PDT Return-Path: <@MCC.COM:rcp@MCC.COM> Received: from MCC.COM by Xerox.COM ; 19 MAY 87 14:40:32 PDT Received: from milano.SW.MCC.COM by MCC.COM with TCP; Tue 19 May 87 16:39:50-CDT Received: from perseus by milano.SW.MCC.COM (5.52/STP1.44) id AA10276; Tue, 19 May 87 16:40:16 CDT Date: Tue, 19 May 87 16:39:32 CDT From: Rob Pettengill Message-Id: <8705192139.AA06104@perseus> Received: by perseus (3.2/STP) id AA06104; Tue, 19 May 87 16:39:32 CDT To: CommonLoops.pa@Xerox.COM Subject: EXCL 2.0 FASL FILE ORDERING BUG WITH PCL One problem we have run in to with compiled PCL fasl files for Franz excl version 2.0 is as follows: It seems that excl does not always preserve the order of expressions in your source file in the compiled fasl file. In some fasl files with pcl code in them we have found that the DEFCLASS form occurs after DEFMETHODS on that class (even thought they are in the correct order in the source file). The result is that the fasl file will not load in a "clean" lisp image. We have found two workarounds: 1. Put defclasses in a seperate file that is loaded first. 2. Inserting a dummy DEFUN in the source file can alter the order of the fasl forms in the compiled file allowing it to load correctly. ;rob Robert C. Pettengill, MCC Software Technology Program P. O. Box 200195, Austin, Texas 78720 ARPA: rcp@mcc.com PHONE: (512) 338-3533 UUCP: {ihnp4,seismo,harvard,gatech,pyramid}!ut-sally!im4u!milano!rcp  Received: from Xerox.COM (TCP 1200400040) by AI.AI.MIT.EDU 19 May 87 13:12:21 EDT Received: from Cabernet.ms by ArpaGateway.ms ; 19 MAY 87 10:05:14 PDT Return-Path: Received: from hplabs.HP.COM ([192.5.58.10]) by Xerox.COM ; 19 MAY 87 10:04:03 PDT Received: from hplabsc by hplabs.HP.COM with TCP ; Tue, 19 May 87 10:02:44 pdt Received: by hplabsc ; Tue, 19 May 87 10:02:22 pdt Date: Tue, 19 May 87 10:02:22 pdt From: Jim Kempf Message-Id: <8705191702.AA19777@hplabsc> To: commonloops.pa@Xerox.COM Subject: Problems with :METACLASS option The :METACLASS option to DEFCLASS is causing some circularity problems. Supposing I want to have a class at the top of the class hierarchy, but the metaclass is not ESSENTIAL-CLASS (or STANDARD-CLASS in the CLOS spec). Then, after defining the metaclass, I might try to define it as: (defclass top-class () () (:metaclass new-metaclass)) But this gives me a meta/super incompatibility error in CHECK-SUPER-METACLASS-COMPATIBILITY, because class OBJECT is included by default, even if the inheritance list is NIL (as in this case). Jim Kempf kempf@hplabs.hp.com  Received: from Xerox.COM (TCP 1200400040) by AI.AI.MIT.EDU 18 May 87 17:07:52 EDT Received: from Cabernet.ms by ArpaGateway.ms ; 18 MAY 87 13:34:43 PDT Date: 18 May 87 13:30 PDT Sender: Bobrow.pa@Xerox.COM From: Danny Bobrow Subject: Re: initialization In-reply-to: Rick.Busdiecker@h.cs.cmu.edu's message of 18 May 87 15:47 EDT To: Rick.Busdiecker@h.cs.cmu.edu cc: CommonLoops.PA@Xerox.COM Message-ID: <870518-133443-1539@Xerox> After discovering that Initialize is not exported in 4/29/87 prime, I also found that the CLOS spec (87-002) says, on page 1-7, that ``the initialization protocol of make-instance is not yet specified.'' Is this still the case? Is it safe/reasonable to assume that (a) some mechanism will be specified Yes (b) defining a pcl::initialize method on an object will continue to work until the initialization protocol is specified? I would think so.  Received: from Xerox.COM (TCP 1200400040) by AI.AI.MIT.EDU 18 May 87 17:07:40 EDT Received: from Cabernet.ms by ArpaGateway.ms ; 18 MAY 87 13:10:42 PDT Return-Path: Received: from H.CS.CMU.EDU ([128.2.254.156]) by Xerox.COM ; 18 MAY 87 13:08:54 PDT Date: 18 May 87 15:47 EDT From: Rick.Busdiecker@h.cs.cmu.edu To: CommonLoops.PA@Xerox.COM Subject: initialization Message-Id: <548365657/rfb@h.cs.cmu.edu> After discovering that Initialize is not exported in 4/29/87 prime, I also found that the CLOS spec (87-002) says, on page 1-7, that ``the initialization protocol of make-instance is not yet specified.'' Is this still the case? Is it safe/reasonable to assume that (a) some mechanism will be specified and (b) defining a pcl::initialize method on an object will continue to work until the initialization protocol is specified? Rick  Received: from Xerox.COM (TCP 1200400040) by AI.AI.MIT.EDU 18 May 87 17:07:26 EDT Received: from Cabernet.ms by ArpaGateway.ms ; 18 MAY 87 10:48:47 PDT Return-Path: Received: from hplabs.HP.COM ([192.5.58.10]) by Xerox.COM ; 18 MAY 87 10:46:35 PDT Received: from hplabsc by hplabs.HP.COM with TCP ; Sun, 17 May 87 15:59:04 pdt Received: by hplabsc ; Sun, 17 May 87 15:59:20 pdt Date: Sun, 17 May 87 15:59:20 pdt From: Jim Kempf Message-Id: <8705172259.AA01115@hplabsc> To: commonloops.pa@Xerox.COM Subject: Bug in REMOVE-NAMED-METHOD The 4/29 prime version of PCL had a bug in REMOVE-NAMED-METHOD. The attempt to get the function from GENERIC-FUNCTION rather than GENERIC-FUNCTION-NAME would fail, since GENERIC-FUNCTION is bound to NIL. Here is a corrected version (from methods.l): (defmethod remove-named-method (generic-function-name argument-specifiers &optional extra) (let ((generic-function ()) (method ())) (cond ((or (null (fboundp generic-function-name)) (not (generic-function-p (setq generic-function (symbol-function generic-function-name))))) (error "~S does not name a generic-function." generic-function-name)) ((null (setq method (find-method generic-function argument-specifiers extra t))) (error "There is no method for the generic-function ~S~%~ which matches the argument-specifiers ~S." generic-function argument-specifiers)) (t (remove-method generic-function method)))))  Received: from Xerox.COM (TCP 1200400040) by AI.AI.MIT.EDU 18 May 87 13:42:33 EDT Received: from Cabernet.ms by ArpaGateway.ms ; 18 MAY 87 10:10:18 PDT Return-Path: <@MCC.COM:rcp@MCC.COM> Received: from MCC.COM by Xerox.COM ; 18 MAY 87 10:08:01 PDT Received: from milano.SW.MCC.COM by MCC.COM with TCP; Mon 18 May 87 09:34:46-CDT Received: from perseus by milano.SW.MCC.COM (5.52/STP1.44) id AA17270; Mon, 18 May 87 09:35:07 CDT Date: Mon, 18 May 87 09:34:30 CDT From: Rob Pettengill Message-Id: <8705181434.AA04589@perseus> Received: by perseus (3.2/STP) id AA04589; Mon, 18 May 87 09:34:30 CDT To: CommonLoops.pa@Xerox.COM Subject: [RCP@MCC.COM: &allow-other-keys for initialize methods in pcl] Character-Type-Mappings: (1 0 (NIL 0) (NIL :BOLD NIL) "CPTFONTCB") (2 0 (NIL 0) (NIL :ITALIC NIL) "CPTFONTI") Fonts: CPTFONT, CPTFONTCB, CPTFONTI In Symbolics 3650 Zwei in Genera 7.0G1, IP-TCP 52.0, MCC Genera 7.0 Patches 4.11, MCC-Base 2.2, Experimental Rcp 18, Experimental STP Deli CLOS Shell 5, Experimental Portable Common Loops 5, Experimental X-Window-System 2.0, microcode 3650-MIC 394, FEP 206, Fep0:>g206-lisp.flod(6), Fep0:>g206-loaders.flod(6), Fep0:>g206-info.flod(6), Fep0:>G206-debug.flod(1), Machine serial number 30301, TCP-FTP Binary Loader Fix (from RCP:SYS;TCP-BINARY-LOADER-FIX.LISP.4), on Sabielocks: For the trivial example: (defclass foo () (alpha beta) (:accessor-prefix ||)) (defmethod INITIALIZE ((SELF foo) INIT-PLIST) (call-next-method) (let ((a (getf init-plist :a))) (when a (setf (alpha self) a)))) (setq f (make-instance 'foo :a 7)) generates this error. It would be very useful to be able to define additional initialization keywords for an init method. 1Error: :A is not a valid keyword in the init-plist. 0While in the function (PCL::METHOD PCL::INITIALIZE-FROM-INIT-PLIST (PCL::OBJECT))  (:INTERNAL (:INTERNAL #:G19506 0) 0)  (PCL::METHOD INITIALIZE (PCL::OBJECT)) The condition signalled was ZL:FERROR 1(PCL::METHOD PCL::INITIALIZE-FROM-INIT-PLIST (PCL::OBJECT))0: (P.C. = 71) Arg 0 (PCL::SELF): #S(FOO ALPHA NIL BETA NIL) Arg 1 (PCL::INIT-PLIST): (:A 7) Local 2: # Local 3: # Local 4: # Local 5: # Local 6 (PCL::CLASS): # Local 7 (PCL::INSTANCE-SLOTS): (# #) Local 8 (PCL::NON-INSTANCE-SLOTS): NIL Local 9 (PCL::.FIND-SLOTD-FUNCTION-CELL.): # Local 10 (PCL::KEYWORD-LOC): (:A 7) Local 11 (PCL::VALUE-LOC): (7) Local 12 (PCL::SLOTD): NIL Local 13 (PCL::ALLOW-OTHER-KEYS-P): 0 Local 14 (PCL::.ALLOW-OTHER-KEYWORDS-P-FUNCTION-CELL.): # 1(:INTERNAL (:INTERNAL #:G19506 0) 0)0: (P.C. = 131) Arg 0 (COMPILER:.LEXICAL-ENVIRONMENT-POINTER.): (# # NIL # NIL NIL NIL NIL NIL NIL ...) Arg 1 (PCL::|Discriminating Function Arg 0|): #S(FOO ALPHA NIL BETA NIL) Arg 2 (PCL::|Discriminating Function Arg 1|): (:A 7) 1(PCL::METHOD INITIALIZE (PCL::OBJECT))0: (P.C. = 6) Arg 0 (PCL::OBJECT): #S(FOO ALPHA NIL BETA NIL) Arg 1 (PCL::INIT-PLIST): (:A 7) 1PCL::CALL-NEXT-METHOD-INTERNAL0: (P.C. = 357) 2(from PCL:SOURCE;FIXUP) 0 Arg 0 (PCL::CURRENT-METHOD): # Rest arg (PCL::ARGS): (#S(FOO ALPHA NIL BETA NIL) (:A 7)) 1(PCL::METHOD INITIALIZE (FOO))0: (P.C. = 5) Arg 0 (SELF): #S(FOO ALPHA NIL BETA NIL) Arg 1 (INIT-PLIST): (:A 7) 1(:INTERNAL (:INTERNAL #:G16031 0) 0)0: (P.C. = 160) Arg 0 (COMPILER:.LEXICAL-ENVIRONMENT-POINTER.): (# # NIL NIL NIL NIL NIL NIL NIL NIL ...) Arg 1: #S(FOO ALPHA NIL BETA NIL) Arg 2: (:A 7) 1MAKE-INSTANCE0: (P.C. = 15) 2(from PCL:SOURCE;SLOTS) 0 Arg 0 (PCL::CLASS): FOO Local 0 (PCL::CLASS): # Rest arg (PCL::INIT-PLIST): (:A 7) 1SI:*EVAL0: (P.C. = 455) 2(from SYS:PATCH;SYSTEM-349-17) 0 Arg 0 (SYS:FORM): (MAKE-INSTANCE (QUOTE FOO) :A 7) Local 0 (SYS:FORM): NIL Arg 1 (SI:ENV): NIL 2 --Defaulted args:-- 0 Arg 2 (SI:HOOK): NIL 2Rest of stack: 1EVAL0: (P.C. = 7) 1SETQ0: (P.C. = 24) 1SI:*EVAL0: (P.C. = 172)2 (from SYS:PATCH;SYSTEM-349-17) 1EVAL0: (P.C. = 7) 1(:INTERNAL (:INTERNAL SI:BREAK-INTERNAL 1 SI:WITH-PROCESS-INTERACTIVE-PRIORITY-BODY) 1)0: (P.C. = 7) 1(:INTERNAL (:INTERNAL (:INTERNAL SI:LISP-COMMAND-LOOP-INTERNAL 0 SI:WITH-PROCESS-INTERACTIVE-PRIORITY-BODY) 0) 0 SI:WITH-PROCESS-NON-INTERACTIVE-PRIORITY-BODY)0: (P.C. = 11) 1(FLAVOR:METHOD SI:WITH-PROCESS-NON-INTERACTIVE-PRIORITY-INTERNAL SI:PROCESS)0: (P.C. = 43) 1(:INTERNAL (:INTERNAL SI:LISP-COMMAND-LOOP-INTERNAL 0 SI:WITH-PROCESS-INTERACTIVE-PRIORITY-BODY) 0)0: (P.C. = 331) 1TV:WITH-NOTIFICATION-MODE-INTERNAL0: (P.C. = 15) 1(:INTERNAL SI:LISP-COMMAND-LOOP-INTERNAL 0 SI:WITH-PROCESS-INTERACTIVE-PRIORITY-BODY)0: (P.C. = 52) 1(FLAVOR:METHOD SI:WITH-PROCESS-INTERACTIVE-PRIORITY-INTERNAL SI:PROCESS)0: (P.C. = 22) 1SI:LISP-COMMAND-LOOP-INTERNAL0: (P.C. = 27) 1(:INTERNAL SI:BREAK-INTERNAL 1 SI:WITH-PROCESS-INTERACTIVE-PRIORITY-BODY)0: (P.C. = 213) 1(FLAVOR:METHOD SI:WITH-PROCESS-INTERACTIVE-PRIORITY-INTERNAL SI:PROCESS)0: (P.C. = 40) 1SI:BREAK-INTERNAL0: (P.C. = 37) 1ZWEI:COM-BREAK0: (P.C. = 10) 1(:INTERNAL ZWEI:COMMAND-EXECUTE 0 SI:WITH-PROCESS-NON-INTERACTIVE-PRIORITY-BODY)0: (P.C. = 17) 1(FLAVOR:METHOD SI:WITH-PROCESS-NON-INTERACTIVE-PRIORITY-INTERNAL SI:PROCESS)0: (P.C. = 43) 1ZWEI:COMMAND-EXECUTE0: (P.C. = 57) 1ZWEI:PROCESS-COMMAND-CHAR0: (P.C. = 14) 1(FLAVOR:METHOD :EDIT ZWEI:EDITOR)0: (P.C. = 316) 1(:INTERNAL (FLAVOR:COMBINED :EDIT ZWEI:ZMACS-TOP-LEVEL-EDITOR) 1)0: (P.C. = 20) 1(:INTERNAL (FLAVOR:WHOPPER :EDIT ZWEI:EDITOR) 0 SI:WITH-PROCESS-INTERACTIVE-PRIORITY-BODY)0: (P.C. = 7) 1(FLAVOR:METHOD SI:WITH-PROCESS-INTERACTIVE-PRIORITY-INTERNAL SI:PROCESS)0: (P.C. = 40) 1(FLAVOR:WHOPPER :EDIT ZWEI:EDITOR)0: (P.C. = 20) 1(FLAVOR:COMBINED :EDIT ZWEI:ZMACS-TOP-LEVEL-EDITOR)0: (P.C. = 317) 1ZWEI:ZMACS-WINDOW-TOP-LEVEL0: (P.C. = 55)2 (from SYS:PATCH;SYSTEM-349-88) 1SI:PROCESS-TOP-LEVEL0: (P.C. = 45)  Received: from Xerox.COM (TCP 1200400040) by AI.AI.MIT.EDU 18 May 87 13:42:11 EDT Received: from Cabernet.ms by ArpaGateway.ms ; 18 MAY 87 09:58:31 PDT Return-Path: Received: from H.CS.CMU.EDU ([128.2.254.156]) by Xerox.COM ; 18 MAY 87 09:55:41 PDT Date: 18 May 87 10:08 EDT From: Rick.Busdiecker@h.cs.cmu.edu To: CommonLoops.PA@Xerox.COM Subject: call-next-method bug Message-Id: <548345325/rfb@h.cs.cmu.edu> The following file which should compile error/warning free: ;;; -*- Mode: Lisp; Package: PCL-BUG -*- (in-package "PCL-BUG" :use '("LISP" "PCL")) (defclass foo () (a b)) (defmethod slots ((self foo)) (list (slot-value self 'a) (slot-value self 'b))) (defclass bar (foo) (c)) (eval-when (compile) (format t "Check point.~%")) (defmethod slots ((self bar)) `(,@(call-next-method) ,(slot-value self 'c))) Here's a portion of a lisp session in which I compile the above file: * pcl::*pcl-system-date* "4/29/87 prime April 29, 1987" * (compile-file "pcl-bug") Error output from /usr1/rfb/meta-device/pcl-bug.lisp 18-May-87 10:03:20. Compiled on 18-May-87 10:03:33 by CLC version M1.6 (17-Apr-87). Check point. Warning in #:g2629: #:g2628 not declared or bound, assuming special. Finished compilation of file "/usr/rfb/pcl-bug.lisp". 0 Errors, 1 Warnings. Elapsed time 0:00:26, run time 0:00:04. The following variables, assumed to be special, are referenced but never declared: (#:g2628) t Functionally, things are correct, but something is still wrong. Rick  Received: from Xerox.COM (TCP 1200400040) by AI.AI.MIT.EDU 15 May 87 23:00:19 EDT Received: from Cabernet.ms by ArpaGateway.ms ; 15 MAY 87 17:10:30 PDT Return-Path: Received: from shambhala.berkeley.edu ([128.32.132.54]) by Xerox.COM ; 15 MAY 87 17:09:31 PDT Received: by shambhala.berkeley.edu (5.57/1.16) id AA01913; Fri, 15 May 87 17:08:59 PDT Message-Id: <8705160008.AA01913@shambhala.berkeley.edu> To: Commonloops.pa@Xerox.COM Subject: check-super-metaclass-compatibility.... Date: Fri, 15 May 87 17:08:56 -0700 From: Rick L. Spickelmier ... is spelled check-super-meta-class-compatibility in *other-exports* in pcl version "4/29/87 prime". Rick Spickelmier  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 15 May 87 20:16:40 EDT Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 15 May 87 17:15:05 PDT Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 141385; Fri 15-May-87 20:14:21 EDT Date: Fri, 15 May 87 20:13 EDT From: David A. Moon Subject: optimization versus constructors To: Common-Lisp-Object-System@Sail.Stanford.edu In-Reply-To: <870515-110752-4939@Xerox> Message-ID: <870515201336.5.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: 15 May 87 11:07 PDT From: Gregor.pa@Xerox.COM Danny and I have been thinking about initialization and are picking away at parts of the problem we don't understand. Specifically, I was trying to remember what the :constructor option was really for. .... This shows that whatever optimization can be gotten from the :constructor option can also be gotten from calls to make-instance (at least the calls to make-instance for which you could have used a constructor). I agree that the :constructor mechanism could be replaced by a complicated mechanism involving compile time optimizations of recognized patterns of constant arguments to make-instance, with some way to get around the fact that constructors can initialize any slot but we don't want make-instance to be able to do that. There is some trickiness required to make this compile-time optimized code get recompiled whenever the class's structure is changed. I don't remember who put constructors in, but I assume the idea was that the other way of doing it was too complicated. It's probably a good model for thinking about the semantics and making sure that constructors and make-instance behave consistently, but we probably don't want to require implementations to work that way.  Received: from Xerox.COM (TCP 1200400040) by AI.AI.MIT.EDU 15 May 87 19:55:33 EDT Received: from Cabernet.ms by ArpaGateway.ms ; 15 MAY 87 16:41:22 PDT Date: 15 May 87 16:39 PDT From: Gregor.pa@Xerox.COM Subject: Re: print-object In-reply-to: Timothy.Freeman@theory.cs.cmu.edu's message of Thu, 14 May 87 23:13:32 EDT To: Timothy.Freeman@theory.cs.cmu.edu cc: commonloops.pa@Xerox.COM Message-ID: <870515-164122-5484@Xerox> The next release of PCL has print-instance renamed to print-object.  Received: from Xerox.COM (TCP 1200400040) by AI.AI.MIT.EDU 15 May 87 19:55:06 EDT Received: from Cabernet.ms by ArpaGateway.ms ; 15 MAY 87 15:57:38 PDT Date: 15 May 87 15:56 PDT From: Gregor.pa@Xerox.COM Subject: Re: Incorrect CPL calculation in 4-29 Release? In-reply-to: Jim Kempf 's message of Fri, 15 May 87 15:45:41 pdt To: kempf%hplabsc@hplabs.HP.COM cc: commonloops.pa@Xerox.COM Message-ID: <870515-155738-5426@Xerox> I think you are off by one level of class-of. If I say (defclass foo () ()), then (class-precedence-list (class-named 'foo)) wants to be (FOO OBJECT T) so that (class-precedence-list (class-of (make-instance 'foo))) can be '(FOO OBJECT T) On the other hand, (class-precedence-list (class-of (class-named 'foo))) is (CLASS BASIC-CLASS ...) This last should really be (STANDARD-CLASS CLASS OBJECT T), as you say in your message but I haven't changed the names in PCL yet.  Received: from Xerox.COM (TCP 1200400040) by AI.AI.MIT.EDU 15 May 87 19:54:54 EDT Received: from Cabernet.ms by ArpaGateway.ms ; 15 MAY 87 15:47:32 PDT Return-Path: Received: from hplabs.HP.COM ([192.5.58.10]) by Xerox.COM ; 15 MAY 87 15:46:18 PDT Received: from hplabsc by hplabs.HP.COM with TCP ; Fri, 15 May 87 15:45:27 pdt Received: by hplabsc ; Fri, 15 May 87 15:45:41 pdt Date: Fri, 15 May 87 15:45:41 pdt From: Jim Kempf Message-Id: <8705152245.AA13902@hplabsc> To: commonloops.pa@Xerox.COM Subject: Incorrect CPL calculation in 4-29 Release? I suspect that the class precedence list calculation for class objects in the 4-29 release of PCL/PCLOS may be incorrect. Consider the following: (defclass foo () () ) (class-precedence-list (class-named 'foo)) returns: (# # # ) implying that the class of the FOO class object is FOO...which is incorrect. If class FOO has metaclass STANDARD-CLASS, then the FOO class object should have STANDARD-CLASS as the first element of the class precedence list (in fact, since STANDARD-CLASS is not yet in the system, this will probably be CLASS). This should only be a problem for people using the metaobject protocol, since only in that case are methods dispatching on class objects relevent. Jim Kempf kempf@hplabs.hp.com  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 15 May 87 19:50:53 EDT Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 15 May 87 16:48:43 PDT Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 141322; Fri 15-May-87 19:37:40 EDT Date: Fri, 15 May 87 19:36 EDT From: David A. Moon Subject: Re: Why in MAKE-INSTANCE not generic? To: Jim Kempf cc: common-lisp-object-system@sail.stanford.edu In-Reply-To: <8705152014.AA11627@hplabsc> Message-ID: <870515193649.3.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Fri, 15 May 87 13:14:48 pdt From: Jim Kempf There seems to be a slight discrepency between 87-002 and 87-003 on this point. 87-002, pg. 2-44 implies that MAKE-INSTANCE is a programmer interface function, 87-003, pg. 3-7 implies that it is a method which is part of the metaobject protocol. As you may have noticed, the protocol for creating objects hasn't been defined yet. Anything that's in the documents now can't be relied upon.  Received: from Xerox.COM (TCP 1200400040) by AI.AI.MIT.EDU 15 May 87 17:50:10 EDT Received: from Cabernet.ms by ArpaGateway.ms ; 15 MAY 87 13:41:16 PDT Return-Path: Received: from hplabs.HP.COM ([192.5.58.10]) by Xerox.COM ; 15 MAY 87 13:38:34 PDT Received: from hplms1 by hplabs.HP.COM with TCP ; Fri, 15 May 87 13:36:53 pdt Received: from hplrds (hplrds) by hplms1; Fri, 15 May 87 13:36:33 pdt Return-Path: Received: by hplrds ; Fri, 15 May 87 13:36:20 pdt Date: Fri, 15 May 87 13:36:20 pdt From: Roy D'Souza Message-Id: <8705152036.AA05222@hplrds> To: commonloops%hplrds@hplabs.HP.COM, gregor%hplrds@hplabs.HP.COM Subject: HP Lisp fix for low.l Cc: kempf%hplrds@hplabs.HP.COM On an HP Bobcat, while trying to compile PCL version 4/29 prime, I get a wrong-number-of-args error. Unfortunately, what I have in the way of a debugger can't even tell me the arglist (I can't quite get nmode working yet, so I'm using bare common-lisp). I hope there's enough here for you to recognize the problem. (compile-pcl) Loading binary of PKG... Loading binary of WALK... Loading binary of MACROS... Loading binary of LOW... !!!!! Error: Wrong number of arguments passed to function Condition signalled in: MAKE-MEMORY-BLOCK-MASK. This is due to a bug in the HP Lisp compiler. Please change the call to 'make-memory-block-mask' in 'low.l' to: (defconstant class-wrapper-cache-mask (make-memory-block-mask class-wrapper-cache-size #+HP 2)) Roy  Received: from Xerox.COM (TCP 1200400040) by AI.AI.MIT.EDU 15 May 87 17:49:57 EDT Received: from Cabernet.ms by ArpaGateway.ms ; 15 MAY 87 13:38:55 PDT Return-Path: Received: from EDDIE.MIT.EDU ([18.62.0.6]) by Xerox.COM ; 15 MAY 87 13:36:00 PDT Received: by EDDIE.MIT.EDU with UUCP with smail2.3 with sendmail-5.31/4.7 id ; Fri, 15 May 87 16:34:35 EDT Received: by primerd.prime.com (1.1/SMI-3.0DEV3/smail) id AA04850; Fri, 15 May 87 15:56:14 EDT Message-Id: <8705151956.AA04850@primerd.prime.com> Received: (from user DOUG) by ENX.Prime.PDN; 15 May 87 15:26:08 EST To: COMMONLOOPS.PA@Xerox.COM From: primerd!DOUG@ENX.Prime.PDN.ARPA Date: 15 May 87 15:26:09 EST To: CommonLoops (commonloops.pa@xerox.com) Cc: Gregor (Gregor.pa@xerox.com), Steve Gadol (sgadol@sun.com) From: Doug Rand (doug@enx.prime.com) x4182 bldg 10 Date: 15 May 87 3:23 PM Subject: Change to output-structure in lucid-low for streams I have a corrected version of output-structure. The one distributed with PCL drives me crazy since streams actually print out. (defun output-structure (struct currlevel) (let ((type (structure-type struct))) (multiple-value-bind (length struct-type constructor print-function) (defstruct-info type) (declare (ignore struct-type constructor)) ;; Correct problem with streams being output (if (or (not *print-structure*) (streamp struct)) ;; End of correct (output-terse-object struct (if (streamp struct) "Stream" "Structure") type) (funcall (if print-function (symbol-function print-function) #'default-structure-print) struct *print-output* currlevel)))))  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 15 May 87 16:17:57 EDT Received: from HPLABS.HP.COM by SAIL.STANFORD.EDU with TCP; 15 May 87 13:15:24 PDT Received: from hplabsc by hplabs.HP.COM with TCP ; Fri, 15 May 87 13:14:28 pdt Received: by hplabsc ; Fri, 15 May 87 13:14:48 pdt Date: Fri, 15 May 87 13:14:48 pdt From: Jim Kempf Message-Id: <8705152014.AA11627@hplabsc> To: common-lisp-object-system@sail.stanford.edu Subject: Re: Why in MAKE-INSTANCE not generic? There seems to be a slight discrepency between 87-002 and 87-003 on this point. 87-002, pg. 2-44 implies that MAKE-INSTANCE is a programmer interface function, 87-003, pg. 3-7 implies that it is a method which is part of the metaobject protocol. Jim Kempf kempf@hplabs.hp.com  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 15 May 87 15:43:22 EDT Received: from HPLABS.HP.COM by SAIL.STANFORD.EDU with TCP; 15 May 87 12:40:34 PDT Received: from hplabsc by hplabs.HP.COM with TCP ; Fri, 15 May 87 12:39:40 pdt Received: by hplabsc ; Fri, 15 May 87 12:39:32 pdt Date: Fri, 15 May 87 12:39:32 pdt From: Jim Kempf Message-Id: <8705151939.AA11025@hplabsc> To: common-lisp-object-system@sail.stanford.edu Subject: Why is MAKE-INSTANCE not generic? 87-002 says that MAKE-INSTANCE is a function, and not a generic function. Why is this? In particular, a metaclass may want to specialize MAKE-INSTANCE to a particular metaclass-dependent instance creation procedure. The instance "creation" procedure might not fit into the ALLOCATE-INSTANCE/INITIALIZE pattern which MAKE-INSTANCE currently uses. I realize that instance creation is, as yet, not completely specified, but wanted to bring up the point anyway. Jim Kempf kempf@hplabs.hp.com  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 15 May 87 14:14:00 EDT Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 15 May 87 11:10:32 PDT Received: from Cabernet.ms by ArpaGateway.ms ; 15 MAY 87 11:07:52 PDT Date: 15 May 87 11:07 PDT From: Gregor.pa@Xerox.COM Subject: optimization versus constructors To: Common-Lisp-Object-System@Sail.Stanford.edu Message-ID: <870515-110752-4939@Xerox> Danny and I have been thinking about initialization and are picking away at parts of the problem we don't understand. Specifically, I was trying to remember what the :constructor option was really for. I remembered that: - it isn't really just an abbreviation for a defun and a call to make-instance since it can set slots which are not settable by initargs. - even if it was just an abbreviation for a defun with a call to make-instance, the constructors generated by the :constructor option would be much faster than the ones defined by calling make-instance by hand. This message addresses the second of these 2 points. Specifically, I will show a simple (even trivial) technique which reduces optimizing calls to make-instance to exactly the same problem as optimizing constructors produced by :constructor option. This is important because it means that we can think about constructors only in terms of their behavior, they are not needed for performance anymore. The basic idea is that a call to make-instance with a constant first argument and constant key (even numbered) args can be treated as a dynamic definition of an :constructor with some gensymed name. So that in the form (progn .. (make-instance 'boat :speed 10) ..) the call to make-instance can be converted to something like: (progn .. (#:G001 10) ..) and the class gets updated as if it had had a :constructor option (:constructor #:g001 (speed)). This shows that whatever optimization can be gotten from the :constructor option can also be gotten from calls to make-instance (at least the calls to make-instance for which you could have used a constructor).  Received: from Xerox.COM (TCP 1200400040) by AI.AI.MIT.EDU 15 May 87 09:41:41 EDT Received: from Cabernet.ms by ArpaGateway.ms ; 15 MAY 87 06:22:15 PDT Return-Path: <@MCC.COM:krall%pp.mcc.com@mcc.com> Received: from MCC.COM by Xerox.COM ; 15 MAY 87 06:21:12 PDT Received: from pp.mcc.com by MCC.COM with TCP; Fri 15 May 87 08:20:56-CDT Posted-Date: Friday, 15 May 1987, 08:20-CDT Message-Id: <8705151321.AA10737@pp.mcc.com> Received: from amber.pp.mcc.com by pp.mcc.com (4.12/KA70505) id AA10737; Fri, 15 May 87 08:21:03 cdt Date: Fri, 15 May 87 08:20 CDT From: Sender: krall%pp.mcc.com@mcc.com Subject: Keyword problem in PCL To: commonloops.pa@Xerox.COM Perhaps I am missing something, but the following behavior is a bit of a problem: Class AAA has an instance variable or slot called "name". Therefore subclass AA of AAA also has this slot. When I do a (make-instance 'AA :name "joe"), the slot that gets initialized is the one named pcl::name not user::name. Why is this? Because 1. the keyword lookup procedure (referenced from initialize-from-init-plist in the file slots.lsp) does a simple forward search on the value returned by class-instance-slots, and 2. this value lists the instance slots in ancestral order, and 3. the slots pcl::name and user::name have the same keyword, :name. I wonder if this is the optimal behavior. Shouldn't the more recent or local declaration (user::name) shadow the older and more general one (pcl::name)?  Received: from Xerox.COM (TCP 1200400040) by AI.AI.MIT.EDU 15 May 87 02:05:51 EDT Received: from Cabernet.ms by ArpaGateway.ms ; 14 MAY 87 22:18:48 PDT Return-Path: Received: from THEORY.CS.CMU.EDU ([128.2.254.182]) by Xerox.COM ; 14 MAY 87 22:17:35 PDT Date: Fri, 15 May 87 01:18:16 EDT From: Timothy.Freeman@theory.cs.cmu.edu To: commonloops.pa@Xerox.COM Subject: Lucid Walker can't walk labels Message-ID: <1987.5.15.5.13.17.Timothy.Freeman@theory.cs.cmu.edu> The version of PCL dated "4/29/87 prime April 29, 1987" can't walk labels forms in Lucid lisp. Here is my test file that illustrates this: (in-package :user) (use-package :pcl) (defclass tree () () (:accessor-prefix nil)) (defmethod baz ((self tree)) (with-slots (self) (labels ((rec-print-tree (node) 4))))) and here's what happens: > (compile-file "~/test/foo.lisp" :messages nil) >>Interrupt: segmentation violation MACROEXPAND-1: Required arg 0 (FORM): (LABELS ((REC-PRINT-TREE # 4)) (WALKER::MAKE-LEXICAL-ENVIRONMENT-2)) Optional arg 1 (ENV): -37339120 :A Abort to Lisp Top Level -> :n EVALHOOK: Required arg 0 (FORM): (LABELS ((REC-PRINT-TREE # 4)) (WALKER::MAKE-LEXICAL-ENVIRONMENT-2)) Required arg 1 (EVALHOOKFN): WALKER::MAKE-LEXICAL-ENVIRONMENT-1 Required arg 2 (APPLYHOOKFN): NIL Optional arg 3 (ENV): ((#S(LUCID::%VARIABLE NIL SELF NIL NIL NIL NIL NIL NIL NIL 0 NIL NIL) #S(LUCID::%ANODE NIL LAMBDA NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL #...)) (NIL #S(LUCID::%ANODE NIL LAMBDA NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL #...)) (#S(LUCID::%BLOCK NIL BAZ NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL)) NIL NIL (#S(LUCID::%DECL NIL CALL-NEXT-METHOD NIL LUCID::MVAR NIL #) #S(LUCID::%DECL NIL WITH-SLOTS NIL LUCID::MVAR N IL #)) NIL LUCID::%ALPHALEX) -> :n unnamed function: Required arg 0 (G1771): 62913901 -> :n WALKER::WALK-FLET/LABELS: Required arg 0 (FORM): (LABELS ((REC-PRINT-TREE # 4))) Required arg 1 (CONTEXT): :EVAL The rest of the backtrace looks fairly reasonable. Does anyone know how to fix this?  Received: from Xerox.COM (TCP 1200400040) by AI.AI.MIT.EDU 15 May 87 02:05:42 EDT Received: from Cabernet.ms by ArpaGateway.ms ; 14 MAY 87 20:14:21 PDT Return-Path: Received: from THEORY.CS.CMU.EDU ([128.2.254.182]) by Xerox.COM ; 14 MAY 87 20:12:33 PDT Date: Thu, 14 May 87 23:13:32 EDT From: Timothy.Freeman@theory.cs.cmu.edu To: commonloops.pa@Xerox.COM Subject: print-object Message-ID: <1987.5.15.3.10.44.Timothy.Freeman@theory.cs.cmu.edu> PCL differs from the CLOS spec in that the specializable method that the printer uses to print objects is called pcl::print-instance instead of pcl:print-object. Is this something that would be non-trivial to fix?  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 14 May 87 16:28:27 EDT Received: from HPLABS.HP.COM by SAIL.STANFORD.EDU with TCP; 14 May 87 13:22:01 PDT Received: from hplabsc by hplabs.HP.COM with TCP ; Thu, 14 May 87 13:21:05 pdt Received: by hplabsc ; Thu, 14 May 87 13:21:23 pdt Date: Thu, 14 May 87 13:21:23 pdt From: Jim Kempf Message-Id: <8705142021.AA26108@hplabsc> To: common-lisp-object-system@sail.stanford.edu Subject: Re: Printing Objects Cc: kempf%hplabsc@hplabs.HP.COM From Gregor: >Be warned, I am going to (mostly) dump on using printing for dumping. > >The reason defstruct has a readable representation for printed objects >is because defstruct is broken in this (and many other) regard. I >believe the default printed representation of defstruct types lulls >programmers into a false sense of believing that the problem of dumping >and restoring has been solved for them when in fact, that is not at all >true. From Dan Weinreb: > 4) The hooks should be part of the metaobject protocol, since the > metaobject protocol controls the representation of classes and > instances. > >I don't agree with this; it would be a real pain in the neck, and >overkill, to have to define a whole new metaclass just to say how an >instance is printed. Defining a method is far easier. Yow! Ok, let's forget it then. The default PRINT-OBJECT can print out in a nonreadable form, and it's up to the user to take care of printing in a class or metaclass specific way. From Gregor: >Here is a related question? > >What happens if an object appears as a constant in a piece of code that >is being compiled to a file? CLtL certainly is not clear on what >happens if a defstruct-defined structure appears in such a place. Is >print-object what you would like to call here?? In fact, CLtL doesn't specify how a constant ANYTHING gets compiled into file. It doesn't even specify that two references to a constant which are EQ during compilation will be EQ after the compiled file is loaded. The only thing which my reading of CLtL seems to indicate will be EQ is an interned symbol, and then only if the package exists in the load environment. I don't think you can realistically expect PRINT-OBJECT to be of use here, since everyone will have a different low level representation within compiled code files. The motivation for having a readable format was for easy exchange of objects between machines, and the ability to store objects in some default format, like DEFSTRUCT. But, as was pointed out, a general solution is probably still a research question. For examining the internals of an object, DESCRIBE (87-002, pg. 2-37) or INSPECT (CLtL, pg. 442, but not in 87-002) could be used. Jim Kempf kempf@hplabs.hp.com  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 13 May 87 17:55:41 EDT Received: from [192.10.41.109] by SAIL.STANFORD.EDU with TCP; 13 May 87 14:44:22 PDT Received: from CHICOPEE.SCRC.Symbolics.COM by ALDERAAN.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 81287; Wed 13-May-87 17:31:55 EDT Date: Wed, 13 May 87 17:31 EDT From: Daniel L. Weinreb Subject: Object Printing Discussion To: kempf%hplabsc@hplabs.HP.COM, common-lisp-object-system@sail.stanford.edu In-Reply-To: <8705131556.AA06328@hplabsc> Message-ID: <870513173115.5.DLW@CHICOPEE.SCRC.Symbolics.COM> Date: Wed, 13 May 87 08:56:15 pdt From: Jim Kempf 1) CLOS should specify a default printable object representation which is readable again, if only because programmers find it useful. The point is that it's not clear what "readable" means, and how useful it is. You'd have to be more careful about how this is defined. What if the value of one of the slots is a compiled code object? But even if all the values are symbols, you still have to make sure that people realize that reading this printed representation can only be said to "create a new instance which, in some respects, is like the instance that got printed", which isn't really guaranteeing very much. 2) This representation should be ASCII and should use existing Common Lisp read macros where possible, to facilitate portability and backward compatibility. (Not ASCII, but the CL character set, which is more restrictive than that. Portability to the 370, remember.) 4) The hooks should be part of the metaobject protocol, since the metaobject protocol controls the representation of classes and instances. I don't agree with this; it would be a real pain in the neck, and overkill, to have to define a whole new metaclass just to say how an instance is printed. Defining a method is far easier.  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 13 May 87 16:32:06 EDT Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 13 May 87 13:22:56 PDT Received: from Cabernet.ms by ArpaGateway.ms ; 13 MAY 87 12:51:11 PDT Date: 13 May 87 12:50 PDT From: Gregor.pa@Xerox.COM Subject: Re: Object Printing Discussion In-reply-to: Jim Kempf 's message of Wed, 13 May 87 08:56:15 pdt To: kempf%hplabsc@hplabs.HP.COM cc: common-lisp-object-system@sail.stanford.edu Message-ID: <870513-125111-2498@Xerox> Be warned, I am going to (mostly) dump on using printing for dumping. The reason defstruct has a readable representation for printed objects is because defstruct is broken in this (and many other) regard. I believe the default printed representation of defstruct types lulls programmers into a false sense of believing that the problem of dumping and restoring has been solved for them when in fact, that is not at all true. In my mind, printing an object for the user read its 'printed representation' and dumping an object so that some other program can restore it later are two completely different operations. In addition, depending on the application or mode, there may be many different ways to do each of these. Lets just look at dumping/restoring, what are some of the issues: - circularity, how to deal with it? - pointers to special "ground" objects which shouldn't be dumped but which should be "re-grounded" when the object is restored. - restoring an object but not all the objects it points to None of these questions is terribly hard, but they all have very different answers depending on the specific application. Whats more, none of these have to do with efficiency per se. I can add efficeincy as another problem, it only makes this more complicated. - efficiency of dump format. Certainly the #S format is about the least efficient dump format imaginable. It takes a lot of space, and it takes a lot of work at dump and restore time. So I guess my opinion is that it would be a mistake to try to standardize a 'generally useful for dumping' print function. Certainly any class or metaclass which wants to can provide a different method for print-object which would be the base of a whole dumping/restoring sub-protocol. So the hook is there for people to do whatever they want. But I think we would be doing them a diservice to pretend that we had provided them a general solution to this problem. Here is a related question? What happens if an object appears as a constant in a piece of code that is being compiled to a file? CLtL certainly is not clear on what happens if a defstruct-defined structure appears in such a place. Is print-object what you would like to call here??  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 13 May 87 14:41:08 EDT Received: from HPLABS.HP.COM by SAIL.STANFORD.EDU with TCP; 13 May 87 11:30:14 PDT Received: from hplabsc by hplabs.HP.COM with TCP ; Wed, 13 May 87 08:56:07 pdt Received: by hplabsc ; Wed, 13 May 87 08:56:15 pdt Date: Wed, 13 May 87 08:56:15 pdt From: Jim Kempf Message-Id: <8705131556.AA06328@hplabsc> To: common-lisp-object-system@sail.stanford.edu Subject: Object Printing Discussion Continuing the object printing discussion, I'd like to address some points brought up by Moon, and summarize things so far. Before going further, however, I'd like to provide some motivation for continuing this discussion. As mentioned in a previous note, the Objective-C Filer has proven to be a useful tool for Objective-C programmers, even though it does have some serious disadvantages as a mechanism for storing objects. Additionally, CommonObjects never defined a default storage mechanism (primarily because the issues of abstraction violation were not fully thought out) and it has proven to be a perennial problem. Binary storage mechanisms based on compiler modifications, databases and the like are all interesting, but some base level hooks and a simple default storage mechanism using existing Common Lisp read macros where possible and ASCII text can simplify applications development and provide backward compatibility with DEFSTRUCT. I'm sure, if it is not provided, someone will to question why DEFSTRUCT's have a readable storage representation and objects do not. On to the discussion: >Since we seem to be agreeing that the technique for creating objects >will not make the physical slots directly visible, but instead will add >a layer of abstraction, there is the issue that this transformation >may not be reversible: It may not be self-evident how to convert the >slot-values of an object into a set of arguments to make-instance that >will create an object with the same slot-values. Suppose that not all >of the slots have initargs that can initialize them. I agree with the need for a layer of abstraction, however, the level of MAKE-INSTANCE may be too high. In particular, if, as Moon's comments indicate, the defined initialization protocol for the class will not accomodate initializing an object with the current slot value when read back in, it would not be possible to write out an object's slot values and read them back in using MAKE-INSTANCE. An example would be when no initarg is defined for a slot (i.e., it is not initializable from MAKE-INSTANCE). >In addition to this issue of slot values, I don't think the concept >of "allowing an object printed out to be read back in" is well-defined, >because the concept of reading "the same object" is not well-defined. >In the simplest cases, creating an object of the same class with >slot values "printed out and read back in" will do the job, but only >in the simplest cases. In general, an object is part of a data structure >and ripping the object out of that data structure and jamming it >into a world by itself may not be meaningful. This is the same reason >why we don't provide a general copy-object function. I think you could make this argument for any Lisp data structure, including lists, vectors, or what have you. Perhaps more strongly for objects, since they tend to be more highly structured. I certainly agree it may not be meaningful to write out an object and read it back in, but, in the default case, I think the metaclass could provide some kind of meaning, which could then be customized on a class by class (or metaclass by metaclass) basis. In cases where it is not possible to provide meaning (like writing out packages and fundefs in Common Lisp), the #< read macro can be used to prohibit reading the representation back in. >I think it would make sense to have a standardized mixin class for >those simple objects whose semantics are defined entirely by the >values of their initializable slots. This class would define a >print-object method that used either #S(...) or #.(make-instance ...), >and would probably also define methods for copying and for dumping >into binary files output by compilers. This is fine; the thing I >want to be very cautious about is assuming that -all- objects should >have these methods. It's much better to package them in a mixin that >is there if you want it and not otherwise. Any suggestions for a >good name for this class? simple-object? As mentioned in a previous note, I think that control of object representation should be left to the metaclass, and therefore this functionality should be part of the metaobject protocol. The metaobject protocol controls how objects and classes get created within memory, and thus it seems logical that it should also control how objects move out to disc. . . . . . . Lacking any concensus on object creation, it's difficult to outline a detailed proposal as to what should be done. Here's a summary of my thinking on the issue so far: 1) CLOS should specify a default printable object representation which is readable again, if only because programmers find it useful. 2) This representation should be ASCII and should use existing Common Lisp read macros where possible, to facilitate portability and backward compatibility. 3) The abstraction level should be below MAKE-INSTANCE, so that slots which are not initable through MAKE-INSTANCE initargs can still be initialized, but above the level of simply setting the slot, so the class can customize initialization from a dumped object if desired. 4) The hooks should be part of the metaobject protocol, since the metaobject protocol controls the representation of classes and instances. With regard to 3) and 4), possibly the issue of conversion of slot values could be dealt with via a method on the STANDARD-SLOT-DESCRIPTION class. However, I'll forgo any detailed proposals until hearing whether there is any agreement about the overall issues. Jim Kempf kempf@hplabs.hp.com  Received: from Xerox.COM (TCP 1200400040) by AI.AI.MIT.EDU 13 May 87 13:21:45 EDT Received: from Salvador.ms by ArpaGateway.ms ; 13 MAY 87 09:53:48 PDT Return-Path: Received: from hplabs.HP.COM ([192.5.58.10]) by Xerox.COM ; 13 MAY 87 09:47:41 PDT Received: from hplabsc by hplabs.HP.COM with TCP ; Wed, 13 May 87 09:46:34 pdt Received: by hplabsc ; Wed, 13 May 87 09:46:50 pdt Date: Wed, 13 May 87 09:46:50 pdt From: Jim Kempf Message-Id: <8705131646.AA07073@hplabsc> To: commonloops.pa@Xerox.COM Subject: Implementing PRINT-OBJECT Why doesn't the ANSI 87-002 spec for PRINT-OBJECT include an argument for the current level. In particular, if PRINT-OBJECT is supposed to deal correctly with circular structures (as indicated in the 4th bullet item on pg. 2-51) using *PRINT-CIRCLE*, it must know the level. Unless an additional special is used to indicate the level, there is no way the PRINT-OBJECT can know it. Additionally, the DEFSTRUCT print functions require three arguments, including the print level. Why shouldn't PRINT-OBJECT as well? Jim Kempf kempf@hplabs.hp.com  Received: from Xerox.COM (TCP 1200400040) by AI.AI.MIT.EDU 12 May 87 10:24:18 EDT Received: from Cabernet.ms by ArpaGateway.ms ; 12 MAY 87 07:07:29 PDT Return-Path: <@MCC.COM:rcp@MCC.COM> Received: from MCC.COM by Xerox.COM ; 12 MAY 87 07:06:02 PDT Received: from milano.SW.MCC.COM by MCC.COM with TCP; Tue 12 May 87 09:05:01-CDT Received: from perseus (perseus.ARPA) by milano.SW.MCC.COM (4.12/STP1.44) id AA08478; Tue, 12 May 87 09:05:40 cdt Date: Tue, 12 May 87 09:02:58 CDT From: Rob Pettengill Message-Id: <8705121402.AA28385@perseus> Received: by perseus (3.2/STP) id AA28385; Tue, 12 May 87 09:02:58 CDT To: CommonLoops.pa@Xerox.COM, bug-lucid-ext%sw.MCC.COM@MCC.COM Subject: pcl 4/29 prime and sclisp-2.0.3 We finally got set up with Lucid SCLISP version 2.0.3 here, but we still have a problem Implementation: Lucid Common Lisp version Development Environment Version 2.0.3 Machine Type: Sun2 version 68010 Software Type: UNIX4.2 version 3.2 Site: perseus @ MCC Software Technology Program Features: FLAVORS, WINDOWS, EDITOR, FOREIGN-FUNCTION-CALL, FLOATING-POINT, COMPILER, MC68000, SUN, UNIX, LUCID, Modules: ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ;;;Comments: ;;; I finally got sclisp-2.0.3 and did compile-pcl. This error ;;; happened while loading the binary of fixup. ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ;;; Wrote output file #P"/usr/deli/src/pcl/pcl-04-29-87/fixup.lbin" ;;; Warning: The following functions are not known to be defined: ;;; COMBINE-METHODS was referenced by toplevel forms ;;; DS-OPTIONS-CONSTRUCTORS was referenced by toplevel forms ;;; EXPAND-CALL-NEXT-METHOD was referenced by #:G26305 Loading binary of FIXUP... >>Error: # should be of type STRUCTURE PUT-SLOT-USING-CLASS--CLASS-INTERNAL: Required arg 0 (CLASS): #1=# Required arg 1 (OBJECT): # Required arg 2 (SLOT-NAME): NAME Required arg 3 (NEW-VALUE): NIL Required arg 4 (DONT-CALL-SLOT-MISSING-P): NIL :A Abort to Lisp Top Level :C Supply a new value STACK DUMP: [LUCID::SPECIAL-BINDING] [UNWIND-PROTECT] [catch tag: LUCID::ENTER-DEBUGGER] [LUCID::SPECIAL-BINDING] [LUCID::SPECIAL-BINDING] [LUCID::SPECIAL-BINDING] [UNWIND-PROTECT] [LUCID::SPECIAL-BINDING] [UNWIND-PROTECT] [LUCID::SPECIAL-BINDING] [LUCID::SPECIAL-BINDING] CERROR: Required arg 0 (CONTINUE-FORMAT-STRING): "Supply a new value" Required arg 1 (FORMAT-STRING): "~S should be of type ~A" Rest arg (FORMAT-ARGS): (# STRUCTURE) SYSTEM:CHECK-TYPE-RUNTIME: Required arg 0 (VALUE): # Required arg 1 (TYPE): STRUCTURE Optional arg 2 (STRING): NIL LUCID::STRUCTURE-REF: Required arg 0 (S): # Required arg 1 (I): 0 Required arg 2 (TYPE): IWMC-CLASS PUT-SLOT-USING-CLASS--CLASS-INTERNAL: Required arg 0 (CLASS): #1=# Required arg 1 (OBJECT): # Required arg 2 (SLOT-NAME): NAME Required arg 3 (NEW-VALUE): NIL Required arg 4 (DONT-CALL-SLOT-MISSING-P): NIL Local 5: 0 Local 6: NIL Local 7: NIL (METHOD INITIALIZE-FROM-DEFAULTS (OBJECT)): Required arg 0 (SELF): # Local 1: #1=# Local 2: #1=(#2=# #3=#4=# #7=  Received: from Xerox.COM (TCP 1200400040) by AI.AI.MIT.EDU 11 May 87 13:46:20 EDT Received: from Cabernet.ms by ArpaGateway.ms ; 11 MAY 87 10:35:28 PDT Date: 11 May 87 10:33 PDT From: Gregor.pa@Xerox.COM Subject: new version of excl-low To: CommonLoops.pa@Xerox.COM Reply-to: Gregor.pa@Xerox.COM Message-ID: <870511-103528-2035@Xerox> This message is only important for people using PCL in ExCL (Franz Common Lisp). There is a new version of excl-low.lisp on parcvax.xerox.com. This fixes a bug which caused slot lookup caching to always miss. Anyone using PCL in ExCL should get a copy of this file and then use (compile-pcl) to recompile their pcl, and then recompile their files that use PCL. This should result in a significant speed improvement for many programs. Some cases of method lookup will be 5 times faster, compiled slot-access will be much faster. Its hard to quantify exactly, but it should definitely be noticeable.  Received: from Xerox.COM (TCP 1200400040) by AI.AI.MIT.EDU 10 May 87 19:51:28 EDT Received: from Cabernet.ms by ArpaGateway.ms ; 10 MAY 87 16:35:32 PDT Return-Path: Received: from hplabs.HP.COM ([192.5.58.10]) by Xerox.COM ; 10 MAY 87 16:34:29 PDT Received: from hplabsc by hplabs.HP.COM with TCP ; Sun, 10 May 87 16:33:48 pdt Received: by hplabsc ; Sun, 10 May 87 16:34:12 pdt Date: Sun, 10 May 87 16:34:12 pdt From: Jim Kempf Message-Id: <8705102334.AA03431@hplabsc> To: commonloops.pa@Xerox.COM Subject: GENERIC-FUNCTION-NAME and FIN's Apparently, the metobject generic functions are not getting their names set during bootstrapping. If I do (for example): (generic-function-name (symbol-function 'pcl::add-named-class)) I get: NIL In addition, none of the generic functions appear to be getting their names set via SET-FUNCALLABLE-INSTANCE-NAME. If I do: (funcallable-instance-name (symbol-function )) I get: 0 (what we initialize it to). From this, I make two conclusions: 1) As initially stated, the names of generic functions in the kernel are not getting set during bootstrapping. 2) The names of other, user defined generic functions are not getting set using SET-FUNCALLABLE-INSTANCE-NAME, but rather in some other way. Note that, since SET-FUNCALLABLE-INSTANCE-NAME has hooks into the implementation, it can set the name so that debugging and other environmental info. can be determined. These tests were done on the 4/21 beta version of PCL/PCLOS. Jim Kempf kempf@hplabs.hp.com  Received: from Xerox.COM (TCP 1200400040) by AI.AI.MIT.EDU 10 May 87 14:05:22 EDT Received: from Cabernet.ms by ArpaGateway.ms ; 10 MAY 87 10:46:14 PDT Return-Path: Received: from hplabs.HP.COM ([192.5.58.10]) by Xerox.COM ; 10 MAY 87 10:44:39 PDT Received: from hplabsc by hplabs.HP.COM with TCP ; Sun, 10 May 87 10:44:02 pdt Received: by hplabsc ; Sun, 10 May 87 10:44:28 pdt Date: Sun, 10 May 87 10:44:28 pdt From: Jim Kempf Message-Id: <8705101744.AA01755@hplabsc> To: commonloops.pa@Xerox.COM, primerd!DOUG@ENX.Prime.PDN.ARPA Subject: Re: :after and :before methods We have tried metnod combination in PCL/PCLOS and found that it does not, in fact, work, at least not in the 4/29 beta release. The value returned by a combination is just the value of the :AFTER method, and only the :AFTER method appears to be running. Jim Kempf kempf@hplabs.hp.com  Received: from Xerox.COM (TCP 1200400040) by AI.AI.MIT.EDU 8 May 87 19:43:46 EDT Received: from Cabernet.ms by ArpaGateway.ms ; 08 MAY 87 16:33:15 PDT Return-Path: Received: from EDDIE.MIT.EDU ([18.62.0.6]) by Xerox.COM ; 08 MAY 87 16:31:49 PDT Received: by EDDIE.MIT.EDU with UUCP with smail2.3 with sendmail-5.31/4.7 id ; Fri, 8 May 87 19:30:56 EDT Received: by primerd.prime.com (1.1/SMI-3.0DEV3/smail) id AA02217; Fri, 8 May 87 18:09:57 EDT Message-Id: <8705082209.AA02217@primerd.prime.com> Received: (from user DOUG) by ENX.Prime.PDN; 08 May 87 17:21:43 EST Subject: :after and :before methods To: commonloops.pa@Xerox.COM From: primerd!DOUG@ENX.Prime.PDN.ARPA Date: 08 May 87 17:21:43 EST Is declarative method combination working? For a subset? We have someone here who is porting FLAVORS code and badly needs this. If anyone has a patch to PCL or if a new version supporting this is imminent I'd like to know. Doug (doug@enx.prime.com)  Received: from Xerox.COM (TCP 1200400040) by AI.AI.MIT.EDU 7 May 87 23:48:10 EDT Received: from Salvador.ms by ArpaGateway.ms ; 07 MAY 87 20:16:11 PDT Return-Path: Received: from shambhala.berkeley.edu ([128.32.132.54]) by Xerox.COM ; 07 MAY 87 20:14:30 PDT Received: by shambhala.berkeley.edu (5.57/1.16) id AA02548; Thu, 7 May 87 20:13:18 PDT Message-Id: <8705080313.AA02548@shambhala.berkeley.edu> To: Timothy.Freeman@theory.cs.cmu.edu Cc: commonloops.pa@Xerox.COM, ricks@shambhala.berkeley.edu Subject: Re: Pseudo-dvi documents In-Reply-To: Your message of Thu, 07 May 87 22:39:52 -0400. <1987.5.8.2.37.48.Timothy.Freeman@theory.cs.cmu.edu> Date: Thu, 07 May 87 20:13:14 -0700 From: Rick L. Spickelmier DVI files are 8 bit files so you need to transfer them using binary mode in ftp. I had the same problem the first time I copied them (using ascii mode). Rick Spickelmier  Received: from Xerox.COM (TCP 1200400040) by AI.AI.MIT.EDU 7 May 87 22:49:51 EDT Received: from Salvador.ms by ArpaGateway.ms ; 07 MAY 87 19:40:48 PDT Return-Path: Received: from THEORY.CS.CMU.EDU ([128.2.254.182]) by Xerox.COM ; 07 MAY 87 19:39:17 PDT Date: Thu, 7 May 87 22:39:52 EDT From: Timothy.Freeman@theory.cs.cmu.edu To: commonloops.pa@Xerox.COM Subject: Pseudo-dvi documents Message-ID: <1987.5.8.2.37.48.Timothy.Freeman@theory.cs.cmu.edu> What is the format of the files doc/{concep,functi}.{am,cm}dvi? They don't seem to be dvi files, because my dvi file previewer complains that "POST is missing at head of preamble".  Received: from Xerox.COM (TCP 1200400040) by AI.AI.MIT.EDU 7 May 87 20:35:23 EDT Received: from Salvador.ms by ArpaGateway.ms ; 07 MAY 87 17:23:22 PDT Return-Path: Received: from hplabs.HP.COM ([192.5.58.10]) by Xerox.COM ; 07 MAY 87 17:21:29 PDT Received: from hplabsc by hplabs.HP.COM with TCP ; Thu, 7 May 87 15:54:31 pdt Received: by hplabsc ; Thu, 7 May 87 15:54:36 pdt Date: Thu, 7 May 87 15:54:36 pdt From: Jim Kempf Message-Id: <8705072254.AA01353@hplabsc> To: commonloops.pa@Xerox.COM Subject: WITH-SLOTS :USE-ACCESSORS The :USE-ACCESSORS keyword doesn't work in the 4/21/87 beta release of PCL/PCLOS. It still requires :USE-SLOT-VALUE. Jim Kempf kempf@hplabs.hp.com  Received: from Xerox.COM (TCP 1200400040) by AI.AI.MIT.EDU 7 May 87 16:47:30 EDT Received: from Cabernet.ms by ArpaGateway.ms ; 07 MAY 87 13:34:17 PDT Return-Path: Received: from ohio-state.ARPA ([192.5.58.18]) by Xerox.COM ; 07 MAY 87 13:32:30 PDT Return-Path: Received: from OSU-20 (osu-20.ARPA) by ohio-state.ARPA (4.12/6.1.OSU-CIS) id AA11854; Thu, 7 May 87 16:31:45 edt Message-Id: <8705072031.AA11854@ohio-state.ARPA> Date: Thu, 7 May 87 16:30:39 EDT From: Mike Subject: pcl-env problems To: commonloops.PA@Xerox.COM 3 problems-- (1) pcl-env.lisp is missing from /pub/pcl/xerox on parcvax. worse, pcl-env.dfasl & the 27 april 87 Lyric sysout seem to disagree about what constitutes a function. specifically: (2) if i-- (defclass aa () (a1 :initform 0)) (setf anaa (make-instance 'aa)) (inspect anaa) => an inspect window left-button the slot name middle-button ditto, => menu of one item: SET select SET i get a break-- Undefined Function PCL::INSPECT-SETF-SLOT-VALUE. In IL:OLDFAULT1 under IL:NEWFAULT1 under IL:FAULTEVAL under IL:EVAL under IL:LISPXEVAL [none of whose stack frames struck me as odd] (symbol-function 'PCL::INSPECT-SETF-SLOT-VALUE) is a compiled closure. (3) can't inspect compiled closures. trying it on the one above, i get another break-- ARG NOT IWMC-CLASS. In IL:ERROR under PCL::ALL-SLOTS under IL:INSPECTW.CREATEA000 under IL:INSPECTW.CREATE mike herring [herring@ohio-state.arpa] [.com ??] -------  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 7 May 87 11:59:02 EDT Received: from HPLABS.HP.COM by SAIL.STANFORD.EDU with TCP; 7 May 87 08:50:58 PDT Received: from hplabsc by hplabs.HP.COM with TCP ; Thu, 7 May 87 07:49:32 pdt Received: by hplabsc ; Thu, 7 May 87 07:49:54 pdt Date: Thu, 7 May 87 07:49:54 pdt From: Jim Kempf Message-Id: <8705071449.AA25199@hplabsc> To: Moon@STONY-BROOK.SCRC.Symbolics.COM, common-lisp-object-system@SAIL.STANFORD.EDU Subject: Re: Printing Objects Leaving aside the question of whether to use #S and how to match reading to MAKE-INSTANCE, couldn't the *PRINT-ESCAPE* switch play a role about whether an object is printed out in a form which is readable again? My reading of the description of *PRINT-ESCAPE* on pg. 370 of CLtL is not clear. The first paragraph seems to imply that this switch is supposed to primarily affect printing of symbols with strange print names, the second paragraph seems to imply that it serves a more general function in controlling whether a "structure" (and by this I interpret CLtL to mean any Common Lisp data structure, not just a DEFSTRUCT) gets printed in a way which makes it readable again. Perhaps this switch could be used for controlling whether the instance is printed in a readable or nonreadable form. Returning to the more general question, while I agree about the desirability for compiling objects into a binary form and writing them out, and other forms of saving objects, these will all be machine dependent. Looking at other object-oriented languages, one of the most attractive aspects of Objective-C to many programmers is the Filer, a way of writing an object out in ASCII form. It provides a kind of "lowest common denominator" persistence, and is a debugging aid too. A programmer can send a Filer generated representation of an Objective-C object around a local area network of diverse machines without much extra code to do conversion from one form to another. On the question of reading violating abstraction and who should know how to print out an object, I think it is the metaclass rather than the class which should know about how to print an object and read it again. The metaclass controls the low level representation of the object, thus should have the knowledge to decompose and write it out, and read it in again. For FUNCALLABLE-STANDARD-CLASS, for example, the metaclass method could do the same thing as is done for a fundef. For STANDARD-CLASS, a default method could be provided to read and write the object. Other metaclasses would need to supply their own methods. This should not, however, preclude a programmer from defining a method on a class which writes an object in some nonreadable form. I also agree that any read macro should go through MAKE-INSTANCE, to avoid violating the class/object abstraction. Maybe some combination of #S and #. could play a role, or maybe the default is simply: #.(make-instance (class-named Subject: Re: Printing Objects To: common-lisp-object-system@SAIL.STANFORD.EDU In-Reply-To: <870506-220014-1229@Xerox> Message-ID: <870507013351.7.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: 6 May 87 22:01 PDT From: Masinter.pa@Xerox.COM Of the alternatives: a) All objects print out as #S, if you want different behavior, you override it b) By default, objects can't print themselves, and you have to provide a print function or else mixin a standard class This is misleading. 87-002 requires that the implementation provide a default method. The issue in question is not whether objects can print themselves, but what happens you feed the output of that to read. Thus alternative b should be stated as "By default, objects print something that signals an error when read." If I wanted to be parallel to that, but biased, I would state alternative a as "By default, objects print something that creates a bogus object when read." Consider three cases: 1) object wants to print out as #S... 2) object cannot be printed really -- it doesn't make sense to "read" it 3) object wants to be printed in a special way Case 1: a is preferable, since what you want to do is already the default Case 2: b is only marginally better. In alternative a, you have to supply an error-if-you-print-me method or else you will get printing when you shouldn't really --if your erroneously print something and try to read it back in, alternative b gives you an error at print time, while alternative a gives you an error later on in your program. Not so, since Common Lisp is missing the :readably argument to WRITE. Alternative b gives you an error at read time, not print time. Case 3: it makes no difference, since you're supplying a print method. I think Case 1 is the most common in most of the program's I've seen anyway. Not in the programs I've seen. Leaving aside endless arguments about who's seen what programs, and turning to design rationales: I think it is better to signal an error when there is some question what people might want, and provide a way for them to say what they want, than to lead them down a garden path that ends up in a mysterious blowout because the system guessed their intention wrong. This is a general principle, but I think it applies to this case.  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 7 May 87 01:08:18 EDT Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 6 May 87 22:02:34 PDT Received: from Cabernet.ms by ArpaGateway.ms ; 06 MAY 87 22:00:14 PDT Date: 6 May 87 22:01 PDT From: Masinter.pa@Xerox.COM Subject: Re: Printing Objects In-reply-to: David A. Moon 's message of Wed, 6 May 87 23:22 EDT To: Moon@STONY-BROOK.SCRC.Symbolics.COM cc: common-lisp-object-system@SAIL.STANFORD.EDU Message-ID: <870506-220014-1229@Xerox> Of the alternatives: a) All objects print out as #S, if you want different behavior, you override it b) By default, objects can't print themselves, and you have to provide a print function or else mixin a standard class Consider three cases: 1) object wants to print out as #S... 2) object cannot be printed really -- it doesn't make sense to "read" it 3) object wants to be printed in a special way Case 1: a is preferable, since what you want to do is already the default Case 2: b is only marginally better. In alternative a, you have to supply an error-if-you-print-me method or else you will get printing when you shouldn't really --if your erroneously print something and try to read it back in, alternative b gives you an error at print time, while alternative a gives you an error later on in your program. Case 3: it makes no difference, since you're supplying a print method. I think Case 1 is the most common in most of the program's I've seen anyway.  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 6 May 87 23:31:02 EDT Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 6 May 87 20:24:42 PDT Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 133775; Wed 6-May-87 23:22:56 EDT Date: Wed, 6 May 87 23:22 EDT From: David A. Moon Subject: Re: Printing Objects To: common-lisp-object-system@SAIL.STANFORD.EDU In-Reply-To: <8705062000.AA15399@hplabsc> Message-ID: <870506232253.8.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Wed, 6 May 87 13:00:33 pdt From: Jim Kempf > Date: Wed, 6 May 87 09:34:12 pdt > From: Jim Kempf > > Looking through the PRINT-OBJECT specification, there is no read macro > specified for allowing an object printed out to be read back in. > >I don't see why #S couldn't be extended to read instances. Since #S >can only read "typed" structures (those that define a common lisp type), >the semantics wouldn't get changed. That would be OK too. Looking at the specification of #S, it could be extended to anything with a constructor. The important point is that the extension be noted in the CLOS specification, so it doesn't get lost. If we wanted a thing like #S for instances of standard classes, we would certainly use #S rather than inventing another read macro that does the same thing as #S. However, there are some problems with #S. Since we seem to be agreeing that the technique for creating objects will not make the physical slots directly visible, but instead will add a layer of abstraction, there is the issue that this transformation may not be reversible: It may not be self-evident how to convert the slot-values of an object into a set of arguments to make-instance that will create an object with the same slot-values. Suppose that not all of the slots have initargs that can initialize them. If instead we made #S bypass make-instance's abstraction and specify the physical slots directly, it would be a terrible violation of modularity. What this really shows, I think, is that only a method for the class in question can know what is the proper way to create an equivalent instance. In addition to this issue of slot values, I don't think the concept of "allowing an object printed out to be read back in" is well-defined, because the concept of reading "the same object" is not well-defined. In the simplest cases, creating an object of the same class with slot values "printed out and read back in" will do the job, but only in the simplest cases. In general, an object is part of a data structure and ripping the object out of that data structure and jamming it into a world by itself may not be meaningful. This is the same reason why we don't provide a general copy-object function. I think it would make sense to have a standardized mixin class for those simple objects whose semantics are defined entirely by the values of their initializable slots. This class would define a print-object method that used either #S(...) or #.(make-instance ...), and would probably also define methods for copying and for dumping into binary files output by compilers. This is fine; the thing I want to be very cautious about is assuming that -all- objects should have these methods. It's much better to package them in a mixin that is there if you want it and not otherwise. Any suggestions for a good name for this class? simple-object?  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 6 May 87 16:09:57 EDT Received: from HPLABS.HP.COM by SAIL.STANFORD.EDU with TCP; 6 May 87 13:03:08 PDT Received: from hplabsc by hplabs.HP.COM with TCP ; Wed, 6 May 87 13:00:01 pdt Received: by hplabsc ; Wed, 6 May 87 13:00:33 pdt Date: Wed, 6 May 87 13:00:33 pdt From: Jim Kempf Message-Id: <8705062000.AA15399@hplabsc> To: DUSSUD%Jenner%ti-csl.csnet@RELAY.CS.NET, kempf%hplabsc@hplabs.hp.com Subject: Re: Printing Objects Cc: common-lisp-object-system@SAIL.STANFORD.EDU > Date: Wed, 6 May 87 09:34:12 pdt > From: Jim Kempf > Subject: Printing Objects > > Looking through the PRINT-OBJECT specification, there is no read macro > specified for allowing an object printed out to be read back in. > Since DEFSTRUCT has the #S read macro, it seems as if something similar > should be available for instances of classes of the default metaclass. > #O comes to mind first, but, of course, that is used by octal numbers. > > Why not #@? From CLTL, pg. 352, this one looks free. > > Jim Kempf kempf@hplabs.hp.com > >I don't see why #S couldn't be extended to read instances. Since #S >can only read "typed" structures (those that define a common lisp type), >the semantics wouldn't get changed. > That would be OK too. Looking at the specification of #S, it could be extended to anything with a constructor. The important point is that the extension be noted in the CLOS specification, so it doesn't get lost. Jim Kempf kempf@hplabs.hp.com  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 6 May 87 14:47:54 EDT Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 6 May 87 11:42:06 PDT Received: from relay2.cs.net by RELAY.CS.NET id aa15417; 6 May 87 14:35 EDT Received: from ti-csl by RELAY.CS.NET id ab23481; 6 May 87 14:31 EDT Received: from Jenner (jenner.ARPA) by tilde id AA17350; Wed, 6 May 87 13:09:25 cdt Message-Id: <2756311822-982351@Jenner> Date: Wed, 6 May 87 13:10:22 CDT From: Patrick H Dussud To: Jim Kempf Cc: common-lisp-object-system@SAIL.STANFORD.EDU Subject: Re: Printing Objects In-Reply-To: Msg of Wed, 6 May 87 09:34:12 pdt from Jim Kempf Date: Wed, 6 May 87 09:34:12 pdt From: Jim Kempf Subject: Printing Objects Looking through the PRINT-OBJECT specification, there is no read macro specified for allowing an object printed out to be read back in. Since DEFSTRUCT has the #S read macro, it seems as if something similar should be available for instances of classes of the default metaclass. #O comes to mind first, but, of course, that is used by octal numbers. Why not #@? From CLTL, pg. 352, this one looks free. Jim Kempf kempf@hplabs.hp.com I don't see why #S couldn't be extended to read instances. Since #S can only read "typed" structures (those that define a common lisp type), the semantics wouldn't get changed.  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 6 May 87 12:42:16 EDT Received: from HPLABS.HP.COM by SAIL.STANFORD.EDU with TCP; 6 May 87 09:35:59 PDT Received: from hplabsc by hplabs.HP.COM with TCP ; Wed, 6 May 87 09:33:39 pdt Received: by hplabsc ; Wed, 6 May 87 09:34:12 pdt Date: Wed, 6 May 87 09:34:12 pdt From: Jim Kempf Message-Id: <8705061634.AA12121@hplabsc> To: common-lisp-object-system@sail.stanford.edu Subject: Printing Objects Looking through the PRINT-OBJECT specification, there is no read macro specified for allowing an object printed out to be read back in. Since DEFSTRUCT has the #S read macro, it seems as if something similar should be available for instances of classes of the default metaclass. #O comes to mind first, but, of course, that is used by octal numbers. Why not #@? From CLTL, pg. 352, this one looks free. Jim Kempf kempf@hplabs.hp.com  Received: from Xerox.COM (TCP 1200400040) by AI.AI.MIT.EDU 1 May 87 14:00:22 EDT Received: from Salvador.ms by ArpaGateway.ms ; 01 MAY 87 10:06:29 PDT Return-Path: Received: from caf.MIT.EDU ([18.62.0.232]) by Xerox.COM ; 01 MAY 87 10:03:56 PDT Return-Path: Received: from CHAPLIN.MIT.EDU by caf.MIT.EDU (5.54/MIT.1x) with CHAOS; on Fri, 1 May 87 12:56:29 EDT Message-Id: <2755875338-4462578@CHAPLIN> Sender: MBM@chaplin.MIT.EDU Date: Fri, 1 May 87 12:55:38 EDT From: MBM@caf.MIT.EDU To: "" Cc: "" , smh@EDDIE.MIT.EDU Subject: Re: imminent fixes to PCL In-Reply-To: Msg of 23 Apr 87 11:09 PDT from Gregor.pa@Xerox.COM Date: 23 Apr 87 11:09 PDT From: Gregor.pa@Xerox.COM Subject: imminent fixes to PCL The next release of PCL (which should be later today) will have at least the following bugs fixed: - It will run in Symbolics Release 6. - It will run in older versions of ExCL, the excl::fn-locals bug will be fixed. As of 4/29 and 4/29', it isnt fixed. In fsc-low, this cannot be compiled by Excl 1.5 (when (fboundp 'excl::fn_locals) (setf (excl::fn_locals fin) (excl::fn_locals new-value))) I suggest guarding this with a #+sun for now. Unfortunately, however, there is some other problem; ExCL 1.5 DUMPS CORE trying to compile fsc. Steve Hafflich (smh@eddie.mit.edu) of Franz has managed to get us a working version by changing some declares, but we dont really understand the problem (presumably at least an ExCL problem, not necessarily a PCL problem). If someone else is desperate to run in ExCL 1.5 on a vax I will make the changes available. --mike  Received: from Xerox.COM (TCP 1200400040) by AI.AI.MIT.EDU 30 Apr 87 21:42:04 EDT Received: from Salvador.ms by ArpaGateway.ms ; 30 APR 87 16:43:10 PDT Return-Path: <@MCC.COM:rcp@MCC.COM> Received: from MCC.COM by Xerox.COM ; 30 APR 87 16:40:15 PDT Received: from milano.SW.MCC.COM by MCC.COM with TCP; Thu 30 Apr 87 18:39:14-CDT Received: from perseus (perseus.ARPA) by milano.SW.MCC.COM (4.12/STP1.43) id AA01756; Thu, 30 Apr 87 18:40:15 cdt Date: Thu, 30 Apr 87 18:38:39 CDT From: Rob Pettengill Message-Id: <8704302338.AA17323@perseus> Received: by perseus (3.2/STP) id AA17323; Thu, 30 Apr 87 18:38:39 CDT To: CommonLoops.pa@Xerox.COM Subject: [RCP@MCC.COM: &allow-other-keys for initialize methods in pcl] Character-Type-Mappings: (1 0 (NIL 0) (NIL :BOLD NIL) "CPTFONTCB") (2 0 (NIL 0) (NIL :ITALIC NIL) "CPTFONTI") Fonts: CPTFONT, CPTFONTCB, CPTFONTI In Symbolics 3650 Zwei in Genera 7.0G1, IP-TCP 52.0, MCC Genera 7.0 Patches 4.11, MCC-Base 2.2, Experimental Rcp 18, Experimental STP Deli CLOS Shell 5, Experimental Portable Common Loops 5, Experimental X-Window-System 2.0, microcode 3650-MIC 394, FEP 206, Fep0:>g206-lisp.flod(6), Fep0:>g206-loaders.flod(6), Fep0:>g206-info.flod(6), Fep0:>G206-debug.flod(1), Machine serial number 30301, TCP-FTP Binary Loader Fix (from RCP:SYS;TCP-BINARY-LOADER-FIX.LISP.4), on Sabielocks: For the trivial example: (defclass foo () (alpha beta) (:accessor-prefix ||)) (defmethod INITIALIZE ((SELF foo) INIT-PLIST) (call-next-method) (let ((a (getf init-plist :a))) (when a (setf (alpha self) a)))) (setq f (make-instance 'foo :a 7)) generates this error. It would be very useful to be able to define additional initialization keywords for an init method. 1Error: :A is not a valid keyword in the init-plist. 0While in the function (PCL::METHOD PCL::INITIALIZE-FROM-INIT-PLIST (PCL::OBJECT))  (:INTERNAL (:INTERNAL #:G19506 0) 0)  (PCL::METHOD INITIALIZE (PCL::OBJECT)) The condition signalled was ZL:FERROR 1(PCL::METHOD PCL::INITIALIZE-FROM-INIT-PLIST (PCL::OBJECT))0: (P.C. = 71) Arg 0 (PCL::SELF): #S(FOO ALPHA NIL BETA NIL) Arg 1 (PCL::INIT-PLIST): (:A 7) Local 2: # Local 3: # Local 4: # Local 5: # Local 6 (PCL::CLASS): # Local 7 (PCL::INSTANCE-SLOTS): (# #) Local 8 (PCL::NON-INSTANCE-SLOTS): NIL Local 9 (PCL::.FIND-SLOTD-FUNCTION-CELL.): # Local 10 (PCL::KEYWORD-LOC): (:A 7) Local 11 (PCL::VALUE-LOC): (7) Local 12 (PCL::SLOTD): NIL Local 13 (PCL::ALLOW-OTHER-KEYS-P): 0 Local 14 (PCL::.ALLOW-OTHER-KEYWORDS-P-FUNCTION-CELL.): # 1(:INTERNAL (:INTERNAL #:G19506 0) 0)0: (P.C. = 131) Arg 0 (COMPILER:.LEXICAL-ENVIRONMENT-POINTER.): (# # NIL # NIL NIL NIL NIL NIL NIL ...) Arg 1 (PCL::|Discriminating Function Arg 0|): #S(FOO ALPHA NIL BETA NIL) Arg 2 (PCL::|Discriminating Function Arg 1|): (:A 7) 1(PCL::METHOD INITIALIZE (PCL::OBJECT))0: (P.C. = 6) Arg 0 (PCL::OBJECT): #S(FOO ALPHA NIL BETA NIL) Arg 1 (PCL::INIT-PLIST): (:A 7) 1PCL::CALL-NEXT-METHOD-INTERNAL0: (P.C. = 357) 2(from PCL:SOURCE;FIXUP) 0 Arg 0 (PCL::CURRENT-METHOD): # Rest arg (PCL::ARGS): (#S(FOO ALPHA NIL BETA NIL) (:A 7)) 1(PCL::METHOD INITIALIZE (FOO))0: (P.C. = 5) Arg 0 (SELF): #S(FOO ALPHA NIL BETA NIL) Arg 1 (INIT-PLIST): (:A 7) 1(:INTERNAL (:INTERNAL #:G16031 0) 0)0: (P.C. = 160) Arg 0 (COMPILER:.LEXICAL-ENVIRONMENT-POINTER.): (# # NIL NIL NIL NIL NIL NIL NIL NIL ...) Arg 1: #S(FOO ALPHA NIL BETA NIL) Arg 2: (:A 7) 1MAKE-INSTANCE0: (P.C. = 15) 2(from PCL:SOURCE;SLOTS) 0 Arg 0 (PCL::CLASS): FOO Local 0 (PCL::CLASS): # Rest arg (PCL::INIT-PLIST): (:A 7) 1SI:*EVAL0: (P.C. = 455) 2(from SYS:PATCH;SYSTEM-349-17) 0 Arg 0 (SYS:FORM): (MAKE-INSTANCE (QUOTE FOO) :A 7) Local 0 (SYS:FORM): NIL Arg 1 (SI:ENV): NIL 2 --Defaulted args:-- 0 Arg 2 (SI:HOOK): NIL 2Rest of stack: 1EVAL0: (P.C. = 7) 1SETQ0: (P.C. = 24) 1SI:*EVAL0: (P.C. = 172)2 (from SYS:PATCH;SYSTEM-349-17) 1EVAL0: (P.C. = 7) 1(:INTERNAL (:INTERNAL SI:BREAK-INTERNAL 1 SI:WITH-PROCESS-INTERACTIVE-PRIORITY-BODY) 1)0: (P.C. = 7) 1(:INTERNAL (:INTERNAL (:INTERNAL SI:LISP-COMMAND-LOOP-INTERNAL 0 SI:WITH-PROCESS-INTERACTIVE-PRIORITY-BODY) 0) 0 SI:WITH-PROCESS-NON-INTERACTIVE-PRIORITY-BODY)0: (P.C. = 11) 1(FLAVOR:METHOD SI:WITH-PROCESS-NON-INTERACTIVE-PRIORITY-INTERNAL SI:PROCESS)0: (P.C. = 43) 1(:INTERNAL (:INTERNAL SI:LISP-COMMAND-LOOP-INTERNAL 0 SI:WITH-PROCESS-INTERACTIVE-PRIORITY-BODY) 0)0: (P.C. = 331) 1TV:WITH-NOTIFICATION-MODE-INTERNAL0: (P.C. = 15) 1(:INTERNAL SI:LISP-COMMAND-LOOP-INTERNAL 0 SI:WITH-PROCESS-INTERACTIVE-PRIORITY-BODY)0: (P.C. = 52) 1(FLAVOR:METHOD SI:WITH-PROCESS-INTERACTIVE-PRIORITY-INTERNAL SI:PROCESS)0: (P.C. = 22) 1SI:LISP-COMMAND-LOOP-INTERNAL0: (P.C. = 27) 1(:INTERNAL SI:BREAK-INTERNAL 1 SI:WITH-PROCESS-INTERACTIVE-PRIORITY-BODY)0: (P.C. = 213) 1(FLAVOR:METHOD SI:WITH-PROCESS-INTERACTIVE-PRIORITY-INTERNAL SI:PROCESS)0: (P.C. = 40) 1SI:BREAK-INTERNAL0: (P.C. = 37) 1ZWEI:COM-BREAK0: (P.C. = 10) 1(:INTERNAL ZWEI:COMMAND-EXECUTE 0 SI:WITH-PROCESS-NON-INTERACTIVE-PRIORITY-BODY)0: (P.C. = 17) 1(FLAVOR:METHOD SI:WITH-PROCESS-NON-INTERACTIVE-PRIORITY-INTERNAL SI:PROCESS)0: (P.C. = 43) 1ZWEI:COMMAND-EXECUTE0: (P.C. = 57) 1ZWEI:PROCESS-COMMAND-CHAR0: (P.C. = 14) 1(FLAVOR:METHOD :EDIT ZWEI:EDITOR)0: (P.C. = 316) 1(:INTERNAL (FLAVOR:COMBINED :EDIT ZWEI:ZMACS-TOP-LEVEL-EDITOR) 1)0: (P.C. = 20) 1(:INTERNAL (FLAVOR:WHOPPER :EDIT ZWEI:EDITOR) 0 SI:WITH-PROCESS-INTERACTIVE-PRIORITY-BODY)0: (P.C. = 7) 1(FLAVOR:METHOD SI:WITH-PROCESS-INTERACTIVE-PRIORITY-INTERNAL SI:PROCESS)0: (P.C. = 40) 1(FLAVOR:WHOPPER :EDIT ZWEI:EDITOR)0: (P.C. = 20) 1(FLAVOR:COMBINED :EDIT ZWEI:ZMACS-TOP-LEVEL-EDITOR)0: (P.C. = 317) 1ZWEI:ZMACS-WINDOW-TOP-LEVEL0: (P.C. = 55)2 (from SYS:PATCH;SYSTEM-349-88) 1SI:PROCESS-TOP-LEVEL0: (P.C. = 45)  Received: from Xerox.COM (TCP 1200400040) by AI.AI.MIT.EDU 30 Apr 87 19:34:54 EDT Received: from Salvador.ms by ArpaGateway.ms ; 30 APR 87 15:25:54 PDT Date: 30 Apr 87 15:22 PDT From: Gregor.pa@Xerox.COM Subject: new release of PCL 4/29 prime To: CommonLoops.pa@Xerox.COM cc: Gregor.pa@Xerox.COM Reply-to: Gregor.pa@Xerox.COM Message-ID: <870430-152554-4406@Xerox> There is a new release of PCL on parcvax.xerox.com. This release is the same as yesterday's except that :dynamic and :class slots work. You may want to FTP only the defsys.lisp, slots.lisp and notes.text files. Note that this release (as well as yesterday's) exports far fewer symbols than previous releases of PCL. Specifically, it exports only those symbols specified in chapters 1 and 2 of the CLOS specification. Some programs may have import extra symbols from PCL. An excellent example is that any program which defines methods on print-instance will have to import print-instance.  Received: from Xerox.COM (TCP 1200400040) by AI.AI.MIT.EDU 30 Apr 87 14:23:31 EDT Received: from Cabernet.ms by ArpaGateway.ms ; 30 APR 87 10:15:24 PDT Date: 30 Apr 87 10:13 PDT From: Gregor.pa@Xerox.COM Subject: Re: Slots with :allocation :class or :dynamic In-reply-to: Roy D'Souza 's message of Wed, 29 Apr 87 17:24:14 pdt To: dsouza%hplrds@hplabs.HP.COM cc: CommonLoops.pa@Xerox.COM Message-ID: <870430-101524-3868@Xerox> This bug is now fixed in my sources and will be out on parcvax as part of 4/30 later today. The fix is a little different than your code but should have the same effect.  Received: from Xerox.COM (TCP 1200400040) by AI.AI.MIT.EDU 29 Apr 87 23:10:12 EDT Received: from Cabernet.ms by ArpaGateway.ms ; 29 APR 87 19:18:01 PDT Return-Path: Received: from hplabs.HP.COM ([192.5.58.10]) by Xerox.COM ; 29 APR 87 19:16:46 PDT Received: from hplms1 by hplabs.HP.COM with TCP ; Wed, 29 Apr 87 17:55:07 pdt Received: from hplrds (hplrds) by hplms1; Wed, 29 Apr 87 17:24:27 pdt Return-Path: Received: by hplrds ; Wed, 29 Apr 87 17:24:14 pdt Date: Wed, 29 Apr 87 17:24:14 pdt From: Roy D'Souza Message-Id: <8704300024.AA04914@hplrds> To: commonloops%hplrds@hplabs.HP.COM Subject: Slots with :allocation :class or :dynamic Cc: gregor%hplrds@hplabs.HP.COM, harris%hplrds@hplabs.HP.COM, kempf%hplrds@hplabs.HP.COM There appears to be a problem with accessing slots that are of allocation type :class or :dynamic in PCL "4/21/87 beta April 21rst 1987", using HP Lisp. For example: (defclass some-class (class) ((some-slot :allocation :class))) (setf some-instance (make 'some-class)) (setf (get-slot some-instance 'some-slot) 'some-value) [Accessing the slot 'some-slot' will give an error.] The problem appears to be in the file slots.l, and the redefining the macro 'slotd-assoc' as below appears to fix the problem. 'slotd-assoc' expects one of its args to be an a-list but is being given a list of slots instead. (defmacro slotd-assoc (slotd-name slotds) `(dolist (var ,slotds) (cond ((equal ,slotd-name (xyslotd-name var)) (return var))))) In file 'braid0.l', an accessor has to be defined for the slot 'name' in the class definition of standard-slotd. (I chose xyslotd-name to avoid a conflict with an existing function) (defclass standard-slotd (object) ((name :initform nil :accessor xyslotd-name) ... etc.] By the way, I encountered the same problem on PCL "4/29/87", and the same patch appeared to work. Roy D'Souza dsouza@hplabs.hp.com  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 29 Apr 87 21:41:25 EDT Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 29 Apr 87 18:35:58 PDT Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 127851; Wed 29-Apr-87 21:36:13 EDT Date: Wed, 29 Apr 87 21:36 EDT From: David A. Moon Subject: Object creation discussion (at last!) To: Common-Lisp-Object-System@sail.stanford.edu In-Reply-To: <870427013057.6.MOON@EUPHRATES.SCRC.Symbolics.COM> Message-ID: <870429213604.0.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Mon, 27 Apr 87 01:30 EDT From: David A. Moon I can see from the misunderstanding in the mail that I did an abysmal job of communicating my ideas. I'll try to send a more comprehensible essay tomorrow.... As you can see, I didn't get to it. I'm not going to be allowed that kind of time for this until some time next week, so if you have comments but you were waiting for that before sending them, open fire.  Received: from Xerox.COM (TCP 1200400040) by AI.AI.MIT.EDU 29 Apr 87 18:23:45 EDT Received: from Semillon.ms by ArpaGateway.ms ; 29 APR 87 14:07:02 PDT Date: Wed, 29 Apr 87 14:02 PDT From: Gregor.pa@Xerox.COM Subject: new release of PCL (4/29) To: CommonLoops.PA@Xerox.COM Message-ID: <870429140246.5.GREGOR@AVALON.isl.parc.xerox.com> Line-fold: no There is a new release of PCL on parcvax.xerox.com. The major changes in this release are: make has been renamed to make-instance make-instance has been renamed to allocate-instance get-slot has been renamed to slot-value In the case of make and get-slot you can continue to use the old name for a little while for compatibility. Code that calls make-instance MUST be converted to call allocate instance. As usual, please be sure to read the notes file for more details. Enjoy, and send bug reports. -------  Received: from Xerox.COM (TCP 1200400040) by AI.AI.MIT.EDU 29 Apr 87 18:23:36 EDT Received: from Cabernet.ms by ArpaGateway.ms ; 29 APR 87 12:50:37 PDT Date: 29 Apr 87 12:49 PDT From: Gregor.pa@Xerox.COM Subject: fixed amdvi file To: CommonLoops.pa@Xerox.COM Reply-to: Gregor.pa@Xerox.COM Message-ID: <870429-125037-2693@Xerox> The concep.amdvi file and functi.amdvi files in /pub/pcl/doc are now fixed so that they don't print everything 1 inch too far to the bottom right.  Received: from Xerox.COM (TCP 1200400040) by AI.AI.MIT.EDU 28 Apr 87 20:29:34 EDT Received: from Cabernet.ms by ArpaGateway.ms ; 28 APR 87 15:55:07 PDT Date: 28 Apr 87 15:53 PDT From: Gregor.pa@Xerox.COM Subject: Re: PCL 4/21 on Symbolics Genera 7 In-reply-to: Rob Pettengill 's message of Tue, 28 Apr 87 07:53:46 CDT To: rcp@MCC.COM cc: CommonLoops.pa@Xerox.COM Message-ID: <870428-155507-1650@Xerox> Date: Tue, 28 Apr 87 07:53:46 CDT From: Rob Pettengill I have found a couple of problems with the new defclass under genera 7. When I compile a file with defclass and defmethod forms (as opposed to incrementally compiling in the editor) - it seems that the class definitions are not "seen" in the compile time environment and I get errors like this one. Another Problem I have found is that while EXCL is happy with either (:accessor-prefix nil) or (:accessor-prefix ||), Genera 7 will only generate accessors given the latter. It takes (:accessor-prefix nil) happily but then doesn't generate accessors or setf methods for the slots. Both of these problems are fixed in my sources and will be included in the next release.  Received: from Xerox.COM (TCP 1200400040) by AI.AI.MIT.EDU 28 Apr 87 18:26:10 EDT Received: from Cabernet.ms by ArpaGateway.ms ; 28 APR 87 15:17:37 PDT Date: 28 Apr 87 15:14 PDT From: Gregor.pa@Xerox.COM Subject: Re: accessor-prefix In-reply-to: Rick L. Spickelmier 's message of Tue, 28 Apr 87 13:59:56 -0700 To: ricks%shambhala.Berkeley.EDU@BERKELEY.EDU cc: CommonLoops.pa@Xerox.COM Message-ID: <870428-151737-1583@Xerox> Date: Tue, 28 Apr 87 13:59:56 -0700 From: Rick L. Spickelmier NIL should be special cased since on page 2-18 of the CLOS specification it is used to specify an accessor with no 'conc-name'. 'parse-slot-description-internal' in braid1.lsp of 3/19/87 has: right, thanks, this fix is in my sources now and will be in the next release.  Received: from Xerox.COM (TCP 1200400040) by AI.AI.MIT.EDU 28 Apr 87 18:26:03 EDT Received: from Cabernet.ms by ArpaGateway.ms ; 28 APR 87 14:00:52 PDT Return-Path: Received: from shambhala.berkeley.edu ([128.32.132.54]) by Xerox.COM ; 28 APR 87 13:59:35 PDT Received: by shambhala.berkeley.edu (5.57/1.16) id AA14667; Tue, 28 Apr 87 14:00:05 PDT Message-Id: <8704282100.AA14667@shambhala.berkeley.edu> To: CommonLoops.pa@Xerox.COM Subject: accessor-prefix Date: Tue, 28 Apr 87 13:59:56 -0700 From: Rick L. Spickelmier VAXLISP T2.2 also distinguishes between (:accessor-prefix ||) and (:accessor-prefix nil) and does nothting with the 'nil' form (PCL 4/21/87). The 3/19/87 version accepted (:accessor-prefix nil). I hope this is right.... In defclass.lsp in the method 'parse-defclass-slot', the following code fragment builds accessor names: (dolist (option parsed-options) (when (listp option) (case (car option) (:accessor-prefix (push (intern (string-append (cadr option) name)) accessors)) (:reader-prefix (push (intern (string-append (cadr option) name)) readers))))) (string-append nil 'bob) => nilbob (string-append '|| 'bob) => bob NIL should be special cased since on page 2-18 of the CLOS specification it is used to specify an accessor with no 'conc-name'. 'parse-slot-description-internal' in braid1.lsp of 3/19/87 has: (if conc-name (symbol-append conc-name name) name) Rick Spickelmier  Received: from Xerox.COM (TCP 1200400040) by AI.AI.MIT.EDU 28 Apr 87 16:46:13 EDT Received: from Cabernet.ms by ArpaGateway.ms ; 28 APR 87 11:56:22 PDT Return-Path: <@MCC.COM:rcp@MCC.COM> Received: from MCC.COM by Xerox.COM ; 28 APR 87 11:55:03 PDT Received: from milano.SW.MCC.COM by MCC.COM with TCP; Tue 28 Apr 87 13:52:09-CDT Received: from perseus (perseus.ARPA) by milano.SW.MCC.COM (4.12/STP1.41) id AA01117; Tue, 28 Apr 87 13:53:03 cdt Date: Tue, 28 Apr 87 07:53:46 CDT From: Rob Pettengill Message-Id: <8704281253.AA14311@perseus> Received: by perseus (3.2/STP) id AA14311; Tue, 28 Apr 87 07:53:46 CDT To: CommonLoops.pa@Xerox.COM Subject: PCL 4/21 on Symbolics Genera 7 In Symbolics 3650 Compiler in Genera 7.0G1, IP-TCP 52.0, MCC Genera 7.0 Patches 4.11, MCC-Base 2.2, Experimental Rcp 18, Experimental STP Deli CLOS Shell 2, Experimental Portable Common Loops 3, Experimental X-Window-System 1.0, microcode 3650-MIC 394, FEP 206, Fep0:>g206-lisp.flod(6), Fep0:>g206-loaders.flod(6), Fep0:>g206-info.flod(6), Fep0:>G206-debug.flod(1), Machine serial number 30301, TCP-FTP Binary Loader Fix (from RCP:SYS;TCP-BINARY-LOADER-FIX.LISP.4), on Sabielocks: ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; I have found a couple of problems with the new defclass under genera 7. When I compile a file with defclass and defmethod forms (as opposed to incrementally compiling in the editor) - it seems that the class definitions are not "seen" in the compile time environment and I get errors like this one. Another Problem I have found is that while EXCL is happy with either (:accessor-prefix nil) or (:accessor-prefix ||), Genera 7 will only generate accessors given the latter. It takes (:accessor-prefix nil) happily but then doesn't generate accessors or setf methods for the slots. ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; 1Error: No class named: 2D-PLACEMENT. 0While in the function CLASS-NAMED  (PCL::METHOD PCL::PARSE-TYPE-SPECIFIER (PCL::GENERIC-FUNCTION PCL::BASIC-METHOD))  (:INTERNAL (:INTERNAL #:G18344 0) 0) While processing (DEFMETHOD TRANSLATION ((SELF 2D-PLACEMENT) &OPTIONAL OFFSET Y-OFFSET) "Return/Set the translation of the object with respect to its parent's coordinate system. Translation = Position-in-parent - Position-in-child ARGUMENTS: SELF is the object OFFSET is the new horzontal offset of the object's coordinate system or (TUPLE X-OFFSET Y-OFFSET) Y-OFFSET is the new vertical offset of the canvas coordinate system RETURNS: the translation as an object SIDE-EFFECTS: The coordinate transformation may be changed " (COND ((NULL OFFSET) (TUPLE # #)) ((TUPLE-P OFFSET) (SETF # # # #)) (T (SETF # OFFSET # Y-OFFSET)))) The condition signalled was ZL:FERROR 1CLASS-NAMED0: (P.C. = 15) 2(from PCL:SOURCE;MACROS) 0 Arg 0 (PCL::NAME): 2D-PLACEMENT Arg 1 (PCL::NO-ERROR-P): NIL 1(PCL::METHOD PCL::PARSE-TYPE-SPECIFIER (PCL::GENERIC-FUNCTION PCL::BASIC-METHOD))0: (P.C. = 14) Arg 0 (PCL::PROTO-GENERIC-FUNCTION): # Arg 1 (PCL::PROTO-METHOD): # Arg 2 (PCL::TYPE-SPECIFIER): 2D-PLACEMENT 1(:INTERNAL (:INTERNAL #:G18344 0) 0)0: (P.C. = 256) Arg 0 (COMPILER:.LEXICAL-ENVIRONMENT-POINTER.): (# # NIL # # NIL NIL NIL NIL NIL ...) Arg 1 (PCL::|Discriminating Function Arg 0|): # Arg 2 (PCL::|Discriminating Function Arg 1|): # Arg 3 (PCL::|Discriminating Function Arg 2|): 2D-PLACEMENT 1(PCL::METHOD PCL::PARSE-TYPE-SPECIFIERS (PCL::GENERIC-FUNCTION PCL::BASIC-METHOD))0: (P.C. = 13) Arg 0 (PCL::PROTO-GENERIC-FUNCTION): # Arg 1 (PCL::PROTO-METHOD): # Arg 2 (PCL::TYPE-SPECIFIERS): (2D-PLACEMENT) 1(:INTERNAL (:INTERNAL #:G18344 0) 0)0: (P.C. = 256) Arg 0 (COMPILER:.LEXICAL-ENVIRONMENT-POINTER.): (# # NIL # # NIL NIL NIL NIL NIL ...) Arg 1 (PCL::|Discriminating Function Arg 0|): # Arg 2 (PCL::|Discriminating Function Arg 1|): # Arg 3 (PCL::|Discriminating Function Arg 2|): (2D-PLACEMENT) 1PCL::REAL-COMPILE-METHOD-10: (P.C. = 16) 2(from PCL:SOURCE;METHODS) 0 Arg 0 (PCL::GENERIC-FUNCTION-NAME): TRANSLATION Arg 1 (PCL::METHOD-TYPE-SPECIFIERS): (2D-PLACEMENT) Arg 2 (PCL:METHOD-ARGLIST): (SELF &OPTIONAL OFFSET Y-OFFSET) Arg 3 (PCL::OPTIONS): NIL Arg 4 (DOCUMENTATION): (QUOTE "Return/Set the translation of the object with respect to its parent's coordinate system. Translation = Position-in-parent - Position-in-child ARGUMENTS: SELF is the object OFFSET is the new horzontal offset of the object's coordinate system or (TUPLE X-OFFSET Y-OFFSET) Y-OFFSET is the new vertical offset of the canvas coordinate system RETURNS: the translation as an object SIDE-EFFECTS: The coordinate transformation may be changed ") 1PCL::EXPAND-DEFMETHOD0: (P.C. = 66) 2(from PCL:SOURCE;BOOT) 0 Arg 0 (PCL::NAME): TRANSLATION Arg 1 (PCL::QUALIFIERS): NIL Arg 2 (SCL:ARGLIST): ((SELF 2D-PLACEMENT) &OPTIONAL OFFSET Y-OFFSET) Arg 3 (PCL::BODY): ("Return/Set the translation of the object with respect to its parent's coordinate system. Translation = Position-in-parent - Position-in-child ARGUMENTS: SELF is the object OFFSET is the new horzontal offset of the object's coordinate system or (TUPLE X-OFFSET Y-OFFSET) Y-OFFSET is the new vertical offset of the canvas coordinate system RETURNS: the translation as an object SIDE-EFFECTS: The coordinate transformation may be changed " (COND ((NULL OFFSET) (TUPLE # #)) ((TUPLE-P OFFSET) (SETF # # # #)) (T (SETF # OFFSET # Y-OFFSET)))) 1DEFMETHOD0: (P.C. = 12) 2(from PCL:SOURCE;BOOT) 0 Arg 0 (SI:.FORM.): (DEFMETHOD TRANSLATION ((SELF 2D-PLACEMENT) &OPTIONAL OFFSET Y-OFFSET) "Return/Set the translation of the object with respect to its parent's coordinate system. Translation = Position-in-parent - Position-in-child ARGUMENTS: SELF is the object OFFSET is the new horzontal offset of the object's coordinate system or (TUPLE X-OFFSET Y-OFFSET) Y-OFFSET is the new vertical offset of the canvas coordinate system RETURNS: the translation as an object SIDE-EFFECTS: The coordinate transformation may be changed " (COND ((NULL OFFSET) (TUPLE # #)) ((TUPLE-P OFFSET) (SETF # # # #)) (T (SETF # OFFSET # Y-OFFSET)))) Arg 1 (SI:.ENV.): NIL Special PCL::*CLASS-NAME-HASH-TABLE*: # 2Rest of stack: 1FUNCALL0: (P.C. = 5) 1SI:MACROEXPAND-1-INTERNAL0: (P.C. = 201) 1MACROEXPAND0: (P.C. = 11) 1(:INTERNAL COMPILER:COMPILE-PROCESS-DEFAULT 1 (:MACRO-EXPAND))0: (P.C. = 3) 1COMPILER:COMPILE-PROCESS-DEFAULT0: (P.C. = 30) 1COMPILER:COMPILE-TO-FILE0: (P.C. = 121) 1COMPILER:COMPILE-FROM-STREAM-10: (P.C. = 53) 1COMPILER:PROCESS-FORMS-FROM-STREAM0: (P.C. = 115) 1COMPILER:COMPILE-FROM-STREAM0: (P.C. = 231) 1COMPILER:COMPILE-FILE0: (P.C. = 233) 1ZWEI:COM-COMPILE-FILE0: (P.C. = 57) 1ZWEI:COM-EXTENDED-COMMAND0: (P.C. = 17) 1(:INTERNAL ZWEI:COMMAND-EXECUTE 0 SI:WITH-PROCESS-NON-INTERACTIVE-PRIORITY-BODY)0: (P.C. = 17) 1(FLAVOR:METHOD SI:WITH-PROCESS-NON-INTERACTIVE-PRIORITY-INTERNAL SI:PROCESS)0: (P.C. = 43) 1ZWEI:COMMAND-EXECUTE0: (P.C. = 57) 1ZWEI:PROCESS-COMMAND-CHAR0: (P.C. = 14) 1(FLAVOR:METHOD :EDIT ZWEI:EDITOR)0: (P.C. = 316) 1(:INTERNAL (FLAVOR:COMBINED :EDIT ZWEI:ZMACS-TOP-LEVEL-EDITOR) 1)0: (P.C. = 20) 1(:INTERNAL (FLAVOR:WHOPPER :EDIT ZWEI:EDITOR) 0 SI:WITH-PROCESS-INTERACTIVE-PRIORITY-BODY)0: (P.C. = 7) 1(FLAVOR:METHOD SI:WITH-PROCESS-INTERACTIVE-PRIORITY-INTERNAL SI:PROCESS)0: (P.C. = 40) 1(FLAVOR:WHOPPER :EDIT ZWEI:EDITOR)0: (P.C. = 20) 1(FLAVOR:COMBINED :EDIT ZWEI:ZMACS-TOP-LEVEL-EDITOR)0: (P.C. = 317) 1ZWEI:ZMACS-WINDOW-TOP-LEVEL0: (P.C. = 55)2 (from SYS:PATCH;SYSTEM-349-88) 1SI:PROCESS-TOP-LEVEL0: (P.C. = 45)  Received: from Xerox.COM (TCP 1200400040) by AI.AI.MIT.EDU 28 Apr 87 08:36:45 EDT Received: from Salvador.ms by ArpaGateway.ms ; 28 APR 87 04:21:25 PDT Return-Path: <@MCC.COM,@HAL.CAD.MCC.COM:Loeffler@MCC.COM> Received: from MCC.COM by Xerox.COM ; 28 APR 87 04:17:39 PDT Received: from HAL.CAD.MCC.COM by MCC.COM with TCP; Tue 28 Apr 87 06:16:21-CDT D,#TD1PsT[Begin using 006 escapes]Date: Monday, 27 April 1987, 18:25-CDT From: Postmaster at HAL.CAD.MCC.COM Subject: Unable to deliver letter Message-ID: <870427182558.1.LOEFFLER@HAL.CAD.MCC.COM> To: RCP@MCC.COM Resent-To: ext-commonloops@HAL.CAD.MCC.COM, rcp@MCC.COM Resent-From: David D. Loeffler Resent-Date: Tue, 28 Apr 87 06:15 CDT Resent-Message-ID: <870428061520.8.LOEFFLER@HAL.CAD.MCC.COM> Unable to deliver letter to the following recipient: CommonLoops.pa@Xerox.COM: After trying (without success) for 3 days to contact the relevant domain servers needed to resolve the name Xerox.COM, the Mailer has concluded there is no such host. ----- Text of letter follows ----- Received: from SABIE.SW.MCC.COM by HAL.CAD.MCC.COM via CHAOS with CHAOS-MAIL id 45129; Fri 24-Apr-87 18:21:28 CDT Date: Fri, 24 Apr 87 18:20 CDT From: Robert C. Pettengill Subject: PCL 4/21 on Symbolics Genera 7 To: CommonLoops.pa@Xerox.COM Message-ID: <870424182059.1.RCP@SABIE.SW.MCC.COM> Character-Type-Mappings: (1 0 (NIL 0) (NIL :BOLD NIL) "CPTFONTCB") (2 0 (NIL 0) (NIL :ITALIC NIL) "CPTFONTI") Fonts: CPTFONT, CPTFONTCB, CPTFONTI In Symbolics 3650 Compiler in Genera 7.0G1, IP-TCP 52.0, MCC Genera 7.0 Patches 4.11, MCC-Base 2.2, Experimental Rcp 18, Experimental STP Deli CLOS Shell 2, Experimental Portable Common Loops 3, Experimental X-Window-System 1.0, microcode 3650-MIC 394, FEP 206, Fep0:>g206-lisp.flod(6), Fep0:>g206-loaders.flod(6), Fep0:>g206-info.flod(6), Fep0:>G206-debug.flod(1), Machine serial number 30301, TCP-FTP Binary Loader Fix (from RCP:SYS;TCP-BINARY-LOADER-FIX.LISP.4), on Sabielocks: ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; I have found a couple of problems with the new defclass under genera 7. When I compile a file with defclass and defmethod forms (as opposed to incrementally compiling in the editor) - it seems that the class definitions are not "seen" in the compile time environment and I get errors like this one. Another Problem I have found is that while EXCL is happy with either (:accessor-prefix nil) or (:accessor-prefix ||), Genera 7 will only generate accessors given the latter. It takes (:accessor-prefix nil) happily but then doesn't generate accessors or setf methods for the slots. ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; 1Error: No class named: 2D-PLACEMENT. 0While in the function CLASS-NAMED  (PCL::METHOD PCL::PARSE-TYPE-SPECIFIER (PCL::GENERIC-FUNCTION PCL::BASIC-METHOD))  (:INTERNAL (:INTERNAL #:G18344 0) 0) While processing (DEFMETHOD TRANSLATION ((SELF 2D-PLACEMENT) &OPTIONAL OFFSET Y-OFFSET) "Return/Set the translation of the object with respect to its parent's coordinate system. Translation = Position-in-parent - Position-in-child ARGUMENTS: SELF is the object OFFSET is the new horzontal offset of the object's coordinate system or (TUPLE X-OFFSET Y-OFFSET) Y-OFFSET is the new vertical offset of the canvas coordinate system RETURNS: the translation as an object SIDE-EFFECTS: The coordinate transformation may be changed " (COND ((NULL OFFSET) (TUPLE # #)) ((TUPLE-P OFFSET) (SETF # # # #)) (T (SETF # OFFSET # Y-OFFSET)))) The condition signalled was ZL:FERROR 1CLASS-NAMED0: (P.C. = 15) 2(from PCL:SOURCE;MACROS) 0 Arg 0 (PCL::NAME): 2D-PLACEMENT Arg 1 (PCL::NO-ERROR-P): NIL 1(PCL::METHOD PCL::PARSE-TYPE-SPECIFIER (PCL::GENERIC-FUNCTION PCL::BASIC-METHOD))0: (P.C. = 14) Arg 0 (PCL::PROTO-GENERIC-FUNCTION): # Arg 1 (PCL::PROTO-METHOD): # Arg 2 (PCL::TYPE-SPECIFIER): 2D-PLACEMENT 1(:INTERNAL (:INTERNAL #:G18344 0) 0)0: (P.C. = 256) Arg 0 (COMPILER:.LEXICAL-ENVIRONMENT-POINTER.): (# # NIL # # NIL NIL NIL NIL NIL ...) Arg 1 (PCL::|Discriminating Function Arg 0|): # Arg 2 (PCL::|Discriminating Function Arg 1|): # Arg 3 (PCL::|Discriminating Function Arg 2|): 2D-PLACEMENT 1(PCL::METHOD PCL::PARSE-TYPE-SPECIFIERS (PCL::GENERIC-FUNCTION PCL::BASIC-METHOD))0: (P.C. = 13) Arg 0 (PCL::PROTO-GENERIC-FUNCTION): # Arg 1 (PCL::PROTO-METHOD): # Arg 2 (PCL::TYPE-SPECIFIERS): (2D-PLACEMENT) 1(:INTERNAL (:INTERNAL #:G18344 0) 0)0: (P.C. = 256) Arg 0 (COMPILER:.LEXICAL-ENVIRONMENT-POINTER.): (# # NIL # # NIL NIL NIL NIL NIL ...) Arg 1 (PCL::|Discriminating Function Arg 0|): # Arg 2 (PCL::|Discriminating Function Arg 1|): # Arg 3 (PCL::|Discriminating Function Arg 2|): (2D-PLACEMENT) 1PCL::REAL-COMPILE-METHOD-10: (P.C. = 16) 2(from PCL:SOURCE;METHODS) 0 Arg 0 (PCL::GENERIC-FUNCTION-NAME): TRANSLATION Arg 1 (PCL::METHOD-TYPE-SPECIFIERS): (2D-PLACEMENT) Arg 2 (PCL:METHOD-ARGLIST): (SELF &OPTIONAL OFFSET Y-OFFSET) Arg 3 (PCL::OPTIONS): NIL Arg 4 (DOCUMENTATION): (QUOTE "Return/Set the translation of the object with respect to its parent's coordinate system. Translation = Position-in-parent - Position-in-child ARGUMENTS: SELF is the object OFFSET is the new horzontal offset of the object's coordinate system or (TUPLE X-OFFSET Y-OFFSET) Y-OFFSET is the new vertical offset of the canvas coordinate system RETURNS: the translation as an object SIDE-EFFECTS: The coordinate transformation may be changed ") 1PCL::EXPAND-DEFMETHOD0: (P.C. = 66) 2(from PCL:SOURCE;BOOT) 0 Arg 0 (PCL::NAME): TRANSLATION Arg 1 (PCL::QUALIFIERS): NIL Arg 2 (SCL:ARGLIST): ((SELF 2D-PLACEMENT) &OPTIONAL OFFSET Y-OFFSET) Arg 3 (PCL::BODY): ("Return/Set the translation of the object with respect to its parent's coordinate system. Translation = Position-in-parent - Position-in-child ARGUMENTS: SELF is the object OFFSET is the new horzontal offset of the object's coordinate system or (TUPLE X-OFFSET Y-OFFSET) Y-OFFSET is the new vertical offset of the canvas coordinate system RETURNS: the translation as an object SIDE-EFFECTS: The coordinate transformation may be changed " (COND ((NULL OFFSET) (TUPLE # #)) ((TUPLE-P OFFSET) (SETF # # # #)) (T (SETF # OFFSET # Y-OFFSET)))) 1DEFMETHOD0: (P.C. = 12) 2(from PCL:SOURCE;BOOT) 0 Arg 0 (SI:.FORM.): (DEFMETHOD TRANSLATION ((SELF 2D-PLACEMENT) &OPTIONAL OFFSET Y-OFFSET) "Return/Set the translation of the object with respect to its parent's coordinate system. Translation = Position-in-parent - Position-in-child ARGUMENTS: SELF is the object OFFSET is the new horzontal offset of the object's coordinate system or (TUPLE X-OFFSET Y-OFFSET) Y-OFFSET is the new vertical offset of the canvas coordinate system RETURNS: the translation as an object SIDE-EFFECTS: The coordinate transformation may be changed " (COND ((NULL OFFSET) (TUPLE # #)) ((TUPLE-P OFFSET) (SETF # # # #)) (T (SETF # OFFSET # Y-OFFSET)))) Arg 1 (SI:.ENV.): NIL Special PCL::*CLASS-NAME-HASH-TABLE*: # 2Rest of stack: 1FUNCALL0: (P.C. = 5) 1SI:MACROEXPAND-1-INTERNAL0: (P.C. = 201) 1MACROEXPAND0: (P.C. = 11) 1(:INTERNAL COMPILER:COMPILE-PROCESS-DEFAULT 1 (:MACRO-EXPAND))0: (P.C. = 3) 1COMPILER:COMPILE-PROCESS-DEFAULT0: (P.C. = 30) 1COMPILER:COMPILE-TO-FILE0: (P.C. = 121) 1COMPILER:COMPILE-FROM-STREAM-10: (P.C. = 53) 1COMPILER:PROCESS-FORMS-FROM-STREAM0: (P.C. = 115) 1COMPILER:COMPILE-FROM-STREAM0: (P.C. = 231) 1COMPILER:COMPILE-FILE0: (P.C. = 233) 1ZWEI:COM-COMPILE-FILE0: (P.C. = 57) 1ZWEI:COM-EXTENDED-COMMAND0: (P.C. = 17) 1(:INTERNAL ZWEI:COMMAND-EXECUTE 0 SI:WITH-PROCESS-NON-INTERACTIVE-PRIORITY-BODY)0: (P.C. = 17) 1(FLAVOR:METHOD SI:WITH-PROCESS-NON-INTERACTIVE-PRIORITY-INTERNAL SI:PROCESS)0: (P.C. = 43) 1ZWEI:COMMAND-EXECUTE0: (P.C. = 57) 1ZWEI:PROCESS-COMMAND-CHAR0: (P.C. = 14) 1(FLAVOR:METHOD :EDIT ZWEI:EDITOR)0: (P.C. = 316) 1(:INTERNAL (FLAVOR:COMBINED :EDIT ZWEI:ZMACS-TOP-LEVEL-EDITOR) 1)0: (P.C. = 20) 1(:INTERNAL (FLAVOR:WHOPPER :EDIT ZWEI:EDITOR) 0 SI:WITH-PROCESS-INTERACTIVE-PRIORITY-BODY)0: (P.C. = 7) 1(FLAVOR:METHOD SI:WITH-PROCESS-INTERACTIVE-PRIORITY-INTERNAL SI:PROCESS)0: (P.C. = 40) 1(FLAVOR:WHOPPER :EDIT ZWEI:EDITOR)0: (P.C. = 20) 1(FLAVOR:COMBINED :EDIT ZWEI:ZMACS-TOP-LEVEL-EDITOR)0: (P.C. = 317) 1ZWEI:ZMACS-WINDOW-TOP-LEVEL0: (P.C. = 55)2 (from SYS:PATCH;SYSTEM-349-88) 1SI:PROCESS-TOP-LEVEL0: (P.C. = 45)  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 27 Apr 87 16:43:41 EDT Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 27 Apr 87 13:29:14 PDT Received: from relay2.cs.net by RELAY.CS.NET id ab26381; 27 Apr 87 16:20 EDT Received: from ti-csl by RELAY.CS.NET id ah07490; 27 Apr 87 16:17 EDT Received: from dsg (juliett.ARPA) by tilde id AA04504; Mon, 27 Apr 87 14:27:09 cdt Received: From Jenner By dsg Via CHAOS-NET With CHAOS-MAIL; Mon, 27 Apr 87 14:28:46 CDT Message-Id: <2755538893-1609268@Jenner> Date: Mon, 27 Apr 87 14:28:13 CDT From: Patrick H Dussud To: Common-Lisp-Object-System@SAIL.STANFORD.EDU Subject: Re: Object creation discussion (at last!) In-Reply-To: Msg of Mon, 27 Apr 87 01:30 EDT from "David A. Moon" Date: Mon, 27 Apr 87 01:30 EDT From: "David A. Moon" Subject: Object creation discussion (at last!) I can see from the misunderstanding in the mail that I did an abysmal job of communicating my ideas. I'll try to send a more comprehensible essay tomorrow, but for now I would like to just clarify a couple of points and then make some comments on excerpts from the mail in places where they might help communication. Complexity and simplicity are partly matters of taste, and largely matters of point of view. I try to take the point of view of the majority of programmers, who are using the outer interfaces of the system without necessarily understanding everything that's going on inside. No matter how beautifully we explain it, most programmers simply won't read beyond the point where they think they know everything they need to know to get their immediate job done. Now, it may be that we will decide that we would rather make life more complicated for people writing initialization methods in order to make the conceptual explanation shorter. That would be okay with me if it's done for good reasons, but we shouldn't just dismiss the other way without understanding it and understanding why I proposed it. I have a feeling this message isn't going to explain it adequately either, and if that happens I will apologize and follow up with a more carefully written explanation. One key point that I was trying to convey, and I think partially succeeded, was the need for information hiding (abstraction) in the arguments to make-instance and in relations among the various initialization specifications attached to a class and its superclasses. Another key point, which I don't think came through, was that each initarg should be explicitly defined, and should be defined in exactly one place. This is simply good modularity. Some aspects of what I proposed were reacting to user complaints about the way Flavors does it. I have the ambition of making this new standard better than Flavors. All this leads to the idea that initargs of types 2 and 4 (in the nomenclature of my 16 Apr message) should be defined by methods, since their meaning is implemented by methods. Similarly, type 3 should be defined by slot-options, since their meaning is entirely involved with slots. In Flavors, type 4 have the ugly property that they have to be defined in two places, once in the method that implements them and again in a defflavor form; it's easy to get these two places out of sync. Hence the proposal to use the lambda-list of a defmethod as the way to define these initargs. I would stress this point further by saying that an object system is going to be appreciated for its ease of use during program development. Adding a new method is a normal thing to do and will be easier (faster,...) on most implementation than DEFCLASS redefinition which is a more traumatic operation (potential obsolescence of class...). Adding a new initarg keyword to make-class for 2 or 4 does not make the class obsolete. We shouldn't be forced to reevaluate DEFCLASS for such a small and upwardly compatible change. Date: Thu, 23 Apr 87 08:03:20 pst From: Jim Kempf From subsequent discussion, it seems as if an additional DEFCLASS option, :DEFAULT-INITARGS is being proposed. I wonder if this is needed, considering that a user can already specify an initialization value via the :INITFORM option? Perhaps the metaclass ought to attend to this? Or the :INITFORM and :DEFAULT-INITARGS options should be merged? This indicates that I completely failed to convey what :default-initargs is about, and that in turn may possibly indicate that :default-initargs should be flushed. In my proposal there are two ways to specify a default for an initarg: at the point of definition, and remotely. To explain: when defining an initarg one can specify right there, locally, a default value form. For initargs that fill slots, this is the existing :initform slot-option; no need to invent anything new there. For initargs that are implemented by methods, this is the existing defaulting mechanism in the lambda-list; again, no need to invent anything new. Now for remote defaulting: here the idea is that one class defines what an initarg means, while a second class specifies a default for it; this is :default-initargs. When you mix the two classes together, the default meets up with the implementation and things work. The reason remote defaulting is desirable is twofold: (1) it's often useful when mixing classes together for one class to customize another class by specifying initialization options, in addition to the existing ability to customize a class by shadowing or wrapping methods; (2) for modularity reasons, when class A customizes class B by specifying an initarg that class B defines, class A shouldn't have to know whether the initarg fills a slot or is implemented by a method. If not for reason (2), remote defaulting wouldn't require a new mechanism, because it could be implemented using the existing mechanism of :initform for slot initargs plus call-next-method-with-arguments (proposed but not yet accepted) for method initargs. But I think reason (2) is important. Date: 23 Apr 87 18:24 PDT From: Gregor.pa@Xerox.COM What is the purpose of :initform anymore? You only need it when you want to specify the default value for a slot that isn't set by any initarg. This means that we have two mechanisms which do almost the same thing -- initargs which set slots are almost a superset of initforms. This is a sure sign of bad modularity. On the contrary, I think it's a sign of good modularity! The two mechanisms do almost the same thing inside the implementation, but from the point of view of someone on the outside who doesn't know the information that is supposed to be hidden from him by modular abstraction, they do rather different things. I could give a longer explanation of what I mean, but it's late, this message is already too long to ask anyone to read carefully, and I think I would just be repeating what I said a bit earlier. (defclass position () (x y) (:default-initargs (nil 0 x) (nil 0 y))) What I am trying to do is seperate what I perceive as the separate parts of what is going on into separate places. The reason I don't like this is that the information about a slot is no longer all in one place. Another way of saying it is that I think that information in defclass should be organized spatially rather than temporally, i.e. information pertaining to one slot should be together, rather than putting information pertaining to one phase of object creation together. One of the ways that I think defclass is better than defflavor is that it has done a better job of spatial organization by putting more of the information about a slot into slot options instead of scattering it around in various options some of which refer back to the slot by name. I see :default-initargs being on the client side (make-instance and such) and :initform being on the implementor side. One will supersede the other, but conceptually they are different and should be kept different.  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 27 Apr 87 01:37:20 EDT Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 26 Apr 87 22:30:57 PDT Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 124868; Mon 27-Apr-87 01:31:17 EDT Date: Mon, 27 Apr 87 01:30 EDT From: David A. Moon Subject: Object creation discussion (at last!) To: Common-Lisp-Object-System@sail.stanford.edu In-Reply-To: <870416002258.1.MOON@EUPHRATES.SCRC.Symbolics.COM>, <870421134012.6.MOON@EUPHRATES.SCRC.Symbolics.COM>, <870422134241.3.GREGOR@AVALON.isl.parc.xerox.com>, <870422172838.5.GREGOR@AVALON.isl.parc.xerox.com>, <8704231603.AA11434@hplabsc>, <870423-182427-1534@Xerox> Message-ID: <870427013057.6.MOON@EUPHRATES.SCRC.Symbolics.COM> I can see from the misunderstanding in the mail that I did an abysmal job of communicating my ideas. I'll try to send a more comprehensible essay tomorrow, but for now I would like to just clarify a couple of points and then make some comments on excerpts from the mail in places where they might help communication. Complexity and simplicity are partly matters of taste, and largely matters of point of view. I try to take the point of view of the majority of programmers, who are using the outer interfaces of the system without necessarily understanding everything that's going on inside. No matter how beautifully we explain it, most programmers simply won't read beyond the point where they think they know everything they need to know to get their immediate job done. Now, it may be that we will decide that we would rather make life more complicated for people writing initialization methods in order to make the conceptual explanation shorter. That would be okay with me if it's done for good reasons, but we shouldn't just dismiss the other way without understanding it and understanding why I proposed it. I have a feeling this message isn't going to explain it adequately either, and if that happens I will apologize and follow up with a more carefully written explanation. One key point that I was trying to convey, and I think partially succeeded, was the need for information hiding (abstraction) in the arguments to make-instance and in relations among the various initialization specifications attached to a class and its superclasses. Another key point, which I don't think came through, was that each initarg should be explicitly defined, and should be defined in exactly one place. This is simply good modularity. Some aspects of what I proposed were reacting to user complaints about the way Flavors does it. I have the ambition of making this new standard better than Flavors. All this leads to the idea that initargs of types 2 and 4 (in the nomenclature of my 16 Apr message) should be defined by methods, since their meaning is implemented by methods. Similarly, type 3 should be defined by slot-options, since their meaning is entirely involved with slots. In Flavors, type 4 have the ugly property that they have to be defined in two places, once in the method that implements them and again in a defflavor form; it's easy to get these two places out of sync. Hence the proposal to use the lambda-list of a defmethod as the way to define these initargs. Along with this, I tried to eliminate clunky syntax from initialization methods, hence the elimination of &allow-other-keys and the elimination of having to write :before all the time. If this is too confusing, we could invent a new syntax that both defines initargs and defines the method that implements them. Clearly this is the weakest part of my proposal. We could obviously simplify things a lot by getting rid of the :constructor option to defclass. I didn't put it in, at least not this year. I do think it ought to remain, in spite of its inherent complexity in any initialization proposal (previous ones I've seen have glossed over this rather than solving it), because I believe many users will find it quite useful. Date: Wed, 22 Apr 87 13:42 PDT From: Gregor.pa@Xerox.COM The special method combination type for initialize instance adds considerable conceptual overhead for very little functional gain. The goal was not functional gain, that is, the ability to program something you couldn't program before, but rather syntactic simplicity. Perhaps in the end we'll decide it's not worth it, but I'd like us to keep considering the question a bit longer. I admit that the basic method combination rule is simple enough to understand. But there are other aspects of this method combination types which will cause people to ask themeselves questions they will have a hard time answering with any kind of simple model of this thing. - if I don't have to say &allow-other-keys here, why do I have to say it in the normal kind of method combination? True, this is a problem. - why is it that I can't count on the methods getting all the initargs if I use &rest in the lambda-list? Note that this also robs useful functionality which exists everywhere else in Common Lisp. Specifically, it makes the &rest args &allow-other-keys idiom not work. This idiom is very useful for methods which want to process all the initargs in the init-plist in ways that makes those initargs interact. I can't figure out precisely all you're saying here, but I think this just stems from a half-baked idea that I wouldn't have included in the proposal if I had spent more time thinking about it before sending it. I was trying to do an efficiency optimization involving not consing lists of slot-filling initargs that have been defaulted, and I now think that was premature. We can revisit the question after the major framework is agreed upon, plus I always (except when I fall from grace) believe in the principle that designs should first consider what is right, and optimizations should be subordinate to that, fitting into an existing framework rather than distorting it. - If I redefine a initialize-instance method, will that effect the interpretation of all the :constructor lambda-lists involved? Will all those :constructors get fixed? Of course the constructors have to get fixed if you change something in a way that changes the compiled code that was supposed to have been generated for them. I think that fact is independent of details of all object creation proposals. The specific example that I think you were thinking about is when a positional parameter of a constructor is changed from something that only fills a slot and isn't cared about by initialize methods, to something that both fills a slot and is seen by initialize methods. In my proposal, adding an initialize-instance method could do this. In your most recent one, evaluating a defclass could do this. *** the complex rules for interpreting the lambda-list of :constructors .... example elided .... I don't see any problem here that I added. The lambda-list syntax of constructors is like defstruct, not like defun, but that's already in 87-002. Your example also touches upon the lambda-list of initialize-instance methods. Here the default for an argument that is already defaulted by defclass options would never be used, because all calls that reached the initialize-instance method would necessarily have to supply that argument. But I don't think there's anything new to Common Lisp in that. - what arguments does allocate-instance get? allocate-instance was intended to work exactly like initialize-instance, however the latter turns out. Date: Wed, 22 Apr 87 17:28 PDT From: Gregor.pa@Xerox.COM The default-initargs defclass option serves two purposes. It specifies all the initargs which can be passed to make-instance of this class, and it specifies default values for some of those initargs. This is an important modularity mistake, in my opinion. By combining these two things, which ought to be separate, you have lost the ability for one class to specify a default value for an initarg defined by another class. If specifying a default value always defines an initarg, there is no way to check the consistency of the set of initargs with default values specified against the set of initargs actually defined. If there is a misspelling, the default value will simply be discarded, since no method will receive it and do something with it. constructors can be thought of as providing a "boa" syntax for specific calls to make-instance. This can't work as long as constructors are allowed to fill slots that make-instance is not allowed to fill, which I think is an important ability because it gives the programmer more control over interfaces. Date: Thu, 23 Apr 87 08:03:20 pst From: Jim Kempf From subsequent discussion, it seems as if an additional DEFCLASS option, :DEFAULT-INITARGS is being proposed. I wonder if this is needed, considering that a user can already specify an initialization value via the :INITFORM option? Perhaps the metaclass ought to attend to this? Or the :INITFORM and :DEFAULT-INITARGS options should be merged? This indicates that I completely failed to convey what :default-initargs is about, and that in turn may possibly indicate that :default-initargs should be flushed. In my proposal there are two ways to specify a default for an initarg: at the point of definition, and remotely. To explain: when defining an initarg one can specify right there, locally, a default value form. For initargs that fill slots, this is the existing :initform slot-option; no need to invent anything new there. For initargs that are implemented by methods, this is the existing defaulting mechanism in the lambda-list; again, no need to invent anything new. Now for remote defaulting: here the idea is that one class defines what an initarg means, while a second class specifies a default for it; this is :default-initargs. When you mix the two classes together, the default meets up with the implementation and things work. The reason remote defaulting is desirable is twofold: (1) it's often useful when mixing classes together for one class to customize another class by specifying initialization options, in addition to the existing ability to customize a class by shadowing or wrapping methods; (2) for modularity reasons, when class A customizes class B by specifying an initarg that class B defines, class A shouldn't have to know whether the initarg fills a slot or is implemented by a method. If not for reason (2), remote defaulting wouldn't require a new mechanism, because it could be implemented using the existing mechanism of :initform for slot initargs plus call-next-method-with-arguments (proposed but not yet accepted) for method initargs. But I think reason (2) is important. I don't understand. What is understood here by the word "module"? Has it any relation to *MODULES* on pg. 188 and thus to the PROVIDE/REQUIRE mechanism? No relation. I meant the general computer-science concept of modules as subdivisions of a program that have some independence from each other, not something realized as an object in an implementation. What if a user defines a constructor function to make an object out of a list, or to return a symbol? If the constructor function tries to call initializaton methods, then what will be the result? Also, if the initialization succeeds, method definition and lookup might do the wrong thing if the low level structure of an instance is not what is expected. As an example, say the constructor function returns an integer, and there are two methods on a generic function, one with an INTEGER selector and one with the same class as the erring constructor function. In addition, I think the IN-LINE declaration could help getting speed out of a constructor. By "constructor", I meant the functions defined by the :constructor option to defclass. The syntax of that option doesn't admit any of the above possibilities. I wonder if you were getting at a different issue: what if the value returned by the allocate-instance method is not an instance of the exact class being instantiated? If the caller of allocate-instance simply assumes the type of this value is correct, all kinds of terrible things could happen, especially if slot-filling is open-coded in constructors. Danny's chapter 3 speaks of "recognizable blocks of storage", and I think we need to say something like that here. I think this issue is largely independent of the other details of object creation proposals, and needs to be resolved on its own. It's hard for me to say much about it since I don't understand why anyone would need to customize allocate-instance. Are the initforms run in the context of INITIALIZE-INSTANCE? We agreed some time ago that they are in the lexical environment in which the defclass was evaluated. Is WITH-SLOTS acceptable within an initform? WITH-SLOTS works everywhere (although it works more efficiently in some places). However, the object being created is not lexically available in the environment of initforms, so it isn't possible to access its slots. Some people have proposed that the object and the initargs be lexically available to initforms, and this does open some intriguing expressive possibilities. However, I think I prefer to say that anything this complicated should be done in initialize-instance methods instead. Date: 23 Apr 87 18:24 PDT From: Gregor.pa@Xerox.COM What is the purpose of :initform anymore? You only need it when you want to specify the default value for a slot that isn't set by any initarg. This means that we have two mechanisms which do almost the same thing -- initargs which set slots are almost a superset of initforms. This is a sure sign of bad modularity. On the contrary, I think it's a sign of good modularity! The two mechanisms do almost the same thing inside the implementation, but from the point of view of someone on the outside who doesn't know the information that is supposed to be hidden from him by modular abstraction, they do rather different things. I could give a longer explanation of what I mean, but it's late, this message is already too long to ask anyone to read carefully, and I think I would just be repeating what I said a bit earlier. (defclass position () (x y) (:default-initargs (nil 0 x) (nil 0 y))) What I am trying to do is seperate what I perceive as the separate parts of what is going on into separate places. The reason I don't like this is that the information about a slot is no longer all in one place. Another way of saying it is that I think that information in defclass should be organized spatially rather than temporally, i.e. information pertaining to one slot should be together, rather than putting information pertaining to one phase of object creation together. One of the ways that I think defclass is better than defflavor is that it has done a better job of spatial organization by putting more of the information about a slot into slot options instead of scattering it around in various options some of which refer back to the slot by name.  Received: from Xerox.COM (TCP 1200400040) by AI.AI.MIT.EDU 24 Apr 87 23:18:32 EDT Received: from Cabernet.ms by ArpaGateway.ms ; 24 APR 87 18:57:58 PDT Date: 24 Apr 87 18:56 PDT From: Gregor.pa@Xerox.COM Subject: Re: PCL on a TI In-reply-to: brill@vaxa.isi.edu (Dave Brill)'s message of 24 Apr 87 16:09 PST (Friday) To: brill@vaxa.isi.edu cc: CommonLoops.PA@Xerox.COM, macgregor@vaxa.isi.edu Message-ID: <870424-185758-3002@Xerox> Well I wouldn't be surprised if you were having trouble. Here is the story. The currently released version is missing special code (in fsc-low) for the Explorer. The version I am about to release has that special code for both Release 2 and Release 3 of TI Common Lisp. But it only works in release 3 because of a bug in release 2 which the people at TI and I are still working to track down.  Received: from Xerox.COM (TCP 1200400040) by AI.AI.MIT.EDU 24 Apr 87 21:38:43 EDT Received: from Salvador.ms by ArpaGateway.ms ; 24 APR 87 17:10:23 PDT Return-Path: Received: from vaxa.isi.edu by Xerox.COM ; 24 APR 87 17:08:58 PDT Received: by vaxa.isi.edu (4.12/4.7) id AA07396; Fri, 24 Apr 87 16:09:13 pst From: brill@vaxa.isi.edu (Dave Brill) Message-Id: <8704250009.AA07396@vaxa.isi.edu> Date: 24 Apr 87 16:09 PST (Friday) To: CommonLoops.PA@Xerox.COM Cc: macgregor@vaxa.isi.edu Subject: PCL on a TI We've been having some trouble bringing up CommonLoops on a TI Explorer. If anyone out there has done this successfully, we would appreciate talking to you. Thanks.  Received: from Xerox.COM (TCP 1200400040) by AI.AI.MIT.EDU 24 Apr 87 21:38:33 EDT Received: from Salvador.ms by ArpaGateway.ms ; 24 APR 87 17:04:05 PDT Return-Path: Received: from RELAY.CS.NET by Xerox.COM ; 24 APR 87 17:02:14 PDT Received: from relay2.cs.net by RELAY.CS.NET id aa00811; 24 Apr 87 19:55 EDT Received: from ucf.edu by RELAY.CS.NET id aa03052; 24 Apr 87 19:49 AST Received: by localhost.UUCP (5.51/6.0.UCF) id AA12372; Fri, 24 Apr 87 07:52:48 EDT Date: Fri, 24 Apr 87 07:52:48 EDT From: Mike Moshell Posted-Date: Fri, 24 Apr 87 07:52:48 EDT To: commonloops.pa@Xerox.COM Message-ID: <870424-170405-2911@Xerox> Please remove me from the mailing list; my students are now monitoring the mailings and will keep me informed. Thanks!  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 24 Apr 87 00:37:26 EDT Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 23 Apr 87 21:32:39 PDT Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 123676; Fri 24-Apr-87 00:32:46 EDT Date: Fri, 24 Apr 87 00:32 EDT From: David A. Moon Subject: CL types --> classes To: Common-Lisp-Object-System@Sail.Stanford.edu In-Reply-To: <870422144631.4.GREGOR@AVALON.isl.parc.xerox.com> Message-ID: <870424003237.6.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Wed, 22 Apr 87 14:46 PDT From: Gregor.pa@Xerox.COM My notes generally agree with your message. Here are the differences and extensions: They say COMPILED-FUNCTION is in the same boat with FUNCTION. KEYWORD Class can change by setf of symbol-package. There was an argument about whether Common Lisp allows setf of symbol-package, but I think we came up with a way to use IMPORT to change something that isn't a keyword into a keyword. Traditionally the type of an object is something you can't change. Does the existence of CHANGE-CLASS mean that KEYWORD should be a class? I feel like leaving out KEYWORD on the basis that extra classes shouldn't be put in if they aren't clearly useful, but this is an issue that could go either way. SIMPLE-ARRAY SIMPLE-BIT-VECTOR SIMPLE-STRING SIMPLE-VECTOR ?? What is the reason for this ?? Subrange is scrawled next to these on my notes. If these are subranges then KEYWORD is too. PACKAGE READTABLE RANDOM-STATE HASH-TABLE PATHNAME CLtL only requires that these types be disjoint with each other. We would like X3J13 to fix these too. There are probably a lot of implementations in which one or more of these is a subtype of ARRAY. That might be hard to fix efficiently? No list type-specifier names a class and no deftype names a class, say my notes. SHORT-FLOAT LONG-FLOAT SINGLE-FLOAT DOUBLE-FLOAT I don't believe we excluded these but I believe Pavel said he would write up the rules about how these work. The issue was that if there are methods defined for both SHORT-FLOAT and SINGLE-FLOAT, but these types are collapsed into one, the precedence order of the methods is not well-defined. The only thing we thought of in the meeting was to signal an error when this happens, but I suspect that would be unsatisfactory in practice. In the precedence relationships for built in classes with multiple direct superclasses, I think we decided on (defclass null (list symbol) ...) (defclass vector (array sequence) ...) (defclass list (cons sequence) ...) Are we ready to write this up yet?  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 23 Apr 87 23:25:38 EDT Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 23 Apr 87 20:20:33 PDT Received: from Cabernet.ms by ArpaGateway.ms ; 23 APR 87 18:24:27 PDT Date: 23 Apr 87 18:24 PDT From: Gregor.pa@Xerox.COM Subject: Re: Object Creation Discussion (at last!) In-reply-to: Jim Kempf 's message of Thu, 23 Apr 87 08:03:20 pst To: kempf%hplabsc@hplabs.HP.COM cc: common-lisp-object-system@sail.stanford.edu Message-ID: <870423-182427-1534@Xerox> Date: Thu, 23 Apr 87 08:03:20 pst From: Jim Kempf From subsequent discussion, it seems as if an additional DEFCLASS option, :DEFAULT-INITARGS is being proposed. I wonder if this is needed, considering that a user can already specify an initialization value via the :INITFORM option? Perhaps the metaclass ought to attend to this? Or the :INITFORM and :DEFAULT-INITARGS options should be merged? I don't think we have reduced initialization to its fundamental components yet. In this message I am trying to attack some of our assumptions to see if that can help us get at those fundamental components. What if we got rid of :initform?? What is the purpose of :initform anymore? You only need it when you want to specify the default value for a slot that isn't set by any initarg. This means that we have two mechanisms which do almost the same thing -- initargs which set slots are almost a superset of initforms. This is a sure sign of bad modularity. Let's just pretend you didn't have initforms but that you did want to be able to have some slots which had "default values" but which weren't initable from the initargs passed to make-instance. (in the terminology of all previous proposals: (defclass position () ((x 0) (y 0))) now, adopting a slighlty different syntax for :default-initargs, you could say: (defclass position () (x y) (:default-initargs (:moosefish1 0 x) (:moosefish2 0 y))) (apologies to Alan Snyder) This new syntax for default-initargs reads: ":moosefish1 is an initarg whose default value is 0 and which make-instance uses to set the value of the x slot..." :moosefish1 is some name which is chosen to be weird enough that no-one will ever use it. So, "in-effect" the slots are not initable in the call to make-instance. When the initialize-instance generic-function is called (whether that call is open coded or not) the values of the x and y slots are sure to be 0. :moosefish1 is silly of course (more apologies to Alan), but what about something like: (defclass position () (x y) (:default-initargs (nil 0 x) (nil 0 y))) What I am trying to do is seperate what I perceive as the separate parts of what is going on into separate places. 1. the structure of the instance is specified, the slots and their allocation. 2. the legal initarg names are specified 3. the default values for the initargs are specified 4. automatic initialization of the values of some of the slots by make instance is specified. the slot descriptions specify 1 (the structure of the instance) the cars of the :default-initargs option arguments specify the legal initarg names the cadrs specify the default value the caddrs specify which slots are set from the value. think of the :default-initargs syntax as being something like the syntax of what follows &key in a lambda list except reversed, so each can be one of: initarg | (initarg default-value) | (initarg default-value slot-name)  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 23 Apr 87 20:26:56 EDT Received: from HPLABS.HP.COM by SAIL.STANFORD.EDU with TCP; 23 Apr 87 17:22:03 PDT Received: from hplabsc by hplabs.HP.COM with TCP ; Thu, 23 Apr 87 15:38:10 pst Received: by hplabsc ; Thu, 23 Apr 87 15:27:22 pst Date: Thu, 23 Apr 87 15:27:22 pst From: Jim Kempf Message-Id: <8704232327.AA18524@hplabsc> To: Moon@STONY-BROOK.SCRC.Symbolics.COM, kempf%hplabsc@hplabs.HP.COM Subject: Re: CLOS Declaration Proposal Cc: common-lisp-object-system@sail.stanford.edu I understand the problem. I can see two possible solutions. 1) Introduce a declaration which invokes the metaclass functions. Something like: (PROCLAIM '(FREEZE-CLASS-PRECEDENCE-LIST FOO)) in the DEFSYS file would cause the class precedence list to be frozen. 2) Leave it up to use of (EVAL-WHEN (COMPILE EVAL) ... ) to do it. I don't like either of these much, but like a defclass option even less, since there are already so many. I'll give it some more thought. Thanks for pointing this out. jak  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 23 Apr 87 18:01:37 EDT Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 23 Apr 87 14:56:52 PDT Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 123315; Thu 23-Apr-87 17:53:57 EDT Date: Thu, 23 Apr 87 17:53 EDT From: David A. Moon Subject: Re: CLOS Declaration Proposal To: Jim Kempf cc: common-lisp-object-system@sail.stanford.edu In-Reply-To: <8704231709.AA12554@hplabsc> Message-ID: <870423175345.0.MOON@EUPHRATES.SCRC.Symbolics.COM> The only problem with using functions, rather than defclass options, to freeze attributes of classes is how to make these functions take effect at compile time, which is when they have to take effect to be of any use. Propose something.  Received: from Xerox.COM (TCP 1200400040) by AI.AI.MIT.EDU 23 Apr 87 17:24:37 EDT Received: from Cabernet.ms by ArpaGateway.ms ; 23 APR 87 12:02:41 PDT Date: 23 Apr 87 11:09 PDT From: Gregor.pa@Xerox.COM Subject: imminent fixes to PCL To: CommonLoops.pa@Xerox.COM Reply-to: Gregor.pa@Xerox.COM Message-ID: <870423-120241-533@Xerox> The next release of PCL (which should be later today) will have at least the following bugs fixed: - It will run in Symbolics Release 6. - It will run in older versions of ExCL, the excl::fn-locals bug will be fixed. - SLOT-VALUE will exist.  Received: from Xerox.COM (TCP 1200400040) by AI.AI.MIT.EDU 23 Apr 87 17:24:25 EDT Received: from Cabernet.ms by ArpaGateway.ms ; 23 APR 87 11:14:00 PDT Date: 23 Apr 87 11:09 PDT From: Gregor.pa@Xerox.COM Subject: imminent fixes to PCL To: CommonLoops.pa@Xerox.COM Reply-to: Gregor.pa@Xerox.COM Message-ID: <870423-111400-523@Xerox> The next release of PCL (which should be later today) will have at least the following bugs fixed: - It will run in Symbolics Release 6. - It will run in older versions of ExCL, the excl::fn-locals bug will be fixed. - SLOT-VALUE will exist.  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 23 Apr 87 15:55:43 EDT Received: from HPLABS.HP.COM by SAIL.STANFORD.EDU with TCP; 23 Apr 87 12:48:38 PDT Received: from hplabsc by hplabs.HP.COM with TCP ; Thu, 23 Apr 87 08:02:47 pst Received: by hplabsc ; Thu, 23 Apr 87 08:03:20 pst Date: Thu, 23 Apr 87 08:03:20 pst From: Jim Kempf Message-Id: <8704231603.AA11434@hplabsc> To: common-lisp-object-system@sail.stanford.edu Subject: Re: Object Creation Discussion (at last!) Comments on Moon's creation note (and subsequent discussion): OVERALL COMMENTS: I agree with Gregor that the proposal needs simplification. The special method combination type, the overemphasis on constructor speed (they could be simply declared IN-LINE) and the complex rules for lambda-list interpretation need some reworking. In addition, I would like to see the syntax for the :INITFORM, :INITARG, and :DEFAULT-INITARG options better integrated (see below for addition to Gregor's suggestion). SPECIFICS: *On symbols as initarg keys: > "initargs" (initialization arguments) are a set of named arguments that > control object creation and initialization. Each initarg has a name, which > is a symbol (not necessarily a keyword), and a value. The arguments to > make-instance, excepting the first, taken in pairs, are initargs. Subsequent discussion has cleared up this point as a potential area of incompatibility which needs a cleanup committee proposal. *On storage allocation: > Also customizable by the metaclass, because the metaclass controls the > stored representation of instances. This should probably be the "recommended" way of doing things. Though it's probably not a good idea to prohibit it, I think it should be encouraged for portability reasons. The metaobject protocol should be the lowest level, portable interface into the object system. Anything below should be system dependent. *On the proposed additional slot and class definition options: >3. Customizable by slot-description, which specifies a default value for the > slot and whether the slot can be filled with a value specified by the > client; if so, the slot-description specifies the name of the initarg > whose value is stored into the slot. >The :default-initargs defclass option is followed by alternating initarg >names and forms. If an initarg is not specified by the client nor by >a :default-initargs option in a more specific class, the form is evaluated >in the lexical environment of the defclass and the resulting value is used >for the initarg. From subsequent discussion, it seems as if an additional DEFCLASS option, :DEFAULT-INITARGS is being proposed. I wonder if this is needed, considering that a user can already specify an initialization value via the :INITFORM option? Perhaps the metaclass ought to attend to this? Or the :INITFORM and :DEFAULT-INITARGS options should be merged? In particular: >So, a defclass form like this: > > (defclass position () > ((x :initarg :x) > (y :initarg :y)) > (:default-initargs (:x 0) (:y 0) :rho :theta)) > Consider what the syntax would be if you wanted to specify an initform as well: (defclass position () ((x :initarg :x :initform 0) (y :initarg :y :initform 0)) (:default-initargs (:x 0) (:y 0) :rho :theta)) So why not simplify this as: (defclass position () ((x :initarg (:x 0)) (y :initarg (:y 0))) ( :rho :theta) ) Semantics are: 1) If MAKE-INSTANCE is called without an initialization list, the initialization values of X and Y are set to zero. 2) If initialization values are supplied in the initialization list, then they are used. 3) :RHO and :THETA are valid as keys for initargs to MAKE-INSTANCE in any case. If no value is given, then they are NIL. A suggestion for would be :ADDITIONAL-INITARGS. *On MAKE-INSTANCE and modules: >>> Is make-instance an intra-module or inter-module interface? > >Both. > >>> Do the arguments to make-instance correspond directly to actual stored >slots, or are they a more abstract concept, whose implementation in terms >of slots or in terms of something else is hidden from the caller? > >More abstract, because make-instance is often used as an inter-module I don't understand. What is understood here by the word "module"? Has it any relation to *MODULES* on pg. 188 and thus to the PROVIDE/REQUIRE mechanism? *On constructors: >>> What is the lambda-list of a constructor created by a :constructor >option with no lambda-list specified? > >It accepts the same arguments as make-instance, excepting the first. > >>> Do constructors call initialization methods? > >Yes. > >>> Why do we have a :constructor option to defclass? > >For speed; make-instance is interpretive, while constructors are compiled, >since they know the exact class that they are constructing, and since they can >be automatically recompiled if the class or any of its superclasses changes. I'm not quite sure how this fits in with the metaclass protocol. What if a user defines a constructor function to make an object out of a list, or to return a symbol? If the constructor function tries to call initializaton methods, then what will be the result? Also, if the initialization succeeds, method definition and lookup might do the wrong thing if the low level structure of an instance is not what is expected. As an example, say the constructor function returns an integer, and there are two methods on a generic function, one with an INTEGER selector and one with the same class as the erring constructor function. In addition, I think the IN-LINE declaration could help getting speed out of a constructor. *On the context in which an initialization is run: >The :initarg slot-option specifies that this slot can be filled in, and >specifies the initarg name. This slot-option can be given more than once. > >There is no defclass option that specifies initargs for all the slots, >because that would endorse a particular convention for naming initargs. > Are the initforms run in the context of INITIALIZE-INSTANCE? Is WITH-SLOTS acceptable within an initform? I think this proposal would satisfy Dave Martin's request for initialization hooks. I'm enclosing his message on this below. jak --------------------------------------------------------------------------- Well, what we currently have is the following: defmethod initialize ((self new-object) init-plist) (initialize-from-defaults self) (initialize-from-init-plist self init-plist) (apply #'new-instance self init-plist)) Where the new-instance function is defined to do nothing for new-object but takes an arbitrary list of keywords (generally including slot names) to set the values. What I would *like* to see is the function initialize (or some other name) initialize from the defaults, and then initialize from the init-plist only on slots keywords (this is what we do, I rewrote initialize-from-init-plist to ignore non-keyword slots) and then call a class specific function to do the remaining setup. It would be nice if slots which were read-only were still settable inside the initialization code (e.g. the resource id of a window object should be read-only, but I can't set it until the new-instance function is called). I was thinking about changing the initialize function to do the following: 1) initialize from the default value of each keyword slot; 2) use the setf function for setting from the init-plist argument for any keywords which correspond to slots; and 3) call a user-specifiable routine (i.e. have a slot in the class called initialize-method) which would be mandatory for each class and would be hacked to allow call-next-method to find the appropriate method for the super classes even if the method name differed. With this setup we avoid having to set aside new-instance as a reserved name, allow the system to set slot values appropriately (using the setf method should be a flaggable option), and hopefully be able to reduce the size of the new-instance function.  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 23 Apr 87 15:31:14 EDT Received: from HPLABS.HP.COM by SAIL.STANFORD.EDU with TCP; 23 Apr 87 12:25:23 PDT Received: from hplabsc by hplabs.HP.COM with TCP ; Thu, 23 Apr 87 09:10:55 pst Received: by hplabsc ; Thu, 23 Apr 87 09:09:09 pst Date: Thu, 23 Apr 87 09:09:09 pst From: Jim Kempf Message-Id: <8704231709.AA12554@hplabsc> To: common-lisp-object-system@sail.stanford.edu Subject: Re: (long) CLOS Declaration Proposal Text Some additional comments on the declaration discussion, and Moon's reply. Dick Gabrial, are you still there? > 5) If method combination is prohibited for a certain method, > any overhead which is needed to support method combination > in the general case could be avoided. > >I agree that this is a non-issue. OK, then, unless anyone else objects, we can drop any consideration of declarations for method combination. > (CLASS FOO X) > >I think (EXACT-CLASS FOO X) has a lot less potential for confusion. This syntax is fine with me. > a user may want to restrict a particular name to be a generic function > >I don't see why. I suggest leaving this out unless there is a good >reason for it (which should be articulated). I would like to see this resolved in the context of the GFLET, GFLABELS, and GLAMBDA proposals discussed earlier. In particular, I would like the ability to say: (MAPCAR LIST-OF-OBJECTS) and not have to do a global definition of the methods. A GENERIC-FUNCTION declaration might allow us to get away without introducing GFLET and GFLABELS. For example, the following could be legal: (DEFUN EXAMPLE (OBJECT-LIST) (FLET (FOO ((A FOO-CLASS)) A) (FOO ((B BAZ-CLASS)) B) ) (DECLARE (GENERIC-FUNCTION FOO)) (MAPCAR #'FOO OBJECT-LIST) ) or some similar syntax. Notice that this will not resolve the problem of GLAMBDA, however. >When a user creates a subclass of a "staticized" class, rather than >changing the semantics in some unclear way, I suggest signalling an >error if there is a conflict between the semantics frozen into the >superclass and the semantics that would exist if the superclass had not >been "staticized". The design principle here is that adding a >"staticize" declaration to a working program shouldn't change what it >does, only how fast it does it. I agree here. >The name MAKE-STATIC isn't the best. To me, it connotes a function that >returns an object that I can hand to the WRITE-SOUND function and get an >ugly noise from the speaker in my console. FREEZE-CLASS would be better. I like the idea of using FREEZE- for optimization and other postdevelopment processing. I would suggest the following additions to the metaobject protocol for this purpose: FREEZE-REDEFINITION Takes a class object as an argument and causes the definition of the class to be frozen. Any attempt to redefine the class will cause an error to be signalled. In order for a class's definition to be frozen, all superclass definitions must be frozen as well. An error will be signalled if this is not the case. FREEZE-SLOT-LAYOUT Causes slots to be located at fixed offsets if the class is used as a superclass during inheritence. Signals an error if all superclasses do not have frozen slot layout as well. FREEZE-CLASS-PRECEDENCE-LIST The class precedence list for the class argument is calculated (if it hasn't already been) and the class precedence for subclasses is frozen. An attempt to define a subclass whose included direct supers would cause a difference class precedence ordering causes an error to be signalled. An error is signalled if all superclasses of the class argument do not have frozen class precedence lists as well. jak  Received: from Xerox.COM (TCP 1200400040) by AI.AI.MIT.EDU 23 Apr 87 13:48:03 EDT Received: from Cabernet.ms by ArpaGateway.ms ; 23 APR 87 09:28:00 PDT Date: 23 Apr 87 09:26 PDT From: Gregor.pa@Xerox.COM Subject: Re: 'with' bug In-reply-to: ricks%shambhala.Berkeley.EDU@BERKELEY.EDU's message of Wed, 22 Apr 87 22:59:32 -0700 To: ricks%shambhala.Berkeley.EDU@BERKELEY.EDU cc: commonloops.pa@Xerox.COM Message-ID: <870423-092800-5028@Xerox> This is fixed in the version now on parcvax.  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 23 Apr 87 12:56:53 EDT Received: from HPLABS.HP.COM by SAIL.STANFORD.EDU with TCP; 23 Apr 87 09:51:39 PDT Received: from hplabsc by hplabs.HP.COM with TCP ; Thu, 23 Apr 87 08:13:56 pst Received: by hplabsc ; Thu, 23 Apr 87 08:14:08 pst Date: Thu, 23 Apr 87 08:14:08 pst From: Jim Kempf Message-Id: <8704231614.AA11598@hplabsc> To: common-lisp-object-system@sail.stanford.edu Subject: Re: CLOS Type Cleanup Gregor's list looks accurate. One comment on FUNCTION. If X3J13 fixes this, then a nice solution about what to do with funcallable instances might be to make them a subclass of FUNCTION. jak  Received: from Xerox.COM (TCP 1200400040) by AI.AI.MIT.EDU 23 Apr 87 03:16:05 EDT Received: from Salvador.ms by ArpaGateway.ms ; 22 APR 87 23:03:29 PDT Return-Path: Received: from shambhala.berkeley.edu ([128.32.132.54]) by Xerox.COM ; 22 APR 87 23:01:07 PDT Received: by shambhala.berkeley.edu (5.57/1.16) id AA06174; Wed, 22 Apr 87 21:59:36 PST Message-Id: <8704230559.AA06174@shambhala.berkeley.edu> To: commonloops.pa@Xerox.COM Subject: 'with' bug Date: Wed, 22 Apr 87 22:59:32 -0700 From: ricks%shambhala.Berkeley.EDU@BERKELEY.EDU 'expand-with-slots' uses 'slotd-accessor', but it is not defined anywhere..... It looks like this was not updated when the ability to have multiple accessor functions on each slot was added. Try this: (defclass bob () (a b) (:accessor-prefix ||) (:constructor make-bob)) (defmethod fred ((self bob)) (with (self) a)) (fred (make-bob)) ;;; error ;;; pcl::slotd-accessor is undefined Rick Spickelmier UC Berkeley  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 22 Apr 87 20:39:46 EDT Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 22 Apr 87 17:29:01 PDT Received: from Cabernet.ms by ArpaGateway.ms ; 22 APR 87 17:30:04 PDT Date: Wed, 22 Apr 87 17:28 PDT From: Gregor.pa@Xerox.COM Subject: Re: Object creation discussion (at last!) To: Moon@STONY-BROOK.SCRC.Symbolics.COM cc: Common-Lisp-Object-System@Sail.Stanford.edu Message-ID: <870422172838.5.GREGOR@AVALON.isl.parc.xerox.com> Line-fold: no OK, here is a try at a counter proposal which tries to show what I do and don't like about your proposal. This isn't finished yet, once again I thought it would be better to send it out now so that you could see where I was headed. Basically, my proposal keeps these features from your proposal: :initarg slot option :default-initargs defclass option (different syntax) make-instance processes slot initargs or evaluates initforms constructors can be faster because they can inline stuff and gets rid of these: the new method combination type for initialize instance using &key in an initialize-instance method augments legal initargs SO: The :initarg slot option can be used to teach make-instance the name of an initarg which can be used to initialize the value of this slot from the initargs passed to make-instance. The way to think of this option is that it implements the abstract initarg name to slot name mapping for make-instance. For convenience, specifying an :initarg name in a slot description also includes that initarg name in the :default-initargs of the defclass. The default-initargs defclass option serves two purposes. It specifies all the initargs which can be passed to make-instance of this class, and it specifies default values for some of those initargs. The syntax of this option is a lot like the part of a lambda-list following &key (which serves two similar purposes). For example: (:default-initargs :foo :bar (:baz 3)) says that this class accepts initargs :FOO, :BAR and :BAZ. Furthermore, the default value of the :BAZ initarg is 3. The default values of :FOO and :BAR are both nil. So, a defclass form like this: (defclass position () ((x :initarg :x) (y :initarg :y)) (:default-initargs (:x 0) (:y 0) :rho :theta)) can be read as saying: make-instance with a first argument of POSITION accepts 4 initargs (:x :y :rho :theta). The default value for :x and :y is 0; the default value for :rho and :theta is nil. When make-instance is called, it sets the value of the x slot of the instance to the value of the :x initarg ..(same for y and :y). make-instance calls allocate-instance generic-function with all the initargs (the ones passed to make-instance plus any defaulted ones). It then sets the values of any slots for which initargs appear in the initargs, it then sets the values of the remaining slots from their initforms. It then calls the intialize-instance generic-function with all the initargs. constructors can be thought of as providing a "boa" syntax for specific calls to make-instance. Because make-instance is a function and not a generic-function, constructors are allowed to "perform the same actions calling make-instance would have" rather than calling make-instance directly. As a result, in many implementations, constructors are faster than the corresponding call to make-instance. To produce the "call to make-instance" a constructor interprets its lambda-list as follows: - if an element of its lambda-list names an initarg acceptable to this class, then that initarg pair will appear in the "call to make-instance". - if an element of the lambda list does not name an initarg, but names a slot this is an abbreviation for defining a gensymed initarg for that slot and using that gensym. [This needs work or perhaps need to be removed. I want to try to make this case be an abbreviation for something that is already understood.] - if neither of the above are true, calling the constructor signals an error. Some implementations may warn earlier of course. initialize-instance uses the default kind of method combination. Note that all initialize-instance methods should say &allow-other-keys. Under some programming styles, many initialize-instance methods will be :before methods. Under other programming styles they will not be, they will probably use call-next-method. -------  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 22 Apr 87 19:48:22 EDT Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 22 Apr 87 16:39:50 PDT Received: from Cabernet.ms by ArpaGateway.ms ; 22 APR 87 16:40:52 PDT Date: 22 Apr 87 16:40 PDT From: Gregor.pa@Xerox.COM Subject: funcallable-standard-class To: Common-Lisp-Object-System@Sail.Stanford.edu Message-ID: <870422-164052-4316@Xerox> Another note just to record something we all need to think about. We need to document the metaclass which generic-function classes use. This is so that people can define their own generic-function classes (the need to know what :metaclass to specify). Also, the funcallable-instance functionality is useful enough, and easy enough to document that I think we should make it generally available. This note will serve to remind me to mail out a proposal about this based on what is now in PCL.  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 22 Apr 87 19:45:15 EDT Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 22 Apr 87 16:37:24 PDT Received: from Cabernet.ms by ArpaGateway.ms ; 22 APR 87 16:37:59 PDT Date: 22 Apr 87 16:37 PDT From: Gregor.pa@Xerox.COM Subject: note about clos instance disjointness To: Common-Lisp-Object-System@Sail.Stanford.edu Message-ID: <870422-163759-4304@Xerox> I don't know exactly where this would fit in in the document, but we need to say that instances of standard-classes have type disjoint with all other types. This is kind of obvious of course, but should be made explicit.  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 22 Apr 87 18:43:06 EDT Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 22 Apr 87 15:33:09 PDT Received: from Cabernet.ms by ArpaGateway.ms ; 22 APR 87 15:19:17 PDT Date: 22 Apr 87 15:19 PDT From: Pavel.pa@Xerox.COM Subject: Re: CL types --> classes In-reply-to: Gregor.pa's message of Wed, 22 Apr 87 14:46 PDT To: Common-Lisp-Object-System@Sail.Stanford.edu Message-ID: <870422-151917-4178@Xerox> SHORT-FLOAT LONG-FLOAT SINGLE-FLOAT DOUBLE-FLOAT I don't believe we excluded these but I believe either Pavel or Patrick said they would write up the rules about how these work. I indeed said that I would write these up. I'll be able to get to it later this week. Pavel  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 22 Apr 87 17:57:57 EDT Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 22 Apr 87 14:48:35 PDT Received: from Semillon.ms by ArpaGateway.ms ; 22 APR 87 14:48:02 PDT Date: Wed, 22 Apr 87 14:46 PDT From: Gregor.pa@Xerox.COM Subject: CL types --> classes To: Common-Lisp-Object-System@Sail.Stanford.edu Message-ID: <870422144631.4.GREGOR@AVALON.isl.parc.xerox.com> Line-fold: no This message is a brief summary of what I believe we decided about which Common Lisp types could be classes. This is take from Sonya's very careful notes and my less careful memory. If we pass this message back and forth for a while it could probably become a draft of a section in the design rationale document. I plan to send something like this (hopefully after it is improved by the other people on this list) to the CommonLoops list to explain the changes I am making in built-in classes in the next release of PCL. Take table 4-1 from CLtL (page 43). From that table, the following types do NOT have corresponding classes: ATOM This is a negation type. STANDARD-CHAR STRING-CHAR BIT FIXNUM BIGNUM We decided not to do subranges. COMMON STREAM FUNCTION Specification in CLtL too vague. It would be nice if X3J13 fixed stream and function though. KEYWORD Class can change by setf of symbol-package. SIMPLE-ARRAY SIMPLE-BIT-VECTOR SIMPLE-STRING SIMPLE-VECTOR ?? What is the reason for this ?? PACKAGE READTABLE RANDOM-STATE HASH-TABLE PATHNAME CLtL only requires that these types be disjoint with each other. We would like X3J13 to fix these too. SHORT-FLOAT LONG-FLOAT SINGLE-FLOAT DOUBLE-FLOAT I don't believe we excluded these but I believe either Pavel or Patrick said they would write up the rules about how these work. -------  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 22 Apr 87 16:57:20 EDT Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 22 Apr 87 13:48:21 PDT Received: from Semillon.ms by ArpaGateway.ms ; 22 APR 87 13:44:58 PDT Date: Wed, 22 Apr 87 13:42 PDT From: Gregor.pa@Xerox.COM Subject: Re: Object creation discussion (at last!) To: Moon@STONY-BROOK.SCRC.Symbolics.COM cc: Common-Lisp-Object-System@Sail.Stanford.edu Message-ID: <870422134241.3.GREGOR@AVALON.isl.parc.xerox.com> Line-fold: no I have a lot of comments and questions about this proposal. I originally tried to work them in with the running text, but that proved too cumbersome given the general nature of my comments. What's more, this message itself isn't all that polished. I thought it would be better to send it out now so that you would have an idea of what I was thinking. My overall comment is that this proposal is a lot more complicated than either of my previous proposals, in fact it doesn't seem to stress simplicity at all. Parts of this proposal provide important, useful and understandable functionality, which I would like to see in CLOS. Other parts add considerable conceptual complexity and don't seem to add significant functional gain. The best example of this is the special method combination type for initialize-instance. After I send out this message I will begin working on another message which lays out the framework of a proposal which incorporates all the things I really like about your proposal. I think that will be the best way to make it clear what I have in mind. My major objections are with: *** special method combination for the initialize-instance The special method combination type for initialize instance adds considerable conceptual overhead for very little functional gain. I admit that the basic method combination rule is simple enough to understand. But there are other aspects of this method combination types which will cause people to ask themeselves questions they will have a hard time answering with any kind of simple model of this thing. - if I don't have to say &allow-other-keys here, why do I have to say it in the normal kind of method combination? - why is it that I can't count on the methods getting all the initargs if I use &rest in the lambda-list? Note that this also robs useful functionality which exists everywhere else in Common Lisp. Specifically, it makes the &rest args &allow-other-keys idiom not work. This idiom is very useful for methods which want to process all the initargs in the init-plist in ways that makes those initargs interact. - If I redefine a initialize-instance method, will that effect the interpretation of all the :constructor lambda-lists involved? Will all those :constructors get fixed? *** the complex rules for interpreting the lambda-list of :constructors These rules are just plain complicated. In order to figure out what to do, you need to know: The names of all the slots, inherited and local (simple enough). All the mappings to initargs of those slot names. Inheriting this information is simple enough, but name mapping is confusing in general. All the :default-initargs inherited and local. Once again, understanding the inheritance here is simple enough. But putting all this together is pretty complicated. Because it isn't really three simple inheritance structures that are then combined. I don't think? I think your rules may cover the following case, but I don't believe its that simple to reason about. (defclass foo () () (:default-initargs :bazola ())) (defclass bar (foo) ((b :initarg :bazola))) (defclass baz () () (:constructor make-baz (&key bazola))) (defmethod initialize-instance ((a-baz baz) &key bazola) (setf (slot-value a-baz 'b) (list bazola (slot-value a-baz 'b)))) *** the overemphasis on getting speed out of the :constructors. This proposal seems to be mostly focused on getting speed out of using the :constructors. While I agree that instance creation speed is important, I am not sure that I like putting so much emphasis on doing it using :constructors. For one thing, from the user's point of view, I don't believe it is easy to understand why constructors should be so much faster. I don't believe that the reasons why the :constructors are so much faster are obvious. For another thing, the ability to be able to compile the :constructors into something fast leaks all over. The rule that says that particular initialize-instance methods can't count on getting the entire set of initargs is an excellent example of this "leakage". Other specific questions: - what arguments does allocate-instance get? at one point you say: From Moon: 2. Initargs that control storage allocation are defined by defining an allocate-instance method that accepts the initarg as an &key argument. For example, in systems with areas :area is an initarg for step 2. The standard does not require any initargs to exist for step 2. but how does this work? why don't all the allocate instance methods also have to say &allow-other-keys. Things that I like and agree with: Since I have been focusing on things I don't like, it may not be clear what I do like. Let me try to make explicit some of the major points I like and agree with. I like the functionality provided by the :default-initargs option. The next proposal I will submit has this feature in a slighltly more CommonLispy syntax. I agree that the initargs to make instance are "more abstract" than slots. I agree that constructors should call initialization methods. I agree that it is important for instance creation to be fast. I agree that :constructors are the best known way of doing this. I agree that there should be no defclass option which specifies an initarg for all the slots. I probably agree with other, more subtle things that I don't remember right now. -------  Received: from Xerox.COM (TCP 1200400040) by AI.AI.MIT.EDU 22 Apr 87 14:15:44 EDT Received: from Cabernet.ms by ArpaGateway.ms ; 22 APR 87 10:11:45 PDT Date: 22 Apr 87 10:07 PDT From: Gregor.pa@Xerox.COM Subject: PCL in Release 6 To: CommonLoops.pa@Xerox.COM cc: Gregor.pa@Xerox.COM Reply-to: Gregor.pa@Xerox.COM Message-ID: <870422-101145-3621@Xerox> If you don't use PCL on a Symbolics machine stop reading now. If you are already using release 7 (genera) stop reading now. I was hoping no-one would still be reading this, but I get the impression its not so. As you now, I stopped mainatining PCL in release 6 a little while ago, because it was just simpler for me to only maintain it in release 7. But now it seems that at least a couple of people still using release 6 would like to use the newest version of PCL. What I want to find out is how many people using rel6 want to use the newest version of PCL, and how long those people expect to be using rel6. So, if you want to use PCL in rel6, send me a message saying so. Please add when you plan to convert to rel7. Thanks Gregor  Received: from Xerox.COM (TCP 1200400040) by AI.AI.MIT.EDU 21 Apr 87 21:59:17 EDT Received: from Semillon.ms by ArpaGateway.ms ; 21 APR 87 17:05:21 PDT Date: Tue, 21 Apr 87 16:57 PDT From: Gregor.pa@Xerox.COM Subject: new version of PCL To: CommonLoops.PA@Xerox.COM Message-ID: <870421165740.1.GREGOR@AVALON.isl.parc.xerox.com> Line-fold: no There is a new version of pcl on parcvax.xerox.com *pcl-system-date* of this release is: "4/21/87 April 21rst 1987" This release runs in: ExCL Lucid Symbolics Common Lisp (Genera) Vaxlisp (2.0) Xerox Common Lisp (Lyric Release) Kyoto Common Lisp (5.2) CMU Lisp (nee Spice) should be working soon, I will announce another release at that time. Xerox Lisp users should FTP all the source files from /pub/pcl/ as well as all the dfasl files from /pub/pcl/xerox/. Included in the xerox specific directory is a file called PCL-ENV, which provides some simple environment support for using PCL in Xerox Lisp. The major difference in this release is that defclass conforms to the CLOS specification (pretty much I hope). Previous warnings about what would happen when defclass became CLOS defclass now apply. Once major difference is that PCL currently does require that all a classes superclasses be defined when a defclass form is evaluated. This will change sometime soon. As usual, I recommend that users for whom FTP'ing a copy of the sources is very time consuming wait a few days until some of the bugs in this release get shaken out by the people who can FTP new versions more easily. -------  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 21 Apr 87 14:09:54 EDT Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 21 Apr 87 10:49:03 PDT Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 120677; Tue 21-Apr-87 13:40:33 EDT Date: Tue, 21 Apr 87 13:40 EDT From: David A. Moon Subject: Re: Object creation discussion (at last!) To: Common-Lisp-Object-System@SAIL.STANFORD.EDU In-Reply-To: <2754940257-775701@Jenner> Message-ID: <870421134012.6.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Mon, 20 Apr 87 16:10:57 CDT From: Patrick H Dussud I did a census of :before and :after :init methods on our system: There are 864 flavors, 192 :before :init methods, 336 :after :init methods. The :after :init methods seem to be more common than :before :init. Did you come up with a different count? When I make these counts I try to exclude the window system, because I don't consider its design representative of how things would be programmed today. Unless you've redesigned the MIT window system a lot more than we have, that's probably true of your system as well. Here are the make-instance methods I found (in my CLOS object creation proposal these would be initialize-instance methods, and I have translated the method qualifiers to the terminology of that proposal): 224 methods total 138 unqualified methods 81 :after methods 5 :around methods I expected the fraction of :after methods to be lower than 36%. I suppose it would be good to study them and see why so many are being used, but that would take more time than I wish to spend today. Maybe later. For completeness, here are the :init counts, but they are mostly window flavors: 293 methods total 92 :before methods 23 unqualified methods 170 :after methods 8 :around methods There is the same preponderance of :after methods, but because :init uses :daemon method combination (thus almost anything that uses an unqualified method is, in fact, broken) and because of the influence of the window system, I don't think there is much to be learned from these numbers.  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 21 Apr 87 11:18:06 EDT Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 21 Apr 87 08:12:20 PDT Received: from relay2.cs.net by RELAY.CS.NET id ab05835; 21 Apr 87 11:06 EDT Received: from ti-csl by RELAY.CS.NET id ab23071; 21 Apr 87 11:00 AST Received: from Jenner (jenner.ARPA) by tilde id AA02583; Tue, 21 Apr 87 07:44:11 cdt Message-Id: <2754996278-4141536@Jenner> Date: Tue, 21 Apr 87 07:44:38 CDT From: Patrick H Dussud To: "David A. Moon" Cc: Common-Lisp-Object-System@SAIL.STANFORD.EDU Subject: Re: Object creation discussion (at last!) In-Reply-To: Msg of Mon, 20 Apr 87 16:55 EDT from "David A. Moon" Date: Mon, 20 Apr 87 16:55 EDT From: "David A. Moon" Subject: Re: Object creation discussion (at last!) Date: Mon, 20 Apr 87 14:49:05 CDT From: Patrick H Dussud Date: Fri, 17 Apr 87 14:49 EDT From: "David A. Moon" I can't understand what you're getting at here. In Common Lisp :allow-other-keys T does not apply to non-keywords like JUNK. I can't find any evidence for this except at the top of p.62 in CLtL where it says "It is an error for the first object of each pair to be anything but a keyword." I was under the impression that it had been decided a couple of years ago that the last word in this sentence should have been "symbol", but perhaps that's not true. Unfortunately I lost my copy, but I think this was in the proposed corrections and clarifications Guy Steele distributed in December 1985. I didn't find any reference to this in the clarifications/corrections. I tell you what I'll do; I'll go find out the format for submissions to the cleanup subcommittee and send this in. Let's proceed on the assumption that it will be accepted. Sounds good.  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 21 Apr 87 11:15:20 EDT Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 20 Apr 87 14:48:49 PDT Received: from relay2.cs.net by RELAY.CS.NET id ad20964; 20 Apr 87 17:45 EDT Received: from ti-csl by RELAY.CS.NET id ap18098; 20 Apr 87 17:37 AST Received: from Jenner (jenner.ARPA) by tilde id AA19015; Mon, 20 Apr 87 16:10:24 cdt Message-Id: <2754940257-775701@Jenner> Date: Mon, 20 Apr 87 16:10:57 CDT From: Patrick H Dussud To: "David A. Moon" Cc: Common-Lisp-Object-System@SAIL.STANFORD.EDU Subject: Re: Object creation discussion (at last!) David, Another small point: I did a census of :before and :after :init methods on our system: There are 864 flavors, 192 :before :init methods, 336 :after :init methods. The :after :init methods seem to be more common than :before :init. Did you come up with a different count? Patrick.  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 20 Apr 87 16:59:45 EDT Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 20 Apr 87 13:55:34 PDT Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 120069; Mon 20-Apr-87 16:55:30 EDT Date: Mon, 20 Apr 87 16:55 EDT From: David A. Moon Subject: Re: Object creation discussion (at last!) To: Patrick H Dussud cc: Common-Lisp-Object-System@SAIL.STANFORD.EDU In-Reply-To: <2754935345-480598@Jenner> Message-ID: <870420165517.4.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Mon, 20 Apr 87 14:49:05 CDT From: Patrick H Dussud Date: Fri, 17 Apr 87 14:49 EDT From: "David A. Moon" I can't understand what you're getting at here. In Common Lisp :allow-other-keys T does not apply to non-keywords like JUNK. I can't find any evidence for this except at the top of p.62 in CLtL where it says "It is an error for the first object of each pair to be anything but a keyword." I was under the impression that it had been decided a couple of years ago that the last word in this sentence should have been "symbol", but perhaps that's not true. Unfortunately I lost my copy, but I think this was in the proposed corrections and clarifications Guy Steele distributed in December 1985. If only symbols in the keyword package are allowed as keyword argument names, my object creation proposal falls apart, as does every other one that has ever been mailed to this list! I tell you what I'll do; I'll go find out the format for submissions to the cleanup subcommittee and send this in. Let's proceed on the assumption that it will be accepted.  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 20 Apr 87 16:36:15 EDT Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 20 Apr 87 13:31:08 PDT Received: from relay2.cs.net by RELAY.CS.NET id ae19504; 20 Apr 87 16:13 EDT Received: from ti-csl by RELAY.CS.NET id ax17675; 20 Apr 87 16:05 AST Received: from Jenner (jenner.ARPA) by tilde id AA16384; Mon, 20 Apr 87 14:48:44 cdt Message-Id: <2754935345-480598@Jenner> Date: Mon, 20 Apr 87 14:49:05 CDT From: Patrick H Dussud To: "David A. Moon" Cc: Common-Lisp-Object-System@SAIL.STANFORD.EDU Subject: Re: Object creation discussion (at last!) In-Reply-To: Msg of Fri, 17 Apr 87 14:49 EDT from "David A. Moon" Date: Fri, 17 Apr 87 14:49 EDT From: "David A. Moon" Subject: Re: Object creation discussion (at last!) >> What if multiple initargs that fill the same slot are supplied? If the same initarg is given more than once in the arguments to make-instance, the leftmost occurrence prevails, as required by Common Lisp. If two different initargs that fill the same slot are given in the arguments to make-instance, the leftmost occurrence prevails (alternatively we could make this an error, but I think it's simpler to treat it the same as two occurrences of the same initarg). A :constructor option whose lambda-list has more than one parameter that fills a single slot signals an error, whether or not the parameter names are eq (see proposal below for how it is possible for non-eq parameters to fill the same slot). I also added the following related clarification: When :default-initargs defaults an initarg that fills a slot, it is treated the same as an :initform slot-option for purposes of inheritance (note well: the class that specifies the :default-initargs may not know whether the initarg fills a slot or not, and indeed this may depend on which subclass of that class we are dealing with). If a single class specifies more than one default value for a single slot, via :default-initargs or :initform or both, an error is signalled. Is this agreeable? Yes. Initargs don't have to be keywords, but the entire object creation might not work very well if any of initargs is not a keyword: In common Lisp, :allow-other-keys T works only for keyword value pairs. We would have to slightly change its meaning for make-instance. In practice this is probably implemented by calling all of the initialize-instance methods with all of the initargs and automatically adding &allow-other-keys to the lambda-list in defmethod. This won't work if there is an initarg which is not a key. The methods that can be called during object creation (like those on allocate-instance) would be easier to code if they knew that they would get keyword-value pairs. (if I understand correctly, those methods would get all the arguments supplied to make-instance, right?) I can't understand what you're getting at here. Could you send a follow-up message this is more explicit? Take the following example: (make-instance 'class-1 'SLOT1 2 :AREA 'class-1-area 'JUNK 3 :allow-other-keys t) SLOT-1 is an initarg for a slot, :AREA is a key for an allocate-instance method, but JUNK is not a valid initarg. According to your proposal, :allow-other-keys would tell make-instance to ignore JUNK (ie. return without signalling an error). In Common Lisp :allow-other-keys T does not apply to non-keywords like JUNK. Suppose I have a method like: (defmethod allocate-instance ((class 'class-1) &key :area &allow-other-keys) .....) If we call allocate-instance with all the initarg-value pairs coming from the make-instance call and if all the initargs are keywords, then according to Common Lisp, only the :area keyword is not ignored and we get the intended effect. Now, if one of the initargs is not a keyword, then Common Lisp says it is an error... My point is, the implementations will have to filter out non keyword initargs that are not relevant to allocate-instance before calling allocate-instance if they want strict compliance with CLtL. Is this true or did I miss something? >> Can step 2 return an existing object instead of allocating storage, aborting the remaining steps? Step 2 can return anything it wants, but the remaining steps are still executed. To do "interning" you must build a higher-level interface around make-instance; make-instance always makes. No way is provided for the metaclass to be able to completely bypass the entire action of MAKE-INSTANCE. Is this agreeable? Yes.  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 17 Apr 87 15:51:34 EDT Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 17 Apr 87 12:44:29 PDT Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 118986; Fri 17-Apr-87 15:29:48 EDT Date: Fri, 17 Apr 87 15:29 EDT From: David A. Moon Subject: (long) CLOS Declaration Proposal Text To: Jim Kempf cc: common-lisp-object-system@sail.stanford.edu In-Reply-To: <8704162339.AA22952@hplabsc> Message-ID: <870417152924.3.MOON@EUPHRATES.SCRC.Symbolics.COM> This is a good beginning. Not being a fan of machines that require declarations, I'm going to keep a low profile in this discussion, but I do have a couple of comments/criticisms for you. 5) If method combination is prohibited for a certain method, any overhead which is needed to support method combination in the general case could be avoided. I agree that this is a non-issue. (CLASS FOO X) I think (EXACT-CLASS FOO X) has a lot less potential for confusion. a user may want to restrict a particular name to be a generic function I don't see why. I suggest leaving this out unless there is a good reason for it (which should be articulated). When a user creates a subclass of a "staticized" class, rather than changing the semantics in some unclear way, I suggest signalling an error if there is a conflict between the semantics frozen into the superclass and the semantics that would exist if the superclass had not been "staticized". The design principle here is that adding a "staticize" declaration to a working program shouldn't change what it does, only how fast it does it. The name MAKE-STATIC isn't the best. To me, it connotes a function that returns an object that I can hand to the WRITE-SOUND function and get an ugly noise from the speaker in my console. FREEZE-CLASS would be better.  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 17 Apr 87 14:57:40 EDT Received: from [192.10.41.109] by SAIL.STANFORD.EDU with TCP; 17 Apr 87 11:49:33 PDT Received: from EUPHRATES.SCRC.Symbolics.COM by ALDERAAN.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 73015; Fri 17-Apr-87 14:49:44 EDT Date: Fri, 17 Apr 87 14:49 EDT From: David A. Moon Subject: Re: Object creation discussion (at last!) To: Common-Lisp-Object-System@SAIL.STANFORD.EDU In-Reply-To: <2754594256-919057@Jenner> Message-ID: <870417144911.9.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Thu, 16 Apr 87 16:04:16 CDT From: Patrick H Dussud Thanks for the comments. I hope the others will comment as well (but I'm certainly willing to wait a few days). If multiple initargs that fill the same slot are supplied, which value ends up in the slot is indeterminate. In what sense do you mean "indeterminate"? Do you mean "defined to be one of those values, but not defined as to which of them", such that it would be legal to use a random number generator to decide? Yes. "which value" should be "which of those values". I certainly won't complain if someone proposes a determinate action here instead. We could check, at run time for make-instance that two initargs that fill the same slot are not getting a value. For the constructors, we can check at compile time that they don't specify in their lambda list two initargs filling the same slot. This would be a restriction for constructors. Those are good ideas. I agree with the constructor one. I'm not so sure about the make-instance one, because I just noticed that Common Lisp allows duplicate keyword arguments in a function call and mandates that the leftmost argument prevails. One could argue that this should extend to arguments that have different names but fill the same slot. I was concerned about the speed of a runtime check either to do what you (Patrick) suggested, or to do what I just mentioned above. However, after consulting our implementation I see that it is easy to do, although we are not currently using the mechanism to address the issue of multiple initargs filling the same slot. Briefly, you detect at compile time (or the first time a class is instantiated) that there are multiple possible initargs, and then you assign a bit in a bit mask to record whether the given slot has been filled. If you see an initarg that fills a slot whose bit is already set, you either ignore it (leftmost duplicate prevails) or check what keyword was used the previous time (signal an error except in the case where Common Lisp says the leftmost duplicate prevails). Given all this, I added the following to my proposal (philosophy section): >> What if multiple initargs that fill the same slot are supplied? If the same initarg is given more than once in the arguments to make-instance, the leftmost occurrence prevails, as required by Common Lisp. If two different initargs that fill the same slot are given in the arguments to make-instance, the leftmost occurrence prevails (alternatively we could make this an error, but I think it's simpler to treat it the same as two occurrences of the same initarg). A :constructor option whose lambda-list has more than one parameter that fills a single slot signals an error, whether or not the parameter names are eq (see proposal below for how it is possible for non-eq parameters to fill the same slot). I also added the following related clarification: When :default-initargs defaults an initarg that fills a slot, it is treated the same as an :initform slot-option for purposes of inheritance (note well: the class that specifies the :default-initargs may not know whether the initarg fills a slot or not, and indeed this may depend on which subclass of that class we are dealing with). If a single class specifies more than one default value for a single slot, via :default-initargs or :initform or both, an error is signalled. Is this agreeable? Initargs don't have to be keywords, but the entire object creation might not work very well if any of initargs is not a keyword: In common Lisp, :allow-other-keys T works only for keyword value pairs. We would have to slightly change its meaning for make-instance. In practice this is probably implemented by calling all of the initialize-instance methods with all of the initargs and automatically adding &allow-other-keys to the lambda-list in defmethod. This won't work if there is an initarg which is not a key. The methods that can be called during object creation (like those on allocate-instance) would be easier to code if they knew that they would get keyword-value pairs. (if I understand correctly, those methods would get all the arguments supplied to make-instance, right?) I can't understand what you're getting at here. Could you send a follow-up message this is more explicit? >> Can step 2 return an existing object instead of allocating storage, aborting the remaining steps? No, to do "interning" you must build a higher-level interface around make-instance. Make-instance always makes. I am wondering if you propose to enforce this. What if somebody defines an :around method for ALLOCATE-INSTANCE and does not call-next-method but returns an interned object instead ? Is it an error? I don't see how it would be possible to enforce a restriction that the value returned by ALLOCATE-INSTANCE is not EQ to any other object in the world. However, note that in your example the value returned by ALLOCATE-INSTANCE is going to have every one of its slots stored into, and is going to have its INITIALIZE-INSTANCE methods run, so the effect might not be what the user intended. What I was really getting at with my philosophy question is "should a way be provided for the metaclass to be able to completely bypass the entire action of MAKE-INSTANCE?" and my answer to that is "no". In my file copy of the proposal I changed this section to the following: >> Can step 2 return an existing object instead of allocating storage, aborting the remaining steps? Step 2 can return anything it wants, but the remaining steps are still executed. To do "interning" you must build a higher-level interface around make-instance; make-instance always makes. No way is provided for the metaclass to be able to completely bypass the entire action of MAKE-INSTANCE. Is this agreeable?  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 17 Apr 87 13:19:33 EDT Received: from [192.10.41.109] by SAIL.STANFORD.EDU with TCP; 17 Apr 87 10:00:37 PDT Received: from FLYING-DOVE.SCRC.Symbolics.COM by ALDERAAN.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 72959; Fri 17-Apr-87 13:00:56 EDT Date: Fri, 17 Apr 87 13:01 EDT From: Jonathan L. Balgley Subject: "Object" System To: common-lisp-object-system@sail.stanford.edu Message-ID: <870417130124.4.JLB@FLYING-DOVE.SCRC.Symbolics.COM> Hi! I've read the draft version of CLOS standard and gave my comments through Symbolics' other representatives. But I have one question: Why is it called the "Common Lisp Object System"? I understand the desire to be related to the term "object-oriented", but pure Common Lisp could already be called an "object system". Indeed, CLtL dedicates an entire chapter (number 2, "Data Types") to discussing the "variety of types of data objects". I believe that the name will cause unnecessary confusion when trying to describe the facilities that CLOS provides over pure Common Lisp. I can hear CL beginners now: "OK, you've convinced me that conses and symbols are objects. How does that relate to the Common Lisp Object System?" So, have other names been proposed and turned down? Is this name finalized or will you take other suggestions? If you will, here's my idea for a name: "CL Generic Structure System". Another one, that Sonya Keene proposed, was "Classes". At the very least, I hope that the "Design Rationale" chapter will briefly mention why it's named what it is. Thanks for listening.  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 16 Apr 87 22:49:09 EDT Received: from HPLABS.HP.COM by SAIL.STANFORD.EDU with TCP; 16 Apr 87 19:38:47 PDT Received: from hplabsc by hplabs.HP.COM with TCP ; Thu, 16 Apr 87 16:01:43 pst Received: by hplabsc ; Thu, 16 Apr 87 15:39:45 pst Date: Thu, 16 Apr 87 15:39:45 pst From: Jim Kempf Message-Id: <8704162339.AA22952@hplabsc> To: common-lisp-object-system@sail.stanford.edu Subject: (long) CLOS Declaration Proposal Text CLOS Declaration Proposal James Kempf HP Labs 4/16/87 I. INTRODUCTION The purpose of this proposal is to explore issues regarding integration of the Common Lisp Object System (CLOS) into the declaration mechanism in Chapter 9 of Steele. Some specific "trial balloon" proposals will also be made for suggested additions, but, as usual, they are open for comment and revision as agreement on the fundamentals emerges. There are several reasons why adding declaration mechanisms for the CLOS to Common Lisp may be desirable: 1) It could tighten the integration between CLOS and the underlying language. 2) It could give application developers on conventional architectures a means of achieving extra performance after their applications have been developed. 3) It could give vendors a means of freezing the semantics of operations on objects with user defined classes, so users could inherit from vendor delivered libraries of classes without having the order of methods invoked during a CALL-NEXT-METHOD change depending on the user's class structure. Additionally, if the suite of method combinations could be frozen, a vendor could deliver a class library as a "black box", in which the user's options for modification of the semantics are limited. Points 2 and 3 deal with aids for helping applications developers move from a prototyping phase to a product or delivery phase, with a minimum amount of recoding, beyond the addition of (possibly local) declarations. Point 3 also would simplify regression testing for class libraries, since developers could more easily identify areas where user code may cause problems and take steps to avoid them appropriately. (Footnote: An example of this is the :PRINT-FUNCTION option to DEFSTRUCT). ANSI 87-002 (the CLOS specification) has a number of areas where declarations play a role (most specifically, for DEFGENERIC-OPTIONS). This proposal should be seen as an effort to compliment these areas, and to tie them together with the rest of Common Lisp. Note that this proposal will *not* discuss the issue of compilation semantics for the CLOS (though, perhaps, it should, since extra semantics are being proposed). This is also an area in need of clarification, but complex enough to require a seperate note. II. OPTIMIZATION POTENTIAL There are a number of areas where potential optimizations could be applied to CLOS code: 1) Where the exact class of a variable is known at compile time, method dispatch at run time can be avoided (or the amount of time involved significantly reduced). 2) If the inheritance structure of a class is frozen, slot access could be compiled in-line into a simple memory reference. 3) Lack of class redefinition could also allow double indirection for slot reference to be avoided, potentially saving memory (though this becomes less important as memory gets cheaper) and cycles. 4) If the class of a lexical variable is known, and the compiler can infer that the object reference will not be passed outside of the lexical scope, then the compiler may allocate the instance on the stack. This could encourage developers to use instances in loops and in other areas where excessive garbage creation may otherwise be a concern. 5) If method combination is prohibited for a certain method, any overhead which is needed to support method combination in the general case could be avoided. Note that some CLOS implementors may choose to include these optimizations as part of general compiler optimizations done when an OPTIMIZE declaration is in force. However, in certain cases, additional information is needed from the application developer in order for the optimizations to be made. In the rest of this note, suggestions for additions to Steele, Chapter 9 to support Points 1-4 will be discussed. Though Point 5 seems like an important area where developers may require additional language mechanisms, I do not feel knowledgable enough about the implementation of method combination to make a suggestion, and will leave this point open to comment from method combination bgwahns (= supergurus). It may even be a nonissue. III. SPECIFIC DECLARATIONS With reference to the list of potential optimizations above, here are some areas where specific declarations may be desirable. A. Declaration of Class Common Lisp currently has no mechanism for saying that this variable will always be bound to an object of *a* particular type, and no other. The TYPE declaration always allows subtyping. If a user defined class has a type of the same name (Footnote: I couldn't find a statement to this effect in ANSI 87-002, so I'm guessing) and subtyping and subclassing are synonomous (i.e., if X is a subclass of Y, then it is also a subtype), then the TYPE declaration can be used to restrict a variable's class to a particular part of the class hierarchy, which could potentially be useful in optimization. However, additional mechanism may be needed to further restrict a variable's reference to objects of one (and only one) class. A suggestion for this purpose would be a CLASS declaration: (CLASS FOO X) would restrict X to objects of class FOO, and no other. This would allow very efficient compile time optimization of method lookup. Essentially, a reference to the function implementing the method could be inserted at the call site. Note that a declaration of this sort would severely restrict flexibility (resembling *shudder* Pascal static typing) but could be useful in postdevelopment, when the developer has discovered that certain variables only get bound to objects of a particular class. In time critical sections of code, developers might arrange to restrict the class of objects. Declarations of certain variables to one of the built-in Common Lisp type classes may allow substitution of a Common Lisp function directly. Finally, even if the class of the primary argument varies, the classes of other arguments in a multimethod dispatch could be dynamically nonvarying for particular invocations. B. Declaration of Function Class or Type Currently, Common Lisp has two ways of declaring the argument and return type of a function (FTYPE and FUNCTION pg. 158-159 of CLtL). The existing mechanism may be adequate for specifying the same information about generic functions as well, with the exception of the lack of ability to restrict an argument type to a particular class (and no other), as noted above. The addition of CLASS to the declaration may achieve this: (DECLARE (FUNCTION FOO ((CLASS BAZ)) (CLASS BOO))) would specify that FOO takes objects of class BAZ (and *only* of class BAZ) and returns objects of class BOO (and *only* of class BOO). Alternatively, a user may want to restrict a particular name to be a generic function, and so a parallel GENERIC-FUNCTION and GENERIC-FTYPE declaration (rather than a function) may be desired. In the interest of parsimony (there are, after all, already *two* ways of achieving similar functionality) perhaps the declarations for function should apply to generic functions, and a specific GENERIC-FUNCTION declaration be introduced for declaring that a particular name is for a generic function: (DECLARE (GENERIC-FUNCTION FOO)) Note that the issue of lexical generic function definition (GFLET and GFLABELS) has not yet been resolved, but, should it be, then the same rules should apply for generic function declaration naming as for functions. C. INLINE/NOTINLINE The meaning of these declarations for generic functions should be carefully thought out. In particular, if an implementor chooses to implement INLINE, then does the generic function body itself get inserted inline? This would seem to be the case, unless further optimization of method lookup is possible. D. OPTIMIZE Compiler writers should be left a good deal of freedom to implement CLOS code optimizations as they see fit, though they should be encouraged to document what optimizations are done in the CLOS for particular levels. The information in the other declarations could be used to good effect here. E. METACLASS DECLARATIONS It seems as if declarations for metaclasses may also be needed, but specific proposals should probably wait until the metaobject protocol is accepted. IV. CLASS STATICIZATION The term "staticization" (introduced by Dick Gabrial) referrs to making a portion of a class hierarchy static. This could involve a number of potential effects: 1) Redefinition of the class is no longer allowed. 2) Slot layout is fixed. 3) WITH-SLOTS compiles out any dynamic lookup. 4) All included classes in the hierarchy need to be staticized as well. 5) User defined classes should be able to inherit from a staticized class. 6) The class precedence list is frozen. The overall idea is to move resolution of as much inheritance compuation as possiblefrom run time to compile time, without changing the inheritance semantics. Note that semantic changes *may*, in fact, become visible to subclasses of a staticized class if method inheritance is resolved at compile time (as noted in the introduction). The order in which CALL-NEXT-METHOD invokes a method and the class precedence list order could be frozen for inheriting classes, meaning that the semantics of method inheritance would not change as the user inherits classes for multiply inherited classes. If the class precedence list is NOT frozen, then the semantics will change, depending on the order in which the user lists the superclasses in the :INCLUDE form. The issues here are complex, and need more discussion. Perhaps several levels of staticization are desirable, as is the case with SPEED and SAFETY. At one level, the class precedence list would not be frozen, but redefinition would be excluded. At the next, slot layout would be frozen, and finally, the class precedence list would be frozen as well. In any event, the nature of the CLOS, with classes being first class objects, suggests that a (generic) functional interface rather than a declaration be used. As a starting point, I would suggest MAKE-STATIC with an ESSENTIAL-CLASS argument. Keyword and optional arguments to specify particular staticization level may be needed, if the additional complexity of such levels seems desirable. A MAKE-STATIC method for ESSENTIAL-METHOD may also be needed. Perhaps these should be included in the metaobject protocol. V. CONCLUSION As noted in the introduction, this note is meant to start up (perhaps lively) discussion on the issues of optimization and class staticization. Perhaps all of it should be junked! But, in any event, I hope the issues don't get ignored, since I feel confident that developers will want hooks into the declaration mechanism, and the ability to deliver class libraries that have been processed by postdevelopment mechanisms to make them as efficient and reliable as possible.  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 16 Apr 87 21:53:47 EDT Received: from HPLABS.HP.COM by SAIL.STANFORD.EDU with TCP; 16 Apr 87 18:45:07 PDT Received: from hplabsc by hplabs.HP.COM with TCP ; Thu, 16 Apr 87 15:53:01 pst Received: by hplabsc ; Thu, 16 Apr 87 15:39:07 pst Date: Thu, 16 Apr 87 15:39:07 pst From: Jim Kempf Message-Id: <8704162339.AA22947@hplabsc> To: common-lisp-object-system@sail.stanford.edu Subject: CLOS Declaration Proposal The next posting will be a (long) proposal discussing issues in integrating CLOS with the Common Lisp declaration mechanism and with staticization of classes. I believe this was an unfinished issue at the ANSI meeting, and this proposal is meant to get discussion going again. Jim Kempf kempf@hplabs.hp.com  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 16 Apr 87 19:38:43 EDT Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 16 Apr 87 16:28:47 PDT Received: from relay2.cs.net by RELAY.CS.NET id af06011; 16 Apr 87 19:21 EDT Received: from ti-csl by RELAY.CS.NET id ae17117; 16 Apr 87 19:17 AST Received: from Jenner (jenner.ARPA) by tilde id AA26564; Thu, 16 Apr 87 17:01:36 cdt Message-Id: <2754594256-919057@Jenner> Date: Thu, 16 Apr 87 16:04:16 CDT From: Patrick H Dussud To: "David A. Moon" Cc: Common-Lisp-Object-System@SAIL.STANFORD.EDU Subject: Re: Object creation discussion (at last!) In-Reply-To: Msg of Thu, 16 Apr 87 00:22 EDT from "David A. Moon" David, If multiple initargs that fill the same slot are supplied, which value ends up in the slot is indeterminate. In what sense do you mean "indeterminate"? Do you mean "defined to be one of those values, but not defined as to which of them", such that it would be legal to use a random number generator to decide? Yes. "which value" should be "which of those values". I certainly won't complain if someone proposes a determinate action here instead. We could check, at run time for make-instance that two initargs that fill the same slot are not getting a value. For the constructors, we can check at compile time that they don't specify in their lambda list two initargs filling the same slot. This would be a restriction for constructors. Initargs don't have to be keywords, but the entire object creation might not work very well if any of initargs is not a keyword: In common Lisp, :allow-other-keys T works only for keyword value pairs. We would have to slightly change its meaning for make-instance. In practice this is probably implemented by calling all of the initialize-instance methods with all of the initargs and automatically adding &allow-other-keys to the lambda-list in defmethod. This won't work if there is an initarg which is not a key. The methods that can be called during object creation (like those on allocate-instance) would be easier to code if they knew that they would get keyword-value pairs. (if I understand correctly, those methods would get all the arguments supplied to make-instance, right?) >> Can step 2 return an existing object instead of allocating storage, aborting the remaining steps? No, to do "interning" you must build a higher-level interface around make-instance. Make-instance always makes. I am wondering if you propose to enforce this. What if somebody defines an :around method for ALLOCATE-INSTANCE and does not call-next-method but returns an interned object instead ? Is it an error?  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 16 Apr 87 15:30:06 EDT Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 16 Apr 87 12:19:08 PDT Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 117802; Thu 16-Apr-87 15:19:26 EDT Date: Thu, 16 Apr 87 15:18 EDT From: David A. Moon Subject: Object creation discussion (at last!) To: Daniel L. Weinreb cc: Common-Lisp-Object-System@sail.stanford.edu In-Reply-To: <870416080247.6.DLW@CHICOPEE.SCRC.Symbolics.COM> Message-ID: <870416151813.2.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Thu, 16 Apr 87 08:02 EDT From: Daniel L. Weinreb Date: Thu, 16 Apr 87 00:22 EDT From: David A. Moon If multiple initargs that fill the same slot are supplied, which value ends up in the slot is indeterminate. In what sense do you mean "indeterminate"? Do you mean "defined to be one of those values, but not defined as to which of them", such that it would be legal to use a random number generator to decide? Yes. "which value" should be "which of those values". I certainly won't complain if someone proposes a determinate action here instead. The :default-initargs defclass option is followed by alternating initarg names and forms. This syntax is a little bit strange, because usually, in Common Lisp, a "variable" and the form that specifies the initial value of the "variable" are kept close together, textually. LET and DEFSTRUCT are both examples. The now-documented :initform works that way too. What is the motivation for moving these forms into a defclass option? This is typically used to specify a default for an initarg defined by a superclass. Note that the places that define initargs (the :initarg slot option and the &key lambda-lists of initialize-instance and allocate-instance) already have a local defaulting mechanism. :default-initargs is provided specifically for non-local defaulting. The class-initargs function takes a class and returns a list of initarg-name symbols. These are all of the initargs accepted by make-instance of that class. How does it know all the initargs that are accepted, without "understanding" the code of every initialize-instance method? It understands the lambda-list (not the code) of every initialize-instance and allocate-instance method. I should have made this clearer. I updated my file copy of my thoughts to reflect these clarifications.  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 16 Apr 87 12:57:29 EDT Date: 16 Apr 87 0948 PDT From: Dick Gabriel Subject: defclass options To: common-lisp-object-system@SAIL.STANFORD.EDU Moon: ``I vote for allowing :foo as an abbreviation for (:foo).'' rpg: ``I vote against it.''  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 16 Apr 87 12:28:27 EDT Received: from [192.10.41.109] by SAIL.STANFORD.EDU with TCP; 16 Apr 87 09:20:47 PDT Received: from CHICOPEE.SCRC.Symbolics.COM by ALDERAAN.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 72470; Thu 16-Apr-87 08:06:26 EDT Date: Thu, 16 Apr 87 08:02 EDT From: Daniel L. Weinreb Subject: Object creation discussion (at last!) To: Moon@STONY-BROOK.SCRC.Symbolics.COM, Common-Lisp-Object-System@sail.stanford.edu In-Reply-To: <870416002258.1.MOON@EUPHRATES.SCRC.Symbolics.COM> Message-ID: <870416080247.6.DLW@CHICOPEE.SCRC.Symbolics.COM> Date: Thu, 16 Apr 87 00:22 EDT From: David A. Moon If multiple initargs that fill the same slot are supplied, which value ends up in the slot is indeterminate. In what sense do you mean "indeterminate"? Do you mean "defined to be one of those values, but not defined as to which of them", such that it would be legal to use a random number generator to decide? The :default-initargs defclass option is followed by alternating initarg names and forms. This syntax is a little bit strange, because usually, in Common Lisp, a "variable" and the form that specifies the initial value of the "variable" are kept close together, textually. LET and DEFSTRUCT are both examples. The now-documented :initform works that way too. What is the motivation for moving these forms into a defclass option? The class-initargs function takes a class and returns a list of initarg-name symbols. These are all of the initargs accepted by make-instance of that class. How does it know all the initargs that are accepted, without "understanding" the code of every initialize-instance method?  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 16 Apr 87 00:31:07 EDT Received: from [192.10.41.109] by SAIL.STANFORD.EDU with TCP; 15 Apr 87 21:23:08 PDT Received: from EUPHRATES.SCRC.Symbolics.COM by ALDERAAN.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 72460; Thu 16-Apr-87 00:23:25 EDT Date: Thu, 16 Apr 87 00:22 EDT From: David A. Moon Subject: Object creation discussion (at last!) To: Common-Lisp-Object-System@sail.stanford.edu Message-ID: <870416002258.1.MOON@EUPHRATES.SCRC.Symbolics.COM> I have returned from consulting my Muse in Montreal and I now have some thoughts to offer on object creation. I have some other things too, but I think it would be better to settle object creation before embarking on anything else. I will present this in four parts: facts, philosophy, proposal, and remarks. The facts are just a framework for discussion. Philosophy is in the form of some questions and my proposed answers; to proceed we need to agree on some consistent set of answers to these questions. >>> FACTS Creating an object involves four steps: (1) Client calls an object-creation function, passing it some arguments. The function is either make-instance or a function created by the :constructor option to defclass. (2) Allocate storage for the object. (3) Fill in the slots. (4) Call the initialization methods. Terminology: "initargs" (initialization arguments) are a set of named arguments that control object creation and initialization. Each initarg has a name, which is a symbol (not necessarily a keyword), and a value. The arguments to make-instance, excepting the first, taken in pairs, are initargs. >>> PHILOSOPHY >> Which of the four steps above should be customizable, and how are they to be customized? 1. Client can call any function he likes, no other customization necessary. 2. Customizable by client in an implementation-dependent way; for example, in systems with areas, client can specify in which area to allocate storage. Also customizable by the metaclass, because the metaclass controls the stored representation of instances. 3. Customizable by slot-description, which specifies a default value for the slot and whether the slot can be filled with a value specified by the client; if so, the slot-description specifies the name of the initarg whose value is stored into the slot. Also customizable by the arglist of the :constructor option to defclass, which specifies names of slots into which arguments are stored. 4. Customizable by defining methods. Only step 2 needs to be customizable by the metaclass. >> Is make-instance an intra-module or inter-module interface? Both. >> Do the arguments to make-instance correspond directly to actual stored slots, or are they a more abstract concept, whose implementation in terms of slots or in terms of something else is hidden from the caller? More abstract, because make-instance is often used as an inter-module interface. >> What is the lambda-list of a constructor created by a :constructor option with no lambda-list specified? It accepts the same arguments as make-instance, excepting the first. >> Do constructors call initialization methods? Yes. >> Who is responsible for error checking of make-instance arguments? Part of step 1 is the normal argument checking that happens on any function call. For constructors, this is completely normal. For make-instance, the behavior is the same as if there was always a constructor created by a :constructor option with no lambda-list specified and make-instance simply called it. This implies that if the client calls make-instance with a misspelled initarg name, "it is an error" (CLtL pp.62-3) unless :allow-other-keys t was specified. >> Can step 2 return an existing object instead of allocating storage, aborting the remaining steps? No, to do "interning" you must build a higher-level interface around make-instance. Make-instance always makes. >> Why do we have a :constructor option to defclass? For speed; make-instance is interpretive, while constructors are compiled, since they know the exact class that they are constructing, and since they can be automatically recompiled if the class or any of its superclasses changes. >> Is speed of object creation important? Yes, that's why we have :constructor. Otherwise the user could just write a defun whose body is a call to make-instance. >> What assistance does the object system give to the class definer? Error-checking in step 1; default storage allocation method in step 2; convenient defclass slot-option syntax to control step 3; convenient defmethod syntax to control step 4. >> How should classes' initializations interact when they are mixed? The set of valid initargs for a class is the union of the initargs defined by the class and its superclasses. Storage allocation is controlled by the metaclass. A slot is filled by a given initarg if the class or any of its superclasses so specifies, thus more than one initarg can fill the same slot. If multiple initargs that fill the same slot are supplied, which value ends up in the slot is indeterminate. Default values for slots inherit as discussed in 87-002. >> How should initialization methods combine? Initialization methods combine in a way that is convenient for the common case where the methods are independent, and for the less common but still typical case where some initializations need to be performed after the object has been otherwise fully initialized. There is no need for method shadowing since each method initializes things relevant to its own class. A specialized type of method-combination is used in which unqualified methods behave like the :before methods of standard method-combination. This means the common case is handled without resorting to either qualified methods or call-next-method. :after methods, as in standard method-combination, are allowed, to handle that less common case. :around methods could be allowed, although examination of the corresponding thing in Flavors shows that it doesn't seem to be used for anything reasonable. >> How many generic functions are involved in object creation, and what are their names? MAKE-INSTANCE is not generic; customizing it would do no good, since a client can call a constructor instead of calling make-instance, and constructors are not generic. ALLOCATE-INSTANCE class initargs... is the generic function for which the user can define methods to customize step 2. Standard method combination is used. INITIALIZE-INSTANCE instance initargs... is the generic function for which the user can define methods to customize step 4. The specialized type of method combination described above is used. Both of these generic functions should not be called by the user. They are called by make-instance and by constructors. After calling allocate-instance and before calling initialize-instance, make-instance or the constructor fills in the slots. >>> PROPOSAL (Information that would duplicate the answers to the philosophy questions omitted for the sake of brevity.) The :initarg slot-option specifies that this slot can be filled in, and specifies the initarg name. This slot-option can be given more than once. There is no defclass option that specifies initargs for all the slots, because that would endorse a particular convention for naming initargs. The :default-initargs defclass option is followed by alternating initarg names and forms. If an initarg is not specified by the client nor by a :default-initargs option in a more specific class, the form is evaluated in the lexical environment of the defclass and the resulting value is used for the initarg. The class-initargs function takes a class and returns a list of initarg-name symbols. These are all of the initargs accepted by make-instance of that class. The class-slot-initargs function takes a class and returns an alist of (initarg-name slot-name) pairs. These are all the initargs that fill slots. The arguments to make-instance are first a class or a class-name, followed by alternating initarg names and values. Make-instance and constructors return one value, the newly created object. Each initarg can be associated with one or more of the four steps. Note that these are not mutually exclusive. Note that in general the client does not know or care which steps an initarg is associated with. 1. :allow-other-keys serves its usual function, as in all &key argument lists. It isn't possible to define additional initargs for step 1. 2. Initargs that control storage allocation are defined by defining an allocate-instance method that accepts the initarg as an &key argument. For example, in systems with areas :area is an initarg for step 2. The standard does not require any initargs to exist for step 2. 3. Initargs that fill slots are defined by the :initarg slot-option. 4. Initargs for initialization methods are defined by defining an initialize-instance method that accepts the initarg as an &key argument. (defmethod initialize-instance ((object class1) &key foo) (f object foo)) is an example of an initialization method. Evaluating this defmethod is sufficient to make :foo an acceptable initarg for class1 and its subclasses. Each initialize-instance method is called with the initargs that it accepts. In practice this is probably implemented by calling all of the initialize-instance methods with all of the initargs and automatically adding &allow-other-keys to the lambda-list in defmethod, however the standard should not guarantee this, i.e. it should not guarantee what an initialize-instance method with an &rest parameter will see. A constructor should be allowed to call the initialize-instance methods directly, without going through a generic-function dispatch. The parameters in the lambda-list of a constructor can specify either slot names or initargs. The rules are as follows: If a parameter name is eq to a slot name, the argument fills the slot regardless of whether a :initarg slot-option was specified. Otherwise, if a parameter name is eq to an initarg name, the argument specifies the value of the initarg. If neither of the first two rules hold, and the parameter's keyword (if the parameter is not an &key parameter, the corresponding keyword is computed by the same rule used for &key parameters) is eq to an initarg name, the argument specifies the value of the initarg. If none of these three rules holds, the :constructor defclass option is erroneous. (Because of the forward-reference rules for defclass, this error cannot be signalled at the time the defclass is evaluated. We can say that it is signalled at some later time when the constructor is actually made.) >>> REMARKS I don't like the pseudo-words "initarg" and "initform", but in the absence of a better name for "initform", I'm suggesting "initarg" in order to be consistent. To make constructor functions work in the face of forward references to superclasses in defclass, we may need to introduce compile-flavor-methods. Another reason for having compile-flavor-methods was discussed at the MIT meeting last summer. What's a good name for it? I think we need a way in the meta-object protocol for the code that makes constructor functions to determine that the standard allocate-instance method is being used, so it can be inlined. The way Symbolics implements constructors is such that it is much more efficient if allocate-instance is not actually called and there is no possibility of changing the storage representation other than by redefining the defclass. Should there be a way to create constructor functions for anonymous classes? If standard meta-objects are created by make-instance, rather than by constructors, we need to decide what initarg naming convention they are going to use. Currently 87-002 says they are made by constructors, but I think in a later meeting we decided to use make-instance instead. This is a first draft and I might suggest changes myself, as well as inviting suggestions for changes from the rest of the group.  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 15 Apr 87 23:41:39 EDT Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 15 Apr 87 20:34:19 PDT Received: from Cabernet.ms by ArpaGateway.ms ; 15 APR 87 20:34:49 PDT Date: 15 Apr 87 20:34 PDT From: Gregor.pa@Xerox.COM Subject: Re: :accessor-prefix and :reader-prefix same? In-reply-to: David A. Moon 's message of Wed, 15 Apr 87 23:03 EDT To: Moon@STONY-BROOK.SCRC.Symbolics.COM cc: Common-Lisp-Object-System@Sail.Stanford.edu Message-ID: <870415-203449-5128@Xerox> My 'interesting example' was a typo, I meant: (defclass foo () ((x :accessor foo-x)) (:reader-prefix foo-)) But you probably figured that out. But I think we agree that this "is wrong" (signals an error). Correcting your use of function where I think it should say method, I like your description of why it signals an error, namely "a single defclass form isn't allowed to define two functions with the same name if they do different things". We should use that in the documentation. Of course the string "functions with the same name" needs to be replaced with "methods with the same qualifiers on the same generic function" or something like it.  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 15 Apr 87 23:12:51 EDT Received: from [192.10.41.109] by SAIL.STANFORD.EDU with TCP; 15 Apr 87 20:03:53 PDT Received: from EUPHRATES.SCRC.Symbolics.COM by ALDERAAN.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 72451; Wed 15-Apr-87 23:03:46 EDT Date: Wed, 15 Apr 87 23:03 EDT From: David A. Moon Subject: :accessor-prefix and :reader-prefix same? To: Common-Lisp-Object-System@Sail.Stanford.edu In-Reply-To: <870415192039.6.GREGOR@AVALON.isl.parc.xerox.com> Message-ID: <870415230322.0.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Wed, 15 Apr 87 19:20 PDT From: Gregor.pa@Xerox.COM What happens if you do: (defclass foo () (a) (:accessor-prefix foo-) (:reader-prefix foo-)) I believe this should do exactly the same thing as (defclass foo () ((a :accessor foo-a :reader foo-a))) 87-002 doesn't say what this does, but it seems reasonable to make it an error. The following is an error too (defclass foo () ((a :accessor foo-a) (b :accessor foo-a))) The rule would be that a single defclass form isn't allowed to define two functions with the same name if they do different things. This is an interesting example (defclass foo () ((x :accessor foo-x)) (:accessor-prefix foo-)) which defines the same function twice. I'm inclined to say that this is not an error, but I won't argue much if someone feels it is better to make it an error. In the above, reading "signals an error" for "is an error" is fine with me. Only toy implementations would not signal such errors in my opinion. The only question is whether an error or a warning is preferable. In Flavors, all things like these are warnings (i.e. compilation continues).  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 15 Apr 87 22:37:39 EDT Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 15 Apr 87 19:29:45 PDT Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 117214; Wed 15-Apr-87 22:30:03 EDT Date: Wed, 15 Apr 87 22:29 EDT From: David A. Moon Subject: defclass options To: Gregor.pa@Xerox.COM cc: Common-Lisp-Object-System@Sail.Stanford.edu In-Reply-To: <870415155351.5.GREGOR@AVALON.isl.parc.xerox.com> Message-ID: <870415222911.6.MOON@EUPHRATES.SCRC.Symbolics.COM> Line-fold: No Date: Wed, 15 Apr 87 15:53 PDT From: Gregor.pa@Xerox.COM When an implementation (or a metaclass) extends the set of defclass options, are they allowed to add an "atomic" option. That is an option that doesn't have to be inside of a list?? I can't find language in chapter 1 or 2 that covers this. I vote for allowing :foo as an abbreviation for (:foo).  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 15 Apr 87 22:29:20 EDT Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 15 Apr 87 19:21:05 PDT Received: from Semillon.ms by ArpaGateway.ms ; 15 APR 87 19:22:10 PDT Date: Wed, 15 Apr 87 19:20 PDT From: Gregor.pa@Xerox.COM Subject: :accessor-prefix and :reader-prefix same? To: Common-Lisp-Object-System@Sail.Stanford.edu Message-ID: <870415192039.6.GREGOR@AVALON.isl.parc.xerox.com> Line-fold: no What happens if you do: (defclass foo () (a) (:accessor-prefix foo-) (:reader-prefix foo-)) How about: (defclass foo () (a) (:reader-prefix foo-) (:accessor-prefix foo-)) Is this undefined?? Signals an error?? If it does signal an error, why exactly? Is is because you aren't allowed to have an automatically generated accessor and an automatically generated reader with the same name? That would mean that this signals an error too: (defclass foo () ((x :accessor foo-x)) (:reader-prefix foo-)) I guess that seems right to me. -------  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 15 Apr 87 19:00:42 EDT Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 15 Apr 87 15:54:30 PDT Received: from Cabernet.ms by ArpaGateway.ms ; 15 APR 87 15:55:35 PDT Date: Wed, 15 Apr 87 15:53 PDT From: Gregor.pa@Xerox.COM Subject: defclass options To: Common-Lisp-Object-System@Sail.Stanford.edu Message-ID: <870415155351.5.GREGOR@AVALON.isl.parc.xerox.com> Line-fold: no When an implementation (or a metaclass) extends the set of defclass options, are they allowed to add an "atomic" option. That is an option that doesn't have to be inside of a list?? I can't find language in chapter 1 or 2 that covers this. -------  Received: from Xerox.COM (TCP 1200400040) by AI.AI.MIT.EDU 14 Apr 87 19:31:04 EDT Received: from Cabernet.ms by ArpaGateway.ms ; 14 APR 87 15:23:17 PDT Return-Path: Received: from H.CS.CMU.EDU ([128.2.254.156]) by Xerox.COM ; 14 APR 87 15:21:17 PDT Date: 14 Apr 87 17:53 EDT From: Rick.Busdiecker@h.cs.cmu.edu To: CommonLoops.PA@Xerox.COM Subject: -p function Message-Id: <545435632/rfb@h.cs.cmu.edu> In PCL of "2/24/87" in CMU CommonLisp I ran into an interesting feature. Since I was under the impression that DefClass didn't define a type predicate and I happened to want one, I defined one as: (defun -p (object) (typep object ')) which is what was recommended in Gregor's mail of 4-Dec-86. Unfortunately things had already been defined such that evaluating (typep object ') was equivalent to (-p object) which lead to an infinite recursion. So, it appears that DefClass *does* define a predicate (at least in "2/24/87") and that the recommended approach can be a lose. Rick  Received: from Xerox.COM (TCP 1200400040) by AI.AI.MIT.EDU 10 Apr 87 21:13:12 EDT Received: from Cabernet.ms by ArpaGateway.ms ; 10 APR 87 17:22:00 PDT Return-Path: Received: from navajo.stanford.edu ([36.8.0.48]) by Xerox.COM ; 10 APR 87 17:20:54 PDT Received: by navajo.stanford.edu; Fri, 10 Apr 87 17:19:07 PST Received: from bhopal.edsel.com by edsel.uucp (2.2/SMI-2.0) id AA08893; Fri, 10 Apr 87 15:06:52 pst Received: by bhopal.edsel.com (3.2/SMI-3.2) id AA03879; Fri, 10 Apr 87 16:03:03 PDT Date: Fri, 10 Apr 87 16:03:03 PDT From: edsel!bhopal!jonl@navajo.stanford.edu (Jon L White) Message-Id: <8704102303.AA03879@bhopal.edsel.com> To: navajo!rcp%MCC.COM@navajo.stanford.edu Cc: navajo!CommonLoops.pa%Xerox.COM@navajo.stanford.edu In-Reply-To: Rob Pettengill's message of Fri, 10 Apr 87 11:10:37 CDT Subject: make-specializable in SCLISP Version 2.0.2 Just a small point about (defun function-arglist (f) (system::arglist f)) ARGLIST is external in Lucid's SYSTEM package, so you shouldn't have to use double colons. The intent is that other packages could "use" SYSTEM, and thus ARGLIST wouldn't need any package qualification. It may be that in the future, the ARGLIST function will be an "extensions" package -- such a notion has been discussed on the Common Lisp mailing list for some time, and many vendors are planning to ogranize their extensions into such a place. An example would be Symbolic's use of the SYMBOLICS-COMMON-LISP package, which a typical package would want to "use" along with the LISP package. -- JonL White --  Received: from Xerox.COM (TCP 1200400040) by AI.AI.MIT.EDU 10 Apr 87 13:30:03 EDT Received: from Salvador.ms by ArpaGateway.ms ; 10 APR 87 09:14:29 PDT Return-Path: <@MCC.COM:rcp@MCC.COM> Received: from MCC.COM by Xerox.COM ; 10 APR 87 09:11:03 PDT Received: from milano.SW.MCC.COM by MCC.COM with TCP; Fri 10 Apr 87 11:09:52-CDT Received: from perseus (perseus.ARPA) by milano.SW.MCC.COM (4.12/STP1.41) id AA18050; Fri, 10 Apr 87 11:10:53 cdt Date: Fri, 10 Apr 87 11:10:37 CDT From: Rob Pettengill Message-Id: <8704101610.AA02178@perseus> Received: by perseus (3.2/STP) id AA02178; Fri, 10 Apr 87 11:10:37 CDT To: CommonLoops.pa@Xerox.COM Subject: make-specializable in SCLISP Version 2.0.2 In the last few releases of PCL make-specializable has been broken. In file lucid-low.lisp I have been placing the following: ;;; this is needed for make-specializable, rcp Fri Apr 10 10:55:24 1987 (defun function-arglist (f) (system::arglist f)) ;rob Robert C. Pettengill, MCC Software Technology Program P. O. Box 200195, Austin, Texas 78720 ARPA: rcp@mcc.com PHONE: (512) 338-3533 UUCP: {ihnp4,seismo,harvard,gatech,pyramid}!ut-sally!im4u!milano!rcp  Received: from Xerox.COM (TCP 1200400040) by AI.AI.MIT.EDU 8 Apr 87 01:15:11 EDT Received: from Cabernet.ms by ArpaGateway.ms ; 07 APR 87 21:19:43 PDT Return-Path: Received: from SPAR-20.ARPA by Xerox.COM ; 07 APR 87 21:18:49 PDT Date: Tue, 7 Apr 87 21:18 PDT From: Dan Carnese Subject: ftp premature trucation bug To: commonloops.PA@Xerox.COM Message-ID: <870407211837.8.CARNESE@KATYDID.#Internet> Yup, looks like it's fixed. -- Dan  Received: from Xerox.COM (TCP 1200400040) by AI.AI.MIT.EDU 7 Apr 87 22:32:24 EDT Received: from Cabernet.ms by ArpaGateway.ms ; 07 APR 87 19:00:07 PDT Date: 7 Apr 87 18:41 PDT From: Gregor.pa@Xerox.COM Subject: Re: make-instance In-reply-to: Rob Pettengill 's message of Thu, 2 Apr 87 10:13:07 CST To: rcp@MCC.COM cc: CommonLoops.pa@Xerox.COM Message-ID: <870407-190007-1010@Xerox> I have found a couple of CLOS problems with PCL:make-instance This is a place where PCL doesn't completely agree with the CLOS spec. The function pcl:make is more like what the spec calls make-instance. I will try to make this name change soon.  Received: from Xerox.COM (TCP 1200400040) by AI.AI.MIT.EDU 7 Apr 87 22:32:16 EDT Received: from Cabernet.ms by ArpaGateway.ms ; 07 APR 87 18:27:35 PDT Date: 7 Apr 87 18:25 PDT From: Gregor.pa@Xerox.COM Subject: FTP bug fixed? To: CommonLoops.pa@Xerox.COM Message-ID: <870407-182735-275@Xerox> I am told that the FTP "file truncation" bug has now been fixed on parcvax.xerox.com. Could people who have had problems because of this bug please try FTPing files again. Let me know if you have any more problems. Thanks Gregor  Received: from Xerox.COM (TCP 1200400040) by AI.AI.MIT.EDU 2 Apr 87 12:35:23 EST Received: from Semillon.ms by ArpaGateway.ms ; 02 APR 87 08:14:52 PST Return-Path: <@MCC.COM:rcp@MCC.COM> Received: from MCC.COM by Xerox.COM ; 02 APR 87 08:13:50 PST Received: from milano.SW.MCC.COM by MCC.COM with TCP; Thu 2 Apr 87 10:13:03-CST Received: from perseus (perseus.ARPA) by milano.SW.MCC.COM (4.12/STP1.41) id AA03938; Thu, 2 Apr 87 10:13:56 cst Date: Thu, 2 Apr 87 10:13:07 CST From: Rob Pettengill Message-Id: <8704021613.AA28906@perseus> Received: by perseus (3.2/STP) id AA28906; Thu, 2 Apr 87 10:13:07 CST To: CommonLoops.pa@Xerox.COM Subject: make-instance I have found a couple of CLOS problems with PCL:make-instance 1. Make-Instance will not take the name of a class only a class: (make-instance 'foo) looses and (make-instance (class-named 'foo)) wins. 2. Make-Instance does not initialize the instance while Make-FOO does: (make-2d-placement) #S(2D-PLACEMENT ANGLE-OF-ROTATION 0 X-SCALE 1.0 Y-SCALE 1.0 ...) (make-instance (class-named '2d-placement)) #S(2D-PLACEMENT ANGLE-OF-ROTATION NIL X-SCALE NIL Y-SCALE NIL ...)  Received: from Xerox.COM (TCP 1200400040) by AI.AI.MIT.EDU 2 Apr 87 01:59:50 EST Received: from Semillon.ms by ArpaGateway.ms ; 01 APR 87 22:00:34 PST Return-Path: Received: from SPAR-20.ARPA by Xerox.COM ; 01 APR 87 21:58:58 PST Date: Wed, 1 Apr 87 21:59 PST From: Dan Carnese Subject: bootstrap-meta-braid in lucid To: commonloops.PA@Xerox.COM Message-ID: <870401215901.3.CARNESE@KATYDID.#Internet> It dies trying to do a setf of (class-named 'class), but no such class apparently exists. I really didn't want to compile pcl, but the lucid/sun directory appears empty and the ftp bug hasn't been fixed yet anyway. -- Dan BUG REPORT: "Development Environment Version 2.0.4" "Sun2" "68010" "zonker" "UNIX4.2" "3.2" "Schlumberger Palo Alto Research" (:WINDOWS :EDITOR :FOREIGN-FUNCTION-CALL :FLOATING-POINT :COMPILER :MC68000 :SUN :UNIX :LUCID :COMMON-LISP) ---------- User's comments: Just at the start of braid2 ---------- CERROR: Required arg 0 (CONTINUE-FORMAT-STRING): "Try evaluating ~S again" Required arg 1 (FORMAT-STRING): "~S has no global value" Rest arg (FORMAT-ARGS): (NAME) SYMBOL-VALUE: Required arg 0 (S): NAME Local 1: # LUCID::LRUN-FUNCALL: Required arg 0 (LCODE): #S(LUCID::LCODE-FUNCALL NIL # NIL NAME NIL (#S(LUCID::CONTOUR NIL 0 NIL (#:G3769 CLASS))) NIL #S(LUCID::LCODE-GLOBAL-FUNCTION-REFERENCE NIL # NIL (FUNCTION SYMBOL-VALUE) NIL (#S(LUCID::CONTOUR NIL 0 NIL (#:G3769 CLASS))) NIL SYMBOL-VALUE) NIL #) Required arg 1 (ENVIRONMENT): (((CLASS-NAMED #:G7822) #:G7821)) Local 2: # Local 3: # Local 4: 1 Local 5: NAME [... lots of lucid:lrun frames ...] PROGN: Original code: (PROGN (SYSTEM:BQ-LIST (QUOTE SET-CLASS-NAMED) NAME CLASS) (LET* ((#:G3770 (CDR #:G3769)) (NAME (SYSTEM:CAR-REF #:G3770 # #)) (#:G3771 (SYSTEM:CDR-REF #:G3770 # #)) (IGNORE (SYSTEM:SCAR-REF #:G3771 NIL # #)) (#:G3772 (SYSTEM:END-REF-1 # # #))) (DECLARE (IGNORE IGNORE)) (SYSTEM:BQ-LIST (QUOTE SET-CLASS-NAMED) NAME CLASS))) [... lots more lucid:lrun frames ...] GET-SETF-METHOD-MULTIPLE-VALUE: Required arg 0 (FORM): (CLASS-NAMED (QUOTE CLASS)) Optional arg 1 (ENVIRONMENT): ((#S(LUCID::%ANODE NIL LAMBDA NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL (VALUES &REST T) NIL NIL)) (#S(LUCID::%ANODE NIL LAMBDA NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL (VALUES &REST T) NIL NIL)) NIL NIL NIL NIL NIL LUCID::%ALPHALEX) Local 2: # Local 3: #:G7821 Local 4: NIL Local 5: (#:G7822) Local 6: (CLASS-NAMED #:G7822) Local 7: (#:G7822) Local 8: ((QUOTE CLASS)) Local 9: (#:G7821) GET-SETF-METHOD: Required arg 0 (FORM): (CLASS-NAMED (QUOTE CLASS)) Optional arg 1 (ENVIRONMENT): ((#S(LUCID::%ANODE NIL LAMBDA NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL (VALUES &REST T) NIL NIL)) (#S(LUCID::%ANODE NIL LAMBDA NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL (VALUES &REST T) NIL NIL)) NIL NIL NIL NIL NIL LUCID::%ALPHALEX) SETF: Required arg 0 (FORM): (SETF (CLASS-NAMED (QUOTE CLASS)) I) Required arg 1 (ENVIRONMENT): ((#S(LUCID::%ANODE NIL LAMBDA NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL (VALUES &REST T) NIL NIL)) (#S(LUCID::%ANODE NIL LAMBDA NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL (VALUES &REST T) NIL NIL)) NIL NIL NIL NIL NIL LUCID::%ALPHALEX) Local 2: ((CLASS-NAMED (QUOTE CLASS)) I) Local 3: NIL LUCID::COMPILER-MACROEXPAND-1: Required arg 0 (FORM): (SETF (CLASS-NAMED (QUOTE CLASS)) I) Optional arg 1 (ENV): ((#S(LUCID::%ANODE NIL LAMBDA NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL (VALUES &REST T) NIL NIL)) (#S(LUCID::%ANODE NIL LAMBDA NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL (VALUES &REST T) NIL NIL)) NIL NIL NIL NIL NIL LUCID::%ALPHALEX) Optional arg 2 (REAL-MACROS-ONLY): T Local 3: # LUCID::PARSE-BODY: Required arg 0 (BODY): ((SETF (CLASS-NAMED (QUOTE CLASS)) I) (%ALLOCATE-INSTANCE--CLASS-1 14 I) I) Optional arg 1 (ENVIRONMENT): ((#S(LUCID::%ANODE NIL LAMBDA NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL (VALUES &REST T) NIL NIL)) (#S(LUCID::%ANODE NIL LAMBDA NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL (VALUES &REST T) NIL NIL)) NIL NIL NIL NIL NIL LUCID::%ALPHALEX) Optional arg 2 (DOC-STRING-ALLOWED): NIL Local 3: ((SETF (CLASS-NAMED (QUOTE CLASS)) I) (%ALLOCATE-INSTANCE--CLASS-1 14 I) I) Local 4: NIL Local 5: NIL Local 6: (SETF (CLASS-NAMED (QUOTE CLASS)) I) Local 7: T LET: Required arg 0 (FORM): (LET ((I (%%ALLOCATE-INSTANCE--CLASS))) (SETF (CLASS-NAMED (QUOTE CLASS)) I) (%ALLOCATE-INSTANCE--CLASS-1 14 I) I) Required arg 1 (ENVIRONMENT): ((#S(LUCID::%ANODE NIL LAMBDA NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL (VALUES &REST T) NIL NIL)) (#S(LUCID::%ANODE NIL LAMBDA NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL (VALUES &REST T) NIL NIL)) NIL NIL NIL NIL NIL LUCID::%ALPHALEX) Local 2: (((I (%%ALLOCATE-INSTANCE--CLASS))) (SETF (CLASS-NAMED (QUOTE CLASS)) I) (%ALLOCATE-INSTANCE--CLASS-1 14 I) I) Local 3: ((I (%%ALLOCATE-INSTANCE--CLASS))) Local 4: ((SETF (CLASS-NAMED (QUOTE CLASS)) I) (%ALLOCATE-INSTANCE--CLASS-1 14 I) I)  Received: from Xerox.COM (TCP 1200400040) by AI.AI.MIT.EDU 1 Apr 87 14:29:08 EST Received: from Semillon.ms by ArpaGateway.ms ; 01 APR 87 09:45:13 PST Return-Path: Received: from EDDIE.MIT.EDU ([18.62.0.6]) by Xerox.COM ; 01 APR 87 09:42:58 PST Received: by EDDIE.MIT.EDU with UUCP with smail2.3 with sendmail-5.31/4.7 id ; Wed, 1 Apr 87 12:32:35 EST Received: by primerd.prime.com (1.1/SMI-3.0DEV3/smail) id AA14454; Wed, 1 Apr 87 12:28:44 EST Message-Id: <8704011728.AA14454@primerd.prime.com> Received: (from user DOUG) by ENX.Prime.PDN; 01 Apr 87 12:04:58 EST To: COMMONLOOPS.PA@Xerox.COM From: primerd!DOUG@ENX.Prime.PDN.ARPA Date: 01 Apr 87 12:04:58 EST To: CommonLoops (commonloops.pa@xerox.com) From: Doug Rand (DOUG@ENX) x4182 bldg 10 Date: 01 Apr 87 12:01 PM Subject: Test bed failures On the newest version of PCL (3/19') I find that on both the Prime and the Sun there is a failure in the 'with inside of lexical closers' test. I observe that it looks like it should fail since the defmethod is macroexpanded before the class foo exists. Is this right? Has anyone else noticed this as a problem? Doug (doug@enx.prime.com, dougr@eddie.mit.edu)  Received: from Xerox.COM (TCP 1200400040) by AI.AI.MIT.EDU 1 Apr 87 14:28:54 EST Received: from Semillon.ms by ArpaGateway.ms ; 01 APR 87 09:32:44 PST Return-Path: <@MCC.COM:rcp@MCC.COM> Received: from MCC.COM by Xerox.COM ; 01 APR 87 09:31:05 PST Received: from milano.SW.MCC.COM by MCC.COM with TCP; Wed 1 Apr 87 11:30:34-CST Received: from perseus (perseus.ARPA) by milano.SW.MCC.COM (4.12/STP1.41) id AA17448; Wed, 1 Apr 87 11:30:05 cst Date: Wed, 1 Apr 87 11:29:22 CST From: Rob Pettengill Message-Id: <8704011729.AA27670@perseus> Received: by perseus (3.2/STP) id AA27670; Wed, 1 Apr 87 11:29:22 CST To: Gregor.pa@Xerox.COM Cc: CommonLoops.pa@Xerox.COM In-Reply-To: Gregor.pa@Xerox.COM's message of 31 Mar 87 15:01 PST <870331-150314-3001@Xerox> Subject: copies of CLOS DRAFT specification I managed to transfer over the new documentation files concep.amdvi, concep.cmdvi, functi.amdvi, and functi.cmdvi correctly and am trying to get them printed from a Sun with an Imagen printer. I am using "lpr -n" to print them which I have used successfully for other TeX dvi formatted documents. With the "cmdvi" versions I get no output at all. With the "amdvi" versions I get nicely formatted output that is shifted too far to the right on the page. There is about a 2 inch margin on the top and left sides of each page, which results in the text running off the right side of each sheet by 3 or 4 characters. Can anyone suggest a solution? ;rob Robert C. Pettengill, MCC Software Technology Program P. O. Box 200195, Austin, Texas 78720 ARPA: rcp@mcc.com PHONE: (512) 338-3533 UUCP: {ihnp4,seismo,harvard,gatech,pyramid}!ut-sally!im4u!milano!rcp  Received: from Xerox.COM (TCP 1200400040) by AI.AI.MIT.EDU 31 Mar 87 18:54:36 EST Received: from Semillon.ms by ArpaGateway.ms ; 31 MAR 87 15:50:10 PST Return-Path: Received: from vaxa.isi.edu by Xerox.COM ; 31 MAR 87 15:48:34 PST Received: by vaxa.isi.edu (4.12/4.7) id AA16028; Tue, 31 Mar 87 15:49:24 pst From: macgreg@vaxa.isi.edu (Robert MacGregor) Message-Id: <8703312349.AA16028@vaxa.isi.edu> Date: 31 Mar 87 15:49 PST (Tuesday) To: Gregor.pa@Xerox.COM Cc: Gregor.pa@Xerox.COM, commonloops.pa@Xerox.COM, macgreg@vaxa.isi.edu, RPG@SAIL.STANFORD.EDU, DLW@ALDERAAN.SCRC.Symbolics.COM, kempf%hplabsc@hplabs.HP.COM Subject: Re: Accessing dynamic slots using "slot-value" In-Reply-To: Your message of 31 Mar 87 10:38 PST. <870331-104035-2584@Xerox> Gregor, You hit the slot issue exactly. Our application requires that "slot-value" (or else a kludged variant of it) work with our envisioned use of dynamic slots. We don't like kludges any better than the next person. However, since our architecture expressly forbids anything resembling "undeclared" slots, the problem with "with"s that you brought up isn't an issue. Although there may be hundreds of possible slots for some of our knowledge base objects, all such slots will be pre-declared. It would be quite inefficient for us to use a special function to access dynamic slots, since an "optional" slot which has a :dynamic allocation high up in a class lattice may become "mandatory" and switch to an :instance allocation farther down in the class lattice. We want the choice of storage allocation to be transparent to the slot access calls. Putting :dynamic slots into a meta-class written on top of CLOS would be more than satisfactory.  Received: from Xerox.COM (TCP 1200400040) by AI.AI.MIT.EDU 31 Mar 87 18:52:36 EST Received: from Cabernet.ms by ArpaGateway.ms ; 31 MAR 87 15:03:14 PST Date: 31 Mar 87 15:01 PST From: Gregor.pa@Xerox.COM Subject: copies of CLOS DRAFT specification To: CommonLoops.pa@Xerox.COM Reply-to: Gregor.pa@Xerox.COM Message-ID: <870331-150314-3001@Xerox> In the /pub/pcl/doc directory are .dvi files for the current draft of the Common Lisp Object System Specification (CLOS). There are two documents, named concep and functi. For each document there are 3 files like this: concep.amdvi a dvi file using 'am' fonts concep.cmdvi a dvi file using 'cm' fonts concep.ampress a press file using am fonts functi.amdvi . . . . . NOTE 1: These documents correspond to the current DRAFT of the CLOS specification. NOTE 2: The document which describes the differences between the system these documents specify and the current version of PCL has not yet been written. I will be away for a few days, I thought it would be better to get these out as soon as possible rather than hold the whole thing up waiting for the differences document.  Received: from Xerox.COM (TCP 1200400040) by AI.AI.MIT.EDU 31 Mar 87 15:03:18 EST Received: from Cabernet.ms by ArpaGateway.ms ; 31 MAR 87 10:40:35 PST Date: 31 Mar 87 10:38 PST From: Gregor.pa@Xerox.COM Subject: Re: Eliminating dynamic slots In-reply-to: macgreg@vaxa.isi.edu (Robert MacGregor)'s message of 30 Mar 87 17:04 PST (Monday) To: macgreg@vaxa.isi.edu To: RPG@SAIL.STANFORD.EDU To: DLW@ALDERAAN.SCRC.Symbolics.COM To: kempf%hplabsc@hplabs.HP.COM cc: Gregor.pa@Xerox.COM, commonloops.pa@Xerox.COM Message-ID: <870331-104035-2584@Xerox> The real issue here is whether you would like to be able to use slot-value (nee get-slot) to access your dynamic slots. What about with-slots? This seems to be what DLW calls syntax. If you want to use with-slots, you have to be able to give up the notion of so-called "undeclared" dynamic slots (ones which do not appear in the defclass form but are created on the fly with get-slot always). On the other hand, saying that you could use slot-value but not with-slots seems kludgey. These are the problems that led us to remove :dynamic slots from the CLOS specification. In your own program, if you would like slot-value to access your :dynamic slots, then you will need to define a new meta-class. If you are willing to use a special function to access dynamic slots, you don't really need a new metaclass, you can use something like the property-list-mixin DLW referred to or the code that Jim Kempf mentioned. It would still be nicer to use a new meta-class since that would let you put the :dynamic slots in the defclass form which would help document your program and have all those other nice features. I will look into adding a meta-class which does this for you, but which would be written on top of CLOS to the same release of PCL in which I remove :dynamic slots.  Received: from Xerox.COM (TCP 1200400040) by AI.AI.MIT.EDU 31 Mar 87 11:59:26 EST Received: from Semillon.ms by ArpaGateway.ms ; 31 MAR 87 07:53:25 PST Return-Path: Received: from hplabs.HP.COM ([192.5.58.10]) by Xerox.COM ; 31 MAR 87 07:51:32 PST Received: from hplabsc by hplabs.HP.COM with TCP ; Tue, 31 Mar 87 07:49:10 pst Received: by hplabsc ; Tue, 31 Mar 87 07:50:27 pst Date: Tue, 31 Mar 87 07:50:27 pst From: Jim Kempf Message-Id: <8703311550.AA06978@hplabsc> To: Gregor.pa@Xerox.COM, macgreg@vaxa.isi.edu Subject: Re: Eliminating dynamic slots Cc: commonloops.pa@Xerox.COM >as the basis for a knowledge representation system. We are forcasting >that in future applications, knowledge base objects might have on the >order of 5 to 20 slots which fit the notion of an instance slot, i.e., a >slot which must have a value, while for the same object there may be >hundreds of "potential" slots, each of which has an exceedingly low >probability of having a value. The solution to this is to simply use a slot to which is assigned an object containing the slots which one wants to make dynamic. Thus: (defclass knowledge-based-application-class (slots-where-things-always-are NIL) (slots-where-things-could-be :accessor dynamic-slot-access) ) >If dynamic slots are eliminated, we will be forced to implement >them ourselves. My guess is that an efficient implementation would >rely on relatively low-level portions of the PCL code, and would thus >be subject to update as new versions are released. What we would Not necessarily. The metaclass kernel is specifically designed to make this kind of thing easy. >We would prefer to be PCL-users rather than PCL hackers (in the >non-perjorative sense of the word), in the sense that we are hoping to >utilize PCL without the necessity of learning its internals, especially >right now, when the implementation is continuously changing. Changes in the implementation are a problem at the moment. The point of getting rid of the :dynamic option was to pair out functionality which was costing people who didn't use it. The metaobject protocol was specificially designed for easy customization of system internals, so the amount of "PCL hacking" you'd need to do would be fairly trivial. >The last glimpse we saw of the Common Objects/Classes standard said very >little about metaclasses, not even remotely enough to enable one to >define one's own metaclass based only the standard. In other words, the >metaclass mechanism seems to be one of the less mature parts of the >standard, and from our vantage point, using it might consume a great >deal more time than we would like to spend. It is true that the metaobject protocol is still under discussion, but a basic interface is outlined in ANSI X3J13 document 87-003. I don't think it would take as much time to do a dynamic slots metaclass as you seem to think (tracking revisions is another matter). This is speaking from experience, since I've already done a metaclass for CommonObjects. Jim Kempf kempf@hplabs.hp.com  Received: from Xerox.COM (TCP 1200400040) by AI.AI.MIT.EDU 31 Mar 87 02:28:03 EST Received: from Semillon.ms by ArpaGateway.ms ; 30 MAR 87 22:48:33 PST Return-Path: Received: from ALDERAAN.SCRC.Symbolics.COM ([192.10.41.109]) by Xerox.COM ; 30 MAR 87 22:47:30 PST Received: from CHICOPEE.SCRC.Symbolics.COM by ALDERAAN.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 67203; Tue 31-Mar-87 01:14:15 EST Date: Tue, 31 Mar 87 01:12 EST From: Daniel L. Weinreb Subject: :dynamic slots To: RPG@SAIL.STANFORD.EDU, commonloops.pa@Xerox.COM In-Reply-To: <870330-204604-2018@Xerox> Message-ID: <870331011214.9.DLW@CHICOPEE.SCRC.Symbolics.COM> Line-fold: No I agree, and would like to amplify the important point you made: it isn't necessary to define a new metaclass to get the essential functionality of the :dynamic feature. You can do it with a class that gets inherited by anybody using the feature, plus a macro. We've been doing the equivalent thing with flavors for a long time, using a flavor called property-list-mixin. The only advantage to building in :dynamic that I can see would be if you like that syntax better. I don't see any reason to expect a performance penalty.  Received: from Xerox.COM (TCP 1200400040) by AI.AI.MIT.EDU 31 Mar 87 00:44:55 EST Received: from Semillon.ms by ArpaGateway.ms ; 30 MAR 87 20:55:14 PST Return-Path: Received: from caf.MIT.EDU ([18.62.0.232]) by Xerox.COM ; 30 MAR 87 20:54:11 PST Received: by caf.MIT.EDU (5.54/4.7) id AA05828; Mon, 30 Mar 87 23:52:36 EST Date: Mon, 30 Mar 87 23:52:36 EST From: mbm@caf.MIT.EDU (Mike McIlrath) Message-Id: <8703310452.AA05828@caf.MIT.EDU> To: macgreg@vaxa.isi.edu Cc: Gregor.pa@Xerox.COM, commonloops.pa@Xerox.COM In-Reply-To: Robert MacGregor's message of 30 Mar 87 17:04 PST (Monday) <8703310105.AA06666@vaxa.isi.edu> Subject: Eliminating dynamic slots I'm in a similar situation; we are using PCL to interface to a heterogeneous CIM database. The objects under discussion may have a number of attributes (slots) that require multiple queries to the database to retrieve, and may not always be needed. On the other hand, if the slot is accessed, the info should show up, and then be memoized. Of course this should all be transparent to the "user". I dont mind pawing around in the code to find pcl::all-slots or whatever it is in this release, but I have not succeeded in making a non-trivial metaclass at all, let alone one with dynamic slots that is compatible with the new standard being documented. Perhaps Gregor could show us how. I dont care so much about taking a performance hit, and I think I agree that classes that dont need dynamic slots shouldnt have to pay for them. A new metaclass makes sense to me -- now how do I do it? --mike  Received: from Xerox.COM (TCP 1200400040) by AI.AI.MIT.EDU 31 Mar 87 00:44:43 EST Received: from Semillon.ms by ArpaGateway.ms ; 30 MAR 87 20:46:04 PST Return-Path: Received: from SAIL.STANFORD.EDU by Xerox.COM ; 30 MAR 87 20:45:05 PST Date: 30 Mar 87 20:43 PST From: Dick Gabriel Subject: :dynamic slots To: commonloops.pa@Xerox.COM Message-ID: <870330-204604-2018@Xerox> The reason that :dynamic slots were eliminated from CLOS was that they are a difficult-to-justify programming language construct. Because there are no users of CLOS yet (only users of PCL) now is the time to eliminate all constructs we will later regret. To be blunt, :dynamic slots are a kludge. Now, I suspect that you have discovered that you have some concept in mind that happens to map onto PCL :dynamic slots, and this ``AI'' concept is interesting to you. This is no justification for putting something in a programming language. I think if you define your own generic-function accessors and setf methods, you will be able to get the effect of :dynamic slots with little or no performance penalty, and you won't have learn about the meta-object protocol. -rpg-  Received: from Xerox.COM (TCP 1200400040) by AI.AI.MIT.EDU 30 Mar 87 20:59:00 EST Received: from Semillon.ms by ArpaGateway.ms ; 30 MAR 87 17:06:23 PST Return-Path: Received: from vaxa.isi.edu by Xerox.COM ; 30 MAR 87 17:04:11 PST Received: by vaxa.isi.edu (4.12/4.7) id AA06666; Mon, 30 Mar 87 17:05:00 pst From: macgreg@vaxa.isi.edu (Robert MacGregor) Message-Id: <8703310105.AA06666@vaxa.isi.edu> Date: 30 Mar 87 17:04 PST (Monday) To: Gregor.pa@Xerox.COM Cc: commonloops.pa@Xerox.COM Subject: Re: Eliminating dynamic slots In-Reply-To: Your message of 29 Mar 87 18:35 PST. <870329-183643-3698@Xerox> At ISI we are currently making extensive use of dynamic slots in our application of PCL, and I would expect that many of our objects would double in size if we didn't have the :dynamic option. We are using PCL as the basis for a knowledge representation system. We are forcasting that in future applications, knowledge base objects might have on the order of 5 to 20 slots which fit the notion of an instance slot, i.e., a slot which must have a value, while for the same object there may be hundreds of "potential" slots, each of which has an exceedingly low probability of having a value. If dynamic slots are eliminated, we will be forced to implement them ourselves. My guess is that an efficient implementation would rely on relatively low-level portions of the PCL code, and would thus be subject to update as new versions are released. What we would like to see is official support for a second meta-class called, say, "dynamic-class", which does what "class" does now. "Of course, for a program which reall does want something like :dynamic slots, its pretty easy to do using the meta-object protocol." We would prefer to be PCL-users rather than PCL hackers (in the non-perjorative sense of the word), in the sense that we are hoping to utilize PCL without the necessity of learning its internals, especially right now, when the implementation is continuously changing. The last glimpse we saw of the Common Objects/Classes standard said very little about metaclasses, not even remotely enough to enable one to define one's own metaclass based only the standard. In other words, the metaclass mechanism seems to be one of the less mature parts of the standard, and from our vantage point, using it might consume a great deal more time than we would like to spend. Bob Mac Gregor  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 30 Mar 87 18:48:15 EST Date: 30 Mar 87 1541 PST From: Linda DeMichiel Subject: clos files on [cls,lsp] To: common-lisp-object-system@SAIL.STANFORD.EDU I have updated concep and functi to incorporate the "Corrections" part of the Errata document handed out at x3j13. New files: concep.tex, concep.dvi, concep.pre, concep.imp; functi.tex, functi.dvi, functi.pre, functi.imp. --LGD  Received: from Xerox.COM (TCP 1200400040) by AI.AI.MIT.EDU 30 Mar 87 16:58:06 EST Received: from Salvador.ms by ArpaGateway.ms ; 30 MAR 87 13:54:31 PST Date: Mon, 30 Mar 87 13:53:56 PST From: kahn.pa@Xerox.COM Subject: Re: {eris}: tracts of dead flesh? In-Reply-To: "Gregor's message of Mon, 30 Mar 87 9:51:00 PST" To: Gregor.pa@Xerox.COM cc: Bobrow.pa@Xerox.COM, Fischer.pa@Xerox.COM, CommonLoopsCore^.pa@Xerox.COM Message-ID: <870330-135431-1490@Xerox> I copied {eris}commonlog> to {phylum}commonlog> References Gregor's message of Mon, 30 Mar 87 9:51:00 PST -- Re: {eris}: tracts of dead flesh?  Received: from Xerox.COM (TCP 1200400040) by AI.AI.MIT.EDU 30 Mar 87 12:57:04 EST Received: from Cabernet.ms by ArpaGateway.ms ; 30 MAR 87 09:51:49 PST Date: 30 Mar 87 09:51 PST From: Gregor.pa@Xerox.COM Subject: Re: {eris}: tracts of dead flesh? In-reply-to: Danny Bobrow 's message of 25 Mar 87 15:26 PST To: Bobrow.pa@Xerox.COM cc: Gregor.pa@Xerox.COM, Fischer.pa@Xerox.COM, CommonLoopsCore^.pa@Xerox.COM, Kahn.pa@Xerox.COM Message-ID: <870330-095149-1049@Xerox> Is there any real point to archiving this stuff? (the old version of PCL that sort of runs in Koto)? Can you imagine us ever wanting to run it again? If you want to archive it go ahead, otherwise I will just delete it.  Received: from Xerox.COM (TCP 1200400040) by AI.AI.MIT.EDU 30 Mar 87 12:39:58 EST Received: from Cabernet.ms by ArpaGateway.ms ; 30 MAR 87 09:33:52 PST Date: 30 Mar 87 09:41 PST From: Masinter.pa@Xerox.COM Subject: [hagmann.pa: Announcement of April 10th BASS] To: CommonLoopsCore^.pa@Xerox.COM Message-ID: <870330-093352-1010@Xerox> note Kemph's talk.... ----- Begin Forwarded Messages ----- Date: Mon, 30 Mar 87 08:48:05 PST From: hagmann.pa Subject: Announcement of April 10th BASS To: ComputerResearch^.pa Reply-to: hagmann Below is the BASS announcement from the SUN coordinator for BASS, David Rosenthal. Please respond to me by electronic mail by Monday, April 6 if you plan to attend. There is a total of 80 person limit in the conference room, so attendance may be limited (sigh). If limited, the order of response to this message will determine priority. The map below looks best in fixed pitch font. The location is the old Xerox Geng Road site. BASS 8: Databases & Other Stuff Friday, April 10th Sun Microsystems 2300 Geng Rd. Palo Alto 1. Location BASS 8 will be held in the Glacier Meeting Room at the new location for Sun's Software Products Division, 2300 Geng Rd., Palo Alto on Friday April 10th. X marks the spot. Oregon | | | Embarcadero North(ish)-> | | | | | | =================+===+=+=========================== 101 | | | =================+===+=+=========================== \ | | | / -----+---+-+--- ---------------Frontage \ / \| | / X O -- | | / O ---------------%-%--- O Park | | | %-%-------------+-------Geng | | Refreshments and lunch will be served. 2. Program 09:00 Coffee & Pastries 09:30 NonStop SQL Jim Gray Tandem 10:30 Starburst John McPherson IBM 11:30 Coffee 11:45 Hiding Secrets Dorothy Denning SRI 12:45 Lunch 1:45 Mahler David Wall DEC WRL 2:45 Tea 3:00 Portable CommonLoops "jak" H-P Labs 2.1. NonStop SQL Jim Gray: Tandem NonStop SQL is an implementation of the ANSI Standard SQL relational database language. Extensions in the data defin- ition area include the notions of catalogs, assertions on tables, and table partitioning, organization, node auton- omy features, and integration with the host naming and authorization mechanism. Extensions in the data manipula- tion are include binding of the SQL source an dobject with compiled object programs, location independent naming, locking extensions, and extensions to deal with both tran- saction protected files and non-transactional files. The implementation goal was to provide the functionality and useability of SQL with the price/performance of IMS/Fast Path. Benchmarks demonstrate that the system can deliver well beyond 200 transactions per second at about $50K/tps. After a brief sketch of SQL and the NonStop SQL extensions, the talk will focus on the design choices which gave such impressive results. 2.2. The Data Management Extension Architecture of Star- burst John A. McPherson, IBM Almaden Research Center Starburst is an experimental relational database project at IBM Almaden Research Center. The Starburst project's goal is to produce a portable, extensible, distributed database management system which incorporates new system structures and performance techniques. In support of the extensibility goal, a database management system architecture has been defined that facilitates the implementation of data management extensions. This archi- tecture supports two classes of data management extensions: "flavors", which are relation storage extensions, and "attachments", which are access method or integrity con- straint extensions. Generic sets of operations are defined for flavors and attachments, and these operations must be provided in order to add a new flavor or attachment type to the system. The data management extension architecture also provides common services for coordination of flavor and attachment execution. This talk will give a brief overview of the Starburst project and then will discuss in more detail the database management extension architecture. 2.3. Hiding Secrets in Databases Dorothy E. Denning: SRI International SRI International and Gemini Computers are developing a for- mal security model for a relational database system that would protect sensitive data of different classifications (e.g., proprietary, confidential, or classified in the DoD sense). Two principal problems that the model must address are: assurance that sensitive data of a given class cannot be accessed by or leaked to users who are not authorized for data of that class, and the avalanche of effects on the data model that arise from hiding data. The talk will discuss these problems and describe an extended relational model that solves them. 2.4. The Mahler Experience: Using an Intermediate Language as the Machine Description David Wall: DEC WRL Division of a compiler into a front end and a back end that communicate via an intermediate language is a well-known technique. In building compilers for a family of machines with simple instruction sets and addressing capabilities, we have designed an intermediate language that we use as the official description of the machine, hiding some of the inconvenient idiosyncrasies of the real machine from the users and the front end compilers. To do this credibly, we have had to hide not only the existence of the idiosyncrasies but also the performance consequences of hiding them. That is, the back end that compiles and links the intermediate language tries to gen- erate code that does not suffer a performance penalty because of the details that were hidden from the front end compiler. For the most part we have been successful. In this talk we discuss the techniques used to accomplish this. We use interprocedural register allocation to hide the fact that the machine has only a finite number of regis- ters. We use instruction scheduling to hide the existence of multi-cycle floating-point instructions and pipeline stalls. Finally, we use branch slot filling to hide the existence of delayed branches. 2.5. Experiences with Portable CommonLoops "jak": H-P Labs -> Dan: -> I expect to have some results on CommonLoops by April 1, -> the due date for papers submitted to OOPSLA and would like to -> give something at BASS also. Is this possible? The paper will -> be called "Experiences with Portable CommonLoops" and will -> contain a discussion of Warren Harris's window system, my -> portable CommonObjects implementation, and some profiling -> results. I expect the profiling to include, at least, HP Lisp, -> and possibly also Kyoto Common Lisp and Franz Lisp. Remotely, -> I might be able to get Lucid, Symbolics, and DEC Lisp in too. -> -> -> jak ----- End Forwarded Messages -----  Received: from Xerox.COM (TCP 1200400040) by AI.AI.MIT.EDU 29 Mar 87 22:36:44 EST Received: from Cabernet.ms by ArpaGateway.ms ; 29 MAR 87 18:36:43 PST Date: 29 Mar 87 18:35 PST From: Gregor.pa@Xerox.COM Subject: Re: PCL Bombing on dynamic slots In-reply-to: mbm@caf.MIT.EDU (Mike McIlrath)'s message of Sat, 28 Mar 87 09:27:04 EST To: mbm@caf.MIT.EDU cc: Gregor.pa@Xerox.COM, wallace@ucbarpa.Berkeley.EDU, commonloops.pa@Xerox.COM Message-ID: <870329-183643-3698@Xerox> I should have put a more careful explanation of the demise of :dynamic slots in my previous message. After looking at :dynamic slots carefully, we decided that in almost all cases, they did not give an advantageous space/performance tradeoff. Basically - just providing :dynamic slots as an option means that every instance of every class with meta-class class, is one word bigger. Regardless of whether the class uses :dynamic slots. for instances which do have :dynamic slots, it takes 4 words of storage to store the value of the slot rather than the 1 word it takes if the slot is a :instance slot. When you add this up :dynamic slots just don't seem worth it, most programs which did use them will do just as well or better to use :instance (the default) slots. Of course, for a program which reall does want something like :dynamic slots, its pretty easy to do using the meta-object protocol.  Received: from Xerox.COM (TCP 1200400040) by AI.AI.MIT.EDU 29 Mar 87 22:36:34 EST Received: from Cabernet.ms by ArpaGateway.ms ; 29 MAR 87 18:31:05 PST Date: 29 Mar 87 18:28 PST From: Gregor.pa@Xerox.COM Subject: Re: documentation In-reply-to: mbm@caf.MIT.EDU (Mike McIlrath)'s message of Sat, 28 Mar 87 09:19:35 EST To: mbm@caf.MIT.EDU cc: Gregor.pa@Xerox.COM, CommonLoops.pa@Xerox.COM Message-ID: <870329-183105-3696@Xerox> From: mbm@caf.MIT.EDU (Mike McIlrath) Date: Sat, 21 Mar 87 14:05 PST From: Gregor.pa@Xerox.COM Line-Fold: no At some point next week, we will be putting DVI files of the current draft of the Common Lisp Object System (CLOS) Specification on parcvax.xerox.com. Is it next week yet? Well no, not yet. Hopefully it will be next week sometime this week. A little editing needs to be done to that document before it can be distributed.  Received: from Xerox.COM (TCP 1200400040) by AI.AI.MIT.EDU 28 Mar 87 11:17:45 EST Received: from Semillon.ms by ArpaGateway.ms ; 28 MAR 87 06:29:48 PST Return-Path: Received: from caf.MIT.EDU ([18.62.0.232]) by Xerox.COM ; 28 MAR 87 06:28:41 PST Received: by caf.MIT.EDU (5.54/4.7) id AA00474; Sat, 28 Mar 87 09:27:04 EST Date: Sat, 28 Mar 87 09:27:04 EST From: mbm@caf.MIT.EDU (Mike McIlrath) Message-Id: <8703281427.AA00474@caf.MIT.EDU> To: Gregor.pa@Xerox.COM Cc: wallace@ucbarpa.Berkeley.EDU, commonloops.pa@Xerox.COM In-Reply-To: Gregor.pa@Xerox.COM's message of 27 Mar 87 13:34 PST <870327-133830-2477@Xerox> Subject: PCL Bombing on dynamic slots Date: 27 Mar 87 13:34 PST From: Gregor.pa@Xerox.COM ... NOTICE of upcoming change to PCL. The next version of PCL won't support :dynamic slots, anyone who is using them should convert their code in this release to not use them anymore. Why?? Is there going to be some other way to get this functionality?  Received: from Xerox.COM (TCP 1200400040) by AI.AI.MIT.EDU 28 Mar 87 11:17:35 EST Received: from Semillon.ms by ArpaGateway.ms ; 28 MAR 87 06:24:12 PST Return-Path: Received: from caf.MIT.EDU ([18.62.0.232]) by Xerox.COM ; 28 MAR 87 06:21:46 PST Received: by caf.MIT.EDU (5.54/4.7) id AA00409; Sat, 28 Mar 87 09:19:35 EST Date: Sat, 28 Mar 87 09:19:35 EST From: mbm@caf.MIT.EDU (Mike McIlrath) Message-Id: <8703281419.AA00409@caf.MIT.EDU> To: Gregor.pa@Xerox.COM Cc: CommonLoops.pa@Xerox.COM In-Reply-To: Gregor.pa@Xerox.COM's message of Sat, 21 Mar 87 14:05 PST <870321140502.9.GREGOR@AVALON.isl.parc.xerox.com> Subject: documentation Date: Sat, 21 Mar 87 14:05 PST From: Gregor.pa@Xerox.COM Line-Fold: no At some point next week, we will be putting DVI files of the current draft of the Common Lisp Object System (CLOS) Specification on parcvax.xerox.com. ... Is it next week yet?  Received: from Xerox.COM (TCP 1200400040) by AI.AI.MIT.EDU 27 Mar 87 17:53:35 EST Received: from Cabernet.ms by ArpaGateway.ms ; 27 MAR 87 13:38:30 PST Date: 27 Mar 87 13:34 PST From: Gregor.pa@Xerox.COM Subject: Re: PCL Bombing on dynamic slots In-reply-to: wallace@ucbarpa.Berkeley.EDU (David E. Wallace)'s message of Wed, 25 Mar 87 02:55:27 PST To: wallace@ucbarpa.Berkeley.EDU cc: commonloops.pa@Xerox.COM Message-ID: <870327-133830-2477@Xerox> Well, I don't understand what is causing this bug yet. But I do have some suggestions. 1. Try getting the new version of FSC-LOW off of parcvax.xerox.com. It *may* fix this bug. 2. Better yet, stop using :dynamic slots. NOTICE of upcoming change to PCL. The next version of PCL won't support :dynamic slots, anyone who is using them should convert their code in this release to not use them anymore.  Received: from Xerox.COM (TCP 1200400040) by AI.AI.MIT.EDU 25 Mar 87 21:45:57 EST Received: from Cabernet.ms by ArpaGateway.ms ; 25 MAR 87 16:37:05 PST Return-Path: Received: from EDDIE.MIT.EDU ([18.62.0.6]) by Xerox.COM ; 25 MAR 87 16:31:48 PST Received: by EDDIE.MIT.EDU with UUCP with smail2.3 with sendmail-5.31/4.7 id ; Wed, 25 Mar 87 19:32:02 EST Received: by primerd.prime.com (1.1/SMI-3.0DEV3/smail) id AA03909; Wed, 25 Mar 87 19:15:06 EST Message-Id: <8703260015.AA03909@primerd.prime.com> Received: (from user DOUG) by ENX.Prime.PDN; 25 Mar 87 18:32:39 EST To: COMMONLOOPS.PA@Xerox.COM From: primerd!DOUG@ENX.Prime.PDN.ARPA Date: 25 Mar 87 18:32:39 EST To: CommonLOOPS (commonloops@xerox.com) From: Doug Rand (DOUG@ENX.PRIME.COM) x4182 bldg 10 Date: 25 Mar 87 6:29 PM Subject: Fix to problem in 1.0 Prime Common LISP (LUCID) I talked with Gregor and we found the following fixes to my problems with Lucid on Prime. In fsc-low.lisp: ;; after (defun make-funcallable-instance-1 ;; add the line (declare (notinline lucid::new-procedure)) ;; change the lines (dotimes (i max-procedure-size) (setf (lucid::procedure-ref fin i) (lucid::procedure-ref new-value i))) ;; to (dotimes (i max-procedure-size) (setf (lucid::procedure-ref fin i) (if (< i new-procedure-size) (lucid::procedure-ref new-value i) nil)))  Received: from Xerox.COM (TCP 1200400040) by AI.AI.MIT.EDU 25 Mar 87 19:12:48 EST Received: from Salvador.ms by ArpaGateway.ms ; 25 MAR 87 15:41:48 PST Return-Path: Received: from aramis.rutgers.edu ([128.6.5.58]) by Xerox.COM ; 25 MAR 87 15:39:30 PST Received: by aramis.rutgers.edu; Wed, 25 Mar 87 18:43:22 EST Date: Wed, 25 Mar 87 18:43:22 EST From: liew@aramis.rutgers.edu (Liew) Message-Id: <8703252343.AA13225@aramis.rutgers.edu> To: Gregor.pa@Xerox.COM Cc: CommonLoops.PA@Xerox.COM In-Reply-To: Gregor.pa@Xerox.COM's message of 24 Mar 87 11:26 PST Subject: Re: Problem with the latest CommonLoops I tried out the fix you suggested and it fixed the problem in excl-low.cl. A similar problem arose in fsc-low.cl and I was not successful at patching that source file. I am going to temporarily go back to the old source and wait until we get an update from Franz for ExCL. Thanks for the help. -chun  Received: from Xerox.COM (TCP 1200400040) by AI.AI.MIT.EDU 25 Mar 87 19:12:33 EST Received: from Cabernet.ms by ArpaGateway.ms ; 25 MAR 87 15:28:33 PST Date: 25 Mar 87 15:26 PST Sender: Bobrow.pa@Xerox.COM From: Danny Bobrow Subject: Re: {eris}: tracts of dead flesh? In-reply-to: Gregor.pa's message of 25 Mar 87 13:06 PST To: Gregor.pa@Xerox.COM cc: Fischer.pa@Xerox.COM, CommonLoopsCore^.pa@Xerox.COM, Kahn.pa@Xerox.COM Message-ID: <870325-152833-2564@Xerox> Old stuff to make an old version of PCL run in Koto. Unless someone objects I will delete all this. At least let us archive this rather than just delete. danny  Received: from Xerox.COM (TCP 1200400040) by AI.AI.MIT.EDU 25 Mar 87 19:12:05 EST Received: from Cabernet.ms by ArpaGateway.ms ; 25 MAR 87 14:37:04 PST Date: 25 Mar 87 14:35 PST From: Gregor.pa@Xerox.COM Subject: Re: Problem compiling on LUCID LISP on the PRIME In-reply-to: primerd!DOUG@ENX.Prime.PDN.ARPA's message of 23 Mar 87 15:12:01 EST To: CommonLoops.pa@Xerox.COM Message-ID: <870325-143704-2504@Xerox> From: primerd!DOUG@ENX.Prime.PDN.ARPA Date: 23 Mar 87 15:12:01 EST Complains while loading the binary from BRAID1. SET-FUNCALLABLE-INSTANCE-FUNCTION Req arg 0 (FIN): # Req arg 1 (NEW-VALUE): # There is a new version of fsc-low.lisp on parcvax which EVERYONE WHO USES LUCID LISP should get a copy of. If you want to save a little time, you can compile it as follows rather than using (compile-pcl). It will also work to use (compile-pcl) its just that compile-pcl will recompile most of the system which isn't necessary. 1. Get a lisp with PCL loaded into it. 2. Compile the file fsc-low. 3. Then get a fresh lisp and use (load-pcl) to load pcl.  Received: from Xerox.COM (TCP 1200400040) by AI.AI.MIT.EDU 25 Mar 87 16:11:17 EST Received: from Cabernet.ms by ArpaGateway.ms ; 25 MAR 87 13:07:05 PST Date: 25 Mar 87 13:06 PST From: Gregor.pa@Xerox.COM Subject: Re: {eris}: tracts of dead flesh? In-reply-to: Fischer.pa's message of 25 Mar 87 12:18 PST To: Fischer.pa@Xerox.COM cc: CommonLoopsCore^.pa@Xerox.COM, Kahn.pa@Xerox.COM Message-ID: <870325-130705-2399@Xerox> By deleting excess versions I got back about 4k pages. What's left falls into 3 categories. CommonLog stuff. Ken, would you please do something with this? Old stuff to make an old version of PCL run in Koto. Unless someone objects I will delete all this. Documentation. Lets just leave this where it is for now, it doesn't take up much space.  Received: from Xerox.COM (TCP 1200400040) by AI.AI.MIT.EDU 25 Mar 87 15:23:36 EST Received: from Cabernet.ms by ArpaGateway.ms ; 25 MAR 87 12:20:39 PST Date: 25 Mar 87 12:18 PST From: Fischer.pa@Xerox.COM Subject: {eris}: tracts of dead flesh? To: CommonLoopsCore^.pa@Xerox.COM cc: LispCore^.pa@Xerox.COM Reply-to: Fischer.pa@Xerox.COM Message-ID: <870325-122039-2315@Xerox> We frequently run out of space on eris these days. No files have been written in the directory since december of last year. It takes about 13,400 pages (as shown by filebrowser). I understand most development of PCL occurs on Phylum now. Perhaps you could move off of Eris? (ron)  Received: from Xerox.COM (TCP 1200400040) by AI.AI.MIT.EDU 25 Mar 87 15:23:25 EST Received: from Cabernet.ms by ArpaGateway.ms ; 25 MAR 87 09:37:21 PST Return-Path: Received: from EDDIE.MIT.EDU ([18.62.0.6]) by Xerox.COM ; 25 MAR 87 09:33:28 PST Received: by EDDIE.MIT.EDU with UUCP with smail2.3 with sendmail-5.31/4.7 id ; Wed, 25 Mar 87 12:33:12 EST Received: by primerd.prime.com (1.1/SMI-3.0DEV3/smail) id AA03296; Wed, 25 Mar 87 12:07:14 EST Message-Id: <8703251707.AA03296@primerd.prime.com> Received: (from user DOUG) by ENX.Prime.PDN; 25 Mar 87 11:09:29 EST To: COMMONLOOPS.PA@Xerox.COM From: primerd!DOUG@ENX.Prime.PDN.ARPA Date: 25 Mar 87 11:09:29 EST To: CommonLoops (CommonLoops@xerox.com) From: Doug Rand (DOUG@ENX.PRIME.COM) Date: 25 Mar 87 10:46 AM Subject: Problem Loading BRAID1 binary in Lucid CL I find that I get the following error message after (pcl::compile-pcl) if I don't delete the pcl and walker packages: Loading binary of BRAID1... ;;; Warning: Redefining GET-STATIC-SLOT--CLASS ;;; Warning: Redefining GET-DYNAMIC-SLOT--CLASS ;;; Warning: Redefining REMOVE-DYNAMIC-SLOT--CLASS ;;; Warning: Redefining structure ESSENTIAL-SLOTD ;;; Warning: Redefining SLOTD-POSITION ;;; Warning: Redefining SLOTD-MEMBER ;;; Warning: Redefining SLOTD-ASSOC ;;; Warning: Redefining structure DS-OPTIONS >>Error: Can't add an early method to ordinary lisp function. LOAD-METHOD-1: Required arg 0 (GENERIC-FUNCTION-NAME): MAKE-DS-OPTIONS Required arg 1 (METHOD-TYPE-SPECIFIERS): (BASIC-CLASS) Required arg 2 (METHOD-ARGLIST): (CLASS NAME) Required arg 3 (OPTIONS): NIL Required arg 4 (DOCUMENTATION): NIL :A Abort to Lisp Top Level -> :A Back to Lisp Top Level And I get this other (related?) message if I first clean house and delete the pcl and walker packages: Loading binary of BOOT... Loading binary of BRAID1... >>Error: # is not a funcallable-instance SET-FUNCALLABLE-INSTANCE-FUNCTION: Required arg 0 (FIN): # Required arg 1 (NEW-VALUE): # :A Abort to Lisp Top Level -> :A Back to Lisp Top Level > (dribble) This also happens with a fresh copy of LISP. The stack above this error is also in process of LOAD-METHOD-1 on make-ds-options. Has anyone successfully compiled and loaded the new PCL on Lucid? Doug (doug@enx.prime.com, dougr@eddie.mit.edu)  Received: from Xerox.COM (TCP 1200400040) by AI.AI.MIT.EDU 25 Mar 87 07:30:13 EST Received: from Cabernet.ms by ArpaGateway.ms ; 25 MAR 87 02:56:34 PST Return-Path: Received: from ucbarpa.Berkeley.EDU by Xerox.COM ; 25 MAR 87 02:55:10 PST Received: by ucbarpa.Berkeley.EDU (5.57/1.23) id AA26010; Wed, 25 Mar 87 02:55:30 PST From: wallace@ucbarpa.Berkeley.EDU (David E. Wallace) Message-Id: <8703251055.AA26010@ucbarpa.Berkeley.EDU> To: commonloops.pa@Xerox.COM Subject: PCL Bombing on dynamic slots Date: Wed, 25 Mar 87 02:55:27 PST I'm running PCL under ExCL on a Sun/3, and am having trouble with PCL bombing out when I try to instantiate a class with two dynamic slots for the second time. I get slightly different behavior with the PCL versions of 1/26/87 and 3/21/87; both are shown below. This example runs fine under the 3/21/87 version with VAXLISP. The 3/21/87 version compiled with no errors. Separate question: I cooked up this example because I was trying to figure out how to tell if a given dynamic slot had been allocated on a given instance. Best way I've found so far is to call pcl::iwmc-class-dynamic-slots on the instance, and look for the slot name in the result. Is there a better/more "official" way to do this? Dave Wallace (wallace@ucbarpa.Berkeley.EDU) * * * * * * * * ;;; PCL version of 3/21/87 Extended Common Lisp 1.5.6 (1/23/87 15:22) Copyright (c) 1986, Franz Inc., Alameda, Ca (defclass foo () ((var1 3) (var2 :allocation :dynamic :initform 5) (var3 :allocation :dynamic :initform 7)) (:accessor-prefix ||)(:constructor make-foo)) FOO (setq f1 (make-foo)) #S(FOO VAR1 3) (setq f2 (make-foo)) Process lisp illegal instruction (core dumped) ;;; PCL version of 1/26/87 Extended Common Lisp 1.5.6 (1/23/87 15:22) Copyright (c) 1986, Franz Inc., Alameda, Ca (defclass foo () ((var1 3) (var2 :allocation :dynamic :initform 5) (var3 :allocation :dynamic :initform 7)) (:accessor-prefix ||)(:constructor make-foo)) FOO (setq f1 (make-foo)) #S(FOO VAR1 3) (setq f2 (make-foo)) Error: Received signal number 10 (Bus error) [1] :zo Evaluation stack: ->(EXCL::READ-EVAL-PRINT-LOOP NIL "Received signal number 10 (Bus error) " ...) (ERROR "Received signal number ~s ~@[(~a)~]~%" 10 ...) (FUNCALL (LAMBDA # #)) (EXCL::%EVAL (MAKE-FOO)) (SETQ F2 (MAKE-FOO)) (EXCL::%EVAL (SETQ F2 #)) (EVAL (SETQ F2 #)) (EXCL::READ-EVAL-PRINT-LOOP NIL NIL ...) ... 1 more ... [1] :res :exit Process lisp finished  Received: from Xerox.COM (TCP 1200400040) by AI.AI.MIT.EDU 24 Mar 87 20:42:39 EST Received: from Semillon.ms by ArpaGateway.ms ; 24 MAR 87 17:30:37 PST Date: Tue, 24 Mar 87 17:26 PST From: Gregor.pa@Xerox.COM Subject: make-specializable To: Ricks%ic.Berkeley.edu@Berkeley.edu cc: CommonLoops.PA@Xerox.COM Message-ID: <870324172647.4.GREGOR@AVALON.isl.parc.xerox.com> Line-fold: no Your make specializable bug is fixed in the sources currently on parcvax.xerox.com. You should either FTP a new copy of methods.lisp or replace the definition of make-specializable with the code included at the end of this message. Once you do this, use (compile-pcl) to recompile. Anyone who uses make-specializable should make this change. (defun make-specializable (function-name &key (arglist nil arglistp)) (cond ((not (null arglistp))) ((not (fboundp function-name))) ((fboundp 'function-arglist) ;; function-arglist exists, get the arglist from it. (setq arglist (function-arglist function-name))) (t (error "The :arglist argument to make-specializable was not supplied~%~ and there is no version of FUNCTION-ARGLIST defined for this~%~ port of Portable CommonLoops.~%~ You must either define a version of FUNCTION-ARGLIST (which~%~ should be easy), and send it off to the Portable CommonLoops~%~ people or you should call make-specializable again with the~%~ :arglist keyword to specify the arglist."))) (let ((original (and (fboundp function-name) (symbol-function function-name))) (generic-function (make 'standard-generic-function :name function-name))) (setf (symbol-function function-name) generic-function) (when arglistp (setf (generic-function-pretty-arglist generic-function) arglist)) (when original (add-named-method function-name arglist () original)) generic-function)) -------  Received: from Xerox.COM (TCP 1200400040) by AI.AI.MIT.EDU 24 Mar 87 20:42:29 EST Received: from Cabernet.ms by ArpaGateway.ms ; 24 MAR 87 15:17:33 PST Return-Path: Received: from seismo.CSS.GOV by Xerox.COM ; 24 MAR 87 15:15:20 PST Received: from burdvax.UUCP by seismo.CSS.GOV (5.54/1.14) with UUCP id AA20139; Tue, 24 Mar 87 18:15:14 EST Received: by burdvax.PRC.Unisys.Com (5.54/4.7) id AA21208; Tue, 24 Mar 87 18:11:40 EST From: The devil himself Message-Id: <8703242311.AA21208@burdvax.PRC.Unisys.Com> Date: 24 Mar 87 23:11:38 GMT To: seismo!xerox.com!commonloops.pa@seismo.CSS.GOV Subject: Submission for sdc-commonloops Responding-System: burdvax.PRC.Unisys.COM Path: burdvax!daemon From: Gregor.pa@Xerox.COM Newsgroups: sdc.commonloops Subject: Re: problem with CLASS-INSTANCE-SLOTS Message-ID: <3102@burdvax.PRC.Unisys.COM> Date: 24 Mar 87 23:11:33 GMT Sender: daemon@burdvax.PRC.Unisys.COM Lines: 16 I understand your problem, but not why it is happening. The code which computes the order of slots for a class is real careful to make this slot appear in the right place. Of course it is possible that there is a bug in the 1/26 version. I understand that you don't want to convert wholesale to 3/19, but why don't you try using the new definition of collect-slotds from 3/19? That should fix your problem. In 3/19, I have no problems with your example. Note that real-class-instance-slots probably won't work for long its will just run into the same problems you ran into when you tried to make class-instance-slots a method. Let me know if this works.  Received: from Xerox.COM (TCP 1200400040) by AI.AI.MIT.EDU 24 Mar 87 18:00:47 EST Received: from Cabernet.ms by ArpaGateway.ms ; 24 MAR 87 11:49:07 PST Return-Path: Received: from seismo.CSS.GOV by Xerox.COM ; 24 MAR 87 11:43:35 PST Received: from burdvax.UUCP by seismo.CSS.GOV (5.54/1.14) with UUCP id AA14774; Tue, 24 Mar 87 14:43:25 EST Received: by burdvax.PRC.Unisys.Com (5.54/4.7) id AA17704; Tue, 24 Mar 87 14:40:54 EST From: The devil himself Message-Id: <8703241940.AA17704@burdvax.PRC.Unisys.Com> Date: 24 Mar 87 19:40:53 GMT To: seismo!xerox.com!commonloops.pa@seismo.CSS.GOV Subject: Submission for sdc-commonloops Responding-System: burdvax.PRC.Unisys.COM Path: burdvax!daemon From: The devil himself Newsgroups: sdc.commonloops Subject: Submission for sdc-commonloops Message-ID: <3100@burdvax.PRC.Unisys.COM> Date: 24 Mar 87 19:40:51 GMT Sender: daemon@burdvax.PRC.Unisys.COM Lines: 11 Path: burdvax!daemon From: Gregor.pa@Xerox.COM Newsgroups: sdc.commonloops Subject: Re: Add me to the list Message-ID: <3097@burdvax.PRC.Unisys.COM> Date: 24 Mar 87 19:26:46 GMT Sender: daemon@burdvax.PRC.Unisys.COM Lines: 2 OK, great, I have added commonloops@burdvax.prc.unisys.com to the CommonLoops@Xerox.com mailing list.  Received: from Xerox.COM (TCP 1200400040) by AI.AI.MIT.EDU 24 Mar 87 18:00:37 EST Received: from Cabernet.ms by ArpaGateway.ms ; 24 MAR 87 11:47:39 PST Return-Path: Received: from seismo.CSS.GOV by Xerox.COM ; 24 MAR 87 11:43:33 PST Received: from burdvax.UUCP by seismo.CSS.GOV (5.54/1.14) with UUCP id AA14770; Tue, 24 Mar 87 14:43:20 EST Received: by burdvax.PRC.Unisys.Com (5.54/4.7) id AA17692; Tue, 24 Mar 87 14:40:43 EST From: The devil himself Message-Id: <8703241940.AA17692@burdvax.PRC.Unisys.Com> Date: 24 Mar 87 19:40:42 GMT To: seismo!xerox.com!commonloops.pa@seismo.CSS.GOV Subject: Submission for sdc-commonloops Responding-System: burdvax.PRC.Unisys.COM Path: burdvax!daemon From: Gregor.pa@Xerox.COM Newsgroups: sdc.commonloops Subject: Re: Problem with the latest CommonLoops Message-ID: <3099@burdvax.PRC.Unisys.COM> Date: 24 Mar 87 19:40:41 GMT Sender: daemon@burdvax.PRC.Unisys.COM Lines: 13 When trying to compile excl-low.cl, it comes up with the following error message: Error: EXCL::FN_SYMDEF is not a known location specifier for setf. [1] For the time being, go to the file excl-low and comment out the definition of set-function-name. I will do a more elegant patch later and put it on parcvax. Anyone else who has this problem with ExCL and the new release of PCL should do the same. NOTE, don't do this unless you have this problem, people using the newest release of ExCL will not have this problem.  Received: from Xerox.COM (TCP 1200400040) by AI.AI.MIT.EDU 24 Mar 87 18:00:28 EST Received: from Cabernet.ms by ArpaGateway.ms ; 24 MAR 87 11:44:33 PST Date: 24 Mar 87 11:37 PST From: Gregor.pa@Xerox.COM Subject: Re: problem with CLASS-INSTANCE-SLOTS In-reply-to: Dawn MacLaughlin 's message of Tue, 24 Mar 87 11:29 EST To: dmaclaug@VAX.bbn.com cc: commonloops.pa@Xerox.COM, dmaclaughlin@VAX.bbn.com Message-ID: <870324-114433-1222@Xerox> I understand your problem, but not why it is happening. The code which computes the order of slots for a class is real careful to make this slot appear in the right place. Of course it is possible that there is a bug in the 1/26 version. I understand that you don't want to convert wholesale to 3/19, but why don't you try using the new definition of collect-slotds from 3/19? That should fix your problem. In 3/19, I have no problems with your example. Note that real-class-instance-slots probably won't work for long its will just run into the same problems you ran into when you tried to make class-instance-slots a method. Let me know if this works.  Received: from Xerox.COM (TCP 1200400040) by AI.AI.MIT.EDU 24 Mar 87 18:00:17 EST Received: from Cabernet.ms by ArpaGateway.ms ; 24 MAR 87 11:35:57 PST Return-Path: Received: from seismo.CSS.GOV by Xerox.COM ; 24 MAR 87 11:29:21 PST Received: from burdvax.UUCP by seismo.CSS.GOV (5.54/1.14) with UUCP id AB14462; Tue, 24 Mar 87 14:29:17 EST Received: by burdvax.PRC.Unisys.Com (5.54/4.7) id AA17502; Tue, 24 Mar 87 14:26:51 EST From: The devil himself Message-Id: <8703241926.AA17502@burdvax.PRC.Unisys.Com> Date: 24 Mar 87 19:26:49 GMT To: seismo!xerox.com!commonloops.pa@seismo.CSS.GOV Subject: Submission for sdc-commonloops Responding-System: burdvax.PRC.Unisys.COM Path: burdvax!daemon From: Gregor.pa@Xerox.COM Newsgroups: sdc.commonloops Subject: Re: Add me to the list Message-ID: <3097@burdvax.PRC.Unisys.COM> Date: 24 Mar 87 19:26:46 GMT Sender: daemon@burdvax.PRC.Unisys.COM Lines: 2 OK, great, I have added commonloops@burdvax.prc.unisys.com to the CommonLoops@Xerox.com mailing list.  Received: from Xerox.COM (TCP 1200400040) by AI.AI.MIT.EDU 24 Mar 87 18:00:05 EST Received: from Cabernet.ms by ArpaGateway.ms ; 24 MAR 87 11:32:58 PST Date: 24 Mar 87 11:26 PST From: Gregor.pa@Xerox.COM Subject: Re: Problem with the latest CommonLoops In-reply-to: liew@aramis.rutgers.edu (Liew)'s message of Mon, 23 Mar 87 23:40:56 EST To: liew@aramis.rutgers.edu cc: CommonLoops.PA@Xerox.COM Message-ID: <870324-113258-1207@Xerox> When trying to compile excl-low.cl, it comes up with the following error message: Error: EXCL::FN_SYMDEF is not a known location specifier for setf. [1] For the time being, go to the file excl-low and comment out the definition of set-function-name. I will do a more elegant patch later and put it on parcvax. Anyone else who has this problem with ExCL and the new release of PCL should do the same. NOTE, don't do this unless you have this problem, people using the newest release of ExCL will not have this problem.  Received: from Xerox.COM (TCP 1200400040) by AI.AI.MIT.EDU 24 Mar 87 13:27:11 EST Received: from Cabernet.ms by ArpaGateway.ms ; 24 MAR 87 08:29:16 PST Return-Path: <@CONGER.bbn.com:dmaclaug@VAX.bbn.com> Received: from CONGER.bbn.com by Xerox.COM ; 24 MAR 87 08:27:37 PST Received: from ALEWIFE.bbn.com by CONGER.bbn.com via CHAOS with CHAOS-MAIL id 14203; Tue 24-Mar-87 11:29:11-EST Date: Tue, 24 Mar 87 11:29 EST From: Dawn MacLaughlin Subject: problem with CLASS-INSTANCE-SLOTS To: commonloops.pa@Xerox.COM cc: dmaclaughlin@VAX.bbn.com Message-ID: <870324112915.1.DMACLAUGHLIN@ALEWIFE.bbn.com> There is a problem with the class-instance-slots and class-non-instance-slots functions. I have defined a new meta-class which has one extra slot in it (as shown below). This throws off the class-(non-)instance-slots functions so that they access the wrong fields in the structure. This is because these functions have the "position" of this slot wired into them--they return whatever is in the 7th and 8th positions. I read the note in braid.lisp about these functions, which implies that they have to be redefined to work correctly for my new meta-class. Is there a good way to make these functions general enough so that the numbers (7 and 8) are not wired in? I tried defining class-instance-slots as a method, which really messed things up. I came up with a kludge which works, but involves using a different name: REAL-CLASS-(NON-)INSTANCE-SLOTS. Note: we are using *pcl-system-date* = 1/26/87 on a Symbolics Lisp Machine. (While I'm at it, make-specializable doesn't work at all. I sent out a bug report some time ago. Will this be fixed in the new release?) (defclass PACKET-HANDLING-MIXIN () ((packets nil)) (:accessor-prefix nil)) (defclass NEW-META-CLASS (packet-handling-mixin class) ()) (defmethod check-super-metaclass-compatibility ((class NEW-META-CLASS) (super class)) (ignore class super) t) (defmethod check-super-metaclass-compatibility ((super class) (class NEW-META-CLASS)) (ignore class super) t) (defclass NEW-META-CLASS-CLASS () () (:metaclass new-metaclass))) (defmeth REAL-CLASS-INSTANCE-SLOTS (class) (get-slot class 'instance-slots)) (defmeth REAL-CLASS-NON-INSTANCE-SLOTS (class) (get-slot class 'non-instance-slots))  Received: from Xerox.COM (TCP 1200400040) by AI.AI.MIT.EDU 24 Mar 87 00:25:57 EST Received: from Cabernet.ms by ArpaGateway.ms ; 23 MAR 87 20:38:36 PST Return-Path: Received: from aramis.rutgers.edu ([128.6.5.58]) by Xerox.COM ; 23 MAR 87 20:37:07 PST Received: by aramis.rutgers.edu; Mon, 23 Mar 87 23:40:56 EST Date: Mon, 23 Mar 87 23:40:56 EST From: liew@aramis.rutgers.edu (Liew) Message-Id: <8703240440.AA17638@aramis.rutgers.edu> To: CommonLoops.PA@Xerox.COM Subject: Problem with the latest CommonLoops I just ftp'ed all the files from pub/pcl and encountered a problem when trying to compile pcl. For your information, I am running on a SUN 3/50 using Extended Common Lisp 1.3 from Franz. When trying to compile excl-low.cl, it comes up with the following error message: (pcl::compile-pcl) Loading binary of WALK... Loading binary of MACROS... Loading binary of LOW... Compiling EXCL-LOW... ; --- Compiling file /u1/liew/loops.d/pcl/excl-low.cl --- ; Compiling LOAD-TIME-EVAL ; Compiling SYMBOL-CACHE-NO ; Compiling OBJECT-CACHE-NO ; Compiling PRINTING-RANDOM-THING-INTERNAL ; Compiling SET-FUNCTION-NAME Error: EXCL::FN_SYMDEF is not a known location specifier for setf. [1] Any help is appreciated. Thank you. chun liew liew@aramis.rutgers.edu  Received: from Xerox.COM (TCP 1200400040) by AI.AI.MIT.EDU 23 Mar 87 19:57:41 EST Received: from Cabernet.ms by ArpaGateway.ms ; 23 MAR 87 16:10:19 PST Date: 23 Mar 87 15:14 PST From: Gregor.pa@Xerox.COM Subject: Re: that old dinner bell ringing In-reply-to: mbm@caf.MIT.EDU (Mike McIlrath)'s message of Sat, 21 Mar 87 19:47:03 EST To: mbm@caf.MIT.EDU cc: CommonLoops.pa@Xerox.COM Message-ID: <870323-161019-1107@Xerox> From: mbm@caf.MIT.EDU (Mike McIlrath) To: Gregor.pa Subject: Re: that old dinner bell ringing Actually, I'd be curious to know how you compiled this in excl. I tried and got as far as fsc-low, and then in compiling set-funcallable-instance-function, got EXCL::FN_LOCALS is not a know location specifier for setf. Any ideas? I am running the current Vax ExCL (1.5.vax.5) of 2/20/87. You should get a new copy of the file fsc-low.lisp from parcvax.xerox.com. Anyone else trying to use PCL in the 1.5 or older versions of ExCL should also get a copy of this file. People using other Lisp versions should not bother to get a new copy of fsc-low. I have updated the file /pub/pcl/tar/tarfile to include this new version of fsc-low.  Received: from Xerox.COM (TCP 1200400040) by AI.AI.MIT.EDU 23 Mar 87 17:29:34 EST Received: from Cabernet.ms by ArpaGateway.ms ; 23 MAR 87 13:28:18 PST Date: 23 Mar 87 13:25 PST From: Gregor.pa@Xerox.COM Subject: Re: new sources work in Vaxlisp In-reply-to: robbins%ramona.DEC@decwrl.DEC.COM's message of 23 Mar 1987 14:54 To: robbins%ramona.DEC@decwrl.DEC.COM cc: CommonLoops.pa@Xerox.COM Message-ID: <870323-132818-10085@Xerox> Date: 23 Mar 1987 14:54 From: robbins%ramona.DEC@decwrl.DEC.COM The file BOOT.LISP ends in the middle of an expression. Where is the rest of the file? No, actually the whole file is there. This problem is due to a bug in our FTP server which should be fixed soon. For convenience, I have created a new subdirectory /pub/pcl/tar. In that diretcory is a single file call tarfile which is a tafile of all the .lisp files in /pub/pcl. You may have better luck if you try FTP'ing that file. If not, just keep trying to get boot.lisp until you get the whole thing. Once you get all of all the files, if you still have problems bringing it up in Vaxlisp 2.1 please let me know.  Received: from Xerox.COM (TCP 1200400040) by AI.AI.MIT.EDU 22 Mar 87 23:51:37 EST Received: from Salvador.ms by ArpaGateway.ms ; 22 MAR 87 20:11:30 PST Return-Path: Received: from hplabs.HP.COM ([192.5.58.10]) by Xerox.COM ; 22 MAR 87 20:09:39 PST Received: from hplabsc by hplabs.HP.COM with TCP ; Sun, 22 Mar 87 20:08:55 pst Received: by hplabsc ; Sun, 22 Mar 87 20:10:16 pst Date: Sun, 22 Mar 87 20:10:16 pst From: Jim Kempf Message-Id: <8703230410.AA13557@hplabsc> To: common-lisp@sail.stanford.edu, commonloops.pa@Xerox.COM Subject: Re: CommonObjects on CommonLoops As several people have noticed, it is not possible to get to /ja/guest/kempf/public via anonymous ftp. I have set up the COOL distribution so that it is in /pub/cool, rather than /ja/guest/kempf/public. If anybody has taken the cool.tar file which was in /pub, it contains the cool distribution in U*NX tar format, but it was not properly made so there may be trouble un-taring it. In any event, I would suggest if you have trouble, that you simply get the new distribution. Again, there are two subdirectories under /pub/cool-cool and pcl, containing, respectively, the COOL release and the 2/24/87 PCL release. The directory /pub/cool itself contains a README file. Thanks for your patience and I'm sorry for the confusion. Let us know how you're doing. Jim Kempf cool@hplabs.hp.com  Received: from Xerox.COM (TCP 1200400040) by AI.AI.MIT.EDU 22 Mar 87 23:51:24 EST Received: from Salvador.ms by ArpaGateway.ms ; 22 MAR 87 19:47:29 PST Return-Path: Received: from ic.Berkeley.EDU ([128.32.132.1]) by Xerox.COM ; 22 MAR 87 19:45:45 PST Received: by ic.Berkeley.EDU (5.57/1.16) id AA02979; Sun, 22 Mar 87 19:45:15 PST Message-Id: <8703230345.AA02979@ic.Berkeley.EDU> To: Commonloops.pa@Xerox.COM Subject: problem with make-specializable Date: Sun, 22 Mar 87 19:45:14 -0800 From: ricks%ic.Berkeley.EDU@BERKELEY.EDU In the previous version of PCL (2/24/87, VAXLISP) the following worked: (use-package 'pcl) (defun bob (x) x) (pcl::make-specializable 'bob) (defmethod bob ((x fixnum)) (+ x 10)) (bob 3) 13 (bob 'hi) hi In the current version (3/19/87 prime, VAXLISP), (bob 3) works, but (bob 'hi) gives the 'no matching method' error. Is there a new way to do specialization of an existing function? How do I keep the default function? I noticed that the following section of code in 'make-specializable' is commented out (methods.lsp): ; (when (fboundp function-name) ;*** Put this back ; (add-named-method ;(class-prototype (class-named 'discriminator)) ; ;(class-prototype (class-named 'method)) ; function-name ; arglist ; () ; (symbol-function function-name))) Thanks, Rick Spickelmier UC Berkeley  Received: from Xerox.COM (TCP 1200400040) by AI.AI.MIT.EDU 22 Mar 87 21:11:54 EST Received: from Salvador.ms by ArpaGateway.ms ; 22 MAR 87 17:09:42 PST Return-Path: Received: from CS.COLUMBIA.EDU by Xerox.COM ; 22 MAR 87 17:08:09 PST Date: Sun, 22 Mar 87 20:07:41 EST From: Michael van Biema Subject: New Flavors in Commonloops? To: commonloops.pa@Xerox.COM Message-ID: <12288536608.15.MICHAEL@CS.COLUMBIA.EDU> I seem to remember reading that somebody implemented this. Is it available anywhere? Michael -------  Received: from Xerox.COM (TCP 1200400040) by AI.AI.MIT.EDU 22 Mar 87 12:36:58 EST Received: from Salvador.ms by ArpaGateway.ms ; 22 MAR 87 07:59:47 PST Return-Path: <@Cs.Ucl.AC.UK,@csvax.aberdeen.ac.uk:messick@computing-science.aberdeen.ac.uk> Received: from Cs.Ucl.AC.UK (TUNNEL.CS.UCL.AC.UK) by Xerox.COM ; 22 MAR 87 07:57:54 PST Received: from csvax.aberdeen.ac.uk by mv1.Cs.Ucl.AC.UK via Janet with NIFTP id aa04499; 22 Mar 87 15:56 WET Date: Sun, 22 Mar 87 15:52:31 GMT From: Steve Messick To: "commonloops.pa" <@Cs.Ucl.AC.UK:commonloops.pa@xerox.com> Subject: request for addition and info Cc: messick%server.aberdeen.ac.uk@Cs.Ucl.AC.UK Message-ID: <870322-075947-9096@Xerox> Please add messick%csvax.aberdeen.ac.uk@CS.UCL.AC.UK to the commonloops list. Also, how may I obtain common loops? Thanks! --steve  Received: from Xerox.COM (TCP 1200400040) by AI.AI.MIT.EDU 22 Mar 87 01:01:56 EST Received: from Semillon.ms by ArpaGateway.ms ; 21 MAR 87 21:19:47 PST Return-Path: Received: from hplabs.HP.COM ([192.5.58.10]) by Xerox.COM ; 21 MAR 87 21:18:07 PST Received: from hplabsc by hplabs.HP.COM with TCP ; Sat, 21 Mar 87 21:17:27 pst Received: by hplabsc ; Sat, 21 Mar 87 21:19:15 pst Date: Sat, 21 Mar 87 21:19:15 pst From: Jim Kempf Message-Id: <8703220519.AA24502@hplabsc> To: common-lisp@sail.stanford.edu, commonloops.pa@Xerox.COM Subject: CommonObjects on CommonLoops ******* Announcing CommonObjects on CommonLoops ******* A portable implementation of HP's CommonObjects object-oriented programming language is now available. More information on CommonObjects semantics can be found in the article "CommonObjects: An Overview" by Alan Snyder in the October, 1986 issue of SIGPLAN Notices, or by mailing a request for the technical report ATC-85-1 to mingus@hplabs.hp.com CommonObjects on CommonLoops (COOL) uses the metaclass kernel of Portable CommonLoops (PCL) to implement 95% of CommonObjects functionality. Both COOL and PCL run embedded in Common Lisp. COOL is freely distributable and available via anonymous FTP from ingres.berkeley.edu. It is located in the directory /ja/guest/kempf/public/cool. Tests of COOL in HP Common Lisp (where it was developed) and Kyoto Common Lisp have been made, and it is designed to be as portable as PCL. Currently, COOL runs on the 2/24/87 release of PCL. In order to avoid software tracking problems, the release of PCL in which COOL runs will be distributed along with COOL. In the cool directory are two subdirectories, one containing the PCL source (pcl) and one containing the COOL source (cool). The (upper) cool directory also contains a README file describing how to build and use the system. The cool/cool directory, in addition to the COOL source, contains a series of regression tests and profiling tests. Please report any problems with COOL to cool@hplabs.hp.com. We are interested in any portability problems but cannot attempt to fix them unless we can either get access to a running system where the problem is occuring or get enough information that we can help a knowledgable Common Lisp programmer fix the problem.  Received: from Xerox.COM (TCP 1200400040) by AI.AI.MIT.EDU 21 Mar 87 20:06:41 EST Received: from Cabernet.ms by ArpaGateway.ms ; 21 MAR 87 16:28:22 PST Date: Sat, 21 Mar 87 16:25 PST From: Gregor.pa@Xerox.COM Subject: new sources work in Vaxlisp To: CommonLoops.pa@Xerox.COM Message-ID: <870321162556.0.GREGOR@AVALON.isl.parc.xerox.com> Line-fold: no The version of PCL which is NOW on parcvax.xerox.com works in Vaxlisp 2.0. This version has *pcl-system-date* "3/19/87 prime". I know today is the 21st, but thats not really relevant you see. Anyone who FTP'd themselves a copy of PCL in the last 2 hours should get a copy of this one instead since it is slightly different inside. -------  Received: from Xerox.COM (TCP 1200400040) by AI.AI.MIT.EDU 21 Mar 87 18:58:33 EST Received: from Semillon.ms by ArpaGateway.ms ; 21 MAR 87 14:07:11 PST Date: Sat, 21 Mar 87 14:05 PST From: Gregor.pa@Xerox.COM Subject: documentation To: CommonLoops.pa@Xerox.COM Message-ID: <870321140502.9.GREGOR@AVALON.isl.parc.xerox.com> Line-fold: no At some point next week, we will be putting DVI files of the current draft of the Common Lisp Object System (CLOS) Specification on parcvax.xerox.com. In the next couple of months PCL will evolve to conform to the CLOS specification. The target is to make PCL be an implementation of that specification. Since it does not conform to that specification now, we will be writing up some notes which try to explain the ways in which it differs from that specification. As time goes by, those notes should get shorter and shorter, and eventually disappear. -------  Received: from Xerox.COM (TCP 1200400040) by AI.AI.MIT.EDU 21 Mar 87 18:58:24 EST Received: from Semillon.ms by ArpaGateway.ms ; 21 MAR 87 14:02:10 PST Date: Sat, 21 Mar 87 13:58 PST From: Gregor.pa@Xerox.COM Subject: that old dinner bell ringing To: CommonLoops.pa@Xerox.COM Message-ID: <870321135852.8.GREGOR@AVALON.isl.parc.xerox.com> Line-fold: no There is a new release of PCL on parcvax.xerox.com. Sources and notes are in the /pub/pcl directory. There are binaries in the /pub/pcl/3600 and /pub/pcl/xerox directories. These notes correspond to *pcl-system-date* 3/19/87. This release runs in: ExCL Lucid Symbolics Common Lisp (Genera) Xerox Common Lisp (Lyric Release) CMU Lisp (nee Spice), KCL and VaxLisp should be working soon, I will announce another release at that time. I figured it was better to get some people beating on it as soon as possibl. Xerox Lisp users should FTP all the source files from /pub/pcl/ as well as all the dfasl files from /pub/pcl/xerox/. Included in the xerox specific directory is a file called PCL-ENV, which provides some simple environment support for using PCL in Xerox Lisp. Following is a description of some of the things that are different in this release of PCL. This list isn't in any particular order. There are a number of incompatible changes in this release, please read the whole thing carefully. As usual, please enjoy, and send bug-reports, questions etc. to CommonLoops@Xerox.com. *** The single most significant change is that discriminator-objects with corresponding discriminating functions have been replaced by generic function objects. What does this mean?? Well, in previous releases of PCL, if you did: (defmethod foo ((x class)) 'class) (defmethod foo ((x method)) 'method) Then (discriminator-named 'foo) returned a discriminator object which had both of these methods defined on it. (symbol-function 'foo) returned a discriminating function, which (discriminator-named 'foo) had put in foo's function cell. In this release of PCL, the above defmethod's put a generic-function object in foo's function cell. This generic-function object is a combination of the discriminator object and discriminating function of the previous releases of PCL. This generic-function object is funcallable, funcalling it causes the appropriate method to be looked up and called. This generic function object has accessors which return the methods defined on the generic function. This generic function object is mutable. It is possible to add and remove methods from it. (defmethod foo ((x class)) 'class) (defmethod foo ((x method)) 'method) (generic-function-methods #'foo) (# #) (foo (make 'class)) ==> 'class (foo (make 'method)) ==> 'method (remove-method #'foo (car (generic-function-methods #'foo))) (foo (make 'class)) ==> 'class (foo (make 'method)) ==> no matching method error Note that as part of this change, the name of any function, generic function or class which included the string "DISCRIMINATOR" has changed. The name changes that happened were: The class essential-discriminator was renamed to generic-function, The class basic-discriminator and the class discrimiantor were combined and renamed to standard-generic-function. If you went through your code and made the following name changes, you would probably win, (this is what I did to PCL and it worked). essential-discriminator ==> generic-function basic-discriminator ==> standard-generic-function discriminator (when it appears as a specializer) ==> standard-generic-function discriminator (when it appears as part of a variable name or something) ==> generic-function *** In most Lisp implementations, method lookup is at least twice as fast as it was in the previous release. *** The compiler isn't called when PCL is loaded anymore. In a future release, the compiler will also not be called when any other method definitions are loaded. This is part of an effort to get PCL to a state where the compiler will never be needed when compiled files are loaded. *** PCL now has a mechanism for naming the generic-function's and method functions defined by defmethod. This means that in ports of PCL which take advantage of this mechanism, you will see useful function names in the debugger rather than the useless gensym names that have been in the past few releases. *** Compiled files containing defmethod forms should be smaller and load faster. *** Many of the files in the system have been renamed. More files will be renamed in upcoming releases. *** An important part of the bootstrapping code has been re-written. The remainder of this code (the BRAID1 and BRAID2 files) will be re-written sometime soon. The changes made to bootstrapping in this release were done to make early methods more understandable, and as part of implementing generic function objects. Also, most users should find that PCL loads in less time than it did before. The changes which will be made to bootstrapping in a future release will make understanding the "Braid" stuff easier, and will make it possible to implement slot-description objects as described in the CURRENT DRAFT of the Common Lisp Object System Chapter 3. *** The defsys file has been re-written AGAIN. This shouldn't affect users since there are still the old familiar variables *pcl-pathname-defaults* and *pathname-extensions*. *** The specialized foo-notes files are all gone. Most of them were hopelessly out of date, and installing pcl is now the same operation for any Lisp. In particular, note that in Vaxlisp, it is no longer necessary to push lisp:vaxlisp on the *features* list. -------  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 16 Mar 87 14:44:11 EST Received: from HPLABS.HP.COM by SAIL.STANFORD.EDU with TCP; 16 Mar 87 11:32:07 PST Received: from hplabsc by hplabs.HP.COM with TCP ; Mon, 16 Mar 87 11:31:48 pst Received: by hplabsc ; Mon, 16 Mar 87 11:33:32 pst Date: Mon, 16 Mar 87 11:33:32 pst From: Jim Kempf Message-Id: <8703161933.AA12626@hplabsc> To: Masinter.pa@Xerox.COM Subject: Re: is of type... Cc: common-lisp-object-system@sail.stanford.edu Masinter writes: >Its pretty clear that "A is of type B" is defined to mean that A >can be an instance of some sub-type of B. You assert this is false... After consulting my dog-eared copy of CLtL, it seems as if this is the sense in which "is of type" is used in CLtL, and thus there is no ambiguity between Chapters 2 and 4 and Section 9.2 on DECLARE and 9.3 on THE. I think the fundamental problem here is that it is not possible to have instances of types in Common Lisp which are more general (correct me if I'm wrong), with perhaps the exception of DEFSTRUCTS. For example, it is not possible to have an instance of INTEGER which is not either a FIXNUM or a BIGNUM. With DEFSTRUCTS, it is possible to have an instance of a type A which is a supertype of type B, so DECLAREing a variable to be of type A does not preclude B , and thus there is limited potential for compilation optimization. In stock Common Lisp, however, this probably isn't a problem, since passing a STRUCT to a function by reference is probably about the best you can do. In CLOS, however, it is a problem, since the application developer might want to optimize out messaging via a declaration, if the compiler writer and the language specification have provided that option. jak  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 16 Mar 87 04:50:24 EST Received: from HPLABS.HP.COM by SAIL.STANFORD.EDU with TCP; 16 Mar 87 01:44:04 PST Received: from hplabsc by hplabs.HP.COM with TCP ; Fri, 13 Mar 87 10:27:16 pst Received: by hplabsc ; Fri, 13 Mar 87 10:27:19 pst Date: Fri, 13 Mar 87 10:27:19 pst From: Jim Kempf Message-Id: <8703131827.AA10539@hplabsc> To: common-lisp-object-system@sail.stanford.edu Subject: Re: Moon's Comments > > and one for > specifying that a variable name can be bound to an > object of a particular class *or a subclass*, since > the restriction to a single class is covered by TYPE. > >I think you're mistaken here. (THE INTEGER x) does not >imply that x is not a FIXNUM, and similarly (THE C x) does >not imply that (CLASS-OF x) is not a subclass of C. I don't >think Common Lisp has any way to declare that an object is of >a given type, and no more-specific type. I was going on the basis of the statement on the bottom of pg. 161, top of pg. 162 of CLtL: "In effect, this declares that the user undertakes to guarantee that the values of the form will always be of the specified type." in the description of THE semantics. A previous disclaimer, however, states that it is up to the implementation whether this is checked or not. In addition, on pg. 158, the description of the TYPE DECLARE specifier: "In particular, values assigned to variables by SETQ, as well as the initial values of the variables, must be of the specified type." implies that subtyping is not allowed. My recollection of the typing chapter is that subtyping is allowed, however, so the situation is ambiguous. jak  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 15 Mar 87 14:02:36 EST Received: from HPLABS.HP.COM by SAIL.STANFORD.EDU with TCP; 15 Mar 87 10:54:41 PST Received: from hplabsc by hplabs.HP.COM with TCP ; Sun, 15 Mar 87 10:54:56 pst Received: by hplabsc ; Sun, 15 Mar 87 10:56:56 pst Date: Sun, 15 Mar 87 10:56:56 pst From: Jim Kempf Message-Id: <8703151856.AA01005@hplabsc> To: RPG@SAIL.STANFORD.EDU, common-lisp-object-system@SAIL.STANFORD.EDU Subject: Re: Inheritance of Slots I'll add my vote to flushing :dynamic. jak  Received: from Xerox.COM (TCP 1200400040) by AI.AI.MIT.EDU 13 Mar 87 15:08:59 EST Received: from Salvador.ms by ArpaGateway.ms ; 13 MAR 87 09:37:14 PST Date: 13 Mar 87 09:35 PST From: Gregor.pa@Xerox.COM Subject: changes to meta-objects To: CommonLoops.pa@Xerox.COM Reply-To: Gregor.pa@Xerox.COM Message-ID: <870313-093714-148@Xerox> In order to make PCL conform to the Common Lisp Object System draft specification, the next few releases of PCL will include incompatible changes to the names of the meta-object classes and some of the generic-functions in the meta-object protocol. As an example, in the next release of PCL, the name of every generic-function and class which included the string "DISCRIMINATOR" will be different. In order to help me understand how I can help you make this transition less difficult, I would like to ask people who make use of meta-objects in their code to send me a message. In the message, please tell me what special kinds of meta-objects you define (classes methods discriminators). What generic-functions in the existing protocol you define methods on etc. If possible, just send the part of your code that defines your new meta-object class and the methods on it. Thanks Gregor  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 13 Mar 87 02:00:15 EST Date: 12 Mar 87 2232 PST From: Dick Gabriel Subject: Here We Go Again To: common-lisp-object-system@SAIL.STANFORD.EDU I know the disclaimer is silly, but I don't like to put something in the hands of the masses that looks like an official document written by us that has not been checked by us. Someday someone will forget this was handed out to help with the discussion and think it's the real thing. That's why the metaobject protocol chapter had the same disclaimer. I'll remove the authors' names, but leave the disclaimer. Moon writes: ``In the correction to 2-34 second paragraph, "parameter" was inadvertently changed to "argument". It should refer to "names of required parameters."'' I see now that Steele uses the term ``required parameter,'' which we thought was inconsistent with usage (though we flubbed the rewording anyhow). Moon writes: ``In the first bullet on page 7, part of the sentence was lost. According to the order of what? I don't know how to say it grammatically, but it's the order of the classes that define the slot specifiers.'' Hm. I thought the ellided material was sufficiently implied. We'll put it back. Note, though, I think this section needs more work - we were too tired yesterday to do it ourselves. -rpg-  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 13 Mar 87 00:34:07 EST Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 12 Mar 87 21:24:51 PST Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 92335; Fri 13-Mar-87 00:24:22 EST Date: Fri, 13 Mar 87 00:24 EST From: David A. Moon Subject: Errata and Glossary To: common-lisp-object-system@SAIL.STANFORD.EDU In-Reply-To: The message of 12 Mar 87 12:11 EST from Dick Gabriel Message-ID: <870313002424.4.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: 12 Mar 87 0911 PST From: Dick Gabriel We have formatted and test-printed the errata and glossary chapters. Linda will place the text for these two chapters on SAIL today for your approval before reproduction. Not having heard further from Dick or Linda, I assume the versions of glossa.dvi dated 3/12/87 14:33 and errata.dvi dated 3/12/87 13:36 on [cls,lsp] are the right ones. I printed these out and looked them over. The big disclaimer on the front of the glossary looks rather silly, since virtually all of the text was taken verbatim from the main document. Also I had little to do with writing this except insofar as I wrote text in the main document that was borrowed, so putting my name on it is silly. If it's all the same to you, I would prefer to delete the entire first page. The rest of it looks okay, if a bit long-winded. On p.6, I don't think the definition of "slot description" agrees with the meta-object chapter, perhaps that glossary entry should just be deleted. In the Corrections and Amendments: In the correction to 2-34 second paragraph, "parameter" was inadvertently changed to "argument". It should refer to "names of required parameters." In the first bullet on page 7, part of the sentence was lost. According to the order of what? I don't know how to say it grammatically, but it's the order of the classes that define the slot specifiers. Otherwise the changes from my version are improvements, and I didn't notice any old errors while proofreading (although I may have read this too many times by now to be an effective proofreader of it).  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 12 Mar 87 18:03:39 EST Date: 12 Mar 87 1448 PST From: Linda DeMichiel Subject: errata and glossary files To: common-lisp-object-system@SAIL.STANFORD.EDU The errata and glossary tex and dvi files are now on [CLS,LSP]. In order to allow time for photocopying tomorrow, I would like to get all requests for last-minute changes by noon. NOTE: there were no changes made to the glossary that Sonya provided. lgd  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 12 Mar 87 16:35:28 EST Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 12 Mar 87 13:25:29 PST Received: from JUNCO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 91956; Thu 12-Mar-87 16:25:19 EST Date: Thu, 12 Mar 87 16:25 EST From: Sonya E. Keene Subject: Errata and Glossary To: RPG@SAIL.STANFORD.EDU cc: common-lisp-object-system@SAIL.STANFORD.EDU In-Reply-To: The message of 12 Mar 87 12:11 EST from Dick Gabriel Message-ID: <870312162513.9.SKEENE@JUNCO.SCRC.Symbolics.COM> Date: 12 Mar 87 0911 PST From: Dick Gabriel We have formatted and test-printed the errata and glossary chapters. The glossary was rendered into accurate TEX, but we didn't proofread it at all. Thank you. Even if there are typos in it, having a Glossary should be better than not having one. [text deleted] Linda will place the text for these two chapters on SAIL today for your approval before reproduction. The new Glossary isn't on SAIL yet, so I wasn't able to check it today.  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 12 Mar 87 15:23:52 EST Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 12 Mar 87 12:17:30 PST Received: from relay2.cs.net by RELAY.CS.NET id ac12427; 12 Mar 87 14:53 EST Received: from ti-csl by csnet-relay.csnet id af03031; 12 Mar 87 14:48 EST Received: from Jenner (jenner.ARPA) by tilde id AA26313; Thu, 12 Mar 87 12:30:54 cst Message-Id: <2751561175-1124785@Jenner> Date: Thu, 12 Mar 87 12:32:55 CST From: Patrick H Dussud To: Dick Gabriel Cc: common-lisp-object-system@SAIL.STANFORD.EDU Subject: Re: Meeting In-Reply-To: Msg of 09 Mar 87 1122 PST from Dick Gabriel Is 9am ok with everyone? Sure, Patrick.  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 12 Mar 87 12:32:40 EST Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 12 Mar 87 09:23:54 PST Received: from Cabernet.ms by ArpaGateway.ms ; 11 MAR 87 13:10:50 PST Date: 11 Mar 87 13:10 PST Sender: Bobrow.pa@Xerox.COM From: Danny Bobrow Subject: Re: Inheritance of Slots In-reply-to: Dick Gabriel 's message of 11 Mar 87 09:13 PST To: RPG@SAIL.STANFORD.EDU cc: common-lisp-object-system@SAIL.STANFORD.EDU Message-ID: <870311-131050-1245@Xerox> I think we should leave in the :type descriptor. Since none of you care about it, let be commune with my compiler and propose a reasonable thing, which will probably be a variant of what is currently in the spcification. I am happy to leave it in if you like it. I thought I had been the only champion, and I have become decidedly neutral. Danny, we cannot relegate all matters to the metaobject protocol, though we could. I agree. Staticizing: Kempf rightly points out that this is a concern. I thought I had a scheme to do it similar to the scheme for staticizing function calls, but I'm now not entirely sure of it. I hope to rethink it today, but for the moment, Kempf, suffice it to say I am sympathetic to your concerns. What is your belief about how sticizing ought to be communicated -- and what price should one be willing to pay for changing one's mind. danny  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 12 Mar 87 12:26:57 EST Date: 12 Mar 87 0911 PST From: Dick Gabriel Subject: Errata and Glossary To: common-lisp-object-system@SAIL.STANFORD.EDU We have formatted and test-printed the errata and glossary chapters. The glossary was rendered into accurate TEX, but we didn't proofread it at all. We added a meta-object-protocol-like disclaimer to it and included an attribution to Moon and Sonya. I'm not sure Linda even read it - I didn't. The errata was formatted as a corrections and amendments chapter. True errata (corrections to erroneous facts) were separated out. Alterations to the text that did not change the meaning were placed in the amendments section. Also placed there were the wishlist of clarifications such as the new ``pages'' about TYPEP, SUBTYPEP, et al. The draft of the ``Inheritance...'' section was separated out at the end of the amendments. I believe that the wording requires some minor improvements to eliminate the last of the confusions (such as what happens when a slot description has a only a :reader option specified), and so it was labeled a ``draft.'' We removed most of the extraneous comments about the errata when the comments didn't add to the content; this was done to to make the corrections and amendments chapter read less like the Common Lisp mailing list. We made some minor wording changes to the corrections and amendments to bring them more in line with the document. Grammatical and punctuation errors were corrected. Linda will place the text for these two chapters on SAIL today for your approval before reproduction. -rpg-  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 12 Mar 87 03:12:41 EST Received: from HPLABS.HP.COM by SAIL.STANFORD.EDU with TCP; 12 Mar 87 00:02:23 PST Received: from hplabsc by hplabs.HP.COM with TCP ; Wed, 11 Mar 87 15:57:43 pst Received: by hplabsc ; Wed, 11 Mar 87 15:45:54 pst Date: Wed, 11 Mar 87 15:45:54 pst From: Jim Kempf Message-Id: <8703112345.AA10871@hplabsc> To: common-lisp-object-system@sail.stanford.edu Subject: Re: Gabriel's Comments Some further comments on class changing and staticizing. > With regard to class redefinition, lazy update would certainly > get rid of having to keep pointers around in classes, but would > introduce an extra operation during method dispatch, slot access, > or whatever operation was chosen to do the update. Since method > dispatch is 100% overhead as far as the applications programmer is > concerned, the question is whether the added flexibility of having > the class update automatically is worth the extra time spent > checking during method dispatch. Similarly with slot access. > > Note that inserting update into dispatch could also interfere > with staticizing a class. Suppose you have finished developing a > class and now want to staticize it. If method dispatches must check > whether instances need to be changed, staticization needs not only > to affect classes but also methods dispatching on the classes, > since the check for changes in the class must be removed from the > dispatch. > >The issue you bring up here can be characterized in terms of a tradeoff >between a good development environment and one fully optimized for >speed. I think the revelent word here is "environment." How much of the change-class functionality should be part of the language definition and how much a part of the environment? > I assume that when you talk of "staticizing a class" you really >mean "staticizing a set of classes and generic functions which apply >only to those classes". And that the former means that you expect not >to build any subclasses of the staticized classes (or at least have them >staticized immediately). Not necessarily. With multimethods, the developer may have some methods which discriminate on a staticized class through any number or order of arguments. Building a staticized class may not mean that you don't want to subclass; in fact, staticized classes might be build into class libraries for incorporation into different applications, with developers specializing them for particular purposes. > The purpose of the meta-object protocol in >part is to allow you to change the implementation of a set of classes by >defining the implementation structure, and optimizations of slot access >and method lookup. For classes of such metaclasses, neither >CHANGE-CLASS nor instance updating (CLASS REDEFINITION) need work. >These are only guaranteed to work for STANDARD-CLASS. Perhaps using the metaobject protocol to define a STATIC-CLASS metaclass is one solution. This would mean STANDARD-CLASS leans heavily towards a prototypying vehicle, however. How STANDARD-CLASS fits into the Common Lisp DECLARE mechanism (if at all) still needs to be resolved. > In addition, the question of whether changing a class > definition and having instances still be EQ is consistent with > Common Lisp's EQ semantics needs to be resolved. >It is the same semantics as EQ when a list structure has been RPLAC'd. >EQ implies a continuity of history and coreference. > That is one way to look at it. Considering the fact that CLtL makes practically no guarantees about what is EQ, it may leave a big hole open to implementors. As an example, consider the case with vectors which are fasled. I've worked with two CL implementations which take completely opposite approaches. In one, a vector which is inserted into two places into code that is compiled will later be EQ when the code is loaded. In the other, this isn't the case. Integers don't necessarily have to be EQ in CL (and, in fact, aren't in one implementation). I don't want to get into a long, philisophical discussion about EQness, but just want to point out that unless we are very clear about this and about how CLOS fits in with Common Lisp, we may end up with a certain amount of implementation chaos. Jim Kempf kempf@hplabs.hp.com  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 12 Mar 87 02:43:54 EST Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 11 Mar 87 23:27:46 PST Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 91196; Wed 11-Mar-87 21:15:48 EST Date: Wed, 11 Mar 87 21:15 EST From: David A. Moon Subject: Comments on 87-002, Chapter 1 To: Jim Kempf cc: common-lisp-object-system@sail.stanford.edu In-Reply-To: <8702231935.AA19678@hplabsc> Message-ID: <870311211535.1.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Mon, 23 Feb 87 11:35:56 pst From: Jim Kempf C) INTERACTION BETWEEN CLOS AND CL `DECLARE' AND `THE' There is no mention in the document of how the CLOS will interact with CL DECLARE and THE. The requirement that parameter specifiers be type specifiers (pg. 1-19, paragraph 6) means that TYPEP must do the right thing when given an instance object and a valid class name (and presumably TYPEOF must return the class name as well?) but does that mean I can say: (DECLARE (TYPE TEXT-BUFFER X)) and: (THE TEXT-BUFFER X) I think that was the intention. We should say it explicitly so there is no possibility of misinterpretation. CLtL is vague on what happens if I try to bind X to something not of TYPE TEXT-BUFFER and I have it so DECLAREd (see pg. 158) but more explicit for THE (pg. 161). And what happens if I have two TEXT-BUFFER classes, one whose metaclass is the default and one with metaclass COMMON-OBJECTS-CLASS? There can only be one class with a given name. Seems to me an additional set of declarations are needed, one, perhaps, restricting the metaclass Could this be done by making all classes in that metaclass (all instances of that metaclass) have a particular class as a superclass? For instance, it has been proposed from time to time that every standard class should have as a superclass a class called STANDARD-OBJECT. Thus (THE STANDARD-OBJECT x) would declare that x is an object with STANDARD-CLASS, or a subclass of STANDARD-CLASS, as its metaclass. and one for specifying that a variable name can be bound to an object of a particular class *or a subclass*, since the restriction to a single class is covered by TYPE. I think you're mistaken here. (THE INTEGER x) does not imply that x is not a FIXNUM, and similarly (THE C x) does not imply that (CLASS-OF x) is not a subclass of C. I don't think Common Lisp has any way to declare that an object is of a given type, and no more-specific type. This would allow implementations to optimize method lookup away at compile time to varying degrees, potentially completely for a TYPE declaration, and partially for subclass and metaclass declarations. So far the standard proposal hasn't examined the issues involved in early binding of classes and compiling-away of these types of decisions. I think we should be completely open to a proposal here. I don't think that a late-bound implementation is going to be so slow as to demand this type of optimization to get anything done, but of course the amount of speedup available depends on the machine.  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 12 Mar 87 02:42:30 EST Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 11 Mar 87 23:25:59 PST Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 91182; Wed 11-Mar-87 20:52:15 EST Date: Wed, 11 Mar 87 20:52 EST From: David A. Moon Subject: Re: Gabriel's Comments To: Jim Kempf cc: common-lisp-object-system@sail.stanford.edu In-Reply-To: <8703101731.AA00849@hplabsc> Message-ID: <870311205207.9.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Tue, 10 Mar 87 09:31:52 pst From: Jim Kempf .... CLASS REDEFINITION With regard to class redefinition, lazy update would certainly get rid of having to keep pointers around in classes, but would introduce an extra operation during method dispatch, slot access, or whatever operation was chosen to do the update. Since method dispatch is 100% overhead as far as the applications programmer is concerned, the question is whether the added flexibility of having the class update automatically is worth the extra time spent checking during method dispatch. Similarly with slot access. Method dispatch isn't slowed down, since you simply make there be no methods applicable to obsolete instances, other than a default method that updates the instance and tries again. This works well in New Flavors and I believe has been used in other object systems as well. Slot access by calling an accessor generic function isn't slowed down because that goes through method dispatch. Slot access by calling the SLOT-VALUE function is slowed down, but probably infinitesimally compared to the cost of looking up the name of the slot in a table to get the position of the slot. Slot access by special implementation-dependent compiler-optimized technique is defined to prefer speed over the ability to change the class at any instant; see the mention of semantic difficulties on page 2-9. (There used to be a more explicit discussion here. Where did it go?) It's probably safe to say that there are a number of things in this proposal that seem at first glance to be inefficient, but actually are amenable to clever implementation techniques. Someone should publish a paper outlining those techniques so all implementors concerned with maximizing efficiency can use them. Note that inserting update into dispatch could also interfere with staticizing a class. I suspect that everyone means something slightly different by the term "staticizing a class." But whatever it means, surely it could be defined to rule out the ability to use change-class on instances of that class. Problems with WITH-SLOTS and with inadvertent trashing of important classes ala` the example with TEXT-BUFFER remain to be solved. I assume that was the following, from your 23 February message: 3) What happens to methods written on the old class? Do they stop working? Only if they depend on an aspect of the class that is no longer true. Note that there isn't really "an old class" and "a new class"; there is only one class. Redefining a class updates the existing object rather than creating a new object. What if the methods contain a WITH-SLOTS and some of the slots accessed within the scope of the WITH-SLOTS disappear? The semantics of WITH-SLOTS is defined in terms of calling accessor generic functions (and hence calling accessor methods) and SLOT-VALUE. So either you get a no-applicable-method error from the accessor generic function or SLOT-VALUE signals a no-such-slot error. Automatic instance updating would limit the amount of optimization that could be done during a WITH-SLOTS expansion, since changing the number of slots could invalidate any attempts to directly access the slot values (like, for example, trying to get rid of the double indirect referencing mentioned above). Perhaps my earlier answer to this got lost. Double indirection is not the only possible implementation technique. Also the possibilities for optimization are enhanced by the "semantic difficulties" note mentioned above, which essentially says you can't change the class while a method is executing (it isn't quite that strong). Also in a multiple inheritance system, doing the optimization I think you are thinking of (compiling positions of slots directly into compiled methods) requires some kind of restriction, possibly "staticizing the class", and in this case either changing the class would be forbidden or (as in New Flavors with the :ordered-instance-variables option) changing the class would be permitted but the system would enforce a restriction that those slots could not move. What about accessor functions? Are they undefined? Redefined to give an error? See the first paragraph on p. 1-11. It's a pity we don't have a more tutorial-style document, in which answers to questions like this would be easier to find. The accessor methods go away, the accessor generic functions remain defined of course, since other classes might also have methods for them. I'm not sure if we said anywhere what happens when you call a generic function and there is no applicable method; I think it ought to signal an error. 4) Automatic instance updating, in and of itself, could have potentially serious side effects in every day use. I don't see how the scenario you gave (redefining a class that the programming environment depends on, and putting a bug into it) is any different from redefining a function that the programming environment depends on, and putting a bug into it. An extra powerful programming environment might have ways to defend itself against both of these problems, but I don't think any special language features are called for. In addition, the question of whether changing a class definition and having instances still be EQ is consistent with Common Lisp's EQ semantics needs to be resolved. True. I've been collecting a list of issues like this, and this is on it.  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 12 Mar 87 01:17:28 EST Received: from HPLABS.HP.COM by SAIL.STANFORD.EDU with TCP; 11 Mar 87 22:03:55 PST Received: from hplabsc by hplabs.HP.COM with TCP ; Wed, 11 Mar 87 16:26:05 pst Received: by hplabsc ; Wed, 11 Mar 87 16:14:11 pst Date: Wed, 11 Mar 87 16:14:11 pst From: Jim Kempf Message-Id: <8703120014.AA11352@hplabsc> To: RPG@SAIL.STANFORD.EDU, common-lisp-object-system@SAIL.STANFORD.EDU Subject: Re: Staticizing I think this discussion is fruitful, and I'm interested in seeing Gabriel's proposal. At the risk of seeming to postpone the issue, however, I wonder if we could try to limit discussion on Monday to Danny's original proposal of the metaobject protocol (with perhaps some side discussion on issues where a certain amount of closure has been achieved, like inheritence of slot options, possibly initialization protocol for STANDARD-CLASS instances)? I agree that the issue can't be relegated to the metaobject protocol, since the issue of hooks into CL DECLARE and THE should be resolved as well, but the metaobject protocol may have a role to play. jak  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 11 Mar 87 16:19:41 EST Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 11 Mar 87 13:04:52 PST Received: from JUNCO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 90789; Wed 11-Mar-87 16:04:27 EST Date: Wed, 11 Mar 87 16:04 EST From: Sonya E. Keene Subject: Glossary (enclosed) To: rpg@sail.stanford.edu, lgd@sail.stanford.edu cc: common-lisp-object-system@sail.stanford.edu Message-ID: <870311160408.0.SKEENE@JUNCO.SCRC.Symbolics.COM> The Glossary would be helpful for the X3J13 audience. I've written one up, by taking the definitions out of the text of the document, mostly verbatim. In case you want to see where the definition came from, the list below shows the page number of each definition. Would you format the Glossary and have it copied in time for next week's meeting? Please also write it to the standard places in the CLS,LSP directory. I would do so myself, if only I knew the password. ----------------------- Page References in CLOS Document for Glossary Entries :after method 1-24 :around method 1-24 :before method 1-24 accessor 1-6 applicable method 1-21 auxiliary method 1-20 class 1-3 class precedence list 1-4 declarative method combination 1-25 default method 1-19 and Errata direct subclass 1-4 direct superclass 1-4 effective method 1-21 generic function 1-3 instance 1-3 local precedence order 1-4 local slot 1-6 metaclass 1-4 method 1-3 method combination parameter specializer 1-18, 1-19 parameter specializer name 1-18, 1-19 primary method 1-20 qualified method 1-19 qualifier 1-19 qualifiers 1-18 reader 1-6 setf generic functions 1-18 and Errata setf methods 1-18 and Errata shared slot 1-6 slot 1-5 and Errata slot description 1-7, 2-17 slot specifier 1-7, 2-17 specialized lambda list 1-18 and Errata standard method combination 1-26 standard-class 1-26 standard-generic-function 1-26 standard-type-class 1-26 structure-class 1-26 subclass 1-4 superclass 1-4 unqualified method 1-19 ----------------------------------------------------- \input macros \def\bookline{\CLOS\ Specification} \def\chapline{Glossary} \beginChapter 4.{Common Lisp Object System Specification}% {Glossary}{Glossary} \endTitlePage \beginSection{Introduction} The terminology is introduced in this document the first time each term is used. This section presents the terms in alphabetical order, for easy reference. \endSection%{Introduction} \beginSection{Glossary} {\bit Accessible slot\/}: We say that a slot is accessible in an instance of a class if the slot is defined by the class of the instance or is inherited from a superclass of that class. At most one slot of a given name can be accessible in an instance. {\bit Accessor\/}: When a slot has an accessor, this means it has two generic functions, one for reading the value of the slot, and another for writing the value of the slot. The mechanism for writing is to use {\bf setf} with the reader generic function. {\bf defclass} has options for automatically generating methods for slot accessors; these methods are implemented by using {\bf slot-value} and are added to the appropriate generic functions. It is possible to modify the behavior of these generic functions by writing methods for them. {\bit :after method\/}: In standard method combination, an {\bf :after} method has the keyword {\bf :after} as its only qualifier. An {\bf :after} method specifies code that is to be run after the primary method. {\bit Applicable method\/}: Given a generic function and a set of arguments, the applicable methods are all methods for that generic function whose parameter specializers are satisfied by their corresponding arguments. {\bit :around method\/}: In standard method combination, an {\bf :around} method has the keyword {\bf :around} as its only qualifier. {\bit Auxiliary method\/}: In standard method combination, a qualified method has the role of auxiliary method; an auxiliary method modifies the main action of the effective method in some way. Standard method combination allows zero qualifiers or a single qualifier, which is one of: {\bf :after}, {\bf :before}, or {\bf :around}. {\bit :before method\/}: In standard method combination, a {\bf :before} method has the keyword {\bf :before} as its only qualifier. A {\bf :before} method specifies code that is to be run before the primary method. {\bit Class\/}: An object that describes the structure and behavior of a set of objects, which are called its instances. Every Lisp object is an instance of a class, and can be queried for its class by using the {\bf class-of} function. The class of an object determines the set of operations that can be performed on the object. {\bf defclass} is used to define new classes. {\bit Class precedence list\/}: A total ordering of the set of the given class and its superclasses. The total ordering is expressed as a list ordered from most specific to least specific. The class precedence list is used in several ways. The method selection and combination process uses the class precedence list to order methods from most specific to least specific. Similarly, the process of determining slot characteristics uses the class precedence list to order slot specifiers from most specific to least specific. {\bit Declarative method combination\/}: The programmer can use the {\bf define-method-combination} macro to define new forms of method combination. The method-combination type controls the selection of methods, the order in which they are run, and the values that are returned by the generic function. There are two forms of {\bf define-method-combination}. The short form is a simple facility for the cases that have been found to be most commonly needed. The long form is more powerful but more verbose; it allows arbitrary control structures to be implemented, and arbitrary processing of method qualifiers. {\bit Default method\/}: A method all of whose parameter specializers are the class named {\bf t} is a default method. Note that if a parameter has no specializer, it is the same as having a parameter specializer of {\bf t}, since {\bf t} is the class of all objects. A default method is always applicable, but is often shadowed by a more specific method. {\bit Defining a slot\/}: We say that a class {\it defines\/} a slot with a given name when the {\bf defclass} form for that class contains a slot specifier with that name. Defining a local slot does not immediately create a slot; it causes a slot to be created each time an instance of the class is created. Defining a shared slot creates a slot. {\bit Direct superclass and subclass\/}: The direct superclasses of a class are those classes that are included explicitly in the superclass list in the {\bf defclass} form. Class A is a direct subclass of class B if B is a direct superclass of A. {\bit Effective method\/}: When a generic function is called with particular arguments, it must decide what code to execute. We call this code the effective method for those arguments. The effective method can be one of the methods for the generic function, or a combination of several of them. {\bit Generic function\/}: A function whose behavior depends on the classes or identities of the arguments supplied to it. A generic function comprises a set of methods, a lambda-list, a method-combination type, and possibly some options. The methods define the class-specific behavior and operations of the generic function. Thus, generic functions are objects that may be specialized by defining methods to provide class-specific operations. When a generic function is invoked, the classes of its required arguments determine which methods will be invoked. The behavior of the generic function results from which methods are selected for execution, the order in which the selected methods are called, and how their values are combined to produce the value or values of the generic function. {\bit Instance\/}: Every Lisp object is an instance of some class. The term instance is used to describe the instance/class relationship of an object to its class. {\bf make-instance} is used to create new instances of classes which were defined by {\bf defclass}. {\bit Local precedence order\/}: When a class is defined, the order in which its direct superclasses are mentioned in the defining form is important. Each class has a local precedence order, which is a list consisting of the class followed by its direct superclasses in the order mentioned in the defining form. {\bit Local slot\/}: A local slot is local to an individual instance. A local slot is created by giving {\bf :instance} or {\bf :dynamic} as the value of the {\bf defclass} {\bf :allocation} slot option, or by providing a slot specifier that omits the {\bf :allocation} slot option (since {\bf :instance} is the default). {\bit Metaclass\/}: Classes are represented by objects that are themselves instances of classes. The class of the class of an object is termed the metaclass of that object. The metaclass determines the form of inheritance used by the classes that are its instances and the representation of the instances of those classes. The \CLOS\ provides a default metaclass that is appropriate for most programs; it is called {\bf standard-class}. The meta-object protocol will allow for defining and using new metaclasses. {\bit Method\/}: An object that defines the class-specific behavior and operations of the generic function. Each required formal parameter of each method has an associated parameter specializer, and the method is expected to be invoked only on arguments that satisfy its parameter specializers. A method object contains a method function, a set of parameter specializers that specify when the given method is applicable, and a set of qualifiers that are used by the method combination to distinguish among methods. {\bit Method combination\/}: Each generic function contains a method-combination type, which controls the selection of methods, the order in which they are run, and the values that are returned by the generic function. The \CLOS\ offers a default method combination type that is appropriate for most user programs; it is called standard method combination. The \CLOS\ also provides a facility for declaring new types of method combination for programs that require them. {\bit Parameter specializer\/}: Each method has an ordered set of parameter specializers, that specify when the given method is applicable. Only required parameters can be specialized, and there must be a parameter specializer for each required parameter. For notational simplicity, if some required parameter in a specialized lambda-list is simply a variable name, its parameter specializer defaults to the class named {\bf t}. Parameter specializers are used in the functional interface ({\bf make-method} and {\bf get-method}). A parameter specializer name denotes a parameter specializer as follows: Let $N$ be a parameter specializer name and $P$ be the corresponding parameter specializer; if $N$ is a class name, then $P$ is the class with that name; otherwise $N$ equals $P$. {\bit Parameter specializer name\/}: Parameter specializer names are used in macros intended as the user-level interface ({\bf defmethod} and {\bf defmethod-setf}). Every parameter specializer name is a Common Lisp type specifier, but the only Common Lisp type specifiers that are valid as parameter specializer names are: the name of any class, or a list of the form {\tt ({\bf quote} {\it object\/})}. {\bit Primary method\/}: In standard method combination, an unqualified method has the role of primary method; a primary method defines the main action of the effective method. For types of method combination defined using the short form of {\bf define-method-combination}, primary methods are defined to include not only the unqualified methods, but certain others as well. {\bit Qualified method\/}: A method that has one or more qualifiers is called a {\bit qualified\/} method. {\bit Qualifier\/}: Each method has an ordered set of qualifiers that are used by the method combination facility to distinguish among methods. A qualifier is any object other than a list; in other words, any non-{\bf nil} atom. By convention, qualifiers are usually keyword symbols. Standard method combination allows zero qualifiers or a single qualifier, which is one of: {\bf :after}, {\bf :before}, or {\bf :around}. {\bit Reader generic function\/}: A generic function that enables you to read the value of a slot. {\bf defclass} has options for automatically generating methods for readers; these methods are implemented by using {\bf slot-value} and are added to the appropriate generic functions. It is possible to modify the behavior of these generic functions by writing methods for them. {\bit SETF generic function\/}: A {\bf setf} generic function is called in an expression such as: ({\bf setf} ({\it symbol arguments\/}) {\it new-value\/}). One example of {\it symbol\/} is a slot reader. The macro {\bf defgeneric-options-setf} is used to define a {\bf setf} generic function. {\bf setf} generic functions do not have names. The macros {\bf defmethod-setf} and {\bf defgeneric-options-setf} use {\bf get-setf-generic-function} to find the generic function they affect. {\bit SETF method\/}: A method for a {\bf setf} generic function. {\bf defmethod-setf} is used to write a {\bf setf} method. {\bit Shared slot\/}: A shared slot is shared by all instances of a given class. A shared slot is created by giving {\bf :class} as the value of the {\bf defclass} {\bf :allocation} slot option. {\bit Slot\/}: An object has zero or more named slots. An object's set of slots is determined by the object's class. Each slot can hold one value. There are two kinds of slots: slots that are local to an individual instance and slots that are shared by all instances of a given class. The {\bf :allocation} slot option controls the kind of slot that is defined. If the value of the {\bf :allocation} slot option is {\bf :instance} or {\bf :dynamic}, a local slot is created. If the value of the {\bf :allocation} slot option is {\bf :class}, a shared slot is created. {\bit Slot description\/}: Another term for slot specifier. {\bit Slot specifier\/}: A slot specifier is part of the syntax of {\bf defclass}. A slot specifier contains the name of a slot, and zero or more slot-options. {\bit Specialized lambda list\/}: Each method has a specialized lambda-list, which determines when that method can be selected. A specialized lambda-list is like an ordinary lambda-list except that a specialized parameter may occur instead of the name of a parameter. {\bit Specialized parameter\/}: A specialized parameter is a list, {\tt ({\it variable-name parameter-specializer-name\/})}. {\bit Standard method combination\/}: Standard method combination is the name of the default method combination type. {\bit Standard-class\/}: The class {\bf standard-class} is the default class of classes defined by {\bf defclass}. {\bit Standard-generic-function\/}: The class {\bf standard-generic-function} is the default class of generic functions defined by {\bf defmethod}, {\bf defmethod-setf}, {\bf defgeneric}, or {\bf defgeneric-setf}. {\bit Standard-method\/}: The class {\bf standard-method} is the default class of methods defined by {\bf defmethod} or {\bf defmethod-setf}. {\bit Standard-type-class\/}: The class {\bf standard-type-class} is a metaclass of all the classes that correspond to the standard Common Lisp types specified in {\it Common Lisp: The Language\/} by Guy L. Steele Jr. The classes whose metaclass is {\bf standard-type-class} are called standard-type-classes. For example {\bf array} is a standard-type-class; {\bf array} is the name of the class for objects of type {\bf array}. It is not allowed to make an instance of a standard-type-class with {\bf make-instance}, or to include a standard-type-class as a superclass of a class. {\bit Structure-class\/}: The class {\bf structure-class} is a subclass of {\bf standard-type-class}. All classes defined by means of {\bf defstruct} are instances of {\bf structure-class} or a subclass of {\bf structure-class}. {\bit Subclass and superclass\/}: A class whose definition refers to other classes for the purpose of inheriting from them is said to be a {\bf subclass} of each of those classes. The classes that are designated for purposes of inheritance are said to be {\bf superclasses} of the inheriting class. Note that a class is not considered a subclass nor a superclass of itself. The set of subclasses of a class is the transitive closure of its direct subclasses. The set of superclasses of a class is the transitive closure of its direct superclasses. {\bit T\/}: There is a distinguished class named {\bit T\/}. It has no superclasses, and is a superclass of every class except itself. {\bit Unqualified method\/}: A method that has no qualifiers is called an {\bit unqualified\/} method. \endSection%{Glossary} \endSection \endChapter \bye  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 11 Mar 87 12:52:26 EST Date: 11 Mar 87 0939 PST From: Dick Gabriel Subject: Staticizing To: common-lisp-object-system@SAIL.STANFORD.EDU Kempf rightly points out that this is a concern. I thought I had a scheme to do it similar to the scheme for staticizing function calls, but I'm now not entirely sure of it. I hope to rethink it today, but for the moment, Kempf, suffice it to say I am sympathetic to your concerns. Danny, we cannot relegate all matters to the metaobject protocol, though we could. If we want to start putting things there that are now in the first-order specification, I have a long list. -rpg-  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 11 Mar 87 12:22:27 EST Date: 11 Mar 87 0913 PST From: Dick Gabriel Subject: Inheritance of Slots To: common-lisp-object-system@SAIL.STANFORD.EDU I think we should leave in the :type descriptor. Since none of you care about it, let be commune with my compiler and propose a reasonable thing, which will probably be a variant of what is currently in the spcification. While we're on the topic of deriding parts of the specification that only one person likes, I'd like to re-propose flushing :dynamic slots. Now let me see, what kind of convincing argument can I give? Hm, could it be ``it is something that can be added with the metaobject protocol''? -rpg-  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 11 Mar 87 11:11:23 EST Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 11 Mar 87 07:59:51 PST Received: from Cabernet.ms by ArpaGateway.ms ; 11 MAR 87 07:57:10 PST Date: 11 Mar 87 07:56 PST Sender: Bobrow.pa@Xerox.COM From: Danny Bobrow Subject: Re: Gabriel's Comments In-reply-to: Jim Kempf 's message of Tue, 10 Mar 87 09:31:52 pst To: kempf%hplabsc@hplabs.HP.COM cc: common-lisp-object-system@sail.stanford.edu Message-ID: <870311-075710-1512@Xerox> With regard to class redefinition, lazy update would certainly get rid of having to keep pointers around in classes, but would introduce an extra operation during method dispatch, slot access, or whatever operation was chosen to do the update. Since method dispatch is 100% overhead as far as the applications programmer is concerned, the question is whether the added flexibility of having the class update automatically is worth the extra time spent checking during method dispatch. Similarly with slot access. Note that inserting update into dispatch could also interfere with staticizing a class. Suppose you have finished developing a class and now want to staticize it. If method dispatches must check whether instances need to be changed, staticization needs not only to affect classes but also methods dispatching on the classes, since the check for changes in the class must be removed from the dispatch. The issue you bring up here can be characterized in terms of a tradeoff between a good development environment and one fully optimized for speed. I assume that when you talk of "staticizing a class" you really mean "staticizing a set of classes and generic functions which apply only to those classes". And that the former means that you expect not to build any subclasses of the staticized classes (or at least have them staticized immediately). The purpose of the meta-object protocol in part is to allow you to change the implementation of a set of classes by defining the implementation structure, and optimizations of slot access and method lookup. For classes of such metaclasses, neither CHANGE-CLASS nor instance updating (CLASS REDEFINITION) need work. These are only guaranteed to work for STANDARD-CLASS. In addition, the question of whether changing a class definition and having instances still be EQ is consistent with Common Lisp's EQ semantics needs to be resolved. It is the same semantics as EQ when a list structure has been RPLAC'd. EQ implies a continuity of history and coreference. danny  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 11 Mar 87 10:10:20 EST Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 11 Mar 87 07:01:51 PST Received: from Cabernet.ms by ArpaGateway.ms ; 11 MAR 87 07:01:08 PST Date: 11 Mar 87 07:01 PST Sender: Bobrow.pa@Xerox.COM From: Danny Bobrow Subject: Re: Inheritance of Slots and Slot Options In-reply-to: David A. Moon 's message of Wed, 11 Mar 87 00:08 EST To: Moon@STONY-BROOK.SCRC.Symbolics.COM cc: Common-Lisp-object-system@SAIL.STANFORD.EDU Message-ID: <870311-070108-1469@Xerox> The strong type constraint rule Moon proposes Please note that I never proposed this, I only tried to make the explanation understandable. If I had my druthers, there would be no :type slot option. As the one who proposed the :type option (because I was trying to be upward compatible from defstruct), I support Moon's feeling. If this is uniformly the case (Dick, we have not heard from you on this issue), then why don't we delete it. It is something that can be added with the metaobject protocol. Proposal. In the errata sheet we eliminate :type, and make an explicit statement to that effect in the presentation. danny  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 11 Mar 87 03:15:37 EST Received: from HPLABS.HP.COM by SAIL.STANFORD.EDU with TCP; 11 Mar 87 00:05:35 PST Received: from hplabsc by hplabs.HP.COM with TCP ; Tue, 10 Mar 87 12:18:00 pst Received: by hplabsc ; Tue, 10 Mar 87 09:31:52 pst Date: Tue, 10 Mar 87 09:31:52 pst From: Jim Kempf Message-Id: <8703101731.AA00849@hplabsc> To: common-lisp-object-system@sail.stanford.edu Subject: Re: Gabriel's Comments Sorry it's taken so long to get around to this. Starting from the bottom up, here's some replies to Dick's comments: METHOD COMBINATION >``7) General comment on method combination. It is certainly clearer now >than in the original documents, but I wish the preciseness with >which the inheritence algorithm was specified could also be true >of method combination. '' > >Moon (and Sonya) spent some effort cleaning this section up. Nevertheless, >I judged it needed more rewriting, but I could not muster the enthusiasm >or time to do it myself. I had a hard enough time making sense of the >originally confusing uses of the terms ``primary method,'' ``auxiliary >method,'' and ``unqualified method.'' > I think my problems with the section had nothing to do with its casting in English, but rather with a general dissatisfaction with using English to describe something so complicated. As there doesn't seem to be much choice of a more precise language at the moment, I think the current version looks OK. CLASS REDEFINITION With regard to class redefinition, lazy update would certainly get rid of having to keep pointers around in classes, but would introduce an extra operation during method dispatch, slot access, or whatever operation was chosen to do the update. Since method dispatch is 100% overhead as far as the applications programmer is concerned, the question is whether the added flexibility of having the class update automatically is worth the extra time spent checking during method dispatch. Similarly with slot access. Note that inserting update into dispatch could also interfere with staticizing a class. Suppose you have finished developing a class and now want to staticize it. If method dispatches must check whether instances need to be changed, staticization needs not only to affect classes but also methods dispatching on the classes, since the check for changes in the class must be removed from the dispatch. Problems with WITH-SLOTS and with inadvertent trashing of important classes ala` the example with TEXT-BUFFER remain to be solved. In addition, the question of whether changing a class definition and having instances still be EQ is consistent with Common Lisp's EQ semantics needs to be resolved. INHERITANCE OF SLOT DESCRIPTORS Due to problems with our mail delivery, my note got delivered after Moon's simpilified slot descriptors note, although it was mailed before. So I hadn't had a chance to look at it. It looks to have simplified a good portion of the explanation, but it would be useful to see it in context. I think I understand the logic behind (AND ...) type specifiers for inherited slots with the :TYPE option now, after some more study. I think the desired specialization is being achieved with this.  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 11 Mar 87 01:51:29 EST Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 10 Mar 87 20:01:08 PST Received: from Cabernet.ms by ArpaGateway.ms ; 10 MAR 87 17:09:07 PST Date: 10 Mar 87 17:08 PST Sender: Bobrow.pa@Xerox.COM From: Danny Bobrow Subject: Re: Meeting In-reply-to: Dick Gabriel 's message of 09 Mar 87 11:22 PST To: RPG@SAIL.STANFORD.EDU cc: common-lisp-object-system@SAIL.STANFORD.EDU Message-ID: <870310-170907-204@Xerox> 9am Fine. danny  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 11 Mar 87 00:56:22 EST Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 10 Mar 87 21:35:50 PST Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 90146; Wed 11-Mar-87 00:26:55 EST Date: Wed, 11 Mar 87 00:26 EST From: David A. Moon Subject: 87-002 errata To: Common-Lisp-Object-System@sail.stanford.edu Message-ID: <870311002649.7.MOON@EUPHRATES.SCRC.Symbolics.COM> Here is the errata sheet for the 87-002 document, revised on the basis of all the discussion over the mail. Dick and Linda have graciously offered to format this and print up copies to distribute at the X3J13 meeting. I imagine there is still a day or so to remove or correct anything that is not generally agreed upon (I tried to do so already); the exact amount of time depends on their schedule. 1-4 seventh paragraph: The distinguished class T is mentioned but its characteristics are not described in the document, except by implication. Add the sentence: T has no superclasses and is a superclass of every class except itself. 1-5 at the end of the ``Defining Classes'' section, add "A class definition cannot contain two slot specifiers with the same name." 1-5 first paragraph under ``Slots'': Replace the first sentence with "An object has zero or more named slots. An object's set of slots is determined by the object's class. Each slot can hold one value." 1-6 first paragraph: Change ":instance" to ":instance or :dynamic". 1-6 second and third paragraphs: Replace them with the following: We say that a class {\it defines\/} a slot with a given name when the {\bf defclass} form for that class contains a slot specifier with that name. Defining a local slot does not immediately create a slot; it causes a slot to be created each time an instance of the class is created. Defining a shared slot creates a slot. We say that a slot is {\it accessible\/} in an instance of a class if the slot is defined by the class of the instance or is inherited from a superclass of that class. At most one slot of a given name can be accessible in an instance. A detailed explanation of the inheritance of slots is given in the section ``Inheritance of Slots and Slot Options.'' 1-6 last paragraph: At the end of the second sentence: change "lexically available" to "lexically available as if they were variables". 1-7: Replace the section ``Inheritance of Slots and Slot Options'' with the new section supplied below. 1-10: Replace the last sentence with "There is also a method for {\bf setf} of {\tt C2-S3} that writes the value of {\tt S3}." 1-11 second paragraph: The vague word "access" is used without definition. Add the sentence: "In this context, an instance is said to be accessed when a generic function is called with the instance as an argument that is used for method selection, or when {\bf slot-value} is called with the instance as its first argument." 1-11 third paragraph: Remove the sentence "The function {\bf change-class} is called when the number of instance variables changes or when the name of any instance variable changes" since there is no such concept as "instance variable" in this standard. Replace it with the sentence: "When a class is redefined in such a way that the set of local slots accessible to an instance of the class is changed, or the order of slots in storage is changed, updating an instance of the class calls the function {\bf change-class}." 1-11 fourth paragraph: Delete the entire paragraph, it isn't true. Replace it with this paragraph: Because the class C-sub-O does not have a name, writing a method for class-changed that is specialized to a particular C-sub-O must be done through the functional interface, using add-method rather than using defmethod. See the section ``Introduction to Methods.'' 1-11 fifth paragraph third sentence: Change "Each slot of the new version" to "Each local slot of the new version". Last sentence: Delete "For local slots," since we are only talking about local slots anyway. 1-11 last paragraph: Change "the value of that slot will be the same in both instances" to "the value of that slot is unchanged". Since only one instance is involved, we can't say "both instances." 1-11 last paragraph: Break the paragraph after the third sentence so local slots and shared slots are discussed in separate paragraphs. Clarify that the paragraph discussing shared slots refers to what happens at the time the class is redefined, and shared slots are not affected by updating an instance nor by the values of local slots. 1-12 last paragraph: Change "Whether {\bf defclass} is allowed to change the metaclass" to "Whether {\bf defclass} is allowed to change the metaclass, and whether redefining a class updates existing instances,". 1-13 First paragraph: Delete the last sentence. Add a new paragraph at the end of the page: "Every class that has a name has a corresponding type with the same name as the class. In addition, every class object is a valid type specifier. Thus (typep ) is true if the class of the given is itself or a subclass of and (subtypep ) returns t t if is a subclass of or they are the same class, and returns nil t otherwise." 1-18 first paragraph under "Introduction to setf Generic Functions": Change "(setf (generic-function-name arguments) new-value)" to "(setf (symbol arguments) new-value)" because the base function does not have to be generic, in fact it does not even have to be defined. 1-18 last paragraph: The term "parameter specifier" is used in a way that is inconsistent with its use by CLtL and there are a couple of typographical problems. Replace the entire paragraph with: Each method has a {\bit specialized lambda-list}, which determines when that method can be selected. A specialized lambda-list is like an ordinary lambda-list except that a {\bit specialized parameter} may occur instead of the name of a parameter. A specialized parameter is a list, {\tt ({\it variable-name parameter-specializer-name\/})}, where {\it parameter-specializer-name} is a parameter specializer name. Every parameter specializer name is a Common Lisp type specifier, but the only Common Lisp type specifiers that are valid as parameter specializer names are the following: 1-19: Delete the first line "In short..." since the two bulleted items are now introduced by the preceding paragraph. 1-19 fourth paragraph, beginning "Only required parameters can be specialized": The term "parameter specifier" is misused again. Replace the paragraph with: Only required parameters can be specialized, and there must be a parameter specializer for each required parameter. For notational simplicity, if some required parameter in a specialized lambda-list is simply a variable name, its parameter specializer defaults to the class named {\bf t}. 1-19 fifth paragraph: Change "when the class of each required argument" to "when each required argument". 1-19 seventh paragraph: Change to "This proposal requires that both parameter specializers and parameter specializer names be Common Lisp type specifiers." 1-19 tenth paragraph: Change "parameter specializers are t" to "parameter specializers are the class named t". Change "always part of the generic function" to "always applicable". 1-19 last paragraph fourth sentence: Change "cons" to "list". 1-22 second paragraph: Change "the specializers must be quoted objects (otherwise" to "the specializers must be equal (otherwise". 1-23 first line: Change "defmacro" to "defmethod". 1-25 sixth paragraph: Change "All {\bf :around} methods run before any primary methods run." to "All {\bf :around} methods run before any non-{\bf :around} methods run." 1-26 first paragraph: Change "Flavors" to "CommonObjects". 2-5 Values paragraph: Replace the whole sentence with "The value is {\it generic-function}." to clarify that the value is EQ to the argument. 2-8 Purpose paragraph: Add the sentences "The generic function {\bf change-class} is invoked automatically by the system after {\bf defclass} has been used to redefine an existing class. It can also be explicitly invoked by the user." 2-8 Values paragraph: Replace the whole sentence with "The value is {\it instance}." to clarify that the value is EQ to the argument. 2-11 Purpose paragraph: Delete the sentences "The generic function {\bf change-class} is invoked automatically by the system after {\bf defclass} has been used to redefine an existing class. It can also be explicitly invoked by the user." Add the sentence "The function {\bf class-changed} is called only by the function {\bf change-class}." 2-11 second Arguments paragraph: Delete the second sentence. It lost its intended meaning as a result of previous editing. 2-11 first Remarks paragraph: Delete this. It contradicts an example on page 2-8 and it isn't true. 2-11 second Remarks paragraph: Some occurrences of change-class should be class-changed and there are a couple of terminological problems ("copy", "part"). Replace the paragraph with: The arguments to {\bf class-changed} are computed by {\bf change-class}. The first argument is an instance of the original class created to hold the old slot values temporarily. This argument has dynamic extent within {\bf class-changed}, and therefore it is an error to reference it in any way once {\bf class-changed} returns. 2-15 third paragraph: Add "A class object can be used directly as a type-specifier. Thus (typep ) is true if the class of the given is itself or a subclass of ." 2-15 last line: Delete this. Defclass has no effect on the value cells of symbols. 2-17 second paragraph: Delete ", from their superclasses, and so on". 2-17 :allocation bullet: Change "in the class instance" to "in each instance". 2-18 first bullet (:type). There is no discussion of the meaning and enforcement of :type. Add the following (stolen from CLtL p.310): This specifies that the contents of the slot will always be of the specified data type. This is entirely analogous to the declaration of a variable or function; indeed, it effectively declares the result type of the reader generic function when applied to an object of this class. An implementation may or may not choose to check the type of the new value when initializing or assigning to a slot. 2-18 :accessor-prefix, :reader-prefix bullets: Change "These ... functions are interned" to "These ... function names are interned". 2-26 short-form-option syntax: Delete the :order clause. 2-27 fourth bullet: Delete it. 2-29 first paragraph: Replace the next to last sentence with: "If {\bf :description} is not specified, a default description is generated based on the variable name and the qualifier patterns, and on whether this method-group includes the unqualified methods." 2-33 third paragraph: Change "If no generic function is currently named by the symbol {\it name\/}" to "If {\tt (fboundp {\it name\/})} is {\bf nil}" to match the terminology used on page 2-21. 2-34 first paragraph: Change "primary (in this case, unqualified) methods" to "unqualified methods". 2-34 second paragraph: Same problem with "parameter specifier" as on 1-18. Replace the first two sentences of the paragraph with: The {\it specialized-lambda-list\/} argument is like an ordinary function lambda-list except that required parameter names can be replaced by specialized parameters. A specialized parameter is a list of the form {\tt ({\it variable-name parameter-specializer-name\/})}. 2-35 syntax for specialized-setf-lambda-list: Change "specializer" to "parameter-specializer-name". 2-38 fourth Arguments paragraph: Change "If the first argument is a symbol" to "If the first argument is a symbol that names a class". 2-38 last Arguments paragraph: Change "If the first argument is a symbol" to "If the first argument is a symbol that has a setf generic function associated with it". 2-39 last Arguments paragraph: Change "second" to "errorp". 2-41 second Purpose paragraph: Replace it with "Whether {\bf invalid-method-error} returns to its caller or exits via {\bf throw} is implementation dependent." 2-46 second Purpose paragraph first sentence: It was not intended to guarantee that the returned value is a list with certain objects in its car and cdr. Change "a form whose first element" to "a form whose effect is the same as a form whose first element". 2-47 Values paragraph: same as the preceding. 2-48 second Purpose paragraph: Replace it with "Whether {\bf method-combination-error} returns to its caller or exits via {\bf throw} is implementation dependent." 2-53 Syntax paragraph: remove "&optional errorp". 2-53 last Arguments paragraph: Replace the entire paragraph with "{\bf remove-method} does not signal an error if the method has already been removed from the generic function." 2-53 Values paragraph: Replace the whole sentence with "The value is {\it generic-function}." to clarify that the value is EQ to the argument. 2-54: Add pages for SUBTYPEP, TYPE-OF, and TYPEP, explaining that SUBTYPEP and TYPEP are to be extended to accept class objects as type specifiers, and explaining that TYPE-OF never returns a class object, with a cross-reference to CLASS-OF. (Unresolved issue: does TYPE-OF an instance of an anonymous class return the class object, or does it return some symbol?) 2-55 last paragraph first sentence: Delete "or a superclass". 2-55 last paragraph fourth sentence: Change "not a subclass of the specified class" to "not the specified class or a subclass of the specified class". 2-55 last paragraph fifth sentence: Change "superclass of the instance" to "superclass of the actual class of the instance" and change "different" to "smaller". 2-56 second paragraph: Change "using the accessor function" to "calling the accessor function", "is used to access" to "is called to access", and "accesses the slots by using" to "accesses the slots by calling". 2-56 Values paragraph: Change "value" to "values" to clarify that the body can return multiple values. ! Revised ``Inheritance of Slots and Slot Options'' section: [For readability all TEX formatting has been temporarily removed] The set of the names of all slots accessible in an instance of a class, C, is the union of the sets of names of slots defined by C and its superclasses. At most one slot of a given name can be accessible in an instance. In the simplest case, only one class among C and its superclasses defines a slot with a given slot name. If the class that defines the slot is not C, we say that the slot is inherited. The characteristics of the slot are determined by the slot specifier of the defining class. If the :allocation slot option is omitted, :instance, or :dynamic, then it specifies a local slot and each instance of C has its own slot that stores its own value. If the :allocation slot option is :class, then it specifies a shared slot, the class that defined the slot stores the value, and all instances of C access that single slot. In general, more than one class among C and its superclasses can define a slot with a given name. In such cases, only one slot with the given name is accessible in an instance of C, and the characteristics of that slot are a combination of the several slot specifiers, computed as follows. - All the slot specifiers for a given slot name are ordered from most specific to least specific, according to the order in the class precedence list of C of the classes that define them. - The allocation of a slot is controlled by the most specific slot specifier. If the most specific slot specifier does not contain an :allocation slot option, :instance is used. Less specific slot specifiers never affect the allocation. - The initform of a slot is controlled by the most specific slot specifier that contains an :initform slot option. If no slot specifier contains an :initform, the slot has no default initial value form. - The type of a slot is (and T1 T2 T3...), where T1, T2, T3, and so on are the :type slot options contained in all of the slot specifiers. If no slot specifier contains :type, the type is t. The :reader and :accessor slot options were not mentioned because they create methods, rather than defining characteristics of a slot. Reader and accessor methods are inherited in the sense described in the section ``Inheritance of Methods.'' A consequence of the allocation rule is that shared slots can be shadowed. If a class C-sub-1 defines a shared slot named S, normally that single slot is accessible in instances of C-sub-1 and all of its subclasses. However, if C-sub-2 is a subclass of C-sub-1 and also defines a slot named S, C-sub-1's slot is not shared by instances of C-sub-2 and its subclasses. See S2 in the section ``Examples of Inheritance.'' A consequence of the type rule is that the value of a slot satisfies the type constraint of each slot specifier that contributes to that slot. Note that an implementation may or may not choose to check the type of the new value when initializing or assigning to a slot. Methods that access slots know only the name of the slot and the type of the slot's value. Suppose a superclass provides a method that expects to access a shared slot of a given name and a subclass defines a local slot with the same name. If the method provided by the superclass is used on an instance of the subclass, the method accesses the local slot.  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 11 Mar 87 00:30:42 EST Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 10 Mar 87 21:16:06 PST Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 90132; Wed 11-Mar-87 00:10:25 EST Date: Wed, 11 Mar 87 00:10 EST From: David A. Moon Subject: Re: Proposed revision of "Inheritance of Slots and Slot Options" section To: Common-Lisp-Object-System@sail.stanford.edu In-Reply-To: <870227-162043-4596@Xerox> Message-ID: <870311001020.6.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: 27 Feb 87 16:20 PST From: Danny Bobrow In general I agree with Moon that slot inheritance is simple and like his rewording. A few minor glitches: If the :allocation slot option is omitted or specifies a local slot, then each instance of C stores its own value for the slot. This needs to be specific about local being either :instance or :dynamic (or perhaps it should have that earlier). An earlier item on the errata sheet was to add :dynamic where it had been left out. But I agree that it's better to mention the specific keywords here too, so I added that to the revised errata sheet I am about to mail out. Secondly, the type constraint is presented very strongly. The intent of having it (I pushed it in) was to allow compatibility with current defstruct. Current defstruct does not specify that a slot MUST meet its type constraint. Consequently, I would suggest that the rule specify: "The :type of a slot need not be specified. If it is, the interpretation is that the value of the slot should be of type (and T1 T2 T3...), where T1 , ... Tn are all the type specifiers provided in any slot specifcation. Implementations need not check for values, but those that do should use the interpretation, and hence may optimize for those values." In 87-002 it seems we forgot to say anywhere what :type really means. The errata sheet for chapter 2 says something that I think is equivalent to what you just said.  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 11 Mar 87 00:29:25 EST Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 10 Mar 87 21:15:57 PST Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 90130; Wed 11-Mar-87 00:08:27 EST Date: Wed, 11 Mar 87 00:08 EST From: David A. Moon Subject: Inheritance of Slots and Slot Options To: Common-Lisp-object-system@SAIL.STANFORD.EDU In-Reply-To: The message of 28 Feb 87 01:58 EST from Dick Gabriel Message-ID: <870311000821.5.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: 27 Feb 87 2258 PST From: Dick Gabriel He removed the sentence: ``At most, one slot of a given name can be accessible in an instance.'' Although he inserts it later, I think it doesn't hurt to leave it where it is (as well). I put it back, in the revised errata I am about to mail out. Moon writes: ``- The type of a slot is (and T1 T2 T3...), where T1, T2, T3, and so on are the :type slot options contained in all of the slot specifiers. If no slot specifier contains :type, the type is t.'' Here I think the language is unclear. Does this mean that the :type option for the most specific class is taken to be (and ...)? Is the slot constrained to hold values that satisfy (and ...) in the sense that an error is signaled if someone tries to store something there that does not satisfy the type? The language we had originally stated that the :type option defaulted to T, and the contents of the slot would always be of type (and ...). This mimicked the language in CLtL for defstruct and represents a statement more in line with types as optional information to the compiler. The errata sheet already contains a description of what the :type slot option means, based on earlier discussion over the mail. What may be confusing is that it's buried in the description of defclass in chapter 2. I don't see a really good place to put it in chapter 1. Later Moon writes: ``A consequence of the type rule is that the value of a slot must satisfy the type constraint in -every- slot specifier that contributes to that slot.'' The convention in CLtL is that the phrase ``x must do y'' means that otherwise it is an error, so we can deduce that he means that the slot is not constrained in the sense of signaling an error. Again, this is explained in chapter 2. In the revised errata sheet I am about to mail out, I changed the wording of the offending sentence to be clearer. We should probably include at the beginning of these chapters a warning to read page 6 of CLtL to understand the conventions of the language we use. I agree, it wouldn't hurt to say that we are using the same terminology as CLtL in the next version of this document. Moon writes in the next paragraph: ``An argument to a method can be an instance of a subclass of the class declared by a parameter specializer, so the compiler cannot know the exact class.'' This should be expanded because many will not easily see the connection between random methods and optimizing based on the types of slots. Instead, I removed the whole discussion. It seems either a whole page of design rationale is needed here, or it's better simply to state how it is without trying to explain why. The strong type constraint rule Moon proposes Please note that I never proposed this, I only tried to make the explanation understandable. If I had my druthers, there would be no :type slot option. has some effects that might be difficult for a reader to understand unless explained properly. Suppose we have: (defclass c1 () ((foo :type t1))) (defclass c2 (c1) ((foo :type t2))) (defclass c3 (c1) ((foo :type t3))) The FOO slot in C1 must be of type (and T1 T2) when regarded from the point of view of C2, and it must be of the type (and T1 T3) when regarded from the point of view of C3. Therefore, it actually must be of type (and T1 T2 T3). The compiler compiling methods on C2 or C3 alone won't care much, and when it compiles a method on C2 and C3 it might discover the happy fact. A reader of this specification might be confused into thinking that there is some intractable problem at hand and that the type of a slot cannot actually be deduced because it depends on classes very far away. Your last sentence here was what really convinced me that it was better not to try to explain the design rationale here. I removed all mention of compilers. Moon writes near the end: ``The :reader and :accessor slot options were not mentioned above because they create methods rather than defining characteristics of a slot. Reader and accessor methods are inherited in the sense described in the section ``Inheritance of Methods.'' '' This needs to be made clear at the outset: two-pass reading is bad news. I agree; I moved this up to a more appropriate place.  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 10 Mar 87 14:45:31 EST Received: from [192.10.41.109] by SAIL.STANFORD.EDU with TCP; 10 Mar 87 11:13:44 PST Received: from CHICOPEE.SCRC.Symbolics.COM by ALDERAAN.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 60354; Tue 10-Mar-87 13:58:36 EST Date: Tue, 10 Mar 87 13:57 EST From: Daniel L. Weinreb Subject: Meeting To: RPG@SAIL.STANFORD.EDU, common-lisp-object-system@SAIL.STANFORD.EDU In-Reply-To: The message of 9 Mar 87 14:22 EST from Dick Gabriel Message-ID: <870310135741.7.DLW@CHICOPEE.SCRC.Symbolics.COM> 9am is fine with me. (That's noon eastern time...)  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 9 Mar 87 14:41:06 EST Date: 09 Mar 87 1122 PST From: Dick Gabriel Subject: Meeting To: common-lisp-object-system@SAIL.STANFORD.EDU I have a meeting room at the hotel reserved for 9-5 Monday. Because I will possibly need to flame at the regular meeting during the Cleanup Committee discussion, I'd like to start our meeting early in the day. Is 9am ok with everyone? -rpg-  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 8 Mar 87 06:46:32 EST Received: from HPLABS.HP.COM by SAIL.STANFORD.EDU with TCP; 8 Mar 87 03:42:00 PST Received: from hplabsc by hplabs.HP.COM ; Mon, 23 Feb 87 11:35:42 pst Received: by hplabsc ; Mon, 23 Feb 87 11:35:04 pst Date: Mon, 23 Feb 87 11:35:04 pst From: Jim Kempf Message-Id: <8702231935.AA19657@hplabsc> To: common-lisp-object-system@sail.stanford.edu Subject: Comments on CLOS specification So far, I've read through the Introduction and MetaObject Protocol chapters. I'll post my comments on each section individually. Jim Kempf kempf@hplabs.hp.com  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 8 Mar 87 05:59:05 EST Received: from HPLABS.HP.COM by SAIL.STANFORD.EDU with TCP; 8 Mar 87 02:53:23 PST Received: from hplabsc by hplabs.HP.COM ; Fri, 20 Feb 87 08:37:02 pst Received: by hplabsc ; Fri, 20 Feb 87 08:36:28 pst Date: Fri, 20 Feb 87 08:36:28 pst From: Jim Kempf Message-Id: <8702201636.AA19092@hplabsc> To: common-lisp-object-system@sail.stanford.edu Subject: Re: Consistency In response to Gabrial's concerns: >At this point I'm worried about a couple of new things: first, that >the Common-Lisp-skeptics will accuse us of doing to object-oriented >programming what we did to Lisp: obfuscate and ruin it; This may happen, but I think it is too late to back out now. Application developers are waiting for an object oriented extension, and there has been some grumbling that if a major application written in Common Lisp (NOT an expert system shell) does not come out in the next year or so, Common Lisp, itself, may be sunk. > second, that >the proposal might be in jeopardy because it is too complex. Though this may sound trite, I think the quote from Einstein about "everything should be made as simple as possible to understand, but not simpler" is relevent here. If we are trying to do something complex, then we should try to explain it as simply as possible. If there is too much mechanism, then maybe some should be eliminated. As I have not had a chance to look at the documents yet (scheduled for this weekend) I can't yet say which may be the case. >The people at Tektronix had no trouble understanding what I said, nor >did they fail to understand CLOS. They were appalled at the complexity >and questioned whether that complexity was necessary. I think some of the complexity may be the result of a desire to provide maximum flexibility. Certainly this is true of the Metaobject Kernel. >I still believe that we are writing a specification, and it would be wrong >to put fluffy, imprecise language into the document. I think from my >comments about Moon's errata you can still see this attitude. And if you >compared the draft material as of 2 weeks ago with the current draft you >will see a major movement towards consistency and preciseness, even at the >expense of pretty language - it may not be perfect, but a lot of >what was there before was embarrassingly bad. > >When I decide to write things using mathematical notation, for example, it >is because I cannot think of how to unambiguously express the concepts in >English. (Also, if the concepts were simpler, they could be expressed in >prose more easily.) I think there is a major problem here which CLtL itself faces, and that is specifications of large complex software systems just simply cannot be done accurately in English (or any other natural languge, for that matter). Nobody expects to be able to built a bridge or a jet airplane from an English description, why should the same not be true of a complex software system? Specification languages like Larch or OBJ are the only way to get a precise design, in my opinion, but they are still largely experimental, and therefore probably of little help to the task at hand. As mentioned, I have yet to read the documents, but from my experience working with PCL over the last couple months, I think there is something worthwhile there and I would not like to see it remain unavailable to applications developers because some people are grumbling. Jim Kempf kempf@hplabs.hp.com  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 7 Mar 87 04:20:24 EST Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 7 Mar 87 01:14:09 PST Received: from relay2.cs.net by RELAY.CS.NET id aa05178; 7 Mar 87 4:13 EST Received: from utokyo-relay by RELAY.CS.NET id aa14018; 7 Mar 87 4:05 EST Received: by u-tokyo.junet (4.12/4.9J-1[JUNET-CSNET]) id AA04051; Sat, 7 Mar 87 10:30:42+0900 Received: by tansei.u-tokyo.junet (4.12/6.2Junet) id AA14093; Sat, 7 Mar 87 01:08:05+0900 Date: Sat, 7 Mar 87 01:08:05+0900 From: Masayuki Ida Return-Path: Message-Id: <8703061608.AA14093@tansei.u-tokyo.junet> To: Common-lisp-object-system@SAIL.STANFORD.EDU, ida%u-tokyo.junet@RELAY.CS.NET Subject: Questions on CLOS specification Questions and comments on Common Lisp Object System Specification by Masayuki Ida, Japan with the contributions of: N. Saji (NEC), Yokoo (NTT), Ohkubo (panaFacom), Shiota (Nippon Symbolics), Kawabe (Nippon UNIVAC), Nishida (Fuji Xerox) Basically We are welcome to have an object system for Common Lisp. Though we have no more experience to read the CLOS Specification, we send this mail to CL-Object-system bboard as our first impression memo I hope it may assist the discussion on the comming meeting at Palo Alto. 1>> make-specializable PCL has a make-specializable. How can we add method for a Common Lisp function. (defmethod print ...) give us a special procedure to handle special case on print in PCL. 2>> initialization protocol of make-instance Page 1-5 says "The initialization protocol of make-instance is not yet specified." It seems to arise many difficulties if the initialization protocol will not be specified. We recommend meta object protocol should be included. observation : there is no :initable-instance-variable thing of Flavors in CLOS. :init qualifier of Flavors is not included. So, we need meta object. 3>> defrecord Where is defrecord syntax ? 4>> allocation slot option there is no :none allocation :none allocation allows us to eliminate the not-needed inherited slots allocation. We prefer :none be included 5>> allocation option 2 there seems to be a :dynamic allocation. But there is no explanation on :dynamic. 6>> page 1-6 Accessing Slots "The macro with-slots can be used to set up a lexical environment in which certain slots are lexically available" What is the definition of 'lexical environment' in this context ? it only says the slot name shadows the same name symbol if any ? 7>> page 1-7 Inheritance of Slots and Slot options there is no story on :dynamic :instnce story contains the story for :dynamic ? 8>> page 1-8 Ti can be a Common Lisp Type Why does a class NOT allowed to be a :type ? If we can write a class name for a :type, with the assistance of metaclass idea, we can do more interest things like active-value with simple extension. 9>>page 1-9 7L (and T1 ... Tn) It is too severe restriction on type. 10>> Examples of Inheritance what is the intension of the example ? 11>> Redefining Classes : Slot renaming Is it possible to rename the slot ? class-changed enable it ? Is it truely possible ? Accessor for old-name is safely deleted if w can rename slot by class-changed ? 12>> Redefining Classes : change-class Is it possible to go to a quite different class ? If it is OK to go to a quite different class, a type-conversion may occur for the same slot with different types between the old and the new ? the intention of change-class is like the become: of smalltalk ? become: plays a role to grow the instance, but we feel change-class have a more flexible power ? 13>> Page 1-13 Integrating Types and Classes How about the following story ? split types into three categolies 1) Essential types; which are the terminal types just above the nil type. they will be the defined most-specific types. 2) Defined types; which are the types defined in CLtl except Essential types. 3) system dependent types; which are the types defined in the specific implementation It is not allowed for the value of class-of to be a type of 3). The system must return the type of Essential types if the object belong to the type upon class-of invocation. 14>> Page 1-14 'require' "We require that an implementation of Common Lisp Object System signal an error if R is inconsistent,..." What the word 'require' mean in this case ? 15>> Page 1-15 Examples ; the sequence of defclasses (defclass pie (apple cinnamon) ()) appeared first. It means apple and cinnamon definitions are NOT needed prior to defclassing pie ? 16>> Page 1-17 Local generic function Are there any true possibility to have a local (lexical) generic functions ? There was a discussion on mlet thing.Mlet will revival ? 17>> individual method with unreadable object Is it possible to QUOTE unreadable object on defmethoding ? Say, can we write a trap routine which is invoked upon the access to specific memory location ? 18>> we feel (not ..) and (or ..) syntax for defmethod parameter-specializer-name should be included. (defmethod foo ((x (or symbol simple-string character))) ...) (defmethod foo ((x (not null))) ...) 19>> Page 1-20 Congruent Lambda-lists Consider the following three cases. 1) the case where we need to have a method specifying the classes for optional parameter (defmethod foo ((x foo)(y bar) &optional z) ...) (defmethod foo ((x foo)(y bar) (z baz) &optional zz) ...) 2) generic operation concept with different numbers of arguments. (defmethod rotate ((x 2d-position)(theata number)) ...) (defmethod rotate ((x 3d-position)(theata number)(rou number)) ...) 3) extending the current methods to new methods with more arguments. OLD (defmethod foo ((x ...) (y ...)) ...) -> NEW (defmethod foo ((x ...)(y ...)(z ...)) ...) there will be a transient status where the two argument version and three argument version co-exist. We feel the congruence should get to be more loose. 20>> call-next-method call-next-method has no arguments. Then the arguments are from the lambda list of the current method. this means the arguments can be modified before call-next-method ? The modified value are passed to the next-method ? 21>> add-method the first argument is preferable to be a name,not a generic function object itself. But we also understand the add-method is generic function itself, so, it is not possible to write a name for the first argument. Is it impossible to define add-method as a function ? 22>> Page 2-9 5L is it allowed to supply :x 2 :y 0 without initable declaration or something ? there is no concept of inittable decralation ? 23>> Page 2-11 class-changed Remarks says "It is not possible to define methods on class-changed by using defmethod" But Page 2-8 example uses defmethod to define class-changed ? 24>> Page 2-16 class-option there is no initable related option ? 25>> Page 2-50 multiple-value-prog2 why multiple-value-prog2 is included as a part of CLOS ? it should goto more general discussion ? (I know multiple-value-prog2 is used in define-method-combination)  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 6 Mar 87 22:07:43 EST Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 6 Mar 87 19:02:49 PST Received: from Cabernet.ms by ArpaGateway.ms ; 06 MAR 87 18:39:03 PST Date: 6 Mar 87 18:28 PST Sender: Bobrow.pa@Xerox.COM From: Danny Bobrow Subject: Quote of the day To: Common-lisp-object-system@SAIL.STANFORD.EDU cc: Bobrow.pa@Xerox.COM Reply-to: Bobrow.pa@Xerox.COM Message-ID: <870306-183903-2496@Xerox> A dedication for our work (or perhaps for the whole Common Lisp standardization effort). From: Robert Hass "Praise" Ecco Press 1979 We asked the captain what course of action he proposed to take toward a beast so large, terrifying, and unpredictable. He hesitated to answer, and then said judiciously: "I think I shall praise it." Enjoy danny  Received: from Xerox.COM (TCP 1200400040) by AI.AI.MIT.EDU 6 Mar 87 17:16:19 EST Received: from Salvador.ms by ArpaGateway.ms ; 06 MAR 87 14:10:34 PST Date: 6 Mar 87 14:08 PST From: Gregor.pa@Xerox.COM Subject: Re: gensym'd names to user function names In-reply-to: ricks%eros.Berkeley.EDU@Berkeley.EDU (Rick L Spickelmier)'s message of 6 Mar 87 11:52 PST (Friday) To: ricks%eros.Berkeley.EDU@Berkeley.EDU cc: commonloops.pa@Xerox.COM Message-ID: <870306-141034-2125@Xerox> The next release will have method names back for at least most Common Lisps. In particular, I plan to have them back for Xerox, Symbolics, Lucid and Franz. I hope to also be able to do them for VAXLisp and KCL in that timeframe, but I am not sure yet.  Received: from Xerox.COM (TCP 1200400040) by AI.AI.MIT.EDU 6 Mar 87 16:00:14 EST Received: from Cabernet.ms by ArpaGateway.ms ; 06 MAR 87 11:53:44 PST Return-Path: Received: from ucbvax.Berkeley.EDU by Xerox.COM ; 06 MAR 87 11:51:26 PST Received: by ucbvax.Berkeley.EDU (5.53/1.23) id AA21759; Fri, 6 Mar 87 11:52:29 PST Received: by eros.berkeley.edu (1.2/5.6) id AA01182; Fri, 6 Mar 87 11:52:02 pst From: ricks%eros.Berkeley.EDU@Berkeley.EDU (Rick L Spickelmier) Message-Id: <8703061952.AA01182@eros.berkeley.edu> Date: 6 Mar 87 11:52 PST (Friday) To: commonloops.pa@Xerox.COM Subject: gensym'd names to user function names When I do a backtrace of a PCL program in VAXLISP, I get frames that look like: Frame #17: (#:G10922-I10098-I10101 #) This is not very informative... I would like to be able to find out the name of the defmethod that the user used to create '#:G10922....'. (PCL-GENSYM-NAME '#:G10922-I....) => USER-METHOD-NAME Is there an easy way to do this. Thanks, Rick Spickelmier UC Berkeley  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 6 Mar 87 02:17:27 EST Date: 05 Mar 87 2311 PST From: Dick Gabriel Subject: Kempf's Remarks To: common-lisp-object-system@SAIL.STANFORD.EDU Kempf makes some interesting remarks. I'm not sure I can answer all of them, but Gregor and Moon can fill in the holes. A. Redefining classes 1. I think that the big performance hit in double indirection happens when the trampoline object that represents the identity of the instance is on a different page from the storage for the instance. The issue of redefinition comes up whenever the programmer needs to re-read a file of DEFCLASS's that are different. CLOS doesn't address, yet, the issue of compiler declarations that static-ize the class graph. Because there are ways of dealing with the issue of static function linkages and reDEFUNition, there are ways of dealing with this, also. Thus, I think a ``sufficiently'' clever implementation can do ok, but the question is how clever the implementor must be to produce this implementation. It ought to be a topic of debate in a few weeks. 2. The section on class redefinition states that updating of instances occurs in a lazy manner as instances are stumbled across. Therefore, there is no need to keep sets containing them explicitly. Furthermore, the blocks of storage for the new instances are created lazily at this same time. 3. When a method is applied to an instance, that instance is updated if a class redefinition has been done. So methods on the old instance apply to the new instance, unless the methods have been implicitly removed during class redefinition. I think the document states that WITH-SLOTS might become confused when classes are redefined. 4. No comment on this example. 5. I agree we should think about the issues of compilation semantics. B) Compilation Semantics I agree we need to think about these things. C) Interaction between CLOS and CL ``THE'' and ``DECLARE'' I agree we have to think about this. D) Particular Quibbles Kempf writes: ``1) Pg. 1-5, paragraph 1. A reference to 87-003 (the metaobject chapter) would probably be good here.'' When Chapter 3 is in good shape we need to have reasonable cross-references. At the time that Chapters 1 and 2 were completed for X3J13, Chapter 3 was not available. I felt that it would not be reasonable to put references in existing text to text that did not exist and was not known to be guaranteed to ever exist. Kempf writes: ``2) Pg. 1-6, paragraph 6. There is no statement ... that a class cannot [have] two slots [with] the same name.'' This needs to be clarfied to state that there can only be one slot of a given name. Kempf writes: ``3) pg 1-7 through 1-9. The description of slot options, as Moon has stated, seems needlessly complex.'' I agree that we can simplify this. When writing this section, there was not enough time to thoroughly understand the slot description inheritance rules and to think of how to explain them. Once I understood it, I wrote up a correct, but dull and excessive, explanation that was correct so that people could argue about its reasonableness. I didn't think it was reasonable, so I had little enthusiasm to explain it well. Kempf writes: `` "characteristics of that slot involve some combination of the several slot descriptions" I don't understand why it is necessary to have do this.'' I think the main reason is that people will want to have only the incremental updates to slot descriptions in each class definition. The `intuitively' desirable behavior requires some defaulting where inheritance might seem to make sense. Kempf writes: `` b) The description of valid values on the top of the page has some notational ambiguity....'' Oh dear, this means that my meta-syntactic notation wasn't clear. The idea was to define a mathematical abstraction that represented the semantics of slot description inheritance. The definition of this abstraction was meant to clarify the nature of combined slot descriptions. C(j) and (:class j) were parts of this mathematical abstraction and hence is not intended to exist anywhere. The funny numbers that Kempf refers to are simply the part of the abstraction that represents the information about the class with which a shared slot is shared. Kempf continues: `` c) At the bottom of the page, do you really want the default to be UNSUPPLIED? If so, in what package is this symbol? '' Again, this is part of the abstraction. When the part of the abstraction corresponding to the initform is defined to be UNSUPPLIED this means that in the slot description the effect is as if the initform were not supplied. No package to think about here, except, possibly, PLATO-HEAVEN. Kempf writes: ``d) pg. 1-8. Middle bullet. Why use (AND T(1) .. T(n) )? Again, coming at this from the point of view that subclasses specialize behavior of supers, shouldn't the more specialized type prevail?'' I don't understand this. The effect of the combined slot description is as if the class definition contained (...:type T) and objects stored in that slot will be (in DEFSTRUCT terminology) of type (and t(1) ... t(n)) where t(i) is the ith class in the CPL. Therefore, the type of object is the specialized one Kempf desires (I think). Kempf writes: ``7) General comment on method combination. It is certainly clearer now than in the original documents, but I wish the preciseness with which the inheritence algorithm was specified could also be true of method combination. '' Moon (and Sonya) spent some effort cleaning this section up. Nevertheless, I judged it needed more rewriting, but I could not muster the enthusiasm or time to do it myself. I had a hard enough time making sense of the originally confusing uses of the terms ``primary method,'' ``auxiliary method,'' and ``unqualified method.'' -rpg-  Received: from Xerox.COM (TCP 1200400040) by AI.AI.MIT.EDU 5 Mar 87 17:18:37 EST Received: from Cabernet.ms by ArpaGateway.ms ; 05 MAR 87 13:56:23 PST Date: 5 Mar 87 13:56 PST From: mittal.pa@Xerox.COM Subject: [WIrish.pa: Forwarding: I would like to get a copy of Common Loops.] To: commonloopscore^.pa@Xerox.COM cc: mittal.pa@Xerox.COM Message-ID: <870305-135623-3268@Xerox> Can someone take care of this? ----- Begin Forwarded Messages ----- Date: 5 Mar 87 10:29:07 PST (Thursday) From: WIrish.pa Subject: Forwarding: I would like to get a copy of Common Loops. To: Mittal cc: postmaster ---------------------------------------------------------------- Return-Path: Received: from CS.COLUMBIA.EDU by Xerox.COM ; 05 MAR 87 08:38:36 PST Date: Thu, 5 Mar 87 11:38:14 EST From: Michael van Biema Subject: I would like to get a copy of Common Loops. To: postmaster.PA Message-ID: <12283987420.53.MICHAEL@CS.COLUMBIA.EDU> Can you please put me in touch with whoever is handling this. Thanks, Michael ------- ----------------------------------------------------------------  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 5 Mar 87 15:04:08 EST Received: from HPLABS.HP.COM by SAIL.STANFORD.EDU with TCP; 5 Mar 87 11:57:34 PST Received: from hplabsc by hplabs.HP.COM ; Thu, 26 Feb 87 10:24:29 pst Received: by hplabsc ; Thu, 26 Feb 87 10:24:01 pst Date: Thu, 26 Feb 87 10:24:01 pst From: Jim Kempf Message-Id: <8702261824.AA08020@hplabsc> To: common-lisp-object-system@sail.stanford.edu Subject: 87-003 MetaObject Protocol I feel the major lack in this document is a clear statement of how one goes about defining and implementing a new metaclass. What protocol does a class need to support in order to be promotable to a metaclass via DEFINE-METACLASS? Does DEFINE-METACLASS even care, i.e. does it check before promoting a class? What types of slots? The answer to this question seems to be scattered about the document, so this is more a criticism of organization than content. An example defining a new metaclass would be helpful, but perhaps this document is not the place for it, but rather a "User's Manual" type document might be more appropriate. As in the programmer interface document, a major technical problem is lack of specification of compile time semantics. While the :COMPILE-TIME-HASH-TABLE keyword argument to CLASS-NAMED-FROM-METACLASS on pg. 3-14 provides a hook for maintaining information about partially defined classes at compile time, no such hook exists for methods. To give an example of how this can make implementation of a new metaclass difficult, consider my experience with implementing inheritence of methods in CommonObjects on CommonLoops (COOL). In COOL, CommonObjects inheritence is maintained orthogonally to CommonLoops inheritence, due to the nature of the encapsulation semantics specified by CommonObjects. But COOL depends on the PCL kernel to obtain information about what methods are defined on which classes (via CLASS-DIRECT-METHODS). Where the interaction between these two factors becomes a problem is in inheritence of methods. COOL determines at compile time what methods a subclass inherits from its supers since it needs to generate special code for inherited methods. However, the code generated by PCL for methods doesn't fully define the method until load time, as should be the case, since otherwise the compile time environment could be detrimentally side effected. This means that a CommonObjects super class and methods on the super class cannot be defined in the same file as a subclass, since the superclass methods won't be fully defined until load time and therefore won't be found during compilation for the subclass to inherit. To be fair, it would probably be possible to work around this problem through more extensive redefinition of the method handling portion of the PCL metaclass kernel, but it seems as if some means of maintaining partially defined method information, as with classes, could be designed to simplify implementing novel kinds of method inheritence. Additional examples of where compile time semantics may cause problems appear throughout the document. Consider the following description of class precedence list calculation on pg. 3-4: It is computed (just) before the first instance of this class is created, or when any method is defined on this class or any subclass. What effect (if any) does compilation have on the class precedence list? I can imagine cases where optimization of method lookup may require knowing the class precedence list at compile time, and where compilation of something may correspondingly cause the class precedence list to change. This could even be true for the default CLOS language; however, I think it is even more important that compile time semantics get pinned down in the metaobject protocol because the metaclass kernel is, in a certain sense, a means of modifying the compiler/evaluator. As a final point about the importance of nailing down compile time semantics, consider the possibility of portability problems developing. This is, in fact, currently the case with DEFSTRUCTs in Kyoto Common Lisp. Unless *compile time too* mode is turned on within KCL (the default), the SETF functions for DEFSTRUCT accessors don't get generated at compile time, and hence SETF's of DEFSTRUCT accessors don't expand properly. Turning on *compile time too* mode causes an implicit (EVAL-WHEN (COMPILE) ...) to be wrapped around the processing of top level forms, which can cause serious problems with embedded languages (like PCL) that require certain things (like full method definition) not get done at compile time but rather only at load time. One solution to this problem is simply to interpret the file before compiling, but that is pushing the portability problem back into the system building process. Minor points of fuzziness within the document: 1) pg. 3-3. A figure of the inheritence/instance relationship between the metaclass kernel classes would be most useful here. 2) pg 3-6. The description of INITFORM. Is INITFORM run in the context of a method? Is WITH-SLOTS valid within it? Again, as with the CLOS language, this should probably be pinned down along with the entire initialization protocol. 3) pg. 3-14. Description of SETF of class name. Does this go both ways, i.e. if I (SETF CLASS-NAME) then will CLASS-NAMED recognize the class under the new name? The last time I looked in PCL, this was not the case (though it may have changed). 4) pg. 3-18. Description of FUNCTION slot in METHOD class. Is this a fundef object (function pointer) or a symbol whose function cell is bound? 5) Section 2.2. The description of the relationship between the generic function classes and the method classes leaves me somehow uneasy. While I can't make a case for having one inherit from the other, it seems as if the relationship should be more intimate than the generic function classes simply having a slot for methods. Perhaps this can be handled by using inheritence from one of the generic function classes and having the SETF method distinguish which methods get put onto the slot. I am particularly concerned about having two co-existing metaclasses and users trying to define methods on the same symbol from both metaclasses. We currently handle this in COOL by convention, i.e. telling users to use PCL and COOL in the same package at their own risk. 6) pg. 3-21, and throughout the discussion of the generic function classes. I somehow have the feeling that having the generic function classes inherit from a standard type class FUNCTION would more elegently tie together the CLOS with Common Lisp, provided, of course, the questions raised by the discussion on having a class for FUCTION and the other types which were originally not on the list to have classes can be answered.  Received: from Xerox.COM (TCP 1200400040) by AI.AI.MIT.EDU 5 Mar 87 14:26:59 EST Received: from Cabernet.ms by ArpaGateway.ms ; 05 MAR 87 09:45:57 PST Return-Path: Received: from RELAY.CS.NET by Xerox.COM ; 05 MAR 87 09:44:34 PST Received: from relay2.cs.net by RELAY.CS.NET id aa08300; 5 Mar 87 12:39 EST Received: from germany by csnet-relay.csnet id ac02187; 5 Mar 87 12:33 EST Received: from ecrcvax by uka.uucp id aa04312; 5 Mar 87 17:19 MET Received: by ecrcvax.ecrc (4.12/4.7) id AA12471; Thu, 5 Mar 87 16:26:07 -0100 Date: Thu, 5 Mar 87 16:26:07 -0100 From: David McKelvie Message-Id: <8703051526.AA12471@ecrcvax.ecrc> To: germany!commonloops.pa%xerox.arpa%germany.csnet@RELAY.CS.NET Subject: Request for info on PCL Cc: david%ecrcvax.uucp%germany.csnet@RELAY.CS.NET, jack%ecrcvax.uucp%germany.csnet@RELAY.CS.NET Hi; Thanks for replying to my questionabout all-slots-using-class, I changed all-slots-using-class in the way suggested and it works fine. I sent the letter below to Germany\!CommonLoops-Coordinator.pa@Xerox.arpa and to Germany\!gregor.pa@Xerox.arpa and did'nt get a reply. Perhaps it did'nt get through, so I'll repeat it here. Thanks for adding me to the CommonLoops mailing list, I am finding it useful. In fact other people at ECRC are also interested in this mail, so we'd like to send the incoming mail to another name here. So, could you change david@ecrcvax to cl@ecrcvax on the mailing list? We at ECRC are trying to use CommonLoops on a Xerox 1100 machine with Koto and CML and are finding it hard work. Mainly because we have scanty documentation i.e. two papers by Bobrow et al which are seriously inaccurate. This mail contains a list of questions we have, and would be grateful for any helpful replies. The version we received was from Siemens in Germany as they sold us the machines. In the CommonLoops mailing list I hear of various versions of CommonLoops, I dont know what version we have, the variable *pcl-system-date* is not defined. The file kernel.l is dated 18 Sept 86. I suspect that we have an out-of-date version as you recommended using 'defclass' instead of 'ndefstruct'and that is not part of our system. Questions: Is there any proper documentation available on CommonLoops? If it is seriously intended as a trial standard then I think there should be. If there is, then how do we get it? Is there a mechanism for receiving new versions of CommonLoops? Has anyone written a class browser for CommonLoops, particularly one that works using the 1100 graphics? The CL system is very badly integrated with the normal Interlisp programming environment. What is the recommended way to develop CL programs on the 1100? The command compile-file does not work on files stored on a file-server as they must be RANDOMACCESSP. It is claimed that one can edit a class and add new slots, and that these new slots will then exist in instances of the class previously created. However this does not happen. Example: (ndefstruct (junk (:class class)) a ) (setq j1 (make 'junk :a 1)) (ndefstruct (junk (:class class)) a b) (junk-b j1) typed into a CL exec window gives the error message The slot B is missing from the object #(MAKE (QUOTE OBSOLETE-JUNK) :A 1) Thanks; david  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 5 Mar 87 10:47:40 EST Received: from HPLABS.HP.COM by SAIL.STANFORD.EDU with TCP; 5 Mar 87 07:39:51 PST Received: from hplabsc by hplabs.HP.COM with TCP ; Thu, 5 Mar 87 07:39:42 pst Received: by hplabsc ; Thu, 5 Mar 87 07:39:04 pst Date: Thu, 5 Mar 87 07:39:04 pst From: Jim Kempf Message-Id: <8703051539.AA15918@hplabsc> To: Bobrow.pa@Xerox.COM, RPG@SAIL.STANFORD.EDU Subject: Re: Meeting Monday Cc: common-lisp-object-system@SAIL.STANFORD.EDU >I would like to spend a significant part of it discussing the >meta-object protocol. What else is on the agenda. > danny > Yes, that is an excellent idea. I also think that initialization, change class, and inheritence of slot options should be on the agenda, if possible. In the event there isn't enough time for everything, my priorities for these three topics would be in the order listed. Jim Kempf