[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Issue: STANDARD-INPUT-INITIAL-BINDING (version 3)
- To: cl-cleanup%sail.stanford.edu@multimax
- Subject: Issue: STANDARD-INPUT-INITIAL-BINDING (version 3)
- From: Dan L. Pierson <pierson%mist@multimax.ARPA>
- Date: Mon, 23 May 88 19:15:04 EDT
Issue: STANDARD-INPUT-INITIAL-BINDING
References: Standard streams (pp. 327-329)
Category: CHANGE
Edit history: Version 1 by Pierson and Haflich 1/19/87
Version 2 by Pierson 2/29/88
Version 3 by Pierson 5/23/88, per comments by Moon
Status: For Internal Discussion
The primitive streams have been removed.
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 many existing and
potential operating environments.
For example, a Unix implementation is currently unable to legally
support Unix 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
because *TRACE-OUTPUT* is required to start out bound to the same
stream as *STANDARD-OUTPUT*.
Proposal (STANDARD-INPUT-INITIAL-BINDING:DEFINED-CONTRACTS):
A Common Lisp implementation is required to provide the following
initial streams. Each initial stream has a specific purpose as defined
in CLtL.
*STANDARD-INPUT*
This stream is bound to the primary default input of the Lisp
system (e.g. standard input on Unix, SYS$INPUT on VMS). While
this will probably be an interactive terminal or window during
program development, it may well be a data file for a
non-interactive application.
*STANDARD-OUTPUT*
This stream is bound to the primary default output of the Lisp
system (e.g. standard output on Unix, SYS$OUTPUT on VMS). While
this will probably be an interactive terminal or window during
program development, it may well be a data file for a
non-interactive application.
*QUERY-INPUT*
Whenever possible, this stream is bound to an interactive
input source. This may be the same as *initial-input* in a
development environment, or it may be a separate window, or
terminal. If the Lisp system is running under an operating
system such as Aegis which provides a separate error input
source, this stream should probably be bound to that source.
In a non-interactive environment for which no interactive input
is available, reading this stream will always result in EOF.
*ERROR-OUTPUT*
If *initial-query-input* is bound to an interactive input source,
this stream should be bound to the cooresponding interactive output
destination such that *query-io* will work in the expected way if
bound to a two-way stream between these two streams. If the Lisp
system is running under an operating system such as Aegis, Unix,
or VMS which provides a separate error output destination, this
stream should be bound to that destination. In a non-interactive
environment without a separate error destination, this stream should
be bound to the same destination as *initial-output*.
*TRACE-OUTPUT*
The initial binding of *trace-output* is *initial-error-output*
in a non-windowed environment. In a windowed environment,
*trace-output* may start out bound in some other way (e.g. to
a non-existant trace output window which will be automagically
created when output is first done to *trace-output*).
*QUERY-IO*
In a non-windowed environment, the initial binding of
*query-io* is a stream that reads from *initial-query-input*
and writes to *initial-error-output*.
*TERMINAL-IO*
The initial binding of *terminal-io* is the same as *query-io*
in a non-windowed environment. In a windowed environment,
*terminal-io* may refer to a different window than *query-io*
as long as all of these streams refer to windows.
*DEBUG-IO*
The initial binding of *debug-io* is the same as *query-io* in
a non-windowed environment. In a windowed environment,
*debug-io* may refer to a different window than *query-io*
as long as all of these streams refer to windows.
Test Cases/Examples:
(PROGN
(PRINT "Output" *STANDARD-OUTPUT*)
(PRINT "Error" *STANDARD-ERROR*))
In current Common Lisp will write:
------
Output
Error
------
With proposal *might* write:
------
Output
------
and "Error" appears somewhere else.
Rationale:
This proposal attempts to provide a balance between over-specifying
behavior to the point that Lisp programs can't behave like other
programs in conventional operating systems and providing enough
specification that Common Lisp programs can perform portable input and
output.
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:
All implementations will have to change to some degree but the changes
will probably be simple and localized.
Cost to Users:
User code which depends on the strict binding hierarchy in CLtL may
have to change.
Cost of non-Adoption:
It will continue to be difficult or impossible to integrate portable
Common Lisp progams in conventional operating system environments.
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:
Slightly improved because this area becomes better defined.
Discussion:
The repeated mention of windowing environments above seems to be
getting dangerously close to the environmental issues this standard is
supposed to avoid, but Pierson feels that if we have to do more than
leave these areas undefined, we also have to give advanced
environments official permission to do their thing.
Pitman was concerned that the initial version of this proposal didn't
provide a guaranteed way to get back the initial streams after
rebinding, e.g. *standard-io*. The second version of this proposal
offered a solution to that problem which was generally considered too
complex.