Re: unoptimized Slot-value and other things

[Gregor.pa@Xerox.COM]

    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.
-------