[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Editorial Comments and My Disposition of Them



Here is a series of excerpts from Gregor's message and how I dealt with them:

From: Dan L. Pierson <pierson%mist@multimax.ARPA>

Page 1-9,   Add to the list of things provided by slot options and
    	    class options:
	    
	    o Specifying the legal data types of the slot contents.

	    (Of course, this can be found elsewhere in the document,
	    but my impression on reading this introductory list was
	    that for some reason you couldn't do this.)
[RPG: ok]

Page 1-11, Paragraphs 3 and 7
    	    Why are reader, writer, and with-slots *required* to be
	    implemented using SLOT-VALUE?  I don't doubt that you have
	    a good reason, but it's not obvious to a relative novice.

[These must call slot value because the implementation of slot-value for
a particular class can be changed using the MOP.  We don't want to go
into that at this point in the document, but perhaps a simple forward
reference would be appropriate.

	   Paragraphs 7 and 8
	    This implies that WITH-SLOTS can access slots without
	    accessors but WITH-ACCESSORS can't.  This is reasonable
	    but should probably be made explicit.  Some people may
	    feel that this makes WITH-SLOTS unsafe.

[Yes this needs to be made explicit.]
[RPG: ok]

Page 1-26, Paragraph 2, Sentence 2
    	    The following are my exact notes as I read this section:

    	    What about methods in both old and new?  Are they "added"?
	    If so, in what way is this definition different from
	    saying that the "contents" of the old generic function are
	    trashed and replaced by the new generic function?  AHA!
	    Some methods could have been defined by DEFMETHOD, but the
	    wording is still confusing.

[RPG: Maybe it is, but it is quite precise. I think it's ok.]

    	   Paragraph 6, Sentence 3
	    The wording is a bit confusing.

[RPG: either I cannot find what he is talking about or else he is very
confused.  The sentence he refers to simply lists the forms in a category
that was just defined.]


Page 1-28, Paragraph 2, Sentence 4 and example line
    	    Has this been submitted to cleanup?  I don't recognize it.

[He is confused by the use of the expression "This proposal" to describe
the CLOS specification.  That should be clarified somehow.]

[RPG: ok]

Page 1.29, Paragraph 1
    	    The wording implies that:

	    	(EQUAL '(A (B C)) '((A B) C))

    	    is T, which is certainly false.  Note that cleanup is
	    entertaining proposal to flush EQUAL and EQUALP.

[Just change this to the lists of qualifiers are EQUAL?]
[RPG: The prose already states that we are dealing with lists of qualifiers
and not with anything resembling his point.]

Page 1-32, At this point I made a note:

    	    In general, this draft details the complex, general case
	    before the simpler, common special case.  This *may* be
	    appropriate for a standards document but it certainly
	    isn't for a manual.

[Sonya already explained to him that this wasn't a manual.  I will
include this criticism in the ones we respond to in written form so that
we can answer it for everyone.]

Date: Wed, 13 Apr 88 10:32 PDT
From: Sonya E. Keene <skeene@STONY-BROOK.SCRC.Symbolics.COM>


The section "Determining the Class Precedence List" has examples where
defclass is used to define classes, and the CPL is computed from those
definitions.   However, the CPLs shown don't include standard-object
(they do include t).   We should really fix this.  

[RPG: Fixed]

The table in Figure 1-1 has two columns, labelled "Predefined Common
Lisp Type" and "Class Precedence List".   The first column heading isn't
right; actually, it is correct, but it misses the point.   They are
Common Lisp types, but the important thing is that CLOS has classes
corresponding to those types.   I think that column heading should be
simply "Classes" or "Predefined Classes" (since "Classes Corresponding
to Common Lisp Types" is too long).

[RPG: Fixed]

Also, the section "Standard Meta-objects" says "The class named
standard-object is an instance of the class standard-class and is a
superclass of every class that is an instance of standard-class except
itself."   I believe that the MOP (p 3-10) contradicts this statement,
since the class structure-object is an instance of the class
standard-class, yet it doesn't have standard-object as a superclass.

[The draft of the MOP you were reading was wrong here.  structure-object
is an instance of structure-class.]

[RPG: Clarified the wording.]

Date: Thu, 21 Apr 88 19:32:30 JST
From: Masayuki Ida <ida%aoyama.cc.aoyama.junet@UTOKYO-RELAY.CSNET>

Comments on CLOS ch1 and ch2.

   1. explanation around the mixture of defmethod and defun.
   I could not find the specification on the mixture of
   defmethod and defun with the same name.
   is it error ? is it allowed in what sense?

[Somehow we need to make the following clear.

defun calls setf of symbol-fucntion, so defun totally wipes out what
used to be in the symbols `function cell'.  If the symbol used to name a
function it now names a new function.  If the symbol used to name a
generic function, that generic function is gone and the symbol now just
names the new function

defmethod calls ensure-generic-function which signals an error if the
symbol already names an ordinary function or macro.

Here is the state table, it might be a good idea to put this in the
document?

             function     macro       generic function  
           ----------------------------------------------
           |
defun      |  fn is        macro is    generic function
           |  replaced     replaced    is replaced
           |
defmacro   |  fn is        macro is    generic function
           |  replaced     replaced    is replaced
           |
defmethod  |  error        error       method is added to
           |  signalled    signalled   generic function,
           |                           existing method may
           |                           be replaced

]

[RPG: I think this is already clear. There is a section on naming
generic functions which states that generic functions are named
exactly as normal functions are. There are clear passages that state
that trying to add methods to non-generic functions cause errors to be
signaled.  Trying to define a function on top of a generic function is
covered by the naming discussion. I think if we say anything more than
what is already said, we will be specifying CL more than CL is currently
specified. There is already no discussion of what the following does in CL
except for the function naming disucssion in CLtL:

(defun f ...)
(defun f ...)

For example, we don't know what this does either:

(defun f ...)
(defmacro f ...)

So, the best we can do is to state that the generic function names are
exactly like CL ones and leave as an implication that your implementation
will do to generic functions whatever it does to ordinary functions
under DEFUN and DEFMACRO.]