[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Issue: STREAM-CAPABILITIES (version 1)
- To: cl-cleanup%sail.stanford.edu@multimax
- Subject: Issue: STREAM-CAPABILITIES (version 1)
- From: Dan L. Pierson <pierson%mist@multimax.ARPA>
- Date: Tue, 05 Jul 88 17:56:31 EDT
Issue: STREAM-CAPABILITIES
References: Standard streams (pp. 327-329)
Category: ADDITION
Edit history: Version 1 by Pierson 7/ 5 88, add redesign per Pitman
Status: For Internal Discussion
Two versions, one from Masinter and one from Pitman.
Problem description:
Portable programs cannot currently determine certain useful
relationships among streams because the required information is
operating-system dependent and unavailable at a portable Common Lisp
level.
---------------------------------------------------------------------------
Proposal (STREAM-CAPABILITIES:NEW-PREDICATES):
Add the following inquiry functions to Common Lisp:
STREAM-SAME-DESTINATION-P stream1 stream2 [Function]
Returns T if the Lisp can prove that the two streams send their
output to the same "destination". For example, this function
would return true for two streams that output to Unix files iff
the streams resulted either in output to the same file
descriptor or in output to two different file descriptors for
the same inode.
STREAM-SAME-SOURCE-P stream1 stream2 [Function]
Returns T if the Lisp can prove that the two streams receive
their input from the same "source", where same source mans that
input on one stream will change what the other stream would next
read. For example, this function would return true for two
streams that read from Unix files iff the streams resulted in
input from the same file descriptor but not if the streams
resulted in in input from two different file descriptors for the
same inode because then reading one stream would not change what
the other stream saw.
INTERACTIVE-STREAM-P stream [Function]
Returns T if the Lisp believes that the stream is interactive.
Some of the things that define a stream as interactive include:
1. The stream is connected to a person, program, or device
such that the program can prompt for information and
expect to receive different input depending on the prompt.
2. The program should prompt for input and support "normal
input editing".
3. READ-CHAR might hang waiting for input instead of
immediately returning EOF.
The answer returned by this function may be incorrect; it will
most likely be based on whether or not the stream is connected
to whatever the underlying operating system considers a
"terminal device".
Test Cases/Examples:
(LET* ((IN1 (OPEN "foo" :DIRECTION :INPUT))
(IN2 (OPEN "foo" :DIRECTION :INPUT))
(OUT1 (OPEN "foo" :DIRECTION :OUTPUT))
(OUT2 (OPEN "foo" :DIRECTION :OUTPUT))
(STREAM1 (MAKE-TWO-WAY-STREAM IN1 OUT1))
(STREAM2 (MAKE-TWO-WAY-STREAM IN2 OUT2)))
(LIST (STREAM-SAME-DESTINATION-P STREAM1 OUT1)
(STREAM-SAME-DESTINATION-P STREAM1 STREAM2)
(STREAM-SAME-SOURCE-P STREAM1 IN1)
(STREAM-SAME-SOURCE-P STREAM1 STREAM2)
(STREAM-INTERACTIVE-P STREAM1)
(STREAM-INTERACTIVE-P *TERMINAL-IO*)))
==> (T T T NIL NIL ?) ; *TERMINAL-IO* might or might not be interactive
---------------------------------------------------------------------------
Proposal (STREAM-CAPABILITIES:LIST-FUNCTIONS)
Add the following inquiry functions to Common Lisp:
STREAM-SOURCE-ID-LIST stream [Function]
STREAM-DESTINATION-ID-LIST stream [Function]
Returns a list of tokens which identify the source or the
destination of the stream at the current time. The tokens may
be any Lisp objects distinguishable using EQL. The only valid
operations on the list of tokens are non-destructive set
operations.
A synonym stream always returns the same id list as the stream
to which it is indirected.
An encapsulated stream (such as an echo stream or a broadcast
stream) always returns at least the union of the tokens which
would be returned by each of the encapsulated streams.
INTERACTIVE-STREAM-P stream [Function]
Returns T if the Lisp believes that the stream is interactive.
Some of the things that define a stream as interactive include:
1. The stream is connected to a person, program, or device
such that the program can prompt for information and
expect to receive different input depending on the prompt.
2. The program should prompt for input and support "normal
input editing".
3. READ-CHAR might hang waiting for input instead of
immediately returning EOF.
The answer returned by this function may be incorrect; it will
most likely be based on whether or not the stream is connected
to whatever the underlying operating system considers a
"terminal device".
Test Cases/Examples:
(LET* ((IN1 (OPEN "foo" :DIRECTION :INPUT))
(IN2 (OPEN "foo" :DIRECTION :INPUT))
(OUT1 (OPEN "foo" :DIRECTION :OUTPUT))
(OUT2 (OPEN "foo" :DIRECTION :OUTPUT))
(STREAM1 (MAKE-TWO-WAY-STREAM IN1 OUT1))
(STREAM2 (MAKE-TWO-WAY-STREAM IN2 OUT2)))
(LIST (INTERSECTION (STREAM-DESTINATION-ID-LIST STREAM1)
(STREAM-DESTINATION-ID-LIST OUT1))
(INTERSECTION (STREAM-DESTINATION-ID-LIST STREAM1)
(STREAM-DESTINATION-ID-LIST STREAM2))
(INTERSECTION (STREAM-SOURCE-ID-LIST STREAM1)
(STREAM-SOURCE-ID-LIST IN1))
(INTERSECTION (STREAM-SOURCE-ID-LIST STREAM1)
(STREAM-SOURCE-ID-LIST STREAM2))
(INTERACTIVE-STREAM-P STREAM1)
(INTERACTIVE-STREAM-P *TERMINAL-IO*)))
==> (T T T NIL NIL ?) ; *TERMINAL-IO* might or might not be interactive
---------------------------------------------------------------------------
Rationale:
These inquiry functions answer questions that portable Lisp programs
can't answer on their own because the information is frequently only
maintained at an operating system level.
Current practice:
No implementations currently provide this functionality.
Cost to Implementors:
Implementations will have to support these new functions. 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:
Portable programs will have trouble matching their user interface to
different target environments.
Benefits:
Implementations will be more able to match their IO behavior to their
environment and their user's expectations. Portable programs will
have more tools for reasoning about stream relationships.
Aesthetics:
Improved because this area becomes better defined.
Discussion:
Masinter doesn't believe that STREAM-SAME-SOURCE-P (or, presumably,
STREAM-SOURCE-ID-LIST) is needed; Pierson disagrees.
INTERACTIVE-STREAM-P is problematical, the information would be useful
to some programs, but it's not clear how many implementations can
return a useful answer.
Pierson supports STREAM-CAPABILITIES:NEW-PREDICATES because he is
concerned that it may be hard for implementations to provide the list
functions efficiently because the natural token type for multiple,
disjoint types of streams may be integers. The implementation would
have to coerce these integers in to some other type of token that
would be guaranteed unique across all possible stream types.