[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: DEFCONSTANT
- To: Walter van Roggen <Walter.VanRoggen%CMU-CS-A@SU-DSN>
- Subject: Re: DEFCONSTANT
- From: David A. Moon <Moon%SCRC-TENEX%MIT-MC@SU-DSN>
- Date: Wed, 08 Jun 1983 02:16:00 -0000
- Cc: common-lisp@su-ai
- In-reply-to: <07Jun83.182018.WV50@CMU-CS-A>
Date: 7 June 1983 1820-EDT (Tuesday)
From: Walter van Roggen <Walter.VanRoggen@CMU-CS-A> (C410WV50)
My idea of how DEFCONSTANT should work is similar to how DEFMACRO works.
Each DEFCONSTANT has an implied EVAL-WHEN (COMPILE LOAD EVAL) around it.
The issue here is that if you do that the value of the variable (constant)
gets changed in the Lisp in which you are running the compiler. This
certainly has to be documented, and could be a serious problem if you are
changing the value of a constant; suppose that the constant is something
that is needed in order to run the compiler or the reader or some other
low-level part of the Lisp system. For a concrete example, let's say
that it's the value of some field in the readtable that means "open
parenthesis." The only thing that is likely to save you is if all
references to the constant were actually open-coded, and no important
code is being run interpreted.
Those of you on the list who use cross-compilers, rather than compiling
in the Lisp environment in which you actually do your work, may not yet
appreciate all the ways you can get into trouble by having the act of
compiling a file (without loading it) change things in your Lisp world.
The choices I see are (in no particular order):
(1) DEFCONSTANT has an implied EVAL-WHEN (COMPILE LOAD EVAL) around it and
hence compiling anything with a DEFCONSTANT in it is just like loading it.
(2) A special constant-values table is set up by DEFCONSTANT and used by
the compiler in certain contexts that have to be carefully documented. The
important thing is that these constant values are not seen by the interpreter
and not seen by SYMBOL-VALUE. This is very similar to the way the compiler
treats macros, where MACROEXPAND searches the special table of macros that
have been seen during the compilation, but EVAL doesn't.
(3) DEFCONSTANTs are executed at compile time, but the values are restored
after the compilation completes (perhaps a dynamic binding is created by the
compiler when it sees a DEFCONSTANT, and the rest of the compilation runs
inside of that binding.)
(4) It is illegal to use a DEFCONSTANT in any but certain restricted
contexts, i.e. compiling references to it. If you want it to be
available to the interpreter during compilation, you must explicitly put
in an EVAL-WHEN and face the consequences to the environment in which
you are running the compiler. This is very similar to the way the
compiler treats defuns.
- References:
- Re: DEFCONSTANT
- From: Walter van Roggen <Walter.VanRoggen@CMU-CS-A> (C410WV50)