bug#13813: 24.3.50; eval-and-compile in macro inhibits let-binding of variable

[David Engster]

Stefan Monnier writes:
> OK, you got me, I admit it,

Ha! No one can escape the EIEIO testsuite!

> I changed recently eval-and-compile to be (in effect)
> eval-during-load-and-compile.  I could turn it into a
> eval-during-eval-load-and-compile, but then your above test would run
> `mytestfun' twice (once with myflag=nil and then once with myflag=t)
> which I don't think would please everyone either.

Yep, my gut says that would create problems in EIEIO, too.

>> * Note the following:
>>   - It works if you just 'setq' the 'myflag' variable
>
> But not if you (progn (setq myflag t) (mytestmacro)). 

True. I didn't test that.

>> And yes, Stefan, this bug turned up in the EIEIO test suite. :-)
>
> Could you give some details, so we can better assess the best solution?

There is a flag called `eieio-error-unsupported-class-tags' which makes
`eieio-defclass' signal an error if a tag is unsupported. Since
`eieio-defclass' is the implementation of the `defclass' macro (wrapped
in `eval-and-comopile'), this flag has no effect if it is set in a
let-binding. To be specific, the test checks that this

(let ((eieio-error-unsupported-class-tags t))
        (defclass class-error ()
          ((error-slot :initarg :error-slot
                       :badslottag 1))
          "A class with a bad slot tag."))

is throwing an error.

> BTW, I think eval-and-compile should only be used to wrap definitions.
> Anything else is asking for trouble.

As I said: I can't wrap my head around that stuff. But the Emacs Lisp
manual specifically mentions this use case for `eval-and-compile'.

Out of curiosity I removed the `eval-and-compile' and everything seems
to work fine, which just adds to my confusion.

-David