Re: problem with macroexpansion in THE form?

On Thu, 31 Oct 2002, Timothy Moore wrote:

> Compiling the attached file gives the error
>   > Error: While compiling LEGAL-P :
>  >        Can't call macro function BREF
>
> This is excerpted from the recently released cl-reversi.
>
> Tim
>
>

I found some behavior that's even more bizarre:

? (compile-file "home:test.lisp")
> Error: While compiling LEGAL-P :
>        Can't call macro function BREF
> Type :POP to abort.
Type :? for other options.
1 >
? (load "home:test.lisp")
> Error: value #<SIMPLE-VECTOR 2> is not of the expected type LIST.
> While executing: NX1-CHECK-CALL-ARGS
> Type :POP to abort.
Type :? for other options.
1 >
?

A #<SIMPLE-VECTOR 2> is what's shoved into the function cell of a
symbol that has a global macro definition, so I suppose that both
of these behaviors have something to do with confusion about the
macro function BREF.

Both of these misbehaviors seem to go away if (OPTIMIZE (DEBUG 3))
is toned down a bit.  There were some cases reported a couple of
weeks ago where the compiler was confusing itself when (DEBUG 3)
was in effect (it expected some constant folding to take place, and
constant folding's suppressed when the DEBUG optimize quantity is 3.)

Something equally stupid seems to be happening here, though I'm not
yet sure what. Setting DEBUG to 2 or less allows your test file to
be loaded and compiled without major incident (legitimate-looking
warnings about WOULD-FLIP? being undefined.)

Obviously, the compiler shouldn't be so confused by (DEBUG 3) (it
might be a good idea for me to run with (DEBUG 3) in effect, at
least every once in a while.  Hmm ...)  As an editorial aside,
I wish that people would get in the habit of wrapping top-level
declamations inside (EVAL-WHEN (:COMPILE-TOPLEVEL :EXECUTE) ...)
forms, to avoid side-effecting the user's environment.

I'll try to find the real problem and post a patch here; in the
meantime, setting the DEBUG optimize quantity to 2 or less seems
to avoid the bug.