Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA21095; Mon, 8 May 89 16:32:37 -0700 Reply-To: Received: from Cabernet.ms by ArpaGateway.ms ; 08 MAY 89 09:36:33 PDT Return-Path: Redistributed: commonloops.pa Received: from cheops.cis.ohio-state.edu ([128.146.8.62]) by Xerox.COM ; 08 MAY 89 09:32:54 PDT Received: by cheops.cis.ohio-state.edu (5.59/2.890120) id AA29325; Mon, 8 May 89 12:32:45 EDT Date: Mon, 8 May 89 12:32:45 EDT From: Arun Welch Message-Id: <8905081632.AA29325@cheops.cis.ohio-state.edu> To: commonloops.pa@Xerox.COM Subject: Envos Medley & latest PCL Has anyone been able to bring it up under Medley? I'm getting an inconsistent stack depths break on compiling early-dfun, and thought I'd check before I start digging through the problem. ...arun Received: from Sail.Stanford.EDU by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA25216; Mon, 8 May 89 19:52:59 -0700 Reply-To: Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 8 May 89 19:48:53 PDT Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 591903; 8 May 89 22:49:23 EDT Date: Mon, 8 May 89 22:49 EDT From: David A. Moon Subject: DEFINE-METHOD-COMBINATION issues To: Common-Lisp-Object-System@sail.stanford.edu Cc: Scott Cyphers , SKeene@STONY-BROOK.SCRC.Symbolics.COM In-Reply-To: <19890508210229.5.CYPHERS@SEAR.SCRC.Symbolics.COM> Message-Id: <19890509024926.3.MOON@EUPHRATES.SCRC.Symbolics.COM> Here are some questions about unclarities in 88-002R revolving around method combination, along with my suggested answers. Any comments? I think I will try to use the eventual resolution of this to improve the writeup in the ANSI Common Lisp draft specification. Can CALL-NEXT-METHOD be called lexically within a MAKE-METHOD? p.2-12 says CALL-NEXT-METHOD can be used in the body of a method defined by a method-defining form, and 1-22 defines "method-defining form" and does not include MAKE-METHOD, so I think that CALL-NEXT-METHOD is not specified to work in MAKE-METHOD. The 2-12 text may have been meant to exclude methods created with the chapter 3 function MAKE-METHOD-LAMBDA, but in fact it's clear from the draft of chapter 3 that CALL-NEXT-METHOD does work in such methods. So I don't really know what the intent of 2-12 was, but I think it would be safe to assume that CALL-NEXT-METHOD need not be supported in MAKE-METHOD. Example: (call-method (make-method (or (frob) (call-next-method))) ,remaining-methods) could be rewritten: (or (frob) (call-method ,(first remaining-methods) ,(rest remaining-methods))) See additional discussion below. Does CALL-METHOD use the arguments of the effective method, or does it use the arguments of the MAKE-METHOD that it was a part of? For example, (DEFMETHOD CHANGE :AROUND (X &OPTIONAL (N 1)) (CALL-NEXT-METHOD X (MIN N 0))) (DEFMETHOD CHANGE (X &OPTIONAL (N 2)) N) What does (CHANGE T 5) return? A strict reading of the spec says 5, but my intuition says 0, and 0 is a lot easier to implement. If this is standard method combination, and there are no other methods, the effective method is (call-method <:around method> ((make-method (call-method )))) and the target of the CALL-NEXT-METHOD is the MAKE-METHOD. p.2-11: "The arguments are the arguments that were supplied to the effective method form containing the invocation of CALL-METHOD." But this is ambiguous, does "the effective method form" mean the whole thing, or just the part containing the invocation of CALL-METHOD? If it had meant the whole thing, I think it would have said "the arguments that were supplied to the generic function". Also it makes more sense that once call-next-method changes the arguments, they don't "randomly" change back to the original arguments. So I think the example returns 0. I propose to change the text on p.2-11 to say "The arguments are the arguments that were supplied to the innermost MAKE-METHOD-created method enclosing the invocation of CALL-METHOD, or if there is no MAKE-METHOD, the arguments that were supplied to the generic function." I'd like to say this in fewer words, but couldn't think of a way. Is the effective method code a real Lisp form, i.e. can it contain forms which require closures, like: (BLOCK TOO-DEEP (CALL-METHOD ,(FIRST PRE-METHODS) (,@(REST PRE-METHODS) (MAKE-METHOD (RETURN-FROM TOO-DEEP NIL)))) (CALL-METHOD ,(FIRST POST-METHODS) (,@(REST POST-METHODS) (MAKE-METHOD T)))) Nothing in chapter 1 or 2 mentions any restrictions on what the effective method form can do, so the answer should be yes. The problem is that the description of MAKE-METHOD (p.2-11) fails to specify the lexical environment of the form its given. Nor does anything specify the lexical environment of the overall effective method form. After thinking about it a bit, I believe the intention was that both of these forms are in the null lexical environment. Thus the answer is that this example code is not valid. Unless there are further comments, I propose to change the ANSI Common Lisp specification to say both effective method forms and MAKE-METHOD forms are in the null lexical environment. Note that this implies no CALL-NEXT-METHOD inside of MAKE-METHOD. And no CONTINUE-WHOPPER inside of a DEFWRAPPER, to translate back to Flavors terminology. In 12/15/88 MOP Draft number 10, some places seem to think that a METHOD-COMBINATION object consists of the information supplied to DEFGENERIC (with a mysterious "Documentation" slot), and other places seem to think that it consists of the information supplied to DEFINE-METHOD-COMBINATION, but the slots only make sense for the short form. The MOP draft is not part of the spec. The relevant text from 89-002R is A method for {\bf compute-effective-method} can be defined directly by using {\bf defmethod} or indirectly by using {\bf define-method-combination}. A {\bit method combination object} is an object that encapsulates the method combination type and options specified by the {\bf :method-combination} option to forms that specify generic function options. \item{\bull} Every method combination object is an instance of a subclass of the class {\bf method-combination}. The {\bf :method-combination} argument [to ensure-generic-function] is a method combination object. The first argument of {\bf documentation} is either a symbol, a function specifier list of the form {\tt (setf {\it symbol\/})}, a method object, a class object, a generic function object, a method combination object, or a slot description object. The form {\tt (documentation {\it symbol\/} 'method-combination)} returns the documentation string of the method combination type named by the symbol. Note: method combination type, not method combination object. I think this makes it clear that the role of a method combination object is to hold the information obtained by parsing the :METHOD-COMBINATION option to DEFGENERIC. The division of labor between slots in the method combination object, methods for compute-effective-method applicable to the method combination object, and methods for other generic functions applicable to the method combination object, is not specified in 88-002R. It might be specified in chapter 3 (but probably won't be). The documentation mentioned on p.3-8 is the same documentation you would get by first extracting the method combination type symbol and then calling the function DOCUMENTATION with two arguments, that symbol and the symbol METHOD-COMBINATION. Chapter 3 is not supposed to specify the existence of any slots for any meta objects. I couldn't find anything about slots of method combination objects, but I didn't look real hard since the MOP draft is not part of the language specification. I'm not sure that any documentation change is required to clarify this. If a method gets redefined, do the effective methods get destructively modified or do new ones get created to take their place? For example, (DEFMETHOD STRANGE (X) (LOOP (CALL-NEXT-METHOD) (REMOVE-METHOD ..some strange method..))) does the CALL-NEXT-METHOD continue to see the next methods as they were when strange was entered, or does each time around the loop see something different, or is this undefined? Common Lisp rarely specifies what happens if programs modify themselves. I think the results should be undefined. I would expect that most implementations would capture the next methods at the time the generic function was called, so modifications would not be seen, but some implementations might let the modifications be seen, either because they are not optimized at all, or because they are highly optimized and reuse some storage. I'm not sure that any documentation change is required to clarify this. When the :ARGUMENTS option is used with DEFINE-METHOD-COMBINATION, how do the arguments get matched up with the actual arguments of the generic function? The issue here is that p.2-34 says "If lambda-list is not congruent to the generic function's lambda-list, additional ignored parameters are automatically inserted until it is congruent", but this doesn't say where they are inserted nor what happens if inserting additional parameters can't make it congruent (e.g. too many required parameters to begin with). Are they inserted at the end? At the end of each group (required, optional, keyword)? At the beginning?? We thought about simplifying this to just require the two lambda-lists to be congruent, but that doesn't work well since a single method combination type should be useable with many different generic functions with different lambda-lists. I think the best answer is to delete the stuff about congruence (the last two sentences of the first paragraph on p.2-34) and simply say what happens if the arguments supplied to the generic function don't match the lambda-list: if there are too few arguments, NIL is assumed for missing arguments. If there are too many arguments, the extra arguments are ignored. If there are unhandled keyword arguments, they are ignored. Supplied-p parameters work in the normal fashion. Default value forms are evaluated in the null lexical environment (except for bindings of :ARGUMENTS parameters to their left, of course). This is more or less what the equivalent Flavors feature does. Any objections? Also, what happens if the effective method form returned by your body forms includes (setq ,variable ...) or (setf ,variable ...), where variable is one of the :ARGUMENTS parameters? I think the consequences should be undefined. Does CALL-METHOD take the original arguments, the way CALL-NEXT-METHOD with no arguments does, or does the method combiner get a chance to change things around, perhaps supplying a default for an optional or something? CALL-METHOD uses the original arguments, as clearly documented. The extension to CALL-METHOD to allow specifying arguments, as in CALL-NEXT-METHOD, was rejected by the committee, I don't remember if it was for a good reason. No way is provided for the effective method form to change the original arguments. Perhaps the first paragraph in the arguments section of CALL-NEXT-METHOD, which says you can't change the original arguments, should be repeated under CALL-METHOD or under DEFINE-METHOD-COMBINATION. Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA28602; Tue, 9 May 89 00:13:00 -0700 Reply-To: Received: from Cabernet.ms by ArpaGateway.ms ; 09 MAY 89 00:14:09 PDT Return-Path: Redistributed: commonloops.pa Received: from fs3.cs.rpi.edu ([128.213.1.14]) by Xerox.COM ; 09 MAY 89 00:10:58 PDT Received: by fs3.cs.rpi.edu (5.54/1.2-RPI-CS-Dept) id AA00167; Tue, 9 May 89 03:05:36 EDT Date: Tue, 9 May 89 03:05:36 EDT From: harrisr@turing.cs.rpi.edu (Richard Harris) Received: by turing.cs.rpi.edu (4.0/1.2-RPI-CS-Dept) id AA24293; Tue, 9 May 89 03:05:36 EDT Message-Id: <8905090705.AA24293@turing.cs.rpi.edu> To: gregor.pa@Xerox.COM Subject: bugs in early-dfun Cc: commonloops.pa@Xerox.COM In order to get "5/5/89 Cinco de Mayo PCL" to compile, I needed to fix two bugs in early-dfun (boot.lisp): 1) The sort predicate expects two lists of classes, not lists of class names. - Before I fixed problem 1, PCL died in check-super-metaclass-compatibility, (while defining the class standard-generic-function, while evaluating *methods-defclass-forms* in methods.lisp), because early-dfun picked the wrong primary method for check-super-metaclass-compatibility. - After fixing problem 1, PCL died with in slot-boundp-using-class, (while checking a slot of the generic function all-std-class-readers-miss-1, while running fix-early-generic-functions in fixup.lisp), because early-dfun picked the wrong primary method for slot-boundp-using-class. 2) The sort predicate returned the opposite of the correct answer when neither class was *the-class-t*. Rick Harris (defun early-dfun (methods args) (let ((primary ()) (before ()) (after ())) (flet ((get-cpl (object) (if (symbolp object) (list *the-class-symbol* *the-class-t*) (bootstrap-get-slot 'class (class-of object) 'class-precedence-list))) (early-method-specializers1 (method) (early-method-specializers method t))) (dolist (method methods) (let* ((specializers (early-method-specializers1 method)) (qualifiers (early-method-qualifiers method)) (args args) (specs specializers)) (when (loop (when (or (null args) (null specs)) ;; If we are out of specs, then we must be in the optional, ;; rest or keywords arguments. This method is applicable ;; to these arguments. Return T. (return t)) (let ((arg (pop args)) (spec (pop specs))) (unless (or (eq spec *the-class-t*) (memq spec (get-cpl arg))) (return nil)))) (cond ((null qualifiers) (push method primary)) ((equal qualifiers '(:before)) (push method before)) ((equal qualifiers '(:after)) (push method after)) (t (error "Unrecognized qualifer in early method.")))))) (flet ((sort-methods (list) (if (null (cdr list)) list (sort list #'(lambda (specls-1 specls-2) (iterate ((s1 (list-elements specls-1)) (s2 (list-elements specls-2)) (a (list-elements args))) (cond ((eq s1 s2)) ((eq s2 *the-class-t*) (return t)) ((eq s1 *the-class-t*) (return nil)) (t (return (memq s2 (memq s1 (get-cpl a)))))))) :key #'early-method-specializers1)))) (dolist (m (sort-methods before)) (apply (cadr m) args)) (multiple-value-prog1 (apply (cadar (sort-methods primary)) args) (dolist (m (sort-methods after)) (apply (cadr m) args))))))) Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA29359; Tue, 9 May 89 01:55:05 -0700 Reply-To: Received: from Salvador.ms by ArpaGateway.ms ; 09 MAY 89 01:56:24 PDT Return-Path: <@mirsa.inria.fr:dvorak@iam.unibe.ch> Redistributed: CommonLoops.pa Received: from mirsa.inria.fr ([192.5.60.96]) by Xerox.COM ; 09 MAY 89 01:55:08 PDT Received: from kwai.inria.fr by mirsa.inria.fr with SMTP (5.59++/IDA-1.2.8) id AA25699; Tue, 9 May 89 10:56:48 +0200 Received: by aristote.fr with X.400; 09 May 89 08:56:06+0100 Received: by ch; 09 May 89 10:52:31+0100 Date: 09 May 89 10:52:31+0100 From: Jiri Dvorak To: Subject: Pattern matching Message-Id: <405*dvorak@iam.unibe.ch> Is there a nice way to implement a pattern matcher in PCL that deals with patterns of the form: (object slot value) where at every position variables are allowed? I.e. the pattern matcher should be able to find all objects with a given value in a given slot, or find all slots of a given object, etc. Many thanks, Jiri Dvorak dvorak@iam.unibe.ch or Institute for Informatics dvorak%iam.unibe.ch@relay.cs.net University of Berne UUCP: ..!uunet!mcvax!iam.unibe.ch!dvorak Switzerland Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA12017; Tue, 9 May 89 16:52:47 -0700 Reply-To: Received: from Semillon.ms by ArpaGateway.ms ; 09 MAY 89 16:49:49 PDT Return-Path: Redistributed: commonloops.pa Received: from DINO.BBN.COM ([128.89.3.8]) by Xerox.COM ; 09 MAY 89 14:01:50 PDT To: Gregor.pa@Xerox.COM Cc: Darrell , commonloops.pa@Xerox.COM, Stephanie_Cammarata Subject: Re: Changing the :metaclass of a class In-Reply-To: Your message of Tue, 02 May 89 10:06:00 -0700. <19890502170618.0.GREGOR@SPIFF.parc.xerox.com> Date: Tue, 09 May 89 17:09:07 -0400 From: kanderso@DINO.BBN.COM Message-Id: <890509-164949-3087@Xerox> Received: from Semillon.ms by ArpaGateway.ms ; 02 MAY 89 10:15:12 PDT Date: Tue, 2 May 89 10:06 PDT From: Gregor.pa@xerox.com Subject: Re: Changing the :metaclass of a class To: Darrell Cc: commonloops.pa@xerox.com, Stephanie_Cammarata Fcc: BD:>Gregor>mail>outgoing-mail-6.text.newest In-Reply-To: <8905011955.AA05406@blackcomb.arpa> Message-Id: <19890502170618.0.GREGOR@SPIFF.parc.xerox.com> Line-Fold: no Date: Mon, 01 May 89 12:55:17 PDT From: Darrell ;;; Why is it that when I change the :metaclass of a class, ;;; the class instance is not changed? For example: This is because of a structural bug in PCL. Unfortunately, this won't be fixed in this week's release. It should be fixed this month though. Note that in almost all cases, you can just use change-class by hand on the class object. ------- I had a patch for this in the Cute version of PCL, that I forgot to mention to anyone. This might work ok until Gregor fixes it. ;;; ;;; Patch std-class.lisp ;;; KRA 89/3/30: Let class-change happen if the metaclass of a class changes. ;;; ;;; CLASS-FOR-REDEFINITION old-class proto-class name ds-options slotds ;;; protocol: class definition ;;; ;;; When a class is being defined, and a class with that name already exists ;;; a decision must be made as to what to use for the new class object, and ;;; whether to update the old class object. For this, class-for-redefinition ;;; is called with the old class object, the prototype of the new class, and ;;; the name ds-options and slotds corresponding to the new definition. ;;; It should return the class object to use as the new definition. It is ;;; OK for this to be old-class if that is appropriate. ;;; (defmethod class-for-redefinition ((old-class standard-class) (proto-class standard-class) name local-supers local-slot-slotds extra) (declare (ignore name local-supers local-slot-slotds extra)) (UNLESS (EQ (CLASS-OF OLD-CLASS) (CLASS-OF PROTO-CLASS)) (CHANGE-CLASS OLD-CLASS (CLASS-OF PROTO-CLASS))) old-class) Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA12280; Tue, 9 May 89 17:08:55 -0700 Reply-To: Received: from Cabernet.ms by ArpaGateway.ms ; 09 MAY 89 16:52:41 PDT Return-Path: Redistributed: commonloops.pa Received: from DINO.BBN.COM ([128.89.3.8]) by Xerox.COM ; 09 MAY 89 14:02:32 PDT To: Gregor.pa@Xerox.COM Cc: Darrell , commonloops.pa@Xerox.COM, Stephanie_Cammarata Subject: Re: Changing the :metaclass of a class In-Reply-To: Your message of Tue, 02 May 89 10:06:00 -0700. <19890502170618.0.GREGOR@SPIFF.parc.xerox.com> Date: Tue, 09 May 89 17:09:46 -0400 From: kanderso@DINO.BBN.COM Message-Id: <890509-165241-3098@Xerox> Received: from Semillon.ms by ArpaGateway.ms ; 02 MAY 89 10:15:12 PDT Date: Tue, 2 May 89 10:06 PDT From: Gregor.pa@xerox.com Subject: Re: Changing the :metaclass of a class To: Darrell Cc: commonloops.pa@xerox.com, Stephanie_Cammarata Fcc: BD:>Gregor>mail>outgoing-mail-6.text.newest In-Reply-To: <8905011955.AA05406@blackcomb.arpa> Message-Id: <19890502170618.0.GREGOR@SPIFF.parc.xerox.com> Line-Fold: no Date: Mon, 01 May 89 12:55:17 PDT From: Darrell ;;; Why is it that when I change the :metaclass of a class, ;;; the class instance is not changed? For example: This is because of a structural bug in PCL. Unfortunately, this won't be fixed in this week's release. It should be fixed this month though. Note that in almost all cases, you can just use change-class by hand on the class object. ------- I had a patch for this in the Cute version of PCL, that I forgot to mention to anyone. This might work ok until Gregor fixes it. ;;; ;;; Patch std-class.lisp ;;; KRA 89/3/30: Let class-change happen if the metaclass of a class changes. ;;; ;;; CLASS-FOR-REDEFINITION old-class proto-class name ds-options slotds ;;; protocol: class definition ;;; ;;; When a class is being defined, and a class with that name already exists ;;; a decision must be made as to what to use for the new class object, and ;;; whether to update the old class object. For this, class-for-redefinition ;;; is called with the old class object, the prototype of the new class, and ;;; the name ds-options and slotds corresponding to the new definition. ;;; It should return the class object to use as the new definition. It is ;;; OK for this to be old-class if that is appropriate. ;;; (defmethod class-for-redefinition ((old-class standard-class) (proto-class standard-class) name local-supers local-slot-slotds extra) (declare (ignore name local-supers local-slot-slotds extra)) (UNLESS (EQ (CLASS-OF OLD-CLASS) (CLASS-OF PROTO-CLASS)) (CHANGE-CLASS OLD-CLASS (CLASS-OF PROTO-CLASS))) old-class) Received: from [13.0.12.232] by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA16959; Tue, 9 May 89 22:28:25 -0700 Reply-To: Received: from Chardonnay.ms by ArpaGateway.ms ; 09 MAY 89 22:23:27 PDT Return-Path: Redistributed: commonloops.pa Received: from IBM.COM ([192.5.58.7]) by Xerox.COM ; 09 MAY 89 16:20:06 PDT Date: Tue, 09 May 89 11:04:59 PDT From: David Alpern To: commonloops.pa@Xerox.COM Message-Id: <890509-222327-3749@Xerox> PCL seems to do some compilation (i.e., invokes lisp's compiler) as programs begin to run (first create objects, perhaps?), even if the lisp program files have been compiled first. Is there some way to cause whatever compilation is going on to occur during the lisp program file compilation and get captured in the compiled form? I'm running the 12/7/88 release on LUCID on an IBM RT. - Dave Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA12280; Tue, 9 May 89 17:08:55 -0700 Reply-To: Received: from Cabernet.ms by ArpaGateway.ms ; 09 MAY 89 16:52:41 PDT Return-Path: Redistributed: commonloops.pa Received: from DINO.BBN.COM ([128.89.3.8]) by Xerox.COM ; 09 MAY 89 14:02:32 PDT To: Gregor.pa@Xerox.COM Cc: Darrell , commonloops.pa@Xerox.COM, Stephanie_Cammarata Subject: Re: Changing the :metaclass of a class In-Reply-To: Your message of Tue, 02 May 89 10:06:00 -0700. <19890502170618.0.GREGOR@SPIFF.parc.xerox.com> Date: Tue, 09 May 89 17:09:46 -0400 From: kanderso@DINO.BBN.COM Message-Id: <890509-165241-3098@Xerox> Received: from Semillon.ms by ArpaGateway.ms ; 02 MAY 89 10:15:12 PDT Date: Tue, 2 May 89 10:06 PDT From: Gregor.pa@xerox.com Subject: Re: Changing the :metaclass of a class To: Darrell Cc: commonloops.pa@xerox.com, Stephanie_Cammarata Fcc: BD:>Gregor>mail>outgoing-mail-6.text.newest In-Reply-To: <8905011955.AA05406@blackcomb.arpa> Message-Id: <19890502170618.0.GREGOR@SPIFF.parc.xerox.com> Line-Fold: no Date: Mon, 01 May 89 12:55:17 PDT From: Darrell ;;; Why is it that when I change the :metaclass of a class, ;;; the class instance is not changed? For example: This is because of a structural bug in PCL. Unfortunately, this won't be fixed in this week's release. It should be fixed this month though. Note that in almost all cases, you can just use change-class by hand on the class object. ------- I had a patch for this in the Cute version of PCL, that I forgot to mention to anyone. This might work ok until Gregor fixes it. ;;; ;;; Patch std-class.lisp ;;; KRA 89/3/30: Let class-change happen if the metaclass of a class changes. ;;; ;;; CLASS-FOR-REDEFINITION old-class proto-class name ds-options slotds ;;; protocol: class definition ;;; ;;; When a class is being defined, and a class with that name already exists ;;; a decision must be made as to what to use for the new class object, and ;;; whether to update the old class object. For this, class-for-redefinition ;;; is called with the old class object, the prototype of the new class, and ;;; the name ds-options and slotds corresponding to the new definition. ;;; It should return the class object to use as the new definition. It is ;;; OK for this to be old-class if that is appropriate. ;;; (defmethod class-for-redefinition ((old-class standard-class) (proto-class standard-class) name local-supers local-slot-slotds extra) (declare (ignore name local-supers local-slot-slotds extra)) (UNLESS (EQ (CLASS-OF OLD-CLASS) (CLASS-OF PROTO-CLASS)) (CHANGE-CLASS OLD-CLASS (CLASS-OF PROTO-CLASS))) old-class) Received: from Sail.Stanford.EDU by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA27897; Wed, 10 May 89 10:16:26 -0700 Reply-To: Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 10 May 89 10:16:47 PDT Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 592824; 10 May 89 13:16:51 EDT Date: Wed, 10 May 89 13:17 EDT From: David A. Moon Subject: editorial correction to CLOS stuff To: chapman%aitg.dec@decwrl.dec.com Cc: common-lisp-object-system@sail.stanford.edu Message-Id: <19890510171702.9.MOON@EUPHRATES.SCRC.Symbolics.COM> I think this is small enough that it doesn't need to go through the X3J13 cleanup process. If anyone disagrees please let me know. Kathy: I assume this text migrated into the X3J13 draft specification, although I didn't find it in an excessively quick look through the parts that happened to be in my office. If no one objects, could you update it? Page 1-15 of 88-002R says Each class that corresponds to a predefined Common Lisp type specifier can be implemented in one of three ways, at the discretion of each implementation. It can be a {\bit standard class\/} (of the kind defined by {\bf defclass}), a {\bit structure class\/} (defined by {\bf defstruct}), or a {\bit built-in class\/} (implemented in a special, non-extensible way). This can be interpreted to mean that the metaclass of an object of a predefined Common Lisp type can only be one of standard-class, structure-class, or built-in-class, and no others. I don't think that was intended. I don't think it was even intended that the metaclass must be a subclass of one of those classes. One example where this came up is an implementation with Flavors, that implements some predefined Common Lisp types using Flavors. The metaclass of a Flavors instance is certainly not any of those three. I would change that paragraph to read Each class that corresponds to a predefined Common Lisp type specifier can be implemented in one of four ways, at the discretion of each implementation. It can be a {\bit standard class\/} (of the kind defined by {\bf defclass}), a {\bit structure class\/} (defined by {\bf defstruct}), a {\bit built-in class\/} (implemented in a special, non-extensible way), or some other implementation-defined class. The paragraphs after it don't need to be changed. Received: from Sail.Stanford.EDU by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA28104; Wed, 10 May 89 10:30:29 -0700 Reply-To: Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 10 May 89 10:30:52 PDT Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 592837; 10 May 89 13:31:11 EDT Date: Wed, 10 May 89 13:31 EDT From: David A. Moon Subject: editorial correction to CLOS stuff To: chapman%aitg.dec@decwrl.dec.com Cc: common-lisp-object-system@sail.stanford.edu Supersedes: <19890510171702.9.MOON@EUPHRATES.SCRC.Symbolics.COM> Comments: Changed the wording after thinking about it over lunch Message-Id: <19890510173122.0.MOON@EUPHRATES.SCRC.Symbolics.COM> I think this is small enough that it doesn't need to go through the X3J13 cleanup process. If anyone disagrees please let me know. Kathy: I assume this text migrated into the X3J13 draft specification, although I didn't find it in an excessively quick look through the parts that happened to be in my office. If no one objects, could you update it? Page 1-15 of 88-002R says Each class that corresponds to a predefined Common Lisp type specifier can be implemented in one of three ways, at the discretion of each implementation. It can be a {\bit standard class\/} (of the kind defined by {\bf defclass}), a {\bit structure class\/} (defined by {\bf defstruct}), or a {\bit built-in class\/} (implemented in a special, non-extensible way). This can be interpreted to mean that the metaclass of an object of a predefined Common Lisp type can only be one of standard-class, structure-class, or built-in-class, and no others. I don't think that was intended. I don't think it was even intended that the metaclass must be a subclass of one of those classes. One example where this came up is an implementation with Flavors, that implements some predefined Common Lisp types using Flavors. The metaclass of a Flavors instance is certainly not any of those three. I would change that paragraph to read Each class that corresponds to a predefined Common Lisp type specifier can be implemented in one of four ways, at the discretion of each implementation. It can be a {\bit standard class\/} (of the kind defined by {\bf defclass}), a {\bit structure class\/} (defined by {\bf defstruct}), a {\bit built-in class\/} (implemented in a special, non-extensible way), or any other implementation-defined class that is no more restrictive than a {\bit built-in class\/}. The paragraphs after it don't need to be changed. Received: from Sail.Stanford.EDU by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA29086; Wed, 10 May 89 11:31:09 -0700 Reply-To: Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 10 May 89 11:31:13 PDT Received: from Semillon.ms by ArpaGateway.ms ; 10 MAY 89 11:30:15 PDT Date: Wed, 10 May 89 11:29 PDT From: Gregor.pa@Xerox.COM Subject: Re: editorial correction to CLOS stuff To: David A. Moon Cc: chapman%aitg.dec@decwrl.dec.com, common-lisp-object-system@sail.stanford.edu Fcc: BD:>Gregor>mail>outgoing-mail-6.text.newest In-Reply-To: <19890510171702.9.MOON@EUPHRATES.SCRC.Symbolics.COM> Message-Id: <19890510182921.0.GREGOR@SPIFF.parc.xerox.com> Line-Fold: no I agree this change is fine and should just be put in. ------- Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA29429; Wed, 10 May 89 11:43:31 -0700 Reply-To: Received: from Semillon.ms by ArpaGateway.ms ; 10 MAY 89 11:44:14 PDT Date: Wed, 10 May 89 11:41 PDT From: Gregor.pa@Xerox.COM Subject: new Cinco de Mayo PCL To: CommonLoops.PA@Xerox.COM Fcc: BD:>Gregor>mail>outgoing-mail-6.text.newest Message-Id: <19890510184127.2.GREGOR@SPIFF.parc.xerox.com> Line-Fold: no There is a new version of PCL on arisia.xerox.com. This version is still called "Cinco de Mayo PCL". It fixes some version skew problems we had that made Cinco de Mayo PCL not work. This version has been tested in Genera 7.4, Lucid 3.0, Allegro 3.0, Coral 1.2.2 and IBCL 01/01. I believe it works in Golden 3.1, please check this out and let me know. ------- Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA29429; Wed, 10 May 89 11:43:31 -0700 Reply-To: Received: from Semillon.ms by ArpaGateway.ms ; 10 MAY 89 11:44:14 PDT Date: Wed, 10 May 89 11:41 PDT From: Gregor.pa@Xerox.COM Subject: new Cinco de Mayo PCL To: CommonLoops.PA@Xerox.COM Fcc: BD:>Gregor>mail>outgoing-mail-6.text.newest Message-Id: <19890510184127.2.GREGOR@SPIFF.parc.xerox.com> Line-Fold: no There is a new version of PCL on arisia.xerox.com. This version is still called "Cinco de Mayo PCL". It fixes some version skew problems we had that made Cinco de Mayo PCL not work. This version has been tested in Genera 7.4, Lucid 3.0, Allegro 3.0, Coral 1.2.2 and IBCL 01/01. I believe it works in Golden 3.1, please check this out and let me know. ------- Received: from Sail.Stanford.EDU by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA03373; Wed, 10 May 89 15:43:34 -0700 Reply-To: Received: from lucid.com by SAIL.Stanford.EDU with TCP; 10 May 89 15:43:23 PDT Received: from challenger ([192.9.200.17]) by heavens-gate.lucid.com id AA02737g; Wed, 10 May 89 15:42:36 PDT Received: by challenger id AA01373g; Wed, 10 May 89 15:42:18 PDT Date: Wed, 10 May 89 15:42:18 PDT From: Patrick Dussud Message-Id: <8905102242.AA01373@challenger> To: Moon@STONY-BROOK.SCRC.Symbolics.COM Cc: Common-Lisp-Object-System@sail.stanford.edu, Cyphers@JASPER.SCRC.Symbolics.COM, SKeene@STONY-BROOK.SCRC.Symbolics.COM In-Reply-To: David A. Moon's message of Mon, 8 May 89 22:49 EDT <19890509024926.3.MOON@EUPHRATES.SCRC.Symbolics.COM> Subject: DEFINE-METHOD-COMBINATION issues Date: Mon, 8 May 89 22:49 EDT From: David A. Moon Here are some questions about unclarities in 88-002R revolving around method combination, along with my suggested answers. Any comments? I think I will try to use the eventual resolution of this to improve the writeup in the ANSI Common Lisp draft specification. Can CALL-NEXT-METHOD be called lexically within a MAKE-METHOD? p.2-12 says CALL-NEXT-METHOD can be used in the body of a method defined by a method-defining form, and 1-22 defines "method-defining form" and does not include MAKE-METHOD, so I think that CALL-NEXT-METHOD is not specified to work in MAKE-METHOD. The 2-12 text may have been meant to exclude methods created with the chapter 3 function MAKE-METHOD-LAMBDA, but in fact it's clear from the draft of chapter 3 that CALL-NEXT-METHOD does work in such methods. So I don't really know what the intent of 2-12 was, but I think it would be safe to assume that CALL-NEXT-METHOD need not be supported in MAKE-METHOD. Example: (call-method (make-method (or (frob) (call-next-method))) ,remaining-methods) could be rewritten: (or (frob) (call-method ,(first remaining-methods) ,(rest remaining-methods))) See additional discussion below. Does CALL-METHOD use the arguments of the effective method, or does it use the arguments of the MAKE-METHOD that it was a part of? For example, (DEFMETHOD CHANGE :AROUND (X &OPTIONAL (N 1)) (CALL-NEXT-METHOD X (MIN N 0))) (DEFMETHOD CHANGE (X &OPTIONAL (N 2)) N) What does (CHANGE T 5) return? A strict reading of the spec says 5, but my intuition says 0, and 0 is a lot easier to implement. If this is standard method combination, and there are no other methods, the effective method is (call-method <:around method> ((make-method (call-method )))) and the target of the CALL-NEXT-METHOD is the MAKE-METHOD. p.2-11: "The arguments are the arguments that were supplied to the effective method form containing the invocation of CALL-METHOD." But this is ambiguous, does "the effective method form" mean the whole thing, or just the part containing the invocation of CALL-METHOD? If it had meant the whole thing, I think it would have said "the arguments that were supplied to the generic function". Also it makes more sense that once call-next-method changes the arguments, they don't "randomly" change back to the original arguments. So I think the example returns 0. I propose to change the text on p.2-11 to say "The arguments are the arguments that were supplied to the innermost MAKE-METHOD-created method enclosing the invocation of CALL-METHOD, or if there is no MAKE-METHOD, the arguments that were supplied to the generic function." I'd like to say this in fewer words, but couldn't think of a way. I makes sense. I think that is the right thing to do. Is the effective method code a real Lisp form, i.e. can it contain forms which require closures, like: (BLOCK TOO-DEEP (CALL-METHOD ,(FIRST PRE-METHODS) (,@(REST PRE-METHODS) (MAKE-METHOD (RETURN-FROM TOO-DEEP NIL)))) (CALL-METHOD ,(FIRST POST-METHODS) (,@(REST POST-METHODS) (MAKE-METHOD T)))) Nothing in chapter 1 or 2 mentions any restrictions on what the effective method form can do, so the answer should be yes. The problem is that the description of MAKE-METHOD (p.2-11) fails to specify the lexical environment of the form its given. Nor does anything specify the lexical environment of the overall effective method form. After thinking about it a bit, I believe the intention was that both of these forms are in the null lexical environment. Thus the answer is that this example code is not valid. Unless there are further comments, I propose to change the ANSI Common Lisp specification to say both effective method forms and MAKE-METHOD forms are in the null lexical environment. Note that this implies no CALL-NEXT-METHOD inside of MAKE-METHOD. And no CONTINUE-WHOPPER inside of a DEFWRAPPER, to translate back to Flavors terminology. The only comment I have is that I don't know if it is going to be seen as a drastic constraint or not. I'd like to see others opinion on this. In 12/15/88 MOP Draft number 10, some places seem to think that a METHOD-COMBINATION object consists of the information supplied to DEFGENERIC (with a mysterious "Documentation" slot), and other places seem to think that it consists of the information supplied to DEFINE-METHOD-COMBINATION, but the slots only make sense for the short form. I agree with what was said and I don't think we need to change the document. The issue here is that p.2-34 says "If lambda-list is not congruent to the generic function's lambda-list, additional ignored parameters are automatically inserted until it is congruent", but this doesn't say where they are inserted nor what happens if inserting additional parameters can't make it congruent (e.g. too many required parameters to begin with). Are they inserted at the end? At the end of each group (required, optional, keyword)? At the beginning?? We thought about simplifying this to just require the two lambda-lists to be congruent, but that doesn't work well since a single method combination type should be useable with many different generic functions with different lambda-lists. I think the best answer is to delete the stuff about congruence (the last two sentences of the first paragraph on p.2-34) and simply say what happens if the arguments supplied to the generic function don't match the lambda-list: if there are too few arguments, NIL is assumed for missing arguments. If there are too many arguments, the extra arguments are ignored. If there are unhandled keyword arguments, they are ignored. Supplied-p parameters work in the normal fashion. Default value forms are evaluated in the null lexical environment (except for bindings of :ARGUMENTS parameters to their left, of course). This is more or less what the equivalent Flavors feature does. Any objections? Also, what happens if the effective method form returned by your body forms includes (setq ,variable ...) or (setf ,variable ...), where variable is one of the :ARGUMENTS parameters? I think the consequences should be undefined. All of this sound good. Received: from Sail.Stanford.EDU by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA16108; Thu, 11 May 89 06:29:35 -0700 Reply-To: Received: from lucid.com by SAIL.Stanford.EDU with TCP; 11 May 89 06:30:07 PDT Received: from bhopal ([192.43.178.13]) by heavens-gate.lucid.com id AA03361g; Thu, 11 May 89 06:29:07 PDT Received: by bhopal id AA04911g; Thu, 11 May 89 06:28:56 PDT Date: Thu, 11 May 89 06:28:56 PDT From: Jon L White Message-Id: <8905111328.AA04911@bhopal> To: Moon@STONY-BROOK.SCRC.Symbolics.COM Cc: chapman%aitg.dec@decwrl.dec.com, common-lisp-object-system@sail.stanford.edu In-Reply-To: David A. Moon's message of Wed, 10 May 89 13:31 EDT <19890510173122.0.MOON@EUPHRATES.SCRC.Symbolics.COM> Subject: Random metaclasses for CL types re: . . . or any other implementation-defined class that is no more restrictive than a {\bit built-in class\/}. I liked your first version better -- I don't remember 88-002R having a well-ordered scale for "restrictiveness" of metaclasses, so this phrase (for me) causes much more confusion than it clears up. But it's not a big point. On a related theme -- I was wondering if everyone agrees that the following is also permitted by "Integrating Types And Classes" section. An implementation may have a subset of some built-in class being implemented by a different meta-class than the rest of the set. For example, in most implementations we probably have: (class-name (class-of (find-class 'integer))) --> BUILT-IN-CLASS But some implementation might also have a FIXNUM class such that: (class-name (class-of (find-class 'fixnum))) --> FAST-ARITH-CLASS where FAST-ARITH-CLASS is not a subclass of BUILT-IN-CLASS. Of course, the FIXNUM class is a still a subclass of INTEGER. [don't take this example too seriously -- I'm more concerned about subclasses of the FUNCTION class.] Assuming that this is legit, then I guess the point you are trying to clear up is whether or not it is valid for the subset to be the whole set -- i.e., some CL type is wholly implemented by a moderately random metaclass. -- JonL -- Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA27415; Thu, 11 May 89 14:56:07 -0700 Reply-To: Received: from Semillon.ms by ArpaGateway.ms ; 11 MAY 89 14:55:00 PDT Return-Path: Redistributed: commonloops.pa Received: from neptune.CS.UCLA.EDU ([131.179.128.32]) by Xerox.COM ; 11 MAY 89 13:53:27 PDT Return-Path: Received: from LocalHost by neptune.CS.UCLA.EDU (Sendmail 5.59/2.10) id AA27758; Thu, 11 May 89 13:52:22 PDT Message-Id: <8905112052.AA27758@neptune.CS.UCLA.EDU> To: CommonLoops.pa@Xerox.COM Subject: problems in Compiling the NEW Cinco De Mayo PCL in LUCID 3.0 Date: Thu, 11 May 89 13:52:20 PDT From: poman@CS.UCLA.EDU I was trying to compile the new version of PCL (5/10/89 version) on Lucid 3.0, but it ran into a Segmentation Violation while compiling fixup.lisp. Does anyone have the same problem? Any comments/suggestions are appreciated. The error message is as follows : >>Trap: Segmentation violation COMPUTE-EFFECTIVE-METHOD-BODY: Required arg 0 (STANDARD-GENERIC-FUNCTION): # Required arg 1 (METHODS): (# #) :A 0: Abort to Lisp Top Level -Richard Leung (poman@cs.ucla.edu) Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA27415; Thu, 11 May 89 14:56:07 -0700 Reply-To: Received: from Semillon.ms by ArpaGateway.ms ; 11 MAY 89 14:55:00 PDT Return-Path: Redistributed: commonloops.pa Received: from neptune.CS.UCLA.EDU ([131.179.128.32]) by Xerox.COM ; 11 MAY 89 13:53:27 PDT Return-Path: Received: from LocalHost by neptune.CS.UCLA.EDU (Sendmail 5.59/2.10) id AA27758; Thu, 11 May 89 13:52:22 PDT Message-Id: <8905112052.AA27758@neptune.CS.UCLA.EDU> To: CommonLoops.pa@Xerox.COM Subject: problems in Compiling the NEW Cinco De Mayo PCL in LUCID 3.0 Date: Thu, 11 May 89 13:52:20 PDT From: poman@CS.UCLA.EDU I was trying to compile the new version of PCL (5/10/89 version) on Lucid 3.0, but it ran into a Segmentation Violation while compiling fixup.lisp. Does anyone have the same problem? Any comments/suggestions are appreciated. The error message is as follows : >>Trap: Segmentation violation COMPUTE-EFFECTIVE-METHOD-BODY: Required arg 0 (STANDARD-GENERIC-FUNCTION): # Required arg 1 (METHODS): (# #) :A 0: Abort to Lisp Top Level -Richard Leung (poman@cs.ucla.edu) Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA02832; Thu, 11 May 89 17:46:35 -0700 Reply-To: Received: from Salvador.ms by ArpaGateway.ms ; 11 MAY 89 17:10:39 PDT Return-Path: Redistributed: CommonLoops.pa Received: from ra.cs.ucla.edu ([131.179.128.33]) by Xerox.COM ; 11 MAY 89 15:41:33 PDT Return-Path: Received: by ra.cs.ucla.edu (Sendmail 4.0/2.10) id AA06003; Thu, 11 May 89 15:43:57 PDT Date: Thu, 11 May 89 15:43:57 PDT From: mujica@CS.UCLA.EDU (S. Mujica) Message-Id: <8905112243.AA06003@ra.cs.ucla.edu> To: CommonLoops.pa@Xerox.COM Subject: Cinco de mayo PCL Cinco de mayo PCL is sort of long. Could we rename it 55 PCL? (a touch of the fifties...) Sergio Mujica Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA04855; Thu, 11 May 89 20:14:10 -0700 Reply-To: Received: from Cabernet.ms by ArpaGateway.ms ; 11 MAY 89 20:15:25 PDT Return-Path: Redistributed: CommonLoops.pa Received: from p.lanl.gov ([128.165.4.4]) by Xerox.COM ; 11 MAY 89 20:14:02 PDT Received: by p.lanl.gov (5.54/1.14) id AA03716; Thu, 11 May 89 21:13:56 MDT Received: by zaphod (4.0/5.17) id AA00370; Thu, 11 May 89 21:15:38 MDT Date: Thu, 11 May 89 21:15:38 MDT From: egdorf%zaphod@LANL.GOV (Skip Egdorf @ Los Alamos National Laboratory) Message-Id: <8905120315.AA00370@zaphod> To: CommonLoops.pa@Xerox.COM Subject: Sun Common Lisp 2.1.3 pcl problem There is a problem with "5/5/89 Cinco de Mayo PCL" retrieved May 11 (so the new fixes are in place) when used with Lucid version 2.1.3. Sun still distributes Lucid 2.1.3 as well as Lucid 3.0.2. This seems to be due to unavailability of things like SPE or third-party stuff like KEE on 3.0 yet. For (I guess) similar reasons, I still use both Sun Common Lisp 2.1.3 and 3.0.2. Pcl uses #+Lucid in a few places where #+Lcl3.0 should really be used. In particular, the package Lucid-Common-Lisp exists only in 3.0. This problem existed in three places in 5/5 pcl, and only two in the version retrieved today, so maybe the problem is known. In any case, two fixes to defs.lisp and boot.lisp allow pcl to compile, load, and run test.lisp under Sun Common Lisp 2.1.3 tested on a Sun-3/60 running SunOS 4.0.1. % diff boot.lisp boot.lisp.orig 955,959c955,956 < #+ (and :Lucid :Lcl3.0) < (lucid-common-lisp:*redefinition-action* nil) < #+ (and :Lucid (not :Lcl3.0)) < (system:*redefinition-action* nil) < ) --- > #+Lucid > (lucid-common-lisp:*redefinition-action* nil)) %diff defs.lisp defs.lisp.orig 381,384c381 < #+Lcl3.0 (let ((lucid-common-lisp::*redefinition-action* nil)) < (setf (symbol-function symbol) new-definition)) < #+(and :Lucid (not :Lcl3.0)) < (let ((system::*redefinition-action* nil)) --- > #+Lucid (let ((lucid-common-lisp::*redefinition-action* nil)) Until 2.1.3 goes away forever... Skip Egdorf hwe@lanl.gov Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA02832; Thu, 11 May 89 17:46:35 -0700 Reply-To: Received: from Salvador.ms by ArpaGateway.ms ; 11 MAY 89 17:10:39 PDT Return-Path: Redistributed: CommonLoops.pa Received: from ra.cs.ucla.edu ([131.179.128.33]) by Xerox.COM ; 11 MAY 89 15:41:33 PDT Return-Path: Received: by ra.cs.ucla.edu (Sendmail 4.0/2.10) id AA06003; Thu, 11 May 89 15:43:57 PDT Date: Thu, 11 May 89 15:43:57 PDT From: mujica@CS.UCLA.EDU (S. Mujica) Message-Id: <8905112243.AA06003@ra.cs.ucla.edu> To: CommonLoops.pa@Xerox.COM Subject: Cinco de mayo PCL Cinco de mayo PCL is sort of long. Could we rename it 55 PCL? (a touch of the fifties...) Sergio Mujica Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA01753; Fri, 12 May 89 08:13:36 -0700 Reply-To: Received: from Cabernet.ms by ArpaGateway.ms ; 12 MAY 89 08:13:49 PDT Return-Path: Redistributed: CommonLoops.pa Received: from DINO.BBN.COM ([128.89.3.8]) by Xerox.COM ; 12 MAY 89 08:12:01 PDT To: Owners-CommonLoops.pa@Xerox.COM Cc: CommonLoops.pa@Xerox.COM Subject: Re: Pattern matching In-Reply-To: Your message of 09 May 89 10:52:31 +0100. <405*dvorak@iam.unibe.ch> Date: Fri, 12 May 89 11:17:10 -0400 From: kanderso@DINO.BBN.COM Message-Id: <890512-081349-5966@Xerox> Date: 09 May 89 10:52:31+0100 From: Jiri Dvorak To: CommonLoops.pa@xerox.com Subject: Pattern matching Message-Id: <405*dvorak@iam.unibe.ch> Is there a nice way to implement a pattern matcher in PCL that deals with patterns of the form: (object slot value) where at every position variables are allowed? I.e. the pattern matcher should be able to find all objects with a given value in a given slot, or find all slots of a given object, etc. Well, you should be able to have metaclasses provide support for this. For example, you might want classes to keep track of their instances, so that queries like (class-of x 'some-class) will work. What else you do depends on how you want to optimize other queries. For example, you may want to maintain inverse relationships on slot-value if you do (object 'some-slot 'some-value) queries a lot. You may want to build your own slot-discriptions to let you specify how each slot should be indexed. k Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA07181; Fri, 12 May 89 09:40:58 -0700 Received: from Cabernet.ms by ArpaGateway.ms ; 12 MAY 89 09:38:52 PDT Return-Path: Redistributed: CommonLoops.pa Received: from arisia.Xerox.COM ([13.1.100.206]) by Xerox.COM ; 12 MAY 89 09:33:50 PDT Received: from layla.parc.Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA06686; Fri, 12 May 89 09:31:51 -0700 Reply-To: Received: by layla. (4.0/SMI-4.0) id AA00527; Fri, 12 May 89 09:32:53 PDT Date: Fri, 12 May 89 09:32:53 PDT From: Ramana Rao Message-Id: <8905121632.AA00527@layla.> To: CommonLoops.pa@Xerox.COM Subject: Bug in handling forward reference class (in 'pcl) (defclass foo (bar baz) ()) Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA07256; Fri, 12 May 89 09:45:27 -0700 Received: from Cabernet.ms by ArpaGateway.ms ; 12 MAY 89 09:45:44 PDT Return-Path: Redistributed: commonloops.pa Received: from arisia.Xerox.COM ([13.1.100.206]) by Xerox.COM ; 12 MAY 89 09:39:35 PDT Received: from layla.parc.Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA07130; Fri, 12 May 89 09:37:41 -0700 Reply-To: Received: by layla. (4.0/SMI-4.0) id AA00530; Fri, 12 May 89 09:38:45 PDT Date: Fri, 12 May 89 09:38:45 PDT From: Ramana Rao Message-Id: <8905121638.AA00530@layla.> To: commonloops.pa@Xerox.COM Subject: Bug in Checking Initargs (in-package 'pcl) (defclass foo () ()) (defmethod initialize-instance :after ((foo foo) &rest args) nil) ;; Shouldn't the &rest in initialize-instance on foo allow the following. ;; I think so. (make-instance 'foo :bar :baz) Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA08141; Fri, 12 May 89 10:29:24 -0700 Reply-To: Received: from Semillon.ms by ArpaGateway.ms ; 12 MAY 89 10:27:33 PDT Return-Path: Redistributed: CommonLoops.pa Received: from p.lanl.gov ([128.165.4.4]) by Xerox.COM ; 12 MAY 89 10:22:24 PDT Received: by p.lanl.gov (5.54/1.14) id AA12516; Fri, 12 May 89 11:22:18 MDT Received: by zaphod (4.0/5.17) id AA00693; Fri, 12 May 89 11:23:59 MDT Date: Fri, 12 May 89 11:23:59 MDT From: egdorf%zaphod@LANL.GOV (Skip Egdorf @ Los Alamos National Laboratory) Message-Id: <8905121723.AA00693@zaphod> To: CommonLoops.pa@Xerox.COM Subject: Lucid 3.0.2 Optimization botch "5/5/89 Cinco de Mayo PCL" has a problem on Lucid 3.0 with the optimizing compiler. On a Sun 3/60, SunOS 4.0.1, Sun Common Lisp 3.0.2, pcl runs test.lisp correctly when compiled with the default (development) compiler mode. However, when (proclaim '(optimize (compilation-speed 0))) is evaluated prior to (load "defsys") in order to use the production mode of the compiler, the following happens: % pcl-3.0-fast ... > (load "test.lisp") ... Testing shared-initialize with T argument and initargs...OK Testing initialization arguments rules test...OK Testing more tests for initialization arguments rules...OK Testing initialization protocols... >>Error: SYSTEM:STRUCTURE-TYPE called with 5 arguments, but only 1 argument is allowed SYSTEM:STRUCTURE-TYPE: Required arg 0 (X): # :C 0: Ignore extra arguments :A 1: Abort to Lisp Top Level -> I am happy (for the moment) with the development-mode compilation, so am not really looking for a solution. This feels like a Lucid bug rather than a pcl bug. Skip Egdorf hwe@lanl.gov Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA12393; Fri, 12 May 89 14:47:45 -0700 Received: from Chardonnay.ms by ArpaGateway.ms ; 12 MAY 89 14:47:04 PDT Return-Path: Redistributed: Commonloops.pa Received: from arisia.Xerox.COM ([13.1.100.206]) by Xerox.COM ; 12 MAY 89 14:43:59 PDT Received: from layla.parc.Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA12173; Fri, 12 May 89 14:42:05 -0700 Reply-To: Received: by layla. (4.0/SMI-4.0) id AA00601; Fri, 12 May 89 14:43:07 PDT Date: Fri, 12 May 89 14:43:07 PDT From: Ramana Rao Message-Id: <8905122143.AA00601@layla.> To: Commonloops.pa@Xerox.COM Subject: Bug in Compute-applicable-methods Hitting lots of bugs today. Sorry, all bugs reported by me (today) are in Cinco de Mayo Release and show up in both Lucid and Franz. (defclass foo () ()) (defclass bar () ()) (defclass baz (foo bar) ()) (defmethod try :after ((foo foo)) (print "after")) (defmethod try ((bar bar)) t) (try (make-instance 'baz)) --> ERROR (compute-applicable-methods #'try `(,(make-instance 'baz))) --> Incorrect Ans. Received: from Sail.Stanford.EDU by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA13550; Fri, 12 May 89 15:33:32 -0700 Reply-To: Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 12 May 89 15:33:46 PDT Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 594309; 12 May 89 16:16:02 EDT Date: Fri, 12 May 89 16:16 EDT From: David A. Moon Subject: Random metaclasses for CL types To: Jon L White Cc: chapman%aitg.dec@decwrl.dec.com, common-lisp-object-system@SAIL.STANFORD.EDU In-Reply-To: <8905111328.AA04911@bhopal> Message-Id: <19890512201615.2.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Thu, 11 May 89 06:28:56 PDT From: Jon L White re: . . . or any other implementation-defined class that is no more restrictive than a {\bit built-in class\/}. I liked your first version better -- I don't remember 88-002R having a well-ordered scale for "restrictiveness" of metaclasses, so this phrase (for me) causes much more confusion than it clears up. But it's not a big point. "restrictive" refers to the immediately following paragraph in 88-002R, which documents the restrictions of built-in-class. The idea is that if a user program assumes it might be a built-in-class, an implementation can't screw the user over by coming with an implementation-defined class that's even worse (can't appear as the cdr of a cons or something). How about changing "is no more restrictive" to "has no more restrictions"? Kathy? On a related theme -- I was wondering if everyone agrees that the following is also permitted by "Integrating Types And Classes" section. An implementation may have a subset of some built-in class being implemented by a different meta-class than the rest of the set. 1-16 says additional type specifiers can have classes, so I think everyone agrees that the built-in classes can have implementation-defined subclasses. I assume the metaclass of those can be anything that works. For example, in most implementations we probably have: (class-name (class-of (find-class 'integer))) --> BUILT-IN-CLASS But some implementation might also have a FIXNUM class such that: (class-name (class-of (find-class 'fixnum))) --> FAST-ARITH-CLASS where FAST-ARITH-CLASS is not a subclass of BUILT-IN-CLASS. Of course, the FIXNUM class is a still a subclass of INTEGER. I can't understand why FAST-ARITH-CLASS wouldn't be a subclass of BUILT-IN-CLASS. Maybe the example you really meant was (class-name (class-of (find-class 'integer))) --> SLOW-ARITH-CLASS (class-name (class-of (find-class 'fixnum))) --> FAST-ARITH-CLASS where SLOW-ARITH-CLASS and FAST-ARITH-CLASS are disjoint subclasses of BUILT-IN-CLASS? [don't take this example too seriously -- I'm more concerned about subclasses of the FUNCTION class.] Or maybe you really meant that (class-name (class-of (find-class 'function))) --> BUILT-IN-CLASS but (class-name (class-of (find-class 'generic-function))) --> FUNCALLABLE-STANDARD-CLASS and (subclassp 'FUNCALLABLE-STANDARD-CLASS 'BUILT-IN-CLASS) --> NIL which is specified either by 88-002R or the draft metaobject protocol, I forget which. Anyway this example shows that you don't have to worry. Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA08141; Fri, 12 May 89 10:29:24 -0700 Reply-To: Received: from Semillon.ms by ArpaGateway.ms ; 12 MAY 89 10:27:33 PDT Return-Path: Redistributed: CommonLoops.pa Received: from p.lanl.gov ([128.165.4.4]) by Xerox.COM ; 12 MAY 89 10:22:24 PDT Received: by p.lanl.gov (5.54/1.14) id AA12516; Fri, 12 May 89 11:22:18 MDT Received: by zaphod (4.0/5.17) id AA00693; Fri, 12 May 89 11:23:59 MDT Date: Fri, 12 May 89 11:23:59 MDT From: egdorf%zaphod@LANL.GOV (Skip Egdorf @ Los Alamos National Laboratory) Message-Id: <8905121723.AA00693@zaphod> To: CommonLoops.pa@Xerox.COM Subject: Lucid 3.0.2 Optimization botch "5/5/89 Cinco de Mayo PCL" has a problem on Lucid 3.0 with the optimizing compiler. On a Sun 3/60, SunOS 4.0.1, Sun Common Lisp 3.0.2, pcl runs test.lisp correctly when compiled with the default (development) compiler mode. However, when (proclaim '(optimize (compilation-speed 0))) is evaluated prior to (load "defsys") in order to use the production mode of the compiler, the following happens: % pcl-3.0-fast ... > (load "test.lisp") ... Testing shared-initialize with T argument and initargs...OK Testing initialization arguments rules test...OK Testing more tests for initialization arguments rules...OK Testing initialization protocols... >>Error: SYSTEM:STRUCTURE-TYPE called with 5 arguments, but only 1 argument is allowed SYSTEM:STRUCTURE-TYPE: Required arg 0 (X): # :C 0: Ignore extra arguments :A 1: Abort to Lisp Top Level -> I am happy (for the moment) with the development-mode compilation, so am not really looking for a solution. This feels like a Lucid bug rather than a pcl bug. Skip Egdorf hwe@lanl.gov Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA20458; Fri, 12 May 89 22:36:00 -0700 Reply-To: Received: from Chardonnay.ms by ArpaGateway.ms ; 12 MAY 89 22:37:07 PDT Return-Path: Redistributed: CommonLoops.pa Received: from lucid.com ([192.26.25.1]) by Xerox.COM ; 12 MAY 89 22:35:58 PDT Received: from bhopal ([192.43.178.13]) by heavens-gate id AA01159g; Fri, 12 May 89 22:35:04 PDT Received: by bhopal id AA17980g; Fri, 12 May 89 22:34:52 PDT Date: Fri, 12 May 89 22:34:52 PDT From: Jon L White Message-Id: <8905130534.AA17980@bhopal> To: CommonLoops.pa@Xerox.COM In-Reply-To: egdorf%zaphod@LANL.GOV (Skip Egdorf's message of Thu, 11 May 89 21:15:38 MDT <8905120315.AA00370@zaphod> Subject: Sun Common Lisp 2.1.3 pcl problem Rather than adding many more #+/#- conditionalizations, perhaps the best thing would be to resort to using the "lucid::" notation. This is how the files walk.lisp and fin.lisp - and to some degree defs.lisp also -- have insulated themselves against the package differences between Lucid's version 2 and version 3. Ordinarily, I would strongly recommend against use of double-colon format in files, but in this particular case, each symbol so qualified is "stable" in it's particular release version. At one point I suggested to Gregor that he could simply import into the PCL package the dozen or so Lucid internal symbols he needs. But a dozen or so symbols multiplied by the dozen or so implementations that PCL runs in might create more headaches than it cures. -- JonL -- Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA27316; Sat, 13 May 89 11:52:35 -0700 Reply-To: Received: from Semillon.ms by ArpaGateway.ms ; 13 MAY 89 11:52:45 PDT Return-Path: Redistributed: commonloops.pa Received: from arpa.att.com ([192.20.225.1]) by Xerox.COM ; 13 MAY 89 11:51:05 PDT From: "lgm@att.att.com"@ihlpf.att.com Date: Sat, 13 May 89 13:26 CDT >From: ihlpf!lgm (Lawrence G Mayka +1 312 416 5166) To: commonloops.pa%xerox.com%att.uucp@ihlpf.att.com Subject: Can't compile latest PCL on AKCL 1.122 Message-Id: <890513-115245-8525@Xerox> I am attempting to compile the revised edition of Cinco de Mayo PCL (put up a couple days ago on arisia.xerox.com) on top of Austin Kyoto Common Lisp 1.122 (with the TURBO-CLOSURE patch). If I compile with safety 2, I get an error during the compilation of "construct.lsp": ___ Compiling CONSTRUCT... Compiling /f111/lgm/lisp/pcl/construct.lsp. Error: The index, 24, is too large. Error signalled by CHECK-SUPER-METACLASS-COMPATIBILITY. Backtrace: > eval > let > load-defclass > add-named-class > update-class > CHECK-SUPER-METACLASS-COMPATIBILITY ; (LET NIL ...) is being compiled. ;;; The form (LET NIL (LOAD-DEFCLASS 'FUNCALLABLE-STANDARD-CLASS 'CONSTRUCTOR 'NIL (LIST (LIST* :NAME 'CLASS '(:INITARG :CLASS :READER CONSTRUCTOR-CLASS)) (LIST* :NAME 'NAME :INITFUNCTION #'FALSE '(:INITFORM NIL :INITARG :NAME :READER CONSTRUCTOR-NAME)) (LIST* :NAME 'CODE-TYPE :INITFUNCTION #'FALSE '(:INITFORM NIL :ACCESSOR CONSTRUCTOR-CODE-TYPE)) (LIST* :NAME 'SUPPLIED-INITARG-NAMES '(:INITARG :SUPPLIED-INITARG-NAMES :READER CONSTRUCTOR-SUPPLIED-INITARG-NAMES)) (LIST* :NAME 'CODE-GENERATORS '(:INITARG :CODE-GENERATORS :READER CONSTRUCTOR-CODE-GENERATORS))) (LIST))) was not evaluated successfully. ;;; You are recommended to compile again. ______ If I modify "kcl-patches.lsp" to ensure that safety is 0 throughout the compilation, I get a segmentation violation while compiling "high.lsp". Any suggestions? Lawrence G. Mayka AT&T Bell Laboratories lgm@ihlpf.att.com Received: from Sail.Stanford.EDU by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA00574; Sat, 13 May 89 18:10:51 -0700 Reply-To: Received: from lucid.com by SAIL.Stanford.EDU with TCP; 13 May 89 18:11:24 PDT Received: from bhopal ([192.43.178.13]) by heavens-gate id AA01974g; Sat, 13 May 89 18:10:42 PDT Received: by bhopal id AA18947g; Sat, 13 May 89 18:10:29 PDT Date: Sat, 13 May 89 18:10:29 PDT From: Jon L White Message-Id: <8905140110.AA18947@bhopal> To: Moon@STONY-BROOK.SCRC.Symbolics.COM, Gray@dsg.csc.ti.com Cc: common-lisp-object-system@SAIL.STANFORD.EDU, chapman%aitg.dec@decwrl.dec.com In-Reply-To: David A. Moon's message of Fri, 12 May 89 16:16 EDT <19890512201615.2.MOON@EUPHRATES.SCRC.Symbolics.COM> Subject: Random metaclasses for CL types re: . . . The idea is that if a user program assumes it might be a built-in-class, an implementation can't screw the user over by coming with an implementation-defined class that's even worse (can't appear as the cdr of a cons or something). Maybe a positive way to say this is that such instances must be "first-class" -- i.e, can be passed as arguments to functions, can be cons'd into list structure, can be specialized upon by generic functions, don't crash the system if you try to print them, etc. Better to know where the alligator *is* than where he isn't. re: Or maybe you really meant that (class-name (class-of (find-class 'function))) --> BUILT-IN-CLASS but (class-name (class-of (find-class 'generic-function))) --> FUNCALLABLE-STANDARD-CLASS and (subclassp 'FUNCALLABLE-STANDARD-CLASS 'BUILT-IN-CLASS) --> NIL which is specified either by 88-002R or the draft metaobject protocol, I forget which. Anyway this example shows that you don't have to worry. Why, yes, as a matter of fact, that's precisely what I was hinting at. However I don't see any particular consequence of requiring FUNCALLABLE-STANDARD-CLASS to be a subclass of STANDARD-CLASS rather than of BUILT-IN-CLASS. It's certainly possible for one subclass of STANDARD-CLASS to paint a totally different picture of its instances than some other random subclass of STANDARD-CLASS does. Also, I don't feel strongly that non-FUNCALLABLE-STANDARD-CLASS function classes should have a separate name from FUNCTION -- to form a partition as you were suggesting in: "... where SLOW-ARITH-CLASS and FAST-ARITH-CLASS are disjoint subclasses of BUILT-IN-CLASS?" [presumably you also meant also that the union of SLOW-ARITH-CLASS and FAST-ARITH-CLASS would conver the INTEGER class]. Rather, I would like to see a clear picture as follows, where the dots show metaclass links, and the slashes show subclass links: FUNCTION . . . . . . . . . . . . . . . . BUILT-IN-CLASS / \ / \ / \ ?? STANDARD-FUNCTION-OBJECT . . . . . . . STANDARD-FUNCTION-CLASS / \ / \ / \ GENERIC-FUNCTION / \ / / \ / {PCL's "constructors"} STANDARD-GENERIC-FUNCTION The advantage of using the name STANDARD-FUNCTION-CLASS rather than FUNCALLABLE-STANDARD-CLASS is that it continues the parallels already established between the nomenclatures of certain other meta objects: STANDARD-OBJECT -- STANDARD-CLASS STRUCTURE-OBJECT -- STRUCTURE-CLASS {BUILT-IN-OBJECT} -- BUILT-IN-CLASS {STANDARD-FUNCTION-OBJECT} -- STANDARD-FUNCTION-CLASS [The names in {}'s show classes that aren't specified in the standard, but which people informally talk about using various names]. The ?? class under FUNCTION above would be left for implementation-specific functions, which don't have the regular structure about them that allows easy (perhaps "portable") manipulation of subcomponents. This is what STANDARD-FUNCTION-CLASS would represent -- regular, accessible structure of the functions. I'd be particularly curious as to how you two Daves feel about this. -- JonL -- Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA13856; Mon, 15 May 89 03:20:52 -0700 Reply-To: Received: from Cabernet.ms by ArpaGateway.ms ; 15 MAY 89 03:21:30 PDT Return-Path: Redistributed: Commonloops.pa Received: from columbia.edu ([128.59.16.1]) by Xerox.COM ; 15 MAY 89 03:19:20 PDT Received: from cunixc.cc.columbia.edu by columbia.edu (5.59++/0.3) with SMTP id AA27605; Mon, 15 May 89 06:17:27 EDT Received: from cuchmc.chem.columbia.EDU by cunixc.cc.columbia.edu (5.54/5.10) id AA12161; Mon, 15 May 89 06:16:37 EDT Received: by cuchmc.chem.columbia.EDU (5.51/4.8) id AA26396; Mon, 15 May 89 06:15:25 EDT Date: Mon, 15 May 89 06:15:25 EDT From: lee@cuchmc.chem.columbia.edu (Tim Lee) Message-Id: <8905151015.AA26396@cuchmc.chem.columbia.EDU> To: Commonloops.pa@Xerox.COM Subject: Help For building PCL under KCL on Convex Cpu Hi: I am forwarding the following msg for Dan Golan. Thanks, Tim >From golan Tue May 9 12:01:38 1989 Date: Tue, 9 May 89 12:00:51 CDT From: golan (Dan Golan) To: CommonLoops-Coordinator.pa@Xerox.arpa Subject: problem with pcl under new kcl Cc: golan Status: R to whom it may concern, my name is dan golan. i work for CONVEX computer corp. my address is : CONVEX Computer Corporation 3000 Waterview Parkway P.O. Box 833851 Richardson, TX 75083-3851 email: golan@convex.com i received a copy of PCL from tim lee at columbia university. i can build and run it fine on the convex under 3 June 1987 KCL. i recently acquired the 1 December 1988 version of KCL directly from program author Taiichi Yuasa. When building PCL it fails during compilation of the file boot.lsp - (compile listing follows at the end of this note). In my attempt to debug this problem i searched for kcl-specific code which might lead to the problem i'm seeing. not sure if problem is in kcl or pcl, since kcl compiler has changed. right now most likely candidate seems to be the code in WALK, with possibilities in KCL-PATCHES and KCL-LOW. if you see anything familiar in the listing which would help isolate the problem please let me know. otherwise i'll just slog through until i figure something out. thanks, Dan p.s. just for grins i also hand loaded the uncompiled versions of all of the files which are compiled and loaded prior to boot.lsp, and then compiled boot.lsp to see what would happen. i've also concatenated a listing of the results of this. ++++++++++++++++++++++++++++++++++++++ bof (listing of normal build) ++++++++++++++++++++++++++++++++++++++ KCl (Kyoto Common Lisp) December 1, 1988 >Loading pcl_88/defsys.lsp Finished loading pcl_88/defsys.lsp T >Loading pcl_88/pkg.lsp Finished loading pcl_88/pkg.lsp T >Compiling KCL-PATCHES... Compiling /scratch/golan/pcl_debug/pcl_88/kcl-patches.lsp. Warning: DEFMACRO is being redefined. End of Pass 1. End of Pass 2. OPTIMIZE levels: Safety=0 (No runtime error checking), Space=0, Speed=3 Finished compiling /scratch/golan/pcl_debug/pcl_88/kcl-patches.lsp. Loading binary of KCL-PATCHES... Compiling PKG... Compiling /scratch/golan/pcl_debug/pcl_88/pkg.lsp. End of Pass 1. End of Pass 2. OPTIMIZE levels: Safety=0 (No runtime error checking), Space=0, Speed=3 Finished compiling /scratch/golan/pcl_debug/pcl_88/pkg.lsp. Loading binary of PKG... Compiling WALK... Compiling /scratch/golan/pcl_debug/pcl_88/walk.lsp. End of Pass 1. ;; Note: Tail-recursive call of WALK-TEMPLATE was replaced by iteration. ;; Note: Tail-recursive call of WALK-TEMPLATE was replaced by iteration. ;; Note: Tail-recursive call of WALK-TEMPLATE-HANDLE-REPEAT-1 was replaced by iteration. End of Pass 2. OPTIMIZE levels: Safety=0 (No runtime error checking), Space=0, Speed=3 Finished compiling /scratch/golan/pcl_debug/pcl_88/walk.lsp. Loading binary of WALK... Compiling ITERATE... Compiling /scratch/golan/pcl_debug/pcl_88/iterate.lsp. ; (DEFUN OPTIMIZE-ITERATE-FORM ...) is being compiled. ;; Warning: The ignored variable V is used. End of Pass 1. End of Pass 2. OPTIMIZE levels: Safety=0 (No runtime error checking), Space=0, Speed=3 Finished compiling /scratch/golan/pcl_debug/pcl_88/iterate.lsp. Loading binary of ITERATE... Compiling MACROS... Compiling /scratch/golan/pcl_debug/pcl_88/macros.lsp. End of Pass 1. ;; Note: Tail-recursive call of MAKE-CAXR was replaced by iteration. ;; Note: Tail-recursive call of MAKE-CDXR was replaced by iteration. ;; Note: Tail-recursive call of REDUCE-CONSTANT was replaced by iteration. End of Pass 2. OPTIMIZE levels: Safety=0 (No runtime error checking), Space=0, Speed=3 Finished compiling /scratch/golan/pcl_debug/pcl_88/macros.lsp. Loading binary of MACROS... Compiling LOW... Compiling /scratch/golan/pcl_debug/pcl_88/low.lsp. End of Pass 1. End of Pass 2. OPTIMIZE levels: Safety=0 (No runtime error checking), Space=0, Speed=3 Finished compiling /scratch/golan/pcl_debug/pcl_88/low.lsp. Loading binary of LOW... Compiling KCL-LOW... Compiling /scratch/golan/pcl_debug/pcl_88/kcl-low.lsp. ; (DEFUN SET-FUNCTION-NAME-1 ...) is being compiled. ;; Warning: The variable IGNORE is not used. End of Pass 1. End of Pass 2. OPTIMIZE levels: Safety=0 (No runtime error checking), Space=0, Speed=3 Finished compiling /scratch/golan/pcl_debug/pcl_88/kcl-low.lsp. Loading binary of KCL-LOW... Compiling FIN... Compiling /scratch/golan/pcl_debug/pcl_88/fin.lsp. End of Pass 1. End of Pass 2. OPTIMIZE levels: Safety=0 (No runtime error checking), Space=0, Speed=3 Finished compiling /scratch/golan/pcl_debug/pcl_88/fin.lsp. Loading binary of FIN... Compiling DEFS... Compiling /scratch/golan/pcl_debug/pcl_88/defs.lsp. ; (DEFUN DO-SATISFIES-DEFTYPE ...) is being compiled. ;; Warning: The variable EXPAND-FN is not used. End of Pass 1. End of Pass 2. OPTIMIZE levels: Safety=0 (No runtime error checking), Space=0, Speed=3 Finished compiling /scratch/golan/pcl_debug/pcl_88/defs.lsp. Loading binary of DEFS... Compiling BOOT... Compiling /scratch/golan/pcl_debug/pcl_88/boot.lsp. Warning: couldn't optimize ITERATE because generator NIL is closed over S, in conflict with another iteration variable. you may have meant to use iterate* Error: The GO tag ITERATE::PUNT is missing. Error signalled by ITERATE::OPTIMIZE-GATHERING-FORM. Backtrace: > macroexpand > funcall > gathering > let > ITERATE::OPTIMIZE-GATHERING-FORM ; (DEFUN MAKE-PARAMETER-REFERENCES ...) is being compiled. ;;; The macro form (GATHERING ((REFERENCES (COLLECTING))) (ITERATE ((S (LIST-ELEMENTS SPECIALIZED-LAMBDA-LIST)) (P (LIST-ELEMENTS REQUIRED-PARAMETERS))) (COND ((NOT (LISTP S))) ((IGNOREDP (CAR S)) (WARN "In defmethod ~S ~S, there is a~%~ redundant ignore declaration for the parameter ~S." GENERIC-FUNCTION-NAME SPECIALIZERS (CAR S))) (T (GATHER (CAR S) REFERENCES))))) was not expanded successfully. Warning: couldn't optimize ITERATE because generator NIL is closed over S, in conflict with another iteration variable. you may have meant to use iterate* Error: The GO tag ITERATE::PUNT is missing. Error signalled by ITERATE::OPTIMIZE-GATHERING-FORM. Backtrace: > funcall > funcall > gathering > let > ITERATE::OPTIMIZE-GATHERING-FORM ;;; The macro form (GATHERING ...) was not expanded successfully. ;; Warning: The variable SPECIALIZED-LAMBDA-LIST is not used. ;; Warning: The variable REQUIRED-PARAMETERS is not used. ;; Warning: The variable DECLARATIONS is not used. ;; Warning: The variable GENERIC-FUNCTION-NAME is not used. ;; Warning: The variable SPECIALIZERS is not used. ; (DEFUN ENSURE-GENERIC-FUNCTION ...) is being compiled. ;; Warning: The variable GENERIC-FUNCTION-CLASS is not used. No FASL generated. Loading binary of BOOT... Error: Cannot open the file /scratch/golan/pcl_debug/pcl_88/boot.o. Error signalled by LOAD. Broken at LOAD. Type :H for Help. >>Bye. 139.43u 11.00s 5:19 47% 149+3771k 26+686io 2362pf+0w ++++++++++++++++++++++++++++++++++++++ eof (listing of normal build) ++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++ bof (listing of build where only boot is compiled) ++++++++++++++++++++++++++++++++++++++ KCl (Kyoto Common Lisp) December 1, 1988 >Loading pcl_88/defsys.lsp Finished loading pcl_88/defsys.lsp T >Loading pcl_88/pkg.lsp Finished loading pcl_88/pkg.lsp T >Loading pcl_88/kcl-patches.lsp Warning: DEFMACRO is being redefined. Finished loading pcl_88/kcl-patches.lsp T >Loading pcl_88/walk.lsp Finished loading pcl_88/walk.lsp T >Loading pcl_88/iterate.lsp Finished loading pcl_88/iterate.lsp T >Loading pcl_88/macros.lsp Finished loading pcl_88/macros.lsp T >Loading pcl_88/low.lsp Finished loading pcl_88/low.lsp T >Loading pcl_88/kcl-low.lsp Finished loading pcl_88/kcl-low.lsp T >Loading pcl_88/fin.lsp Finished loading pcl_88/fin.lsp T >Loading pcl_88/defs.lsp Finished loading pcl_88/defs.lsp T >Compiling pcl_88/boot.lsp. Warning: couldn't optimize ITERATE because generator NIL is closed over S, in conflict with another iteration variable. you may have meant to use iterate* Error: The tag ITERATE::PUNT is missing. Error signalled by GO. Backtrace: > macroexpand > funcall > gathering > let > iterate::optimize-gathering-form > let* > setq > iterate::walk-gathering-body > let > walk-form > let > walker::walk-form-internal > catch > catch > cond > if > walker::walk-template > if > case > cond > walker::walk-template > if > case > walker::walk-template-handle-repeat > if > walker::walk-template-handle-repeat-1 > cond > walker::walk-template > if > let > if > progn > walker::walk-form-internal > catch > catch > cond > cond > walker::walk-form-internal > catch > catch > cond > if > walker::walk-template > if > case > cond > walker::walk-template > if > case > cond > walker::walk-template > if > case > walker::walk-template-handle-repeat > if > walker::walk-template-handle-repeat-1 > cond > walker::walk-template > if > let > if > progn > walker::walk-form-internal > catch > catch > cond > if > funcall > walker::walk-let* > walker::walk-let/let* > let > let* > walker::walk-declarations > cond > walker::walk-declarations > cond > funcall > walker::w ; (DEFUN MAKE-PARAMETER-REFERENCES ...) is being compiled. ;;; The macro form (GATHERING ((REFERENCES (COLLECTING))) (ITERATE ((S (LIST-ELEMENTS SPECIALIZED-LAMBDA-LIST)) (P (LIST-ELEMENTS REQUIRED-PARAMETERS))) (COND ((NOT (LISTP S))) ((IGNOREDP (CAR S)) (WARN "In defmethod ~S ~S, there is a~%~ redundant ignore declaration for the parameter ~S." GENERIC-FUNCTION-NAME SPECIALIZERS (CAR S))) (T (GATHER (CAR S) REFERENCES))))) was not expanded successfully. Warning: couldn't optimize ITERATE because generator NIL is closed over S, in conflict with another iteration variable. you may have meant to use iterate* Error: The tag ITERATE::PUNT is missing. Error signalled by GO. Backtrace: > funcall > funcall > gathering > let > iterate::optimize-gathering-form > let* > setq > iterate::walk-gathering-body > let > walk-form > let > walker::walk-form-internal > catch > catch > cond > if > walker::walk-template > if > case > cond > walker::walk-template > if > case > walker::walk-template-handle-repeat > if > walker::walk-template-handle-repeat-1 > cond > walker::walk-template > if > let > if > progn > walker::walk-form-internal > catch > catch > cond > cond > walker::walk-form-internal > catch > catch > cond > if > walker::walk-template > if > case > cond > walker::walk-template > if > case > cond > walker::walk-template > if > case > walker::walk-template-handle-repeat > if > walker::walk-template-handle-repeat-1 > cond > walker::walk-template > if > let > if > progn > walker::walk-form-internal > catch > catch > cond > if > funcall > walker::walk-let* > walker::walk-let/let* > let > let* > walker::walk-declarations > cond > walker::walk-declarations > cond > funcall > walker::walk- ;;; The macro form (GATHERING ...) was not expanded successfully. ;; Warning: The variable SPECIALIZED-LAMBDA-LIST is not used. ;; Warning: The variable REQUIRED-PARAMETERS is not used. ;; Warning: The variable DECLARATIONS is not used. ;; Warning: The variable GENERIC-FUNCTION-NAME is not used. ;; Warning: The variable SPECIALIZERS is not used. ; (DEFUN ENSURE-GENERIC-FUNCTION ...) is being compiled. ;; Warning: The variable GENERIC-FUNCTION-CLASS is not used. No FASL generated. >Bye. ++++++++++++++++++++++++++++++++++++++ eof (listing of build where only boot is compiled) ++++++++++++++++++++++++++++++++++++++ Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA15027; Mon, 15 May 89 05:48:46 -0700 Reply-To: Received: from Cabernet.ms by ArpaGateway.ms ; 15 MAY 89 05:49:52 PDT Return-Path: Redistributed: commonloops.pa Received: from arpa.att.com ([192.20.225.1]) by Xerox.COM ; 15 MAY 89 05:48:37 PDT From: "capek!bb@att.att.com"@ihlpf.att.com Received: by bbsun.att.com (4.0/SMI-4.0) id AA28790; Mon, 15 May 89 08:36:00 EDT Date: Mon, 15 May 89 08:36:00 EDT >From: bb@lucian (Bruce Buntschuh) Message-Id: <8905151236.AA28790@bbsun.att.com> To: Owners-commonloops.pa@Xerox.COM Cc: commonloops.pa%xerox.com%att.uucp@ihlpf.att.com In-Reply-To: "lgm@att.att.com"@ihlpf.att.com's message of Sat, 13 May 89 13:26 CDT <890513-115245-8525@Xerox> Subject: Can't compile latest PCL on AKCL 1.122 I successfully compiled PCL on akcl-1-122 on both sun3 and sun4 machines. I modified the defsys.lsp file so that it doesn't try to compile or load kcl-patches. (it's commented out). IT then successfully runs all of the tests. Bruce Buntschuh AT&T Bell Laboratories Murray Hill, NJ. 07974 bb@research.att.com Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA16114; Mon, 15 May 89 08:57:27 -0700 Reply-To: Received: from Semillon.ms by ArpaGateway.ms ; 15 MAY 89 08:53:32 PDT Date: Mon, 15 May 89 08:49 PDT From: Gregor.pa@Xerox.COM Subject: Re: Help For building PCL under KCL on Convex Cpu To: Tim Lee , golan@convex.com Cc: Commonloops.pa@Xerox.COM Fcc: BD:>Gregor>mail>outgoing-mail-6.text.newest In-Reply-To: <8905151015.AA26396@cuchmc.chem.columbia.EDU> Message-Id: <19890515154956.2.GREGOR@SPIFF.parc.xerox.com> Line-Fold: no From: golan (Dan Golan) Subject: problem with pcl under new kcl i received a copy of PCL from tim lee at columbia university. i can build and run it fine on the convex under 3 June 1987 KCL. i recently acquired the 1 December 1988 version of KCL directly from program author Taiichi Yuasa. When building PCL it fails during compilation of the file boot.lsp - (compile listing follows at the end of this note). Looking at the dribble file you sent it looks to me like the new version of KCL isn't interacting with the code walker properly. Here is an idea about a way to test this. At the end of the file walk.lisp, there are a bunch of test cases for the code walker. Try putting that code in a separate file and then loading it after loading walk.o. ------- Received: from Sail.Stanford.EDU by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA16439; Mon, 15 May 89 09:06:28 -0700 Reply-To: Received: from lucid.com by SAIL.Stanford.EDU with TCP; 15 May 89 09:07:06 PDT Received: from challenger ([192.9.200.17]) by heavens-gate id AA03746g; Mon, 15 May 89 09:04:36 PDT Received: by challenger id AA08623g; Mon, 15 May 89 09:04:13 PDT Date: Mon, 15 May 89 09:04:13 PDT From: Patrick Dussud Message-Id: <8905151604.AA08623@challenger> To: jonl@lucid.com Cc: Moon@STONY-BROOK.SCRC.Symbolics.COM, Gray@dsg.csc.ti.com, common-lisp-object-system@SAIL.STANFORD.EDU, chapman%aitg.dec@decwrl.dec.com In-Reply-To: Jon L White's message of Sat, 13 May 89 18:10:29 PDT <8905140110.AA18947@bhopal> Subject: Random metaclasses for CL types However I don't see any particular consequence of requiring FUNCALLABLE-STANDARD-CLASS to be a subclass of STANDARD-CLASS rather than of BUILT-IN-CLASS. It's certainly possible for one subclass of STANDARD-CLASS to paint a totally different picture of its instances than some other random subclass of STANDARD-CLASS does. I coudn't parse that, so excuse me if what I say is totally obvious to you. I think that funcallable-standard-class shouldn't be a subclass of built-in-class. That would break the intuitive concept of specializations: the specialization refines the behavior of its superclass. Rather, I would like to see a clear picture as follows, where the dots show metaclass links, and the slashes show subclass links: FUNCTION . . . . . . . . . . . . . . . . BUILT-IN-CLASS / \ / \ / \ ?? STANDARD-FUNCTION-OBJECT . . . . . . . STANDARD-FUNCTION-CLASS / \ / \ / \ GENERIC-FUNCTION / \ / / \ / {PCL's "constructors"} STANDARD-GENERIC-FUNCTION Are you suggesting to add STANDARD-FUNCTION-OBJECT in the standard? I don't have anything against it. It's just I am not clear on what you want. The advantage of using the name STANDARD-FUNCTION-CLASS rather than FUNCALLABLE-STANDARD-CLASS is that it continues the parallels already established between the nomenclatures of certain other meta objects: STANDARD-OBJECT -- STANDARD-CLASS STRUCTURE-OBJECT -- STRUCTURE-CLASS {BUILT-IN-OBJECT} -- BUILT-IN-CLASS {STANDARD-FUNCTION-OBJECT} -- STANDARD-FUNCTION-CLASS The names STANDARD-FUNCTION-OBJECT and STANDARD-FUNCTION-CLASS are misleading. One can think that Common Lisp functions are standard-function objects. I agree that the current name FUNCALLABLE-STANDARD-CLASS doesn't fit well in the nomenclature, but it is strange enough so it does not have the wrong connotation. Patrick. Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA15027; Mon, 15 May 89 05:48:46 -0700 Reply-To: Received: from Cabernet.ms by ArpaGateway.ms ; 15 MAY 89 05:49:52 PDT Return-Path: Redistributed: commonloops.pa Received: from arpa.att.com ([192.20.225.1]) by Xerox.COM ; 15 MAY 89 05:48:37 PDT From: "capek!bb@att.att.com"@ihlpf.att.com Received: by bbsun.att.com (4.0/SMI-4.0) id AA28790; Mon, 15 May 89 08:36:00 EDT Date: Mon, 15 May 89 08:36:00 EDT >From: bb@lucian (Bruce Buntschuh) Message-Id: <8905151236.AA28790@bbsun.att.com> To: Owners-commonloops.pa@Xerox.COM Cc: commonloops.pa%xerox.com%att.uucp@ihlpf.att.com In-Reply-To: "lgm@att.att.com"@ihlpf.att.com's message of Sat, 13 May 89 13:26 CDT <890513-115245-8525@Xerox> Subject: Can't compile latest PCL on AKCL 1.122 I successfully compiled PCL on akcl-1-122 on both sun3 and sun4 machines. I modified the defsys.lsp file so that it doesn't try to compile or load kcl-patches. (it's commented out). IT then successfully runs all of the tests. Bruce Buntschuh AT&T Bell Laboratories Murray Hill, NJ. 07974 bb@research.att.com Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA28657; Mon, 15 May 89 15:09:37 -0700 Reply-To: Received: from Semillon.ms by ArpaGateway.ms ; 15 MAY 89 15:08:27 PDT Return-Path: Redistributed: CommonLoops.PA Received: from rand.org ([192.5.14.33]) by Xerox.COM ; 15 MAY 89 13:51:56 PDT Received: from blackcomb.rand.org by rand.org; Mon, 15 May 89 13:11:39 PDT Received: from localhost by blackcomb.arpa; Mon, 15 May 89 13:11:24 PDT Message-Id: <8905152011.AA06072@blackcomb.arpa> To: CommonLoops.PA@Xerox.COM Subject: Allegro hangs while compiling Cinco de Mayo PCL Date: Mon, 15 May 89 13:11:22 PDT From: Darrell When compiling the boot file, in latest version of PCL under both Allegro 3.0.1 and 3.0.3 the system hangs at the following spot: ; --- Compiling file /b/shane/cl/clos/pcl/new/boot.lisp --- ; Compiling REDIRECT-EARLY-FUNCTION-INTERNAL ; Compiling DEFGENERIC ; Compiling EXPAND-DEFGENERIC ; Compiling LOAD-DEFGENERIC ; Compiling DEFMETHOD ; Compiling METHOD-PROTOTYPE-FOR-GF ; Compiling EXPAND-DEFMETHOD ; Compiling EXPAND-DEFMETHOD-INTERNAL ; Compiling ADD-LEXICAL-FUNCTIONS-TO-METHOD-LAMBDA ; Compiling MAKE-PARAMETER-REFERENCES recursive format error, would have printed: "Funcall of ~s which is a non-function." 0 recursive format error, would have printed: "Funcall of ~s which is a non-function." 0 Any help would be appreciated, Darrell Shane Received: from Sail.Stanford.EDU by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA04247; Mon, 15 May 89 18:30:03 -0700 Reply-To: Received: from lucid.com by SAIL.Stanford.EDU with TCP; 15 May 89 18:30:26 PDT Received: from bhopal ([192.43.178.13]) by heavens-gate id AA04774g; Mon, 15 May 89 18:29:08 PDT Received: by bhopal id AA24714g; Mon, 15 May 89 18:28:52 PDT Date: Mon, 15 May 89 18:28:52 PDT From: Jon L White Message-Id: <8905160128.AA24714@bhopal> To: dussud@lucid.com Cc: Moon@STONY-BROOK.SCRC.Symbolics.COM, Gray@dsg.csc.ti.com, common-lisp-object-system@SAIL.STANFORD.EDU, chapman%aitg.dec@decwrl.dec.com In-Reply-To: Patrick Dussud's message of Mon, 15 May 89 09:04:13 PDT <8905151604.AA08623@challenger> Subject: Random metaclasses for CL types re: I think that funcallable-standard-class shouldn't be a subclass of built-in-class. That would break the intuitive concept of specializations: the specialization refines the behavior of its superclass. My note didn't suggest that FUNCALLABLE-STANDARD-CLASS be a subclass of BUILT-IN-CLASS -- I only remarked that there is no reason why it _can't_ be a subclass of STANDARD-CLASS. In the reverse direction -- whether STANDARD-FUNCTION-OBJECTs can have a metaclass that is a subclass of BUILT-IN-CLASS -- well this is probably an implementational issue, isn't it? But on the other hand, I don't see how the "rule of refinement" applies here. Suppose the class B-OBJECT is a "refinement" of A-OBJECT; my message was to elucidate that this does not imply that that the metaclass for B-OBJECT must be a subclass of the metaclasss for A-OBJECT. That is, the subclassing relations between metaclasses are more concerned with _how_ the metaclasses describe the details of their end-products than with _what_ the shape of each end-product is. re: The names STANDARD-FUNCTION-OBJECT and STANDARD-FUNCTION-CLASS are misleading. One can think that Common Lisp functions are standard-function objects. I agree that the current name FUNCALLABLE-STANDARD-CLASS doesn't fit well in the nomenclature, but it is strange enough so it does not have the wrong connotation. I don't follow the reasoning here either. Why would anyone ever think that a class named STANDARD-FUNCTION-OBJECT covers Common Lisp (non- generic) functions? Does anyone ever jump to the conclusion that Common Lisp data types are elements of STANDARD-OBJECT just because of the name? -- JonL -- Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA00383; Tue, 16 May 89 07:02:50 -0700 Reply-To: Received: from Chardonnay.ms by ArpaGateway.ms ; 16 MAY 89 05:51:03 PDT Return-Path: Redistributed: CommonLoops.pa Received: from lucid.com ([192.26.25.1]) by Xerox.COM ; 16 MAY 89 05:47:21 PDT Received: from bhopal ([192.43.178.13]) by heavens-gate id AA05084g; Tue, 16 May 89 05:46:09 PDT Received: by bhopal id AA25471g; Tue, 16 May 89 05:45:56 PDT Date: Tue, 16 May 89 05:45:56 PDT From: Jon L White Message-Id: <8905161245.AA25471@bhopal> To: egdorf%zaphod@LANL.GOV Cc: CommonLoops.pa@Xerox.COM In-Reply-To: egdorf%zaphod@LANL.GOV (Skip Egdorf's message of Fri, 12 May 89 11:23:59 MDT <8905121723.AA00693@zaphod> Subject: Lucid 3.0.2 Optimization botch re: "5/5/89 Cinco de Mayo PCL" has a problem on Lucid 3.0 with the optimizing compiler. On a Sun 3/60, SunOS 4.0.1, Sun Common Lisp 3.0.2, pcl runs test.lisp correctly when compiled with the default (development) compiler mode. However, when (proclaim '(optimize (compilation-speed 0))) is evaluated prior to (load "defsys") in order to use the production mode of the compiler, the following happens: This isn't a bug in Lucid's compiler -- it's a lurking bug in PCL that will "bite" most implementations where different settings of the compiler optimization switches will produce morphologically different (but of course functionally equivalent) function objects. The difficulty is in how discriminator codes service cache misses. They "call out" to (potentially) random functions that will in some cases "smash" the function object that was actually running as the discriminator code. This is all right providing you don't return to that function frame, but alas ... I know this is a more extensive problem because the code in the port-independent function 'notice-methods-change' goes out of its way to do a tail-recursive call to the function that is going to smash the possibly-executing discriminator code. Here is the commentary from that code (sic): ;; In order to prevent this we take a simple measure: we just ;; make sure that it doesn't try to reference our its own closure ;; variables after it makes the dcode change. This is done by ;; having notice-methods-change-2 do the work of making the change ;; AND calling the actual generic function (a closure variable) ;; over. This means that at the time the dcode change is made, ;; there is a pointer to the generic function on the stack where ;; it won't be affected by the change to the closure variables. A similar thing should be done in the construction of standard-accessor, checking, and caching dcodes. In an experimental version here at Lucid, I rewrote dcode.lisp to do that, and there is no problem with it. Although that code is somewhat Lucid-specific, it could be of help to someone who wanted to rewrite the generic dcode.lisp (no pun intended). Contact me privately if you are intersted. Doing a tail-recursive call out of dcodes when there is a cache miss is a good thing, regardless of other problems. I think one might as well do it. However, I should point out that in the presence of multiprocessing, there is another more serious problem that cannot be solved so simply. Think about what happens when one process decides to update a dcode while another process is still using it; no such stack-maintenance discipline will fix this case. A tail-recursive exit from the dcode will *immensely* reduce the likelihood that another process can sneak in during the interval in which the dcode requires consistency in its function; but it can't reduce that likelihood to zero. The more desirable thing to do is to put the whole "dcode" down one more level of indirection through the symbol-function cell of the generic functon. This is effectively what PCL's 'make-trampoline' function does, but unfortunately that is not a very efficient approach when you consider how most compilers will compile it. Something akin to the "mattress-pads" in John Foderaro's code (in the fin.lisp file) could probably be done for many other implementations as well. I don't know who wrote the Lucid specific parts of fin.lisp, but I can supply the Lucid-specific code sequences of corresponding "mattress-pad"'s for several machines to anyone who wants to give it a try. Just doing the tail-recursive exit will probably make the matter essentially moot for all practical purposes. -- JonL -- Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA06106; Tue, 16 May 89 12:23:52 -0700 Reply-To: Received: from Chardonnay.ms by ArpaGateway.ms ; 16 MAY 89 12:24:04 PDT Return-Path: Redistributed: commonloops.pa Received: from cheops.cis.ohio-state.edu ([128.146.8.62]) by Xerox.COM ; 16 MAY 89 12:12:22 PDT Received: by cheops.cis.ohio-state.edu (5.59/4.890516) id AA21769; Tue, 16 May 89 15:12:12 EDT Date: Tue, 16 May 89 15:12:12 EDT From: Arun Welch Message-Id: <8905161912.AA21769@cheops.cis.ohio-state.edu> To: commonloops.pa@Xerox.COM Subject: bug in Walker tests Instead of the lambda body being quoted, it should be #'ed. So, the form should look like: blurf..... (result (walk-form ',form nil #'(lambda (x y env) blurf... ...arun Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA13316; Tue, 16 May 89 17:43:38 -0700 Reply-To: Received: from Salvador.ms by ArpaGateway.ms ; 16 MAY 89 17:43:43 PDT Return-Path: Redistributed: CommonLoops.PA Received: from rand.org ([192.5.14.33]) by Xerox.COM ; 16 MAY 89 17:37:32 PDT Received: from blackcomb.rand.org by rand.org; Tue, 16 May 89 17:26:53 PDT Received: from localhost by blackcomb.arpa; Tue, 16 May 89 17:26:37 PDT Message-Id: <8905170026.AA06874@blackcomb.arpa> To: CommonLoops.PA@Xerox.COM Subject: How to add a new slot-option Date: Tue, 16 May 89 17:26:36 PDT From: Darrell I would like to add a new slot-option. Is there a sanctioned way to do this? For example suppose that I had a vehicle database interfaced to CL. Below is a defclass whose weight slot is to be initialized from the database. (defclass vehicle () ((make :initarg :make :read make :type symbol) (model :initarg :model :reader model :type symbol) (WEIGHT :INITRETRIEVE (lambda (&rest initargs &key make model) (declare (ignore initargs)) (setf make (string make) model (string model)) (retrieve '(column vehicle weight) :where `(and (string= ,make (column vehicle make)) (string= ,model (column vehicle model))))) :reader weight :type integer :documentation "This slot is initialized to the value stored in a database. The vehicle's make and model are used to qualify the desired record.") )) (defmethod shared-initialize :around ((instance vehicle) slot-names &rest initargs) ;; loop over all the slot instances, adding initargs and values for ;; all slots whose :INITRETRIEVE slot-option is not nil. (dolist (slot (pcl::class-slots (class-of instance))) (when (not (null (initretrieve slot))) (setf initargs (apply (list (first (initargs slot)) (apply (initretrieve slot) initargs)) initargs)))) (call-next-method instance slot-names initargs)) I cannot use the slot weight's :initform because its initial value depends upon the initial values of slots make and model. Thanks for any help, Darrell Shane To: CommonLoops.PA@Xerox.COM Subject: How to add a new slot-option -------- I would like to add a new slot-option. Is there a sanctioned way to do this? For example suppose that I had a vehicle database interfaced to CL. Below is a defclass whose weight slot is to be initialized from the database. (defclass vehicle () ((make :initarg :make :read make :type symbol) (model :initarg :model :reader model :type symbol) (WEIGHT :INITRETRIEVE (lambda (&rest initargs &key make model) (declare (ignore initargs)) (setf make (string make) model (string model)) (retrieve '(column vehicle weight) :where `(and (string= ,make (column vehicle make)) (string= ,model (column vehicle model))))) :reader weight :type integer :documentation "This slot is initialized to the value stored in a database. The vehicle's make and model are used to qualify the desired record.") )) (defmethod shared-initialize :around ((instance vehicle) slot-names &rest initargs) ;; loop over all the slot instances, adding initargs and values for ;; all slots whose :INITRETRIEVE slot-option is not nil. (dolist (slot (pcl::class-slots (class-of instance))) (when (not (null (initretrieve slot))) (setf initargs (apply (list (first (initargs slot)) (apply (initretrieve slot) initargs)) initargs)))) (call-next-method instance slot-names initargs)) I cannot use the slot weight's :initform because its initial value depends upon the initial values of slots make and model. Thanks for any help, Darrell Shane Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA13403; Tue, 16 May 89 17:47:30 -0700 Reply-To: Received: from Salvador.ms by ArpaGateway.ms ; 16 MAY 89 17:45:19 PDT Return-Path: Redistributed: commonloops.pa Received: from life.ai.mit.edu ([128.52.32.80]) by Xerox.COM ; 16 MAY 89 17:38:31 PDT Received: from rice-chex.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA21959; Tue, 16 May 89 20:38:04 EDT From: gillett@ai.mit.edu (Walter E. Gillett) Received: by rice-chex.ai.mit.edu (4.1/AI-4.10) id AA13731; Tue, 16 May 89 20:38:02 EDT Date: Tue, 16 May 89 20:38:02 EDT Message-Id: <8905170038.AA13731@rice-chex.ai.mit.edu> To: commonloops.pa@Xerox.COM Cc: gillett@ai.mit.edu Subject: problems with PCL on Allegro 3.0.3/Tektronix When I try (pcl::compile-pcl), the files PKG, WALK, ..., DEFS, and BOOT (nine files in all) compile successfully, but the compiler blows up in the file VECTOR.CL, function LOOKUP-PV-MISS, with the following error message: Error: attempt to call '|PCL STANDARD-GENERIC-FUNCTION predicate|', which is an undefined function. Any suggestions would be greatly appreciated. -Walter P.S. An unrelated note: I have observed the same bug reported by "Darrell " under the heading "Allegro hangs while compiling Cinco de Mayo PCL", 5/15. For some reason, that bug seems to have disappeared. This may have something to do with compiling in the vanilla "cl" environment rather than in the "ccl" loaded by the Franz/GNU Emacs command fi:common-lisp, but I wouldn't swear to it. Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA15247; Tue, 16 May 89 19:43:40 -0700 Reply-To: Received: from Cabernet.ms by ArpaGateway.ms ; 16 MAY 89 19:44:54 PDT Return-Path: Redistributed: commonloops.pa Received: from life.ai.mit.edu ([128.52.32.80]) by Xerox.COM ; 16 MAY 89 19:43:34 PDT Received: from rice-chex.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA22986; Tue, 16 May 89 22:43:12 EDT From: gillett@ai.mit.edu (Walter E. Gillett) Received: by rice-chex.ai.mit.edu (4.1/AI-4.10) id AA14506; Tue, 16 May 89 22:43:10 EDT Date: Tue, 16 May 89 22:43:10 EDT Message-Id: <8905170243.AA14506@rice-chex.ai.mit.edu> To: commonloops.pa@Xerox.COM In-Reply-To: Walter E. Gillett's message of Tue, 16 May 89 20:38:02 EDT <8905170038.AA13731@rice-chex.ai.mit.edu> Subject: problems with PCL on Allegro 3.0.3/Tektronix After further investigation, it turns out that our problems were caused by trying to compile PCL within a LISP world that had the older version of PCL loaded. Compiling PCL in a vanilla LISP world (no PCL) was successful. Apologies- Walter Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA13403; Tue, 16 May 89 17:47:30 -0700 Reply-To: Received: from Salvador.ms by ArpaGateway.ms ; 16 MAY 89 17:45:19 PDT Return-Path: Redistributed: commonloops.pa Received: from life.ai.mit.edu ([128.52.32.80]) by Xerox.COM ; 16 MAY 89 17:38:31 PDT Received: from rice-chex.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA21959; Tue, 16 May 89 20:38:04 EDT From: gillett@ai.mit.edu (Walter E. Gillett) Received: by rice-chex.ai.mit.edu (4.1/AI-4.10) id AA13731; Tue, 16 May 89 20:38:02 EDT Date: Tue, 16 May 89 20:38:02 EDT Message-Id: <8905170038.AA13731@rice-chex.ai.mit.edu> To: commonloops.pa@Xerox.COM Cc: gillett@ai.mit.edu Subject: problems with PCL on Allegro 3.0.3/Tektronix When I try (pcl::compile-pcl), the files PKG, WALK, ..., DEFS, and BOOT (nine files in all) compile successfully, but the compiler blows up in the file VECTOR.CL, function LOOKUP-PV-MISS, with the following error message: Error: attempt to call '|PCL STANDARD-GENERIC-FUNCTION predicate|', which is an undefined function. Any suggestions would be greatly appreciated. -Walter P.S. An unrelated note: I have observed the same bug reported by "Darrell " under the heading "Allegro hangs while compiling Cinco de Mayo PCL", 5/15. For some reason, that bug seems to have disappeared. This may have something to do with compiling in the vanilla "cl" environment rather than in the "ccl" loaded by the Franz/GNU Emacs command fi:common-lisp, but I wouldn't swear to it. Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA13316; Tue, 16 May 89 17:43:38 -0700 Reply-To: Received: from Salvador.ms by ArpaGateway.ms ; 16 MAY 89 17:43:43 PDT Return-Path: Redistributed: CommonLoops.PA Received: from rand.org ([192.5.14.33]) by Xerox.COM ; 16 MAY 89 17:37:32 PDT Received: from blackcomb.rand.org by rand.org; Tue, 16 May 89 17:26:53 PDT Received: from localhost by blackcomb.arpa; Tue, 16 May 89 17:26:37 PDT Message-Id: <8905170026.AA06874@blackcomb.arpa> To: CommonLoops.PA@Xerox.COM Subject: How to add a new slot-option Date: Tue, 16 May 89 17:26:36 PDT From: Darrell I would like to add a new slot-option. Is there a sanctioned way to do this? For example suppose that I had a vehicle database interfaced to CL. Below is a defclass whose weight slot is to be initialized from the database. (defclass vehicle () ((make :initarg :make :read make :type symbol) (model :initarg :model :reader model :type symbol) (WEIGHT :INITRETRIEVE (lambda (&rest initargs &key make model) (declare (ignore initargs)) (setf make (string make) model (string model)) (retrieve '(column vehicle weight) :where `(and (string= ,make (column vehicle make)) (string= ,model (column vehicle model))))) :reader weight :type integer :documentation "This slot is initialized to the value stored in a database. The vehicle's make and model are used to qualify the desired record.") )) (defmethod shared-initialize :around ((instance vehicle) slot-names &rest initargs) ;; loop over all the slot instances, adding initargs and values for ;; all slots whose :INITRETRIEVE slot-option is not nil. (dolist (slot (pcl::class-slots (class-of instance))) (when (not (null (initretrieve slot))) (setf initargs (apply (list (first (initargs slot)) (apply (initretrieve slot) initargs)) initargs)))) (call-next-method instance slot-names initargs)) I cannot use the slot weight's :initform because its initial value depends upon the initial values of slots make and model. Thanks for any help, Darrell Shane To: CommonLoops.PA@Xerox.COM Subject: How to add a new slot-option -------- I would like to add a new slot-option. Is there a sanctioned way to do this? For example suppose that I had a vehicle database interfaced to CL. Below is a defclass whose weight slot is to be initialized from the database. (defclass vehicle () ((make :initarg :make :read make :type symbol) (model :initarg :model :reader model :type symbol) (WEIGHT :INITRETRIEVE (lambda (&rest initargs &key make model) (declare (ignore initargs)) (setf make (string make) model (string model)) (retrieve '(column vehicle weight) :where `(and (string= ,make (column vehicle make)) (string= ,model (column vehicle model))))) :reader weight :type integer :documentation "This slot is initialized to the value stored in a database. The vehicle's make and model are used to qualify the desired record.") )) (defmethod shared-initialize :around ((instance vehicle) slot-names &rest initargs) ;; loop over all the slot instances, adding initargs and values for ;; all slots whose :INITRETRIEVE slot-option is not nil. (dolist (slot (pcl::class-slots (class-of instance))) (when (not (null (initretrieve slot))) (setf initargs (apply (list (first (initargs slot)) (apply (initretrieve slot) initargs)) initargs)))) (call-next-method instance slot-names initargs)) I cannot use the slot weight's :initform because its initial value depends upon the initial values of slots make and model. Thanks for any help, Darrell Shane Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA13316; Tue, 16 May 89 17:43:38 -0700 Reply-To: Received: from Salvador.ms by ArpaGateway.ms ; 16 MAY 89 17:43:43 PDT Return-Path: Redistributed: CommonLoops.PA Received: from rand.org ([192.5.14.33]) by Xerox.COM ; 16 MAY 89 17:37:32 PDT Received: from blackcomb.rand.org by rand.org; Tue, 16 May 89 17:26:53 PDT Received: from localhost by blackcomb.arpa; Tue, 16 May 89 17:26:37 PDT Message-Id: <8905170026.AA06874@blackcomb.arpa> To: CommonLoops.PA@Xerox.COM Subject: How to add a new slot-option Date: Tue, 16 May 89 17:26:36 PDT From: Darrell I would like to add a new slot-option. Is there a sanctioned way to do this? For example suppose that I had a vehicle database interfaced to CL. Below is a defclass whose weight slot is to be initialized from the database. (defclass vehicle () ((make :initarg :make :read make :type symbol) (model :initarg :model :reader model :type symbol) (WEIGHT :INITRETRIEVE (lambda (&rest initargs &key make model) (declare (ignore initargs)) (setf make (string make) model (string model)) (retrieve '(column vehicle weight) :where `(and (string= ,make (column vehicle make)) (string= ,model (column vehicle model))))) :reader weight :type integer :documentation "This slot is initialized to the value stored in a database. The vehicle's make and model are used to qualify the desired record.") )) (defmethod shared-initialize :around ((instance vehicle) slot-names &rest initargs) ;; loop over all the slot instances, adding initargs and values for ;; all slots whose :INITRETRIEVE slot-option is not nil. (dolist (slot (pcl::class-slots (class-of instance))) (when (not (null (initretrieve slot))) (setf initargs (apply (list (first (initargs slot)) (apply (initretrieve slot) initargs)) initargs)))) (call-next-method instance slot-names initargs)) I cannot use the slot weight's :initform because its initial value depends upon the initial values of slots make and model. Thanks for any help, Darrell Shane To: CommonLoops.PA@Xerox.COM Subject: How to add a new slot-option -------- I would like to add a new slot-option. Is there a sanctioned way to do this? For example suppose that I had a vehicle database interfaced to CL. Below is a defclass whose weight slot is to be initialized from the database. (defclass vehicle () ((make :initarg :make :read make :type symbol) (model :initarg :model :reader model :type symbol) (WEIGHT :INITRETRIEVE (lambda (&rest initargs &key make model) (declare (ignore initargs)) (setf make (string make) model (string model)) (retrieve '(column vehicle weight) :where `(and (string= ,make (column vehicle make)) (string= ,model (column vehicle model))))) :reader weight :type integer :documentation "This slot is initialized to the value stored in a database. The vehicle's make and model are used to qualify the desired record.") )) (defmethod shared-initialize :around ((instance vehicle) slot-names &rest initargs) ;; loop over all the slot instances, adding initargs and values for ;; all slots whose :INITRETRIEVE slot-option is not nil. (dolist (slot (pcl::class-slots (class-of instance))) (when (not (null (initretrieve slot))) (setf initargs (apply (list (first (initargs slot)) (apply (initretrieve slot) initargs)) initargs)))) (call-next-method instance slot-names initargs)) I cannot use the slot weight's :initform because its initial value depends upon the initial values of slots make and model. Thanks for any help, Darrell Shane Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA13316; Tue, 16 May 89 17:43:38 -0700 Reply-To: Received: from Salvador.ms by ArpaGateway.ms ; 16 MAY 89 17:43:43 PDT Return-Path: Redistributed: CommonLoops.PA Received: from rand.org ([192.5.14.33]) by Xerox.COM ; 16 MAY 89 17:37:32 PDT Received: from blackcomb.rand.org by rand.org; Tue, 16 May 89 17:26:53 PDT Received: from localhost by blackcomb.arpa; Tue, 16 May 89 17:26:37 PDT Message-Id: <8905170026.AA06874@blackcomb.arpa> To: CommonLoops.PA@Xerox.COM Subject: How to add a new slot-option Date: Tue, 16 May 89 17:26:36 PDT From: Darrell I would like to add a new slot-option. Is there a sanctioned way to do this? For example suppose that I had a vehicle database interfaced to CL. Below is a defclass whose weight slot is to be initialized from the database. (defclass vehicle () ((make :initarg :make :read make :type symbol) (model :initarg :model :reader model :type symbol) (WEIGHT :INITRETRIEVE (lambda (&rest initargs &key make model) (declare (ignore initargs)) (setf make (string make) model (string model)) (retrieve '(column vehicle weight) :where `(and (string= ,make (column vehicle make)) (string= ,model (column vehicle model))))) :reader weight :type integer :documentation "This slot is initialized to the value stored in a database. The vehicle's make and model are used to qualify the desired record.") )) (defmethod shared-initialize :around ((instance vehicle) slot-names &rest initargs) ;; loop over all the slot instances, adding initargs and values for ;; all slots whose :INITRETRIEVE slot-option is not nil. (dolist (slot (pcl::class-slots (class-of instance))) (when (not (null (initretrieve slot))) (setf initargs (apply (list (first (initargs slot)) (apply (initretrieve slot) initargs)) initargs)))) (call-next-method instance slot-names initargs)) I cannot use the slot weight's :initform because its initial value depends upon the initial values of slots make and model. Thanks for any help, Darrell Shane To: CommonLoops.PA@Xerox.COM Subject: How to add a new slot-option -------- I would like to add a new slot-option. Is there a sanctioned way to do this? For example suppose that I had a vehicle database interfaced to CL. Below is a defclass whose weight slot is to be initialized from the database. (defclass vehicle () ((make :initarg :make :read make :type symbol) (model :initarg :model :reader model :type symbol) (WEIGHT :INITRETRIEVE (lambda (&rest initargs &key make model) (declare (ignore initargs)) (setf make (string make) model (string model)) (retrieve '(column vehicle weight) :where `(and (string= ,make (column vehicle make)) (string= ,model (column vehicle model))))) :reader weight :type integer :documentation "This slot is initialized to the value stored in a database. The vehicle's make and model are used to qualify the desired record.") )) (defmethod shared-initialize :around ((instance vehicle) slot-names &rest initargs) ;; loop over all the slot instances, adding initargs and values for ;; all slots whose :INITRETRIEVE slot-option is not nil. (dolist (slot (pcl::class-slots (class-of instance))) (when (not (null (initretrieve slot))) (setf initargs (apply (list (first (initargs slot)) (apply (initretrieve slot) initargs)) initargs)))) (call-next-method instance slot-names initargs)) I cannot use the slot weight's :initform because its initial value depends upon the initial values of slots make and model. Thanks for any help, Darrell Shane Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA23352; Wed, 17 May 89 09:24:36 -0700 Reply-To: Received: from Semillon.ms by ArpaGateway.ms ; 17 MAY 89 09:26:01 PDT Return-Path: Redistributed: commonloops.pa Received: from VAX.BBN.COM ([128.89.0.91]) by Xerox.COM ; 17 MAY 89 09:21:02 PDT To: commonloops.pa@Xerox.COM Subject: CPL and method-update bug (& fix?) Date: Wed, 17 May 89 12:14:24 -0400 From: Mike Thome Message-Id: <890517-092601-16780@Xerox> We've noticed the following bug in Cinco-de-Mayo PCL: (defclass class-a () ()) (defmethod meth-1 ((x class-a)) (print 'class-a)) ;; ^- recomputes combination points (defclass b-mixin () ()) (defmethod meth-1 :after ((x b-mixin)) (print 'b-mixin)) (meth-1 (make-instance 'class-a)) ;compute-c-p ;; ^- recomputes combination points (defclass a-and-b (b-mixin class-a) ()) ;; ^- doesn't recompute combination points (meth-1 (make-instance 'a-and-b)) ;; ^- doesn't recompute combination points, and blows up with ;; "no applicable primary method" error. Below is a fix for the problem - probably not the *right* one, but it does seem to make things work: (defmethod update-method-inheritance ((class standard-class) old-cpl new-cpl) (unless (or ;(null old-cpl) ; mthome@bbn - for new ones, too (equal old-cpl new-cpl)) (let* ((shared-tail (shared-tail old-cpl new-cpl)) (old (butlast old-cpl (length shared-tail))) (new (butlast new-cpl (length shared-tail))) (seen-gfs ())) (labels ((consider-gf (gf) (unless (memq gf seen-gfs) (push gf seen-gfs) (when (check-method-precedences gf) (update gf)))) (check-method-precedences (gf) (block check-method-precedences (let* ((specializers (delete-duplicates (apply #'append (mapcar #'method-type-specifiers (generic-function-methods gf))))) (old-precedence (gathering1 (collecting) (dolist (o old) (when (memq o specializers) (gather1 o)))))) (dolist (n new) (when (memq n specializers) (unless (eq n (pop old-precedence)) (return-from check-method-precedences t))))))) (update (gf) (invalidate-generic-function gf))) (dolist (o old) (dolist (dm (class-direct-methods o)) (consider-gf (method-generic-function dm)))) (dolist (n new) (unless (memq n old) (dolist (dm (class-direct-methods n)) (consider-gf (method-generic-function dm))))))))) Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA24309; Wed, 17 May 89 10:02:51 -0700 Reply-To: Received: from Cabernet.ms by ArpaGateway.ms ; 17 MAY 89 10:04:11 PDT Return-Path: Redistributed: CommonLoops.PA Received: from DINO.BBN.COM ([128.89.3.8]) by Xerox.COM ; 17 MAY 89 10:00:34 PDT To: Owners-CommonLoops.PA@Xerox.COM Cc: CommonLoops.PA@Xerox.COM Subject: Re: How to add a new slot-option In-Reply-To: Your message of Tue, 16 May 89 17:26:36 -0700. <8905170026.AA06874@blackcomb.arpa> Date: Wed, 17 May 89 13:05:10 -0400 From: kanderso@DINO.BBN.COM Message-Id: <890517-100411-16910@Xerox> To add a new slot-option: 1. Write a metaclasps that provides: a legal-class-option-p :around method a parse-class-slot :primary method 2. Define a new class of slot-discription that contains what you need. An alternative to retrieving the weight, might be to look it up in an :AFTER INITIALIZE-INSTANCEif it isn't slot-bound. Would that be satisfactory? Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA13316; Tue, 16 May 89 17:43:38 -0700 Reply-To: Received: from Salvador.ms by ArpaGateway.ms ; 16 MAY 89 17:43:43 PDT Return-Path: Redistributed: CommonLoops.PA Received: from rand.org ([192.5.14.33]) by Xerox.COM ; 16 MAY 89 17:37:32 PDT Received: from blackcomb.rand.org by rand.org; Tue, 16 May 89 17:26:53 PDT Received: from localhost by blackcomb.arpa; Tue, 16 May 89 17:26:37 PDT Message-Id: <8905170026.AA06874@blackcomb.arpa> To: CommonLoops.PA@Xerox.COM Subject: How to add a new slot-option Date: Tue, 16 May 89 17:26:36 PDT From: Darrell I would like to add a new slot-option. Is there a sanctioned way to do this? For example suppose that I had a vehicle database interfaced to CL. Below is a defclass whose weight slot is to be initialized from the database. (defclass vehicle () ((make :initarg :make :read make :type symbol) (model :initarg :model :reader model :type symbol) (WEIGHT :INITRETRIEVE (lambda (&rest initargs &key make model) (declare (ignore initargs)) (setf make (string make) model (string model)) (retrieve '(column vehicle weight) :where `(and (string= ,make (column vehicle make)) (string= ,model (column vehicle model))))) :reader weight :type integer :documentation "This slot is initialized to the value stored in a database. The vehicle's make and model are used to qualify the desired record.") )) (defmethod shared-initialize :around ((instance vehicle) slot-names &rest initargs) ;; loop over all the slot instances, adding initargs and values for ;; all slots whose :INITRETRIEVE slot-option is not nil. (dolist (slot (pcl::class-slots (class-of instance))) (when (not (null (initretrieve slot))) (setf initargs (apply (list (first (initargs slot)) (apply (initretrieve slot) initargs)) initargs)))) (call-next-method instance slot-names initargs)) I cannot use the slot weight's :initform because its initial value depends upon the initial values of slots make and model. Thanks for any help, Darrell Shane To: CommonLoops.PA@Xerox.COM Subject: How to add a new slot-option -------- I would like to add a new slot-option. Is there a sanctioned way to do this? For example suppose that I had a vehicle database interfaced to CL. Below is a defclass whose weight slot is to be initialized from the database. (defclass vehicle () ((make :initarg :make :read make :type symbol) (model :initarg :model :reader model :type symbol) (WEIGHT :INITRETRIEVE (lambda (&rest initargs &key make model) (declare (ignore initargs)) (setf make (string make) model (string model)) (retrieve '(column vehicle weight) :where `(and (string= ,make (column vehicle make)) (string= ,model (column vehicle model))))) :reader weight :type integer :documentation "This slot is initialized to the value stored in a database. The vehicle's make and model are used to qualify the desired record.") )) (defmethod shared-initialize :around ((instance vehicle) slot-names &rest initargs) ;; loop over all the slot instances, adding initargs and values for ;; all slots whose :INITRETRIEVE slot-option is not nil. (dolist (slot (pcl::class-slots (class-of instance))) (when (not (null (initretrieve slot))) (setf initargs (apply (list (first (initargs slot)) (apply (initretrieve slot) initargs)) initargs)))) (call-next-method instance slot-names initargs)) I cannot use the slot weight's :initform because its initial value depends upon the initial values of slots make and model. Thanks for any help, Darrell Shane Received: from Sail.Stanford.EDU by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA26405; Thu, 18 May 89 12:15:21 -0700 Reply-To: Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 18 May 89 12:12:40 PDT Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 597188; 18 May 89 15:06:17 EDT Date: Thu, 18 May 89 15:06 EDT From: David A. Moon Subject: Random metaclasses for CL types To: Jon L White Cc: Gray@dsg.csc.ti.com, common-lisp-object-system@SAIL.STANFORD.EDU, chapman%aitg.dec@decwrl.dec.com In-Reply-To: <8905140110.AA18947@bhopal> Message-Id: <19890518190611.8.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Sat, 13 May 89 18:10:29 PDT From: Jon L White re: . . . The idea is that if a user program assumes it might be a built-in-class, an implementation can't screw the user over by coming with an implementation-defined class that's even worse (can't appear as the cdr of a cons or something). Maybe a positive way to say this is that such instances must be "first-class" -- i.e, can be passed as arguments to functions, can be cons'd into list structure, can be specialized upon by generic functions, don't crash the system if you try to print them, etc. Better to know where the alligator *is* than where he isn't. I completely disagree. I do not want to define this in terms of a possibly incomplete list of things you can do with these objects. I want to define it so that a program that assumes that all specified types are of metaclass BUILT-IN-CLASS is a conforming program and will work in all implementations regardless of what the actual metaclass is. Can we come up with a wording that clearly and unambiguously expresses that idea? re: Or maybe you really meant that (class-name (class-of (find-class 'function))) --> BUILT-IN-CLASS but (class-name (class-of (find-class 'generic-function))) --> FUNCALLABLE-STANDARD-CLASS and (subclassp 'FUNCALLABLE-STANDARD-CLASS 'BUILT-IN-CLASS) --> NIL which is specified either by 88-002R or the draft metaobject protocol, I forget which. Anyway this example shows that you don't have to worry. Why, yes, as a matter of fact, that's precisely what I was hinting at. However I don't see any particular consequence of requiring FUNCALLABLE-STANDARD-CLASS to be a subclass of STANDARD-CLASS rather than of BUILT-IN-CLASS. It's certainly possible for one subclass of STANDARD-CLASS to paint a totally different picture of its instances than some other random subclass of STANDARD-CLASS does. Since FUNCALLABLE-STANDARD-CLASS is purely chapter 3, I don't want to digress into discussing it now. .... This is what STANDARD-FUNCTION-CLASS would represent -- regular, accessible structure of the functions. I'd be particularly curious as to how you two Daves feel about this. FUNCALLABLE-STANDARD-CLASS is a bad name, but STANDARD-FUNCTION-CLASS is worse. I'm not sure that name needs to be defined in chapter 3, though; I think it might suffice to say that the implementation provides GENERIC-FUNCTION with an appropriate metaclass without naming that metaclass, particularly since chapter 3 no longer specifies the action of the SLOT-VALUE function on any metaobject. FUNCALLABLE-STANDARD-CLASS may just be an artifact of the implementation used in PCL. Now you know how this Dave feels about it. .... Why would anyone ever think that a class named STANDARD-FUNCTION-OBJECT covers Common Lisp (non- generic) functions? Does anyone ever jump to the conclusion that Common Lisp data types are elements of STANDARD-OBJECT just because of the name? Yes. The name STANDARD-OBJECT is definitely a problem for that reason. It's a bit late in the day to change it, though, and I don't recall ever hearing a suggested name I liked better, even though this has been discussed on several occasions in the past. Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA02341; Thu, 18 May 89 17:32:42 -0700 Reply-To: Received: from Salvador.ms by ArpaGateway.ms ; 18 MAY 89 15:27:27 PDT Return-Path: Redistributed: commonloops.pa Received: from uunet.UU.NET ([192.48.96.2]) by Xerox.COM ; 18 MAY 89 15:24:27 PDT Received: from franz.UUCP by uunet.UU.NET (5.61/1.14) with UUCP id AA13163; Thu, 18 May 89 18:24:11 -0400 Received: by franz.franz.uucp (MC 2.0/FI-0.96) id AA02530; Thu, 18 May 89 14:53:20 PDT Received: by snooze.franz.uucp (4.0/FI-0.96) id AA12511; Thu, 18 May 89 14:52:17-080 From: layer%franz.uucp@uunet.UU.NET (Kevin Layer) Message-Id: <8905182252.AA12511@snooze.franz.uucp> To: commonloops.pa@Xerox.COM Subject: 5/5/89 PCL on Allegro CL 3.0 Date: Thu, 18 May 89 14:52:12 -0800 I have just verified that PCL works on vanilla Allegro CL versions: 3.0.1beta on Sun4 3.0.3 on Sun3 3.1beta on Sun3 and Sun4 No patches were necessary for compilation. To test, I loaded test.lisp, without warning or error. I don't know how to explain the problems people have had--maybe it is related to the first two versions of 5/5/89 PCL that Gregor released. If anyone is still having trouble, let me know. Kevin Layer Franz Inc. Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA02439; Thu, 18 May 89 17:37:18 -0700 Reply-To: Received: from Semillon.ms by ArpaGateway.ms ; 18 MAY 89 12:55:45 PDT Return-Path: Redistributed: CommonLoops.pa Received: from inria.inria.fr ([128.93.8.1]) by Xerox.COM ; 18 MAY 89 12:52:55 PDT Received: by inria.inria.fr (5.61+/89.0.7) via Fnet-EUnet id AA23110; Thu, 18 May 89 21:50:50 +0200 (MET) From: ralph@nastassia.laas.fr Received: from nastassia.laas.fr (nastassia.ARPA) by laas.laas.fr, Thu, 18 May 89 18:49:17 -0200 Date: Thu, 18 May 89 18:53:07 +0200 Received: by nastassia.laas.fr, Thu, 18 May 89 18:53:07 +0200 Message-Id: <8905181653.AA09437@nastassia.laas.fr> To: CommonLoops.pa@Xerox.COM, info-1100@cis.ohio-state.edu Subject: Unable to compile Cinco de Mayo PCL in Medley Under Medley on a Xerox 1186, the new PCL balks in the file boot.lisp. It gives a "BUG: Inconsistent stack depths seen." under EARLY-DFUN. I am using the "19-Sep-88 17:45:52" sysout of Medley -- not the new Medley 1.1. This may be either a tail-recursion problem (it occurs under the FLET) or a Medley bug. I am not used to the compiler stack traces, but the code/stack frames just above the call to STACK-ANALYSE are: EARLY-DFUN, SORT-METHODS, and "lambda in SORT-METHODS". Has anyone else encountered this problem and does there exist a patch? I hope that the description was informative enough. Ralph P. Sobek Disclaimer: The above ruminations are my own. ralph@laas.laas.fr Addresses are ordered by importance. ralph@laas.uucp, or ...!uunet!mcvax!laas!ralph If all else fails, try: SOBEK@FRMOP11.BITNET sobek@eclair.Berkeley.EDU Received: from Sail.Stanford.EDU by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA00736; Fri, 19 May 89 07:29:54 -0700 Reply-To: Received: from lucid.com by SAIL.Stanford.EDU with TCP; 19 May 89 07:28:26 PDT Received: from bhopal ([192.43.178.13]) by heavens-gate id AA24181g; Fri, 19 May 89 07:24:44 PDT Received: by bhopal id AA04129g; Fri, 19 May 89 07:23:58 PDT Date: Fri, 19 May 89 07:23:58 PDT From: Jon L White Message-Id: <8905191423.AA04129@bhopal> To: Moon@STONY-BROOK.SCRC.Symbolics.COM Cc: Gray@dsg.csc.ti.com, common-lisp-object-system@SAIL.STANFORD.EDU, chapman%aitg.dec@decwrl.dec.com In-Reply-To: David A. Moon's message of Thu, 18 May 89 15:06 EDT <19890518190611.8.MOON@EUPHRATES.SCRC.Symbolics.COM> Subject: Random metaclasses for CL types re: [The "holy" types of 88-002R, pages 1-16 and 1-17] I want to define it so that a program that assumes that all specified types are of metaclass BUILT-IN-CLASS is a conforming program and will work in all implementations regardless of what the actual metaclass is. Can we come up with a wording that clearly and unambiguously expresses that idea? Well, foo, this loosely worded specification implies that the metaclasses of the "holy" types are in fact subclasses of BUILT-IN-CLASS. And that's precisely what I thought you were trying to avoid prescribing. The example discussed in previous mail -- STANDARD-FUNCTION-CLASS (?) -- wasn't shown as a subclass of BUILT-IN-CLASS precisely because Chap 3 requires it to be a direct sublcass of STANDARD-CLASS instead. I wouldn't be against changing this and simply saying, quite up-front, that all implementation-specific metaclasses covering the "holy" types must be subclasses of BUILT-IN-CLASS (i.e. those which are not of metaclass STANDARD-CLASS or STRUCTURE-CLASS). Perhaps we could investigate the possibilities of having a broad enough definition for BUILT-IN-CLASS so that your flavor-implemented types could be covered? I don't see much in 88-002R that overly constrains built-in classes. re: FUNCALLABLE-STANDARD-CLASS is a bad name, but STANDARD-FUNCTION-CLASS is worse. I'm not sure that name needs to be defined in chapter 3, though; I think it might suffice to say that the implementation provides GENERIC-FUNCTION with an appropriate metaclass without naming that metaclass, particularly since chapter 3 no longer specifies the action of the SLOT-VALUE function on any metaobject. FUNCALLABLE-STANDARD-CLASS may just be an artifact of the implementation used in PCL. The point of STANDARD-FUNCTION-CLASS is *not* that it is the metaclass of GENERIC-FUNCTION, but rather of an orthogonal set of functions that have "standard" structure. PCL uses it to make "constructors", which are functions but not generic-functions. You're right that this is probably a PCL-inspired artifact; but it's not completely senseless. It's justifiable in Chap 3 only to the extent that someone else might want to do something like PCL's constructors. I'll leave it to Gregor to defend them. But if you think it's unlikely that Chap 3 will have a serious impact, then perhaps it isn't worth discussing yet. Since no one objected to the subclass links in my earlier mail , I take it that the following subclass graph is obvious [regardless of the metaclass links]? FUNCTION / | \ / | \ / | \ / | \ / | \ / | \ / | \ GENERIC-FUNCTION {OtherFuns} {STANDARD-FUNCTION} \ / | \ \ / | \ \ / | \ \ / | \ \ / | \ \ / | \ \ / | \ STANDARD-GENERIC-FUNCTION {Hunoz?} {PCL-Constructors} -- JonL -- Received: from Sail.Stanford.EDU by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA01640; Fri, 19 May 89 08:45:29 -0700 Reply-To: Received: from lucid.com by SAIL.Stanford.EDU with TCP; 19 May 89 08:43:51 PDT Received: from challenger ([192.9.200.17]) by heavens-gate id AA24497g; Fri, 19 May 89 08:38:06 PDT Received: by challenger id AA03510g; Fri, 19 May 89 08:36:55 PDT Date: Fri, 19 May 89 08:36:55 PDT From: Patrick Dussud Message-Id: <8905191536.AA03510@challenger> To: jonl@lucid.com Cc: Moon@STONY-BROOK.SCRC.Symbolics.COM, Gray@dsg.csc.ti.com, common-lisp-object-system@SAIL.STANFORD.EDU, chapman%aitg.dec@decwrl.dec.com In-Reply-To: Jon L White's message of Fri, 19 May 89 07:23:58 PDT <8905191423.AA04129@bhopal> Subject: Random metaclasses for CL types Date: Fri, 19 May 89 07:23:58 PDT From: Jon L White re: [The "holy" types of 88-002R, pages 1-16 and 1-17] I want to define it so that a program that assumes that all specified types are of metaclass BUILT-IN-CLASS is a conforming program and will work in all implementations regardless of what the actual metaclass is. Can we come up with a wording that clearly and unambiguously expresses that idea? Well, foo, this loosely worded specification implies that the metaclasses of the "holy" types are in fact subclasses of BUILT-IN-CLASS. And that's precisely what I thought you were trying to avoid prescribing. I disagree. It means that the external protocol supported by the implementation dependent metaclass needs to cover the capabilities BUILT-IN-CLASS. This can be achieved independently of the taxinomy of metaclasses. I don't think we want the users to rely on the taxinomy of metaclasses at this point. The example discussed in previous mail -- STANDARD-FUNCTION-CLASS (?) -- wasn't shown as a subclass of BUILT-IN-CLASS precisely because Chap 3 requires it to be a direct sublcass of STANDARD-CLASS instead. I wouldn't be against changing this and simply saying, quite up-front, that all implementation-specific metaclasses covering the "holy" types must be subclasses of BUILT-IN-CLASS (i.e. those which are not of metaclass STANDARD-CLASS or STRUCTURE-CLASS). I would be against it. Perhaps we could investigate the possibilities of having a broad enough definition for BUILT-IN-CLASS so that your flavor-implemented types could be covered? I don't see much in 88-002R that overly constrains built-in classes. I would be against having Flavor's metaclass be a subclass of BUILT-IN-CLASS. Flavors are much closer to STANDARD-CLASS than they are from BUILT-IN-CLASS. Since no one objected to the subclass links in my earlier mail , I take it that the following subclass graph is obvious [regardless of the metaclass links]? FUNCTION / | \ / | \ / | \ / | \ / | \ / | \ / | \ GENERIC-FUNCTION {OtherFuns} {STANDARD-FUNCTION} \ / | \ \ / | \ \ / | \ \ / | \ \ / | \ \ / | \ \ / | \ STANDARD-GENERIC-FUNCTION {Hunoz?} {PCL-Constructors} As far as the standard is concrned, we are interested only in: function | generic function | standard-generic-function and that's OK with me. Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA10487; Fri, 19 May 89 12:07:44 -0700 Reply-To: Received: from Burger.ms by ArpaGateway.ms ; 19 MAY 89 11:20:20 PDT Return-Path: Redistributed: commonloops.pa Received: from life.ai.mit.edu ([128.52.32.80]) by Xerox.COM ; 19 MAY 89 11:18:19 PDT Received: from wheat-chex.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA02829; Fri, 19 May 89 14:17:53 EDT From: gillett@ai.mit.edu (Walter E. Gillett) Received: by wheat-chex.ai.mit.edu (4.1/AI-4.10) id AA01016; Fri, 19 May 89 14:17:51 EDT Date: Fri, 19 May 89 14:17:51 EDT Message-Id: <8905191817.AA01016@wheat-chex.ai.mit.edu> To: commonloops.pa@Xerox.COM Cc: gillett@ai.mit.edu Subject: default initargs bug with 5/5/89 PCL I am running PCL in Allegro CL V3.0.3 on a Tektronix 4319. I found this bug in the Cinco de Mayo version of PCL: With DEFAULT-INITARGS, I should be able to provide default values for any initialization argument, whether it initializes a slot or is passed to a method. However, the current PCL provides defaults for method initargs only when either the defclass or the defmethod is evaluated more than once: ------------------------------------------------------------ Without :default-initargs, I get the behavior I would expect: (defclass class1 () ()) NIL (defmethod initialize-instance :after ((class1 class1) &key keyword) (format t "Keyword: ~S~%" keyword)) NIL (make-instance 'class1) Keyword: NIL # (make-instance 'class1 :keyword 100) Keyword: 100 # ------------------------------------------------------------ With :default-initargs, however, I get pathological behavior: (defclass class2 () () (:default-initargs :keyword 'default)) NIL (defmethod initialize-instance :after ((class2 class2) &key keyword) (format t "Keyword: ~S~%" keyword)) NIL (make-instance 'class2) Error: Invalid initialization argument :KEYWORD for class CLASS2 [1] :pop (make-instance 'class2 :keyword 100) Error: Invalid initialization argument :KEYWORD for class CLASS2 [1] :pop ;;; If I reevaluate the defmethod, it starts acting correctly: (defmethod initialize-instance :after ((class2 class2) &key keyword) (format t "Keyword: ~S~%" keyword)) NIL (make-instance 'class2) Keyword: DEFAULT # (make-instance 'class2 :keyword 100) Keyword: 100 # ------------------------------------------------------------ Any suggestions? -Seth Goldstein (message forwarded by W. Gillett) Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA00472; Mon, 22 May 89 13:32:51 -0700 Received: from Chardonnay.ms by ArpaGateway.ms ; 19 MAY 89 14:04:28 PDT Return-Path: Redistributed: commonloops.pa Received: from kanga.parc.xerox.com ([13.2.16.53]) by Xerox.COM ; 19 MAY 89 13:58:20 PDT Received: by kanga.parc.xerox.com (5.61+/IDA-1.2.8/gandalf) id AA04238; Fri, 19 May 89 13:58:19 PDT Message-Id: <8905192058.AA04238@kanga.parc.xerox.com> Date: Fri, 19 May 89 13:58:19 PDT From: Dan Rabin To: commonloops.pa@arisia.Xerox.COM Subject: Minor mod needed to Coral %stack-block walker template patch Reply-To: rabin@arisia.Xerox.COM The following will interest users of PCL in Coral (Allegro) Common Lisp 1.2.1 or 1.2.2 for the Macintosh: Symptom: compilation of ccl:rlet within pcl:with-slots fails. Fix: In Cinco de Mayo PCL as it was retrievable from Arisia on 18 May, the file walk.lisp contains #+Coral (define-walker-template ccl:%stack-block walk-let) This should be changed to #+:Coral ... for the reason that Coral Common Lisp does not coerce conditional-read feature-names to the keyword package. --Dan Rabin Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA00533; Mon, 22 May 89 13:37:17 -0700 Reply-To: Received: from Semillon.ms by ArpaGateway.ms ; 19 MAY 89 13:36:47 PDT Date: Fri, 19 May 89 13:32 PDT From: Gregor.pa@Xerox.COM Subject: runtime calls to the compiler To: David Alpern Cc: commonloops.pa@Xerox.COM Fcc: BD:>Gregor>mail>outgoing-mail-6.text.newest In-Reply-To: The message of 9 May 89 11:04 PDT from David Alpern Message-Id: <19890519203224.3.GREGOR@SPIFF.parc.xerox.com> Line-Fold: no Date: Tue, 09 May 89 11:04:59 PDT From: David Alpern PCL seems to do some compilation (i.e., invokes lisp's compiler) as programs begin to run (first create objects, perhaps?), even if the lisp program files have been compiled first. Is there some way to cause whatever compilation is going on to occur during the lisp program file compilation and get captured in the compiled form? This compilation has two different sources. While there has been a rough solution to this problem (precompile-random-code-segments) for quite some time, more elegant and useful solutions are under development now. In Cinco de Mayo and later versions of PCL, setting the variable *compiler-present-p* to nil will prevent extra calls to the compiler. On the other hand, this will degrade system performance unreasonably. A major change under development right now is a mechanism which prevents PCL from having to call the compiler to generate method lookup code. Once this change is in place, I will install a facility which precompiles so called method combinationes (effective-methods) which will take care of the remaining spurious calls to the compiler. ------- Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA00694; Mon, 22 May 89 13:43:13 -0700 Reply-To: Received: from Cabernet.ms by ArpaGateway.ms ; 22 MAY 89 09:54:34 PDT Date: Mon, 22 May 89 09:52 PDT From: Gregor.pa@Xerox.COM Subject: Re: Lucid 3.0.2 Optimization botch To: Jon L White Cc: egdorf%zaphod@LANL.GOV, CommonLoops.pa@Xerox.COM Fcc: BD:>Gregor>mail>outgoing-mail-6.text.newest In-Reply-To: <8905161245.AA25471@bhopal> Message-Id: <19890522165243.3.GREGOR@SPIFF.parc.xerox.com> Line-Fold: no Date: Tue, 16 May 89 05:45:56 PDT From: Jon L White The more desirable thing to do is to put the whole "dcode" down one more level of indirection through the symbol-function cell of the generic functon. This is effectively what PCL's 'make-trampoline' function does, but unfortunately that is not a very efficient approach when you consider how most compilers will compile it. Something akin to the "mattress-pads" in John Foderaro's code (in the fin.lisp file) could probably be done for many other implementations as well. I don't know who wrote the Lucid specific parts of fin.lisp, but I can supply the Lucid-specific code sequences of corresponding "mattress-pad"'s for several machines to anyone who wants to give it a try. If you rewrite the Lucid part of FIN to do this mattress-pad stuff then I can install it in PCL and fix this longstanding problem. Just doing the tail-recursive exit will probably make the matter essentially moot for all practical purposes. The problem crops up all the time here for people using PCL in Lucid Lisp. ------- Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA00720; Mon, 22 May 89 13:45:24 -0700 Reply-To: Received: from Semillon.ms by ArpaGateway.ms ; 22 MAY 89 09:57:50 PDT Date: Mon, 22 May 89 09:49 PDT From: Gregor.pa@Xerox.COM Subject: Re: Unable to compile Cinco de Mayo PCL in Medley To: ralph@nastassia.laas.fr Cc: CommonLoops.pa@Xerox.COM, info-1100@cis.ohio-state.edu Fcc: BD:>Gregor>mail>outgoing-mail-6.text.newest In-Reply-To: <8905181653.AA09437@nastassia.laas.fr> Message-Id: <19890522164932.2.GREGOR@SPIFF.parc.xerox.com> Line-Fold: no Date: Thu, 18 May 89 18:53:07 +0200 From: ralph@nastassia.laas.fr Under Medley on a Xerox 1186, the new PCL balks in the file boot.lisp. It gives a "BUG: Inconsistent stack depths seen." under EARLY-DFUN. I am using the "19-Sep-88 17:45:52" sysout of Medley -- not the new Medley 1.1. This bug, and another which prevented compilation in Xerox Lisp (Medley) have been fixed and will be released later today. ------- Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA03072; Mon, 22 May 89 16:18:09 -0700 Received: from Burger.ms by ArpaGateway.ms ; 22 MAY 89 16:13:42 PDT Return-Path: <@uunet.UU.NET,@andersen.uucp:debellis@Andersen.COM> Redistributed: commonloops.pa Received: from arisia.Xerox.COM ([13.1.100.206]) by Xerox.COM ; 22 MAY 89 16:11:17 PDT Received: from uunet.UU.NET by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA02974; Mon, 22 May 89 16:09:10 -0700 Reply-To: Received: from andersen.UUCP by uunet.UU.NET (5.61/1.14) with UUCP id AA16806; Mon, 22 May 89 19:10:57 -0400 Received: from bergman. by Andersen.COM (4.0/SMI-4.0) id AA12586; Mon, 22 May 89 17:05:10 CDT Date: Mon, 22 May 89 17:05:10 CDT From: Michael DeBellis Message-Id: <8905222205.AA12586@Andersen.COM> To: commonloops.pa@arisia.Xerox.COM Subject: Creating new slot options I would like to add new options to slots. For example I would like to be able to state the cardinality (legal number of values) and value-class of a slot. I would like the value class to be much more than the :tyype option since I want the system to take action when it encounters a value that does not satisfy a value-class (e.g. warn the user and enable her/him to fix it). Essentially what I want is to add "facets" as they are used in KEE and other Frame oriented languages. It seems to me that the best way to do this is to create my own slot options. Is this possible? If possible how difficult is it? Would I have to get into PCL internals? Is there a better way to do it? Thanks in Advance Mike DeBellis Received: from Sail.Stanford.EDU by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA04745; Mon, 22 May 89 18:39:27 -0700 Reply-To: Received: from lucid.com by SAIL.Stanford.EDU with TCP; 22 May 89 18:38:32 PDT Received: from bhopal ([192.43.178.13]) by heavens-gate id AA03791g; Fri, 19 May 89 21:09:03 PDT Received: by bhopal id AA05273g; Fri, 19 May 89 21:07:17 PDT Date: Fri, 19 May 89 21:07:17 PDT From: Jon L White Message-Id: <8905200407.AA05273@bhopal> To: dussud@lucid.com, Gray@dsg.csc.ti.com Cc: Moon@STONY-BROOK.SCRC.Symbolics.COM, common-lisp-object-system@SAIL.STANFORD.EDU, chapman%aitg.dec@decwrl.dec.com In-Reply-To: Patrick Dussud's message of Fri, 19 May 89 08:36:55 PDT <8905191536.AA03510@challenger> Subject: Random metaclasses for CL types re: . . . It means that the external protocol supported by the implementation dependent metaclass needs to cover the capabilities BUILT-IN-CLASS. This can be achieved independently of the taxinomy of metaclasses. I don't think we want the users to rely on the taxinomy of metaclasses at this point. On the first two points, we are quite in agreement. But the taxonomy *is* user-visible; and for any flavor-implemented "holy" type, it wouldn't satisfy all the BUILT-IN-CLASS capabilities unless it had a similar hierarchy. Unless Moon wants to be more explicit on what he wants out of portability of BUILT-IN-CLASS, I would have to assume that it includes taxonomy. Now, as Gray says, flavor-implemented classes **in general** have some structural features that BUILT-IN-CLASS types don't have. But this isn't an argument against using a particlar one to support a BUILT-IN-CLASS element, because a sufficiently-restrictive set of methods on that flavor-implemented class will strip it of its apparent slots. On the other hand, why shouldn't some limited set of BUILT-IN-CLASS elements respond to, say, SLOT-VALUE? The question is, How do you view the limitations of BUILT-IN-CLASS -- as merely a limit on what is guaranteed to be available, or as an absolute prohibition on what shall not be available? If anything, the trouble we seem to be having in pinpointing the problem is that BUILT-IN-CLASS is a purely synthetic concept that agglomerates numerous totally-independent structures [e.g., how is FLOAT, say, related to SYMBOL?]. The only thing that relates them together -- regardless of their inner details (e.g "standard" slots or not) is their opacity in the class system. I.e., you can specialize on their type, but you can't generally do any other structural operations such as "make an instance", expose a "slot", etc. Now, in the FUNCTION domain, it's true that the standard so far has only spoken about: function | generic function | standard-generic-function Except for Chap 3, it hasn't even spoken about what relationship, *** if any **, there is between the metaclass of FUNCTION and that of STANDARD-GENERIC-FUNCTION. Have we finally agreed even if FUNCTION is implemented as BUILT-IN-CLASS, this places no particluar constraint on what the class of STANDARD-GENERIC-FUNCTION is? including whether or not it is BUILT-IN-CLASS or STANDARD-CLASS? What I was trying to illustrate with the bifurcated tree: function / \ / \ / \ / \ generic-function standard-function \ / \ / \ / \ / standard-generic-function is that we could have somewhat random metaclasses for GENERIC-FUNCTION and STANDARD-FUNCTION; hence, even though STANDARD-GENERIC-FUNCTION is a subclass of both, it could have a totally different metaclass. The constraints needed for metaclass "compatibility" don't seem to be encompassed by subclass relationships. In fact, GENERIC-FUNCTION seems almost worthless. What might show a truer picture is a GENERIC mixin, which when combined with STANDARD-FUNCTION yields STANDARD-GENERIC-FUNCTION. But I must confess that the GENERIC mixin probably wouldn't be of use anywhere else. One last point -- as Gray mentions, there isn't an obvious meaning for STANDARD-FUNCTION. I've abstracted that from what Gregor calls "funcallable instances" in PCL. The trouble with the latter term is that *all* functions are "funcallable instances" in some sense, in that you can FUNCALL them. The crucial difference is in a little protocol puts two "slots" into an othewise vanilla funtion; this is what makes them "standard" in my view. Mostly I'm raising these issues about subclasses and metaclasse of FUNCTION as a Chap 3 point, since it is there where substructure of FUNCTION can be exposed. And I think it is a good thing to do so, since expert Lisp users have *always* wanted to know the structure of functions and tinker with them in some superficial but tremendously useful way. PCL's "fins" are a prime example of this, and I don't suspect that they'll be the last. -- JonL -- Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA04723; Mon, 22 May 89 18:38:25 -0700 Reply-To: Received: from Cabernet.ms by ArpaGateway.ms ; 22 MAY 89 18:37:04 PDT Date: 22 May 89 18:35 PDT From: Burwell.pa@Xerox.COM Subject: Re: Unable to compile Cinco de Mayo PCL in Medley In-Reply-To: Gregor.pa's message of Mon, 22 May 89 09:49 PDT To: Gregor.pa@Xerox.COM Cc: CommonLoops.pa@Xerox.COM, Lanning.pa@Xerox.COM Message-Id: <890522-183704-6275@Xerox> Re: the bug will be fixed later today... can you please tell me where the patch is? I'll put it in the sysout and in our patches directory. Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA09184; Tue, 23 May 89 00:03:26 -0700 Reply-To: Received: from Semillon.ms by ArpaGateway.ms ; 23 MAY 89 00:04:46 PDT Return-Path: Redistributed: CommonLoops.pa Received: from lucid.com ([192.26.25.1]) by Xerox.COM ; 23 MAY 89 00:02:42 PDT Received: from bhopal ([192.43.178.13]) by heavens-gate id AA04591g; Tue, 23 May 89 00:00:32 PDT Received: by bhopal id AA10294g; Tue, 23 May 89 00:00:14 PDT Date: Tue, 23 May 89 00:00:14 PDT From: Jon L White Message-Id: <8905230700.AA10294@bhopal> To: Gregor.pa@Xerox.COM Cc: egdorf%zaphod@LANL.GOV, CommonLoops.pa@Xerox.COM In-Reply-To: Gregor.pa@Xerox.COM's message of Mon, 22 May 89 09:52 PDT <19890522165243.3.GREGOR@SPIFF.parc.xerox.com> Subject: Lucid 3.0.2 Optimization botch re: If you rewrite the Lucid part of FIN to do this mattress-pad stuff then I can install it in PCL and fix this longstanding problem. Just doing the tail-recursive exit will probably make the matter essentially moot for all practical purposes. The problem crops up all the time here for people using PCL in Lucid Lisp. ------- The problem with the "mattress pad" is that it has to be presented as a "binary patch" -- that is, a small segment of machine code presented as hex digits -- for each and every hardware platform. I can easily do this for the 68K and SPARC if you so wish, but note that numerous Lucid users are on other platforms. Do you wanna try to do the tail-recursive cache-miss code yourself? I can show you my version, although it may have Lucid-specific parts in it; it will take a little thought to see how to retro-fit it (but not much). The reason why not doing a tail-recursive call is such a big lose is in the relative period of time in which dcode (procedure) consistency is required: (1) non-tail: over the interval of open-coded cache lookup, *** as well as over the call to 'dcode-cache-miss' *** which can take not only an arbitrarily long period of time, but will ocasionally directly overwrite the dcode itself, due to cache growth. (2) tail: only over the interval of the open-coded cache lookup [which we all know to be very small, right, or else PCL wouldn't be viable at all]; the liklihood of a multiprocessing collision here is about the same as the liklihood of a multiprocessing collision revealing one of the few unprotected "critical sections" in the Lucid 3.0 system -- not zero, but epsilonically small. Also, there is no problem with cache growth or other updates than can occur in the "miss" case. Of course, all other implementations would benefit from the fix to dcodes to be tail recursive when "miss"'ing. I'm pretty sure that VaxLisp has compiler OPTIMIZE settings that can produce morphologically different code; and there ought to be other such compilers around. -- JonL -- P.S. I've been advised privately that the credits for the "mattress pad" idea (and name) really belong to another Franz person -- that jkf simply wrote the first version of Franz's "fin". My apologies. Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA17262; Tue, 23 May 89 08:41:56 -0700 Reply-To: Received: from Semillon.ms by ArpaGateway.ms ; 23 MAY 89 08:37:58 PDT Date: Tue, 23 May 89 08:35 PDT From: Gregor.pa@Xerox.COM Subject: Re: Unable to compile Cinco de Mayo PCL in Medley To: Burwell.pa@Xerox.COM Cc: CommonLoops.pa@Xerox.COM, Lanning.PA@Xerox.COM Fcc: BD:>Gregor>mail>outgoing-mail-6.text.newest In-Reply-To: The message of 22 May 89 18:35 PDT from Burwell.pa Message-Id: <19890523153512.1.GREGOR@SPIFF.parc.xerox.com> Line-Fold: no The bug won't be fixed in medley, it will be fixed in PCL. ------- Received: from Sail.Stanford.EDU by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA18787; Tue, 23 May 89 10:51:36 -0700 Reply-To: Message-Id: <11c9OI@SAIL.Stanford.EDU> Date: 23 May 89 1047 PDT From: Dick Gabriel Subject: re: Random metaclasses for CL types To: jonl@LUCID.COM, dussud@LUCID.COM, Gray@dsg.csc.ti.com Cc: Moon@STONY-BROOK.SCRC.SYMBOLICS.COM, common-lisp-object-system@SAIL.Stanford.EDU, chapman%aitg.dec@decwrl.dec.com [In reply to message from jonl@lucid.com sent Fri, 19 May 89 21:07:17 PDT.] I haven't been following this debate too closely, but on discussing it with Dussud and Jonl, I am not sure why the metaclass taxonomy cannot look like this: class | --------------------------------------------------- | | | | built-in-class basic-flavor-class structure-class standard-class | | | -------------------------------- | | | flavor-implemented-built-in-class ordinary-flavor-class where basic-flavor has just enough structure to support the flavor-implemented builtins, and just enough ontology to represent flavors (as usual, I don't endorse these names). PATHNAME and STREAM are instances of flavor-implemented-built-in-class and user-defined or other flavors are instances of ordinary-flavor-class. The other alternative is to flush built-in-class and let imlementations decide their own metaclass hierarchy. Maybe that way we would see some implementors doing some innovative design. -rpg- Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA20210; Tue, 23 May 89 12:54:59 -0700 Reply-To: Received: from Semillon.ms by ArpaGateway.ms ; 23 MAY 89 12:56:24 PDT Date: Tue, 23 May 89 12:54 PDT From: Gregor.pa@Xerox.COM Subject: Re: default initargs bug with 5/5/89 PCL To: Walter E. Gillett Cc: commonloops.pa@Xerox.COM Fcc: BD:>Gregor>mail>outgoing-mail-6.text.newest In-Reply-To: <8905191817.AA01016@wheat-chex.ai.mit.edu> Message-Id: <19890523195418.0.GREGOR@SPIFF.parc.xerox.com> Line-Fold: no Date: Fri, 19 May 89 14:17:51 EDT From: gillett@ai.mit.edu (Walter E. Gillett) With DEFAULT-INITARGS, I should be able to provide default values for any initialization argument, whether it initializes a slot or is passed to a method. However, the current PCL provides defaults for method initargs only when either the defclass or the defmethod is evaluated more than once: This bug is fixed in Victoria Day PCL which is about to be released. ------- Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA20210; Tue, 23 May 89 12:54:59 -0700 Reply-To: Received: from Semillon.ms by ArpaGateway.ms ; 23 MAY 89 12:56:24 PDT Date: Tue, 23 May 89 12:54 PDT From: Gregor.pa@Xerox.COM Subject: Re: default initargs bug with 5/5/89 PCL To: Walter E. Gillett Cc: commonloops.pa@Xerox.COM Fcc: BD:>Gregor>mail>outgoing-mail-6.text.newest In-Reply-To: <8905191817.AA01016@wheat-chex.ai.mit.edu> Message-Id: <19890523195418.0.GREGOR@SPIFF.parc.xerox.com> Line-Fold: no Date: Fri, 19 May 89 14:17:51 EDT From: gillett@ai.mit.edu (Walter E. Gillett) With DEFAULT-INITARGS, I should be able to provide default values for any initialization argument, whether it initializes a slot or is passed to a method. However, the current PCL provides defaults for method initargs only when either the defclass or the defmethod is evaluated more than once: This bug is fixed in Victoria Day PCL which is about to be released. ------- Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA00724; Tue, 23 May 89 14:48:49 -0700 Reply-To: Received: from Burger.ms by ArpaGateway.ms ; 23 MAY 89 13:32:27 PDT Return-Path: Redistributed: CommonLoops.PA Received: from boulder.Colorado.EDU ([128.138.238.18]) by Xerox.COM ; 23 MAY 89 13:30:46 PDT Return-Path: Received: by boulder.Colorado.EDU (cu-hub.022489) Received: by sigi.colorado.edu (cu.generic.041888) Date: Tue, 23 May 89 14:30:34 MDT From: Andreas Girgensohn Message-Id: <8905232030.AA03228@sigi.colorado.edu> To: CommonLoops.PA@Xerox.COM Subject: Bug in Cinco de Mayo PCL I compiled Cinco de Mayo PCL with *print-case* = :downcase. Somebody else tried to load it with *print-case* = :upcase and got an error. I found the function that produces the bug and fixed it. Andreas Girgensohn andreasg@boulder.colorado.edu ;;; in DEFS.LISP (defun make-type-predicate-name (class-name) (intern (format nil "~A ~A predicate" (package-name (symbol-package class-name)) (symbol-name class-name)) *the-pcl-package*)) #|| ;;; old version (defun make-type-predicate-name (class-name) (intern (format nil "~A ~A predicate" (package-name (symbol-package class-name)) class-name *the-pcl-package*))) ||# Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA04418; Tue, 23 May 89 17:26:06 -0700 Reply-To: Received: from Semillon.ms by ArpaGateway.ms ; 23 MAY 89 17:26:54 PDT Date: Tue, 23 May 89 17:24 PDT From: Gregor.pa@Xerox.COM Subject: Re: Sun Common Lisp 2.1.3 pcl problem To: Jon L White Cc: CommonLoops.pa@Xerox.COM Fcc: BD:>Gregor>mail>outgoing-mail-6.text.newest In-Reply-To: <8905130534.AA17980@bhopal> Message-Id: <19890524002449.3.GREGOR@SPIFF.parc.xerox.com> Line-Fold: no Date: Fri, 12 May 89 22:34:52 PDT From: Jon L White Rather than adding many more #+/#- conditionalizations, perhaps the best thing would be to resort to using the "lucid::" notation. This is how the files walk.lisp and fin.lisp - and to some degree defs.lisp also -- have insulated themselves against the package differences between Lucid's version 2 and version 3. Ordinarily, I would strongly recommend against use of double-colon format in files, but in this particular case, each symbol so qualified is "stable" in it's particular release version. So what should I used for *redefinition-action*? system:: or lucid-common-lisp:: ?? ------- Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA04418; Tue, 23 May 89 17:26:06 -0700 Reply-To: Received: from Semillon.ms by ArpaGateway.ms ; 23 MAY 89 17:26:54 PDT Date: Tue, 23 May 89 17:24 PDT From: Gregor.pa@Xerox.COM Subject: Re: Sun Common Lisp 2.1.3 pcl problem To: Jon L White Cc: CommonLoops.pa@Xerox.COM Fcc: BD:>Gregor>mail>outgoing-mail-6.text.newest In-Reply-To: <8905130534.AA17980@bhopal> Message-Id: <19890524002449.3.GREGOR@SPIFF.parc.xerox.com> Line-Fold: no Date: Fri, 12 May 89 22:34:52 PDT From: Jon L White Rather than adding many more #+/#- conditionalizations, perhaps the best thing would be to resort to using the "lucid::" notation. This is how the files walk.lisp and fin.lisp - and to some degree defs.lisp also -- have insulated themselves against the package differences between Lucid's version 2 and version 3. Ordinarily, I would strongly recommend against use of double-colon format in files, but in this particular case, each symbol so qualified is "stable" in it's particular release version. So what should I used for *redefinition-action*? system:: or lucid-common-lisp:: ?? ------- Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA01254; Tue, 23 May 89 19:36:41 -0700 Reply-To: Received: from Semillon.ms by ArpaGateway.ms ; 23 MAY 89 19:35:23 PDT Date: Tue, 23 May 89 19:34 PDT From: Gregor.pa@Xerox.COM Subject: Victoria Day PCL To: CommonLoops.PA@Xerox.COM Fcc: BD:>Gregor>mail>outgoing-mail-6.text.newest Message-Id: <19890524023403.7.GREGOR@SPIFF.parc.xerox.com> Line-Fold: no There is a new version of PCL on arisia.xerox.com. This version completely replaces Cinco de Mayo PCL. This version has been tested more carefully and seems to work in at least the following Lisps: Coral 1.2 Lucid 3.0 Allegro 3.0.1 Golden Common Lisp 3.1 I believe it will work in these Lisps as well, it is being tested in them now. Symbolics 7.2, 7.4 EnvOS Medley IBCL (October 15, 1987) Let me take this opportunity to apologize for the tragedy that was Cinco de Mayo PCL. We will try to do better in the future. -Gregor ------- Received: from Sail.Stanford.EDU by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA00249; Wed, 24 May 89 08:50:10 -0700 Reply-To: Received: from lucid.com by SAIL.Stanford.EDU with TCP; 24 May 89 08:06:45 PDT Received: from bhopal ([192.43.178.13]) by heavens-gate id AA06671g; Wed, 24 May 89 08:03:38 PDT Received: by bhopal id AA13037g; Wed, 24 May 89 08:03:20 PDT Date: Wed, 24 May 89 08:03:20 PDT From: Jon L White Message-Id: <8905241503.AA13037@bhopal> To: RPG@SAIL.Stanford.EDU Cc: dussud@lucid.com, Gray@dsg.csc.ti.com, Moon@STONY-BROOK.SCRC.SYMBOLICS.COM, common-lisp-object-system@SAIL.Stanford.EDU, chapman%aitg.dec@decwrl.dec.com In-Reply-To: Dick Gabriel's message of 23 May 89 1047 PDT <11c9OI@SAIL.Stanford.EDU> Subject: Random metaclasses for CL types re: The other alternative is to flush built-in-class and let imlementations decide their own metaclass hierarchy. Maybe that way we would see some implementors doing some innovative design. Before doing that, we should reflect on why BUILT-IN-CLASS is in the standard, and why 88-002R specifies that the "holy" Common Lisp types should be of metaclass either BUILT-IN-CLASS, STRUCTURE-CLASS, or STANDARD-CLASS. After all, our present problem is determining how to say the intent that Moon wants to add to 88-002R, page 1-15, about "restrictions" on implementation-dependent metaclasses. After talking it over with you (RPG), I think we have been overly concerned with the aphorism "The Metaclass implements the structure of the instances". In fact, this just isn't true of all Metaclasses; the fact that it is a concise description of the structure of STANDARD-CLASS has fooled us into thinking it to be more widely true. I see BUILT-IN-CLASS as a series of "fronts" for objects that exist in a Common Lisp implementation's extended type hiearchy. The structure of these "instances" __is not__ implemented by any facility whatsoever in the Common Lisp Object System, but by all of "the ususal suspects", such as microcode, machine-language assembly code, Lisp functions, compiler tricks, etc. The sole raison d'etre of BUILT-IN-CLASS is so that generic functions may discriminate on these "holy" types (but probably not on lots of other types about which no one cares). Viewed in this light, there is no reason at all why the flavor-implemented types shouldn't simply be represented by a place-holder class that is either an instance of BUILT-IN-CLASS, or some implementation-dependent subclass thereof. The question should arise: Why not require all "holy" types to be of metaclass BUILT-IN-CLASS (or implementation-dependent subclass thereof)? The answer comes from the fact that CLOS _does not_ provide for true information/structure hiding such as, say, Common Objects has. Thus if some implementation should support a "holy" type by using a STANDARD-CLASS, this would be visible to the end user. Furthermore, any attempt to apply some restrictions to such a metaclass (such as by providing overrides for SLOT-VALUE-ABUSING-CLASS to make it look to the user like these classes don't have slots) would also apply to the implementor, thereby totally nullifying the advantage or using a STANDARD-CLASS in the first place. Thus, because of the openess of CLOS, STRUCTURE-CLASS and STANDARD-CLASS must be allowed explicitly; but _any_ other implementational technique needs only BUILT-IN-CLASS as a "front", regardless of whether it is by microcode, by flavors classes, or by YetAnotherObjectSystem. -- JonL -- Received: from Sail.Stanford.EDU by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA00257; Wed, 24 May 89 08:50:19 -0700 Reply-To: Received: from lucid.com by SAIL.Stanford.EDU with TCP; 24 May 89 08:05:08 PDT Received: from challenger ([192.9.200.17]) by heavens-gate id AA06665g; Wed, 24 May 89 08:02:07 PDT Received: by challenger id AA02782g; Wed, 24 May 89 08:01:27 PDT Date: Wed, 24 May 89 08:01:27 PDT From: Patrick Dussud Message-Id: <8905241501.AA02782@challenger> To: RPG@SAIL.Stanford.EDU Cc: jonl@lucid.com, Gray@dsg.csc.ti.com, Moon@STONY-BROOK.SCRC.SYMBOLICS.COM, common-lisp-object-system@SAIL.Stanford.EDU, chapman%aitg.dec@decwrl.dec.com In-Reply-To: Dick Gabriel's message of 23 May 89 1047 PDT <11c9OI@SAIL.Stanford.EDU> Subject: Random metaclasses for CL types Date: 23 May 89 1047 PDT From: Dick Gabriel [In reply to message from jonl@lucid.com sent Fri, 19 May 89 21:07:17 PDT.] I haven't been following this debate too closely, but on discussing it with Dussud and Jonl, I am not sure why the metaclass taxonomy cannot look like this: class | --------------------------------------------------- | | | | built-in-class basic-flavor-class structure-class standard-class | | | -------------------------------- | | | flavor-implemented-built-in-class ordinary-flavor-class where basic-flavor has just enough structure to support the flavor-implemented builtins, and just enough ontology to represent flavors (as usual, I don't endorse these names). PATHNAME and STREAM are instances of flavor-implemented-built-in-class and user-defined or other flavors are instances of ordinary-flavor-class. I think this would work. There are some issues that need to be ironed out: Can the implementation allow subclasses of flavor-implemented-built-in-class? If yes, then does flavor-implemented-built-in-class needs to expose its slots? or merely allow subclasses to have slots and treat the superclasses like blackboxes? The other alternative is to flush built-in-class and let imlementations decide their own metaclass hierarchy. Maybe that way we would see some implementors doing some innovative design. I prefer this one, just because it leaves more options open to the implementation. Patrick. Received: from Sail.Stanford.EDU by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA00317; Wed, 24 May 89 08:55:44 -0700 Reply-To: Message-Id: <11cWdx@SAIL.Stanford.EDU> Date: 24 May 89 0854 PDT From: Dick Gabriel Subject: re: Random metaclasses for CL types To: jonl@LUCID.COM, RPG@SAIL.Stanford.EDU Cc: dussud@LUCID.COM, Gray@dsg.csc.ti.com, Moon@STONY-BROOK.SCRC.SYMBOLICS.COM, common-lisp-object-system@SAIL.Stanford.EDU, chapman%aitg.dec@decwrl.dec.com [In reply to message from jonl@lucid.com sent Wed, 24 May 89 08:03:20 PDT.] I think the aphorism is ``the metaclass determines the representation of instances of its instances.'' This is because MAKE-INSTANCE as a function depends on the metaclass. So, any operation whose operation takes a class depends on the metaclass. Representation creation is the most important or visible of those operations. (Another use is to reify other aspects of an object, such as the interpreter to use to execute code associated with a class. This is sort of what Maes (1988) and Gabriel (1980) do with metaobjects.) Of course, there is nothing to prevent one from having MAKE-INSTANCE select a metaclass to use that corresponds to a subclass of the original class. MAKE-ARRAY is such a pseudo-constructor. BUILT-IN-CLASS seems to me to be a metaclass for things that you cannot MAKE-INSTANCE of. In that sense it might represent the metaclass for things with no metaclass at all. I think this is consistent with what you're saying. One reason to flush BUILT-IN-CLASS is to allow implementations to experiment with real metaclasses for Common Lisp types. Possibly such a system would be only of educational interest. -rpg- Received: from Sail.Stanford.EDU by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA06934; Wed, 24 May 89 11:17:27 -0700 Reply-To: Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 24 May 89 11:14:39 PDT Received: from KENNETH-WILLIAMS.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 600026; 24 May 89 13:43:12 EDT Date: Wed, 24 May 89 13:46 EDT From: David A. Moon Subject: re: Random metaclasses for CL types To: Dick Gabriel , Patrick Dussud , Jon L White Cc: Gray@dsg.csc.ti.com, common-lisp-object-system@SAIL.Stanford.EDU, chapman%aitg.dec@decwrl.dec.com In-Reply-To: <11c9OI@SAIL.Stanford.EDU>, <8905241501.AA02782@challenger>, <8905241503.AA13037@bhopal>, <11cWdx@SAIL.Stanford.EDU> Message-Id: <19890524174658.5.MOON@KENNETH-WILLIAMS.SCRC.Symbolics.COM> I wish we could bring this conversation back down to earth. All I want to know is what one-line change to make to the draft ANSI Common Lisp spec where it says what a conforming program can assume about the behavior of objects of the built-in types. Received: from Sail.Stanford.EDU by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA07424; Wed, 24 May 89 11:47:37 -0700 Reply-To: Message-Id: <1ycZDQ@SAIL.Stanford.EDU> Date: 24 May 89 1144 PDT From: Dick Gabriel Subject: re: Random metaclasses for CL types To: Moon@STONY-BROOK.SCRC.SYMBOLICS.COM, RPG@SAIL.Stanford.EDU, dussud@LUCID.COM, jonl@LUCID.COM Cc: Gray@dsg.csc.ti.com, common-lisp-object-system@SAIL.Stanford.EDU, chapman%aitg.dec@decwrl.dec.com [In reply to message from Moon@STONY-BROOK.SCRC.Symbolics.COM sent Wed, 24 May 89 13:46 EDT.] Gabriel to Earth. Now hear this. My suggestion is to delete the following paragraph from the specification: ``Each class that corresponds to a predefined Common Lisp type specifier can be implemented in one of three ways, at the discretion of each implementation. It can be a {\bit standard class\/} (of the kind defined by {\bf defclass}), a {\bit structure class\/} (defined by {\bf defstruct}), or a {\bit built-in class\/} (implemented in a special, non-extensible way).'' And change this one: ``It is possible to determine whether a class is a built-in class by checking the metaclass. A standard class is an instance of {\bf standard-class}, a built-in class is an instance of {\bf built-in-class}, and a structure class is an instance of {\bf structure-class}.'' to this: ``A standard class is an instance of {\bf standard-class} and a structure class is an instance of {\bf structure-class}.'' -rpg- Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA07679; Wed, 24 May 89 11:58:20 -0700 Reply-To: Received: from Chardonnay.ms by ArpaGateway.ms ; 24 MAY 89 09:21:27 PDT Return-Path: Redistributed: CommonLoops.pa Received: from lucid.com ([192.26.25.1]) by Xerox.COM ; 24 MAY 89 09:14:53 PDT Received: from bhopal ([192.43.178.13]) by heavens-gate id AA06837g; Wed, 24 May 89 08:39:53 PDT Site: Received: by bhopal id AA13132g; Wed, 24 May 89 08:39:34 PDT Date: Wed, 24 May 89 08:39:34 PDT From: Jon L White Message-Id: <8905241539.AA13132@bhopal> To: Gregor.pa@Xerox.COM Cc: CommonLoops.pa@Xerox.COM In-Reply-To: Gregor.pa@Xerox.COM's message of Tue, 23 May 89 17:24 PDT <19890524002449.3.GREGOR@SPIFF.parc.xerox.com> Subject: Sun Common Lisp 2.1.3 pcl problem re: So what should I used for *redefinition-action*? system:: or lucid-common-lisp:: ?? Neither. This is precisely one of those places that I (reluctantly) advise the use of lucid::. One alternative is to write: #+LCL3.0 lcl:*redefinition-action* #-LCL3.0 sys:*redefinition-action* but it's messier and longer. Another alternative is to import the symbol into the PCL package by, say, the "defsys" file so that it doesn't have to be written out in colon-qualified form (but I understand the difficulties that brings in too). The problem is that *REDEFINITION-ACTION* was ill-advisedly put into the SYSTEM package in the 1.0 and 2.0 releases; and not until the 3.0 release did we have a "home" for Lucid extensions (namely the LUCID-COMMON-LISP package). So source code that must be portable to both the Lucid pre-3.0 and post-3.0 versions needs to take one of the above protective actions on references to symbols that migrated from SYSTEM to LUCID-COMMON-LISP. In fact, the differences between releases might imply that you should have separate "lucid-low" files -- one for pre-3.0 and one for post-3.0. But unfortunately, not all the Lucid-spcific references are in that file; I've noticed quite a bit of #+/#-'ing in several PCL files. -- JonL -- Received: from Sail.Stanford.EDU by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA13660; Wed, 24 May 89 17:30:21 -0700 Reply-To: Received: from ti.com by SAIL.Stanford.EDU with TCP; 24 May 89 17:18:25 PDT Received: by ti.com id AA12879; Wed, 24 May 89 19:18:41 CDT Received: from dsg by tilde id AA00396; Wed, 24 May 89 19:07:09 CDT Received: From Kelvin By dsg Via TCP With SMTP; Wed, 24 May 89 16:22:56 CDT Message-Id: <2821036952-6570488@Kelvin> Sender: GRAY@kelvin.csc.ti.com Date: Wed, 24 May 89 16:22:32 CDT From: David N Gray To: Dick Gabriel Cc: Moon@STONY-BROOK.SCRC.SYMBOLICS.COM, dussud@LUCID.COM, jonl@LUCID.COM, common-lisp-object-system@SAIL.Stanford.EDU Subject: re: Random metaclasses for CL types In-Reply-To: Msg of 24 May 89 1144 PDT from Dick Gabriel > Gabriel to Earth. Now hear this. My suggestion is to delete the > following paragraph from the specification: ... In other, words, delete the use of BUILT-IN-CLASS? I don't think that's a good idea, because BUILT-IN-CLASS does serve a useful purpose: it serves notice that there may exist some classes for which MAKE-INSTANCE and SLOT-VALUE are not legal, and it provides a way to test whether a given class has those restrictions. Thus, while the result of, for example, (CLASS-OF (FIND-CLASS 'READTABLE)) should be permitted to be implementation-dependent, it should be meaningful for portable code to test for (TYPEP (FIND-CLASS 'READTABLE) 'BUILT-IN-CLASS) in order to find out if READTABLEs can have slots in the current implementation. Received: from Sail.Stanford.EDU by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA13665; Wed, 24 May 89 17:30:31 -0700 Reply-To: Received: from ti.com by SAIL.Stanford.EDU with TCP; 24 May 89 17:19:22 PDT Received: by ti.com id AA12901; Wed, 24 May 89 19:19:06 CDT Received: from dsg by tilde id AA00499; Wed, 24 May 89 19:08:56 CDT Received: From Kelvin By dsg Via CHAOS-NET With CHAOS-MAIL; Wed, 24 May 89 18:34:00 CDT Message-Id: <2821044883-7046991@Kelvin> Sender: GRAY@kelvin.csc.ti.com Date: Wed, 24 May 89 18:34:43 CDT From: David N Gray To: Jon L White Cc: RPG@SAIL.Stanford.EDU, dussud@lucid.com, Moon@STONY-BROOK.SCRC.SYMBOLICS.COM, common-lisp-object-system@SAIL.Stanford.EDU Subject: Re: Random metaclasses for CL types In-Reply-To: Msg of Wed, 24 May 89 08:03:20 PDT from Jon L White > I see BUILT-IN-CLASS as a series of "fronts" for objects that exist > in a Common Lisp implementation's extended type hiearchy. ... > Viewed in this light, there is no reason at all why the flavor-implemented > types shouldn't simply be represented by a place-holder class that is either > an instance of BUILT-IN-CLASS, or some implementation-dependent subclass > thereof. > > The question should arise: Why not require all "holy" types to be of > metaclass BUILT-IN-CLASS (or implementation-dependent subclass thereof)? > The answer comes from the fact that CLOS _does not_ provide for true > information/structure hiding such as, say, Common Objects has. Thus if > some implementation should support a "holy" type by using a STANDARD-CLASS, > this would be visible to the end user. Furthermore, any attempt to apply > some restrictions to such a metaclass (such as by providing overrides for > SLOT-VALUE-ABUSING-CLASS to make it look to the user like these classes > don't have slots) would also apply to the implementor, thereby totally > nullifying the advantage or using a STANDARD-CLASS in the first place. > > Thus, because of the openess of CLOS, STRUCTURE-CLASS and STANDARD-CLASS > must be allowed explicitly; but _any_ other implementational technique > needs only BUILT-IN-CLASS as a "front", regardless of whether it is by > microcode, by flavors classes, or by YetAnotherObjectSystem. I don't see why flavor classes are any different from standard classes in this regard. Our implementation provides for writing CLOS methods that specialize on flavors and use SLOT-VALUE to access their instance variables. True, flavors does have another way of writing methods that can be used instead, but that wouldn't necessarily be true of all implementation-defined metaclasses. If you want to expose the slots as an implementation extension, fine, I think that should be permitted. If you want to hide them, I think that can still be done with a standard class. (Remember, we're talking about an implementation here, not portable CLOS code.) For example: (defclass hidden-class (standard-class) ((visible-class :accessor visible-class))) (defmethod validate-superclass ((class hidden-class) (super standard-class)) t) (defclass internal-pathname (standard-object) ( ... ) (:metaclass hidden-class)) ; [implementation magic equivalent to:] (defclass pathname (internal-pathname) () (:metaclass built-in-class)) (setf (visible-class (find-class 'internal-pathname)) (find-class 'pathname)) (defmethod initialize-instance :after ((instance hidden-class) &rest ignore) ; [implementation magic equivalent to:] (setf (class-of instance) (visible-class (class-of instance)))) Then the class PATHNAME appears opaque to users, but the system can use methods on INTERNAL-PATHNAME. SLOT-VALUE would work in those methods because they expect an INTERNAL-PATHNAME, which is a STANDARD-CLASS. There would be an inconsistency in that a non-optimized call to SLOT-VALUE would not work, but the system programmers who would be affected by that should be able to understand that and work around it. I don't think that this technique is much different from what would be needed to create a built-in "front class" for an internal flavor class. Received: from Sail.Stanford.EDU by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA13670; Wed, 24 May 89 17:30:36 -0700 Reply-To: Received: from ti.com by SAIL.Stanford.EDU with TCP; 24 May 89 17:18:44 PDT Received: by ti.com id AA12886; Wed, 24 May 89 19:18:47 CDT Received: from dsg by tilde id AA00406; Wed, 24 May 89 19:07:26 CDT Received: From Kelvin By dsg Via CHAOS-NET With CHAOS-MAIL; Wed, 24 May 89 16:39:54 CDT Message-Id: <2821038061-6637127@Kelvin> Sender: GRAY@kelvin.csc.ti.com Date: Wed, 24 May 89 16:41:01 CDT From: David N Gray To: "David A. Moon" Cc: Dick Gabriel , Patrick Dussud , Jon L White , common-lisp-object-system@SAIL.Stanford.EDU Subject: re: Random metaclasses for CL types In-Reply-To: Msg of Wed, 24 May 89 13:46 EDT from David A. Moon > I wish we could bring this conversation back down to earth. All I want > to know is what one-line change to make to the draft ANSI Common Lisp > spec where it says what a conforming program can assume about the > behavior of objects of the built-in types. I thought your proposed wording of May 10 was sufficient: Each class that corresponds to a predefined Common Lisp type specifier can be implemented in one of four ways, at the discretion of each implementation. It can be a {\bit standard class\/} (of the kind defined by {\bf defclass}), a {\bit structure class\/} (defined by {\bf defstruct}), a {\bit built-in class\/} (implemented in a special, non-extensible way), or any other implementation-defined class that is no more restrictive than a {\bit built-in class\/}. I think that the question about what "no more restrictive" means is not a problem when this paragraph is viewed together with the paragraph that follows it in the draft. I'm a little concerned, though, about the following paragraph: It is possible to determine whether a class is a built-in class by checking the metaclass. A standard class is an instance of {\bf standard-class}, a built-in class is an instance of {\bf built-in-class}, and a structure class is an instance of {\bf structure-class}. I wouldn't want this to be interpreted in a way that would rule out subclasses of BUILT-IN-CLASS. Suppose it said: It is possible to determine whether a class is a built-in class by checking the metaclass. A standard class is one for which (TYPEP class 'STANDARD-CLASS) is true, a built-in class is one for which (TYPEP class 'BUILT-IN-CLASS) is true, and a structure class is one for which (TYPEP class 'STRUCTURE-CLASS) is true. Also, I just remembered that I don't think that the class CLASS is mentioned prior to chapter 3. It would be helpful for the standard to specify that BUILT-IN-CLASS, STANDARD-CLASS, STRUCTURE-CLASS, and any other implementation-defined metaclasses are all subclasses of CLASS. Probably this belongs on page 1-33. n't GENERIC-FUNCTION already understood to be a class that is not directly instantiated? Received: from Sail.Stanford.EDU by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA14039; Wed, 24 May 89 18:29:22 -0700 Reply-To: Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 24 May 89 18:29:51 PDT Received: from Semillon.ms by ArpaGateway.ms ; 24 MAY 89 18:28:00 PDT Date: Wed, 24 May 89 18:27 PDT From: Gregor.pa@Xerox.COM Subject: Re: Random metaclasses for CL types To: Jon L White Cc: RPG@SAIL.Stanford.EDU, dussud@lucid.com, Gray@dsg.csc.ti.com, Moon@STONY-BROOK.SCRC.SYMBOLICS.COM, common-lisp-object-system@SAIL.Stanford.EDU, chapman%aitg.dec@decwrl.dec.com Fcc: BD:>Gregor>mail>outgoing-mail-6.text.newest In-Reply-To: <8905241503.AA13037@bhopal> Message-Id: <19890525012747.4.GREGOR@SPIFF.parc.xerox.com> Line-Fold: no I am working on it now, and hope to send out a message about this all tomorrow. I think the power is off in this building Friday. ------- Received: from Sail.Stanford.EDU by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA14419; Wed, 24 May 89 19:03:45 -0700 Reply-To: Message-Id: <9c$zP@SAIL.Stanford.EDU> Date: 24 May 89 1901 PDT From: Dick Gabriel Subject: re: Random metaclasses for CL types To: Gray@dsg.csc.ti.com, RPG@SAIL.Stanford.EDU Cc: Moon@STONY-BROOK.SCRC.SYMBOLICS.COM, dussud@LUCID.COM, jonl@LUCID.COM, common-lisp-object-system@SAIL.Stanford.EDU [In reply to message from Gray@DSG.csc.ti.com sent Wed, 24 May 89 16:22:32 CDT.] I actually made a mistake. I meant to also delete the requirement of the existence of BUILT-IN-CLASS as well, but not the concept of built-in class. However, I'm not certain that this is the right way to address what I think is the real concern, which is that it's possibly the restrictions on built-in classes that we might wish to loosen. In the following paragraph we state that errors are signaled: ``A built-in class is one whose instances have restricted capabilities or special representations. Attempting to use {\bf defclass} to define subclasses of a built-in class signals an error. Calling {\bf make-instance} to create an instance of a built-in class signals an error. Calling {\bf slot-value} on an instance of a built-in class signals an error. Redefining a built-in class or using {\bf change-class} to change the class of an instance to or from a built-in class signals an error. However, built-in classes can be used as parameter specializers in methods.'' I think the real concern is that some implementations might wish to allow even the holy types to respond to these protocols. I think we don't want to prevent it. Maybe this is a point at which we wish to consider such things as ``implementations are free to extend the \OS\ to allow {\bf defclass} to define subclasses of a built-in class,'' and the same for the other protocols. In trying to translate Moon's proposal into something I can more easily understand, I came up with this; is it a fair copy? Each class that corresponds to a predefined Common Lisp type specifier can be implemented in one of four ways, at the discretion of each implementation. It can be a {\bit standard class\/} (of the kind defined by {\bf defclass}), a {\bit structure class\/} (defined by {\bf defstruct}), a {\bit built-in class\/} (implemented in a special, non-extensible way), or any other implementation-defined class that allows it to be used as a parameter specializer in a method. In Gray's example of the use of BUILT-IN-CLASS, I can't imagine that someone writing a portable program couldn't devise a more portable solution to the problem, especially if there is alternative that is used if the (TYPEP (FIND-CLASS 'READTABLE) 'BUILT-IN-CLASS) returns T. Are you thinking of a portable programming environment? -rpg- Received: from Sail.Stanford.EDU by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA15805; Wed, 24 May 89 21:30:32 -0700 Reply-To: Received: from Sun.COM by SAIL.Stanford.EDU with TCP; 24 May 89 21:31:24 PDT Received: from snail.Sun.COM (snail.Corp.Sun.COM) by Sun.COM (4.1/SMI-4.1) id AA09723; Wed, 24 May 89 21:31:30 PDT Received: from suntana.sun.com by snail.Sun.COM (4.1/SMI-4.1) id AA06439; Wed, 24 May 89 21:30:05 PDT Received: from localhost by suntana.sun.com (4.0/SMI-4.0) id AA05656; Wed, 24 May 89 21:31:35 PDT Message-Id: <8905250431.AA05656@suntana.sun.com> To: David N Gray Cc: Dick Gabriel , Moon@STONY-BROOK.SCRC.SYMBOLICS.COM, dussud@LUCID.COM, jonl@LUCID.COM, common-lisp-object-system@SAIL.Stanford.EDU Subject: Re: Random metaclasses for CL types In-Reply-To: Your message of Wed, 24 May 89 16:22:32 -0500. <2821036952-6570488@Kelvin> Date: Wed, 24 May 89 21:31:32 PDT From: kempf@Sun.COM >> Gabriel to Earth. Now hear this. My suggestion is to delete the >> following paragraph from the specification: >... > >In other, words, delete the use of BUILT-IN-CLASS? I don't think that's a >good idea, because BUILT-IN-CLASS does serve a useful purpose: it serves I agree. jak Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA16402; Wed, 24 May 89 22:39:03 -0700 Reply-To: Received: from Burger.ms by ArpaGateway.ms ; 24 MAY 89 22:40:24 PDT Return-Path: Redistributed: CommonLoops.pa Received: from etana.funet.fi ([128.214.1.1]) by Xerox.COM ; 24 MAY 89 22:39:41 PDT Received: by etana.funet.fi; id AA03731; Thu, 25 May 89 08:39:49 +0200 Received: by stek2.oulu.fi (3.2/SMI-3.2) id AA00576; Thu, 25 May 89 08:39:37 +0200 Date: Thu, 25 May 89 08:39:37 +0200 From: jpr@stek2.oulu.fi (Jukka Riekki) Message-Id: <8905250639.AA00576@stek2.oulu.fi> To: CommonLoops.pa@Xerox.COM Hello, I just copied the "5/5/89 Cinco de Mayo PCL" version of the PCL by FTP. Do you know which versions the CLX and the CLUE work with this version of PCL ? We have here AKCL v 1.89, SunOS 4.0 and Sun 3. Sincerely Jukka Riekki, Computer laboratory, Dept. of Electrical Eng, University of Oulu, 90570 Oulu Finland E-mail: jpr@steks.oulu.fi Received: from Sail.Stanford.EDU by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA25722; Thu, 25 May 89 09:07:05 -0700 Reply-To: Received: from lucid.com by SAIL.Stanford.EDU with TCP; 25 May 89 09:07:42 PDT Received: from bhopal ([192.43.178.13]) by heavens-gate id AA05703g; Thu, 25 May 89 09:06:31 PDT Received: by bhopal id AA15693g; Thu, 25 May 89 09:04:42 PDT Date: Thu, 25 May 89 09:04:42 PDT From: Jon L White Message-Id: <8905251604.AA15693@bhopal> To: Moon@STONY-BROOK.SCRC.Symbolics.COM Cc: RPG@SAIL.Stanford.EDU, dussud@lucid.com, Gray@dsg.csc.ti.com, common-lisp-object-system@SAIL.Stanford.EDU, chapman%aitg.dec@decwrl.dec.com In-Reply-To: David A. Moon's message of Wed, 24 May 89 13:46 EDT <19890524174658.5.MOON@KENNETH-WILLIAMS.SCRC.Symbolics.COM> Subject: Random metaclasses for CL types re: . . . what one-line change to make to the draft ANSI Common Lisp spec where it says what a conforming program can assume about the behavior of objects of the built-in types. I fear it won't be one-line change. Would you be happy if we could all agree to a two-dozen line change? If so, then I think I could go for Gabriel's plan to flush BUILT-IN-CLASS as a required class, providing that we add an implementation-revealing defconstant -- say, BUILT-IN-CLASSES -- which is just a list of all the classes supporting "built in" types. The "holy" types of pages 1-16 and 1-17 would be required to have representatives on this list, and an implementation would be free to add as many others as necessary to provide reasonable support so that CLASS-OF is a total function. As I've previously argued, the only utility of BUILT-IN-CLASS is taxonomic; and this capability can just as easily and naturally be provided by a list of all such classes. [By the bye, "holy" because they are set apart for a transcendent purpose.] A list is better than a predicate BUILT-IN-CLASS-P since one might never know to look for the very implementation-specific classes. Secondly, I still tend to think that the notion of "restriction" isn't clear enough. One man thinks it means no use of SLOT-VALUE; another sees it as no MAKE-INSTANCE; yet a third is concerned that it might even mean "can't appear in the cdr of a list". By letting all the "holy" types have metaclasses of unspecified nature (but of course every metaclass itself is a very standard object), implementations are free to let "built-in" classes respond to any protocol whatsoever. However, the standard will not specify any CLOS operations on the "holy" types, so that portable code can depend only on existence of such classes (for use as specializer names). Thus I would also agree with Gabriel that we could get along nicely without specifying any restrictions on built-in classes. I'm not happy with the idea of end-users defining subclasses of INTEGER and VECTOR, but . . . well, this really is an implementational matter; after all, I probably wouldn't have thought of wanting to have my own subclasses of PATHNAME either. -- JonL -- Received: from Sail.Stanford.EDU by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA26248; Thu, 25 May 89 09:40:58 -0700 Reply-To: Received: from lucid.com by SAIL.Stanford.EDU with TCP; 25 May 89 09:41:00 PDT Received: from bhopal ([192.43.178.13]) by heavens-gate id AA05828g; Thu, 25 May 89 09:38:22 PDT Received: by bhopal id AA15726g; Thu, 25 May 89 09:36:33 PDT Date: Thu, 25 May 89 09:36:33 PDT From: Jon L White Message-Id: <8905251636.AA15726@bhopal> To: Gray@dsg.csc.ti.com Cc: dussud@lucid.com, Moon@STONY-BROOK.SCRC.Symbolics.COM, common-lisp-object-system@SAIL.STANFORD.EDU In-Reply-To: David N Gray's message of Wed, 24 May 89 17:35:33 CDT <2821041333-6833702@Kelvin> Subject: Random metaclasses for CL types re: Date: Wed, 24 May 89 17:35:33 CDT From: David N Gray . . . [... jonl's inheritance diagram for FUNCTION, STANDARD-FUNCTION, etc] . . . OK; the real issue is that if users are to be permitted to define subclasses of GENERIC-FUNCTION or STANDARD-FUNCTION, then they just need to know what to use for the :METACLASS option for their class in order for the inheritance to be permitted. Right. And I don't see any particular reason to require it to be STANDARD-CLASS. But even if it were to be STANDARD-CLASS, that's not nearly so important as the recognition that subclass relations in the base classes -- such as FUNCTION, STANDARD-FUNCTION, and STANDARD-GENERIC-FUNCTION -- don't imply any particular subclass relations in their metaclasses. I think you seem to be agreeing with me on that. re: Date: Wed, 24 May 89 18:34:43 CDT From: David N Gray . . . [suggestion that specification for the "holy" types must explicitly allow for STANDARD-CLASS and STRUCTURE-CLASS because of the openness of CLOS] . . . I don't see why flavor classes are any different from standard classes in this regard. Our implementation provides for writing CLOS methods that specialize on flavors and use SLOT-VALUE to access their instance variables. True, flavors does have another way of writing methods that can be used instead, but that wouldn't necessarily be true of all implementation-defined metaclasses. With respect to STANDARD-CLASS, that's precisely the point -- that there are _no_ ways other than SLOT-VALUE, etc. [I presume you meant "all implementation-defined metaclasses" for built-in classes?] But you're clever trick for pathnames -- letting it be implemented by a kind of standard class ("hidden-class") but represented by a kind of built-in class (the "visible-class") -- shows that we could even forgo the special dispensation for STANDARD-CLASS and STRUCTURE-CLASS. However, if the Gabriel plan of flushing BUILT-IN-CLASS succeeds, it will all be moot. -- JonL -- Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA00364; Thu, 25 May 89 14:23:21 -0700 Received: from Cabernet.ms by ArpaGateway.ms ; 25 MAY 89 11:00:33 PDT Return-Path: Redistributed: commonloops.PA Received: from crdgw1.ge.com ([192.35.44.4]) by Xerox.COM ; 25 MAY 89 10:57:23 PDT Received: by crdgw1.ge.com (5.57/Ultrix 3.0 (1.45)) id AA05571; Thu, 25 May 89 13:57:36 EDT Received: from eraserhead.crd.Ge.Com by unclejack.crd.Ge.Com (4.1/SMI-4.0/GE-CRD @(#)sun4.ease 1.13 4/13/89) id AA06245; Thu, 25 May 89 13:57:34 EDT Date: Thu, 25 May 89 13:57:34 EDT From: duff@unclejack.crd.ge.com (David A Duff) Message-Id: <8905251757.AA06245@unclejack.crd.Ge.Com> Received: by eraserhead.crd.Ge.Com (4.0/SMI-4.0/GE-CRD @(#)sun4.ease 1.13 4/13/89) id AA07034; Thu, 25 May 89 13:53:34 EDT To: commonloops.PA@Xerox.COM Subject: minor point about extract-declarations Reply-To: duff@eraserhead.crd.ge.com hello. the macro EXTRACT-DECLARATIONS, defined in macros.lisp performs a function that is very useful to me. looking at it more closely, however, revealed either a discrepancy in the code or in my understanding of Steele's description of common lisp. the macro only returns at most one docstring and it assumes that the docstring, if present will always be the first thing in the body. Steele seems to indicate that multiple docstrings are allowable and that they can be interspersed with the declarations. has there been some sort of cleanup or clarification of Steele on this issue? i personally, can't see much point in allowing docstrings to be interspersed with declarations, and i don't know what the correct way would be to handle more than one (i don't think Steele says anything about this). Dave Duff GE Corporate Research and Development duff@eraserhead.crd.ge.com Schenectady, NY 12309 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA00784; Thu, 25 May 89 14:48:36 -0700 Reply-To: Received: from Salvador.ms by ArpaGateway.ms ; 25 MAY 89 08:54:34 PDT Return-Path: <@CORNELLC.cit.cornell.edu:JACKSON@NRCCIT.NRC.CA> Redistributed: CommonLoops.pa Received: from CORNELLC.cit.cornell.edu ([128.253.1.19]) by Xerox.COM ; 25 MAY 89 08:51:05 PDT Received: from VM.NRC.CA by CORNELLC.cit.cornell.edu (IBM VM SMTP R1.2.1MX) with BSMTP id 9136; Thu, 25 May 89 11:31:43 EDT Received: from NRCNET.NRC.CA by VM.NRC.CA (Mailer R2.03B) with BSMTP id 5299; Thu, 25 May 89 10:19:29 EDT Date: Thu, 25 May 89 10:19 EST From: JACKSON%NRCCIT.NRC.CA@CORNELLC.cit.cornell.edu Subject: PCL/Symbolics Problem To: CommonLoops.pa@Xerox.COM X-Vms-To: BITNET::"CommonLoops.pa@Xerox.com" Message-Id: <890525-085434-1247@Xerox> Dear PCL Gods/Goddesses: Good day, this is Dick Jackson from the National Research Council of Canada in Winnipeg, Manitoba, with a few points to raise regarding a release of PCL (8-28-88). I've been most happy with how this release worked with Allegro CL on the Macintosh, and more recently, I've tried to get it moving on VAX Lisp and on our Symbolics. I won't press the issue regarding the VAX, as your 'notes.txt' gave no promise that it would work there. However, I might ask your indulgence concerning the Symbolics version. Again, the notes said it worked fine on Symbolics 7.2, and we're running 7.1, so if you wish to wash your hands of my problem right now, I'll understand. The story so far... - succeeded in loading "defsys.lisp" - called (pcl::compile-pcl) - several files successfully compiled, with minor warnings - message generated by PCL: "Iterate operator in clause NIL is not fboundp" - Lisp error message: "Trap: the first argument given to ZL:AR-1 instruction, #, was not an array. While compiling MAKE-PARAMETER-REFERENCES" - a backtrace provided the following: EVERY LOOP SI:MACROEXPAND-1-INTERNAL MACROEXPAND-1 WALKER::WALK-FROM-INTERNAL ... (PCL::COMPILE-PCL) I can only wish that someone has run into this before, and I'd much appreciate any help you can offer me. I've looked through several parts of the code, without being able to trace it much more than: the root of the problem is the Iterate macro-call, which is inside the Gathering call in the MAKE-PARAMETER-REFERENCES defun in file BOOT.lisp Thanks very much for your time, and I hope to hear from you soon. Please reach me on BITNET at jackson@nrccit.nrc.ca Sincerely, -Dick P.S.: If you don't mind a personal question, what is Xerox's motivation to produce (and maintain) PCL? I can only be amazed at the amount of work that goes into it, and wonder what return Xerox gets on this investment. Keep it up, it's an excellent system! Received: from Sail.Stanford.EDU by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA00851; Thu, 25 May 89 14:56:29 -0700 Reply-To: Received: from ti.com by SAIL.Stanford.EDU with TCP; 25 May 89 14:56:54 PDT Received: by ti.com id AA20862; Thu, 25 May 89 16:57:06 CDT Received: from dsg by tilde id AA04103; Thu, 25 May 89 16:38:21 CDT Received: From Kelvin By dsg Via CHAOS-NET With CHAOS-MAIL; Thu, 25 May 89 11:48:46 CDT Message-Id: <2821106973-10777481@Kelvin> Sender: GRAY@kelvin.csc.ti.com Date: Thu, 25 May 89 11:49:33 CDT From: David N Gray To: Dick Gabriel Cc: Moon@STONY-BROOK.SCRC.SYMBOLICS.COM, dussud@LUCID.COM, jonl@LUCID.COM, common-lisp-object-system@SAIL.Stanford.EDU Subject: re: Random metaclasses for CL types In-Reply-To: Msg of 24 May 89 1901 PDT from Dick Gabriel > I think the real concern is that some implementations might wish to allow > even the holy types to respond to these protocols. I think we don't want > to prevent it. But that is easily handled by allowing the implementation the freedom to decide which classes are BUILT-IN-CLASSes; we don't need to change the definition of BUILT-IN-CLASS. > In Gray's example of the use of BUILT-IN-CLASS, I can't imagine that someone > writing a portable program couldn't devise a more portable solution to the > problem, especially if there is alternative that is used if the > > (TYPEP (FIND-CLASS 'READTABLE) 'BUILT-IN-CLASS) > > returns T. > > Are you thinking of a portable programming environment? Suppose I were trying to write a portable inspector. If an object is an instance of a built-in class, then probably all I can do with it is to invoke the implementation-supplied DESCRIBE-OBJECT method, but if it is a STANDARD-CLASS, then I can do interesting things with its CLASS-SLOTS list. According to page 3-81 of document 89-003, CLASS-SLOTS simply returns NIL for a BUILT-IN-CLASS, so how else would I know the difference between a standard object that has no slots versus an object implemented in some way that I can't look inside of? Received: from Sail.Stanford.EDU by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA01250; Thu, 25 May 89 15:13:52 -0700 Reply-To: Received: from ti.com by SAIL.Stanford.EDU with TCP; 25 May 89 15:14:27 PDT Received: by ti.com id AA21021; Thu, 25 May 89 17:13:25 CDT Received: from dsg by tilde id AA04628; Thu, 25 May 89 16:49:16 CDT Received: From Kelvin By dsg Via CHAOS-NET With CHAOS-MAIL; Thu, 25 May 89 16:25:08 CDT Message-Id: <2821123544-11773066@Kelvin> Sender: GRAY@kelvin.csc.ti.com Date: Thu, 25 May 89 16:25:44 CDT From: David N Gray To: Jon L White Cc: Moon@STONY-BROOK.SCRC.Symbolics.COM, RPG@SAIL.Stanford.EDU, dussud@lucid.com, common-lisp-object-system@SAIL.Stanford.EDU Subject: Re: Random metaclasses for CL types In-Reply-To: Msg of Thu, 25 May 89 09:04:42 PDT from Jon L White > As I've previously argued, the only utility of BUILT-IN-CLASS is taxonomic; > and this capability can just as easily and naturally be provided by a list > of all such classes. No, having a list doesn't give you the ability to write methods specialized on that group of things. Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA01628; Thu, 25 May 89 15:24:03 -0700 Reply-To: Received: from Semillon.ms by ArpaGateway.ms ; 25 MAY 89 13:47:30 PDT Return-Path: Redistributed: CommonLoops.PA Received: from rand.org ([192.5.14.33]) by Xerox.COM ; 25 MAY 89 13:43:53 PDT Received: from blackcomb.rand.org by rand.org; Thu, 25 May 89 13:22:31 PDT Received: from localhost by blackcomb.arpa; Thu, 25 May 89 13:22:05 PDT Message-Id: <8905252022.AA11868@blackcomb.arpa> To: CommonLoops.PA@Xerox.COM Subject: Is the structure-class metaclass implemented? Date: Thu, 25 May 89 13:22:04 PDT From: Darrell I was not able to find any reference to structure-class metaclass in the current version of PCL, any idea when it will be implemented? Thanks, Darrell Shane Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA01784; Thu, 25 May 89 15:37:11 -0700 Reply-To: Received: from Semillon.ms by ArpaGateway.ms ; 25 MAY 89 14:34:15 PDT Date: Thu, 25 May 89 14:32 PDT From: Gregor.pa@Xerox.COM Subject: Re: Is the structure-class metaclass implemented? To: Darrell Cc: CommonLoops.PA@Xerox.COM Fcc: BD:>Gregor>mail>outgoing-mail-6.text.newest In-Reply-To: <8905252022.AA11868@blackcomb.arpa> Message-Id: <19890525213201.7.GREGOR@SPIFF.parc.xerox.com> Line-Fold: no Date: Thu, 25 May 89 13:22:04 PDT From: Darrell I was not able to find any reference to structure-class metaclass in the current version of PCL, any idea when it will be implemented? A group of us are currently working on part of the low-level support required to do this reasonably. We have most of an implementors spec done and a number of people have `signed off' on it. The other parts are pretty easy to do, and converting PCL to use this stuff is also easy. ------- Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA02480; Thu, 25 May 89 16:28:29 -0700 Reply-To: Received: from Semillon.ms by ArpaGateway.ms ; 25 MAY 89 16:23:24 PDT Return-Path: Redistributed: commonloops.pa Received: from june.cs.washington.edu ([128.95.1.4]) by Xerox.COM ; 25 MAY 89 16:20:41 PDT Received: from localhost by june.cs.washington.edu (5.59/6.13+) id AA11352; Thu, 25 May 89 16:20:41 PDT Return-Path: Message-Id: <8905252320.AA11352@june.cs.washington.edu> To: CommonLoops.pa@Xerox.COM Subject: Implementing parameterized classes Date: Thu, 25 May 89 16:20:40 PDT From: andyg@june.cs.washington.edu Has anyone out there thought about trying to write a metaclass that provides parameterized classes? Is this a realistic thing to attempt in CLOS? Or is CLU (or something else) the way to go. Any thoughts greatly appreciated. Andy Goodman Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA03607; Thu, 25 May 89 17:46:25 -0700 Reply-To: Received: from Semillon.ms by ArpaGateway.ms ; 25 MAY 89 17:42:12 PDT Return-Path: Redistributed: commonloops.pa Received: from arpa.att.com ([192.20.225.1]) by Xerox.COM ; 25 MAY 89 17:39:36 PDT From: lgm%ihlpf.uucp@att.att.com Date: Thu, 25 May 89 18:44 CDT >From: ihlpf!lgm (Lawrence G Mayka +1 312 416 5166) To: commonloops.pa%xerox.com%att.uucp@att.att.com Subject: Victoria Day PCL, on AKCL 1.122, on AMDAHL UTS Message-Id: <890525-174212-1780@Xerox> Well, the problem I was encountering in building PCL on AKCL 1.122 only occurs when running on Amdahl UTS; AKCL 1.122 on Sun workstations accepts PCL fine. I was hoping that the latest (Victoria Day) PCL would build properly on the Amdahl, but I've had no luck. With safety set to 0, I get various difficulties, depending on whether I'm compiling or simply loading, etc. I set safety to 2 and got __________________ Compiling CONSTRUCT... Compiling /f111/lgm/lisp/pcl/construct.lsp. Error: The index, 24, is too large. Error signalled by DCODE-CACHE-MISS. Backtrace: eval > let > load-defclass > add-named-class > update-class > check-super-metaclass-compatibility > notice-methods-change-2 > dcode-cache-miss ; (LET NIL ...) is being compiled. ;;; The form (LET NIL (LOAD-DEFCLASS 'FUNCALLABLE-STANDARD-CLASS 'CONSTRUCTOR 'NIL (LIST (LIST* :NAME 'CLASS '(:INITARG :CLASS :READER CONSTRUCTOR-CLASS)) (LIST* :NAME 'NAME :INITFUNCTION #'FALSE '(:INITFORM NIL :INITARG :NAME :READER CONSTRUCTOR-NAME)) (LIST* :NAME 'CODE-TYPE :INITFUNCTION #'FALSE '(:INITFORM NIL :ACCESSOR CONSTRUCTOR-CODE-TYPE)) (LIST* :NAME 'SUPPLIED-INITARG-NAMES '(:INITARG :SUPPLIED-INITARG-NAMES :READER CONSTRUCTOR-SUPPLIED-INITARG-NAMES)) (LIST* :NAME 'CODE-GENERATORS '(:INITARG :CODE-GENERATORS :READER CONSTRUCTOR-CODE-GENERATORS))) (LIST))) was not evaluated successfully. ;;; You are recommended to compile again. ___________________ A look at the value stack shows ___________________ IHS[14]: # ---> VS[99] VS[99]: # VS[100]: # @ IHS[15]: # ---> VS[101] VS[101]: # VS[102]: # VS[103]: #(0 NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL) VS[104]: 32 VS[105]: 14 VS[106]: 4 VS[107]: 2 VS[108]: 3 VS[109]: T VS[110]: # VS[111]: (#(20 (NAME CLASS-PRECEDENCE-LIST LOCAL-SUPERS LOCAL-SLOTS DIRECT-SUBCLASSES DIRECT-METHODS FORWARD-REFERENCED-SUPERS NO-OF-INSTANCE-SLOTS SLOTS WRAPPER DIRECT-GENERIC-FUNCTIONS PROTOTYPE OPTIONS CONSTRUCTORS ALL-DEFAULT-INITARGS) NIL #) #(2 (NAME CLASS-PRECEDENCE-LIST LOCAL-SUPERS LOCAL-SLOTS DIRECT-SUBCLASSES DIRECT-METHODS FORWARD-REFERENCED-SUPERS NO-OF-INSTANCE-SLOTS SLOTS WRAPPER DIRECT-GENERIC-FUNCTIONS PROTOTYPE OPTIONS CONSTRUCTORS ALL-DEFAULT-INITARGS) NIL #) # #) VS[112]: T VS[113]: 20 VS[114]: 8 VS[115]: 0 VS[116]: NIL VS[117]: 24 VS[118]: 32 VS[119]: 0 VS[120]: 24 VS[121]: 24 VS[122]: :ERROR VS[123]: NIL VS[124]: DCODE-CACHE-MISS VS[125]: "" VS[126]: "The index, ~D, is too large." VS[127]: (24) VS[128]: "The index, 24, is too large." ________________________ The last PCL that worked on AKCL on the Amdahl was the 12/7 version. If anyone, by some bizarre chance, actually has Victoria Day PCL running on top of AKCL 1.122 on Amdahl UTS (preferably 5.2.6b), you might let me know just so that I know there's hope. By the way, my AKCL does have the TURBO-CLOSURE patch installed. Lawrence G. Mayka AT&T Bell Laboratories lgm@ihlpf.att.com Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA13124; Fri, 26 May 89 06:55:14 -0700 Reply-To: Received: from Burger.ms by ArpaGateway.ms ; 26 MAY 89 06:47:57 PDT Return-Path: Redistributed: commonloops.pa Received: from arpa.att.com ([192.20.225.1]) by Xerox.COM ; 26 MAY 89 06:47:06 PDT From: lgm%ihlpf.uucp@att.att.com Date: Fri, 26 May 89 08:20 CDT >From: ihlpf!lgm (Lawrence G Mayka +1 312 416 5166) To: commonloops.pa%xerox.com%att.uucp@att.att.com Subject: Safety proclamation in "kcl-patches" is never rescinded Message-Id: <890526-064757-2615@Xerox> I have successfully built the Victoria Day PCL on top of AKCL 1.122 on a Sun-4. However, I noticed that all files were compiled with safety 2. This is because safety is set to 2 in "kcl-patches" via a PROCLAIM and is never changed thereafter. My reading of CLtL is that AKCL's behavior here is correct: PROCLAIM applies globally, and not just to the file currently being compiled. So, should I append the following to the end of "kcl-patches" (if I want safety 0, that is)? (proclaim '(optimize (safety 0) (space 0) (speed 3))) Actually, it would be more proper to set the optimizations back to whatever they were previously, but I don't know how to query AKCL about its optimization settings. By the way, at least one person has simply suggested skipping "kcl-patches" entirely - i.e., that PCL can do just fine without it. Lawrence G. Mayka AT&T Bell Laboratories lgm@ihlpf.att.com Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA13408; Fri, 26 May 89 07:32:59 -0700 Reply-To: Received: from Chardonnay.ms by ArpaGateway.ms ; 26 MAY 89 07:32:13 PDT Return-Path: Redistributed: commonloops.pa Received: from CHILES.SLISP.CS.CMU.EDU ([128.2.217.11]) by Xerox.COM ; 26 MAY 89 07:30:27 PDT Received: from CHILES.SLISP.CS.CMU.EDU by CHILES.SLISP.CS.CMU.EDU; 26 May 89 10:29:35 EDT To: commonloops.pa@Xerox.COM Subject: Victoria Day test.lisp Date: Fri, 26 May 89 10:29:17 EDT Message-Id: <371.612196157@CHILES.SLISP.CS.CMU.EDU> From: Bill.Chiles@WB1.CS.CMU.EDU I'm trying to install the Victoria Day PCL in CMU Common Lisp, and I'm having problems just compiling the test.lisp file. I'm pretty new to this stuff, so I don't have any good clues or skills for providing any good information on the lossage I'm seeing. I see the error in DCODE-CACHE-SIZE. I interpreted this definition and compiled test.lisp to produce the error below. The lossage is different when compiled in our system since PCL compiles with safety 0, so I interpreted DCODE-CACHE-SIZE. I've provided a partial backtrace. Has anyone else had this problem, or should I start crawling deep into our system? I should not guess at the problem, but it appears someone, some closure or cached information, thinks some structure is larger than it really is, possibly because cache structures can grow? Bill * (compile-file "pcl:test") Error output from /usr1/lisp/pcl/test.lisp 25-May-89 10:59:54. Compiled on 25-May-89 13:54:48 by CLC version M1.8 (24-May-89). DO-TEST compiled. DO-TEST-ERROR compiled. CLEANUP-DO-TEST compiled. Warning between functions: CLASS bound but not referenced. Error in function SVREF. Vector index, 16, out of bounds. Restarts: 0: Return to Top-Level. Debug (type H for help) (CONDITIONS::MAKE-ERROR-TABLE SVREF 0 16 NIL) 0] backtrace (CONDITIONS::MAKE-ERROR-TABLE SVREF 0 16 NIL) (SVREF #(0 NIL NIL NIL NIL ...) 16) (LET NIL (DECLARE (OPTIMIZE # #) (INLINE SVREF)) (SVREF (THE SIMPLE-VECTOR CACHE) (THE FIXNUM #))) (COND ((NOT #) NIL (RETURN T))) (DOTIMES (I NKEYS) (UNLESS (EQ # #) (RETURN T))) (COND ((NOT #) NIL (SETQ FREE-NEXT TRY) (RETURN-FROM SCAN-CACHE #))) (LET ((TAIL WRAPPERS-AND-ARGS)) (UNLESS (DOTIMES # #) (SETQ FREE-NEXT TRY) (RETURN-FROM SCAN-CACHE #))) (COND ((NOT #) NIL (LET # #) (DECF LIMIT))) (DO ((TRY # #) (LIMIT NEXT-SCAN-LIMIT LIMIT)) ((ZEROP LIMIT) (RETURN-FROM SCAN-CACHE #)) (UNLESS (ZEROP TRY) (LET # #) (DECF LIMIT))) (SETQ VALUE (BLOCK SCAN-CACHE (DO # # #))) (PROGN (SETQ VALUE (BLOCK SCAN-CACHE #)) (UNLESS (OR # #) (LET # # #)) (RETURN-FROM DCODE-CACHE-MISS VALUE)) (MACROLET ((INTERRUPTS-ON NIL NIL) (INTERRUPTS-OFF NIL NIL)) (PROGN (SETQ VALUE #) (UNLESS # #) (RETURN-FROM DCODE-CACHE-MISS VALUE))) (LABELS ((FILL-LINE # #) (COPY-LINE # # #) (FILL-PRIMARY NIL # #) (DISPLACE-PRIMARY NIL #) (COPY-TO-NEXT # #) ...) (WITHOUT-INTERRUPTS (SETQ VALUE #) (UNLESS # #) (RETURN-FROM DCODE-CACHE-MISS VALUE))) (LET* ((ENTRIES-HAVE-VALUE-P #) (PRIMARY #) (MIRROR #) (FREE-NEXT 0) (VALUE NIL)) (LABELS (# # # # # ...) (WITHOUT-INTERRUPTS # # #))) (TAGBODY RESTART (LET* (# # # # #) (LABELS # #))) (MACROLET ((COMPUTE-MIRROR # #) (COMPUTE-LOC-FROM-LINE # #)) (TAGBODY RESTART (LET* # #))) ((LAMBDA (GF TERTIARY-MISS-FN CACHE SIZE MASK ...) (BLOCK DCODE-CACHE-MISS #)) # # #(0 NIL NIL NIL NIL ...) 32 ...) (CHECK-SUPER-METACLASS-COMPATIBILITY # #) (NOTICE-METHODS-CHANGE-2 # (# #)) (CHECK-SUPER-METACLASS-COMPATIBILITY # #) (|(METHOD UPDATE-CLASS (STANDARD-CLASS))| # :DIRECT-SUPERCLASSES NIL :DIRECT-SLOTS ...) (UPDATE-CLASS # :DIRECT-SUPERCLASSES NIL :DIRECT-SLOTS ...) (NOTICE-METHODS-CHANGE-2 # (# :DIRECT-SUPERCLASSES NIL :DIRECT-SLOTS NIL ...)) (UPDATE-CLASS # :DIRECT-SUPERCLASSES NIL :DIRECT-SLOTS ...) (|(METHOD ADD-NAMED-CLASS (STANDARD-CLASS T T T T))| # FOO1 NIL NIL ...) (ADD-NAMED-CLASS # FOO1 NIL NIL ...) (NOTICE-METHODS-CHANGE-2 # (# FOO1 NIL NIL NIL)) (ADD-NAMED-CLASS # FOO1 NIL NIL ...) (LOAD-DEFCLASS STANDARD-CLASS FOO1 NIL NIL ...) . . . Received: from Sail.Stanford.EDU by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA13875; Fri, 26 May 89 08:48:16 -0700 Reply-To: Received: from lucid.com by SAIL.Stanford.EDU with TCP; 26 May 89 08:48:56 PDT Received: from bhopal ([192.43.178.13]) by heavens-gate id AA06358g; Fri, 26 May 89 08:47:37 PDT Received: by bhopal id AA17257g; Fri, 26 May 89 08:47:17 PDT Date: Fri, 26 May 89 08:47:17 PDT From: Jon L White Message-Id: <8905261547.AA17257@bhopal> To: Gray@dsg.csc.ti.com Cc: Moon@STONY-BROOK.SCRC.Symbolics.COM, RPG@SAIL.Stanford.EDU, dussud@lucid.com, common-lisp-object-system@SAIL.Stanford.EDU In-Reply-To: David N Gray's message of Thu, 25 May 89 16:25:44 CDT <2821123544-11773066@Kelvin> Subject: Random metaclasses for CL types re: > As I've previously argued, the only utility of BUILT-IN-CLASS is > taxonomic and this capability can just as easily and naturally be > provided by a list of all such classes. No, having a list doesn't give you the ability to write methods specialized on that group of things. Hey, did you forget we are talking about BUILT-IN-CLASS (and not about any particular built-in class such as INTEGER or VECTOR)? User's can't write methods for BUILT-IN-CLASS. Since my previous arguments about the artificial similarities among the built-in classes haven't been rebutted, then I don't see much to be gained by trying to let them write methods for such an ad-hoc construct. In your "portable INSPECTOR" project, for example, you need to make a decision as to whether to call the built-in DESCRIBE-OBJECT, or to fall into some code written in CLOS. I claim there is no conceptual disadvantage to making that decision by doing a MEMBER down a system supplied list. Furthermore I claim that creating an abstract metaclass for some totally disconnected set of classes has the _disadvantage_ of adding confusion, because the observer of the abstraction must think that there is an underlying similarity in the base elements. [The offending abstraction is BUILT-IN-CLASS because it's only portable use is taxonomic.] -- JonL -- Received: from Sail.Stanford.EDU by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA14682; Fri, 26 May 89 10:34:42 -0700 Reply-To: Received: from ti.com by SAIL.Stanford.EDU with TCP; 26 May 89 10:35:04 PDT Received: by ti.com id AA28451; Fri, 26 May 89 12:33:20 CDT Received: from Kelvin by tilde id AA09755; Fri, 26 May 89 12:30:34 CDT Message-Id: <2821195790-16113736@Kelvin> Sender: GRAY@kelvin.csc.ti.com Date: Fri, 26 May 89 12:29:50 CDT From: David N Gray To: Jon L White Cc: Moon@STONY-BROOK.SCRC.Symbolics.COM, RPG@SAIL.Stanford.EDU, common-lisp-object-system@SAIL.Stanford.EDU Subject: Re: Random metaclasses for CL types In-Reply-To: Msg of Fri, 26 May 89 08:47:17 PDT from Jon L White > Hey, did you forget we are talking about BUILT-IN-CLASS (and not about > any particular built-in class such as INTEGER or VECTOR)? No. > User's can't > write methods for BUILT-IN-CLASS. Sure they can. (defmethod frob ((class built-in-class)) (punt class)) (frob (class-of 3)) There, I just did it. The only thing you aren't supposed to do is to replace the BUILT-IN-CLASS methods specified by the standard. Admittedly, the usefulness of this may be limited. > Since my previous arguments about the > artificial similarities among the built-in classes haven't been rebutted, > then I don't see much to be gained by trying to let them write methods for > such an ad-hoc construct. I don't see anything to be gained by not allowing it. > In your "portable INSPECTOR" project, for example, you need to make a > decision as to whether to call the built-in DESCRIBE-OBJECT, or to fall > into some code written in CLOS. I claim there is no conceptual > disadvantage to making that decision by doing a MEMBER down a system > supplied list. Then what do we need object-oriented programming for? Sure, there's always another way it could be done. > Furthermore I claim that creating an abstract metaclass > for some totally disconnected set of classes has the _disadvantage_ of > adding confusion, because the observer of the abstraction must think > that there is an underlying similarity in the base elements. There _is_ an underlying similarity: they share the same methods for MAKE-INSTANCE, SLOT-VALUE-USING-CLASS, SLOT-BOUNDP-USING-CLASS, SLOT-EXISTS-P-USING-CLASS, SLOT-MAKUNBOUND-USING-CLASS, CLASS-SLOTS, CLASS-DEFAULT-INITARGS, CLASS-DIRECT-DEFAULT-INITARGS, CLASS-DIRECT-SLOTS, CLASS-FINALIZED-P, as specified in chapter 3. The only way I might accept dropping BUILT-IN-CLASS from the standard would be if the standard included the class CLASS (which should be done anyway), so I could do (defmethod frob ((class class)) (punt class)) as a catch-all for any unexpected metaclass. But since BUILT-IN-CLASS or some equivalent needs to exist in each implementation for the meta-object protocol, why not standardize the name of it? It could be argued, though, that it only belongs in chapter 3. Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA14843; Fri, 26 May 89 10:57:31 -0700 Reply-To: Received: from Burger.ms by ArpaGateway.ms ; 26 MAY 89 10:56:45 PDT Return-Path: Redistributed: commonloops.pa Received: from fs3.cs.rpi.edu ([128.213.1.14]) by Xerox.COM ; 26 MAY 89 10:55:55 PDT Received: by fs3.cs.rpi.edu (5.54/1.2-RPI-CS-Dept) id AA07084; Fri, 26 May 89 13:49:27 EDT Date: Fri, 26 May 89 13:50:10 EDT From: harrisr@turing.cs.rpi.edu (Richard Harris) Received: by turing.cs.rpi.edu (4.0/1.2-RPI-CS-Dept) id AA04106; Fri, 26 May 89 13:50:10 EDT Message-Id: <8905261750.AA04106@turing.cs.rpi.edu> To: commonloops.pa@Xerox.COM Subject: Re: Safety proclamation in "kcl-patches" is never rescinded > By the way, at least one person has simply suggested skipping > "kcl-patches" entirely - i.e., that PCL can do just fine without > it. The file kcl-patches.lisp patches three functions: defmacro: fix KCL's &environment bug, get-setf-method: check the result of get-setf-method-multiple-value, get-setf-method-multiple-value: (I don't understand this one, presumably it works around some bug, but it seems to be equivalent to the original version of get-setf-method-multiple-value). The defmacro &environment bug has been fixed in akcl since akcl-1-98. If you are using an akcl that is newer than akcl-1-98, I think you can skip the file kcl-patches. Rick Harris Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA16558; Fri, 26 May 89 12:29:10 -0700 Reply-To: Received: from Semillon.ms by ArpaGateway.ms ; 26 MAY 89 12:14:02 PDT Date: Fri, 26 May 89 12:11 PDT From: Gregor.pa@Xerox.COM Subject: EQL bug in Victoria Day PCL To: CommonLoops.PA@Xerox.COM Fcc: BD:>Gregor>mail>outgoing-mail-6.text.newest Message-Id: <19890526191129.3.GREGOR@SPIFF.parc.xerox.com> Line-Fold: no There is a bug in Victoria Day PCL with certain uses of EQL specializers. I believe that this bug could also strike people doing simple meta-level programming, but have not heard any reports of such. The following patch should deal with this problem. You can either put this in a separate file and compile and load that on top of PCL, or you can make the changes to the PCL sources and recompile. ;from file defs.lisp (this is an addition) (defvar *notice-methods-change-force-p* ()) ;from file boot.lisp (defun fix-early-generic-functions (&optional noisyp) (allocate-instance (find-class 'standard-generic-function));Be sure this ;class has an ;instance. (let* ((class (find-class 'standard-generic-function)) (wrapper (class-wrapper class)) (n-static-slots (class-no-of-instance-slots class)) #+Lucid (lucid::*redefinition-action* nil) (*notice-methods-change-force-p* t)) (flet ((fix-structure (gf) (let ((static-slots (%allocate-static-slot-storage--class n-static-slots))) (setf (funcallable-instance-wrapper gf) wrapper (funcallable-instance-static-slots gf) static-slots)))) (dolist (early-gf-spec *early-generic-functions*) (when noisyp (format t "~&~S..." early-gf-spec)) (let* ((early-gf (gdefinition early-gf-spec)) (early-static-slots (funcallable-instance-static-slots early-gf)) (early-discriminator-code nil) (early-methods nil) (aborted t)) (flet ((trampoline (&rest args) (apply early-discriminator-code args))) (if (not (listp early-static-slots)) (when noisyp (format t "already fixed?")) (unwind-protect (progn (setq early-discriminator-code (early-gf-discriminator-code early-gf)) (setq early-methods (early-gf-methods early-gf)) (setf (gdefinition early-gf-spec) #'trampoline) (when noisyp (format t "trampoline...")) (fix-structure early-gf) (when noisyp (format t "fixed...")) (initialize-instance early-gf) (dolist (early-method early-methods) (destructuring-bind (class quals lambda-list specs fn doc slot-name) (cadddr early-method) (setq specs (early-method-specializers early-method t)) (real-add-method early-gf (real-make-a-method class quals lambda-list specs fn doc slot-name)) (when noisyp (format t "m")))) (setf (slot-value early-gf 'name) early-gf-spec) (setq aborted nil)) (setf (gdefinition early-gf-spec) early-gf) (when noisyp (format t ".")) (when aborted (setf (funcallable-instance-static-slots early-gf) early-static-slots))))))) (dolist (fns *early-functions*) (setf (symbol-function (car fns)) (symbol-function (caddr fns)))) (dolist (fixup *generic-function-fixups*) (destructuring-bind (gf-spec lambda-list specializers method-fn-name) fixup (let* ((fn (if method-fn-name (symbol-function method-fn-name) (symbol-function gf-spec))) (gf (make-instance 'standard-generic-function)) (method (make-a-method 'standard-method () lambda-list specializers fn nil))) (set-function-name gf gf-spec) (setf (generic-function-name gf) gf-spec) (real-add-method gf method) (setf (gdefinition gf-spec) gf))))))) ;from file methods.lisp (defun notice-methods-change (generic-function) (let ((old-discriminator-code (generic-function-discriminator-code generic-function))) (if *notice-methods-change-force-p* (notice-methods-change-1 generic-function) ;; Install a lazy evaluation discriminator code updator as the ;; funcallable-instance function of the generic function. When ;; it is called, it will update the discriminator code of the ;; generic function, unless it is inside a recursive call to ;; the generic function in which case it will call the old ;; version of the discriminator code for the generic function. ;; ;; Note that because this closure will be the discriminator code ;; of a generic function it must be careful about how it changes ;; the discriminator code of that same generic function. If it ;; isn't careful, it could change its closure variables out from ;; under itself. ;; ;; In order to prevent this we take a simple measure: we just ;; make sure that it doesn't try to reference its own closure ;; variables after it makes the dcode change. This is done by ;; having notice-methods-change-2 do the work of making the ;; change AND calling the actual generic function (a closure ;; variable) over. This means that at the time the dcode change ;; is made, there is a pointer to the generic function on the ;; stack where it won't be affected by the change to the closure ;; variables. ;; (set-funcallable-instance-function generic-function #'(lambda (&rest args) #+Genera (declare (dbg:invisible-frame :clos-internal)) (if (memq generic-function *invalid-generic-functions-on-stack*) (if old-discriminator-code (apply old-discriminator-code args) (error "Tried to call an invalid generic function ~ that never was valid at all.")) (notice-methods-change-2 generic-function args))))))) ------- Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA13408; Fri, 26 May 89 07:32:59 -0700 Reply-To: Received: from Chardonnay.ms by ArpaGateway.ms ; 26 MAY 89 07:32:13 PDT Return-Path: Redistributed: commonloops.pa Received: from CHILES.SLISP.CS.CMU.EDU ([128.2.217.11]) by Xerox.COM ; 26 MAY 89 07:30:27 PDT Received: from CHILES.SLISP.CS.CMU.EDU by CHILES.SLISP.CS.CMU.EDU; 26 May 89 10:29:35 EDT To: commonloops.pa@Xerox.COM Subject: Victoria Day test.lisp Date: Fri, 26 May 89 10:29:17 EDT Message-Id: <371.612196157@CHILES.SLISP.CS.CMU.EDU> From: Bill.Chiles@WB1.CS.CMU.EDU I'm trying to install the Victoria Day PCL in CMU Common Lisp, and I'm having problems just compiling the test.lisp file. I'm pretty new to this stuff, so I don't have any good clues or skills for providing any good information on the lossage I'm seeing. I see the error in DCODE-CACHE-SIZE. I interpreted this definition and compiled test.lisp to produce the error below. The lossage is different when compiled in our system since PCL compiles with safety 0, so I interpreted DCODE-CACHE-SIZE. I've provided a partial backtrace. Has anyone else had this problem, or should I start crawling deep into our system? I should not guess at the problem, but it appears someone, some closure or cached information, thinks some structure is larger than it really is, possibly because cache structures can grow? Bill * (compile-file "pcl:test") Error output from /usr1/lisp/pcl/test.lisp 25-May-89 10:59:54. Compiled on 25-May-89 13:54:48 by CLC version M1.8 (24-May-89). DO-TEST compiled. DO-TEST-ERROR compiled. CLEANUP-DO-TEST compiled. Warning between functions: CLASS bound but not referenced. Error in function SVREF. Vector index, 16, out of bounds. Restarts: 0: Return to Top-Level. Debug (type H for help) (CONDITIONS::MAKE-ERROR-TABLE SVREF 0 16 NIL) 0] backtrace (CONDITIONS::MAKE-ERROR-TABLE SVREF 0 16 NIL) (SVREF #(0 NIL NIL NIL NIL ...) 16) (LET NIL (DECLARE (OPTIMIZE # #) (INLINE SVREF)) (SVREF (THE SIMPLE-VECTOR CACHE) (THE FIXNUM #))) (COND ((NOT #) NIL (RETURN T))) (DOTIMES (I NKEYS) (UNLESS (EQ # #) (RETURN T))) (COND ((NOT #) NIL (SETQ FREE-NEXT TRY) (RETURN-FROM SCAN-CACHE #))) (LET ((TAIL WRAPPERS-AND-ARGS)) (UNLESS (DOTIMES # #) (SETQ FREE-NEXT TRY) (RETURN-FROM SCAN-CACHE #))) (COND ((NOT #) NIL (LET # #) (DECF LIMIT))) (DO ((TRY # #) (LIMIT NEXT-SCAN-LIMIT LIMIT)) ((ZEROP LIMIT) (RETURN-FROM SCAN-CACHE #)) (UNLESS (ZEROP TRY) (LET # #) (DECF LIMIT))) (SETQ VALUE (BLOCK SCAN-CACHE (DO # # #))) (PROGN (SETQ VALUE (BLOCK SCAN-CACHE #)) (UNLESS (OR # #) (LET # # #)) (RETURN-FROM DCODE-CACHE-MISS VALUE)) (MACROLET ((INTERRUPTS-ON NIL NIL) (INTERRUPTS-OFF NIL NIL)) (PROGN (SETQ VALUE #) (UNLESS # #) (RETURN-FROM DCODE-CACHE-MISS VALUE))) (LABELS ((FILL-LINE # #) (COPY-LINE # # #) (FILL-PRIMARY NIL # #) (DISPLACE-PRIMARY NIL #) (COPY-TO-NEXT # #) ...) (WITHOUT-INTERRUPTS (SETQ VALUE #) (UNLESS # #) (RETURN-FROM DCODE-CACHE-MISS VALUE))) (LET* ((ENTRIES-HAVE-VALUE-P #) (PRIMARY #) (MIRROR #) (FREE-NEXT 0) (VALUE NIL)) (LABELS (# # # # # ...) (WITHOUT-INTERRUPTS # # #))) (TAGBODY RESTART (LET* (# # # # #) (LABELS # #))) (MACROLET ((COMPUTE-MIRROR # #) (COMPUTE-LOC-FROM-LINE # #)) (TAGBODY RESTART (LET* # #))) ((LAMBDA (GF TERTIARY-MISS-FN CACHE SIZE MASK ...) (BLOCK DCODE-CACHE-MISS #)) # # #(0 NIL NIL NIL NIL ...) 32 ...) (CHECK-SUPER-METACLASS-COMPATIBILITY # #) (NOTICE-METHODS-CHANGE-2 # (# #)) (CHECK-SUPER-METACLASS-COMPATIBILITY # #) (|(METHOD UPDATE-CLASS (STANDARD-CLASS))| # :DIRECT-SUPERCLASSES NIL :DIRECT-SLOTS ...) (UPDATE-CLASS # :DIRECT-SUPERCLASSES NIL :DIRECT-SLOTS ...) (NOTICE-METHODS-CHANGE-2 # (# :DIRECT-SUPERCLASSES NIL :DIRECT-SLOTS NIL ...)) (UPDATE-CLASS # :DIRECT-SUPERCLASSES NIL :DIRECT-SLOTS ...) (|(METHOD ADD-NAMED-CLASS (STANDARD-CLASS T T T T))| # FOO1 NIL NIL ...) (ADD-NAMED-CLASS # FOO1 NIL NIL ...) (NOTICE-METHODS-CHANGE-2 # (# FOO1 NIL NIL NIL)) (ADD-NAMED-CLASS # FOO1 NIL NIL ...) (LOAD-DEFCLASS STANDARD-CLASS FOO1 NIL NIL ...) . . . Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA23023; Fri, 26 May 89 21:25:07 -0700 Reply-To: Received: from Cabernet.ms by ArpaGateway.ms ; 26 MAY 89 21:26:16 PDT Return-Path: Redistributed: commonloops.pa Received: from mbunix.mitre.org ([129.83.20.100]) by Xerox.COM ; 26 MAY 89 21:24:58 PDT Posted-From: The MITRE Corp., Bedford, MA X-Alternate-Route: user%node@mbunix.mitre.org Return-Path: Received: from sabre.mitre.org by linus.MITRE.ORG (5.59/RCF-3S) id AA17356; Fri, 26 May 89 17:08:31 EDT Posted-Date: Fri, 26 May 89 17:08:28 EDT Received: from localhost by sabre.mitre.org (3.2/RCF-3C) id AA02801; Fri, 26 May 89 17:08:32 EDT Message-Id: <8905262108.AA02801@sabre.mitre.org> To: CommonLoops.pa@Xerox.COM Cc: pc@linus.MITRE.ORG Subject: eql specializers Date: Fri, 26 May 89 17:08:28 EDT From: rich@linus.MITRE.ORG They don't seem to work at all in Victoria Day PCL. If you type: (DEFMETHOD FOO ((X (EQL :X)) XXX) NIL) you get into an infinite loop. It seems that when it is invalidating methods it will want to do the same for every superior class. This means the class T. Since FOO is also a direct method of T it will try to invalidate FOO again. I think this was supposed to be avoided because FOO should already have been invalidated and put on the list *umi-gfs*. However, you call UPDATE-CLASS again, which nils out the global *umi-gfs*, therefore an infinite loop.... Rich ------------------------------------------------------------------------- uucp: linus!rich arpa: rich@mitre.org Received: from Sail.Stanford.EDU by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA02862; Sat, 27 May 89 13:56:37 -0700 Reply-To: Received: from lucid.com by SAIL.Stanford.EDU with TCP; 27 May 89 13:57:17 PDT Received: from bhopal ([192.43.178.13]) by heavens-gate id AA04783g; Sat, 27 May 89 13:54:32 PDT Received: by bhopal id AA18885g; Sat, 27 May 89 13:54:10 PDT Date: Sat, 27 May 89 13:54:10 PDT From: Jon L White Message-Id: <8905272054.AA18885@bhopal> To: Gray@dsg.csc.ti.com Cc: Moon@STONY-BROOK.SCRC.Symbolics.COM, RPG@SAIL.Stanford.EDU, common-lisp-object-system@SAIL.Stanford.EDU In-Reply-To: David N Gray's message of Fri, 26 May 89 12:29:50 CDT <2821195790-16113736@Kelvin> Subject: Random metaclasses for CL types re: [using MEMBER on a list of built-in classes] Then what do we need object-oriented programming for? Sure, there's always another way it could be done. That's not the point at all; rather the entire issue is whether or not BUILT-IN-CLASS has enough commonality among its elements such that writing methods on it makes sense (your example method certainly didn't make any sense to me). The flip side of the comment "Sure, there's always another way it could be done" is, "Sure, every random collection of things can be made into a class". I am certainly not arguing against someone implementing built-in classes this way -- using a common meta-class to simplify coding -- rather, I am supporting Gabriel's call to remove this piece of non-portable, internal implementation from the end-user's view. re: There _is_ an underlying similarity: they share the same methods for MAKE-INSTANCE, ... CLASS-FINALIZED-P, as specified in chapter 3. I.e., they are "similar" because someone decided make a random collection of types, and then list all the methods that could be applied to class objects? Isn't that circular reasoning? [By the bye, Chap 3 *isn't* part of the standard, and we are talking about a change to the elementary part of Chap 1.] Also, as I would have it, built-in classes couldn't be defined by the user, subclassed by the user, dynamically altered by the user, etc; under these restrictions, many parts of the metaobject protocol wouldn't be interesting for random collections of built-in classes, including the whole such collection. In fact, _almost_ any method that one would need to support the implementation of built-in types is not specific to BUILT-IN-CLASS, but is the default at the top of the class heirarchy. The restrictions on BUILT-IN-CLASS are typically just "You can't do that", which is what you need for any otherwise unembellished metaclass. re: The only way I might accept dropping BUILT-IN-CLASS from the standard would be if the standard included the class CLASS (which should be done anyway), . . . Gleep, I don't recall how we managed to vote in Chap 1 without class CLASS. Can someone add a quickie cleanup to straighten this out? -- JonL -- Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA10811; Sun, 28 May 89 11:13:37 -0700 Reply-To: Received: from Cabernet.ms by ArpaGateway.ms ; 28 MAY 89 11:14:45 PDT Return-Path: Redistributed: commonloops.pa Received: from arpa.att.com ([192.20.225.1]) by Xerox.COM ; 28 MAY 89 11:13:43 PDT From: lgm%ihlpf.uucp@att.att.com Date: Sun, 28 May 89 12:53 CDT >From: ihlpf!lgm (Lawrence G Mayka +1 312 416 5166) To: commonloops.pa%xerox.com%att.uucp@att.att.com Subject: The compilation ordering imposed by SETF methods Message-Id: <890528-111445-5404@Xerox> This topic has general applicability to Lisp, but I have a particular question in regard to CLOS, so please bear with me. I am interested in the issue of *independent compilation* - i.e., Lisp systems' support for the compiling and loading of different software units (functions, files, or CLOS classes) independently of each other. Generally, of course, functions have this property and macros don't. That is, a call to a function not yet defined produces at most a warning; a use of a macro not yet defined produces incorrect code (a call to a function instead of a use of the macro). Thus, in a many-person (e.g., department-size) project, macros as interfaces can lead to troublesome interdependencies unless they are confined to a "global header file" loaded before anything else is compiled, and any modifications to the macros maintain upward-compatibility from previous usage. The interface to a CLOS class is made up primarily of functions: everything from MAKE-INSTANCE to applicable methods to slot readers. One exception, however, is SETF methods (including the SETF method created through use of the :ACCESSOR slot option). Because SETF is a macro, most Lisp systems refuse to compile a use of SETF unless a corresponding setf-method has already been defined. Such a restriction forces a compilation ordering on the caller and called methods. The only resolution of the interdependency seems to be to create a "global header file" of DEFGENERICs like (defgeneric (setf the-slot) (right-hand-side self)) Does anyone have a better resolution of the SETF ordering problem? Does anyone know of any other ordering problems (with or without solutions!) in a many-person CLOS-based software project? Does anyone else worry about these issues? For example, I have heard that the ANSI Common Lisp committee is doing a few things to "clean up" SETF. Have they considered the ordering problem in regular Lisp, especially with respect to SETF? In fact, is there an ANSI Common Lisp mailing list? I'd like to keep up to date on any plans for modifications to Common Lisp. Lawrence G. Mayka AT&T Bell Laboratories lgm@ihlpf.att.com Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA11728; Sun, 28 May 89 14:04:46 -0700 Reply-To: Received: from Semillon.ms by ArpaGateway.ms ; 28 MAY 89 14:06:10 PDT Date: Sun, 28 May 89 14:03 PDT From: Gregor.pa@Xerox.COM Subject: Re: The compilation ordering imposed by SETF methods To: lgm%ihlpf.uucp@att.att.com Cc: commonloops.pa@Xerox.COM Fcc: BD:>Gregor>mail>outgoing-mail-6.text.newest In-Reply-To: The message of 28 May 89 10:53 PDT from ihlpf!lgm@att.att.com Message-Id: <19890528210337.2.GREGOR@SPIFF.parc.xerox.com> Line-Fold: no This message is important to all users of PCL. Date: Sun, 28 May 89 12:53 CDT From: ihlpf!lgm@att.att.com That is, a call to a function not yet defined produces at most a warning; a use of a macro not yet defined produces incorrect code (a call to a function instead of a use of the macro). Thus, in a many-person (e.g., department-size) project, macros as interfaces can lead to troublesome interdependencies ... The interface to a CLOS class is made up primarily of functions: everything from MAKE-INSTANCE to applicable methods to slot readers. One exception, however, is SETF methods (including the SETF method created through use of the :ACCESSOR slot option). Because SETF is a macro, most Lisp systems refuse to compile a use of SETF unless a corresponding setf-method has already been defined. Such a restriction forces a compilation ordering on the caller and called methods. The only resolution of the interdependency seems to be to create a "global header file" of DEFGENERICs like (defgeneric (setf the-slot) (right-hand-side self)) Actually, a CLOS inspired change to Common Lisp was made precisely to solve this problem. Unfortunately, it is difficult to implement this change in PCL. Common Lisp has been changed to give SETF a `well known', default expansion. When expanding a SETF macro, such as: (setf ( object) new) if there is no declared setf method for the function , the setf form expands as follows: (funcall #'(setf ) new object) because of this general rule, it is possible to compile SETF forms without preloading a mess of defsetf forms. The definition of the actual setf function, #'(setf ), can come later just like the definition of other functions. Note: As you can see, this change also introduced a mechanism for using lists to name functions (i.e. lists whose car is the symbol SETF), but that isn't really relevant. Note: (Author's personal opinion) If you never, ever use defsetf or any of its friends, this change makes SETF what it should have been all along, a naming convention for setters. It gets rid of most of its troublesome macro behavior. The problem is that there isn't really a portable way to implement this. For one thing, I can't add non-symbol function names portably. For another, it is difficult to patch SETF portably. So, in the meatime, in PCL you must take special, advance action to be able to expand calls to setf in this new, default way. To make this easier, PCL provides the macro DO-STANDARD-DEFSETF. You can put calls to this macro in a header file, and then program normally. PCL also tries to help by doing one of these standard defsetfs whenever it sees the name of an accessor, writer or a defmethod with (setf ). When you get a Common Lisp that really has this change made to it you can delete the header file and PCL will be able to stop doing them internally. In fact, is there an ANSI Common Lisp mailing list? I'd like to keep up to date on any plans for modifications to Common Lisp. Send a message to RPG@Sail.Stanford.edu to ask to be added to the Common-Lisp or X3J13 mailing lists. ------- Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA29870; Tue, 30 May 89 04:23:22 -0700 Reply-To: Received: from Semillon.ms by ArpaGateway.ms ; 30 MAY 89 03:48:25 PDT Return-Path: Redistributed: commonloops.pa Received: from uunet.uu.net ([192.48.96.2]) by Xerox.COM ; 30 MAY 89 03:46:13 PDT Received: from unido.UUCP by uunet.uu.net (5.61/1.14) with UUCP id AA04487; Tue, 30 May 89 06:46:02 -0400 Received: from ifistg.uucp by unido.irb.informatik.uni-dortmund.de with uucp via EUnet for uunet id AI27457; Tue, 30 May 89 08:28:42 +0100 Received: by ifistg.uucp; Tue, 30 May 89 09:16:13 -0200 From: "Christian Rathke" Date: Tue, 30 May 89 09:11:57 +0200 Message-Id: <8905300711.AA02060@is4.ifistg.uucp> Received: by is4.ifistg.uucp; Tue, 30 May 89 09:11:57 +0200 To: commonloops.pa@Xerox.COM Subject: mail archive server for pcl I appologize for using this list for a non technical question. In West-Germany we do not have easy access to the newest PCL version available by ftp because of a missing internet access. Is there someone out there who is willing to establish (or already has established) a mail archive server for PCL that we could use to poll for the newest version? Currently, we have to beg a friend to ftp it for us, pack it and send it over to the old world, but this seems to be unbearable in the future. We also do not want to loose his cooperative attitude towards us. Of course, we do appreciate Gregor's efforts for keeping PCL developing as dynamicly as it has been, and would like to avoid asking him for the additional work. Please let me know if you are willing to help us. Maybe other sites would appreciate this service also. -Christian Rathke ============================================================================== Christian Rathke unido!ifistg!rathke@uunet.uu.net Institut fuer Informatik Universitaet Stuttgart Forststrasse 86 D - 7000 Stuttgart 1 FRG Tel.: (49) 711-121-1436 ============================================================================== Received: from Sail.Stanford.EDU by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA24717; Thu, 1 Jun 89 08:58:08 -0700 Reply-To: Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 1 Jun 89 08:52:51 PDT Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs) id AA25231; Thu, 1 Jun 89 09:53:09 -0600 Received: by defun.utah.edu (5.61/utah-2.0-leaf) id AA14532; Thu, 1 Jun 89 09:53:06 -0600 From: sandra%defun@cs.utah.edu (Sandra J Loosemore) Message-Id: <8906011553.AA14532@defun.utah.edu> Date: Thu, 1 Jun 89 09:53:05 MDT Subject: issue CLOS-MACRO-COMPILATION To: cl-compiler@sail.stanford.edu Cc: common-lisp-object-system@sail.stanford.edu I'm in the process of revising the writeup on this issue to incorporate the amendment Gregor proposed at the last meeting, and I have a question. The amendment uses the term "load time" to describe the time at which certain things happen. I think is not really what we want, since it's possible that the defining macro in question might not appear at top level. I'd suggest saying something like "the time at which the macro is normally executed" instead. However, to me this doesn't really make sense in the context of the amendment to the DEFINE-METHOD-COMBINATION language: "clarify that the bodies of such forms are evaluated no earlier than load time". Does this really mean "no earlier than the time at which the DEFINE-METHOD-COMBINATION macro is executed"? I've been under the impression that DEFINE-METHOD-COMBINATION defines a functional object and that its body could be evaluated no earlier than the time that function is invoked, which would be (at the earliest) when a DEFGENERIC form that references it is executed. Or am I confused again? -Sandra ------- Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA12079; Tue, 6 Jun 89 12:52:48 -0700 Reply-To: Received: from Burger.ms by ArpaGateway.ms ; 06 JUN 89 12:43:45 PDT Return-Path: Redistributed: Commonloops.PA Received: from flamingo.stanford.edu ([36.12.0.20]) by Xerox.COM ; 06 JUN 89 12:41:33 PDT Received: by flamingo.stanford.edu (5.57/Ultrix2.4-C) id AA09114; Tue, 6 Jun 89 12:39:37 EDT Date: Tue, 6 Jun 89 12:39:37 EDT From: rit@flamingo.stanford.edu (Jean-Francois Rit) Message-Id: <8906061639.AA09114@flamingo.stanford.edu> To: Commonloops.PA@Xerox.COM Subject: compiling braid1.lisp under IBCL I have some difficulty to compile PCL (Victoria Day) under IBCL. Namely,in the file braid1.lsp, during the compilation of (defmethod shared-initialize :after ((class standard-class) ... The compiler seems to go into a loop. It goes on forever, without crashing. If I try to enter in a break loop, the debugger stops short of giving me the whole value stack, a further interruption crashes the lisp process. Has anybody had a related problem? JF Jean-Francois Rit Tel: (415) 723 3796 CS Dept Robotics Laboratory e-mail: rit@coyote.stanford.edu Cedar Hall B7 Stanford, CA 94305-4110 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA11922; Thu, 8 Jun 89 17:09:32 -0700 Reply-To: Received: from Salvador.ms by ArpaGateway.ms ; 08 JUN 89 17:09:32 PDT Return-Path: Redistributed: CommonLoops.PA Received: from sumex-aim.stanford.edu ([36.44.0.6]) by Xerox.COM ; 08 JUN 89 17:08:09 PDT Received: by sumex-aim.stanford.edu (4.0/inc-1.0) id AA26602; Thu, 8 Jun 89 17:09:32 PDT Date: Thu, 8 Jun 89 17:09:31 PDT From: James Rice To: CommonLoops.PA@Xerox.COM Subject: Bug in DCODE and/or Caching. Message-Id: Hello, I think the following is indicative of a bug in DCode/Caching. I don't have time to look for it (I'm off on holiday, whoopee) so I thought I'd just broadcast it. The symptom is (apparently) unnecessary consing when using an accessor for a shared slot from somewhere outside of a method. So: (defclass foo () ((a :Allocation :Class :Accessor a :Initform 42))) (defun bar (x) (a x)) (setq inst (make-instance 'foo)) (meter:test '(bar inst) #o16) -> (sorry about the long lines) DCODE-CACHE-MISS 1 1,269 1,269 480 1,269 (:INTERNAL (:INTERNAL #:F0533 0) 0) 1 358 358 0 358 LOOKUP-METHOD-1 1 357 357 0 357 SYS:*EVAL 2 323 161 0 323 ALL-STD-CLASS-READERS-TERTIARY-MISS 1 279 279 0 279 LOOKUP-METHOD-INTERNAL 1 260 260 0 260 COMPUTE-WRAPPER-CACHE-LOCATION-1 1 258 258 32 258 GET-CPL-1 1 217 217 0 217 (:INTERNAL (:INTERNAL #:F3600 0) 0) 1 206 206 0 206 BAR 1 144 144 0 144 (:INTERNAL LOOKUP-METHOD-1 0) 1 137 137 0 137 (:INTERNAL (:INTERNAL #:F2107 0) 0) 1 134 134 0 134 SLOT-VALUE 1 114 114 0 114 EVAL 1 113 113 0 113 (METHOD READER/WRITER-METHOD-SLOT-NAME (STANDARD-READER/WRITER-METHOD) 1 106 106 0 106 (:INTERNAL (:INTERNAL #:F2207 0) 0) 1 91 91 0 91 (METHOD SLOT-VALUE-USING-CLASS (STANDARD-CLASS T T)) 1 76 76 0 76 GET-CLASS-SLOT-VALUE-1 1 50 50 0 50 GET-CLASS-1 1 48 48 0 48 CLASS-OF 1 38 38 0 38 WRAPPER-OF 1 35 35 0 35 (METHOD ALL-STD-CLASS-READERS-MISS-1 (STANDARD-CLASS T T)) 1 31 31 0 31 INTEGER-LENGTH 1 27 27 0 27 METER::TEST 1 0 0 0 0 total 25 4,671 186 512 4,671 As you can see, DCODE-CACHE-MISS and COMPUTE-WRAPPER-CACHE-LOCATION-1 both cons a fair bit. This problem happens on every call, so class slots can cons pretty heroically if you're not careful. This is for "5/22/89 Victoria Day PCL" on a TI Explorer I running release 5. Have fun, Rice. Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA01083; Fri, 9 Jun 89 11:12:46 -0700 Reply-To: Received: from Semillon.ms by ArpaGateway.ms ; 09 JUN 89 11:11:47 PDT Date: 9 Jun 89 11:06 PDT From: kiuchi.pa@Xerox.COM Subject: Re: compiling braid1.lisp under IBCL In-Reply-To: rit@flamingo.stanford.edu (Jean-Francois Rit)'s message of Tue, 6 Jun 89 12:39:37 EDT To: rit@flamingo.stanford.edu (Jean-Francois Rit) Cc: Commonloops.PA@Xerox.COM Message-Id: <890609-111147-8262@Xerox> I have some difficulty to compile PCL (Victoria Day) under IBCL. Namely,in the file braid1.lsp, during the compilation of (defmethod shared-initialize :after ((class standard-class) ... The compiler seems to go into a loop. It goes on forever, without crashing. If I try to enter in a break loop, the debugger stops short of giving me the whole value stack, a further interruption crashes the lisp process. Has anybody had a related problem? I've tested compiling the current version(Victoria Day) of PCL under IBCL(01/01, October 15, 1987) with turbo-closure patch on Sun4/110(SunOS4.0). I could not reproduce your problem. Yasuhiko Kiuchi (Kiuchi.pa@Xerox.com) ---------- Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA02558; Sun, 11 Jun 89 03:05:27 -0700 Received: from Salvador.ms by ArpaGateway.ms ; 11 JUN 89 03:03:11 PDT Return-Path: Redistributed: commonloops.pa Received: from vlsi.caltech.edu ([192.12.18.4]) by Xerox.COM ; 11 JUN 89 03:01:18 PDT Received: by vlsi.caltech.edu (5.59/1.2) id AA18161; Sun, 11 Jun 89 03:01:31 PDT Date: Sun, 11 Jun 89 03:01:31 PDT From: newton@vlsi.caltech.edu (Mike Newton) Message-Id: <8906111001.AA18161@vlsi.caltech.edu> To: commonloops.pa@Xerox.COM Subject: Bug in latest PCL when used w/ AKCL + 'fix' I believe there is a problem with either get-setf-method or get-setf-method-multiple-value in the kcl-patches.lsp. This shows up when compiling std-class.lsp under AKCL version 1.175. The below file is a 'minimal' (80 line) test case. Either compile the whole thing or just load the two get-setf... defuns and then try to compile the last defun. Note that this 'bug' is easy to get around if you are running Akcl 1.175 -- just #|... out ...|# the definitions of getf-setf... in the file kcl-patches.lsp and everything compiles fine. - mike (No longer in exile in Hilo.) newton@csvax.caltech.edu {ucbvax!cithep,amdahl}!cit-vax!newton Caltech 256-80 818-356-6771 (afternoons,nights) Pasadena CA 91125 Beach Bums Anonymous, Pasadena President Life's a beach. Then you graduate. ;;; This is PART of the file kcl-patches.lsp from PCL, (c) Xerox.... (in-package 'system) ;;; ;;; setf patches ;;; (defun get-setf-method (form) (multiple-value-bind (vars vals stores store-form access-form) (get-setf-method-multiple-value form) (unless (listp vars) (error "The temporary variables component, ~s, of the setf-method for ~s is not a list." vars form)) (unless (listp vals) (error "The values forms component, ~s, of the setf-method for ~s is not a list." vals form)) (unless (listp stores) (error "The store variables component, ~s, of the setf-method for ~s is not a list." stores form)) (unless (= (list-length stores) 1) (error "Multiple store-variables are not allowed.")) (values vars vals stores store-form access-form))) (defun get-setf-method-multiple-value (form) (cond ((symbolp form) (let ((store (gensym))) (values nil nil (list store) `(setq ,form ,store) form))) ((or (not (consp form)) (not (symbolp (car form)))) (error "Cannot get the setf-method of ~S." form)) ((get (car form) 'setf-method) (apply (get (car form) 'setf-method) (cdr form))) ((get (car form) 'setf-update-fn) (let ((vars (mapcar #'(lambda (x) (declare (ignore x)) (gensym)) (cdr form))) (store (gensym))) (values vars (cdr form) (list store) `(,(get (car form) 'setf-update-fn) ,@vars ,store) (cons (car form) vars)))) ((get (car form) 'setf-lambda) (let* ((vars (mapcar #'(lambda (x) (declare (ignore x)) (gensym)) (cdr form))) (store (gensym)) (l (get (car form) 'setf-lambda)) (f `(lambda ,(car l) (funcall #'(lambda ,(cadr l) ,@(cddr l)) ',store)))) (values vars (cdr form) (list store) (apply f vars) (cons (car form) vars)))) ((macro-function (car form)) (get-setf-method-multiple-value (macroexpand-1 form))) (t (error "Cannot expand the SETF form ~S." form)))) ;;; from PCL file std-class.lsp, (c) Xerox.... (defstruct (class-precedence-description (:conc-name nil) (:constructor make-cpd ())) (cpd-class nil) (cpd-supers ()) (cpd-after ()) (cpd-count 0)) (defun compute-std-cpl-phase-2 (all-cpds) (dolist (cpd all-cpds) (let ((supers (cpd-supers cpd))) (when supers (incf (cpd-count (car supers)) 1))))) Received: from Sail.Stanford.EDU by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA21771; Wed, 14 Jun 89 01:05:16 -0700 Received: from lucid.com by SAIL.Stanford.EDU with TCP; 14 Jun 89 01:05:43 PDT Received: from bhopal ([192.43.178.13]) by heavens-gate id AA09613g; Wed, 14 Jun 89 01:03:50 PDT Received: by bhopal id AA17033g; Wed, 14 Jun 89 01:06:07 PDT Date: Wed, 14 Jun 89 01:06:07 PDT From: Jon L White Message-Id: <8906140806.AA17033@bhopal> To: Moon@STONY-BROOK.SCRC.Symbolics.COM Cc: common-lisp-object-system@sail.stanford.edu, Gray@dsg.csc.ti.com Subject: FLAVOR-CLASS, and Random metaclasses for CL types I don't think we ever came to any resolution about your original query of Date: Wed, 10 May 89 13:31 EDT -- namely how to rewrite the paragraph on page 1-15 of 88-002R which spells out how the "holy" types can be implemented. However, I remember it being sparked by a desire to assure that flavors-implemented types could be used as the underlying implementation of some of the "holy" types; and this led to the discussion of how such a class might relate to BUILT-IN-CLASS. But I see that several vendors are planning to offer a FLAVOR-CLASS as a tie-in with their native (or optional) flavors products (and Gregor mentioned he is working on a similar "hook" for PCL too). That is, a meta-class somewhat like STRUCTURE-CLASS that ensures that flavor types (which are integrated with CL types in those products) also have appropriately named CLOS classes behind them so that they can be specialized upon. Why not mention this directly in the standard? either as one possibility for implementation of the "holy" types, or simply as an example of an implementation-specific meta-class being used to supply one of the "holy" types. I don't think it would be necessary to "flesh out" FLAVOR-CLASS anymore than STRUCTURE-CLASS is currently specified. FLAVOR-CLASS indeed has a good deal to recommend it, in an implementation that supports flavors -- much more than, say, BUILT-IN-CLASS (see my previous critique of the inutility of making a class for the random, small collection of "left over" CL types). Don't you think a short statement like the above would give the kind of assurance you wanted for Symbolic's implementation of pathnames? -- JonL -- Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA21921; Wed, 14 Jun 89 01:22:39 -0700 Received: from Cabernet.ms by ArpaGateway.ms ; 14 JUN 89 00:23:48 PDT Return-Path: <@CORNELLC.cit.cornell.edu:coulman@SKSON1.USask.CA> Redistributed: CommonLoops.PA Received: from CORNELLC.cit.cornell.edu ([128.253.1.19]) by Xerox.COM ; 14 JUN 89 00:22:10 PDT Received: from SASK.USask.CA by CORNELLC.cit.cornell.edu (IBM VM SMTP R1.2.1MX) with BSMTP id 5181; Wed, 14 Jun 89 03:19:33 EDT Received: from dvinci.USask.ca by SASK.USask.CA; Wed, 14 Jun 89 01:00 CST Received: from skson1.USask.ca by dvinci.USask.ca (3.2/SMI-3.2); Wed, 14 Jun 89 01:01:26 CST id AA06532 for CommonLoops@Xerox.com Received: by skson1.USask.ca (3.2/SMI-3.2) id AA03001; Wed, 14 Jun 89 01:00:29 CST Date: Wed, 14 Jun 89 01:00:29 CST From: coulman%SKSON1.USask.CA@CORNELLC.cit.cornell.edu Subject: Has defgeneric been implemented yet? To: CommonLoops.PA@Xerox.COM Message-Id: <8906140700.AA03001@skson1.USask.ca> I can't seem to find defgeneric. Is it me, or has it not been implemented yet? If not, is there an ETA for it? I am using the 12/7/88 version of PCL. ***************************************************************************** Randy A. Coulman | "I don't know what people are thinking University of Saskatchewan | while they're sayin' my faith's a coulman@skdad.Usask.ca | crutch." -- Shout ***************************************************************************** Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA02855; Wed, 14 Jun 89 16:02:41 -0700 Received: from Semillon.ms by ArpaGateway.ms ; 14 JUN 89 16:03:15 PDT Return-Path: <@lll-winken.uucp,@uunet.uucp,@prlb2.uucp,@prlhp1.uucp:gupta@prlhp1.uucp> Redistributed: CommonLoops.pa Received: from arisia.Xerox.COM ([13.1.100.206]) by Xerox.COM ; 14 JUN 89 15:59:31 PDT Received: from lll-winken.UUCP by arisia.Xerox.COM with UUCP (5.61+/IDA-1.2.8/gandalf) id AA02788; Wed, 14 Jun 89 15:57:07 -0700 Received: by lll-winken.llnl.gov (smail2.5) id AA00639; 14 Jun 89 09:25:22 PDT (Wed) Received: from prlb2.UUCP by uunet.uu.net (5.61/1.14) with UUCP id AA20736; Wed, 14 Jun 89 11:17:41 -0400 Received: by prlb2.UUCP (4.12/4.7) id AA23139; Wed, 14 Jun 89 16:50:07 +0100 Received: from apollo06.prl.philips.co.uk by prlhp1.prl.philips.co.uk; Wed, 14 Jun 89 15:25:51 bst From: Ashok Gupta Date: Wed, 14 Jun 89 15:22:39 bst Message-Id: <239.8906141522@apollo06.prl.philips.co.uk> To: CommonLoops.pa@Xerox.COM Subject: Cant compile high.lisp Hi, Recently a *kind* gent mailed pearl-harbour pcl, *pcl-system-date* "12/7/88 Can't think of a cute name PCL", to me. I loaded defsys.lisp in a virgin image and eval'd (pcl::compile-pcl). Most of the files were compiled and loaded successfully, though with many warnings of the kind :- ;;; Warning: Redefining macro %LOGAND which used to be defined in file low.lisp and other macro redefinitions ..... ;;; Warning: Redefining function PRINT-IWMC-CLASS which used to be defined in file low.lisp and other function definitions ..... ;;; Warning: Variable I is bound but its value is ignored. and others ...... ;;; Warning: The following functions are not known to be defined: loads of fn. names .... ;;; Warning: Misplaced declaration: (IGNORE DEPTH) ;;; Warning: Assuming LAMBDA-LIST-KEYWORDS is special until it came to compile high.lisp. The following is an edited transcript. Compiling HIGH... ;;; Reading input file #P"~lisp/ph-pcl/high.lisp" ;;; Compiling toplevel form...assembling...emitting...done. . . . ;;; Compiling function DESCRIBE-INSTANCE... ;;; Warning: Invalid form # in function lambda list ; <-------- #!@%? >>Interrupt: access violation (OS/fault handler) ; <-------- Say what ! Er ? LUCID:COMPILE-FORM: :A Abort to Lisp Top Level :C Resume Interrupted Instruction -> :b ; backtrace LUCID:COMPILE-FORM <- LUCID:COMPILE-FORM <- COMPILE-FILE <- LET <- IF <- PROGN <- BLOCK <- COMPILE-MODULE <- IF <- ECASE <- LET <- PROGN <- PROGN <- TAGBODY <- BLOCK <- PROGN <- LABELS <- LET <- PROGN <- LET <- BLOCK <- OPERATE-ON-SYSTEM <- RETURN-FROM <- IF <- PROGN <- BLOCK <- BLOCK <- COMPILE-PCL <- EVAL <- unnamed function -> :v ; show all args. LUCID:COMPILE-FORM: Local 0: (SYSTEM:DEFINE (QUOTE DESCRIBE-INSTANCE) (QUOTE FUNCTION) (FUNCTION (LAMBDA # #))) Local 1: LUCID::TOPLEVEL Local 2: # Local 3: (# # #) Local 4: 1 Local 5: # Local 6: # Local 7: 13048348 Local 8: # Local 9: 13048339 Local 10: (SYSTEM:DEFINE (QUOTE DESCRIBE-INSTANCE) (QUOTE FUNCTION) (FUNCTION (LAMBDA # #))) Local 11: # Local 12: 2 Local 13: 13048329 Local 14: LUCID::*WARNED-FUNCTIONS* Local 15: NIL Local 16: LUCID::*DEFERRING-INTERRUPTS* Local 17: NIL Local 18: SYSTEM:DEFINE Local 19: NIL Local 20: DESCRIBE-INSTANCE Local 21: FUNCTION Local 22: (LAMBDA (OBJECT &OPTIONAL (STREAM T)) (BLOCK DESCRIBE-INSTANCE (LET* # # # # # # # # #))) Local 23: # Local 24: 2 Local 25: 13048323 Local 26: LUCID::*ORIGINAL-VNAMES* Local 27: NIL Local 28: LUCID::*FUNCTION-NAME-PRINTED* Local 29: NIL Local 30: DESCRIBE-INSTANCE Local 31: # Local 32: 1 plus 3 more locals (max = 35, use :L to see one, :V 35 to see all.) -> :L Name or number of variable: 33 13048311 -> :L 34 LUCID::*CURRENT-FUNCTION* -> :L 35 NIL Apologies for the length of this note. *Any* clues would be *appreciated*. Thanks, Ashok "Ash" Gupta Post : Philips Research Labs, Crossoak Lane, Redhill, Surrey, RH1 5HA, U.K. Voice : +44 293 785544 ext 217 email : gupta@prl.philips.co.uk Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA04051; Wed, 14 Jun 89 17:18:04 -0700 Received: from Semillon.ms by ArpaGateway.ms ; 14 JUN 89 17:06:23 PDT Return-Path: Redistributed: commonloops.PA Received: from unixb.CTC.FMC.COM ([192.5.202.40]) by Xerox.COM ; 14 JUN 89 17:03:29 PDT Received: by unixb.CTC.FMC.COM (1.2/Ultrix2.0-B) id AA01298; Wed, 14 Jun 89 17:04:11 pdt From: rajd@unixb.ctc.fmc.com (Rajendra Dodhiawala) Message-Id: <8906150004.AA01298@unixb.CTC.FMC.COM> Date: 14 Jun 89 17:04:08 PDT (Wed) To: commonloops.PA@Xerox.COM Cc: rajd@unixb.ctc.fmc.com Subject: Supported CLOS Hi! We are interested in knowing if there is such a thing as a supported version of CLOS. We would like to use CLOS for a few applications, but our customers desire all "layers" be supported. I believe that some Lisp vendors have started shipping their version of CLOS along with their Lisps; does this imply they support it also. Any pointers on this will be appreciated. Thanx in advance. - rajendra FMC Corporate Technology Center 1205 Coleman Ave Santa Clara, CA 95052 (408) 289-3303 ARPAnet: rajd@cel.fmc.com Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA04062; Wed, 14 Jun 89 17:19:23 -0700 Received: from Semillon.ms by ArpaGateway.ms ; 14 JUN 89 17:13:38 PDT Date: Wed, 14 Jun 89 17:10 PDT From: Gregor.pa@Xerox.COM Subject: Re: Has defgeneric been implemented yet? To: coulman%SKSON1.USask.CA@CORNELLC.cit.cornell.edu Cc: CommonLoops.PA@Xerox.COM Fcc: BD:>Gregor>mail>outgoing-mail-7.text.newest In-Reply-To: <8906140700.AA03001@skson1.USask.ca> Message-Id: <19890615001027.6.GREGOR@SPIFF.parc.xerox.com> Line-Fold: no Date: Wed, 14 Jun 89 01:00:29 CST From: coulman%SKSON1.USask.CA@CORNELLC.cit.cornell.edu I can't seem to find defgeneric. Is it me, or has it not been implemented yet? If not, is there an ETA for it? I am using the 12/7/88 version of PCL. In the release you have, DEFGENERIC is not implemented. In Victoria Day PCL, there is a version of DEFGENERIC which basically does nothing. In the version of PCL running on my desk, there is a version of DEFGENERIC which can be used to specify the method combination type and the argument precedence order (yes, method combination and argument precedence order have been implemented). Once some more of the bugs get out, this will be released. Hopefully this will happen sometime early next week, but these are pretty big changes to PCL. ------- Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA22402; Thu, 15 Jun 89 09:54:04 -0700 Received: from Semillon.ms by ArpaGateway.ms ; 15 JUN 89 09:52:37 PDT Return-Path: Redistributed: commonloops.pa Received: from ti.com ([128.247.159.141]) by Xerox.COM ; 15 JUN 89 09:49:43 PDT Received: by ti.com id AA01416; Thu, 15 Jun 89 11:35:49 CDT Received: from dsg by tilde id AA03942; Thu, 15 Jun 89 11:23:04 CDT Received: From Sierra By dsg Via CHAOS-NET With CHAOS-MAIL; Thu, 15 Jun 89 11:20:10 CDT Message-Id: <2822919524-13850389@Sierra> Sender: KK@sierra.csc.ti.com Date: Thu, 15 Jun 89 11:18:44 CDT From: Kerry Kimbrough To: rajd@unixb.ctc.fmc.com (Rajendra Dodhiawala) Cc: commonloops.PA@Xerox.COM Subject: Re: Supported CLOS In-Reply-To: Msg of 14 Jun 89 17:04:08 PDT (Wed) from rajd@unixb.ctc.fmc.com (Rajendra Dodhiawala) > We are interested in knowing if there is such a thing as a supported > version of CLOS. There is, and it is called TI Explorer CLOS. This will be a key part of Release 6.0 for Explorer and microExplorer system software. Coming soon to Explorer customers and TI dealers near you. See it at AAAI. Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA23211; Thu, 15 Jun 89 10:58:16 -0700 Received: from Semillon.ms by ArpaGateway.ms ; 15 JUN 89 10:58:44 PDT Return-Path: Redistributed: commonloops.PA Received: from SAIL.Stanford.EDU ([36.86.0.194]) by Xerox.COM ; 15 JUN 89 10:56:00 PDT Message-Id: <11nYV4@SAIL.Stanford.EDU> Date: 15 Jun 89 10:55 PDT From: Dick Gabriel Subject: re: Supported CLOS To: Kimbrough@dsg.csc.ti.com, rajd@UNIXB.CTC.FMC.COM Cc: commonloops.PA@Xerox.COM [In reply to message from Kimbrough@dsg.csc.ti.com sent Thu, 15 Jun 89 11:18:44 CDT.] > We are interested in knowing if there is such a thing as a supported > version of CLOS. Hey, it's been years since I've engaged in crass commercialism. I'm a little rusty, so I'll take my inspiration from Kimbrough: There is, and it is called Lucid CLOS. This will be a key part of Release 4.0 for SUN, HP/Apollo, IBM, DEC, and everything else. Coming soon to SUN, HP/Apollo, IBM - heck there're too many to name - customers. See it at IJCAI. -rpg- Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA29145; Thu, 15 Jun 89 17:47:46 -0700 Received: from Salvador.ms by ArpaGateway.ms ; 15 JUN 89 17:41:00 PDT Return-Path: Redistributed: commonloops.pa Received: from eden.Berkeley.EDU ([128.32.149.9]) by Xerox.COM ; 15 JUN 89 17:37:53 PDT Received: by eden.Berkeley.EDU (5.61/1.29) id AA01410; Thu, 15 Jun 89 17:37:52 -0700 Date: Thu, 15 Jun 89 17:37:52 -0700 From: konstan@postgres.Berkeley.EDU (Joe Konstan) Message-Id: <8906160037.AA01410@eden.Berkeley.EDU> To: commonloops.pa@Xerox.COM Subject: Method Compilation Question I need to be able to compile methods which are being defined at run-time. So far I haven't been able to figure out which pcl functions are used to invoke the compiler, or which compiler hooks are being invoked. In the 12/7/88 pcl the function compile-method seems to never be called. I've tried comp::compile-process-form (on EXCL) and that accepts a defmethod but doesn't actually compile it (at least as far as PCL is concerned). What is the easiest way to accompish this (ideally, I'd like to pass the defmethod off to a magic function which does it) short of writing the defmethod to a file and compiling and loading it? Joe Konstan konstan@postgres.berkeley.edu Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA22402; Thu, 15 Jun 89 09:54:04 -0700 Received: from Semillon.ms by ArpaGateway.ms ; 15 JUN 89 09:52:37 PDT Return-Path: Redistributed: commonloops.pa Received: from ti.com ([128.247.159.141]) by Xerox.COM ; 15 JUN 89 09:49:43 PDT Received: by ti.com id AA01416; Thu, 15 Jun 89 11:35:49 CDT Received: from dsg by tilde id AA03942; Thu, 15 Jun 89 11:23:04 CDT Received: From Sierra By dsg Via CHAOS-NET With CHAOS-MAIL; Thu, 15 Jun 89 11:20:10 CDT Message-Id: <2822919524-13850389@Sierra> Sender: KK@sierra.csc.ti.com Date: Thu, 15 Jun 89 11:18:44 CDT From: Kerry Kimbrough To: rajd@unixb.ctc.fmc.com (Rajendra Dodhiawala) Cc: commonloops.PA@Xerox.COM Subject: Re: Supported CLOS In-Reply-To: Msg of 14 Jun 89 17:04:08 PDT (Wed) from rajd@unixb.ctc.fmc.com (Rajendra Dodhiawala) > We are interested in knowing if there is such a thing as a supported > version of CLOS. There is, and it is called TI Explorer CLOS. This will be a key part of Release 6.0 for Explorer and microExplorer system software. Coming soon to Explorer customers and TI dealers near you. See it at AAAI. Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA22402; Thu, 15 Jun 89 09:54:04 -0700 Received: from Semillon.ms by ArpaGateway.ms ; 15 JUN 89 09:52:37 PDT Return-Path: Redistributed: commonloops.pa Received: from ti.com ([128.247.159.141]) by Xerox.COM ; 15 JUN 89 09:49:43 PDT Received: by ti.com id AA01416; Thu, 15 Jun 89 11:35:49 CDT Received: from dsg by tilde id AA03942; Thu, 15 Jun 89 11:23:04 CDT Received: From Sierra By dsg Via CHAOS-NET With CHAOS-MAIL; Thu, 15 Jun 89 11:20:10 CDT Message-Id: <2822919524-13850389@Sierra> Sender: KK@sierra.csc.ti.com Date: Thu, 15 Jun 89 11:18:44 CDT From: Kerry Kimbrough To: rajd@unixb.ctc.fmc.com (Rajendra Dodhiawala) Cc: commonloops.PA@Xerox.COM Subject: Re: Supported CLOS In-Reply-To: Msg of 14 Jun 89 17:04:08 PDT (Wed) from rajd@unixb.ctc.fmc.com (Rajendra Dodhiawala) > We are interested in knowing if there is such a thing as a supported > version of CLOS. There is, and it is called TI Explorer CLOS. This will be a key part of Release 6.0 for Explorer and microExplorer system software. Coming soon to Explorer customers and TI dealers near you. See it at AAAI. Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA22402; Thu, 15 Jun 89 09:54:04 -0700 Received: from Semillon.ms by ArpaGateway.ms ; 15 JUN 89 09:52:37 PDT Return-Path: Redistributed: commonloops.pa Received: from ti.com ([128.247.159.141]) by Xerox.COM ; 15 JUN 89 09:49:43 PDT Received: by ti.com id AA01416; Thu, 15 Jun 89 11:35:49 CDT Received: from dsg by tilde id AA03942; Thu, 15 Jun 89 11:23:04 CDT Received: From Sierra By dsg Via CHAOS-NET With CHAOS-MAIL; Thu, 15 Jun 89 11:20:10 CDT Message-Id: <2822919524-13850389@Sierra> Sender: KK@sierra.csc.ti.com Date: Thu, 15 Jun 89 11:18:44 CDT From: Kerry Kimbrough To: rajd@unixb.ctc.fmc.com (Rajendra Dodhiawala) Cc: commonloops.PA@Xerox.COM Subject: Re: Supported CLOS In-Reply-To: Msg of 14 Jun 89 17:04:08 PDT (Wed) from rajd@unixb.ctc.fmc.com (Rajendra Dodhiawala) > We are interested in knowing if there is such a thing as a supported > version of CLOS. There is, and it is called TI Explorer CLOS. This will be a key part of Release 6.0 for Explorer and microExplorer system software. Coming soon to Explorer customers and TI dealers near you. See it at AAAI. Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA22402; Thu, 15 Jun 89 09:54:04 -0700 Received: from Semillon.ms by ArpaGateway.ms ; 15 JUN 89 09:52:37 PDT Return-Path: Redistributed: commonloops.pa Received: from ti.com ([128.247.159.141]) by Xerox.COM ; 15 JUN 89 09:49:43 PDT Received: by ti.com id AA01416; Thu, 15 Jun 89 11:35:49 CDT Received: from dsg by tilde id AA03942; Thu, 15 Jun 89 11:23:04 CDT Received: From Sierra By dsg Via CHAOS-NET With CHAOS-MAIL; Thu, 15 Jun 89 11:20:10 CDT Message-Id: <2822919524-13850389@Sierra> Sender: KK@sierra.csc.ti.com Date: Thu, 15 Jun 89 11:18:44 CDT From: Kerry Kimbrough To: rajd@unixb.ctc.fmc.com (Rajendra Dodhiawala) Cc: commonloops.PA@Xerox.COM Subject: Re: Supported CLOS In-Reply-To: Msg of 14 Jun 89 17:04:08 PDT (Wed) from rajd@unixb.ctc.fmc.com (Rajendra Dodhiawala) > We are interested in knowing if there is such a thing as a supported > version of CLOS. There is, and it is called TI Explorer CLOS. This will be a key part of Release 6.0 for Explorer and microExplorer system software. Coming soon to Explorer customers and TI dealers near you. See it at AAAI. Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA13763; Fri, 16 Jun 89 10:32:55 -0700 Received: from Burger.ms by ArpaGateway.ms ; 16 JUN 89 08:34:32 PDT Return-Path: Redistributed: commonloops.pa Received: from ads.com ([128.229.30.16]) by Xerox.COM ; 16 JUN 89 08:32:45 PDT Received: by ads.com (5.59/1.19) id AA05491; Fri, 16 Jun 89 07:56:49 PDT Date: Fri, 16 Jun 89 07:56:49 PDT From: Chris McConnell Message-Id: <8906161456.AA05491@ads.com> To: konstan@postgres.Berkeley.EDU Cc: commonloops.pa@Xerox.COM In-Reply-To: Joe Konstan's message of Thu, 15 Jun 89 17:37:52 -0700 <8906160037.AA01410@eden.Berkeley.EDU> Subject: Method Compilation Question Here is a function that I have used to compile methods. ;;; (in-package 'pcl) (export '(compile-methods)) ;;; (defun COMPILE-METHODS (generic-function) "Make sure that methods of GENERIC-FUNCTION are compiled." (dolist (method (generic-function-methods generic-function)) (unless (compiled-function-p (method-function method)) (setf (method-function method) (compile nil (method-function method)))))) Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA13799; Fri, 16 Jun 89 10:34:57 -0700 Received: from Semillon.ms by ArpaGateway.ms ; 16 JUN 89 10:12:19 PDT Return-Path: Redistributed: commonloops.pa Received: from VAX.BBN.COM ([128.89.0.91]) by Xerox.COM ; 16 JUN 89 10:08:12 PDT Received: by VAX.BBN.COM id aa15132; 16 Jun 89 12:57 EDT To: commonloops.pa@Xerox.COM Subject: PCL Bug?? Date: Fri, 16 Jun 89 12:52:18 -0400 From: Mike Thome Message-Id: <890616-101219-8377@Xerox> We've been having a strange problem with Victoria day PCL on occasion (under Genera, both 7.2 and 7.4): The direct symptom is that one of the cache entries in pcl:*free-generic-function-caches* becomes an integer instead of a cache (array) or nil. This leads me to believe that either a cache is getting freed incorrectly (i.e someone is setting the cache lock counter of a cache on the freelist) or we've got Yet Another Multi-Process related bug. Other clues: doing some tracing and such makes it appear that this happens about the same time that the last pre-allocated cache is used. I've looked at the caching/locking/freeing code and, well, I see nothing obviously wrong with any of it... Help? -mike (mthome@bbn.com) Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA14996; Fri, 16 Jun 89 12:18:52 -0700 Received: from Semillon.ms by ArpaGateway.ms ; 16 JUN 89 11:36:17 PDT Return-Path: Redistributed: commonloops.PA Received: from Princeton.EDU ([128.112.0.1]) by Xerox.COM ; 16 JUN 89 11:32:27 PDT Received: from winnie.Princeton.EDU by Princeton.EDU (5.58+++/2.17) id AA06656; Fri, 16 Jun 89 14:30:47 EDT Received: by winnie (4.12/1.81) id AA02645; Fri, 16 Jun 89 14:29:18 edt Date: Fri, 16 Jun 89 14:29:18 edt From: eliot@winnie.Princeton.EDU (eliot handelman) Message-Id: <8906161829.AA02645@winnie> To: Kimbrough@dsg.csc.ti.com, rajd@unixb.ctc.fmc.com Subject: Re: Supported CLOS Cc: commonloops.PA@Xerox.COM Ok, I've now got 6 copies of TI's ad. I got the idea. Received: from Sail.Stanford.EDU by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA17715; Fri, 16 Jun 89 15:59:24 -0700 Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 16 Jun 89 15:54:29 PDT Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 612340; 16 Jun 89 18:56:02 EDT Date: Fri, 16 Jun 89 18:56 EDT From: David A. Moon Subject: issue COMPILE-ENVIRONMENT-CONSISTENCY, version 6 To: cl-compiler@sail.stanford.edu, Common-Lisp-Object-System@sail.stanford.edu In-Reply-To: <8906151608.AA23867@defun.utah.edu> Message-Id: <19890616225632.4.MOON@EUPHRATES.SCRC.Symbolics.COM> This is okay (either proposal). I believe there is no harm in requiring conforming programs to obey the DEFCLASS restriction for now, so I don't see the advantage to BOBS-AMENDMENT, even though in the future metaclasses might change this. Received: from Sail.Stanford.EDU by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA18009; Fri, 16 Jun 89 16:35:12 -0700 Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 16 Jun 89 16:35:43 PDT Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 612385; 16 Jun 89 19:37:01 EDT Date: Fri, 16 Jun 89 19:37 EDT From: David A. Moon Subject: FLAVOR-CLASS, and Random metaclasses for CL types To: Jon L White Cc: common-lisp-object-system@sail.stanford.edu, Gray@dsg.csc.ti.com In-Reply-To: <8906140806.AA17033@bhopal> Message-Id: <19890616233725.8.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Wed, 14 Jun 89 01:06:07 PDT From: Jon L White I don't think we ever came to any resolution about your original query of Date: Wed, 10 May 89 13:31 EDT -- namely how to rewrite the paragraph on page 1-15 of 88-002R which spells out how the "holy" types can be implemented. I'm not sure. I have 20 messages saved on the topic and don't have time to review them right now. But I see that several vendors are planning to offer a FLAVOR-CLASS as a tie-in with their native (or optional) flavors products (and Gregor mentioned he is working on a similar "hook" for PCL too). That is, a meta-class somewhat like STRUCTURE-CLASS that ensures that flavor types (which are integrated with CL types in those products) also have appropriately named CLOS classes behind them so that they can be specialized upon. Why not mention this directly in the standard? I don't think it's at all appropriate to include the name FLAVOR-CLASS in the standard. What I do want to do to the standard is to make sure that it doesn't accidentally contain language that would make it impossible for an implementation to add FLAVOR-CLASS, OBJECT-LISP-CLASS, PCL-CLASS, or any of several others. I think this should be easy to do. Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA13799; Fri, 16 Jun 89 10:34:57 -0700 Received: from Semillon.ms by ArpaGateway.ms ; 16 JUN 89 10:12:19 PDT Return-Path: Redistributed: commonloops.pa Received: from VAX.BBN.COM ([128.89.0.91]) by Xerox.COM ; 16 JUN 89 10:08:12 PDT Received: by VAX.BBN.COM id aa15132; 16 Jun 89 12:57 EDT To: commonloops.pa@Xerox.COM Subject: PCL Bug?? Date: Fri, 16 Jun 89 12:52:18 -0400 From: Mike Thome Message-Id: <890616-101219-8377@Xerox> We've been having a strange problem with Victoria day PCL on occasion (under Genera, both 7.2 and 7.4): The direct symptom is that one of the cache entries in pcl:*free-generic-function-caches* becomes an integer instead of a cache (array) or nil. This leads me to believe that either a cache is getting freed incorrectly (i.e someone is setting the cache lock counter of a cache on the freelist) or we've got Yet Another Multi-Process related bug. Other clues: doing some tracing and such makes it appear that this happens about the same time that the last pre-allocated cache is used. I've looked at the caching/locking/freeing code and, well, I see nothing obviously wrong with any of it... Help? -mike (mthome@bbn.com) Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA02435; Sat, 17 Jun 89 18:22:02 -0700 Received: from Semillon.ms by ArpaGateway.ms ; 17 JUN 89 18:23:33 PDT Return-Path: Redistributed: commonloops.PA Received: from labrea.stanford.edu ([36.8.0.47]) by Xerox.COM ; 17 JUN 89 18:21:49 PDT Received: by labrea.stanford.edu; Sat, 17 Jun 89 18:20:56 PDT Received: by ibuki.UUCP (5.52/4.7) id AA16974; Fri, 16 Jun 89 10:04:43 PDT Date: Fri, 16 Jun 89 10:04:43 PDT From: rww%ibuki.uucp@labrea.stanford.edu (Richard Weyhrauch) Message-Id: <8906161704.AA16974@ibuki.UUCP> To: commonloops.PA@Xerox.COM, rajd@unixb.ctc.fmc.com Subject: Re: Supported CLOS Cc: rajd@unixb.ctc.fmc.com IBUKI Common Lisp will support CLOS on the following machines: Amdahl, Apollo 3xxx, 4xxx, 10xxx, AT&T 3b's, DEC Station 3100 and all VAX -- Ultrix, UNIX, VMS (where apprepriate), Encore, HP 300's. HP 800's, IBM RT, PS/2, 370, MIPS, Sequent Balance, Symmetry, SGI Iris, 4D, Sony News, SUN 386i, 2, 3, 4, 386 UNIx, ... and many more. Come see it at IJCAI Richard Weyhrauch Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA02435; Sat, 17 Jun 89 18:22:02 -0700 Received: from Semillon.ms by ArpaGateway.ms ; 17 JUN 89 18:23:33 PDT Return-Path: Redistributed: commonloops.PA Received: from labrea.stanford.edu ([36.8.0.47]) by Xerox.COM ; 17 JUN 89 18:21:49 PDT Received: by labrea.stanford.edu; Sat, 17 Jun 89 18:20:56 PDT Received: by ibuki.UUCP (5.52/4.7) id AA16974; Fri, 16 Jun 89 10:04:43 PDT Date: Fri, 16 Jun 89 10:04:43 PDT From: rww%ibuki.uucp@labrea.stanford.edu (Richard Weyhrauch) Message-Id: <8906161704.AA16974@ibuki.UUCP> To: commonloops.PA@Xerox.COM, rajd@unixb.ctc.fmc.com Subject: Re: Supported CLOS Cc: rajd@unixb.ctc.fmc.com IBUKI Common Lisp will support CLOS on the following machines: Amdahl, Apollo 3xxx, 4xxx, 10xxx, AT&T 3b's, DEC Station 3100 and all VAX -- Ultrix, UNIX, VMS (where apprepriate), Encore, HP 300's. HP 800's, IBM RT, PS/2, 370, MIPS, Sequent Balance, Symmetry, SGI Iris, 4D, Sony News, SUN 386i, 2, 3, 4, 386 UNIx, ... and many more. Come see it at IJCAI Richard Weyhrauch Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA08122; Sun, 18 Jun 89 12:44:00 -0700 Received: from Semillon.ms by ArpaGateway.ms ; 18 JUN 89 12:44:45 PDT Date: Sun, 18 Jun 89 12:43 PDT From: Gregor.pa@Xerox.COM Subject: Re: Supported CLOS To: commonloops.PA@Xerox.COM Fcc: BD:>Gregor>mail>outgoing-mail-7.text.newest Message-Id: <19890618194306.4.GREGOR@SPIFF.parc.xerox.com> Line-Fold: no OK folks, please stop this now. ------- Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA08122; Sun, 18 Jun 89 12:44:00 -0700 Received: from Semillon.ms by ArpaGateway.ms ; 18 JUN 89 12:44:45 PDT Date: Sun, 18 Jun 89 12:43 PDT From: Gregor.pa@Xerox.COM Subject: Re: Supported CLOS To: commonloops.PA@Xerox.COM Fcc: BD:>Gregor>mail>outgoing-mail-7.text.newest Message-Id: <19890618194306.4.GREGOR@SPIFF.parc.xerox.com> Line-Fold: no OK folks, please stop this now. ------- Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA00408; Mon, 19 Jun 89 07:51:01 -0700 Received: from Burger.ms by ArpaGateway.ms ; 19 JUN 89 06:07:05 PDT Return-Path: Redistributed: CommonLoops.PA Received: from uunet.uu.net ([192.48.96.2]) by Xerox.COM ; 19 JUN 89 06:05:18 PDT Received: from ukc.UUCP by uunet.uu.net (5.61/1.14) with UUCP id AA29972; Mon, 19 Jun 89 09:05:08 -0400 Received: from cl.cam.ac.uk by kestrel.Ukc.AC.UK via Janet (UKC CAMEL FTP) id aa01357; 19 Jun 89 13:50 BST Via: uk.co.harlqn; 19 Jun 89 13:47 BST (UK.AC.Cam.Cl.scaup) Received: from jung.harlqn.co.uk (jung) by harlqn.harlqn.co.uk; Mon, 19 Jun 89 12:29:45 BST From: Zany Cornetto Date: Mon, 19 Jun 89 12:30:17 BST Message-Id: <12099.8906191130@jung.harlqn.co.uk> To: Rajendra Dodhiawala Cc: CommonLoops.PA@Xerox.COM In-Reply-To: rajd@unixb.ctc.fmc.com's message of 15 Jun 89 00:04:08 GMT Subject: Supported CLOS Harlequin's LispWorks - a Common Lisp implementation and programming environment - includes an implementation of CLOS which is fully supported. For more information please contact lispworks-request@harlqn.co.uk. See us at IJCAI too! chris richardson ---------------- chris@harlqn.co.uk, ..!uunet!mcvax!harlqn.co.uk!chris Harlequin Ltd, Barrington Hall, Barrington, Cambridge, CB2 5RG, England. Phone: 0223 872522 (National), +44-223-872522 (International). Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA01499; Mon, 19 Jun 89 09:00:26 -0700 Received: from Chardonnay.ms by ArpaGateway.ms ; 19 JUN 89 08:55:41 PDT Return-Path: Redistributed: commonloops.pa Received: from ti.com ([128.247.159.141]) by Xerox.COM ; 19 JUN 89 08:50:46 PDT Received: by ti.com id AA04872; Mon, 19 Jun 89 10:51:06 CDT Received: from dsg by tilde id AA17791; Mon, 19 Jun 89 10:24:20 CDT Received: From Sierra By dsg Via CHAOS-NET With CHAOS-MAIL; Mon, 19 Jun 89 10:13:34 CDT Message-Id: <2823261130-1344472@Sierra> Sender: KK@sierra.csc.ti.com Date: Mon, 19 Jun 89 10:12:10 CDT From: Kerry Kimbrough To: Gregor.pa@Xerox.COM Cc: commonloops.PA@Xerox.COM Subject: Re: Supported CLOS In-Reply-To: Msg of Sun, 18 Jun 89 12:43 PDT from Gregor.pa@Xerox.COM Gregor, if you're referring to multiple copies of our replies, let me assure you that this is *not* intentional. I have sent one message only, but there is a net echo somewhere that's pelting us with copies of several messages. Received: from Sail.Stanford.EDU by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA02723; Mon, 19 Jun 89 09:57:45 -0700 Received: from lucid.com by SAIL.Stanford.EDU with TCP; 19 Jun 89 09:56:51 PDT Received: from bhopal ([192.43.178.13]) by heavens-gate id AA20643g; Mon, 19 Jun 89 09:54:16 PDT Received: by bhopal id AA00425g; Mon, 19 Jun 89 09:56:07 PDT Date: Mon, 19 Jun 89 09:56:07 PDT From: Jon L White Message-Id: <8906191656.AA00425@bhopal> To: Moon@STONY-BROOK.SCRC.Symbolics.COM Cc: common-lisp-object-system@sail.stanford.edu, Gray@dsg.csc.ti.com In-Reply-To: David A. Moon's message of Fri, 16 Jun 89 19:37 EDT <19890616233725.8.MOON@EUPHRATES.SCRC.Symbolics.COM> Subject: FLAVOR-CLASS, and Random metaclasses for CL types re: Why not mention this directly in the standard? I don't think it's at all appropriate to include the name FLAVOR-CLASS in the standard. What I do want to do to the standard is to make sure that it doesn't accidentally contain language that would make it impossible for an implementation to add FLAVOR-CLASS, OBJECT-LISP-CLASS, PCL-CLASS, or any of several others. I think this should be easy to do. Uh, wrong referent on the "mention this" -- it wasn't to include FLAVOR-CLASS in the standard. The rest of the paragraph you excerpted was: . . . either as one possibility for implementation of the "holy" types, or simply as an example of an implementation-specific meta-class being used to supply one of the "holy" types. The point is simply that any "implementation-specific meta-class" which preserves the properties of the "holy" types should be satisfactory, regardless of whether it is called a BUILT-IN-CLASS or not. The advantage of using FLAVOR-CLASS as an example is that, like STRUCTURE-CLASS, it is already tied into the type system of those implementations that have it. Thus all that is lacking from CLOS's point of view is a (CLOS) class definition stub, so that such instances may be specialized upon. -- JonL -- Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA06564; Mon, 19 Jun 89 11:37:23 -0700 Received: from Cabernet.ms by ArpaGateway.ms ; 19 JUN 89 11:31:13 PDT Date: 19 Jun 89 11:27 PDT From: kiuchi.pa@Xerox.COM Subject: Mailing-list problem To: CommonLoops.pa@Xerox.COM Cc: kiuchi.pa@Xerox.COM, Gregor.pa@Xerox.COM Message-Id: <890619-113113-12509@Xerox> We have a problem with the one of the mailer and this is causing lots of message duplications to the external distribution of CommonLoops mailing-list. We are currently working on the problem. If you get any further message duplication problem, please send me(Kiuchi.pa@Xerox.com) headers of those messages. Thanks. Yasuhiko Kiuchi (Kiuchi.pa@Xerox.com) ---------- Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA00408; Mon, 19 Jun 89 07:51:01 -0700 Received: from Burger.ms by ArpaGateway.ms ; 19 JUN 89 06:07:05 PDT Return-Path: Redistributed: CommonLoops.PA Received: from uunet.uu.net ([192.48.96.2]) by Xerox.COM ; 19 JUN 89 06:05:18 PDT Received: from ukc.UUCP by uunet.uu.net (5.61/1.14) with UUCP id AA29972; Mon, 19 Jun 89 09:05:08 -0400 Received: from cl.cam.ac.uk by kestrel.Ukc.AC.UK via Janet (UKC CAMEL FTP) id aa01357; 19 Jun 89 13:50 BST Via: uk.co.harlqn; 19 Jun 89 13:47 BST (UK.AC.Cam.Cl.scaup) Received: from jung.harlqn.co.uk (jung) by harlqn.harlqn.co.uk; Mon, 19 Jun 89 12:29:45 BST From: Zany Cornetto Date: Mon, 19 Jun 89 12:30:17 BST Message-Id: <12099.8906191130@jung.harlqn.co.uk> To: Rajendra Dodhiawala Cc: CommonLoops.PA@Xerox.COM In-Reply-To: rajd@unixb.ctc.fmc.com's message of 15 Jun 89 00:04:08 GMT Subject: Supported CLOS Harlequin's LispWorks - a Common Lisp implementation and programming environment - includes an implementation of CLOS which is fully supported. For more information please contact lispworks-request@harlqn.co.uk. See us at IJCAI too! chris richardson ---------------- chris@harlqn.co.uk, ..!uunet!mcvax!harlqn.co.uk!chris Harlequin Ltd, Barrington Hall, Barrington, Cambridge, CB2 5RG, England. Phone: 0223 872522 (National), +44-223-872522 (International). Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA08606; Mon, 19 Jun 89 14:20:44 -0700 Received: from Burger.ms by ArpaGateway.ms ; 19 JUN 89 14:21:22 PDT Return-Path: Redistributed: commonloops.PA Received: from uunet.uu.net ([192.48.96.2]) by Xerox.COM ; 19 JUN 89 14:19:36 PDT Received: by uunet.uu.net (5.61/1.14) with UUCP id AA18357; Mon, 19 Jun 89 17:19:20 -0400 Received: by franz.Franz.COM (MC 2.0/FI-1.0) id AA00705; Mon, 19 Jun 89 13:32:54 PDT Received: by snooze.Franz.COM (4.0/FI-1.0) id AA01179; Mon, 19 Jun 89 13:26:32-080 From: layer@franz.com (Kevin Layer) Message-Id: <8906192126.AA01179@snooze.Franz.COM> To: Kerry Kimbrough Cc: commonloops.PA@Xerox.COM Subject: Re: Supported CLOS In-Reply-To: Your message of Mon, 19 Jun 89 10:12:10 CDT. <2823261130-1344472@Sierra> Date: Mon, 19 Jun 89 13:26:30 -0800 >> Gregor, if you're referring to multiple copies of our replies, let me >> assure you that this is *not* intentional. I have sent one message only, >> but there is a net echo somewhere that's pelting us with copies of several >> messages. I hope he is referring to the crass adverts from several lisp companies. ;-> Kevin Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA10115; Mon, 19 Jun 89 15:36:37 -0700 Received: from Chardonnay.ms by ArpaGateway.ms ; 19 JUN 89 15:37:36 PDT Return-Path: Redistributed: CommonLoops.PA Received: from Moe.McRCIM.McGill.EDU ([132.206.4.1]) by Xerox.COM ; 19 JUN 89 15:33:00 PDT Received: by Moe.McRCIM.McGill.EDU (5.54) id <8906191415.AA17070@Moe.McRCIM.McGill.EDU>; Mon, 19 Jun 89 10:15:36 EDT Date: Mon, 19 Jun 89 10:15:36 EDT From: Martin Boyer Message-Id: <8906191415.AA17070@Moe.McRCIM.McGill.EDU> To: CommonLoops.PA@Xerox.COM Subject: How to add slots to method objects I am trying to add slots to method objects and to generic-function objects using Victoria Day PCL on Lucid 3.0.2. If I understand the 88-00R document correctly (in particular, the DEFGENERIC description and its :method-class option), this could be done by: 1. creating a new class of methods: (defclass action-method (standard-method) ( (type :reader action-type ) ) ) 2. telling PCL that certain methods are instances of action-method: (defgeneric move (object position) (:method-class 'action-method) ) 3. And I could retrieve the slot values using: (defun find-action-type (action qualifiers &rest object-types) (let ((method-used (find-method action qualifiers object-types))) (action-type method-used) ) ) The first one was easy. Unfortunately, DEFGENERIC doesn't yet accept options and FIND-METHOD is not implemented yet. I tried ENSURE-GENERIC-FUNCTION, but it ignores the relevant options. I tried CHANGE-CLASS on a method, but there is no method defined for CHANGE-CLASS on action-method classes. I also looked in the section on Meta-Objects (p. 1-33, 1-34), but chapter 3 is not available yet for non-initiated. It there a solution to this? I am considering modifications to the PCL source to add those slots as part of the STANDARD-METHOD definition but that is an ugly hack. Thanks, Martin -- Martin Boyer McGill Research Centre for Intelligent Machines McGill University, Montreal, QC gamin@larry.mcrcim.mcgill.edu gamin@mcgill-vision.uucp Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA12881; Mon, 19 Jun 89 18:46:09 -0700 Received: from Burger.ms by ArpaGateway.ms ; 19 JUN 89 18:48:13 PDT Return-Path: Redistributed: CommonLoops.PA Received: from Think.COM ([131.239.2.1]) by Xerox.COM ; 19 JUN 89 18:46:32 PDT Return-Path: Received: from sauron.think.com by Think.COM; Mon, 19 Jun 89 20:05:55 EDT Received: by sauron.think.com; Mon, 19 Jun 89 20:04:25 EDT Date: Mon, 19 Jun 89 20:04:25 EDT From: massar@Think.COM Message-Id: <8906200004.AA08772@sauron.think.com> To: lispworks-request@harlequin.co.uk Cc: rajd@unixb.ctc.fmc.com, CommonLoops.PA@Xerox.COM In-Reply-To: Zany Cornetto's message of Mon, 19 Jun 89 12:30:17 BST <12099.8906191130@jung.harlqn.co.uk> Subject: Supported CLOS Please send information about LispWorks. From: Zany Cornetto Date: Mon, 19 Jun 89 12:30:17 BST Harlequin's LispWorks - a Common Lisp implementation and programming environment - includes an implementation of CLOS which is fully supported. For more information please contact lispworks-request@harlqn.co.uk. See us at IJCAI too! chris richardson ---------------- chris@harlqn.co.uk, ..!uunet!mcvax!harlqn.co.uk!chris Harlequin Ltd, Barrington Hall, Barrington, Cambridge, CB2 5RG, England. Phone: 0223 872522 (National), +44-223-872522 (International). Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA03243; Tue, 20 Jun 89 11:14:02 -0700 Received: from Semillon.ms by ArpaGateway.ms ; 20 JUN 89 11:06:16 PDT Return-Path: Redistributed: commonloops.pa Received: from aic.nrl.navy.mil ([192.26.18.49]) by Xerox.COM ; 20 JUN 89 11:02:26 PDT Return-Path: Received: Tue, 20 Jun 89 14:01:16 EDT by aic.nrl.navy.mil id AA22933 Date: Tue, 20 Jun 89 14:01:16 EDT From: Lawrence Hall Message-Id: <8906201801.AA22933@aic.nrl.navy.mil> To: commonloops.pa@Xerox.COM Subject: Problem compiling Victoria Day PCL We have been trying to install Victoria Day Pcl under Lucid Common Lisp 2.1.1. It won't compile. The error and a script are described below. Has anyone else succeeded under this old version of Lucid? Is there a fix? Thanks in advance for any suggestions. --Larry Hall hall@usfvax2.csee.usf.edu The error "undefined function" was found in the file "walk.lisp". After loading this file and compiling I get the error "Package 'lucid-Common-lisp' not found". We continued and finally get this same "undefined function" error again. Also, I printed the search for the missen string flag by the error. Finally, the listing of the /user1/clos/clos directory is printed to this script file. Script started on Mon Jun 19 15:57:32 1989 % lisp ;;; Sun Common Lisp, Development Environment 2.1.1, 21-Mar-89 ;;; ;;; Copyright (c) 1987 by Sun Microsystems, Inc. All Rights Reserved ;;; Copyright (c) 1985, 1986, 1987 by Lucid Inc., All Rights Reserved ;;; ;;; This software product contains confidential and trade secret ;;; information belonging to Sun Microsystems. It may not be copied ;;; for any reason other than for archival and backup purposes. > (load "defsys.lisp") ;;; Loading source file "defsys.lisp" #P"/user1/clos/clos/defsys.lisp" > (pcl::cokm  mi pile-pcl) Loading binary of PKG... Loading binary of WALK... Loading binary of ITERATE... Loading binary of MACROS... Loading binary of LOW... Loading binary of LUCID-LOW... ;;; Warning: Redefining macro %LOGAND which used to be defined in file /user1/clos/clos/low.lisp ;;; Warning: Redefining macro %ASH which used to be defined in file /user1/clos/clos/low.lisp ;;; Warning: Redefining macro MAKE-MEMORY-BLOCK which used to be defined in file /user1/clos/clos/low.lisp ;;; Warning: Redefining macro OBJECT-CACHE-NO which used to be defined in file /user1/clos/clos/low.lisp ;;; Warning: Redefining function SET-FUNCTION-NAME-1 which used to be defined in file /user1/clos/clos/low.lisp ;;; Warning: Redefining function PRINTING-RANDOM-THING-INTERNAL which used to be defined in file /user1/clos/clos/macros.lisp Loading binary of FIN... Loading binary of DEFS... Loading binary of BOOT... Loading binary of VECTOR... Loading binary of SLOTS... Loading binary of INIT... Loading binary of DEFCLASS... Loading binary of STD-CLASS... Compiling POINTS... ;;; Reading input file #P"/user1/clos/clos/points.lisp" ;;; Compiling toplevel form...assembling...emitting...done. ;;; Compiling macro MAKE-CPNODE...assembling...sharing list...emitting...done. ;;; Compiling toplevel form...assembling...emitting...done. ;;; Compiling macro CPNODE-ENTRY...assembling...sharing list...emitting...done. ;;; Compiling toplevel form...assembling...emitting...done. ;;; Compiling macro CPNODE-SUBNODES...assembling...sharing list...sharing list...sharing code...emitting...done. ;;; Compiling function WALK-CPNODE...assembling...emitting...done. ;;; Compiling function MAP-CPNODE...assembling...emitting...done. ;;; Compiling toplevel form...assembling...emitting...done. ;;; Compiling macro MAKE-POINT-ENTRY...assembling...sharing list...emitting...done. ;;; Compiling toplevel form...assembling...emitting...done. ;;; Compiling macro POINT-ENTRY-CLASSES...assembling...sharing list...sharing list...sharing code...emitting...done. ;;; Compiling toplevel form...assembling...emitting...done. ;;; Compiling macro POINT-ENTRY-PMO...assembling...sharing list...sharing list...sharing list...sharing code...emitting...done. ;;; Compiling toplevel form...assembling...emitting...done. ;;; Compiling macro POINT-ENTRY-FLAG...assembling...sharing list...sharing list...sharing code...emitting...done. ;;; Compiling toplevel form...assembling...emitting...done. ;;; Compiling macro POINT-ENTRY-CROSS-INFO...assembling...sharing list...sharing list...sharing code...emitting...done. ;;; Compiling toplevel form...assembling...emitting...done. ;;; Compiling macro MAKE-COLUMN-ENTRY...assembling...sharing list...sharing code...emitting...done. ;;; Compiling toplevel form...assembling...emitting...done. ;;; Compiling macro COLUMN-ENTRY-CLASS...assembling...sharing list...sharing list...sharing code...emitting...done. ;;; Compiling toplevel form...assembling...emitting...done. ;;; Compiling macro COLUMN-ENTRY-PMO...assembling...sharing list...sharing list...sharing list...sharing code...emitting...done. ;;; Compiling toplevel form...assembling...emitting...done. ;;; Compiling macro COLUMN-ENTRY-FLAG...assembling...sharing list...sharing list...sharing list...sharing code...emitting...done. ;;; Compiling toplevel form...assembling...emitting...done. ;;; Compiling macro MAKE-CPD-ENTRY...assembling...sharing list...sharing list...sharing code...emitting...done. ;;; Compiling toplevel form...assembling...emitting...done. ;;; Compiling macro CPD-ENTRY-CLASS...assembling...sharing list...sharing list...sharing code...emitting...done. ;;; Compiling toplevel form...assembling...emitting...done. ;;; Compiling macro CPD-ENTRY-PRECEDENCE...assembling...sharing list...sharing list...sharing list...sharing code...emitting...done. ;;; Compiling toplevel form...assembling...emitting...done. ;;; Compiling macro CPD-ENTRY-MULTIPLE-SUPERS-P...assembling...sharing list...sharing list...sharing list...sharing code...emitting...done. ;;; Compiling toplevel form...assembling...emitting...done. ;;; Compiling macro MAKE-CPDI-ENTRY...assembling...sharing list...sharing list...sharing code...emitting...done. ;;; Compiling toplevel form...assembling...emitting...done. ;;; Compiling macro CPDI-ENTRY-CLASS...assembling...sharing list...sharing list...sharing code...emitting...done. ;;; Compiling toplevel form...assembling...emitting...done. ;;; Compiling macro CPDI-ENTRY-PRECEDENCE...assembling...sharing list...sharing list...sharing list...sharing code...emitting...done. ;;; Compiling toplevel form...assembling...emitting...done. ;;; Compiling macro CPDI-ENTRY-COUNT...assembling...sharing list...sharing list...sharing list...sharing code...emitting...done. ;;; Compiling toplevel form...assembling...emitting...done. ;;; Compiling macro CPDI-ENTRY-SUPERS...assembling...sharing list...sharing list...sharing list...sharing code...emitting...done. ;;; Compiling toplevel form...assembling...emitting...done. ;;; Compiling macro CPDI-ENTRY-STATUS...assembling...sharing list...sharing list...sharing code...emitting...done. ;;; Compiling function COMPUTE-COMBINATION-POINTS... ;;; Warning: Variable A is bound but its value is ignored. ;;; assembling...emitting...done. ;;; Compiling function COMPUTE-COLUMN-SPECIALIZERS...assembling...emitting...done. ;;; Compiling function ADJUST-POINTS-FOR-EQL-METHODS...tail merging...tail merging...tail merging...assembling...(assembling...)(assembling...(assembling...))emitting...done. ;;; Compiling function CROSS-COLUMNS...tail merging...assembling...emitting...done. ;;; Compiling function CROSS-COLUMNS-MAIN...tail merging...assembling...(assembling...sharing list...)emitting...done. ;;; Compiling function CROSS-COLUMNS-NULL-REST...tail merging... ;;; Expanding Dynamic Memory assembling...(assembling...sharing list...)(assembling...sharing list...)emitting...done. ;;; Compiling function FULL-ON-COLUMN-CROSS...tail merging...assembling...emitting...done. ;;; Compiling function CROSS-COLUMN-WITH-POINT...assembling...(assembling...)(assembling...)sharing list...emitting...done. ;;; Compiling function CROSS-POINT-WITH-COLUMN... >>Error: The function LUCID::AUGMENT-LEXENV-FVARS-DUMMY is undefined WALKER::WITH-AUGMENTED-ENVIRONMENT-INTERNAL: Required arg 0 (ENV): ((# # #) (NIL #) (#) NIL NIL (# # ) NIL LUCID::%ALPHALEX) Required arg 1 (FUNCTIONS): ((WALK-COLUMN (PENTRY PCLASSES CNODE SUPER-CROSSED-PMO SUPER-CPMO) (LET* # #)) (WALK-POINT (PNODE) (LET* # #))) Required arg 2 (MACROS): NIL :A Abort to Lisp Top Level :C Try calling LUCID::AUGMENT-LEXENV-FVARS-DUMMY again -> :c Try calling LUCID::AUGMENT-LEXENV-FVARS-DUMMY again >>Error: The function LUCID::AUGMENT-LEXENV-FVARS-DUMMY is undefined WALKER::WITH-AUGMENTED-ENVIRONMENT-INTERNAL: Required arg 0 (ENV): ((# # #) (NIL #) (#) NIL NIL (# # ) NIL LUCID::%ALPHALEX) Required arg 1 (FUNCTIONS): ((WALK-COLUMN (PENTRY PCLASSES CNODE SUPER-CROSSED-PMO SUPER-CPMO) (LET* # #)) (WALK-POINT (PNODE) (LET* # #))) Required arg 2 (MACROS): NIL :A Abort to Lisp Top Level :C Try calling LUCID::AUGMENT-LEXENV-FVARS-DUMMY again -> :a ;;; Compilation aborted, object file not written Back to Lisp Top Level > (quit) pandora% exit pandora% script done on Mon Jun 19 16:20:31 1989 Script started on Mon Jun 19 16:14:49 1989 pandora% cd /user1/clos/clos pandora% grep lucid::augment-lexenv-fvars * grep: Read error on archive: Is a directory grep: Read error on check: Is a directory grep: Read error on doc: Is a directory grep: Read error on reflect: Is a directory grep: Read error on text: Is a directory walk.lisp:(defun lucid::augment-lexenv-fvars-dummy (lexical vars) walk.lisp: (lucid::augment-lexenv-fvars-aux lexical vars '() '() 'flet '())) walk.lisp: (setq env (lucid::augment-lexenv-fvars-dummy env function-names))) grep: Read error on web: Is a directory pandora% exit pandora% script done on Mon Jun 19 16:20:55 1989 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA06354; Tue, 20 Jun 89 14:52:22 -0700 Received: from Salvador.ms by ArpaGateway.ms ; 20 JUN 89 13:16:27 PDT Return-Path: Redistributed: CommonLoops.PA Received: from DINO.BBN.COM ([128.89.3.8]) by Xerox.COM ; 20 JUN 89 13:14:17 PDT To: Martin Boyer Cc: CommonLoops.PA@Xerox.COM Subject: Re: How to add slots to method objects In-Reply-To: Your message of Mon, 19 Jun 89 10:15:36 -0400. <8906191415.AA17070@Moe.McRCIM.McGill.EDU> Date: Tue, 20 Jun 89 16:20:05 -0400 From: kanderso@DINO.BBN.COM Message-Id: <890620-131627-14963@Xerox> Date: Mon, 19 Jun 89 10:15:36 EDT From: Martin Boyer Message-Id: <8906191415.AA17070@Moe.McRCIM.McGill.EDU> To: CommonLoops.PA@xerox.com Subject: How to add slots to method objects The first one was easy. Unfortunately, DEFGENERIC doesn't yet accept options and FIND-METHOD is not implemented yet. I tried ENSURE-GENERIC-FUNCTION, but it ignores the relevant options. I tried CHANGE-CLASS on a method, but there is no method defined for CHANGE-CLASS on action-method classes. I also looked in the section on Meta-Objects (p. 1-33, 1-34), but chapter 3 is not available yet for non-initiated. It there a solution to this? I am considering modifications to the PCL source to add those slots as part of the STANDARD-METHOD definition but that is an ugly hack. Use ENSURE-GNERIC-FUNCTION to get an empty gf. Then set its generic-function-method-class to be (find-class 'action-method). Use GET-METHOD for FIND-METHOD. Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA06404; Tue, 20 Jun 89 14:55:03 -0700 Received: from Salvador.ms by ArpaGateway.ms ; 20 JUN 89 13:28:44 PDT Return-Path: Redistributed: commonloops.pa Received: from sde.hp.com ([15.255.152.2]) by Xerox.COM ; 20 JUN 89 13:27:10 PDT Received: from hpllab.HP.COM by hp-sde.sde.hp.com ; Tue, 20 Jun 89 13:26:55 pdt Received: from localhost by hpllab.HP.COM; Tue, 20 Jun 89 13:26:30 pdt Full-Name: Lee Alton Barford Message-Id: <8906202026.AA01046@hpllab.HP.COM> To: Lawrence Hall Subject: Re: Problem compiling Victoria Day PCL Cc: commonloops.pa@Xerox.COM In-Reply-To: Your message of "Tue, 20 Jun 89 14:01:16 EDT." <8906201801.AA22933@aic.nrl.navy.mil> Date: Tue, 20 Jun 89 13:26:28 PDT From: barford@hpllab.hp.com I had the same problem compiling the Victoria Day PCL under Lucid 2.15. I worked around the problem as follows: ;; Patches to allow Victoria Day PCL to compile under LUCID 2.15: (in-package :lucid :nicknames '(lucid-common-lisp)) ;; it uses a wrong name (export '(*redefinition-action*)) ;; it assumes this is global (in-package :user) (load "defsys.l") (pcl::compile-pcl) Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA06509; Tue, 20 Jun 89 15:03:14 -0700 Received: from Chardonnay.ms by ArpaGateway.ms ; 20 JUN 89 12:55:58 PDT Return-Path: Redistributed: commonloops.pa Received: from DINO.BBN.COM ([128.89.3.8]) by Xerox.COM ; 20 JUN 89 12:51:30 PDT To: commonloops.pa@Xerox.COM Cc: kanderson@DINO.BBN.COM, Jmorrill@DINO.BBN.COM Subject: recursive cache expanding bug Date: Tue, 20 Jun 89 15:54:20 -0400 From: kanderso@DINO.BBN.COM Message-Id: <890620-125558-14895@Xerox> ;;;-*-Mode:LISP; Package:(PCL LISP 1000); Base:10; Syntax:Common-lisp -*- #|| Two bug fixes. I'm not sure, but the second one might be related to the problem Mike Thome was having. 1. Fixed a bug in ENSURE-GENERIC-FUNCTION-CACHE that throws away a cache that has just grown because it was too big, so gf's grow and then shrink as they are invalidated and used. ||# (defun ensure-generic-function-cache (generic-function size) (let ((existing (generic-function-cache generic-function))) (cond ((null existing) (setq existing (get-generic-function-cache size)) (setf (generic-function-cache generic-function) existing)) ((< (GENERIC-FUNCTION-CACHE-SIZE EXISTING) SIZE) (free-generic-function-cache existing) (setq existing (get-generic-function-cache size)) (setf (generic-function-cache generic-function) existing))) existing)) #|| 2. Suppose something calls CLASS-DIRECT-SUBCLASSES, EXPAND-DCODE-CACHE is called to expand the cache of CLASS-DIRECT-SUBCLASSES and either GENERIC-FUNCTION-CACHE or SLOT-VALUE-USING-CLASS are invalidated. Then the innocent looking line (SETF (GENERIC-FUNCTION-CACHE NEW-CACHE) GENERIC-FUNCTION) at the bottom of EXPAND-DCODE-CACHE will cause EXPAND-DCODE-CACHE to be called again on the same cache (because CLASS-DIRECT-SUBCLASSES gets called in while computing the combined methods). This trashes the *free-generic-function-caches*. The patch below avoids this extra expansion by making the SETF more "atomic". (Is this really another cache locking issue?) ||# (defun expand-dcode-cache (generic-function old-cache old-size line-size nkeys next-scan-limit dcode-constructor) (let* ((new-size (* old-size 2)) (new-number-of-lines (floor new-size line-size)) (new-mask (make-wrapper-cache-mask new-number-of-lines)) (new-cache (get-generic-function-cache new-size)) (new-dcode nil) (wrappers ()) (value nil)) (flet ((%SET-GENERIC-FUNCTION-CACHE (NV OBJECT) ;; Set the generic function cache avoiding another expansion. (LET ((SLOT-NAME 'CACHE)) (BIND-WRAPPER-AND-STATIC-SLOTS--FSC OBJECT (SETF-SLOT-VALUE-USING-CLASS-1)))) (collect-wrappers (loc) (block collect-wrappers (when (%svref old-cache loc) (setq wrappers ()) (dotimes (i nkeys) (let ((wrapper (%svref old-cache (+ i loc)))) (if (zerop (wrapper-cache-no wrapper)) ;; This wrapper is obsolete, we don't have an instance ;; so there is no related trap. Just drop this line ;; on the floor. (return-from collect-wrappers nil) (push wrapper wrappers)))) (setq wrappers (nreverse wrappers) value (and (< nkeys line-size) (%svref old-cache (+ loc nkeys)))) t)))) (flush-generic-function-caches-internal new-cache) (do ((old-location line-size (+ old-location line-size))) ((= old-location old-size)) (when (collect-wrappers old-location) (apply #'dcode-cache-miss generic-function #'(lambda (&rest ignore) (declare (ignore ignore)) value) new-cache new-size new-mask line-size nkeys next-scan-limit nil ;Means don't allow another ;expand while filling the ;new cache. This can only ;happen in one pathological ;case, but prevent it anyways. dcode-constructor wrappers))) (setq new-dcode (funcall dcode-constructor generic-function new-cache)) (%SET-GENERIC-FUNCTION-CACHE NEW-CACHE GENERIC-FUNCTION) (install-discriminating-function generic-function new-dcode) (free-generic-function-cache old-cache) new-cache))) Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA08835; Tue, 20 Jun 89 16:56:44 -0700 Received: from Salvador.ms by ArpaGateway.ms ; 20 JUN 89 16:56:57 PDT Return-Path: Redistributed: CommonLoops.pa Received: from uunet.uu.net ([192.48.96.2]) by Xerox.COM ; 20 JUN 89 16:55:28 PDT Received: from piring.cwi.nl by uunet.uu.net (5.61/1.14) with SMTP id AA26708; Tue, 20 Jun 89 19:55:10 -0400 Received: by piring.cwi.nl via EUnet; Wed, 21 Jun 89 01:54:30 +0200 (MET) Date: Wed, 21 Jun 89 01:54:30 +0200 From: lucas@cwi.nl (Peter Lucas) Message-Id: <8906202354.AA04179@piring.cwi.nl> To: CommonLoops.pa@Xerox.COM Subject: Can't compile Victoria Day PCL using AKCL I have problems in compiling 5/12/89 Virtoria Day PCL using AKCL Version 1.167. The turbo closure feature has not been installed, and I wonder whether this is the cause of the problem. However, "can't think of a cute name" PCL runs fine with AKCL. The problem seems to be caused by expansion of places in setf, incf and related forms in the "std-class.lsp" file. Following is part of the transcript using AKCL: ------------------------------------------------------------------------ PCL>(compil-pcl) Loading binary of DEFCLASS... Compiling STD-CLASS... Compiling /ufs/lucas/PCL2/std-class.lsp. Error: Cannot expand the SETF form (CPD-COUNT (CAR SUPERS)). Error signalled by FUNCALL. Backtrace: > funcall > funcall > INCF ; (DEFUN COMPUTE-STD-CPL-PHASE-2 ...) is being compiled. ;;; The macro form (INCF ...) was not expanded successfully. Error: Cannot expand the SETF form (CPD-COUNT (CAR T2)). Error signalled by FUNCALL. Backtrace: > funcall > funcall > INCF ;;; The macro form (INCF ...) was not expanded successfully. Error: Cannot expand the SETF form (CPD-AFTER (CAR T1)). Error signalled by FUNCALL. Backtrace: > funcall > funcall > PUSH ;;; The macro form (PUSH ...) was not expanded successfully. Error: Cannot expand the SETF form (CPD-COUNT AFTER). Error signalled by FUNCALL. Backtrace: > funcall > funcall > DECF ; (DEFUN COMPUTE-STD-CPL-PHASE-3 ...) is being compiled. ;;; The macro form (DECF ...) was not expanded successfully. ; (DEFUN NAMED-OBJECT-PRINT-FUNCTION ...) is being compiled. ;; Warning: Ignore declaration was found for not bound variable DEPTH. No FASL generated. -------------------------------------------------------------------------- Is there any one who could help me solve this problem? Thanks in advance, Peter Lucas. Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA06404; Tue, 20 Jun 89 14:55:03 -0700 Received: from Salvador.ms by ArpaGateway.ms ; 20 JUN 89 13:28:44 PDT Return-Path: Redistributed: commonloops.pa Received: from sde.hp.com ([15.255.152.2]) by Xerox.COM ; 20 JUN 89 13:27:10 PDT Received: from hpllab.HP.COM by hp-sde.sde.hp.com ; Tue, 20 Jun 89 13:26:55 pdt Received: from localhost by hpllab.HP.COM; Tue, 20 Jun 89 13:26:30 pdt Full-Name: Lee Alton Barford Message-Id: <8906202026.AA01046@hpllab.HP.COM> To: Lawrence Hall Subject: Re: Problem compiling Victoria Day PCL Cc: commonloops.pa@Xerox.COM In-Reply-To: Your message of "Tue, 20 Jun 89 14:01:16 EDT." <8906201801.AA22933@aic.nrl.navy.mil> Date: Tue, 20 Jun 89 13:26:28 PDT From: barford@hpllab.hp.com I had the same problem compiling the Victoria Day PCL under Lucid 2.15. I worked around the problem as follows: ;; Patches to allow Victoria Day PCL to compile under LUCID 2.15: (in-package :lucid :nicknames '(lucid-common-lisp)) ;; it uses a wrong name (export '(*redefinition-action*)) ;; it assumes this is global (in-package :user) (load "defsys.l") (pcl::compile-pcl) Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA20088; Wed, 21 Jun 89 04:07:02 -0700 Received: from Salvador.ms by ArpaGateway.ms ; 21 JUN 89 04:07:39 PDT Return-Path: Redistributed: commonloops.PA Received: from uunet.uu.net ([192.48.96.2]) by Xerox.COM ; 21 JUN 89 04:04:51 PDT Received: from mcvax.UUCP by uunet.uu.net (5.61/1.14) with UUCP id AA12791; Wed, 21 Jun 89 07:04:29 -0400 Received: by mcvax.cwi.nl via EUnet; Wed, 21 Jun 89 12:54:41 +0200 (MET) Received: by cernvax.uucp (1.2/Ultrix2.0-B) id AA26303; Wed, 21 Jun 89 12:39:52 +0200 Received: by delphi.uucp (3.2/SMI-3.2) id AA07193; Wed, 21 Jun 89 12:26:32 +0200 Date: Tue, 20 Jun 89 8:09:49 MET From: Sabrina Russell Subject: Re: Supported CLOS To: rajd@unixb.ctc.fmc.com, Kimbrough@dsg.csc.ti.com, rpg@sail.stanford.edu Cc: commonloops.PA@Xerox.COM Message-Id: <89/06/20 0809.508@delphi> [In reply to message from Kimbrough@dsg.csc.ti.com sent Thu, 15 Jun 89 11:18:44] > We are interested in knowing if there is such a thing as a supported > version of CLOS. The first commercial implementation of CLOS for workstations (Sun, Apollo ....) was announced by DELPHI in October 1988. DELPHI's proprietary implementation of CLOS is one of the features along with a specially tuned version of CLX and a multithread facility for concurrency embedded in Delphi Common Lisp (DCL). Derived from KCL, DCL, in one compact, portable package that runs on a variety of standard computers including Sun, HP/Apollo, DEC VAX/Ultrix and 386/Unix-based PCs, provides a complete implementation of Common Lisp, enhanced with the latest recognized standards in the Lisp world. The just released version 1.9 of DCL includes an implementation of CLOS with significantly improved performance, specially in the area of generic function call and slot access. Some benchmark results: DCL 1.9 Machine: Sun-4/260 10,000 SINGLE ARGUMENT GENERIC FUNCTION CALLS real time 0.317 10,000 GENERIC FUNCTION CALLS WITH SLOT ACCESS real time 0.467 100,000 SLOT ACCESSES WITHIN A SINGLE METHOD real time 0.150 Delphi Common Lisp will be shown at IJCAI - Detroit - in August - Delphi Booth 922. For more information contact dcl@delphi.uucp DELPHI S.p.A. - A.I. Division Via Vetraia 11 - 55049 Viareggio (LU) - Italy Tel: +39 (584) 395225 - Fax: +39 (584) 395366 - Tlx: 501542 DELPHI I Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA21458; Wed, 21 Jun 89 06:49:46 -0700 Received: from Salvador.ms by ArpaGateway.ms ; 21 JUN 89 06:45:22 PDT Return-Path: Redistributed: CommonLoops.pa Received: from mbunix.mitre.org ([129.83.20.100]) by Xerox.COM ; 21 JUN 89 06:43:47 PDT Posted-From: The MITRE Corp., Bedford, MA X-Alternate-Route: user%node@mbunix.mitre.org Return-Path: Received: from linnaeus.mitre.org by linus.MITRE.ORG (5.59/RCF-3S) id AA03352; Wed, 21 Jun 89 09:41:07 EDT Posted-Date: Wed, 21 Jun 89 09:42:19 EDT Received: by linnaeus.mitre.org (4.12/RCF-3C) id AA00719; Wed, 21 Jun 89 09:42:21 edt From: pc@linus.MITRE.ORG Message-Id: <8906211342.AA00719@linnaeus.mitre.org> To: lucas@cwi.nl Cc: CommonLoops.pa@Xerox.COM Subject: Re: Can't compile Victoria Day PCL using AKCL In-Reply-To: Your message of Wed, 21 Jun 89 01:54:30 +0200. <8906202354.AA04179@piring.cwi.nl> Date: Wed, 21 Jun 89 09:42:19 EDT I think this has been on the list before, but if you're running recent versions of AKCL you should skip the setf patches in the kcl-patches.lisp file. If I remember correctly, the errors you got are related to that. I actually skip the whole file and haven't had any problems (I believe &environment at least can now appear anywhere in macro lambda-list in AKCL). There's now an AKCL feature (probably since 1.167) and one way to deal with this would be to conditionalize the setf patches to KCL's that are not AKCL. - Penny Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA25998; Wed, 21 Jun 89 10:09:11 -0700 Received: from Semillon.ms by ArpaGateway.ms ; 21 JUN 89 09:54:29 PDT Date: Wed, 21 Jun 89 09:50 PDT From: Gregor.pa@Xerox.COM Subject: Re: Supported CLOS To: Sabrina Russell Cc: commonloops.PA@Xerox.COM Fcc: BD:>Gregor>mail>outgoing-mail-7.text.newest In-Reply-To: <89/06/20 0809.508@delphi> Message-Id: <19890621165059.9.GREGOR@SPIFF.parc.xerox.com> Line-Fold: no Date: Tue, 20 Jun 89 8:09:49 MET From: Sabrina Russell [In reply to message from Kimbrough@dsg.csc.ti.com sent Thu, 15 Jun 89 11:18:44] > We are interested in knowing if there is such a thing as a supported > version of CLOS. The first commercial implementation of CLOS for workstations (Sun, Apollo ....) was announced by DELPHI in October 1988. DELPHI's proprietary implementation of CLOS is one of the features along with a specially tuned version of CLX and a multithread facility for concurrency embedded in Delphi Common Lisp (DCL). I don't understand how you missed my message asking people to stop sending this sort of message. But, for the record, please don't send such commercial messages on this mailing list. Thanks. ------- Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA21458; Wed, 21 Jun 89 06:49:46 -0700 Received: from Salvador.ms by ArpaGateway.ms ; 21 JUN 89 06:45:22 PDT Return-Path: Redistributed: CommonLoops.pa Received: from mbunix.mitre.org ([129.83.20.100]) by Xerox.COM ; 21 JUN 89 06:43:47 PDT Posted-From: The MITRE Corp., Bedford, MA X-Alternate-Route: user%node@mbunix.mitre.org Return-Path: Received: from linnaeus.mitre.org by linus.MITRE.ORG (5.59/RCF-3S) id AA03352; Wed, 21 Jun 89 09:41:07 EDT Posted-Date: Wed, 21 Jun 89 09:42:19 EDT Received: by linnaeus.mitre.org (4.12/RCF-3C) id AA00719; Wed, 21 Jun 89 09:42:21 edt From: pc@linus.MITRE.ORG Message-Id: <8906211342.AA00719@linnaeus.mitre.org> To: lucas@cwi.nl Cc: CommonLoops.pa@Xerox.COM Subject: Re: Can't compile Victoria Day PCL using AKCL In-Reply-To: Your message of Wed, 21 Jun 89 01:54:30 +0200. <8906202354.AA04179@piring.cwi.nl> Date: Wed, 21 Jun 89 09:42:19 EDT I think this has been on the list before, but if you're running recent versions of AKCL you should skip the setf patches in the kcl-patches.lisp file. If I remember correctly, the errors you got are related to that. I actually skip the whole file and haven't had any problems (I believe &environment at least can now appear anywhere in macro lambda-list in AKCL). There's now an AKCL feature (probably since 1.167) and one way to deal with this would be to conditionalize the setf patches to KCL's that are not AKCL. - Penny Received: from Sail.Stanford.EDU by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA03361; Wed, 21 Jun 89 16:43:04 -0700 Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 21 Jun 89 16:44:02 PDT Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs) id AA05056; Wed, 21 Jun 89 17:44:24 -0600 Received: by defun.utah.edu (5.61/utah-2.0-leaf) id AA01963; Wed, 21 Jun 89 17:44:21 -0600 From: sandra%defun@cs.utah.edu (Sandra J Loosemore) Message-Id: <8906212344.AA01963@defun.utah.edu> Date: Wed, 21 Jun 89 17:44:20 MDT Subject: Re: issue CLOS-MACRO-COMPILATION, version 4 To: Kent M Pitman Cc: cl-compiler@sail.stanford.edu, Moon@STONY-BROOK.SCRC.Symbolics.COM, RPG@Lucid.COM, common-lisp-object-system@sail.stanford.edu In-Reply-To: Kent M Pitman , Wed, 21 Jun 89 18:18 EDT > Date: Wed, 21 Jun 89 18:18 EDT > From: Kent M Pitman > > Surely you don't mean that DEFGENERIC will arrange for the gf not to > be callable. You simply mean that it won't arrange for it to be callable. Yes, you're right. > - DEFMETHOD may not pollute the compile time environment by augmenting > the generic function at that time. The intent is that simply *compiling* a DEFMETHOD won't pollute the compile time environment. I agree this could perhaps be made more explicit. > Actually, on an unrelated point, I guess I am also slightly nervous > about the vague phrasing "may try to evaluate" (e.g., in discussion of > EQL specializers). This wording was taken from the amendment Gregor proposed at the last meeting. I have not presumed to try to interpret what it means. I personally think we would be better off deleting this particular sentence from the proposal, and sticking with the simple statement that EQL specializer forms are evaluated when the DEFMETHOD form is executed. -Sandra ------- Received: from Sail.Stanford.EDU by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA04374; Wed, 21 Jun 89 17:59:06 -0700 Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 21 Jun 89 17:52:48 PDT Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 614933; 21 Jun 89 20:54:07 EDT Date: Wed, 21 Jun 89 20:54 EDT From: Kent M Pitman Subject: Re: issue CLOS-MACRO-COMPILATION, version 4 To: sandra%defun@cs.utah.edu Cc: KMP@STONY-BROOK.SCRC.Symbolics.COM, cl-compiler@sail.stanford.edu, Moon@STONY-BROOK.SCRC.Symbolics.COM, RPG@Lucid.COM, common-lisp-object-system@sail.stanford.edu In-Reply-To: <8906212344.AA01963@defun.utah.edu> Message-Id: <19890622005403.7.KMP@BOBOLINK.SCRC.Symbolics.COM> Date: Wed, 21 Jun 89 17:44:20 MDT From: sandra%defun@cs.utah.edu (Sandra J Loosemore) ... > - DEFMETHOD may not pollute the compile time environment by augmenting > the generic function at that time. The intent is that simply *compiling* a DEFMETHOD won't pollute the compile time environment. I agree this could perhaps be made more explicit. I guess the problem was that because the previous thing (about DEFGENERIC) had forced me to contort the meanings of some of the words, there was a tendency for me to wonder if there were hidden meanings in some of the others. > Actually, on an unrelated point, I guess I am also slightly nervous > about the vague phrasing "may try to evaluate" (e.g., in discussion of > EQL specializers). This wording was taken from the amendment Gregor proposed at the last meeting. I have not presumed to try to interpret what it means. I personally think we would be better off deleting this particular sentence from the proposal, and sticking with the simple statement that EQL specializer forms are evaluated when the DEFMETHOD form is executed. Well, removing the statement would probably be fine by me. I don't think it really adds much semantic content since, after all, any function can attempt to evaluate just about anything as long as the effects of doing so are not visible. Maybe all that's really being said is that ``the compiler can build in knowledge about what the form in an EQL specializer will evaluate to in cases where the ultimate result can be syntactically inferred without actually evaluating it.'' I guess that's an interesting piece of information, but I'd prefer a presentation like this that emphasized -not- evaluating it rather than something that said trying evaluation was ok when clearly in the general case it is not. Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA09757; Wed, 21 Jun 89 23:01:28 -0700 Received: from Salvador.ms by ArpaGateway.ms ; 21 JUN 89 23:03:26 PDT Return-Path: Redistributed: commonloops.pa Received: from IBM.COM ([192.5.58.7]) by Xerox.COM ; 21 JUN 89 23:01:14 PDT Date: Wed, 21 Jun 89 22:06:02 PDT From: David Alpern To: commonloops.pa@Xerox.COM Message-Id: <890621-230326-18754@Xerox> I just took a look at defconstruct, as present in the "No cute name" release. I hope I'm not missing something simple, but one thing I'd like to have is very simple make- routines that don't care a bit about the initialization arguments, just to provide a little abstraction above the *make-instance call. In other words, (defun make-foo (&rest plist) (apply #'pcl::*make-instance 'foo plist)) I would have though that would be what defconstruct would be great at, but I can't figure out how to set it up so that the &rest arg (plist above) is treated as a list of initialization arguments rather than as just a single item. To do this above, I needed to use apply -- but what can one do with defconstructor? - Dave David M. Alpern IBM Almaden Research Center, K31/802 650 Harry Road, San Jose, CA 95120-6099 Phone: (408) 927-2067 Internet: ALPERN@IBM.COM Bitnet: ALPERN at ALMVMC Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA20330; Thu, 22 Jun 89 07:20:34 -0700 Received: from Semillon.ms by ArpaGateway.ms ; 22 JUN 89 07:22:24 PDT Return-Path: Redistributed: CommonLoops.pa Received: from shamash.cdc.com ([129.205.0.10]) by Xerox.COM ; 22 JUN 89 07:20:26 PDT Received: by shamash.cdc.com (5.59/CDC1.1) id AA10303; Thu, 22 Jun 89 09:18:46 -0600 From: bmiller@shamash.cdc.com (Brad Miller - EMD) Message-Id: <8906221418.AA10303@shamash.cdc.com> Subject: subtypep questions To: CommonLoops.pa@Xerox.COM Date: Thu, 22 Jun 89 9:18:42 CDT X-Mailer: ELM [version 2.2 PL0] I am sure that this question has come up here before, but I have looked back through the archives and I cannot find the answer. I am trying to teach myself about CLOS and therefore have been going through Keene's book and trying the examples. However the first one I try doesn't seem to be working out. The following is a section of a recent transcript from Allegro CL 1.2.1 on my Mac II. ? (defclass lock () ((name :initarg :name :reader lock-name))) # ? (defclass null-lock (lock) ()) # ? (defclass simple-lock (lock) ((owner :initform nil :accessor lock-owner))) # ? (subtypep 'simple-lock 'lock) nil nil *** QUESTION NUMBER 1, why does this not return t t as I would expect? ? (setq *null-lock* (make-instance 'null-lock :name "Null lock")) # ? (setq *simple-lock* (make-instance 'simple-lock :name "Simple lock")) # ? (type-of *null-lock*) iwmc-class *** QUESTION NUMBER 2, What is this iwmc-class, and what has happened to my null-lock class? ? (typep *simple-lock* 'simple-lock) t *** COMMENT NUMBER 1, Well at least something worked as I expected. Any comments or advice to point this wayward programmer in the right direction would be sincerely appreciated. Thanks in advance. Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA24098; Thu, 22 Jun 89 11:33:16 -0700 Received: from Semillon.ms by ArpaGateway.ms ; 22 JUN 89 10:19:09 PDT Date: Thu, 22 Jun 89 10:13 PDT From: Gregor.pa@Xerox.COM Subject: Re: subtypep questions To: Brad Miller - EMD Cc: CommonLoops.pa@Xerox.COM Fcc: BD:>Gregor>mail>outgoing-mail-7.text.newest In-Reply-To: <8906221418.AA10303@shamash.cdc.com> Message-Id: <19890622171341.6.GREGOR@SPIFF.parc.xerox.com> Line-Fold: no Date: Thu, 22 Jun 89 9:18:42 CDT From: bmiller@shamash.cdc.com (Brad Miller - EMD) The basic answers to your questions are that PCL can't implement all of CLOS portably. In particular, parts of CLOS which require changes to the way a pre-existing Common Lisp function are difficult to implement portably. TYPE-OF and SUBTYPEP are examples of these. Let me stress again that any new user of PCL should take the time to read through ALL OF THE OLD xxx-notes.text files. I know this seems tedious, but it is the best way to get an idea of what PCL is and isn't wrt to the CLOS specification. ------- Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA24154; Thu, 22 Jun 89 11:37:53 -0700 Received: from Semillon.ms by ArpaGateway.ms ; 22 JUN 89 11:01:26 PDT Date: Thu, 22 Jun 89 10:19 PDT From: Gregor.pa@Xerox.COM Subject: DEFCONSTRUCTOR To: David Alpern Cc: commonloops.pa@Xerox.COM Fcc: BD:>Gregor>mail>outgoing-mail-7.text.newest In-Reply-To: The message of 21 Jun 89 22:06 PDT from David Alpern Message-Id: <19890622171916.7.GREGOR@SPIFF.parc.xerox.com> Line-Fold: no Date: Wed, 21 Jun 89 22:06:02 PDT From: David Alpern (defun make-foo (&rest plist) (apply #'pcl::*make-instance 'foo plist)) I would have though that would be what defconstruct would be great at, but I can't figure out how to set it up so that the &rest arg (plist above) is treated as a list of initialization arguments rather than as just a single item. To do this above, I needed to use apply -- but what can one do with defconstructor? It is best to go ahead and define such functions as you have done above with DEFUN and APPLY. As you point out, DEFCONSTRUCTOR doesn't have a syntax for doing just this. DEFCONSTRUCTOR itself is going to go away soon anyways. It was just a stop-gap measure until I was ready to ask implementors to provide the right compiler hook so that I could optimize calls to make-instance more directly. The bulk of the DEFCONSTRUCTOR smarts will stick around its just that there won't be an explicit interface that people have to use to get that optimization. So, where you now write: (defconstructor make-foo foo (x) :x x) and PCL turns it into something like: (defun make-foo (x) (funcall x)) In the future you will write: (defun make-foo (x) (make-instance 'foo :x x)) and PCL will turn it into: (defun make-foo (x) (funcall x)) ------- Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA24250; Thu, 22 Jun 89 11:47:09 -0700 Received: from Semillon.ms by ArpaGateway.ms ; 22 JUN 89 11:01:49 PDT Date: Thu, 22 Jun 89 10:31 PDT From: Gregor.pa@Xerox.COM Subject: stuck in the middle To: CommonLoops.PA@Xerox.COM Fcc: BD:>Gregor>mail>outgoing-mail-7.text.newest Message-Id: <19890622173122.9.GREGOR@SPIFF.parc.xerox.com> Line-Fold: no Now I am getting opinions from all sides. Some people think commercial announcements are OK, others think they aren't. My initial reaction to try and stop these messages was intended only to try and avoid these sorts of flames, but it seems like it didn't work. :-( Moreover, those vendors who have refrained from advertising their CLOS work have, by doing so, made it appear that they are not developing a CLOS. That seems unfortunate and unfair. But, the network isn't really supposed to be used for advertising, so it is a difficult situation to resolve. At this point, if any vendor is doing a CLOS implementation and wants to send out a one or two paragraph description of their work I am not going to complain. Please make these technically oriented descriptions so it won't become an unadultered marketing frenzy. ------- Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA26675; Thu, 22 Jun 89 14:04:00 -0700 Received: from Cabernet.ms by ArpaGateway.ms ; 22 JUN 89 14:00:37 PDT Return-Path: Redistributed: commonloops.pa Received: from mbunix.mitre.org ([129.83.20.100]) by Xerox.COM ; 22 JUN 89 13:58:30 PDT Posted-From: The MITRE Corp., Bedford, MA X-Alternate-Route: user%node@mbunix.mitre.org Return-Path: Received: from sabre.mitre.org by linus.MITRE.ORG (5.59/RCF-3S) id AA23007; Thu, 22 Jun 89 16:55:58 EDT Posted-Date: Thu, 22 Jun 89 16:56:38 EDT Received: from localhost by sabre.mitre.org (3.2/RCF-3C) id AA19252; Thu, 22 Jun 89 16:56:42 EDT Message-Id: <8906222056.AA19252@sabre.mitre.org> To: CommonLoops.pa@Xerox.COM Subject: Bug in printing lexical closures (Genera) Date: Thu, 22 Jun 89 16:56:38 EDT From: rich@linus.MITRE.ORG In fin.lisp, PCL-PRINT-LEXICAL-CLOSURE is used to print lexical closures and funcallable instances. However, this will cause SI:PRINT-LEXICAL-CLOSURE to be sent 4 args, when it only takes 3 (it doesn't take depth). I commented out the depth arg and both lexical closures and funcallable instances seem to print out just fine. However, the depth arg was there for some reason. What is the "real" fix? Rich Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA27233; Thu, 22 Jun 89 14:39:08 -0700 Received: from Semillon.ms by ArpaGateway.ms ; 22 JUN 89 14:36:44 PDT Return-Path: Redistributed: commonloops.pa Received: from mbunix.mitre.org ([129.83.20.100]) by Xerox.COM ; 22 JUN 89 14:34:06 PDT Posted-From: The MITRE Corp., Bedford, MA X-Alternate-Route: user%node@mbunix.mitre.org Return-Path: Received: from sabre.mitre.org by linus.MITRE.ORG (5.59/RCF-3S) id AA23888; Thu, 22 Jun 89 17:31:38 EDT Posted-Date: Thu, 22 Jun 89 17:32:26 EDT Received: from localhost by sabre.mitre.org (3.2/RCF-3C) id AA19286; Thu, 22 Jun 89 17:32:28 EDT Message-Id: <8906222132.AA19286@sabre.mitre.org> To: gregor.pa@Xerox.COM Cc: CommonLoops.pa@Xerox.COM Subject: defconstructors Date: Thu, 22 Jun 89 17:32:26 EDT From: rich@linus.MITRE.ORG >Date: Thu, 22 Jun 89 10:19 PDT >From: Gregor.pa@Xerox.COM >Subject: DEFCONSTRUCTOR >To: David Alpern > > Date: Wed, 21 Jun 89 22:06:02 PDT > From: David Alpern > > (defun make-foo (&rest plist) > (apply #'pcl::*make-instance 'foo plist)) > > I would have though that would be what defconstruct would be great at, > but I can't figure out how to set it up so that the &rest arg (plist > above) is treated as a list of initialization arguments rather than > as just a single item. To do this above, I needed to use apply -- > but what can one do with defconstructor? > >It is best to go ahead and define such functions as you have done above >with DEFUN and APPLY. As you point out, DEFCONSTRUCTOR doesn't have a >syntax for doing just this. Actually, you can write a macro to create the appropriate constructor, but you have to be very tricky in certain situations. We wrote one, which was a real hack, because we wanted to be able to make DEFCONSTRUCTOR act exactly like the :CONSTRUCTOR option (that used be available for the defclass definition). In other words, if you had an old kind of constructor, MAKE-FOO, it was just a "shorthand" for (make-instance 'foo ....) and you could call it with any initargs that you had specified. We wanted this same behavior from DEFCONSTRUCTOR. Since we always specify initargs for our slots, the constructors created from defconstructor have to have ALL initargs as potential keyword arguments. Ignoring the issues that are involved in creating just such a constructor and have it handle initargs and initforms correctly, am I just on the wrong track altogether???? The constructors that result are enormous! Perhaps, the purpose of defconstructor was to have SPECIALIZED constructors for classes. In other words, when creating a FOO in situation 1 use MAKE-FOO-IN-SIT-1 and when creating a FOO in situation 2 use MAKE-FOO-IN-SIT-2, where the different siutations require different initargs, and the number of initargs used in a particular situation is few. Which is correct? >DEFCONSTRUCTOR itself is going to go away soon anyways. What time frame are we talking about???? Rich Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA27246; Thu, 22 Jun 89 14:40:06 -0700 Received: from Semillon.ms by ArpaGateway.ms ; 22 JUN 89 14:39:03 PDT Return-Path: Redistributed: CommonLoops.pa Received: from uunet.uu.net ([192.48.96.2]) by Xerox.COM ; 22 JUN 89 14:36:51 PDT Received: from unido.UUCP by uunet.uu.net (5.61/1.14) with UUCP id AA19687; Thu, 22 Jun 89 17:36:09 -0400 Received: from gmdzi.UUCP (gmdzi) (2407) by unido.irb.informatik.uni-dortmund.de for uunet id AU18323; Thu, 22 Jun 89 20:01:40 +0100 Received: by gmdzi.UUCP id AA19197; Thu, 22 Jun 89 21:02:26 -0200 Received: from liliput by sysiphos via INTERNET with SMTP id 46036; 22 Jun 89 20:59:07+0100 Date: Thu, 22 Jun 89 20:59+0100 From: Heinz W. Schmidt Subject: Re: subtypep questions To: bmiller%shamash.cdc.com%gmdzi.uucp@uunet.UU.NET Cc: CommonLoops.pa%Xerox.COM%gmdzi.uucp@uunet.UU.NET In-Reply-To: <8906221418.AA10303@shamash.cdc.com> Message-Id: <19890622195956.8.HWS@liliput> From: Brad Miller - EMD ... ? (defclass lock () ((name :initarg :name :reader lock-name))) # ? (defclass null-lock (lock) ()) # ? (defclass simple-lock (lock) ((owner :initform nil :accessor lock-owner))) # ? (subtypep 'simple-lock 'lock) nil nil *** QUESTION NUMBER 1, why does this not return t t as I would expect? ? (setq *null-lock* (make-instance 'null-lock :name "Null lock")) # ? (setq *simple-lock* (make-instance 'simple-lock :name "Simple lock")) # ? (type-of *null-lock*) iwmc-class *** QUESTION NUMBER 2, What is this iwmc-class, and what has happened to my null-lock class? These are not bugs according to the CLtL spec. The second value of SUBTYPEP is NIL and TYPE-OF returns a representation dependent value, not the declared type as perceived by the programmer. Maybe this does what you were looking for (.. cute .. pcl): (subclassp 'simple-lock 'lock) => (# # #) (class-name (class-of *null-lock*)) ==> NULL-LOCK A workaround towards your expections might be (defmacro *type-of (object) `(let ((object ,object)) (if (typep object 'pcl::iwmc-class) ; not robust 'cause IWMC-CLASS is internal (pcl:class-name (pcl:class-of object)) (lisp:type-of object)))) (defmacro *subtypep (type1 type2) `(let ((type1 ,type1) (type2 ,type2)) (if (and (pcl:find-class type1 nil) (pcl:find-class type2 nil)) ;; make the guess a certainty where pcl knows better (values (when (pcl:subclassp type1 type2) t) t) (lisp:subtypep type1 type2)))) --hws Heinz W. Schmidt UUCP: hws@gmdzi.UUCP German National Research Center Tel: (++49 2241) 14-2448 for Computer Science (GMD), Institut fuer Systemtechnik Postf. 1240 D-5205 St. Augustin 1, FRG Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA09315; Fri, 23 Jun 89 06:32:11 -0700 Received: from Salvador.ms by ArpaGateway.ms ; 22 JUN 89 19:27:30 PDT Return-Path: Redistributed: commonloops.pa Received: from Sun.COM ([192.9.9.1]) by Xerox.COM ; 22 JUN 89 19:26:03 PDT Received: from snail.Sun.COM (snail.Corp.Sun.COM) by Sun.COM (4.1/SMI-4.1) id AA00644; Thu, 22 Jun 89 19:26:03 PDT Received: from suntana.sun.com by snail.Sun.COM (4.1/SMI-4.1) id AA25367; Thu, 22 Jun 89 19:24:35 PDT Received: from localhost by suntana.sun.com (4.0/SMI-4.0) id AA01673; Thu, 22 Jun 89 19:25:42 PDT Message-Id: <8906230225.AA01673@suntana.sun.com> To: Gregor.pa@Xerox.COM Cc: CommonLoops.PA@Xerox.COM Subject: Sun Common Lisp CLOS In-Reply-To: Your message of Thu, 22 Jun 89 10:31:00 -0700. <19890622173122.9.GREGOR@SPIFF.parc.xerox.com> Date: Thu, 22 Jun 89 19:25:40 PDT From: kempf@Sun.COM >is a difficult situation to resolve. At this point, if any vendor is >doing a CLOS implementation and wants to send out a one or two paragraph >description of their work I am not going to complain. Please make these >technically oriented descriptions so it won't become an unadultered marketing frenzy. This sounds like a reasonable proposition. Anyway, now that Gregor has given his blessing, I can say that Sun and Lucid are working on an implementation of CLOS. Currently, the implemenation is in alpha test. It will be part of Sun Common Lisp 4.0. Our CLOS implementation is an integration of PCL into the Sun Common Lisp base, and we have tryed to document how people with PCL code can port to Sun Common Lisp 4.0. PCL compatibility should be fairly high. Sun has been using this implementation internally on a window interface (more about that elsewhere, potential for flamage here), and on some prototype environment work. We believe that it is quite solid and should be a good product. Perhaps JonL White or Peter Bensen from Lucid want to say more? jak Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA18921; Tue, 27 Jun 89 10:41:44 -0700 Received: from Semillon.ms by ArpaGateway.ms ; 24 JUN 89 16:25:10 PDT Date: Sat, 24 Jun 89 16:21 PDT From: Gregor.pa@Xerox.COM Subject: Re: recursive cache expanding bug To: kanderso@DINO.BBN.COM Cc: commonloops.pa@Xerox.COM, kanderson@DINO.BBN.COM, Jmorrill@DINO.BBN.COM Fcc: BD:>Gregor>mail>outgoing-mail-7.text.newest In-Reply-To: The message of 20 Jun 89 12:54 PDT from kanderso@DINO.BBN.COM Message-Id: <19890624232110.7.GREGOR@SPIFF.parc.xerox.com> Line-Fold: no Date: Tue, 20 Jun 89 15:54:20 -0400 From: kanderso@DINO.BBN.COM 1. Fixed a bug in ENSURE-GENERIC-FUNCTION-CACHE that throws away a cache that has just grown because it was too big, so gf's grow and then shrink as they are invalidated and used. I installed this change. 2. Suppose something calls CLASS-DIRECT-SUBCLASSES, EXPAND-DCODE-CACHE is called to expand the cache of CLASS-DIRECT-SUBCLASSES and either GENERIC-FUNCTION-CACHE or SLOT-VALUE-USING-CLASS are invalidated. Then the innocent looking line (Is this really another cache locking issue?) Sort of, it also resembles the metacircularity issues of having to call a generic function as part of updating that same generic function. I didn't install this change, but when I rewrite the dcode mechanism to use the new LAP stuff I will put in a *expansions-on-stack* sort of thing to prevent this from happening. Thanks for these bug reports and fixes. ------- Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA19086; Tue, 27 Jun 89 10:56:25 -0700 Received: from Semillon.ms by ArpaGateway.ms ; 24 JUN 89 17:20:04 PDT Date: Sat, 24 Jun 89 17:16 PDT From: Gregor.pa@Xerox.COM Subject: Re: defconstructors To: rich@linus.MITRE.ORG Cc: CommonLoops.pa@Xerox.COM Fcc: BD:>Gregor>mail>outgoing-mail-7.text.newest In-Reply-To: <8906222132.AA19286@sabre.mitre.org> Message-Id: <19890625001639.9.GREGOR@SPIFF.parc.xerox.com> Line-Fold: no Date: Thu, 22 Jun 89 17:32:26 EDT From: rich@linus.MITRE.ORG Ignoring the issues that are involved in creating just such a constructor and have it handle initargs and initforms correctly, am I just on the wrong track altogether???? The constructors that result are enormous! My belief is that people should use the existing language features to create these interfaces. These features include DEFUN, MAKE-INSTANCE and the very powerful (hairy) lambda-list keywords facility. As an example, take the following `constructor': (defun make-foo (x y) (make-instance 'foo :x x :y y)) It is then the job of the underlying CLOS implementation to optimize these kinds of definitions. DEFCONSTRUCTOR was a temporary hack designed to get around the fact that PCL couldn't get from each Common Lisp the hooks it needed to "optimize these kinds of definitions". DEFCONSTRUCTOR was designed in such a way that it would be as easy as possible for people to later go through and convert all calls to DEFCONSTRUCTOR to calls to DEFUN and MAKE-INSTANCE. Given this belief, it may be that I would say you are on the wrong track by building such huge constructors. Rather I would agree with the following comment take from your message: Perhaps, the purpose of defconstructor was to have SPECIALIZED constructors for classes. In other words, when creating a FOO in situation 1 use MAKE-FOO-IN-SIT-1 and when creating a FOO in situation 2 use MAKE-FOO-IN-SIT-2, where the different siutations require different initargs, and the number of initargs used in a particular situation is few. I would say this is exactly the kind of thing you can and should do with named constructor functions created either with DEFCONSTRUCTOR or DEFUN and MAKE-INSTANCE. In her book Sonya Keene presents a good discussion of the kinds of reasons why you want to have special constructor functions this way. What time frame are we talking about? (to delete DEFCONSTRUCTOR) Little hard to say, it depends on how soon I get the right compiler hooks, but I want to do it in the next few weeks. ------- Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA21743; Tue, 27 Jun 89 14:02:49 -0700 Received: from Semillon.ms by ArpaGateway.ms ; 26 JUN 89 06:19:33 PDT Return-Path: <@stalingrad.bbn.com,@sleepy:tmitchel@vax.bbn.com> Redistributed: CommonLoops.pa Received: from VAX.BBN.COM ([128.89.0.91]) by Xerox.COM ; 26 JUN 89 06:17:42 PDT Received: by VAX.BBN.COM id aa09281; 26 Jun 89 9:05 EDT Received: from stalingrad.bbn.com by VAX.BBN.COM id aa09165; 26 Jun 89 8:56 EDT Date: Mon, 26 Jun 89 08:57 EDT From: Tom Mitchell Subject: subtypep questions To: bmiller@shamash.cdc.com, CommonLoops.pa@Xerox.COM In-Reply-To: <8906221418.AA10303@shamash.cdc.com> Message-Id: <19890626125702.1.TOM@SLEEPY> Date: Thu, 22 Jun 89 9:18:42 CDT From: Brad Miller - EMD Here is what I did to fix this problem. I have only run it on a Symbolics machine (7.2) but I think it should work in Common Lisp. The function do-satisfies-deftype is from the 12/7 version of PCL. I assume it remains essentially the same in the latest version (5/22). Try it and let me know if it works. The change is explained in the comments and set off by two lines of hyphens. -tom ;;;******************************************************************************** ;;;handle deftyping properly... ;;;this gives us the subtype relationship within the CL Type system. ;;;******************************************************************************** ;;;the deftype for an associated class now will look like this: ;;; ;;;For ;;; (defclass baz (foo bar) ()) ;;; ;;;We do ;;; (deftype baz () ;;; (and foo bar object t (satisfies |BAZ predicate|))) ;;; ;;;which gives us the subtype relationship we want when defining types of slots, ;;;instead of making all classes disjoint in the Common Lisp Type hierarchy. ;;;this is accomplished by grabbing the class-precedence-list of the class being ;;;defined (or redefined), taking the cdr of it (to eliminate the current class, ;;;which always seems to be the car of the list), and mapping #'class-name through ;;;the list to get the symbol associated with the class. (defun do-satisfies-deftype (name predicate) (let* ((specifier `(satisfies ,predicate)) (expand-fn #'(lambda (&rest ignore) (declare (ignore ignore)) ;;;-------------------------------------------------- `(and ,(mapcar #'class-name (cdr (class-precedence-list (find-class name)))) ;;;-------------------------------------------------- ,specifier)))) ;; Specific ports can insert their own way of doing this. Many ;; ports may find the expand-fn defined above useful. ;; (or #+:Genera (setf (get name 'deftype) expand-fn) #+(and :Lucid (not :Prime)) (system::define-macro `(deftype ,name) expand-fn nil) #+ExCL (setf (get name 'excl::deftype-expander) expand-fn) #+:coral (setf (get name 'ccl::deftype-expander) expand-fn) ;; This is the default for ports for which we don't know any ;; better. Note that for most ports, providing this definition ;; should just speed up class definition. It shouldn't have an ;; effect on performance of most user code. (eval `(deftype ,name () '(satisfies ,predicate)))))) Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA24182; Tue, 27 Jun 89 16:50:20 -0700 Received: from Semillon.ms by ArpaGateway.ms ; 26 JUN 89 23:55:43 PDT Return-Path: <@CUNYVM.CUNY.EDU:CHEEWEEI@ITIVAX.BITNET> Redistributed: CommonLoops.pa Received: from CUNYVM.CUNY.EDU ([128.228.1.2]) by Xerox.COM ; 26 JUN 89 23:54:11 PDT Received: from ITIVAX.BITNET by CUNYVM.CUNY.EDU (IBM VM SMTP R1.1) with BSMTP id 8995; Tue, 27 Jun 89 02:54:07 EDT Date: Tue, 27 Jun 89 14:49 U From: Subject: define-meta-class To: CommonLoops.pa@Xerox.COM X-Original-To: CommonLoops.pa@Xerox.com, CHEEWEEI Message-Id: <890626-235543-214@Xerox> There's a format error in define-meta-class of PCL. The error function is missing arguments. Slots are bound to nil when it should be unbound when a new instance is created whose slots are not assigned any values. (As spec by CLOS). Slot-exists-p always returns t. Is it possible to obtain the on-line draft of the Meta-Object protocol for CLOS (Chapt 3). CW Reply to: CHEEWEEI@itivax.bitnet Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA18921; Tue, 27 Jun 89 10:41:44 -0700 Received: from Semillon.ms by ArpaGateway.ms ; 24 JUN 89 16:25:10 PDT Date: Sat, 24 Jun 89 16:21 PDT From: Gregor.pa@Xerox.COM Subject: Re: recursive cache expanding bug To: kanderso@DINO.BBN.COM Cc: commonloops.pa@Xerox.COM, kanderson@DINO.BBN.COM, Jmorrill@DINO.BBN.COM Fcc: BD:>Gregor>mail>outgoing-mail-7.text.newest In-Reply-To: The message of 20 Jun 89 12:54 PDT from kanderso@DINO.BBN.COM Message-Id: <19890624232110.7.GREGOR@SPIFF.parc.xerox.com> Line-Fold: no Date: Tue, 20 Jun 89 15:54:20 -0400 From: kanderso@DINO.BBN.COM 1. Fixed a bug in ENSURE-GENERIC-FUNCTION-CACHE that throws away a cache that has just grown because it was too big, so gf's grow and then shrink as they are invalidated and used. I installed this change. 2. Suppose something calls CLASS-DIRECT-SUBCLASSES, EXPAND-DCODE-CACHE is called to expand the cache of CLASS-DIRECT-SUBCLASSES and either GENERIC-FUNCTION-CACHE or SLOT-VALUE-USING-CLASS are invalidated. Then the innocent looking line (Is this really another cache locking issue?) Sort of, it also resembles the metacircularity issues of having to call a generic function as part of updating that same generic function. I didn't install this change, but when I rewrite the dcode mechanism to use the new LAP stuff I will put in a *expansions-on-stack* sort of thing to prevent this from happening. Thanks for these bug reports and fixes. ------- Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA24394; Tue, 27 Jun 89 17:14:42 -0700 Received: from Burger.ms by ArpaGateway.ms ; 27 JUN 89 10:59:23 PDT Return-Path: Redistributed: CommonLoops.PA Received: from uunet.uu.net ([192.48.96.2]) by Xerox.COM ; 27 JUN 89 10:55:22 PDT Received: by uunet.uu.net (5.61/1.14) with UUCP id AA06178; Tue, 27 Jun 89 13:55:06 -0400 Received: by franz.Franz.COM (MC 2.0/FI-1.0) id AA00438; Tue, 27 Jun 89 10:05:09 PDT Received: by snooze.Franz.COM (4.0/FI-1.0) id AA07440; Tue, 27 Jun 89 10:03:38-080 From: layer@franz.com (Kevin Layer) Message-Id: <8906271803.AA07440@snooze.Franz.COM> To: CommonLoops.PA@Xerox.COM Subject: Re: stuck in the middle In-Reply-To: Your message of Thu, 22 Jun 89 10:31:00 PDT. <19890622173122.9.GREGOR@SPIFF.parc.xerox.com> Date: Tue, 27 Jun 89 10:03:36 -0800 >> Moreover, those vendors who have refrained from advertising their CLOS >> work have, by doing so, made it appear that they are not developing a >> CLOS. That seems unfortunate and unfair. Yes, I did get some messages from people asking why we were not supporting CLOS. We are currently working on integrating CLOS into the debugger (both non-windowized and windowized versions). Also high priority is optimizing CLOS to make it as fast as possible. As a company, we are committed to using, developing, optimizing and supporting CLOS. We, too, will announce availability dates at IJCAI. Kevin Layer INTERNET: layer@franz.com Franz Inc. UUCP: uunet!franz!layer Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA19086; Tue, 27 Jun 89 10:56:25 -0700 Received: from Semillon.ms by ArpaGateway.ms ; 24 JUN 89 17:20:04 PDT Date: Sat, 24 Jun 89 17:16 PDT From: Gregor.pa@Xerox.COM Subject: Re: defconstructors To: rich@linus.MITRE.ORG Cc: CommonLoops.pa@Xerox.COM Fcc: BD:>Gregor>mail>outgoing-mail-7.text.newest In-Reply-To: <8906222132.AA19286@sabre.mitre.org> Message-Id: <19890625001639.9.GREGOR@SPIFF.parc.xerox.com> Line-Fold: no Date: Thu, 22 Jun 89 17:32:26 EDT From: rich@linus.MITRE.ORG Ignoring the issues that are involved in creating just such a constructor and have it handle initargs and initforms correctly, am I just on the wrong track altogether???? The constructors that result are enormous! My belief is that people should use the existing language features to create these interfaces. These features include DEFUN, MAKE-INSTANCE and the very powerful (hairy) lambda-list keywords facility. As an example, take the following `constructor': (defun make-foo (x y) (make-instance 'foo :x x :y y)) It is then the job of the underlying CLOS implementation to optimize these kinds of definitions. DEFCONSTRUCTOR was a temporary hack designed to get around the fact that PCL couldn't get from each Common Lisp the hooks it needed to "optimize these kinds of definitions". DEFCONSTRUCTOR was designed in such a way that it would be as easy as possible for people to later go through and convert all calls to DEFCONSTRUCTOR to calls to DEFUN and MAKE-INSTANCE. Given this belief, it may be that I would say you are on the wrong track by building such huge constructors. Rather I would agree with the following comment take from your message: Perhaps, the purpose of defconstructor was to have SPECIALIZED constructors for classes. In other words, when creating a FOO in situation 1 use MAKE-FOO-IN-SIT-1 and when creating a FOO in situation 2 use MAKE-FOO-IN-SIT-2, where the different siutations require different initargs, and the number of initargs used in a particular situation is few. I would say this is exactly the kind of thing you can and should do with named constructor functions created either with DEFCONSTRUCTOR or DEFUN and MAKE-INSTANCE. In her book Sonya Keene presents a good discussion of the kinds of reasons why you want to have special constructor functions this way. What time frame are we talking about? (to delete DEFCONSTRUCTOR) Little hard to say, it depends on how soon I get the right compiler hooks, but I want to do it in the next few weeks. ------- Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA24394; Tue, 27 Jun 89 17:14:42 -0700 Received: from Burger.ms by ArpaGateway.ms ; 27 JUN 89 10:59:23 PDT Return-Path: Redistributed: CommonLoops.PA Received: from uunet.uu.net ([192.48.96.2]) by Xerox.COM ; 27 JUN 89 10:55:22 PDT Received: by uunet.uu.net (5.61/1.14) with UUCP id AA06178; Tue, 27 Jun 89 13:55:06 -0400 Received: by franz.Franz.COM (MC 2.0/FI-1.0) id AA00438; Tue, 27 Jun 89 10:05:09 PDT Received: by snooze.Franz.COM (4.0/FI-1.0) id AA07440; Tue, 27 Jun 89 10:03:38-080 From: layer@franz.com (Kevin Layer) Message-Id: <8906271803.AA07440@snooze.Franz.COM> To: CommonLoops.PA@Xerox.COM Subject: Re: stuck in the middle In-Reply-To: Your message of Thu, 22 Jun 89 10:31:00 PDT. <19890622173122.9.GREGOR@SPIFF.parc.xerox.com> Date: Tue, 27 Jun 89 10:03:36 -0800 >> Moreover, those vendors who have refrained from advertising their CLOS >> work have, by doing so, made it appear that they are not developing a >> CLOS. That seems unfortunate and unfair. Yes, I did get some messages from people asking why we were not supporting CLOS. We are currently working on integrating CLOS into the debugger (both non-windowized and windowized versions). Also high priority is optimizing CLOS to make it as fast as possible. As a company, we are committed to using, developing, optimizing and supporting CLOS. We, too, will announce availability dates at IJCAI. Kevin Layer INTERNET: layer@franz.com Franz Inc. UUCP: uunet!franz!layer Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA24394; Tue, 27 Jun 89 17:14:42 -0700 Received: from Burger.ms by ArpaGateway.ms ; 27 JUN 89 10:59:23 PDT Return-Path: Redistributed: CommonLoops.PA Received: from uunet.uu.net ([192.48.96.2]) by Xerox.COM ; 27 JUN 89 10:55:22 PDT Received: by uunet.uu.net (5.61/1.14) with UUCP id AA06178; Tue, 27 Jun 89 13:55:06 -0400 Received: by franz.Franz.COM (MC 2.0/FI-1.0) id AA00438; Tue, 27 Jun 89 10:05:09 PDT Received: by snooze.Franz.COM (4.0/FI-1.0) id AA07440; Tue, 27 Jun 89 10:03:38-080 From: layer@franz.com (Kevin Layer) Message-Id: <8906271803.AA07440@snooze.Franz.COM> To: CommonLoops.PA@Xerox.COM Subject: Re: stuck in the middle In-Reply-To: Your message of Thu, 22 Jun 89 10:31:00 PDT. <19890622173122.9.GREGOR@SPIFF.parc.xerox.com> Date: Tue, 27 Jun 89 10:03:36 -0800 >> Moreover, those vendors who have refrained from advertising their CLOS >> work have, by doing so, made it appear that they are not developing a >> CLOS. That seems unfortunate and unfair. Yes, I did get some messages from people asking why we were not supporting CLOS. We are currently working on integrating CLOS into the debugger (both non-windowized and windowized versions). Also high priority is optimizing CLOS to make it as fast as possible. As a company, we are committed to using, developing, optimizing and supporting CLOS. We, too, will announce availability dates at IJCAI. Kevin Layer INTERNET: layer@franz.com Franz Inc. UUCP: uunet!franz!layer Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA16082; Wed, 28 Jun 89 17:12:18 -0700 Received: from Salvador.ms by ArpaGateway.ms ; 28 JUN 89 04:07:56 PDT Return-Path: <@lll-winken.uucp,@uunet.uucp,@prlb2.uucp,@prlhp1.uucp:gupta@prlhp1.uucp> Redistributed: CommonLoops.pa Received: from arisia.Xerox.COM ([13.1.100.206]) by Xerox.COM ; 28 JUN 89 04:03:38 PDT Received: from lll-winken.UUCP by arisia.Xerox.COM with UUCP (5.61+/IDA-1.2.8/gandalf) id AA04363; Wed, 28 Jun 89 04:00:58 -0700 Received: by lll-winken.llnl.gov (smail2.5) id AA21071; 28 Jun 89 03:38:40 PDT (Wed) Received: from prlb2.UUCP by uunet.uu.net (5.61/1.14) with UUCP id AA14476; Wed, 28 Jun 89 06:01:03 -0400 Received: by prlb2.UUCP (4.12/4.7) id AA08141; Wed, 28 Jun 89 11:49:49 +0100 Received: from apollo01.prl.philips.co.uk by prlhp1.prl.philips.co.uk; Wed, 28 Jun 89 10:10:30 bst From: Ashok Gupta Date: Wed, 28 Jun 89 10:53:08 bst Message-Id: <347.8906280953@apollo12.prl.philips.co.uk> Received: To: CommonLoops.pa@Xerox.COM Hi, I posted a plea for help almost two weeks ago but didn't see it in the Common-Loops mailing : it must have fallen foul of the problems at Xerox PARC with the mailer and NameServer. Anyway, here it is ... ---------------------------------------------------------------- Recently a *kind* gent mailed pearl-harbour pcl, *pcl-system-date* "12/7/88 Can't think of a cute name PCL", to me. I loaded defsys.lisp in a virgin image and eval'd (pcl::compile-pcl). Most of the files were compiled and loaded successfully, though with many warnings of the kind :- ;;; Warning: Redefining macro %LOGAND which used to be defined in file low.lisp and other macro redefinitions ..... ;;; Warning: Redefining function PRINT-IWMC-CLASS which used to be defined in file low.lisp and other function definitions ..... ;;; Warning: Variable I is bound but its value is ignored. and others ... ;;; Warning: The following functions are not known to be defined: loads of fn. names .... ;;; Warning: Misplaced declaration: (IGNORE DEPTH) ;;; Warning: Assuming LAMBDA-LIST-KEYWORDS is special until it came to compile high.lisp. The following is an edited transcript. Compiling HIGH... ;************ ;;; Reading input file #P"~lisp/ph-pcl/high.lisp" ;;; Compiling toplevel form...assembling...emitting...done. . . . ;;; Compiling function DESCRIBE-INSTANCE... ;;; Warning: Invalid form # in function lambda list >>Interrupt: access violation (OS/fault handler) ;************* LUCID:COMPILE-FORM: :A Abort to Lisp Top Level :C Resume Interrupted Instruction -> :b ; backtrace ;************ LUCID:COMPILE-FORM <- LUCID:COMPILE-FORM <- COMPILE-FILE <- LET <- IF <- PROGN <- BLOCK <- COMPILE-MODULE <- IF <- ECASE <- LET <- PROGN <- PROGN <- TAGBODY <- BLOCK <- PROGN <- LABELS <- LET <- PROGN <- LET <- BLOCK <- OPERATE-ON-SYSTEM <- RETURN-FROM <- IF <- PROGN <- BLOCK <- BLOCK <- COMPILE-PCL <- EVAL <- unnamed function -> :v ; show all args. LUCID:COMPILE-FORM: Local 0: (SYSTEM:DEFINE (QUOTE DESCRIBE-INSTANCE) (QUOTE FUNCTION) (FUNCTION (LAMBDA # #))) Local 1: LUCID::TOPLEVEL Local 2: # Local 3: (# # #) Local 4: 1 Local 5: # Local 6: # Local 7: 13048348 Local 8: # Local 9: 13048339 Local 10: (SYSTEM:DEFINE (QUOTE DESCRIBE-INSTANCE) (QUOTE FUNCTION) (FUNCTION (LAMBDA # #))) Local 11: # Local 12: 2 Local 13: 13048329 Local 14: LUCID::*WARNED-FUNCTIONS* Local 15: NIL Local 16: LUCID::*DEFERRING-INTERRUPTS* Local 17: NIL Local 18: SYSTEM:DEFINE Local 19: NIL Local 20: DESCRIBE-INSTANCE Local 21: FUNCTION Local 22: (LAMBDA (OBJECT &OPTIONAL (STREAM T)) (BLOCK DESCRIBE-INSTANCE (LET* # # # # # # # # #))) Local 23: # Local 24: 2 Local 25: 13048323 Local 26: LUCID::*ORIGINAL-VNAMES* Local 27: NIL Local 28: LUCID::*FUNCTION-NAME-PRINTED* Local 29: NIL Local 30: DESCRIBE-INSTANCE Local 31: # Local 32: 1 plus 3 more locals (max = 35, use :L to see one, :V 35 to see all.) -> :L Name or number of variable: 33 13048311 -> :L 34 LUCID::*CURRENT-FUNCTION* -> :L 35 NIL ---------------------------------------------------------------- I then tried the following (suggested by Yasuhiko Kiuchi, from a posting by Lee Barford) :- (in-package :lucid :nicknames '(lucid-common-lisp)) ;it uses a wrong name (export '(*redefinition-action*)) ; it assumes this is global (in-package :user) (load "defsys.lisp") (pcl::compile-pcl) but when it came to compile high.lisp, got :- . . . ;;; Compiling function BUILT-IN-WRAPPER-OF...assembling...emitting...done. ;;; Compiling function BUILT-IN-CLASS-OF...assembling...sharing list... sharing code...emitting...done. >>Error: No matching method for the generic-function #, when called with arguments (#< >>Error: No matching method for the generic-function #,when called with arguments (#). |(METHOD PRINT-OBJECT (T T))|: Required arg 0 (INSTANCE): # Required arg 1 (STREAM): # :A Abort to Lisp Top Level -> :b ;backtrace ****************** |(METHOD PRINT-OBJECT (T T))| <- NOTICE-METHODS-CHANGE-2 <- PRIN1 <- FORMAT <- ERROR <- NOTICE-METHODS-CHANGE-2 <- unnamed function <- METHOD-PROTOTYPE-FOR-GF <- DEFMETHOD <- LUCID:COMPILE-FORM <- COMPILE-FILE <- EVAL <- unnamed function Apologies for the length of this note. *Any* clues would be *appreciated*. Thanks, Ashok "Ash" Gupta Post : Philips Research Labs, Crossoak Lane, Redhill, Surrey, RH1 5HA, U.K. Voice : +44 293 785544 ext 5647 email : gupta@prl.philips.co.uk Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA16082; Wed, 28 Jun 89 17:12:18 -0700 Received: from Salvador.ms by ArpaGateway.ms ; 28 JUN 89 04:07:56 PDT Return-Path: <@lll-winken.uucp,@uunet.uucp,@prlb2.uucp,@prlhp1.uucp:gupta@prlhp1.uucp> Redistributed: CommonLoops.pa Received: from arisia.Xerox.COM ([13.1.100.206]) by Xerox.COM ; 28 JUN 89 04:03:38 PDT Received: from lll-winken.UUCP by arisia.Xerox.COM with UUCP (5.61+/IDA-1.2.8/gandalf) id AA04363; Wed, 28 Jun 89 04:00:58 -0700 Received: by lll-winken.llnl.gov (smail2.5) id AA21071; 28 Jun 89 03:38:40 PDT (Wed) Received: from prlb2.UUCP by uunet.uu.net (5.61/1.14) with UUCP id AA14476; Wed, 28 Jun 89 06:01:03 -0400 Received: by prlb2.UUCP (4.12/4.7) id AA08141; Wed, 28 Jun 89 11:49:49 +0100 Received: from apollo01.prl.philips.co.uk by prlhp1.prl.philips.co.uk; Wed, 28 Jun 89 10:10:30 bst From: Ashok Gupta Date: Wed, 28 Jun 89 10:53:08 bst Message-Id: <347.8906280953@apollo12.prl.philips.co.uk> To: CommonLoops.pa@Xerox.COM Hi, I posted a plea for help almost two weeks ago but didn't see it in the Common-Loops mailing : it must have fallen foul of the problems at Xerox PARC with the mailer and NameServer. Anyway, here it is ... ---------------------------------------------------------------- Recently a *kind* gent mailed pearl-harbour pcl, *pcl-system-date* "12/7/88 Can't think of a cute name PCL", to me. I loaded defsys.lisp in a virgin image and eval'd (pcl::compile-pcl). Most of the files were compiled and loaded successfully, though with many warnings of the kind :- ;;; Warning: Redefining macro %LOGAND which used to be defined in file low.lisp and other macro redefinitions ..... ;;; Warning: Redefining function PRINT-IWMC-CLASS which used to be defined in file low.lisp and other function definitions ..... ;;; Warning: Variable I is bound but its value is ignored. and others ... ;;; Warning: The following functions are not known to be defined: loads of fn. names .... ;;; Warning: Misplaced declaration: (IGNORE DEPTH) ;;; Warning: Assuming LAMBDA-LIST-KEYWORDS is special until it came to compile high.lisp. The following is an edited transcript. Compiling HIGH... ;************ ;;; Reading input file #P"~lisp/ph-pcl/high.lisp" ;;; Compiling toplevel form...assembling...emitting...done. . . . ;;; Compiling function DESCRIBE-INSTANCE... ;;; Warning: Invalid form # in function lambda list >>Interrupt: access violation (OS/fault handler) ;************* LUCID:COMPILE-FORM: :A Abort to Lisp Top Level :C Resume Interrupted Instruction -> :b ; backtrace ;************ LUCID:COMPILE-FORM <- LUCID:COMPILE-FORM <- COMPILE-FILE <- LET <- IF <- PROGN <- BLOCK <- COMPILE-MODULE <- IF <- ECASE <- LET <- PROGN <- PROGN <- TAGBODY <- BLOCK <- PROGN <- LABELS <- LET <- PROGN <- LET <- BLOCK <- OPERATE-ON-SYSTEM <- RETURN-FROM <- IF <- PROGN <- BLOCK <- BLOCK <- COMPILE-PCL <- EVAL <- unnamed function -> :v ; show all args. LUCID:COMPILE-FORM: Local 0: (SYSTEM:DEFINE (QUOTE DESCRIBE-INSTANCE) (QUOTE FUNCTION) (FUNCTION (LAMBDA # #))) Local 1: LUCID::TOPLEVEL Local 2: # Local 3: (# # #) Local 4: 1 Local 5: # Local 6: # Local 7: 13048348 Local 8: # Local 9: 13048339 Local 10: (SYSTEM:DEFINE (QUOTE DESCRIBE-INSTANCE) (QUOTE FUNCTION) (FUNCTION (LAMBDA # #))) Local 11: # Local 12: 2 Local 13: 13048329 Local 14: LUCID::*WARNED-FUNCTIONS* Local 15: NIL Local 16: LUCID::*DEFERRING-INTERRUPTS* Local 17: NIL Local 18: SYSTEM:DEFINE Local 19: NIL Local 20: DESCRIBE-INSTANCE Local 21: FUNCTION Local 22: (LAMBDA (OBJECT &OPTIONAL (STREAM T)) (BLOCK DESCRIBE-INSTANCE (LET* # # # # # # # # #))) Local 23: # Local 24: 2 Local 25: 13048323 Local 26: LUCID::*ORIGINAL-VNAMES* Local 27: NIL Local 28: LUCID::*FUNCTION-NAME-PRINTED* Local 29: NIL Local 30: DESCRIBE-INSTANCE Local 31: # Local 32: 1 plus 3 more locals (max = 35, use :L to see one, :V 35 to see all.) -> :L Name or number of variable: 33 13048311 -> :L 34 LUCID::*CURRENT-FUNCTION* -> :L 35 NIL ---------------------------------------------------------------- I then tried the following (suggested by Yasuhiko Kiuchi, from a posting by Lee Barford) :- (in-package :lucid :nicknames '(lucid-common-lisp)) ;it uses a wrong name (export '(*redefinition-action*)) ; it assumes this is global (in-package :user) (load "defsys.lisp") (pcl::compile-pcl) but when it came to compile high.lisp, got :- . . . ;;; Compiling function BUILT-IN-WRAPPER-OF...assembling...emitting...done. ;;; Compiling function BUILT-IN-CLASS-OF...assembling...sharing list... sharing code...emitting...done. >>Error: No matching method for the generic-function #, when called with arguments (#< >>Error: No matching method for the generic-function #,when called with arguments (#). |(METHOD PRINT-OBJECT (T T))|: Required arg 0 (INSTANCE): # Required arg 1 (STREAM): # :A Abort to Lisp Top Level -> :b ;backtrace ****************** |(METHOD PRINT-OBJECT (T T))| <- NOTICE-METHODS-CHANGE-2 <- PRIN1 <- FORMAT <- ERROR <- NOTICE-METHODS-CHANGE-2 <- unnamed function <- METHOD-PROTOTYPE-FOR-GF <- DEFMETHOD <- LUCID:COMPILE-FORM <- COMPILE-FILE <- EVAL <- unnamed function Apologies for the length of this note. *Any* clues would be *appreciated*. Thanks, Ashok "Ash" Gupta Post : Philips Research Labs, Crossoak Lane, Redhill, Surrey, RH1 5HA, U.K. Voice : +44 293 785544 ext 5647 email : gupta@prl.philips.co.uk Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA00595; Wed, 28 Jun 89 18:51:55 -0700 Received: from Semillon.ms by ArpaGateway.ms ; 28 JUN 89 14:53:28 PDT Return-Path: Redistributed: commonloops.pa Received: from Think.COM ([131.239.2.1]) by Xerox.COM ; 28 JUN 89 14:17:53 PDT Return-Path: Received: from FAUSTINUS.THINK.COM by Think.COM; Wed, 28 Jun 89 15:04:05 EDT Date: Wed, 28 Jun 89 15:02 EDT From: Jim Salem Subject: Lacking exports in Victoria Day PCL To: commonloops.pa@Xerox.COM Message-Id: <19890628190217.1.SALEM@FAUSTINUS.THINK.COM> I believe the following symbols should be exported from PCL : standard-class built-in-class structure-class standard-object object They are not exported in the Victoria Day version. -- jim salem@think.com Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA00625; Wed, 28 Jun 89 18:54:07 -0700 Received: from Cabernet.ms by ArpaGateway.ms ; 28 JUN 89 17:47:20 PDT Date: 28 Jun 89 17:45 PDT From: kiuchi.pa@Xerox.COM Subject: CommonLoops mailing list To: CommonLoops.pa@Xerox.COM Reply-To: CommonLoops-request.pa@Xerox.COM Cc: kiuchi.pa@Xerox.COM Message-Id: <890628-174720-1302@Xerox> (1)The mailing-list problem: We have not fixed the problems of the mailer using for external redistribution of CommonLoops@Xerox.com mailing list and still working on it. (2)The mailing-list requests or other administrative stuff to CommonLoops-request@Xerox.com: I will be out of town from tomorrow(6/29) and will be back on 7/10. I will start replying the messages when I get back. Thanks. Yasuhiko Kiuchi (Kiuchi.pa@Xerox.com) ---------- Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA16082; Wed, 28 Jun 89 17:12:18 -0700 Received: from Salvador.ms by ArpaGateway.ms ; 28 JUN 89 04:07:56 PDT Return-Path: <@lll-winken.uucp,@uunet.uucp,@prlb2.uucp,@prlhp1.uucp:gupta@prlhp1.uucp> Redistributed: CommonLoops.pa Received: from arisia.Xerox.COM ([13.1.100.206]) by Xerox.COM ; 28 JUN 89 04:03:38 PDT Received: from lll-winken.UUCP by arisia.Xerox.COM with UUCP (5.61+/IDA-1.2.8/gandalf) id AA04363; Wed, 28 Jun 89 04:00:58 -0700 Received: by lll-winken.llnl.gov (smail2.5) id AA21071; 28 Jun 89 03:38:40 PDT (Wed) Received: from prlb2.UUCP by uunet.uu.net (5.61/1.14) with UUCP id AA14476; Wed, 28 Jun 89 06:01:03 -0400 Received: by prlb2.UUCP (4.12/4.7) id AA08141; Wed, 28 Jun 89 11:49:49 +0100 Received: from apollo01.prl.philips.co.uk by prlhp1.prl.philips.co.uk; Wed, 28 Jun 89 10:10:30 bst From: Ashok Gupta Date: Wed, 28 Jun 89 10:53:08 bst Message-Id: <347.8906280953@apollo12.prl.philips.co.uk> To: CommonLoops.pa@Xerox.COM Hi, I posted a plea for help almost two weeks ago but didn't see it in the Common-Loops mailing : it must have fallen foul of the problems at Xerox PARC with the mailer and NameServer. Anyway, here it is ... ---------------------------------------------------------------- Recently a *kind* gent mailed pearl-harbour pcl, *pcl-system-date* "12/7/88 Can't think of a cute name PCL", to me. I loaded defsys.lisp in a virgin image and eval'd (pcl::compile-pcl). Most of the files were compiled and loaded successfully, though with many warnings of the kind :- ;;; Warning: Redefining macro %LOGAND which used to be defined in file low.lisp and other macro redefinitions ..... ;;; Warning: Redefining function PRINT-IWMC-CLASS which used to be defined in file low.lisp and other function definitions ..... ;;; Warning: Variable I is bound but its value is ignored. and others ... ;;; Warning: The following functions are not known to be defined: loads of fn. names .... ;;; Warning: Misplaced declaration: (IGNORE DEPTH) ;;; Warning: Assuming LAMBDA-LIST-KEYWORDS is special until it came to compile high.lisp. The following is an edited transcript. Compiling HIGH... ;************ ;;; Reading input file #P"~lisp/ph-pcl/high.lisp" ;;; Compiling toplevel form...assembling...emitting...done. . . . ;;; Compiling function DESCRIBE-INSTANCE... ;;; Warning: Invalid form # in function lambda list >>Interrupt: access violation (OS/fault handler) ;************* LUCID:COMPILE-FORM: :A Abort to Lisp Top Level :C Resume Interrupted Instruction -> :b ; backtrace ;************ LUCID:COMPILE-FORM <- LUCID:COMPILE-FORM <- COMPILE-FILE <- LET <- IF <- PROGN <- BLOCK <- COMPILE-MODULE <- IF <- ECASE <- LET <- PROGN <- PROGN <- TAGBODY <- BLOCK <- PROGN <- LABELS <- LET <- PROGN <- LET <- BLOCK <- OPERATE-ON-SYSTEM <- RETURN-FROM <- IF <- PROGN <- BLOCK <- BLOCK <- COMPILE-PCL <- EVAL <- unnamed function -> :v ; show all args. LUCID:COMPILE-FORM: Local 0: (SYSTEM:DEFINE (QUOTE DESCRIBE-INSTANCE) (QUOTE FUNCTION) (FUNCTION (LAMBDA # #))) Local 1: LUCID::TOPLEVEL Local 2: # Local 3: (# # #) Local 4: 1 Local 5: # Local 6: # Local 7: 13048348 Local 8: # Local 9: 13048339 Local 10: (SYSTEM:DEFINE (QUOTE DESCRIBE-INSTANCE) (QUOTE FUNCTION) (FUNCTION (LAMBDA # #))) Local 11: # Local 12: 2 Local 13: 13048329 Local 14: LUCID::*WARNED-FUNCTIONS* Local 15: NIL Local 16: LUCID::*DEFERRING-INTERRUPTS* Local 17: NIL Local 18: SYSTEM:DEFINE Local 19: NIL Local 20: DESCRIBE-INSTANCE Local 21: FUNCTION Local 22: (LAMBDA (OBJECT &OPTIONAL (STREAM T)) (BLOCK DESCRIBE-INSTANCE (LET* # # # # # # # # #))) Local 23: # Local 24: 2 Local 25: 13048323 Local 26: LUCID::*ORIGINAL-VNAMES* Local 27: NIL Local 28: LUCID::*FUNCTION-NAME-PRINTED* Local 29: NIL Local 30: DESCRIBE-INSTANCE Local 31: # Local 32: 1 plus 3 more locals (max = 35, use :L to see one, :V 35 to see all.) -> :L Name or number of variable: 33 13048311 -> :L 34 LUCID::*CURRENT-FUNCTION* -> :L 35 NIL ---------------------------------------------------------------- I then tried the following (suggested by Yasuhiko Kiuchi, from a posting by Lee Barford) :- (in-package :lucid :nicknames '(lucid-common-lisp)) ;it uses a wrong name (export '(*redefinition-action*)) ; it assumes this is global (in-package :user) (load "defsys.lisp") (pcl::compile-pcl) but when it came to compile high.lisp, got :- . . . ;;; Compiling function BUILT-IN-WRAPPER-OF...assembling...emitting...done. ;;; Compiling function BUILT-IN-CLASS-OF...assembling...sharing list... sharing code...emitting...done. >>Error: No matching method for the generic-function #, when called with arguments (#< >>Error: No matching method for the generic-function #,when called with arguments (#). |(METHOD PRINT-OBJECT (T T))|: Required arg 0 (INSTANCE): # Required arg 1 (STREAM): # :A Abort to Lisp Top Level -> :b ;backtrace ****************** |(METHOD PRINT-OBJECT (T T))| <- NOTICE-METHODS-CHANGE-2 <- PRIN1 <- FORMAT <- ERROR <- NOTICE-METHODS-CHANGE-2 <- unnamed function <- METHOD-PROTOTYPE-FOR-GF <- DEFMETHOD <- LUCID:COMPILE-FORM <- COMPILE-FILE <- EVAL <- unnamed function Apologies for the length of this note. *Any* clues would be *appreciated*. Thanks, Ashok "Ash" Gupta Post : Philips Research Labs, Crossoak Lane, Redhill, Surrey, RH1 5HA, U.K. Voice : +44 293 785544 ext 5647 email : gupta@prl.philips.co.uk Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA16082; Wed, 28 Jun 89 17:12:18 -0700 Received: from Salvador.ms by ArpaGateway.ms ; 28 JUN 89 04:07:56 PDT Return-Path: <@lll-winken.uucp,@uunet.uucp,@prlb2.uucp,@prlhp1.uucp:gupta@prlhp1.uucp> Redistributed: CommonLoops.pa Received: from arisia.Xerox.COM ([13.1.100.206]) by Xerox.COM ; 28 JUN 89 04:03:38 PDT Received: from lll-winken.UUCP by arisia.Xerox.COM with UUCP (5.61+/IDA-1.2.8/gandalf) id AA04363; Wed, 28 Jun 89 04:00:58 -0700 Received: by lll-winken.llnl.gov (smail2.5) id AA21071; 28 Jun 89 03:38:40 PDT (Wed) Received: from prlb2.UUCP by uunet.uu.net (5.61/1.14) with UUCP id AA14476; Wed, 28 Jun 89 06:01:03 -0400 Received: by prlb2.UUCP (4.12/4.7) id AA08141; Wed, 28 Jun 89 11:49:49 +0100 Received: from apollo01.prl.philips.co.uk by prlhp1.prl.philips.co.uk; Wed, 28 Jun 89 10:10:30 bst From: Ashok Gupta Date: Wed, 28 Jun 89 10:53:08 bst Message-Id: <347.8906280953@apollo12.prl.philips.co.uk> To: CommonLoops.pa@Xerox.COM Hi, I posted a plea for help almost two weeks ago but didn't see it in the Common-Loops mailing : it must have fallen foul of the problems at Xerox PARC with the mailer and NameServer. Anyway, here it is ... ---------------------------------------------------------------- Recently a *kind* gent mailed pearl-harbour pcl, *pcl-system-date* "12/7/88 Can't think of a cute name PCL", to me. I loaded defsys.lisp in a virgin image and eval'd (pcl::compile-pcl). Most of the files were compiled and loaded successfully, though with many warnings of the kind :- ;;; Warning: Redefining macro %LOGAND which used to be defined in file low.lisp and other macro redefinitions ..... ;;; Warning: Redefining function PRINT-IWMC-CLASS which used to be defined in file low.lisp and other function definitions ..... ;;; Warning: Variable I is bound but its value is ignored. and others ... ;;; Warning: The following functions are not known to be defined: loads of fn. names .... ;;; Warning: Misplaced declaration: (IGNORE DEPTH) ;;; Warning: Assuming LAMBDA-LIST-KEYWORDS is special until it came to compile high.lisp. The following is an edited transcript. Compiling HIGH... ;************ ;;; Reading input file #P"~lisp/ph-pcl/high.lisp" ;;; Compiling toplevel form...assembling...emitting...done. . . . ;;; Compiling function DESCRIBE-INSTANCE... ;;; Warning: Invalid form # in function lambda list >>Interrupt: access violation (OS/fault handler) ;************* LUCID:COMPILE-FORM: :A Abort to Lisp Top Level :C Resume Interrupted Instruction -> :b ; backtrace ;************ LUCID:COMPILE-FORM <- LUCID:COMPILE-FORM <- COMPILE-FILE <- LET <- IF <- PROGN <- BLOCK <- COMPILE-MODULE <- IF <- ECASE <- LET <- PROGN <- PROGN <- TAGBODY <- BLOCK <- PROGN <- LABELS <- LET <- PROGN <- LET <- BLOCK <- OPERATE-ON-SYSTEM <- RETURN-FROM <- IF <- PROGN <- BLOCK <- BLOCK <- COMPILE-PCL <- EVAL <- unnamed function -> :v ; show all args. LUCID:COMPILE-FORM: Local 0: (SYSTEM:DEFINE (QUOTE DESCRIBE-INSTANCE) (QUOTE FUNCTION) (FUNCTION (LAMBDA # #))) Local 1: LUCID::TOPLEVEL Local 2: # Local 3: (# # #) Local 4: 1 Local 5: # Local 6: # Local 7: 13048348 Local 8: # Local 9: 13048339 Local 10: (SYSTEM:DEFINE (QUOTE DESCRIBE-INSTANCE) (QUOTE FUNCTION) (FUNCTION (LAMBDA # #))) Local 11: # Local 12: 2 Local 13: 13048329 Local 14: LUCID::*WARNED-FUNCTIONS* Local 15: NIL Local 16: LUCID::*DEFERRING-INTERRUPTS* Local 17: NIL Local 18: SYSTEM:DEFINE Local 19: NIL Local 20: DESCRIBE-INSTANCE Local 21: FUNCTION Local 22: (LAMBDA (OBJECT &OPTIONAL (STREAM T)) (BLOCK DESCRIBE-INSTANCE (LET* # # # # # # # # #))) Local 23: # Local 24: 2 Local 25: 13048323 Local 26: LUCID::*ORIGINAL-VNAMES* Local 27: NIL Local 28: LUCID::*FUNCTION-NAME-PRINTED* Local 29: NIL Local 30: DESCRIBE-INSTANCE Local 31: # Local 32: 1 plus 3 more locals (max = 35, use :L to see one, :V 35 to see all.) -> :L Name or number of variable: 33 13048311 -> :L 34 LUCID::*CURRENT-FUNCTION* -> :L 35 NIL ---------------------------------------------------------------- I then tried the following (suggested by Yasuhiko Kiuchi, from a posting by Lee Barford) :- (in-package :lucid :nicknames '(lucid-common-lisp)) ;it uses a wrong name (export '(*redefinition-action*)) ; it assumes this is global (in-package :user) (load "defsys.lisp") (pcl::compile-pcl) but when it came to compile high.lisp, got :- . . . ;;; Compiling function BUILT-IN-WRAPPER-OF...assembling...emitting...done. ;;; Compiling function BUILT-IN-CLASS-OF...assembling...sharing list... sharing code...emitting...done. >>Error: No matching method for the generic-function #, when called with arguments (#< >>Error: No matching method for the generic-function #,when called with arguments (#). |(METHOD PRINT-OBJECT (T T))|: Required arg 0 (INSTANCE): # Required arg 1 (STREAM): # :A Abort to Lisp Top Level -> :b ;backtrace ****************** |(METHOD PRINT-OBJECT (T T))| <- NOTICE-METHODS-CHANGE-2 <- PRIN1 <- FORMAT <- ERROR <- NOTICE-METHODS-CHANGE-2 <- unnamed function <- METHOD-PROTOTYPE-FOR-GF <- DEFMETHOD <- LUCID:COMPILE-FORM <- COMPILE-FILE <- EVAL <- unnamed function Apologies for the length of this note. *Any* clues would be *appreciated*. Thanks, Ashok "Ash" Gupta Post : Philips Research Labs, Crossoak Lane, Redhill, Surrey, RH1 5HA, U.K. Voice : +44 293 785544 ext 5647 email : gupta@prl.philips.co.uk Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA19424; Mon, 3 Jul 89 11:59:50 -0700 Received: from Cabernet.ms by ArpaGateway.ms ; 03 JUL 89 11:54:12 PDT Return-Path: Redistributed: CommonLoops.PA Received: from Moe.McRCIM.McGill.EDU ([132.206.4.1]) by Xerox.COM ; 03 JUL 89 11:52:03 PDT Received: by Moe.McRCIM.McGill.EDU (5.54) id <8907031850.AA10803@Moe.McRCIM.McGill.EDU>; Mon, 3 Jul 89 14:50:53 EDT Date: Mon, 3 Jul 89 14:50:53 EDT From: Martin Boyer Message-Id: <8907031850.AA10803@Moe.McRCIM.McGill.EDU> To: CommonLoops.PA@Xerox.COM Subject: Using nonstandard method-class in generic-functions Cc: gamin@Moe.McRCIM.McGill.EDU I am trying to define my own class of methods using Victoria Day PCL on Lucid 3.0.2. I am having a problem using DEFMETHOD on generic functions when the method class (defined through GENERIC-FUNCTION-METHOD-CLASS) is not STANDARD-METHOD. It may be a PCL bug somewhere, but I'm not really good enough to tell. From the following transcript, perhaps some kind soul can tell me what is going wrong: ;;; Given the following definitions: (defclass widget () ( (position :accessor widget-position :initform nil) ) ) ;;;; ACTION-METHOD ;;; This is simply a standard method with additional slots. ;;; (defclass action-method (standard-method) ( (type :reader action-type) ) ) ;;; The following is an edited transcript: > (setq gf (ensure-generic-function 'hello :lambda-list '(object))) # > (setf (pcl::generic-function-method-class gf) (find-class 'action-method)) # > (describe gf) # is an instance of class #: The following slots have :INSTANCE allocation: NAME HELLO METHODS NIL DISCRIMINATOR-CODE NIL CLASSICAL-METHOD-TABLE NIL COMBINED-METHODS NIL CACHE NIL VALID-P NIL PRETTY-ARGLIST NIL METHOD-CLASS # DISPATCH-ORDER :DEFAULT > (defmethod hello ( (self widget) ) (format t "~A (a widget) says hello.~%" self) ) >>Error: The value of ARRAY, NIL, should be of type (ARRAY * (*)) LUCID-RUNTIME-SUPPORT:1DIM-AREF-SUBR: Required arg 0 (ARRAY): NIL Required arg 1 (I): 3 :C 0: Use a new value :A 1: Abort to Lisp Top Level -> :a Abort to Lisp Top Level Back to Lisp Top Level > (quit) Note that if I use (setf (pcl::generic-function-method-class gf) (find-class 'standard-method)) instead, I don't get the error. By the way, many thanks to kanderso@DINO.BBN.COM for the ENSURE-GENERIC-FUNCTION and GET-METHOD tricks that allowed me to get this far. Thanks, Martin -- Martin Boyer McGill Research Centre for Intelligent Machines McGill University, Montreal, QC gamin@larry.mcrcim.mcgill.edu gamin@mcgill-vision.uucp Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA04908; Tue, 4 Jul 89 18:21:06 -0700 Received: from Semillon.ms by ArpaGateway.ms ; 04 JUL 89 18:23:28 PDT Date: Tue, 4 Jul 89 18:19 PDT From: Gregor.pa@Xerox.COM Subject: Re: Bug in printing lexical closures (Genera) To: rich@linus.MITRE.ORG Cc: CommonLoops.pa@Xerox.COM Fcc: BD:>Gregor>mail>outgoing-mail-7.text.newest In-Reply-To: <8906222056.AA19252@sabre.mitre.org> Message-Id: <19890705011911.4.GREGOR@SPIFF.parc.xerox.com> Line-Fold: no Date: Thu, 22 Jun 89 16:56:38 EDT From: rich@linus.MITRE.ORG In fin.lisp, PCL-PRINT-LEXICAL-CLOSURE is used to print lexical closures and funcallable instances. However, this will cause SI:PRINT-LEXICAL-CLOSURE to be sent 4 args, when it only takes 3 (it doesn't take depth). In 7.4 it takes all four arguments which is how it got to say that in the PCL source. I commented out the depth arg and both lexical closures and funcallable instances seem to print out just fine. However, the depth arg was there for some reason. What is the "real" fix? I don't know what the real fix is, but as you observe your fix works. At least for now I am just putting in your fix. ------- Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA12576; Wed, 5 Jul 89 05:36:48 -0700 Received: from Semillon.ms by ArpaGateway.ms ; 05 JUL 89 05:38:13 PDT Return-Path: Redistributed: CommonLoops.PA Received: from uunet.uu.net ([192.48.96.2]) by Xerox.COM ; 05 JUL 89 05:35:41 PDT Received: from unido.UUCP by uunet.uu.net (5.61/1.14) with UUCP id AA29614; Wed, 5 Jul 89 08:35:29 -0400 Received: from sbsvax.uucp by unido.informatik.uni-dortmund.de with uucp via EUnet for uunet id AM04373; Wed, 5 Jul 89 12:36:24 +0100 Received: by sbsvax.uucp; Tue, 4 Jul 89 17:18:36 +0200 (MET dst) From: "Gerd Herzog" Date: Tue, 4 Jul 89 17:18:33 +0200 (MET dst) Message-Id: <8907041518.AA14950@fb10vax.sbsvax.uucp> Received: by fb10vax.sbsvax.uucp; Tue, 4 Jul 89 17:18:33 +0200 (MET dst) To: CommonLoops.PA@Xerox.COM Subject: WANTED: CLOS Browser Recently, we have installed the AAAI PCL version of PCL on our different machines, including a Xerox 1186 AI workstation running the Lyric Release. Could somebody please give us a hint on how to get an updated version of the Interim CLOS Browser which is compatibel with AAAI PCL ? By the way, is there a CLOS Browser for the Symbolics (Rel. 7.1) out there ? Fanx in advance, Duke ------------------------------------------------------------------ |NET: herzog%sbsvax@unido.uucp (via uunet, relay.cs.net,...) | | herzog@fb10vax.informatik.uni-saarland.dbp.de | | (via relay.cs.net, if some mailer doesn't understand '.de')| | It's a long address, but it's X400! (;-) | |----------------------------------------------------------------| |POST: Gerd Herzog | PHONE: +49-681-302-4135| | FB 10 - Informatik IV |------------------------| | Universitaet des Saarlandes | | | Im Stadtwald 15 | | | D-6600 Saarbruecken 11 | | | Federal Republic of Germany | | ------------------------------------------------------------------ Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA00810; Thu, 6 Jul 89 07:20:36 -0700 Received: from Burger.ms by ArpaGateway.ms ; 06 JUL 89 06:35:36 PDT Return-Path: Redistributed: CommonLoops.pa Received: from siemens.siemens.com ([129.73.10.1]) by Xerox.COM ; 06 JUL 89 06:33:28 PDT Received: by siemens.siemens.com (5.54/1.15) id AA03892; Thu, 6 Jul 89 09:33:53 EST From: jutta@ztivax.siemens.com (Jutta Estenfeld) Date: Thu, 6 Jul 89 15:31:58 -0200 Message-Id: <8907061331.AA28683@ztivax.uucp> Received: by ztivax.uucp; Thu, 6 Jul 89 15:31:58 -0200 To: CommonLoops.pa@Xerox.COM Subject: bug in eql-specializer methods I think there is a bug in the Victoria Day (5/22/89) Version of PCL (Xerox CL (Lyric) and Lucid CL 2.1) if you define eql-specializer methods for make-instance: I define a class my-class and a method for make-instance to do some specific things when my-class will be instantiated: (defclass my-class () ()) (defmethod make-instance ((class (eql (find-class 'my-class)))) ;; some specifics (format t "make-instance of class ~a~%" class) (call-next-method)) Evaluating this call of defmethod an error is signalled: No matching method for the generic-function .. UPDATE-CONSTRUCTORS .. when called with arguments ((EQL #)) If I evaluate the call of defmethod once more the same error is signalled. It's okay, but now the class standard-class doesn't know its subclasses any more: (class-direct-subclasses (find-class 'standard-class)) evaluates to nil. In all cases (you can also try it with metaclasses) the metaclass of the class with the eql-specializer method for make-instance looses the link to its subclasses. Jutta Estenfeld Siemens AG, Munich, West Germany jutta@ztivax.uucp Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA01087; Thu, 6 Jul 89 07:49:01 -0700 Received: from Burger.ms by ArpaGateway.ms ; 06 JUL 89 07:51:08 PDT Return-Path: Redistributed: commonloops.pa Received: from lucid.com ([192.26.25.1]) by Xerox.COM ; 06 JUL 89 07:49:33 PDT Received: from bhopal ([192.43.178.13]) by heavens-gate id AA06206g; Thu, 6 Jul 89 07:46:41 PDT Received: by bhopal id AA01046g; Wed, 5 Jul 89 22:02:21 PDT Date: Wed, 5 Jul 89 22:02:21 PDT From: Jon L White Message-Id: <8907060502.AA01046@bhopal> To: hall@aic.nrl.navy.mil, barford@hpllab.hp.com Cc: commonloops.pa@Xerox.COM In-Reply-To: Lawrence Hall's message of Tue, 20 Jun 89 14:01:16 EDT <8906201801.AA22933@aic.nrl.navy.mil> Subject: Problem compiling Victoria Day PCL Hmmm, I quite frankly don't see how any of the PCL in recent times could work in a Lucid Lisp of the vintage you have -- Sun 2.1.1. My copy of that release here doesn't even have the symbol LUCID::AUGMENT-LEXENV-FVARS-DUMMY in it. However, I do notice patched-up definition of it in walk.lisp as follows: #+Prime (defun lucid::augment-lexenv-fvars-dummy (lexical vars) (lucid::augment-lexenv-fvars-aux lexical vars '() '() 'flet '())) Perhaps that #+Prime should be extended to cover this case as well. A first cut would be #+(or Prime (and mc68000 sun (not lcl3.0))) The problem solved by the reply from barford@hpllab.hp.com is, I think, a different one. Gregor: current release has one place in defs.lisp and one in boot.lisp where the token lucid-common-lisp:*redefinition-action* occurs [one place uses two colons]. Sad to say, if you don't import this symbol into the PCL package, it will have to be qualified differently depending on whether it is the 2.1 or 3.0 release. I would approve of yet another resort to the kludge of doing it as lucid::*redefinition-action* in these two instances. -- JonL -- Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA01107; Thu, 6 Jul 89 07:51:59 -0700 Received: from Chardonnay.ms by ArpaGateway.ms ; 06 JUL 89 07:54:05 PDT Return-Path: Redistributed: commonloops.pa Received: from lucid.com ([192.26.25.1]) by Xerox.COM ; 06 JUL 89 07:50:01 PDT Received: from bhopal ([192.43.178.13]) by heavens-gate id AA06209g; Thu, 6 Jul 89 07:46:49 PDT Received: by bhopal id AA01004g; Wed, 5 Jul 89 21:40:09 PDT Date: Wed, 5 Jul 89 21:40:09 PDT From: Jon L White Message-Id: <8907060440.AA01004@bhopal> To: Gregor.pa@Xerox.COM Cc: kanderso@DINO.BBN.COM, commonloops.pa@Xerox.COM, Jmorrill@DINO.BBN.COM, jonl@lucid.com In-Reply-To: Gregor.pa@Xerox.COM's message of Sat, 24 Jun 89 16:21 PDT <19890624232110.7.GREGOR@SPIFF.parc.xerox.com> Subject: recursive cache expanding bug re: [Ken]: I installed this change. 2. Suppose something calls CLASS-DIRECT-SUBCLASSES, EXPAND-DCODE-CACHE is called to expand the cache of CLASS-DIRECT-SUBCLASSES and either GENERIC-FUNCTION-CACHE or SLOT-VALUE-USING-CLASS are invalidated. Then the innocent looking line (Is this really another cache locking issue?) [Gregor]: Sort of, it also resembles the metacircularity issues of having to call a generic function as part of updating that same generic function. . . . I think it really is the metacircularity issue. Isn't that the main reason you have the parallel slot-reader interfaces SLOT-VALUE--FSC and SLOT-VALUE--STD? Alternatively, the line: (setf (generic-function-cache generic-function) new-cache) could easily have been written: (setf (slot-value generic-function 'cache) new-cache) and the circular dependency would have been avoided. In this particular, case the slow-down implied by going through SLOT-VALUE-ABUSING-CLASS (rather than through some sort of setf on SLOT-VALUE--FSC) could hardly be noticeable, given all that cache-expansion entails. One amusing consequence of the use of *INVALID-GENERIC-FUNCTIONS-ON-STACK* in NOTICE-METHODS-CHANGE-2 is that it masks a whole slew of metacircular references. Apparently it's main purpose was to prevent the clobberage of a function which has called out to another but which will eventually be returned to after the update; here is the comment from methods.lisp: ;; Note that because this closure will be the discriminator code ;; of a generic function it must be careful about how it changes ;; the discriminator code of that same generic function. If it ;; isn't careful, it could change its closure variables out from ;; under itself. But with the use of "mattress pad" discriminators, rather than of functions that are actually clobbered, there is no longer a need for keeping track of *-ON-STACK*. At least not for the purposes of preventing clobberage of running code. -- JonL -- P.S.: Looks like the Victoria Day PCL hasn't put the equivalent of 'cache-lock-count' into the cache used by SLOT-VALUE--STD and SLOT-VALUE--FSC; so they still have the prospect of being slowed down by WITHOUT-INTERRUPTS as Ken noted some months ago. Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA02624; Thu, 6 Jul 89 09:41:15 -0700 Received: from Semillon.ms by ArpaGateway.ms ; 06 JUL 89 09:43:23 PDT Date: Thu, 6 Jul 89 09:37 PDT From: Gregor.pa@Xerox.COM Subject: Re: bug in eql-specializer methods To: Jutta Estenfeld Cc: CommonLoops.pa@Xerox.COM Fcc: BD:>Gregor>mail>outgoing-mail-7.text.newest In-Reply-To: <8907061331.AA28683@ztivax.uucp> Message-Id: <19890706163746.5.GREGOR@SPIFF.parc.xerox.com> Line-Fold: no Date: Thu, 6 Jul 89 15:31:58 -0200 From: jutta@ztivax.siemens.com (Jutta Estenfeld) I think there is a bug in the Victoria Day (5/22/89) Version of PCL if you define eql-specializer methods for make-instance: Yes, there is. I will try to send out a patch to this when I get back. ------- Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA02664; Thu, 6 Jul 89 09:43:05 -0700 Received: from Semillon.ms by ArpaGateway.ms ; 06 JUL 89 09:45:34 PDT Date: Thu, 6 Jul 89 09:42 PDT From: Gregor.pa@Xerox.COM Subject: I will be away To: CommonLoops.PA@Xerox.COM Fcc: BD:>Gregor>mail>outgoing-mail-7.text.newest Message-Id: <19890706164223.6.GREGOR@SPIFF.parc.xerox.com> Line-Fold: no The next release of PCL, which I have been mentioning for some time, is running reasonably well on my desk. It includes significant changes, and fixes to a lot of the recent bugs that have been reported. But, I am about to go out of town for a week. The PCL needs a little more work and I don't want to release it just before leaving. So, I will release after I get back. I will also be answering a slew of `how do I do xxx?' messages that I have collected up. Thanks for your patience. Sorry for the delay. ------- Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA04126; Thu, 6 Jul 89 11:32:38 -0700 Received: from Semillon.ms by ArpaGateway.ms ; 06 JUL 89 11:33:58 PDT Return-Path: Redistributed: CommonLoops.PA Received: from DINO.BBN.COM ([128.89.3.8]) by Xerox.COM ; 06 JUL 89 11:28:26 PDT To: Martin Boyer Cc: CommonLoops.PA@Xerox.COM Subject: Re: Using nonstandard method-class in generic-functions In-Reply-To: Your message of Mon, 03 Jul 89 14:50:53 -0400. <8907031850.AA10803@Moe.McRCIM.McGill.EDU> Date: Thu, 06 Jul 89 14:36:41 -0400 From: kanderso@DINO.BBN.COM Message-Id: <890706-113358-8842@Xerox> Your code works fine in AKCL, so i suspect it is a Lucid problem. I did notice that (describe #'hello) prints the slots out differently in AKCL, but i wouldn't expect that to be related. # is an instance of class #: The following slots have :INSTANCE allocation: DISPATCH-ORDER :DEFAULT METHOD-CLASS # PRETTY-ARGLIST NIL VALID-P NIL CACHE NIL COMBINED-METHODS NIL CLASSICAL-METHOD-TABLE NIL DISCRIMINATOR-CODE NIL METHODS NIL NAME HELLO Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA04642; Fri, 7 Jul 89 16:18:01 -0700 Received: from Riesling.ms by ArpaGateway.ms ; 07 JUL 89 16:10:15 PDT Return-Path: Redistributed: CommonLoops.pa Received: from lucid.com ([192.26.25.1]) by Xerox.COM ; 07 JUL 89 16:08:00 PDT Received: from bhopal ([192.43.178.13]) by heavens-gate id AA04104g; Fri, 7 Jul 89 16:05:08 PDT Received: by bhopal id AA05545g; Fri, 7 Jul 89 16:07:18 PDT Date: Fri, 7 Jul 89 16:07:18 PDT From: Jon L White Message-Id: <8907072307.AA05545@bhopal> To: gupta%prlhp1.uucp%prlb2.uucp%uunet.uucp@lucid.com Cc: CommonLoops.pa@Xerox.COM In-Reply-To: Ashok Gupta 's message of Wed, 28 Jun 89 10:53:08 bst <347.8906280953@apollo12.prl.philips.co.uk> Subject: Troubles reported by Ashok Gupta [My sincere apologies for letting this reply go to the whole mailing list, but apparently Ashok's return address isn't adequate for our mailer to reply to.] Can you give me detailed information on just which version of Lucid Common Lisp you are using -- e.g, is is on a Sun3? What does the banner say (the stuff that is printed out when you startup). -- Jon L White -- Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA05500; Mon, 10 Jul 89 19:55:26 -0700 Received: from Riesling.ms by ArpaGateway.ms ; 10 JUL 89 15:59:54 PDT Return-Path: Redistributed: CommonLoops.pa Received: from rand.org ([192.5.14.33]) by Xerox.COM ; 10 JUL 89 15:58:18 PDT Received: from blackcomb.rand.org by rand.org; Mon, 10 Jul 89 15:20:52 PDT Received: from localhost by blackcomb.rand.org; Mon, 10 Jul 89 15:19:46 PDT Message-Id: <8907102219.AA27167@blackcomb.rand.org> To: CommonLoops.pa@Xerox.COM Cc: Darrell_Shane , David_McArthur Subject: Declaration of valid initialization args. not working properly Date: Mon, 10 Jul 89 15:19:45 PDT From: Darrell ;;; PCL doesn't seem to recognize initialization arguments ;;; that supply arguments to an :after (or :before) method. ;;; For example: (defclass c1()()) (defmethod allocate-instance :before ((self c1) &rest ignore &key b) (declare (ignore ignore)) (format t "Allocate-instance: b=~A.~%" b)) (defmethod shared-initialize :AFTER ((self c1) slot-names &rest initargs &key b) (format t "Shared-initialize: b=~A.~%" b)) (make-instance 'c1 :b 10) --> Error: Invalid initialization argument :B for class C1 ;;; Yet the following works correctly: (defclass c1()()) (defmethod allocate-instance :before ((self c1) &rest ignore &key b) (declare (ignore ignore)) (format t "Allocate-instance: b=~A.~%" b)) (defmethod shared-initialize :AROUND ((self c1) slot-names &rest initargs &key b) (format t "Shared-initialize: b=~A.~%" b) (call-next-method)) (make-instance 'c1 :b 10) Shared-initialize around: b=10. # ;;; Some related questions: ;;; 1. Why is it necessary to define an allocate-instance method ;;; just so that b can be an initialization argument? The ;;; documentation for method definitions which serve to declare ;;; initialization arguments is confusing: "Making an instance of ;;; a class: allocate-instance, initialize-instance, and shared- ;;; initialize. Initialization arguments declared as valid by these ;;; methods are valid when making an instance of a class." Does this ;;; mean that by making an instance of ONE of the three classes is ;;; sufficient, or must an instance be made of each class? ;;; 2. Why the allocate-instance :before method get invoked? No ;;; "Allocate-instance: b=10." message was printed. ;;; Thanks, ;;; Darrell Shane ;;; P.S. I am running Victoria Day PCL on Allegro CL 3.0.3.sun3.1 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA05663; Mon, 10 Jul 89 20:02:42 -0700 Received: from Riesling.ms by ArpaGateway.ms ; 10 JUL 89 17:24:52 PDT Return-Path: Redistributed: CommonLoops.pa Received: from rand.org ([192.5.14.33]) by Xerox.COM ; 10 JUL 89 17:23:09 PDT Received: from blackcomb.rand.org by rand.org; Mon, 10 Jul 89 17:20:32 PDT Received: from localhost by blackcomb.rand.org; Mon, 10 Jul 89 17:19:27 PDT Message-Id: <8907110019.AA27276@blackcomb.rand.org> To: CommonLoops.pa@Xerox.COM Cc: Darrell_Shane , David_McArthur Subject: How to use call-next-method with an &rest argument Date: Mon, 10 Jul 89 17:19:25 PDT From: Darrell How can call-next-method be used within a method that has an &rest argument. Suppose that I want to add an initialization argument :foo to the list of initargs passed to initialize-instance. (defmethod initialize-instance :around ((self my-class) &rest initargs) (call-next-method self (append (list :foo 10) initargs))) The method above is not correct, the next method will always be passed exactly two arguments. Thanks, Darrell Shane Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA05713; Mon, 10 Jul 89 20:06:13 -0700 Received: from Cabernet.ms by ArpaGateway.ms ; 10 JUL 89 14:41:38 PDT Return-Path: Redistributed: CommonLoops.pa Received: from rand.org ([192.5.14.33]) by Xerox.COM ; 10 JUL 89 14:25:55 PDT Received: from blackcomb.rand.org by rand.org; Mon, 10 Jul 89 13:59:55 PDT Received: from localhost by blackcomb.rand.org; Mon, 10 Jul 89 13:58:49 PDT Message-Id: <8907102058.AA27126@blackcomb.rand.org> To: CommonLoops.pa@Xerox.COM Cc: Darrell_Shane , David_McArthur Subject: pcl erroring out for some unknown reason Date: Mon, 10 Jul 89 13:58:48 PDT From: Darrell At random places where I am defining methods and classes I will get an error message similar to the following: Error: No matching method for the generic-function #, when called with arguments (NIL). After the error, PCL is completely corrupt. The error will be issued from then on whenever an instance is instantiated, including classes and methods. Has anyone experienced this error before? Any fixes, or guidance will be most appreciated. Thanks, Darrell Shane P.S. I am running Victoria Day PCL on Allegro CL version 3.0.3.sun3.1 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA08046; Tue, 11 Jul 89 03:10:19 -0700 Received: from Chardonnay.ms by ArpaGateway.ms ; 11 JUL 89 02:19:45 PDT Return-Path: Redistributed: CommonLoops.pa Received: from uunet.uu.net ([192.48.96.2]) by Xerox.COM ; 11 JUL 89 02:16:38 PDT Received: by uunet.uu.net (5.61/1.14) with UUCP id AA20109; Tue, 11 Jul 89 05:16:25 -0400 Received: by franz.Franz.COM (MC 2.0/FI-1.0) id AA00625; Mon, 10 Jul 89 22:53:16 PDT Received: by aurora.Franz.COM (3.2/FI-1.0) id AA01313; Mon, 10 Jul 89 22:50:24 PDT Date: Mon, 10 Jul 89 22:50:24 PDT From: smh@franz.com (Steve Haflich) Message-Id: <8907110550.AA01313@aurora.Franz.COM> To: shane%blackcomb@rand.org Cc: CommonLoops.pa@Xerox.COM, shane@rand.org, dave@rand.org In-Reply-To: Darrell's message of Mon, 10 Jul 89 17:19:25 PDT <8907110019.AA27276@blackcomb.rand.org> Subject: How to use call-next-method with an &rest argument Date: Mon, 10 Jul 89 17:19:25 PDT From: Darrell How can call-next-method be used within a method that has an &rest argument. Suppose that I want to add an initialization argument :foo to the list of initargs passed to initialize-instance. (defmethod initialize-instance :around ((self my-class) &rest initargs) (call-next-method self (append (list :foo 10) initargs))) The method above is not correct, the next method will always be passed exactly two arguments. How about: (defmethod initialize-instance :around ((self my-class) &rest initargs) (apply #'call-next-method self :foo 10 initargs)) Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA09870; Tue, 11 Jul 89 08:53:52 -0700 Received: from Cabernet.ms by ArpaGateway.ms ; 11 JUL 89 07:30:47 PDT Return-Path: Redistributed: CommonLoops.pa Received: from CAD.CS.CMU.EDU ([128.2.254.133]) by Xerox.COM ; 11 JUL 89 07:28:45 PDT Date: Tue, 11 Jul 89 10:15 EDT From: Robert.Coyne@CAD.CS.CMU.EDU To: CommonLoops.pa@Xerox.COM Subject: Problems with VD PCL in Lucid 2.1.1 Message-Id: <616169724/coyne@CAD.CS.CMU.EDU> In a recent message, Jon L. White writes: Hmmm, I quite frankly don't see how any of the PCL in recent times couldwork in a Lucid Lisp of the vintage you have -- Sun 2.1.1. My copy of that release here doesn't even have the symbol LUCID::AUGMENT-LEXENV-FVARS-DUMMY in it. However, I do notice patched-up definition of it in walk.lisp as follows: etc...... Alas, I also have experienced many problems a some confusion in trying to compile the Victoria Day PCL under a 2.1.1 vintage of Lucid running under a Mach on a Sun 3/60. Is this really a lost cause or is there a complete and coherent set of patches somewhere that allows it to work with reasonable confidence? Thanks, Robert Coyne Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA21754; Wed, 12 Jul 89 04:19:36 -0700 Received: from Cabernet.ms by ArpaGateway.ms ; 11 JUL 89 23:33:21 PDT Return-Path: Redistributed: CommonLoops.pa Received: from lucid.com ([192.26.25.1]) by Xerox.COM ; 11 JUL 89 23:32:17 PDT Received: from bhopal ([192.43.178.13]) by heavens-gate id AA14992g; Tue, 11 Jul 89 23:29:21 PDT Received: by bhopal id AA12622g; Tue, 11 Jul 89 23:31:33 PDT Date: Tue, 11 Jul 89 23:31:33 PDT From: Jon L White Message-Id: <8907120631.AA12622@bhopal> To: shane%blackcomb@rand.org Cc: CommonLoops.pa@Xerox.COM, shane@rand.org, dave@rand.org In-Reply-To: Darrell's message of Mon, 10 Jul 89 15:19:45 PDT <8907102219.AA27167@blackcomb.rand.org> Subject: Declaration of valid initialization args. not working properly I'm not fully sure, but I think the question you are asking about what are valid initialization args has already been "posted" as a PCL bug two months ago by , on Fri, 12 May 89 09:38:45 PDT. I haven't seen any public reply to that posting, but we have discussed it internally here at Lucid, and came to the conclusion that Ramana's expectations are indeed correct according to the draft CLOS specification. Your other question -- about why the :before method on ALLOCATE-INSTANCE isn't firing -- looks to me like a previously unreported bug in standard method combination. Anyone else think otherwise? -- JonL -- Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA21774; Wed, 12 Jul 89 04:23:19 -0700 Received: from Cabernet.ms by ArpaGateway.ms ; 11 JUL 89 15:56:42 PDT Return-Path: Redistributed: CommonLoops.PA Received: from rand.org ([192.5.14.33]) by Xerox.COM ; 11 JUL 89 15:54:52 PDT Received: from blackcomb.rand.org by rand.org; Tue, 11 Jul 89 15:52:22 PDT Received: from localhost by blackcomb.rand.org; Tue, 11 Jul 89 15:52:19 PDT Message-Id: <8907112252.AA00535@blackcomb.rand.org> To: CommonLoops.PA@Xerox.COM Cc: David_McArthur , Darrell_Shane Subject: Compute-applicable-methods not working properly in Victoria Day PCL Date: Tue, 11 Jul 89 15:52:18 PDT From: Darrell (defmethod foo ((sym (eql 'A))) (format t "Main foo method.~%")) (defmethod foo :around ((sym (eql 'A))) (call-next-method) (format t "Around foo method.~%")) (defmethod foo :before ((sym (eql 'A))) (format t "Before foo method.~%")) (defmethod foo :after ((sym (eql 'A))) (format t "After foo method.~%")) (compute-applicable-methods #'foo (list 'A)) --> (#) Which is not the complete set of applicable methods. Also, I believe this is reason why PCL doesn't recognize initialization arguments that are arguments to method(s). Darrell Shane Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA21994; Wed, 12 Jul 89 05:19:13 -0700 Received: from Cabernet.ms by ArpaGateway.ms ; 12 JUL 89 05:18:16 PDT Return-Path: <"LSR::Darrell"@venus.tamu.edu> Redistributed: CommonLoops.PA Received: from venus.tamu.edu ([128.194.4.1]) by Xerox.COM ; 12 JUL 89 05:17:13 PDT Received: by venus id <2041A805031@venus.tamu.edu> ; Wed, 12 Jul 89 07:16:53 CDT Date: Wed, 12 Jul 89 07:16:45 CDT From: Darrell Subject: Compute-applicable-methods not working properly in Victoria Day Sender: "LSR::Darrell"@venus.tamu.edu To: yurttas@cssun.tamu.edu X-Vms-Mail-To: CommonLoops.PA@Xerox.COM Message-Id: <890712071645.2041A805031@venus.tamu.edu> >Return-Path: >Received: from arisia.Xerox.COM by LSR.TAMU.EDU ; 12-JUL-1989 07:23:20.85 >Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA21774; Wed, 12 Jul 89 04:23:19 -0700 >Received: from Cabernet.ms by ArpaGateway.ms ; 11 JUL 89 15:56:42 PDT >Return-Path: Redistributed: CommonLoops.PA >Received: from rand.org ([192.5.14.33]) by Xerox.COM ; 11 JUL 89 15:54:52 PDT >Received: from blackcomb.rand.org by rand.org; Tue, 11 Jul 89 15:52:22 PDT >Received: from localhost by blackcomb.rand.org; Tue, 11 Jul 89 15:52:19 PDT Message-Id: <8907112252.AA00535@blackcomb.rand.org> To: CommonLoops.PA@Xerox.COM Cc: David_McArthur , Darrell_Shane Subject: Compute-applicable-methods not working properly in Victoria Day PCL >Date: Tue, 11 Jul 89 15:52:18 PDT (defmethod foo ((sym (eql 'A))) (format t "Main foo method.~%")) (defmethod foo :around ((sym (eql 'A))) (call-next-method) (format t "Around foo method.~%")) (defmethod foo :before ((sym (eql 'A))) (format t "Before foo method.~%")) (defmethod foo :after ((sym (eql 'A))) (format t "After foo method.~%")) (compute-applicable-methods #'foo (list 'A)) --> (#) Which is not the complete set of applicable methods. Also, I believe this is reason why PCL doesn't recognize initialization arguments that are arguments to method(s). Darrell Shane Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA22052; Wed, 12 Jul 89 05:25:17 -0700 Received: from Burger.ms by ArpaGateway.ms ; 12 JUL 89 05:23:44 PDT Return-Path: <"LSR::Jon"@venus.tamu.edu> Redistributed: CommonLoops.pa Received: from venus.tamu.edu ([128.194.4.1]) by Xerox.COM ; 12 JUL 89 05:21:47 PDT Received: by venus id <2041C50F031@venus.tamu.edu> ; Wed, 12 Jul 89 07:20:51 CDT Date: Wed, 12 Jul 89 07:20:40 CDT From: Jon L White Subject: Declaration of valid initialization args. not working properly Sender: "LSR::Jon"@venus.tamu.edu To: yurttas@cssun.tamu.edu X-Vms-Mail-To: shane%blackcomb@rand.org Message-Id: <890712072040.2041C50F031@venus.tamu.edu> >Return-Path: >Received: from arisia.Xerox.COM by LSR.TAMU.EDU ; 12-JUL-1989 07:27:20.49 >Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA21754; Wed, 12 Jul 89 04:19:36 -0700 >Received: from Cabernet.ms by ArpaGateway.ms ; 11 JUL 89 23:33:21 PDT >Return-Path: Redistributed: CommonLoops.pa >Received: from lucid.com ([192.26.25.1]) by Xerox.COM ; 11 JUL 89 23:32:17 PDT >Received: from bhopal ([192.43.178.13]) by heavens-gate id AA14992g; Tue, 11 Jul 89 23:29:21 PDT >Received: by bhopal id AA12622g; Tue, 11 Jul 89 23:31:33 PDT >Date: Tue, 11 Jul 89 23:31:33 PDT Message-Id: <8907120631.AA12622@bhopal> To: shane%blackcomb@RAND.ORG Cc: CommonLoops.pa@Xerox.COM, shane@RAND.ORG, dave@RAND.ORG In-Reply-To: Darrell's message of Mon, 10 Jul 89 15:19:45 PDT <8907102219.AA27167@blackcomb.rand.org> Subject: Declaration of valid initialization args. not working properly I'm not fully sure, but I think the question you are asking about what are valid initialization args has already been "posted" as a PCL bug two months ago by , on Fri, 12 May 89 09:38:45 PDT. I haven't seen any public reply to that posting, but we have discussed it internally here at Lucid, and came to the conclusion that Ramana's expectations are indeed correct according to the draft CLOS specification. Your other question -- about why the :before method on ALLOCATE-INSTANCE isn't firing -- looks to me like a previously unreported bug in standard method combination. Anyone else think otherwise? -- JonL -- Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA24368; Wed, 12 Jul 89 09:50:33 -0700 Received: from Riesling.ms by ArpaGateway.ms ; 12 JUL 89 09:36:51 PDT Return-Path: <"LSR::Jon"@star.tamu.edu> Redistributed: CommonLoops.pa Received: from star.tamu.edu ([128.194.4.2]) by Xerox.COM ; 12 JUL 89 09:16:56 PDT Received: by venus id <2041C692031@venus.tamu.edu> ; Wed, 12 Jul 89 09:00:48 CDT Date: Wed, 12 Jul 89 09:00:35 CDT From: Jon L White Subject: Declaration of valid initialization args. not working properly Sender: "LSR::Jon"@venus.tamu.edu To: yurttas@cssun.tamu.edu X-Vms-Mail-To: yurttas@cssun.tamu.edu Message-Id: <890712090035.2041C692031@venus.tamu.edu> >Return-Path: >Received: from arisia.Xerox.COM by LSR.TAMU.EDU ; 12-JUL-1989 09:07:11.24 >Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA22052; Wed, 12 Jul 89 05:25:17 -0700 >Received: from Burger.ms by ArpaGateway.ms ; 12 JUL 89 05:23:44 PDT >Return-Path: <"LSR::Jon"@venus.tamu.edu> Redistributed: CommonLoops.pa >Received: from venus.tamu.edu ([128.194.4.1]) by Xerox.COM ; 12 JUL 89 05:21:47 PDT >Received: by venus id <2041C50F031@venus.tamu.edu> ; Wed, 12 Jul 89 07:20:51 CDT >Date: Wed, 12 Jul 89 07:20:40 CDT Subject: Declaration of valid initialization args. not working properly >Sender: "LSR::Jon"@venus.tamu.edu To: yurttas@cssun.tamu.edu X-Vms-Mail-To: shane%blackcomb@rand.org Message-Id: <890712072040.2041C50F031@venus.tamu.edu> >Return-Path: >Received: from arisia.Xerox.COM by LSR.TAMU.EDU ; 12-JUL-1989 07:27:20.49 >Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA21754; Wed, 12 Jul 89 04:19:36 -0700 >Received: from Cabernet.ms by ArpaGateway.ms ; 11 JUL 89 23:33:21 PDT >Return-Path: Redistributed: CommonLoops.pa >Received: from lucid.com ([192.26.25.1]) by Xerox.COM ; 11 JUL 89 23:32:17 PDT >Received: from bhopal ([192.43.178.13]) by heavens-gate id AA14992g; Tue, 11 Jul 89 23:29:21 PDT >Received: by bhopal id AA12622g; Tue, 11 Jul 89 23:31:33 PDT >Date: Tue, 11 Jul 89 23:31:33 PDT Message-Id: <8907120631.AA12622@bhopal> To: shane%blackcomb@RAND.ORG Cc: CommonLoops.pa@Xerox.COM, shane@RAND.ORG, dave@RAND.ORG In-Reply-To: Darrell's message of Mon, 10 Jul 89 15:19:45 PDT <8907102219.AA27167@blackcomb.rand.org> Subject: Declaration of valid initialization args. not working properly I'm not fully sure, but I think the question you are asking about what are valid initialization args has already been "posted" as a PCL bug two months ago by , on Fri, 12 May 89 09:38:45 PDT. I haven't seen any public reply to that posting, but we have discussed it internally here at Lucid, and came to the conclusion that Ramana's expectations are indeed correct according to the draft CLOS specification. Your other question -- about why the :before method on ALLOCATE-INSTANCE isn't firing -- looks to me like a previously unreported bug in standard method combination. Anyone else think otherwise? -- JonL -- Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA21994; Wed, 12 Jul 89 05:19:13 -0700 Received: from Cabernet.ms by ArpaGateway.ms ; 12 JUL 89 05:18:16 PDT Return-Path: <"LSR::Darrell"@venus.tamu.edu> Redistributed: CommonLoops.PA Received: from venus.tamu.edu ([128.194.4.1]) by Xerox.COM ; 12 JUL 89 05:17:13 PDT Received: by venus id <2041A805031@venus.tamu.edu> ; Wed, 12 Jul 89 07:16:53 CDT Date: Wed, 12 Jul 89 07:16:45 CDT From: Darrell Subject: Compute-applicable-methods not working properly in Victoria Day Sender: "LSR::Darrell"@venus.tamu.edu To: yurttas@cssun.tamu.edu X-Vms-Mail-To: CommonLoops.PA@Xerox.COM Message-Id: <890712071645.2041A805031@venus.tamu.edu> >Return-Path: >Received: from arisia.Xerox.COM by LSR.TAMU.EDU ; 12-JUL-1989 07:23:20.85 >Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA21774; Wed, 12 Jul 89 04:23:19 -0700 >Received: from Cabernet.ms by ArpaGateway.ms ; 11 JUL 89 15:56:42 PDT >Return-Path: Redistributed: CommonLoops.PA >Received: from rand.org ([192.5.14.33]) by Xerox.COM ; 11 JUL 89 15:54:52 PDT >Received: from blackcomb.rand.org by rand.org; Tue, 11 Jul 89 15:52:22 PDT >Received: from localhost by blackcomb.rand.org; Tue, 11 Jul 89 15:52:19 PDT Message-Id: <8907112252.AA00535@blackcomb.rand.org> To: CommonLoops.PA@Xerox.COM Cc: David_McArthur , Darrell_Shane Subject: Compute-applicable-methods not working properly in Victoria Day PCL >Date: Tue, 11 Jul 89 15:52:18 PDT (defmethod foo ((sym (eql 'A))) (format t "Main foo method.~%")) (defmethod foo :around ((sym (eql 'A))) (call-next-method) (format t "Around foo method.~%")) (defmethod foo :before ((sym (eql 'A))) (format t "Before foo method.~%")) (defmethod foo :after ((sym (eql 'A))) (format t "After foo method.~%")) (compute-applicable-methods #'foo (list 'A)) --> (#) Which is not the complete set of applicable methods. Also, I believe this is reason why PCL doesn't recognize initialization arguments that are arguments to method(s). Darrell Shane Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA26924; Wed, 12 Jul 89 13:38:40 -0700 Received: from Cabernet.ms by ArpaGateway.ms ; 12 JUL 89 09:41:48 PDT Return-Path: <"LSR::Jon"@star.tamu.edu> Redistributed: CommonLoops.pa Received: from star.tamu.edu ([128.194.4.2]) by Xerox.COM ; 12 JUL 89 09:17:57 PDT Received: by venus id <2041C692031@venus.tamu.edu> ; Wed, 12 Jul 89 09:00:48 CDT Date: Wed, 12 Jul 89 09:00:35 CDT From: Jon L White Subject: Declaration of valid initialization args. not working properly Sender: "LSR::Jon"@venus.tamu.edu To: yurttas@cssun.tamu.edu X-Vms-Mail-To: yurttas@cssun.tamu.edu Message-Id: <890712090035.2041C692031@venus.tamu.edu> >Return-Path: >Received: from arisia.Xerox.COM by LSR.TAMU.EDU ; 12-JUL-1989 09:07:11.24 >Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA22052; Wed, 12 Jul 89 05:25:17 -0700 >Received: from Burger.ms by ArpaGateway.ms ; 12 JUL 89 05:23:44 PDT >Return-Path: <"LSR::Jon"@venus.tamu.edu> Redistributed: CommonLoops.pa >Received: from venus.tamu.edu ([128.194.4.1]) by Xerox.COM ; 12 JUL 89 05:21:47 PDT >Received: by venus id <2041C50F031@venus.tamu.edu> ; Wed, 12 Jul 89 07:20:51 CDT >Date: Wed, 12 Jul 89 07:20:40 CDT Subject: Declaration of valid initialization args. not working properly >Sender: "LSR::Jon"@venus.tamu.edu To: yurttas@cssun.tamu.edu X-Vms-Mail-To: shane%blackcomb@rand.org Message-Id: <890712072040.2041C50F031@venus.tamu.edu> >Return-Path: >Received: from arisia.Xerox.COM by LSR.TAMU.EDU ; 12-JUL-1989 07:27:20.49 >Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA21754; Wed, 12 Jul 89 04:19:36 -0700 >Received: from Cabernet.ms by ArpaGateway.ms ; 11 JUL 89 23:33:21 PDT >Return-Path: Redistributed: CommonLoops.pa >Received: from lucid.com ([192.26.25.1]) by Xerox.COM ; 11 JUL 89 23:32:17 PDT >Received: from bhopal ([192.43.178.13]) by heavens-gate id AA14992g; Tue, 11 Jul 89 23:29:21 PDT >Received: by bhopal id AA12622g; Tue, 11 Jul 89 23:31:33 PDT >Date: Tue, 11 Jul 89 23:31:33 PDT Message-Id: <8907120631.AA12622@bhopal> To: shane%blackcomb@RAND.ORG Cc: CommonLoops.pa@Xerox.COM, shane@RAND.ORG, dave@RAND.ORG In-Reply-To: Darrell's message of Mon, 10 Jul 89 15:19:45 PDT <8907102219.AA27167@blackcomb.rand.org> Subject: Declaration of valid initialization args. not working properly I'm not fully sure, but I think the question you are asking about what are valid initialization args has already been "posted" as a PCL bug two months ago by , on Fri, 12 May 89 09:38:45 PDT. I haven't seen any public reply to that posting, but we have discussed it internally here at Lucid, and came to the conclusion that Ramana's expectations are indeed correct according to the draft CLOS specification. Your other question -- about why the :before method on ALLOCATE-INSTANCE isn't firing -- looks to me like a previously unreported bug in standard method combination. Anyone else think otherwise? -- JonL -- Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA02004; Wed, 12 Jul 89 19:31:51 -0700 Received: from Riesling.ms by ArpaGateway.ms ; 12 JUL 89 10:24:11 PDT Return-Path: Redistributed: CommonLoops.PA Received: from DINO.BBN.COM ([128.89.3.8]) by Xerox.COM ; 12 JUL 89 09:52:14 PDT To: Darrell Cc: CommonLoops.PA@Xerox.COM, David_McArthur , Darrell_Shane Subject: Re: Compute-applicable-methods not working properly in Victoria Day PCL In-Reply-To: Your message of Tue, 11 Jul 89 15:52:18 -0700. <8907112252.AA00535@blackcomb.rand.org> Date: Wed, 12 Jul 89 09:44:00 -0400 From: kanderso@DINO.BBN.COM Message-Id: <890712-102411-1482@Xerox> To: CommonLoops.PA@xerox.com Cc: David_McArthur , Darrell_Shane Subject: Compute-applicable-methods not working properly in Victoria Day PCL Date: Tue, 11 Jul 89 15:52:18 PDT From: Darrell (defmethod foo ((sym (eql 'A))) (format t "Main foo method.~%")) (defmethod foo :around ((sym (eql 'A))) (call-next-method) (format t "Around foo method.~%")) (defmethod foo :before ((sym (eql 'A))) (format t "Before foo method.~%")) (defmethod foo :after ((sym (eql 'A))) (format t "After foo method.~%")) (compute-applicable-methods #'foo (list 'A)) --> (#) Which is not the complete set of applicable methods. Also, I believe this is reason why PCL doesn't recognize initialization arguments that are arguments to method(s). Darrell Shane When i do this in AKCL, it seems to work: PCL>(generic-function-methods #'foo) (# # # #) PCL>(foo 'a) Before foo method. Main foo method. After foo method. Around foo method. NIL PCL>(compute-applicable-methods #'foo (list 'a)) (# # # #) Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA02298; Wed, 12 Jul 89 19:52:01 -0700 Received: from Riesling.ms by ArpaGateway.ms ; 12 JUL 89 09:40:16 PDT Return-Path: <"LSR::Jon"@venus.tamu.edu> Redistributed: CommonLoops.pa Received: from venus.tamu.edu ([128.194.4.1]) by Xerox.COM ; 12 JUL 89 09:17:29 PDT Received: by venus id <2041C692031@venus.tamu.edu> ; Wed, 12 Jul 89 09:00:48 CDT Date: Wed, 12 Jul 89 09:00:35 CDT From: Jon L White Subject: Declaration of valid initialization args. not working properly Sender: "LSR::Jon"@venus.tamu.edu To: yurttas@cssun.tamu.edu X-Vms-Mail-To: yurttas@cssun.tamu.edu Message-Id: <890712090035.2041C692031@venus.tamu.edu> >Return-Path: >Received: from arisia.Xerox.COM by LSR.TAMU.EDU ; 12-JUL-1989 09:07:11.24 >Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA22052; Wed, 12 Jul 89 05:25:17 -0700 >Received: from Burger.ms by ArpaGateway.ms ; 12 JUL 89 05:23:44 PDT >Return-Path: <"LSR::Jon"@venus.tamu.edu> Redistributed: CommonLoops.pa >Received: from venus.tamu.edu ([128.194.4.1]) by Xerox.COM ; 12 JUL 89 05:21:47 PDT >Received: by venus id <2041C50F031@venus.tamu.edu> ; Wed, 12 Jul 89 07:20:51 CDT >Date: Wed, 12 Jul 89 07:20:40 CDT Subject: Declaration of valid initialization args. not working properly >Sender: "LSR::Jon"@venus.tamu.edu To: yurttas@cssun.tamu.edu X-Vms-Mail-To: shane%blackcomb@rand.org Message-Id: <890712072040.2041C50F031@venus.tamu.edu> >Return-Path: >Received: from arisia.Xerox.COM by LSR.TAMU.EDU ; 12-JUL-1989 07:27:20.49 >Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA21754; Wed, 12 Jul 89 04:19:36 -0700 >Received: from Cabernet.ms by ArpaGateway.ms ; 11 JUL 89 23:33:21 PDT >Return-Path: Redistributed: CommonLoops.pa >Received: from lucid.com ([192.26.25.1]) by Xerox.COM ; 11 JUL 89 23:32:17 PDT >Received: from bhopal ([192.43.178.13]) by heavens-gate id AA14992g; Tue, 11 Jul 89 23:29:21 PDT >Received: by bhopal id AA12622g; Tue, 11 Jul 89 23:31:33 PDT >Date: Tue, 11 Jul 89 23:31:33 PDT Message-Id: <8907120631.AA12622@bhopal> To: shane%blackcomb@RAND.ORG Cc: CommonLoops.pa@Xerox.COM, shane@RAND.ORG, dave@RAND.ORG In-Reply-To: Darrell's message of Mon, 10 Jul 89 15:19:45 PDT <8907102219.AA27167@blackcomb.rand.org> Subject: Declaration of valid initialization args. not working properly I'm not fully sure, but I think the question you are asking about what are valid initialization args has already been "posted" as a PCL bug two months ago by , on Fri, 12 May 89 09:38:45 PDT. I haven't seen any public reply to that posting, but we have discussed it internally here at Lucid, and came to the conclusion that Ramana's expectations are indeed correct according to the draft CLOS specification. Your other question -- about why the :before method on ALLOCATE-INSTANCE isn't firing -- looks to me like a previously unreported bug in standard method combination. Anyone else think otherwise? -- JonL -- Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA02706; Wed, 12 Jul 89 20:12:25 -0700 Received: from Riesling.ms by ArpaGateway.ms ; 12 JUL 89 09:42:28 PDT Return-Path: <"LSR::Jon"@venus.tamu.edu> Redistributed: CommonLoops.pa Received: from venus.tamu.edu ([128.194.4.1]) by Xerox.COM ; 12 JUL 89 09:18:20 PDT Received: by venus id <2041C692031@venus.tamu.edu> ; Wed, 12 Jul 89 09:00:48 CDT Date: Wed, 12 Jul 89 09:00:35 CDT From: Jon L White Subject: Declaration of valid initialization args. not working properly Sender: "LSR::Jon"@venus.tamu.edu To: yurttas@cssun.tamu.edu X-Vms-Mail-To: yurttas@cssun.tamu.edu Message-Id: <890712090035.2041C692031@venus.tamu.edu> >Return-Path: >Received: from arisia.Xerox.COM by LSR.TAMU.EDU ; 12-JUL-1989 09:07:11.24 >Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA22052; Wed, 12 Jul 89 05:25:17 -0700 >Received: from Burger.ms by ArpaGateway.ms ; 12 JUL 89 05:23:44 PDT >Return-Path: <"LSR::Jon"@venus.tamu.edu> Redistributed: CommonLoops.pa >Received: from venus.tamu.edu ([128.194.4.1]) by Xerox.COM ; 12 JUL 89 05:21:47 PDT >Received: by venus id <2041C50F031@venus.tamu.edu> ; Wed, 12 Jul 89 07:20:51 CDT >Date: Wed, 12 Jul 89 07:20:40 CDT Subject: Declaration of valid initialization args. not working properly >Sender: "LSR::Jon"@venus.tamu.edu To: yurttas@cssun.tamu.edu X-Vms-Mail-To: shane%blackcomb@rand.org Message-Id: <890712072040.2041C50F031@venus.tamu.edu> >Return-Path: >Received: from arisia.Xerox.COM by LSR.TAMU.EDU ; 12-JUL-1989 07:27:20.49 >Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA21754; Wed, 12 Jul 89 04:19:36 -0700 >Received: from Cabernet.ms by ArpaGateway.ms ; 11 JUL 89 23:33:21 PDT >Return-Path: Redistributed: CommonLoops.pa >Received: from lucid.com ([192.26.25.1]) by Xerox.COM ; 11 JUL 89 23:32:17 PDT >Received: from bhopal ([192.43.178.13]) by heavens-gate id AA14992g; Tue, 11 Jul 89 23:29:21 PDT >Received: by bhopal id AA12622g; Tue, 11 Jul 89 23:31:33 PDT >Date: Tue, 11 Jul 89 23:31:33 PDT Message-Id: <8907120631.AA12622@bhopal> To: shane%blackcomb@RAND.ORG Cc: CommonLoops.pa@Xerox.COM, shane@RAND.ORG, dave@RAND.ORG In-Reply-To: Darrell's message of Mon, 10 Jul 89 15:19:45 PDT <8907102219.AA27167@blackcomb.rand.org> Subject: Declaration of valid initialization args. not working properly I'm not fully sure, but I think the question you are asking about what are valid initialization args has already been "posted" as a PCL bug two months ago by , on Fri, 12 May 89 09:38:45 PDT. I haven't seen any public reply to that posting, but we have discussed it internally here at Lucid, and came to the conclusion that Ramana's expectations are indeed correct according to the draft CLOS specification. Your other question -- about why the :before method on ALLOCATE-INSTANCE isn't firing -- looks to me like a previously unreported bug in standard method combination. Anyone else think otherwise? -- JonL -- Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA05152; Wed, 12 Jul 89 23:27:57 -0700 Received: from Burger.ms by ArpaGateway.ms ; 12 JUL 89 15:12:02 PDT Return-Path: Redistributed: CommonLoops.PA Received: from rand.org ([192.5.14.33]) by Xerox.COM ; 12 JUL 89 15:09:45 PDT Received: from blackcomb.rand.org by rand.org; Wed, 12 Jul 89 14:59:49 PDT Received: from localhost by blackcomb.rand.org; Wed, 12 Jul 89 14:59:44 PDT Message-Id: <8907122159.AA01339@blackcomb.rand.org> To: kanderso@dino.bbn.com Cc: CommonLoops.PA@Xerox.COM, David_McArthur , Darrell_Shane Subject: Re: Compute-applicable-methods not working properly in Victoria Day PCL In-Reply-To: Your message of Wed, 12 Jul 89 09:44:00 D. <8907121340.AA18214@rand.org> Date: Wed, 12 Jul 89 14:59:43 PDT From: Darrell >> When i do this in AKCL, it seems to work: >> >> PCL>(generic-function-methods #'foo) >> (# >> # >> # >> #) >> >> PCL>(foo 'a) >> Before foo method. >> Main foo method. >> After foo method. >> Around foo method. >> NIL >> >> PCL>(compute-applicable-methods #'foo (list 'a)) >> (# >> # >> # >> #) Try computing the applicable methods before invoking (foo 'a). I think that you will get the same incorrect results I did. Darrell Shane Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA05381; Wed, 12 Jul 89 23:35:13 -0700 Received: from Chardonnay.ms by ArpaGateway.ms ; 12 JUL 89 10:28:03 PDT Return-Path: Redistributed: CommonLoops.pa Received: from DINO.BBN.COM ([128.89.3.8]) by Xerox.COM ; 12 JUL 89 09:52:09 PDT To: CommonLoops.pa@Xerox.COM Subject: [Jeff Morrill: Recursive cache expansion bug rears its ugly head] Date: Wed, 12 Jul 89 09:23:54 -0400 From: kanderso@DINO.BBN.COM Message-Id: <890712-102803-1498@Xerox> ------- Forwarded Message Received: from BBN.COM by DINO.BBN.COM id aa14374; 10 Jul 89 14:13 EDT Received: from v1.bbn.com by BBN.COM id aa01115; 10 Jul 89 14:11 EDT Return-path: <@adams.bbn.com:jmorrill@[128.89.0.87]> Received: from adams.bbn.com by v1.bbn.com via TCP; Mon Jul 10 14:01 EDT Date: Mon, 10 Jul 89 14:03 EDT From: Jeff Morrill Subject: Recursive cache expansion bug rears its ugly head To: mthome@bbn.com, kanderson@bbn.com, delatizky@bbn.com, jmorrill@bbn.com Message-ID: <19890710180350.1.JMORRILL@adams.bbn.com> The recursive cache expansion bug appeared again today on the XL400 during a demo, despite our previous fix. That previous fix was to avoid applying setf to a generic function while doing an EXPAND-DCODE-CACHE. Otherwise, PCL tries to expand the cache for (setf slot-value-using-class) recursively forever (or until something breaks). Well, we didn't fix enough. EXPAND-DCODE-CACHE calls INSTALL-DISCRIMINATING-FUNCTION, which once again applies setf to a generic function. Here is a fix that seems to work. (defmethod install-discriminating-function ((generic-function standard-generic-function) function) (set-funcallable-instance-function generic-function function) ;; (setf (generic-function-discriminator-code generic-function) function)) (setf (slot-value generic-function 'discriminator-code) function)) Jon L White pointed out that although (setf slot-value) expands into a call to set-slot-value (which in turn calls (setf slot-value-using-class)), the code walker replaces calls to set-slot-value with some low-level ugly fast thing that doesn't worry about cache expansion. It seems like a good idea when writing future DCODE algorithms to avoid like the plague applying setf to generic functions, except for the case of (setf slot-value). Of course, even that could lead to the recursive cache expansion bug if it's in a defun rather than a defmethod. It would also help if (setf slot-value-using-class) wasn't being invalidated every time we define a class whose metaclass provides a method for it. Mike, I'll leave it to you to put the patch wherever it goes in our source files. Maybe somebody should forward this to Gregor too. jeff morrill ------- End of Forwarded Message Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA05406; Wed, 12 Jul 89 23:37:09 -0700 Received: from Semillon.ms by ArpaGateway.ms ; 12 JUL 89 19:40:49 PDT Return-Path: Redistributed: commonloops.pa Received: from rand.org ([192.5.14.33]) by Xerox.COM ; 12 JUL 89 19:38:09 PDT Received: from blackcomb.rand.org by rand.org; Wed, 12 Jul 89 19:24:06 PDT Received: from localhost by blackcomb.rand.org; Wed, 12 Jul 89 19:23:59 PDT Message-Id: <8907130223.AA01740@blackcomb.rand.org> To: commonloops.pa@Xerox.COM Cc: Kai Lam , David_McArthur , Darrell_Shane Subject: Re:pcl erroring out for some unknown reason Date: Wed, 12 Jul 89 19:23:58 PDT From: Darrell >> At random places where I am defining methods and classes I will get >> an error message similar to the following: >> >> Error: No matching method for the generic-function >> #, >> when called with arguments (NIL). >> >> After the error, PCL is completely corrupt. The error will be issued >> from then on whenever an instance is instantiated, including classes >> and methods. Has anyone experienced this error before? Any fixes, >> or guidance will be most appreciated. ;;; I now know why this error message was issued. Consider the following: (defclass c1 () ()) ;;; Notice the incorrect lambda list. (defmethod shared-initialize :after ((self c1) &rest ignore) (declare (ignore slot-names ignore)) (format t "After c1 shared-initialize method.~%")) (defmethod shared-initialize :before ((self c1) slot-names &rest ignore) (declare (ignore ignore)) (format t "Before c1 shared-initialize method.~%")) ;;; When compiling the above class and two methods, PCL will issue the ;;; error message: Error: No matching method for the generic-function #, when called with arguments (NIL). ;;; when trying to compile the last method. That is an error is signaled ;;; when the next method of the generic function is compiled; not when the ;;; erroneous method is. The error message is extremely misleading ;;; especially when the two methods are separated by many other forms ;;; or are defined in separate files. To all those who tried to help, thanks. Darrell Shane Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA05152; Wed, 12 Jul 89 23:27:57 -0700 Received: from Burger.ms by ArpaGateway.ms ; 12 JUL 89 15:12:02 PDT Return-Path: Redistributed: CommonLoops.PA Received: from rand.org ([192.5.14.33]) by Xerox.COM ; 12 JUL 89 15:09:45 PDT Received: from blackcomb.rand.org by rand.org; Wed, 12 Jul 89 14:59:49 PDT Received: from localhost by blackcomb.rand.org; Wed, 12 Jul 89 14:59:44 PDT Message-Id: <8907122159.AA01339@blackcomb.rand.org> To: kanderso@dino.bbn.com Cc: CommonLoops.PA@Xerox.COM, David_McArthur , Darrell_Shane Subject: Re: Compute-applicable-methods not working properly in Victoria Day PCL In-Reply-To: Your message of Wed, 12 Jul 89 09:44:00 D. <8907121340.AA18214@rand.org> Date: Wed, 12 Jul 89 14:59:43 PDT From: Darrell >> When i do this in AKCL, it seems to work: >> >> PCL>(generic-function-methods #'foo) >> (# >> # >> # >> #) >> >> PCL>(foo 'a) >> Before foo method. >> Main foo method. >> After foo method. >> Around foo method. >> NIL >> >> PCL>(compute-applicable-methods #'foo (list 'a)) >> (# >> # >> # >> #) Try computing the applicable methods before invoking (foo 'a). I think that you will get the same incorrect results I did. Darrell Shane Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA05406; Wed, 12 Jul 89 23:37:09 -0700 Received: from Semillon.ms by ArpaGateway.ms ; 12 JUL 89 19:40:49 PDT Return-Path: Redistributed: commonloops.pa Received: from rand.org ([192.5.14.33]) by Xerox.COM ; 12 JUL 89 19:38:09 PDT Received: from blackcomb.rand.org by rand.org; Wed, 12 Jul 89 19:24:06 PDT Received: from localhost by blackcomb.rand.org; Wed, 12 Jul 89 19:23:59 PDT Message-Id: <8907130223.AA01740@blackcomb.rand.org> To: commonloops.pa@Xerox.COM Cc: Kai Lam , David_McArthur , Darrell_Shane Subject: Re:pcl erroring out for some unknown reason Date: Wed, 12 Jul 89 19:23:58 PDT From: Darrell >> At random places where I am defining methods and classes I will get >> an error message similar to the following: >> >> Error: No matching method for the generic-function >> #, >> when called with arguments (NIL). >> >> After the error, PCL is completely corrupt. The error will be issued >> from then on whenever an instance is instantiated, including classes >> and methods. Has anyone experienced this error before? Any fixes, >> or guidance will be most appreciated. ;;; I now know why this error message was issued. Consider the following: (defclass c1 () ()) ;;; Notice the incorrect lambda list. (defmethod shared-initialize :after ((self c1) &rest ignore) (declare (ignore slot-names ignore)) (format t "After c1 shared-initialize method.~%")) (defmethod shared-initialize :before ((self c1) slot-names &rest ignore) (declare (ignore ignore)) (format t "Before c1 shared-initialize method.~%")) ;;; When compiling the above class and two methods, PCL will issue the ;;; error message: Error: No matching method for the generic-function #, when called with arguments (NIL). ;;; when trying to compile the last method. That is an error is signaled ;;; when the next method of the generic function is compiled; not when the ;;; erroneous method is. The error message is extremely misleading ;;; especially when the two methods are separated by many other forms ;;; or are defined in separate files. To all those who tried to help, thanks. Darrell Shane Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA05381; Wed, 12 Jul 89 23:35:13 -0700 Received: from Chardonnay.ms by ArpaGateway.ms ; 12 JUL 89 10:28:03 PDT Return-Path: Redistributed: CommonLoops.pa Received: from DINO.BBN.COM ([128.89.3.8]) by Xerox.COM ; 12 JUL 89 09:52:09 PDT To: CommonLoops.pa@Xerox.COM Subject: [Jeff Morrill: Recursive cache expansion bug rears its ugly head] Date: Wed, 12 Jul 89 09:23:54 -0400 From: kanderso@DINO.BBN.COM Message-Id: <890712-102803-1498@Xerox> ------- Forwarded Message Received: from BBN.COM by DINO.BBN.COM id aa14374; 10 Jul 89 14:13 EDT Received: from v1.bbn.com by BBN.COM id aa01115; 10 Jul 89 14:11 EDT Return-path: <@adams.bbn.com:jmorrill@[128.89.0.87]> Received: from adams.bbn.com by v1.bbn.com via TCP; Mon Jul 10 14:01 EDT Date: Mon, 10 Jul 89 14:03 EDT From: Jeff Morrill Subject: Recursive cache expansion bug rears its ugly head To: mthome@bbn.com, kanderson@bbn.com, delatizky@bbn.com, jmorrill@bbn.com Message-ID: <19890710180350.1.JMORRILL@adams.bbn.com> The recursive cache expansion bug appeared again today on the XL400 during a demo, despite our previous fix. That previous fix was to avoid applying setf to a generic function while doing an EXPAND-DCODE-CACHE. Otherwise, PCL tries to expand the cache for (setf slot-value-using-class) recursively forever (or until something breaks). Well, we didn't fix enough. EXPAND-DCODE-CACHE calls INSTALL-DISCRIMINATING-FUNCTION, which once again applies setf to a generic function. Here is a fix that seems to work. (defmethod install-discriminating-function ((generic-function standard-generic-function) function) (set-funcallable-instance-function generic-function function) ;; (setf (generic-function-discriminator-code generic-function) function)) (setf (slot-value generic-function 'discriminator-code) function)) Jon L White pointed out that although (setf slot-value) expands into a call to set-slot-value (which in turn calls (setf slot-value-using-class)), the code walker replaces calls to set-slot-value with some low-level ugly fast thing that doesn't worry about cache expansion. It seems like a good idea when writing future DCODE algorithms to avoid like the plague applying setf to generic functions, except for the case of (setf slot-value). Of course, even that could lead to the recursive cache expansion bug if it's in a defun rather than a defmethod. It would also help if (setf slot-value-using-class) wasn't being invalidated every time we define a class whose metaclass provides a method for it. Mike, I'll leave it to you to put the patch wherever it goes in our source files. Maybe somebody should forward this to Gregor too. jeff morrill ------- End of Forwarded Message Received: from arisia.Xerox.COM by arisia with SMTP (5.61+/IDA-1.2.8/gandalf) id AA02916; Thu, 13 Jul 89 09:43:50 -0700 Received: from arisia.Xerox.COM by arisia with SMTP (5.61+/IDA-1.2.8/gandalf) id AA02590; Thu, 13 Jul 89 09:39:47 -0700 Received: from arisia.Xerox.COM by arisia with SMTP (5.61+/IDA-1.2.8/gandalf) id AA02554; Thu, 13 Jul 89 09:39:25 -0700 Received: from arisia.Xerox.COM by arisia with SMTP (5.61+/IDA-1.2.8/gandalf) id AA02529; Thu, 13 Jul 89 09:39:09 -0700 Received: from arisia.Xerox.COM by arisia with SMTP (5.61+/IDA-1.2.8/gandalf) id AA02509; Thu, 13 Jul 89 09:38:57 -0700 Received: from arisia.Xerox.COM by arisia with SMTP (5.61+/IDA-1.2.8/gandalf) id AA02484; Thu, 13 Jul 89 09:38:46 -0700 Received: from arisia.Xerox.COM by arisia with SMTP (5.61+/IDA-1.2.8/gandalf) id AA02471; Thu, 13 Jul 89 09:38:17 -0700 Received: from arisia.Xerox.COM by arisia with SMTP (5.61+/IDA-1.2.8/gandalf) id AA02457; Thu, 13 Jul 89 09:38:08 -0700 Received: from arisia.Xerox.COM by arisia with SMTP (5.61+/IDA-1.2.8/gandalf) id AA02432; Thu, 13 Jul 89 09:37:54 -0700 Received: from arisia.Xerox.COM by arisia with SMTP (5.61+/IDA-1.2.8/gandalf) id AA02421; Thu, 13 Jul 89 09:37:49 -0700 Received: from Xerox.COM by arisia with SMTP (5.61+/IDA-1.2.8/gandalf) id AA02369; Thu, 13 Jul 89 09:37:10 -0700 Received: from Cabernet.ms by ArpaGateway.ms ; 13 JUL 89 07:01:00 PDT Return-Path: Redistributed: commonloops.pa Received: from arpa.att.com ([192.20.225.1]) by Xerox.COM ; 13 JUL 89 06:59:34 PDT From: lgm%ihlpf.uucp@att.att.com Date: Thu, 13 Jul 89 08:39 CDT >From: ihlpf!lgm (Lawrence G Mayka +1 312 416 5166) To: commonloops.pa%xerox.com%att.uucp@att.att.com Subject: Singleton, default DEFMETHOD now as fast as a DEFUN? Message-Id: <890713-070100-393@Xerox> I have recently noticed that with Victoria Day PCL on Sun Common Lisp 3.0.1, a method with no specialization (i.e., with only T specifiers) is just as fast as the equivalent ordinary function, if it is the only method of the generic function. In other words, if (defmethod fun (arg) 'hi) is the only method of generic function FUN, then it runs no slower than (defun fun (arg) 'hi) This brings up a few questions: 1) Did I find a rather special case, or is it generally true now that a DEFUN can be replaced by the corresponding DEFMETHOD without loss of speed? 2) What do people think of a style of programming in which one *always* uses DEFMETHOD instead of DEFUN, thereby making *all* user-programmed behavior specializable? If a default DEFMETHOD such as the example above is as fast as a DEFUN, performance does not suffer unless/until one actually *uses* the flexibility (i.e., by writing another method for the same generic function). The two hitches are (a) functions taking no arguments cannot be DEFMETHODs, and (b) replacing a function with another whose lambda-list is not congruent becomes a greater bother, especially since the current PCL doesn't seem to error-check this situation well. (In fact, PCL seems to be disabling the argument-count checking that I would normally get at safety 1.) 3) One could imagine still another optimization. If a generic function has only one method but that method does have specializers, PCL could simply perform quick type checks (in the style of CHECK-TYPE) and, if they pass, jump to the one method. Presumably, then, a generic function with a single method - which is apparently a common occurrence - could be faster than the more general case. Actually, PCL may already perform such an optimization - I guess I don't know. 4) If singleton, default DEFMETHODs are now as fast as DEFUNs, might one hope that the prohibition on specializing built-in Lisp functions might someday be lifted, at least to a limited degree? This isn't that big a deal to me, but people in other object-oriented programming camps are often very attached to "operator overloading." Sorry if this issue has already been beat to death by others. Lawrence G. Mayka AT&T Bell Laboratories lgm@ihlpf.att.com Standard disclaimer. Received: from Xerox.COM by arisia with SMTP (5.61+/IDA-1.2.8/gandalf) id AA07523; Thu, 13 Jul 89 11:18:58 -0700 Received: from Salvador.ms by ArpaGateway.ms ; 13 JUL 89 11:15:32 PDT Return-Path: Redistributed: CommonLoops.pa Received: from fs3.cs.rpi.edu ([128.213.1.14]) by Xerox.COM ; 13 JUL 89 10:26:43 PDT Received: by fs3.cs.rpi.edu (5.54/1.2-RPI-CS-Dept) id AA19553; Thu, 13 Jul 89 12:34:37 EDT Date: Thu, 13 Jul 89 12:35:19 EDT From: harrisr@turing.cs.rpi.edu (Richard Harris) Received: by turing.cs.rpi.edu (4.0/1.2-RPI-CS-Dept) id AA10917; Thu, 13 Jul 89 12:35:19 EDT Message-Id: <8907131635.AA10917@turing.cs.rpi.edu> To: CommonLoops.pa@Xerox.COM Subject: lambda-list congruency checking Cc: , , Darrell_Shane@turing.cs.rpi.edu, David_McArthur@turing.cs.rpi.edu > Date: Mon, 10 Jul 89 13:58:48 PDT > From: Darrell > Status: RO > > At random places where I am defining methods and classes I will get > an error message similar to the following: > > Error: No matching method for the generic-function > #, > when called with arguments (NIL). > > After the error, PCL is completely corrupt. The error will be issued > from then on whenever an instance is instantiated, including classes > and methods. Has anyone experienced this error before? Any fixes, > or guidance will be most appreciated. > > Thanks, > Darrell Shane > > P.S. I am running Victoria Day PCL on Allegro CL version 3.0.3.sun3.1 > I made some lambda-list congruency errors in a program I am writing, and got an obscure error. This patch improves things. PCL does not currently do any lambda-list congruency checking, but some parts of PCL assume that all the methods of a generic-function have the same number of required arguments. (When this assumption fails, class-precedence-list might be called on NIL, (causing a "No matching methods" error) in the following situation: notice-methods-change-2 ...> compute-combined-methods ...> compute-precedence-dag > class-precedence-list) The following patch does lambda-list congruency checking, and provides reasonable error messages (in place of the very obscure errors that a user will get otherwise). Rick Harris (in-package "PCL") ;;In methods.lisp (defun check-lambda-list-congruency (generic-function method) (let ((methods (generic-function-methods generic-function))) (when methods (multiple-value-bind (gf-required gf-optional gf-rest gf-key gf-allow-other-keys) (method-pretty-arglist (car methods)) (multiple-value-bind (required optional rest key allow-other-keys) (method-pretty-arglist method) (unless (= (length gf-required) (length required)) (error "~S has ~D required arguments, but existing methods have ~D required arguments" method (length required) (length gf-required))) (unless (= (length gf-optional) (length optional)) (error "~S has ~D optional arguments, but existing methods have ~D optional arguments" method (length optional) (length gf-optional))) (if (or gf-rest gf-key gf-allow-other-keys) (unless (or rest key allow-other-keys) (error "~S has neither &key nor &rest in its lambda-list, conflicting with existing methods" method)) (unless (not (or rest key allow-other-keys)) (error "~S has a &key or a &rest in its lambda-list, conflicting with existing methods" method)))))))) ;; To patch a running PCL, use the next line in place of (defun real-add-method ... ;(defmethod add-method ((generic-function standard-generic-function) (method standard-method)) (defun real-add-method (generic-function method) (setf (method-generic-function method) generic-function) (check-lambda-list-congruency generic-function method) (let* ((specializers (method-type-specifiers method)) (qualifiers (method-qualifiers method)) (existing (get-method generic-function qualifiers specializers nil))) (when existing (remove-method-internal generic-function existing)) (pushnew method (generic-function-methods generic-function)) (dolist (specializer specializers) (add-method-on-specializer method specializer)) (notice-methods-change generic-function) (maybe-update-constructors generic-function method) method)) Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA16111; Thu, 13 Jul 89 15:51:43 -0700 Received: from Chardonnay.ms by ArpaGateway.ms ; 13 JUL 89 15:42:22 PDT Return-Path: Redistributed: CommonLoops.pa Received: from mbunix.mitre.org ([129.83.20.100]) by Xerox.COM ; 13 JUL 89 15:36:00 PDT Posted-From: The MITRE Corp., Bedford, MA X-Alternate-Route: user%node@mbunix.mitre.org Return-Path: Received: from keemun.mitre.org by linus.MITRE.ORG (5.59/RCF-3S) id AA09243; Thu, 13 Jul 89 18:32:28 EDT From: john@linus.MITRE.ORG (John D. Burger) Posted-Date: Thu, 13 Jul 89 18:32:16 EDT Message-Id: <8907132232.AA09243@linus.MITRE.ORG> Received: by keemun.mitre.org (4.0/RCF-4C) id AA00466; Thu, 13 Jul 89 18:32:17 EDT To: CommonLoops.pa@Xerox.COM Subject: Re: Singleton, default DEFMETHOD now as fast as a DEFUN? Date: Thu, 13 Jul 89 18:32:16 EDT ihlpf!lgm (Lawrence G Mayka) says: >The two hitches are (a) functions taking no arguments cannot be >DEFMETHODs, ... Is this specified in the CLOS standard? From an empirical point of view, it's false, since I just did the following in Victoria Day PCL: (defmethod say-hello-gracie () "Hello, Gracie") This sort of definition is admittedly very uninteresting, but it does appear to be supported. John Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA00211; Fri, 14 Jul 89 17:59:28 -0700 Received: from Semillon.ms by ArpaGateway.ms ; 14 JUL 89 17:42:35 PDT Date: Fri, 14 Jul 89 17:39 PDT From: Gregor.pa@Xerox.COM Subject: 2nd CLOS Workshop To: common-lisp-object-system@sail.stanford.edu, CommonLoops.pa@Xerox.COM Fcc: BD:>Gregor>mail>outgoing-mail-7.text.newest Message-Id: <19890715003916.7.GREGOR@SPIFF.parc.xerox.com> Line-Fold: no This message is a reminder about the second CLOS workshop. The workshop will be held at the OOPSLA conference which will be in New Orleans this year. The dates for OOPSLA are October 2 - 6. This year's workshop is targeted to persons with significant experience with the Common Lisp Object System. The purpose of this workshop is to bring together a wide range of CLOS expertise in a setting which promotes substantive interaction among the participants. The workshop will address current issues in the use, development and implementation of CLOS. In order to promote intensive interaction among workshop participants, attendance will be limited to 30 people. Persons who would like to attend should submit five copies of a short (5 - 10 page) paper describing their work with CLOS. It is permissible for this to be a paper which will be presented in the main track of the conference. Papers will be reviewed by a committee, workshop participants will be selected from the submitted papers. Papers must be received by August 1 1989 and should be sent to: Gregor Kiczales Xerox PARC 3333 Coyote Hill Rd. Palo Alto, CA 94304 ------- Received: from Sail.Stanford.EDU by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA00479; Fri, 14 Jul 89 18:36:06 -0700 Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 14 Jul 89 18:35:49 PDT Received: from Semillon.ms by ArpaGateway.ms ; 14 JUL 89 17:42:35 PDT Date: Fri, 14 Jul 89 17:39 PDT From: Gregor.pa@Xerox.COM Subject: 2nd CLOS Workshop To: common-lisp-object-system@sail.stanford.edu, CommonLoops.pa@Xerox.COM Fcc: BD:>Gregor>mail>outgoing-mail-7.text.newest Message-Id: <19890715003916.7.GREGOR@SPIFF.parc.xerox.com> Line-Fold: no This message is a reminder about the second CLOS workshop. The workshop will be held at the OOPSLA conference which will be in New Orleans this year. The dates for OOPSLA are October 2 - 6. This year's workshop is targeted to persons with significant experience with the Common Lisp Object System. The purpose of this workshop is to bring together a wide range of CLOS expertise in a setting which promotes substantive interaction among the participants. The workshop will address current issues in the use, development and implementation of CLOS. In order to promote intensive interaction among workshop participants, attendance will be limited to 30 people. Persons who would like to attend should submit five copies of a short (5 - 10 page) paper describing their work with CLOS. It is permissible for this to be a paper which will be presented in the main track of the conference. Papers will be reviewed by a committee, workshop participants will be selected from the submitted papers. Papers must be received by August 1 1989 and should be sent to: Gregor Kiczales Xerox PARC 3333 Coyote Hill Rd. Palo Alto, CA 94304 ------- Received: from Xerox.COM by arisia.xerox.com with SMTP (5.61+/IDA-1.2.8/gandalf) id AA16715; Mon, 17 Jul 89 16:53:31 -0700 Received: from Chardonnay.ms by ArpaGateway.ms ; 17 JUL 89 16:35:03 PDT Return-Path: Redistributed: CommonLoops.pa Received: from roo.parc.xerox.com ([13.2.16.72]) by Xerox.COM ; 17 JUL 89 16:30:40 PDT Received: by roo.parc.xerox.com (5.61+/IDA-1.2.8/gandalf) id AA03875; Mon, 17 Jul 89 16:30:39 PDT Message-Id: <8907172330.AA03875@roo.parc.xerox.com> From: To: CommonLoops.pa@Xerox.COM Cc: gregor.pa@arisia.xerox.com Subject: PCL performance testing Date: Mon, 17 Jul 89 16:30:38 -0700 I'm an MIT summer intern working at Xerox PARC on a formal analysis of the behavior of PCL's caching mechanism. PCL's basic caching architecture is very similar to that of many OOLs, but it has never been tuned, and multi-methods have never been looked at carefully. In order to carry out this research, I need to gather data from a number of large, running PCL applications. To gather this data, I would like to ask people to volunteer to run some data collection programs for me. Running these programs would involve loading the data gathering code on top of the application, running the PCL application, then sending the results back to me. This should not take too much time, and the results would be of great value to me, and indirectly to you, as newer versions of PCL incorporate improvements in caching. If you would like to volunteer to do this, please reply to me so that I can send you the first run of data gathering code. Thanks. -Luis Received: from Xerox.COM by arisia.xerox.com with SMTP (5.61+/IDA-1.2.8/gandalf) id AA20178; Mon, 17 Jul 89 21:58:03 -0700 Received: from Burger.ms by ArpaGateway.ms ; 17 JUL 89 18:09:37 PDT Return-Path: <@CUNYVM.CUNY.EDU:CHEEWEEI@ITIVAX.BITNET> Redistributed: commonloops.pa Received: from CUNYVM.CUNY.EDU ([128.228.1.2]) by Xerox.COM ; 17 JUL 89 18:07:47 PDT Received: from ITIVAX.BITNET by CUNYVM.CUNY.EDU (IBM VM SMTP R1.1) with BSMTP id 6468; Mon, 17 Jul 89 21:08:00 EDT Date: Tue, 18 Jul 89 09:08 U From: Subject: no-applicable-method To: commonloops.pa@Xerox.COM X-Original-To: commonloops.pa@xerox.com, CHEEWEEI Message-Id: <890717-180937-7880@Xerox> Has anyone had problems defining an :around method for no-applicable-method or even redefining the default method? I tried both but the old error message in the default message keeps firing, ie. No matching method for .... I'm using Victoria day PCL running in Lucid 3.0 CW Received: from Sail.Stanford.EDU by arisia.xerox.com with SMTP (5.61+/IDA-1.2.8/gandalf) id AA22096; Mon, 17 Jul 89 22:59:31 -0700 Received: from ti.com by SAIL.Stanford.EDU with TCP; 17 Jul 89 22:57:35 PDT Received: by ti.com id AA20759; Mon, 17 Jul 89 12:33:14 CDT Received: from Kelvin by tilde id AA12698; Mon, 17 Jul 89 12:18:06 CDT Message-Id: <2825687758-15679445@Kelvin> Sender: GRAY@kelvin.csc.ti.com Date: Mon, 17 Jul 89 12:15:58 CDT From: David N Gray To: Common-Lisp-Object-System@SAIL.Stanford.edu Cc: john@linus.MITRE.ORG (John D. Burger) Subject: DEFMETHOD with no required args? In-Reply-To: Msg of Thu, 13 Jul 89 18:32:16 EDT from john@linus.MITRE.ORG (John D. Burger) > Date: Thu, 13 Jul 89 18:32:16 EDT > From: john@linus.MITRE.ORG (John D. Burger) > To: CommonLoops.pa@Xerox.COM > Subject: Re: Singleton, default DEFMETHOD now as fast as a DEFUN? > > ihlpf!lgm (Lawrence G Mayka) says: > > >The two hitches are (a) functions taking no arguments cannot be > >DEFMETHODs, ... > > Is this specified in the CLOS standard? From an empirical point of > view, it's false, since I just did the following in Victoria Day PCL: > > (defmethod say-hello-gracie () "Hello, Gracie") > > This sort of definition is admittedly very uninteresting, > but it does appear to be supported. My immediate reaction was "of course that isn't supposed to work", but I can't find anywhere that 88-002R actually says that. In particular, the specialized lambda list syntax uses {...}* instead of {...}+ which implies that there could be no required arguments. Is this really supposed to be permitted, or is it an oversight that it is not explicitly prohibited? Received: from Xerox.COM by arisia.xerox.com with SMTP (5.61+/IDA-1.2.8/gandalf) id AA20178; Mon, 17 Jul 89 21:58:03 -0700 Received: from Burger.ms by ArpaGateway.ms ; 17 JUL 89 18:09:37 PDT Return-Path: <@CUNYVM.CUNY.EDU:CHEEWEEI@ITIVAX.BITNET> Redistributed: commonloops.pa Received: from CUNYVM.CUNY.EDU ([128.228.1.2]) by Xerox.COM ; 17 JUL 89 18:07:47 PDT Received: from ITIVAX.BITNET by CUNYVM.CUNY.EDU (IBM VM SMTP R1.1) with BSMTP id 6468; Mon, 17 Jul 89 21:08:00 EDT Date: Tue, 18 Jul 89 09:08 U From: Subject: no-applicable-method To: commonloops.pa@Xerox.COM X-Original-To: commonloops.pa@xerox.com, CHEEWEEI Message-Id: <890717-180937-7880@Xerox> Has anyone had problems defining an :around method for no-applicable-method or even redefining the default method? I tried both but the old error message in the default message keeps firing, ie. No matching method for .... I'm using Victoria day PCL running in Lucid 3.0 CW Received: from Sail.Stanford.EDU by arisia.xerox.com with SMTP (5.61+/IDA-1.2.8/gandalf) id AA00478; Tue, 18 Jul 89 10:18:57 -0700 Message-Id: Date: 18 Jul 89 0342 PDT From: Dick Gabriel Subject: re: DEFMETHOD with no required args? To: Gray@dsg.csc.ti.com, Common-Lisp-Object-System@SAIL.Stanford.EDU Cc: john@LINUS.MITRE.ORG [In reply to message from Gray@DSG.csc.ti.com sent Mon, 17 Jul 89 12:15:58 CDT.] David Gray writes: ``My immediate reaction was "of course that isn't supposed to work", but I can't find anywhere that 88-002R actually says that. In particular, the specialized lambda list syntax uses {...}* instead of {...}+ which implies that there could be no required arguments. Is this really supposed to be permitted, or is it an oversight that it is not explicitly prohibited?'' As one of the primary authors of 88-002R, it is not an oversight that generic functions of 0 required arguments is permitted, and one reason is that it strikes me that ``of course that is supposed to work.'' The question appears to hinge on a judgement of the form that unless some particular feature has some ``reasonable use'' in a language, why permit the feature? A generic function of 0 arguments is primarily useful for writing a program with a simple control structure based on the method combination type specified. The counter to the judgement is that regularity or consistency is also important. For example, we do not prohibit addition of 0, even though there is no use for it (coercion or normalization aside). So why make a special case of 0 arguments? Another approach to the problem is to maintain the belief that methods are somehow attached to classes, and since a method on 0 arguments has no classes for attachment, there can be no method. Already we need to attach methods to sets of classes rather than individual classes, so the empty set need not be a special case. Finally, there may be an implementation reason to prohibit generic functions of 0 arguments, but this reason is not interesting. -rpg- Received: from Sail.Stanford.EDU by arisia.xerox.com with SMTP (5.61+/IDA-1.2.8/gandalf) id AA01041; Tue, 18 Jul 89 10:23:41 -0700 Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 18 Jul 89 10:21:49 PDT Received: from Semillon.ms by ArpaGateway.ms ; 18 JUL 89 09:58:15 PDT Date: Tue, 18 Jul 89 09:58 PDT From: Gregor.pa@Xerox.COM Subject: re: DEFMETHOD with no required args? To: Dick Gabriel Cc: Gray@dsg.csc.ti.com, Common-Lisp-Object-System@SAIL.Stanford.EDU, john@LINUS.MITRE.ORG Fcc: BD:>Gregor>mail>outgoing-mail-7.text.newest In-Reply-To: Message-Id: <19890718165805.0.GREGOR@SPIFF.parc.xerox.com> Line-Fold: no Date: 18 Jul 89 03:42 PDT From: Dick Gabriel The question appears to hinge on a judgement of the form that unless some particular feature has some ``reasonable use'' in a language, why permit the feature? A generic function of 0 arguments is primarily useful for writing a program with a simple control structure based on the method combination type specified. It seems pathological to me to have a generic function of zero required arguments. I would never have guessed that the spec would allow this. It requires a degenerate case of the first stage of generic function invocation, namely determining the ordered set of applicable methods. The only use for this is, as you say, to get access to the method combination facility without the method lookup facility. I guess this will make it easier for people to demonstrate how CLOS makes it possible to write gratuitously confusing programs! ------- Received: from Xerox.COM by arisia.xerox.com with SMTP (5.61+/IDA-1.2.8/gandalf) id AA08123; Tue, 18 Jul 89 12:55:41 -0700 Received: from Semillon.ms by ArpaGateway.ms ; 18 JUL 89 12:42:56 PDT Date: Tue, 18 Jul 89 12:37 PDT From: Gregor.pa@Xerox.COM Subject: Re: Singleton, default DEFMETHOD now as fast as a DEFUN? To: GRAY%Kelvin.csc.ti.com%arpa.uucp@att.att.com Cc: lgm%ihlpf.uucp@att.att.com, commonloops.pa@Xerox.COM Fcc: BD:>Gregor>mail>outgoing-mail-7.text.newest In-Reply-To: <2825686558-15607391@Kelvin> Message-Id: <19890718193734.3.GREGOR@SPIFF.parc.xerox.com> Line-Fold: no Date: Mon, 17 Jul 89 11:55:58 CDT From: arpa!Kelvin.csc.ti.com!GRAY@att.att.com > 1) Did I find a rather special case, or is it generally true now that > a DEFUN can be replaced by the corresponding DEFMETHOD without > loss of speed? I can't say about PCL, but there is nothing in the CLOS spec that requires this, so you shouldn't expect this to be true in other CLOS implementations. The spec doesn't say anything about performance at all, so it can't say anything about the performance of this special case. Given that the `semantics' of this case require less work than the `semantics' of the more general cases, I believe users will expect implementations to do better on this case than the more general ones. ------- Received: from Xerox.COM by arisia.xerox.com with SMTP (5.61+/IDA-1.2.8/gandalf) id AA06074; Tue, 18 Jul 89 11:54:13 -0700 Received: from Chardonnay.ms by ArpaGateway.ms ; 18 JUL 89 02:08:29 PDT Return-Path: Redistributed: commonloops.pa Received: from sunic.sunet.se ([192.36.125.2]) by Xerox.COM ; 18 JUL 89 02:06:46 PDT Received: from majestix.ida.liu.se by sunic.sunet.se (5.61+IDA/KTH/LTH/1.65) id AAsunic19257; Tue, 18 Jul 89 11:06:14 +0200 Received: from LISBET.IDA.LIU.SE by majestix.ida.liu.se; Tue, 18 Jul 89 11:07:05 +0200 Date: Tue, 18 Jul 89 11:04:47 From: Henrik Eriksson Subject: Bug in Victoria Day PCL To: commonloops.pa@Xerox.COM Organization: Dept. of Comp. and Info. Sc., Linkoping University, Sweden Message-Id: <6S75647.D.H-ERIKSSON@LISBET.IDA.LIU.SE> There is a rare bug in Victoria Day PCL which appears under the following circumstances: (defclass c2 (c1) ((my-slot :allocation :class))) ;; Note: c1 is not yet defined (defclass c3 (c2) ()) ;; Should be ok, but... Not an array: nil This bug only appears when (1) "c1" isn't defined (i.e. it's forward-referenced); (2) there is at least one slot in "c2" allocated in the class; (3) a specialization to "c2" is defined before "c1" is defined (i.e. "c3" is defined when "c1" is still forward-referenced); and (4) "c3" doesn't redefine inherited class-slots (i.e. "my-slot" is not redefined in "c3"). The problem is that the "wrapper-slot" of "c2" isn't asserted when "c3" is defined (because "c1" is forward-referenced). The wrapper of "c2" is needed in this particular situation to construct the wrapper of "c3" (i.e. to get the inherited class slots). A simple fix would be to change the following expression in the function update-slots--class in the file std-class.lisp: ;-------- (setf (wrapper-class-slots nwrapper) (gathering1 (collecting) (dolist (slotd inherited-class-slots) (gather1 (assoc (slotd-name slotd) (wrapper-class-slots (class-wrapper (slotd-allocation slotd)))))) (dolist (slotd class-slots) (gather1 (cons (slotd-name slotd) (funcall (slotd-initfunction slotd))))))) ;-------- into this: ;++++++++ (setf (wrapper-class-slots nwrapper) (gathering1 (collecting) (dolist (slotd inherited-class-slots) (gather1 (and (arrayp (class-wrapper (slotd-allocation slotd))) (assoc (slotd-name slotd) (wrapper-class-slots (class-wrapper (slotd-allocation slotd))))))) (dolist (slotd class-slots) (gather1 (cons (slotd-name slotd) (funcall (slotd-initfunction slotd))))))) ;++++++++ The above works since the wrapper gets updated when the forward-referenced super-class is declared. There is probably a "better" fix for this bug. However, this seems to work reasonably well. Henrik Eriksson ------- Received: from Xerox.COM by arisia.xerox.com with SMTP (5.61+/IDA-1.2.8/gandalf) id AA07676; Tue, 18 Jul 89 12:36:38 -0700 Received: from Salvador.ms by ArpaGateway.ms ; 18 JUL 89 01:44:51 PDT Return-Path: Redistributed: commonloops.pa Received: from arpa.att.com ([192.20.225.1]) by Xerox.COM ; 18 JUL 89 01:42:36 PDT From: GRAY%Kelvin.csc.ti.com%arpa.uucp@att.att.com Received: by ti.com id AA20618; Mon, 17 Jul 89 12:03:31 CDT Received: from Kelvin by tilde id AA12387; Mon, 17 Jul 89 11:58:14 CDT Message-Id: <2825686558-15607391@Kelvin> Sender: GRAY@kelvin.csc.ti.com Date: Mon, 17 Jul 89 11:55:58 CDT >From: David N Gray To: lgm%ihlpf.uucp@att.att.com Cc: commonloops.pa%xerox.com%att.uucp@att.att.com Subject: Re: Singleton, default DEFMETHOD now as fast as a DEFUN? In-Reply-To: Msg of Thu, 13 Jul 89 08:39 CDT from lgm%ihlpf.uucp@att.att.com > 1) Did I find a rather special case, or is it generally true now that > a DEFUN can be replaced by the corresponding DEFMETHOD without > loss of speed? I can't say about PCL, but there is nothing in the CLOS spec that requires this, so you shouldn't expect this to be true in other CLOS implementations. Received: from Xerox.COM by arisia.xerox.com with SMTP (5.61+/IDA-1.2.8/gandalf) id AA06912; Tue, 18 Jul 89 12:19:59 -0700 Received: from Semillon.ms by ArpaGateway.ms ; 18 JUL 89 10:19:33 PDT Date: Tue, 18 Jul 89 10:13 PDT From: Gregor.pa@Xerox.COM Subject: Re: Singleton, default DEFMETHOD now as fast as a DEFUN? To: lgm%ihlpf.uucp@att.att.com Cc: commonloops.pa@Xerox.COM Fcc: BD:>Gregor>mail>outgoing-mail-7.text.newest In-Reply-To: The message of 13 Jul 89 06:39 PDT from ihlpf!lgm@att.att.com Message-Id: <19890718171336.5.GREGOR@SPIFF.parc.xerox.com> Line-Fold: no Date: Thu, 13 Jul 89 08:39 CDT From: ihlpf!lgm@att.att.com 1) Did I find a rather special case, or is it generally true now that a DEFUN can be replaced by the corresponding DEFMETHOD without loss of speed? PCL has always provided the optimization that a generic function with only default methods would be as fast as a function. In some ports of PCL it is a little slower, but this could be fixed in the port-specific code. 2) What do people think of a style of programming in which one *always* uses DEFMETHOD instead of DEFUN, thereby making *all* user-programmed behavior specializable? If a default DEFMETHOD such as the example above is as fast as a DEFUN, performance does not suffer unless/until one actually *uses* the flexibility (i.e., by writing another method for the same generic function). There seems to be debate about this. One counter argument is that by making something a function, you are explicitly stating that it shouldn't and will not be specialized. This statement may have some value in certain programming situations. 3) One could imagine still another optimization. If a generic function has only one method but that method does have specializers, PCL could simply perform quick type checks (in the style of CHECK-TYPE) and, if they pass, jump to the one method. PCL already does this. 4) If singleton, default DEFMETHODs are now as fast as DEFUNs, might one hope that the prohibition on specializing built-in Lisp functions might someday be lifted, at least to a limited degree? One of the issues here is that many of those functions actually get compiled inline by the compiler (e.g. CAR). So, some people believe that turning them into generic functions might require compiling them as real function calls and that would cause a performance penalty. I think the real issue is that there hasn't been enough experience with what happens if you do this in Lisp, and so we weren't ready to try and standardize something here. I expect that in the next couple of years, a number of the Lisp vendors will themselves extend the set of standard functions that are generic. ------- Received: from Sail.Stanford.EDU by arisia.xerox.com with SMTP (5.61+/IDA-1.2.8/gandalf) id AA10617; Tue, 18 Jul 89 15:08:34 -0700 Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 18 Jul 89 15:06:10 PDT Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 627408; 18 Jul 89 18:08:03 EDT Date: Tue, 18 Jul 89 18:08 EDT From: David A. Moon Subject: call-next-method incoherency To: Common-Lisp-Object-System@sail.stanford.edu Message-Id: <19890718220816.2.MOON@EUPHRATES.SCRC.Symbolics.COM> There is a problem in the specification of call-next-method which I need some help to fix. The current draft of the ANSI Common lisp specification says: If there is no next method, the generic function no-next-method is called. If call-next-method is used in a method whose method combination does not support it, an error of type control-error is signalled. In 88-002R, it said just "an error is signaled" rather than specifying control-error. The problem I need help with is not the inconsistent spelling of "signaled" and is not exactly the particular condition type to be signaled. The problem is with the definition of what it means for a method combination type to not support call-next-method. Define-method-combination does not contain any way to specify whether call-next-method is supported. All you can do is call a method with call-method and either supply a next-method-list or not supply one; but there is no way to distinguish between a next-method-list that happens to be empty (in which case call-next-method should call no-next-method) and a situation where a next-method-list is not allowed. I see four possible approaches: 1. Change "an error of type control-error is signalled" to "the generic function no-next-method is called." Assume that an applicable method for no-next-method signals the error. 2. Change call-method to accept a second argument of :error, in place of a next-method-list, which tells call-next-method to signal an error. 3. Change call-method to make next-method-list optional. If it is not supplied, that tells call-next-method to signal an error. 4. Add a long-form-option to define-method-combination to specify whether methods in this method group support call-next-method. None of these approaches makes it particularly easy to report the misuse-of-call-next-method error at compile time, but that's not vitally important. Approach 1 is the only one that makes reporting the error at compile time impossible. I need some help deciding which of these approaches is right. We can't just stick with the status quo, because it's inconsistent. The approach I prefer is #3, as the least change to the language. Received: from Sail.Stanford.EDU by arisia.xerox.com with SMTP (5.61+/IDA-1.2.8/gandalf) id AA11157; Tue, 18 Jul 89 15:19:29 -0700 Message-Id: <12uyLq@SAIL.Stanford.EDU> Date: 18 Jul 89 1517 PDT From: Dick Gabriel Subject: re: call-next-method incoherency To: Moon@STONY-BROOK.SCRC.SYMBOLICS.COM, Common-Lisp-Object-System@SAIL.Stanford.EDU [In reply to message from Moon@STONY-BROOK.SCRC.Symbolics.COM sent Tue, 18 Jul 89 18:08 EDT.] I prefer #1 and ``signaled''. -rpg- Received: from Sail.Stanford.EDU by arisia.xerox.com with SMTP (5.61+/IDA-1.2.8/gandalf) id AA11929; Tue, 18 Jul 89 16:28:32 -0700 Received: from ti.com by SAIL.Stanford.EDU with TCP; 18 Jul 89 16:22:46 PDT Received: by ti.com id AA12267; Tue, 18 Jul 89 18:19:04 CDT Received: from Kelvin by tilde id AA17463; Tue, 18 Jul 89 18:02:50 CDT Message-Id: <2825794999-5597375@Kelvin> Sender: GRAY@kelvin.csc.ti.com Date: Tue, 18 Jul 89 18:03:19 CDT From: David N Gray To: "David A. Moon" Cc: Common-Lisp-Object-System@sail.stanford.edu Subject: Re: call-next-method incoherency In-Reply-To: Msg of Tue, 18 Jul 89 18:08 EDT from David A. Moon I prefer approach #1 since it is the simplest to implement, and no need for a more complicated approach has been demonstrated. Received: from Xerox.COM by arisia.xerox.com with SMTP (5.61+/IDA-1.2.8/gandalf) id AA06074; Tue, 18 Jul 89 11:54:13 -0700 Received: from Chardonnay.ms by ArpaGateway.ms ; 18 JUL 89 02:08:29 PDT Return-Path: Redistributed: commonloops.pa Received: from sunic.sunet.se ([192.36.125.2]) by Xerox.COM ; 18 JUL 89 02:06:46 PDT Received: from majestix.ida.liu.se by sunic.sunet.se (5.61+IDA/KTH/LTH/1.65) id AAsunic19257; Tue, 18 Jul 89 11:06:14 +0200 Received: from LISBET.IDA.LIU.SE by majestix.ida.liu.se; Tue, 18 Jul 89 11:07:05 +0200 Date: Tue, 18 Jul 89 11:04:47 From: Henrik Eriksson Subject: Bug in Victoria Day PCL To: commonloops.pa@Xerox.COM Organization: Dept. of Comp. and Info. Sc., Linkoping University, Sweden Message-Id: <6S75647.D.H-ERIKSSON@LISBET.IDA.LIU.SE> There is a rare bug in Victoria Day PCL which appears under the following circumstances: (defclass c2 (c1) ((my-slot :allocation :class))) ;; Note: c1 is not yet defined (defclass c3 (c2) ()) ;; Should be ok, but... Not an array: nil This bug only appears when (1) "c1" isn't defined (i.e. it's forward-referenced); (2) there is at least one slot in "c2" allocated in the class; (3) a specialization to "c2" is defined before "c1" is defined (i.e. "c3" is defined when "c1" is still forward-referenced); and (4) "c3" doesn't redefine inherited class-slots (i.e. "my-slot" is not redefined in "c3"). The problem is that the "wrapper-slot" of "c2" isn't asserted when "c3" is defined (because "c1" is forward-referenced). The wrapper of "c2" is needed in this particular situation to construct the wrapper of "c3" (i.e. to get the inherited class slots). A simple fix would be to change the following expression in the function update-slots--class in the file std-class.lisp: ;-------- (setf (wrapper-class-slots nwrapper) (gathering1 (collecting) (dolist (slotd inherited-class-slots) (gather1 (assoc (slotd-name slotd) (wrapper-class-slots (class-wrapper (slotd-allocation slotd)))))) (dolist (slotd class-slots) (gather1 (cons (slotd-name slotd) (funcall (slotd-initfunction slotd))))))) ;-------- into this: ;++++++++ (setf (wrapper-class-slots nwrapper) (gathering1 (collecting) (dolist (slotd inherited-class-slots) (gather1 (and (arrayp (class-wrapper (slotd-allocation slotd))) (assoc (slotd-name slotd) (wrapper-class-slots (class-wrapper (slotd-allocation slotd))))))) (dolist (slotd class-slots) (gather1 (cons (slotd-name slotd) (funcall (slotd-initfunction slotd))))))) ;++++++++ The above works since the wrapper gets updated when the forward-referenced super-class is declared. There is probably a "better" fix for this bug. However, this seems to work reasonably well. Henrik Eriksson ------- Received: from Xerox.COM by arisia.xerox.com with SMTP (5.61+/IDA-1.2.8/gandalf) id AA07676; Tue, 18 Jul 89 12:36:38 -0700 Received: from Salvador.ms by ArpaGateway.ms ; 18 JUL 89 01:44:51 PDT Return-Path: Redistributed: commonloops.pa Received: from arpa.att.com ([192.20.225.1]) by Xerox.COM ; 18 JUL 89 01:42:36 PDT From: GRAY%Kelvin.csc.ti.com%arpa.uucp@att.att.com Received: by ti.com id AA20618; Mon, 17 Jul 89 12:03:31 CDT Received: from Kelvin by tilde id AA12387; Mon, 17 Jul 89 11:58:14 CDT Message-Id: <2825686558-15607391@Kelvin> Sender: GRAY@kelvin.csc.ti.com Date: Mon, 17 Jul 89 11:55:58 CDT >From: David N Gray To: lgm%ihlpf.uucp@att.att.com Cc: commonloops.pa%xerox.com%att.uucp@att.att.com Subject: Re: Singleton, default DEFMETHOD now as fast as a DEFUN? In-Reply-To: Msg of Thu, 13 Jul 89 08:39 CDT from lgm%ihlpf.uucp@att.att.com > 1) Did I find a rather special case, or is it generally true now that > a DEFUN can be replaced by the corresponding DEFMETHOD without > loss of speed? I can't say about PCL, but there is nothing in the CLOS spec that requires this, so you shouldn't expect this to be true in other CLOS implementations. Received: from Sail.Stanford.EDU by arisia.xerox.com with SMTP (5.61+/IDA-1.2.8/gandalf) id AA14367; Tue, 18 Jul 89 18:21:57 -0700 Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 18 Jul 89 18:20:20 PDT Received: from Semillon.ms by ArpaGateway.ms ; 18 JUL 89 18:14:42 PDT Date: Tue, 18 Jul 89 18:12 PDT From: Gregor.pa@Xerox.COM Subject: Re: call-next-method incoherency To: David A. Moon Cc: Common-Lisp-Object-System@sail.stanford.edu Fcc: BD:>Gregor>mail>outgoing-mail-7.text.newest In-Reply-To: <19890718220816.2.MOON@EUPHRATES.SCRC.Symbolics.COM> Message-Id: <19890719011208.6.GREGOR@SPIFF.parc.xerox.com> Line-Fold: no I believe I prefer #1. ------- Received: from Sail.Stanford.EDU by arisia.xerox.com with SMTP (5.61+/IDA-1.2.8/gandalf) id AA14520; Tue, 18 Jul 89 18:46:58 -0700 Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 18 Jul 89 18:45:08 PDT Received: from Semillon.ms by ArpaGateway.ms ; 18 JUL 89 18:41:59 PDT Date: 18 Jul 89 18:41 PDT From: Danny Bobrow Subject: Re: call-next-method incoherency In-Reply-To: David A. Moon 's message of Tue, 18 Jul 89 18:08 EDT To: David A. Moon Cc: Common-Lisp-Object-System@sail.stanford.edu Message-Id: <890718-184159-11318@Xerox> I prefer #1 danny Received: from Xerox.COM by arisia.xerox.com with SMTP (5.61+/IDA-1.2.8/gandalf) id AA08123; Tue, 18 Jul 89 12:55:41 -0700 Received: from Semillon.ms by ArpaGateway.ms ; 18 JUL 89 12:42:56 PDT Date: Tue, 18 Jul 89 12:37 PDT From: Gregor.pa@Xerox.COM Subject: Re: Singleton, default DEFMETHOD now as fast as a DEFUN? To: GRAY%Kelvin.csc.ti.com%arpa.uucp@att.att.com Cc: lgm%ihlpf.uucp@att.att.com, commonloops.pa@Xerox.COM Fcc: BD:>Gregor>mail>outgoing-mail-7.text.newest In-Reply-To: <2825686558-15607391@Kelvin> Message-Id: <19890718193734.3.GREGOR@SPIFF.parc.xerox.com> Line-Fold: no Date: Mon, 17 Jul 89 11:55:58 CDT From: arpa!Kelvin.csc.ti.com!GRAY@att.att.com > 1) Did I find a rather special case, or is it generally true now that > a DEFUN can be replaced by the corresponding DEFMETHOD without > loss of speed? I can't say about PCL, but there is nothing in the CLOS spec that requires this, so you shouldn't expect this to be true in other CLOS implementations. The spec doesn't say anything about performance at all, so it can't say anything about the performance of this special case. Given that the `semantics' of this case require less work than the `semantics' of the more general cases, I believe users will expect implementations to do better on this case than the more general ones. ------- Received: from Xerox.COM by arisia.xerox.com with SMTP (5.61+/IDA-1.2.8/gandalf) id AA02821; Thu, 20 Jul 89 11:30:42 -0700 Received: from Riesling.ms by ArpaGateway.ms ; 20 JUL 89 05:47:11 PDT Return-Path: Redistributed: commonloops.pa Received: from uunet.uu.net ([192.48.96.2]) by Xerox.COM ; 20 JUL 89 05:45:13 PDT Received: from ukc.UUCP by uunet.uu.net (5.61/1.14) with UUCP id AA03487; Thu, 20 Jul 89 08:45:04 -0400 Received: from ail by kestrel.Ukc.AC.UK with UUCP id aa05631; 20 Jul 89 13:37 BST Received: from TLewis by ail.co.uk (3.2/SMI-3.5) Received: from MINT: by XEROXMAILER.AIL; 20 Jul 89 09:20:44 GMT Message-Id: <646895197.-1644864307@XEROXMAILER.AIL> To: commonloops.pa@Xerox.COM From: TLewis@artificial-intelligence.co.uk Subject: commonloops - CLOS Tools ? Date: 20 Jul 89 09:16 Sender: Tim_Lewis@artificial-intelligence.co.uk Cc: TLewis@artificial-intelligence.co.uk I am looking to develop some CLOS support tools and would appreciate details of any tools that are already available in the public domain. In particlular a Class Browser using CLX or Common Windows. Thanks Tim Lewis Received: from Sail.Stanford.EDU by arisia.xerox.com with SMTP (5.61+/IDA-1.2.8/gandalf) id AA05671; Thu, 20 Jul 89 14:32:24 -0700 Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 20 Jul 89 14:30:41 PDT Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 628909; 20 Jul 89 17:32:37 EDT Date: Thu, 20 Jul 89 17:32 EDT From: David A. Moon Subject: call-next-method incoherency To: Common-Lisp-Object-System@sail.stanford.edu In-Reply-To: <19890718220816.2.MOON@EUPHRATES.SCRC.Symbolics.COM> Message-Id: <19890720213255.6.MOON@EUPHRATES.SCRC.Symbolics.COM> Here are some arguments from JonL which I find quite persuasive. Before I saw these I was just going to go with #1 since that's what all the respondents had said, but now I am reconfirmed in my belief that #3 is the best option. Did the people who suggested #1 base their suggestion on careful thought, or just pick that one because it seemed easiest or was first on the list? If there are good arguments for #1 I'd like to hear them. #1 smacks of overloading a communication channel. Some lusers out there will come to depend on finding out the method-combination mismatch error by placing obscure methods on NO-NEXT-METHOD, so we will never be able to correct this wort once it gets in. #4 smacks of overkill; a piece of syntax at the same level as everything else in method combination to cover an incredibly obscure problem that almost no one will run into. Why clutter up the spec. Besides, whole method groups might be too coarse a sieve to strain out the contexts under which you want to proscribe CALL-NEXT-METHOD. #3 is a very logical extension of the meaning of CALL-METHOD as spelled out in 88-002R p.2-11. CALL-METHOD should bear the burden, since it is the interface between method-combination and CALL-NEXT-METHOD. I suspect some existing implementations (e.g. PCL) would require more of a change to do it this way than by #1, but not a radical change. #2 is just a variant of #3, but the syntax is more "special case", rather than the "natural extesion" of #3. Providing a null list for the next-methods argument is a fine way to say "any use of CALL-NEXT-METHOD will simply call NO-NEXT-METHD"; the natural way to differentiate this case from a control-error case is to _not_ provide the next-methods argument at all. Thus #3 is preferable. The argument would be compelling if you could show a way to model the prohibitions in standard-method-combination using this #3 approach (i.e., can't use CALL-NEXT-METHOD in :before or :after methods, but can use it in primary and :around). That's the end of the quotation from JonL, the rest is my response: From the documentation examples, here is the existing definition of standard method combination: ;The default method-combination technique (define-method-combination standard () ((around (:around)) (before (:before)) (primary () :required t) (after (:after))) (flet ((call-methods (methods) (mapcar #'(lambda (method) `(call-method ,method ())) methods))) (let ((form (if (or before after (rest primary)) `(multiple-value-prog1 (progn ,@(call-methods before) (call-method ,(first primary) ,(rest primary))) ,@(call-methods (reverse after))) `(call-method ,(first primary) ())))) (if around `(call-method ,(first around) (,@(rest around) (make-method ,form))) form)))) and here is the compelling modified version for the #3 approach: ;The default method-combination technique (define-method-combination standard () ((around (:around)) (before (:before)) (primary () :required t) (after (:after))) (flet ((call-methods (methods) (mapcar #'(lambda (method) `(call-method ,method)) methods))) (let ((form (if (or before after (rest primary)) `(multiple-value-prog1 (progn ,@(call-methods before) (call-method ,(first primary) ,(rest primary))) ,@(call-methods (reverse after))) `(call-method ,(first primary) ())))) (if around `(call-method ,(first around) (,@(rest around) (make-method ,form))) form)))) Only one line is changed. Received: from Sail.Stanford.EDU by arisia.xerox.com with SMTP (5.61+/IDA-1.2.8/gandalf) id AA01114; Fri, 21 Jul 89 09:46:23 -0700 Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 21 Jul 89 09:44:34 PDT Received: from Cabernet.ms by ArpaGateway.ms ; 21 JUL 89 09:39:23 PDT Date: Fri, 21 Jul 89 09:36 PDT From: Gregor.pa@Xerox.COM Subject: Re: call-next-method incoherency To: David A. Moon Cc: Common-Lisp-Object-System@sail.stanford.edu Fcc: BD:>Gregor>mail>outgoing-mail-7.text.newest In-Reply-To: <19890720213255.6.MOON@EUPHRATES.SCRC.Symbolics.COM> Message-Id: <19890721163640.5.GREGOR@SPIFF.parc.xerox.com> Line-Fold: no Sure, I'll go for number 3, what the hell. ------- Received: from Xerox.COM by arisia.xerox.com with SMTP (5.61+/IDA-1.2.8/gandalf) id AA07317; Fri, 21 Jul 89 14:31:35 -0700 Received: from Semillon.ms by ArpaGateway.ms ; 21 JUL 89 11:53:09 PDT Date: Fri, 21 Jul 89 11:33 PDT From: Gregor.pa@Xerox.COM Subject: IJCAI CLOS Tutorial etc. To: CommonLoops.PA@Xerox.COM Fcc: BD:>Gregor>mail>outgoing-mail-7.text.newest Message-Id: <19890721183342.2.GREGOR@SPIFF.parc.xerox.com> Line-Fold: no Many people have asked about how to go about learning to use CLOS. This message summarizes some of the available information, particularly that with which I am most familiar. Please feel free to send other messages that supplement this information. This year at IJCAI, Danny Bobrow and I will be giving a 4 hour CLOS tutorial. This year's tutorial differs from last year's in a number of ways, in particular the sections on performance and use of the metaobject protocol have been considerably expanded. Other sections were removed to make room for the new stuff. In general, this tutorial provides an introduction to many different facets of CLOS. Basic programming, use of the initialization protocol, mixins and modularity, shared and local slots, method combination, class redefinition, multi-methods, performance, meta-level programs etc. I believe this tutorial is valuable to anyone wanting to learn about CLOS in general, or some part of CLOS they don't yet fully understand. Many people will want to get more detailed instruction about programming in CLOS. I believe that all of the major Lisp vendors now offer CLOS classes. These vary from 2 to 5 days in length. In addition, there are at least two books that provide excellent information on programming in CLOS. These are Sonya Keene's "Object Oriented Programming in Common Lisp -- A Programmer's Guide to CLOS" and the third edition of Patrick Winston and Berthold Horn's "Lisp". ------- Received: from Xerox.COM by arisia.xerox.com with SMTP (5.61+/IDA-1.2.8/gandalf) id AA24074; Sat, 22 Jul 89 12:44:47 -0700 Received: from Salvador.ms by ArpaGateway.ms ; 22 JUL 89 10:44:56 PDT Return-Path: Redistributed: commonloops.pa Received: from shrike.Austin.Lockheed.COM ([192.31.24.65]) by Xerox.COM ; 22 JUL 89 10:43:05 PDT Received: by shrike.Austin.Lockheed.COM (4.0/1.46); Sat, 22 Jul 89 00:19:23 CDT Date: Sat, 22 Jul 89 00:19:23 CDT From: Daniel A Haug Message-Id: <8907220519.AA26609@shrike.Austin.Lockheed.COM> To: commonloops.pa@Xerox.COM Subject: Question about inherited slots Cc: haug@AUSTIN.LOCKHEED.COM I have written a small program that generates a reference manual from a loaded PCL system. It simply prints out the various class definitions, slot info, documentation, etc. However, I've run into a problem with slots. Calling CLASS-SLOTS returns a list of standard-slot-descriptors. But for the inherited slots, I lose all of the information that I need. The standard-slot-descriptors for the inherited slots do not retain the reader/writer/accessor/initform/initarg information. So, my question is: how should I go about retreiving this information? Is it necessary for me to traverse the class super's list to look for the class from which the slot was inherited? I was not able to find any simple way in which to tell from what class a slot was inherited. Any help is appreciated. dan haug Internet: haug@austin.lockheed.com uucp: ut-emx!lad-shrike!aihaug Received: from Xerox.COM by arisia.xerox.com with SMTP (5.61+/IDA-1.2.8/gandalf) id AA24074; Sat, 22 Jul 89 12:44:47 -0700 Received: from Salvador.ms by ArpaGateway.ms ; 22 JUL 89 10:44:56 PDT Return-Path: Redistributed: commonloops.pa Received: from shrike.Austin.Lockheed.COM ([192.31.24.65]) by Xerox.COM ; 22 JUL 89 10:43:05 PDT Received: by shrike.Austin.Lockheed.COM (4.0/1.46); Sat, 22 Jul 89 00:19:23 CDT Date: Sat, 22 Jul 89 00:19:23 CDT From: Daniel A Haug Message-Id: <8907220519.AA26609@shrike.Austin.Lockheed.COM> To: commonloops.pa@Xerox.COM Subject: Question about inherited slots Cc: haug@AUSTIN.LOCKHEED.COM I have written a small program that generates a reference manual from a loaded PCL system. It simply prints out the various class definitions, slot info, documentation, etc. However, I've run into a problem with slots. Calling CLASS-SLOTS returns a list of standard-slot-descriptors. But for the inherited slots, I lose all of the information that I need. The standard-slot-descriptors for the inherited slots do not retain the reader/writer/accessor/initform/initarg information. So, my question is: how should I go about retreiving this information? Is it necessary for me to traverse the class super's list to look for the class from which the slot was inherited? I was not able to find any simple way in which to tell from what class a slot was inherited. Any help is appreciated. dan haug Internet: haug@austin.lockheed.com uucp: ut-emx!lad-shrike!aihaug Received: from Xerox.COM by arisia.xerox.com with SMTP (5.61+/IDA-1.2.8/gandalf) id AA04688; Sun, 23 Jul 89 20:03:01 -0700 Received: from Chardonnay.ms by ArpaGateway.ms ; 23 JUL 89 20:03:01 PDT Return-Path: Redistributed: commonloops.pa Received: from shrike.Austin.Lockheed.COM ([192.31.24.65]) by Xerox.COM ; 23 JUL 89 20:00:02 PDT Received: by shrike.Austin.Lockheed.COM (4.0/1.46); Sun, 23 Jul 89 21:43:57 CDT Date: Sun, 23 Jul 89 21:43:57 CDT From: Daniel A Haug Message-Id: <8907240243.AA14221@shrike.Austin.Lockheed.COM> To: commonloops.pa@Xerox.COM Subject: Help with eql specializers Cc: haug@AUSTIN.LOCKHEED.COM I've hit upon a major performance problem with PCL, and I don't know what caused it. The only thing I know for sure is that it happened when I began using eql specializers on a certain generic function. My typical runtime on this function jumped from around .03 seconds to about 6 seconds. I ran the symbolics Metering Interface over the form, and found that almost all of the time is spent in PCL:NOTICE-METHODS-CHANGE-1. Inside of NOTICE-METHODS-CHANGE-1, the run-time is split between COMPUTE-COMBINED-METHODS and UPDATE-DISCRIMINATOR-CODE of STANDARD-GENERIC- FUNCTION. In fact, I placed a break loop in NOTICE-METHODS-CHANGE-1, and saw that it was getting called a zillion (excuse me) times. SHould I be avoiding EQL specializers? Can I expect to always pay this kind of performance penalty for using them? Or is there a problem? The generic function in question here as a total of four methods defined on it, three of which have EQL specializers. Any help is really appreciated. I'm going nuts over this, because it is tied in with menu clicks, and my users are waiting over 6 seconds now between clicking on a window, and getting a response. dan haug Internet: haug@austin.lockheed.com UUCP: ut-emx!lad-shrike!aihaug Received: from Xerox.COM by arisia.xerox.com with SMTP (5.61+/IDA-1.2.8/gandalf) id AA11099; Mon, 24 Jul 89 06:10:41 -0700 Received: from Chardonnay.ms by ArpaGateway.ms ; 24 JUL 89 06:10:30 PDT Return-Path: Redistributed: commonloops.pa Received: from DINO.BBN.COM ([128.89.3.8]) by Xerox.COM ; 24 JUL 89 06:05:21 PDT To: Daniel A Haug Cc: commonloops.pa@Xerox.COM, haug@austin.lockheed.com Subject: Re: Help with eql specializers In-Reply-To: Your message of Sun, 23 Jul 89 21:43:57 -0500. <8907240243.AA14221@shrike.Austin.Lockheed.COM> Date: Mon, 24 Jul 89 09:17:25 -0400 From: kanderso@DINO.BBN.COM Message-Id: <890724-061030-6886@Xerox> Date: Sun, 23 Jul 89 21:43:57 CDT From: Daniel A Haug Message-Id: <8907240243.AA14221@shrike.Austin.Lockheed.COM> To: commonloops.pa@xerox.com Subject: Help with eql specializers Cc: haug@austin.lockheed.com I've hit upon a major performance problem with PCL, and I don't know what caused it. The only thing I know for sure is that it happened when I began using eql specializers on a certain generic function. My typical runtime on this function jumped from around .03 seconds to about 6 seconds. I ran the symbolics Metering Interface over the form, and found that almost all of the time is spent in PCL:NOTICE-METHODS-CHANGE-1. Inside of NOTICE-METHODS-CHANGE-1, the run-time is split between COMPUTE-COMBINED-METHODS and UPDATE-DISCRIMINATOR-CODE of STANDARD-GENERIC- FUNCTION. In fact, I placed a break loop in NOTICE-METHODS-CHANGE-1, and saw that it was getting called a zillion (excuse me) times. Can you extract a short example we can play with? Off hand, i'd say that notice-methods-change... is only called when a generic function is invalidated. It turns out that lots of unnecessary invalidation occurs when classes are defined. However, i'm suprised that this happens when everything is loaded, and you are running a program. SHould I be avoiding EQL specializers? Can I expect to always pay this kind of performance penalty for using them? Or is there a problem? The generic function in question here as a total of four methods defined on it, three of which have EQL specializers. Eql specializers were not optimized well in the previous PCL's, and i'm not sure what happens now. Any help is really appreciated. I'm going nuts over this, because it is tied in with menu clicks, and my users are waiting over 6 seconds now between clicking on a window, and getting a response. dan haug Internet: haug@austin.lockheed.com UUCP: ut-emx!lad-shrike!aihaug Received: from Xerox.COM by arisia.xerox.com with SMTP (5.61+/IDA-1.2.8/gandalf) id AA27116; Mon, 24 Jul 89 23:39:59 -0700 Received: from Riesling.ms by ArpaGateway.ms ; 24 JUL 89 22:57:23 PDT Return-Path: Redistributed: commonloops.pa Received: from shrike.Austin.Lockheed.COM ([192.31.24.65]) by Xerox.COM ; 24 JUL 89 22:54:13 PDT Received: by shrike.Austin.Lockheed.COM (4.0/1.46); Tue, 25 Jul 89 00:53:50 CDT Date: Tue, 25 Jul 89 00:53:50 CDT From: Daniel A Haug Message-Id: <8907250553.AA12108@shrike.Austin.Lockheed.COM> To: aihaug@austin.lockheed.com, kanderso@DINO.BBN.COM Subject: Re: Help with eql specializers Cc: commonloops.pa@Xerox.COM, haug@austin.lockheed.com > From kanderso@DINO.BBN.COM Mon Jul 24 08:04:56 1989 > To: Daniel A Haug > Cc: commonloops.pa@xerox.com, haug@austin.lockheed.com > Subject: Re: Help with eql specializers > > From: Daniel A Haug > Subject: Help with eql specializers > > [problem discussed here] > > Can you extract a short example we can play with? Off hand, i'd say > that notice-methods-change... is only called when a generic function > is invalidated. It turns out that lots of unnecessary invalidation > occurs when classes are defined. However, i'm suprised that this > happens when everything is loaded, and you are running a program. This is pretty meaningless without all of the layered software to go with it, but at least you can see that I'm not doing anything funny. I timed the call from SMS-HANDLE-MAP-CLICK to HANDLE-VIEW-CONTEXT-CLICK. This call either takes about 0.03 seconds, or around 6 seconds (measured with TIME), depending on what happens with the invalidating of generic functions. ;;; ;;; this method is called first... ;;; (defmethod sms-handle-map-click ((rgi sms-rgi-mixin) args) "This is invoked in response to a map-background click: - The buffer contains the mouse-button (left,middle,right) that - was clicked" (let* ((mouse-int (first args)) (pixel-x (second args)) (pixel-y (third args)) (lat (fourth args)) (lon (fifth args)) (mouse-char (case mouse-int (0 mouse-left) (1 mouse-middle) (2 mouse-right))) (mouse-state (make-sms-mouse-state :button mouse-char :position-x pixel-x :position-y pixel-y :lat lat :lon lon)) (view-stack (sms-rgi-view-stack rgi)) (view (first view-stack))) ;; (handle-view-click-low view mouse-state))) ;;; ;;; which then calls this one... ;;; (defmethod handle-view-click-low ((view view-context-mixin ) mouse-state) (handle-view-context-click view (first (view-context-stack view)) mouse-state)) ;;; ;;; which will then call one of these three... ;;; (defmethod handle-view-context-click ((view context-view) (context (eql :first)) mouse-state) (declare (ignore mouse-state)) (print 'at-first) (pop (view-context-stack view)) (push :second (view-context-stack view))) (defmethod handle-view-context-click ((view context-view) (context (eql :second)) mouse-state) (declare (ignore mouse-state)) (print 'at-second) (pop (view-context-stack view)) (push :third (view-context-stack view))) (defmethod handle-view-context-click ((view context-view) (context (eql :third)) mouse-state) (declare (ignore mouse-state)) (print 'at-third) (pop (view-context-stack view))) =========================== end of example code ========================= Here are the methods that were in the environment at the time: For SMS-HANDLE-MAP-CLICK: (#) For HANDLE-VIEW-CLICK-LOW: (# #) For HANDLE-VIEW-CONTEXT-CLICK: (# # # # # #) I can understand that as I am developing, and adding/changing classes and methods, PCL must update everything. So, I expect to pay hits like this occasionally. But, this problem persists, with repeated mouse clicks, the same methods run over and over, without change. And still, I get the 6-plus second delay. I even rebooted and loaded freshly compiled systems, and the problem did not go away. I surely don't know enough PCL internals to tell that this is associated with eql specializers. All I know is that once I began to use them, this problem started. Okay, any suggestions again? dan haug Internet: haug@austin.lockheed.com UUCP: ut-emx!lad-shrike!aihaug Received: from Xerox.COM by arisia.xerox.com with SMTP (5.61+/IDA-1.2.8/gandalf) id AA04120; Tue, 25 Jul 89 06:44:05 -0700 Received: from Burger.ms by ArpaGateway.ms ; 25 JUL 89 06:43:21 PDT Return-Path: Redistributed: commonloops.pa Received: from DINO.BBN.COM ([128.89.3.8]) by Xerox.COM ; 25 JUL 89 06:40:13 PDT To: Daniel A Haug Cc: commonloops.pa@Xerox.COM, haug@austin.lockheed.com Subject: Re: Help with eql specializers In-Reply-To: Your message of Tue, 25 Jul 89 00:53:50 -0500. <8907250553.AA12108@shrike.Austin.Lockheed.COM> Date: Tue, 25 Jul 89 09:45:20 -0400 From: kanderso@DINO.BBN.COM Message-Id: <890725-064321-2889@Xerox> I think i see what your problem is. When you define a method, PCL invalidates the generic function. The next time you call that function, it gets rebuilt. This makes the first call very slow. Subsequent calls are at full speed. If you redefine a class, many generic functions are needlessly invalidated, including most of PCL. I consider this a HUGE BUG, but haven't been able to fix it permanently. So if you change a class and a method, the next you call the generic you must wait for it, and all of PCL to be rebuilt. So, when you do timing, throw away the first call: (defun try (it N) (funcall it) (si:without-interrupts (time (dotimes (i N) (funcall it))))) Received: from Sail.Stanford.EDU by arisia.xerox.com with SMTP (5.61+/IDA-1.2.8/gandalf) id AA05451; Tue, 25 Jul 89 07:47:04 -0700 Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 25 Jul 89 07:45:18 PDT Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 631021; 25 Jul 89 10:46:55 EDT Date: Tue, 25 Jul 89 10:46 EDT From: David A. Moon Subject: call-next-method incoherency To: Common-Lisp-Object-System@sail.stanford.edu In-Reply-To: <19890718220816.2.MOON@EUPHRATES.SCRC.Symbolics.COM>, <12uyLq@SAIL.Stanford.EDU>, <2825794999-5597375@Kelvin>, <19890719011208.6.GREGOR@SPIFF.parc.xerox.com>, <890718-184159-11318@Xerox>, <8907200126.AA28307@bhopal>, <19890720182310.5.MOON@EUPHRATES.SCRC.Symbolics.COM>, <8907202020.AA11750@challenger>, <19890720213255.6.MOON@EUPHRATES.SCRC.Symbolics.COM>, <8907202329.AA12019@challenger>, <19890721163640.5.GREGOR@SPIFF.parc.xerox.com> Message-Id: <19890725144640.8.MOON@EUPHRATES.SCRC.Symbolics.COM> Okay, #3 it is. The next-method-list argument to call-method is optional. Received: from Xerox.COM by arisia.xerox.com with SMTP (5.61+/IDA-1.2.8/gandalf) id AA08457; Tue, 25 Jul 89 12:25:18 -0700 Received: from Cabernet.ms by ArpaGateway.ms ; 25 JUL 89 11:22:54 PDT Return-Path: Redistributed: commonloops.pa Received: from shrike.Austin.Lockheed.COM ([192.31.24.65]) by Xerox.COM ; 25 JUL 89 11:21:23 PDT Received: by shrike.Austin.Lockheed.COM (4.0/1.46); Tue, 25 Jul 89 13:18:32 CDT Date: Tue, 25 Jul 89 13:18:32 CDT From: Daniel A Haug Message-Id: <8907251818.AA18468@shrike.Austin.Lockheed.COM> To: aihaug@austin.lockheed.com, kanderso@DINO.BBN.COM Subject: Re: Help with eql specializers Cc: commonloops.pa@Xerox.COM, haug@austin.lockheed.com > From kanderso@DINO.BBN.COM Tue Jul 25 08:39:32 1989 > To: Daniel A Haug > Cc: commonloops.pa@xerox.com, haug@austin.lockheed.com > Subject: Re: Help with eql specializers > > I think i see what your problem is. > > When you define a method, PCL invalidates the generic function. The > next time you call that function, it gets rebuilt. This makes the > first call very slow. Subsequent calls are at full speed. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ But this is not what's happening. I can make repeated calls to those set of functions I posted, and the invalidation happens EVERY time. But this is isolated ONLY to those functions. It is not a general problem with all of our code. dan haug Internet: haug@austin.lockheed.com UUCP: ut-emx!lad-shrike!aihaug Received: from Xerox.COM by arisia.xerox.com with SMTP (5.61+/IDA-1.2.8/gandalf) id AA12384; Tue, 25 Jul 89 15:51:43 -0700 Received: from Burger.ms by ArpaGateway.ms ; 25 JUL 89 13:27:29 PDT Return-Path: Redistributed: commonloops.pa Received: from DINO.BBN.COM ([128.89.3.8]) by Xerox.COM ; 25 JUL 89 13:24:13 PDT To: Daniel A Haug Cc: commonloops.pa@Xerox.COM, haug@austin.lockheed.com Subject: Re: Help with eql specializers In-Reply-To: Your message of Tue, 25 Jul 89 13:18:32 -0500. <8907251818.AA18468@shrike.Austin.Lockheed.COM> Date: Tue, 25 Jul 89 16:33:33 -0400 From: kanderso@DINO.BBN.COM Message-Id: <890725-132729-373@Xerox> Date: Tue, 25 Jul 89 13:18:32 CDT From: Daniel A Haug Message-Id: <8907251818.AA18468@shrike.Austin.Lockheed.COM> To: aihaug@austin.lockheed.com, kanderso@DINO.BBN.COM Subject: Re: Help with eql specializers Cc: commonloops.pa@xerox.com, haug@austin.lockheed.com > From kanderso@DINO.BBN.COM Tue Jul 25 08:39:32 1989 > To: Daniel A Haug > Cc: commonloops.pa@xerox.com, haug@austin.lockheed.com > Subject: Re: Help with eql specializers > > I think i see what your problem is. > > When you define a method, PCL invalidates the generic function. The > next time you call that function, it gets rebuilt. This makes the > first call very slow. Subsequent calls are at full speed. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ But this is not what's happening. I can make repeated calls to those set of functions I posted, and the invalidation happens EVERY time. But this is isolated ONLY to those functions. It is not a general problem with all of our code. OK, the culprit is COMPUTE-COLUMN-SPECIALIZERS and the super culprit is UPDATE-METHOD-INHERITANCE (the Skurge of PCL). Here is what is happening: 1. You have 2 or more generic functions that is specialized on the class T AND on some symbol. One of them is HANDLE-VIEW-CONTEXT-CLICK, lets call the other one FROINK. Somehow in your mouse handling loop there is a chain of function calls that leads from 1 to the other. Suppose H-V-C-C gets called first. It is invalidated (how do i know this?). In the process of becoming valid it calls COMPUTE-COLUMN-SPECIALIZERS in an attempt to compute the combined methods. This calls UPDATE-CLASS on a new instance of EQL-SPECIALIZER-CLASS for each EQL specialized methods you have (3). This in tern calls UPDATE-METHOD-INHERITANCE and invalidates every generic function on such classes as SYMBOL and T. This in turn causes FROINK to be invalidated. So you get in an infinite loop of validation and invalidation, and there is never more than 1 valid generic function specialized by T and EQL on a symbol at a time!!!!! While you are running your loop, much of your system is being invalidated. THIS IS A HORRIBLE BUG! We can probably fix it by having COMPUTE-COLUMN-SPECIALIZERS be smarter, but UPDATE-METOD-INHERITANCE is the REAL culprit as it needlessly invalidates many functions. Received: from Xerox.COM by arisia.xerox.com with SMTP (5.61+/IDA-1.2.8/gandalf) id AA08457; Tue, 25 Jul 89 12:25:18 -0700 Received: from Cabernet.ms by ArpaGateway.ms ; 25 JUL 89 11:22:54 PDT Return-Path: Redistributed: commonloops.pa Received: from shrike.Austin.Lockheed.COM ([192.31.24.65]) by Xerox.COM ; 25 JUL 89 11:21:23 PDT Received: by shrike.Austin.Lockheed.COM (4.0/1.46); Tue, 25 Jul 89 13:18:32 CDT Date: Tue, 25 Jul 89 13:18:32 CDT From: Daniel A Haug Message-Id: <8907251818.AA18468@shrike.Austin.Lockheed.COM> To: aihaug@austin.lockheed.com, kanderso@DINO.BBN.COM Subject: Re: Help with eql specializers Cc: commonloops.pa@Xerox.COM, haug@austin.lockheed.com > From kanderso@DINO.BBN.COM Tue Jul 25 08:39:32 1989 > To: Daniel A Haug > Cc: commonloops.pa@xerox.com, haug@austin.lockheed.com > Subject: Re: Help with eql specializers > > I think i see what your problem is. > > When you define a method, PCL invalidates the generic function. The > next time you call that function, it gets rebuilt. This makes the > first call very slow. Subsequent calls are at full speed. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ But this is not what's happening. I can make repeated calls to those set of functions I posted, and the invalidation happens EVERY time. But this is isolated ONLY to those functions. It is not a general problem with all of our code. dan haug Internet: haug@austin.lockheed.com UUCP: ut-emx!lad-shrike!aihaug Received: from Sail.Stanford.EDU by arisia.xerox.com with SMTP (5.61+/IDA-1.2.8/gandalf) id AA24911; Wed, 26 Jul 89 09:45:46 -0700 Received: from ti.com by SAIL.Stanford.EDU with TCP; 26 Jul 89 09:44:34 PDT Received: by ti.com id AA20965; Wed, 26 Jul 89 11:36:09 CDT Received: from Kelvin by tilde id AA05507; Wed, 26 Jul 89 11:28:34 CDT Message-Id: <2826458950-15178582@Kelvin> Sender: GRAY@kelvin.csc.ti.com Date: Wed, 26 Jul 89 11:29:10 EDT From: David N Gray To: Common-Lisp-Object-System@SAIL.Stanford.edu Cc: chapman@aitg.enet.dec.com Subject: DOCUMENTATION and DEFCLASS CLOS gurus, I think I've found a small mistake in 88-002R while reviewing Kathy's draft of the DEFCLASS description. Page 2-24 says The :DOCUMENTATION class option causes a documentation string to be attached to the class name. I believe that should say "... to the class object". Note that page 2-44 says The form (DOCUMENTATION symbol 'TYPE) returns the documentation string of the class object named by the symbol ... Test case: (DEFCLASS QQ () () (:DOCUMENTATION "Hello")) (SETF (FIND-CLASS 'ZZ) (FIND-CLASS 'QQ)) (SETF (CLASS-NAME (FIND-CLASS 'ZZ)) 'ZZ) (DOCUMENTATION 'ZZ 'TYPE) => "Hello" Any objection to making an editorial correction? Received: from Sail.Stanford.EDU by arisia.xerox.com with SMTP (5.61+/IDA-1.2.8/gandalf) id AA25826; Wed, 26 Jul 89 10:39:56 -0700 Received: from ti.com by SAIL.Stanford.EDU with TCP; 26 Jul 89 10:38:24 PDT Received: by ti.com id AA21449; Wed, 26 Jul 89 12:34:21 CDT Received: from Kelvin by tilde id AA07039; Wed, 26 Jul 89 12:24:21 CDT Message-Id: <2826462298-15379727@Kelvin> Sender: GRAY@kelvin.csc.ti.com Date: Wed, 26 Jul 89 12:24:58 EDT From: David N Gray To: Moon@STONY-BROOK.SCRC.Symbolics.COM Cc: Common-Lisp-Object-System@sail.stanford.edu Subject: method combination objects From the draft for DEFINE-METHOD-COMBINATION: > \label Values: > > % 88-002R p.2-34 said this, but it's wrong, method-combination objects > % are created by the defgeneric :method-combination option. > % See 88-002R p.1-28. --Moon > % New method combination object. > > % Added by Moon to replace wrong specification above: > > {\arg Name\/}. Oh, OK. Can I also assume then that function FIND-METHOD-COMBINATION in 89-003 is also a mistake and that all we need is GENERIC-FUNCTION-METHOD-COMBINATION ? Received: from Sail.Stanford.EDU by arisia.xerox.com with SMTP (5.61+/IDA-1.2.8/gandalf) id AA25931; Wed, 26 Jul 89 11:00:12 -0700 Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 26 Jul 89 10:59:12 PDT Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 631873; 26 Jul 89 13:59:42 EDT Date: Wed, 26 Jul 89 13:59 EDT From: David A. Moon Subject: method combination objects To: David N Gray Cc: Common-Lisp-Object-System@sail.stanford.edu In-Reply-To: <2826462298-15379727@Kelvin> Message-Id: <19890726175943.6.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Wed, 26 Jul 89 12:24:58 EDT From: David N Gray From the draft for DEFINE-METHOD-COMBINATION: > \label Values: > > % 88-002R p.2-34 said this, but it's wrong, method-combination objects > % are created by the defgeneric :method-combination option. > % See 88-002R p.1-28. --Moon > % New method combination object. > > % Added by Moon to replace wrong specification above: > > {\arg Name\/}. Oh, OK. Can I also assume then that function FIND-METHOD-COMBINATION in 89-003 is also a mistake and that all we need is GENERIC-FUNCTION-METHOD-COMBINATION ? 89-003 is so full of errors that I don't generally find it useful to comment on it. However, the macro expansion of DEFGENERIC has to have some way to convert the :METHOD-COMBINATION option from a list into an object of type METHOD-COMBINATION. I don't see anything wrong with the writeup on 89-003 p.3-61, unless maybe it needs an environment argument, so I don't think it's a mistake. Received: from Sail.Stanford.EDU by arisia.xerox.com with SMTP (5.61+/IDA-1.2.8/gandalf) id AA26727; Wed, 26 Jul 89 11:46:07 -0700 Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 26 Jul 89 11:45:01 PDT Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 631909; 26 Jul 89 14:45:26 EDT Date: Wed, 26 Jul 89 14:45 EDT From: David A. Moon Subject: DOCUMENTATION and DEFCLASS To: David N Gray Cc: Common-Lisp-Object-System@SAIL.Stanford.edu, chapman@aitg.enet.dec.com In-Reply-To: <2826458950-15178582@Kelvin> Message-Id: <19890726184525.9.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Wed, 26 Jul 89 11:29:10 EDT From: David N Gray I think I've found a small mistake in 88-002R while reviewing Kathy's draft of the DEFCLASS description. Page 2-24 says The :DOCUMENTATION class option causes a documentation string to be attached to the class name. I believe that should say "... to the class object". I think you're right. Perhaps the way the DOCUMENTATION function works was changed at some point after this had been written. As far as I'm concerned Kathy can go ahead and change "name" to "object" or to "". Received: from Sail.Stanford.EDU by arisia.xerox.com with SMTP (5.61+/IDA-1.2.8/gandalf) id AA27452; Wed, 26 Jul 89 12:42:32 -0700 Received: from ti.com by SAIL.Stanford.EDU with TCP; 26 Jul 89 12:41:39 PDT Received: by ti.com id AA22669; Wed, 26 Jul 89 14:37:05 CDT Received: from Kelvin by tilde id AA09903; Wed, 26 Jul 89 14:16:58 CDT Message-Id: <2826469058-15785914@Kelvin> Sender: GRAY@kelvin.csc.ti.com Date: Wed, 26 Jul 89 14:17:38 EDT From: David N Gray To: "David A. Moon" Cc: Common-Lisp-Object-System@sail.stanford.edu Subject: Re: method combination objects In-Reply-To: Msg of Wed, 26 Jul 89 13:59 EDT from David A. Moon > 89-003 is so full of errors that I don't generally find it useful to > comment on it. Yes, but then what _are_ we going to do with it? :-) > ... However, the macro expansion of DEFGENERIC has to have > some way to convert the :METHOD-COMBINATION option from a list into > an object of type METHOD-COMBINATION. I don't see anything wrong > with the writeup on 89-003 p.3-61, unless maybe it needs an environment > argument, so I don't think it's a mistake. Sounds then like it should be MAKE-METHOD-COMBINATION instead of FIND-METHOD-COMBINATION. Received: from Sail.Stanford.EDU by arisia.xerox.com with SMTP (5.61+/IDA-1.2.8/gandalf) id AA28103; Wed, 26 Jul 89 13:43:07 -0700 Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 26 Jul 89 13:42:10 PDT Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 632047; 26 Jul 89 16:43:53 EDT Date: Wed, 26 Jul 89 16:43 EDT From: David A. Moon Subject: Re: method combination objects To: David N Gray Cc: Common-Lisp-Object-System@sail.stanford.edu In-Reply-To: <2826469058-15785914@Kelvin> Message-Id: <19890726204352.2.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Wed, 26 Jul 89 14:17:38 EDT From: David N Gray > 89-003 is so full of errors that I don't generally find it useful to > comment on it. Yes, but then what _are_ we going to do with it? :-) > ... However, the macro expansion of DEFGENERIC has to have > some way to convert the :METHOD-COMBINATION option from a list into > an object of type METHOD-COMBINATION. I don't see anything wrong > with the writeup on 89-003 p.3-61, unless maybe it needs an environment > argument, so I don't think it's a mistake. Sounds then like it should be MAKE-METHOD-COMBINATION instead of FIND-METHOD-COMBINATION. I think the idea was that since it doesn't necessarily cons a fresh object every time you call it, it should be named like the other FIND- functions. Received: from Sail.Stanford.EDU by arisia.xerox.com with SMTP (5.61+/IDA-1.2.8/gandalf) id AA04813; Wed, 26 Jul 89 21:13:14 -0700 Received: from EDDIE.MIT.EDU by SAIL.Stanford.EDU with TCP; 26 Jul 89 21:12:12 PDT Received: by EDDIE.MIT.EDU with UUCP with smail2.5 with sendmail-5.45/4.7 id ; Thu, 27 Jul 89 00:12:41 EDT Received: by spt.entity.com (smail2.5); 27 Jul 89 00:09:50 EDT (Thu) Date: Thu, 27 Jul 1989 0:09:50 EDT From: Gail Zacharias To: common-lisp-object-system@sail.stanford.edu Subject: call-next-method Message-Id: Can call-next-method be used in init forms of optional/keyword arguments? How about &aux inits? Received: from [13.0.12.232] by arisia.xerox.com with SMTP (5.61+/IDA-1.2.8/gandalf) id AA15080; Thu, 27 Jul 89 03:39:39 -0700 Received: from Semillon.ms by ArpaGateway.ms ; 26 JUL 89 15:16:28 PDT Date: 26 Jul 89 15:15 PDT From: fischer.envos@Xerox.COM Subject: [bane%mimsy.umd:EDU:Xerox: Funky VDPCL behavior?] To: commonloops.pa@Xerox.COM Message-Id: <890726-151628-2080@Xerox> ----- Begin Forwarded Messages ----- From: John R. Bane Subject: Funky VDPCL behavior? Original-Date: Tue, 25 Jul 89 23:26:31 -0400 Message-Id: <8907260326.AA28017@mimsy.umd.edu> The Victoria Day PCL Ramana sent me is acting a little strange. I can load CAT into it fine, and it works, but sometime around when it builds the first generic functions it smashes the PCL::DIRECT-SUBCLASSES slot in the root CONTEXT class. This makes my browser lose, and looks potentially dangerous to boot. The PCL files I have are dated 23 May, mostly, which matches the file dates on arisia. Anyone else heard of anything like this? Got a fix for it? I intend to track it down, but want to avoid doing so if this is a known feature. ----- End Forwarded Messages ----- Received: from [13.0.12.232] by arisia.xerox.com with SMTP (5.61+/IDA-1.2.8/gandalf) id AA15398; Thu, 27 Jul 89 03:42:58 -0700 Received: from Semillon.ms by ArpaGateway.ms ; 26 JUL 89 15:30:04 PDT Date: 26 Jul 89 15:28 PDT From: fischer.envos@Xerox.COM Subject: [bane%mimsy.umd:EDU:Xerox: More on funky VDPCL behavior] To: commonloops.pa@Xerox.COM Message-Id: <890726-153004-2125@Xerox> ----- Begin Forwarded Messages ----- From: John R. Bane Subject: More on funky VDPCL behavior Original-Date: Wed, 26 Jul 89 15:10:45 -0400 Message-Id: <8907261910.AA21428@mimsy.umd.edu> The smashing of the PCL::DIRECT-SUBCLASSES slot seems to be related to building a generic function containing a method dispatching on (EQL *mumble*). (EQL *mumble*) methods are new in PCL with Victoria Day, aren't they? ----- End Forwarded Messages ----- Received: from Sail.Stanford.EDU by arisia.xerox.com with SMTP (5.61+/IDA-1.2.8/gandalf) id AA18777; Thu, 27 Jul 89 09:06:31 -0700 Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 27 Jul 89 09:04:37 PDT Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 632522; 27 Jul 89 12:06:36 EDT Date: Thu, 27 Jul 89 12:06 EDT From: David A. Moon Subject: call-next-method To: Gail Zacharias Cc: common-lisp-object-system@sail.stanford.edu In-Reply-To: Message-Id: <19890727160635.2.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Thu, 27 Jul 1989 0:09:50 EDT From: Gail Zacharias Can call-next-method be used in init forms of optional/keyword arguments? How about &aux inits? The documentation everywhere says "in the body of a method", which presumably excludes forms contained in the lambda-list, since "body of the method" is explicitly defined in the documentation of DEFMETHOD. Personally I think that was a poor design decision. Current practice: PCL appears to allow call-next-method in forms in the lambda-list. Flavors doesn't allow continue-whopper in forms in the lambda-list, although there is no reason why it couldn't. Received: from Xerox.COM by arisia.xerox.com with SMTP (5.61+/IDA-1.2.8/gandalf) id AA01615; Thu, 27 Jul 89 15:39:38 -0700 Received: from Cabernet.ms by ArpaGateway.ms ; 27 JUL 89 15:37:33 PDT Date: 27 Jul 89 15:36 PDT From: fischer.envos@Xerox.COM Subject: [bane%mimsy.umd:EDU:Xerox: VDPCL flakiness solved] To: commonloops.pa@Xerox.COM Message-Id: <890727-153733-1480@Xerox> ----- Begin Forwarded Messages ----- From: John R. Bane Subject: VDPCL flakiness solved Original-Date: Wed, 26 Jul 89 19:13:17 -0400 There is a bug in DELETE-CLASS, a method defined in defclass.lisp and only used in COMPUTE-COMBINATION-POINTS in points.lisp to clean up the class structure after creating eql combined-methods. Here's the corrected code, complete with its original comments: ;;; *** *** ;;; *** This is a piece of shit. I had to do it quickly to get around *** ;;; *** the defaulting of direct supers above. Note that the new *** ;;; *** metaobject protocol solves this problem. *** ;;; *** *** (defmethod delete-class ((class standard-class)) (dolist (super (class-local-supers class)) (setf (class-direct-subclasses super) (delete class (class-direct-subclasses super))))) The faulty code called delete with (class-direct-subclasses class). Would one of y'all bring this to the attention of the PCL gods? ----- End Forwarded Messages ----- Received: from Xerox.COM by arisia.xerox.com with SMTP (5.61+/IDA-1.2.8/gandalf) id AA01615; Thu, 27 Jul 89 15:39:38 -0700 Received: from Cabernet.ms by ArpaGateway.ms ; 27 JUL 89 15:37:33 PDT Date: 27 Jul 89 15:36 PDT From: fischer.envos@Xerox.COM Subject: [bane%mimsy.umd:EDU:Xerox: VDPCL flakiness solved] To: commonloops.pa@Xerox.COM Message-Id: <890727-153733-1480@Xerox> ----- Begin Forwarded Messages ----- From: John R. Bane Subject: VDPCL flakiness solved Original-Date: Wed, 26 Jul 89 19:13:17 -0400 There is a bug in DELETE-CLASS, a method defined in defclass.lisp and only used in COMPUTE-COMBINATION-POINTS in points.lisp to clean up the class structure after creating eql combined-methods. Here's the corrected code, complete with its original comments: ;;; *** *** ;;; *** This is a piece of shit. I had to do it quickly to get around *** ;;; *** the defaulting of direct supers above. Note that the new *** ;;; *** metaobject protocol solves this problem. *** ;;; *** *** (defmethod delete-class ((class standard-class)) (dolist (super (class-local-supers class)) (setf (class-direct-subclasses super) (delete class (class-direct-subclasses super))))) The faulty code called delete with (class-direct-subclasses class). Would one of y'all bring this to the attention of the PCL gods? ----- End Forwarded Messages ----- Received: from Xerox.COM by arisia.xerox.com with SMTP (5.61+/IDA-1.2.8/gandalf) id AA01615; Thu, 27 Jul 89 15:39:38 -0700 Received: from Cabernet.ms by ArpaGateway.ms ; 27 JUL 89 15:37:33 PDT Date: 27 Jul 89 15:36 PDT From: fischer.envos@Xerox.COM Subject: [bane%mimsy.umd:EDU:Xerox: VDPCL flakiness solved] To: commonloops.pa@Xerox.COM Message-Id: <890727-153733-1480@Xerox> ----- Begin Forwarded Messages ----- From: John R. Bane Subject: VDPCL flakiness solved Original-Date: Wed, 26 Jul 89 19:13:17 -0400 There is a bug in DELETE-CLASS, a method defined in defclass.lisp and only used in COMPUTE-COMBINATION-POINTS in points.lisp to clean up the class structure after creating eql combined-methods. Here's the corrected code, complete with its original comments: ;;; *** *** ;;; *** This is a piece of shit. I had to do it quickly to get around *** ;;; *** the defaulting of direct supers above. Note that the new *** ;;; *** metaobject protocol solves this problem. *** ;;; *** *** (defmethod delete-class ((class standard-class)) (dolist (super (class-local-supers class)) (setf (class-direct-subclasses super) (delete class (class-direct-subclasses super))))) The faulty code called delete with (class-direct-subclasses class). Would one of y'all bring this to the attention of the PCL gods? ----- End Forwarded Messages ----- Received: from Xerox.COM by arisia.xerox.com with SMTP (5.61+/IDA-1.2.8/gandalf) id AA17400; Fri, 28 Jul 89 09:44:06 -0700 Received: from Riesling.ms by ArpaGateway.ms ; 28 JUL 89 09:39:59 PDT Return-Path: Redistributed: commonloops.pa Received: from VAX.BBN.COM ([128.89.0.91]) by Xerox.COM ; 28 JUL 89 09:37:47 PDT Received: by VAX.BBN.COM id aa20190; 28 Jul 89 12:26 EDT To: commonloops.pa@Xerox.COM Subject: Try this out: better UMI. Date: Fri, 28 Jul 89 12:21:10 -0400 From: Mike Thome Message-Id: <890728-093959-2929@Xerox> I've come up with what seems to be a "better" Update-method-inheritance... "better" at least in the sense that it only invalidates generic functions which already have the class in question cached. Does it work? I've not been able to break it, after trying it out one two significant meta-level systems, two clos-browsers and several other systems... I've gotten as much as 20% speedup on loading classes, plus the non-invalidation of lots of gfns. The patch can be loaded on top of a running pcl - no recompiling your system, either. I'm pretty certain that it can be made still better, but at least it avoids the EQL specializer bug Dan Haug recently noticed, and elimates large quantities of useless invalidation. -mike (mthome@bbn.com) ;;; -*- Package: PCL; Syntax: Common-Lisp -*- (defun class-wrapper-in-gfn-cache (wrapper gfn) (let ((cache (generic-function-cache gfn))) (and cache (find wrapper cache :test #'eq :start 1)))) (defmethod update-method-inheritance ((class standard-class) old-cpl new-cpl) (let ((wrapper (class-wrapper class))) (flet ((reset-gfs (c) (dolist (m (class-direct-methods c)) (let ((gf (method-generic-function m))) (when (and (not (memq gf *umi-gfs*)) (class-wrapper-in-gfn-cache wrapper gf)) (invalidate-generic-function gf) (push gf *umi-gfs*))))) (reset-some-gfs (c1 c2) (let ((gfs1 ())) (dolist (m (class-direct-methods c1)) (pushnew (method-generic-function m) gfs1)) (dolist (m (class-direct-methods c2)) (let ((gf (method-generic-function m))) (when (and (memq gf gfs1) (not (memq gf *umi-gfs*)) (class-wrapper-in-gfn-cache wrapper gf)) (invalidate-generic-function gf) (push gf *umi-gfs*))))))) (multiple-value-bind (appear disappear reorder) (reordered-classes old-cpl new-cpl) (dolist (a appear) (unless (memq a *umi-complete-classes*) (reset-gfs a) (push a *umi-complete-classes*))) (dolist (d disappear) (unless (memq d *umi-complete-classes*) (reset-gfs d) (push d *umi-complete-classes*))) (dolist (r reorder) (dolist (c1 r) (dolist (c2 (memq c1 r)) (let ((temp nil)) (cond ((setq temp (assq c1 *umi-reorder*)) (unless (memq c2 temp) (reset-some-gfs c1 c2) (push c2 (cdr temp)))) ((setq temp (assq c2 *umi-reorder*)) (unless (memq c1 temp) (reset-some-gfs c1 c2) (push c1 (cdr temp)))) (t (push (list c1 c2) *umi-reorder*))))))))))) (defmethod m-1 ((x (eql :x)) stuff) (print (list x :x))) (defmethod m-2 ((x (eql :x)) stuff) (print (list x :x))) Received: from Sail.Stanford.EDU by arisia.xerox.com with SMTP (5.61+/IDA-1.2.8/gandalf) id AA19940; Fri, 28 Jul 89 12:03:32 -0700 Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 28 Jul 89 12:02:26 PDT Received: from Semillon.ms by ArpaGateway.ms ; 28 JUL 89 11:50:19 PDT Date: Fri, 28 Jul 89 11:47 PDT From: Gregor.pa@Xerox.COM Subject: Re: call-next-method To: David A. Moon Cc: Gail Zacharias , common-lisp-object-system@sail.stanford.edu Fcc: BD:>Gregor>mail>outgoing-mail-7.text.newest In-Reply-To: <19890727160635.2.MOON@EUPHRATES.SCRC.Symbolics.COM> Message-Id: <19890728184745.0.GREGOR@SPIFF.parc.xerox.com> Line-Fold: no Date: Thu, 27 Jul 89 12:06 EDT From: David A. Moon The documentation everywhere says "in the body of a method", which presumably excludes forms contained in the lambda-list, since "body of the method" is explicitly defined in the documentation of DEFMETHOD. Personally I think that was a poor design decision. Current practice: PCL appears to allow call-next-method in forms in the lambda-list. Flavors doesn't allow continue-whopper in forms in the lambda-list, although there is no reason why it couldn't. I rewrote PCL to allow this because I remembered us having a long discussion during which we decided this was the desired behavior. So, I am surprised to see that the spec doesn't say this is right. ------- Received: from Xerox.COM by arisia.xerox.com with SMTP (5.61+/IDA-1.2.8/gandalf) id AA17400; Fri, 28 Jul 89 09:44:06 -0700 Received: from Riesling.ms by ArpaGateway.ms ; 28 JUL 89 09:39:59 PDT Return-Path: Redistributed: commonloops.pa Received: from VAX.BBN.COM ([128.89.0.91]) by Xerox.COM ; 28 JUL 89 09:37:47 PDT Received: by VAX.BBN.COM id aa20190; 28 Jul 89 12:26 EDT To: commonloops.pa@Xerox.COM Subject: Try this out: better UMI. Date: Fri, 28 Jul 89 12:21:10 -0400 From: Mike Thome Message-Id: <890728-093959-2929@Xerox> I've come up with what seems to be a "better" Update-method-inheritance... "better" at least in the sense that it only invalidates generic functions which already have the class in question cached. Does it work? I've not been able to break it, after trying it out one two significant meta-level systems, two clos-browsers and several other systems... I've gotten as much as 20% speedup on loading classes, plus the non-invalidation of lots of gfns. The patch can be loaded on top of a running pcl - no recompiling your system, either. I'm pretty certain that it can be made still better, but at least it avoids the EQL specializer bug Dan Haug recently noticed, and elimates large quantities of useless invalidation. -mike (mthome@bbn.com) ;;; -*- Package: PCL; Syntax: Common-Lisp -*- (defun class-wrapper-in-gfn-cache (wrapper gfn) (let ((cache (generic-function-cache gfn))) (and cache (find wrapper cache :test #'eq :start 1)))) (defmethod update-method-inheritance ((class standard-class) old-cpl new-cpl) (let ((wrapper (class-wrapper class))) (flet ((reset-gfs (c) (dolist (m (class-direct-methods c)) (let ((gf (method-generic-function m))) (when (and (not (memq gf *umi-gfs*)) (class-wrapper-in-gfn-cache wrapper gf)) (invalidate-generic-function gf) (push gf *umi-gfs*))))) (reset-some-gfs (c1 c2) (let ((gfs1 ())) (dolist (m (class-direct-methods c1)) (pushnew (method-generic-function m) gfs1)) (dolist (m (class-direct-methods c2)) (let ((gf (method-generic-function m))) (when (and (memq gf gfs1) (not (memq gf *umi-gfs*)) (class-wrapper-in-gfn-cache wrapper gf)) (invalidate-generic-function gf) (push gf *umi-gfs*))))))) (multiple-value-bind (appear disappear reorder) (reordered-classes old-cpl new-cpl) (dolist (a appear) (unless (memq a *umi-complete-classes*) (reset-gfs a) (push a *umi-complete-classes*))) (dolist (d disappear) (unless (memq d *umi-complete-classes*) (reset-gfs d) (push d *umi-complete-classes*))) (dolist (r reorder) (dolist (c1 r) (dolist (c2 (memq c1 r)) (let ((temp nil)) (cond ((setq temp (assq c1 *umi-reorder*)) (unless (memq c2 temp) (reset-some-gfs c1 c2) (push c2 (cdr temp)))) ((setq temp (assq c2 *umi-reorder*)) (unless (memq c1 temp) (reset-some-gfs c1 c2) (push c1 (cdr temp)))) (t (push (list c1 c2) *umi-reorder*))))))))))) (defmethod m-1 ((x (eql :x)) stuff) (print (list x :x))) (defmethod m-2 ((x (eql :x)) stuff) (print (list x :x))) Received: from [13.0.12.232] by arisia.xerox.com with SMTP (5.61+/IDA-1.2.8/gandalf) id AA11993; Wed, 2 Aug 89 00:14:42 -0700 Received: from Chardonnay.ms by ArpaGateway.ms ; 02 AUG 89 00:14:45 PDT Return-Path: Redistributed: commonloops.pa Received: from ra.cs.ucla.edu ([131.179.128.33]) by Xerox.COM ; 02 AUG 89 00:09:08 PDT Return-Path: Received: by ra.cs.ucla.edu (Sendmail 4.0/2.10) id AA20610; Wed, 2 Aug 89 00:10:02 PDT Date: Wed, 2 Aug 89 00:10:02 PDT From: mujica@CS.UCLA.EDU (S. Mujica) Message-Id: <8908020710.AA20610@ra.cs.ucla.edu> To: clue-review@dsg.csc.ti.com Cc: commonloops.pa@Xerox.COM, sara@CS.UCLA.EDU Subject: compiling clue with victoria day pcl I am compiling CLUE using Victoria day PCL in Lucid 3.0.2. While compiling (defcontact composite ... ) in intrinsics.lisp, PCL goes bananas... and it loops in the following cycle: PCL::|(METHOD UPDATE-METHOD-INHERITANCE (STANDARD-CLASS T T))| <- PCL::|(METHOD PROPAGATE-CLASS-UPDATE (STANDARD-CLASS T T T))| <- PCL::|(METHOD UPDATE-CLASS (STANDARD-CLASS))| <- PCL::COMPUTE-COLUMN-SPECIALIZERS <- PCL::COMPUTE-COMBINATION-POINTS <- PCL::COMPUTE-COMBINED-METHODS <- PCL::NOTICE-METHODS-CHANGE-1 <- (:INTERNAL NIL PCL::RESET-GFS) <- The particularities of PCL are: > (pcl::bug-report-info) PCL system date: 5/22/89 Victoria Day PCL Lisp Implementation type: Lucid Common Lisp Lisp Implementation version: 3.0.2 *features*: (:CLOS :XLIB :PORTABLE-COMMONLOOPS :PCL :PQC :COMMON-LISP :LUCID :UNIX :SUN :MC68000 :IEEE-FLOATING-POINT :LCL3.0 :LOOP :EGC :COMPILER) NIL > (please note that I renamed the package pcl to have the synonym clos) Question: Has anyone succeded in compiling CLUE with Lucid 3.0.2 + Victoria day PCL? am I missing some patches to pcl? Sergio Mujica mujica@cs.ucla.edu Computer Science Department, UCLA Received: from Xerox.COM by arisia.xerox.com with SMTP (5.61+/IDA-1.2.8/gandalf) id AA08571; Wed, 2 Aug 89 18:03:40 -0700 Received: from Chardonnay.ms by ArpaGateway.ms ; 02 AUG 89 17:59:04 PDT Return-Path: Redistributed: commonloops.pa Received: from shrike.Austin.Lockheed.COM ([192.31.24.65]) by Xerox.COM ; 02 AUG 89 17:53:06 PDT Received: by shrike.Austin.Lockheed.COM (4.0/1.46); Wed, 2 Aug 89 19:52:02 CDT Date: Wed, 2 Aug 89 19:52:02 CDT From: Daniel A Haug Message-Id: <8908030052.AA21953@shrike.Austin.Lockheed.COM> To: commonloops.pa@Xerox.COM Subject: thanks Just wanted to say that Mike Thome's patch works great, and my 8-second window-click delay is now history. Thanks to both Mike and Ken Anderson for their help. dan haug Internet: haug@austin.lockheed.com UUCP: ut-emx!lad-shrike!aihaug Received: from Xerox.COM by arisia.xerox.com with SMTP (5.61+/IDA-1.2.8/gandalf) id AA28219; Thu, 3 Aug 89 10:58:42 -0700 Received: from Chardonnay.ms by ArpaGateway.ms ; 03 AUG 89 09:45:26 PDT Return-Path: Redistributed: commonloops.pa Received: from ra.cs.ucla.edu ([131.179.128.33]) by Xerox.COM ; 03 AUG 89 09:37:23 PDT Return-Path: Received: by ra.cs.ucla.edu (Sendmail 4.0/2.10) id AA02107; Thu, 3 Aug 89 09:39:46 PDT Date: Thu, 3 Aug 89 09:39:46 PDT From: mujica@CS.UCLA.EDU (S. Mujica) Message-Id: <8908031639.AA02107@ra.cs.ucla.edu> To: commonloops.pa@Xerox.COM Cc: sara@CS.UCLA.EDU Subject: bug in methods' lambda lists Running Victoria Day PCL (5/22/89) Lucid Common Lisp 3.0.2, in a Sun 3/280, the following code causes the compiler to abort with a bus error: -------------------------- (in-package 'user :use '(pcl)) (defclass a () ()) (defmethod move-focus ((x a) &optional y &key z) (ignore x y z) nil) -------------------------- > (compile-file "pcl-bug") ;;; You are using the compiler in production mode (compilation-speed = 0) ;;; Generation of runtime error checking code is disabled (safety = 0) ;;; Tail recursion elimination is enabled (speed = 3) ;;; Reading source file "pcl-bug.lisp" >>Trap: Bus error LUCID:COMPILE-FORM: Required arg 0 (FORM): (DEFINE-FUNCTION (QUOTE LUCID::%TOPLEVEL-THUNK) (FUNCTION (LAMBDA NIL # NIL))) Required arg 1 (MODE): LUCID::TOPLEVEL Required arg 2 (OUTPUT): # Rest arg 3 (OUTARGS): (# # #) :A 0: Abort to Lisp Top Level -------------------------- It compiles right if the lambda list of the method is changed to: (defmethod move-focus ((x a) &key z &optional y) (ignore x y z) nil) Sergio Mujica mujica@cs.ucla.edu Computer Science Department, UCLA Received: from Sail.Stanford.EDU by arisia.xerox.com with SMTP (5.61+/IDA-1.2.8/gandalf) id AA28734; Thu, 3 Aug 89 11:15:48 -0700 Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 3 Aug 89 11:15:31 PDT Received: from Semillon.ms by ArpaGateway.ms ; 03 AUG 89 10:58:53 PDT Date: Thu, 3 Aug 89 10:56 PDT From: Gregor.pa@Xerox.COM Subject: Re: call-next-method incoherency To: David A. Moon Cc: Common-Lisp-Object-System@sail.stanford.edu Fcc: BD:>Gregor>mail>outgoing-mail-7.text.newest In-Reply-To: <19890725144640.8.MOON@EUPHRATES.SCRC.Symbolics.COM> Message-Id: <19890803175625.3.GREGOR@SPIFF.parc.xerox.com> Line-Fold: no It would be nice to have a one or two page list of all the changes that have been made to CLOS since we voted 88-002R. Something that collects up, in one place, everything that will be different about what appears in the draft standard from 88-002R. Does one of us already have such a list? ------- Received: from Sail.Stanford.EDU by arisia.xerox.com with SMTP (5.61+/IDA-1.2.8/gandalf) id AA29216; Thu, 3 Aug 89 11:35:03 -0700 Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 3 Aug 89 11:34:25 PDT Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 635936; 3 Aug 89 14:36:20 EDT Date: Thu, 3 Aug 89 14:36 EDT From: David A. Moon Subject: Re: call-next-method incoherency To: Common-Lisp-Object-System@sail.stanford.edu In-Reply-To: <19890803175625.3.GREGOR@SPIFF.parc.xerox.com> Message-Id: <19890803183629.9.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Thu, 3 Aug 89 10:56 PDT From: Gregor.pa@Xerox.COM It would be nice to have a one or two page list of all the changes that have been made to CLOS since we voted 88-002R. Something that collects up, in one place, everything that will be different about what appears in the draft standard from 88-002R. Does one of us already have such a list? I don't, although I did make a list of all the cleanup issues that appear to affect CLOS, which is enclosed below. I believe changes like this are supposed to be flagged in the draft of the Common Lisp specification, so a list could be constructed that way. The one or two that I did were mailed to this mailing list. This is the list of X3J13 issues I found that affect CLOS. I can't prove that I didn't miss any. There should be one saying that FUNCTION, HASH-TABLE, etc. have been made into classes, but I couldn't find it. Maybe they forgot to do that. However, the draft ANSI CL spec does have these as classes. CLOS-MACRO-COMPILATION should be no impact, but be careful about DEFINE-METHOD-COMBINATION COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS the CLOS part was removed by amendment, so ignore this DATA-TYPES-HIERARCHY-UNDERSPECIFIED, FUNCTION-TYPE -- just background DESCRIBE-UNDERSPECIFIED FUNCTION-NAME probably does not contradict 88-002R, but check it LOAD-OBJECTS REAL-NUMBER-TYPE SYMBOL-MACROLET-DECLARE SYMBOL-MACROLET-SEMANTICS SYNTACTIC-ENVIRONMENT-ACCESS -- as it relates to SYMBOL-MACROLET TYPE-OF-UNDERCONSTRAINED UNDEFINED-VARIABLES-AND-FUNCTIONS Received: from Sail.Stanford.EDU by arisia.xerox.com with SMTP (5.61+/IDA-1.2.8/gandalf) id AA01050; Thu, 3 Aug 89 13:34:42 -0700 Received: from ti.com by SAIL.Stanford.EDU with TCP; 3 Aug 89 13:33:45 PDT Received: by ti.com id AA08210; Thu, 3 Aug 89 15:34:10 CDT Received: from Kelvin by tilde id AA24773; Thu, 3 Aug 89 15:26:08 CDT Message-Id: <2827164387-5553656@Kelvin> Sender: GRAY@kelvin.csc.ti.com Date: Thu, 3 Aug 89 15:26:27 EDT From: David N Gray To: Gregor.pa@Xerox.COM Cc: Common-Lisp-Object-System@sail.stanford.edu Subject: CLOS changes In-Reply-To: Msg of Thu, 3 Aug 89 10:56 PDT from Gregor.pa@Xerox.COM > It would be nice to have a one or two page list of all the changes that > have been made to CLOS since we voted 88-002R. Something that collects > up, in one place, everything that will be different about what appears > in the draft standard from 88-002R. > > Does one of us already have such a list? > ------- Here's what I had written for our users: This section lists changes to the specification that have been adopted by the ANSI Common Lisp committee since the June 1988 edition of the CLOS specification. The forms symbol-macrolet, with-slots, and with-accessors will accept declarations at the beginning of the body. In particular, type declarations may be given for the variables being defined. For example, (with-slots (n) object (declare (integer n)) (foo n)) is equivalent to: (foo (the integer (slot-value object 'n))) . Within the body of symbol-macrolet, with-slots, and with-accessors, the variables defined can be altered by psetq and multiple-value-setq besides setq and setf. When the compiler encounters an instance or structure that needs to be written to the object file as a constant, it calls the generic function make-load-form to find out what to do. make-load-form is called with the object as its argument; it is expected to return a form which is to be written to the file and evaluated by the loader to create the object. In order to handle recursive data structures, two values may be returned, the first being a form to be evaluated to allocate the object and the second value being a form to be evaluated to finish initializing the object. The first form should return the object created; the second form can refer to the object as one of its arguments; the value returned by the second form is not used. Users can write methods for make-load-form to enable writing instances of their classes. Function symbol-function will continue to work only for symbols; to reference the definition of a (setf ...) function, use function fdefinition. Functions named (setf symbol) can be defined by defun, flet and labels as well as by defgeneric, generic-flet and generic-labels. Instead of making describe a generic function, describe will call the generic function describe-object with two arguments -- the object and the output stream. Users can then write methods for describe-object. Note that this parallels the relationship between print and print-object. symbol-macrolet has been changed from a macro to a special form. When this change is made, the second example on page 2-81 will no longer be valid because macroexpand will expand a symbol defined by symbol-macrolet. Received: from Sail.Stanford.EDU by arisia.xerox.com with SMTP (5.61+/IDA-1.2.8/gandalf) id AA04976; Thu, 3 Aug 89 17:33:21 -0700 Received: from ti.com by SAIL.Stanford.EDU with TCP; 3 Aug 89 17:32:40 PDT Received: by ti.com id AA09991; Thu, 3 Aug 89 19:33:32 CDT Received: from Kelvin by tilde id AA29408; Thu, 3 Aug 89 19:17:19 CDT Message-Id: <2827178271-777909@Kelvin> Sender: GRAY@kelvin.csc.ti.com Date: Thu, 3 Aug 89 19:17:51 EDT From: David N Gray To: Gregor.pa@Xerox.COM Cc: Common-Lisp-Object-System@SAIL.Stanford.edu Subject: MOP slot definition questions A couple more problems with document 89-003: Page 3-91 says that methods should be defined for generic functions SLOT-DEFINITION-NAME, SLOT-DEFINITION-INITFORM, etc. on class SLOT-DEFINITION, but page 3-71 says that these items are initialized by a SHARED-INITIALIZE method on class STANDARD-SLOT-DEFINITION. This is inconsistent. I believe that page 3-91 should specify that these methods are on class STANDARD-SLOT-DEFINITION. Likewise, the primary methods for SLOT-DEFINITION-READERS and SLOT-DEFINITION-WRITERS at the bottom of the page should be on class STANDARD-DIRECT-SLOT-DEFINITION. In the implementation of DEFCLASS, page 3-15 says that ENSURE-CLASS will be called with the :SLOTS argument being a list of "canonicalized slot definitions", which are lists, as described on page 3-14. The description of ENSURE-CLASS on page 3-48 doesn't mention :SLOTS; presumably they are passed through unchanged to ENSURE-CLASS-USING-CLASS. The description of ENSURE-CLASS-USING-CLASS does not explicitly mention :SLOTS, but says on page 3-51 that "All other keyword arguments are included directly in the initialization arguments." Page 3-62 says that INITIALIZE-INSTANCE doesn't do anything special for classes. Page 3-63 says that the :SLOTS argument for the SHARED-INITIALIZE method "is a list of direct slot definition objects. ... An error is signalled if ... any element of this argument is not of type DIRECT-SLOT-DEFINITION." So this chain of events is begun by passing in a list, and we expect to receive an object at the end, but nobody is specified to perform that conversion. The call graph shows SHARED-INITIALIZE calling something called DIRECT-SLOT-DEFINITION-CLASS, which suggests that the call to MAKE-INSTANCE should be done at that level, although I can't find any reference to DIRECT-SLOT-DEFINITION-CLASS in the document. Doing it in SHARED-INITIALIZE would make sense, but that would mean that page 3-63 is wrong. Can someone enlighten me on what the intent was? Received: from Sail.Stanford.EDU by arisia.xerox.com with SMTP (5.61+/IDA-1.2.8/gandalf) id AA04983; Thu, 3 Aug 89 17:33:48 -0700 Received: from ti.com by SAIL.Stanford.EDU with TCP; 3 Aug 89 17:32:37 PDT Received: by ti.com id AA09990; Thu, 3 Aug 89 19:33:32 CDT Received: from Kelvin by tilde id AA29408; Thu, 3 Aug 89 19:17:19 CDT Message-Id: <2827178271-777909@Kelvin> Sender: GRAY@kelvin.csc.ti.com Date: Thu, 3 Aug 89 19:17:51 EDT From: David N Gray To: Gregor.pa@Xerox.COM Cc: Common-Lisp-Object-System@SAIL.Stanford.edu Subject: MOP slot definition questions A couple more problems with document 89-003: Page 3-91 says that methods should be defined for generic functions SLOT-DEFINITION-NAME, SLOT-DEFINITION-INITFORM, etc. on class SLOT-DEFINITION, but page 3-71 says that these items are initialized by a SHARED-INITIALIZE method on class STANDARD-SLOT-DEFINITION. This is inconsistent. I believe that page 3-91 should specify that these methods are on class STANDARD-SLOT-DEFINITION. Likewise, the primary methods for SLOT-DEFINITION-READERS and SLOT-DEFINITION-WRITERS at the bottom of the page should be on class STANDARD-DIRECT-SLOT-DEFINITION. In the implementation of DEFCLASS, page 3-15 says that ENSURE-CLASS will be called with the :SLOTS argument being a list of "canonicalized slot definitions", which are lists, as described on page 3-14. The description of ENSURE-CLASS on page 3-48 doesn't mention :SLOTS; presumably they are passed through unchanged to ENSURE-CLASS-USING-CLASS. The description of ENSURE-CLASS-USING-CLASS does not explicitly mention :SLOTS, but says on page 3-51 that "All other keyword arguments are included directly in the initialization arguments." Page 3-62 says that INITIALIZE-INSTANCE doesn't do anything special for classes. Page 3-63 says that the :SLOTS argument for the SHARED-INITIALIZE method "is a list of direct slot definition objects. ... An error is signalled if ... any element of this argument is not of type DIRECT-SLOT-DEFINITION." So this chain of events is begun by passing in a list, and we expect to receive an object at the end, but nobody is specified to perform that conversion. The call graph shows SHARED-INITIALIZE calling something called DIRECT-SLOT-DEFINITION-CLASS, which suggests that the call to MAKE-INSTANCE should be done at that level, although I can't find any reference to DIRECT-SLOT-DEFINITION-CLASS in the document. Doing it in SHARED-INITIALIZE would make sense, but that would mean that page 3-63 is wrong. Can someone enlighten me on what the intent was? Received: from [36.86.0.194] by arisia.xerox.com with SMTP (5.61+/IDA-1.2.8/gandalf) id AA20020; Fri, 4 Aug 89 09:22:27 -0700 Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 4 Aug 89 09:06:33 PDT Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 636580; 4 Aug 89 12:08:23 EDT Date: Fri, 4 Aug 89 12:08 EDT From: David A. Moon Subject: CLOS changes To: Common-Lisp-Object-System@sail.stanford.edu In-Reply-To: <19890803183629.9.MOON@EUPHRATES.SCRC.Symbolics.COM> Message-Id: <19890804160840.9.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Thu, 3 Aug 89 14:36 EDT From: David A. Moon Date: Thu, 3 Aug 89 10:56 PDT From: Gregor.pa@Xerox.COM It would be nice to have a one or two page list of all the changes that have been made to CLOS since we voted 88-002R. I believe changes like this are supposed to be flagged in the draft of the Common Lisp specification, so a list could be constructed that way. The one or two that I did were mailed to this mailing list. Here is a summary of the changes that I made while reviewing some of the CLOS function pages (other than strictly grammatical type improvements). I might have made some changes while reviewing the Types section (2.2) but it's too long ago to remember. Those would have been only changes to make it reflect cleanup issues that had been passed. Clarify that the arguments to CALL-METHOD are not evaluated. If the invocation of call-method is lexically inside of a make-method, the arguments are those that were supplied to that method. Otherwise the arguments are those that were supplied to the generic function. Clarify where MAKE-METHOD can be used. The form used with make-method is evaluated in the null lexical environment augmented with a local macro definition for call-method and with bindings named by symbols not accessible from the common-lisp-user package. The second argument to CALL-METHOD is now optional. Changed the value returned by DEFINE-METHOD-COMBINATION from a method combination object [which doesn't make any sense] to the name argument. In DEFINE-METHOD-COMBINATION: The effective method is evaluated in the null lexical environment augmented with a local macro definition for call-method and with bindings named by symbols not accessible from the common-lisp-user package. Rewrote the description of the :ARGUMENTS option to DEFINE-METHOD-COMBINATION to clarify how mismatch between these arguments and the generic function's arguments is handled, and to forbid modifying the arguments. Received: from Xerox.COM by arisia.xerox.com with SMTP (5.61+/IDA-1.2.8/gandalf) id AA18068; Mon, 7 Aug 89 19:01:03 -0700 Received: from Chardonnay.ms by ArpaGateway.ms ; 07 AUG 89 15:05:02 PDT Return-Path: Redistributed: commonloops.pa Received: from VAX.BBN.COM ([128.89.0.91]) by Xerox.COM ; 07 AUG 89 13:09:03 PDT To: gregor.pa@Xerox.COM Cc: commonloops.pa@Xerox.COM Subject: PCL patches (Victoria Day) Date: Mon, 07 Aug 89 15:59:06 -0400 From: Mike Thome Message-Id: <890807-150502-2475@Xerox> I've enclosed below a set of patches to fix a variety of different problems with Victoria Day PCL. Some of them are only for Genera, some are applicable to all... some might have been posted previously. Enjoy! -mike (mthome@bbn.com) ;;;-*-Mode:LISP; Package:(PCL LISP 1000); Base:10; Syntax:Common-lisp; Patch-File: Yes -*- ;;; ;;; methods.lisp ;;; ;; hacked by MT to use cerror (usefully) ; original by Rick Harris (defun check-lambda-list-congruency (generic-function method) (flet ((reset-gfn () (setf (generic-function-methods generic-function) nil))) (macrolet ((err (string &rest args) `(unless (cerror "Use this method instead (purge the old methods)" ,string ,@args) (reset-gfn)))) (let ((methods (generic-function-methods generic-function))) (when methods (multiple-value-bind (gf-required gf-optional gf-rest gf-key gf-allow-other-keys) (method-pretty-arglist (car methods)) (multiple-value-bind (required optional rest key allow-other-keys) (method-pretty-arglist method) (unless (= (length gf-required) (length required)) (err "~S has ~D required arguments,~ but existing methods have ~D required arguments" method (length required) (length gf-required))) (unless (= (length gf-optional) (length optional)) (err "~S has ~D optional arguments,~ but existing methods have ~D optional arguments" method (length optional) (length gf-optional))) (if (or gf-rest gf-key gf-allow-other-keys) (unless (or rest key allow-other-keys) (err "~S has neither &key nor &rest in its lambda-list,~ conflicting with existing methods" method)) (unless (not (or rest key allow-other-keys)) (err "~S has a &key or a &rest in its lambda-list,~ conflicting with existing methods" method)))))))))) ;; fix another potential infinite loop in dcode. ;; (defmethod install-discriminating-function ((generic-function standard-generic-function) function) (set-funcallable-instance-function generic-function function) #+ignore (setf (generic-function-discriminator-code generic-function) function) #-ignore (setf (slot-value generic-function 'discriminator-code) function)) ;;;Handle &AUX variables correctly (esp. for check-lambda-list-congruency) (defmethod method-pretty-arglist ((method standard-method)) (let ((required ()) (optional ()) (rest nil) (key ()) (aux ()) (allow-other-keys nil) (state 'required) (arglist (method-arglist method))) (dolist (arg arglist) (cond ((eq arg '&optional) (setq state 'optional)) ((eq arg '&rest) (setq state 'rest)) ((eq arg '&key) (setq state 'key)) ((eq arg '&allow-other-keys) (setq allow-other-keys 't)) ((eq arg '&aux) (setq state 'aux)) ((memq arg lambda-list-keywords)) (t (ecase state (required (push arg required)) (optional (push arg optional)) (key (push arg key)) (rest (setq rest arg)) (aux (push arg aux)))))) (values (nreverse required) (nreverse optional) rest (nreverse key) allow-other-keys aux))) ;;; ;;; points.lisp ;;; ;; fixed to make combined methods work on unspecialized generic ;; functions. (mt 890807) ;; Try the following before adding this patch: ;; (defmethod foo (x y z) t) ;; (defmethod foo :before (x y z) t) ;; (foo 1 2 3) ;blam! ;; (defun cross-columns (columns all-methods) (when (and (eq (first columns) t) (> (length all-methods) 1) (every #'(lambda (x) (eq x t)) (cdr columns))) (setq columns (cons (make-cpnode (make-point-entry *the-class-t* all-methods) ()) (cdr columns)))) (cross-columns-main t (car columns) (cdr columns) #+ignore all-methods #-ignore (copy-list all-methods))) ;; make subtype relationships work. ;; construct the predicate correctly so subtypep can get the right information. ;; - second pass - instead, we now hack subtypep correctly (?) ;; Be careful - the non-genera implementation for subtypep can easily ;; bring a presentation-style window system to thrash-in-place, so if ;; your system is subtypep-intensive, either do not install, or make ;; your SUBTYPEP function work something like below (genera version) (defun do-satisfies-deftype (name predicate) (let* ((specifier `(satisfies ,predicate)) (expand-fn ;; mthome@bbn - fast Genera implementation - see rel-7-2-patches also #+Genera #'(lambda (&rest ignore) (declare (ignore ignore)) specifier) ;; tmitchel@bbn - generic code for CommonLisp #-Genera #'(lambda (&rest ignore) (declare (ignore ignore)) `(and ,@(mapcar #'class-name (cdr (class-precedence-list (find-class name)))) ,specifier)))) ;; Specific ports can insert their own way of doing this. Many ;; ports may find the expand-fn defined above useful. ;; (or #+:Genera (setf (get name 'deftype) expand-fn) #+(and :Lucid (not :Prime)) (system::define-macro `(deftype ,name) expand-fn nil) #+ExCL (setf (get name 'excl::deftype-expander) expand-fn) #+:coral (setf (get name 'ccl::deftype-expander) expand-fn) ;; This is the default for ports for which we don't know any ;; better. Note that for most ports, providing this definition ;; should just speed up class definition. It shouldn't have an ;; effect on performance of most user code. (eval `(deftype ,name () '(satisfies ,predicate)))))) ;;; (rel-7-2-patches.lisp) #+genera cli:: (DEFUN SUBTYPEP (TYPE1 TYPE2 &AUX TYPE-NAME-1 TYPE-ARGS-1 TYPE-NAME-2 TYPE-ARGS-2 class1 class2) (COND ((OR (EQ TYPE1 'NIL) (EQ TYPE2 'T)) ;; NIL is a subtype of everything, everything is a subtype of T (VALUES T T)) ((OR (EQ TYPE1 'T) (EQ TYPE2 'NIL)) ;; T is a subtype of T and nothing else, nothing except NIL is a subtype of NIL (VALUES NIL T)) ((EQUAL TYPE1 TYPE2) (VALUES T T)) (t (cond ((and (fboundp 'pcl:find-class) (setq class1 (pcl:find-class type1 nil)) (setq class2 (pcl:find-class type2 nil))) (values (not (null (pcl:subclassp class1 class2))) t)) #+ignore ((or class1 class2) (values nil t)) ; should this be nil nil? (T (MULTIPLE-VALUE-SETQ (TYPE1 TYPE-NAME-1 TYPE-ARGS-1) (TYPE-EXPAND TYPE1 *SUBTYPEP-TERMINAL-TYPES*)) (MULTIPLE-VALUE-SETQ (TYPE2 TYPE-NAME-2 TYPE-ARGS-2) (TYPE-EXPAND TYPE2 *SUBTYPEP-TERMINAL-TYPES*)) (LET ((FUNCTION (OR (LOOKUP-SUBTYPEP-FUNCTION TYPE-NAME-1 TYPE-NAME-2) (LOOKUP-SUBTYPEP-FUNCTION TYPE-NAME-1 '*) (LOOKUP-SUBTYPEP-FUNCTION '* TYPE-NAME-2) (LOOKUP-SUBTYPEP-FUNCTION TYPE-NAME-1 'DEFAULT) (LOOKUP-SUBTYPEP-FUNCTION 'DEFAULT TYPE-NAME-2) (LOOKUP-SUBTYPEP-FUNCTION 'DEFAULT 'DEFAULT)))) (FUNCALL FUNCTION TYPE1 TYPE-NAME-1 TYPE-ARGS-1 TYPE2 TYPE-NAME-2 TYPE-ARGS-2))))))) ;;; ;;; Patch DCODE.LISP ;;; ;;;Fix the recursion bug in expand-dcode-cache. Replace the call to (setf ;;; generic-function-cache) with something that isn't really a generic function, ;;; because if that gf is invalid, we could recurse and get multiple stack frames ;;; trying to free the old cache. Maybe a lot of other inconsistencies have been ;;; arising this way as well. (defun expand-dcode-cache (generic-function old-cache old-size line-size nkeys next-scan-limit dcode-constructor) (let* ((new-size (* old-size 2)) (new-number-of-lines (floor new-size line-size)) (new-mask (make-wrapper-cache-mask new-number-of-lines)) (new-cache (get-generic-function-cache new-size)) (new-dcode nil) (wrappers ()) (value nil)) (flet ((%set-generic-function-cache (nv object) ;; Set the generic function cache avoiding another expansion. (let ((slot-name 'cache)) (bind-wrapper-and-static-slots--fsc object (setf-slot-value-using-class-1)))) (collect-wrappers (loc) (block collect-wrappers (when (%svref old-cache loc) (setq wrappers ()) (dotimes (i nkeys) (let ((wrapper (%svref old-cache (+ i loc)))) (if (zerop (wrapper-cache-no wrapper)) ;; This wrapper is obsolete, we don't have an instance ;; so there is no related trap. Just drop this line ;; on the floor. (return-from collect-wrappers nil) (push wrapper wrappers)))) (setq wrappers (nreverse wrappers) value (and (< nkeys line-size) (%svref old-cache (+ loc nkeys)))) t)))) (flush-generic-function-caches-internal new-cache) (do ((old-location line-size (+ old-location line-size))) ((= old-location old-size)) (when (collect-wrappers old-location) (apply #'dcode-cache-miss generic-function #'(lambda (&rest ignore) (declare (ignore ignore)) value) new-cache new-size new-mask line-size nkeys next-scan-limit nil ;Means don't allow another ;expand while filling the ;new cache. This can only ;happen in one pathological ;case, but prevent it anyways. dcode-constructor wrappers))) (setq new-dcode (funcall dcode-constructor generic-function new-cache)) (%set-generic-function-cache new-cache generic-function) (install-discriminating-function generic-function new-dcode) (free-generic-function-cache old-cache) new-cache))) ;;;In this patch we change the comparison from = to <, in order to avoid a cycle ;;; of cache growing, shrinking, growing, shrinking, .... Don't let the cache ;;; shrink. (defun ensure-generic-function-cache (generic-function size) (let ((existing (generic-function-cache generic-function))) (cond ((null existing) (setq existing (get-generic-function-cache size)) (setf (generic-function-cache generic-function) existing)) ((< (generic-function-cache-size existing) size) (free-generic-function-cache existing) (setq existing (get-generic-function-cache size)) (setf (generic-function-cache generic-function) existing))) existing)) Received: from Xerox.COM by arisia.xerox.com with SMTP (5.61+/IDA-1.2.8/gandalf) id AA19778; Mon, 7 Aug 89 21:26:45 -0700 Received: from Chardonnay.ms by ArpaGateway.ms ; 07 AUG 89 21:26:55 PDT Return-Path: <@CUNYVM.CUNY.EDU:CHEEWEEI@ITIVAX.BITNET> Redistributed: commonloops.pa Received: from CUNYVM.CUNY.EDU ([128.228.1.2]) by Xerox.COM ; 07 AUG 89 20:00:53 PDT Received: from ITIVAX.BITNET by CUNYVM.CUNY.EDU (IBM VM SMTP R1.2.1MX) with BSMTP id 9574; Mon, 07 Aug 89 23:02:36 EDT Date: Tue, 8 Aug 89 11:01 U From: Subject: no-applicable-method To: commonloops.pa@Xerox.COM X-Original-To: commonloops.pa@xerox.com, CHEEWEEI Message-Id: <890807-212655-3541@Xerox> I encountered a strange phenomenon when I was using and :around method for the no-applicable-method generic function. A sample of the code used is: (defmethod :around ((gen-func standard-generic-function) &rest args) (if (next-method-p) (call-next-method) ... else report some error)) The actual method does a bit more by calling some other gen funcs but the above code seems to be the cause of the problem. I tested out next-method-p and it returns true, implying that a next method exists and so it is invoked, however, this causes an infinite loop causing a stack overflow. A backtrace revealed that it was invoking itself and not the default primary method. Even if this method were to redefine the default method (though it shouldn't), next method-p should not return true then. I am using Victoria Day PCL. CW (reply to: CHEEWEEI%itivax.bitnet) Received: from Xerox.COM by arisia.xerox.com with SMTP (5.61+/IDA-1.2.8/gandalf) id AA18068; Mon, 7 Aug 89 19:01:03 -0700 Received: from Chardonnay.ms by ArpaGateway.ms ; 07 AUG 89 15:05:02 PDT Return-Path: Redistributed: commonloops.pa Received: from VAX.BBN.COM ([128.89.0.91]) by Xerox.COM ; 07 AUG 89 13:09:03 PDT To: gregor.pa@Xerox.COM Cc: commonloops.pa@Xerox.COM Subject: PCL patches (Victoria Day) Date: Mon, 07 Aug 89 15:59:06 -0400 From: Mike Thome Message-Id: <890807-150502-2475@Xerox> I've enclosed below a set of patches to fix a variety of different problems with Victoria Day PCL. Some of them are only for Genera, some are applicable to all... some might have been posted previously. Enjoy! -mike (mthome@bbn.com) ;;;-*-Mode:LISP; Package:(PCL LISP 1000); Base:10; Syntax:Common-lisp; Patch-File: Yes -*- ;;; ;;; methods.lisp ;;; ;; hacked by MT to use cerror (usefully) ; original by Rick Harris (defun check-lambda-list-congruency (generic-function method) (flet ((reset-gfn () (setf (generic-function-methods generic-function) nil))) (macrolet ((err (string &rest args) `(unless (cerror "Use this method instead (purge the old methods)" ,string ,@args) (reset-gfn)))) (let ((methods (generic-function-methods generic-function))) (when methods (multiple-value-bind (gf-required gf-optional gf-rest gf-key gf-allow-other-keys) (method-pretty-arglist (car methods)) (multiple-value-bind (required optional rest key allow-other-keys) (method-pretty-arglist method) (unless (= (length gf-required) (length required)) (err "~S has ~D required arguments,~ but existing methods have ~D required arguments" method (length required) (length gf-required))) (unless (= (length gf-optional) (length optional)) (err "~S has ~D optional arguments,~ but existing methods have ~D optional arguments" method (length optional) (length gf-optional))) (if (or gf-rest gf-key gf-allow-other-keys) (unless (or rest key allow-other-keys) (err "~S has neither &key nor &rest in its lambda-list,~ conflicting with existing methods" method)) (unless (not (or rest key allow-other-keys)) (err "~S has a &key or a &rest in its lambda-list,~ conflicting with existing methods" method)))))))))) ;; fix another potential infinite loop in dcode. ;; (defmethod install-discriminating-function ((generic-function standard-generic-function) function) (set-funcallable-instance-function generic-function function) #+ignore (setf (generic-function-discriminator-code generic-function) function) #-ignore (setf (slot-value generic-function 'discriminator-code) function)) ;;;Handle &AUX variables correctly (esp. for check-lambda-list-congruency) (defmethod method-pretty-arglist ((method standard-method)) (let ((required ()) (optional ()) (rest nil) (key ()) (aux ()) (allow-other-keys nil) (state 'required) (arglist (method-arglist method))) (dolist (arg arglist) (cond ((eq arg '&optional) (setq state 'optional)) ((eq arg '&rest) (setq state 'rest)) ((eq arg '&key) (setq state 'key)) ((eq arg '&allow-other-keys) (setq allow-other-keys 't)) ((eq arg '&aux) (setq state 'aux)) ((memq arg lambda-list-keywords)) (t (ecase state (required (push arg required)) (optional (push arg optional)) (key (push arg key)) (rest (setq rest arg)) (aux (push arg aux)))))) (values (nreverse required) (nreverse optional) rest (nreverse key) allow-other-keys aux))) ;;; ;;; points.lisp ;;; ;; fixed to make combined methods work on unspecialized generic ;; functions. (mt 890807) ;; Try the following before adding this patch: ;; (defmethod foo (x y z) t) ;; (defmethod foo :before (x y z) t) ;; (foo 1 2 3) ;blam! ;; (defun cross-columns (columns all-methods) (when (and (eq (first columns) t) (> (length all-methods) 1) (every #'(lambda (x) (eq x t)) (cdr columns))) (setq columns (cons (make-cpnode (make-point-entry *the-class-t* all-methods) ()) (cdr columns)))) (cross-columns-main t (car columns) (cdr columns) #+ignore all-methods #-ignore (copy-list all-methods))) ;; make subtype relationships work. ;; construct the predicate correctly so subtypep can get the right information. ;; - second pass - instead, we now hack subtypep correctly (?) ;; Be careful - the non-genera implementation for subtypep can easily ;; bring a presentation-style window system to thrash-in-place, so if ;; your system is subtypep-intensive, either do not install, or make ;; your SUBTYPEP function work something like below (genera version) (defun do-satisfies-deftype (name predicate) (let* ((specifier `(satisfies ,predicate)) (expand-fn ;; mthome@bbn - fast Genera implementation - see rel-7-2-patches also #+Genera #'(lambda (&rest ignore) (declare (ignore ignore)) specifier) ;; tmitchel@bbn - generic code for CommonLisp #-Genera #'(lambda (&rest ignore) (declare (ignore ignore)) `(and ,@(mapcar #'class-name (cdr (class-precedence-list (find-class name)))) ,specifier)))) ;; Specific ports can insert their own way of doing this. Many ;; ports may find the expand-fn defined above useful. ;; (or #+:Genera (setf (get name 'deftype) expand-fn) #+(and :Lucid (not :Prime)) (system::define-macro `(deftype ,name) expand-fn nil) #+ExCL (setf (get name 'excl::deftype-expander) expand-fn) #+:coral (setf (get name 'ccl::deftype-expander) expand-fn) ;; This is the default for ports for which we don't know any ;; better. Note that for most ports, providing this definition ;; should just speed up class definition. It shouldn't have an ;; effect on performance of most user code. (eval `(deftype ,name () '(satisfies ,predicate)))))) ;;; (rel-7-2-patches.lisp) #+genera cli:: (DEFUN SUBTYPEP (TYPE1 TYPE2 &AUX TYPE-NAME-1 TYPE-ARGS-1 TYPE-NAME-2 TYPE-ARGS-2 class1 class2) (COND ((OR (EQ TYPE1 'NIL) (EQ TYPE2 'T)) ;; NIL is a subtype of everything, everything is a subtype of T (VALUES T T)) ((OR (EQ TYPE1 'T) (EQ TYPE2 'NIL)) ;; T is a subtype of T and nothing else, nothing except NIL is a subtype of NIL (VALUES NIL T)) ((EQUAL TYPE1 TYPE2) (VALUES T T)) (t (cond ((and (fboundp 'pcl:find-class) (setq class1 (pcl:find-class type1 nil)) (setq class2 (pcl:find-class type2 nil))) (values (not (null (pcl:subclassp class1 class2))) t)) #+ignore ((or class1 class2) (values nil t)) ; should this be nil nil? (T (MULTIPLE-VALUE-SETQ (TYPE1 TYPE-NAME-1 TYPE-ARGS-1) (TYPE-EXPAND TYPE1 *SUBTYPEP-TERMINAL-TYPES*)) (MULTIPLE-VALUE-SETQ (TYPE2 TYPE-NAME-2 TYPE-ARGS-2) (TYPE-EXPAND TYPE2 *SUBTYPEP-TERMINAL-TYPES*)) (LET ((FUNCTION (OR (LOOKUP-SUBTYPEP-FUNCTION TYPE-NAME-1 TYPE-NAME-2) (LOOKUP-SUBTYPEP-FUNCTION TYPE-NAME-1 '*) (LOOKUP-SUBTYPEP-FUNCTION '* TYPE-NAME-2) (LOOKUP-SUBTYPEP-FUNCTION TYPE-NAME-1 'DEFAULT) (LOOKUP-SUBTYPEP-FUNCTION 'DEFAULT TYPE-NAME-2) (LOOKUP-SUBTYPEP-FUNCTION 'DEFAULT 'DEFAULT)))) (FUNCALL FUNCTION TYPE1 TYPE-NAME-1 TYPE-ARGS-1 TYPE2 TYPE-NAME-2 TYPE-ARGS-2))))))) ;;; ;;; Patch DCODE.LISP ;;; ;;;Fix the recursion bug in expand-dcode-cache. Replace the call to (setf ;;; generic-function-cache) with something that isn't really a generic function, ;;; because if that gf is invalid, we could recurse and get multiple stack frames ;;; trying to free the old cache. Maybe a lot of other inconsistencies have been ;;; arising this way as well. (defun expand-dcode-cache (generic-function old-cache old-size line-size nkeys next-scan-limit dcode-constructor) (let* ((new-size (* old-size 2)) (new-number-of-lines (floor new-size line-size)) (new-mask (make-wrapper-cache-mask new-number-of-lines)) (new-cache (get-generic-function-cache new-size)) (new-dcode nil) (wrappers ()) (value nil)) (flet ((%set-generic-function-cache (nv object) ;; Set the generic function cache avoiding another expansion. (let ((slot-name 'cache)) (bind-wrapper-and-static-slots--fsc object (setf-slot-value-using-class-1)))) (collect-wrappers (loc) (block collect-wrappers (when (%svref old-cache loc) (setq wrappers ()) (dotimes (i nkeys) (let ((wrapper (%svref old-cache (+ i loc)))) (if (zerop (wrapper-cache-no wrapper)) ;; This wrapper is obsolete, we don't have an instance ;; so there is no related trap. Just drop this line ;; on the floor. (return-from collect-wrappers nil) (push wrapper wrappers)))) (setq wrappers (nreverse wrappers) value (and (< nkeys line-size) (%svref old-cache (+ loc nkeys)))) t)))) (flush-generic-function-caches-internal new-cache) (do ((old-location line-size (+ old-location line-size))) ((= old-location old-size)) (when (collect-wrappers old-location) (apply #'dcode-cache-miss generic-function #'(lambda (&rest ignore) (declare (ignore ignore)) value) new-cache new-size new-mask line-size nkeys next-scan-limit nil ;Means don't allow another ;expand while filling the ;new cache. This can only ;happen in one pathological ;case, but prevent it anyways. dcode-constructor wrappers))) (setq new-dcode (funcall dcode-constructor generic-function new-cache)) (%set-generic-function-cache new-cache generic-function) (install-discriminating-function generic-function new-dcode) (free-generic-function-cache old-cache) new-cache))) ;;;In this patch we change the comparison from = to <, in order to avoid a cycle ;;; of cache growing, shrinking, growing, shrinking, .... Don't let the cache ;;; shrink. (defun ensure-generic-function-cache (generic-function size) (let ((existing (generic-function-cache generic-function))) (cond ((null existing) (setq existing (get-generic-function-cache size)) (setf (generic-function-cache generic-function) existing)) ((< (generic-function-cache-size existing) size) (free-generic-function-cache existing) (setq existing (get-generic-function-cache size)) (setf (generic-function-cache generic-function) existing))) existing)) Received: from Xerox.COM by arisia.xerox.com with SMTP (5.61+/IDA-1.2.8/gandalf) id AA03610; Tue, 8 Aug 89 10:50:32 -0700 Received: from Semillon.ms by ArpaGateway.ms ; 08 AUG 89 10:39:50 PDT Date: Tue, 8 Aug 89 10:34 PDT From: Gregor.pa@Xerox.COM Subject: Re: no-applicable-method To: CHEEWEEI%ITIVAX.BITNET@CUNYVM.CUNY.EDU Cc: commonloops.pa@Xerox.COM Fcc: BD:>Gregor>mail>outgoing-mail-7.text.newest In-Reply-To: The message of 7 Aug 89 20:01 PDT from CHEEWEEI%ITIVAX.BITNET@CUNYVM.CUNY.EDU Message-Id: <19890808173401.0.GREGOR@SPIFF.parc.xerox.com> Line-Fold: no Date: Tue, 8 Aug 89 11:01 U From: I encountered a strange phenomenon when I was using and :around method for the no-applicable-method generic function. A sample of the code used is: (defmethod no-applicable-method :around ((gen-func standard-generic-function) &rest args) (if (next-method-p) (call-next-method) ... else report some error)) This is an illegal method definition. This is because it is a method on a specified generic function that is specialized to only specified classe. That is, the generic function no-applicable-method is specified in CLOS and the class standard-generic-function is specified in CLOS. There are at least two ways to see why this definition has to be illegal. The easiest is to observe that in some sense, this should be considered a redefinition of a reserved name. This definition is exactly analogous to redefining an existing Lisp function like, lets say, CAR. If were to redefine such a function, at least theoretically, all programs including the system implemenation itself see the change. This can reek havoc if you do something wrong. Another way to see the problem with this definition is based on looking at the problems of implementing a causally effective metacircular system like CLOS. In such a system, this kind of redefinition can have more dramatic effect even if you think your method is, itself, not buggy. The prinicple outlined above permits the implementation to assume (and mine does), that it `knows' about all the specified methods. This is the easiest technique for ensuring that the metacircularity grounds out properly. When an unknown method leaks into the specified level of the system, as in your method above, all hell can break lose. This second is the problem you are running into and, in fact, is the same problem as has been cropping up with cache expansion. ------- Received: from [13.0.12.232] by arisia.xerox.com with SMTP (5.61+/IDA-1.2.8/gandalf) id AA06022; Tue, 8 Aug 89 13:05:08 -0700 Received: from Chardonnay.ms by ArpaGateway.ms ; 08 AUG 89 13:03:16 PDT Return-Path: Redistributed: commonloops.pa Received: from nora.parc.xerox.com ([13.2.16.230]) by Xerox.COM ; 08 AUG 89 12:58:27 PDT Received: by nora.parc.xerox.com (5.61+/IDA-1.2.8/gandalf) id AA02305; Tue, 8 Aug 89 12:58:20 PDT Message-Id: <8908081958.AA02305@nora.parc.xerox.com> Date: Tue, 8 Aug 89 12:58:20 PDT To: Gregor.pa@Xerox.COM Cc: CHEEWEEI%ITIVAX.BITNET@CUNYVM.CUNY.EDU, commonloops.pa@Xerox.COM In-Reply-To: Gregor.pa@Xerox.COM's message of Tue, 8 Aug 89 10:34 PDT <19890808173401.0.GREGOR@SPIFF.parc.xerox.com> Subject: no-applicable-method From: Stanley's Tool Works Sender: lanning@arisia.xerox.com Line-Fold: No "...the problems of implementing a causally effective metacircular system like CLOS" Gee, you really are working with Brian, aren't you? --- smL Received: from Xerox.COM by arisia.xerox.com with SMTP (5.61+/IDA-1.2.8/gandalf) id AA09265; Tue, 8 Aug 89 16:09:48 -0700 Received: from Salvador.ms by ArpaGateway.ms ; 08 AUG 89 16:00:08 PDT Return-Path: Redistributed: commonloops.pa Received: from eden.Berkeley.EDU ([128.32.149.9]) by Xerox.COM ; 08 AUG 89 15:55:08 PDT Received: by eden.Berkeley.EDU (5.61/1.29) id AA00198; Tue, 8 Aug 89 15:55:23 -0700 Date: Tue, 8 Aug 89 15:55:23 -0700 From: konstan@postgres.Berkeley.EDU (Joe Konstan) Message-Id: <8908082255.AA00198@eden.Berkeley.EDU> To: commonloops.pa@Xerox.COM Subject: Method and Generic Function internal names It seems that pcl generates names for methods and setf generic functions by creating a symbol which includes a fully qualified name for the slot or method name. As a result, I have had occasions where a reference to a method was made at a time when that name was not yet exported, but the method defninition occurred using the exported name. In these cases (which can usually be fixed by recompling the correct files) the method (so far, always a setf method) call fails, since the generic function is undefined. For instance: (apropos 'cursor (find-package 'pcl)) PCL::|(METHOD (SETF XCLOS::CURSOR-MODE) (T XCLOS::TEXT-BUFFER-GADGET))| PCL::|(METHOD (SETF XCLOS:CURSOR) (T XCLOS::X-WINDOW))| PCL::|(SETF XCLOS:CURSOR)| PCL::|(SETF XCLOS::CURSOR-MODE)| PCL::|(SETF XCLOS::CURSOR-MOVED)| PCL::|SETF XCLOS:CURSOR| (defined) PCL::|SETF XCLOS::CURSOR| PCL::|SETF XCLOS::CURSOR-MOVED| (defined) PCL::|SETF XCLOS::CURSOR-MODE| (defined) PCL::|(METHOD NEW-INSTANCE (XCLOS::CURSOR))| PCL::|(METHOD XCLOS::HIDE-CURSOR (XCLOS:CHAR-WINDOW))| PCL::|(METHOD XCLOS::DRAW-CURSOR (XCLOS:CHAR-WINDOW))| PCL::|(METHOD XCLOS::DO-DETACH (XCLOS::CURSOR))| Note that the generic function for (setf cursor) is: PCL::|SETF XCLOS:CURSOR| (defined) but the reference which some of the code makes is: PCL::|SETF XCLOS::CURSOR| This is all in the 12/88 (no cute name) PCL. Questions: Is there an easy way to prevent this (other than enforced load orders or enforced export times? Has this changed in later PCL versions? Is it likely that PCL will eventually name methods and generic functions with names which are transparent across import/export? Joe Konstan Picasso Project UC Berkeley Received: from Xerox.COM by arisia.xerox.com with SMTP (5.61+/IDA-1.2.8/gandalf) id AA03844; Wed, 9 Aug 89 13:18:02 -0700 Received: from Semillon.ms by ArpaGateway.ms ; 09 AUG 89 12:33:26 PDT Return-Path: Redistributed: commonloops.pa Received: from uunet.uu.net ([192.48.96.2]) by Xerox.COM ; 09 AUG 89 12:25:12 PDT Received: by uunet.uu.net (5.61/1.14) with UUCP id AA06916; Wed, 9 Aug 89 15:24:35 -0400 Received: by franz.Franz.COM (MC 2.0/FI-1.0) id AA03445; Wed, 9 Aug 89 11:50:52 PDT Received: by feast (5.5/3.14) id AA00346; Wed, 9 Aug 89 14:01:33 EDT Date: Wed, 9 Aug 89 14:01:33 EDT From: smh@franz.com (Steven M. Haflich) Message-Id: <8908091801.AA00346@feast> To: konstan%postgres.Berkeley.EDU@franz.com Cc: commonloops.pa%Xerox.COM@franz.com In-Reply-To: Joe Konstan's message of Tue, 8 Aug 89 15:55:23 -0700 <8908082255.AA00198@eden.Berkeley.EDU> Subject: Method and Generic Function internal names From: franz!postgres.Berkeley.EDU!konstan (Joe Konstan) It seems that pcl generates names for methods and setf generic functions by creating a symbol which includes a fully qualified name for the slot or method name. As a result, I have had occasions where a reference to a method was made at a time when that name was not yet exported, but the method defninition occurred using the exported name. Has this changed in later PCL versions? Is it likely that PCL will eventually name methods and generic functions with names which are transparent across import/export? I don't have the 12/88 PCL handy to check, but the current (Victoria Day) PCL seems to be exposed to the same problem. Here's the relevant code from pcl/defs.lisp: (defun get-setf-function-name (name) (or (gethash name *setf-function-names*) (setf (gethash name *setf-function-names*) (intern (let ((*package* *the-pcl-package*) (*print-case* :upcase) (*print-gensym* 't)) (format nil "~A ~S" 'setf name)) *the-pcl-package*)))) Perhaps the INTERN could have been written this way, which is intended to be equivalent except that it always prints package qualifiers with two colons. (It's untested.) (intern (let* ((pack (symbol-package name)) (*package* (or pack *the-pcl-package*)) (*print-case* :upcase) (*print-gensym* 't)) (format nil "~A ~:[~*~;~A::~]~S" 'setf pack (and pack (package-name pack)) name)) *the-pcl-package*) This removes the dependency on externalness of the symbol. (But it depends on the package name not requiring escape chars, and you'll also lose if you change the home package of NAME, but get real...) The location and details of this code may have changed since 12/88, but you may be able to make analogous changes. You might have to recompile all of pcl after making the change... How names like this should be generated is something of a religious issue. We will be using function specs in Franz's version of CLOS to avoid problems like this, but there is of course something to be said for or against each style. Received: from Xerox.COM by arisia.xerox.com with SMTP (5.61+/IDA-1.2.8/gandalf) id AA02193; Wed, 9 Aug 89 17:13:04 -0700 Received: from Catawba.ms by ArpaGateway.ms ; 09 AUG 89 16:43:03 PDT Return-Path: Redistributed: commonloops.pa Received: from uunet.uu.net ([192.48.96.2]) by Xerox.COM ; 09 AUG 89 16:41:13 PDT Received: by uunet.uu.net (5.61/1.14) with UUCP id AA18378; Wed, 9 Aug 89 19:40:10 -0400 Received: by opal.STC.LOCKHEED.COM (3.2/1.49); Wed, 9 Aug 89 18:29:28 CDT From: Received: by bluejay.STC.LOCKHEED.COM (3.2/1.5); Wed, 9 Aug 89 18:32:33 CDT Date: Wed, 9 Aug 89 18:32:33 CDT Message-Id: <8908092332.AA21267@bluejay.STC.LOCKHEED.COM> Received: by DnaMail (v1.1)(dnamaild.c 1.13); Wed Aug 9 18:32:09 1989 CDT X-Vms-To: HAWK::EAGLE::"commonloops.pa@xerox.com", HAWK::EAGLE::"clue-review@dsg.csc.ti.com", SANTIAGO Subject: problems with CLUE6.0 and PCL To: commonloops.pa@Xerox.COM I would like to know if anyone has been able to compile PCL ( Victoria Day, or whatever the PCL that was on arisia on Monday is called ) under IBCL and has also been able to compile CLUE 6.0. I am having problems compiling CLUE 6.0 under these conditions. I keep on getting a recursive invocation of PCL::PROPAGATE-CLASS-UPDATE when attempting to compile the intrinsics.lsp file of CLUE 6.0. When the compiler reaches (defcontact basic-contact ...) in the intrinsics.lsp file it leads to a stack overflow and a core dump. I have also loaded CLX and the files preceding intrinsics.lsp from CLUE 6.0 interpretively, but get the same results. Any help or direction is appreciated. Ramon Santiago santiago@mvii.decnet.lockheed.com Received: from Xerox.COM by arisia.xerox.com with SMTP (5.61+/IDA-1.2.8/gandalf) id AA06984; Wed, 9 Aug 89 19:43:53 -0700 Received: from Salvador.ms by ArpaGateway.ms ; 09 AUG 89 19:44:31 PDT Return-Path: <@CUNYVM.CUNY.EDU:CHEEWEEI@ITIVAX.BITNET> Redistributed: commonloops.pa Received: from CUNYVM.CUNY.EDU ([128.228.1.2]) by Xerox.COM ; 09 AUG 89 19:40:44 PDT Received: from ITIVAX.BITNET by CUNYVM.CUNY.EDU (IBM VM SMTP R1.2.1MX) with BSMTP id 7160; Wed, 09 Aug 89 22:42:26 EDT Date: Thu, 10 Aug 89 10:41 U From: Subject: no-applicable-method To: commonloops.pa@Xerox.COM X-Original-To: commonloops.pa@xerox.com, CHEEWEEI Message-Id: <890809-194431-5836@Xerox> If defining a method for the gen func NO-APPLICABLE-METHOD, specialised on STANDARD-GENERIC-FUNCTION is illegal, I assume that specialising on the class T is illegal too then since T is specified in CLOS. So, when the specification says methods may be written for it, does that imply that only methods specialised on a user defined metaclass for gf objects may be written? I am referring to methods for no-applicable-method. I presume too that the reason why a method for no-applicable-method specialised on the class T never redefines the default method is due to the fact that the system knows the specified methods and does not allow it. Same goes for :around, :before and :after methods. Any suggestions as to how the behaviour when a gf with no applicable method is invoked, may be customized in a portable fashion? CW CHEEWEEI%itivax.bitnet Received: from Xerox.COM by arisia.xerox.com with SMTP (5.61+/IDA-1.2.8/gandalf) id AA07178; Wed, 9 Aug 89 20:12:56 -0700 Received: from Semillon.ms by ArpaGateway.ms ; 09 AUG 89 20:13:41 PDT Date: Wed, 9 Aug 89 20:12 PDT From: Gregor.pa@Xerox.COM Subject: Re: no-applicable-method To: CHEEWEEI%ITIVAX.BITNET@CUNYVM.CUNY.EDU Cc: commonloops.pa@Xerox.COM Fcc: BD:>Gregor>mail>outgoing-mail-7.text.newest In-Reply-To: The message of 9 Aug 89 19:41 PDT from CHEEWEEI%ITIVAX.BITNET@CUNYVM.CUNY.EDU Message-Id: <19890810031203.9.GREGOR@SPIFF.parc.xerox.com> Line-Fold: no Date: Thu, 10 Aug 89 10:41 U From: If defining a method for the gen func NO-APPLICABLE-METHOD, specialised on STANDARD-GENERIC-FUNCTION is illegal, I assume that specialising on the class T is illegal too then since T is specified in CLOS. Yes, the following excerpt from the current draft version of chapter 3 (which, unfortunately, still isn't available) may be helpful to you. These principles govern inheritance relationships among CLOS classes, and the corresponding method applicability relationships of methods specialized to those classes. Other principles which govern the calling relationships among generic functions are defined in the ``Protocols'' section. These principles are based on a division of classes, methods and generic functions into three categories. Classes, methods and generic functions defined by this specification are called {\bit specified classes}, {\bit specified methods} and {\bit specified generic-functions}. Classes, methods and generic functions which are defined by a particular implementation of CLOS are called {\bit implementation-specific classes}, {\bit implementation-specific methods} and {\bit implementation-specific generic-functions}. Classes, methods and generic functions which are defined by portable programs are called {\bit portable classes}, {\bit portable methods} and {\bit portable generic-functions}. \item{4} Implementations are not free to override a specified method with an unspecified method if that will affect the specified method's applicability to any specified class. \item{5} Implementations are free to define unspecified {\bf :before} and {\bf :after} methods on specified generic functions. \item{6} Portable programs are not free to redefine any specified methods or classes. Portable programs are not free to define methods on specified generic functions which are specialized to specified classes. So, when the specification says methods may be written for it, does that imply that only methods specialised on a user defined metaclass for gf objects may be written? Yes, if the generic function is a specified one, you can write methods on user defined metaobject classes only. So, you could say: (defclass my-generic-function (standard-generic-function) () (:metaclass funcallable-standard-class)) (defmethod no-applicable-method ((gf my-generic-function) args) ...) Then, using defgeneric, you can make a generic function like FOO be an instance of my-generic-function rather than standard-generic-function. In the PCL you are using, you may need to say the following instead: (eval-when (compile load eval) (ensure-generic-function 'foo :generic-function-class my-generic-function)) Or, at the very worst: (eval-when (compile load eval) (unless (fboundp 'foo) (setf (symbol-function 'foo) (make-instance 'my-generic-function)))) ------- Received: from [13.0.12.232] by arisia.xerox.com with SMTP (5.61+/IDA-1.2.8/gandalf) id AA10315; Wed, 9 Aug 89 23:51:57 -0700 Received: from Chardonnay.ms by ArpaGateway.ms ; 09 AUG 89 23:52:33 PDT Return-Path: <@CUNYVM.CUNY.EDU:CHEEWEEI@ITIVAX.BITNET> Redistributed: commonloops.pa Received: from CUNYVM.CUNY.EDU ([128.228.1.2]) by Xerox.COM ; 09 AUG 89 23:49:07 PDT Received: from ITIVAX.BITNET by CUNYVM.CUNY.EDU (IBM VM SMTP R1.2.1MX) with BSMTP id 7989; Thu, 10 Aug 89 02:50:49 EDT Date: Thu, 10 Aug 89 14:49 U From: Subject: metaclasses To: commonloops.pa@Xerox.COM X-Original-To: commonloops.pa@xerox.com, CHEEWEEI Message-Id: <890809-235233-6074@Xerox> In defining a metaclass eg. (defclass my-standard-class (standard-class) ()) I also have to define: (defmethod check-super-metaclass-compatibility ((x my-standard-class) (y t)) 't) Is this something that must be done now as well as in future for user defined metaclasses? Is the decision when classes and methods are compiled totally left up to the CLOS implementation? Is there a similar function like compile-flavor-methods in Flavors that ensures it? C CHEEWEEI%itivax.bitnet Received: from [13.0.12.232] by arisia.xerox.com with SMTP (5.61+/IDA-1.2.8/gandalf) id AA10315; Wed, 9 Aug 89 23:51:57 -0700 Received: from Chardonnay.ms by ArpaGateway.ms ; 09 AUG 89 23:52:33 PDT Return-Path: <@CUNYVM.CUNY.EDU:CHEEWEEI@ITIVAX.BITNET> Redistributed: commonloops.pa Received: from CUNYVM.CUNY.EDU ([128.228.1.2]) by Xerox.COM ; 09 AUG 89 23:49:07 PDT Received: from ITIVAX.BITNET by CUNYVM.CUNY.EDU (IBM VM SMTP R1.2.1MX) with BSMTP id 7989; Thu, 10 Aug 89 02:50:49 EDT Date: Thu, 10 Aug 89 14:49 U From: Subject: metaclasses To: commonloops.pa@Xerox.COM X-Original-To: commonloops.pa@xerox.com, CHEEWEEI Message-Id: <890809-235233-6074@Xerox> In defining a metaclass eg. (defclass my-standard-class (standard-class) ()) I also have to define: (defmethod check-super-metaclass-compatibility ((x my-standard-class) (y t)) 't) Is this something that must be done now as well as in future for user defined metaclasses? Is the decision when classes and methods are compiled totally left up to the CLOS implementation? Is there a similar function like compile-flavor-methods in Flavors that ensures it? C CHEEWEEI%itivax.bitnet Received: from Xerox.COM by arisia.xerox.com with SMTP (5.61+/IDA-1.2.8/gandalf) id AA23718; Thu, 10 Aug 89 12:31:44 -0700 Received: from Chardonnay.ms by ArpaGateway.ms ; 10 AUG 89 10:17:45 PDT Return-Path: Redistributed: commonloops.pa Received: from DINO.BBN.COM ([128.89.3.8]) by Xerox.COM ; 10 AUG 89 10:13:14 PDT To: Gregor.pa@Xerox.COM Cc: CHEEWEEI%ITIVAX.BITNET@cunyvm.cuny.edu, commonloops.pa@Xerox.COM Subject: Re: no-applicable-method In-Reply-To: Your message of Wed, 09 Aug 89 20:12:00 -0700. <19890810031203.9.GREGOR@SPIFF.parc.xerox.com> Date: Thu, 10 Aug 89 13:25:38 -0400 From: kanderso@DINO.BBN.COM Message-Id: <890810-101745-6983@Xerox> Some small items on NO-APPLICALBLE-METHOD: 1. The example that cheeweei has trouble with works fine in my system. At least, the example below works. 2. The problem that i have with NO-APPLICABLE-METHOD is that i'd really like to specialize it on more than the first argument. For example, say i define a class that uses NO-APPLICABLE-METHOD to do a kind of simple delegation: (defmethod no-applicable-method ((gf standard-generic-function) &rest args) ;; Try delegation. (let ((method (apply #'find-delegated-method gf args))) (if method (apply method args) (call-next-method)))) I don't need to change the behavior of STANDARD-GF, i just want to do something different if one or more of the arguments can delegate. Unfortuantely, i can't specialize on any of the args so i must do it with FIND-DELEGATED-METHOD. 3. If i'm forced by Gregor not to change STANDARD-GENERIC-FUNCTION, i must define my own and make every gf use it. This is a lot more work than simply adding one new method. k Received: from Xerox.COM by arisia.xerox.com with SMTP (5.61+/IDA-1.2.8/gandalf) id AA23767; Thu, 10 Aug 89 12:34:45 -0700 Received: from Salvador.ms by ArpaGateway.ms ; 10 AUG 89 10:02:22 PDT Return-Path: Redistributed: commonloops.pa Received: from VAX.BBN.COM ([128.89.0.91]) by Xerox.COM ; 10 AUG 89 09:58:41 PDT Received: by VAX.BBN.COM id aa08332; 10 Aug 89 12:48 EDT To: gregor.pa@Xerox.COM Cc: commonloops.pa@Xerox.COM Subject: More patches Date: Thu, 10 Aug 89 12:38:28 -0400 From: Mike Thome Message-Id: <890810-100222-6941@Xerox> Included below are three more sets of patches. The first is a correction to the update-method-inheritance patch I sent out a while ago, the second adds a useful error message to appear when someone tries to instantiate an incomplete class, and the third hacks the initialization protocol for a little better efficiency. All three are applicable to any PCL port, though the third patch probably will win by less on non-symbolics (though many ports ought to be able to do similar tricks). On my machine, Patch 1 speeds up defclass time of a new class by a factor of 5, conses only abut 3% as much, and invalidates no gfns unless needed. Patch 3 speeds up "(make-instance 'standard-class)" by about 60%. enjoy! -mik (mthome@bbn.com) ;;; -*- Package: PCL -*- ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ;;; ;;; patch.1 ;;; This is to fix an insidious little bug with the umi patch I sent out ;;; a while back. The only actual change from the last set is in ;;; PROPAGATE-CLASS-UPDATE (near the end), but I've included the utility ;;; routine and the patched UPDATE-METHOD-INHERITANCE for completeness. ;;; The case that the original patched failed on was: ;;; (defclass a () ()) ;;; (defclass b () ()) ;;; (defmethod foo ((x object)) x) ;;; (defmethod foo :after ((x b)) (print 'bleah)) ;;; (defclass c (a) ()) ;;; (foo (make-instance 'c)) --> # ;;; (defclass a (b) ()) ; didn't invalidate foo - does now ;;; (foo (make-instance 'c)) ;;; used to produce --> # ;;; now produces --> BLEAH # ;;; ;;; ;;; Patch std-class.lisp ;;; (defmethod PROPAGATE-CLASS-UPDATE ((class standard-class) new-fully-defined-p old-fully-defined-p changed-class &rest key-arguments ;hidden argument &key (its-direct-superclasses () supers-p) (its-options () options-p) (its-direct-slots () slots-p)) (declare (ignore its-direct-superclasses its-options its-direct-slots)) (let ((old-cpl (class-precedence-list class)) (new-cpl ())) (when new-fully-defined-p (cond (supers-p (setq new-cpl (compute-class-precedence-list class)) (setf (class-precedence-list class) new-cpl) (clear-precedence-dag-cache) (update-slots--class class) (update-constructors class)) ((or options-p slots-p) (update-slots--class class) (update-constructors class)))) ;; Propagate all the change information down through our subclasses. ;; For each subclass we also compute its new and old fully-defined-p ;; status. The details of this computation are specific to PCL. (dolist (subclass (class-direct-subclasses class)) (let ((sub-forward-referenced-supers (class-forward-referenced-supers subclass)) sub-newly-defined-p sub-oldly-defined-p) (cond ((null sub-forward-referenced-supers) ;; The subclass used to be fully defined. By definition, ;; that means that we used to be fully defined. It also ;; means that if we just became not-fully-defined this ;; subclass must now become not fully defined. (setq sub-newly-defined-p new-fully-defined-p sub-oldly-defined-p 't) (when (not new-fully-defined-p) (setf (class-forward-referenced-supers subclass) (list class)))) ((and (eq (car sub-forward-referenced-supers) class) (null (cdr sub-forward-referenced-supers))) ;; The only reason this subclass used to be not fully defined ;; is because we used to be not fully defined. That means ;; that if we are still not fully defined so is this subclass ;; and if we just became fully defined so does this subclass. (setq sub-newly-defined-p new-fully-defined-p sub-oldly-defined-p old-fully-defined-p) (when new-fully-defined-p (setf (class-forward-referenced-supers subclass) ()))) (t ;; The general case is where there were multiple reasons ;; why this subclass used to be not-fully-defined. That ;; means it stays not fully defined, but we may add or ;; remove ourselves as a reason. (setq sub-newly-defined-p nil sub-oldly-defined-p nil) (setf (class-forward-referenced-supers subclass) (if new-fully-defined-p (delete class sub-forward-referenced-supers) (pushnew class sub-forward-referenced-supers))))) (apply #'propagate-class-update subclass sub-newly-defined-p sub-oldly-defined-p changed-class key-arguments))) (when new-fully-defined-p (cond (supers-p ;; always do umi now, since (1) it is so much faster and (2) ;; it is needed. ;;(when (eq class changed-class) (update-method-inheritance class old-cpl (class-precedence-list class)) ;;) )) (setf (class-all-default-initargs class) (collect-all-default-initargs class new-cpl))) )) (defun class-wrapper-in-gfn-cache (wrapper gfn) (let ((cache (generic-function-cache gfn))) (and cache (find wrapper cache :test #'eq :start 1)))) (defmethod update-method-inheritance ((class standard-class) old-cpl new-cpl) (let ((wrapper (class-wrapper class))) (flet ((reset-gfs (c) (dolist (m (class-direct-methods c)) (let ((gf (method-generic-function m))) (when (and (not (memq gf *umi-gfs*)) (class-wrapper-in-gfn-cache wrapper gf)) (invalidate-generic-function gf) (push gf *umi-gfs*))))) (reset-some-gfs (c1 c2) (let ((gfs1 ())) (dolist (m (class-direct-methods c1)) (pushnew (method-generic-function m) gfs1)) (dolist (m (class-direct-methods c2)) (let ((gf (method-generic-function m))) (when (and (memq gf gfs1) (not (memq gf *umi-gfs*)) (class-wrapper-in-gfn-cache wrapper gf)) (invalidate-generic-function gf) (push gf *umi-gfs*))))))) (multiple-value-bind (appear disappear reorder) (reordered-classes old-cpl new-cpl) (dolist (a appear) (unless (memq a *umi-complete-classes*) (reset-gfs a) (push a *umi-complete-classes*))) (dolist (d disappear) (unless (memq d *umi-complete-classes*) (reset-gfs d) (push d *umi-complete-classes*))) (dolist (r reorder) (dolist (c1 r) (dolist (c2 (memq c1 r)) (let ((temp nil)) (cond ((setq temp (assq c1 *umi-reorder*)) (unless (memq c2 temp) (reset-some-gfs c1 c2) (push c2 (cdr temp)))) ((setq temp (assq c2 *umi-reorder*)) (unless (memq c1 temp) (reset-some-gfs c1 c2) (push c1 (cdr temp)))) (t (push (list c1 c2) *umi-reorder*))))))))))) ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ;;; ;;; PATCH SLOTS.LISP ;;; ok #|| ;; This fixes the following bug: (defclass incomplete-class1 (very-incomplete-class1) ()) (make-instance 'incomplete-class1) ;D,#TD1PsT[Begin using 006 escapes](1 0 (NIL 0) (:FIX :ROMAN :NORMAL) "CPTFONT")Trap: The first argument given to the ZL:AR-1 instruction, NIL, was not an array. (2 0 (NIL 0) (NIL NIL NIL) "CPTFONT"); ; 1GET-CLASS-1 2; Arg 0 (CLASSES): # ; Arg 1 (I): 0 ; Arg 2 (A): # ; GET-CLASS-1  GET-CPL-1  LOOKUP-METHOD-INTERNAL  ;  (METHOD COMPUTE-APPLICABLE-METHODS-1 (STANDARD-GENERIC-FUNCTION T)) ;  (METHOD MAKE-INSTANCE (STANDARD-CLASS))  (METHOD MAKE-INSTANCE (SYMBOL)) ; The make-instance would allocate a wrapperless instance as the prototype ; of INCOMPLETE-CLASS, and would die in lookup-method-internal. ||# (defmethod allocate-instance ((class standard-class) &rest initargs) (declare (ignore initargs)) (if (class-forward-referenced-supers class) (error "You can't allocate an instance of the incompletely defined class ~A" class) (let* ((class-wrapper (class-wrapper class)) (instance (%allocate-instance--class (class-no-of-instance-slots class)))) (setf (iwmc-class-class-wrapper instance) class-wrapper) instance))) ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ;;; ;;; PATCH INIT.LISP ;;; ;;; The initializing protocol does a lot of needless consing, and goes to ;;; the method well too often. This version reduces consing, and doesn't ;;; go to the well when there are no initargs. This makes (MAKE-INSTANCE ;;; 'STANDARD-CLASS) over 60% faster (on symbolics) ;;; The CHECK-INITARGS-1 stuff should be cached. Perhaps ;;; COMPUTE-APPLICABLE-METHODS should take args as &rest args. Perhaps ;;; COMPUTE-APPLICABLE-METHODS should use the Method cache. ;;; This should be in low.lisp without the following #+s... #-symbolics (defmacro with-stack-list ((var &rest elements) &body body) `(funcall #'(lambda (&rest ,var) ,@body) ,@elements)) ;;; This should be in 3600-low.lisp #+symbolics (import 'scl:with-stack-list 'pcl) (defmethod make-instance ((class standard-class) &rest initargs) (setq initargs (default-initargs class initargs)) (if initargs (with-stack-list (classes class) (with-stack-list (prototypes (class-prototype class)) (check-initargs-1 class initargs (compute-applicable-methods #'allocate-instance classes) (compute-applicable-methods #'initialize-instance prototypes) (compute-applicable-methods #'shared-initialize prototypes))))) (let ((instance (apply #'allocate-instance class initargs))) (apply #'initialize-instance instance initargs) instance)) (defmethod reinitialize-instance ((instance object) &rest initargs) (if initargs (with-stack-list (instances instance) (check-initargs-1 (class-of instance) initargs (compute-applicable-methods #'reinitialize-instance instances) (compute-applicable-methods #'shared-initialize instances)))) (apply #'shared-initialize instance nil initargs) instance) (defmethod update-instance-for-different-class ((previous object) (current object) &rest initargs) (if initargs (with-stack-list (pc previous current) (with-stack-list (c current) (check-initargs-1 (class-of current) initargs (compute-applicable-methods #'update-instance-for-different-class pc) (compute-applicable-methods #'shared-initialize c))))) ;; ;; First we must compute the newly added slots. The spec defines ;; newly added slots as "those local slots for which no slot of ;; the same name exists in the previous class." (let ((added-slots '()) (current-slotds (class-slots (class-of current))) (previous-slot-names (mapcar #'slotd-name (class-slots (class-of previous))))) (dolist (slotd current-slotds) (if (and (not (memq (slotd-name slotd) previous-slot-names)) (eq (slotd-allocation slotd) ':instance)) (push (slotd-name slotd) added-slots))) (apply #'shared-initialize current added-slots initargs))) (defmethod update-instance-for-redefined-class ((instance object) added-slots discarded-slots property-list &rest initargs) (declare (ignore discarded-slots property-list)) (if initargs (with-stack-list (i instance) (check-initargs-1 (class-of instance) initargs (compute-applicable-methods #'update-instance-for-redefined-class i) (compute-applicable-methods #'shared-initialize i)))) (apply #'shared-initialize instance added-slots initargs)) ;;; ;;; For bootstrapping reasons, the real definition of this appears ;;; in fixup.lisp. ;;; (proclaim '(notinline check-initargs-1)) (defun check-initargs-1 (class initargs &rest methods-lists) (declare (ignore class initargs methods-lists)) ()) ;;; ;;; Patch FIXUP.LISP ;;; (defun check-initargs-1 (class initargs &rest method-lists) (let ((legal (apply #'append (mapcar #'slotd-initargs (class-slots class))))) (unless (getf initargs :allow-other-keys) ;; Add to the set of slot-filling initargs the set of ;; initargs that are accepted by the methods. If at ;; any point we come across &allow-other-keys, we can ;; just quit. (dolist (methods method-lists) (dolist (method methods) (multiple-value-bind (keys allow-other-keys) (function-keywords method) (when allow-other-keys (return-from check-initargs-1 nil)) (setq legal (append keys legal))))) ;; Now check the supplied-initarg-names and the default initargs ;; against the total set that we know are legal. (doplist (key val) initargs (unless (memq key legal) (error "Invalid initialization argument ~S for class ~S" key (class-name class))))))) Received: from Xerox.COM by arisia.xerox.com with SMTP (5.61+/IDA-1.2.8/gandalf) id AA23974; Thu, 10 Aug 89 12:56:49 -0700 Received: from Chardonnay.ms by ArpaGateway.ms ; 10 AUG 89 12:58:08 PDT Return-Path: Redistributed: commonloops.pa Received: from DINO.BBN.COM ([128.89.3.8]) by Xerox.COM ; 10 AUG 89 12:55:05 PDT To: Gregor.pa@Xerox.COM Cc: CHEEWEEI%ITIVAX.BITNET@cunyvm.cuny.edu, commonloops.pa@Xerox.COM Subject: Re: no-applicable-method In-Reply-To: Your message of Wed, 09 Aug 89 20:12:00 -0700. <19890810031203.9.GREGOR@SPIFF.parc.xerox.com> Date: Thu, 10 Aug 89 16:07:54 -0400 From: kanderso@DINO.BBN.COM Message-Id: <890810-125808-7326@Xerox> Some small items on NO-APPLICALBLE-METHOD: 1. The example that cheeweei has trouble with works fine in my system. 2. In Flavors it was easy for a class (flavor) to attach methods to the equivalent of NO-APPLICABLE-METHOD. Unfortuantely, this seems to be one thing that we lost with CLOS being more general. It would be nice if somehow NO-APPLICABLE-METHOD could specialize more than its first argument, but it can't. 3. If i'm forced by Gregor not to change STANDARD-GENERIC-FUNCTION, i must define my own and make every gf use it. This is a lot more work than simply adding one new method around NO-APPLICABLE-METHOD. k Received: from Xerox.COM by arisia.xerox.com with SMTP (5.61+/IDA-1.2.8/gandalf) id AA24172; Thu, 10 Aug 89 13:12:21 -0700 Received: from Salvador.ms by ArpaGateway.ms ; 10 AUG 89 13:13:51 PDT Return-Path: Redistributed: commonloops.pa Received: from eecs.nwu.edu ([129.105.5.103]) by Xerox.COM ; 10 AUG 89 13:06:55 PDT Received: by delta.eecs.nwu.edu id aa20435; 10 Aug 89 15:06 CDT To: commonloops.pa@Xerox.COM Subject: PCL compile error in Allegro 1.2.2 Date: Thu, 10 Aug 89 14:59:47 CDT From: jona@eecs.nwu.edu Sender: jona@eecs.nwu.edu Message-Id: <8908101459.aa20302@delta.eecs.nwu.edu> When trying to compile PCL under Allegro CL 1.2.2 on a Mac IIx running system 6.0.3 I get the following error message: Compiling HIGH... > Continuable Error: The function DESCRIBE is already defined in the CCL kernel. > While executing: # > If Continued: Replace the definition of DESCRIBE. > Type Command-/ to continue, Command to abort. 1 > The fuction DESCRIBE is indeed listed in Steele's Common Lisp bible. What do you suggest? Thanks for looking into this. --Kemi ------------------------------------ Kemi Jona jona@eecs.nwu.edu Institute for the Learning Sciences 2029 Sheridan Rd. Swift Hall 102 Evanston, IL 60208 (312) 491-3500 Received: from Xerox.COM by arisia.xerox.com with SMTP (5.61+/IDA-1.2.8/gandalf) id AA24212; Thu, 10 Aug 89 13:14:55 -0700 Received: from Semillon.ms by ArpaGateway.ms ; 10 AUG 89 13:15:23 PDT Return-Path: Redistributed: commonloops.pa Received: from DINO.BBN.COM ([128.89.3.8]) by Xerox.COM ; 10 AUG 89 13:07:41 PDT Received: by DINO.BBN.COM id aa09015; 10 Aug 89 15:57 EDT To: Gregor.pa@Xerox.COM Cc: CHEEWEEI%ITIVAX.BITNET@cunyvm.cuny.edu, commonloops.pa@Xerox.COM Subject: Re: no-applicable-method In-Reply-To: Your message of Wed, 09 Aug 89 20:12:00 -0700. <19890810031203.9.GREGOR@SPIFF.parc.xerox.com> Date: Thu, 10 Aug 89 16:07:10 -0400 From: kanderso@DINO.BBN.COM Message-Id: <890810-131523-7382@Xerox> Some small items on NO-APPLICALBLE-METHOD: 1. The example that cheeweei has trouble with works fine in my system. 2. In Flavors it was easy for a class (flavor) to attach methods to the equivalent of NO-APPLICABLE-METHOD. Unfortuantely, this seems to be one thing that we lost with CLOS being more general. It would be nice if somehow NO-APPLICABLE-METHOD could specialize more than its first argument, but it can't. 3. If i'm forced by Gregor not to change STANDARD-GENERIC-FUNCTION, i must define my own and make every gf use it. This is a lot more work than simply adding one new method around NO-APPLICABLE-METHOD. k Received: from Xerox.COM by arisia.xerox.com with SMTP (5.61+/IDA-1.2.8/gandalf) id AA25846; Thu, 10 Aug 89 15:03:11 -0700 Received: from Chardonnay.ms by ArpaGateway.ms ; 10 AUG 89 14:47:48 PDT Return-Path: Redistributed: commonloops.pa Received: from lucid.com ([192.26.25.1]) by Xerox.COM ; 10 AUG 89 14:37:53 PDT Received: from bhopal ([192.43.178.13]) by heavens-gate id AA05639g; Thu, 10 Aug 89 14:33:47 PDT Received: by bhopal id AA02862g; Thu, 10 Aug 89 14:35:50 PDT Date: Thu, 10 Aug 89 14:35:50 PDT From: Jon L White Message-Id: <8908102135.AA02862@bhopal> To: kanderso@DINO.BBN.COM Cc: Gregor.pa@Xerox.COM, CHEEWEEI%ITIVAX.BITNET@cunyvm.cuny.edu, commonloops.pa@Xerox.COM In-Reply-To: kanderso@DINO.BBN.COM's message of Thu, 10 Aug 89 13:25:38 -0400 <890810-101745-6983@Xerox> Subject: no-applicable-method re: 1. The example that cheeweei has trouble with works fine in my system. At least, the example below works. 2. The problem that i have with NO-APPLICABLE-METHOD is that i'd really like to specialize it on more than the first argument. For example, say i define a class that uses NO-APPLICABLE-METHOD to do a kind of simple delegation: (defmethod no-applicable-method ((gf standard-generic-function) &rest args) ;; Try delegation. (let ((method (apply #'find-delegated-method gf args))) (if method (apply method args) (call-next-method)))) I wonder how this example can work since standard methods aren't typically implemented as applicable functions. So (apply method args) means ??? A similar problem arose with one of Lucid's end users -- an application that had a rare case which the person wanted to fix by a similar kind of delegation. We've supplied an extension to meet this need, although we'd recommend that extensive use of delegation be done in some other way. The design looks something like: (defun APPLY-METHOD (method next-methods &rest arguments) ...) is a normal function that "dispatches" to the method supplied as it's first argument, passing along as arguments the 'arguments' and providing a next-methods context from the argument 'next-methods' ['next-methods' will be a list when "next-methods" are permitted.] As to why APPLY-METHOD is not generic -- there is an analogy to SLOT-VALUE. The person needing to put methods on it is the "system implementor", and he would likely do so on some "meta" level function named something like APPLY-METHOD-USING-CLASS. Possibly that function would specialize both on the class of the method, and the class of the generic-function that the method "belongs to". [A method object contains a pointer back to the function that it "belongs to".] Should the time ever come when it is desirable to do so, we may add APPLY-METHOD-USING-CLASS and "expose" it at the same level as other "meta" things; that way, the end user could become a "system implementor" to the degree that the "meta" interface allows him. APPLY-METHOD-FUNCTION from X3J13/89-003 ["Chapter 3", the metaobject proposal that never actually came up to a vote] is much too complex for the user-level need. Furthermore, it may be presuming too much about the way methods must be implemented. It requires them to have underlying functions -- the METHOD-FUNCTION slot -- but there are some implementations with certain classes of efficient methods that don't have such functions. -- JonL -- Received: from Xerox.COM by arisia.xerox.com with SMTP (5.61+/IDA-1.2.8/gandalf) id AA25846; Thu, 10 Aug 89 15:03:11 -0700 Received: from Chardonnay.ms by ArpaGateway.ms ; 10 AUG 89 14:47:48 PDT Return-Path: Redistributed: commonloops.pa Received: from lucid.com ([192.26.25.1]) by Xerox.COM ; 10 AUG 89 14:37:53 PDT Received: from bhopal ([192.43.178.13]) by heavens-gate id AA05639g; Thu, 10 Aug 89 14:33:47 PDT Received: by bhopal id AA02862g; Thu, 10 Aug 89 14:35:50 PDT Date: Thu, 10 Aug 89 14:35:50 PDT From: Jon L White Message-Id: <8908102135.AA02862@bhopal> To: kanderso@DINO.BBN.COM Cc: Gregor.pa@Xerox.COM, CHEEWEEI%ITIVAX.BITNET@cunyvm.cuny.edu, commonloops.pa@Xerox.COM In-Reply-To: kanderso@DINO.BBN.COM's message of Thu, 10 Aug 89 13:25:38 -0400 <890810-101745-6983@Xerox> Subject: no-applicable-method re: 1. The example that cheeweei has trouble with works fine in my system. At least, the example below works. 2. The problem that i have with NO-APPLICABLE-METHOD is that i'd really like to specialize it on more than the first argument. For example, say i define a class that uses NO-APPLICABLE-METHOD to do a kind of simple delegation: (defmethod no-applicable-method ((gf standard-generic-function) &rest args) ;; Try delegation. (let ((method (apply #'find-delegated-method gf args))) (if method (apply method args) (call-next-method)))) I wonder how this example can work since standard methods aren't typically implemented as applicable functions. So (apply method args) means ??? A similar problem arose with one of Lucid's end users -- an application that had a rare case which the person wanted to fix by a similar kind of delegation. We've supplied an extension to meet this need, although we'd recommend that extensive use of delegation be done in some other way. The design looks something like: (defun APPLY-METHOD (method next-methods &rest arguments) ...) is a normal function that "dispatches" to the method supplied as it's first argument, passing along as arguments the 'arguments' and providing a next-methods context from the argument 'next-methods' ['next-methods' will be a list when "next-methods" are permitted.] As to why APPLY-METHOD is not generic -- there is an analogy to SLOT-VALUE. The person needing to put methods on it is the "system implementor", and he would likely do so on some "meta" level function named something like APPLY-METHOD-USING-CLASS. Possibly that function would specialize both on the class of the method, and the class of the generic-function that the method "belongs to". [A method object contains a pointer back to the function that it "belongs to".] Should the time ever come when it is desirable to do so, we may add APPLY-METHOD-USING-CLASS and "expose" it at the same level as other "meta" things; that way, the end user could become a "system implementor" to the degree that the "meta" interface allows him. APPLY-METHOD-FUNCTION from X3J13/89-003 ["Chapter 3", the metaobject proposal that never actually came up to a vote] is much too complex for the user-level need. Furthermore, it may be presuming too much about the way methods must be implemented. It requires them to have underlying functions -- the METHOD-FUNCTION slot -- but there are some implementations with certain classes of efficient methods that don't have such functions. -- JonL --