Gregor's comments on 2/2/87 draft of functi

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

    Date: 4 Feb 87 14:13 PST
    From: Gregor.pa@Xerox.COM

    Here are a bunch of comments on the 2/2 draft of functi.

The last draft I've seen is 1/31; what changed?

    --
    add-method (and remove-method)

    still say that it accepts symbols or a list of (SETF <symbol>) as
    argument.  I proposed and Moon agreed that it should only accept generic
    function objects as its first argument.  In a separate message I will
    mail out a proposal for ensure-generic-function which is needed as part
    of this change.  For the time being I suggest that
    ensure-generic-function be added to functi to "hold a place for it".

In general I agree with that.  There might be some details to settle.
I think the discussion happened after we finished editing the document,
which is why it didn't get reflected.  There may not be quite time to
finish this before Dick's stated deadline of Sunday night.

    --
    call-next-method

    (2nd paragragh under purpose, end of next to last sentence)
    The phrase "otherwise it is the next most specific primary method" is
    wrong.  It should be something like "otherwise it is the effective
    method which would have been called had there been no :around methods".

Right, looks like an editing mistake since it's the same text as in the
next sentence.

    (1rst paragraph under remarks)
    The last sentence would be more clear if it read:
      Neither argument defaulting, nor the use of setq, nor rebinding the
    variables with the
      same names as parameters affects the values call-next-method passes to
    the method it
      calls.

Whatever.

    --
    change-class

    (1rst para under purpose, 3rd sentence)
    should say the class-changed generic-function is called.

I agree.

    I don't like the indenting of the defclass forms in the examples here.
    I would like to see defclass dorms indented as follows.

    If there are no slots and no options, it should be all on one line:

    (defclass foo () ())
    (defclass bar (foo) ())

    If there are slots or options, the name and supers should be on the
    first line, then the slot descriptions should be indented under the c in
    defclass, then the options should be indented under the e in defclass.

That's okay with me.  I guess it's time we spent the 5 minutes it takes to
make our editor know about defclass and enforce those indentation rules.

    --
    class-of

    last paragraph on the page (under remarks)
    shouldn't this say that class-of returns a class at "least as specific"
    as specified according to figure 1-2.  The difference is that what is
    written says that class-of will always return a class the user has heard
    of, what I am suggesting is that class-of will always return a subclass
    of a class the user has heard of.

In general I agree.  I think your proposed wording is still confusing.
I would rephrase it (assuming "meta-instance of" as a dual of
"meta-class of" is defined elsewhere):
  If the object is a meta-instance of STANDARD-TYPE-CLASS, the class
  returned may be a subclass of one of the classes listed in Figure 1-2.
I'm not sure the phrase "most specific class" really means anything, I
would avoid it.

    --
    defclass

    (2nd para under purpose)
    "that FUNCTIONS be automatically generated" should be "that METHODS
    automatically BE DEFINED ON GENERIC-FUNCTIONS to .." or something like
    it.  This same mistake occurs later in the paragraph.  It looks like
    someone just lifted this from some defstruct documentation somewhere.

Agreed.

    The 3rd (and last) paragraph under purpose wouldn't be needed if we
    could figure out this type to class mapping better and explain it
    better.

I disagree.  This is the class to type mapping, not the type to class
mapping; the description here is about as specific as could be; and I
think defclass is a good place to mention it.  Probably it should be
mentioned in the Concepts chapter too.

    Under Syntax:

    the abbreviation for having an initform with no other slot options
    (<slot-name> <initform>) is missing.

Agreed.  Does anyone think this should not be put back?

    the argument to accessor-prefix and friends is described as string or
    symbol.  Its always a symbol, its sometimes NIL.

Agreed that string should go away.  I think the special-casing of NIL
should go away too, but Danny is still resisting.

    Under arguments:

    (2nd para) it doesn't say that the superclass-name arguments must name a
    class of class standard-class.  This may not be the right place to say
    it, but I can't find this anywhere.

I don't think it should be explained in terms of standard-class.  I think
the explanation should be that if a class and one of its superclasses are
of different metaclasses, whether this is valid depends on the particular
two metaclasses and is controlled by the meta-class protocol.  Further
discussion should be in the meta-objects chapter.  The special case of a
standard class and a standard type class is mentioned on the last page of
the Concepts chapter.

    (3rd para) "there must not be any duplicate slot-names" Or else what?
    Perhaps "If there are any duplicate slot-names an error is signalled"
    would be better.

Yes, although that language can get rather stilted when discussing macros,
where the errors are signalled at compile time rather than run time.

    Under the description of class-options, the argument to :accessor-prefix
    and friends is also listed as a string-or-symbol.

    Under values:
    I thought we decided all these DEF forms were going to return the object
    they defined?

This seems to have been changed back and forth several times.  I'm happy
with all of them returning the object if that's okay with everyone else.

    Under remarks:

    (6th para after the 4 bullets), there is a sentence missing before the
    last sentence.  The last sentence reads "No other slot option may appear
    more than once.."  The missing sentence would say which slots options
    could appear more than once.

Editing error.  The last sentence of that paragraph belongs two paragraphs
earlier ("It is valid to specify...").

    --
    defgeneric-options-setf (and defmethod-setf)

    Let me say once again, that in order for the user to be able to add
    methods to a setf-generic-function with add-method, we must document the
    convention which defgeneric-options-setf and defmethod-setf use to pass
    the new-value argument to the setf generic function.  I believe the
    convention we must use is that the new-valeu argument to setf becomes
    the first argument to the generic function.

Wouldn't it be better to ask the generic function what its convention is?
Probably a generic function on a generic function and two lambda-lists that
returns one lambda-list.

This seems to be just one of several things we have to solve or clarify if
we expect the add-method level to be taken seriously.

    --
    get-method

    The specializers argument needs to be changed to be a list of
    class-objects or (QUOTE <datum>).

As I've said several times, this isn't right because it doesn't extend well
to discriminating on optional and keyword arguments.  I agree that class
objects rather than class names are wanted, now that we have clarified that
redefining a class modifies the existing class object rather than creating
a new one.  I don't agree with the format as a simple list.

    get-method should not error in the case where no such method exists.
    get-method is the only way to see if such a method exists, it should
    return nil if there isn't one.  Once get-method is changed this way,
    add-method and remove-method's error conditions are good.

Give it an optional error-p argument, I think.

    --
    invalid-method-error and method-combination-error

    I still don't like having these as separate functions.  Could we put a
    note saying that if the condition system is adopted before this
    proposal, these functions would be replaced by descriptions of the
    appropriate condition to signal?

I don't agree with this.  I believe in abstractions for signalling
conditions rather than signalling them directly.  I can spend time
writing a detailed explanation if the motherhood statement that
abstractions are good, and a few minutes thought about proceeding,
aren't enough to convince you.

    --
    make-generic-function and make-method

    I thought we had decided to remove this from the spec.  I believe the
    only thing holding that up is a decision about the initialization
    protocol.  Since nothing is happening with the initialization protocol,
    I plan to write up a revised version of my Strawman, incorporating the
    comments I have received from Moon and as Linda to put it in the spec.
    Afterwards, I think we should replace make-generic-function and
    make-method with descriptions of the appropriate arguments to pass to
    make-instance to make a method a generic-function (and a class).

Agreed tentatively.

    --
    with-slots

    The first paragraph under arguments should probably say the instance
    form must evaluate to an object of class standard class.

I assume you made a typo here and you meant to say that the document
should -not- say this.  with-slots should work for anything.  Of course
if the class has no slots it will be a no-op, but it shouldn't blow out.

    The
    meta-object protocol chapter will describe how to extend with-slots to
    work with instances with other meta-classes.

That's why with-slots should work for anything.