[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Issue: PROCLAIM-LEXICAL
- To: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
- Subject: Issue: PROCLAIM-LEXICAL
- From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
- Date: Sat, 2 May 1987 16:13 EDT
- Cc: cl-cleanup@SAIL.STANFORD.EDU
- In-reply-to: Msg of 28 Apr 1987 16:35-EDT from Jonathan A Rees <JAR at AI.AI.MIT.EDU>
- Sender: FAHLMAN@C.CS.CMU.EDU
<Is JAR on CL-CLEANUP now? If not, we should all include him in the
address list while discussing this.>
I think that this proposal is confused. The current rule for handling a
reference to a variable that is neither bound nor declared is
unambiguous: the variable is assumed to be special. There is no
ambiguity and no need for clarification. Whether we want to change this
is another question, and an interesting one.
However, if you feed this program to many Common Lisp compilers
(including Symbolics's and DEC's), a warning message will be
produced for the SETQ, saying something like "Warning: X not
declared or bound, assuming special."
These warnings, unlike the annotations of undefined functions (which
occur only at the end of a compilation), are presented so
prominently that a user would be hard put to say that a program
which elicited such warning messages was "correct" in that
implementation. Unlike the situation with unused variables, there is
no possible declaration one can write which suppresses the warning
messages.
Not true. You can suppress this warning by saying (proclaim '(special
<var>)) or (defvar <var>).
In my view (the manual doesn't spell this out, so we rely on shared
culture) a Common Lisp compiler is free to issue a warning any time it
spots anything suspicious, even though the code may be legal. The more
of this a compiler does, the better it is as a debugging aid (up to the
point where the "crying wolf" effect sets in because too many spurious
warnings are being generated). The use of an undeclared variable is
legal because users like to do this in the interpreter; in a code file,
on the other hand, it is either very unstylish or, more likely, the
result of a typo. In the latter case, I want to see a warning. If you
tell me that I can can't use a warning here because it looks too much
like an error, then I'll have to create yet another kind of compiler
output ("mild suggestion?") with which I can report these things.
I prefer to retain the term warning for this, and to use the term "error"
when there really is an error.
If a fix really is needed here, it should probably be a compiler
declaration that suppresses all warnings in a certain stretch of code.
Then people who hate to see any warnings can get rid of them, and those
of use who use them for debugging can have them. But I see nothing
unacceptable or even uncomfortable about the status quo. Probably the
spec should explaint he difference between an error and a warning rather
than leaving this to the reader's imagination.
As a separate issue, we might want to try to hammer out a proposal for
what people have called "global lexicals", and we might even want to
make this the default for undeclared symbols used free. But we should
not muddle this into a discussion of the current rules or the difference
between warnings and errors in the compiler.
-- Scott