[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

issue COMPILER-VERBOSITY, version 6



Here's a new draft on this issue.  It removes the USE-CONDITIONS
proposal and incorporates Moon's suggestion for LIKE-LOAD.


Forum:	    	Compiler
Issue:		COMPILER-VERBOSITY
References:	CLtL p. 438-329; 426
		issue COMPILER-DIAGNOSTICS
Category:	ENHANCEMENT
Edit History:   V1, 25 Oct 1988, Sandra Loosemore
    	    	V2, 12 Dec 1988, Dan L. Pierson (add USE-CONDITIONS)
    	    	V3, 15 Dec 1988, Dan L. Pierson (expand on conditions)
    	    	V4, 21 Dec 1988, Dan L. Pierson (reword and clarify)
		V5, 06 Jan 1989, Sandra Loosemore (update discussion)
		V6, 26 Jan 1989, Sandra Loosemore (remove USE-CONDITIONS)
Status:		**DRAFT**


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 special variables, *COMPILE-VERBOSE* and *COMPILE-PRINT*,
with implementation-dependent initial values.

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 the value of *COMPILE-PRINT*),
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.

Introduce a special variable *LOAD-PRINT*, which has an initial value of
NIL.  State that the default value of the :PRINT argument to LOAD is
*LOAD-PRINT* (rather than NIL).


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

Adding the *LOAD-PRINT* variable allows the printing of messages by
LOAD to be controlled either on a global or a per-call basis.


Current Practice:

COMPILE-FILE prints out progress messages in nearly all
implementations.

Lucid provides a :MESSAGES keyword argument to COMPILE-FILE, which can
either be a stream to send 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.)

Symbolics Cloe already has a *LOAD-PRINT* variable.


Cost to implementors:

This is an incompatible change for some implementations.  While the
changes required should be conceptually simple, their implementation
may involve a significant amount of grunt work.  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.

No user code should be broken by the addition of the *LOAD-PRINT*
variable, since the default behavior for the :PRINT keyword to LOAD 
is unchanged.


Benefits:

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


Discussion:

This issue addresses an extension to the language.  If this proposal
is not accepted, the standard will simply continue not to say anything
about whether COMPILE-FILE can print progress messages, or what stream
such messages are directed to.
-------