Issues raised by comments on chapter 2

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

This message is about the format for description of generic functions
in chapter 2. The points are made as a response to a message that Danny
sent, but no one should interpret this as picking on his comments, which
simply serve to bring some decisions to light.

Danny writes:

``I think that if there is a method signature, there
should not be a section called Syntax.  They are to some extent
redundant, and where they are not, Syntax was almost always wrong.''

Hm. I should have written the class redefinition section `wrong', then we
could have eliminated that too. Renaming ``Syntax'' to ``Generic Function
Syntax'' is useful when the generic function lambda-list is important to
know - that is, when it doesn't derive from the method lambda-lists.
Think of INITIALIZE-INSTANCE.  And maybe it's generally useful for people
who are populating their CLOS with additional methods.

``<Add-method> This is the first example of the redundancy.  Please take out
Syntax, and the first two sentences under Arguments....''

If I do that, here's the result:

******************************************************************************

Method Signatures:

add-method (generic-function standard-generic-function) (method standard-method)

Arguments:

The lambda-list of the method function must be congruent with the
lambda-lists of all other methods associated with the generic function and
with the lambda-list of the generic function, or else an error is
signaled.

******************************************************************************

Unfortunately, there is no method function mentioned. There is a larger
liklihood that this would mean the method function of the argument passed
to {\it method}, I suppose.  A rewording of this could be:

``The lambda-list of the method function of the method object passed as
{\it method} must be congruent with the lambda-lists of all other methods
associated with the generic function and with the lambda-list of the
generic function, or else an error is signaled.''

One reason to describe the arguments in English is to introduce some
simple noun phrase to use to talk about these arguments.

Danny goes on:

``The signature specifies what the types of the arguments must be, and if
people add another method the arguments need not be those objects.''

This brings up the interesting point. We have a heading called ``Purpose:''.
Linda and I spent several hours last night trying to redesign the generic
function pages, and the question of when the purpose should be written as
the purpose of the generic function and when it should be the purpose
of some method. Here is an example, again ADD-METHOD.

****************************************************************************

Purpose:
The generic function add-method adds a method to a generic function.  It
destructively modifies the generic function and returns the modified
generic function as its result.

****************************************************************************

ADD-METHOD has 1 method defined. This purpose could be moved to
describe the purpose of that method. If we do that, then any additional
methods are not constrained to have any particular behavior or purpose.
For instance, ADD-METHOD when applied to 2 matrices could add them - it
is the add method, after all.

The purpose when left as a description of the generic function requires
implementors to define only methods for ADD-METHOD that satisfy that
purpose.

The spirit of object-oriented programming, I guess, states that users can
define whatever the hell they like for methods. The spirit of reasonable
abstraction states that users should be required to choose their own
random names for their random methods, leaving ADD-METHOD for methods that
add methods to generic functions.

I propose, then, that the policy of CLOS be that purpose statements be promoted
to apply to generic functions whenever feasible.

Danny writes about CHANGE-CLASS:

``Remove Syntax section, Remove first two lines of Arguments.  The last
sentence should read "... and then invokes the first method with the class
returned as value from (symbol-class symbol)."''

The last sentence cannot say this unless you are imagining that the
two methods on CHANGE-CLASS are defined as follows: Use LABELS to make
two functions, one that assumes a class as its second argument and one
that assumes a symbol as its second argument. Have the second invoke
the first (as a function) with (symbol-class symbol) as its second argument.
Now take these two functions and make method objects out of them with the
usual paraphenalia and stuff them into CHANGE-CLASS using ADD-METHOD.

I don't think this is what we mean. Therefore the purpose of the
second method must say something like:

``This method invokes CHANGE-CLASS on {\it instance} and (symbol-class
{\it symbol}).''

This is particularly relevant when the spirit of object-oriented programming
encourages us to write random methods for CHANGE-CLASS, and we certainly
want those methods to get a second crack at the instance in this case.

This brings up the second general point, which is are we going to require
that a pristine CLOS have all and only the methods described in the
specification? Danny's proposed rewrite of the description of CHANGE-CLASS
implies he believes so. I tend to favor the restriction.

Currently there is a statement in the introduction to Chapter 2 that
states:

``Any implementation of the \CLOS\ is allowed to provide other methods
for the generic functions described in this chapter.''

Opinions?

			-rpg-