Interpreter messages inside a PROGV

[David Kieras <kieras@engin.umich.edu>]

I have a problem with some interpreter warnings that intrude into my program
output:

Interpreter warnings :
;   Undeclared free variable ^R-CLT, in an anonymous lambda form.
;   Undeclared free variable ?R-CLT, in an anonymous lambda form.

The code appears to work correctly, so the only problem is that these
messages make a mess of the output, being very voluminous.

Where these are coming from:

I have a production-system interpreter.  The rule actions are
interpreted by code in a PROGV that is handed a list of variable
names and variable bindings computed elsewhere.  These names and
bindings are to be in effect during the action execution. The
code inside the PROGV gets each action, which is a LISP form, and
EVALs it.  The action form is normally required by the rest of 
the code to return NIL.

The message appears when one of the actions eval'd is a macro, such as:

(DEFMACRO FRF-SM-PM (IN OUT)
    `(LET () (SETQ ,OUT (FETCH-REF-FORM ,IN (QUOTE SM))) NIL)
)

So for example, the context is something like this:
(PROGV SYMBOL-LIST VALUE-LIST
...
   (DOLIST (ACTION ACTION-LIST)
...   (EVAL ACTION)

where SYMBOL-LIST would be (^R-CLT ?R-CLT),  VALUE-LIST would be (NIL FOO) 
and ACTION would be (FRF-SM-PM ^R-CLT ?R-CLT)

I believe the unhappy interpreter here is the one behind EVAL.  I
thought that the scoping and binding provided by the PROGV
function (which is intended for such applications) would have
kept the LISP interpreter  happy - no problems with the exact
same code in Franz Allegro CL. 

Can anyone:

1. Tell me how to shut off the message, at least? Run time is critical, so
if there isn't a flag variable to do this, I'll have to do something else.

2. Explain why MCL is unhappy with my PROGV variables? I thought PROGV in effect
made the variables special, and so I would expect that EVAL would treat them
as if they were special, so the message is confusing.  Such variables are used
as arguments to other action functions interfaced with macros, so the only distinctive
thing here might be that the outermost layer of the macro is a LET.  (Is this
where the anonymous lambda form is coming from?)

3. Based on #2, if #1 can't be done, is there a workaround?  It is important to be 
able to use macros in this context, so getting rid of them is not a good solution.
Using APPLY instead of EVAL won't handle the macros.

Note that it is important that the binding be lost outside of the PROGV, so 
solutions that declare the variables top-level special won't work either.
Perhaps I should proclaim the variables special when their names are computed?  I 
thought PROGV in effect did this.  But how long would the proclamation take (run time
is critical), and would it have the desired effect inside a PROGV?

Thanks!