Sections 2.3 and 2.5

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

    Date: Sat, 22 Apr 89 11:36:27 PDT
    From: Richard P. Gabriel <rpg@lucid.com>

    Of the three approaches Moon suggests, I favor a combination of
    bringing some stuff into the main specification from the prototype
    chapter 3 and flagging the rest as places for future extension.

This conversation seems to have flagged.  Out of inertia, I favor
minimizing changes to the language rather than trying to bring in
parts of chapter 3, even though if we did the extra work to rethink
the boundary between chapter 2 and chapter 3 we would probably end
up with a better language.

    I feel that the largest exposures we have are readers (but not
    writers) for some things like these (this list suggested by Jonl):

    class-direct-supers, class-direct-subclasses, class-direct-slots,
    class-slots, class-direct-methods, class-precedence-list,
    class-forward-referenced-supers, class-no-of-instance-slots,
    method-function, method-generic-function, method-arglist,
    method-qualifiers, method-specializers, generic-function-name,
    generic-function-methods, generic-function-discriminator-code,
    generic-function-lambda-list, slotd-name, slotd-allocation,
    slotd-initform, slotd-initargs, and slotd-type.

method-qualifiers is already in chapter 2.  The slotd- ones would
require also bringing slotd objects in chapter 2 (currently they
aren't), which I'm afraid of because the chapter 3 definition of slotd
objects seems to still be changing.  The ones that return lists of slotd
objects can't be used if we don't have slotd objects.
class-forward-referenced-supers is too controversial as well as a bad
name.  class-no-of-instance-slots seems unnecessary and is a bad name.
generic-function-discriminator-code is too implementation-dependent.
method-function is too implementation-dependent.

The remaining ones would be okay, however I haven't found the time to
figure out whether they would make a complete and consistent set.
That's class-direct-supers [again a bad name], class-direct-subclasses,
class-direct-methods, class-precedence-list, method-generic-function,
method-arglist [should be method-lambda-list], method-specializers,
generic-function-name, generic-function-methods, and
generic-function-lambda-list.

    Also we are exposed on the inability to make methods for add-method to
    use. These are the places where I would consider trying move something
    into the main specification.

I agree about the add-method problem.  Since the macroexpansion of defmethod
in chapter 3 is still in flux, I think it might be unwise to try to bring
into chapter 2 a way to construct the argument to add-method.  It might be
better to get rid of add-method.  I haven't found the time to figure out
whether getting rid of add-method would break anything.  Maybe it's better
just to flag add-method as a place for future expansion and not change
the language.

I looked through the summary on pages 2-5 and 2-6 of 88-002R and the following
seemed not clearly justified as chapter 2 rather than chapter 3.  Again I
can't claim to have evaluated the possible danger of kicking these out to
chapter 3.
  add-method
  compute-applicable-methods
  ensure-generic-function
Everything else in chapter 2 clearly belongs in the programmer interface
rather than the metaobjects level.

Also it's perhaps time to bring up the question of whether we really want
the ANSI standard to include generic-flet, generic-function, generic-labels,
and with-added-methods.  While these nicely round out the language, I have
so far been unable to discover any CLOS implementation that implements them
or says it plans to implement them.  Putting them in the standard is
probably premature in the absence of any practice.

    Someone [probably KMP] writes:

    ``p.2-3, para.3: Without meta objects one can't create anonymous
    classes and improper class names, so much of this paragraph is
    currently irrelevant.  Keep the first two sentences and the last
    sentence, delete the rest.  [I think we should keep it anyway, but
    flag it as a framework for future extensions --Moon]''

    Hm, I thought CLASS-NAME was a SETFable place, as was FIND-CLASS, but
    I guess that isn't true as it currently stands.

class-name and find-class are both documented as setf'able in 88-002R.
There's no way to make an argument for (setf find-class) except by
getting a named class defined by defclass, but still this is enough to
create improper class names and even anonymous classes in a roundabout
way.  So most likely the whole paragraph should be kept (I don't have
a copy of it here to recheck what it said).

    ``p.2-4, para.3,4: Again the stuff about metaclasses is not relevant to
    the current metaobject-free standard.''

    Well, there are various metaclasses now (structure-class and
    standard-class), and there are some places that talk about compatible
    metaclasses. I can't believe it's reasonable to flush all mention of
    metaclasses because you cannot create them. (Actually, you can, but it
    isn't likely that you can do anything useful with them. For example,
    you can do (defclass random-metaclass (standard-class)) and then
    proceed to make instances of it which are hardly distinguishable from
    ordinary standard classes.)

Agreed.

    ``p.2-5, bullet 3: changing "is shared by instances" to
    "is shared by all instances" would be clearer.''

    This is fine. Kathy, can you do this?

Agreed.

    ``p.2-5: Delete the 3-line inheritance section.  This section has been
    reorganized into nonexistence.

    p.2-5: Inheritance of Class Options should come after the class
    precedence list section.''

    Ok. Kathy, can you do this?

    ``p.2-9, Redefining Classes, Third paragraph:  The CLOS spec says when
    slots aren't updated, X3J13 says when they are updated.  X3J13 doesn't
    mention anything about changes to ordering.  [How come this spec.
    doesn't say exactly the same thing as 88-002R here? --Moon]''

    I don't quite get this. I have the Feb 14 X3J13 draft here (my March 21
    draft is at work), and both the Feb 14 draft and 88-002R say this:

    ``Note that redefining a class may cause slots to be added or deleted.
    If a class is redefined in a way that changes the set of local slots
    accessible in instances, the instances will be updated.  It is
    implementation dependent whether instances are updated if a class is
    redefined in a way that does not change the set of local slots
    accessible in instances.''

    On the other hand, this paragraph appears on page 2-47 not 2-9, so it's
    hard to tell whether we are all talking about the same thing.

I don't have the thing here, but I think we're not al talking about the same
thing and on p.2-9 there was some text that needs to be made consistent
with the other parts of the document.

    ``In several of these paragraphs, references are made to the "old class"
    and the "new class".  It would be clearer to say "the old class
    definition" and "the new class definition" since it's still the same
    class object after the redefinition.''

    I think there is ample distinction made in the first paragraph of this section
    between the class object and the class. This section and others like it
    are difficult enough to understand without extra words like ``definition''
    being thrown in where that doesn't really aid understanding. Consider how
    you would rewrite this using ``definition'':

    ``The value of a slot that is specified as shared both in the old class
    and in the new class is retained.  If such a shared slot was unbound
    in the old class, it will be unbound in the new class.  Slots that
    were local in the old class and that are shared in the new class are
    initialized.  Newly added shared slots are initialized.''

    Here is a try:

    ``The value of a slot that is specified as shared both by the old
    class definition and by the new class definition is retained.  If such
    a shared slot was unbound in the class specified by the old
    definition, it will be unbound in the class specified by the new
    definition.  Slots that were specified as local by the old class
    definition and that are specified as shared by the new class are
    initialized.  Newly added shared slots are initialized.''

    I'm not sure that this slightly more precise paragraph says anything
    more than the original, and it is a lot harder to understand.

It just seems longer to me, and not harder to understand for any
reason other than the extra length.  However I really have no
opinion on this issue.  BTW I was unaware that there was _any_
distinction between "the class object" and "the class."

    Finally, the classes might be EQ, but they are not equal as classes.
    (1 2 3) and (a b c d e) might be EQ, but one is the old list and the
    other is the new list, if one was derived from the other via
    replacement.

Well, as soon as time-varying objects are brought into the picture,
equality becomes ten times as hard to talk about.