issue COMPILER-VERBOSITY, version 1

[sandra%defun@cs.utah.edu (Sandra J Loosemore)]

Here is the first draft on this issue, which has been split off from
COMPILER-DIAGNOSTICS.  As usual, flames (or even suggestions) are
welcome. 

-Sandra


Issue:		COMPILER-VERBOSITY
References:	CLtL p. 438-329; 426
		issue COMPILER-DIAGNOSTICS
Category:	CHANGE/CLARIFICATION/ENHANCEMENT
Edit History:   V1, 25 Oct 1988, Sandra Loosemore


Problem Description:

Implementations vary widely in the amount of information that is printed
out by COMPILE-FILE.  In some situations, it would be useful to control
how much information is printed.


Proposal COMPILER-VERBOSITY:LIKE-LOAD:

Introduce a special variable, *COMPILE-VERBOSE*, with an implementation-
dependent initial value.

Add :VERBOSE and :PRINT keyword arguments to the function COMPILE-FILE,
analogous to those for the function LOAD.

The :VERBOSE argument (which defaults to the value of *COMPILE-VERBOSE*),
if true, permits COMPILE-FILE to print a message in the form of a comment
to *STANDARD-OUTPUT* indicating what file is being compiled and other
useful information.

The :PRINT argument (which defaults to NIL), if true, causes
information about top-level forms in the file being compiled to be
printed to *STANDARD-OUTPUT*.  Exactly what is printed will vary from
implementation to implementation, but nevertheless some information
will be printed.


Rationale:

This proposal makes COMPILE-FILE behave like LOAD.  There is already
some precedent for doing this (for example, issue COMPILE-FILE-PACKAGE,
which makes COMPILE-FILE as well as LOAD rebind *PACKAGE*).


Current Practice:

Lucid provides a :MESSAGES keyword argument to COMPILE-FILE, which can
either be a stream to send progress messages to, or NIL to suppress messages.
The default value is T, which sends messages to "the standard terminal
device".

On the TI Explorer, COMPILE-FILE displays the name of the function being
compiled when the option :VERBOSE T is given or special variable
COMPILER:COMPILER-VERBOSE is true.  (In other words, they use :VERBOSE
to mean what this proposal says to use :PRINT for.)


Cost to implementors:

This is an incompatible change for some implementations, but the changes
required should be fairly simple.  At least two implementations already
provide some similar mechanism for suppressing messages.


Cost to users:

Some (non-portable) user code may break in implementations where this is
an incompatible change.

Specifying that the :PRINT argument defaults to NIL is consistent with
LOAD, but in most implementations the default now is to print out a
lot of information about each function or top-level form.  Some users
may find it irritating to have to type in :print t to get the same
amount of information they're used to seeing.


Benefits:

Users are given a portable way to control how much information is printed
by COMPILE-FILE.


Discussion:

Rather than just treating :PRINT and :VERBOSE as boolean values, it
might be useful to have them convey more information.  For example,
Pitman has suggested using keyword values like :BRIEF or :DETAILED to
allow varying amounts of information of each type to be printed.
Alternatively, it might be reasonable to follow Lucid's precedent to
allow the values of :PRINT and :VERBOSE to be streams to allow
messages to be directed somewhere other than *STANDARD-OUTPUT*.
Either of these suggestions could reasonably be made to apply to LOAD
as well, but the intent of this proposal is to make COMPILE-FILE
behave like LOAD, not to change the specification of LOAD.

Pierson has suggested an entirely different approach -- introducing
one or more new condition types for informational messages.  This
could be presented as an alternative proposal on this issue, if he
cares enough about it to write it up.  Loosemore believes that using
conditions for this purpose is not appropriate, because this issue
deals with messages indicating the normal progress of the compiler and
conditions are supposed to be used to signal exceptional
(non-ordinary) situations.
-------