State of Affairs

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

I've completed the major pass on chapter 1 that Gregor's comments
required. The result so cleaned it up that I made a second major
pass and I now believe chapter 1 to be very close to complete.

The state of affairs with chapter 2 now greatly concerns me.
To illustrate this, let me comment on one of the comments that Moon
made about the selected function pages that we put out for comment.

Regarding CHANGE-CLASS Moon writes:

``change-class: the second remarks paragraph is a remark about the
generic function as a whole, and has nothing to do with the specific
method to which it is attached.''

That remarks paragraph states:

``This method on {\bf change-class} has several semantic difficulties.
First, it performs a destructive operation that can be invoked within a
method on an instance that was used to select that method. When multiple
methods are involved because methods are being combined,
the methods currently executing or about to be executed
may no longer be applicable.  Second, some implementations might use compiler
optimizations of slot access, and when the class of an instance is
changed the assumptions the compiler made might be violated.
This implies that a programmer must not use this method on {\bf
change-class} inside a method if any methods for that generic function 
access any slots, or else the results are undefined.''

The semantic problem is that the class of the instance is altered while
the generic function is operating.  One can argue that this is a change of
identity in some semantic domain.  The fact that this is related to a
``destructive operation'' depends on the representation of the instance,
which depends on its metaclass which depends on the fact that the instance
is an instance of standard-object, because its class is standard-class.
This appears to be something specific to this method or constellation of
methods. The same reasoning holds for the mention of the compiler messing
around with optimizations of slot access - I've heard some metaclasses
say ``what's a slot?''

Therefore, the semantic difficulty is best expressed in both places:

There is a semantic difficulty with the generic function because we choose
to specify that whatever else it does it alters the class of an instance.
And this can happen in the middle of a method combination that might
involve running those other methods on a now-non-applicable instance.

This method happens to compound the problem by messing with the
representation in some way, invalidating the compiler's assumptions.

Therefore, the comment Moon makes serves to raise a much harder issue of
how close to the bone we cut our distinctions.

Notice that LGD and I gave this some amount of thought, because the
Purpose entry for the generic function states that the generic function
changes the class, while the one for this main method talks about the
destructiveness of the operation.

What has to be pointed out is that even if we choose to back out of
any changes made to the format of chapter 2 in the last 4 days (this amounts
to little or no work), we now know that the wording that we have been using
is very imprecise with respect to a level of precision to which we could
rationally aspire. This Remark, if left in a version of chapter 2 with
the older format, mixes up the general activities and meaning of a very
abstract entity (a generic function) with the activities and meaning of
a specific method.

Let me state at this point that LGD and I have neither interest nor motivation
to want to take a shot at sorting this out by ourselves. And I can easily
see this group, even in a face-to-face meeting, arguing for weeks about
the wording and exact breakdown of what is said when and where.

What's worse, our selection procedure was to pick the first 4 or 5
function pages in chapter 2 to try, not the hardest 4 or 5, and I'm not
sure that we could totally resolve CHANGE-CLASS in under 4 days of
discussion at the current bandwidth.

Therefore, I leave it to you folks to decide how to proceed.

			-rpg-