[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
- To: cl-cleanup@SAIL.STANFORD.EDU
- Subject: Issue: PROCLAIM-LEXICAL
- From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
- Date: Tue, 19 May 87 20:38 EDT
- In-reply-to: <FAHLMAN.12303180096.BABYL@C.CS.CMU.EDU>
Date: Sun, 17 May 1987 17:46 EDT
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
I think I forgot to answer this, but if you're seeing it twice, I apologize.
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
CONSTANT, you mean.
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.
I think this is an environment issue rather than a language issue.
If Rob's compiler proposal, or something like it, were in effect, we
could probably explain what the rules are within that framework.
I think Rob's proposal would only tell us how to compile a program that
proclaims a variable one way inside a Lisp that proclaims it another way,
but not what happens when the result of that compilation is loaded into
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.
In other words, it's an environment issue. I agree that it should be
"is an error" rather than "signals an error"; I think this is an excellent
example of something where program development environments should have
flexibility and, conversely, no portable program would rely on the error
being signalled and want to handle it (using conditions).
The second problem is Moon's suggestion that it should be an error to
assign or reference an unproclaimed and undeclared variable.
Actually I just copied that from Rees.
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.
That's why it's "is an error" rather than "signals an error", isn't it?
Is using undeclared variables in the interpreter something for portable
programs to rely on being able to do, or just something for human users?
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.
That would be okay with me, however people in general might prefer that we
just say it's an error and not try to dictate what the compiler should do.
I have no strong opinion here.
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.