Issue: CLOSED-STREAM-OPERATIONS (Version 4)

[Kent M Pitman <KMP@stony-brook.scrc.symbolics.com>]

Ok, here's what I did in the proposal below:

 * Changes to proposal
    - Elaborate on each issue. Say more than just "is valid".
      Hopefully this will make any need for line-item veto easier.
    - I changed the treatment of INPUT-STREAM-P and OUTPUT-STREAM-P
      because I couldn't live with claiming that a closed stream was
      no longer of the same type. (This is like saying that a dead
      man is neither man nor woman. I've never bought into this
      nonsense. You never know when you'll find out they were only 
      faking and there's no sense in revising your entire belief
      system just to accomodate a bit which is really orthogonal.)
      If Masinter thinks it's useful to be able to detect that these
      streams can't have I/O done to them, I'm ammenable to adding
      an OPEN-STREAM-P primitive.
    - I clarified the treatment of PATHNAME and friends in a way
      that might not have been compatible.
   In general, read the Proposal carefully with a fresh eye.

 * Very minor cosmetic reformatting to most of sections. With the
   exception of Aesthetics, where I turned "Yes" into a full sentence,
   I didn't change the actual wording of any of other sections.

-----
Issue:          CLOSED-STREAM-OPERATIONS
References:     CLOSE (CLtL p 332)
Category:       CLARIFICATION
Edit history:   26-Aug-88, Version 1 by Chapman
                 8-Oct-88, Version 2 by Masinter
                13-Oct-88, Version 3 by van Roggen
	         1-Dec-88, Version 4 by Pitman
Related Issues: STREAM-ACCESS, STREAM-INFO
Status:         For Internal Discussion
 
Problem Description:
 
 The description of CLOSE is not completely clear about the functions
 which are allowed to be performed on a closed stream.
 
 On p332 it says:

  ``The stream is closed. No further Input/output operations may be
    performed on it. However, certain inquiry operations may still
    be performed, ...''

  but the list of inquiry operations is not specified.
 
  At least one implementation interpreted the list to include at least
  OUTPUT-STREAM-P, while another has disallowed that operation to be
  performed on a closed stream. 
 
Proposal (CLOSED-STREAM-FUNCTIONS:ALLOW-INQUIRY)
 
 Clarify the behavior of the following functions on closed streams:

  * STREAMP is unaffected by whether its stream argument is open or closed.
 
  * INPUT-STREAM-P and OUTPUT-STREAM-P are unaffected by whether their
    stream arguments are open or closed.
 
    This is not the same as saying that once a stream is determined to be
    an input-stream, it will always be. For example, if an implementation
    provides an implementation-specific way to change the direction of a
    stream, that implementation-dependent code may affect the output of
    these functions. Similarly, in implementations where it is possible to
    re-open a closed stream in some ways, the effect of so doing is not
    prohibited from opening the stream with different direction, etc.
    However, as long as only Common Lisp functions are used, INPUT-STREAM-P
    and OUTPUT-STREAM-P of a stream will remain constant over time.
 
  * If CLOSE is called on a stream which is open, it will return T.
    However, if CLOSE is called on a stream which is closed, it
    will succeed without error but the return value is not specified.
 
  * PATHNAME is valid on either an open or closed stream. Since some
    implementations cannot provide the truename of a file until the
    file is closed, it would in principle be possible for PATHNAME in
    some implementations to return more specific information after the
    stream is closed. For consistency, however, PATHNAME is prohibited
    from doing this. PATHNAME (which is valid only on file streams, of
    course) must return the same pathname after a file is closed as it
    did before.
 
  * TRUENAME is valid on either an open or closed stream. Since some
    implementations cannot provide the truename of a file until the
    file is closed, it is permissible TRUENAME to return more specific
    information after the stream is closed.
 
  * MERGE-PATHNAMES, PATHNAME-HOST, PATHNAME-DEVICE, PATHNAME-DIRECTORY,
    PATHNAME-NAME, PATHNAME-TYPE, PATHNAME-VERSION, NAMESTRING, 
    FILE-NAMESTRING, DIRECTORY-NAMESTRING, HOST-NAMESTRING, 
    ENOUGH-NAMESTRING, and OPEN are valid on either open or closed streams.
    For any of these operations, using a stream, S, as an argument 
    where appropriate is equivalent to using (PATHNAME s). See the
    description of PATHNAME above to understand the consequences of this.
 
  * PROBE-FILE and DIRECTORY are valid on either open or closed streams.
    For either of these operations, using a stream, S, as an argument 
    where appropriate is equivalent to using (PATHNAME s). See the
    description of PATHNAME above to understand the consequences of this.
    In this case of these operators however, closed stream may well be the
    most reliable arguments in some cases, since treatment of open streams
    to the file system may vary considerably between implementations.
    For example, in some operating systems, open files are written under
    temporary names and not renamed until close and/or are held invisible
    until a close is performed. In general, any code with an intent to be
    highly portable should tread lightly when using PROBE-FILE or
    DIRECTORY.
 
  * If proposal STREAM-ACCESS:PROVIDE is adopted, all of its functions
    will work on closed streams. That is, the effect of calling any of
    the operations introduced by that proposal on a stream is the same
    whether the stream is open or closed.
 
  * If proposal STREAM-INFO:ONE-DIMENSIONAL-FUNCTIONS is adopted, none
    of its functions are required to work on closed streams. That is,
    the effect of calling any of the operations introduced by that 
    proposal on a closed stream is undefined.

Rationale:
 
 One can consider many characteristics of a stream to be independent of
 the ability to do I/O.  Being able to determine a stream's direction and
 its name is often useful for debugging.  A number of the descriptions in
 CLtL imply (weakly) the ability to work on closed streams.  Functions
 such as OPEN and DIRECTORY don't really depend on the stream, but on
 the name of the stream.
 
Current Practice:
 
 At least two implementations differ in which functions are allowed to be
 performed on a closed stream.
 
Cost to Implementors:
 
 Unknown, but likely to be small in most implementations.

 A nontrivial amount of work may be necessary if the pathname information
 is held  externally and is normally deleted when the stream is closed. 
 The implementation will have to copy the information at some time for later
 inquiries.

Cost to Users:

 None.
 
Benefits:
 
 These clarifications will assist users in writing portable code.
 
Aesthetics:
 
 Most people will probably see these clarifications as an improvement
 in aesthetics.
 
Discussion:

 There are some separate, but related, issues regarding what CLOSE
 should do on composite streams or constructed streams.