[cffi-devel] Re: defcenum values not evaluated

[James Bielman]

On Wed, 2007-05-16 at 01:22 +0100, Luis Oliveira wrote:
> "Lawrence Nakamura" <ln at 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