DEFMETHOD compile-time processing

[Patrick Dussud <dussud@lucid.com>]

   Sender: GRAY@Kelvin.csc.ti.com
   Date: Mon, 23 Jan 89  11:15:30 CST
   From: David N Gray <Gray@DSG.csc.ti.com>

   In the Meta Object Protocol draft number 10 [89-003], on page 3-16 it says
   that 
     "At compile time: ... (5) The method function is computed by
     evaluating the special form (FUNCTION <lambda>) in the lexical
     environment of the DEFMETHOD.  ...  (7) The function ADD-METHOD is
     called ..."

   This isn't going to work.  You can install the function at load
   time in its lexical environment, or you can install it at compile time in
   the null lexical environment, but you can't evaluate something at
   compile-time in its run-time lexical environment.

you're right. 


The general issue that we try to address is that it should be possible for
some implementations to precompute a certain number of characteristic of CLOS
programs at compile-file time. These precomputation involve metaobjects
(looking at user class definitions, method object, generic functions) in a
state that should be close enough to their state when the program is loaded in
the remote environment. It is not generally possible to simulate the remote
environment as far as running remote code. Therefore, precomputation at
compile time, by doing metaprogramming on remote environment objects is more
restrictive that doing metaprogramming on local environment objects. However,
we don't want to introduce two distinct metaprogrammings. Chapter 3 is trying
to unify remote and local metaprogramming. All the side effect that are done
when the program is loaded, is simulated in the remote environment(
Add-method, ensure-class...). As Gray noticed, it does not always work. In
particular, we should acknowledge the difference as far as function objects
are concerned: Local function object can be executed, remote functions can
only be looked at.


   Possible remedies include:

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

    * Don't ever do a compile-time call to ADD-METHOD.  I haven't seen a
      reason why methods would need to be installed in the compile-time
      environment.  Apparently at least some information about generic
      function definitions needs to be remembered for use when invoking
      MAKE-METHOD-LAMBDA, but that wouldn't require being able to actually
      call the generic function at compile-time.

This will lead to two different metaprogramming styles. Note that this is more
or less what Flavors does. It is workable, but not pretty. Maybe a better
solution is to standardize a representation for objects in the remote
environment, and have the compile-file time expansion create them. Add-method
and such work as before, function slots don't always contain real functions.

Patrick.