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: Proposal LIKE-LOAD passed March 89. 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.