[Openmcl-devel] Compiler warnings

[Ron Garret]

On Oct 21, 2009, at 8:33 AM, Daniel Weinreb wrote:

> Ron Garret wrote:
>>
>>> 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.
> I think we are having a vocabulary problem.  In the sense
> in which I am using the word, CCL treats it like a dynamic
> variable.

Not if you are using the word "dynamic" to mean what the spec defines  
it to mean.

> The following paragraph will make sense (even if you
> disagree with it) if I am understanding your use of
> the vocabulary as you mean it; not, if not.
>
> Whether a symbol has been declared special is one of the
> inputs to the decision that the evaluator makes as to
> whether to treat a symbol (when seen in context of
> being a varible) as dynamic versus lexical.  Although
> a top level "(setq x 5)" does not declare the symbol x
> special, Lisp nevertheless treats it as a special variable.

No, Lisp does *not* treat it as a special variable, at least not as  
defined in the spec.  If it did, the following would return 2:

(setf x 1)
(defun foo () x)
(let ((x 2)) (foo))

but it doesn't, it returns 1.

>>
>>> 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.
> If the symbol were declared special, you could no longer (etc).
> The symbol is not declared special.  But Lisp is treating
> the symbol as a dynamic variable, the way I'm using those
> words.
> The wording in the spec may not be consistent with the
> way I'm using the words.

Indeed it is not.  I respectfully suggest that you choose a different  
word.  If you use terms defined in the spec to mean something other  
than the spec's definition, the result will likely be a great deal of  
confusion.

>  (The spec is not always internally consistent about vocabulary.)

That may be true, but I don't think you will be helping matters if you  
deliberately use words to mean something other than their established  
definitions.

>>
>>>
>>> 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?
> That (setq x 3) is not well-defined is, to me, unsatisfactory.

But it *is* well defined.  It is possible to describe exactly what  
(setq x 3) does.  The only problem is that what it does isn't  
consistent with the spec, and doesn't have a name.

>>
>>> 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.
> Note that the Hyperspec page on "defvar" does not
> ever refer to "creating" a variable.
>
> It does talk about "establishing" a symbol as a dynamic
> variable, which I take to be synonymous with declarating
> or proclaiming a symbol as a dynamic variable.  It's not the
> same thing.

Happily, we don't have to wonder what "establish" means.  The spec  
defines it:

establish v.t. to build or bring into being a binding, a declaration,  
an exit point, a tag, a handler, a restart, or an environment. ``let  
establishes lexical bindings.''

To my ear, that sounds pretty much the same as "create".  But the spec  
also defines "declare" and "proclaim" so we don't have to wonder what  
those words mean either.  The authors of the spec were remarkably  
prescient.

rg