[Openmcl-devel] Compiler warningsy

[Taoufik Dachraoui]

On Oct 18, 2009, at 2:18 PM, Gary Byers wrote:

>
>
> On Sun, 18 Oct 2009, Taoufik Dachraoui wrote:
>
>> 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 doesn't "create variables"; it's a macro that expands into code
> that assigns values to "places".
But if there were no place it will create one. There were no place for  
x before setf and after
setf we have a place for x; and thats what i meant by setf creates a  
variable x. Somehow
after setf we have a place for x and it is not dynamic and it is not  
lexical; It behaves like a
lexical variable unless you declare it special.

>
>> ? (setf x 1)
>
> A perfectly reasonable way of determining the value of that (or any  
> other)
> toplevel expression is to compile a function whose definition is that
> expression and call that function.  CCL's EVAL function handles some  
> simple
> forms via other means (and this SETF is one of those simple cases).   
> Had CCL's
> EVAL function chosen to use the compiler:
>
> ? (funcall (compile nil `(lambda () (setf x 1))))
> ;Compiler warnings :
> ;   In an anonymous lambda form: Undeclared free variable X
>
> the compiler would have warned about X, which is not a special  
> variable,
> not lexically bound, and not a constant.  (It's not a symbol-macro  
> either,
> but it's probably wise for you to ignore that for now.)
>
> When CCL's EVAL handles the SETF form above, it -could- notice these  
> things
> about x and warn about them, but it happens not to, as others may  
> have noted
> and as I've said at least twice already in the last day or two.  As  
> I've noted at least twice already, there isn't a good reason for  
> this inconsistency.
>
> All you are seeing in the cases you cite as examples is different  
> warning
> behavior between builtin EVAL behavior and the CCL compiler.  In all  
> cases,
> references to X are anomalous; whether warnings are or are not  
> generated
> is just a case of inconsistent warning behavior between the built-in  
> evaluaator
> and the compiler.
>
> The different behaviors do not mean anything else, and they  
> certainly don't
> mean what you imagine they do.
>
Forget about warnings, I am talking about the seeable behavior of SETF  
and THE operators.
Before SETF there were no place for x, and after SETF there is a place  
and it is not
lexical nor dynamic. And the THE operator is not compliant with CLHS.

>> 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.
>
> People have been explaining this to you for a few days now.  At some  
> point,
> it'd probably be worth it for you to accept what they're saying and  
> try to
> understand it, since whatever it is that you're doing instead of  
> that doesn't
> seem to work very well.
>
I understand, to some level, how it is implemented now after their  
explanations and I
thank you all for that. But what I am saying is about compliance with  
CLHS.

>> 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
>>

Kind regards
Taoufi