[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: DEFMETHOD compile-time processing
- To: email@example.com
- Subject: Re: DEFMETHOD compile-time processing
- From: firstname.lastname@example.org (Sandra J Loosemore)
- Date: Tue, 24 Jan 89 18:43:21 MST
- Cc: jrose@Sun.COM (John Rose), Gray@DSG.csc.ti.com, Common-Lisp-Object-System@SAIL.STANFORD.EDU, CL-Compiler@SAIL.STANFORD.EDU
- In-reply-to: jrose@Sun.COM (John Rose), Tue, 24 Jan 89 14:15:11 PST
> * Do the compile-time call to ADD-METHOD only if the DEFMETHOD appears at
> top-level in a null lexical environment. This would be consistent with
> the treatment of DEFMACRO in proposal DEFINING-MACROS-NON-TOP-LEVEL.
> I don't consider this solution very satisfying, because it hides the problem.
> It is possible to represent functions for the remote environment by normal
> functions if the lexical environment is null, but still, they can't be
> executed. The problem remains.
This may not be very satisfying, but it is probably the only practical
solution. We have already had a lot of debate on this regarding
DEFMACRO and the other defining macros. A number of people raised
very strong objections to things like DEFMACRO causing the definition
to appear in the compile-time environment when buried inside a control
construct such as IF, or inside a DEFUN. I don't see any reason why
those same arguments are not just as applicable to the CLOS defining
It seems exceedingly unlikely that we compiler people would be able to
agree on any major reversal of the current proposal on issue
DEFINING-MACROS-NON-TOP-LEVEL in the 6 weeks or so we have remaining.
It also seems unlikely that you CLOS people are going to have the time
to work out any alternative semantics before then. Even if we did
have more time to work out alternatives, to me it seems that
restricting the compile-time magic to top-level situations is the
simplest solution for all of us. I don't see that it would affect
other parts of CLOS, and it would just allow us to take the description
of the compile-time behavior of DEFMETHOD directly from the MOP
Incidentally, I notice that the same considerations also affect
DEFCLASS and DEFGENERIC, both of which also want to create functional
objects. The MOP document doesn't seem to say anything about
DEFINE-METHOD-COMBINATION -- does anyone care to take a shot at
specifying its expansion? What does PCL do with it?