DEFMETHOD compile-time processing

[Patrick Dussud <dussud@lucid.com>]

   From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
   Date: Tue, 24 Jan 89 18:43:21 MST

   >     * 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
   macros. 


   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
   document. 

Even if we decide to take this stand, the problem won't be entirely solved.
Metaprogrammers won't be able to blindly get their paws on a method object,
and do something that will cause the method-function to be called. If the
method-function is a remote environment function, it may not be able to run in
the local environment. I consider the semantics of the macros and the
representation of remote environment objects being two distincts issues. My
objections were not directed at the semantics issue, but at the representation
issue. I expect that other CLOS members will give opinions on the semantics
issue. 

   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? 

That's right, all those macros create functional object, therefore are subject
to the ruling concerning macros in non null lexical environment.

Patrick.