some questions on your chapter 2 comments

[David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>]

[Added back the rest of the mailing list for this question, which is
of general interest.]

    Date: 18 Jan 88  1808 PST
    From: Linda DeMichiel <LGD@SAIL.Stanford.EDU>

    In your comments on chapter 2 you mention:

      2-29 first line: This says that removing a :method from a defgeneric and
      re-evaluating the defgeneric does not remove the old method.  While that's
      a good default behavior, we should make sure not to rule out smart program
      development environments that know better what is going on and remove the
      old method in cases where the user thinks that's appropriate.  In the Error
      Terminology introduced in chapter 1, implementations should be free to
      extend this.  Redefinition is a program development environment issue, not
      really a language issue, anyway.

    This suggested change doesn't sound right to me.  The problem is that
    if this behavior on the part of defgeneric is extensible, programs
    that rely on the "default" behavior from defgeneric won't be portable.
    Or did you intend something else here?

Redefining a definition is a program development operation, not a programming
language operation.  Portable programs, with the possible exception of portable
program development tools, wouldn't depend on what happens when a defgeneric is
evaluated twice.

It wouldn't bother me a bit if we changed the language to require all
implementations to remove methods that were created by a defgeneric, if
the defgeneric were re-evaluated without the :method.  We already do this
for accessor methods created by defclass.  We're now saying that the class
remembers the specific method objects and removes them if they are still
there; if they've already been replaced by a defmethod, it doesn't remove
the method put there by the defmethod.

What would bother me would be if we required all implementations to be
stupid about this.

So how about it?  Shall we change CLOS so that re-evaluating a defgeneric
removes methods that were previously defined by :method, but no longer
appear in the new defgeneric form?  I think we should.