CLHS: Issue COMPILER-VERBOSITY Writeup

#

## Issue COMPILER-VERBOSITY Writeup

    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:		Ready for release

    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.

Copyright 1996-2001, Xanalys Inc. All rights reserved.