[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Issue: STREAM-CAPABILITIES (version 3)
- To: CL-Cleanup@sail.stanford.edu
- Subject: Issue: STREAM-CAPABILITIES (version 3)
- From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
- Date: Tue, 23 May 89 14:46 EDT
I hope this issue is on the agenda for the June X3J13 meeting. KMP and
I have prepared a revised writeup which we think is ready for release.
I'd like to distribute this to X3J13 as soon as discussion, if any, in
the cleanup subcommittee is completed.
References: Standard streams (pp. 327-329)
Edit history: Version 1 by Pierson 5-Jul-88, add redesign per Pitman
Version 2 by Moon, 10-May-89, remove controversial parts
Version 3 by Moon, 12-May-89, improve wording and examples
Programs cannot currently distinguish between interactive use and batch
(or background) use without using implementation-dependent extensions.
For example, there is currently no way to tell whether it is useful to
ask a question when an unexpected situation is encountered.
Note: earlier versions of this issue tried to solve another problem
as well. See discussion section.
Add the following function:
Returns T if the stream is interactive, otherwise NIL. Signals
an error of type TYPE-ERROR if the argument is not a stream.
The precise meaning of INTERACTIVE-STREAM-P is implementation
dependent, and may depend on the underlying operating system. However
the general intent is to distinguish between interactive and batch (or
background or command-file) operations.
Some examples of the things that might identify a stream as interactive
1. The stream is connected to a person (or equivalent) in
such a way that the program can prompt for information and
expect to receive different input depending on the prompt.
2. The program is expected to prompt for input and support
"normal input editing".
3. READ-CHAR might hang waiting for the user to type something
instead of quickly returning a character or EOF.
*TERMINAL-IO* might or might not be interactive.
(when (> measured limit)
(let ((error (round (* (- measured limit) 100)
(unless (if (interactive-stream-p *query-io*)
(yes-or-no-p "The frammis is out of tolerance by ~D%.~@
Is it safe to proceed? " error)
(< error 15)) ;15% is acceptable
(error "The frammis is out of tolerance by ~D%." error))))
INTERACTIVE-STREAM-P has been proposed several times and is clearly
needed by any program that alters its behavior depending on whether
it is interacting with a user or running in a "batch" mode.
Most implementations have this feature already, often under a
Cost to Implementors:
Implementations will have to support this new function. Correct support
will require some thought for each operating system supported.
Cost to Users:
None, this is an upward-compatible extension.
Cost of non-adoption:
Less featureful language.
More featureful language.
More featureful language.
Note that some proposed features for telling whether two streams are
connected to the same source or sink of information have been removed
from this version of the proposal. These were the functions
STREAM-SAME-SOURCE-P, STREAM-SAME-DESTINATION-P, STREAM-SOURCE-ID-LIST,
and STREAM-DESTINATION-ID-LIST. These could be revived in another
proposal if desired, but Moon thought INTERACTIVE-STREAM-P was
important and didn't want it to be lost due to controversy over these