[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: CLOS defining macros & compilation
- To: David N Gray <Gray@DSG.csc.ti.com>
- Subject: Re: CLOS defining macros & compilation
- From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
- Date: Thu, 23 Feb 89 17:05:35 MST
- Cc: sandra%defun@cs.utah.edu (Sandra J Loosemore), cl-compiler@sail.stanford.edu, common-lisp-object-system@sail.stanford.edu
- In-reply-to: David N Gray <Gray@DSG.csc.ti.com>, Thu, 23 Feb 89 17:42:47 CST
> Date: Thu, 23 Feb 89 17:42:47 CST
> From: David N Gray <Gray@DSG.csc.ti.com>
>
> > The descriptions of the expansions of the DEFCLASS, DEFMETHOD, and
> > DEFGENERIC macros in the meta-object protocol document assume that
> > lexical environment objects received with &ENVIRONMENT have indefinite
> > extent.
>
> Not really, unless you've noticed something I missed. Some objects in
> the environment (class definitions in particular) have an extent
> corresponding to the duration of the invocation of COMPILE-FILE, but the
> environment objects themselves, as received by a macro, do not need to
> be used outside the extent of that macro invocation.
We all seem to be converging on the idea that compile-time
side-effects from macros should be handled by having the macro expand
into an (EVAL-WHEN (COMPILE) ...). The MOP document specifies that
the environment object be passed as an argument to calls to FIND-CLASS
(or whatever) that happen as a compile-time side-effect. This implies
that the environment object would have to appear as a quoted constant
in the macro expansion. The proposal to give macro environment
objects dynamic scope would give them dynamic scope *within the macro
function*, which means it would not be legitimate for them to appear
at all in the expansion returned from the macro.
-Sandra
-------