[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
DEFMETHOD compile-time processing
- To: firstname.lastname@example.org
- Subject: DEFMETHOD compile-time processing
- From: Patrick Dussud <email@example.com>
- Date: Wed, 25 Jan 89 08:31:05 PST
- Cc: Common-Lisp-Object-System@SAIL.Stanford.edu, CL-Compiler@SAIL.Stanford.edu
- In-reply-to: Sandra J Loosemore's message of Tue, 24 Jan 89 18:43:21 MST <8901250143.AA20013@defun.utah.edu>
From: firstname.lastname@example.org (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
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
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
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.