The compilation ordering imposed by SETF methods

[lgm%ihlpf.uucp@att.att.com]

This topic has general applicability to Lisp, but I have a
particular question in regard to CLOS, so please bear with me.

I am interested in the issue of *independent compilation* - i.e.,
Lisp systems' support for the compiling and loading of different
software units (functions, files, or CLOS classes) independently of
each other.  Generally, of course, functions have this property and
macros don't.  That is, a call to a function not yet defined
produces at most a warning; a use of a macro not yet defined
produces incorrect code (a call to a function instead of a use of
the macro).  Thus, in a many-person (e.g., department-size)
project, macros as interfaces can lead to troublesome
interdependencies unless they are confined to a "global
header file" loaded before anything else is compiled, and
any modifications to the macros maintain upward-compatibility from
previous usage.

The interface to a CLOS class is made up primarily of functions:
everything from MAKE-INSTANCE to applicable methods to slot
readers.  One exception, however, is SETF methods (including the
SETF method created through use of the :ACCESSOR slot option).
Because SETF is a macro, most Lisp systems refuse to compile a use of
SETF unless a corresponding setf-method has already been defined.
Such a restriction forces a compilation ordering on the caller and
called methods.  The only resolution of the interdependency seems
to be to create a "global header file" of DEFGENERICs like

	(defgeneric (setf the-slot) (right-hand-side self))

Does anyone have a better resolution of the SETF ordering problem?
Does anyone know of any other ordering problems (with or without
solutions!) in a many-person CLOS-based software project?  Does
anyone else worry about these issues?  For example, I have heard
that the ANSI Common Lisp committee is doing a few things to "clean
up" SETF.  Have they considered the ordering problem in regular Lisp,
especially with respect to SETF?

In fact, is there an ANSI Common Lisp mailing list?  I'd like to keep
up to date on any plans for modifications to Common Lisp.


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