[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Consider the following:
File foo contains:
(defconstant const ...)
File bar contains:
(defun zap (x)
... (reference const x) ...)
Now suppose that I compile file bar in an environment in which I have
already loaded foo. Thus the compiler will recognize that the
reference to const in zap is a reference of a constant.
In some implementations, the value of const will be substituted for
const. In others, const may be treated like any other special
But how about an implementation that does the following: It
substitutes a reference to a slot in the compiled function's "constant
vector" (i.e., the piece of data where most implementations store
constant values). BUT it does not init the slot at compile time (like
most implementations), instead, it generates code that will init. the
slot to the value that const has at load time!
Thus, if I loaded bar before loading foo, I will cause an error, since
const is undefined at the time bar is loaded.
My questions are: Is this a legal implemenation of defconstant? If
not, how does CLtL forbid it?
In my opinion, it is not legal CL. I base this on the fact that
defconstant, like defvar and defparameter, defines a variable (albeit
one which about which the compiler may make assumptions). And nowhere
in CLtL does it state that it is an error to load a piece of code that
conatains a reference of a variable that is unbound at load time. CLtL
only requires that the varibable have a value at the moment the
reference is evaluated.
The only argument in favor of considering such behavior legal would be
based on the statement "defconstant ... [asserts] that the value of
the variable NAME is fixed" One could argue that the value of the
variable at compile time was different from the value at load time
(i.e., the value UNBOUND), and thus the assertion has been
What do you think? By the way, thre does exist such an