On Wed, 2007-05-16 at 01:22 +0100, Luis Oliveira wrote:

"Lawrence Nakamura" ln@imap.cc writes:

...

In the defcenum macro, the values don't seem to be evaluated. Is this behavior a bug or a feature?

I'm not sure. What's your use case? Would #. work there?

I just got another report about this as well. For now, I agree that #. is a serviceable workaround:

(defcenum foo (:bar #.(ash 1 0)))

If I may ramble a bit on this, I'm inclined to say that we should evaluate it, but we need to think about at what time the evaluation is done:

- If we evaluate the value at compile-time, then we leave the door open for optimizing enum values to constants (I don't think we do anything like this yet, do we?)

The downside to this approach is the user will need to supply the appropriate EVAL-WHENs around variable definitions that are to be used as enumeration values.

- If we don't care about the enum value at compile-time, it might be better to use LOAD-TIME-VALUE to evaluate the enum's value in the expansion of DEFCENUM.

I suspect this could be useful for some users, such as copying CLISP fasl files from one platform to another. If they were evaluated at compile-time as above, they'd get hardcoded into the fasl file.

- I don't think we can change the EVAL-WHEN in the expansion of DEFCENUM to create the type at load-time, because then the type won't be visible to compiler macros in the same translation unit.

- Of course, there's the possibility of just using EVAL in the expansion, but I don't think there are any real advantages there.

Any thoughts?

James