[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: undeclared variables
- To: email@example.com
- Subject: Re: undeclared variables
- From: firstname.lastname@example.org (Bill St. Clair)
- Date: Fri, 18 Sep 1992 15:45:35 -0500
- Cc: "Mark A. Tapia" <email@example.com>, info-mcl
> in the following piece of code,
>why am I getting the undeclared free variable warnings?
> (setq x t
> y t
> z nil)
>? (and x (or z y))
>;Compiler warnings :
>; Undeclared free variable Z, in an anonymous lambda form.
>; Undeclared free variable Y, in an anonymous lambda form.
Mark was correct in his explanation of how to prevent the problem.
I want to say a little about why it works the way it does.
EVAL calls CCL::CHEAP-EVAL-IN-ENVIRONMENT, which knows how to evaluate
some of the simple Common Lisp forms and calls the compiler (or the
full-blown evaluator if *compile-definitions* is false) to handle
forms it doesn't understand.
CCL::CHEAP-EVAL-IN-ENVIRONMENT knows how to evaluate symbols and
how to do macroexpansions. If it sees a form which the compiler handles
specially, however, it lets the compiler do the work. It just happens
that AND is marked as not specially handled by the compiler whereas
or IS specially handled. Hence, CHEAP-EVAL-IN-ENVIRONMENT macroexpands
the AND form, but calls the compiler for the OR form. The compiler warns
about the undeclared variables: Z and Y.
The really correct way to do this would be for CHEAP-EVAL-IN-ENVIRONMENT
to also warn about undeclared global variables. What I'd prefer would be
a *warn-about-undeclared-specials* flag which defaults to true and is
bound to NIL while evaluating a form from the Listener. It's probably not
hard to write a handler that will implement this and install it by
wrapping it around MCL's normal toplevel loop. Anyone motivated?