**DRAFT** issue CLOS-MACRO-COMPILATION, version 2

[David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>]

I would go with MINIMAL for now.  It leaves a lot of behavior
unspecified, and we can fill in that behavior later when we
add metaobjects to the standard.

Relatively small comments:

The compiler should be allowed to warn, but not error, about
failures of lambda-list congruence between methods or generic
functions in the file being compiled and methods or generic
functions in the Lisp doing the compilation.  When you say
the compiler may not "perform tests" between these, it's not
clear whether you mean to rule out only errors or both errors
and warnings.

The only thing here that might be overspecification is allowing a
DEFINE-METHOD-COMBINATION to be used later in the same compilation.
However, I see no real harm in that, and it would often be 
convenient for programmers, so leave it.  But if someone else
moves to remove it, I will not object.

Evaluation of the form in EQL parameter specializer names in DEFMETHOD
needs to be covered.  I think this is tied up with the pending compiler
committee issue DEFCONSTANT-VALUE (whose version 2 writeup I don't like,
it's too messy).  The choices seem to be to require the form in an EQL
parameter specializer name to be evaluable at compile time, to require
it to depend only on constants defined in the file being compiled, or to
permit its evaluation to be deferred until load time.  I don't like the
first choice.  I think for both DEFCONSTANT and EQL the semantics should
be as if it were never evaluated until load time, with the compiler
allowed to evaluate it sooner only if it can prove that that does not
change the semantics.  I'd be happier if the mechanism the compiler
uses to do this tentative evaluation were made available to the user,
but that can be deferred until metaobjects.