[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


I think that Moon's analysis of this issue is right on the mark, and I
like his proposal except for two points:

First, it is made clear that only one of SPECIAL, LEXICAL, GLOBAL, or
DYNAMIC can be in effect for a variable at any one time, but the
proposal does not address the question of whether you can over-ride an
old proclamation in this set by issuing a new one.  We have to address
that, I think, and it is a moderately complex question.

It seems to me that we want to allow a variable to be re-proclaimed for
two reasons: to correct proclmations issued in error by the user,
without having to kill off the Lisp and start over, and to make it
easier to merge programs written by two different programmers.  (The
latter reason may be bogus -- these guys shouldn't be in the same
package anyway -- but there are times when a quick-and-dirty fix is
extremely handy.)  On that other hand, we want the compiler to be able
to wire certain things in tight as a result of these proclamations, so
we need to make clear that if you proclaim something to be GLOBAL,
compile some code, then proclaim it to be SPECIAL and then compile some
more code the rebinds this variable, you may not get what you expect.
Same with unconstantifying a constant.

If Rob's compiler proposal, or something like it, were in effect, we
could probably explain what the rules are within that framework.
However, given the current state of things, it might be best to say that
it "is an error" to re-proclaim a variable into a different class --
this says that portable code cannot do this and count on the result --
but that implementations are strongly urged to allow this
re-proclamation as a way of correcting erroneous proclamations, perhaps
issuing a warning or signalling a correctable error whenever a
proclamation actually gets changed.

The second problem is Moon's suggestion that it should be an error to
assign or reference an unproclaimed and undeclared variable.  The
problem I have with this is that most of us like to be able to do things
with undeclared variables in the interpreter -- stashing things in
made-up variables like FOO -- and I think that there will be blood in
the streets if we take this away from people or if the interpreter is
required to hassle them for not declaring the variable before using it.
And yet, when the compiler comes across an undeclared variable, I want
to get a warning, especially now that I can use a LEXICAL proclamation
to flush that warning with no other side effects.

I think that the right move is to say that accessing and referencing an
undeclared variable is legal, and that such references access the global
cell while leaving the variable in unproclaimed state.  We should then
encourage (require?) compiler writers to issue a warning in such cases.

Of course, if you believe that the compiler has no business warning
about anything that is technically legal (and some wording in Moon's
"cost of adoption" section suggests to me that he may be in this camp),
then the above proposal is a non-sequitur.  In my view, however, the
compiler may issue a warning about code that is legal but suspicious,
though I agree with Rees that in all such cases there should be
something you can put in a program to say, "Shut up, I know what I'm
doing here."  The LEXICAL proclamation gives us that.

-- Scott