Issue GC-MESSAGES (Version 1)

[Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>]

Issue:        GC-MESSAGES
References:   None
Category:     ENHANCEMENT
Edit history: 23-Apr-87, Version 1 by Pitman
Status:	      For Internal Discussion

Problem Description:

  Although there is no standard interface to the garbage collector,
  it is common for there to be a garbage collector in nearly every system.
  In many systems, these do unsolicited typeout which obstructs program 
  typeout in unpredictable ways.

Proposal (GC-MESSAGES:FLAG-VARIABLE):

  Make a variable called *GC-MESSAGES* which controls GC message typeout.
  Possible values of this stream include:
    T		Standard notifications (typically to *TERMINAL-IO*).
    NIL		No notifications.

  Since not all implementations could allow an arbitrary user-supplied
  stream for use as a value of *GC-MESSAGES* (because streams might cons
  and consing might be illegal at the time of the message), this cannot
  be offered as an option. However, this would be a reasonable 
  implementation-dependent extension in some systems, so we should offer
  it as an option.

  In multi-processed, shared-address space implementations, if the GC is
  going to type a message on a stream that belongs to some other process
  (or otherwise ``notify'' the process, to use Lisp Machine terminology),
  the value of *GC-MESSAGES* in the process being notified should be used
  rather than the value in the current process so that this variable can
  be usefully bound by user programs.

  Permit that as an act of desperation, shortly before running completely
  out of space when *GC-MESSAGES* is NIL, the GC may notify the user
  that he is about to lose (in spite of the fact that he has seemingly 
  asked to lose). This permission is important so that people don't feel
  afraid to bind *GC-MESSAGES* to NIL to suppress frequent messages 
  only for fear that they might not get critical last minute information 
  that says it's time to do drastic cleanup action.

Rationale:

  Application programs which do display (especially display which conses)
  need a way of deferring GC warnings that might ruin the display.

Current Practice:

  This functionality is provided in some form or another by a number of
  implementations.

  Zetalisp currently offers SI:GC-REPORT-STREAM which can be set to T, NIL,
  or a stream. It provides useful flexibility and is used by quite a number
  of users.

  Other systems provide ways of enabling or disabling the messages, or of
  customizing the message which is typed out.

Adoption Cost:

  The set of places in which the GC does typeout is probably very 
  restricted, so finding them and changing them to be appropriately
  conditionalized is probably not a lot of work.

Benefits:

  This would allow the user some portable control over a common feature which
  cannot currently be controlled in a portable way.

Conversion Cost:

  This is an upward compatible change.

Aesthetics:

  No significant impact.

Discussion:

  MACSYMA needs this (so it can bind it to NIL). Its display often does
  consing. In some implementations this can cause a GC, which can in turn
  spoil the carefully crafted display.