Re: Compiler Warnings, again

[rwk@crl.dec.com (Bob Kerns)]

In article <29C7E640.4967@ics.uci.edu> pazzani@pan.ics.uci.edu (Michael Pazzani) writes:

   From: pazzani@pan.ics.uci.edu (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
warnings for.

   Because it
   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
standard says.

   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*