Proof of CLOS Document

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

A few comments on excerpts from your comments:

    Date: Mon, 26 Oct 87 11:16:40 PST
    From: kempf%hplabsz@hplabs.HP.COM

    pg. 1-17: Last Paragraph. It is not clear from this what should happen
    if (TYPE-OF <obj>) returns a type speciifer which is a list. Should an
    error be signalled or should the CAR of the list be used? On pg. 42 of
    CLtL, the description of type specifiers which are lists suggests
    that the CAR should work.

Is this the page that has figure 1-1 on it?  I can't find anything on that
page that looks like what you're referring to.  I suspect you've uncovered
a problem here, but I can't find the problem.  Note however that the
second paragraph on page 1-16, where it says (type-of I) is S if S is
the proper name of C, else C, should say that this only applies when C
is an instance of STANDARD-CLASS.

    Overall: When referring to SETF functions, the list specifying a
    SETF function name is often not quoted. Example: (fboundp (setf <name>)).
    If the argument had been a function symbol name, however, it would have
    been quoted, since FBOUNDP is a function and therefore the arguments
    are evaluated. Shouldn't this be so for SETF function names as well,
    or is the assumption that (SETF <name>) is a macro which returns the
    actual name of the function (e.g. expands into something like '<actual name>)?

It's just missing quote marks; no hairy macro like that was intended.
Do you have page references for these typos?  I think I noticed one or two,
but they're easy to overlook and you probably saw some that I missed.

    Perhaps using the italic <setf-function-specification> would be more
    appropriate.

That would be okay too, although offhand I think it would be better to
say '(SETF <name>) so we don't have to define one more syntactic
nonterminal symbol.

    pg. 2-7: Is CALL-NEXT-METHOD a function? From the as yet incomplete
    e-mail discussion, it would seem to be either a macro (if Moon's
    implementation is accepted) or a special form.

CALL-NEXT-METHOD has been a function since we changed it from a macro
in late 1986 or early 1987.  I'm not sure what implementation of mine
you're referring to; I don't recall proposing one this year.  I proposed
one last year, which is totally out of date by now.

    pg. 2-7: 2nd Paragraph under ARGUMENTS. "the same set of applicable methods"
    I think what you mean here is the effective method, since, the intent is
    to avoid having to recalculate the effective method.

No it really means the stronger condition that it says.  Remember we spent a
long time discussing this.  I don't remember all the discussion, but it may
have been that "same applicable methods" is both easier to specify precisely
and easier to compute than "same effective method".

    pg. 2-26: :DECLARE description. Why prohibit INLINE and NOTINLINE? One
    optimization a compiler writer might want is to have the generic function
    code inserted in line. Or is the assumption that this should be controlled
    in the lexical context enclosing the generic function invocation, rather
    than in the definition of the generic function's interface?

Precisely.  The idea is that there isn't any body in DEFGENERIC, so there
isn't any code for INLINE and NOTINLINE declarations to affect.

    pg. 2-30: Top of page. I'm curious if the form generated is expected to
    be executable. That is, if <operator> can be a keyword symbol, then the
    implicit assumption is that the function cell of keywords can be 
    bound. I know this is possible in Symbolics CL and not in ours, also
    I don't think CLtL says anything either way. Is there a Cleanup proposal
    on this?

This moved to 2-29 in the latest draft (if things are getting shorter, that's
a good sign!).  I don't see anything that implies here that an implementation
has to allow <operator> to be a keyword symbol.  Certainly that was not
intended.  On the other hand, I don't know of anything in CLtL that allows
implementations to forbid defining keyword symbols as functions.  Anyway,
the intent here is that <operator> is the name of a function, macro, or
special form and can appear in the car of a form; precisely what objects
satisfy that criterion is defined by CL rather than CLOS.

    pg. 2-40: 2nd bullet item, last line. Do you mean list? (SETF <name>)
    is something more than a general list, I think. Perhaps function
    specification?

(SETF <name>) is certainly a list, whatever else it is.  But I note that
this is one the missing quote marks you mentioned earlier, which might
have obscured the meaning.  (Page 2-39 in latest draft.)

    pg. 3-12: SYNTAX. Shouldn't the argument list be an &REST parameter,
    since its size will vary depending on the number of required arguments
    the generic function accepts?

I don't think so, I think this argument is just a list of arguments.

    pg. 3-12: I'm confused by where the effective method is calculated.
    Is it this function, or is there another?

This function computes the applicable methods, not the effective method.
compute-effective-method is mentioned on 1-28, but there is no writeup
for it yet.