# Re: Issues raised by comments on chapter 2

After pondering Dick's and Sonya's messages, I take back my plea for
non-redundancy (I usually favor redundancy anyway).  Syntax is useful,
and I think Method Signatures should include all the arguments,
including keyword names, optionals (as they did for make-instance in the
version of Nov 2).  Sonya's characterization of the different questions
How do I call this g-f?

What methods are guaranteed to exist for this g-f?

----

RPG:
One reason to describe the arguments in English is to introduce
some simple noun phrase to use to talk about these arguments.
I also agree with Dick's comment.  The redundancy I found slightly
distressing was where Arguments gave type restrictions on specialized
arguments (e.g. The {\it method} argument is a method object.).  I am
all in favor of English.

----
RPG:
I propose, then, that the policy of CLOS be that purpose
statements be promoted to apply to generic functions whenever
feasible.
This is the place that the contract for the genric function is
described.

---

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)."''

Therefore the purpose of the second method must say something
like:

This method invokes CHANGE-CLASS on {\it instance} and
(symbol-class {\it symbol}).''
I agree with Dick.  A much better wording of what I intended.
------
RPG:
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.
I don't know what I said to generate this idea.  I think I believe the
statement above.

But I don't know what criteria are appropriate.  What are the criteria
for Common Lisp implementations.  Must they have just the types and
functions specified in CTtL.  Or is it only the using up of symbols that
count (i.e. Can an implementation have functions and types whose names
the ordinary user doesn't see?).  If so, are extra methods (which don't
have names) more like types and functions whose names are in another
package, or like symbols.

For example, CLOS specifies only one method for describe.  Could special
methods for describe specialized to pathnames or streams etc. be
defined.  Isn't this an implemenation decision relative to putting the
code to discriminate these types in the default method, or in separate
methods?

Finally, I appreciate the spirit in which Dick wrote his response:
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.