Re: Compiler Warnings, again

[pazzani@pan.ics.uci.edu (Michael Pazzani)]

In article <9203182157.AA19026@brazil.cambridge.apple.com> pierce@at-mail-server.vitro.com ("pierce") writes:
>
> Michael Pazzani writes:
>
>>> Once again, I understand that warnings should almost never be turned
>>> off, but a program that calls the compiler during its normal operation
>>> might want to control the warnings.
>
>Even if your program is calling the compiler, you should have your program
>generate common-lisp code which doesn't generate any warnings.  If you are
>generating some warnings, then you should update the code generator part of
>your compiler to generate code which is warning free by using declarations as
>necessary and wrapping your functions in a with-compilation-unit form.  This
>way, you can be sure that your compiler flags at least as many warnings as the
>common lisp compiler that you are using.
>
>-Jonathan


I object to you position on three grounds:
A. I am building a language on top of lisp.  Users write programs
in this language.  I provide some support to detect static errors
in these programs (type mismatches, singleton variable checks, use
of undefined predicates).  However, I find it hard to guarentee
that a user cannot write a program without warnings.  In the example
you use, undefined predicates are flagged.  For example, if the
user writes
(def-rule append
	(((append ?x () ?x))  ; append(X,[],X).
	 ((append (?h . ?t) ?y (?h . ?z))   ;append([H | T], Y, [H | Z]) :-
	   (apend ?t ?y ?z)))               ;       apend(T,Y,Z).

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.  Because it
may have been the user's intent to define apend at some later time, I
feel obligated to compile his rule.

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. If you wrote a lisp
function like

(defun fact (x y)
	(if (= x 0)
            (* x (fact (- x 1) y))))

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).

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.

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. Now if only he
could tell me the purpose of CCL::*compiler-whining-conditions*