Moon's Comments on RPG's Comments on Moon's Errata

[Dick Gabriel <RPG@SAIL.STANFORD.EDU>]

Moon comments:

``For example, in an earlier proposal from Xerox C-sub-o was given the
name (intern (concatenate 'string "obsolete-" (symbol-name (class-name
class)))), or something similar.  This had a problem if the class was
redefined twice, but that could easily be fixed.''

Thank God this proposal went by the boards, though it is an excellent example
of why it's the case that the fewer things are named the better off we are.

Moon continues:

``I put the following into my errata file, is this okay with everybody?

``1-11 fourth paragraph: Delete the entire paragraph, it isn't true.  Replace
it with this paragraph:
  Because the class C-sub-O does not have a name, writing a method for
  class-changed that is specialized to a particular C-sub-O
  must be done through the functional interface, using add-method rather
  than using defmethod.  See the section ``Introduction to Methods.'' ''

This seems fine.

Moon writes:

``I didn't think the phrase "where {\it parameter-specializer-name\/} is a
parameter specializer name" added anything to understandability.''

If a reader has gotten used to meta-syntactic items being linked to
English phrases in a precise way, then failing to do that reduces
understandability.

How about this:

      Each method has a {\bit specialized lambda-list}, which determines when
      that method can be selected.  A specialized lambda-list is like an
      ordinary lambda-list except that a {\bit specialized parameter} may occur
      instead of the name of a parameter.  A specialized parameter is a list,
      {\tt ({\it variable-name parameter-specializer-name\/})}, where {\it
      parameter-specializer-name} is a parameter specializer name.  Every
      parameter specializer name is a Common Lisp type specifier, but the only
      Common Lisp type specifiers that are valid as parameter specializer names
      are the following:

This is Moon's rewrite with my pissant addition.

Moon writes:

``This is better than what I suggested, but self-contradictory.  First it
says that each required parameter must be a specializer parameter, which
was earlier defined as a list, then it says that a required parameter
can be a symbol.''

Well, it actually said that the notation enabled a programmer to write a symbol
that would be taken as a specialized parameter, but Moon's rewriting is better
than what I had:

      Only required parameters can be specialized, and there must be a
      parameter specializer for each required parameter.  For notational
      simplicity, if some required parameter in a specialized lambda-list is
      simply a variable name, its parameter specializer defaults to the class
      named {\bf t}.

Moon correctly comments and asks:

``If this means that typep is to be extended to accept class objects, that is a
reasonable extension to propose, however since it is mentioned nowhere else in
the document and is not stated explicitly here, and was never discussed on the
mailing list, I assumed that that was not the intention, and instead the
problem was that the conversion from "parameter specializer" to "parameter
specializer name" had not been carried out uniformly.  So which is it?  If
typep is to accept class objects, we need an errata entry that makes that very
explicit.''

The class redefinition prose that Moon inserted into the document at some point
in time requires either that the prose talking about TYPEP at this point in the
document be removed or amended as I tried. I presumed that deleting content was
incorrect, so I tried to fix up this prose to be consistent.  The offending
statement is ``the function TYPEP can be used to determine whether an argument
satisfies a parameter specializer.'' This statement is meant to reinforce the
fact that the class system extends the CL type system. If this statement is to
stand, TYPEP has to deal with class objects in addition to class names, because
of the functional interface.

More specifically, the issue is that MAKE-METHOD specifies class objects and
possibly TYPEP should be used during generic function invocation to
determine which methods are applicable. The class redefinition protocol
requires that we be able to write methods that apply to classes that have been
rendered obsolete (or nameless).

Here are the alternatives:

	1. MAKE-METHOD takes class names; TYPEP operates on names and
	   type specifiers as usual (extended to classes); redefining
	   a class creates a stupid but predictable name for the ``old''
	   class (or we invent some funny notation to refer to obsolete
	   classes of various vintages).

	2. MAKE-METHOD takes class objects; TYPEP is extended to class objects;
	   class redefinition renders the ``old'' class nameless.

	3. We simplify the class redefinition protocol to eliminate
	   CLASS-CHANGED (this is the generic function that causes the
	   problem.

	4. We can talk about how TYPEP can be used by the user to predict
	   which methods are applicable.

	5. We can eliminate any statements about TYPEP.

I think 3. is not easily acceptable, because Moon's class redefinition protocol
is quite powerful (and suggestive to people trying to understand the system).
Option 2. probably will piss off the Common Lisp crowd. Option 3. will piss
me off. Option 4. is dumb. Option 5. requires some further changes to the
document to provide the function that really decides satisfaction.

Moon's further remarks on this point correctly indicate other problems that
can be easily solved once we decide whether we really intend that TYPEP
work on class objects.

I think I agreed with all of Moon's other errata. Moon: at some point (when we
all agree on the list) you should mail your current errata list to me.

			-rpg-