streams ...

[David Bein <pyramid!bein@hplabs.HP.COM>]

  Sorry for all the confusion. Now for a fresh batch.

  My questions are motivated by what is supposed to happen when
a stream which is composed of other streams runs into one of the
standard streams (e.q. original *standard-input*,*standard-output*,
or *terminal-io*). Note that I am assuming that it is erroneous
to bash the original streams. I do not know whether it should cause
an error or simply do nothing. My feeling is that either is desirable
at different times. I also can imagine cases where one explicitly
wants to bash one of the original streams. Any interactive error/query system
ought to be able to throw its hands up when someone closes *terminal-io*.

  My proposal for handling this mess without forcing true believers
on either side of the question is:

(1) Provide a stream operation which marks a stream as "NEVER-CLOSE".
    When CLOSE (either directly or via a CLOSE on some composed stream)
    hits one of these it ignores it and returns. We could designate
    this as a "DINER" stream since it is always open.

(2) Provide a stream operation which marks a stream as "COMPLAIN-IF-CLOSED".
    When CLOSE (same conditions as above) hits one of these it flames
    out and causes an error.

  Any stream which has neither of these attributes is fair game
for closing either directly or via recursion. Both options may of
course be turned off if a user desires it.

  Establish well-defined defaults for any of the standard streams
so that one can write "portable" code. Perhaps neither attribute
should be on when a stream is created. Of course this does not
help much when *terminal-io* appears out of nowhere as far as
any user is concerned.

  I agree with those people who believe a close on a composed-stream
(echo,synonym,two-way,concatenated,broadcast) should render the
top level stream unusable.

  While on the subject, I think that it would be reasonable to be
able to query a composed stream. It would also be reasonable to
make the various kinds of streams be distinct types (each a subtyp of STREAM)
so the typing system could help differentiate between the streams.
Of course we will have to draw some distinction between "portable"
streams and all the other kinds which implementers have added.

  More food for thought -- what do people think is reasonable to
do with *terminal-io* if the process is running without any kind
of connection to an interactive device? I have seen different
approaches. I personally like the idea that use of *terminal-io*
when no kind of interactive device exists should cause some kind
of merciless death. This has implications for error/query systems
of course.

--David