[Openmcl-devel] Compiler warnings

[Taoufik Dachraoui]

On Oct 18, 2009, at 5:46 PM, Ron Garret wrote:

>
> On Oct 18, 2009, at 4:26 AM, Taoufik Dachraoui wrote:
>
>>
>>>
>>>> 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.
>>>>
>>>
>>> No, this is not clear.  The only thing that is clear is just what  
>>> it says, that if the result is not of the declared type then the  
>>> consequences are undefined.  In CCL, for example:
>>>
>> Where do you see "not of the declared"?
>
> I believe you meant to ask: where do you see, "Not of the declared  
> TYPE".
>
>> Where do you see declared the in the specs?
>
> That is not a grammatically correct English sentence.  But I'm going  
> to guess that you meant to write: Where do you see "declared" in the  
> specs?
>
>> I see "values returned by form".
>
> That's in the first sentence.  Do you see that there is a second  
> sentence?  What are the last five words in that second sentence?
The issue is before "consequences are undefined".
My understanding of the specs for (THE TYPE FORM), one more time, is:
if the types of the returned values of FORM is consistant with TYPE  
then return the values
if not then "the consequences are undefined".

So in the first then; just before compiling (THE TYPE FORM), if FORM  
is a valid
expression and returns valid values, and if the values are of  
typeTYPE, it seems
not correct to raise a warning. So if the compiler raises a warning it  
is the problem of
the compiler, or it is the problem of the hack with SETF.

I understood what you explained and what Raffael put clearly. The  
issue is this, now that
I start to understand what is going on:

In the specs it is said that there is three kinds of variables:  
lexical, dynamic and constant,
and this is the problem, it seems that the hash on SETF creates a  
variable that is neither
lexical, nor dynamic nor constant (as show in previous submissions);  
So the question
is what is the rational behind this hack? why the hack did not create  
a dynamic variable as in CMUCL?



>
>> I believe that you missunderstood my concern,
>
> I'm pretty sure that's not the problem.
>
>> I may be wrong
>> and I may be right, clear, precise and correct answers may convince  
>> me.
>
> I've been as clear and precise as I know how to be.  You, however,  
> are being sloppy and lazy.  Did you read the paper that I pointed  
> you to?  No, you did not, because if you did you would know the  
> answers to some of the questions that you continue to ask.
>
>
>>>
>>>> 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.
>>>
>>> The exact same thing happens with other operators:
>>>
>> But do you agree that the z defined by SETF is a lexical variable?
>>
>
> No.  Z is not defined by SETF.  SETF doesn't define anything.  The  
> fact that CCL creates a place for you when you use SETF on a symbol  
> that has not been defined is a hack for the sake of convenience.  It  
> is not behavior that is defined by the standard.
>
>>> ? (setf x 1)
>>> 1
>>> ? ((lambda () x))
>>> ;Compiler warnings :
>>> ;   In an anonymous lambda form: Undeclared free variable X
>>> 1
>>> ? ((lambda () 1))
>>> 1
>>> ? (let ((y x)) y)
>>> ;Compiler warnings :
>>> ;   In an anonymous lambda form: Undeclared free variable X
>>> 1
>>> ? (let ((y 1)) y)
>>> 1
>>>
>>>
>>> It has nothing to do with THE, it has to do with whether a  
>>> reference to an undeclared free variable is passed to the  
>>> compiler, which is what generates these warnings.  Again: this has  
>>> nothing to do with THE -- except insofar as THE is one construct  
>>> (among many) that causes the compiler to be invoked.
>>>
>> It remains that the THE operator as implemented does not follow the  
>> specs.
>>
>
> No.  You are completely and utterly mistaken, and if you keep saying  
> that there is something wrong with "THE" then everyone will  
> eventually write you off as a troll and an idiot.
>
> Now go do your homework.
>
> rg
>

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