(PROCLAIM '(IGNORE ...))

["Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>]

    Where in the manual does it say or imply that a lambda-list keyword
    cannot be used as a normal variable?  To the contrary, pg 60 says,
    "They are ordinary symbols each of whose names begins with an
    ampersand."

Hmmm...I guess it never comes right out and says that, probably because
it was too obvious to mention.  At least, it seems very clear to me that
the lambda-list keywords cannot be used as normal variables in
lambda-lists.  Most such uses would screw up the parsing, and any that
are not ambiguous by would be confusing as hell.  Most exisitng
compilers warn about any lambda-list keywords that seem to be out of
order in a lambda list, and some compilers issue a warning about any
unknown symbol starting with an ampersand.  Such symbols are not
illegal, but a warning doesn't imply illegality -- merely something
suspicious that the user might want to take a close look at.

I suppose one could argue that lambda-list keywords ought to be legal as
variable names in non-lambda contexts.  I think that this should be
illegal -- it is amazingly confusing -- but by a strict reading of the
current manual, I guess it is legal at present.

Maybe the best way to resolve this IGNORE issue is to leave the language
spec as it is, but to encourage compiler writers to provide some
mechanism whereby the user can specify that certain classes of warnings
can be suppressed.  In this case, one would like to suppress "bound but
not referenced" warnings for particular symbols.

There's a more general issue here regarding compiler warnings:

Spurious compiler warnings seem to bother some people more than others.
I have generally taken the view that if the compiler spots something
vaguely suspicious, even if it is not clearly incorrect, it can't hurt
to issue a warning.  It costs very little to ignore such a warning, and
if the problem is a real one, you might save the user many hours of
debugging time.  However, some individuals and companies seem to believe
that code is not in a presentable state until all compiler warnings have
been eliminated, either by fixing the code or by explicitly suppressing
the error message.

At present, the language spec does not say what warnings a compiler must
or may issue, and there is nothing in the spec about suppressing such
warnings.  One reasonable position (that looks good to me) is that this
is an environment issue and the language doesn't need to say anything
about this.  But if people are going to get upset when allegedly
portable programs give rise to compiler warnings, then maybe we need to
think about some standard in-file mechanism (perhaps an extension to
Proclaim/Declare, or perhaps something new) for suppressing certain
classes of warnings at various places within a file.  Such a thing would
provide a common language for creating such advisories, but it would not
be mandatory for compilers to pay any attention to them -- just
desirable.

-- Scott