[Openmcl-devel] Compiler warnings

Taoufik Dachraoui taoufik.dachraoui at wanadoo.fr
Sun Oct 18 03:28:13 PDT 2009


I am not talking about the warnings, warnings are sometimes necessary,  
and I understand the
difference between dynamic and lexical variables.

I am puzzled by the special operator THE as implemented in CCL. Why  
the THE operator
expects a special variable 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.

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?

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

Taoufik

On Oct 18, 2009, at 7:38 AM, Gary Byers wrote:

>
>
>
> On Sun, 18 Oct 2009, Taoufik Dachraoui wrote:
>
>> Hi,
>>
>> I understand your explanation
>
> Including this part ?
>
>>> some forms typed into the REPL in CCL are handled by a very simple
>>> evaluator (which generally doesn't try to warn about this sort of
>>> thing); other forms are "evaluated" by compiling them and
>>> funcalling the resulting function, and the compiler generally does
>>> warn in this case.
>
> and this part ?
>
>>> I guess that I'd agree that things should be consistent (and the  
>>> simple
>>> evaluator should warn in the same cases that the compiler does).
>
>






More information about the Openmcl-devel mailing list