#

## Issue UNSOLICITED-MESSAGES Writeup

    Issue:        UNSOLICITED-MESSAGES
    References:   Chapter 1, Section 1.5, Working draft of standard
    Category:     Clarification
    Edit history: 8-JAN-89, Version 1 by Masinter
    	      6-FEB-89, Version 2 by Chapman
    	      10-MAR-89, Version 3 by Chapman (added discussion)
    	      21-MAR-89, Version 4 by Chapman
    	      24-MAR-89, Version 5 by Chapman
    	      6-APR-89, Version 6 by Chapman (added amendment from 3/89 mtg)

    Problem: Is it legal for an implementation to produce unsolicited output,
    e.g., GC notifications, autoload heralds, and progress messages from
    COMPILE-FILE or LOAD?

    Proposal: UNSOLICITED-MESSAGES:NOT-TO-SYSTEM-USER-STREAMS

    No output may be produced
    by functions other than that specified in the standard or due to the
    signalling of conditions detected by the function.

    Unsolicited output, such as GC notifications and autoload heralds,
    should not go directly to the stream held by any
    Common Lisp stream variable but can go indirectly to
    *TERMINAL-IO* by using a synonym stream to that variable.

    Output such as progress reports from LOAD and COMPILE are "solicited",
    and are not covered by this issue. See issue COMPILE-AND-LOAD-VERBOSE.

    Rationale:

    The intent of the proposal is stated informally as follows:
    if a file is written to, no implementation-generated output should
    end up in the file except as stated above.

    The intent of paragraph 2 of the proposal is that
    implementations are forced to make such streams possible to
    redirect without redirecting the Common Lisp stream itself.

    Current Practice:

    Adoption Cost:

    Small. Implementations and their documentation may have to change slightly.

    Benefits:

    Portability.
    This proposal has very little impact on implementations, but helps the
    user by explicitly stating the disposition of unsolicited output.

    Conversion Cost:

    See Adoption Cost.

    Aesthetics:

    None.

    Discussion:

Copyright 1996-2005, LispWorks Ltd. All rights reserved.