[Openmcl-devel] Compiler warnings

[Taoufik Dachraoui]

Also, I would like to insist on the fact that SETF creates a lexical  
variable (on behavior at least,
it is weird for me to say that because for me when I learned Common  
Lisp I was told that
there a daynamic and lexical variables).

The following example shows that SETF creates a lexical variable  
(because f always returns
the value of x as defined by SETF)

? (setf x 1)
1
? (defun f () (+ x 1))
;Compiler warnings :
;   In F: Undeclared free variable X
F
? (let ((x 5)) (f))
;Compiler warnings :
;   In an anonymous lambda form: Unused lexical variable X
2
? (defvar y 1)
Y
? (defun g () (+ 1 y))
G
? (let ((x 5) (y 10)) (values (f) (g)))
;Compiler warnings :
;   In an anonymous lambda form: Unused lexical variable X
2
11

If you do not agree please explain in more details so I learn and  
understand something new.

Taoufik

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

> Sorry but I have to insist.
>
> In the CL specs
>
> "the specifies that the values[1a] returned by form are of the types  
> specified by value-type.
> The consequences are undefined if any result is not of the declared  
> type."
>
> It is clear that (THE type expr)  specifies the the returned value  
> of expr is of type type.
>
> Again the example:
>
> ? (setf z 1)
> 1
> ? (the fixnum z)
> ;Compiler warnings :
> ;   In an anonymous lambda form: Undeclared free variable Z
> 1
> ? z
> 1
> ? (the fixnum 1)
> 1
> ?
>
> As you can see, after the SETF z has a value of 1 and (THE fixnum 1)  
> does not raise a
> warning but  (THE fixnum z) does, this means to me that the THE  
> operator does not
> merely uses the returned value of z but has something too say about  
> z, and this is wrong
> I believe.
>
> Taoufik
>
>
>
>
> On Oct 18, 2009, at 12:40 PM, Ron Garret wrote:
>
>>
>>
>> On Oct 18, 2009, at 3:28 AM, Taoufik Dachraoui wrote:
>>
>>> I am not talking about the warnings, warnings are sometimes  
>>> necessary, and I understand the
>>> difference between dynamic and lexical variables.
>>
>> But not, apparently, the difference between compile-time and run- 
>> time.
>>
>>> I am puzzled by the special operator THE as implemented in CCL.  
>>> Why the THE operator
>>> expects a special variable
>>
>> It doesn't.
>>
>>> and not simply specifies the value returned by the expression as
>>> described in the CLHS:
>>>
>>> again the example I gave shows the awkwardness:
>>>
>>> ? (setf x 3)
>>> 3
>>> ? (the fixnum x)
>>> ;Compiler warnings :
>>> ;   In an anonymous lambda form: Undeclared free variable X
>>> 3
>>> ? (defun f () x)
>>> ;Compiler warnings :
>>> ;   In F: Undeclared free variable X
>>> F
>>> ? (the fixnum (f))
>>>
>>> The last form shows that the THE operator did not care about the x  
>>> it just specified the
>>> value of the result without complaining, but if the expression  
>>> directly contain a non defined
>>> variable as in the first form, the THE operator raise a warning.
>>
>> This has nothing to do with THE.  This warning is generated by the  
>> compiler.  In CCL, most, but not all, expressions are compiled  
>> before they are run.  *Any* expression sufficiently complex to  
>> trigger a compilation will produce the warning:
>>
>> Welcome to Clozure Common Lisp Version 1.4-dev-r12726M-trunk   
>> (DarwinX8664)!
>> ? (setf x 1)
>> 1
>> ? (let ((y x)) y)
>> ;Compiler warnings :
>> ;   In an anonymous lambda form: Undeclared free variable X
>> 1
>> ? ((lambda () x))
>> ;Compiler warnings :
>> ;   In an anonymous lambda form: Undeclared free variable X
>> 1
>>
>> "THE" is a red-herring (except insofar as it is one of the forms  
>> that triggers a compilation rather than using the simple evaluator).
>>
>>> Also, two other things one again about the THE operator and one  
>>> about SETF.
>>>
>>> I would like to understand; what is the purpose of the THE  
>>> operator if it does not raise
>>> an error if the expression returns a value with a type different  
>>> from the specified one?
>>
>> It's to help the compiler produce more efficient code.
>>
>>> As you saw in the examples that I provided in my previous  
>>> submission, we see that CMUCL
>>> declares the variables defined by SETF as special (so dynamic),  
>>> unlike CCL the variables are not dynamic (but lexical, at least  
>>> they behave like that as I showed in the examples).
>>
>> No, you haven't, and they aren't.  See my earlier response to you  
>> in this thread.
>>
>> rg
>>
>>
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.clozure.com/pipermail/openmcl-devel/attachments/20091018/239eee4f/attachment.htm>