On Fri, Feb 23, 2001 at 10:57:06PM +0100, Arthur Lemmens wrote:
> Lispworks seems to have a different way of evaluating DEFCONSTANT-forms
> than SBCL/CMUCL. Apparently, in SBCL a DEFCONSTANT-form is evaluated
> immediately (at compile time), whereas in Lispworks it's evaluated
> later (at load time).
> Some SBCL-code depends on this early evaluation of DEFCONSTANT-forms.
> I think it shouldn't, because it's not guaranteed by the standard,
> which says: "An implementation may choose to evaluate the value-form
> at compile time, load time, or both."
> Fortunately, it seems to be easily solvable by wrapping
> (EVAL-WHEN :COMPILE-TOPLEVEL :LOAD-TOPLEVEL)
> around the offending forms. So far, I've found two places where this
> was necessary: the sequence of DEFENUMS in early-objdef.lisp where
> the second DEFENUM depends on a value defined in the DEFENUM before
> it, and the use of #.MAX-VOP-TN-REFS in vmdef.lisp.
I actually went out of my way to remove such EVAL-WHENs from the code,
because I thought that under the ANSI definition of DEFCONSTANT,
defconstant normally appears as a top level form, but it is meaningful
for it to appear as a non-top-level form. However, the compile-time
side effects described below only take place when defconstant appears
as a top level form.
The side effects of the execution of defconstant must be equivalent
to at least the side effects of the execution of the following code:
(setf (symbol-value 'name) initial-value)
(setf (documentation 'name 'variable) 'documentation)
the DEFCONSTANT would automatically take effect at compile time.
However, now that I read it again more skeptically, I think
the intended (though not especially clear) meaning is that "the
compile-time side effects" refers to this passage
If a defconstant form appears as a top level form, the compiler
must recognize that name names a constant variable.
So Lispworks' behavior is conforming, and I screwed up.:-(
OK, thanks for pointing out the problem. I'll add the EVAL-WHEN
wrappers to the places you mention above. You'll probably run across
quite a few more, because I remember deleting quite a few such
wrappers.:-( I can't think of any automated way to identify the ones
which really are needed, so I probably won't be motivated to hunt them
down myself, but if you can send me patches for them as you discover
them, I'll merge them.
William Harold Newman <william.newman@...>
PGP key fingerprint 85 CE 1C BA 79 8D 51 8C B9 25 FB EE E0 C3 E5 7C