[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
- To: David A. Moon <Moon%SCRC-TENEX@MIT-MC>
- Subject: DEFCONSTANT
- From: Scott E. Fahlman <Fahlman@CMU-CS-C>
- Date: Wed, 08 Jun 1983 05:40:00 -0000
- Cc: common-lisp@su-ai
- In-reply-to: Msg of 7 Jun 1983 22:16-EDT from David A. Moon <Moon%SCRC-TENEX%MIT-MC at SU-DSN>
I guess I hadn't realized that there was a problem here. In Spice we
will probably spawn a second Lisp process whenever we want to compile a
file, though compilation of individual functions may be done within the
Lisp where we live. The latter operation tends not to hit DEFCONSTANTs.
I see no compelling reason why DEFCONSTANT values have to be available
to EVAL during a compilation, as long as we carefully document that. As
you say, if some such value must be available to a macro-expander
function, the user can put it in an explicit EVAL-WHEN COMPILE and take
his lumps. We might discover that the EVAL-WHEN form gets used so often
that we want to make it a standard macro with a different name, but I
bet it won't.
Note also that if a DEFCONSTANT contains something that the compiler
can't figure out at compile time, the compiler can just decline to
open-code references to this constant and can code the reference as a
normal special. The variable will get its value at load-time and
everythign will work correctly, though perhaps more slowly than the user
expected. Just how clever the compiler has to be is something that we
should leave up to the implementor. We do not want the white pages to
say that certain things must be open-coded. Even a quoted constant
might not want to be open-coded if it is a huge list and the user has
asked the compiler to optimize for size.
I think this is Moon's option 2, though it might be 4 -- I'm not sure I
grasp the difference. I could live with 1 (go ahead and clobber the
variable), since we don't compile where we live anyway. Option 3,
binding and unbinding the things a compilation might zap, strikes me as
too hard to implement.