[Openmcl-devel] Compiler warnings

[james anderson]

On 2009-10-19, at 20:15 , Daniel Weinreb wrote:

>
>
> [...]
>
> Whenever Common Lisp sees a symbol being used
> as a variable, which means evaluting it or binding
> it or setting it, it has to decide whether this is a
> "lexical" or "dynamic" ("special") reference.

yes, if the implementation is of common lisp.

>
> [...]
>
> But traditionally it's been possible to just walk
> up to a Lisp REPL and start doing things like
>
> (setq z 4)
>
> and expect to "globally set z to 4".

but, if the implementation is of common lisp, it cannot do this.
if it does do do this, then all bets are off, as we have entered a  
realm outside of the spec.
it creates a binding with indefinite scope and indefinite extent.  
steele takes chapter three to set clear the concepts of scope and  
extent, yet defines no variable class to cover this combination.  
neither does the spec.
- it cannot be a lexical variable[0], as that would require a lexical  
environment.
- there can be no lexical environment[1], as there can be no lexical  
scope[2], because there is no establishing form.
- it cannot be a dynamic variable[3], as that would require a dynamic  
environment[4]. of which there is none, as the binding at issue has  
indefinite extent, not dynamic extent. there is also no declaration.
- it cannot be a special variable[5], as that is the same as a  
dynamic variable.
- it is not a global variable[6], as it is neither a dynamic  
variable, not a constant variable.

where does that leave one, when all operators of the setf/setq family  
are defined to operate on a variable of one of these defined kinds only.

as such one can only commiserate with mr dachraou, when he tries to  
figure out why such a thing necessarily behaves the way it does.
not to mention, that it behaves differently in different purportedly  
conformant implementations.
yes, cmucl allows that it is not really doing "the right  
thing" [http://www.cons.org/cmucl/FAQ.html], but if you don't already  
understand what it is doing, there is little hope for clarity.

the one clear, conformant consequence of such a set operation should  
be an error - whether interpreted or compiled.
there must have been a lisp-in-the-old-days which actually did this.
was it so reviled, that everyone decided, "just go ahead and bind  
it"? for convenience sake?


----
[0] http://www.lispworks.com/documentation/HyperSpec/Body/ 
26_glo_l.htm#lexical_variable
[1] http://www.lispworks.com/documentation/HyperSpec/Body/ 
26_glo_l.htm#lexical_environment
[2] http://www.lispworks.com/documentation/HyperSpec/Body/ 
26_glo_l.htm#lexical_scope
[3] http://www.lispworks.com/documentation/HyperSpec/Body/ 
26_glo_d.htm#dynamic_variable
[4] http://www.lispworks.com/documentation/HyperSpec/Body/ 
26_glo_d.htm#dynamic_environment
[5] http://www.lispworks.com/documentation/HyperSpec/Body/ 
26_glo_s.htm#special_variable
[4] http://www.lispworks.com/documentation/HyperSpec/Body/ 
26_glo_g.htm#global_variable


>   That can only happen
> if z is treated as a special variable.  CMUCL actually
> declares the symbol z to be special, side-effecting the global
> environment, which means any future references to
> z as a variable, even if they could have been interpreted as lexical,
> will now be interpreted as special.  CCL doesn't do
> that, and I don't think other implementations do either.
>
> So (as I understand it) CCL in this case interprets z as
> special,

it interprets it as bound.

> but does not declare the symbol z to be special,
> so any code in the future that uses z in a normal lexical
> way will do what it would have done in the absence
> of the "setq" that happened at top level.