[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


> Date: Wed, 15 Mar 89 21:38:06 CST
> From: alarson@src.honeywell.com (Aaron Larson)
> If we permit the compiler to signal warnings for functions where the
> compile-time environment signature is different from the function call
> being compiled, why do we prohibit it for generic functions?

I believe there are two different (although related) issues being
addressed here.

consistency requirements for function calls.  It says the compiler
can't assume you're not going to redefine functions between compile
time and run time. 

The section from CLOS-MACRO-COMPILATION deals with consistency between
methods and generic functions.  If you read the description of
DEFMETHOD in CLOS chapter 2, it says that an error must be signalled
if there are problems with lambda-list congruency, or if the function
isn't a generic function, and maybe other things too that I can't
remember off the top of my head.  The intent of the wording in this
proposal was to clarify that this error signalling should happen at
run time and not compile time, since the methods don't actually get
"added" to the generic function until then, and the generic function
might have been redefined between compile time and run time. 

I agree this is confusing, though.  To make things worse, there's been
a suggestion for issue COMPILER-DIAGNOSTICS to allow the compiler to
signal a warning whenever it runs into a situation that it can
determine will cause an error to be signalled at run time.  I will
make another pass over all three proposals to make sure that they are
all mutually consistent in this respect.  Probably this will involve
moving the piece allowing warnings to be signalled from issue
that this is only a style warning, and fixing CLOS-MACRO-COMPILATION
to make it more clear that it's talking about the error signalling
required by the specification of DEFMETHOD in CLOS chapter 2 and not
random style warnings issued by the compiler.  Sound OK?