Compilation dependencies in CLOS

[lgm@ihlpf.att.com]

I am examining the issue of CLOS compilation dependencies.
One concern is with some redefinition dependencies stated or
implied in Steele's CLtL/2e.  Pages 686-687 state that the
compiler "may also assume that a class defined by DEFCLASS in the
compile-time environment will be defined in the run-time
environment in such a way as to have the same superclasses and
metaclass." Taken to its extreme, this seems to permit an
implementation to compile all methods on the assumption of a fixed
class inheritance graph, such that any modification of that graph
would require massive recompilation.  Except during specifically
requested "block compilations," I hope that commercial CLOS
vendors actually permit the arbitrary modification of superclass
lists (with recompilation of only the modified class definition
and nothing else).

Another concern of mine is with the last sentence on Page 777 of
CLtL/2e:  "Any accessors specified by WITH-ACCESSORS must already
have been defined before they are used."  But the use of an
accessor is simply an ordinary function call (for a read) or a
call to one of the new (SETF <accessor>) functions (for a write).
Function calls have always been independent of the function's
definition; and the new SETF rules described on Page 128
effectively make calls to (SETF <accessor>) functions independent
of their definition.  So why do we need any restriction on
WITH-ACCESSORS?  I could also ask why WITH-ACCESSORS can't have
the same slot-list shorthand that WITH-SLOTS permits, but that's
yet another question.

A third difficulty I have is with the use of undefined classes.
Consider a DEFCLASS which in its superclass list includes a name
not yet defined as a class; or a DEFMETHOD which has a parameter
specializer name that is not yet defined as a class.  Can/Must a
CLOS implementation permit such references to undefined classes?
If so, does such usage in effect create a "forward-referenced
class"?  What operations (e.g., FIND-CLASS) are legal on a
"forward-referenced class"?  When such a class is later defined
via DEFCLASS, are all previous references guaranteed to work
properly without recompilation?

The final question is one of efficiency.  Are typical
implementations going to penalize any of this independence?  In
other words, will I be offered two modes, a "development" mode
that supports compilation independence but generates poor code and
a "production" mode that generates efficient code but imposes
onerous compilation dependencies?

Unfortunately, I do not have a running version of the latest PCL,
so I would also be interested to know how well PCL in particular
deals with these concerns.


	Lawrence G. Mayka
	AT&T Bell Laboratories
	lgm@ihlpf.att.com

Standard disclaimer.