You can use the #. reader macro to get symbolic case labels in Common Lisp. Example:

(defconstant +foo+ 1)
(defconstant +bar+ 2)

(defun quux (x)
  (ecase x
    (#.+foo+ "Foo!")
    (#.+bar+ "Bar.")))

This works in all implementations I tried in the REPL or when loading it from a file.

When using compile-file (or building via asdf), behavior differs, though. In SBCL it works, but CCL reports an error: Error: Unbound variable: +FOO+

Wrapping the defconstants in eval-when allows compiling in both SBCL and Clozure CL:

(eval-when (:compile-toplevel :load-toplevel :execute)
  (defconstant +foo+ 1)
  (defconstant +bar+ 2))

My question is whether the behavior of CCL conforms to the standard; that is, does portable code require using eval-when in this scenario? I've read the sections on defconstant and compilation in CLTL2, and the remarks about the special behavior of defconstant in compiled code indicate that it should work without eval-when. But I'm interested in the language-lawyer answer.

You can use the #. reader macro to get symbolic case labels in Common Lisp. Example:

(defconstant +foo+ 1)
(defconstant +bar+ 2)

(defun quux (x)
  (ecase x
    (#.+foo+ "Foo!")
    (#.+bar+ "Bar.")))

This works in all implementations I tried in the REPL or when loading it from a file.

When using compile-file (or building via asdf), behavior differs, though. In SBCL it works, but CCL reports an error: Error: Unbound variable: +FOO+

Wrapping the defconstants in eval-when allows compiling in both SBCL and Clozure CL:

(eval-when (:compile-toplevel :load-toplevel :execute)
  (defconstant +foo+ 1)
  (defconstant +bar+ 2))

My question is whether the behavior of CCL conforms to the standard; that is, does portable code require using eval-when in this scenario? I've read the sections on defconstant and compilation in CLTL2, and the remarks about the special behavior of defconstant in compiled code indicate that it should work without eval-when. But I'm interested in the language-lawyer answer.

• common-lisp
• sbcl
• ccl
• clozure-cl

2 Answers 2

I am not going to look at CLTL2 because it's outside of the standard, even if some of what it prescribes may usually be found implemented in practice. First, you are using COMPILE-FILE which brings up the following rule from 3.2.3 File Compilation:

Normally, the top level forms appearing in a file compiled with compile-file are evaluated only when the resulting compiled file is loaded, and not when the file is compiled. However, it is typically the case that some forms in the file need to be evaluated at compile time so the remainder of the file can be read and compiled correctly.

You are using reader macros, which means you are trying to evaluate forms at read time. Your ecase form, when being read, must have access to the constants defined earlier, which means that the past forms in the file must have been both compiled and evaluated (the compile-time-too mode of compile-file). If defconstant was required to be evaluated at compile-time too (in the evaluation environment), that could work. However, the implementation may choose to evaluate the constant at a later time, according to DEFCONSTANT:

If a defconstant form appears as a top level form, the compiler must recognize that name names a constant variable. An implementation may choose to evaluate the value-form at compile time, load time, or both.

--- edit

Copying my comment below: a minimal compiler could work without constant-folding and only emit instructions that read from a constant address. In that case it only needs to know that the name refers to a constant, but doesn't know what its value is. That is IMO the distinction that the paragraph is making and saying "unbound variable" is consistent with a constant being declared but not yet initialized.

Note also that in this particular case, the compiler environment is updated, you can have a later form that is (eval-when (:compile-toplevel) (print +foo+)) that is aware of the value bound to +FOO+, but as indicated by the backtrace, the environment in which the form is read is distinct from the compiler environment and isn't aware yet of the value bound to +FOO+. Using bash expansion as an analogy:

$ eval "X=3; Y=${X}"

The above is a bit similar, the expansion has not yet access to the value that will eventually be associated with X.

Yes, CCL is conforming. The standard says

An implementation may choose to evaluate the value-form at compile time, load time, or both.

Therefore if you want to use the value of the constant at read time, which is normally before load time which is the latest time that the constant can have a value, you must ensure that both the compile and load times of the defconstant form are before the read time of the place you want to use it. That's what eval-when is for.

In fact the situation is stronger than this: a program which doesn't use eval-when when the defconstant is in the same file as the read time use of the constant variable is not conforming (may not be compilable), although a conforming implementation may process it correctly. So SBCL is allowed to do what it does, but CCL is also allowed to reject your program.