[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Compiler Warnings, again
In article <29C7E640.email@example.com> firstname.lastname@example.org (Michael Pazzani) writes:
From: email@example.com (Michael Pazzani)
Date: 19 Mar 92 00:54:24 GMT
I object to you position on three grounds:
My compiler might print a nice warning message
"Apend- undefined predicate in clause 2 of append"
My warning message serves one of two purposes
1. Pointing out that apend is spelled wrong
2. Reminding the user to define apend
Even though this warning message is generated, you seem to argue that
common lisp should print its warning "apend/2 undefined". This error
message would only serve to confuse users of my language.
So generate code that doesn't produce warnings. We've already
pointed out how you can do this. If you've already told him
about the possible problem with apend/2, then declare it.
The point of his remark was not that you should never cause warnings
to be issued, but rather that YOU (the translator, as opposed to your
user) should never cause warnings to be generated. It's even better
if you can provide better warnings than the lisp compiler --- in which
case you should then generate code that the lisp compiler won't issue
may have been the user's intent to define apend at some later time, I
feel obligated to compile his rule.
Absolutely. Nobody has suggested otherwise.
The general idea is that when you build layers of abstraction onto a
language, the users don't want to hear error messages from the lower
levels. For example, many lisp compilers don't generate machine code
directly, but instead output some other language that is then compiled
or assembled. It's unrealistic to assume that the generated code of
any user program in the high level language will not violate some
stylistic guidelines of the lower level one.
This is why style warnings are supposed to be warnings of class
STYLE-WARNING. I don't know if they are yet, but that's what the
Most lisp compilers, including MCL, don't complain that the argument
"y" isn't necessary. Perhaps they should, but I'm certain that if
there were a warning from a lower level assembly language, it won't be
real useful (e.g., register 4 should not be pushed on stack).
But what if it warned of a real problem? After all, what you're
talking about here *IS* a real problem, and the code won't run
until it is fixed. It's far far worse to fail and have the fact
of that failure hidden from the user.
B. I want to do research in area X (In my case machine learning). My
program runs on at least 5 common lisps on 4 machines. It's hard
enough figuring out how to turn off warnings in each one. Anticipating
every warning each common lisp might generate is even worse. Especially
when those warnings change with each release. For example, if next
year, Apple writes a routine to detect unused parameter values
in recursive functions, I'd rather continue my research than worry
about determining the conditions under which a prolog rule gets
converted to such a function and putting in the necessary declarations.
Turning off all warnings lets me accomplish this.
But at what a cost! The answer, of course, is that Apple shouldn't
do anything so foolish. There is also some (but not enough) standardization
of what warnings may be produced.
C. I like lisp because it gives we enough rope to hang myself. It
always bothers me when someone takes my rope away.
Thanks to Bill St. Clair who told me something that isn't in CLtL2 or
the MCL2 documentation. The condition ccl::compiler-warning is
signaled on compiler warnings in MCL2. I hope this info makes it to
the next release of the manual as a documented feature.
God, I hope not. I would hope that it conforms to the standard, instead,
which is far more useful, because it also has STYLE-WARNING, and most
importantly, is standard.
Now if only he
could tell me the purpose of CCL::*compiler-whining-conditions*