Kempf's Remarks

[Dick Gabriel <RPG@SAIL.STANFORD.EDU>]

Kempf makes some interesting remarks. I'm not sure I can answer
all of them, but Gregor and Moon can fill in the holes.

A. Redefining classes

1. I think that the big performance hit in double indirection
happens when the trampoline object that represents the identity
of the instance is on a different page from the storage for the
instance.

The issue of redefinition comes up whenever the programmer needs to
re-read a file of DEFCLASS's that are different. CLOS doesn't address,
yet, the issue of compiler declarations that static-ize the class
graph. Because there are ways of dealing with the issue of static
function linkages and reDEFUNition, there are ways of dealing
with this, also.

Thus, I think a ``sufficiently'' clever implementation can do ok,
but the question is how clever the implementor must be to produce this
implementation. It ought to be a topic of debate in a few weeks.

2. The section on class redefinition states that updating of instances
occurs in a lazy manner as instances are stumbled across. Therefore, there
is no need to keep sets containing them explicitly. Furthermore, 
the blocks of storage for the new instances are created lazily at this
same time.

3. When a method is applied to an instance, that instance is updated
if a class redefinition has been done. So methods on the old instance
apply to the new instance, unless the methods have been implicitly removed
during class redefinition.

I think the document states that WITH-SLOTS might become confused when
classes are redefined.

4. No comment on this example.

5. I agree we should think about the issues of compilation semantics.

B) Compilation Semantics

I agree we need to think about these things.

C)  Interaction between CLOS and CL ``THE'' and ``DECLARE''

I agree we have to think about this.

D) Particular Quibbles

Kempf writes:

``1) Pg. 1-5, paragraph 1. A reference to 87-003 (the metaobject chapter)
would probably be good here.''

When Chapter 3 is in good shape we need to have reasonable cross-references.
At the time that Chapters 1 and 2 were completed for X3J13, Chapter 3 
was not available. I felt that it would not be reasonable to put references
in existing text to text that did not exist and was not known to be
guaranteed to ever exist.

Kempf writes:

``2) Pg. 1-6, paragraph 6. There is no statement ... that a class cannot
[have] two slots [with] the same name.''

This needs to be clarfied to state that there can only be one slot of a given
name.

Kempf writes:

``3) pg 1-7 through 1-9. The description of slot options, as Moon has
stated, seems needlessly complex.''

I agree that we can simplify this. When writing this section, there was
not enough time to thoroughly understand the slot description inheritance
rules and to think of how to explain them. Once I understood it, I wrote
up a correct, but dull and excessive, explanation that was correct so
that people could argue about its reasonableness. I didn't think it
was reasonable, so I had little enthusiasm to explain it well.

Kempf writes:

``      "characteristics of that slot involve some combination of the several
        slot descriptions"

    I don't understand why it is necessary to have do this.''

I think the main reason is that people will want to have only the incremental
updates to slot descriptions in each class definition. The `intuitively'
desirable behavior requires some defaulting where inheritance might seem
to make sense. 

Kempf writes:

``  b) The description of valid values on the top of the page has some notational
     ambiguity....''

Oh dear, this means that my meta-syntactic notation wasn't clear. The idea
was to define a mathematical abstraction that represented the semantics
of slot description inheritance. The definition of this abstraction was
meant to clarify the nature of combined slot descriptions. C(j) and (:class j)
were parts of this mathematical abstraction and hence is not intended to
exist anywhere. The funny numbers that Kempf refers to are simply the
part of the abstraction that represents the information about the class 
with which a shared slot is shared.

Kempf continues:

``  c) At the bottom of the page, do you really want the default to be
     UNSUPPLIED? If so, in what package is this symbol? ''

Again, this is part of the abstraction. When the part of the abstraction
corresponding to the initform is defined to be UNSUPPLIED this means that
in the slot description the effect is as if the initform were not supplied.
No package to think about here, except, possibly, PLATO-HEAVEN.

Kempf writes:

``d) pg. 1-8. Middle bullet. Why use (AND T(1) .. T(n) )? Again, coming
     at this from the point of view that subclasses specialize behavior
     of supers, shouldn't the more specialized type prevail?''

I don't understand this. The effect of the combined slot description
is as if the class definition contained (...:type T) and objects stored
in that slot will be (in DEFSTRUCT terminology) of type (and t(1) ... t(n))
where t(i) is the ith class in the CPL. Therefore, the type of object
is the specialized one Kempf desires (I think).

Kempf writes:

``7) General comment on method combination. It is certainly clearer now
than in the original documents, but I wish the preciseness with
which the inheritence algorithm was specified could also be true
of method combination. ''

Moon (and Sonya) spent some effort cleaning this section up. Nevertheless,
I judged it needed more rewriting, but I could not muster the enthusiasm
or time to do it myself. I had a hard enough time making sense of the
originally confusing uses of the terms ``primary method,'' ``auxiliary
method,'' and ``unqualified method.''

			-rpg-