[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Issue COMPILER-DIAGNOSTICS, v7
- To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
- Subject: Re: Issue COMPILER-DIAGNOSTICS, v7
- From: Dan L. Pierson <firstname.lastname@example.org>
- Date: Tue, 03 Jan 89 13:01:46 EST
- Cc: cl-compiler@SAIL.STANFORD.EDU, email@example.com
- In-reply-to: Your message of Tue, 03 Jan 89 02:00:00 -0500.
[[Meta-note to cl-cleanup. One of the proposals for handling compiler
messages is based on signalling all messages as conditions with the
standard signalling function "printing" the message iff the
condition isn't handled. I think that this approach can, and
should, be applied to messages in the cleanup domain as well so I'm
forwarding just this message to cleanup to get a sense of the
Part of my objection is that the name NOTICE is too vanilla.
There are other possible meanings and I can see people being bummed
if we use it up.
The Lisp Machine has a thing called a notification. I might be
susceptible to calling the type a NOTIFICATION and making a function
called NOTIFY. Then, at least, there would be current practice behind
I have no objection to these name changes.
In another message, you suggested things like
could be controlled by this, but there's already a competing proposal
for a :PRINT keyword to COMPILE-FILE which would cause that kind of
thing to go to STANDARD-OUTPUT (presumably unconditionally). I don't
want -too- many ways to do the same thing, so we should be careful about
That's true. I am mildly opposed to the competing proposal because
it's redundant with mine. I am strongly in favor of one general
condition-based mechanism for all of these messages.
If we made a notification facility, I think it should be done by Cleanup,
not compiler. Then perhaps GC messages could be done using it, and
the GC-MESSAGES issue (which deals with suppressing such messages) could
be handled as part of the same thing, too.
No object, since it also came up in connection with Moon's comments on
GC-MESSAGES, if forwarding this to cl-cleanup as well.
I don't have time to pursue this further and I can't say for sure that
if someone fleshed this out that I would necessarily support it ... but
I am not unalterably opposed to it if it's done in a way that motivates
its use (and doesn't just go in randomly with not even an initial purpose),
doesn't lock down too many short highly generic names, etc.
I can try to come up with something, if a condition-based approach to
this whole problem looks acceptable.