[Openmcl-devel] Compiler warnings
dlw at itasoftware.com
Mon Oct 19 14:15:37 EDT 2009
Tim Bradshaw wrote:
> One of the most annoying things about SETF at the top-level in CMUCL
> is that it does (or did) effectively declare the name as special.
> That can have fairly pervasive and unfortunate side-effects.
> So it's a good thing it does not do this in CCL.
I agree strongly. In fact, having SETF at top level
cause a declaration to happen is extremely confusing.
This is a much more profound issue than the question
of when warnings are emitted. The warnings are less
profound because they do not actually have any effect
on the outcome of the program.
In Taoufik's defense, this stuff really is pretty confusing.
First, the CMUCL behavior makes it very different from
anything else. Second, I can see how it would be easy
to think that the presence or absence of warnings meant
something more than it actually did. Third, even I am
finding that I have trouble explaining this, even though
I have co-authored or closely edited at least three texts
on Lisp that try to explain all this! (And I agree with
Ron that this all reflects poorly on the clarity of
the language design; it's all due to unfortunate
Ignoring symbol macros (since that's orthogonal)
for simplicity and brevity:
The following is not stringent and precise, so please
don't pick over details if they aren't really germane
to the point I'm trying to make; thanks in advance.
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.
Basically, if the current declaration context says
that the symbol is declared "special", it's taken
as a special reference. I think the best way to say
it is that evaluation treats the symbol as the name
of a dynamic variable, and then that evaluation is
getting the value of that dynamic variable. Binding
is doing a "dynamic bind" of the dynamic variable.
If the symbol is not declared special, then the
symbol is treated as the name of a lexical variable
from some lexically enclosing context (the "innermost"
If the symbol isn't declared special and there isn't
any lexically enclosing context providing a variable
named by that symbol, what happens?
In a comopiled program, usually such a circumstance
is interpreted as being an invalid program; it's an
error. This is what happens if you accidentally
mis-spell a variable name (unless there really is
something spelled that way, of course).
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". 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, 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.
Note: Talking about Lisp "creating a variable" can be
confusing. Symbols are created by the reader, at
read time. 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
I hope this helps.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Openmcl-devel