[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
re: EVAL-WHEN-NON-TOP-LEVEL
- To: IIM%ECLA@ECLC.USC.EDU, JonL@LUCID.COM, sandra%defun@CS.UTAH.EDU
- Subject: re: EVAL-WHEN-NON-TOP-LEVEL
- From: cperdue@Sun.COM (Cris Perdue)
- Date: Fri, 10 Feb 89 14:43:08 PST
- Cc: cl-compiler@SAIL.STANFORD.EDU, iim%ECLA@ECLC.USC.EDU
It seems to me that we really want two things out of EVAL-WHEN.
We want to be able to control compile- and load-time execution
of top level forms. Usually we want to be able to force something
to be defined or evaluated at compile time because it is needed
by some macro (or readmacro). Sometimes we want to control
compile- and load-time execution in other ways, too.
The second thing I claim we would really like to do with EVAL-WHEN
is to explain the behavior of forms such as defining macros in terms
of EVAL-WHEN (along with other Lisp code), for example explaining
DEFMACRO as similar to:
(eval-when (compile load eval)
(setf (macro-function ... ) ... ))
Are you compiler committee committee people in favor of these principles?
Notice that if you agree with these principles, you want
EVAL-WHEN to be defined in such a way that a lexically outer
EVAL-WHEN in effect overrides an inner one, so forms such as
(eval-when (compile)
(defmacro . . . ))
can mean "define the macro at compile-time only", and even
(eval-when (load)
(defmacro . . . ))
can mean "define the macro at load-time only".