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

Issue: STREAM-CAPABILITIES (version 1)



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.