From Gregor.pa@Xerox.COM Fri Aug 5 18:28:43 1988 Return-Path: Received: from Xerox.COM by arisia.Xerox.COM (4.0/SMI-DDN) id AA18035; Fri, 5 Aug 88 18:28:43 PDT Received: from Semillon.ms by ArpaGateway.ms ; 05 AUG 88 18:23:27 PDT Date: Fri, 5 Aug 88 18:21 PDT From: Gregor.pa@Xerox.COM Subject: Re: description language classes & the Meta-Object Protocol To: John Rose Cc: common-lisp-object-system@sail.stanford.edu, CommonLoops.pa@Xerox.COM Fcc: BD:>Gregor>mail>outgoing-mail-3.text.newest In-Reply-To: <8808051925.AA05986@lukasiewicz.sun.com> Message-Id: <19880806012130.5.GREGOR@PORTNOY.parc.xerox.com> Line-Fold: no Date: Fri, 5 Aug 88 12:25:14 PDT From: jrose@Sun.COM (John Rose) I'm going to describe a way I'd like to use the Meta-Object Protocol. Hopefully, readers of this list will either tell me why it's a misuse, or assure me that the Meta-Object Protocol will support what I have in mind. Danny and I spent some time talking about this, and I plan to send a message about this next week once I finish the current round of hacking. ------- From Gregor.pa@Xerox.COM Mon Aug 8 11:35:11 1988 Return-Path: Received: from Xerox.COM by arisia.Xerox.COM (4.0/SMI-DDN) id AA26328; Mon, 8 Aug 88 11:35:11 PDT Received: from Semillon.ms by ArpaGateway.ms ; 08 AUG 88 11:23:12 PDT Date: Mon, 8 Aug 88 11:18 PDT From: Gregor.pa@Xerox.COM Subject: Re: Version of 2 August 88 To: M. Schneider-Hufschmidt Cc: CommonLoops.pa@Xerox.COM Fcc: BD:>Gregor>mail>outgoing-mail-3.text.newest In-Reply-To: <8808051455.AA22830@ztivax.uucp> Message-Id: <19880808181859.9.GREGOR@PORTNOY.parc.xerox.com> Line-Fold: no Date: Fri, 5 Aug 88 16:55:50 -0200 From: msch@ztivax.siemens.com (M. Schneider-Hufschmidt) 1. Since compat.lisp is no longer in pcl you should take it out of the system-definition. compat.lisp is still one of the files in PCL. It should still be on the /pcl directory. 2. Under Xerox-Lyric the fix-early-generic-functions in fixup.lisp tries to aref on a ptr-hunk. The bug seems to be inserted by the change of reader/writer-method-slot-name in methods.lisp. Taking the change back caused pcl to compile and load nicely. However, I can't tell for sure that everything works correct like this. This change probably won't really fix things for you. The 8/2/88 version of PCL doesn't work in Xerox Lisp. I suspect the next version we release will work in Xerox Lisp though since there are people here who are using it. ------- From Gregor.pa@Xerox.COM Mon Aug 8 13:26:36 1988 Return-Path: Received: from Xerox.COM by arisia.Xerox.COM (4.0/SMI-DDN) id AA26877; Mon, 8 Aug 88 13:26:36 PDT Received: from Semillon.ms by ArpaGateway.ms ; 08 AUG 88 13:29:44 PDT Date: Mon, 8 Aug 88 13:20 PDT From: Gregor.pa@Xerox.COM Subject: (SETF FOO) in next PCL To: CommonLoops.PA@Xerox.COM Fcc: BD:>Gregor>mail>outgoing-mail-3.text.newest Message-Id: <19880808202001.7.GREGOR@PORTNOY.parc.xerox.com> Line-Fold: no The next release of PCL includes a fairly significant change related to the order of arguments of setf functions. To most all user programs, this change should be invisible. Your program should run just fine in the new version of PCL. Once you get it running, you will need to do some conversion however since DEFMETHOD-SETF is now obsolete and will be going away soon. Some programs may take some work to adapt to this change. This will particularly be true of programs which manipulated methods for setf generic-functions using make-instance, add-method and friends. This message gives a brief overview of the upcoming change to PCL. This overview is must reading for anyone programming in PCL. Many people will find that this message will be all they need to know about this change. A subsequent message will present more details which may be important to people maintaing programs which do more internal hacking. The CLOS specification assumes a default behavior for SETF in the absence of any defsetf or define-modify-macro. The default behavior is to expand forms like: (SETF (FOO x y) a) into: (FUNCALL #'(SETF FOO) a x y) The key point is that by default, setf expands into a call to a function with a well-defined name, and that in that call, the new value argument comes before all the other arguments. This requires a change in PCL, because previously, PCL arranged for the new-value argument to be the last required argument. This change affects the way automatically generated writer methods work, and the way that defmethod with a first argument of the form (SETF ) works. An important point is that I cannot implement function names of the form (SETF ) portably in PCL. As a result, in PCL, I am using names of the form |SETF FOO|. Note that the symbol |SETF FOO| is interned in the home package of the symbol FOO. (See the description of the GET-SETF-FUNCTION and GET-SETF-FUNCTION-NAME). CertainlyThe user-visible changes will be: * All programs will need to be completely recompiled to run in this release of PCL. * DEFMETHOD will accept lists of the form (SETF FOO) as a first argument. This will define methods on the generic function named by the symbol |SETF FOO|. As specified in the spec, these methods should expect to receive the new-value as their first argument. Calls to defmethod of this form will also arrange for SETF of FOO to expand into an appropriate call to |SETF FOO|. * Automatically generated writer methods will expect to receive the new value as their first argument. * DEFMETHOD-SETF will also place the new-value as the first argument. This is for backward compatibility, since defmethod-setf itself will be obsolete, and you should convert your code to stop using it. * GET-SETF-FUNCTION is a function which takes a function name and returns the setf function for that function if there is one. Note that it doesn't take an environment argument. Note that this function is not specified in Common Lisp or CLOS. PCL will continue to support it as an extra export indefinetely. * GET-SETF-FUNCTION-NAME is a function which takes a function name and returns the symbol which names the setf function for that function. Note that this function is not specified in Common Lisp or CLOS. PCL will continue to support it as an extra export indefinetely. * For convenience, PCL defines a macro called DO-STANDARD-DEFSETF which can be used to do the appropriate defsetf. This may be helpful for programs which have calls to setf of a generic-function before any of the generic function's method definitions. A use of this macro looks like: (do-standard-defsetf position-x) Afterwards, a form like (SETF (POSITION-X P) V) will expand into a form like (|SETF POSITION-X| V P). The reason you may have to use do-standard-defsetf is that I cannot portably change every implementations SETF to have the new default behavior. The proper way to use this is to take an early file in your system, and put a bunch of calls to do-standard-defsetf in it. Note that as soon as PCL sees a defmethod with a name argument of the form (SETF FOO), or it sees a :accessor in a defclass, it will do an appropriate do-standard-defsetf for you. In summary, the only things that will need to be changed in most programs is that uses of defmethod-setf should be converted to appropriate uses of defmethod. Here is an example of a typical user program which is affected by this change. (defclass position () ((x :initform 0 :accessor pos-x) (y :initform 0 :accessor pos-y))) (defclass monitored-position (position) ()) (defmethod-setf pos-x :before ((p monitored-position)) (new) (format *trace-output* "~&Changing x coord of ~S to ~D." p new)) (defmethod-setf pos-y :before ((p monitored-position)) (new) (format *trace-output* "~&Changing y coord of ~S to ~D." p new)) To bring this program up to date, you should convert the two defmethod-setf forms as follows: (defmethod (setf pos-x) :before (new (p monitored-position)) (format *trace-output* "~&Changing x coord of ~S to ~D." p new)) (defmethod (setf pos-y) :before (new (p monitored-position)) (format *trace-output* "~&Changing y coord of ~S to ~D." p new)) ------- From Gregor.pa@Xerox.COM Mon Aug 8 14:03:17 1988 Return-Path: Received: from Xerox.COM by arisia.Xerox.COM (4.0/SMI-DDN) id AB27944; Mon, 8 Aug 88 14:03:17 PDT Received: from Semillon.ms by ArpaGateway.ms ; 08 AUG 88 13:39:17 PDT Date: Mon, 8 Aug 88 13:29 PDT From: Gregor.pa@Xerox.COM Subject: Re: Misc. PCL patches To: LaMott Oren Cc: CommonLoops.pa@Xerox.COM Fcc: BD:>Gregor>mail>outgoing-mail-3.text.newest In-Reply-To: <2795811648-642518@SI> Message-Id: <19880808202921.8.GREGOR@PORTNOY.parc.xerox.com> Line-Fold: no Date: Fri, 5 Aug 88 17:20:48 CDT From: LaMott Oren I'm working with *pcl-system-date* "7/7/88 (beta) July 7th PCL" and made the following patches: Thanks for these changes. Even though I am not going to make the particular changes you sent, they point out some important issues, and except for the declare macros change, we are working on equivalent changes. ;;; Reason: Common-lisp allows macros to define declarations. ;;; Patch PCL to allow this also. A cleanup committe proposal modifies Common Lisp not to allow this. PCL doesn't allow this by concious design decision. It used to allow it and doesn't now. So, I am not going to put this patch in. ;;; Reason: Explorer DEFSTRUCT has a bug where an inefficient predicate ;;; gets generated the first time its compiled. Redefine ;;; IWMC-CLASS-P with an efficient definition. (This makes some ;;; PCL applications run TWICE as fast) ;; In the TI-LOW file (proclaim '(inline IWMC-CLASS-P)) (defun IWMC-CLASS-P (thing) (typep thing 'iwmc-class)) An equivalent version of this change was contributed by Reed Hastings at Stanford. I will include this in the next release along with some other Explorer changes which are sitting on a Macintosh disk in my office. ;;; Reason: Optimize initialize-instance for the common case ;;; where there are less than two slot-initargs. The next release of PCL will include an implementation of the real initialization protocol specified by 88-002R. It will also include a mechanism for defining functions which are equivalent to calls to make-instance. These functions will be highly optimized, and this should speed up instance creation dramatically. ------- From Gregor.pa@Xerox.COM Mon Aug 8 17:37:26 1988 Return-Path: Received: from Xerox.COM by arisia.Xerox.COM (4.0/SMI-DDN) id AA00607; Mon, 8 Aug 88 17:37:26 PDT Received: from Semillon.ms by ArpaGateway.ms ; 08 AUG 88 17:37:12 PDT Date: Mon, 8 Aug 88 17:34 PDT From: Gregor.pa@Xerox.COM Subject: Re: 88/8/1 PCL patches To: kanderso@WILMA.BBN.COM Cc: CommonLoops.pa@Xerox.COM, kanderson@WILMA.BBN.COM Fcc: BD:>Gregor>mail>outgoing-mail-3.text.newest In-Reply-To: The message of 2 Aug 88 14:28 PDT from kanderso@WILMA.BBN.COM Message-Id: <19880809003414.0.GREGOR@PORTNOY.parc.xerox.com> Line-Fold: no Date: Tue, 02 Aug 88 17:28:50 -0400 From: kanderso@WILMA.BBN.COM Gregor, Here are the remaining patches i've had to make to get the latest PCL to run through my test cases. Thanks once again for your patches and help with PCL. Here is the current status of these patches with respect to my sources here. Basically they cover: 1. Jim Larus' performance improvements. Looking through these, it looks like a lot of this can be achived by changing the definitions of the %mumble functions in low.lisp as follows: (defmacro %logand (&rest args) (reduce-variadic-to-binary 'logand args 0 t 'fixnum)) (defmacro %logxor (&rest args) (reduce-variadic-to-binary 'logxor args 0 t 'fixnum)) (defmacro %+ (&rest args) (reduce-variadic-to-binary '+ args 0 t 'fixnum)) ;;; ;;; This support function may be useful for ports which are redefining ;;; the primitive math and logic operations. ;;; (defun reduce-variadic-to-binary (binary-op args default identity-with-one-argument-p type) (labels ((bin (args) (if (null (cdr args)) `(the ,type ,(car args)) `(the ,type (,binary-op (the ,type ,(car args)) ,(bin (cdr args))))))) (cond ((null args) `(the ,type ,default)) ((and identity-with-one-argument-p (null (cdr args))) `(the ,type ,(car args))) (t (bin args))))) I have done that in my sources here and this will be in the next release of PCL. In addition, it is necessary to fix a couple of things in dcode, which I have also done. 2. Class redefinition infinite loop. The next release of PCL will use a completely different underlying mechanism for handling redefined classes. The user behavior should conform fully to 88-002R. That is to say that when a class is redefined, and the instances must be updated, the generic function update-instance-for-redefined-class will be called with arguments as specified. So this long-lingering class redefinition infinite loop problem will be solved. 3. Angela Dappert-Farquhar's with-slots-internal--class and related function. I don't understand quite what this does? 4. Eliminate need for class-direct-generic-functions. This will be in the next release. 5. Fix some differences between 7-1 and 7-2 debugger. I realize, you plan to rework some of these, but 2 & 3 are needed to make PCL useable now. ;;;-*-Mode:LISP; Package:(PCL LISP 1000); Base:10; Syntax:Common-lisp; Patch-File: Yes -*- ;;; Patches to "8/1/88 (beta) Laguna Seca PCL" ;;; Patches that must be made in the sources files are commented out here with ;;; "#+patched-in-sources". #|| Questions: ? Why does make-parameter-references produce a warning? make-parameter-references warns when it sees a redundant ignore declaration in a defmethod. Since defmethod is supposed to "reference" all the arguments which have a specializer, an ignore declaration for one of those arguments should be redundant. Have you found a case where it produces erroneous warnings? ? Can the logand's and logxor's in dcode be replaced by %logand and %logxor? This is done in the next release. Actually there are no more calls to either of these in dcode. Instead, dcode calls a new facility called cache-key-from-wrappers. This is defined in vector lisp and only uses %mumble functions. To Do: o mki -> make-instance. In the next release, there will be an implementation of the initialization protocol as defined in 88-002. This will be part of a two-step process geared towards getting rid of the old initialization protocols and introducing the new one. In the next release, the new functions will be called: *make-instance *initialize-instance shared-initialize update-instance-for-redefined-class update-instance-for-different-class In a subsequent release *make-instance and *initialize-instance will be renamed to their real names. Sometime in between, PCL will be converted to use the new initialization protocol. o Remove extra defmethod print-object in methods.lisp Done. o add ignore declarations to keep compiler quiet. Done partially. I will try to do the rest of these before the next release. o Fix iterate compiler problem in 7.1 For you to do since I don't have a 7.1. o extend Jim larus's fixnum patch to pair logand arguments for machines that only optimize binary arguments. As mentioned above, I did this in low.lisp. BUGS: o specializer (eql fred) works but (eql 'fred) as in CLOS doesn't. This should work now. What still is a problem is that eql methods don't work too well with method combination. o supress lispm's redefinition warnings for setf methods. Yes, I would like to see this fixed. This is on my agenda of things to do as part of a more intimate interface to setf from PCL. o C-E in debugger or M-. on a method can't find it unless it has been ZMAC'd o tracing methods doesn't work ------- From Owners-commonloops.pa@Xerox.COM Tue Aug 9 08:24:08 1988 Received: from Xerox.COM by arisia.Xerox.COM (4.0/SMI-DDN) id AA02107; Tue, 9 Aug 88 08:24:08 PDT Received: from Cabernet.ms by ArpaGateway.ms ; 09 AUG 88 08:10:27 PDT Return-Path: Redistributed: commonloops.pa Received: from Sun.COM ([10.7.0.2]) by Xerox.COM ; 09 AUG 88 08:09:05 PDT Received: from snail.sun.com by Sun.COM (4.0/SMI-4.0) id AA17599; Tue, 9 Aug 88 08:06:55 PDT Received: from suntana.sun.com by snail.sun.com (4.0/SMI-4.0) id AA10297; Tue, 9 Aug 88 08:07:38 PDT Received: from localhost by suntana.sun.com (4.0/SMI-4.0) id AA07541; Tue, 9 Aug 88 08:06:25 PDT Message-Id: <8808091506.AA07541@suntana.sun.com> To: kanderson@WILMA.BBN.COM, CommonLoops.pa@Xerox.COM Subject: Re: 88/8/1 PCL patches In-Reply-To: Your message of Mon, 08 Aug 88 17:34:00 -0700. <19880809003414.0.GREGOR@PORTNOY.parc.xerox.com> Date: Tue, 09 Aug 88 08:06:22 -0700 From: kempf@Sun.COM > o C-E in debugger or M-. on a method can't find it unless it has > been ZMAC'd > > o tracing methods doesn't work Since CLtL doesn't define any programming environment hooks beyond TRACE and a few others, these will be fairly implementation specific. Of course, if a portable interface can be defined which allows multiple implementations to benefit, then such hooks are a win for everybody, but doing them for one specific implementation (such as the Lisp Machine) unfairly excludes users of other implementations. jak From Owners-Commonloops.pa@Xerox.COM Tue Aug 9 14:17:23 1988 Received: from Xerox.COM by arisia.Xerox.COM (4.0/SMI-DDN) id AA01910; Tue, 9 Aug 88 14:17:23 PDT Received: from Riesling.ms by ArpaGateway.ms ; 09 AUG 88 14:06:21 PDT Return-Path: Redistributed: Commonloops.pa Received: from rand-unix.arpa ([10.3.0.7]) by Xerox.COM ; 09 AUG 88 14:05:19 PDT Received: by rand-unix.arpa; Tue, 9 Aug 88 13:25:48 PDT Message-Id: <8808092025.AA20088@rand-unix.arpa> To: Commonloops.pa@Xerox.COM Cc: David_McArthur , Darrell_Shane Subject: 8/3/88 version won't compile under KCL Date: Tue, 09 Aug 88 13:25:46 PDT From: burdorf@rand-unix.ARPA I just brought over the new version of PCL and tried to get it running under KCL. What version of KCL is it supposed to run under. I tried it under the September 13, 1986 version and got the following results: taos% kcl KCl (Kyoto Common Lisp) September 13, 1986 >(load "defsys.lsp") Loading defsys.lsp Finished loading defsys.lsp T (pcl::compile-pcl) Compiling KCL-PATCHES... Compiling /g/burdorf/kpcl/pcl/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 /g/burdorf/kpcl/pcl/kcl-patches.lsp. Loading binary of KCL-PATCHES... Compiling PKG... Compiling /g/burdorf/kpcl/pcl/pkg.lsp. Error: Cannot use #<"ITERATE" package> from #<"PCL" package>, because ITERATE:ITERATE and PCL::ITERATE will cause a name conflict. Error signalled by IN-PACKAGE. Backtrace: > eval > IN-PACKAGE ; (IN-PACKAGE 'PCL ...) is being compiled. ;;; The form (IN-PACKAGE 'PCL :USE '("LISP" "WALKER" "ITERATE")) was not evaluat ed successfully. ;;; You are recommended to compile again. Error: Cannot import the symbol DEFCLASS from #<"PCL" package>, because there is already a symbol with the same name in the package. Error signalled by EXPORT. Backtrace: > eval > EXPORT ; (EXPORT '(DEFCLASS MAKE-INSTANCE ...) ...) is being compiled. ;;; The form (EXPORT '(DEFCLASS MAKE-INSTANCE DEFMETHOD DEFMETHOD-SETF DEFGENERI C-OPTIONS DEFGENERIC-OPTIONS-SETF CALL-NEXT-METHOD NEXT-METHOD-P SLOT-VALUE WITH - -SLOTS WITH-ACCESSORS CHANGE-CLASS CLASS-CHANGED ADD-METHOD CLASS-NAMED SYMBOL-C LASS CBOUNDP GET-METHOD GET-SETF-GENERIC-FUNCTION REMOVE-METHOD DEFINE-METHOD-CO MBINATION MAKE-METHOD-CALL METHOD-QUALIFIERS METHOD-COMBINATION-ERROR INVALID-ME THOD-ERROR CLASS-OF PRINT-OBJECT FIND-CLASS) (FIND-PACKAGE 'PCL)) was not evalua ted successfully. ;;; You are recommended to compile again. No FASL generated. I would greatly appreciate any help I can get with this problem. thanks, Chris Burdorf burdorf@rand-unix.org ------- End of Forwarded Message From Owners-commonloops.pa@Xerox.COM Tue Aug 9 14:57:09 1988 Received: from Xerox.COM by arisia.Xerox.COM (4.0/SMI-DDN) id AA02104; Tue, 9 Aug 88 14:57:09 PDT Received: from Burger.ms by ArpaGateway.ms ; 09 AUG 88 14:49:45 PDT Return-Path: Redistributed: commonloops.pa Received: from fs3.cs.rpi.edu ([128.213.1.14]) by Xerox.COM ; 09 AUG 88 14:48:39 PDT Received: by fs3.cs.rpi.edu (5.54/1.2-RPI-CS-Dept) id AA00565; Tue, 9 Aug 88 17:47:33 EDT Date: Tue, 9 Aug 88 17:47:31 EDT From: harrisr@turing.cs.rpi.edu (Richard Harris) Received: by turing.cs.rpi.edu (4.0/1.2-RPI-CS-Dept) id AA28014; Tue, 9 Aug 88 17:47:31 EDT Message-Id: <8808092147.AA28014@turing.cs.rpi.edu> To: commonloops.pa@Xerox.COM Subject: macros defining declarations It is necessary to have at least some support for macros which define declarations if PCL is to be used with the current (X11R2) version of CLX, as in CLUE. The CLX macros which define declarations are: declare-arglist, declare-values, declare-array, declare-funarg, declare-bufmac, and declare-buffun. These macros allow implementation dependencies in declarations to be collected into one place. For example, here is the definition of declare-funarg: #+lispm (defmacro declare-funarg (type &rest vars) `(declare (type ,type ,@vars) (sys:downward-funarg ,@vars))) #-lispm (defmacro declare-funarg (type &rest vars) `(declare (type ,type ,@vars))) > ;;; Reason: Common-lisp allows macros to define declarations. > ;;; Patch PCL to allow this also. > >A cleanup committe proposal modifies Common Lisp not to allow this. PCL >doesn't allow this by concious design decision. It used to allow it and >doesn't now. So, I am not going to put this patch in. Please tell me how to find out more about this proposal. Rick From Owners-commonloops.pa@Xerox.COM Tue Aug 9 16:41:52 1988 Received: from Xerox.COM by arisia.Xerox.COM (4.0/SMI-DDN) id AB02731; Tue, 9 Aug 88 16:41:52 PDT Received: from Salvador.ms by ArpaGateway.ms ; 09 AUG 88 16:37:39 PDT Return-Path: Redistributed: commonloops.pa Received: from SUMEX-AIM.Stanford.EDU ([10.0.0.56]) by Xerox.COM ; 09 AUG 88 16:34:51 PDT Date: Tue, 9 Aug 88 16:30:19 PDT From: Vaughan Johnson Subject: #+lispm bugs To: commonloops.pa@Xerox.COM Cc: vjOHNSON@SUMEX-AIM.Stanford.EDU Message-Id: <12421163748.72.VJOHNSON@SUMEX-AIM.Stanford.EDU> The following code from boot.lisp and defs.lisp used to have #+lispm instead of #+Symbolics. Some of it won't compile on the TI (dbg:report gets translated as eh:report, which has no definition), and the rest is probably not relevant to us on Explorers. The lispm feature is not unique to Symbolics machines, so care needs to be taken in deciding whether to use it or the symbolics feature. Here's the changed code: ;;; From Boot.Lisp #+Symbolics (zl:defflavor generic-clobbers-function (name) (si:error) :initable-instance-variables) #+Symbolics (zl:defmethod (dbg:report generic-clobbers-function) (stream) (format stream "~S aready names a ~a" name (if (and (symbolp name) (macro-function name)) "macro" "function"))) #+Symbolics (zl:defmethod (sys:proceed generic-clobbers-function :specialize-it) () "Make it specializable anyway?" (make-specializable name)) ;;;Edited by Vaughan Johnson 9 Aug 88 16:09 ;;;Edited by Vaughan Johnson 9 Aug 88 16:10 (defun ensure-generic-function (spec &rest keys &key lambda-list argument-precedence-order declarations documentation method-combination generic-function-class method-class) (declare (ignore lambda-list argument-precedence-order declarations documentation method-combination method-class)) (let ((existing (and (gboundp spec) (gdefinition spec)))) (cond ((null existing) (let ((new (apply #'ensure-gf-internal spec keys))) (setq new (set-function-name new spec)) (setf (gdefinition spec) new))) ((funcallable-instance-p existing) existing) (existing #+Symbolics (zl:signal 'generic-clobbers-function :name spec) #-Symbolics (error "~S already names an ordinary function or a macro,~%~ it can't be converted to a generic function." spec))))) ;;; From Defs.Lisp (defun do-defsetf (access store-or-args &optional store-vars &rest body) (let #+Genera ((si:inhibit-fdefine-warnings t)) #-Genera () #+Symbolics (setq body (copy-list body)) (if body (eval `(defsetf ,access ,store-or-args ,store-vars ,@body)) (eval `(defsetf ,access ,store-or-args))))) ----- Vaughan Johnson, vjohnson@sumex-aim.stanford.edu ------- From Owners-CommonLoops.pa@Xerox.COM Wed Aug 10 00:46:59 1988 Received: from Xerox.COM by arisia.Xerox.COM (4.0/SMI-DDN) id AA04932; Wed, 10 Aug 88 00:46:59 PDT Received: from Salvador.ms by ArpaGateway.ms ; 10 AUG 88 00:47:53 PDT Return-Path: Redistributed: CommonLoops.pa Received: from Think.COM ([10.4.0.6]) by Xerox.COM ; 10 AUG 88 00:46:04 PDT Received: from fafnir.think.com by Think.COM; Wed, 10 Aug 88 03:47:21 EDT Return-Path: Received: from sauron.think.com by fafnir.think.com; Wed, 10 Aug 88 03:41:32 EDT Received: from POLYCARP.THINK.COM by sauron.think.com; Wed, 10 Aug 88 03:41:29 EDT Date: Wed, 10 Aug 88 03:41 EDT From: Jim Salem Subject: PCL package To: CommonLoops@Think.COM Message-Id: <19880810074125.7.SALEM@POLYCARP.THINK.COM> Moon: 5 days, 9 hours, 44 minutes since the last quarter of the moon. I am delighted to have a copy of the PCL package. It is just what we are looking for to develop user interface tools on top of CLUE/CLX. We are running it in the Symbolics (7.2) and Lucid ver 2 (Sun 3, hoping for Sun4 and VAX) environments. Suggestions and bugs [8/2/88 version from arisia.xerox.com:/pcl/] :: 1) Please modify the Mode lines to NOT automatically create the packages on Genera. By default, Genera creates the package with the Zetalisp colon mode (i.e. no internal symbols) 2) The definition of the mapforms property of pcl::top-level-form was commented out in rel-7-2-patches. This caused the Genera compiler to barf while compiling simple defclasses (like (defclass foo () ())). 3) Sun 4 notes: [Under Lucid 2.1.1] a) %LOGAND& was not defined. I replaced it with the following definition : ;;; Fix for SPARC LCL #+sparc (defun %logand& (x y) (declare (optimize (speed 3) (safety 0)) (inline logand)) (logand (the fixnum x) (the fixnum y)) ) b) Got weird error [FLAG was not either EQ or LUCID::NE] compiling lucid::proceedurep (used by set-function-name-1, funcallable-instance-p, set-funcallable-instance-function). To fix I replaced all uses by a call to the following :: (defun my-procedurep (x) #+sparc (and (functionp x) (not (listp x))) #-sparc (procedurep x) ) c) Finally, there looked to be a compiler bug in PROG which caused ITERATE to lose I gave up at this point. 4) I suggest that all the hair used to define the %logand and %logxor functions on Lucid (in lucid-low) be removed and be replaced by the more common lispy and efficient :: (defmacro %logand (x y) `(the fixnum (locally (declare (optimize (speed 3) (safety 0)) (inline logand)) (logand (the fixnum ,x) (the fixnum ,y))))) -- jim From Owners-commonloops.pa@Xerox.COM Wed Aug 10 07:07:30 1988 Received: from Xerox.COM by arisia.Xerox.COM (4.0/SMI-DDN) id AA06737; Wed, 10 Aug 88 07:07:30 PDT Received: from Cabernet.ms by ArpaGateway.ms ; 10 AUG 88 07:11:02 PDT Return-Path: Redistributed: commonloops.pa Received: from ALDERAAN.SCRC.Symbolics.COM ([128.81.41.109]) by Xerox.COM ; 10 AUG 88 07:09:37 PDT Received: from WINTER.SCRC.Symbolics.COM by ALDERAAN.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 213626; Wed 10-Aug-88 09:31:26 EDT Date: Wed, 10 Aug 88 09:30 EDT From: Charles Hornig Subject: #+lispm bugs To: Vaughan Johnson , commonloops.pa@Xerox.COM In-Reply-To: <12421163748.72.VJOHNSON@SUMEX-AIM.Stanford.EDU> Message-Id: <19880810133040.1.HORNIG@WINTER.SCRC.Symbolics.COM> Date: Tue, 9 Aug 88 16:30:19 PDT From: Vaughan Johnson The following code from boot.lisp and defs.lisp used to have #+lispm instead of #+Symbolics. Some of it won't compile on the TI (dbg:report gets translated as eh:report, which has no definition), and the rest is probably not relevant to us on Explorers. The lispm feature is not unique to Symbolics machines, so care needs to be taken in deciding whether to use it or the symbolics feature. Please also note that not all Symbolics Lisp implementations are LispM's. We sell a 80386 Lisp which has #+Symbolics but not #+LispM. In this case you should use #+Genera. Here's the changed code: ;;; From Boot.Lisp #+Symbolics (zl:defflavor generic-clobbers-function (name) (si:error) :initable-instance-variables) #+Symbolics (zl:defmethod (dbg:report generic-clobbers-function) (stream) (format stream "~S aready names a ~a" name (if (and (symbolp name) (macro-function name)) "macro" "function"))) #+Symbolics (zl:defmethod (sys:proceed generic-clobbers-function :specialize-it) () "Make it specializable anyway?" (make-specializable name)) ;;;Edited by Vaughan Johnson 9 Aug 88 16:09 ;;;Edited by Vaughan Johnson 9 Aug 88 16:10 (defun ensure-generic-function (spec &rest keys &key lambda-list argument-precedence-order declarations documentation method-combination generic-function-class method-class) (declare (ignore lambda-list argument-precedence-order declarations documentation method-combination method-class)) (let ((existing (and (gboundp spec) (gdefinition spec)))) (cond ((null existing) (let ((new (apply #'ensure-gf-internal spec keys))) (setq new (set-function-name new spec)) (setf (gdefinition spec) new))) ((funcallable-instance-p existing) existing) (existing #+Symbolics (zl:signal 'generic-clobbers-function :name spec) #-Symbolics (error "~S already names an ordinary function or a macro,~%~ it can't be converted to a generic function." spec))))) ;;; From Defs.Lisp (defun do-defsetf (access store-or-args &optional store-vars &rest body) (let #+Genera ((si:inhibit-fdefine-warnings t)) #-Genera () #+Symbolics (setq body (copy-list body)) (if body (eval `(defsetf ,access ,store-or-args ,store-vars ,@body)) (eval `(defsetf ,access ,store-or-args))))) ----- Vaughan Johnson, vjohnson@sumex-aim.stanford.edu ------- From Gregor.pa@Xerox.COM Wed Aug 10 09:39:59 1988 Return-Path: Received: from Xerox.COM by arisia.Xerox.COM (4.0/SMI-DDN) id AA07188; Wed, 10 Aug 88 09:39:59 PDT Received: from Semillon.ms by ArpaGateway.ms ; 10 AUG 88 09:40:42 PDT Date: Wed, 10 Aug 88 09:34 PDT From: Gregor.pa@Xerox.COM Subject: Re: macros defining declarations To: Richard Harris , Masinter.pa@Xerox.COM Cc: commonloops.pa@Xerox.COM Fcc: BD:>Gregor>mail>outgoing-mail-3.text.newest In-Reply-To: <8808092147.AA28014@turing.cs.rpi.edu> Message-Id: <19880810163456.3.GREGOR@PORTNOY.parc.xerox.com> Line-Fold: no Date: Tue, 9 Aug 88 17:47:31 EDT From: harrisr@turing.cs.rpi.edu (Richard Harris) It is necessary to have at least some support for macros which define declarations if PCL is to be used with the current (X11R2) version of CLX, as in CLUE. The CLX macros which define declarations are: declare-arglist, declare-values, declare-array, declare-funarg, declare-bufmac, and declare-buffun. These macros allow implementation dependencies in declarations to be collected into one place. I won't say anything too nasty about this use of macros since I used to do it myself. If you say that peole programming with CLX and PCL need this, then I guess its important for PCL to support it. I will change PCL to allow macros to expand into declares. I don't have a copy of the relevant cleanup proposal, but maybe Larry Masinter can mail one out. My understanding is that the idea is to use &body macros which expand into a LOCALLY with the correct declarations instead. Please look at this proposal and determine whether people programming with CLX in PCL could just use this new style instead. Thanks Gregor ------- From Gregor.pa@Xerox.COM Wed Aug 10 09:56:29 1988 Return-Path: Received: from Xerox.COM by arisia.Xerox.COM (4.0/SMI-DDN) id AA07288; Wed, 10 Aug 88 09:56:29 PDT Received: from Semillon.ms by ArpaGateway.ms ; 10 AUG 88 09:57:57 PDT Date: Wed, 10 Aug 88 09:41 PDT From: Gregor.pa@Xerox.COM Reply-To: Gregor.pa@GRAPEVINE.parc.xerox.com Subject: :dynamic slots To: CommonLoops.pa@Xerox.COM Fcc: BD:>Gregor>mail>outgoing-mail-3.text.newest Message-Id: <19880810164146.4.GREGOR@PORTNOY.parc.xerox.com> Line-Fold: no This message is important reading for anyone who uses dynamic slots in the current PCL. This means using any of the following, or any other interface to dynamic slots you may have found. :allocation :dynamic slot-value-always the default argument to slot-value-using-class remove-dynamic-slot dynamic-slots In the next release of PCL, the metaclasses standard-class and funcallable-standard-class will not support dynamic slots. This is being done as one step in a process of bringing these metaclasses into strict conformance with the CLOS specification (88-002R). I will however be glad to implement the replacement functionality that people need. Please send me a brief, but fairly detailed description of how you currently use dynamic slots. What interfaces you use, what behavior you are depending on etc. I will implement a metaclass which has this functionality and distribute it as part of all future PCL releases. Gregor ------- From Owners-CommonLoops.pa@Xerox.COM Wed Aug 10 12:20:26 1988 Received: from Xerox.COM by arisia.Xerox.COM (4.0/SMI-DDN) id AB07715; Wed, 10 Aug 88 12:20:26 PDT Received: from Semillon.ms by ArpaGateway.ms ; 10 AUG 88 12:19:50 PDT Return-Path: Redistributed: CommonLoops.pa Received: from Think.COM ([10.4.0.6]) by Xerox.COM ; 10 AUG 88 12:17:11 PDT Received: from fafnir.think.com by Think.COM; Wed, 10 Aug 88 15:18:21 EDT Return-Path: Received: from sauron.think.com by fafnir.think.com; Wed, 10 Aug 88 15:12:38 EDT Received: by sauron.think.com; Wed, 10 Aug 88 15:12:36 EDT Date: Wed, 10 Aug 88 15:12:36 EDT From: salem@Think.COM Message-Id: <8808101912.AA11041@sauron.think.com> To: commonloops@Think.COM Subject: (DEFMETHOD (setf foo) ... doesn't work In the 8/2/88 version of PCL, (defmethod (setf foo) .... followed by a (setf (foo ... doesn't work because no DEFSETF has been done. In any case, it was not clear to me from the CLOS spec. what the arglist should look like for SETF methods. (Documentation bug ?) Is it : a) (defmethod (setf foo) ((object | class) value) or b) (defmethod (setf foo) (value (object | class)) ?? -- jim P.S. Is this the appropriate list for both these questions ? From Owners-commonloops.pa@Xerox.COM Wed Aug 10 17:36:29 1988 Received: from Xerox.COM by arisia.Xerox.COM (4.0/SMI-DDN) id AB09280; Wed, 10 Aug 88 17:36:29 PDT Received: from Burger.ms by ArpaGateway.ms ; 10 AUG 88 17:21:30 PDT Return-Path: <@EN-C06.Prime.COM,@S51.Prime.COM,@s66.Prime.COM:SOBO@s66.Prime.COM> Redistributed: commonloops.pa Received: from EN-C06.Prime.COM ([192.5.58.32]) by Xerox.COM ; 10 AUG 88 17:20:27 PDT Received: from S51.Prime.COM by EN-C06.Prime.COM; 10 Aug 88 20:20:02 EDT Received: from s66.Prime.COM by S51.Prime.COM; 10 Aug 88 20:21:12 EDT Received: (from user SOBO) by s66.Prime.COM; 10 Aug 88 20:18:45 EST Subject: Mailing List To: commonloops.pa@Xerox.COM From: SOBO@s66.Prime.COM Date: 10 Aug 88 20:18:45 EST Message-Id: <880810-172130-1616@Xerox> Please remove me from the mailing list -- I'm getting duplicate messages. Thanks. Nadine Sobolevitch (sobo@s66.prime.com) From Owners-commonloops.pa@Xerox.COM Thu Aug 11 06:56:37 1988 Received: from Xerox.COM by arisia.Xerox.COM (4.0/SMI-DDN) id AA15744; Thu, 11 Aug 88 06:56:37 PDT Received: from Salvador.ms by ArpaGateway.ms ; 11 AUG 88 06:58:01 PDT Return-Path: <@RELAY.CS.NET:gsmith@scotland.bbn.com> Redistributed: commonloops.pa Received: from RELAY.CS.NET ([10.4.0.5]) by Xerox.COM ; 11 AUG 88 06:56:32 PDT Received: from relay2.cs.net by RELAY.CS.NET id at01390; 11 Aug 88 9:27 EDT Received: from scotland.bbn.com by RELAY.CS.NET id aa06804; 11 Aug 88 9:18 EDT Received: by scotland.bbn.com (3.2/SMI-3.2) id AA04666; Thu, 11 Aug 88 09:10:09 BST Date: Thu, 11 Aug 88 09:10:09 BST From: Graeme Smith BBN Scotland To: commonloops.pa@Xerox.COM Subject: PCL/CLOS Message-Id: <880811-065801-2207@Xerox> What is the current version of PCL/CLOS, and what machines has it been ported to? Thanks in advance Graeme From Owners-CommonLoops.pa@Xerox.COM Thu Aug 11 10:27:06 1988 Received: from Xerox.COM by arisia.Xerox.COM (4.0/SMI-DDN) id AA16741; Thu, 11 Aug 88 10:27:06 PDT Received: from Chardonnay.ms by ArpaGateway.ms ; 11 AUG 88 10:25:55 PDT Return-Path: Redistributed: CommonLoops.pa Received: from Think.COM ([10.4.0.6]) by Xerox.COM ; 11 AUG 88 10:24:16 PDT Received: from fafnir.think.com by Think.COM; Thu, 11 Aug 88 13:25:20 EDT Received: from Think.COM by fafnir.think.com; Thu, 11 Aug 88 13:19:30 EDT Return-Path: Received: from Xerox.COM by Think.COM; Thu, 11 Aug 88 13:24:56 EDT Received: from Semillon.ms by ArpaGateway.ms ; 11 AUG 88 10:18:52 PDT Date: Thu, 11 Aug 88 10:16 PDT From: Gregor.pa@Xerox.COM Subject: Re: (DEFMETHOD (setf foo) ... doesn't work To: salem@Think.COM Cc: commonloops@Think.COM Fcc: BD:>Gregor>mail>outgoing-mail-3.text.newest In-Reply-To: <8808101912.AA11041@sauron.think.com> Message-Id: <19880811171649.7.GREGOR@PORTNOY.parc.xerox.com> Line-Fold: no Date: Wed, 10 Aug 88 15:12:36 EDT From: salem@Think.COM In the 8/2/88 version of PCL, (defmethod (setf foo) .... followed by a (setf (foo ... doesn't work because no DEFSETF has been done. This is not supported in the 8/2 release of PCL. It will be supported in the next release. A long message sent to the mailing list a couple of days ago, which you may not have received, describes this change to PCL. In any case, it was not clear to me from the CLOS spec. what the arglist should look like for SETF methods. (Documentation bug ?) The spec used to have a detailed description of this, and then it got removed I guess because it was a duplication of a cleanup proposal. At any rate, the correct form is: (defmethod (setf foo) (new-value (object class)) ..) Note that it is legal to specialize the new-value argument as well, if for some reason you want to do that. For example: (defmethod (setf foo) ((new-value number) (object class)) ..) (defmethod (setf foo) ((new-value symbol) (object class)) ..) P.S. Is this the appropriate list for both these questions ? This list is appropriate for both of these questions. ------- From Owners-CommonLoops.PA@Xerox.COM Thu Aug 11 12:10:02 1988 Received: from Xerox.COM by arisia.Xerox.COM (4.0/SMI-DDN) id AB20375; Thu, 11 Aug 88 12:10:02 PDT Received: from Cabernet.ms by ArpaGateway.ms ; 11 AUG 88 10:56:34 PDT Return-Path: Redistributed: CommonLoops.PA Received: from VANCOUVER.SLISP.CS.CMU.EDU ([128.2.222.25]) by Xerox.COM ; 11 AUG 88 10:52:13 PDT Received: from VANCOUVER.SLISP.CS.CMU.EDU by VANCOUVER.SLISP.CS.CMU.EDU; 11 Aug 88 13:51:24 EDT To: CommonLoops.PA@Xerox.COM Subject: Bug in vector.lisp Date: Thu, 11 Aug 88 13:51:10 EDT From: David.McDonald@WB1.CS.CMU.EDU Message-Id: <880811-105634-2692@Xerox> There is a bug in loopup-pv-2 in vector.lisp. The then part of the if: (aref cache (%+ offset 4)) should be changed to: (aref cache (%+ offset 3)) Otherwise, if there are two cache entries adjacent to one another and the first one is accessed, the result will be the isl of the second one and not the correct permutation vector for the first one. - David. From Owners-CommonLoops.pa@Xerox.COM Thu Aug 11 14:13:19 1988 Received: from Xerox.COM by arisia.Xerox.COM (4.0/SMI-DDN) id AB21061; Thu, 11 Aug 88 14:13:19 PDT Received: from Cabernet.ms by ArpaGateway.ms ; 11 AUG 88 12:58:43 PDT Return-Path: Redistributed: CommonLoops.pa Received: from PEBBLES.BBN.COM ([128.89.1.5]) by Xerox.COM ; 11 AUG 88 12:57:13 PDT To: CommonLoops.pa@Xerox.COM Cc: kanderson@PEBBLES.BBN.COM Subject: 2 problems with add-lexical-functions-to-method-lambda Date: Thu, 11 Aug 88 15:46:53 -0400 From: kanderso@PEBBLES.BBN.COM Message-Id: <880811-125843-2988@Xerox> ;;; -*- Package: PCL -*- In PCL 8/2/88: Two problems with ADD-LEXICAL-FUNCTIONS-TO-METHOD-LAMBDA: 1. &AUX variables are not handled properly in the second COND clause: (macroexpand '(defmethod method-1 ((a c) &aux l) (setq l (list a)) (call-next-method) (print l))) (TOP-LEVEL-FORM (METHOD METHOD-1 (C)) (COMPILE LOAD EVAL) (PROGN (PROGN ; EXTRA PROGN (LOAD-DEFMETHOD 'STANDARD-METHOD 'METHOD-1 'NIL '(C) '(A &AUX L) 'NIL 'NIL '(:NEEDS-NEXT-METHODS-P T) #'(LAMBDA (#:A &AUX L) (LET ((.NEXT-METHOD. (CAR *NEXT-METHODS*)) (*NEXT-METHODS* (CDR *NEXT-METHODS*))) (FLET ((CALL-NEXT-METHOD (&REST CNM-ARGS) (IF CNM-ARGS (APPLY .NEXT-METHOD. CNM-ARGS) (FUNCALL .NEXT-METHOD. #:A &AUX L)))) ; WRONG (LET ((A #:A) (L L)) (DECLARE (CLASS A C)) (PROGN A) (BLOCK METHOD-1 (SETQ L (LIST A)) (CALL-NEXT-METHOD) (PRINT L)))))))))) 2. Only the first cond clause generates a CALL-NEXT-METHOD that errors if there is no next method. The others simply FUNCALL NIL. For example macroexpand these 2 cases: (defmethod method-1 ((a c)) ; Errors correctly (call-next-method a)) (defmethod method-1 ((a c)) ; Funcalls NIL (call-next-method)) From Gregor.pa@Xerox.COM Thu Aug 11 15:44:57 1988 Return-Path: Received: from Xerox.COM by arisia.Xerox.COM (4.0/SMI-DDN) id AA21642; Thu, 11 Aug 88 15:44:57 PDT Received: from Semillon.ms by ArpaGateway.ms ; 11 AUG 88 13:12:26 PDT Date: Thu, 11 Aug 88 13:08 PDT From: Gregor.pa@Xerox.COM Subject: Re: Bug in vector.lisp To: David.McDonald@WB1.CS.CMU.EDU Cc: CommonLoops.PA@Xerox.COM Fcc: BD:>Gregor>mail>outgoing-mail-3.text.newest In-Reply-To: The message of 11 Aug 88 10:51 PDT from David.McDonald@WB1.CS.CMU.EDU Message-Id: <19880811200839.0.GREGOR@PORTNOY.parc.xerox.com> Line-Fold: no Date: Thu, 11 Aug 88 13:51:10 EDT From: David.McDonald@WB1.CS.CMU.EDU There is a bug in loopup-pv-2 in vector.lisp. The then part of the if: (aref cache (%+ offset 4)) should be changed to: (aref cache (%+ offset 3)) Yikes, this is a bad bug. I have fixed this in the version of vector on arisia.xerox.com. Anyone using the latest PCL should either FTP a new version of vector, or make this patch to the version they have. Thanks for this fix. ;from vector.lisp (defun lookup-pv-2 (isl w0 i0 w1 i1) (let* ((cache *pv-cache-2*) (mask *pv-cache-2-mask*) (offset (%logand mask (%logxor (object-cache-no isl mask) (validate-wrapper i0 w0) (validate-wrapper i1 w1))))) (without-interrupts (if (and (eq (%svref cache offset) isl) (eq (%svref cache (%1+ offset)) w0) (eq (%svref cache (%+ offset 2)) w1)) (aref cache (%+ offset 3)) (let ((pv (with-interrupts (lookup-pv-miss isl w0 w1)))) (setf (%svref cache offset) isl) (setf (%svref cache (%1+ offset)) w0) (setf (%svref cache (%+ offset 2)) w1) (setf (%svref cache (%+ offset 3)) pv)))))) ------- From Gregor.pa@Xerox.COM Thu Aug 11 17:36:45 1988 Return-Path: Received: from Xerox.COM by arisia.Xerox.COM (4.0/SMI-DDN) id AB22337; Thu, 11 Aug 88 17:36:45 PDT Received: from Semillon.ms by ArpaGateway.ms ; 11 AUG 88 14:38:15 PDT Date: Thu, 11 Aug 88 14:33 PDT From: Gregor.pa@Xerox.COM Subject: CLOS workshop To: Common-Lisp@Sail.Stanford.edu, CommonLoops.pa@Xerox.COM, X3J13@Sail.Stanford.edu Fcc: BD:>Gregor>mail>outgoing-mail-3.text.newest Message-Id: <19880811213330.2.GREGOR@PORTNOY.parc.xerox.com> Line-Fold: no This is the second announcement of the CLOS workshop to be held at PARC October 3rd and 4th. This is a reminder to help us with our planning by letting us know soon if you are planning to attend. My apologies to people who receive multiple copies of this message. To clarify the position paper requirement, the workshop is not limited exclusively to those who have extensive experience writing CLOS code. Anyone planning CLOS implementations, extensions, environments or CLOS based application development is encouraged to attend. A position paper can simply be a description of the kinds of issues you feel should the CLOS community should address at the workshop. Workshop for CLOS Users and Implementors October 3rd and 4th Xerox PARC Palo Alto, California We have been excited by the extent to which CLOS is already being used, and the ways in which it is being extended. The purpose of this workshop is to provide an opportunity for the members of the CLOS community to get together and share their experience. To provide a good start for the interchange, we are requesting that participants supply a short position paper (1-3 pages) describing work related to CLOS. Some topics of interest are: Applications Programming Techniques Implementation Programming Environment Tools Extensions of CLOS Techniques for Converting to CLOS Meta Object Techniques and Theory Critiques We will try to support demonstrations or videotapes of applications, programming environments, implementations or other relevant systems. If you are planning to attend, please let us know by August 15th. This will help us with planning and allow us to arrange a discount rate at a local hotel. Position papers should reach us by September 9th so that we can organize a program and arrange for duplication of the papers. Position papers, notice to attend, and other correspondence should be sent to: Gregor Kiczales 3333 Coyote Hill Rd. Palo Alto, CA 94304 or by Internet mail to: Gregor.pa@Xerox.com ------- From Owners-CommonLoops.PA@Xerox.COM Fri Aug 12 12:09:27 1988 Received: from Xerox.COM by arisia.Xerox.COM (4.0/SMI-DDN) id AB25749; Fri, 12 Aug 88 12:09:27 PDT Received: from Salvador.ms by ArpaGateway.ms ; 12 AUG 88 12:06:53 PDT Return-Path: Redistributed: CommonLoops.PA Received: from vaxa.isi.edu ([128.9.0.33]) by Xerox.COM ; 12 AUG 88 12:05:47 PDT Posted-Date: Fri, 12 Aug 88 12:07:05 PDT Message-Id: <8808121907.AA13070@vaxa.isi.edu> Received: from LOCALHOST by vaxa.isi.edu (5.54/5.51) id AA13070; Fri, 12 Aug 88 12:07:08 PDT To: Gregor.pa@Xerox.COM Cc: CommonLoops.PA@Xerox.COM Subject: Dynamic Slots Date: Fri, 12 Aug 88 12:07:05 PDT From: macgreg@vaxa.isi.edu Gregor, In reply to your request for input, this note describes our usage of dynamic slots in PCL. In our application of PCL we set the allocation of our slots to :dynamic rather than :instance whenver we estimate that each of the corresponding slot variables has a greater than 75% change of never being assigned a value. Almost half of our slots are dynamic. We don't use any features particularized for dynamic slots except the :dynamic option. There is one caveat -- although our dynamic slot variables are usually never assigned a value, we do read them every so often. If reading an unassigned dynamic slot variable would cause it to allocate space, then we lose, and hence derive no benefit from the dynamic slot mechanism. In the St. Patrick's Day release of PCL, a bug? prevented allocating dynamic slots without also specifying an :initform option. This restriction rendered dynamic slots useless for our application, since a read triggers the :initfunction, which then allocates space for the slot variable. We are hoping that a later release will lift this restriction. We appreciate that you will be continuing to support the :dynamic option. From Owners-commonloops.pa@Xerox.COM Fri Aug 12 17:15:21 1988 Received: from Xerox.COM by arisia.Xerox.COM (4.0/SMI-DDN) id AB27510; Fri, 12 Aug 88 17:15:21 PDT Received: from Semillon.ms by ArpaGateway.ms ; 12 AUG 88 17:07:14 PDT Return-Path: Redistributed: commonloops.pa Received: from moon.src.honeywell.com ([129.30.1.10]) by Xerox.COM ; 12 AUG 88 17:05:31 PDT Return-Path: Received: from pavo.SRC.Honeywell.COM by moon.src.honeywell.com (5.59/smail2.1/05-12-87) id AA21609; Fri, 12 Aug 88 19:02:55 CDT Posted-Date: Fri, 12 Aug 88 19:01:22 CDT Received: by pavo.src.honeywell.com (3.2/SMI-3.2) id AA13744; Fri, 12 Aug 88 19:01:22 CDT Date: Fri, 12 Aug 88 19:01:22 CDT From: alarson@src.honeywell.com (Aaron Larson) Message-Id: <8808130001.AA13744@pavo.src.honeywell.com> To: commonloops.pa@Xerox.COM Subject: who makes class-prototype Is the class prototype created by calling allocate-instance? According to the documentation of class-prototype on pg 3-17 of the march spec: class-prototype The value of this reader is an instance of the class. ... Remarks: This instance may be a completely blank instance as created by allocate-instance ... The only thing guaranteed about this instance is that it will respond properly to class-of and will select a method specialized on this class or any subclass. It is not specified when this instance is created... Like several other people of late, I've created a meta class that does something special for allocate-instance. It is important that I know if the current call is to create a "real" instance, or the prototype. If it is permitted/expected that allocate-instance will create the prototype, how do I tell if the current call is creating the instance? It appears that the sentence about "It is not specified when" explicitly precludes me from assuming that I can use class-finalized-p or class-initialized-p for this purpose. If it is not permitted/expected that allocate-instance will create the prototype, then several allocate-instance methods in pcl need to be changed. From Owners-commonloops.pa@Xerox.COM Sun Aug 14 18:12:35 1988 Received: from Xerox.COM by arisia.Xerox.COM (4.0/SMI-DDN) id AA04766; Sun, 14 Aug 88 18:12:35 PDT Received: from Cabernet.ms by ArpaGateway.ms ; 14 AUG 88 18:13:49 PDT Return-Path: <@LEGAL-SEAFORD.BBN.COM:cerys@bbn.com> Redistributed: commonloops.pa Received: from VAX.BBN.COM ([128.89.0.91]) by Xerox.COM ; 14 AUG 88 18:12:09 PDT Received: from legal-seaford.bbn.com by VAX.BBN.COM id aa05443; 14 Aug 88 21:01 EDT Message-Id: <2796598562-1182548@LEGAL-SEAFOOD> Sender: cerys@legal-seafood.ARPA Date: Sun, 14 Aug 88 20:56:02 EDT From: Daniel Cerys To: Vaughan Johnson Cc: commonloops.pa@Xerox.COM Subject: Re: #+lispm bugs In-Reply-To: Msg of Tue, 9 Aug 88 16:30:19 PDT from Vaughan Johnson The recent bug with the definition of the pcl::generic-clobbers-function error condition was correct in identifying a problem, but the fix was incomplete. Both the Explorer and 36XX machines support error handling of this type, albeit a little differently. To further confuse the matter, the new Symbolics syntax for flavor methods is different from the old syntax that TI uses. So, the following fixes add the support of the pcl::generic-clobbers-function condition for both machines. Note that it is appropriate to use #+LISPM in some cases. ;;;From boot.lisp #+Lispm ;For both #+Symbolics and #+TI (zl:defflavor generic-clobbers-function (name) (si:error) :initable-instance-variables) #+Lispm ;The only difference here between TI and Symbolics is the method spec (zl:defmethod #+symbolics (dbg:report generic-clobbers-function) #+ti (generic-clobbers-function :report) (stream) (format stream "~S aready names a ~a" name (if (and (symbolp name) (macro-function name)) "macro" "function"))) #+Symbolics (zl:defmethod (sys:proceed generic-clobbers-function :specialize-it) () "Make it specializable anyway?" (make-specializable name)) #+ti (zl:defmethod (generic-clobbers-function :case :proceed-asking-user :specialize-it) (continuation ignore) "Make it specializable anyway?" (make-specializable name) (funcall continuation :specialize-it)) (defun ensure-generic-function (spec &rest keys &key lambda-list argument-precedence-order declarations documentation method-combination generic-function-class method-class) (declare (ignore lambda-list argument-precedence-order declarations documentation method-combination method-class)) (let ((existing (and (gboundp spec) (gdefinition spec)))) (cond ((null existing) (let ((new (apply #'ensure-gf-internal spec keys))) (setq new (set-function-name new spec)) (setf (gdefinition spec) new))) ((funcallable-instance-p existing) existing) (existing #+Lispm (zl:signal 'generic-clobbers-function :name spec) #-Lispm (error "~S already names an ordinary function or a macro,~%~ it can't be converted to a generic function." spec))))) From Owners-CommonLoops.pa@Xerox.COM Mon Aug 15 13:15:34 1988 Received: from Xerox.COM by arisia.Xerox.COM (4.0/SMI-DDN) id AA08297; Mon, 15 Aug 88 13:15:34 PDT Received: from Cabernet.ms by ArpaGateway.ms ; 15 AUG 88 13:10:04 PDT Return-Path: Redistributed: CommonLoops.pa Received: from arisia.Xerox.COM ([13.1.100.206]) by Xerox.COM ; 15 AUG 88 08:40:36 PDT Received: from hi-csc.honeywell.com ([192.12.237.29]) by arisia.Xerox.COM (4.0/SMI-DDN) id AA06303; Mon, 15 Aug 88 08:36:28 PDT Received: by hi-csc.honeywell.com (4.12/BSD4.2) id AA02224; Mon, 15 Aug 88 10:51:52 cdt Date: Mon, 15 Aug 88 10:51:52 cdt From: Kurt D. Krebsbach <"krebsbach@hi-csc.honeywell.com"@hi-csc.honeywell.com> Message-Id: <8808151551.AA02224@hi-csc.honeywell.com> To: CommonLoops.pa@hi-csc.honeywell.com Subject: non-beta release Has the non-beta release of the newest PCL come out yet? If not, when, and if so, how can one procure it? From Owners-commonloops.pa@Xerox.COM Mon Aug 15 14:59:04 1988 Received: from Xerox.COM by arisia.Xerox.COM (4.0/SMI-DDN) id AB08895; Mon, 15 Aug 88 14:59:04 PDT Received: from Chardonnay.ms by ArpaGateway.ms ; 15 AUG 88 14:54:00 PDT Return-Path: Redistributed: commonloops.pa Received: from PEBBLES.BBN.COM ([128.89.1.5]) by Xerox.COM ; 15 AUG 88 12:02:54 PDT To: Aaron Larson Cc: commonloops.pa@Xerox.COM Subject: Re: who makes class-prototype In-Reply-To: Your message of Fri, 12 Aug 88 19:01:22 -0500. <8808130001.AA13744@pavo.src.honeywell.com> Date: Mon, 15 Aug 88 15:00:27 -0400 From: kanderso@PEBBLES.BBN.COM Message-Id: <880815-145400-1446@Xerox> The purpose of the class-prototype of a class is to act as a prototypical instance. This is typically used at the Meta PCL level. For example, DEFCLASS and friends use the CLASS-PROTOTYPE of the metaclass of the class being defined. (Could/should a metaclass use itself as its prototype?) Make-instance (or MKI in PCL) makes a new fresh (non EQ to anything else) instance. This is what one should normally use for creating instances. Perhaps CLOS, like other specs is a bit weak on how the pieces of the puzzle are expected to fit together. Hope this helps. k From Owners-CommonLoops.pa@Xerox.COM Mon Aug 15 16:25:48 1988 Received: from Xerox.COM by arisia.Xerox.COM (4.0/SMI-DDN) id AB09884; Mon, 15 Aug 88 16:25:48 PDT Received: from Salvador.ms by ArpaGateway.ms ; 15 AUG 88 14:57:41 PDT Return-Path: Redistributed: CommonLoops.pa Received: from arisia.Xerox.COM ([13.1.100.206]) by Xerox.COM ; 15 AUG 88 12:25:38 PDT Received: from hi-csc.honeywell.com ([192.12.237.29]) by arisia.Xerox.COM (4.0/SMI-DDN) id AA07937; Mon, 15 Aug 88 12:21:29 PDT Received: by hi-csc.honeywell.com (4.12/BSD4.2) id AA02303; Mon, 15 Aug 88 14:36:52 cdt Date: Mon, 15 Aug 88 14:36:52 cdt From: Kurt D. Krebsbach <"krebsbach@hi-csc.honeywell.com"@hi-csc.honeywell.com> Message-Id: <8808151936.AA02303@hi-csc.honeywell.com> To: 1@hi-csc.honeywell.com, CommonLoops.pa@hi-csc.honeywell.com Subject: iteration bug From Owners-CommonLoops.pa@Xerox.COM Mon Aug 15 18:34:10 1988 Received: from Xerox.COM by arisia.Xerox.COM (4.0/SMI-DDN) id AA11030; Mon, 15 Aug 88 18:34:10 PDT Received: from Chardonnay.ms by ArpaGateway.ms ; 15 AUG 88 15:02:18 PDT Return-Path: Redistributed: CommonLoops.pa Received: from arisia.Xerox.COM ([13.1.100.206]) by Xerox.COM ; 15 AUG 88 12:27:56 PDT Received: from hi-csc.honeywell.com ([192.12.237.29]) by arisia.Xerox.COM (4.0/SMI-DDN) id AA07941; Mon, 15 Aug 88 12:23:46 PDT Received: by hi-csc.honeywell.com (4.12/BSD4.2) id AA02313; Mon, 15 Aug 88 14:39:10 cdt Date: Mon, 15 Aug 88 14:39:10 cdt From: Kurt D. Krebsbach <"krebsbach@hi-csc.honeywell.com"@hi-csc.honeywell.com> Message-Id: <8808151939.AA02313@hi-csc.honeywell.com> To: CommonLoops.pa@hi-csc.honeywell.com I've been having a hard time trying to compile the file iterate.lisp on a Symbolics under Genera 7.1. This has happened exactly the same way when trying to compile both the 7/7/88 release, and the 8/2/release. Here's the error I get: For function OPTIMIZE-ITERATE-FORM While compiling (SETQ V (PROG1 (CAR #:G9593) (SETQ #:G9593 (CDR #:G9593)))) The ignored variable V was referenced. Error: The second argument (VALUE) to SYS:SIGNED-IMMEDIATE-OPERAND, 231, was of the wrong type. The function expected a small signed operand. SYS:SIGNED-IMMEDIATE-OPERAND: ARG0: (COMPILER:OPCODE): 67 ARG1: (COMPILER:VALUE): 231 Please let me know what's going on as soon as possible, as I believe this is the only problem keeping us from getting post-St. Patrick's day versions up and running. Thanks, Kurt Krebsbach From Owners-commonloops.PA@Xerox.COM Mon Aug 15 19:24:36 1988 Received: from Xerox.COM by arisia.Xerox.COM (4.0/SMI-DDN) id AB11074; Mon, 15 Aug 88 19:24:36 PDT Received: from Salvador.ms by ArpaGateway.ms ; 15 AUG 88 17:20:35 PDT Return-Path: Redistributed: commonloops.PA Received: from neptune.CS.UCLA.EDU ([128.97.28.9]) by Xerox.COM ; 15 AUG 88 16:33:02 PDT Return-Path: Received: by neptune.CS.UCLA.EDU (Sendmail 5.54/2.07) id AA03419; Mon, 15 Aug 88 16:31:02 PDT Message-Id: <8808152331.AA03419@neptune.CS.UCLA.EDU> To: commonloops.PA@Xerox.COM Subject: problem in initialize-instance Date: Mon, 15 Aug 88 16:30:59 PDT From: poman@CS.UCLA.EDU There is a problem in compiling auxilliary methods defined for initialize- instance. Compilation will bomb with the error of calling the compiler recursively. The following is the example that I worked on : (defclass ppname (name) ((whole-name :accessor glue-name))) (defmethod initialize-instance :after ((cname ppname)) (format t " whole name is :~a ~%" (glue-name cname ))) I would appreciate any information about fixing the bug. Thank you. Richard Leung UCLA computer science dept From Owners-commonloops.pa@Xerox.COM Tue Aug 16 09:08:01 1988 Received: from Xerox.COM by arisia.Xerox.COM (4.0/SMI-DDN) id AA13254; Tue, 16 Aug 88 09:08:01 PDT Received: from Burger.ms by ArpaGateway.ms ; 16 AUG 88 08:58:11 PDT Return-Path: Redistributed: commonloops.pa Received: from uunet.UU.NET ([192.12.141.129]) by Xerox.COM ; 16 AUG 88 08:57:10 PDT Received: from unido.UUCP by uunet.UU.NET (5.59/1.14) with UUCP id AA07962; Tue, 16 Aug 88 11:56:19 EDT From: unido!sbsvax!fb10vax.sbsvax!roman@uunet.UU.NET Received: by unido.uucp with uucp; Tue, 16 Aug 88 16:36:47 +0100 Received: by sbsvax.uucp; Tue, 16 Aug 88 17:19:05 +0200 (MET dst) Message-Id: <8808161519.AA11923@fb10vax.sbsvax.uucp> Received: by fb10vax.sbsvax.uucp; Tue, 16 Aug 88 17:19:03 +0200 (MET dst) To: commonloops.pa@Xerox.COM Subject: Missing Functions for HP Common Lisp Return-Receipt-To: unido!sbsvax!fb10vax.informatik.uni-saarland.dbp.de!roman@uunet.UU.NET Date: Tue, 16 Aug 88 17:19:02 N In the last version of PCL (8/2/88) their were no HP Common Lisp definitions for the 'environment hacking tools' WITH-AUGMENTED-ENVIRONMENT, ENVIRONMENT-FUNCTION and ENVIRONMENT-MACRO. They should be defined in the code walker WALK.LISP. Can anybody provide me with these parts of PCL for HP Common Lisp. Thanks in advance Roman M. Jansen-Winkeln roman%fb10vax.informatik.uni-saarland.dbp.de@relay.cs.net roman%sbsvax.uucp@unido.uucp From Gregor.pa@Xerox.COM Tue Aug 16 10:34:11 1988 Return-Path: Received: from Xerox.COM by arisia.Xerox.COM (4.0/SMI-DDN) id AB13910; Tue, 16 Aug 88 10:34:11 PDT Received: from Semillon.ms by ArpaGateway.ms ; 16 AUG 88 10:37:55 PDT Date: Tue, 16 Aug 88 10:33 PDT From: Gregor.pa@Xerox.COM Subject: Re: problem in initialize-instance To: poman@CS.UCLA.EDU Cc: commonloops.PA@Xerox.COM Fcc: BD:>Gregor>mail>outgoing-mail-3.text.newest In-Reply-To: <8808152331.AA03419@neptune.CS.UCLA.EDU> Message-Id: <19880816173326.0.GREGOR@PORTNOY.parc.xerox.com> Line-Fold: no Date: Mon, 15 Aug 88 16:30:59 PDT From: poman@CS.UCLA.EDU There is a problem in compiling auxilliary methods defined for initialize- instance. Compilation will bomb with the error of calling the compiler recursively. The following is the example that I worked on : (defclass ppname (name) ((whole-name :accessor glue-name))) (defmethod initialize-instance :after ((cname ppname)) (format t " whole name is :~a ~%" (glue-name cname ))) I would appreciate any information about fixing the bug. You don't say, but this must be in KCL. As you say, the problem here is that the KCL compiler isn't reentrant. I have it on my list of things to do to teach PCL about an elegant way to deal with non reentrant compilers, but it is pretty low priority right now. Here is a way you can get around this problem. Before attempting to compile your program, first simple load it interpreted. Then compile your program. The last file compiled in your program should contain the line: (pcl::precompile-random-code-segments) Whenever you subsequently compile or load your program, that file should be loaded first. It must be compiled last and loaded first. This will have the effect of precompiling all the special code segments your program seems to need. Sometimes during the life of your program, you will add something to it that will require a new special code segment. This may require you to first load that part of the program interpreted, then compile it. As I said, this will be fixed in PCL someday, although a much more elegant fix would be to make the KCL compiler reentrant. ------- From Gregor.pa@Xerox.COM Tue Aug 16 15:05:45 1988 Return-Path: Received: from Xerox.COM by arisia.Xerox.COM (4.0/SMI-DDN) id AA16060; Tue, 16 Aug 88 15:05:45 PDT Received: from Semillon.ms by ArpaGateway.ms ; 16 AUG 88 15:01:11 PDT Date: Tue, 16 Aug 88 14:54 PDT From: Gregor.pa@Xerox.COM Subject: iterate in Genera 7.1 To: Kurt D. Krebsbach Cc: CommonLoops.pa@Xerox.COM Fcc: BD:>Gregor>mail>outgoing-mail-3.text.newest In-Reply-To: <8808151939.AA02313@hi-csc.honeywell.com> Message-Id: <19880816215404.5.GREGOR@PORTNOY.parc.xerox.com> Line-Fold: no Date: Mon, 15 Aug 88 14:39:10 cdt From: Kurt D. Krebsbach <"krebsbach@hi-csc.honeywell.com"@hi-csc.honeywell.com> I've been having a hard time trying to compile the file iterate.lisp on a Symbolics under Genera 7.1. This has happened exactly the same way when trying to compile both the 7/7/88 release, and the 8/2/ release. There is a new version of the file iterate.lisp on arisia.xerox.com which corrects this problem. Either FTP the new version, or make the following patch to your version: ;from iterate.lisp (defun optimize-iterate-form (type clauses body iterate-env) (let* ((temp-vars *iterate-temp-vars-list*) (block-name (gensym)) (finish-form `(return-from ,block-name)) (bound-vars (mapcan #'(lambda (clause) (let ((names (first clause))) (if (listp names) (copy-list names) (list names)))) clauses)) iterate-decls generator-decls update-forms bindings final-bindings leftover-body) (do ((tail bound-vars (cdr tail))) ((null tail)) ; check for duplicates (when (member (car tail) (cdr tail)) (warn "variable appears more than once in iterate: ~s" (car tail)))) (flet ((get-iterate-temp nil ; make temporary var. note ; that it is ok to re-use these ; symbols in each iterate, ; because they are not used ; within body. (or (pop temp-vars) (gensym)))) (dolist (clause clauses) (cond ((or (not (consp clause)) (not (consp (cdr clause)))) (warn "bad syntax in iterate: clause not of form (var iterator): ~s" clause)) (t (unless (null (cddr clause)) (warn "probable parenthesis error in iterate clause--more than 2 elements: ~s" clause)) (multiple-value-bind (let-body binding-type let-bindings localdecls otherdecls extra-body) (expand-into-let (second clause) type iterate-env) ;; we have expanded the generator clause and parsed it into its ;; let pieces. (prog* ((vars (first clause)) gen-args renamed-vars) (block punt1 (setq vars (if (listp vars) (copy-list vars) (list vars))) ; vars is now a (fresh) list of ; all iteration vars bound in ; this clause (when (setq let-body (function-lambda-p let-body 1)) ;; we have something of the form #'(lambda ;; (finisharg) ...), possibly with some let bindings ;; around it. (setq let-body (cdr let-body)) (setq gen-args (pop let-body)) (when let-bindings ;; the first transformation we want to perform is ;; "let-eversion": turn (let* ((generator (let ;; (..bindings..) #'(lambda ...)))) ..body..) into ;; (let* (..bindings.. (generator #'(lambda ...))) ;; ..body..). this transformation is valid if ;; nothing in body refers to any of the bindings, ;; something we can assure by alpha-converting the ;; inner let (substituting new names for each var). ;; of course, none of those vars can be special, but ;; we already checked for that above. (multiple-value-setq (let-bindings renamed-vars) (rename-let-bindings let-bindings binding-type iterate-env leftover-body #'get-iterate-temp)) (setq leftover-body nil) ; if there was any leftover ; from previous, it is now ; consumed ) (let ((finish-arg (first gen-args))) ;; the second transformation is substituting the ;; body of the generator (lambda (finish-arg) . ;; gen-body) for its appearance in the update form ;; (funcall generator #'(lambda () finish-form)), ;; then simplifying that form. the requirement for ;; this part is that the generator body not refer to ;; any variables that are bound between the ;; generator binding and the appearance in the loop ;; body. the only variables bound in that interval ;; are generator temporaries, which have unique ;; names so are no problem, and the iteration ;; variables themselves: all of them in the case of ;; iterate, only the remaining ones in the case of ;; iterate*. we'll discover the story as we walk ;; the body. (multiple-value-bind (finishdecl other rest) (parse-declarations let-body gen-args) (declare (ignore finishdecl)) ; pull out declares, if any, ; separating out the one(s) ; referring to the finish arg, ; which we will throw away (when other ; combine remaining decls with ; decls extracted from the let, ; if any (setq otherdecls (nconc otherdecls other))) (setq let-body (cond (otherdecls ; there are interesting ; declarations, so have to keep ; it wrapped. `(let nil (declare ,@otherdecls) ,@rest)) ((null (cdr rest)) ; only one form left (first rest))))) (setq let-body (walk-form let-body iterate-env #'(lambda (form context env) (declare (ignore context)) ;; need to substitute renamed-vars, as well as ;; turn (funcall finish-arg) into the finish ;; form (cond ((symbolp form) (let (renaming) (cond ((and (eq form finish-arg) (variable-same-p form env iterate-env)) ; an occurrence of the finish ; arg outside of funcall ; context--i can't handle this (maybe-warn :definition "couldn't optimize ~s because generator ~s does something with its finish arg besides funcall it." type (second clause)) ;(go punt) (return-from punt1 nil) ) ((and (setq renaming (assoc form renamed-vars )) (variable-same-p form env iterate-env)) ; reference to one of the vars ; we're renaming (cdr renaming)) ((and (member form bound-vars) (variable-same-p form env iterate-env)) ; form is a var that is bound ; in this same iterate, or ; bound later in this iterate*. ; this is a conflict. (maybe-warn :user "couldn't optimize ~s because generator ~s is closed over ~s, in conflict with another iteration variable.~@[ you may have meant to use iterate*~]" type (second clause) form (eq type 'iterate)) ;(go punt) (return-from punt1 nil) ) (t form)))) ((and (consp form) (eq (first form) 'funcall) (eq (second form) finish-arg) (variable-same-p (second form) env iterate-env)) ; (funcall finish-arg) => ; finish-form (unless (null (cddr form)) (maybe-warn :definition "generator for ~s applied its finish arg to > 0 arguments ~s--ignored." (second clause) (cddr form))) finish-form) (t form))))) ;; gen-body is now a form which, when evaluated, ;; returns updated values for the iteration ;; variable(s) (push (mv-setq (copy-list vars) let-body) update-forms) ;; note possible further optimization: if the above ;; expanded into (setq var (prog1 oldvalue ;; prepare-for-next-iteration)), as so many do, then ;; we could in most cases split the prog1 into two ;; pieces: do the (setq var oldvalue) here, and do ;; the prepare-for-next-iteration at the bottom of ;; the loop. this does a slight optimization of the ;; prog1 and also rearranges the code in a way that ;; a reasonably clever compiler might detect how to ;; get rid of redundant variables altogether (such ;; as happens with interval and list-tails); that ;; would make the whole thing closer to what you ;; might have coded by hand. however, to do this ;; optimization, we need to assure that (a) the ;; prepare-for-next-iteration refers freely to no ;; vars other than the internal vars we have ;; extracted from the let, and (b) that the code has ;; no side effects. these are both true for all the ;; iterators defined by this module, but how shall ;; we represent side-effect info and/or tap into the ;; compiler's knowledge of same? (when localdecls ; there were declarations for ; the generator locals--have to ; keep them for later, and ; rename the vars mentioned (setq generator-decls (nconc generator-decls (mapcar #'(lambda (decl) (let ((head (car decl))) (cons head (if (eq head 'type) (cons (second decl) (sublis renamed-vars (cddr decl))) (sublis renamed-vars (cdr decl)))))) localdecls)))) (go finish-clause))) (maybe-warn :definition "could not optimize ~s clause ~s because generator not of form (let[*] ... (function (lambda (finish) ...)))" type (second clause)) );end of block punt1 punt (let ((gvar (get-iterate-temp)) (generator (second clause))) ;; for some reason, we can't expand this guy, so go with ;; the formal semantics: bind a var to the generator, ;; then call it in the update section (setq let-bindings (list (list gvar (cond (leftover-body; have to use this up `(progn ,@(prog1 leftover-body (setq leftover-body nil)) generator)) (t generator))))) (push (mv-setq (copy-list vars) `(funcall ,gvar #'(lambda nil ,finish-form)) ) update-forms)) finish-clause (case type (iterate ; for iterate, don't bind any ; iv's until all exprs are ; evaluated, so defer this (setq final-bindings (nconc final-bindings vars)) (setq vars nil) (when extra-body ; have to save this for next ; clause, too (setq leftover-body (nconc leftover-body extra-body)) (setq extra-body nil))) (iterate* ; pop off the vars we have now ; bound from the list of vars ; to watch out for--we'll bind ; them right now (dolist (v vars) #-Genera (declare (ignore v)) (pop bound-vars)))) (setq bindings (nconc bindings let-bindings (cond (extra-body ; there was some computation to ; do after the bindings--here's ; our chance (cons (list (first vars) `(progn ,@extra-body nil)) (rest vars))) (t vars)))))))))) (do ((tail body (cdr tail))) ((not (and (consp tail) (consp (car tail)) (eq (caar tail) 'declare))) ; tail now points at first ; non-declaration. if there ; were declarations, pop them ; off so they appear in the ; right place (unless (eq tail body) (setq iterate-decls (ldiff body tail)) (setq body tail)))) `(block ,block-name (let* ,(append bindings final-bindings) ,@(and generator-decls `((declare ,@generator-decls))) ,@iterate-decls ,@leftover-body (loop ,@(nreverse update-forms) ,@body))))) ------- From Gregor.pa@Xerox.COM Tue Aug 16 16:02:12 1988 Return-Path: Received: from Xerox.COM by arisia.Xerox.COM (4.0/SMI-DDN) id AB17276; Tue, 16 Aug 88 16:02:12 PDT Received: from Semillon.ms by ArpaGateway.ms ; 16 AUG 88 15:55:58 PDT Date: Tue, 16 Aug 88 15:51 PDT From: Gregor.pa@Xerox.COM Subject: changes to slot access To: CommonLoops.pa@Xerox.COM Fcc: BD:>Gregor>mail>outgoing-mail-3.text.newest Message-Id: <19880816225120.6.GREGOR@PORTNOY.parc.xerox.com> Line-Fold: no The next release of PCL is gearing up to be a good one. Good in the sense that we will be making significant progress towards conforming with the CLOS specification (88-002R). In addition to the previously announced changes related to setf generic functions, this release will include a number of changes related to the way slot access works. This message gives some advance description of these changes. The information in this message will be repeated in the release notes, but I suggest you spend some time reading it now. We are currently in the process of testing the changes we made (hard to believe isn't it), I expect the actual release will be sometime in the next couple of days. Some of the changes described in this message are incompatible. The old behavior of some of the slot access functions has changed incompatibly. Code which was written with the actual CLOS spec in mind should not be affected by these incompatible changes, but some older code may be affected. The basic thrust of the changes to slot access is to bring the following functions and generic functions in line with the specification: slot-boundp slot-exists-p slot-makunbound slot-missing slot-unbound slot-value slot-boundp-using-class slot-exists-p-using-class slot-makunbound-using-class slot-value-using-class (setf slot-value) (setf slot-value-using-class) change-class make-instances-obsolete make-instance (temporarily called *make-instance) initialize-instance (temporarily called *initialize-instance) reinitialize-instance update-instance-for-different-class update-instance-for-redefined-class shared-initialize In this new release, these functions accept the specified number of arguments, return the specified values, have the specified effects, and are called by the rest of PCL in the specified way at the specified times (with the exception that PCL does not yet call *make-instance to create its own metaobjects). Because PCL now checks for unbound slots, you may notice a slight performance degradation in certain applications. For complete information, you should of course see the CLOS specification. The rest of this note is a short summary of how this new behavior is different from the last release. - Dynamic slots are no longer supported. Various functions like slot-value-always and remove-slot no longer exist. Also, slot-value-using-class now only accepts the three arguments as described in the spec. The two extra arguments having to do with dynamic slots are no longer accepted. Shortly, we will release a metaclass which provides the now missing dynamic slot behavior. - slot-missing now receives and accepts different arguments. - slot-unbound is now implemented, and is called at the appropriate times. - the metaclass obsolete-class no longer exists. The mechanism by which instances are marked as being obsolete is now internal, as described in the spec. The generic-function make-instances-obsolete can be used to force the instances of a class to go through the obsolete instance update protocol (see update-instance-for-redefined-class). - all-std-class-readers-miss-1, a generic function which was part of the database interface code I sent out a few weeks ago, has a slightly different argument list. People using the code I sent out a few weeks ago should replace the definition there with: (defmethod all-std-class-readers-miss-1 ((class db-class) wrapper slot-name) (declare (ignore wrapper slot-name)) ()) - The implementation of the slot access generic functions have been considerably streamlined. The impenetrable macrology which used to be used is now gone. - Because the behavior of the underlying slot access generic functions has changed, it is possible that some user code which hacks the underlying instance structure may break. Most of this code shouldn't break though. There have been some questions on the mailing list about what is the right way to modify the structure of an instance. I am working on that section of chapter 3 right now, and will answer those questions sometime soon. ------- From Owners-commonloops.pa@Xerox.COM Wed Aug 17 13:32:05 1988 Received: from Xerox.COM by arisia.Xerox.COM (4.0/SMI-DDN) id AB24525; Wed, 17 Aug 88 13:32:05 PDT Received: from Burger.ms by ArpaGateway.ms ; 17 AUG 88 13:28:31 PDT Return-Path: Redistributed: commonloops.pa Received: from moon.src.honeywell.com ([129.30.1.10]) by Xerox.COM ; 17 AUG 88 13:27:26 PDT Return-Path: Received: from pavo.SRC.Honeywell.COM by moon.src.honeywell.com (5.59/smail2.1/05-12-87) id AA06445; Wed, 17 Aug 88 15:24:38 CDT Posted-Date: Wed, 17 Aug 88 15:23:05 CDT Received: by pavo.src.honeywell.com (3.2/SMI-3.2) id AA21539; Wed, 17 Aug 88 15:23:05 CDT Date: Wed, 17 Aug 88 15:23:05 CDT From: alarson@src.honeywell.com (Aaron Larson) Message-Id: <8808172023.AA21539@pavo.src.honeywell.com> To: commonloops.pa@Xerox.COM Subject: Re: who makes class-prototype In-reply-to: kanderso@PEBBLES.BBN.COM's message of 16 Aug 88 00:20:12 GMT In article <7183@srcsip.UUCP> kanderso@PEBBLES.BBN.COM writes: About a month ago Gregor posted several versions of a message with subject "Re: method discrimination on persistent objects" that contained the following: ... As soon as the instances are allocated, we have to set their object-id. (defmethod allocate-instance ((class db-class)) (let ((instance (call-next-method))) (setf (slot-value instance 'object-id) (allocate-object-id)) instance)) ... The problem is knowing whether 'allocate-object-id' is called when the class-prototype instace is allocated. In my application it is imperative that it not be. Hence it is necessary that CLOS specifies that allocate-instance is not called for the class-prototpe, or that there be some canonical way for an application to determine that the current call is to make the class-prototype. The fact that both Gregor and I (independently) decided that the correct place for the call to allocate-object-id should be on allocate-instance would tend to indicate that performing this action is within the "style" presented by the spec. I realize that assigning object id's could be made part of the make-instance protocol, but I feel that would leave a hole in the system because allocate-instance is part of the defined CLOS interface, and people could justifiably call allocate-instance directly, then there would exist an object without an id. From Owners-commonloops.pa@Xerox.COM Wed Aug 17 14:27:28 1988 Received: from Xerox.COM by arisia.Xerox.COM (4.0/SMI-DDN) id AB24908; Wed, 17 Aug 88 14:27:28 PDT Received: from Salvador.ms by ArpaGateway.ms ; 17 AUG 88 13:47:03 PDT Return-Path: Redistributed: commonloops.pa Received: from SRI-ROBOTX.ARPA ([128.18.3.100]) by Xerox.COM ; 17 AUG 88 13:45:19 PDT Date: Wed, 17 Aug 88 13:41:56 PST From: Doug Ruth Subject: Latest PCL version To: commonloops.pa@Xerox.COM Message-Id: <587853716.0.RUTH@SRI-ROBOTX.ARPA> Mail-System-Version: We have PCL with a pcl-system-date of 5/22/87. Is there a later version? I tried looking in directory /pub/pcl on parcvax.xerox.com using anonymous FTP but access was denied. Thanks, Doug Ruth Robotics Laboratory SRI International (415) 859-3860 Mailing Address: SRI International 333 Ravenswood Avenue, EL286 Menlo Park, CA 94025 ARPA Net Address: ruth@sri-robotx.arpa ------- From Gregor.pa@Xerox.COM Wed Aug 17 17:12:09 1988 Return-Path: Received: from jungle.uucp by arisia.Xerox.COM (4.0/SMI-DDN) id AB27576; Wed, 17 Aug 88 17:12:09 PDT Received: from Semillon.ms by ArpaGateway.ms ; 17 AUG 88 13:51:04 PDT Date: Wed, 17 Aug 88 13:47 PDT From: Gregor.pa@Xerox.COM Subject: Re: with-slots bug (still) To: Michael Sokolov Cc: CommonLoops.pa@Xerox.COM Fcc: BD:>Gregor>mail>outgoing-mail-3.text.newest In-Reply-To: <8807051641.AA01642@waterloo> Message-Id: <19880817204700.9.GREGOR@PORTNOY.parc.xerox.com> Line-Fold: no Date: Tue, 5 Jul 88 12:41:28 EDT From: Michael Sokolov In the 8/1 PCL, running in Lucid, the following error occurs: (defclass foo () (x y) (:accessor-prefix)) (defclass bar () (z w) (:accessor-prefix)) (defmethod foobar ((f foo) (b bar)) (with-slots (x y) f (setf y (+ x (w b))))) (setq f (make-instance 'foo :x 1 :y 1)) (setq b (make-instance 'bar :w 1 :z 1)) Now, (foobar f b) produces the following: OOPS> >>Error: X has no global value Two comments. 1) This error doesn't happen in the version of PCL we are about to release. 2) This code uses the now obsolete :accessor-prefix feature. You should not use :accessor-prefix anymore, it will be going away shortly. Your defclass forms should be updated as follows: (defclass foo () ((x :accessor x) (y :accessor y))) (defclass bar () ((z :accessor z) (w :accessor w))) ------- From Owners-commonloops.pa@Xerox.COM Wed Aug 17 19:01:58 1988 Received: from jungle.uucp by arisia.Xerox.COM (4.0/SMI-DDN) id AB29322; Wed, 17 Aug 88 19:01:58 PDT Received: from Chardonnay.ms by ArpaGateway.ms ; 17 AUG 88 17:22:32 PDT Return-Path: Redistributed: commonloops.pa Received: from WILMA.BBN.COM ([128.89.1.216]) by Xerox.COM ; 17 AUG 88 17:20:56 PDT To: Doug Ruth Cc: commonloops.pa@Xerox.COM Subject: Re: Latest PCL version In-Reply-To: Your message of Wed, 17 Aug 88 13:41:56 -0800. <587853716.0.RUTH@SRI-ROBOTX.ARPA> Date: Wed, 17 Aug 88 20:14:44 -0400 From: kanderso@WILMA.BBN.COM Message-Id: <880817-172232-5551@Xerox> While you weren't looking the host and directory changed to arisia.xerox.com/pcl/* The latest version is 88/08/02 with a new version likely soon. k From Gregor.pa@Xerox.COM Wed Aug 17 19:45:14 1988 Return-Path: Received: from Xerox.COM by arisia.Xerox.COM (4.0/SMI-DDN) id AA02004; Wed, 17 Aug 88 19:45:14 PDT Received: from Semillon.ms by ArpaGateway.ms ; 17 AUG 88 19:49:05 PDT Date: Wed, 17 Aug 88 19:45 PDT From: Gregor.pa@Xerox.COM Subject: Re: who makes class-prototype To: Aaron Larson Cc: commonloops.pa@Xerox.COM Fcc: BD:>Gregor>mail>outgoing-mail-3.text.newest In-Reply-To: <8808172023.AA21539@pavo.src.honeywell.com> Message-Id: <19880818024527.8.GREGOR@PORTNOY.parc.xerox.com> Line-Fold: no Date: Wed, 17 Aug 88 15:23:05 CDT From: alarson@src.honeywell.com (Aaron Larson) About a month ago Gregor posted several versions of a message with subject "Re: method discrimination on persistent objects" that contained the following: (defmethod allocate-instance ((class db-class)) (let ((instance (call-next-method))) (setf (slot-value instance 'object-id) (allocate-object-id)) instance)) The problem is knowing whether 'allocate-object-id' is called when the class-prototype instace is allocated. In my application it is imperative that it not be. Hence it is necessary that CLOS specifies that allocate-instance is not called for the class-prototpe, or that there be some canonical way for an application to determine that the current call is to make the class-prototype. To help me think about this, could you explain why it is, in your application, that allocate-object-id not be called when allocating the prototype? ------- From Owners-commonloops.PA@Xerox.COM Wed Aug 17 22:08:32 1988 Received: from Xerox.COM by arisia.Xerox.COM (4.0/SMI-DDN) id AA03992; Wed, 17 Aug 88 22:08:32 PDT Received: from Semillon.ms by ArpaGateway.ms ; 17 AUG 88 22:11:54 PDT Return-Path: Redistributed: commonloops.PA Received: from hplabs.HP.COM ([15.255.16.7]) by Xerox.COM ; 17 AUG 88 22:10:00 PDT Received: from hplms2.HP.COM (hplms2) by hplabs.HP.COM with SMTP ; Wed, 17 Aug 88 11:49:08 PST Received: from hplwhh.HPL.HP.COM (hplwhh.hpl.hp.com) by hplms2.HP.COM; Wed, 17 Aug 88 12:48:44 pdt Received: from hplwhh by hplwhh.HPL.HP.COM; Wed, 17 Aug 88 12:48:20 pdt To: Gregor.pa@Xerox.COM, poman@CS.UCLA.EDU Cc: commonloops.PA@Xerox.COM Subject: Re: problem in initialize-instance X-Mailer: mh6.5 In-Reply-To: Your message of Tue, 16 Aug 88 10:33:00 -0700. <19880816173326.0.GREGOR@PORTNOY.parc.xerox.com> Date: Wed, 17 Aug 88 12:48:18 PDT Message-Id: <6686.587850498@hplwhh> From: Warren Harris Here's a patch we did for HP Common Lisp which also has a non-reentrant compiler. It has the nasty feature of redefining the function COMPILE, but what it does is returns a closure that will compile the function later (when the function is invoked at runtime and the compiler is not running) if the compiler is currently active. You'll need to find a way in KCL to figure out if the compiler is running. The flag COMPILER::*COMP-RUNNING* does this in HP-CL. Warren (in-package :lisp) (unless (fboundp 'basic-compile) (setf (symbol-function 'basic-compile) (symbol-function 'compile))) (defun deferred-compile (name &optional definition) (if compiler::*comp-running* ; is the compiler running? ;; then return a function which not only executes the definitions, but ;; also compiles itself at runtime (later when the compiler is not running) (let* ((original-definition (or definition (symbol-function name))) (deferred-function #'(lambda (&rest args) (if compiler::*comp-running* (apply original-definition args) (apply (if (null definition) (basic-compile name) (basic-compile name definition)) args))))) (if name (progn (setf (symbol-function name) deferred-function) name) deferred-function)) ;; else, the compiler is not running, so call the old compile function (if (null definition) (basic-compile name) (basic-compile name definition)))) (eval-when (eval load) (setf (symbol-function 'compile) (symbol-function 'deferred-compile))) From Owners-commonloops.PA@Xerox.COM Thu Aug 18 07:00:46 1988 Received: from Xerox.COM by arisia.Xerox.COM (4.0/SMI-DDN) id AA06959; Thu, 18 Aug 88 07:00:46 PDT Received: from Riesling.ms by ArpaGateway.ms ; 18 AUG 88 07:04:43 PDT Return-Path: Redistributed: commonloops.PA Received: from PEBBLES.BBN.COM ([128.89.1.5]) by Xerox.COM ; 18 AUG 88 07:03:35 PDT To: Warren Harris Cc: Gregor.pa@Xerox.COM, poman@CS.UCLA.EDU, commonloops.PA@Xerox.COM Subject: Re: problem in initialize-instance In-Reply-To: Your message of Wed, 17 Aug 88 12:48:18 -0700. <6686.587850498@hplwhh> Date: Thu, 18 Aug 88 10:06:21 -0400 From: kanderso@PEBBLES.BBN.COM Message-Id: <880818-070443-6305@Xerox> The variable you need for KCL seems to be COMPILER::*COMPILER-IN-USE*. k From Owners-CommonLoops.pa@Xerox.COM Thu Aug 18 08:23:58 1988 Received: from Xerox.COM by arisia.Xerox.COM (4.0/SMI-DDN) id AA07079; Thu, 18 Aug 88 08:23:58 PDT Received: from Burger.ms by ArpaGateway.ms ; 18 AUG 88 08:23:02 PDT Return-Path: Redistributed: CommonLoops.pa Received: from arisia.Xerox.COM ([13.1.100.206]) by Xerox.COM ; 18 AUG 88 08:21:51 PDT Received: from hi-csc.honeywell.com ([192.12.237.29]) by arisia.Xerox.COM (4.0/SMI-DDN) id AA07049; Thu, 18 Aug 88 08:17:31 PDT Received: by hi-csc.honeywell.com (4.12/BSD4.2) id AA02968; Thu, 18 Aug 88 10:32:59 cdt Date: Thu, 18 Aug 88 10:32:59 cdt From: Kurt D. Krebsbach Message-Id: <8808181532.AA02968@hi-csc.honeywell.com> To: CommonLoops.pa@Xerox.COM To: CommonLoops.pa@xerox.com Subject: iteration bug --text follows this line-- I've been having a hard time trying to compile the file iterate.lisp on a Symbolics under Genera 7.1. This has happened exactly the same way when trying to compile both the 7/7/88 release, and the 8/2/release. Here's the error I get: For function OPTIMIZE-ITERATE-FORM While compiling (SETQ V (PROG1 (CAR #:G9593) (SETQ #:G9593 (CDR #:G9593)))) The ignored variable V was referenced. Error: The second argument (VALUE) to SYS:SIGNED-IMMEDIATE-OPERAND, 231, was of the wrong type. The function expected a small signed operand. SYS:SIGNED-IMMEDIATE-OPERAND: ARG0: (COMPILER:OPCODE): 67 ARG1: (COMPILER:VALUE): 231 Please let me know what's going on as soon as possible, as I believe this is the only problem keeping us from getting post-St. Patrick's day versions up and running. Thanks, Kurt Krebsbach From Gregor.pa@Xerox.COM Thu Aug 18 10:08:51 1988 Return-Path: Received: from Xerox.COM by arisia.Xerox.COM (4.0/SMI-DDN) id AA07694; Thu, 18 Aug 88 10:08:51 PDT Received: from Semillon.ms by ArpaGateway.ms ; 18 AUG 88 10:10:26 PDT Date: Thu, 18 Aug 88 10:05 PDT From: Gregor.pa@Xerox.COM Subject: iterate in 7.1 To: Kurt D. Krebsbach Cc: CommonLoops.pa@Xerox.COM Fcc: BD:>Gregor>mail>outgoing-mail-3.text.newest In-Reply-To: <8808181532.AA02968@hi-csc.honeywell.com> Message-Id: <19880818170518.3.GREGOR@PORTNOY.parc.xerox.com> Line-Fold: no Date: Thu, 18 Aug 88 10:32:59 cdt From: Kurt D. Krebsbach I've been having a hard time trying to compile the file iterate.lisp on a Symbolics under Genera 7.1. This has happened exactly the same way when trying to compile both the 7/7/88 release, and the 8/2/release. Here's the error I get: For function OPTIMIZE-ITERATE-FORM . . I thought I answered this message last week. There is a new version of iterate on arisia which fixes this bug. ------- From Owners-commonloops.PA@Xerox.COM Thu Aug 18 10:19:00 1988 Received: from Xerox.COM by arisia.Xerox.COM (4.0/SMI-DDN) id AA07807; Thu, 18 Aug 88 10:19:00 PDT Received: from Riesling.ms by ArpaGateway.ms ; 18 AUG 88 10:22:54 PDT Return-Path: <@LEGAL-SEAFOOD.BBN.COM:cerys@bbn.com> Redistributed: commonloops.PA Received: from VAX.BBN.COM ([128.89.0.91]) by Xerox.COM ; 18 AUG 88 10:21:44 PDT Received: from legal-seafood.bbn.com by VAX.BBN.COM id aa15121; 18 Aug 88 13:09 EDT Message-Id: <2796916181-4272232@LEGAL-SEAFOOD> Sender: cerys@LEGAL-SEAFOOD.BBN.COM Date: Thu, 18 Aug 88 13:09:41 EDT From: Daniel Cerys To: commonloops.PA@Xerox.COM Subject: :documentation slot option In DEFCLASS, use of the the :documentation slot option results in an error. Even if the :documentation value isn't used by the system, it shouldn't result in an error. The following change to defclass.lisp corrects this problem: (defmethod LEGAL-SLOT-OPTION-P ((class standard-class) option) (memq option '(:name :initform :initfunction :initarg :initvalue :type :accessor :reader :allocation :documentation))) [Note that :writer is also not supported, but unlike :documentation, its value cannot simply be ignored.] From Owners-commonloops.PA@Xerox.COM Thu Aug 18 10:55:12 1988 Received: from Xerox.COM by arisia.Xerox.COM (4.0/SMI-DDN) id AB08235; Thu, 18 Aug 88 10:55:12 PDT Received: from Riesling.ms by ArpaGateway.ms ; 18 AUG 88 10:55:53 PDT Return-Path: Redistributed: commonloops.PA Received: from cu-arpa.cs.cornell.edu ([10.3.0.96]) by Xerox.COM ; 18 AUG 88 10:51:48 PDT Received: from WRATH.CS.CORNELL.EDU by cu-arpa.cs.cornell.edu (5.59/4.30) id AA24346; Thu, 18 Aug 88 11:10:32 EDT Received: by wrath.cs.cornell.edu (5.54/4.30) id AA16535; Thu, 18 Aug 88 11:10:26 EDT Received: by oravax.UUCP (5.51/5.17) id AA21817; Thu, 18 Aug 88 10:51:40 EDT Date: Thu, 18 Aug 88 10:51:40 EDT From: oravax!hook@cu-arpa.cs.cornell.edu (Jim Hook) Message-Id: <8808181451.AA21817@oravax.UUCP> To: commonloops.PA@Xerox.COM Subject: lucid port of St. Patrick's Day PCL We have been using St. Patrick's Day PCL with ibcl, and have developed a fair amount of code. We just got a copy of lucid from our sun salesman for evaluation and are having problems with "mki" getting a message such as: > (mki 'primitive_constant 'P_constant 'all) Cleared input from *debug-io* >>Error: No matching method for the generic-function: #. PCL::INITIALIZE-INSTANCE: Required arg 0 (Disc-Fn-Arg-0): >>Error: No matching method for the generic-function: #. PRINT-OBJECT: Required arg 0 (Disc-Fn-Arg-0): # Required arg 1 (Disc-Fn-Arg-1): # Required arg 2 (Disc-Fn-Arg-2): 0 :A Abort to Lisp Top Level :E Abort to previous break ->-> ------- Is there a standard set of patches which we should install? Do these problems look familiar to others? Confused in Ithaca, Jim Hook Odyssey Research Associates 301A Harris B. Dates Drive Ithaca, NY 14850 (607)277-2020 hook%oravax.uucp@cs.cornell.edu jgh@svax.cs.cornell.edu From Owners-commonloops.pa@Xerox.COM Thu Aug 18 12:02:27 1988 Received: from Xerox.COM by arisia.Xerox.COM (4.0/SMI-DDN) id AB08854; Thu, 18 Aug 88 12:02:27 PDT Received: from Salvador.ms by ArpaGateway.ms ; 18 AUG 88 11:52:22 PDT Return-Path: Redistributed: commonloops.pa Received: from G.BBN.COM ([8.2.0.18]) by Xerox.COM ; 18 AUG 88 11:49:52 PDT Date: Thu, 18 Aug 88 14:49:08 EDT From: R. Shapiro Subject: STRUCTURE-CLASS metaclass To: commonloops.pa@Xerox.COM Message-Id: <880818-115222-6932@Xerox> According to the June '88 CLOS spec (p. 1-15): "Each structure type created by DEFSTRUCT without using the :TYPE option has a corresponding class. This class is an instance of STRUCTURE-CLASS. The :INCLUDE option of DEFSTRUCT creates a direct subclass of the class that corresponds to the included structure." This functionality does not seem to be in the last release of PCL. Is it expected that this will be included in any release soon? ------- From Owners-CommonLoops.pa@Xerox.COM Thu Aug 18 12:43:20 1988 Received: from Xerox.COM by arisia.Xerox.COM (4.0/SMI-DDN) id AB09405; Thu, 18 Aug 88 12:43:20 PDT Received: from Salvador.ms by ArpaGateway.ms ; 18 AUG 88 12:42:38 PDT Return-Path: Redistributed: CommonLoops.pa Received: from PEBBLES.BBN.COM ([128.89.1.5]) by Xerox.COM ; 18 AUG 88 12:40:36 PDT To: CommonLoops.pa@Xerox.COM Cc: kanderson@PEBBLES.BBN.COM Subject: extra tests in built-in-class-of? Date: Thu, 18 Aug 88 15:40:03 -0400 From: kanderso@PEBBLES.BBN.COM Message-Id: <880818-124238-7047@Xerox> In 88/8/2 PCL in high.lisp Shouldn't built-in-class-of look something like: (defun built-in-class-of (x) (and (typep x 't) (or (and (typep x 'sequence) (or (and (typep x 'array) (or (and (typep x 'vector) (or (and (typep x 'bit-vector) *the-class-bit-vector*) (and (typep x 'string) *the-class-string*) *the-class-vector*)) *the-class-array*)) (and (typep x 'list) (or (and (typep x 'cons) *the-class-cons*) (and (typep x 'symbol) *the-class-null*) *the-class-list*))) *the-class-sequence*) (and (typep x 'character) *the-class-character*) (and (typep x 'number) (or (and (typep x 'complex) *the-class-complex*) (and (typep x 'float) *the-class-float*) (and (typep x 'rational) (or (typep x 'integer) *the-class-integer*) *the-class-rational*) *the-class-number*)) (and (typep x 'symbol) *the-class-symbol*) *the-class-t*))) rather than what is below. For example, something that is not a vector is also checked if it is a string and a sequence (DEFUN BUILT-IN-CLASS-OF (X) (AND (TYPEP X 'T) (OR (AND (TYPEP X 'VECTOR) (OR (AND (TYPEP X 'STRING) (OR (LOCALLY (DECLARE (SPECIAL *THE-CLASS-STRING*)) *THE-CLASS-STRING*))) (AND (TYPEP X 'BIT-VECTOR) (OR (LOCALLY (DECLARE (SPECIAL *THE-CLASS-BIT-VECTOR*)) *THE-CLASS-BIT-VECTOR*))) (LOCALLY (DECLARE (SPECIAL *THE-CLASS-VECTOR*)) *THE-CLASS-VECTOR*))) (AND (TYPEP X 'SYMBOL) (OR (AND (TYPEP X 'NULL) (OR (LOCALLY (DECLARE (SPECIAL *THE-CLASS-NULL*)) *THE-CLASS-NULL*))) (LOCALLY (DECLARE (SPECIAL *THE-CLASS-SYMBOL*)) *THE-CLASS-SYMBOL*))) (AND (TYPEP X 'STRING) (OR (LOCALLY (DECLARE (SPECIAL *THE-CLASS-STRING*)) *THE-CLASS-STRING*))) (AND (TYPEP X 'SEQUENCE) (OR (AND (TYPEP X 'VECTOR) (OR (AND (TYPEP X 'STRING) (OR (LOCALLY (DECLARE (SPECIAL *THE-CLASS-STRING*)) *THE-CLASS-STRING*))) (AND (TYPEP X 'BIT-VECTOR) (OR (LOCALLY (DECLARE (SPECIAL *THE-CLASS-BIT-VECTOR*)) *THE-CLASS-BIT-VECTOR*))) (LOCALLY (DECLARE (SPECIAL *THE-CLASS-VECTOR*)) *THE-CLASS-VECTOR*))) ; (AND (TYPEP X 'STRING) ; (OR (LOCALLY (DECLARE (SPECIAL *THE-CLASS-STRING*)) *THE-CLASS-STRING*))) (AND (TYPEP X 'NULL) (OR (LOCALLY (DECLARE (SPECIAL *THE-CLASS-NULL*)) *THE-CLASS-NULL*))) (AND (TYPEP X 'LIST) (OR (AND (TYPEP X 'NULL) (OR (LOCALLY (DECLARE (SPECIAL *THE-CLASS-NULL*)) *THE-CLASS-NULL*))) (AND (TYPEP X 'CONS) (OR (LOCALLY (DECLARE (SPECIAL *THE-CLASS-CONS*)) *THE-CLASS-CONS*))) (LOCALLY (DECLARE (SPECIAL *THE-CLASS-LIST*)) *THE-CLASS-LIST*))) (AND (TYPEP X 'CONS) (OR (LOCALLY (DECLARE (SPECIAL *THE-CLASS-CONS*)) *THE-CLASS-CONS*))) (AND (TYPEP X 'BIT-VECTOR) (OR (LOCALLY (DECLARE (SPECIAL *THE-CLASS-BIT-VECTOR*)) *THE-CLASS-BIT-VECTOR*))) (LOCALLY (DECLARE (SPECIAL *THE-CLASS-SEQUENCE*)) *THE-CLASS-SEQUENCE*))) (AND (TYPEP X 'RATIONAL) (OR (AND (TYPEP X 'RATIO) (OR (LOCALLY (DECLARE (SPECIAL *THE-CLASS-RATIO*)) *THE-CLASS-RATIO*))) (AND (TYPEP X 'INTEGER) (OR (LOCALLY (DECLARE (SPECIAL *THE-CLASS-INTEGER*)) *THE-CLASS-INTEGER*))) (LOCALLY (DECLARE (SPECIAL *THE-CLASS-RATIONAL*)) *THE-CLASS-RATIONAL*))) (AND (TYPEP X 'RATIO) (OR (LOCALLY (DECLARE (SPECIAL *THE-CLASS-RATIO*)) *THE-CLASS-RATIO*))) (AND (TYPEP X 'NUMBER) (OR (AND (TYPEP X 'RATIONAL) (OR (AND (TYPEP X 'RATIO) (OR (LOCALLY (DECLARE (SPECIAL *THE-CLASS-RATIO*)) *THE-CLASS-RATIO*))) (AND (TYPEP X 'INTEGER) (OR (LOCALLY (DECLARE (SPECIAL *THE-CLASS-INTEGER*)) *THE-CLASS-INTEGER*))) (LOCALLY (DECLARE (SPECIAL *THE-CLASS-RATIONAL*)) *THE-CLASS-RATIONAL*))) (AND (TYPEP X 'RATIO) (OR (LOCALLY (DECLARE (SPECIAL *THE-CLASS-RATIO*)) *THE-CLASS-RATIO*))) (AND (TYPEP X 'INTEGER) (OR (LOCALLY (DECLARE (SPECIAL *THE-CLASS-INTEGER*)) *THE-CLASS-INTEGER*))) (AND (TYPEP X 'FLOAT) (OR (LOCALLY (DECLARE (SPECIAL *THE-CLASS-FLOAT*)) *THE-CLASS-FLOAT*))) (AND (TYPEP X 'COMPLEX) (OR (LOCALLY (DECLARE (SPECIAL *THE-CLASS-COMPLEX*)) *THE-CLASS-COMPLEX*))) (LOCALLY (DECLARE (SPECIAL *THE-CLASS-NUMBER*)) *THE-CLASS-NUMBER*))) (AND (TYPEP X 'NULL) (OR (LOCALLY (DECLARE (SPECIAL *THE-CLASS-NULL*)) *THE-CLASS-NULL*))) (AND (TYPEP X 'LIST) (OR (AND (TYPEP X 'NULL) (OR (LOCALLY (DECLARE (SPECIAL *THE-CLASS-NULL*)) *THE-CLASS-NULL*))) (AND (TYPEP X 'CONS) (OR (LOCALLY (DECLARE (SPECIAL *THE-CLASS-CONS*)) *THE-CLASS-CONS*))) (LOCALLY (DECLARE (SPECIAL *THE-CLASS-LIST*)) *THE-CLASS-LIST*))) (AND (TYPEP X 'INTEGER) (OR (LOCALLY (DECLARE (SPECIAL *THE-CLASS-INTEGER*)) *THE-CLASS-INTEGER*))) (AND (TYPEP X 'FLOAT) (OR (LOCALLY (DECLARE (SPECIAL *THE-CLASS-FLOAT*)) *THE-CLASS-FLOAT*))) (AND (TYPEP X 'CONS) (OR (LOCALLY (DECLARE (SPECIAL *THE-CLASS-CONS*)) *THE-CLASS-CONS*))) (AND (TYPEP X 'COMPLEX) (OR (LOCALLY (DECLARE (SPECIAL *THE-CLASS-COMPLEX*)) *THE-CLASS-COMPLEX*))) (AND (TYPEP X 'CHARACTER) (OR (LOCALLY (DECLARE (SPECIAL *THE-CLASS-CHARACTER*)) *THE-CLASS-CHARACTER*))) (AND (TYPEP X 'BIT-VECTOR) (OR (LOCALLY (DECLARE (SPECIAL *THE-CLASS-BIT-VECTOR*)) *THE-CLASS-BIT-VECTOR*))) (AND (TYPEP X 'ARRAY) (OR (AND (TYPEP X 'VECTOR) (OR (AND (TYPEP X 'STRING) (OR (LOCALLY (DECLARE (SPECIAL *THE-CLASS-STRING*)) *THE-CLASS-STRING*))) (AND (TYPEP X 'BIT-VECTOR) (OR (LOCALLY (DECLARE (SPECIAL *THE-CLASS-BIT-VECTOR*)) *THE-CLASS-BIT-VECTOR*))) (LOCALLY (DECLARE (SPECIAL *THE-CLASS-VECTOR*)) *THE-CLASS-VECTOR*))) (AND (TYPEP X 'STRING) (OR (LOCALLY (DECLARE (SPECIAL *THE-CLASS-STRING*)) *THE-CLASS-STRING*))) (AND (TYPEP X 'BIT-VECTOR) (OR (LOCALLY (DECLARE (SPECIAL *THE-CLASS-BIT-VECTOR*)) *THE-CLASS-BIT-VECTOR*))) (LOCALLY (DECLARE (SPECIAL *THE-CLASS-ARRAY*)) *THE-CLASS-ARRAY*))) (LOCALLY (DECLARE (SPECIAL *THE-CLASS-T*)) *THE-CLASS-T*)))) From Owners-commonloops.PA@Xerox.COM Thu Aug 18 13:59:13 1988 Received: from Xerox.COM by arisia.Xerox.COM (4.0/SMI-DDN) id AA10556; Thu, 18 Aug 88 13:59:13 PDT Received: from Salvador.ms by ArpaGateway.ms ; 18 AUG 88 14:03:05 PDT Return-Path: Redistributed: commonloops.PA Received: from SRI-ROBOTX.ARPA ([128.18.3.100]) by Xerox.COM ; 18 AUG 88 14:01:38 PDT Date: Thu, 18 Aug 88 13:58:31 PST From: Doug Ruth Subject: Defining classes for other predefined CommonLisp types To: commonloops.PA@Xerox.COM Message-Id: <587941111.0.RUTH@SRI-ROBOTX.ARPA> Mail-System-Version: We are using PCL to implement an object-oriented database for use in robotic applications. Requirements include "strong" type-checking and support for user-defined types. I am not an expert at using PCL and so am not sure if it is possible (or, if it is, how easy) to do some of the things I would like. 1) I would like to define classes for some of the other predefined CommonLisp types. What code would I have to add to accomplish this (in addition to adding an appropriate element to the variable *built-in-classes* in the file high.lisp)? 2) How involved would it be (if possible) to have the form deftype create new classes? I haven't been on the mailing list, so if similar subjects have been addressed, I'd appreciate a pointer to them. Thanks, Doug Ruth Robotics Laboratory SRI International (415) 859-3860 Mailing Address: SRI International 333 Ravenswood Avenue, EL286 Menlo Park, CA 94025 ARPA Net Address: ruth@sri-robotx.arpa ------- From Owners-commonloops.PA@Xerox.COM Thu Aug 18 14:44:42 1988 Received: from Xerox.COM by arisia.Xerox.COM (4.0/SMI-DDN) id AB11856; Thu, 18 Aug 88 14:44:42 PDT Received: from Riesling.ms by ArpaGateway.ms ; 18 AUG 88 14:08:39 PDT Return-Path: Redistributed: commonloops.PA Received: from fs3.cs.rpi.edu ([128.213.1.14]) by Xerox.COM ; 18 AUG 88 14:07:22 PDT Received: by fs3.cs.rpi.edu (5.54/1.2-RPI-CS-Dept) id AA05980; Thu, 18 Aug 88 14:03:54 EDT Date: Thu, 18 Aug 88 14:03:59 EDT From: harrisr@turing.cs.rpi.edu (Richard Harris) Received: by turing.cs.rpi.edu (4.0/1.2-RPI-CS-Dept) id AA15273; Thu, 18 Aug 88 14:03:59 EDT Message-Id: <8808181803.AA15273@turing.cs.rpi.edu> To: commonloops.PA@Xerox.COM Subject: Making the KCL compiler recursive Here is a way to make the KCL compiler recursive. It should work for both KCL and AKCL. To make this message shorter, the comments beginning with ";***" give instructions that you will need to follow. Rick Harris ;Beginning of patches. (in-package "COMPILER") (defvar *cmpvar-list* nil) (defmacro defcmpvar (name form) `(eval-when (compile load eval) (defvar ,name ,form) (addcmpvar ',name ',form))) (defun addcmpvar (name form) (let ((a (assoc name *cmpvar-list*))) (if a (setf (cadr a) form) (push (list name form) *cmpvar-list*))) name) (defmacro in-compiler (&body forms) `(progv (mapcar #'car *cmpvar-list*) (mapcar #'(lambda (v-f) (eval (cadr v-f))) *cmpvar-list*) ,@forms)) ;*** For each setq in init-env (found in cmpnew/cmpenv.lsp), ;*** put a defcmpvar form here. ;*** (for example, init-env contains "(setq *next-cvar* 0)", ;*** so put "(defcmpvar *next-cvar* 0)" here) ;*** Extract the definitions of compile-file1, compile1, and disassemble1 ;*** (found in cmpnew/cmpmain.lsp), and put them here. ;*** For each function: ;*** 1) The first (or maybe second) form begins "(cond (*compiler-in-use*". ;*** Remove this form. ;*** 2) Replace the first occurrence of "(init-env)" with "(in-compiler", ;*** and the second occurrence of "(init-env)" with ")". ;End of patches. From Gregor.pa@Xerox.COM Thu Aug 18 15:32:47 1988 Return-Path: Received: from Xerox.COM by arisia.Xerox.COM (4.0/SMI-DDN) id AB12705; Thu, 18 Aug 88 15:32:47 PDT Received: from Semillon.ms by ArpaGateway.ms ; 18 AUG 88 14:33:30 PDT Date: Thu, 18 Aug 88 14:27 PDT From: Gregor.pa@Xerox.COM Subject: Re: :documentation slot option To: Daniel Cerys Cc: commonloops.PA@Xerox.COM Fcc: BD:>Gregor>mail>outgoing-mail-3.text.newest In-Reply-To: <2796916181-4272232@LEGAL-SEAFOOD> Message-Id: <19880818212722.1.GREGOR@PORTNOY.parc.xerox.com> Line-Fold: no Date: Thu, 18 Aug 88 13:09:41 EDT From: Daniel Cerys In DEFCLASS, use of the the :documentation slot option results in an error. Even if the :documentation value isn't used by the system, it shouldn't result in an error. [Note that :writer is also not supported, but unlike :documentation, its value cannot simply be ignored.] In the forthcoming release, the :documentation and :writer slot options will both be implemented. The :documentation string will not be retrievable in this release, but the :writer option will work correctly. ------- From Gregor.pa@Xerox.COM Thu Aug 18 16:15:46 1988 Return-Path: Received: from Xerox.COM by arisia.Xerox.COM (4.0/SMI-DDN) id AA12878; Thu, 18 Aug 88 16:15:46 PDT Received: from Semillon.ms by ArpaGateway.ms ; 18 AUG 88 14:45:05 PDT Date: Thu, 18 Aug 88 14:40 PDT From: Gregor.pa@Xerox.COM Subject: Re: STRUCTURE-CLASS metaclass To: R. Shapiro Cc: commonloops.pa@Xerox.COM Fcc: BD:>Gregor>mail>outgoing-mail-3.text.newest In-Reply-To: The message of 18 Aug 88 11:49 PDT from R. Shapiro Message-Id: <19880818214031.4.GREGOR@PORTNOY.parc.xerox.com> Line-Fold: no Date: Thu, 18 Aug 88 14:49:08 EDT From: R. Shapiro According to the June '88 CLOS spec (p. 1-15): "Each structure type created by DEFSTRUCT without using the :TYPE option has a corresponding class. This class is an instance of STRUCTURE-CLASS. The :INCLUDE option of DEFSTRUCT creates a direct subclass of the class that corresponds to the included structure." This functionality does not seem to be in the last release of PCL. Is it expected that this will be included in any release soon? Ken Anderson at BBN and I just started talking about implementing this. It is possible we will be able to do this in the next few weeks. ------- From Gregor.pa@Xerox.COM Thu Aug 18 16:56:13 1988 Return-Path: Received: from Xerox.COM by arisia.Xerox.COM (4.0/SMI-DDN) id AB13128; Thu, 18 Aug 88 16:56:13 PDT Received: from Semillon.ms by ArpaGateway.ms ; 18 AUG 88 15:47:50 PDT Date: Thu, 18 Aug 88 15:44 PDT From: Gregor.pa@Xerox.COM Subject: Re: extra tests in built-in-class-of? To: kanderso@PEBBLES.BBN.COM Cc: CommonLoops.pa@Xerox.COM, kanderson@PEBBLES.BBN.COM Fcc: BD:>Gregor>mail>outgoing-mail-3.text.newest In-Reply-To: The message of 18 Aug 88 12:40 PDT from kanderso@PEBBLES.BBN.COM Message-Id: <19880818224405.8.GREGOR@PORTNOY.parc.xerox.com> Line-Fold: no Date: Thu, 18 Aug 88 15:40:03 -0400 From: kanderso@PEBBLES.BBN.COM In 88/8/2 PCL in high.lisp Shouldn't built-in-class-of look something like: Congratulations, you have once again found a source of incredible bogosity in PCL. I am working on fixing this right now so that the change can make it into the next PCL. It seems something a shame to be fixing this, since when we do our structure classes we will rewrite it again, but what the hell. Thanks for pointing this out. I can't believe how broken this all was. ------- From Owners-commonloops.pa@Xerox.COM Thu Aug 18 18:24:44 1988 Received: from Xerox.COM by arisia.Xerox.COM (4.0/SMI-DDN) id AA13647; Thu, 18 Aug 88 18:24:44 PDT Received: from Semillon.ms by ArpaGateway.ms ; 18 AUG 88 18:23:40 PDT Return-Path: Redistributed: commonloops.pa Received: from boulder.Colorado.EDU ([128.138.238.18]) by Xerox.COM ; 18 AUG 88 18:20:45 PDT Return-Path: Received: by boulder.Colorado.EDU (cu.grandpoobah.052088) Received: by sigi.colorado.edu (cu.generic.041888) Date: Thu, 18 Aug 88 19:20:26 MDT From: Curt Stevens Message-Id: <8808190120.AA02459@sigi.colorado.edu> To: commonloops.pa@Xerox.COM Subject: Can't get 8/2/88 pcl to compile under Allegro 1.2.1... Wotd: O'Leary I get the following error. Can someone help me? %% ? %% ;Loading "Voodoo:Work-Area:Lisp:PCL:defsys.lisp"... %% ? (pcl::compile-pcl) %% Loading binary of PKG... %% Loading binary of WALK... %% Loading binary of ITERATE... %% Loading binary of MACROS... %% Loading binary of LOW... %% Loading binary of CORAL-LOW... %% **** some redefinition warnings... %% Loading binary of FIN... %% Loading binary of DEFS... %% Loading binary of BOOT... %% Loading binary of VECTOR... %% Loading binary of SLOTS... %% Loading binary of MKI... %% Loading binary of DEFCLASS... %% Loading binary of STD-CLASS... %% Loading binary of BRAID1... %% Loading binary of FSC... %% Loading binary of METHODS... %% Loading binary of COMBIN... %% Loading binary of DCODE... %% ****** some redefinition warnings... then... %% > While executing: CCL::RECORD-SOURCE-FILE %% Compiling DCODE-PRE1... %% While compiling an anonymous function: %% > Error: Can't compile (1 NIL (0)) in car of form : ((1 NIL (0)) (2 NIL (0)) (2 %% NIL (1)) (2 NIL (0 1)) (3 NIL (0 1)) (3 NIL (0)) (4 NIL (0)) (5 NIL (0)) (5 NIL %% (0 1)) (6 NIL (0)) (6 NIL (0 1)) (7 NIL (0)) (1 T (0)) (3 T (0)) (4 T (0))). %% > While executing: # %% > Type Command-/ to continue, Command-. to abort. %% 1 > thanks a bunch... =============================================================================== |Curt Stevens (303)492-1218 | / | E-MAIL: | |University of Colorado at Boulder | o o | ------- | |Computer Science Department | | |arpa: stevens@boulder.colorado.edu| |Campus Box 430 | \_/ |csnet: stevens@boulder.csnet| |Boulder, Colorado 80309 | |uucp:{ncar|nbires}!boulder!stevens| =============================================================================== ======== | Curt | ======== From Owners-commonloops.pa@Xerox.COM Fri Aug 19 11:22:45 1988 Received: from Xerox.COM by arisia.Xerox.COM (4.0/SMI-DDN) id AA03311; Fri, 19 Aug 88 11:22:45 PDT Received: from Salvador.ms by ArpaGateway.ms ; 19 AUG 88 11:12:38 PDT Return-Path: Redistributed: commonloops.pa Received: from cu-arpa.cs.cornell.edu ([10.3.0.96]) by Xerox.COM ; 19 AUG 88 11:11:16 PDT Received: from WRATH.CS.CORNELL.EDU by cu-arpa.cs.cornell.edu (5.59/4.30) id AA28290; Fri, 19 Aug 88 14:10:19 EDT Received: by wrath.cs.cornell.edu (5.54/4.30) id AA02377; Fri, 19 Aug 88 14:10:15 EDT Received: by oravax.UUCP (5.51/5.17) id AA16009; Fri, 19 Aug 88 14:00:10 EDT Date: Fri, 19 Aug 88 14:00:10 EDT From: oravax!esrig@cu-arpa.cs.cornell.edu (Bruce Esrig) Message-Id: <8808191800.AA16009@oravax.UUCP> To: commonloops.pa@Xerox.COM Subject: exporting standard-class In a previous query, we asked whether there were any problems porting pcl to Lucid; we reported that when we make an instance, we get a message stating that there is no matching method for the generic function initialize-instance. We now know that the cause of the problem was that we had created a class with an undefined metaclass. The following definition illustrates our problem. (in-package 'my-package :use '(lisp pcl system)) (defclass topmost_class (standard-class) ()) (make-instance 'topmost_class) In this definition, standard-class refers to the internal symbol of my-package. Should the classes standard-class and above be exported by the pcl package ? If they were, this problem would not occur. Alternatively, should there be a way to get warning messages when forward definitions of class names occur ? Bruce Esrig Odyssey Research Associates esrig%oravax.uucp@cs.cornell.edu From Owners-commonloops.pa@Xerox.COM Fri Aug 19 13:05:26 1988 Received: from Xerox.COM by arisia.Xerox.COM (4.0/SMI-DDN) id AA04256; Fri, 19 Aug 88 13:05:26 PDT Received: from Semillon.ms by ArpaGateway.ms ; 19 AUG 88 13:04:25 PDT Return-Path: Redistributed: commonloops.pa Received: from PEBBLES.BBN.COM ([128.89.1.5]) by Xerox.COM ; 19 AUG 88 13:01:35 PDT To: Bruce Esrig Cc: commonloops.pa@Xerox.COM Subject: Re: exporting standard-class In-Reply-To: Your message of Fri, 19 Aug 88 14:00:10 -0400. <8808191800.AA16009@oravax.UUCP> Date: Fri, 19 Aug 88 15:59:27 -0400 From: kanderso@PEBBLES.BBN.COM Message-Id: <880819-130425-9228@Xerox> The export done in pkg.lisp seems to be out of date. You can get more useful symbols exported by doing (export pcl:*other-exports*) after loading PCL. From Owners-CommonLoops.pa@Xerox.COM Fri Aug 19 14:14:25 1988 Received: from Xerox.COM by arisia.Xerox.COM (4.0/SMI-DDN) id AA07888; Fri, 19 Aug 88 14:14:25 PDT Received: from Cabernet.ms by ArpaGateway.ms ; 19 AUG 88 14:05:20 PDT Return-Path: Redistributed: CommonLoops.pa Received: from Think.COM ([10.4.0.6]) by Xerox.COM ; 19 AUG 88 14:01:26 PDT Received: from fafnir.think.com by Think.COM; Fri, 19 Aug 88 17:00:37 EDT Return-Path: Received: from sauron.think.com by fafnir.think.com; Fri, 19 Aug 88 17:00:15 EDT Received: from POLYCARP.THINK.COM by sauron.think.com; Fri, 19 Aug 88 17:00:04 EDT Date: Fri, 19 Aug 88 16:55 EDT From: Jim Salem Subject: recording source file names To: commonloops@Think.COM Message-Id: <19880819205549.3.SALEM@POLYCARP.THINK.COM> DEFMETHOD doesn't record the source file names on 3600s. This is because the appropriate code was commented out in RECORD-DEFINITION in 3600-low. I suggest this code be reinstated. -- jim From Owners-CommonLoops.pa@Xerox.COM Fri Aug 19 15:23:01 1988 Received: from Xerox.COM by arisia.Xerox.COM (4.0/SMI-DDN) id AA08963; Fri, 19 Aug 88 15:23:01 PDT Received: from Riesling.ms by ArpaGateway.ms ; 19 AUG 88 14:05:51 PDT Return-Path: Redistributed: CommonLoops.pa Received: from Think.COM ([10.4.0.6]) by Xerox.COM ; 19 AUG 88 14:02:18 PDT Received: from fafnir.think.com by Think.COM; Fri, 19 Aug 88 17:01:24 EDT Return-Path: Received: from sauron.think.com by fafnir.think.com; Fri, 19 Aug 88 17:01:03 EDT Received: from POLYCARP.THINK.COM by sauron.think.com; Fri, 19 Aug 88 17:00:55 EDT Date: Fri, 19 Aug 88 16:56 EDT From: Jim Salem Subject: CLOS needs an UNDEFMETHOD To: commonloops@Think.COM Message-Id: <19880819205643.5.SALEM@POLYCARP.THINK.COM> It appears to be very difficult to write an UNDEFMETHOD in standard CLOS. I suggest one be provided. I would like : (defmacro UNDEFMETHOD (method-name {method-qualifiers}* argument-specifiers)) I order to write this I had to call in order : ENSURE-GENERIC-FUNCTION This appears to be the only way to get the generic function object from a symbol name. FIND-CLASS To turn the specifier symbols into class names. FIND-METHOD To find the method after parsing the qualifiers and specializers. REMOVE-METHOD This was quite an ordeal to create a fairly standard developing tool. Since UNDEFMETHOD is used quite often, I suggest it be added to the CLOS spec. -- jim salem@think.com From Owners-commonloops.PA@Xerox.COM Sat Aug 20 10:42:16 1988 Received: from Xerox.COM by arisia.Xerox.COM (4.0/SMI-DDN) id AA21507; Sat, 20 Aug 88 10:42:16 PDT Received: from Chardonnay.ms by ArpaGateway.ms ; 20 AUG 88 10:42:37 PDT Return-Path: Redistributed: commonloops.PA Received: from SAIL.Stanford.EDU ([10.0.0.11]) by Xerox.COM ; 20 AUG 88 10:41:32 PDT Message-Id: Date: 20 Aug 88 10:41 PDT From: Dick Gabriel Subject: CLOS needs an UNDEFMETHOD To: Salem@THINK.COM Cc: commonloops.PA@Xerox.COM From the tone of your message, this seemed to be the step you found unpleasant: ENSURE-GENERIC-FUNCTION This appears to be the only way to get the generic function object from a symbol name. You could have used SYMBOL-FUNCTION, but then you would need to test whether the result was a generic function. -rpg- From Owners-CommonLoops.pa@Xerox.COM Mon Aug 22 05:33:38 1988 Received: from Xerox.COM by arisia.Xerox.COM (4.0/SMI-DDN) id AA12468; Mon, 22 Aug 88 05:33:38 PDT Received: from Salvador.ms by ArpaGateway.ms ; 22 AUG 88 05:18:08 PDT Return-Path: Redistributed: CommonLoops.pa Received: from Think.COM ([10.4.0.6]) by Xerox.COM ; 22 AUG 88 05:16:40 PDT Received: from fafnir.think.com by Think.COM; Mon, 22 Aug 88 08:16:25 EDT Received: from Think.COM by fafnir.think.com; Mon, 22 Aug 88 08:16:06 EDT Return-Path: Received: from PEBBLES.BBN.COM by Think.COM; Mon, 22 Aug 88 08:16:15 EDT Message-Id: <8808221216.AA26135@Think.COM> To: Jim Salem Cc: commonloops@Think.COM Subject: Re: CLOS needs an UNDEFMETHOD In-Reply-To: Your message of Fri, 19 Aug 88 16:56:00 -0400. <19880819205643.5.SALEM@POLYCARP.THINK.COM> Date: Mon, 22 Aug 88 08:16:20 -0400 From: kanderso@pebbles.bbn.com The function parse-method-or-spec should do most of the work you need. Acutally on 3600's M-x kill definition should work. Also, we have PCL working with presentations so we can do such things by mouse clicks. k From Owners-commonloops.pa@Xerox.COM Mon Aug 22 09:42:39 1988 Received: from Xerox.COM by arisia.Xerox.COM (4.0/SMI-DDN) id AA13334; Mon, 22 Aug 88 09:42:39 PDT Received: from Cabernet.ms by ArpaGateway.ms ; 22 AUG 88 09:25:57 PDT Return-Path: <@MCC.COM:halasz%sw.MCC.COM@MCC.COM> Redistributed: commonloops.pa Received: from MCC.COM ([10.3.0.62]) by Xerox.COM ; 22 AUG 88 09:24:02 PDT Received: from milano.sw.mcc.com by MCC.COM with TCP/SMTP; Mon 22 Aug 88 11:23:46-CDT Received: from oryan.sw.mcc.com by milano.sw.mcc.com (5.51/STP1.56) id AA03837; Mon, 22 Aug 88 11:24:04 CDT Date: Mon, 22 Aug 88 11:23:58 CDT From: Frank Halasz Message-Id: <8808221623.AA14273@oryan.sw.mcc.com> Received: by oryan.sw.mcc.com (3.2/STP1.14) id AA14273; Mon, 22 Aug 88 11:23:58 CDT To: commonloops.pa@Xerox.COM Subject: Problem with generic function caches in EXCL (aka Allegro CL) Cc: deli-bugs%sw.MCC.COM@MCC.COM, halasz%sw.MCC.COM@MCC.COM In performance tuning our CLOS-based window system, I noticed an inordinate number of generic function cache misses. In tracking this down, I discovered that (almost) all caches appeared to be only 1/4 full and that the cache misses were being caused by collisions in the cache. I believe the source of this problem is as follows: The macros object-cache-no and generic-function-cache-offset compute a hash-key based on the address of the object's class and a mask. For generic functions with one method and for a cache size of 32, this hash-key is essentially bits 2 thru 5 (where bit 1 is the low order bit) of the address of the object's class. The problem is that classes appear to be double-word aligned (actually double word aligned plus 1, since (excl::pointer-to-fixnum class) always returns a value that is 1 in mod 8). Thus bits 2 and 3 are always the same, leaving only 4 unique hash-keys (determined by bits 4 and 5) rather than the 16 intended. This problem becomes less severe as the number of specialized arguments goes up, but since 95%+ of our functions have a single specialized argument we were getting only 1/4 use out of nearly all of our caches. I solved this problem by rewriting object-cache-no to shift the address three bits to the right as follows: In excl-low.lisp -- (defmacro object-cache-no (object mask) `(logand (%ash (the fixnum (excl::pointer-to-fixnum ,object)) 3) (the fixnum ,mask))) (defmacro %ash (fixnum count) ;; This is very dangerous and shouldn't be done. But ... ;; EXCL ash appears to be just too slow to be of use. But then maybe I ;; just don't know the right compiler declarations. `(comp::.primcall 'shift-right ,fixnum ,count)) This change got rid of nearly all of our cache misses and sped up the system by about 10% (obviously something else is dominating the time!). My guess is that the doubling of the cache size suggested by Jim Larus a few months back is another solution to the same problem (i.e., decreasing the number of collisions in the cache), but one that still wastes 3/4 of the cache space (for singly specalized functions). CAVEAT: I am running on a very old PCL (87/8/27) and on Allegro 3.0.1. I checked the sources for the 88/8/2 version of PCL and as far as I can tell, the object-cache-no/generic-function-cache-offset scheme hasn't changed (in essence) at all. Hence I am assuming that this problem and its fix will hold for the latest PCL, but I haven't tried it out myself. -- Frank --------------------------------------------------- Frank Halasz MCC Software Technology 3500 West Balcones Center Drive Austin TX 78759. [512]338-3648 halasz@MCC.COM or {harvard,ihnp4,nike,seismo}!ut-sally!im4u!milano!halasz From Owners-commonloops.pa@Xerox.COM Mon Aug 22 13:26:14 1988 Received: from Xerox.COM by arisia.Xerox.COM (4.0/SMI-DDN) id AB16774; Mon, 22 Aug 88 13:26:14 PDT Received: from Riesling.ms by ArpaGateway.ms ; 22 AUG 88 13:24:37 PDT Return-Path: Redistributed: commonloops.pa Received: from SRI-ROBOTX.ARPA ([128.18.3.100]) by Xerox.COM ; 22 AUG 88 13:22:45 PDT Date: Mon, 22 Aug 88 13:19:24 PST From: Doug Ruth Subject: VAX compilation errors To: commonloops.pa@Xerox.COM Message-Id: <588284365.0.RUTH@SRI-ROBOTX.ARPA> Mail-System-Version: I'm having trouble compiling the files boot.lisp and vector.lisp on or VAX running VAX LISP V2.1. In boot.lisp the errors are in the functions MAKE-PARAMETER-REFERENCES and FIX-EARLY-GENERIC-FUNCTIONS. In vector.lisp the error is in the function LOOKUP-PV-N. I have included a log of the compilation session invoked with (compile-pcl) at the end of this message. I'd appreciate any help on this. Thanks, Doug Ruth Robotics Laboratory SRI International (415) 859-3860 Mailing Address: SRI International 333 Ravenswood Avenue, EL286 Menlo Park, CA 94025 ARPA Net Address: ruth@sri-robotx.arpa xxxxxxxxxxxxxxxxxxxx cut here xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx . . . Finished compilation of file USR0:[CLOS]DEFS.LISP;1 0 Errors, 7 Warnings Loading binary of DEFS... Compiling BOOT... Starting compilation of file USR0:[CLOS]BOOT.LISP;1 REDIRECT-EARLY-FUNCTION-INTERNAL compiled. DEFMETHOD compiled. DEFMETHOD-SETF compiled. METHOD-PROTOTYPE-FOR-GF compiled. EXPAND-DEFMETHOD compiled. EXPAND-DEFMETHOD-SETF compiled. EXPAND-DEFMETHOD-INTERNAL compiled. ADD-LEXICAL-FUNCTIONS-TO-METHOD-LAMBDA compiled. Error in MAKE-PARAMETER-REFERENCES Compile time error while executing MACROEXPAND-1 Error signalled by ERROR Error message would have been: "Argument must be a list: #((SYSTEM::%COMPILED-CLOSURE% (#((SYSTEM::%COMPILED-CLOSURE% (#(NIL NIL ((#:G5683 ((SYSTEM::%COMPILED-CLOSURE% (#(NIL ((ITERATE::TAIL . #:G8556) (ITERATE::HEAD . #:G8555)) NIL)) #) NIL NIL NIL))))) #) NIL ((#:G5683 ((SYSTEM::%COMPILED-CLOSURE% (#(NIL ((ITERATE::TAIL . #:G8556) (ITERATE::HEAD . #:G8555)) NIL)) #) NIL NIL (ITERATE::VALUE)))))) #) NIL ((#:G5683 ((SYSTEM::%COMPILED-CLOSURE% (#(NIL ((ITERATE::TAIL . #:G8556) (ITERATE::HEAD . #:G8555)) NIL)) #) (NULL ITERATE::HEAD) NIL (ITERATE::VALUE)))))" METHOD-FUNCTION-PLIST compiled. |SETF METHOD-FUNCTION-PLIST| compiled. METHOD-FUNCTION-GET compiled. |SETF METHOD-FUNCTION-GET| compiled. METHOD-FUNCTION-ISL compiled. METHOD-FUNCTION-NEEDS-NEXT-METHODS-P compiled. LOAD-DEFMETHOD compiled. LOAD-DEFMETHOD-SETF compiled. LOAD-DEFMETHOD-INTERNAL compiled. MAKE-METHOD-SPEC compiled. Warning in ENSURE-GENERIC-FUNCTION GENERIC-FUNCTION-CLASS bound but value not used. ENSURE-GENERIC-FUNCTION compiled. EARLY-ENSURE-GF-INTERNAL compiled. EARLY-GF-METHODS compiled. EARLY-GF-DISCRIMINATOR-CODE compiled. Warning in REAL-ENSURE-GF-INTERNAL METHOD-COMBINATION bound but value not used. Warning in REAL-ENSURE-GF-INTERNAL DOCUMENTATION bound but value not used. Warning in REAL-ENSURE-GF-INTERNAL DECLARATIONS bound but value not used. Warning in REAL-ENSURE-GF-INTERNAL ARGUMENT-PRECEDENCE-ORDER bound but value not used. Warning in REAL-ENSURE-GF-INTERNAL LAMBDA-LIST bound but value not used. REAL-ENSURE-GF-INTERNAL compiled. EARLY-MAKE-A-METHOD compiled. REAL-MAKE-A-METHOD compiled. EARLY-METHOD-SPECIALIZERS compiled. EARLY-ADD-NAMED-METHOD compiled. ADD-METHOD compiled. REMOVE-METHOD compiled. EARLY-UPDATE-DISCRIMINATOR-CODE compiled. EARLY-LOOKUP-METHOD compiled. Error in FIX-EARLY-GENERIC-FUNCTIONS Compile time error while executing CONS Error signalled by ERROR Error message would have been: "Too many arguments, 3, to function #" Warning in MAKE-TOP-LEVEL-FORM NAME bound but value not used. MAKE-TOP-LEVEL-FORM compiled. MAKE-PROGN compiled. PARSE-DEFMETHOD compiled. PARSE-SPECIALIZERS compiled. UNPARSE-SPECIALIZERS compiled. PARSE-METHOD-OR-SPEC compiled. SPECIALIZED-LAMBDA-LIST-PARAMETERS compiled. SPECIALIZED-LAMBDA-LIST-LAMBDA-LIST compiled. SPECIALIZED-LAMBDA-LIST-SPECIALIZERS compiled. PARSE-SPECIALIZED-LAMBDA-LIST compiled. WITH-SLOTS compiled. WITH-ACCESSORS compiled. EXPAND-WITH-SLOTS compiled. EXPAND-WITH-SLOTS-INTERNAL compiled. Finished compilation of file USR0:[CLOS]BOOT.LISP;1 2 Errors, 7 Warnings Errors were detected in the following functions: MAKE-PARAMETER-REFERENCES FIX-EARLY-GENERIC-FUNCTIONS The following are assumed to be functions, but were not declared or defined: GENERIC-FUNCTION-P CLASS-PROTOTYPE GENERIC-FUNCTION-METHOD-CLASS CLASS-NAME CLASS-OF MAKE-PARAMETER-REFERENCES CAN-OPTIMIZE-ACCESS OPTIMIZE-SLOT-VALUE OPTIMIZE-SET-SLOT-VALUE OPTIMIZE-STANDARD-INSTANCE-ACCESS SORT-SLOTS-INTO-ISL ADD-PV-BINDING INTERN-SLOT-LISTS ADD-NAMED-METHOD MAKE-INSTANCE MAKE-A-METHOD BOOTSTRAP-GET-SLOT ALLOCATE-INSTANCE CLASS-WRAPPER CLASS-NO-OF-INSTANCE-SLOTS INITIALIZE REAL-ADD-METHOD SET-SLOT-VALUE CLASSP METHOD-TYPE-SPECIFIERS METHOD-P METHOD-GENERIC-FUNCTION GENERIC-FUNCTION-NAME METHOD-QUALIFIERS GET-METHOD Loading binary of BOOT... Compiling VECTOR... Starting compilation of file USR0:[CLOS]VECTOR.LISP;1 MAKE-INTERN-LIST-TABLE compiled. INTERN-IN-LIST-TABLE compiled. INTERN-SLOT-LISTS-1 compiled. INTERN-SLOT-LISTS-2 compiled. INTERN-SLOT-LISTS compiled. LOOKUP-PV compiled. LOOKUP-PV-1 compiled. LOOKUP-PV-2 compiled. LOOKUP-PV-3 compiled. Error in LOOKUP-PV-N Compile time error while executing MACROEXPAND-1 Error signalled by ERROR Error message would have been: "Argument must be a list: #((SYSTEM::%COMPILED-CLOSURE% (#((SYSTEM::%COMPILED-CLOSURE% (#(NIL NIL ((#:G5683 ((SYSTEM::%COMPILED-CLOSURE% (#(NIL ((ITERATE::TAIL . #:G9278) (ITERATE::HEAD . #:G9277)) NIL)) #) NIL NIL NIL))))) #) NIL ((#:G5683 ((SYSTEM::%COMPILED-CLOSURE% (#(NIL ((ITERATE::TAIL . #:G9278) (ITERATE::HEAD . #:G9277)) NIL)) #) NIL NIL (ITERATE::VALUE)))))) #) NIL ((#:G5683 ((SYSTEM::%COMPILED-CLOSURE% (#(NIL ((ITERATE::TAIL . #:G9278) (ITERATE::HEAD . #:G9277)) NIL)) #) (NULL ITERATE::HEAD) NIL (ITERATE::VALUE)))))" . . . xxxxxxxxxxxxxxxxxxxx cut here xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx ------- From Owners-commonloops.pa@Xerox.COM Mon Aug 22 17:28:21 1988 Received: from Xerox.COM by arisia.Xerox.COM (4.0/SMI-DDN) id AB19683; Mon, 22 Aug 88 17:28:21 PDT Received: from Riesling.ms by ArpaGateway.ms ; 22 AUG 88 17:31:18 PDT Return-Path: Redistributed: commonloops.pa Received: from fs3.cs.rpi.edu ([128.213.1.14]) by Xerox.COM ; 22 AUG 88 17:29:59 PDT Received: by fs3.cs.rpi.edu (5.54/1.2-RPI-CS-Dept) id AA00586; Mon, 22 Aug 88 20:26:34 EDT Date: Mon, 22 Aug 88 20:26:35 EDT From: harrisr@turing.cs.rpi.edu (Richard Harris) Received: by turing.cs.rpi.edu (4.0/1.2-RPI-CS-Dept) id AA02338; Mon, 22 Aug 88 20:26:35 EDT Message-Id: <8808230026.AA02338@turing.cs.rpi.edu> To: commonloops.pa@Xerox.COM Subject: additions to KCL-LOW Add (or change) the following functions to KCL-LOW to improve its speed. The same cache miss problem that Frank Halasz reported in EXCL happens in KCL. Rick Harris (defmacro %logand (&rest args) (if (null args) -1 (labels ((bin (args) (if (null (cdr args)) `(the fixnum ,(car args)) `(the fixnum (logand (the fixnum ,(car args)) ,(bin (cdr args))))))) (bin args)))) (defmacro %logxor (&rest args) (if (null args) 0 (labels ((bin (args) (if (null (cdr args)) `(the fixnum ,(car args)) `(the fixnum (logxor (the fixnum ,(car args)) ,(bin (cdr args))))))) (bin args)))) (defmacro %+ (&rest args) (if (null args) 0 (labels ((bin (args) (if (null (cdr args)) `(the fixnum ,(car args)) `(the fixnum (+ (the fixnum ,(car args)) ,(bin (cdr args))))))) (bin args)))) (defmacro %1+ (x) `(the fixnum (1+ (the fixnum ,x)))) (defmacro %svref (vector index) `(svref (the simple-vector ,vector) (the fixnum ,index))) (defsetf %svref (vector index) (new-value) `(setf (svref (the simple-vector ,vector) (the fixnum ,index)) ,new-value)) ;; ;;;;;; Generating CACHE numbers ;; (unless (get 'si:address 'compiler::inline-always) (push '((t) fixnum nil nil "(int)#0") (get 'si:address 'compiler::inline-always))) ;symbols are (stored every) 9 words, so (ash x -2) is fine (defmacro symbol-cache-no (symbol mask) (if (and (constantp symbol) (constantp mask)) `(load-time-eval (logand (ash (si:address ,symbol) -2) ,mask)) `(%logand (ash (the fixnum (si:address ,symbol)) -2) ,mask))) ;structures are (stored every) 4 words, need (ash x -4) (defmacro object-cache-no (object mask) `(%logand (ash (the fixnum (si:address ,object)) -4) ,mask)) From Owners-CommonLoops.pa@Xerox.COM Tue Aug 23 02:22:25 1988 Received: from Xerox.COM by arisia.Xerox.COM (4.0/SMI-DDN) id AA26099; Tue, 23 Aug 88 02:22:25 PDT Received: from Semillon.ms by ArpaGateway.ms ; 23 AUG 88 02:26:28 PDT Return-Path: Redistributed: CommonLoops.pa Received: from Think.COM ([10.4.0.6]) by Xerox.COM ; 23 AUG 88 02:24:10 PDT Received: from fafnir.think.com by Think.COM; Tue, 23 Aug 88 05:23:49 EDT Return-Path: Received: from sauron.think.com by fafnir.think.com; Tue, 23 Aug 88 05:23:43 EDT Received: by sauron.think.com; Tue, 23 Aug 88 05:23:42 EDT Date: Tue, 23 Aug 88 05:23:42 EDT From: salem@Think.COM Message-Id: <8808230923.AA00820@sauron.think.com> To: commonloops@Think.COM Subject: Changes to CLOS {was: UNDEFMETHOD} {After suggesting that CLOS include UNDEFMETHOD . . .} I would appreciate someone filling us newcomers in on the current state of the CLOS standard. Particularly, is there still time to suggest changes that will make it into the final Common Lisp version ? The 6/88 CLOS spec. refers to "the usual editorial and cleanup processes" (page 1-1). What are these usual processes ? -- jim From Gregor.pa@Xerox.COM Wed Aug 24 10:41:01 1988 Return-Path: Received: from Xerox.COM by arisia.Xerox.COM (4.0/SMI-DDN) id AB12327; Wed, 24 Aug 88 10:41:01 PDT Received: from Semillon.ms by ArpaGateway.ms ; 24 AUG 88 10:30:34 PDT Date: Wed, 24 Aug 88 10:26 PDT From: Gregor.pa@Xerox.COM Subject: Re: Problem with generic function caches in EXCL (aka Allegro CL) To: Frank Halasz Cc: commonloops.pa@Xerox.COM, deli-bugs%sw.MCC.COM@MCC.COM Fcc: BD:>Gregor>mail>outgoing-mail-3.text.newest In-Reply-To: <8808221623.AA14273@oryan.sw.mcc.com> Message-Id: <19880824172615.0.GREGOR@PORTNOY.parc.xerox.com> Line-Fold: no Date: Mon, 22 Aug 88 11:23:58 CDT From: Frank Halasz In performance tuning our CLOS-based window system, I noticed an inordinate number of generic function cache misses. In tracking this down, I discovered that (almost) all caches appeared to be only 1/4 full and that the cache misses were being caused by collisions in the cache. Yes, this has been a problem for some time. Its funny you should send this message just now, since this whole mechanism is different in the version of PCL we are releasing today (AAAI PCL). In this new version of PCL, the offsets into caches are computed in a different way. At load time, each class is assigned a number from a special counter. The counter counts by 2, so for 1 class caches, there is no alignment of class numbers. Object-cache-no and symbol-cache-no are not used at all. When this version comes out, give it a try and see what happens to your performance. I also hope to distribute some rudimentary tools people can use to analyze their cache density and send the info back to me. I hope to get the cache hit rate pretty far up with this release. Later tuning should get it higher. I plan to add a facility to allow generic functions to have variable size caches. ------- From Gregor.pa@Xerox.COM Wed Aug 24 17:13:50 1988 Return-Path: Received: from Xerox.COM by arisia.Xerox.COM (4.0/SMI-DDN) id AB16084; Wed, 24 Aug 88 17:13:50 PDT Received: from Semillon.ms by ArpaGateway.ms ; 24 AUG 88 17:06:09 PDT Date: Wed, 24 Aug 88 17:02 PDT From: Gregor.pa@Xerox.COM Subject: new version of PCL To: CommonLoops.pa@Xerox.COM Fcc: BD:>Gregor>mail>outgoing-mail-3.text.newest Message-Id: <19880825000213.0.GREGOR@PORTNOY.parc.xerox.com> Line-Fold: no There is a new version of PCL in the /pcl directory on arisia.xerox.com. You can use anonymous FTP to retrieve it. As usual, you should retrieve all the *.lisp and *.text files. This version of PCL has been tested at PARC in the following Common Lisps: Symbolics 7.2 Coral 1.2 Lucid 3.0 Franz 3.0 Xerox Lyric Xerox Medley (aka EnvOS Medley) We are working on KCL right now and hope to have this release working in KCL sometime in the next couple of days. The notes.text file contains a detailed description of this version of PCL. The following is only a brief summary of those changes. This release contains the big changes which the 7/7 through 8/2 releases were really getting ready for. There are two, distinct major sets of changes in this release, along with a number of minor changes. The effect of the first major set of changes is to make the order of arguments to setf generic functions and methods conform with the spec. In addition, these changes allow the first argument to defmethod to be of the form (SETF ). The second major set of changes has to do with slot access and instance structure. These changes affect all the functions which access the slots of an instance. In addition, the generic functions which are called by the slot access functions in exceptional circumstances are affected. This set of changes also include the implemenentation of the real initialization protocol as specified by 88-002R. ------- From Owners-commonloops.PA@Xerox.COM Thu Aug 25 17:54:08 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP; Thu, 25 Aug 88 17:54:08 PDT Received: from Burger.ms by ArpaGateway.ms ; 25 AUG 88 13:35:10 PDT Return-Path: Redistributed: commonloops.PA Received: from tut.cis.ohio-state.edu ([128.146.8.60]) by Xerox.COM ; 25 AUG 88 13:32:24 PDT Received: by tut.cis.ohio-state.edu (5.54/2.880825) id AA14619; Thu, 25 Aug 88 16:31:29 EDT Date: Thu, 25 Aug 88 16:31:29 EDT From: welch@tut.cis.ohio-state.edu (Arun Welch) Message-Id: <8808252031.AA14619@tut.cis.ohio-state.edu> To: commonloops.PA@Xerox.COM, aisupport.PA@Xerox.COM Subject: PCL Environment files for Envos lisp Could someone stick a copy of the PCL-ENV files for Envos (Xerox) Lisp on arisia, hopefully for Medley as well as Lyric? Thanks. ...arun ---------------------------------------------------------------------------- Arun Welch Lisp Systems Programmer, Lab for AI Research, Ohio State University welch@tut.cis.ohio-state.edu From Owners-CommonLoops.pa@Xerox.COM Thu Aug 25 23:46:14 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP; Thu, 25 Aug 88 23:46:14 PDT Received: from Burger.ms by ArpaGateway.ms ; 25 AUG 88 10:59:12 PDT Return-Path: Redistributed: CommonLoops.pa Received: from Think.COM ([10.4.0.6]) by Xerox.COM ; 25 AUG 88 10:58:07 PDT Received: from fafnir.think.com by Think.COM; Thu, 25 Aug 88 13:56:49 EDT Received: from Think.COM by fafnir.think.com; Thu, 25 Aug 88 13:57:21 EDT Return-Path: Received: from Xerox.COM by Think.COM; Thu, 25 Aug 88 13:56:31 EDT Received: from Semillon.ms by ArpaGateway.ms ; 25 AUG 88 10:47:38 PDT Date: Thu, 25 Aug 88 10:46 PDT From: Gregor.pa@Xerox.COM Subject: Re: CLOS needs an UNDEFMETHOD To: Jim Salem Cc: commonloops@Think.COM Fcc: BD:>Gregor>mail>outgoing-mail-3.text.newest In-Reply-To: <19880819205643.5.SALEM@POLYCARP.THINK.COM> Message-Id: <19880825174614.1.GREGOR@PORTNOY.parc.xerox.com> Line-Fold: no Date: Fri, 19 Aug 88 16:56 EDT From: Jim Salem It appears to be very difficult to write an UNDEFMETHOD in standard CLOS. I suggest one be provided. There is a version of undefmethod in PCL. Unfortunately, the currently distributed one is a little difficult to use. This message has a description, and a patch for a new one. undefmethod is a macro, its argument list is: (UNDEFMETHOD NAME QUALIFIER* (SPECIALIZER*)) If specializers is shorter than the number of required arguments of the generic function it is padded with T's. This means that (defmethod foo ((x class) y z) ..) can be undone by: (undefmethod foo (class)) or by: (undefmethod foo (class t t t)) (defmethod bar :before (x (y class) z) ..) can be undone by: (undefmethod bar :before (t class)) or by: (undefmethod bar :before (t class t)) This version of undefmethod WAS NOT in the 8/24 version put on arisia yesterday. The version on arisia has now been patched to include the following patches. ;from boot.lisp (defun parse-method-or-spec (spec &optional (errorp t)) (declare (values generic-function method method-name)) (let (gf method name temp) (if (method-p spec) (setq method spec gf (method-generic-function method) temp (and gf (generic-function-name gf)) name (if temp (intern-function-name (make-method-spec temp (method-qualifiers method) (unparse-specializers (method-type-specifiers method)))) (make-symbol (format nil "~S" method)))) (multiple-value-bind (gf-spec quals specls) (parse-defmethod spec) (and (setq gf (and (or errorp (gboundp gf-spec)) (gdefinition gf-spec))) (let ((nreq (compute-discriminating-function-arglist-info gf))) (setq specls (append (parse-specializers specls) (make-list (- nreq (length specls)) :initial-element *the-class-t*))) (and (setq method (get-method gf quals specls errorp)) (setq name (intern-function-name (make-method-spec gf-spec quals specls)))))))) (values gf method name))) ;from high.lisp (defmacro undefmethod (&rest args) #+(or (not :lucid) :lcl3.0) (declare (arglist name {method-qualifier}* specializers)) `(undefmethod-1 .,args)) (defun undefmethod-1 (args) (multiple-value-bind (gf method) (parse-method-or-spec args) (when (and gf method) (remove-method gf method) method))) ;from high.lisp, delete the definition of undefmethod-setf ------- From Owners-commonloops.PA@Xerox.COM Fri Aug 26 03:06:39 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP; Thu, 25 Aug 88 17:54:08 PDT Received: from Burger.ms by ArpaGateway.ms ; 25 AUG 88 13:35:10 PDT Return-Path: Redistributed: commonloops.PA Received: from tut.cis.ohio-state.edu ([128.146.8.60]) by Xerox.COM ; 25 AUG 88 13:32:24 PDT Received: by tut.cis.ohio-state.edu (5.54/2.880825) id AA14619; Thu, 25 Aug 88 16:31:29 EDT Date: Thu, 25 Aug 88 16:31:29 EDT From: welch@tut.cis.ohio-state.edu (Arun Welch) Message-Id: <8808252031.AA14619@tut.cis.ohio-state.edu> To: commonloops.PA@Xerox.COM, aisupport.PA@Xerox.COM Subject: PCL Environment files for Envos lisp Could someone stick a copy of the PCL-ENV files for Envos (Xerox) Lisp on arisia, hopefully for Medley as well as Lyric? Thanks. ...arun ---------------------------------------------------------------------------- Arun Welch Lisp Systems Programmer, Lab for AI Research, Ohio State University welch@tut.cis.ohio-state.edu From Gregor.pa@Xerox.COM Fri Aug 26 03:16:55 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP; Fri, 26 Aug 88 03:16:55 PDT Received: from Semillon.ms by ArpaGateway.ms ; 25 AUG 88 11:24:42 PDT Date: Thu, 25 Aug 88 11:20 PDT From: Gregor.pa@Xerox.COM Subject: 8/24 PCL works in KCL To: CommonLoops.pa@Xerox.COM Fcc: BD:>Gregor>mail>outgoing-mail-3.text.newest Message-Id: <19880825182031.2.GREGOR@PORTNOY.parc.xerox.com> Line-Fold: no The version of PCL now on arisia works in KCL. Apparently, it always did work in KCL, I got faked out by Unix into thinking it didn't. The notes.text file has been updated to take this into account. ------- From Owners-commonloops.pa@Xerox.COM Fri Aug 26 03:21:40 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP; Fri, 26 Aug 88 03:21:40 PDT Received: from Cabernet.ms by ArpaGateway.ms ; 25 AUG 88 13:55:27 PDT Return-Path: Redistributed: commonloops.pa Received: from SRI-ROBOTX.ARPA ([128.18.3.100]) by Xerox.COM ; 25 AUG 88 13:53:14 PDT Date: Thu, 25 Aug 88 13:49:42 PST From: Doug Ruth Subject: VAXLisp V2.1 Compilation Error To: commonloops.pa@Xerox.COM Message-Id: <588545382.0.RUTH@SRI-ROBOTX.ARPA> Mail-System-Version: I still have problems compiling the file boot.lisp with the latest (8/24) release. Specifically the function MAKE-PARAMETER-REFERENCES will not compile. The VAXLisp compile debug switch does not seem to work when using the function COMPILE-PCL to compile the file. So I loaded the source boot.lisp (after loading the required binary files) and then invoked (COMPILE 'MAKE-PARAMETER-REFERENCES) to produce the traceback info included at the end of this message. Thanks for your help, Doug Ruth Robotics Laboratory SRI International (415) 859-3860 Mailing Address: SRI International 333 Ravenswood Avenue, EL286 Menlo Park, CA 94025 ARPA Net Address: ruth@sri-robotx.arpa xxxxxxxxxxxxxxxxxxxxxxxxx cut here xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx Dribbling to USR0:[CLOS.V082488]CF.LOG;2 Lisp> (load "boot.lisp") ; Loading contents of file USR0:[CLOS.V082488]BOOT.LISP;1 ; DEFMETHOD ; METHOD-PROTOTYPE-FOR-GF ; EXPAND-DEFMETHOD ; EXPAND-DEFMETHOD-INTERNAL ; ADD-LEXICAL-FUNCTIONS-TO-METHOD-LAMBDA ; MAKE-PARAMETER-REFERENCES ; METHOD-FUNCTION-PLIST ; |SETF METHOD-FUNCTION-PLIST| ; METHOD-FUNCTION-GET ; |SETF METHOD-FUNCTION-GET| ; METHOD-FUNCTION-ISL ; METHOD-FUNCTION-NEEDS-NEXT-METHODS-P ; LOAD-DEFMETHOD ; LOAD-DEFMETHOD-INTERNAL ; MAKE-METHOD-SPEC ; ENSURE-GENERIC-FUNCTION ; EARLY-ENSURE-GF-INTERNAL ; EARLY-GF-P ; EARLY-GF-METHODS ; EARLY-GF-DISCRIMINATOR-CODE ; REAL-ENSURE-GF-INTERNAL ; EARLY-MAKE-A-METHOD ; REAL-MAKE-A-METHOD ; EARLY-METHOD-SPECIALIZERS ; EARLY-ADD-NAMED-METHOD ; ADD-METHOD ; REMOVE-METHOD ; GET-METHOD ; EARLY-UPDATE-DISCRIMINATOR-CODE ; EARLY-LOOKUP-METHOD ; FIX-EARLY-GENERIC-FUNCTIONS ; MAKE-TOP-LEVEL-FORM ; MAKE-PROGN ; PARSE-DEFMETHOD ; PARSE-SPECIALIZERS ; UNPARSE-SPECIALIZERS ; PARSE-METHOD-OR-SPEC ; SPECIALIZED-LAMBDA-LIST-PARAMETERS ; SPECIALIZED-LAMBDA-LIST-LAMBDA-LIST ; SPECIALIZED-LAMBDA-LIST-SPECIALIZERS ; PARSE-SPECIALIZED-LAMBDA-LIST ; WITH-SLOTS ; WITH-ACCESSORS ; EXPAND-WITH-SLOTS ; EXPAND-WITH-SLOTS-INTERNAL ; Finished loading USR0:[CLOS.V082488]BOOT.LISP;1 T Lisp> (compile 'make-parameter-references) Fatal error in function MACROEXPAND-1 (signaled with ERROR). Argument must be a list: #((SYSTEM::%COMPILED-CLOSURE% (#((SYSTEM::%COMPILED-CLOSURE% (#(NIL NIL ((#:G5235 ((SYSTEM::%COMPILED-CLOSURE% (#(NIL ((ITERATE::TAIL . #:G5400) (ITERATE::HEAD . #:G5399)) NIL)) #) NIL NIL NIL))))) #) NIL ((#:G5235 ((SYSTEM::%COMPILED-CLOSURE% (#(NIL ((ITERATE::TAIL . #:G5400) (ITERATE::HEAD . #:G5399)) NIL)) #) NIL NIL (ITERATE::VALUE)))))) #) NIL ((#:G5235 ((SYSTEM::%COMPILED-CLOSURE% (#(NIL ((ITERATE::TAIL . #:G5400) (ITERATE::HEAD . #:G5399)) NIL)) #) (NULL ITERATE::HEAD) NIL (ITERATE::VALUE))))) Control Stack Debugger Frame #28: (MACROEXPAND-1 (NULL ITERATE::HEAD) (SYSTEM::%COMPILED-CLOSURE% (#((SYSTEM::%COMPILED-CLOSURE% (#((SYSTEM::%COMPILED-CLOSURE% (#(NIL NIL ((#:G5235 ((SYSTEM::%COMPILED-CLOSURE% (#(NIL ((ITERATE::TAIL . #:G5400) (ITERATE::HEAD . #:G5399)) NIL)) #) NIL NIL NIL))))) #) NIL ((#:G5235 ((SYSTEM::%COMPILED-CLOSURE% (#(NIL ((ITERATE::TAIL . #:G5400) (ITERATE::HEAD . #:G5399)) NIL)) #) NIL NIL (ITERATE::VALUE)))))) #) NIL ((#:G5235 ((SYSTEM::%COMPILED-CLOSURE% (#(NIL ((ITERATE::TAIL . #:G5400) (ITERATE::HEAD . #:G5399)) NIL)) #) (NULL ITERATE::HEAD) NIL (ITERATE::VALUE)))))) #)) Debug 1> backtrace -- Backtrace start -- Frame #28: (MACROEXPAND-1 (NULL ITERATE::HEAD) (SYSTEM::%COMPILED-CLOSURE% (#((SYSTEM::%COMPILED-CLOSURE% (#((SYSTEM::%COMPILED-CLOSURE% (#(NIL NIL ((#:G5235 ((SYSTEM::%COMPILED-CLOSURE% (#(NIL ((ITERATE::TAIL . #:G5400) (ITERATE::HEAD . #:G5399)) NIL)) #) NIL NIL NIL))))) #) NIL ((#:G5235 ((SYSTEM::%COMPILED-CLOSURE% (#(NIL ((ITERATE::TAIL . #:G5400) (ITERATE::HEAD . #:G5399)) NIL)) #) NIL NIL (ITERATE::VALUE)))))) #) NIL ((#:G5235 ((SYSTEM::%COMPILED-CLOSURE% (#(NIL ((ITERATE::TAIL . #:G5400) (ITERATE::HEAD . #:G5399)) NIL)) #) (NULL ITERATE::HEAD) NIL (ITERATE::VALUE)))))) #)) Frame #19: (GATHERING (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))))) NIL) Frame #18: (SYSTEM::TRANSFORM (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)))))) Frame #3: (COMPILE MAKE-PARAMETER-REFERENCES NIL) Frame #1: (EVAL (COMPILE (QUOTE MAKE-PARAMETER-REFERENCES))) -- Backtrace end -- Frame #28: (MACROEXPAND-1 (NULL ITERATE::HEAD) (SYSTEM::%COMPILED-CLOSURE% (#((SYSTEM::%COMPILED-CLOSURE% (#((SYSTEM::%COMPILED-CLOSURE% (#(NIL NIL ((#:G5235 ((SYSTEM::%COMPILED-CLOSURE% (#(NIL ((ITERATE::TAIL . #:G5400) (ITERATE::HEAD . #:G5399)) NIL)) #) NIL NIL NIL))))) #) NIL ((#:G5235 ((SYSTEM::%COMPILED-CLOSURE% (#(NIL ((ITERATE::TAIL . #:G5400) (ITERATE::HEAD . #:G5399)) NIL)) #) NIL NIL (ITERATE::VALUE)))))) #) NIL ((#:G5235 ((SYSTEM::%COMPILED-CLOSURE% (#(NIL ((ITERATE::TAIL . #:G5400) (ITERATE::HEAD . #:G5399)) NIL)) #) (NULL ITERATE::HEAD) NIL (ITERATE::VALUE)))))) #)) Debug 1> quit Lisp> (dribble) xxxxxxxxxxxxxxxxxxxxxxxxx cut here xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx ------- From Gregor.pa@Xerox.COM Fri Aug 26 03:24:02 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP; Fri, 26 Aug 88 03:24:02 PDT Received: from Semillon.ms by ArpaGateway.ms ; 25 AUG 88 11:41:44 PDT Date: Thu, 25 Aug 88 11:35 PDT From: Gregor.pa@Xerox.COM Subject: Re: exporting standard-class To: Bruce Esrig Cc: commonloops.pa@Xerox.COM Fcc: BD:>Gregor>mail>outgoing-mail-3.text.newest In-Reply-To: <8808191800.AA16009@oravax.UUCP> Message-Id: <19880825183517.5.GREGOR@PORTNOY.parc.xerox.com> Line-Fold: no Date: Fri, 19 Aug 88 14:00:10 EDT From: oravax!esrig@cu-arpa.cs.cornell.edu (Bruce Esrig) In a previous query, we asked whether there were any problems porting pcl to Lucid; we reported that when we make an instance, we get a message stating that there is no matching method for the generic function initialize-instance. We now know that the cause of the problem was that we had created a class with an undefined metaclass. The following definition illustrates our problem. (in-package 'my-package :use '(lisp pcl system)) (defclass topmost_class (standard-class) ()) (make-instance 'topmost_class) In this definition, standard-class refers to the internal symbol of my-package. Should the classes standard-class and above be exported by the pcl package ? If they were, this problem would not occur. Alternatively, should there be a way to get warning messages when forward definitions of class names occur ? I future versions of PCL, there will be two changes, each of which will provide you some help with this problem. 1) symbols like standard-class will be exported from the PCL package. 2) attempting to make an instance of a class which has forward referenced supers will signal an error. ------- From Gregor.pa@Xerox.COM Fri Aug 26 03:28:20 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP; Fri, 26 Aug 88 03:28:20 PDT Received: from Semillon.ms by ArpaGateway.ms ; 25 AUG 88 16:28:23 PDT Date: Thu, 25 Aug 88 16:24 PDT From: Gregor.pa@Xerox.COM Subject: bug with :accessor-prefix To: CommonLoops.pa@Xerox.COM Fcc: BD:>Gregor>mail>outgoing-mail-3.text.newest Message-Id: <19880825232442.3.GREGOR@PORTNOY.parc.xerox.com> Line-Fold: no The 8/24 version has a bug which crops up when the :accessor-prefix option is used with no argument. I am somewhat loathe to fix this since :accessor-prefix is now obsolete, but here is the fix. The version on arisia has been modified to include this patch. ;from defclass.lisp (defun merge-accessor/reader-prefixes (slotds class-options) (dolist (class-option class-options) (flet ((do-prefix (slot-name) (if (cadr class-option) (symbol-append (cadr class-option) slot-name) slot-name))) (when (listp class-option) (case (car class-option) (:accessor-prefix (dolist (slotd slotds) (let ((name (do-prefix (slotd-name slotd)))) (pushnew name (slotd-readers slotd)) (pushnew `(setf ,name) (slotd-writers slotd) :test #'equal)))) (:reader-prefix (dolist (slotd slotds) (let ((name (do-prefix (slotd-name slotd)))) (pushnew name (slotd-readers slotd)))))))))) ------- From Owners-commonloops.pa@Xerox.COM Fri Aug 26 18:48:24 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP; Fri, 26 Aug 88 18:48:24 PDT Received: from Salvador.ms by ArpaGateway.ms ; 26 AUG 88 16:24:45 PDT Return-Path: Redistributed: commonloops.pa Received: from ucbarpa.Berkeley.EDU ([10.0.0.78]) by Xerox.COM ; 26 AUG 88 16:22:52 PDT Received: by ucbarpa.Berkeley.EDU (5.59/1.29) id AA17200; Fri, 26 Aug 88 16:22:08 PDT Received: from frisky by franz (3.2/3.14) id AA11214; Fri, 26 Aug 88 16:15:54 PDT Received: by frisky (3.2/3.14) id AA21951; Fri, 26 Aug 88 16:14:25 PDT From: jkf%frisky%franz@ucbarpa.Berkeley.EDU (John Foderaro) Return-Path: Message-Id: <8808262314.AA21951@frisky> To: commonloops.pa@Xerox.COM Subject: fix for allegro (excl) on sun4 Date: Fri, 26 Aug 88 16:14:23 PDT in version: 8/24/88 (beta) AAAI PCL obtained: 8/26/88 2pm pdt file: fin.lisp under the #+excl #+(and gsgc sun4) conditionalization the function allocate-funcallable-instance-1 has the line (set-funcallable-instance-function new-fin #'init-fn-fun) it should be (set-funcallable-instance-function new-fin #'init-fin-fun) ^---- add the i From Gregor.pa@Xerox.COM Sat Aug 27 15:35:33 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP; Fri, 26 Aug 88 03:24:02 PDT Received: from Semillon.ms by ArpaGateway.ms ; 25 AUG 88 11:41:44 PDT Date: Thu, 25 Aug 88 11:35 PDT From: Gregor.pa@Xerox.COM Subject: Re: exporting standard-class To: Bruce Esrig Cc: commonloops.pa@Xerox.COM Fcc: BD:>Gregor>mail>outgoing-mail-3.text.newest In-Reply-To: <8808191800.AA16009@oravax.UUCP> Message-Id: <19880825183517.5.GREGOR@PORTNOY.parc.xerox.com> Line-Fold: no Date: Fri, 19 Aug 88 14:00:10 EDT From: oravax!esrig@cu-arpa.cs.cornell.edu (Bruce Esrig) In a previous query, we asked whether there were any problems porting pcl to Lucid; we reported that when we make an instance, we get a message stating that there is no matching method for the generic function initialize-instance. We now know that the cause of the problem was that we had created a class with an undefined metaclass. The following definition illustrates our problem. (in-package 'my-package :use '(lisp pcl system)) (defclass topmost_class (standard-class) ()) (make-instance 'topmost_class) In this definition, standard-class refers to the internal symbol of my-package. Should the classes standard-class and above be exported by the pcl package ? If they were, this problem would not occur. Alternatively, should there be a way to get warning messages when forward definitions of class names occur ? I future versions of PCL, there will be two changes, each of which will provide you some help with this problem. 1) symbols like standard-class will be exported from the PCL package. 2) attempting to make an instance of a class which has forward referenced supers will signal an error. ------- From Owners-commonloops.pa@Xerox.COM Sat Aug 27 16:05:33 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP; Fri, 26 Aug 88 03:21:40 PDT Received: from Cabernet.ms by ArpaGateway.ms ; 25 AUG 88 13:55:27 PDT Return-Path: Redistributed: commonloops.pa Received: from SRI-ROBOTX.ARPA ([128.18.3.100]) by Xerox.COM ; 25 AUG 88 13:53:14 PDT Date: Thu, 25 Aug 88 13:49:42 PST From: Doug Ruth Subject: VAXLisp V2.1 Compilation Error To: commonloops.pa@Xerox.COM Message-Id: <588545382.0.RUTH@SRI-ROBOTX.ARPA> Mail-System-Version: I still have problems compiling the file boot.lisp with the latest (8/24) release. Specifically the function MAKE-PARAMETER-REFERENCES will not compile. The VAXLisp compile debug switch does not seem to work when using the function COMPILE-PCL to compile the file. So I loaded the source boot.lisp (after loading the required binary files) and then invoked (COMPILE 'MAKE-PARAMETER-REFERENCES) to produce the traceback info included at the end of this message. Thanks for your help, Doug Ruth Robotics Laboratory SRI International (415) 859-3860 Mailing Address: SRI International 333 Ravenswood Avenue, EL286 Menlo Park, CA 94025 ARPA Net Address: ruth@sri-robotx.arpa xxxxxxxxxxxxxxxxxxxxxxxxx cut here xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx Dribbling to USR0:[CLOS.V082488]CF.LOG;2 Lisp> (load "boot.lisp") ; Loading contents of file USR0:[CLOS.V082488]BOOT.LISP;1 ; DEFMETHOD ; METHOD-PROTOTYPE-FOR-GF ; EXPAND-DEFMETHOD ; EXPAND-DEFMETHOD-INTERNAL ; ADD-LEXICAL-FUNCTIONS-TO-METHOD-LAMBDA ; MAKE-PARAMETER-REFERENCES ; METHOD-FUNCTION-PLIST ; |SETF METHOD-FUNCTION-PLIST| ; METHOD-FUNCTION-GET ; |SETF METHOD-FUNCTION-GET| ; METHOD-FUNCTION-ISL ; METHOD-FUNCTION-NEEDS-NEXT-METHODS-P ; LOAD-DEFMETHOD ; LOAD-DEFMETHOD-INTERNAL ; MAKE-METHOD-SPEC ; ENSURE-GENERIC-FUNCTION ; EARLY-ENSURE-GF-INTERNAL ; EARLY-GF-P ; EARLY-GF-METHODS ; EARLY-GF-DISCRIMINATOR-CODE ; REAL-ENSURE-GF-INTERNAL ; EARLY-MAKE-A-METHOD ; REAL-MAKE-A-METHOD ; EARLY-METHOD-SPECIALIZERS ; EARLY-ADD-NAMED-METHOD ; ADD-METHOD ; REMOVE-METHOD ; GET-METHOD ; EARLY-UPDATE-DISCRIMINATOR-CODE ; EARLY-LOOKUP-METHOD ; FIX-EARLY-GENERIC-FUNCTIONS ; MAKE-TOP-LEVEL-FORM ; MAKE-PROGN ; PARSE-DEFMETHOD ; PARSE-SPECIALIZERS ; UNPARSE-SPECIALIZERS ; PARSE-METHOD-OR-SPEC ; SPECIALIZED-LAMBDA-LIST-PARAMETERS ; SPECIALIZED-LAMBDA-LIST-LAMBDA-LIST ; SPECIALIZED-LAMBDA-LIST-SPECIALIZERS ; PARSE-SPECIALIZED-LAMBDA-LIST ; WITH-SLOTS ; WITH-ACCESSORS ; EXPAND-WITH-SLOTS ; EXPAND-WITH-SLOTS-INTERNAL ; Finished loading USR0:[CLOS.V082488]BOOT.LISP;1 T Lisp> (compile 'make-parameter-references) Fatal error in function MACROEXPAND-1 (signaled with ERROR). Argument must be a list: #((SYSTEM::%COMPILED-CLOSURE% (#((SYSTEM::%COMPILED-CLOSURE% (#(NIL NIL ((#:G5235 ((SYSTEM::%COMPILED-CLOSURE% (#(NIL ((ITERATE::TAIL . #:G5400) (ITERATE::HEAD . #:G5399)) NIL)) #) NIL NIL NIL))))) #) NIL ((#:G5235 ((SYSTEM::%COMPILED-CLOSURE% (#(NIL ((ITERATE::TAIL . #:G5400) (ITERATE::HEAD . #:G5399)) NIL)) #) NIL NIL (ITERATE::VALUE)))))) #) NIL ((#:G5235 ((SYSTEM::%COMPILED-CLOSURE% (#(NIL ((ITERATE::TAIL . #:G5400) (ITERATE::HEAD . #:G5399)) NIL)) #) (NULL ITERATE::HEAD) NIL (ITERATE::VALUE))))) Control Stack Debugger Frame #28: (MACROEXPAND-1 (NULL ITERATE::HEAD) (SYSTEM::%COMPILED-CLOSURE% (#((SYSTEM::%COMPILED-CLOSURE% (#((SYSTEM::%COMPILED-CLOSURE% (#(NIL NIL ((#:G5235 ((SYSTEM::%COMPILED-CLOSURE% (#(NIL ((ITERATE::TAIL . #:G5400) (ITERATE::HEAD . #:G5399)) NIL)) #) NIL NIL NIL))))) #) NIL ((#:G5235 ((SYSTEM::%COMPILED-CLOSURE% (#(NIL ((ITERATE::TAIL . #:G5400) (ITERATE::HEAD . #:G5399)) NIL)) #) NIL NIL (ITERATE::VALUE)))))) #) NIL ((#:G5235 ((SYSTEM::%COMPILED-CLOSURE% (#(NIL ((ITERATE::TAIL . #:G5400) (ITERATE::HEAD . #:G5399)) NIL)) #) (NULL ITERATE::HEAD) NIL (ITERATE::VALUE)))))) #)) Debug 1> backtrace -- Backtrace start -- Frame #28: (MACROEXPAND-1 (NULL ITERATE::HEAD) (SYSTEM::%COMPILED-CLOSURE% (#((SYSTEM::%COMPILED-CLOSURE% (#((SYSTEM::%COMPILED-CLOSURE% (#(NIL NIL ((#:G5235 ((SYSTEM::%COMPILED-CLOSURE% (#(NIL ((ITERATE::TAIL . #:G5400) (ITERATE::HEAD . #:G5399)) NIL)) #) NIL NIL NIL))))) #) NIL ((#:G5235 ((SYSTEM::%COMPILED-CLOSURE% (#(NIL ((ITERATE::TAIL . #:G5400) (ITERATE::HEAD . #:G5399)) NIL)) #) NIL NIL (ITERATE::VALUE)))))) #) NIL ((#:G5235 ((SYSTEM::%COMPILED-CLOSURE% (#(NIL ((ITERATE::TAIL . #:G5400) (ITERATE::HEAD . #:G5399)) NIL)) #) (NULL ITERATE::HEAD) NIL (ITERATE::VALUE)))))) #)) Frame #19: (GATHERING (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))))) NIL) Frame #18: (SYSTEM::TRANSFORM (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)))))) Frame #3: (COMPILE MAKE-PARAMETER-REFERENCES NIL) Frame #1: (EVAL (COMPILE (QUOTE MAKE-PARAMETER-REFERENCES))) -- Backtrace end -- Frame #28: (MACROEXPAND-1 (NULL ITERATE::HEAD) (SYSTEM::%COMPILED-CLOSURE% (#((SYSTEM::%COMPILED-CLOSURE% (#((SYSTEM::%COMPILED-CLOSURE% (#(NIL NIL ((#:G5235 ((SYSTEM::%COMPILED-CLOSURE% (#(NIL ((ITERATE::TAIL . #:G5400) (ITERATE::HEAD . #:G5399)) NIL)) #) NIL NIL NIL))))) #) NIL ((#:G5235 ((SYSTEM::%COMPILED-CLOSURE% (#(NIL ((ITERATE::TAIL . #:G5400) (ITERATE::HEAD . #:G5399)) NIL)) #) NIL NIL (ITERATE::VALUE)))))) #) NIL ((#:G5235 ((SYSTEM::%COMPILED-CLOSURE% (#(NIL ((ITERATE::TAIL . #:G5400) (ITERATE::HEAD . #:G5399)) NIL)) #) (NULL ITERATE::HEAD) NIL (ITERATE::VALUE)))))) #)) Debug 1> quit Lisp> (dribble) xxxxxxxxxxxxxxxxxxxxxxxxx cut here xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx ------- From Gregor.pa@Xerox.COM Sun Aug 28 18:19:55 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP; Sun, 28 Aug 88 18:19:55 PDT Received: from Semillon.ms by ArpaGateway.ms ; 28 AUG 88 17:47:59 PDT Date: Sun, 28 Aug 88 17:44 PDT From: Gregor.pa@Xerox.COM Subject: Rev 1 version of AAAI PCL To: CommonLoops.pa@Xerox.COM Fcc: BD:>Gregor>mail>outgoing-mail-3.text.newest Message-Id: <19880829004418.5.GREGOR@PORTNOY.parc.xerox.com> Line-Fold: no I am sure this will come as a surprise to you long time PCL users, but there are some bugs in the AAAI PCL. This message includes patches for the bugs that have come to my attention. In addition, the sources on arisia.xerox.com have been modified to include all of these patches. Everyone using the 8/24 (beta) AAAI PCL should make these changes or ftp a new set of files. Because a couple of these are nasty performance bugs, you should do this even if you haven't actually noticed a bug. As usual, enjoy. ;;;-*-Mode:LISP; Package:(PCL LISP 1000); Base:10; Syntax:Common-lisp -*- ;;; ;;; (in-package 'pcl) ;from file defsys.lisp (defvar *pcl-system-date* "8/28/88 (beta rev 1) AAAI PCL ") ;;; ;;; There is a bug in funcallable instances in ExCL on the SUN-4. When making ;;; this patch, be very sure to patch the correct line in the file. There ;;; is a line which currently looks like: ;;; ;;; (set-funcallable-instance-function new-fin #'init-fn-fun) ;;; ;;; It should look like: ;;; ;;; (set-funcallable-instance-function new-fin #'init-fin-fun) ;;; ;;; The difference is in the spelling of the last symbol on the line. ;;; ;;; ;;; The new initialization protocol will not work when the metaclass is ;;; funcallable standard-class. ;;; ;from fsc.lisp (defmethod allocate-instance ((class funcallable-standard-class) &rest initargs) (declare (ignore initargs)) (let ((class-wrapper (class-wrapper class))) (allocate-funcallable-instance class-wrapper (class-no-of-instance-slots class)))) ;;; ;;; There is a performance bug introduced by slot-unbound checking. ;;; ;from low.lisp ;;; ;;; This is the value that we stick into a slot to tell us that it is unbound. ;;; It may seem gross, but for performance reasons, we make this an interned ;;; symbol. That means that the fast check to see if a slot is unbound is to ;;; say (EQ '..SLOT-UNBOUND..). That is considerably faster than looking ;;; at the value of a special variable. ;;; (defvar *slot-unbound* '..slot-unbound..) ;from vector.lisp (defun std-instance-access-pv-internal (slots-fetcher instance pv-offset nvp new-value) (if nvp (once-only (new-value) `(let ((.index. (memory-block-ref .pv. ,pv-offset))) (if (null .index.) (pv-access-trap ,instance ,pv-offset .isl. ,new-value) (setf (%svref (,slots-fetcher ,instance) .index.) ,new-value)))) `(let ((.temp. (memory-block-ref .pv. ,pv-offset))) (if (or (null .temp.) (eq (setq .temp. (%svref (,slots-fetcher ,instance) .temp.)) ',*slot-unbound*)) (pv-access-trap ,instance ,pv-offset .isl.) .temp.)))) ;from dcode.lisp (define-function-template all-std-class-readers-dcode () '(.GENERIC-FUNCTION. .CACHE.) (let () `(function (lambda (arg) (locally (declare (optimize (speed 3) (safety 0))) (let* ((wrapper (and (iwmc-class-p arg) (iwmc-class-class-wrapper arg))) (offset 0) (val nil)) (if (null wrapper) (no-applicable-method .GENERIC-FUNCTION. arg) (progn (setq offset (cache-key-from-wrappers ,generic-function-cache-size 2 wrapper)) (without-interrupts (if (and (eq (r/w-cache-key) wrapper) (neq (setq val (%svref (iwmc-class-static-slots arg) (r/w-cache-val))) ',*slot-unbound*)) val (with-interrupts (all-std-class-readers-miss arg wrapper .cache. ,generic-function-cache-size offset .generic-function.)))))))))))) ;;; ;;; There may be a performance bug with some compiler settings in some Lisps. ;;; ;from low.lisp (defmacro %logand (&rest args) `(locally (declare (optimize (speed 3) (safety 0))) ,(reduce-variadic-to-binary 'logand args 0 t 'fixnum))) (defmacro %logxor (&rest args) `(locally (declare (optimize (speed 3) (safety 0))) ,(reduce-variadic-to-binary 'logxor args 0 t 'fixnum))) (defmacro %+ (&rest args) `(locally (declare (optimize (speed 3) (safety 0))) ,(reduce-variadic-to-binary '+ args 0 t 'fixnum))) (defmacro %1+ (x) `(locally (declare (optimize (speed 3) (safety 0))) (the fixnum (1+ (the fixnum ,x))))) (defmacro %svref (vector index) `(locally (declare (optimize (speed 3) (safety 0)) (inline svref)) (svref (the simple-vector ,vector) (the fixnum ,index)))) (defsetf %svref (vector index) (new-value) `(locally (declare (optimize (speed 3) (safety 0)) (inline svref)) (setf (svref (the simple-vector ,vector) (the fixnum ,index)) ,new-value))) ------- From Owners-commonloops.pa@Xerox.COM Mon Aug 29 07:11:17 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP; Mon, 29 Aug 88 07:11:17 PDT Received: from Chardonnay.ms by ArpaGateway.ms ; 29 AUG 88 07:09:54 PDT Return-Path: Redistributed: commonloops.pa Received: from siemens ([129.73.7.1]) by Xerox.COM ; 29 AUG 88 07:08:19 PDT Received: by siemens (5.54/1.15) id AA00875; Mon, 29 Aug 88 10:06:02 EDT From: adf@ztivax.siemens.com (Angela Dappert-Farquhar) Date: Mon, 29 Aug 88 16:07:07 -0200 Message-Id: <8808291407.AA04825@ztivax.uucp> Received: by ztivax.uucp; Mon, 29 Aug 88 16:07:07 -0200 To: commonloops.pa@Xerox.COM Subject: bugs I use the st-patricks-day version of PCL. There are some bugs and I don't know whether they still are in the latest version. I report them anyway. 1. In update-slot-accessors--class in std-class.lisp you do a separate update for instance and non-instance classes. This leads to inconsistent behavior if you redefine an accessor and the allocation of the slot at the same time. e.g. (defclass foo () ((s1 :allocation :class :accessor foo-s1))) (defclass foo () ((s1 :allocation :instance :accessor s1))) (setq i-foo (make-instance 'foo :s1 1)) (s1 i-foo) ;-> 1 (foo-s1 i-foo) ; ->1; foo-s1 should not be known anymore whereas the following is correct: (defclass foo () ((s1 :allocation :class :accessor foo-s1))) (defclass foo () ((s1 :allocation :instance :accessor foo-s1))) (defclass foo () ((s1 :allocation :instance :accessor s1))) (setq i-foo (make-instance 'foo :s1 1)) (s1 i-foo) ;1 (foo-s1 i-foo) ; error 2. In braid1 there is the constant definition for class-instance-slots-position. It is used in the functions class-instance-slots and setf-class-instance-slots. They again are used in class definition. The problem arises when you define your own metaclass that has multiple supers, one of which is standard-class. (defclass my-standard-class (standard-class an-other-class) ()) my-standard-class inherits slots from all superclasses. They get rearranged but class-instance-slots / setf-class-instance-slots still access the slot in the old class-instance-slots-position. This causes errors. The same should be true in the similar case with slotd-name. (A minor thing: the slots that are inherited from the superclasses are in the order 'right-most class first' whereas I would expect it the other way around. This is not the problem but it unveiled it.) 3. A thing that I mentioned earlier but probably wasn't understandable as there was a typo: If you redefine classes with a new metaclass the redefined class will still be of the old metaclass and not know it's new behavior. E.g. (defclass bar () (..) ) (defclass my-meta-class (standard-class) (...)) (defclass bar () (..) (:metaclass my-meta-class)) bar will still be of metaclass standard-class. There must be an (when new-metaclass-p (class-change class new-meta-class)) in update-class. Angela From Owners-commonloops.pa@Xerox.COM Mon Aug 29 19:31:28 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP; Mon, 29 Aug 88 19:31:28 PDT Received: from Cabernet.ms by ArpaGateway.ms ; 29 AUG 88 14:44:02 PDT Return-Path: Redistributed: commonloops.pa Received: from mitre-bedford.ARPA ([26.3.0.66]) by Xerox.COM ; 29 AUG 88 14:25:26 PDT Posted-From: The MITRE Corp., Bedford, MA Received: from orbit.sun.uucp by linus.MENET (3.2/4.7) id AA17765; Mon, 29 Aug 88 17:25:20 EDT Posted-Date: Mon, 29 Aug 88 17:25:07 EDT Received: from localhost by orbit.sun.uucp (3.2/SMI-3.0DEV3) id AA00841; Mon, 29 Aug 88 17:25:09 EDT Message-Id: <8808292125.AA00841@orbit.sun.uucp> To: CommonLoops.pa@Xerox.COM Subject: A PCL browser Date: Mon, 29 Aug 88 17:25:07 EDT From: rich%linus@mitre-bedford.ARPA Gregor mentioned the existence of browsers for PCL. We would be interesting in obtaining one. Anybody out there have one available for a Symbolics, running 7.2? Also, if people are developing tools for their site, it would be useful to the CLOS community if they were made available through this mailing list. Rich From Gregor.pa@Xerox.COM Mon Aug 29 20:14:30 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP; Mon, 29 Aug 88 20:14:30 PDT Received: from Semillon.ms by ArpaGateway.ms ; 29 AUG 88 15:53:02 PDT Date: Mon, 29 Aug 88 15:49 PDT From: Gregor.pa@Xerox.COM Subject: Re: Another (major) difference To: larus@ginger.berkeley.edu Cc: CommonLoops.pa@Xerox.COM Fcc: BD:>Gregor>mail>outgoing-mail-4.text.newest In-Reply-To: <8808291652.AA17481@paris.Berkeley.EDU> Message-Id: <19880829224922.8.GREGOR@PORTNOY.parc.xerox.com> Line-Fold: no Date: Mon, 29 Aug 88 09:52:07 PDT From: larus%paris.Berkeley.EDU@ginger.Berkeley.EDU (James Larus) Gregor, A major difference between the AAAI release of PCL and previous releases of PCL is minimally documented in the release notes. PCL now checks whether slots are "unbound", in other words, you can no longer assume that fields within an object are initialized to NIL. This is a major change to the sematics of PCL (and a major difference from the semantics of CL structures). This is a good point. The notes.text file did not make it clear that this change had happened and that it was a big semantic change. I have put out a new version of notes.text which makes this somewhat more clear. Your message should also serve to warn people. I also find the terminology of slots being "bound" to be extremely confusing. Binding has a clear fuzzy meaning in CL and assignment to fields of objects is not related to this concept. I had a good deal of trouble understanding PCL's error message: Error: The slot OBJECT-MARK is unbound in the object #. I would suggest that correct verb is "uninitialized", not "unbound". Note that the keyword in DEFCLASS is :INITFORM, not :BINDFORM. You are probably right here. The spec seems to use both terms. Had we noticed this sooner we could probably have cleared it up. The general heuristic that says that whenever the string "BOUND" appears your are in trouble should have warned us. But, this is probably the wrong mailing list for this flame. Yup. ------- From Owners-commonloops.pa@Xerox.COM Mon Aug 29 20:20:44 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP; Mon, 29 Aug 88 20:20:44 PDT Received: from Salvador.ms by ArpaGateway.ms ; 29 AUG 88 09:52:10 PDT Return-Path: Redistributed: commonloops.pa Received: from decwrl.dec.com ([128.45.9.1]) by Xerox.COM ; 29 AUG 88 09:49:21 PDT Received: by decwrl.dec.com (5.54.5/4.7.34) id AA02346; Wed, 31 Aug 88 02:49:39 PDT Message-Id: <8808310949.AA02346@decwrl.dec.com> From: piazza%lisp.DEC@decwrl.dec.com (Jeffrey Piazza) Date: 29 Aug 88 12:11 To: RUTH@sri-robotx.arpa Subject: RE: VAXLisp V2.1 Compilation Error There were some incompatible changes between VAX LISP V2.1 and V2.2 which are visible to the VAX LISP-specific portions of PCL. We regret that we are unable to support PCL retroactively for all past and present versions of VAX LISP. If you upgrade to V2.2, you should have no trouble compiling PCL. /JEP From Gregor.pa@Xerox.COM Mon Aug 29 22:04:15 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP; Mon, 29 Aug 88 22:04:15 PDT Received: from Semillon.ms by ArpaGateway.ms ; 29 AUG 88 15:56:08 PDT Date: Mon, 29 Aug 88 15:49 PDT From: Gregor.pa@Xerox.COM Subject: Re: Another (major) difference To: larus@ginger.Berkeley.EDU Cc: CommonLoops.pa@Xerox.COM Fcc: BD:>Gregor>mail>outgoing-mail-4.text.newest In-Reply-To: <8808291652.AA17481@paris.Berkeley.EDU> Message-Id: <19880829224931.9.GREGOR@PORTNOY.parc.xerox.com> Line-Fold: no Date: Mon, 29 Aug 88 09:52:07 PDT From: larus%paris.Berkeley.EDU@ginger.Berkeley.EDU (James Larus) Gregor, A major difference between the AAAI release of PCL and previous releases of PCL is minimally documented in the release notes. PCL now checks whether slots are "unbound", in other words, you can no longer assume that fields within an object are initialized to NIL. This is a major change to the sematics of PCL (and a major difference from the semantics of CL structures). This is a good point. The notes.text file did not make it clear that this change had happened and that it was a big semantic change. I have put out a new version of notes.text which makes this somewhat more clear. Your message should also serve to warn people. I also find the terminology of slots being "bound" to be extremely confusing. Binding has a clear fuzzy meaning in CL and assignment to fields of objects is not related to this concept. I had a good deal of trouble understanding PCL's error message: Error: The slot OBJECT-MARK is unbound in the object #. I would suggest that correct verb is "uninitialized", not "unbound". Note that the keyword in DEFCLASS is :INITFORM, not :BINDFORM. You are probably right here. The spec seems to use both terms. Had we noticed this sooner we could probably have cleared it up. The general heuristic that says that whenever the string "BOUND" appears your are in trouble should have warned us. ------- From Owners-CommonLoops.pa@Xerox.COM Mon Aug 29 22:08:40 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP; Mon, 29 Aug 88 22:08:40 PDT Received: from Cabernet.ms by ArpaGateway.ms ; 29 AUG 88 09:54:47 PDT Return-Path: Redistributed: CommonLoops.pa Received: from paris.Berkeley.EDU ([128.32.150.46]) by Xerox.COM ; 29 AUG 88 09:53:27 PDT Received: by paris.Berkeley.EDU (5.57/1.25) id AA17481; Mon, 29 Aug 88 09:52:14 PDT From: larus@paris.Berkeley.EDU (James Larus) Message-Id: <8808291652.AA17481@paris.Berkeley.EDU> To: Gregor.pa@Xerox.COM Cc: CommonLoops.pa@Xerox.COM Subject: Another (major) difference Reply-To: larus@ginger.Berkeley.EDU Date: Mon, 29 Aug 88 09:52:07 PDT Gregor, A major difference between the AAAI release of PCL and previous releases of PCL is minimally documented in the release notes. PCL now checks whether slots are "unbound", in other words, you can no longer assume that fields within an object are initialized to NIL. This is a major change to the sematics of PCL (and a major difference from the semantics of CL structures). I also find the terminology of slots being "bound" to be extremely confusing. Binding has a clear fuzzy meaning in CL and assignment to fields of objects is not related to this concept. I had a good deal of trouble understanding PCL's error message: Error: The slot OBJECT-MARK is unbound in the object #. I would suggest that correct verb is "uninitialized", not "unbound". Note that the keyword in DEFCLASS is :INITFORM, not :BINDFORM. But, this is probably the wrong mailing list for this flame. /Jim From Lanning.pa@Xerox.COM Mon Aug 29 22:12:01 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP; Mon, 29 Aug 88 22:12:01 PDT Received: from Semillon.ms by ArpaGateway.ms ; 29 AUG 88 15:44:10 PDT Date: 29 Aug 88 15:40 PDT From: Stan Lanning Subject: Re: PCL Environment files for Envos lisp In-Reply-To: welch@tut.cis.ohio-state.edu (Arun Welch)'s message of Thu, 25 Aug 88 16:31:29 EDT To: welch@tut.cis.ohio-state.edu (Arun Welch) Cc: commonloops.PA@Xerox.COM, aisupport.PA@Xerox.COM Message-Id: <880829-154410-1934@Xerox> I have (finally) fixed up the pcl-env files for Xerox Lisp. There are two files, PCL-ENV.LISP and PCL-ENV-INTERNAL.LISP, both available on arisia via ftp. These should work in both the Lyric and Medley releases of XeroxLisp. The file PCL-ENV-INTERNAL requires some system record definitions to be compiled. If you have these sources, fine. If you don't, there is a copy of the binary PCL-ENV-INTERNAL.DFASL on arisia, too. Just make sure you fetch it in binary mode. A word about compatibility between Lyric and Medley: The PCL-ENV.LISP file is heavily conditionalized. You can't load a Lyric compiled version of it into Medley. Also, remember that Medley compiled files can't be loaded into a Lyric sysout. Note that the file DEFSYS.LISP tries to deal with this when it sets up *PCL-DIRECTORY*. One last thing: While you are at it, you might as well refetch the XEROX-LOW file, esp. if you grabbed it before the afternoon of Aug 29th. There was a bug that screwed up printing of instances that is fixed in the latest version. ----- sm(al)L From Owners-CommonLoops.pa@Xerox.COM Mon Aug 29 23:22:26 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP; Mon, 29 Aug 88 23:22:26 PDT Received: from Riesling.ms by ArpaGateway.ms ; 29 AUG 88 23:26:04 PDT Return-Path: Redistributed: CommonLoops.pa Received: from lucid.com ([192.26.25.1]) by Xerox.COM ; 29 AUG 88 23:24:53 PDT Received: from kent-state ([192.9.200.24]) by heavens-gate id AA03848g; Mon, 29 Aug 88 22:25:11 PST Received: by kent-state id AA01696g; Mon, 29 Aug 88 23:23:57 PDT Date: Mon, 29 Aug 88 23:23:57 PDT From: Eric Benson Message-Id: <8808300623.AA01696@kent-state> To: larus@ginger.Berkeley.EDU Cc: Gregor.pa@Xerox.COM, CommonLoops.pa@Xerox.COM In-Reply-To: James Larus's message of Mon, 29 Aug 88 09:52:07 PDT <8808291652.AA17481@paris.Berkeley.EDU> Subject: Another (major) difference Redistributed: CommonLoops.pa From: larus@paris.Berkeley.EDU (James Larus) Reply-To: larus@ginger.Berkeley.EDU Date: Mon, 29 Aug 88 09:52:07 PDT Gregor, A major difference between the AAAI release of PCL and previous releases of PCL is minimally documented in the release notes. PCL now checks whether slots are "unbound", in other words, you can no longer assume that fields within an object are initialized to NIL. This is a major change to the sematics of PCL (and a major difference from the semantics of CL structures). I beg to differ. On p.308 of the Silver Bible regarding DEFSTRUCT: "If no {\it default-init} is specified, then the initial contents of the slot are undefined and implementation-dependent." It is only by convention, not by law, that existing Common Lisp implementations initialize unspecified DEFSTRUCT slots to NIL. From Owners-commonloops.pa@Xerox.COM Tue Aug 30 07:00:49 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/Vxxiii) id AA05866; Tue, 30 Aug 88 07:00:49 PDT Received: from Chardonnay.ms by ArpaGateway.ms ; 30 AUG 88 05:07:29 PDT Return-Path: Redistributed: commonloops.pa Received: from G.BBN.COM ([192.1.2.67]) by Xerox.COM ; 30 AUG 88 05:05:39 PDT Date: Tue, 30 Aug 88 08:04:43 EDT From: R. Shapiro Subject: Re: A PCL browser To: rich%linus@MITRE-BEDFORD.ARPA Cc: commonloops.pa@Xerox.COM In-Reply-To: Message from "rich%linus@mitre-bedford.arpa" of Mon 29 Aug 88 23:10:14-EDT Message-Id: <880830-050729-2918@Xerox> We have a PCL "browser" running in 7.2. I think it will be shown at one of the upcoming meetings. I'm not clear on its legal status (i.e. whether I can give it out freely) -- as the author, I'd like to see it in circulation, but the legal department here may have other ideas. (we also have a fix for the Inspector which makes pcl objects reasonably inspectable) Likewise, we have an implementation of Conditions written in pcl, which may be useful until some such facility is made part of Common Lisp. Finally, we have a version of method combination definition (and uses of it to define all of the predefined combination types in Flavors). I believe that Gregor's PCL will have its own version of this soon (if it doesn't already). Ours may be useful in the meantime. Again I should stress that I'm not sure I can give away any of this, but if people are interested, I'll check it out with the appropriate people here. Richard Shapiro/RSHAPIRO@BBN ------- From Owners-commonloops.pa@Xerox.COM Tue Aug 30 16:15:26 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/Vxxiii) id AA11689; Tue, 30 Aug 88 16:15:26 PDT Received: from Riesling.ms by ArpaGateway.ms ; 30 AUG 88 11:14:58 PDT Return-Path: Redistributed: commonloops.pa Received: from gmuvax2.gmu.edu ([192.5.215.8]) by Xerox.COM ; 30 AUG 88 11:12:27 PDT Received: by gmuvax2.gmu.edu (5.54/1.14) id AA13114; Tue, 30 Aug 88 14:12:13 EDT Date: Tue, 30 Aug 88 14:12:13 EDT From: "Pawel Stefanski" Message-Id: <8808301812.AA13114@gmuvax2.gmu.edu> To: commonloops.pa@Xerox.COM Subject: Lucid Bug when compiling PCL (?) Looks like the following definition cannot be processed correctly by Sun Lucid CL 2.1 - loops indefinitely printing out "alloc-p", and signalling incorrectly constructed optional argument: file name: high.lisp function name: describe-instance 'erroneous definition' : (describe-slot (name value allocation &aux (alloc-p t)) in the flet body. Pawel A. Stefanski, Phone (703)764-6057, (703)323-2713, (stefan@gmu90x.gmu.edu OR stefan@gmuvax2.gmu.edu ) Machine Learning Laboratory, Department of Computer Science, George Mason University, Fairfax, VA 22030. =================================================================== From Owners-commonloops.pa@Xerox.COM Tue Aug 30 16:31:36 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/Vxxiii) id AA11956; Tue, 30 Aug 88 16:31:36 PDT Received: from Cabernet.ms by ArpaGateway.ms ; 30 AUG 88 12:18:42 PDT Return-Path: Redistributed: commonloops.pa Received: from hplabs.HP.COM ([15.255.16.7]) by Xerox.COM ; 30 AUG 88 12:06:01 PDT Received: from hplms2.HP.COM (hplms2) by hplabs.HP.COM with SMTP ; Tue, 30 Aug 88 11:05:17 PST Received: from hplwhh.HPL.HP.COM (hplwhh.hpl.hp.com) by hplms2.HP.COM; Tue, 30 Aug 88 12:04:57 pdt Received: from loopback by hplwhh.HPL.HP.COM; Tue, 30 Aug 88 12:04:32 pdt To: gregor.pa@Xerox.COM Cc: commonloops.pa@Xerox.COM Subject: printing prototypes X-Mailer: mh6.5 Date: Tue, 30 Aug 88 12:04:28 PDT Message-Id: <6146.588971068@hplwhh> From: Warren Harris Here's a fix that allows the print routines to print uninitialized instances (such as class prototypes). From "std-class.l": (defun named-object-print-function (instance stream &optional (extra nil extra-p)) (declare (ignore depth)) (printing-random-thing (instance stream) (if (slot-boundp instance 'name) (format stream "~:(~A~) ~S~:[~*~; ~:S~]" ; can you say format (class-name (class-of instance)) (slot-value instance 'name) extra-p extra) (format stream "~:(~A~)~:[~*~; ~:S~]" (class-name (class-of instance)) extra-p extra)))) Warren From Owners-commonloops.pa@Xerox.COM Tue Aug 30 17:30:53 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/Vxxiii) id AA13026; Tue, 30 Aug 88 17:30:53 PDT Received: from Cabernet.ms by ArpaGateway.ms ; 30 AUG 88 11:07:05 PDT Return-Path: Redistributed: commonloops.pa Received: from fs3.cs.rpi.edu ([128.213.1.14]) by Xerox.COM ; 30 AUG 88 11:02:47 PDT Received: by fs3.cs.rpi.edu (5.54/1.2-RPI-CS-Dept) id AA09514; Tue, 30 Aug 88 14:00:51 EDT Date: Tue, 30 Aug 88 14:01:18 EDT From: harrisr@turing.cs.rpi.edu (Richard Harris) Received: by turing.cs.rpi.edu (4.0/1.2-RPI-CS-Dept) id AA15121; Tue, 30 Aug 88 14:01:18 EDT Message-Id: <8808301801.AA15121@turing.cs.rpi.edu> To: commonloops.pa@Xerox.COM Subject: eql specializers > Date: Mon, 8 Aug 88 17:34 PDT > From: Gregor.pa@Xerox.COM > BUGS: > > o specializer (eql fred) works but (eql 'fred) as in CLOS doesn't. > >This should work now. What still is a problem is that eql methods don't >work too well with method combination. I don't understand what you mean here. It appears to me as if eql specializers are not getting evaluated, and I haven't found a problem with method combination. Here is an example of what happens now: (with "8/28/88 (beta rev 1) AAAI PCL " and KCL) (macroexpand '(defmethod a ((b (eql 'c))) 'd)) => (PROGN (EVAL-WHEN (COMPILE LOAD EVAL) (PROGN (PROGN (LOAD-DEFMETHOD 'STANDARD-METHOD 'A 'NIL '((EQL 'C)) '(B) 'NIL 'NIL 'NIL #'(LAMBDA (B) (PROGN B) (BLOCK A 'D)))))) (EVAL-WHEN ())) (defmethod a ((b (eql 'c))) 'd) => NIL (a 'c) => Error: No matching method for the generic-function # when called with arguments (C). Error signalled by A. Broken at NO-APPLICABLE-METHOD. Type :H for Help. I think this problem can be fixed by changing expand-defmethod: ;From boot.lisp (defun expand-defmethod (proto-method name qualifiers lambda-list body env) (multiple-value-bind (fn-form specializers doc plist) (expand-defmethod-internal name qualifiers lambda-list body env) (make-top-level-form (make-method-spec name qualifiers specializers) '(compile load eval) `(progn ,(make-progn `(load-defmethod ',(if proto-method (class-name (class-of proto-method)) 'standard-method) ',name ',qualifiers ,(if (some #'(lambda (specializer) (and (consp specializer) (eq (car specializer) 'eql))) specializers) `(list ,@(mapcar #'(lambda (specializer) (if (and (consp specializer) (eq (car specializer) 'eql)) ``(eql ,,(cadr specializer)) `',specializer)) specializers)) `',specializers) ',(specialized-lambda-list-lambda-list lambda-list) ',doc ',(getf plist :isl-cache-symbol) ;Paper over a bug in KCL by ;passing the cache-symbol ;here in addition to in the ;plist. ',plist ,fn-form)))))) With this patch: (macroexpand '(defmethod a ((b (eql 'c))) 'd)) => (PROGN (EVAL-WHEN (COMPILE LOAD EVAL) (PROGN (PROGN (LOAD-DEFMETHOD 'STANDARD-METHOD 'A 'NIL (LIST (LIST 'EQL 'C)) '(B) 'NIL 'NIL 'NIL #'(LAMBDA (B) (PROGN B) (BLOCK A 'D)))))) (EVAL-WHEN ())) (defmethod a ((b (eql 'c))) 'd) => NIL (a 'c) => D ---- Rick Harris From Owners-commonloops.pa@Xerox.COM Tue Aug 30 17:37:47 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/Vxxiii) id AA13200; Tue, 30 Aug 88 17:37:47 PDT Received: from Cabernet.ms by ArpaGateway.ms ; 30 AUG 88 15:16:41 PDT Return-Path: Redistributed: commonloops.pa Received: from Sun.COM ([10.7.0.2]) by Xerox.COM ; 30 AUG 88 15:04:37 PDT Received: from snail.sun.com by Sun.COM (4.0/SMI-4.0) id AA17268; Tue, 30 Aug 88 15:02:13 PDT Received: from suntana.sun.com by snail.sun.com (4.0/SMI-4.0) id AA10546; Tue, 30 Aug 88 15:05:04 PDT Received: from localhost by suntana.sun.com (4.0/SMI-4.0) id AA06902; Tue, 30 Aug 88 09:10:57 PDT Message-Id: <8808301610.AA06902@suntana.sun.com> To: rich%linus@MITRE-BEDFORD.ARPA, commonloops.pa@Xerox.COM Subject: Re: A PCL browser In-Reply-To: Your message of Tue, 30 Aug 88 08:04:43 -0400. <880830-050729-2918@Xerox> Date: Tue, 30 Aug 88 09:10:55 -0700 From: kempf@Sun.COM We've got a series of prototype enhancements to the Sun Common Lisp Symbolic Programming Environment (SPE) 1.0 (which runs in Lucid 2.1) that provide support for programming in CLOS using the PCL implementation. The enhancements include: *Partial integration with the debugger, including ability to find method source from a stack frame of the method, visual display of method arguments, etc. TRACE and ADVISE of individual methods (as opposed to generic functions) are not there yet. *M-. and general source finding integration for finding method and class source. Handles generic function names, so that if you give the generic function name, it will pop up a menu with the list of methods on the generic function for you to select one. Also handles slot accessor names, so if you give a generic function name which it knows is a slot accessor, it will bring up the class definition. *Almost full integration with the Cross Reference Analyzer (CREF) for methods. The only things missing are the ability to mouse on a call graph node for CALL-NEXT-METHOD and get to the next method, and not displaying the call graph of the macroexpansion of WITH-SLOTS and WITH-ACCESSORS, but rather doing a premacroexpansion call graph, so that the usage of macros can be shown. *A full set of CLOS browsers and inspectors for browsing classes, methods, generic functions, and instances. These are integrated with the debugger as well, so that you can browse an argument currently on the stack and see what it has, and with the rest of the Common Lisp inspector system. The browser system also lets you browse class and method source from the class or method browser, so it can be easily and incrementally changed. The enhancements work on both the Sun3 and Sun4 versions of SPE. They will be made available in some form, but, obviously, you'll need SPE in order to use them, so it doesn't make much sense to just post the source. I think the marketing folks are planning to distribute it somewhere within the OOPSLA time frame. I'll keep people posted. From Gregor.pa@Xerox.COM Tue Aug 30 17:42:33 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/Vxxiii) id AA13318; Tue, 30 Aug 88 17:42:33 PDT Received: from Semillon.ms by ArpaGateway.ms ; 30 AUG 88 15:29:24 PDT Date: Tue, 30 Aug 88 14:14 PDT From: Gregor.pa@Xerox.COM Subject: Re: IGNORE on specialized parameters in methods To: rich%linus@mitre-bedford.ARPA Cc: CommonLoops.pa@Xerox.COM Fcc: BD:>Gregor>mail>outgoing-mail-4.text.newest In-Reply-To: <8808301939.AA20990@linus.MENET> Message-Id: <19880830211422.2.GREGOR@PORTNOY.parc.xerox.com> Line-Fold: no Date: Tue, 30 Aug 88 15:39:57 EDT From: rich%linus@mitre-bedford.ARPA On page 2-43 of the 88-002 draft, the documentation for DEFMETHOD says that each of the specialized parameters will be referred to by DEFMETHOD's expansion. I wondered what the motivation for this was. Very often, an argument passed to a generic function is used to specialize the method lookup, but then not actually used in the body of the method. Here is an example from PCL: (defmethod slot-unbound ((class standard-class) instance slot-name) (error "The slot ~S is unbound in the object ~S." slot-name instance)) This rule was put in for convenience when defining methods like this. ------- From Owners-commonloops.pa@Xerox.COM Tue Aug 30 17:55:23 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/Vxxiii) id AA13679; Tue, 30 Aug 88 17:55:23 PDT Received: from Salvador.ms by ArpaGateway.ms ; 30 AUG 88 11:28:32 PDT Return-Path: Redistributed: commonloops.pa Received: from hplabs.HP.COM ([15.255.16.7]) by Xerox.COM ; 30 AUG 88 11:25:37 PDT Received: from hplms2.HP.COM (hplms2) by hplabs.HP.COM with SMTP ; Tue, 30 Aug 88 10:25:16 PST Received: from hplwhh.HPL.HP.COM (hplwhh.hpl.hp.com) by hplms2.HP.COM; Tue, 30 Aug 88 11:24:50 pdt Received: from loopback by hplwhh.HPL.HP.COM; Tue, 30 Aug 88 11:24:23 pdt To: gregor.pa@Xerox.COM Cc: commonloops.pa@Xerox.COM Subject: PCL DESCRIBE X-Mailer: mh6.5 Date: Tue, 30 Aug 88 11:24:19 PDT Message-Id: <6065.588968659@hplwhh> From: Warren Harris Here's a fix to the DESCRIBE generic function to handle unbound slots. The code as supplied with AAAI PCL breaks when an unbound slot is encountered: (defmethod describe ((obj object) &optional (stream t)) (let* ((class (class-of obj)) (slotds (slots-to-inspect class obj)) (max-slot-name-length 0) (instance-slotds ()) (class-slotds ()) (other-slotds ())) (flet ((adjust-slot-name-length (name) (setq max-slot-name-length (max max-slot-name-length ;; format nil is necessary so we count the length of ;; any package prefix if its going to get printed (length (format nil "~S" name))))) (describe-slot (name &optional (allocation () alloc-p)) (if (slot-boundp obj name) (format stream "~% ~:[~*~;~A~]~V@S ~S" alloc-p allocation max-slot-name-length name (slot-value obj name)) (format stream "~% ~:[~*~;~A~]~V@S" alloc-p allocation max-slot-name-length name)))) ;; Figure out a good width for the slot-name column. (dolist (slotd slotds) (adjust-slot-name-length (slotd-name slotd)) (case (slotd-allocation slotd) (:instance (push slotd instance-slotds)) (:class (push slotd class-slotds)) (otherwise (push slotd other-slotds)))) (setq max-slot-name-length (min (+ max-slot-name-length 3) 30)) (format stream "~%~S is an instance of class ~S:" obj class) (when instance-slotds (format stream "~% The following slots have :INSTANCE allocation:") (dolist (slotd (nreverse instance-slotds)) (describe-slot (slotd-name slotd)))) (when class-slotds (format stream "~% The following slots have :CLASS allocation:") (dolist (slotd (nreverse class-slotds)) (describe-slot (slotd-name slotd)))) (when other-slotds (format stream "~% The following slots have allocation as shown:") (dolist (slotd (nreverse other-slotds)) (describe-slot (slotd-name slotd) (slotd-allocation slotd)))) (values)))) Here's another hack which allows you to see more information when describing classes. It just allows the default object method to be called instead of DESCRIBE-CLASS. (defmethod describe ((obj standard-class) &optional (stream t)) (call-next-method)) I'd use UNDEFMETHOD to do this if I knew how it worked. If some of the slots of standard-class should be hidden from the DESCRIBE mechanism, I suggest specializing the SLOTS-TO-INSPECT method for standard-class. Otherwise, its really useful to see all the information that's there. Warren From Owners-commonloops.pa@Xerox.COM Tue Aug 30 18:00:00 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/Vxxiii) id AA13716; Tue, 30 Aug 88 18:00:00 PDT Received: from Riesling.ms by ArpaGateway.ms ; 30 AUG 88 16:37:02 PDT Return-Path: Redistributed: commonloops.pa Received: from ucbarpa.Berkeley.EDU ([10.0.0.78]) by Xerox.COM ; 30 AUG 88 16:35:16 PDT Received: by ucbarpa.Berkeley.EDU (5.59/1.29) id AA08405; Tue, 30 Aug 88 16:34:37 PDT Received: from frisky by franz (3.2/3.14) id AA04288; Tue, 30 Aug 88 16:22:51 PDT Received: by frisky (3.2/3.14) id AA05233; Tue, 30 Aug 88 16:21:23 PDT From: jkf%frisky%franz@ucbarpa.Berkeley.EDU (John Foderaro) Return-Path: Message-Id: <8808302321.AA05233@frisky> To: commonloops.pa@Xerox.COM Cc: larus%ucbarpa%franz@ucbarpa.Berkeley.EDU, bugs%franz@ucbarpa.Berkeley.EDU Subject: slot unbound Date: Tue, 30 Aug 88 16:21:22 PDT Could it be that during the construction of a pcl class object, there is a period of time between the time the object is created and the time that the slots are filled in that the object is unprintable because certain slots needed for printing are unbound? If so then this should be corrected because attempting to print such a class object causes slot-unbound to be called which creates an error message including the object in question which causes the slot-unbound error to occur and so on and so on. The slots necessary for printing should be given initial dummy values so the object is at least printable. You can often cause this recursive error to happen by tracing 'class-of' before loading in a file containing defclasses. john foderaro franz inc. From Owners-commonloops.pa@Xerox.COM Tue Aug 30 18:47:21 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/Vxxiii) id AA14336; Tue, 30 Aug 88 18:47:21 PDT Received: from Salvador.ms by ArpaGateway.ms ; 30 AUG 88 12:44:15 PDT Return-Path: Redistributed: commonloops.pa Received: from mitre-bedford.ARPA ([26.3.0.66]) by Xerox.COM ; 30 AUG 88 12:40:12 PDT Posted-From: The MITRE Corp., Bedford, MA Received: from localhost by linus.MENET (3.2/4.7) id AA20990; Tue, 30 Aug 88 15:39:59 EDT Posted-Date: Tue, 30 Aug 88 15:39:57 EDT Message-Id: <8808301939.AA20990@linus.MENET> To: CommonLoops.pa@Xerox.COM Subject: IGNORE on specialized parameters in methods Date: Tue, 30 Aug 88 15:39:57 EDT From: rich%linus@mitre-bedford.ARPA On page 2-43 of the 88-002 draft, the documentation for DEFMETHOD says that each of the specialized parameters will be referred to by DEFMETHOD's expansion. I wondered what the motivation for this was. Is it that each of those parameters was used to find the applicable methods, and so are "used", even if the method doesn't explicitly refer to them? I know this was discussed before, but I'm not sure the motivation was ever made explicit. Rich From Owners-CommonLoops.pa@Xerox.COM Wed Aug 31 00:33:07 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/Vxxiii) id AA16865; Wed, 31 Aug 88 00:33:07 PDT Received: from Riesling.ms by ArpaGateway.ms ; 31 AUG 88 00:37:26 PDT Return-Path: <@CUNYVM.CUNY.EDU:9597@DB0TUZ01.BITNET> Redistributed: CommonLoops.pa Received: from CUNYVM.CUNY.EDU ([128.228.1.2]) by Xerox.COM ; 31 AUG 88 00:36:10 PDT Received: from DB0TUI11.BITNET by CUNYVM.CUNY.EDU (IBM VM SMTP R1.1) with BSMTP id 9698; Wed, 31 Aug 88 03:35:00 EDT Received: by DB0TUI11 (Mailer X1.25) id 3442; Wed, 31 Aug 88 09:35:32 MEZ Date: WEDNESDAY, AUGUST 31, 1988 09:23 CET From: 9597@DB0TUZ01.BITNET To: CommonLoops.pa@Xerox.COM Subject: Common LISP Message-Id: <880831-003726-1693@Xerox> Hello. Is there anybody out there using 'Golden Common LISP' from Gold Hill for PCL? Please contact me. Dirk Niemeyer (9597@DB0TUZ01.BITNET) Institute of Aeronautics and Astronautics, Technical University of Berlin, West Germany From Owners-commonloops.pa@Xerox.COM Thu Sep 1 18:18:11 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/Vxxiii) id AA06571; Thu, 1 Sep 88 16:07:21 PDT Received: from Chardonnay.ms by ArpaGateway.ms ; 01 SEP 88 13:47:47 PDT Return-Path: Redistributed: commonloops.pa Received: from fs3.cs.rpi.edu ([128.213.1.14]) by Xerox.COM ; 01 SEP 88 13:44:13 PDT Received: by fs3.cs.rpi.edu (5.54/1.2-RPI-CS-Dept) id AA15212; Thu, 1 Sep 88 16:41:26 EDT Date: Thu, 1 Sep 88 16:42:03 EDT From: harrisr@turing.cs.rpi.edu (Richard Harris) Received: by turing.cs.rpi.edu (4.0/1.2-RPI-CS-Dept) id AA17005; Thu, 1 Sep 88 16:42:03 EDT Message-Id: <8809012042.AA17005@turing.cs.rpi.edu> To: commonloops.pa@Xerox.COM Subject: eql specializers I sent this a few days ago and it seems to have vanished, so here it is again. > Date: Mon, 8 Aug 88 17:34 PDT > From: Gregor.pa@Xerox.COM > BUGS: > > o specializer (eql fred) works but (eql 'fred) as in CLOS doesn't. > >This should work now. What still is a problem is that eql methods don't >work too well with method combination. I don't understand what you mean here. It appears to me as if eql specializers are not getting evaluated, and I haven't found a problem with method combination. Here is an example of what happens now: (with "8/28/88 (beta rev 1) AAAI PCL " and KCL) (macroexpand '(defmethod a ((b (eql 'c))) 'd)) => (PROGN (EVAL-WHEN (COMPILE LOAD EVAL) (PROGN (PROGN (LOAD-DEFMETHOD 'STANDARD-METHOD 'A 'NIL '((EQL 'C)) '(B) 'NIL 'NIL 'NIL #'(LAMBDA (B) (PROGN B) (BLOCK A 'D)))))) (EVAL-WHEN ())) (defmethod a ((b (eql 'c))) 'd) => NIL (a 'c) => Error: No matching method for the generic-function # when called with arguments (C). Error signalled by A. Broken at NO-APPLICABLE-METHOD. Type :H for Help. I think this problem can be fixed by changing expand-defmethod: ;From boot.lisp (defun expand-defmethod (proto-method name qualifiers lambda-list body env) (multiple-value-bind (fn-form specializers doc plist) (expand-defmethod-internal name qualifiers lambda-list body env) (make-top-level-form (make-method-spec name qualifiers specializers) '(compile load eval) `(progn ,(make-progn `(load-defmethod ',(if proto-method (class-name (class-of proto-method)) 'standard-method) ',name ',qualifiers ,(if (some #'(lambda (specializer) (and (consp specializer) (eq (car specializer) 'eql))) specializers) `(list ,@(mapcar #'(lambda (specializer) (if (and (consp specializer) (eq (car specializer) 'eql)) ``(eql ,,(cadr specializer)) `',specializer)) specializers)) `',specializers) ',(specialized-lambda-list-lambda-list lambda-list) ',doc ',(getf plist :isl-cache-symbol) ;Paper over a bug in KCL by ;passing the cache-symbol ;here in addition to in the ;plist. ',plist ,fn-form)))))) With this patch: (macroexpand '(defmethod a ((b (eql 'c))) 'd)) => (PROGN (EVAL-WHEN (COMPILE LOAD EVAL) (PROGN (PROGN (LOAD-DEFMETHOD 'STANDARD-METHOD 'A 'NIL (LIST (LIST 'EQL 'C)) '(B) 'NIL 'NIL 'NIL #'(LAMBDA (B) (PROGN B) (BLOCK A 'D)))))) (EVAL-WHEN ())) (defmethod a ((b (eql 'c))) 'd) => NIL (a 'c) => D ---- Rick Harris From Gregor.pa@Xerox.COM Thu Sep 1 21:27:28 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/Vxxiii) id AA13440; Thu, 1 Sep 88 21:27:28 PDT Received: from Semillon.ms by ArpaGateway.ms ; 01 SEP 88 20:04:53 PDT Date: Thu, 1 Sep 88 19:57 PDT From: Gregor.pa@Xerox.COM Subject: Re: Specializing methods on t with qualifiers To: rich%linus@mitre-bedford.ARPA Cc: CommonLoops.pa@Xerox.COM Fcc: BD:>Gregor>mail>outgoing-mail-4.text.newest In-Reply-To: <8808311742.AA02651@orbit.sun.uucp> Message-Id: <19880902025724.3.GREGOR@PORTNOY.parc.xerox.com> Line-Fold: no Date: Wed, 31 Aug 88 13:42:46 EDT From: rich%linus@mitre-bedford.ARPA In the AAAI PCL release (using Symbolics 7.2): Example: (defmethod blah (xxx) (princ " Primary ")) (defmethod blah :before (xxx) (princ " Before ")) (defmethod blah :after (xxx) (princ " After ")) When you call blah, you get an error. The following patch should solve this problem for you. ;from dcode.lisp (defun compute-discriminator-code-1 (generic-function) (let ((combined (generic-function-combined-methods generic-function)) (methods (generic-function-methods generic-function)) (std-class (find-class 'standard-class)) (t-class *the-class-t*) (r/w nil)) (cond ((null combined) (make-no-methods-dcode generic-function)) ((and (null (cdr combined)) (every #'(lambda (x) (eq x t-class)) (caar combined))) (make-default-method-only-dcode generic-function)) ((dolist (e combined) (when (dolist (specl (car e)) (when (listp specl) (return 't))) (return 't))) (make-individual-method-dcode generic-function)) ((not (dolist (m methods) (let* ((specls (method-type-specifiers m)) (spec0 (car specls)) (spec1 (cadr specls))) (cond ((and (memq r/w '(nil r)) (standard-reader-method-p m) (not (listp spec0)) (if (symbolp spec0) (and (neq spec0 'standard-generic-function) (neq spec0 'generic-function)) (eq (class-of spec0) std-class))) (setq r/w 'r)) ((and (memq r/w '(nil w)) (standard-writer-method-p m) (not (listp spec1)) (if (symbolp spec1) (and (neq spec1 'standard-generic-function) (neq spec1 'generic-function)) (eq (class-of spec1) std-class))) (setq r/w 'w)) (t (return t)))))) (if (eq r/w 'r) (make-all-std-class-readers-dcode generic-function) (make-all-std-class-writers-dcode generic-function))) (t (make-multi-method-dcode generic-function))))) ;from dcode.lisp (defmethod make-default-method-only-dcode (generic-function) (cdar (generic-function-combined-methods generic-function))) Also, it seems as if you can't evaluate the forms above in the lisp listener (methods specialized to other classes seem to work fine). I can't seem to duplicate this problem on my 3600 here. Can you give me some more details about it? ------- From Owners-CommonLoops.pa@Xerox.COM Fri Sep 2 06:56:41 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.3) id AA20046; Fri, 2 Sep 88 06:56:41 PDT Received: from Salvador.ms by ArpaGateway.ms ; 02 SEP 88 07:01:14 PDT Return-Path: Redistributed: CommonLoops.pa Received: from b.cs.wvu.wvnet.edu ([129.71.11.2]) by Xerox.COM ; 02 SEP 88 06:58:29 PDT Received: by b.cs.wvu.wvnet.edu (5.54/25-eef) id AA20627; Fri, 2 Sep 88 09:00:49 EDT Date: Fri, 2 Sep 88 09:00:49 EDT From: Kannan Message-Id: <8809021300.AA20627@b.cs.wvu.wvnet.edu> To: CommonLoops.pa@Xerox.COM, Gregor.pa@Xerox.COM Subject: Re: mailing list I have been getting all the mail. This is to ack. that. We have not started actual work on PCL. In a sense it is good, there is so much mail about pcl. We will start when the dust settles little bit. kannan. From Gregor.pa@Xerox.COM Tue Sep 6 12:48:27 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.3) id AA29129; Tue, 6 Sep 88 12:48:27 PDT Received: from Semillon.ms by ArpaGateway.ms ; 06 SEP 88 09:37:19 PDT Date: Tue, 6 Sep 88 09:33 PDT From: Gregor.pa@Xerox.COM Subject: Re: Apply fails with call-next-method To: Rob Pettengill Cc: CommonLoops.pa@Xerox.COM Fcc: BD:>Gregor>mail>outgoing-mail-4.text.newest In-Reply-To: <8809061330.AA00615@perseus.sw.mcc.com> Message-Id: <19880906163304.6.GREGOR@PORTNOY.parc.xerox.com> Line-Fold: no Date: Tue, 6 Sep 88 08:30:51 CDT From: Rob Pettengill I am trying to write a specialized primary *initialize-instance method (I am using the new *make-instance protocol) that will modify the &rest init-plist before the inherited primary and after methods see the init-plist. I tried to achieve this with apply with the following results: (defmethod pcl::*initialize-instance ((self one) &rest init-plist &key a &allow-other-keys) (apply 'call-next-method :a (if (null a) nil t) init-plist)) I think this is just caused by a typo in your code. "'apply" should be "#'apply". (defmethod pcl::*initialize-instance ((self one) &rest init-plist &key a &allow-other-keys) (apply #'call-next-method :a (if (null a) nil t) init-plist)) ------- From Owners-CommonLoops.pa@Xerox.COM Tue Sep 6 13:02:38 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.3) id AA29400; Tue, 6 Sep 88 13:02:38 PDT Received: from Riesling.ms by ArpaGateway.ms ; 06 SEP 88 07:44:06 PDT Return-Path: <@MCC.COM:rcp%sw.MCC.COM@MCC.COM> Redistributed: CommonLoops.pa Received: from MCC.COM ([10.3.0.62]) by Xerox.COM ; 06 SEP 88 07:42:09 PDT Received: from milano.sw.mcc.com by MCC.COM with TCP/SMTP; Tue 6 Sep 88 09:41:22-CDT Received: from perseus.sw.mcc.com by milano.sw.mcc.com (5.51/STP1.56) id AA05245; Tue, 6 Sep 88 08:30:54 CDT Date: Tue, 6 Sep 88 08:30:51 CDT From: Rob Pettengill Message-Id: <8809061330.AA00615@perseus.sw.mcc.com> Received: by perseus.sw.mcc.com (3.2/STP1.14) id AA00615; Tue, 6 Sep 88 08:30:51 CDT To: CommonLoops.pa@Xerox.COM Subject: Apply fails with call-next-method I am trying to write a specialized primary *initialize-instance method (I am using the new *make-instance protocol) that will modify the &rest init-plist before the inherited primary and after methods see the init-plist. I tried to achieve this with apply with the following results: ; (LISP-IMPLEMENTATION-TYPE) = Allegro CL ; (LISP-IMPLEMENTATION-VERSION) = 3.0.1 [sun3] (8/16/88 17:44) ; (SOFTWARE-TYPE) = SMI Unix ; (MACHINE-TYPE) = Sun Microsystems ; PCL::*PCL-SYSTEM-DATE* = 8/28/88 (beta rev 1) AAAI PCL (in-package :foo :use '(:pcl :lisp)) # (defclass one () ((a :initform nil :initarg :a :accessor one-a))) NIL (defmethod pcl::*initialize-instance ((self one) &rest init-plist &key a &allow-other-keys) (apply 'call-next-method :a (if (null a) nil t) init-plist)) ; of course in this simple example we could just drop the init-plist, ; however, in my system this is not the case. NIL (pcl::*make-instance 'one :a 7) Error: attempt to call `CALL-NEXT-METHOD' which is an undefined function. Restart actions (select using :continue): 0: prompt for a new function, instead of `CALL-NEXT-METHOD'. [1c] Should it be possible to use apply with the lexically defined call-next-method? Is there a better way to do this? ;rob Robert C. Pettengill, MCC Software Technology Program P. O. Box 200195, Austin, Texas 78720 ARPA: rcp@mcc.com PHONE: (512) 338-3533 UUCP: {ihnp4,seismo,harvard,gatech,pyramid}!ut-sally!im4u!milano!rcp From Gregor.pa@Xerox.COM Tue Sep 6 13:06:50 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.3) id AA29462; Tue, 6 Sep 88 13:06:50 PDT Received: from Semillon.ms by ArpaGateway.ms ; 06 SEP 88 11:54:30 PDT Date: Tue, 6 Sep 88 11:47 PDT From: Gregor.pa@Xerox.COM Subject: Re: Apply fails with call-next-method To: Rob Pettengill Cc: CommonLoops.pa@Xerox.COM Fcc: BD:>Gregor>mail>outgoing-mail-4.text.newest In-Reply-To: <19880906163304.6.GREGOR@PORTNOY.parc.xerox.com> Message-Id: <19880906184742.4.GREGOR@PORTNOY.parc.xerox.com> Line-Fold: no Date: Tue, 6 Sep 88 09:33 PDT From: Gregor.pa Date: Tue, 6 Sep 88 08:30:51 CDT From: Rob Pettengill I am trying to write a specialized primary *initialize-instance method (I am using the new *make-instance protocol) that will modify the &rest init-plist before the inherited primary and after methods see the init-plist. I tried to achieve this with apply with the following results: (defmethod pcl::*initialize-instance ((self one) &rest init-plist &key a &allow-other-keys) (apply 'call-next-method :a (if (null a) nil t) init-plist)) I think this is just caused by a typo in your code. "'apply" should be "#'apply". So pleased was I, that I had found a typo, that I didn't proofread my message. I meant "'call-next-method" should be "#'call-next-method". (defmethod pcl::*initialize-instance ((self one) &rest init-plist &key a &allow-other-keys) (apply #'call-next-method :a (if (null a) nil t) init-plist)) ------- From Owners-CommonLoops.pa@Xerox.COM Tue Sep 6 16:47:43 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.3) id AA01217; Tue, 6 Sep 88 16:47:43 PDT Received: from Salvador.ms by ArpaGateway.ms ; 06 SEP 88 13:37:00 PDT Return-Path: <@MCC.COM:rcp%sw.MCC.COM@MCC.COM> Redistributed: CommonLoops.pa Received: from MCC.COM ([10.3.0.62]) by Xerox.COM ; 06 SEP 88 13:33:48 PDT Received: from milano.sw.mcc.com by MCC.COM with TCP/SMTP; Tue 6 Sep 88 15:32:08-CDT Received: from perseus.sw.mcc.com by milano.sw.mcc.com (5.51/STP1.56) id AA16162; Tue, 6 Sep 88 15:32:00 CDT Date: Tue, 6 Sep 88 15:31:57 CDT From: Rob Pettengill Message-Id: <8809062031.AA01437@perseus.sw.mcc.com> Received: by perseus.sw.mcc.com (3.2/STP1.14) id AA01437; Tue, 6 Sep 88 15:31:57 CDT To: Gregor.pa@Xerox.COM Cc: CommonLoops.pa@Xerox.COM In-Reply-To: Gregor.pa@Xerox.COM's message of Tue, 6 Sep 88 09:33 PDT <19880906163304.6.GREGOR@PORTNOY.parc.xerox.com> Subject: Apply DOES NOT fail with call-next-method ! mi culpa WRONG for this use in CLOS (apply 'call-next-method ... => (apply (symbol-function 'call-next-method) ... RIGHT since call-next-method is lexically bound (apply #'call-next-method ... => (apply (function call-next-method) ... ;rob From Common-Lisp-Object-System-mailer@SAIL.STANFORD.EDU Wed Sep 7 20:44:43 1988 Received: from SAIL.STANFORD.EDU by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.3) id AA00338; Wed, 7 Sep 88 20:44:43 PDT Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 7 Sep 88 20:04:15 PDT Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 456000; Wed 7-Sep-88 23:03:21 EDT Date: Wed, 7 Sep 88 23:03 EDT From: David A. Moon Subject: symbol-macrolet-semantics, symbol-macrolet-utility To: Gregor.pa@Xerox.COM, Jeffrey Piazza , Kent M Pitman , Dan L. Pierson , Barry Margolin , cl-cleanup@SAIL.STANFORD.EDU Cc: Common-Lisp-Object-System@SAIL.STANFORD.EDU, cl-cleanup@SAIL.STANFORD.EDU, Jeffrey Piazza <"piazza%lisp.DEC@decwrl.dec.com"@MULTIMAX.ARPA> In-Reply-To: <871123130424.8.GREGOR@SPIFF.parc.xerox.com>, <8806222146.AA21530@decwrl.dec.com>, <8806281758.AA10391@decwrl.dec.com>, <880628165306.6.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>, <8806291818.AA11107@mist.UUCP>, <19880629204455.4.GREGOR@PORTNOY.parc.xerox.com>, <19880729021542.8.BARMAR@OCCAM.THINK.COM>, <8807292109.AA03546@decwrl.dec.com>, <880801135717.1.KMP@PEWEE.SCRC.Symbolics.COM> Message-Id: <19880908030301.1.MOON@EUPHRATES.SCRC.Symbolics.COM> Line-Fold: No I thought it was already well-established that symbol-macrolet has to be a special form, not a macro, and has to affect the behavior of macroexpand. 10 months ago I argued that symbol-macrolet didn't have to be a special form, but I was quite wrong. I favor the proposal SYMBOL-MACROLET-SEMANTICS:SPECIAL-FORM except for the part about forbidding use of symbol macros with SETQ (and macros such as MULTIPLE-VALUE-SETQ and PSETQ that presumably expand into SETQ), which I think is an unnecessary incompatible change. From JLarson.pa@Xerox.COM Fri Sep 9 01:54:23 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.3) id AA03916; Fri, 9 Sep 88 01:54:23 PDT Received: from Salvador.ms by ArpaGateway.ms ; 09 SEP 88 01:59:15 PDT Date: Fri, 09 Sep 88 01:59:06 PDT From: JLarson.pa@Xerox.COM Subject: Test message. Please delete. To: cloops-arisia@arisia.xerox.com Cc: Owner-CommonLoops.pa@Xerox.COM Message-Id: <880909-015915-1938@Xerox> Sorry. I needed to send this to test new mail software on Arisia. Please delete. From Owners-commonloops.pa@Xerox.COM Fri Sep 9 17:58:50 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.3) id AA13376; Fri, 9 Sep 88 17:58:50 PDT Received: from Salvador.ms by ArpaGateway.ms ; 09 SEP 88 13:27:03 PDT Return-Path: <@LEGAL-SEAFOOD.BBN.COM:cerys@bbn.com> Redistributed: commonloops.pa Received: from VAX.BBN.COM ([128.89.0.91]) by Xerox.COM ; 09 SEP 88 13:25:21 PDT Received: from legal-seafood.bbn.com by VAX.BBN.COM id aa09947; 9 Sep 88 15:17 EDT Message-Id: <2798824665-16223846@LEGAL-SEAFOOD> Sender: cerys@LEGAL-SEAFOOD.BBN.COM Date: Fri, 9 Sep 88 15:17:45 EDT From: Daniel Cerys To: commonloops.pa@Xerox.COM Subject: PCL on Explorers There appears to be a problem with the TI Explorer (Rel 4.1) that prevents AAAI PCL from running on it. The problem is with the support for DEFSETF and &rest arguments. I haven't had time to do a workaround for this yet, and am wondering whether anyone else has some sort of kludge that will get AAAI PCL up on Explorers? Dan From Common-Lisp-Object-System-mailer@SAIL.STANFORD.EDU Mon Sep 12 10:57:58 1988 Received: from SAIL.STANFORD.EDU by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.3) id AA05952; Mon, 12 Sep 88 10:57:58 PDT Received: from Sun.COM by SAIL.Stanford.EDU with TCP; 12 Sep 88 11:01:26 PDT Received: from snail.sun.com by Sun.COM (4.0/SMI-4.0) id AA10872; Mon, 12 Sep 88 10:58:11 PDT Received: from suntana.sun.com by snail.sun.com (4.0/SMI-4.0) id AA15636; Mon, 12 Sep 88 11:01:05 PDT Received: from localhost by suntana.sun.com (4.0/SMI-4.0) id AA00397; Mon, 12 Sep 88 11:00:54 PDT Message-Id: <8809121800.AA00397@suntana.sun.com> To: common-lisp-object-system@SAIL.STANFORD.EDU Subject: Fairfax Meeting Date: Mon, 12 Sep 88 11:00:50 PDT From: kempf@Sun.COM Is there any need or plan for a subcommittee meeting? jak From Owners-commonloops.pa@Xerox.COM Mon Sep 12 15:45:28 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.3) id AA07921; Mon, 12 Sep 88 15:45:28 PDT Received: from Burger.ms by ArpaGateway.ms ; 12 SEP 88 10:31:18 PDT Return-Path: Redistributed: commonloops.pa Received: from paris.Berkeley.EDU ([128.32.150.46]) by Xerox.COM ; 12 SEP 88 10:28:06 PDT Received: by paris.Berkeley.EDU (5.57/1.25) id AA00444; Mon, 12 Sep 88 09:06:30 PDT From: larus@paris.Berkeley.EDU (James Larus) Message-Id: <8809121606.AA00444@paris.Berkeley.EDU> To: Gregor.pa@Xerox.COM Cc: commonloops.pa@Xerox.COM Subject: Bug in PCL Reply-To: larus@ginger.Berkeley.EDU Date: Mon, 12 Sep 88 09:06:25 PDT In the AAAI edition of PCL there is a bug. In methods.lisp, GENERIC-FUNCTION-CACHE-SIZE is a declared constant. However, in dcode-pre1.lisp, the value (32) is used in the function templates, which makes it difficult to increase the size of the caches to improve PCL's performance. /Jim From Owners-CommonLoops.PA@Xerox.COM Mon Sep 12 16:31:43 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.3) id AA08242; Mon, 12 Sep 88 16:31:43 PDT Received: from Chardonnay.ms by ArpaGateway.ms ; 12 SEP 88 13:14:55 PDT Return-Path: Redistributed: CommonLoops.PA Received: from lucid.com ([192.26.25.1]) by Xerox.COM ; 12 SEP 88 13:12:40 PDT Received: from edsel ([192.9.200.1]) by heavens-gate.lucid.com id AA00452g; Mon, 12 Sep 88 12:12:26 PST Received: from armageddon.lucid.com by edsel id AA00810g; Mon, 12 Sep 88 13:07:13 PDT Received: by armageddon id AA09552g; Mon, 12 Sep 88 13:09:33 PDT Date: Mon, 12 Sep 88 13:09:33 PDT From: Lois Lew Message-Id: <8809122009.AA09552@armageddon.lucid.com> To: CommonLoops.PA@Xerox.COM Subject: [clagett@cs.unc.edu: PCL/CommonLoops newest version] Does this address exist?? -Lois Date: Mon, 12 Sep 88 15:49:18 From: William Clagett To: lew@cs.unc.edu Subject: PCL/CommonLoops newest version Sorry about that last one ... tried to do something outside of GNUEmacs and screwed it up. I'm trying to figure out how to get my hands on the latest version of PCL that works with LUCID. I've tried to contact CommonLoops@xerox.com but keep getting "Connection refused" messages. Please let me know if there is another place to get it from (maybe you?) or if there is another e-mail address to work with. On a completely different subject, I've heard rumours of the dismantling of the Arpanet. Are these true? If so, when, and whatever will we do? Thanks in advance, - Bruce From Owners-CommonLoops.pa@Xerox.COM Mon Sep 12 16:35:37 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.3) id AA08263; Mon, 12 Sep 88 16:35:37 PDT Received: from Cabernet.ms by ArpaGateway.ms ; 12 SEP 88 13:42:24 PDT Return-Path: Redistributed: CommonLoops.pa Received: from rand-unix.arpa ([10.3.0.7]) by Xerox.COM ; 12 SEP 88 13:40:21 PDT Received: by rand-unix.arpa; Mon, 12 Sep 88 13:32:22 PDT Message-Id: <8809122032.AA12980@rand-unix.arpa> Cc: CommonLoops.pa@Xerox.COM, dave@rand-unix.ARPA, shane@rand-unix.ARPA, steph%ixta@rand-unix.ARPA, burdorf@rand-unix.ARPA Subject: Re: redefining methods Date: Mon, 12 Sep 88 13:32:04 PDT From: burdorf@rand-unix.ARPA When debugging our CLOS-based window system, I redefine methods now an then. However, if I try to redefine a method that's already loaded, the system complains saying "Error: HIGHLIGHT-CHOSEN-ITEM already names an ordinary function or a macro, it can't be converted to a generic function. Error signalled by LOAD-DEFMETHOD. Broken at REAL-ADD-NAMED-METHOD." Is there any way around this? My file is 40 pages long and it takes a lot of time to get out of lisp and reload it each time that I make a change to one of the methods. chris burdorf From Gregor.pa@Xerox.COM Mon Sep 12 17:05:18 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.3) id AA08637; Mon, 12 Sep 88 17:05:18 PDT Received: from Semillon.ms by ArpaGateway.ms ; 12 SEP 88 16:58:02 PDT Date: Mon, 12 Sep 88 16:56 PDT From: Gregor.pa@Xerox.COM Subject: bug in all AAAI PCLs To: CommonLoops.pa@Xerox.COM Fcc: BD:>Gregor>mail>outgoing-mail-4.text.newest Message-Id: <19880912235620.9.GREGOR@PORTNOY.parc.xerox.com> Line-Fold: no There is a nasty little bug affecting :ACCESSORs and :WRITERs in all the AAAI PCLs. Anyone using a AAAI pcl should make this patch. * To save yourself some time, you can patch your running image simply by loading a compiled version of this function. * You can fix your compiled PCL simply by editing the dcode.lisp file and then using compile-file to compile that file. compile-pcl will work too of course, but will compile more files than really need be. ;from dcode.lisp (defun all-std-class-writers-miss (new-value arg wrapper .cache. cache-size offset generic-function) (setq offset (cache-key-from-wrappers-2 cache-size arg)) (let ((class (wrapper-class wrapper)) (method (lookup-method-1 generic-function t arg))) (if (null method) (no-applicable-method generic-function new-value arg) (let* ((slot-name (reader/writer-method-slot-name method)) (slot-pos (all-std-class-readers-miss-1 class wrapper slot-name))) (if (not (null slot-pos)) (progn (without-interrupts (setf (r/w-cache-key) wrapper) (setf (r/w-cache-val) slot-pos)) (setf (%svref (iwmc-class-static-slots arg) slot-pos) new-value)) (setf (slot-value-using-class class arg slot-name) new-value)))))) ------- From CL-Cleanup-mailer@SAIL.STANFORD.EDU Mon Sep 12 17:55:55 1988 Received: from SAIL.STANFORD.EDU by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.3) id AA09161; Mon, 12 Sep 88 17:55:55 PDT Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 12 Sep 88 17:47:38 PDT Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 458005; Mon 12-Sep-88 20:43:49 EDT Date: Mon, 12 Sep 88 20:42 EDT From: David A. Moon Subject: Issue: SYMBOL-MACROLET-DECLARE (version 1) To: CL-Cleanup@SAIL.STANFORD.EDU Cc: Gregor.pa@Xerox.COM, David N Gray , Patrick Dussud , kempf@Sun.COM, Glenn Andrew Kramer , common-lisp-object-system@SAIL.STANFORD.EDU, Jeffrey Piazza In-Reply-To: <19880802205147.3.GREGOR@PORTNOY.parc.xerox.com>, <2795614606-3753982@Kelvin>, <8808031719.AA12130@rainbow-warrior.lucid.com>, <8808031847.AA18770@suntana.sun.com>, <2795636967-5097451@Kelvin>, , <8808041525.AA20536@suntana.sun.com>, <2795711083-4281424@Kelvin>, <19880808171852.6.GREGOR@PORTNOY.parc.xerox.com>, <8808111506.AA11766@suntana.sun.com> Message-Id: <19880913004248.9.MOON@EUPHRATES.SCRC.Symbolics.COM> Line-Fold: No Issue: SYMBOL-MACROLET-DECLARE References: SYMBOL-MACROLET (88-002R page 2-81) WITH-ACCESSORS (88-002R page 2-88) WITH-SLOTS (88-002R page 2-92) Category: ADDITION Edit history: Version 1, 12-Sep-88, Moon Problem description: It would be both natural and nice to be able to write (with-slots (rho theta) point (declare (single-float rho theta)) ...computation...) Proposal (SYMBOL-MACROLET-DECLARE:ALLOW): Allow declarations at the head of the body of SYMBOL-MACROLET, and hence in WITH-ACCESSORS and WITH-SLOTS. Exactly the same declarations are allowed as for LET, with one exception: SYMBOL-MACROLET signals an error if a SPECIAL declaration names one of the symbols being defined as a symbol-macrolet. A type declaration of one of these symbols is equivalent to wrapping a THE expression around the expansion of that symbol. Test Cases/Examples: See problem description. Rationale: If SYMBOL-MACROLET is intended to resemble LET in syntax, it ought to allow declarations. When writing a SYMBOL-MACROLET directly, the user could just as easily write a THE expression instead of a type declaration. However, when invoking a macro such as WITH-SLOTS that expands into SYMBOL-MACROLET, the user does not have this option since the expansion is not supplied explicitly by the user. Current practice: SYMBOL-MACROLET was only tentatively added to Common Lisp 3 months ago. Cost to Implementors: Less than one man-hour. Cost to Users: None. Cost of non-adoption: Minor wart in the language. Benefits: More consistent language definition. Esthetics: More consistent language definition. Discussion: None. From Owners-commonloops.pa@Xerox.COM Mon Sep 12 18:08:25 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.3) id AA09292; Mon, 12 Sep 88 18:08:25 PDT Received: from Burger.ms by ArpaGateway.ms ; 12 SEP 88 18:07:09 PDT Return-Path: <@MCC.COM:halasz%sw.MCC.COM@MCC.COM> Redistributed: commonloops.pa Received: from MCC.COM ([10.3.0.62]) by Xerox.COM ; 12 SEP 88 18:03:04 PDT Received: from milano.sw.mcc.com by MCC.COM with TCP/SMTP; Mon 12 Sep 88 20:02:57-CDT Received: from oryan.sw.mcc.com by milano.sw.mcc.com (5.51/STP1.56) id AA02284; Mon, 12 Sep 88 20:02:55 CDT Date: Mon, 12 Sep 88 20:02:52 CDT From: Frank Halasz Message-Id: <8809130102.AA07215@oryan.sw.mcc.com> Received: by oryan.sw.mcc.com (3.2/STP1.14) id AA07215; Mon, 12 Sep 88 20:02:52 CDT To: commonloops.pa@Xerox.COM Subject: call-next-method and arguments to :before and :after methods The CLOS spec is surprisingly silent about the arguments to be passed to :before and :after methods. There are several possibilities. It seems to me that the current PCL (AAAI) implements the least sensible of these possiblities. Specifically, there are (at least) three possibilities: 1. :before and :after methods always get the original arguments, i.e., the arguments passed to the initial generic function call. (This implies that call-next-method cannot be used to modify the arguments to :before and :after methods.) 2. :before methods get the same arguments as will be passed to the most specific applicable primary method and :after methods get passed the same arguments as were passed to the least specific applicable primary method. (This way call-next-method in an :around method can be used to change the arguments to subsequent :before methods [as well as :after methods], while call-next-method in a primary method can be used to change the arguments to subsequent :after methods.) 3. Both :before and :after methods get passed the same arguments that will be passed to the most specific applicable primary method. (In other words, call-next-method in the primary methods cannot be used to modify the arguments passed to :after methods. However, call-next-method in :around methods can be used to modify the arguments to both :before and :after methods.) PCL implements the third of these, which seem like the least sensoible choice to me. I would vote for #2, but realize that #1 is probably the cleanest choice. What's the story here, both with respect to the lack of information in the CLOS spec and with respect to the choice made in the current PCL? -- Frank ------------------------------------ Frank Halasz MCC Software Technology 9390 Research Blvd Austin TX 78759. [512]338-3648 halasz@MCC.COM or {harvard,ihnp4,nike,seismo}!ut-sally!im4u!milano!halasz From Lanning.pa@Xerox.COM Mon Sep 12 19:08:33 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.3) id AA10199; Mon, 12 Sep 88 19:08:33 PDT Received: from Semillon.ms by ArpaGateway.ms ; 12 SEP 88 19:12:15 PDT Date: 12 Sep 88 19:11 PDT From: Stan Lanning Subject: Re: bug in all AAAI PCLs In-Reply-To: Gregor.pa's message of Mon, 12 Sep 88 16:56 PDT To: Gregor.pa@Xerox.COM Cc: CommonLoops.pa@Xerox.COM Message-Id: <880912-191215-2260@Xerox> Done. The PCL sources on {Phylum}, {nb:}, {pooh/n}pcl> and {pooh/n}pcl>next> have been updated. The Lucid/Sun4 binaries on {pooh/n}pcl> and {pooh/n}pcl>next> have been updated. The XeroxLisp binaries on {Phylum}medley> and {nb:}medley> have been updated. ----- smL From Owners-commonloops.pa@Xerox.COM Mon Sep 12 21:05:41 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.3) id AA10940; Mon, 12 Sep 88 21:05:41 PDT Received: from Semillon.ms by ArpaGateway.ms ; 12 SEP 88 21:10:52 PDT Return-Path: <@MCC.COM:halasz%sw.MCC.COM@MCC.COM> Redistributed: commonloops.pa Received: from MCC.COM ([10.3.0.62]) by Xerox.COM ; 12 SEP 88 21:09:14 PDT Received: from milano.sw.mcc.com by MCC.COM with TCP/SMTP; Mon 12 Sep 88 23:09:04-CDT Received: from oryan.sw.mcc.com by milano.sw.mcc.com (5.51/STP1.56) id AA06535; Mon, 12 Sep 88 23:09:00 CDT Date: Mon, 12 Sep 88 23:08:56 CDT From: Frank Halasz Message-Id: <8809130408.AA07542@oryan.sw.mcc.com> Received: by oryan.sw.mcc.com (3.2/STP1.14) id AA07542; Mon, 12 Sep 88 23:08:56 CDT To: commonloops.pa@Xerox.COM, gregor.PA@Xerox.COM, rcp@sw.MCC.COM Subject: Bug (and fix for same) in ALL-STD-CLASS-WRITERS-MISS There is an bug in ALL-STD-CLASS-WRITERS-MISS (dcode.lisp) that can cause some weird behavior in rare circumstances. The following typescript illustrates a simple case that trips up the bug. The fix is to add NEW-VALUE as an argument to the call LOOKUP-METHOD-1 inside ALL-STD-CLASS-WRITERS-MISS as illustrated below the typescript. ;;;-----Example pcl::*PCL-SYSTEM-DATE* "8/28/88 (beta rev 1) AAAI PCL " (use-package :pcl) T (defclass a ()((a :accessor b))) NIL (defclass b ()((b :accessor b))) NIL (setq a (make-instance 'a)) # (setf (b a) 45) Error: When attempting to set the slot's value to 45 (setf of slot-value), the slot B is missing from the object #. [1] ;;;---- Fix ;; from dcode.lisp (defun all-std-class-writers-miss (new-value arg wrapper .cache. cache-size offset generic-function) (setq offset (cache-key-from-wrappers-2 cache-size arg)) (let ((class (wrapper-class wrapper)) (method (lookup-method-1 generic-function new-value arg))) ;;; ;;; FIX --------- ;;; (if (null method) (no-applicable-method generic-function new-value arg) (let* ((slot-name (reader/writer-method-slot-name method)) (slot-pos (all-std-class-readers-miss-1 class wrapper slot-name))) (if (not (null slot-pos)) (progn (without-interrupts (setf (r/w-cache-key) wrapper) (setf (r/w-cache-val) slot-pos)) (setf (%svref (iwmc-class-static-slots arg) slot-pos) new-value)) (setf (slot-value-using-class class arg slot-name) new-value)))))) -- Frank --------- Frank Halasz MCC Software Technology 9390 Research Blvd Austin TX 78759. [512]338-3648 halasz@MCC.COM or {harvard,ihnp4,nike,seismo}!ut-sally!im4u!milano!halasz From Gregor.pa@Xerox.COM Mon Sep 12 22:47:09 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.3) id AA08637; Mon, 12 Sep 88 17:05:18 PDT Received: from Semillon.ms by ArpaGateway.ms ; 12 SEP 88 16:58:02 PDT Date: Mon, 12 Sep 88 16:56 PDT From: Gregor.pa@Xerox.COM Subject: bug in all AAAI PCLs To: CommonLoops.pa@Xerox.COM Fcc: BD:>Gregor>mail>outgoing-mail-4.text.newest Message-Id: <19880912235620.9.GREGOR@PORTNOY.parc.xerox.com> Line-Fold: no There is a nasty little bug affecting :ACCESSORs and :WRITERs in all the AAAI PCLs. Anyone using a AAAI pcl should make this patch. * To save yourself some time, you can patch your running image simply by loading a compiled version of this function. * You can fix your compiled PCL simply by editing the dcode.lisp file and then using compile-file to compile that file. compile-pcl will work too of course, but will compile more files than really need be. ;from dcode.lisp (defun all-std-class-writers-miss (new-value arg wrapper .cache. cache-size offset generic-function) (setq offset (cache-key-from-wrappers-2 cache-size arg)) (let ((class (wrapper-class wrapper)) (method (lookup-method-1 generic-function t arg))) (if (null method) (no-applicable-method generic-function new-value arg) (let* ((slot-name (reader/writer-method-slot-name method)) (slot-pos (all-std-class-readers-miss-1 class wrapper slot-name))) (if (not (null slot-pos)) (progn (without-interrupts (setf (r/w-cache-key) wrapper) (setf (r/w-cache-val) slot-pos)) (setf (%svref (iwmc-class-static-slots arg) slot-pos) new-value)) (setf (slot-value-using-class class arg slot-name) new-value)))))) ------- From Owners-CommonLoops.PA@Xerox.COM Mon Sep 12 22:46:28 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.3) id AA08242; Mon, 12 Sep 88 16:31:43 PDT Received: from Chardonnay.ms by ArpaGateway.ms ; 12 SEP 88 13:14:55 PDT Return-Path: Redistributed: CommonLoops.PA Received: from lucid.com ([192.26.25.1]) by Xerox.COM ; 12 SEP 88 13:12:40 PDT Received: from edsel ([192.9.200.1]) by heavens-gate.lucid.com id AA00452g; Mon, 12 Sep 88 12:12:26 PST Received: from armageddon.lucid.com by edsel id AA00810g; Mon, 12 Sep 88 13:07:13 PDT Received: by armageddon id AA09552g; Mon, 12 Sep 88 13:09:33 PDT Date: Mon, 12 Sep 88 13:09:33 PDT From: Lois Lew Message-Id: <8809122009.AA09552@armageddon.lucid.com> To: CommonLoops.PA@Xerox.COM Subject: [clagett@cs.unc.edu: PCL/CommonLoops newest version] Does this address exist?? -Lois Date: Mon, 12 Sep 88 15:49:18 From: William Clagett To: lew@cs.unc.edu Subject: PCL/CommonLoops newest version Sorry about that last one ... tried to do something outside of GNUEmacs and screwed it up. I'm trying to figure out how to get my hands on the latest version of PCL that works with LUCID. I've tried to contact CommonLoops@xerox.com but keep getting "Connection refused" messages. Please let me know if there is another place to get it from (maybe you?) or if there is another e-mail address to work with. On a completely different subject, I've heard rumours of the dismantling of the Arpanet. Are these true? If so, when, and whatever will we do? Thanks in advance, - Bruce From Owners-commonloops.pa@Xerox.COM Mon Sep 12 23:17:09 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.3) id AA09292; Mon, 12 Sep 88 18:08:25 PDT Received: from Burger.ms by ArpaGateway.ms ; 12 SEP 88 18:07:09 PDT Return-Path: <@MCC.COM:halasz%sw.MCC.COM@MCC.COM> Redistributed: commonloops.pa Received: from MCC.COM ([10.3.0.62]) by Xerox.COM ; 12 SEP 88 18:03:04 PDT Received: from milano.sw.mcc.com by MCC.COM with TCP/SMTP; Mon 12 Sep 88 20:02:57-CDT Received: from oryan.sw.mcc.com by milano.sw.mcc.com (5.51/STP1.56) id AA02284; Mon, 12 Sep 88 20:02:55 CDT Date: Mon, 12 Sep 88 20:02:52 CDT From: Frank Halasz Message-Id: <8809130102.AA07215@oryan.sw.mcc.com> Received: by oryan.sw.mcc.com (3.2/STP1.14) id AA07215; Mon, 12 Sep 88 20:02:52 CDT To: commonloops.pa@Xerox.COM Subject: call-next-method and arguments to :before and :after methods The CLOS spec is surprisingly silent about the arguments to be passed to :before and :after methods. There are several possibilities. It seems to me that the current PCL (AAAI) implements the least sensible of these possiblities. Specifically, there are (at least) three possibilities: 1. :before and :after methods always get the original arguments, i.e., the arguments passed to the initial generic function call. (This implies that call-next-method cannot be used to modify the arguments to :before and :after methods.) 2. :before methods get the same arguments as will be passed to the most specific applicable primary method and :after methods get passed the same arguments as were passed to the least specific applicable primary method. (This way call-next-method in an :around method can be used to change the arguments to subsequent :before methods [as well as :after methods], while call-next-method in a primary method can be used to change the arguments to subsequent :after methods.) 3. Both :before and :after methods get passed the same arguments that will be passed to the most specific applicable primary method. (In other words, call-next-method in the primary methods cannot be used to modify the arguments passed to :after methods. However, call-next-method in :around methods can be used to modify the arguments to both :before and :after methods.) PCL implements the third of these, which seem like the least sensoible choice to me. I would vote for #2, but realize that #1 is probably the cleanest choice. What's the story here, both with respect to the lack of information in the CLOS spec and with respect to the choice made in the current PCL? -- Frank ------------------------------------ Frank Halasz MCC Software Technology 9390 Research Blvd Austin TX 78759. [512]338-3648 halasz@MCC.COM or {harvard,ihnp4,nike,seismo}!ut-sally!im4u!milano!halasz From Common-Lisp-Object-System-mailer@SAIL.STANFORD.EDU Tue Sep 13 07:03:14 1988 Received: from SAIL.STANFORD.EDU by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.3) id AA15122; Tue, 13 Sep 88 07:03:14 PDT Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 13 Sep 88 07:08:47 PDT Received: by decwrl.dec.com (5.54.5/4.7.34) id AA24481; Tue, 13 Sep 88 07:06:10 PDT Date: Tue, 13 Sep 88 07:06:10 PDT Message-Id: <8809131406.AA24481@decwrl.dec.com> From: piazza%lisp.DEC@decwrl.dec.com (Jeffrey Piazza) To: Moon@stony-brook.scrc.symbolics.com Subject: RE: Issue: SYMBOL-MACROLET-DECLARE (version 1) This seems like a reasonable proposal and does make SYMBOL-MACROLET more consistent with LET. This may be a separate issue, but somewhere we should nail down the interpretation of e.g. (symbol-macrolet ((foo bar)) ... (locally (declare (special foo)) ...foo...)) As currently specified, only a new binding for FOO can turn off its interpretation as a symbol macro. I'd like to see some language that said that a SPECIAL declaration also shadows the symbol macro scope. The limit case, which your proposal makes "an error", might then reasonably have a null semantics: (symbol-macrolet ((foo bar)) (declare (special foo)) ...) might be interpreted as (locally (declare (special foo)) ...) I don't have strong feelings one way or the other about this part--it doesn't seem possible to bring SYMBOL-MACROLET into complete consistency with LET here. /JEP From CL-Cleanup-mailer@SAIL.STANFORD.EDU Tue Sep 13 11:56:07 1988 Received: from SAIL.STANFORD.EDU by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.3) id AA18781; Tue, 13 Sep 88 11:56:07 PDT Received: from lucid.com by SAIL.Stanford.EDU with TCP; 13 Sep 88 11:45:49 PDT Received: from rainbow-warrior ([192.9.200.16]) by heavens-gate.lucid.com id AA00217g; Tue, 13 Sep 88 10:43:38 PST Received: by rainbow-warrior id AA03013g; Tue, 13 Sep 88 11:41:59 PDT Date: Tue, 13 Sep 88 11:41:59 PDT From: Patrick Dussud Message-Id: <8809131841.AA03013@rainbow-warrior> To: piazza%lisp.DEC@decwrl.dec.com Cc: Moon@stony-brook.scrc.symbolics.com, Common-Lisp-Object-System@SAIL.STANFORD.EDU, cl-cleanup@SAIL.STANFORD.EDU In-Reply-To: Jeffrey Piazza's message of Tue, 13 Sep 88 07:06:10 PDT <8809131406.AA24481@decwrl.dec.com> Subject: Issue: SYMBOL-MACROLET-DECLARE (version 1) Date: Tue, 13 Sep 88 07:06:10 PDT From: piazza%lisp.DEC@decwrl.dec.com (Jeffrey Piazza) This seems like a reasonable proposal and does make SYMBOL-MACROLET more consistent with LET. This may be a separate issue, but somewhere we should nail down the interpretation of e.g. (symbol-macrolet ((foo bar)) ... (locally (declare (special foo)) ...foo...)) As currently specified, only a new binding for FOO can turn off its interpretation as a symbol macro. I'd like to see some language that said that a SPECIAL declaration also shadows the symbol macro scope. That seems reasonable. The limit case, which your proposal makes "an error", might then reasonably have a null semantics: (symbol-macrolet ((foo bar)) (declare (special foo)) ...) might be interpreted as (locally (declare (special foo)) ...) This would be a very bad idea, it would be very inconsistent with LET, and would introduce a bizarre semantics: Throw away what I just said in the binding list. I think that it should be an error. Patrick. From Owners-CommonLoops.PA@Xerox.COM Tue Sep 13 18:04:19 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.3) id AA08242; Mon, 12 Sep 88 16:31:43 PDT Received: from Chardonnay.ms by ArpaGateway.ms ; 12 SEP 88 13:14:55 PDT Return-Path: Redistributed: CommonLoops.PA Received: from lucid.com ([192.26.25.1]) by Xerox.COM ; 12 SEP 88 13:12:40 PDT Received: from edsel ([192.9.200.1]) by heavens-gate.lucid.com id AA00452g; Mon, 12 Sep 88 12:12:26 PST Received: from armageddon.lucid.com by edsel id AA00810g; Mon, 12 Sep 88 13:07:13 PDT Received: by armageddon id AA09552g; Mon, 12 Sep 88 13:09:33 PDT Date: Mon, 12 Sep 88 13:09:33 PDT From: Lois Lew Message-Id: <8809122009.AA09552@armageddon.lucid.com> To: CommonLoops.PA@Xerox.COM Subject: [clagett@cs.unc.edu: PCL/CommonLoops newest version] Does this address exist?? -Lois Date: Mon, 12 Sep 88 15:49:18 From: William Clagett To: lew@cs.unc.edu Subject: PCL/CommonLoops newest version Sorry about that last one ... tried to do something outside of GNUEmacs and screwed it up. I'm trying to figure out how to get my hands on the latest version of PCL that works with LUCID. I've tried to contact CommonLoops@xerox.com but keep getting "Connection refused" messages. Please let me know if there is another place to get it from (maybe you?) or if there is another e-mail address to work with. On a completely different subject, I've heard rumours of the dismantling of the Arpanet. Are these true? If so, when, and whatever will we do? Thanks in advance, - Bruce From Owners-commonloops.pa@Xerox.COM Tue Sep 13 19:55:41 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.3) id AA23384; Tue, 13 Sep 88 18:59:44 PDT Received: from Semillon.ms by ArpaGateway.ms ; 13 SEP 88 13:18:18 PDT Return-Path: Redistributed: commonloops.pa Received: from research.att.com ([10.5.0.89]) by Xerox.COM ; 13 SEP 88 13:16:33 PDT From: tk@hunny.att.com Date: Tue, 13 Sep 88 16:15:16 EDT To: commonloops.pa@Xerox.COM Subject: :class slot allocation Message-Id: <880913-131818-372@Xerox> I've just discovered that :class slot allocation in CLOS isn't what I thought it was, specifically the meaning of sharing a :class slot among instances of a class and its subclasses. Evidently shared slots are not shared throughout the class hierarchy, e.g., given (defclass foo () ((baz :allocation :class))) (defclass bar (foo)) the slot baz is shared among instances of foo, and among instances of bar, but not among instance of foo and bar; that is, if I change a foo's baz slot, the baz slot of any instance of bar doesn't change. My apparent misunderstanding of the CLOS spec is undoubtedly colored by my experience with C++, which has something similar to ":class" allocation: a C++ class can have a "static" member, which is a shared by all instances of the class. The difference between C++ and CLOS here is that it is also shared throughout the hierarchy of that classes subclasses. Is there any way to achieve the latter behavior ("static" slot allocation) in CLOS? Of course I can implement this behavior using global data, but I'd rather not admit defeat that easily, since this data is really describing a class attribute. Using the given semantics of :class slots, and explicitly propogating changes of a shared slot to the corresponding shared slot of the subclasses and superclasses seems unacceptable. Is a non-standard metaclass necessary, and if so, is the current CLOS implementation up to it? tom kirk tk@moss.att.com (incidentally, the description of the behavior of :class allocation in the CLOS spec is very similar to that of static class members in the C++ reference; I guess, after re-reading it a few times, that the wording in the CLOS spec is arguably `more correct') From Owners-commonloops.pa@Xerox.COM Tue Sep 13 22:12:38 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.3) id AA26080; Tue, 13 Sep 88 22:12:38 PDT Received: from Riesling.ms by ArpaGateway.ms ; 13 SEP 88 22:17:22 PDT Return-Path: <@MCC.COM,@BRAHMA.ACA.MCC.COM:Gumby@MCC.COM> Redistributed: commonloops.pa Received: from MCC.COM ([10.3.0.62]) by Xerox.COM ; 13 SEP 88 22:15:46 PDT Received: from BRAHMA.ACA.MCC.COM (BRAHMA.ACA.MCC.COM.#Chaos) by MCC.#Chaos with Chaos/SMTP; Wed 14 Sep 88 00:14:23-CDT Date: Wed, 14 Sep 88 00:14 CDT From: David Vinayak Wallace Subject: :class slot allocation To: tk@hunny.att.com Cc: commonloops.pa@Xerox.COM In-Reply-To: <880913-131818-372@Xerox> Message-Id: <880914001419.0.GUMBY@BRAHMA.ACA.MCC.COM> Date: Tue, 13 Sep 88 16:15:16 EDT From: tk@hunny.att.com Is there any way to achieve the latter behavior ("static" slot allocation) in CLOS? Of course I can implement this behavior using global data, but I'd rather not admit defeat that easily, since this data is really describing a class attribute. Sounds like a job for the Mythical Metaclass Protocol! From Owners-commonloops.pa@Xerox.COM Wed Sep 14 12:55:13 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.3) id AA02288; Wed, 14 Sep 88 12:55:13 PDT Received: from Cabernet.ms by ArpaGateway.ms ; 14 SEP 88 09:48:23 PDT Return-Path: Redistributed: commonloops.pa Received: from lucid.com ([192.26.25.1]) by Xerox.COM ; 14 SEP 88 09:46:19 PDT Received: from rainbow-warrior ([192.9.200.16]) by heavens-gate.lucid.com id AA00151g; Wed, 14 Sep 88 08:45:11 PST Received: by rainbow-warrior id AA04848g; Wed, 14 Sep 88 09:42:52 PDT Date: Wed, 14 Sep 88 09:42:52 PDT From: Patrick Dussud Message-Id: <8809141642.AA04848@rainbow-warrior> To: tk@hunny.att.com Cc: commonloops.pa@Xerox.COM In-Reply-To: tk@hunny.att.com's message of Tue, 13 Sep 88 16:15:16 EDT <880913-131818-372@Xerox> Subject: :class slot allocation Redistributed: commonloops.pa From: tk@hunny.att.com Date: Tue, 13 Sep 88 16:15:16 EDT I've just discovered that :class slot allocation in CLOS isn't what I thought it was, specifically the meaning of sharing a :class slot among instances of a class and its subclasses. Evidently shared slots are not shared throughout the class hierarchy, e.g., given (defclass foo () ((baz :allocation :class))) (defclass bar (foo)) the slot baz is shared among instances of foo, and among instances of bar, but not among instance of foo and bar; that is, if I change a foo's baz slot, the baz slot of any instance of bar doesn't change. This appears to be a bug in PCL. If the slot BAZ is not redefined in bar, the instances of bar share baz with the instances of foo. (Refer to the CLOS specs: 88-002R, page 1-12, second paragraph under "Inheritance of Slots and Slot Options") The correct way to obtain two shared slots, one for the instances of foo, one for the instances of bar, is to redefine baz in bar: (defclass bar (foo) ((baz :allocation :class))) Patrick. From Owners-CommonLoops.pa@Xerox.COM Wed Sep 14 16:14:46 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.3) id AA07246; Wed, 14 Sep 88 16:14:46 PDT Received: from Cabernet.ms by ArpaGateway.ms ; 14 SEP 88 16:03:57 PDT Return-Path: Redistributed: CommonLoops.pa Received: from KL.SRI.COM ([10.1.0.2]) by Xerox.COM ; 14 SEP 88 16:02:28 PDT Date: Wed, 14 Sep 88 15:02:49 PDT From: Wei-Han Chu Subject: PCL for Gold-Hill Common Lisp To: CommonLoops.pa@Xerox.COM Cc: chu@KL.SRI.COM Message-Id: <12430585004.29.CHU@KL.SRI.COM> The current version of PCL does not seem to work in Gold-Hill Common Lisp. Does anyone have a patch to allow PCL to compile in Gold-Hill Common Lisp? Wei-Han Chu Varian Associates ------- From Common-Lisp-Object-System-mailer@SAIL.STANFORD.EDU Wed Sep 14 18:12:27 1988 Received: from SAIL.STANFORD.EDU by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.3) id AA09328; Wed, 14 Sep 88 18:12:27 PDT Received: from Sun.COM by SAIL.Stanford.EDU with TCP; 14 Sep 88 18:17:25 PDT Received: from snail.sun.com by Sun.COM (4.0/SMI-4.0) id AA22171; Wed, 14 Sep 88 18:13:51 PDT Received: from lukasiewicz.sun.com by snail.sun.com (4.0/SMI-4.0) id AA05670; Wed, 14 Sep 88 18:16:43 PDT Received: by lukasiewicz.sun.com (4.0/SMI-4.0) id AA00310; Wed, 14 Sep 88 17:10:07 PDT Date: Wed, 14 Sep 88 17:10:07 PDT From: jrose@Sun.COM (John Rose) Message-Id: <8809150010.AA00310@lukasiewicz.sun.com> To: halasz@SW.MCC.COM Cc: common-lisp-object-system@SAIL.STANFORD.EDU In-Reply-To: Frank Halasz's message of Wed, 14 Sep 88 18:48:41 CDT <8809142348.AA11205@oryan.sw.mcc.com> Subject: call-next-method and arguments to :before and :after methods [In response to Frank Halasz's query, I sent him a pointer to the definition of standard method combination in the manual pages for DEFINE-METHOD-COMBINATION. Here's the subsequent conversation. I think the whole exchange may point up an omission in the CLOS documentation.] Date: Wed, 14 Sep 88 18:48:41 CDT From: Frank Halasz Thanks, the code under DEFINE-METHOD-COMBINATION helps. But its still seems a bit ambiguous due to the interpretation of the make-method clause in call-method. Specifically, call-method passes on the "arguments that were supplied to the effective method form containing the invocation of call-method." The effective method form in the example code boils down to the following: `(call-method ,(first around) (,@(rest around) (make-method (multiple-value-prog1 (progn ,@(call-methods before) (call-method ,(first primary) ,(rest primary))) ,@(call-methods (reverse after)))))) The issue is whether the call-method invocations inside the make-method are part of the (outer) effective method form. Alternatively, make-method could be considered as bounding a "new" inner effective method form. The current PCL effectively takes the latter alternative. It seems to me that the spec takes the former reading, in which case :before and :after methods ought to get the arguments passed down to the original call to the genric function. -- Frank The "alternative" that CALL-METHODs are lexically scoped to the innermost MAKE-METHOD seems to be the only viable alternative. If, as you suggest, scoping were to the outer effective method body, there would be in fact no way to deliver arguments as adjusted by CALL-NEXT-METHOD to any method other than those created implicitly by the system; any method you make with MAKE-METHOD would be powerless to access the adjusted arguments, because when it tried to use CALL-METHOD (as it must), the adjusted arguments would be rebound to their original values. So what you're suggesting would probably be a serious design flaw. While your suggested semantics would be unable to simulate the current (and historically correct; see next paragraph) semantics, the reverse is not the case. In order to simulate your suggested semantics, say for a special-purpose method combination type, FLET bindings could be used to capture code at the outer scoping level, which could then be invoked from a MAKE-METHOD at any level: `(flet ((do-before-around () ,@(call-methods before-around))) (call-method ,(first around) (,@(rest around) (make-method (multiple-value-prog1 (progn (do-before-around) ...)))))) By the way, I find it totally natural that :AROUND methods surround primary, :BEFORE, and :AFTER methods, and are thus able to adjust their actual arguments. This is the way it worked in Flavors, which is where this method combination stuff comes from, and I've never heard anyone question it before. The grouping is this: AROUND( BEFORE PRIMARY AFTER ) rather than this: BEFORE AROUND( PRIMARY ) AFTER (Now, I don't find CLOS standard method combination as a whole very natural, for larger reasons, and I wish that the Flavors influence were less strong here, but that's a separate issue.) It is perhaps a documentation bug that the scoping of CALL-METHOD is not better spelled out. Does it really say "arguments that were supplied to the effective method form containing the invocation of call-method"? I can't find any statement one way or the other in my version of the spec, which is an old version. I would have expected words like "innermost effective method or MAKE-METHOD form" instead of "effective method form". (This bug report is the reason for the CC to the Powers That Be.) -- John From Owners-commonloops.pa@Xerox.COM Thu Sep 15 09:28:08 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.3) id AA02288; Wed, 14 Sep 88 12:55:13 PDT Received: from Cabernet.ms by ArpaGateway.ms ; 14 SEP 88 09:48:23 PDT Return-Path: Redistributed: commonloops.pa Received: from lucid.com ([192.26.25.1]) by Xerox.COM ; 14 SEP 88 09:46:19 PDT Received: from rainbow-warrior ([192.9.200.16]) by heavens-gate.lucid.com id AA00151g; Wed, 14 Sep 88 08:45:11 PST Received: by rainbow-warrior id AA04848g; Wed, 14 Sep 88 09:42:52 PDT Date: Wed, 14 Sep 88 09:42:52 PDT From: Patrick Dussud Message-Id: <8809141642.AA04848@rainbow-warrior> To: tk@hunny.att.com Cc: commonloops.pa@Xerox.COM In-Reply-To: tk@hunny.att.com's message of Tue, 13 Sep 88 16:15:16 EDT <880913-131818-372@Xerox> Subject: :class slot allocation Redistributed: commonloops.pa From: tk@hunny.att.com Date: Tue, 13 Sep 88 16:15:16 EDT I've just discovered that :class slot allocation in CLOS isn't what I thought it was, specifically the meaning of sharing a :class slot among instances of a class and its subclasses. Evidently shared slots are not shared throughout the class hierarchy, e.g., given (defclass foo () ((baz :allocation :class))) (defclass bar (foo)) the slot baz is shared among instances of foo, and among instances of bar, but not among instance of foo and bar; that is, if I change a foo's baz slot, the baz slot of any instance of bar doesn't change. This appears to be a bug in PCL. If the slot BAZ is not redefined in bar, the instances of bar share baz with the instances of foo. (Refer to the CLOS specs: 88-002R, page 1-12, second paragraph under "Inheritance of Slots and Slot Options") The correct way to obtain two shared slots, one for the instances of foo, one for the instances of bar, is to redefine baz in bar: (defclass bar (foo) ((baz :allocation :class))) Patrick. From Owners-CommonLoops.pa@Xerox.COM Thu Sep 15 09:58:08 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.3) id AA07246; Wed, 14 Sep 88 16:14:46 PDT Received: from Cabernet.ms by ArpaGateway.ms ; 14 SEP 88 16:03:57 PDT Return-Path: Redistributed: CommonLoops.pa Received: from KL.SRI.COM ([10.1.0.2]) by Xerox.COM ; 14 SEP 88 16:02:28 PDT Date: Wed, 14 Sep 88 15:02:49 PDT From: Wei-Han Chu Subject: PCL for Gold-Hill Common Lisp To: CommonLoops.pa@Xerox.COM Cc: chu@KL.SRI.COM Message-Id: <12430585004.29.CHU@KL.SRI.COM> The current version of PCL does not seem to work in Gold-Hill Common Lisp. Does anyone have a patch to allow PCL to compile in Gold-Hill Common Lisp? Wei-Han Chu Varian Associates ------- From Common-Lisp-Object-System-mailer@SAIL.STANFORD.EDU Thu Sep 15 12:58:09 1988 Received: from SAIL.STANFORD.EDU by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.3) id AA18342; Thu, 15 Sep 88 12:58:09 PDT Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 15 Sep 88 13:03:38 PDT Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 459910; Thu 15-Sep-88 16:00:52 EDT Date: Thu, 15 Sep 88 16:00 EDT From: David A. Moon Subject: call-next-method and arguments to :before and :after methods To: John Rose , halasz@SW.MCC.COM Cc: common-lisp-object-system@SAIL.STANFORD.EDU In-Reply-To: <8809150010.AA00310@lukasiewicz.sun.com> Message-Id: <19880915200041.6.MOON@EUPHRATES.SCRC.Symbolics.COM> It's true that when call-next-method was given the ability to change the arguments, not all of the places in the CLOS specification that should have been updated were. Thus some pages don't discuss what happens in this case. Page 2-11 of 88-002R (describing call-method) ought to make it clear that when an invocation of call-method is nested inside an invocation of make-method, the arguments passed along by call-method are the arguments that were supplied to the make-method, not the arguments supplied to the original generic function call. Thus call-next-method in a :around method can alter the arguments seen by :before and :after methods. I'll send something about this to the Cleanup committee, after waiting a few days for comments. From Common-Lisp-Object-System-mailer@SAIL.STANFORD.EDU Thu Sep 15 13:25:53 1988 Received: from SAIL.STANFORD.EDU by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.3) id AA18692; Thu, 15 Sep 88 13:25:53 PDT Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 15 Sep 88 13:31:35 PDT Received: from Cabernet.ms by ArpaGateway.ms ; 15 SEP 88 13:24:01 PDT Date: 15 Sep 88 13:23 PDT From: masinter.pa@Xerox.COM Subject: Re: call-next-method and arguments to :before and :after methods In-Reply-To: David A. Moon 's message of Thu, 15 Sep 88 16:00 EDT To: David A. Moon Cc: John Rose , halasz@sw.MCC.COM, common-lisp-object-system@SAIL.STANFORD.EDU Message-Id: <880915-132401-3007@Xerox> If there are editorial problems in the CLOS specification where some items are only explained in one place and not in others, I don't think we need to have full-fledged cleanup issues associated with them. There's some judgement involved, but the primary motivation for the rather extensive debates we have on cl-cleanup is to make sure that the issues of costs and benefits-- especially for incompatible changes-- are fully addressed. So: I think symbol-macrolet deserves to be debated as a "cleanup", but if there is general agreement of the CLOS committee that the document does not reflect the intent, I think you should just handle them as editorial amendments. From Owners-CommonLoops.pa@Xerox.COM Fri Sep 16 17:05:02 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.3) id AA03540; Fri, 16 Sep 88 17:05:02 PDT Received: from Burger.ms by ArpaGateway.ms ; 16 SEP 88 13:18:17 PDT Return-Path: Redistributed: CommonLoops.pa Received: from PEBBLES.BBN.COM ([128.89.1.5]) by Xerox.COM ; 16 SEP 88 13:16:04 PDT To: CommonLoops.pa@Xerox.COM Cc: kanderson@PEBBLES.BBN.COM Subject: unoptimized Slot-value and other things Date: Fri, 16 Sep 88 16:18:22 -0400 From: kanderso@PEBBLES.BBN.COM Message-Id: <880916-131817-1277@Xerox> ;;; -*- Package: PCL -*- In "8/28/88 (beta rev 1) AAAI PCL" on a Symbolics LISPM. Several things: 1. In the following 2 methods slot-value gets optimized in the first and not in the second. Shouldn't the second one be optimized too? (pcl:DEFMETHOD :REMPROP ((self PROPERTY-LIST-MIXIN) INDICATOR) (CHECK-TYPE INDICATOR SYMBOL) (let ((list (slot-value self 'property-list))) (remf list indicator) (setf (slot-value self 'property-list) list))) (pcl:DEFMETHOD :REMPROP ((self PROPERTY-LIST-MIXIN) INDICATOR) (CHECK-TYPE INDICATOR SYMBOL) (remf (slot-value self 'property-list) indicator)) 2. On Symbolics machines "M-X Edit Compiler Warnings" has trouble finding where to go in the file because "(PCL:TOP-LEVEL-FORM ..." isn't really there. Can this be improved on? M-. seems to know what to search for! Here are some example warnings: Warnings for file CONGER:>pcl>new>floid>vanilla For Function (PCL:TOP-LEVEL-FORM (PCL:METHOD (CL:SETF :GET) (FLOID:PROPERTY-LIST-MIXIN T))) While compiling FLOID::PROPERTY: The variable FLOID::PROPERTY is unknown and has been declared SPECIAL For Function (:INTERNAL (PCL:TOP-LEVEL-FORM (PCL:METHOD FLOID::GET-HANDLER-FOR (LIST PCL:OBJECT))) 0) FLOID::GBOUNDP was referenced but not defined. FLOID::GDEFINITION was referenced but not defined. 3. When you compile the method below, the compiler complains that initargs isn't used, although i think of them as being used by call-next-method. Does this seem right? (defmethod *make-instance ((class instances-class-mixin) &rest initargs) (let ((instance (call-next-method))) (add-instance class instance) instance)) 4. The body of the method above expands into: #'(LAMBDA (#:CLASS &REST #:AMPERSAND-ARGS) (LET ((.NEXT-METHOD. (CAR *NEXT-METHODS*)) (*NEXT-METHODS* (CDR *NEXT-METHODS*))) (FLET ((CALL-NEXT-METHOD (&REST CNM-ARGS) (IF .NEXT-METHOD. (IF CNM-ARGS (APPLY .NEXT-METHOD. CNM-ARGS) (APPLY .NEXT-METHOD. #:CLASS #:AMPERSAND-ARGS)) (ERROR "No next method.")))) (APPLY #'(LAMBDA (CLASS &REST INITARGS) (DECLARE (CLASS CLASS INSTANCES-CLASS-MIXIN)) (PROGN CLASS) (BLOCK *MAKE-INSTANCE (LET ((INSTANCE (CALL-NEXT-METHOD))) (ADD-INSTANCE CLASS INSTANCE) INSTANCE))) #:CLASS #:AMPERSAND-ARGS)))))))) with a LITTLE more work on already HAIRY function, couldn't we get expand-defmethod-internal to expand the call-next-method in line to something like: #'(LAMBDA (#:CLASS &REST #:AMPERSAND-ARGS) (LET ((.NEXT-METHOD. (CAR *NEXT-METHODS*)) (*NEXT-METHODS* (CDR *NEXT-METHODS*))) (APPLY #'(LAMBDA (CLASS &REST INITARGS) (DECLARE (CLASS CLASS INSTANCES-CLASS-MIXIN)) (PROGN CLASS) (BLOCK *MAKE-INSTANCE (LET ((INSTANCE (if .next-method. (apply .next-method. #:class #:ampersand-args) (ERROR "No next method."))) (ADD-INSTANCE CLASS INSTANCE) INSTANCE)))) #:CLASS #:AMPERSAND-ARGS))))) This would save a funcall and conditional branch in the most common case. We only need the functional semantics of call-next-method when someone does something like: (return (cons #'call-next-method (call-next-method))) From Owners-commonloops.PA@Xerox.COM Fri Sep 16 17:09:12 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.3) id AA03571; Fri, 16 Sep 88 17:09:12 PDT Received: from Riesling.ms by ArpaGateway.ms ; 16 SEP 88 14:22:44 PDT Return-Path: Redistributed: commonloops.PA Received: from SRI-ROBOTX.ARPA ([128.18.3.100]) by Xerox.COM ; 16 SEP 88 14:19:53 PDT Date: Fri, 16 Sep 88 14:15:14 PST From: Doug Ruth Subject: getting a list of existing slots To: commonloops.PA@Xerox.COM Message-Id: <590447715.0.RUTH@SRI-ROBOTX.ARPA> Mail-System-Version: Is there an easy way (e.g., an internal PCL function) to obtain a list of slots in a defined class? And if so, can one obtain information on whether the slot has an allocation of :class or :instance, and whether it is inherited or local? Doug Ruth Robotics Laboratory SRI International (415) 859-3860 Mailing Address: SRI International 333 Ravenswood Avenue, EL286 Menlo Park, CA 94025 ARPA Net Address: ruth@sri-robotx.arpa ------- From Owners-commonloops.PA@Xerox.COM Sat Sep 17 17:06:37 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.3) id AA03571; Fri, 16 Sep 88 17:09:12 PDT Received: from Riesling.ms by ArpaGateway.ms ; 16 SEP 88 14:22:44 PDT Return-Path: Redistributed: commonloops.PA Received: from SRI-ROBOTX.ARPA ([128.18.3.100]) by Xerox.COM ; 16 SEP 88 14:19:53 PDT Date: Fri, 16 Sep 88 14:15:14 PST From: Doug Ruth Subject: getting a list of existing slots To: commonloops.PA@Xerox.COM Message-Id: <590447715.0.RUTH@SRI-ROBOTX.ARPA> Mail-System-Version: Is there an easy way (e.g., an internal PCL function) to obtain a list of slots in a defined class? And if so, can one obtain information on whether the slot has an allocation of :class or :instance, and whether it is inherited or local? Doug Ruth Robotics Laboratory SRI International (415) 859-3860 Mailing Address: SRI International 333 Ravenswood Avenue, EL286 Menlo Park, CA 94025 ARPA Net Address: ruth@sri-robotx.arpa ------- From Owners-CommonLoops.pa@Xerox.COM Sat Sep 17 17:36:37 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.3) id AA03540; Fri, 16 Sep 88 17:05:02 PDT Received: from Burger.ms by ArpaGateway.ms ; 16 SEP 88 13:18:17 PDT Return-Path: Redistributed: CommonLoops.pa Received: from PEBBLES.BBN.COM ([128.89.1.5]) by Xerox.COM ; 16 SEP 88 13:16:04 PDT To: CommonLoops.pa@Xerox.COM Cc: kanderson@PEBBLES.BBN.COM Subject: unoptimized Slot-value and other things Date: Fri, 16 Sep 88 16:18:22 -0400 From: kanderso@PEBBLES.BBN.COM Message-Id: <880916-131817-1277@Xerox> ;;; -*- Package: PCL -*- In "8/28/88 (beta rev 1) AAAI PCL" on a Symbolics LISPM. Several things: 1. In the following 2 methods slot-value gets optimized in the first and not in the second. Shouldn't the second one be optimized too? (pcl:DEFMETHOD :REMPROP ((self PROPERTY-LIST-MIXIN) INDICATOR) (CHECK-TYPE INDICATOR SYMBOL) (let ((list (slot-value self 'property-list))) (remf list indicator) (setf (slot-value self 'property-list) list))) (pcl:DEFMETHOD :REMPROP ((self PROPERTY-LIST-MIXIN) INDICATOR) (CHECK-TYPE INDICATOR SYMBOL) (remf (slot-value self 'property-list) indicator)) 2. On Symbolics machines "M-X Edit Compiler Warnings" has trouble finding where to go in the file because "(PCL:TOP-LEVEL-FORM ..." isn't really there. Can this be improved on? M-. seems to know what to search for! Here are some example warnings: Warnings for file CONGER:>pcl>new>floid>vanilla For Function (PCL:TOP-LEVEL-FORM (PCL:METHOD (CL:SETF :GET) (FLOID:PROPERTY-LIST-MIXIN T))) While compiling FLOID::PROPERTY: The variable FLOID::PROPERTY is unknown and has been declared SPECIAL For Function (:INTERNAL (PCL:TOP-LEVEL-FORM (PCL:METHOD FLOID::GET-HANDLER-FOR (LIST PCL:OBJECT))) 0) FLOID::GBOUNDP was referenced but not defined. FLOID::GDEFINITION was referenced but not defined. 3. When you compile the method below, the compiler complains that initargs isn't used, although i think of them as being used by call-next-method. Does this seem right? (defmethod *make-instance ((class instances-class-mixin) &rest initargs) (let ((instance (call-next-method))) (add-instance class instance) instance)) 4. The body of the method above expands into: #'(LAMBDA (#:CLASS &REST #:AMPERSAND-ARGS) (LET ((.NEXT-METHOD. (CAR *NEXT-METHODS*)) (*NEXT-METHODS* (CDR *NEXT-METHODS*))) (FLET ((CALL-NEXT-METHOD (&REST CNM-ARGS) (IF .NEXT-METHOD. (IF CNM-ARGS (APPLY .NEXT-METHOD. CNM-ARGS) (APPLY .NEXT-METHOD. #:CLASS #:AMPERSAND-ARGS)) (ERROR "No next method.")))) (APPLY #'(LAMBDA (CLASS &REST INITARGS) (DECLARE (CLASS CLASS INSTANCES-CLASS-MIXIN)) (PROGN CLASS) (BLOCK *MAKE-INSTANCE (LET ((INSTANCE (CALL-NEXT-METHOD))) (ADD-INSTANCE CLASS INSTANCE) INSTANCE))) #:CLASS #:AMPERSAND-ARGS)))))))) with a LITTLE more work on already HAIRY function, couldn't we get expand-defmethod-internal to expand the call-next-method in line to something like: #'(LAMBDA (#:CLASS &REST #:AMPERSAND-ARGS) (LET ((.NEXT-METHOD. (CAR *NEXT-METHODS*)) (*NEXT-METHODS* (CDR *NEXT-METHODS*))) (APPLY #'(LAMBDA (CLASS &REST INITARGS) (DECLARE (CLASS CLASS INSTANCES-CLASS-MIXIN)) (PROGN CLASS) (BLOCK *MAKE-INSTANCE (LET ((INSTANCE (if .next-method. (apply .next-method. #:class #:ampersand-args) (ERROR "No next method."))) (ADD-INSTANCE CLASS INSTANCE) INSTANCE)))) #:CLASS #:AMPERSAND-ARGS))))) This would save a funcall and conditional branch in the most common case. We only need the functional semantics of call-next-method when someone does something like: (return (cons #'call-next-method (call-next-method))) From Gregor.pa@Xerox.COM Sun Sep 18 16:47:00 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.3) id AA18829; Sun, 18 Sep 88 16:47:00 PDT Received: from Semillon.ms by ArpaGateway.ms ; 18 SEP 88 16:51:27 PDT Date: Sun, 18 Sep 88 16:49 PDT From: Gregor.pa@Xerox.COM Subject: Re: getting a list of existing slots To: Doug Ruth Cc: commonloops.PA@Xerox.COM Fcc: BD:>Gregor>mail>outgoing-mail-4.text.newest In-Reply-To: <590447715.0.RUTH@SRI-ROBOTX.ARPA> Message-Id: <19880918234935.8.GREGOR@PORTNOY.parc.xerox.com> Line-Fold: no Date: Fri, 16 Sep 88 14:15:14 PST From: Doug Ruth Is there an easy way (e.g., an internal PCL function) to obtain a list of slots in a defined class? And if so, can one obtain information on whether the slot has an allocation of :class or :instance, and whether it is inherited or local? The generic-function CLASS-SLOTS returns a description of the slots which are accessible in instances of a given class. This is represented as a list of slot description objects, each slot description object represents one slot. The generic-function slotd-allocation (which at some point will be renamed to slot-description-allocation) returns the allocation of a slot. For example: (defclass c1 () ((foo :allocation :class) (bar))) (setq slots (pcl::class-slots (find-class 'c1))) (# #) (mapcar #'slot-allocation slots) (:CLASS :INSTANCE) This functionality is all a documented part of the metaobject protocol. Some of the names may change, but the functionality will remain. ------- From Gregor.pa@Xerox.COM Sun Sep 18 17:25:04 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.3) id AA19066; Sun, 18 Sep 88 17:25:04 PDT Received: from Semillon.ms by ArpaGateway.ms ; 18 SEP 88 17:30:15 PDT Date: Sun, 18 Sep 88 17:28 PDT From: Gregor.pa@Xerox.COM Subject: Re: redefining methods To: burdorf@rand-unix.ARPA Cc: CommonLoops.pa@Xerox.COM, dave@rand-unix.ARPA, shane@rand-unix.ARPA, steph%ixta@rand-unix.ARPA Fcc: BD:>Gregor>mail>outgoing-mail-4.text.newest In-Reply-To: <8809122032.AA12980@rand-unix.arpa> Message-Id: <19880919002813.3.GREGOR@PORTNOY.parc.xerox.com> Line-Fold: no Date: Mon, 12 Sep 88 13:32:04 PDT From: burdorf@rand-unix.ARPA When debugging our CLOS-based window system, I redefine methods now an then. However, if I try to redefine a method that's already loaded, the system complains saying "Error: HIGHLIGHT-CHOSEN-ITEM already names an ordinary function or a macro, it can't be converted to a generic function. Error signalled by LOAD-DEFMETHOD. I can't reproduce this error here. Certainly people redefine methods all the time, since that is the basic programming loop. Could you send a small test case? Is it possible that between the original time you defined the method and the time you try to redefine it, you reload PCL? That would certainly cause this kind of weird error. Once PCL is loaded, you should never load it again. ------- From Owners-CommonLoops.pa@Xerox.COM Sun Sep 18 19:35:01 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.3) id AA20008; Sun, 18 Sep 88 19:35:01 PDT Received: from Riesling.ms by ArpaGateway.ms ; 18 SEP 88 19:40:22 PDT Return-Path: Redistributed: CommonLoops.pa Received: from Princeton.EDU ([10.7.0.96]) by Xerox.COM ; 18 SEP 88 19:38:40 PDT Received: from winnie.Princeton.EDU by Princeton.EDU (5.58+++/1.80) id AA19917; Sun, 18 Sep 88 22:38:13 EDT Message-Id: <8809190238.AA19917@Princeton.EDU> Date: Sun, 18 Sep 88 22:37:08 edt From: eliot@winnie.Princeton.EDU (eliot handelman) To: Gregor.pa@Xerox.COM, burdorf@rand-unix.ARPA Subject: Re: redefining methods Cc: CommonLoops.pa@Xerox.COM, dave@rand-unix.ARPA, shane@rand-unix.ARPA, steph%ixta@rand-unix.ARPA However, if I try to redefine a method that's already loaded, the system complains saying "Error: HIGHLIGHT-CHOSEN-ITEM already names an ordinary function or a macro, it can't be converted to a generic function. Error signalled by LOAD-DEFMETHOD. I can't reproduce this error here. Certainly people redefine methods all the time, since that is the basic programming loop. I do remember getting the error from a file in which there were no "ordinary functions," just classes & methods, in which I kept redefining names and generated some confusion. You can get the error like this: (defun foo () nil) (defclass baz () ((s :accessor foo))) -Eliot From Owners-CommonLoops.pa@Xerox.COM Sun Sep 18 20:11:37 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.3) id AA03540; Fri, 16 Sep 88 17:05:02 PDT Received: from Burger.ms by ArpaGateway.ms ; 16 SEP 88 13:18:17 PDT Return-Path: Redistributed: CommonLoops.pa Received: from PEBBLES.BBN.COM ([128.89.1.5]) by Xerox.COM ; 16 SEP 88 13:16:04 PDT To: CommonLoops.pa@Xerox.COM Cc: kanderson@PEBBLES.BBN.COM Subject: unoptimized Slot-value and other things Date: Fri, 16 Sep 88 16:18:22 -0400 From: kanderso@PEBBLES.BBN.COM Message-Id: <880916-131817-1277@Xerox> ;;; -*- Package: PCL -*- In "8/28/88 (beta rev 1) AAAI PCL" on a Symbolics LISPM. Several things: 1. In the following 2 methods slot-value gets optimized in the first and not in the second. Shouldn't the second one be optimized too? (pcl:DEFMETHOD :REMPROP ((self PROPERTY-LIST-MIXIN) INDICATOR) (CHECK-TYPE INDICATOR SYMBOL) (let ((list (slot-value self 'property-list))) (remf list indicator) (setf (slot-value self 'property-list) list))) (pcl:DEFMETHOD :REMPROP ((self PROPERTY-LIST-MIXIN) INDICATOR) (CHECK-TYPE INDICATOR SYMBOL) (remf (slot-value self 'property-list) indicator)) 2. On Symbolics machines "M-X Edit Compiler Warnings" has trouble finding where to go in the file because "(PCL:TOP-LEVEL-FORM ..." isn't really there. Can this be improved on? M-. seems to know what to search for! Here are some example warnings: Warnings for file CONGER:>pcl>new>floid>vanilla For Function (PCL:TOP-LEVEL-FORM (PCL:METHOD (CL:SETF :GET) (FLOID:PROPERTY-LIST-MIXIN T))) While compiling FLOID::PROPERTY: The variable FLOID::PROPERTY is unknown and has been declared SPECIAL For Function (:INTERNAL (PCL:TOP-LEVEL-FORM (PCL:METHOD FLOID::GET-HANDLER-FOR (LIST PCL:OBJECT))) 0) FLOID::GBOUNDP was referenced but not defined. FLOID::GDEFINITION was referenced but not defined. 3. When you compile the method below, the compiler complains that initargs isn't used, although i think of them as being used by call-next-method. Does this seem right? (defmethod *make-instance ((class instances-class-mixin) &rest initargs) (let ((instance (call-next-method))) (add-instance class instance) instance)) 4. The body of the method above expands into: #'(LAMBDA (#:CLASS &REST #:AMPERSAND-ARGS) (LET ((.NEXT-METHOD. (CAR *NEXT-METHODS*)) (*NEXT-METHODS* (CDR *NEXT-METHODS*))) (FLET ((CALL-NEXT-METHOD (&REST CNM-ARGS) (IF .NEXT-METHOD. (IF CNM-ARGS (APPLY .NEXT-METHOD. CNM-ARGS) (APPLY .NEXT-METHOD. #:CLASS #:AMPERSAND-ARGS)) (ERROR "No next method.")))) (APPLY #'(LAMBDA (CLASS &REST INITARGS) (DECLARE (CLASS CLASS INSTANCES-CLASS-MIXIN)) (PROGN CLASS) (BLOCK *MAKE-INSTANCE (LET ((INSTANCE (CALL-NEXT-METHOD))) (ADD-INSTANCE CLASS INSTANCE) INSTANCE))) #:CLASS #:AMPERSAND-ARGS)))))))) with a LITTLE more work on already HAIRY function, couldn't we get expand-defmethod-internal to expand the call-next-method in line to something like: #'(LAMBDA (#:CLASS &REST #:AMPERSAND-ARGS) (LET ((.NEXT-METHOD. (CAR *NEXT-METHODS*)) (*NEXT-METHODS* (CDR *NEXT-METHODS*))) (APPLY #'(LAMBDA (CLASS &REST INITARGS) (DECLARE (CLASS CLASS INSTANCES-CLASS-MIXIN)) (PROGN CLASS) (BLOCK *MAKE-INSTANCE (LET ((INSTANCE (if .next-method. (apply .next-method. #:class #:ampersand-args) (ERROR "No next method."))) (ADD-INSTANCE CLASS INSTANCE) INSTANCE)))) #:CLASS #:AMPERSAND-ARGS))))) This would save a funcall and conditional branch in the most common case. We only need the functional semantics of call-next-method when someone does something like: (return (cons #'call-next-method (call-next-method))) From Gregor.pa@Xerox.COM Sun Sep 18 21:25:44 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.3) id AA20398; Sun, 18 Sep 88 21:25:44 PDT Received: from Semillon.ms by ArpaGateway.ms ; 18 SEP 88 21:31:04 PDT Date: Sun, 18 Sep 88 21:29 PDT From: Gregor.pa@Xerox.COM Subject: Re: redefining methods To: eliot handelman Cc: burdorf@rand-unix.ARPA, CommonLoops.pa@Xerox.COM, dave@rand-unix.ARPA, shane@rand-unix.ARPA, steph%ixta@rand-unix.ARPA Fcc: BD:>Gregor>mail>outgoing-mail-4.text.newest In-Reply-To: <8809190238.AA19917@Princeton.EDU> Message-Id: <19880919042924.6.GREGOR@PORTNOY.parc.xerox.com> Line-Fold: no Date: Sun, 18 Sep 88 22:37:08 edt From: eliot%winnie.Princeton.EDU@Princeton.EDU (eliot handelman) You can get the error like this: (defun foo (x) nil) (defclass baz () ((s :accessor foo))) This code is illegal according to the CLOS specification. On page 2-46, in the description of ensure-generic-function says: If (SYMBOL-FUNCTION ) is a non-generic function, a macro or a special form, an error is signalled. The reason for this, is that defmethod (and ensure-generic-function) believe that they help to build generic function definitions incrementally. When they see a normal function, they have no way to know how to have its definition contribute to the definition of the whole function. What you *may* want to do is: (defun foo (x) nil) (eval-when (load eval) (pcl::make-specializable 'foo :arglist '(x))) (defclass baz () ((s :accessor foo))) ------- From Gregor.pa@Xerox.COM Sun Sep 18 21:43:36 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.3) id AA20427; Sun, 18 Sep 88 21:43:36 PDT Received: from Semillon.ms by ArpaGateway.ms ; 18 SEP 88 21:48:46 PDT Date: Sun, 18 Sep 88 21:46 PDT From: Gregor.pa@Xerox.COM Subject: Re: unoptimized Slot-value and other things To: kanderso@PEBBLES.BBN.COM Cc: CommonLoops.pa@Xerox.COM, kanderson@PEBBLES.BBN.COM Fcc: BD:>Gregor>mail>outgoing-mail-4.text.newest In-Reply-To: The message of 16 Sep 88 13:18 PDT from kanderso@PEBBLES.BBN.COM Message-Id: <19880919044646.7.GREGOR@PORTNOY.parc.xerox.com> Line-Fold: no Date: Fri, 16 Sep 88 16:18:22 -0400 From: kanderso@PEBBLES.BBN.COM In "8/28/88 (beta rev 1) AAAI PCL" on a Symbolics LISPM. Several things: 1. In the following 2 methods slot-value gets optimized in the first and not in the second. Shouldn't the second one be optimized too? (pcl:DEFMETHOD :REMPROP ((self PROPERTY-LIST-MIXIN) INDICATOR) (CHECK-TYPE INDICATOR SYMBOL) (let ((list (slot-value self 'property-list))) (remf list indicator) (setf (slot-value self 'property-list) list))) (pcl:DEFMETHOD :REMPROP ((self PROPERTY-LIST-MIXIN) INDICATOR) (CHECK-TYPE INDICATOR SYMBOL) (remf (slot-value self 'property-list) indicator)) Yes it should. And with a little work, it would be. Basically, the walker needs to learn how to spot variable rebindings itself and pass that information on. The problem is that the expansion of remf first binds a gensym to the value of self and then calls slot-value and pcl::set-slot-value with that gensym as arguments. The walker doesn't tell the optimization mechanism that this has happened, so the optimization mechanism doesn't know that that the value of the gensym is really one of the specialized arguments to the method. 3. When you compile the method below, the compiler complains that initargs isn't used, although i think of them as being used by call-next-method. Does this seem right? (defmethod *make-instance ((class instances-class-mixin) &rest initargs) (let ((instance (call-next-method))) (add-instance class instance) instance)) There is an argument that says it isn't used, and that is in fact why you are getting the warning. It isn't the value of the initargs variable which is passed by call-next-method. It is the parameter received by the method which is passed. For example: (defmethod foo ((x object) &rest rest) (setq rest '(a b c)) (call-next-method)) (defmethod foo (x &rest rest) rest) (foo 1 2 3) ===> (1 2 3) not (A B C) with a LITTLE more work on already HAIRY function, couldn't we get expand-defmethod-internal to expand the call-next-method in line to something like: This would save a funcall and conditional branch in the most common case. We only need the functional semantics of call-next-method when someone does something like: The Symbolics compiler is one of the few that doesn't do this automatically. ------- From Owners-COMMONLOOPS.PA@Xerox.COM Mon Sep 19 09:02:50 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.3) id AA24566; Mon, 19 Sep 88 09:02:50 PDT Received: from Cabernet.ms by ArpaGateway.ms ; 19 SEP 88 09:08:08 PDT Return-Path: <@EN-C06.Prime.COM,@ENB.Prime.COM,@ENI.Prime.COM,@s66.Prime.COM:SOBO@s66.Prime.COM> Redistributed: COMMONLOOPS.PA Received: from EN-C06.Prime.COM ([192.5.58.32]) by Xerox.COM ; 19 SEP 88 09:01:36 PDT Received: from ENB.Prime.COM by EN-C06.Prime.COM; 19 Sep 88 12:01:32 EDT Received: from ENI.Prime.COM by ENB.Prime.COM; 19 Sep 88 11:57:42 EDT Received: from s66.Prime.COM by ENI.Prime.COM; 19 Sep 88 12:04:02 EDT Received: (from user SOBO) by s66.Prime.COM; 19 Sep 88 11:57:21 EST Subject: Recording method definitions To: COMMONLOOPS.PA@Xerox.COM From: SOBO@s66.Prime.COM Date: 19 Sep 88 11:57:21 EST Message-Id: <880919-090808-1429@Xerox> Can someone please tell me why recording the source file for method definitions is *still* disabled on the Symbolics? Nadine Sobolevitch From Owners-commonloops.pa@Xerox.COM Mon Sep 19 11:10:10 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.3) id AA25644; Mon, 19 Sep 88 11:10:10 PDT Received: from Salvador.ms by ArpaGateway.ms ; 19 SEP 88 11:10:50 PDT Return-Path: Redistributed: commonloops.pa Received: from SRI-ROBOTX.ARPA ([128.18.3.100]) by Xerox.COM ; 19 SEP 88 11:07:41 PDT Date: Mon, 19 Sep 88 11:03:03 PST From: Doug Ruth Subject: metaobject protocol documentation To: commonloops.pa@Xerox.COM Message-Id: <590695383.0.RUTH@SRI-ROBOTX.ARPA> Mail-System-Version: Where can I get a hold of the documentation on the metaobject protocol. Chapter 1 of the CLOS Spec refers to it. Doug Ruth Robotics Laboratory SRI International (415) 859-3860 Mailing Address: SRI International 333 Ravenswood Avenue, EL286 Menlo Park, CA 94025 ARPA Net Address: ruth@sri-robotx.arpa ------- From Gregor.pa@Xerox.COM Mon Sep 19 12:11:40 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.3) id AA25125; Mon, 19 Sep 88 10:18:28 PDT Received: from Semillon.ms by ArpaGateway.ms ; 19 SEP 88 10:06:14 PDT Date: Mon, 19 Sep 88 10:02 PDT From: Gregor.pa@Xerox.COM Subject: Re: Recording method definitions To: SOBO@s66.Prime.COM Cc: COMMONLOOPS.PA@Xerox.COM Fcc: BD:>Gregor>mail>outgoing-mail-4.text.newest In-Reply-To: The message of 19 Sep 88 09:57 PDT from SOBO@s66.Prime.COM Message-Id: <19880919170207.1.GREGOR@PORTNOY.parc.xerox.com> Line-Fold: no Date: 19 Sep 88 11:57:21 EST From: SOBO@s66.Prime.COM Can someone please tell me why recording the source file for method definitions is *still* disabled on the Symbolics? I certainly can't. Apparently, at some point or another, I disabled it. I don't know why. It is enabled now in the sources I have been using for the last few weeks, and works fairly well. In the version which we hope to release in the next few days, it will be enabled again. You can also do this yourself just by uncommenting the record-definition definition in 3600-low. ------- From Owners-CommonLoops.pa@Xerox.COM Mon Sep 19 12:41:41 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.3) id AA25566; Mon, 19 Sep 88 10:50:35 PDT Received: from Chardonnay.ms by ArpaGateway.ms ; 19 SEP 88 10:50:28 PDT Return-Path: Redistributed: CommonLoops.pa Received: from rand-unix.arpa ([10.3.0.7]) by Xerox.COM ; 19 SEP 88 10:43:29 PDT Received: by rand-unix.arpa; Mon, 19 Sep 88 09:53:47 PDT Message-Id: <8809191653.AA28806@rand-unix.arpa> To: Gregor.pa@Xerox.COM Cc: CommonLoops.pa@Xerox.COM, dave@rand-unix.ARPA, shane@rand-unix.ARPA, steph%ixta@rand-unix.ARPA, burdorf@rand-unix.ARPA Subject: Re: redefining methods In-Reply-To: Your message of Sun, 18 Sep 88 17:28 PDT. <19880919002813.3.GREGOR@PORTNOY.parc.xerox.com> Date: Mon, 19 Sep 88 09:53:33 PDT From: burdorf@rand-unix.ARPA I double checked and found that I can redefine methods. The problem occurred when I had traced a method and tried to redefine it. The trace code redefined the method as an expr and thus PCL wouldn't allow the trace code to be redefined as a method. At the time I sent the message, I wasn't aware of this problem. The way I get around this problem is to untrace the method, redefine it, and then trace it again. It is a pain, because I have to remember what's a method and what's a function, but it works. Chris Burdorf From Owners-CommonLoops.PA@Xerox.COM Mon Sep 19 16:14:09 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.3) id AA00045; Mon, 19 Sep 88 16:14:09 PDT Received: from Chardonnay.ms by ArpaGateway.ms ; 19 SEP 88 12:57:30 PDT Return-Path: Redistributed: CommonLoops.PA Received: from vaxa.isi.edu ([128.9.0.33]) by Xerox.COM ; 19 SEP 88 12:55:00 PDT Date: Mon, 19 Sep 88 12:40:11 PDT From: bmiller@vaxa.isi.edu (Brent Miller) Posted-Date: Mon, 19 Sep 88 12:40:11 PDT Message-Id: <8809191940.AA02150@vaxa.isi.edu> Received: by vaxa.isi.edu (5.54/5.51) id AA02150; Mon, 19 Sep 88 12:40:11 PDT To: CommonLoops.PA@Xerox.COM Subject: Please put me on the mailing list Thanks. From Owners-commonloops.pa@Xerox.COM Mon Sep 19 18:22:02 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.3) id AA01176; Mon, 19 Sep 88 18:22:02 PDT Received: from Salvador.ms by ArpaGateway.ms ; 19 SEP 88 18:20:58 PDT Return-Path: Redistributed: commonloops.pa Received: from ti.com ([10.7.0.46]) by Xerox.COM ; 19 SEP 88 18:18:58 PDT Received: by ti.com id AA18806; Mon, 19 Sep 88 20:18:10 CDT Received: from dsg by tilde id AA15713; Mon, 19 Sep 88 20:01:07 CDT Received: From Sierra By dsg Via CHAOS-NET With CHAOS-MAIL; Mon, 19 Sep 88 20:02:19 CDT Message-Id: <2799709331-2030355@Sierra> Sender: KK@Sierra.csc.ti.com Date: Mon, 19 Sep 88 20:02:11 CDT From: Kerry Kimbrough To: CommonLoops.PA@Xerox.COM Subject: CLOS question: method combination True or false? The CLOS specification allows an auxilliary method (e.g. :after, etc.) to be defined on a generic function for a particular set of specialized args, *even though* there is no primary method defined for these arg types. The spec says that method combination will signal an error in this case, so the question really has to do with when method combination can occur. If the answer to the question is "True", then I am free to define a "mixin" which qualifies a primary method supplied by some other class (which I know will be there when I instantiate). If "False", then I can't do this (ouch!). From Bobrow.pa@Xerox.COM Mon Sep 19 18:26:20 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.3) id AA01194; Mon, 19 Sep 88 18:26:20 PDT Received: from Semillon.ms by ArpaGateway.ms ; 19 SEP 88 18:31:28 PDT Date: 19 Sep 88 18:29 PDT From: Bobrow.pa@Xerox.COM Subject: Re: CLOS question: method combination In-Reply-To: Kerry Kimbrough 's message of Mon, 19 Sep 88 20:02:11 CDT To: Kimbrough@dsg.csc.ti.com Cc: CommonLoops.PA@Xerox.COM Message-Id: <880919-183128-2927@Xerox> True or false? The CLOS specification allows an auxilliary method (e.g. :after, etc.) to be defined on a generic function for a particular set of specialized args, *even though* there is no primary method defined for these arg types. The spec says that method combination will signal an error in this case, so the question really has to do with when method combination can occur. If the answer to the question is "True", then I am free to define a "mixin" which qualifies a primary method supplied by some other class (which I know will be there when I instantiate). If "False", then I can't do this (ouch!). True. The intent is to allow just such mixins. From Owners-commonloops.pa@Xerox.COM Mon Sep 19 20:24:41 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.3) id AA02352; Mon, 19 Sep 88 20:24:41 PDT Received: from Riesling.ms by ArpaGateway.ms ; 19 SEP 88 20:29:48 PDT Return-Path: Redistributed: commonloops.pa Received: from SRI-ROBOTX.ARPA ([128.18.3.100]) by Xerox.COM ; 19 SEP 88 20:28:06 PDT Date: Mon, 19 Sep 88 20:23:26 PST From: Doug Ruth Subject: :type bug? To: commonloops.pa@Xerox.COM Message-Id: <590729006.0.RUTH@SRI-ROBOTX.ARPA> Mail-System-Version: The following code seems to indicate a bug with respect to slot types: ******************************************************************* (defclass foo () (a)) (pcl:slotd-type (car (pcl:class-slots (find-class 'foo)))) T (pcl:slotd-type (car (pcl:class-local-slots (find-class 'foo)))) (*SLOTD-UNSUPPLIED*) ********************************************************************* It seems the type in the local slot description object for slot a should also be T. Am I correct? Doug Ruth Robotics Laboratory SRI International (415) 859-3860 Mailing Address: SRI International 333 Ravenswood Avenue, EL286 Menlo Park, CA 94025 ARPA Net Address: ruth@sri-robotx.arpa ------- From Gregor.pa@Xerox.COM Mon Sep 19 21:12:23 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.3) id AA02611; Mon, 19 Sep 88 21:12:23 PDT Received: from Semillon.ms by ArpaGateway.ms ; 19 SEP 88 21:17:43 PDT Date: Mon, 19 Sep 88 21:15 PDT From: Gregor.pa@Xerox.COM Subject: Re: metaobject protocol documentation To: Doug Ruth Cc: commonloops.pa@Xerox.COM Fcc: BD:>Gregor>mail>outgoing-mail-4.text.newest In-Reply-To: <590695383.0.RUTH@SRI-ROBOTX.ARPA> Message-Id: <19880920041527.4.GREGOR@PORTNOY.parc.xerox.com> Line-Fold: no Date: Mon, 19 Sep 88 11:03:03 PST From: Doug Ruth Where can I get a hold of the documentation on the metaobject protocol. Chapter 1 of the CLOS Spec refers to it. Unfortunately, this document is not yet available. We are working on it quite actively, and have promised to have it finished by early December. When it is ready it will be announced to this list. ------- From Gregor.pa@Xerox.COM Mon Sep 19 21:33:40 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.3) id AA02633; Mon, 19 Sep 88 21:33:40 PDT Received: from Semillon.ms by ArpaGateway.ms ; 19 SEP 88 21:38:53 PDT Date: Mon, 19 Sep 88 21:36 PDT From: Gregor.pa@Xerox.COM Subject: Re: :type bug? To: Doug Ruth Cc: commonloops.pa@Xerox.COM Fcc: BD:>Gregor>mail>outgoing-mail-4.text.newest In-Reply-To: <590729006.0.RUTH@SRI-ROBOTX.ARPA> Message-Id: <19880920043640.5.GREGOR@PORTNOY.parc.xerox.com> Line-Fold: no Date: Mon, 19 Sep 88 20:23:26 PST From: Doug Ruth The following code seems to indicate a bug with respect to slot types: (defclass foo () (a)) (pcl:slotd-type (car (pcl:class-slots (find-class 'foo)))) T (pcl:slotd-type (car (pcl:class-local-slots (find-class 'foo)))) (*SLOTD-UNSUPPLIED*) It seems the type in the local slot description object for slot a should also be T. Am I correct? No. This particular behavior is pcl-specific, and will change with the chapter 3 specification, but in any case, the second call to slotd-type would never return T. Consider the following case: (defclass foo () ((a :type number))) (defclass bar () ((a))) Clearly, the following are true: (slotd-type (car (class-slots (find-class 'foo)))) ==> NUMBER (slotd-type (car (class-slots (find-class 'bar)))) ==> NUMBER Furthermore, the following is clearly true. (slotd-type (car (class-local-slots (find-class 'foo)))) ==> NUMBER But the following must have some way of noting that the type is not actually specified in the defclass for bar. That is what makes it clear that the type specified in FOO should be used in BAR rather than being overridden by an implicit T. (slotd-type (car (class-local-slots (find-class 'bar)))) ------- From Gregor.pa@Xerox.COM Mon Sep 19 22:44:17 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.3) id AA03271; Mon, 19 Sep 88 22:44:17 PDT Received: from Semillon.ms by ArpaGateway.ms ; 19 SEP 88 22:49:43 PDT Date: Mon, 19 Sep 88 22:48 PDT From: Gregor.pa@Xerox.COM Subject: Re: metaobject protocol documentation To: Doug Ruth Cc: commonloops.pa@Xerox.COM Fcc: BD:>Gregor>mail>outgoing-mail-4.text.newest In-Reply-To: <590695383.0.RUTH@SRI-ROBOTX.ARPA> Supersedes: <19880920041527.4.GREGOR@PORTNOY.parc.xerox.com> Comments: This message is better Message-Id: <19880920054808.0.GREGOR@PORTNOY.parc.xerox.com> Line-Fold: no Date: Mon, 19 Sep 88 11:03:03 PST From: Doug Ruth Where can I get a hold of the documentation on the metaobject protocol. Chapter 1 of the CLOS Spec refers to it. I composed my previous answer to this message too hastily. This message contains some more useful information. There is an existing draft of this document which I can send you if you like. Since that draft, there have been several meetings of the full CLOS committee; these resulted in some significant changes being made to the protocol. We have also made some changes in the presentation to be used in the document. The final draft will differ substantially in presentation, and somewhat in content. We are now working on the final draft which we have promised to complete by early December. That document will be announced to this list when it is ready. ------- From Owners-COMMONLOOPS.PA@Xerox.COM Tue Sep 20 10:59:08 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.3) id AA24566; Mon, 19 Sep 88 09:02:50 PDT Received: from Cabernet.ms by ArpaGateway.ms ; 19 SEP 88 09:08:08 PDT Return-Path: <@EN-C06.Prime.COM,@ENB.Prime.COM,@ENI.Prime.COM,@s66.Prime.COM:SOBO@s66.Prime.COM> Redistributed: COMMONLOOPS.PA Received: from EN-C06.Prime.COM ([192.5.58.32]) by Xerox.COM ; 19 SEP 88 09:01:36 PDT Received: from ENB.Prime.COM by EN-C06.Prime.COM; 19 Sep 88 12:01:32 EDT Received: from ENI.Prime.COM by ENB.Prime.COM; 19 Sep 88 11:57:42 EDT Received: from s66.Prime.COM by ENI.Prime.COM; 19 Sep 88 12:04:02 EDT Received: (from user SOBO) by s66.Prime.COM; 19 Sep 88 11:57:21 EST Subject: Recording method definitions To: COMMONLOOPS.PA@Xerox.COM From: SOBO@s66.Prime.COM Date: 19 Sep 88 11:57:21 EST Message-Id: <880919-090808-1429@Xerox> Can someone please tell me why recording the source file for method definitions is *still* disabled on the Symbolics? Nadine Sobolevitch From Owners-CommonLoops.pa@Xerox.COM Tue Sep 20 11:14:32 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.3) id AA25566; Mon, 19 Sep 88 10:50:35 PDT Received: from Chardonnay.ms by ArpaGateway.ms ; 19 SEP 88 10:50:28 PDT Return-Path: Redistributed: CommonLoops.pa Received: from rand-unix.arpa ([10.3.0.7]) by Xerox.COM ; 19 SEP 88 10:43:29 PDT Received: by rand-unix.arpa; Mon, 19 Sep 88 09:53:47 PDT Message-Id: <8809191653.AA28806@rand-unix.arpa> To: Gregor.pa@Xerox.COM Cc: CommonLoops.pa@Xerox.COM, dave@rand-unix.ARPA, shane@rand-unix.ARPA, steph%ixta@rand-unix.ARPA, burdorf@rand-unix.ARPA Subject: Re: redefining methods In-Reply-To: Your message of Sun, 18 Sep 88 17:28 PDT. <19880919002813.3.GREGOR@PORTNOY.parc.xerox.com> Date: Mon, 19 Sep 88 09:53:33 PDT From: burdorf@rand-unix.ARPA I double checked and found that I can redefine methods. The problem occurred when I had traced a method and tried to redefine it. The trace code redefined the method as an expr and thus PCL wouldn't allow the trace code to be redefined as a method. At the time I sent the message, I wasn't aware of this problem. The way I get around this problem is to untrace the method, redefine it, and then trace it again. It is a pain, because I have to remember what's a method and what's a function, but it works. Chris Burdorf From Owners-commonloops.pa@Xerox.COM Tue Sep 20 11:44:54 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.3) id AA25644; Mon, 19 Sep 88 11:10:10 PDT Received: from Salvador.ms by ArpaGateway.ms ; 19 SEP 88 11:10:50 PDT Return-Path: Redistributed: commonloops.pa Received: from SRI-ROBOTX.ARPA ([128.18.3.100]) by Xerox.COM ; 19 SEP 88 11:07:41 PDT Date: Mon, 19 Sep 88 11:03:03 PST From: Doug Ruth Subject: metaobject protocol documentation To: commonloops.pa@Xerox.COM Message-Id: <590695383.0.RUTH@SRI-ROBOTX.ARPA> Mail-System-Version: Where can I get a hold of the documentation on the metaobject protocol. Chapter 1 of the CLOS Spec refers to it. Doug Ruth Robotics Laboratory SRI International (415) 859-3860 Mailing Address: SRI International 333 Ravenswood Avenue, EL286 Menlo Park, CA 94025 ARPA Net Address: ruth@sri-robotx.arpa ------- From Owners-CommonLoops.PA@Xerox.COM Tue Sep 20 12:16:01 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.3) id AA00045; Mon, 19 Sep 88 16:14:09 PDT Received: from Chardonnay.ms by ArpaGateway.ms ; 19 SEP 88 12:57:30 PDT Return-Path: Redistributed: CommonLoops.PA Received: from vaxa.isi.edu ([128.9.0.33]) by Xerox.COM ; 19 SEP 88 12:55:00 PDT Date: Mon, 19 Sep 88 12:40:11 PDT From: bmiller@vaxa.isi.edu (Brent Miller) Posted-Date: Mon, 19 Sep 88 12:40:11 PDT Message-Id: <8809191940.AA02150@vaxa.isi.edu> Received: by vaxa.isi.edu (5.54/5.51) id AA02150; Mon, 19 Sep 88 12:40:11 PDT To: CommonLoops.PA@Xerox.COM Subject: Please put me on the mailing list Thanks. From Common-Lisp-Object-System-mailer@SAIL.STANFORD.EDU Tue Sep 20 18:11:07 1988 Received: from Sail.Stanford.EDU by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.3) id AA13081; Tue, 20 Sep 88 18:11:07 PDT Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 20 Sep 88 18:17:10 PDT Received: from Semillon.ms by ArpaGateway.ms ; 20 SEP 88 18:02:57 PDT Date: 20 Sep 88 18:02 PDT From: masinter.pa@Xerox.COM Subject: Re: Issue: SYMBOL-MACROLET-DECLARE (version 1) In-Reply-To: Patrick Dussud 's message of Tue, 13 Sep 88 11:41:59 PDT To: Patrick Dussud Cc: piazza%lisp.DEC@decwrl.dec.com, Moon@stony-brook.scrc.symbolics.com, Common-Lisp-Object-System@SAIL.STANFORD.EDU, cl-cleanup@SAIL.STANFORD.EDU Message-Id: <880920-180257-5257@Xerox> We need to get this cleaned up in time to present to X3J13. I think it is at least consistent with LET semantics to say that (LOCALLY (DECLARE (SPECIAL X)) ...) introduces a new scope for X. Its consistent with (LET((X 4)) (DECLARE (SPECIAL X)) (LET ((X 3)) (LOCALLY (DECLARE (SPECIAL X)) X))) returning 4. I.e., add to the proposal something like: Clarify that, within a SYMBOL-MACROLET, a nested LOCALLY with a DECLARE SPECIAL introduces a new scope for the variable(s) declared special, and will override within its scope any SYMBOL-MACROLET. From Owners-commonloops.pa@Xerox.COM Tue Sep 20 18:13:42 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.3) id AA13154; Tue, 20 Sep 88 18:13:42 PDT Received: from Chardonnay.ms by ArpaGateway.ms ; 20 SEP 88 08:07:26 PDT Return-Path: Redistributed: commonloops.pa Received: from Sun.COM ([10.7.0.2]) by Xerox.COM ; 20 SEP 88 07:57:47 PDT Received: from snail.sun.com by Sun.COM (4.0/SMI-4.0) id AA08872; Tue, 20 Sep 88 07:55:32 PDT Received: from suntana.sun.com by snail.sun.com (4.0/SMI-4.0) id AA06666; Tue, 20 Sep 88 07:58:27 PDT Received: from localhost by suntana.sun.com (4.0/SMI-4.0) id AA07512; Tue, 20 Sep 88 07:58:19 PDT Message-Id: <8809201458.AA07512@suntana.sun.com> To: Gregor.pa@Xerox.COM Cc: Doug Ruth , commonloops.pa@Xerox.COM Subject: Re: :type bug? In-Reply-To: Your message of Mon, 19 Sep 88 21:36:00 -0700. <19880920043640.5.GREGOR@PORTNOY.parc.xerox.com> Date: Tue, 20 Sep 88 07:58:17 -0700 From: kempf@Sun.COM >(defclass foo () ((a :type number))) >(defclass bar () ((a))) > >Clearly, the following are true: > >(slotd-type (car (class-slots (find-class 'foo)))) ==> NUMBER >(slotd-type (car (class-slots (find-class 'bar)))) ==> NUMBER I think what you mean here is: (defclass foo () ((a :type number))) (defclass bar (foo) ((a))) Otherwise: (slotd-type (car (class-slots (find-class 'bar)))) ==> T or? jak From CL-Cleanup-mailer@SAIL.STANFORD.EDU Tue Sep 20 20:13:32 1988 Received: from Sail.Stanford.EDU by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.3) id AA13976; Tue, 20 Sep 88 20:13:32 PDT Received: from lucid.com by SAIL.Stanford.EDU with TCP; 20 Sep 88 20:08:49 PDT Received: from rainbow-warrior ([192.9.200.16]) by heavens-gate.lucid.com id AA05077g; Tue, 20 Sep 88 19:06:13 PST Received: by rainbow-warrior id AA19120g; Tue, 20 Sep 88 20:04:34 PDT Date: Tue, 20 Sep 88 20:04:34 PDT From: Patrick Dussud Message-Id: <8809210304.AA19120@rainbow-warrior> To: masinter.pa@Xerox.COM Cc: piazza%lisp.DEC@decwrl.dec.com, Moon@stony-brook.scrc.symbolics.com, Common-Lisp-Object-System@SAIL.STANFORD.EDU, cl-cleanup@SAIL.STANFORD.EDU In-Reply-To: masinter.pa@Xerox.COM's message of 20 Sep 88 18:02 PDT <880920-180257-5257@Xerox> Subject: Issue: SYMBOL-MACROLET-DECLARE (version 1) Date: 20 Sep 88 18:02 PDT From: masinter.pa@Xerox.COM We need to get this cleaned up in time to present to X3J13. Clarify that, within a SYMBOL-MACROLET, a nested LOCALLY with a DECLARE SPECIAL introduces a new scope for the variable(s) declared special, and will override within its scope any SYMBOL-MACROLET. I agree with this. We should also specify that SPECIAL shouldn't be used in the declaration part of a symbol-macrolet. Locally special declaration are fine. Patrick. From Owners-CommonLoops.pa@Xerox.COM Wed Sep 21 10:05:53 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.3) id AA20633; Wed, 21 Sep 88 10:05:53 PDT Received: from Salvador.ms by ArpaGateway.ms ; 21 SEP 88 09:15:49 PDT Return-Path: <@CUNYVM.CUNY.EDU:K311770@AEARN.BITNET> Redistributed: CommonLoops.pa Received: from CUNYVM.CUNY.EDU ([128.228.1.2]) by Xerox.COM ; 21 SEP 88 09:13:44 PDT Received: from AEARN.BITNET by CUNYVM.CUNY.EDU (IBM VM SMTP R1.1) with BSMTP id 1063; Wed, 21 Sep 88 12:12:12 EDT Received: by AEARN (Mailer X1.25) id 1335; Wed, 21 Sep 88 16:36:36 EDT Date: Wed, 21 Sep 88 15:29:23 EDT From: Hubert Hofbauer Subject: Re: metaobject protocol documentation To: Gregor.pa@Xerox.COM Cc: CommonLoops.pa@Xerox.COM In-Reply-To: Your message of Mon, 19 Sep 88 22:48 PDT Message-Id: <880921-091549-596@Xerox> Please send me the draft of the metaobject documentation. At RISC Linz we are currently evaluating PCL as a basis for our symbolic computation library. An important issue in this field are parameterized types - families of classes - such as zmod N, polynomial over A-FIELD in VARS, matrix DIMS of DOMAIN,... , where N, A-FIELD, VARS, DIMS, and DOMAIN are parameters for type zmod, polynomial, and matrix. We would like something like (DEFCLASS (ZMOD N) ...) and (DEFMETHOD xxx ((Z (ZMOD N))... )... ). Related work has been done at Tektronix for Smalltalk - the VIEWS system. Has anybody tried to do something similar for PCL? Thank you, Hubert PS: I have chapter 1 & 2 of the CLOS draft and 'St.Patricks Day' PCL. I cannot get the new versions. A friend who FTPed and sent it as mail cannot do it anymore. Please help an EARN (=BITNET in Europe) user! +-----------------------------------------------+-----------------------+ ! Hubert Hofbauer (research assistant) ! K311770@AEARN.BITNET ! ! Research Institute for Symbolic Computation ! RISC ! ! Johannes-Kepler-Universitaet Linz ! JKU Linz ! ! A-4040 Linz ! Austria / Europe ! +-----------------------------------------------+-----------------------+ From Owners-commonloops.pa@Xerox.COM Wed Sep 21 14:00:29 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.3) id AA23612; Wed, 21 Sep 88 14:00:29 PDT Received: from Cabernet.ms by ArpaGateway.ms ; 21 SEP 88 13:26:46 PDT Return-Path: Redistributed: commonloops.pa Received: from VAX.BBN.COM ([128.89.0.91]) by Xerox.COM ; 21 SEP 88 13:24:01 PDT To: commonloops.pa@Xerox.COM Subject: PCL Genera 7.2 bugfixes Date: Wed, 21 Sep 88 16:11:28 -0400 From: Mike Thome Message-Id: <880921-132646-1431@Xerox> Below are some commented bugfixes for PCL (AAAI release) under Symbolics Genera 7.2. The bulk of them are environment hacks, but there are a few significant bugfixes in there (read the comments). enjoy, -mike thome (mthome@bbn.com) PS. Question: Anyone tried running PCL with MacIvory yet? PPS. I'm still getting two of every commonloops list messages... -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- NOTES: anything marked #+patched-in-sources must be "patched in the sources" for full effect - that is if you want the fixes to apply to the innards of PCL, you'll have to recompile everything. ;;;-*-Mode:LISP; Package:(PCL LISP 1000); Base:10; Syntax:Common-lisp; Patch-File: Yes -*- ;;; PATCH BOOT.LISP ;;; call fdefine on the fspec so stuff gets remembered. ;;; (needed for full M-., etc capability) ;;; A side effect is that the function spec of the new method is ;;; returned by the defmethod form. ;;; #+patched-in-sources (defun load-defmethod (class name quals specls ll doc isl-cache-symbol plist fn) (let ((method-spec (make-method-spec name quals specls))) (record-definition 'method method-spec) (setq fn (set-function-name fn method-spec)) (let ((method (load-defmethod-internal name quals specls ll doc isl-cache-symbol plist fn class))) #+Genera (when method ; patched... MT 880829 (scl:fdefine method-spec fn)) method-spec))) #+patched-in-sources (defun load-defmethod-internal (gf-spec qualifiers specializers lambda-list doc isl-cache-symbol plist fn method-class) (when (listp gf-spec) (do-standard-defsetf-1 (cadr gf-spec))) (when plist (setq plist (copy-list plist)) ;Do this to keep from affecting ;the plist that is about to be ;dumped when we are compiling. (let ((uisl (getf plist :isl)) (isl nil)) (when uisl (setq isl (intern-slot-lists uisl)) (setf (getf plist :isl) isl)) (when isl-cache-symbol (setf (getf plist :isl-cache-symbol) isl-cache-symbol) (set isl-cache-symbol isl))) (setf (method-function-plist fn) plist)) (let ((method (add-named-method gf-spec qualifiers specializers lambda-list fn :documentation doc))) (unless (or (eq method-class 'standard-method) (eq (find-class method-class nil) (class-of method))) (format *error-output* "At the time the method with qualifiers ~:~S and~%~ specializers ~:S on the generic function ~S~%~ was compiled, the method-class for that generic function was~%~ ~S. But, the method class is now ~S, this~%~ may mean that this method was compiled improperly." qualifiers specializers gf-spec method-class (class-name (class-of method)))) method ; return a useful value (MT) )) ;;; Patch FIN.LISP ;;; fixes (defmethod foo (x) x) bug: in vanilla aaai-pcl, if you type ;;; that [---^] form to the interpreter when foo had no previous ;;; definition, pcl would get blown out of the water due to a #' getting ;;; expanded to an SI:DIGESTED-LAMBDA form. this fixes the problem. ;;; (proclaim '(inline applyable-thing-p)) (defun applyable-thing-p (thing) (or (functionp thing) (and (consp thing) (eq (car thing) 'si:digested-lambda)))) (defun set-funcallable-instance-function (fin new-value) (cond ((not (funcallable-instance-p fin)) (error "~S is not a funcallable-instance" fin)) ((not (applyable-thing-p new-value)) (error "~S is not a function." new-value)) ((and (si:lexical-closure-p new-value) (compiled-function-p (si:lexical-closure-function new-value))) (let* ((fin-env (si:lexical-closure-environment fin)) (new-env (si:lexical-closure-environment new-value)) (new-env-size (zl:length new-env)) (fin-env-size (- funcallable-instance-closure-size (length funcallable-instance-data)))) (cond ((<= new-env-size fin-env-size) (dotimes (i fin-env-size) (setf (sys:%p-contents-offset fin-env i) (and (< i new-env-size) (sys:%p-contents-offset new-env i)))) (setf (si:lexical-closure-function fin) (si:lexical-closure-function new-value))) (t (set-funcallable-instance-function fin (make-trampoline new-value)))))) (t (set-funcallable-instance-function fin (make-trampoline new-value))))) ;;; Patch 3600-LOW.LISP ;;; removed comments that keep definition records from being saved. ;;; also fix up stuff so C-E from debugger works. ;;; The hash tables must use equal, 'cuz the keys are consed-up lists. ;;; MT - 880822 #+patched-in-sources (defvar *method-fdefs* (make-hash-table :test #'equal :size 500)) #+patched-in-sources (defvar *method-setf-fdefs* (make-hash-table :test #'equal :size 500)) #+patched-in-sources (defun record-definition (type spec &rest args) (declare (ignore args)) (case type (method (if (listp (cadr spec)) (si:record-source-file-name spec 'method) (si:record-source-file-name spec 'method))) (class (si:record-source-file-name spec 'defclass) (si:record-source-file-name spec 'deftype) ))) ;;; PATCH 3600-low.lisp ;;; Support for multi-line arg lists when a buffer is sectionized while reading - i.e. ;;; M-. on a method whose name, specializers and qualifiers appear on more than one ;;; line in a file which either has not yet been read in or was read in as a result ;;; of another M-.-like function. ;;; NOTE: this also fixes a number of related bugs-- even some existing problems ;;; in finding standard symbolics definitions (see below). ;;; This is especially important when trying to follow the internals of PCL whose ;;; source commmonly contains multiple-line argument lists. ;(defun find-me (x) t) ; Always worked (and still does) ;(defun ; Fixed by patch ; dont-find-me (x) t) ;(defmethod ok-method ((x bar)) x) ; Worked under pcl before ;(defmethod loser-method ((x bar) ; Fixed by patch ; (y bar)) ; (lambda-list split) ; (cons x y)) ;(defmethod even-worse-method ; Ditto ; ((x bar)) ; x) ;(defmethod badder-than-that ; (You get the idea) ; ((x ; bar)) ; x) ;(defmethod really-bad ((x bar) ; Does NOT work (surprisingly enough)... ;(defmethod should-be-found ; ...But its not working doesn't prevent ; ((x bar)) ; following definitions to get broken. ; x) ;;; The variable zwei::*sectionize-line-lookahead* controls how many lines the parser ;;; is willing to look ahead while trying to parse a definition. Even 2 lines is enough ;;; for just about all cases, but there isn't much overhead, and 10 should be enough ;;; to satisfy pretty much everyone... but feel free to change it. ;;; - MT 880921 zwei: (defvar *sectionize-line-lookahead* 10) zwei: (DEFMETHOD (:SECTIONIZE-BUFFER MAJOR-MODE :DEFAULT) (FIRST-BP LAST-BP BUFFER STREAM INT-STREAM ADDED-COMPLETIONS) ADDED-COMPLETIONS ;ignored, obsolete (WHEN STREAM (SEND-IF-HANDLES STREAM :SET-RETURN-DIAGRAMS-AS-LINES T)) (INCF *SECTIONIZE-BUFFER*) (LET ((BUFFER-TICK (OR (SEND-IF-HANDLES BUFFER :SAVE-TICK) *TICK*)) OLD-CHANGED-SECTIONS) (TICK) ;; Flush old section nodes. Also collect the names of those that are modified, they are ;; the ones that will be modified again after a revert buffer. (DOLIST (NODE (NODE-INFERIORS BUFFER)) (AND (> (NODE-TICK NODE) BUFFER-TICK) (PUSH (LIST (SECTION-NODE-FUNCTION-SPEC NODE) (SECTION-NODE-DEFINITION-TYPE NODE)) OLD-CHANGED-SECTIONS)) (FLUSH-BP (INTERVAL-FIRST-BP NODE)) (FLUSH-BP (INTERVAL-LAST-BP NODE))) (DO ((LINE (BP-LINE FIRST-BP) (LINE-NEXT INT-LINE)) (LIMIT (BP-LINE LAST-BP)) (EOFFLG) (ABNORMAL T) (DEFINITION-LIST NIL) (BP (COPY-BP FIRST-BP)) (FUNCTION-SPEC) (DEFINITION-TYPE) (STR) (INT-LINE) (first-time t) (future-line) ; we actually read into future line (future-int-line) (PREV-NODE-START-BP FIRST-BP) (PREV-NODE-DEFINITION-LINE NIL) (PREV-NODE-FUNCTION-SPEC NIL) (PREV-NODE-TYPE 'HEADER) (PREVIOUS-NODE NIL) (NODE-LIST NIL) (STATE (SEND SELF :INITIAL-SECTIONIZATION-STATE))) (NIL) ;; If we have a stream, read another line. (when (AND STREAM (NOT EOFFLG)) (let ((lookahead (if future-line 1 *sectionize-line-lookahead*))) (dotimes (i lookahead) ; startup lookahead (MULTIPLE-VALUE (future-LINE EOFFLG) (LET ((DEFAULT-CONS-AREA *LINE-AREA*)) (SEND STREAM ':LINE-IN LINE-LEADER-SIZE))) (IF future-LINE (SETQ future-INT-LINE (FUNCALL INT-STREAM ':LINE-OUT future-LINE))) (when first-time (setq first-time nil) (setq line future-line) (setq int-line future-int-line)) (when eofflg (return))))) (SETQ INT-LINE LINE) (when int-line (MOVE-BP BP INT-LINE 0)) ;Record as potentially start-bp for a section ;; See if the line is the start of a defun. (WHEN (AND LINE (LET (ERR) (MULTIPLE-VALUE (FUNCTION-SPEC DEFINITION-TYPE STR ERR STATE) (SEND SELF ':SECTION-NAME INT-LINE BP STATE)) (NOT ERR))) (PUSH (LIST FUNCTION-SPEC DEFINITION-TYPE) DEFINITION-LIST) (SECTION-COMPLETION FUNCTION-SPEC STR NIL) ;; List methods under both names for user ease. (LET ((OTHER-COMPLETION (SEND SELF ':OTHER-SECTION-NAME-COMPLETION FUNCTION-SPEC INT-LINE))) (WHEN OTHER-COMPLETION (SECTION-COMPLETION FUNCTION-SPEC OTHER-COMPLETION NIL))) (LET ((PREV-NODE-END-BP (BACKWARD-OVER-COMMENT-LINES BP ':FORM-AS-BLANK))) ;; Don't make a section node if it's completely empty. This avoids making ;; a useless Buffer Header section node. Just set all the PREV variables ;; so that the next definition provokes the *right thing* (UNLESS (BP-= PREV-NODE-END-BP PREV-NODE-START-BP) (SETQ PREVIOUS-NODE (ADD-SECTION-NODE PREV-NODE-START-BP (SETQ PREV-NODE-START-BP PREV-NODE-END-BP) PREV-NODE-FUNCTION-SPEC PREV-NODE-TYPE PREV-NODE-DEFINITION-LINE BUFFER PREVIOUS-NODE (IF (LOOP FOR (FSPEC TYPE) IN OLD-CHANGED-SECTIONS THEREIS (AND (EQ PREV-NODE-FUNCTION-SPEC FSPEC) (EQ PREV-NODE-TYPE TYPE))) *TICK* BUFFER-TICK) BUFFER-TICK)) (PUSH PREVIOUS-NODE NODE-LIST))) (SETQ PREV-NODE-FUNCTION-SPEC FUNCTION-SPEC PREV-NODE-TYPE DEFINITION-TYPE PREV-NODE-DEFINITION-LINE INT-LINE)) ;; After processing the last line, exit. (WHEN (OR #+ignore EOFFLG (null line) (AND (NULL STREAM) (EQ LINE LIMIT))) ;; If reading a stream, we should not have inserted a CR ;; after the eof line. (WHEN STREAM (DELETE-INTERVAL (FORWARD-CHAR LAST-BP -1 T) LAST-BP T)) ;; The rest of the buffer is part of the last node (UNLESS (SEND SELF ':SECTION-NAME-TRIVIAL-P) ;; ---oh dear, what sort of section will this be? A non-empty HEADER ;; ---node. Well, ok for now. (PUSH (ADD-SECTION-NODE PREV-NODE-START-BP LAST-BP PREV-NODE-FUNCTION-SPEC PREV-NODE-TYPE PREV-NODE-DEFINITION-LINE BUFFER PREVIOUS-NODE (IF (LOOP FOR (FSPEC TYPE) IN OLD-CHANGED-SECTIONS THEREIS (AND (EQ PREV-NODE-FUNCTION-SPEC FSPEC) (EQ PREV-NODE-TYPE TYPE))) *TICK* BUFFER-TICK) BUFFER-TICK) NODE-LIST) (SETF (LINE-NODE (BP-LINE LAST-BP)) (CAR NODE-LIST))) (SETF (NODE-INFERIORS BUFFER) (NREVERSE NODE-LIST)) (SETF (NAMED-BUFFER-WITH-SECTIONS-FIRST-SECTION BUFFER) (CAR (NODE-INFERIORS BUFFER))) (SETQ ABNORMAL NIL) ;timing windows here ;; Speed up completion if enabled. (WHEN SI:*ENABLE-AARRAY-SORTING-AFTER-LOADS* (SI:SORT-AARRAY *ZMACS-COMPLETION-AARRAY*)) (SETQ *ZMACS-COMPLETION-AARRAY* (FOLLOW-STRUCTURE-FORWARDING *ZMACS-COMPLETION-AARRAY*)) (RETURN (VALUES (CL:SETF (ZMACS-SECTION-LIST BUFFER) (NREVERSE DEFINITION-LIST)) ABNORMAL)))))) ;;; Patch 3600-LOW.LISP ;;; Previously, if a source file in a PCL-based package contained what looks like ;;; flavor defmethod forms (i.e. an (IN-PACKAGE 'non-pcl-package) form appears at top ;;; level, and then a flavor-style defmethod form) appear, the parser would break. ;;; Now, if we can't parse the defmethod form, we send it to the flavor defmethod parser ;;; instead. ;;; also now supports multi-line arglist sectionizing. ;;; zwei: (defun parse-pcl-defmethod-for-zwei (bp-after-defmethod setfp) (block parser (flet ((barf (&optional (error t)) (return-from parser (cond ((eq error :flavor) (funcall (get 'flavor:defmethod 'zwei::definition-function-spec-parser) bp-after-defmethod)) (t (values nil nil nil error)))))) (let ((bp-after-generic (forward-sexp bp-after-defmethod)) (qualifiers ()) (specializers ()) (spec nil) (ignore1 nil) (ignore2 nil)) (when bp-after-generic (multiple-value-bind (generic error-p) (read-fspec-item-from-interval bp-after-defmethod bp-after-generic) (if error-p (barf) ; error here is really bad.... BARF! (progn (when (listp generic) (if (and (symbolp (car generic)) (string-equal (cl:symbol-name (car generic)) "SETF")) (setq generic (second generic) ; is a (setf xxx) form setfp t) (barf :flavor))) ; make a last-ditch-effort with flavor parser (let* ((bp1 bp-after-generic) (bp2 (forward-sexp bp1))) (cl:loop (if (null bp2) (barf :more) ; item not closed - need another line! (multiple-value-bind (item error-p) (read-fspec-item-from-interval bp1 bp2) (cond (error-p (barf)) ; ((listp item) (setq qualifiers (nreverse qualifiers)) (cl:multiple-value-setq (ignore1 ignore2 specializers) (pcl::parse-specialized-lambda-list item)) (setq spec (pcl::make-method-spec (if setfp `(cl:setf ,generic) generic) qualifiers specializers)) (return (values spec 'defun (string-interval bp-after-defmethod bp2)))) (t (push item qualifiers) (setq bp1 bp2 bp2 (forward-sexp bp2)))))))))))))))) ;;; PATCH 3600-low.lisp (or maybe rel-7-2-patches?) ;;; Fix a minor but annoying bug in Genera 7.2 dynamic window presentations... ;;; it isn't directly related to PCL at all, but use of PCL is how we found the ;;; bug. ;;; - rshapiro #+genera-release-7-2 dw:: (defun symbol-flavor-or-cl-type (symbol) (declare (values flavor defstruct-p deftype-fun typep-fun atomic-subtype-parent non-atomic-deftype)) (multiple-value-bind (result foundp) (gethash symbol *flavor-or-cl-type-cache*) (let ((frob (if foundp result (setf (gethash symbol *flavor-or-cl-type-cache*) (or (get symbol 'flavor:flavor) (not (null (defstruct-type-p symbol))) (let* ((deftype (get symbol 'deftype)) (descriptor (symbol-presentation-type-descriptor symbol)) (typep (unless (and descriptor (presentation-type-explicit-type-function descriptor)) ;; Don't override the one defined in the presentation-type. (get symbol 'typep))) (atomic-subtype-parent (find-atomic-subtype-parent symbol)) (non-atomic-deftype (when (and (not descriptor) deftype) (not (member (first (type-arglist symbol)) '(&rest &key &optional)))))) (if (or typep (not (atom deftype)) non-atomic-deftype ;; deftype overrides atomic-subtype-parent. (and (not deftype) atomic-subtype-parent)) (list-in-area *handler-dynamic-area* deftype typep atomic-subtype-parent non-atomic-deftype) deftype))))))) (locally (declare (inline compiled-function-p)) (etypecase frob (array (values frob)) (null (values nil)) ((member t) (values nil t)) (compiled-function (values nil nil frob)) (lexical-closure (values nil nil frob)) ;bugfix - added clause. (list (destructuring-bind (deftype typep atomic-subtype-parent non-atomic-deftype) frob (values nil nil deftype typep atomic-subtype-parent non-atomic-deftype))) (symbol (values nil nil nil nil frob))))))) From Common-Lisp-Object-System-mailer@SAIL.STANFORD.EDU Wed Sep 21 14:17:20 1988 Received: from Sail.Stanford.EDU by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.3) id AA23861; Wed, 21 Sep 88 14:17:20 PDT Received: from Sun.COM by SAIL.Stanford.EDU with TCP; 21 Sep 88 14:23:13 PDT Received: from snail.sun.com by Sun.COM (4.0/SMI-4.0) id AA06488; Wed, 21 Sep 88 14:18:19 PDT Received: from lukasiewicz.sun.com by snail.sun.com (4.0/SMI-4.0) id AA07789; Wed, 21 Sep 88 14:20:58 PDT Received: by lukasiewicz.sun.com (4.0/SMI-4.0) id AA15464; Wed, 21 Sep 88 13:14:22 PDT Date: Wed, 21 Sep 88 13:14:22 PDT From: jrose@Sun.COM (John Rose) Message-Id: <8809212014.AA15464@lukasiewicz.sun.com> To: K311770@AEARN.BITNET To: Gregor.pa@Xerox.COM, common-lisp-object-system@SAIL.STANFORD.EDU In-Reply-To: Hubert Hofbauer's message of Wed, 21 Sep 88 15:29:23 EDT <880921-091549-596@Xerox> Subject: metaobject protocol (description languages) At RISC Linz we are currently evaluating PCL as a basis for our symbolic computation library. An important issue in this field are parameterized types - families of classes - such as zmod N, polynomial over A-FIELD in VARS, matrix DIMS of DOMAIN,... , where N, A-FIELD, VARS, DIMS, and DOMAIN are parameters for type zmod, polynomial, and matrix. We would like something like (DEFCLASS (ZMOD N) ...) and (DEFMETHOD xxx ((Z (ZMOD N))... )... ). Given the ability to make reasonably general user-definable specializers, you could fake parametrized types, by putting the parametrization info into a slot, and defining a specializer type which dispatched on that slot's value. Something like this: (DEFCLASS ZMOD ((N) ...) ...) (DEFDESCRIPTION ZMOD ((N :KEY #'(LAMBDA (X) (SLOT-VALUE X 'N)))) (:SUPER (ZMOD))) (DEFMETHOD # ((Z (ZMOD N)) ...) ...) The fictitious DEFDESCRIPTION form would give meaning to specializers of the form (ZMOD #). The effect would be to enrich the standard "description language" of specializers, which consists only of class names and EQL constructs. A certain amount of structure is needed to relate new descriptions to the existing ones; this has been discussed in previous messages from me. I believe that many uses of the meta class protocol will center around the extension of the specializer syntax and semantics (hence, of the generic function dispatch mechanisms), rather than around finding new ways to implement slotted structures. -- John From Owners-COMMONLOOPS.PA@Xerox.COM Thu Sep 22 11:52:53 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.3) id AA24566; Mon, 19 Sep 88 09:02:50 PDT Received: from Cabernet.ms by ArpaGateway.ms ; 19 SEP 88 09:08:08 PDT Return-Path: <@EN-C06.Prime.COM,@ENB.Prime.COM,@ENI.Prime.COM,@s66.Prime.COM:SOBO@s66.Prime.COM> Redistributed: COMMONLOOPS.PA Received: from EN-C06.Prime.COM ([192.5.58.32]) by Xerox.COM ; 19 SEP 88 09:01:36 PDT Received: from ENB.Prime.COM by EN-C06.Prime.COM; 19 Sep 88 12:01:32 EDT Received: from ENI.Prime.COM by ENB.Prime.COM; 19 Sep 88 11:57:42 EDT Received: from s66.Prime.COM by ENI.Prime.COM; 19 Sep 88 12:04:02 EDT Received: (from user SOBO) by s66.Prime.COM; 19 Sep 88 11:57:21 EST Subject: Recording method definitions To: COMMONLOOPS.PA@Xerox.COM From: SOBO@s66.Prime.COM Date: 19 Sep 88 11:57:21 EST Message-Id: <880919-090808-1429@Xerox> Can someone please tell me why recording the source file for method definitions is *still* disabled on the Symbolics? Nadine Sobolevitch an expr and thus PCL wouldn't allow the trace code to be redefined as a method. At the time I sent the message, I wasn't aware of this problem. The way I get around this problem is to untrace the method, redefine it, and then trace it again. It is a pain, because I have to remember what's a method and what's a function, but it works. Chris Burdorf From Owners-CommonLoops.PA@Xerox.COM Thu Sep 22 12:52:55 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.3) id AA00045; Mon, 19 Sep 88 16:14:09 PDT Received: from Chardonnay.ms by ArpaGateway.ms ; 19 SEP 88 12:57:30 PDT Return-Path: Redistributed: CommonLoops.PA Received: from vaxa.isi.edu ([128.9.0.33]) by Xerox.COM ; 19 SEP 88 12:55:00 PDT Date: Mon, 19 Sep 88 12:40:11 PDT From: bmiller@vaxa.isi.edu (Brent Miller) Posted-Date: Mon, 19 Sep 88 12:40:11 PDT Message-Id: <8809191940.AA02150@vaxa.isi.edu> Received: by vaxa.isi.edu (5.54/5.51) id AA02150; Mon, 19 Sep 88 12:40:11 PDT To: CommonLoops.PA@Xerox.COM Subject: Please put me on the mailing list Thanks.