Re: Issues raised by comments on chapter 2

[Danny Bobrow <Bobrow.pa@Xerox.COM>]

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
answered by Syntax and Method Signatures is helpful.
    How do I call this g-f?  
       --Answered by Syntax

    What methods are guaranteed to exist for this g-f?  
       --Answered by Method Signature 

Some other comments:
---- 

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. 

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

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

RPG answers:
    ``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.