Hello.
I've compiled all my list functions using:
(compile 'foo)
But once I do compile my function I get quite a few warnings about free
references to undeclared variable *** assumed special.
My question is - Is there a way to suppress these warnings? They are
interfering with my output. Or even better yet - do you know why these
warnings have been issued and what can I do to prevent them ?
My code is still working perfectly, (and faster once compiled !)...
Any help would be much appreciated - either here in the newsgroup or privately
via e-mail:
········@uwaterloo.ca
Thanks in advance !!!
-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/rg_mkgrp.xp Create Your Own Free Member Forum
·······@my-dejanews.com writes:
< Hello.
<
< I've compiled all my list functions using:
< (compile 'foo)
<
< But once I do compile my function I get quite a few warnings about free
< references to undeclared variable *** assumed special.
<
< My question is - Is there a way to suppress these warnings? They are
< interfering with my output. Or even better yet - do you know why these
< warnings have been issued and what can I do to prevent them ?
You could try the macro with-compilation-unit, although I seriously
doubt it will help with undeclared variables.
I think that it may be better to look at the cause of the warnings.
If you posted some sample code that triggers the error I'm almost
certain that someone would be able to help.
Here is an example that should signal a similar warning.
(defun dotimes-expt (base power)
(setq result 1) ; the problem is this setq
(dotimes (count power result)
(setq result (* base result))))
When I call the function such as,
(dotimes-expt 3 5),
I'll get the correct result of 243. If I then type `result' into my
lisp, I'll get 243 again! This is because I used setq. If I instead
use `let' then I will not receive these warning upon compilation of
`dotimes-expt'.
(defun dotimes-expt (base power)
(let ((result 1)) ; temporarily bind RESULT to 1
(dotimes (count power result)
(setq result (* base result)))))
You can use setq after you bind the variable. In this case I `let'
RESULT have the value 1. Then the dotimes is called COUNT times, each
time assigning a new value (which is BASE * RESULT) to the variable
RESULT.
The book Lisp 3rd edition by Winston/Horne gives an excellent
discussion of this using what they called `gates' and `gatekeepers'.
You may want to get a copy as it will no doubt explain `let' and
`setq' much clearer than myself.
The compile may generate better code as a side effect of using `let'
instead of setq as well. Hope this eliminates some of those warnings.
In article <··········@bgtnsc03.worldnet.att.net>,
Steve Gonedes <········@worldnet.att.net> wrote:
....
>Here is an example that should signal a similar warning.
>
>(defun dotimes-expt (base power)
> (setq result 1) ; the problem is this setq
> (dotimes (count power result)
> (setq result (* base result))))
I "guess" the problem is the SETQ. The fact that the SETQ implicitly
creates a global variable that is...
Note that after this function invocation RESULT still "exists".
CL-USER 15 > (dotimes-expt 3 5 )
243
CL-USER 16 > result
243
If that is an intended "by-product" of the function then ignore the
"assumed special" warnings. However, often this not what most folks
wish to do. Hence, you will get warnings when your code does this.
>(defun dotimes-expt (base power)
> (let ((result 1)) ; temporarily bind RESULT to 1
> (dotimes (count power result)
> (setq result (* base result)))))
I'm not sure I would describe the above as "temporarily binding RESULT
to 1", but rather as "declare a variable RESULT whose initial value
is 1". I suppose it is temporary in that that value will soon be
changed by the code below that declaration. And that "result" will
not exist past the exit from the LET (in this context).
--
Lyman S. Taylor "Computers are too reliable to replace
(·····@cc.gatech.edu) humans effectively."
Commander Nathan Spring, "Starcops"
In article <···········@nnrp1.dejanews.com>, <·······@my-dejanews.com> wrote:
....
>
>But once I do compile my function I get quite a few warnings about free
>references to undeclared variable *** assumed special.
Hmm, I presume "***" is some indirect reference to several symbols.
In Common Lisp, there is a predefined global (special) symbol, ***, whose
use should cause no warnings about "assumed special". It is special.
I would _not_ recommend using it as a variable in a function though. :-)
>My question is - Is there a way to suppress these warnings? They are
>interfering with my output. Or even better yet - do you know why these
>warnings have been issued and what can I do to prevent them ?
"Assumed Special" essentially means "You are using some global variable
I haven't so far seen declared as being global, so I'll assume that you'll
get to that later, refer to this variable as a global, and proceed.".
Now if this really is suppose to be some global variable, you can
tell the environment that you "know" it is special. Therefore, you will
not get the warning message.
(defun some-fcn ( arg )
(declare (special some-global-var ) )
... body of your function .... )
DECLARE allows you to "talk to" the compiler about various issues. Since
it knows that you know it is special.... you'll get no warning.
If this really isn't suppose to be a global variable.... You need to
define it as a local variable.
(defun some-fcn ( arg )
(let ( (some-local-var initial-value) )
... body of your function ... ) )
P.S. Technically, "special" has to do with dynamic scoping and LET allows
you to defined lexically scoped variables. However, in the above
context global versus local is probably a better way to describe the
problem and solution.
--
Lyman S. Taylor "Computers are too reliable to replace
(·····@cc.gatech.edu) humans effectively."
Commander Nathan Spring, "Starcops"