[Openmcl-devel] no automatic (eval-when (:compile-toplevel ...) ...) around (declaim (special ...))?

Gary Byers gb at clozure.com
Thu Apr 30 16:08:30 UTC 2009



On Thu, 30 Apr 2009, Dorai Sitaram wrote:

> I was trying to compile-file a bunch of related files in sequence
> (from within a single PROGN say), and it does not seem like
> declaring a special variable *var* via (declaim (special *var*)) in
> an earlier file makes it visible at compile-time to a later file.
> I.e., I get an "Undeclared free variable *VAR*" diagnostic when the
> later file is compiled, if it does something like (let ((*var* ...)) 
> ...).

> Once I wrap the declaim inside an explicit eval-when, the diagnostic
> goes away, so it isn't a big deal, but then I don't see the point of
> (declaim (special *var*)) over a simple (defvar *var*).

> Is this correct, acceptable, or even desired behavior?

Section 3.2.3.1.1 of the spec discusses the processing of defining macros
and notes that:

"The compile-time side effects may cause information about the
definition to be stored differently than if the defining macro had
been processed in the `normal' way (either interpretively or by
loading the compiled file)."

"In particular, the information stored by the defining macros at
compile time might or might not be available to the interpreter
(either during or after compilation), or during subsequent calls to
the compiler."

So yes, it's correct and acceptable for the compile-time side-effects
of a defining macro to not pervasively and unconditionally modify
the execution environment, and the spec points out that it's not
correct to assume that those effects persist.

Whether it's desirable or not depends: sometimes it's desirable for
those side-effects to persist in the execution environment, and
sometimes it's important that they not do so.  CCL tries to limit
those side-effects to the compilation environment, since one can
always get the more pervasive behavior via an explicit EVAL-WHEN.

> The Clozure behavior in this case doesn't seem to be matched in
> other CLs, e.g. SBCL.

I have no idea how one would get the less pervasive behavior if
the implementation unconditionally side-effected the execution
environment.




More information about the Openmcl-devel mailing list