[Openmcl-devel] Compiler warnings

[Ron Garret]

On Oct 20, 2009, at 11:55 AM, Daniel Weinreb wrote:

>
>
> Ron Garret wrote:
>>
>> Yes, but it is defensible behavior in light of what the spec says,  
>> namely (section 3.1.2.1.1):
>>
>> "If a form is a symbol, then it is either a symbol macro or a  
>> variable."
>>
>> and
>>
>> "If a form is a symbol that is not a symbol macro, then it is the  
>> name of a variable, .... There are three kinds of variables:  
>> lexical variables, dynamic variables, and constant variables."
>>
>> Since a "naked" symbol that is not bound and has not been DEF...ed  
>> is clearly not a lexical variable nor a constant variable, one  
>> could reasonably conclude that it must be a dynamic variable.
> I agree with all of this.  The only thing that (setq a 4)
> at top level can possibly mean, if it's not considered
> to be illegal, is to treat the symbol a as a dynamic variable.

That's clearly not true, because CCL neither signals an error nor  
treats the symbol as a dynamic variable.  So there's a constructive  
existence proof of a third option.

> But for it to automatically create a declaration, which will
> cause future uses of that symbol to be treated as
> dynamic variables even when inside a lexical scope
> that defines a variable named by that symbol, is
> a different thing, and isn't necessarily implied by
> the spec.

Actually, it is.  The spec provides an exhaustive enumeration of the  
kinds of variables that exist, and the kind of variable that you get  
when you do a top-level SETF in CCL is not among them.

>  So I don't agree that the CMUCL behavior
> is the only reasonable thing to do.

It is *if* you want to strictly adhere to the spec.  But if you want  
to say that strictly adhering to the spec is not a reasonable thing to  
do then I would be the first to agree with you.

>>
>> In fact, if one does not conclude this and simply does what CCL  
>> does (which I agree is reasonable behavior) then one is outside the  
>> spec.  You have a thing that acts like a variable, but does not act  
>> like any of the three kinds of variables that the spec defines.   
>> (Hence my claim earlier in this thread that a variable created this  
>> way is neither lexical nor dynamic).
> I'm not sure I'd interpret it that way.  The thing is a symbol,
> and it acts like a dynamic variable when used in this way.

No, it doesn't.  If it did then you could no longer make lexical  
closures using that symbol in the lambda list.  But you can.  So it  
isn't a dynamic variable according to the spec.

>
> But the bottom line is that there's no entirely satisfactory
> answer.

I think there are two satisfactory answers.  I think CCL's current  
behavior is satisfactory, notwithstanding that it is outside the  
standard.  I also have a proposed replacement implemented in portable  
CL that I've cited before.

What about these do you find unsatisfactory?

>>
>>> Symbols can be used for many things.
>>> Sometimes, symbols are interpreted as variables,
>>> depending on the context in which they are seen.
>>> There isn't quite anything that is best called "creating
>>> a variable".
>>
>> No, that's not true.  When you create a binding or use DEFVAR or  
>> DEFCONSTANT you are creating a variable.
> Well, when you do a let on a symbol that isn't declared
> special, then I'd say you're creating a lexical variable,
> but if you do one on a symbol that is declared special,
> I would not say that you're creating a variable.

But you are, at least according to the spec.

> OK, I guess you could say that defvar "creates
> a variable" in a sense, even though it does not actually
> create any Lisp object per se.

A variable is NOT a lisp object.  A variable is (according to the  
spec) a binding, and bindings are not first-class in CL.  (They can be  
made first-class.  This is one of the things that my LEXICONS system  
does.)

>  That is, the symbol foo
> in (defvar foo 1) wasn't created by the defvar.

That's true.  But the variable named by FOO was.

rg