[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:10 EDT
- Sender: FAHLMAN@C.CS.CMU.EDU
Sorry, I hit the wrong key and shot that last message off before I was
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 that "is an error" would be the best thing here.
I'd like to see some indication in the proposal (maybe down in the
discussion part) that this particular "is an error" is one that some
interpreters might choose to tolerate (preferably with some warning) for
the convenience of interactive users. Some people equate "is an error"
with "don't do it" rather than "don't depend on it in portable code".
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 legal Common Lisp, and this is one of those
things. So I am strongly opposed to any proposal that says it is OK for
(setq foo 27) not to work in some Common Lisp interpreters.
So I feel pretty strongly that my earlier formulation was the
best one: references and assignments of undeclared/unproclaimed
variables refer to the global cell, but leave the variable undeclared.
And compilers are allowed (not required) to warn about such references.