Need way to suppress warning messages after first see

[Robert Elton Maas <REM%IMSSS@SU-AI.ARPA>]

F> Date: Sun, 20 Apr 1986  11:33 EST
F> From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
F> Subject: (PROCLAIM '(IGNORE ...))  [SIC]
F> ...
F> Spurious compiler warnings seem to bother some people more than others.
F> I have generally taken the view that if the compiler spots something
F> vaguely suspicious, even if it is not clearly incorrect, it can't hurt
F> to issue a warning.  It costs very little to ignore such a warning, and
F> if the problem is a real one, you might save the user many hours of
F> debugging time.  However, some individuals and companies seem to believe
F> that code is not in a presentable state until all compiler warnings have
F> been eliminated, either by fixing the code or by explicitly suppressing
F> the error message.

Seeing and thinking and ignoring one warning once is no big problem,
it takes about a minute of my time, maybe less if it's something
halfway obvious, maybe five minutes if it's a really fatal looking
error I have to figure out carefully, maybe an hour if I have to
discuss it with my boss (for example CANNOT CHANGE FLUID TO GLOBAL or
vice versa in PSL). After I've hassled with one particular instance of
one particular warning a couple times I get more efficient, but the
total time wasted looking at the same error over and over and over
accumulates over the months I work on a system. If in building a large
system I have to look at a hundred warning messages each of a hundred
recompilations during development, that's ten thousand individual
lookings at those idiotic warnings. More likely I just get in the
habit of ignoring them en masse, which is where the harm happens,
because when an important new warning happens I never even look at it
much less study it, in fact I complete miss other obvious things like
DISK FULL, CANNOT OPEN OUTPUT FILE because I'm not even bothering to
eyeball the batch log file. -- Conclusion, it's absolutely essential
for proper use of programmer time and adequate detection of problems
to have a way to suppress individual instances of various warning
messages and in some cases whole classes of warning messages which are
known a priori never to be significant. Any LISP system that fails to
allow the programmer to suppress warnings is (in my opinion) unacceptable.

F> At present, the language spec does not say what warnings a compiler must
F> or may issue, and there is nothing in the spec about suppressing such
F> warnings.

Accompanying the language syntax&semantics spec should be important
guidelines, such as "the compiler should make the resultant as
efficient as possible without sacrificing correctness" (i.e. it's not
legal to sell a "compiler" that just passes most program source thru
to be interpreted at runtime), and "except for detection of outright
errors, it should be possible for the user/programmer to suppress
virtually all warnings and other unnecessary output, as selectively as
reasonable" (i.e. it should be possible to declare individual
names/objects (variables, and data or functions) as well as to declare
classes of names/objects or classes of messages). A general guideline
(desiderata) should be given, so that really obnoxious compilers can
be declared "technically Common LISP but not really in the spirit of
the language".

F>   One reasonable position (that looks good to me) is that this
F> is an environment issue and the language doesn't need to say anything
F> about this.

Insufficient response (my opinion).

F>   But if people are going to get upset when allegedly
F> portable programs give rise to compiler warnings, then ...

Yup, something is needed (my opinion).