[Openmcl-devel] Compiler warnings

[Raffael Cavallaro]

On Oct 18, 2009, at 12:05 PM, Taoufik Dachraoui wrote:

> so (+ x 1) will raise an error? it does not.

You are confusing 3 separate issues.

1. The standard does not *require* an implementation to do *anything*  
at all if you enter:
(setf x 1)
* If you do so, you are invoking undefined behavior.
* Stop doing that!

2. As Gary explained, CCL has *two* separate means of read-eval-print- 
loop (i.e., "Listener") evaluation.

example:
Welcome to Clozure Common Lisp Version 1.4-RC1-r13041M  (DarwinX8664)!
? (setf x 1)
1
? (+ x 1)
2
? (defun foo () (+ x 1))
;Compiler warnings :
;   In FOO: Undeclared free variable X
FOO
? (the double-float x)
;Compiler warnings :
;   In an anonymous lambda form: Undeclared free variable X
1
? (setf l (list 1 2 3))
(1 2 3)
? (push 5 l)
(5 1 2 3)
? (pop l)
;Compiler warnings :
;   In an anonymous lambda form: Undeclared free variable L (3  
references)
5


* One of these evaluators deals with simple expressions and does *not*  
invoke the compiler.
* If the compiler is *not* invoked, you will not get a warning.
* (+ x 1) is precisely this kind of simple expression.
* (+ x 1) does *not* cause the listener to invoke the compiler.
* Because (+ x 1) does *not* invoke the compiler, you get no warning  
for that form.
* (defun ... is the kind of more complicated form that does invoke the  
compiler.
* Because defun invokes the compiler, you get a warning for the defun  
form.
* The special form "the" invokes the compiler.
* Because "the" invokes the compiler you get a warning about x being  
undeclared.
* push is simple, no warning.
* pop invokes the compiler, so you get a warning. etc., etc.
* Not getting a warning doesn't mean your code is correct.



3. the special form "the" does not *require* the implementation to  
compare *anything*.
* "the" is a promise from the programmer.
* The promise is that the values yielded by the form are of the type  
specified by value type.
* An implementation is *not* required to signal an error or warning if  
this promise is broken.
* If this promise is broken the consequences are *undefined*
* The purpose of this promise is to allow an implementation to perform  
optimizations.
* The purpose of the special form "the" is *not* to check types for you.
* See check-type, assert, integerp, typep, etc. if you want to check  
types.

regards,

Ralph


Raffael Cavallaro
raffaelcavallaro at me.com





Raffael Cavallaro
raffaelcavallaro at me.com