[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Issue: EVAL-WHEN-NON-TOP-LEVEL (Version 5)
- To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
- Subject: Re: Issue: EVAL-WHEN-NON-TOP-LEVEL (Version 5)
- From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
- Date: Thu, 16 Feb 89 10:09:28 MST
- Cc: sandra%defun@cs.utah.edu, CL-Compiler@SAIL.Stanford.EDU, Moon@STONY-BROOK.SCRC.Symbolics.COM
- In-reply-to: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>, Mon, 13 Feb 89 13:39 EST
I'm aware that the nesting behavior in your new proposal is the same
as what is described in CLtL. Some people, however, have said that
they think the behavior described in CLtL is "broken". If those
people are willing to stop complaining about it, then I am too. But I
think that the writeup should at least make some mention of the
problem, even if it doesn't propose to fix it.
For current practice, as far as I can make out neither KCL nor Lucid
will make macro definitions available to the compiler when they are
wrapped inside an (EVAL-WHEN (LOAD) ...). (Neither of these
implementations uses EVAL-WHEN in the expansion of DEFMACRO.)
As for why one would want to suppress the compile-time magic of
defining macros: I've mostly run into the problem in cross-compilation
situations. DEFCONSTANT is probably more of a problem than DEFMACRO
in this respect. I agree that the situation is fairly rare, though.
Moving on to one other aspect of the new proposal, does anybody have
any comments on changing the meaning of the EVAL situation from "in
the interpreter" to "at execution time"? This does seem to solve the
problem of what to do in compiled-only implementations, at least.
-Sandra
-------