Issue: CLOSED-STREAM-OPERATIONS (version 3)

[Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>]

    Date: Thu, 13 Oct 88 11:58:56 PDT
    From: vanroggen%aitg.DEC@decwrl.dec.com

    ...
    Issue:        CLOSED-STREAM-OPERATIONS
    ... 
    Proposal (CLOSED-STREAM-FUNCTIONS:ALLOW-INQUIRY)
 
    Clarify that one may call the following functions on closed streams without
    error due to the stream being closed:

This is not the same as saying they will continue to return the same values.
For example...
 - perhaps CLOSE on a closed stream should return NIL, not T. 
 - perhaps some implementations would want INPUT-STREAM-P of closed streams to be NIL.
   i think there's no good reason to have that be so, but it's an issue that would
   have to be resolved and implementations would likely diverge in the absence of info
   so it could lead to portability troubles if we don't clarify that if a stream was
   INPUT-STREAM-P when open, it will be when closed, too. [we might acknowledge the
   possibilty that a stream could be `re-opened' in an implementation-specific way,
   in which case the way this function operated could change.]
    (SETQ S (OPEN "file" :DIRECTION :INPUT))
    (INPUT-STREAM-P S) => T
    (CLOSE S) => T
    (CLOSE S) => T ;NIL?
    (INPUT-STREAM-P S) => T
    (OPEN S :DIRECTION :OUTPUT) => ??
    (INPUT-STREAM-P S) => ??
 - I could imagine the pathname information for a pathname wanting to change from
   the opened name to the truename upon close. eg, if you open .NEWEST, you might
   know the truename only after you close. TRUENAME might therefore want to return
   something different after CLOSE. Whether it should be permitted is something
   -we- should decide, not something we should leave up to implementors ... at least
   not without making it explicit that we're doing so.
 - Gack. I never noticed that PATHNAME-VERSION could be called on a stream. Hmmmm.
   Same comment as for TRUENAME, I guess.
 - The interaction of DIRECTORY is particularly interesting. Even if the truename
   does not change, some file systems will treat DIRECTORY of foo.lisp.newest
   differently depending on whether the stream to that file is still open. Some can
   tell you the file is there but it's still open, while others will not admit its
   existence until it's closed. I don't think we can get away without saying
   something about this.

Any operation for which the level of well-definedness of its meaning is not preserved
by CLOSE is at least a candidate for making an out-and-out error since the behavior
after CLOSE will not be portably defined. Actually, we can probably say "unspecified"
in most cases rather than "undefined" since we can say the behavior is harmless, but
it just may not be particularly meaningful...