Difficulty with lambda-list congruence, specifically &KEY

[lgm@ihlpf.att.com]

Our group is attempting to use CLOS to maintain plug-compatible,
upward-compatible interfaces between the components of a large,
complex, long-lived, evolving software system.  We are having
difficulty, however, with lambda-list congruence; specifically,
with the requirement that

	If any lambda-list mentions &REST or &KEY, each
	lambda-list must mention one or both of them.

This restriction means that if someone defines a method on a
generic function FUNC to take, say, a single (required) argument,
then no one else's later FUNC method can extend the FUNC interface
to accept additional (keyword) arguments; at least, not without
modifying the original FUNC method (which is not desirable from a
methodological point of view).

One (methodological) workaround is to dictate the inclusion of
&KEY in the lambda-list of every method of every publicly
advertised generic function.  This, however, is not possible for
automatically generated methods; in particular, slot accessors
(including readers and writers) take only required arguments.
Thus, either any publicly advertised generic function which counts
a slot accessor as one of its methods must be billed as
"nonextensible" in our terminology, or we must generate our own
accessors via DEFMETHOD (and thereby lose the benefit of any
accessor optimizations provided by the CLOS vendor).

Presumably we could use the meta-object protocol to define the
object system behavior we desire, but we're reluctant to take such
a step just yet.  Does anyone have any comments or ideas about our
difficulty?


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

Standard disclaimer.