[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


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:

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.  


The initial bindings of *STANDARD-INPUT*, *STANDARD-OUTPUT*,
*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

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.


The language is CLtL prevents implementations from doing sensible

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

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.


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


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


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?