[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


    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:


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


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).