[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
DEFMETHOD compile-time processing
- To: Gray@DSG.csc.ti.com
- Subject: DEFMETHOD compile-time processing
- From: Patrick Dussud <firstname.lastname@example.org>
- Date: Tue, 24 Jan 89 09:19:45 PST
- Cc: Common-Lisp-Object-System@SAIL.Stanford.edu, CL-Compiler@SAIL.Stanford.edu
- In-reply-to: David N Gray's message of Mon, 23 Jan 89 11:15:30 CST <2810567730-15432385@Kelvin>
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
"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
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.
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.