Chapter 1 and 2 Last Chance Review

[Sonya E. Keene <skeene@STONY-BROOK.SCRC.Symbolics.COM>]

    Date: Wed, 13 Apr 88 16:19:19 EDT
    From: Dan L. Pierson <pierson%mist@multimax.ARPA>

      Comments on Chapters 1 and 2 of the CLOS Spec (Edition of 2/8/88)

Hey, you actually read it!  Thanks for the useful comments.   

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

Good idea.   (I think originally this section was intended to be an
overview of the more interesting features, but eventually all of the 
features got added except for the :type constraint.)

    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.

Some background is:  we know that any implementation of CLOS will have
to have a primitive that does what SLOT-VALUE does.  Otherwise you
couldn't implement readers or writers at all.  So we document that
primitive (SLOT-VALUE) so that all implementations give it the same
name, arguments, and behavior, and therefore users can write portable
code that calls it.    The goal is to expose the underlying mechanisms
if they are generally useful.

The purpose of WITH-SLOTS is just to be a shortcut syntax for using
SLOT-VALUE all over the place.    It's "required" to be implemented with
SLOT-VALUE because that's just the definition of what it does.  

As for why readers and writers are "required" to be implemented using
SLOT-VALUE, hmmm, I'm not sure.  I don't think there's any reason why
you wouldn't implement readers and writers with SLOT-VALUE, since
SLOT-VALUE does the thing you want to do.    

	       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 maked WITH-SLOTS unsafe.

The implication was intended; that's the difference between the two
macros.   I personally agree with people who feel WITH-SLOTS is unsafe.
We could add a sentence to imply what we mean more directly.   

    Page 1-13, Paragraph 4
		This paragraph appears self-contradictory.  I think that
		it means that portable code cannot depend on slot types
		since:
		    (1) Some implementations may not provide type errors
			(therefore reducing the value of slot types for
			 debugging), and

Yes, it does mean (1).   This is also said in the first bullet on page
1-13.

		    (2) Calls from outside the package may store incorrect
			types (so even if your portable code is self-consistent
			you could wind up with undetected type errors).

I don't know what you mean by (2).

		The wording of this paragraph leads me to suspect that
		this issue has already been argued to death on the CLOS list.

(Don't let the wording fool you.   We argue every issue to death.) 

    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.

Your point about "some methods could have been defined by DEFMETHOD" is
correct, and we should probably add a sentence to that effect.   

    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.  

The section in page 1-32 doesn't present the simpler, common special
case first and then get into details that include the hairy, rare cases.
It does all cases at once.    This is a very central part of CLOS, and
it is somewhat complex, so readers are going to have to read the section
on Method Selection and Combination a couple times or more.   I think
it's OK as it is.  

                This *may* be
		appropriate for a standards document but it certainly
		isn't for a manual.

Right.   Manuals have a lot more freedom.  

    Page 2-27, Next to last paragraph

		Can extension slot options appear more than once in a
		single slot description (it appears reasonable, but it's
		not clear from this whether it's legal).

	       Last paragraph

		The slot can also be accessed by WITH-SLOTS, since
		WITH-SLOTS uses SLOT-VALUE.

Do you think we need to say that explicitly?    Since WITH-SLOTS is
defined in terms of SLOT-VALUE, I think most readers will figure this
out, as you did.  

    Page 2-35, Paragraphs 7 and 8

		These paragraphs don't specify how to distinguish a
		predicate from the first keyword option since they are
		both distinguished by being symbols other than * (or NIL).