longwinded reply to close queries

[franz!jkf@Berkeley (John Foderaro)]

    From: David A. Moon <ucbkim!Moon@SCRC-STONY-BROOK.ARPA>
    Since the function OPEN doesn't return synonym streams, it's difficult to
    say what "a synonym stream is 'opened'" means exactly.  I'd say
    "a synonym stream is made'", since we make them by calling 
    MAKE-SYNONYM-STREAM.

Sure, call it whatever you wish, I always think in terms of streams being
created by 'open' so I'll just use that term and you can mentally substitute
the appropriate function name.

    This doesn't address my comment: I don't see why close should be treated
    differently from other stream operations.

I can give a few reasons:

 1) A stream has three classes of functions which operate on it:

    creation/destruction
    query  (which file is connected, which byte position)
    action  (read/write)

    A typical stream is atomic so all operations apply just to the stream.
    A synonym stream (and the other make-xxx-stream types) are different.
    As I see it, the creation/destruction function apply to the stream
    itself, and the query and action functions apply to the bound stream.
    Thus:
 
    creation/destruction		stream itself
    -----	
    query				bound stream
    action

    Of course what is needed are a set of query function that act on the
    stream itself, providing such information as what symbol is the 
    synonym stream bound to, thus it really should be something like
    this:

    creation/destruction
    query'
    -----
    query
    action


    In this model, making close act only on the synonym stream is
    natural, and not an exception.  You'll (probably) agree that
    every other function already follows this model.

 2) here is a puzzle:
    (setq p (make-synonym-stream '*foo*))
    
    Can I now safely (close p) if I using the semantics for close that
    you believe are correct?  How can I write a program in common lisp
    to tell me if by doing a (close p) I won't shut off my keyboard and
    display?
    I can't think of a program and I would thus conclude that one should
    never close a synonym stream.

 3) The real question is of course what makes sense to do for real programs
    doing real things.
    Consider a simulation program which wants to watch and log ten different
    types of events.  It wants to create ten streams.  At the start of
    the simulation the user interactively decides for each even whether
    the information should go in a file, or go to *standard-output* or
    to *debug-io*.  For the latter two cases, we create synonym streams.
    In the middle of the simulation, after which time events of type X 
    should no long longer occur, we want to close the *x-event-stream*.
    We can't just (close *x-event-stream*) or we may shut down 
    *terminal-io*.   If we simply refuse to close a synonym stream
    then we are forced to leave copies of this 'live' synonym stream
    floating around and we can't detect when someone uses it again when
    they really weren't supposed to.
--- end list--


    From: David A. Moon <ucbkim!Moon@SCRC-STONY-BROOK.ARPA>
    If one adopts your suggestion that closing a synonym stream means to disconnect
    it from the stream it forwards to, and prevent further operations on the
    synonym stream, then surely closing *debug-io* is just as bad as closing
    *terminal-io*.  How you gonna debug it if *debug-io* doesn't work?
    
I was just using *debug-io* as an example of a synonym stream, but as
long as you asked I can imagine a program that wants to use another stream
for *debug-io* first doing a close of *debug-io* before opening another
stream and storing it in *debug-io*.

    
    Let's look at it a different way: you propose for synonym streams to treat
    CLOSE differently from all other stream operations.  Okay, they could do that.
    What would be gained by introducing this extra complexity, other than an
    extra page of thickness of the manual?
    
I would claim that without this extra complexity, synonym streams are too 
dangerous to be used in most of the applications I would see for them.

-john foderaro