[Openmcl-devel] Compiler warningsy
Gary Byers
gb at clozure.com
Sun Oct 18 05:18:54 PDT 2009
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".
>
> ? (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.
> 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.
>
> 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
>
>
>
>
>
>
>
More information about the Openmcl-devel
mailing list