Comments on new draft chapter 1 (dated May 13 20:53)

[David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>]

    Date: Fri, 20 May 88 17:35 EDT
    From: Richard Mlynarik <MLY@AI.AI.MIT.EDU>

Comments on a subset of your comments, not to imply that the remainder
should be ignored.  In general I agree with them.

    1-25 To this reader, the statement in the 4th enumerated PP that ``The
    checking of the validity of keyword names is done in the generic
    function, not in each method'' seems inconsistent with the second PP on
    1-26 ``If a method is passed a keyword argument is does not accept, an
    error is signaled.''  Is the indent to draw some distinction between &key
    args from DEFGENERIC and those which come from random DEFMETHODs?  If
    so, this should be made a lot clearer.

I missed this one in my recent review of the document.
I believe the word "method" in the 2nd pp on 1-26 is a typo and should
be "generic function."  Clearer would be "If a generic function is passed
a keyword argument that no applicable method accepts, an error is signaled."
Also, for consistency with the last paragraph on CLtL p.62, it should be
"an error should be signaled" rather than "an error is signaled."  Not
that I am a fan of implementations that allow you to turn off error checking.

    1-32 <foo>

I don't follow.

    1-33 Penultimate PP.  I am probably just plain confused on this point,
    but is it possible that ``and instances of the classes standard-method,
    ...''  should read just ``the classes standard-method, ...''?  The
    reference to standard-method in the following bulleted PP reinforces my
    probably-mistaken belief.

No, the text is correct as it stands.  Everything involving meta objects is
inherently confusing because it's difficult to keep the two levels straight.

    1-39 3rd PP.  I question the use of the word ``captured'' (which occurs
    in other places in both Chapters 1 and 2.)  ``Inherited'' seems more
    straight-forward to me.  This is probably just a personal preference.

"Captured" refers to lexical capturing, not class inheritance.  I'm not
sure it's necessary to repeat "captured" periodically; we could just leave
it to the explanation on 1-10 and again on 1-35.

    1-39 Table.  The last line would seem to imply that the defaulted
    initlist must always be '(a 1 a 2 b 2), ruling out the `optimization'
    (a 1 b 2).  Is this the intent?  It seems to unnecessarily constrain the
    behaviour of default-initargs methods.

"a 2" was not put in by defaulting, it was supplied explicitly by the caller.
Given that, I don't think we want to change the table.

    1-39 The section `Shared-Initialize' The introduction of this section at
    this point seems very unmotivated.  Nowhere above (except by implication
    of the `--'-bulleted PPs on 1-37) is it made clear that
    shared-initialize is an `underlying' method called by all the various
    (re)initialization methods.  Some small preamble at the beginning of
    this section would make a first-time reading of the the spec somewhat
    easier.

The spec is deliberately made difficult to read to discourage people from
making implementations without reading it slowly and carefully :-)

	 At this point I suppose I might as well express my misgivings about
    the name `shared-initialize' -- it seems to imply to me something to do
    with `shared' (ie class-allocated) slots or something like that.  For
    what it's worth, I'll state that the names `initialize-slots,'
    `basic-initialize' and even `common-initialize' (or even
    `initialize'!) appeal to me more than `shared-initialize.'

The false connotation of shared slots is the same comment I had.  However,
all four of your suggested alternatives have problems, and we spent so much
time trying to find a better name that I think we should go with the one
we have for this round of the document, and let X3J13 instruct us to change
it if they so desire.

    1-40 First (bulleted) PP.  What if the instance doesn't have a slot with
    named by one of the elements of the list?  Is it ``an error?''  Is
    slot-missing called?

You're right, we need to specify this.  Let's make it "the results are
unspecified."

    1-41 Definition of make-instance.  Is nobody else bothered by the fact
    that the use DEFAULT-INITARGS may be a consful operation in the presence
    of :default-initargs?  It would be very easy for the evaluation of
    DEFAULT-INITARGS to consume more storage (to construct a merged initargs
    list) than that of ALLOCATE-INSTANCE does in creation of the instance
    itself! 

Of course.  But the spec defines the semantics of the language, not how
to do semantics-preserving implementation-dependent optimizations.  I
don't think complicating the specification to make it slightly more
obvious how to optimizations is a good tradeoff.  Also, with reasonable
garbage collectors, which are starting to emerge even on traditional
hardware, consing is not such a burden.

    Finally, just to be contentious (I'm not inviting replies):

Yes, CLOS definitely has that design-by-committee aroma.

    * I find the `evalness' of define-method-combination very disturbing.
    It seems to me that a full lisp compiler or evaluator will need to be
    present in any world into are loaded methods on generic functions which
    use user-defined method-combination.  I would -very- much like to be
    convinced that this isn't the case.

I don't understand your point.  How is define-method-combination different
from defmacro in this respect?  Perhaps you've been misled by the way the
spec describes everything as if it was interpreted into thinking that it
cannot be compiled?