Issue: STANDARD-INPUT-INITIAL-BINDING (version 1)

[Dan L. Pierson <pierson@mist>]

Issue:         STANDARD-INPUT-INITIAL-BINDING
References:    Standard streams (pp. 327-329)
Category:      CHANGE
Edit history:  Version 1 by Pierson and Haflich 1/19/87
Status:        For Internal Discussion

Problem description:

CLtL requires that *STANDARD-INPUT*, *STANDARD-OUTPUT*,
*ERROR-OUTPUT*, *TRACE-OUTPUT*, *QUERY-IO*, and *DEBUG-IO* are
initially bound to synonym streams to *TERMINAL-IO*.  This requirement
hampers the integration of Common Lisp with operating systems such as
Unix which support input-output redirection.  

Proposal (STANDARD-INPUT-INITIAL-BINDING:TERMINAL-IO-OPTIONAL):

The initial bindings of *STANDARD-INPUT*, *STANDARD-OUTPUT*,
*ERROR-OUTPUT*, *TRACE-OUTPUT*, *QUERY-IO*, *DEBUG-IO*, and
*TERMINAL-IO* are undefined.  Implementors are encouraged to make them
all refer to the user's console (possibly via *TERMINAL-IO*) if it
makes sense in the current invocation of Common Lisp.

Test Cases/Examples:

A Unix implementation is currently unable to legally support standard
error output even though Common Lisp defines *ERROR-OUTPUT* because
*ERROR-OUTPUT* is required to start out bound to the same stream as
*STANDARD-OUTPUT*.

A workstation environnment which provides stream access to windows as
an extension is currently forbidden to make trace output appear in a
separate window by default.

Rationale:

The language is CLtL prevents implementations from doing sensible
things.

Current practice:

Lucid binds *TERMINAL-IO* to a special internal stream type.  Franz
binds *TERMINAL-IO* to a special internal stream type for terminal
streams which reads from Unix standard input and writes to Unix
standard output.  KCL binds *TERMINAL-IO* to a standard two-way-stream
with input from Unix standard input and output to Unix standard
output.

Cost to Implementors:

None required, implementors would be given more freedom to tailor
their implementations to the target harware and operating system.

Cost to Users:

No direct costs because this proposal doesn't require any
implementation to change.

Cost of non-Adoption:

Many implementations will have to continue to choose between
conforming to the standard and providing a superior user environment.

Benefits:

Implementations will be more able to match their IO behavior to their
environment and their user's expectations.  

Aesthetics:

While the aesthetics of the language won't change much, the aesthetics
of environments would be allowed to improve.

Discussion:

This proposal carefully tries not to answer questions like the
following: When is and isn't real access to the terminal via
*TERMINAL-IO* desired?  It certainly isn't for batch programs.  For
Unix which of different std{in,out,err} is *TERMINAL-IO* bound to?

The KCL binding of *TERMINAL-IO* is a stream with no associated
pathname(s).  CLtL makes this more likely than not, which is not a
good thing in the Unix environment.  Do we need another proposal to
determine stream types and access components of two-way streams?  Does
STREAM-CLASS-ACCESS cover this area?