[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: issue CLOS-MACRO-COMPILATION, version 1
- To: sandra%defun@cs.utah.edu (Sandra J Loosemore)
- Subject: Re: issue CLOS-MACRO-COMPILATION, version 1
- From: David N Gray <Gray@DSG.csc.ti.com>
- Date: Fri, 10 Mar 89 18:06:53 CST
- Cc: cl-compiler@sail.stanford.edu, common-lisp-object-system@sail.stanford.edu
- In-reply-to: Msg of Fri, 10 Mar 89 13:56:05 MST from sandra%defun@cs.utah.edu (Sandra J Loosemore)
- Sender: GRAY@Kelvin.csc.ti.com
> Proposal CLOS-MACRO-COMPILATION:MINIMAL:
...
> DEFMETHOD:
>
> * The method is not callable at compile-time. If there is a generic
> function with the same name at compile-time, compiling a DEFMETHOD
> will not add the method to that generic function.
>
> [This also seems to imply that tests for existence of the generic
> function, lambda-list congruence, etc. must not happen until
> load time.]
No, an implementation should be permitted to check for lambda-list
congruence between methods defined in the same file; this doesn't
require any reference to the resident generic function definition. If
the file doesn't include a DEFGENERIC, then the first DEFMETHOD defines
the compile-time generic function attributes, and subsequent methods can
be checked against that.
> DEFINE-METHOD-COMBINATION:
>
> * The method combination can be used in a subsequent DEFGENERIC. If it
> is referenced, the body of a long form of method combination must be
> evaluable at compile-time.
But if methods are not installed at compile time and generic functions
are not callable at compile time, then I don't think there is any
situation in which the method combination body could be executed at
compile-time.