[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
- To: cl-cleanup@SAIL.STANFORD.EDU
- Subject: Issue: PROCLAIM-LEXICAL
- From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
- Date: Tue, 19 May 1987 21:00 EDT
- In-reply-to: Msg of 19 May 1987 20:38-EDT from David A. Moon <Moon at STONY-BROOK.SCRC.Symbolics.COM>
- Sender: FAHLMAN@C.CS.CMU.EDU
In reply to: David A. Moon <Moon at STONY-BROOK.SCRC.Symbolics.COM>
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).
OK, I think we agree here, more or less. I'd like to see some
indication in the proposal that this particular "is an error" is one
that many interpreters might choose to allow for the convenience of
programmers. Some people equate "is an error" with "don't do it" rather
than "don't depend on it across implementations".
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.
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
Well, you're right in saying that "is an error" would be the right thing
if our only concern were portable programs. That's our main concern,
but not our only one. I would still like to be able to do a few typical
interpreter things in any Common Lisp, and this is one of them. So I am
strongly opposed to any proposal that says it is OK for (setq foo 27)
this issue doesn't affect portable
programs, but that's not the only concern we should deal with. I would
like to see
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.