Issue: STANDARD-INPUT-INITIAL-BINDING (Version 5)

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

    Date: 29 Jun 88 13:04:00 EDT
    From: "AITG::VANROGGEN" <vanroggen%aitg.decnet@hudson.dec.com>

    ... I don't understand the reason for the restriction that the predefined
    streams other than *TERMINAL-IO* can't be synonym streams for each other.
    Is it really necessary to disallow some implementation initially binding
    *ERROR-OUTPUT* to a synonym stream for *DEBUG-IO*, for example?

I believe it is. People write programs that do things like:

 (LET ((*STANDARD-OUTPUT* *DEBUG-IO*))
   ...)

but if *DEBUG-IO* is a synonym stream for a two-way stream which is made
up of synonym streams to *STANDARD-INPUT* and *STANDARD-OUTPUT*, then you
get a circular stream and massive lossage results.

Once the STREAM-CLASS-ACCESS issue goes through and it is possible to detect
a synonym stream, it will finally be possible to at least write cautious
code, but I would hate to think that every time I bound one of these streams
to another, that I must first check to make sure that a synonym circularity
is not being introduced.

As I recall, the current wording neither precludes synonym streams to two-way
streams which are synonym streams nor does it preclude later bindings of these
streams in ways that might introduce circularities, so I agree that the intent
of that text might want to be clarified.

Fyi, I've been screwed rather badly by doing the following seemingly harmless
thing:

 (LET ((*STANDARD-INPUT*  *TERMINAL-IO*)
       (*STANDARD-OUTPUT* *TERMINAL-IO*))
   ...)

on some implementations only to find out that *TERMINAL-IO* was implemented
as a two-way stream to synonym streams to *STANDARD-INPUT* and 
*STANDARD-OUTPUT*. The fireworks that result can be quite messy...

    I don't see the need for adding three more predicates...

Heh,heh. This is why I suggested this should be two proposals, Dan.

    Furthermore the descriptions of those predicates seem controversial.
    What is STREAM-INTERACTIVE-P really trying to establish?  ...

These are good points that I think should get nailed down. Among other things
to add to the list of things interactiveness might want to include are:
 * Should I prompt for input?
 * Is input editing (ie, rubout handling) something that should
   be dealt with?
 * Should I expect that READ-CHAR might hang waiting for input
   (vs returning an eof if no chars are available).