[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Issue: STANDARD-INPUT-INITIAL-BINDING (Version 5)
- To: email@example.com
- Subject: Issue: STANDARD-INPUT-INITIAL-BINDING (Version 5)
- From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
- Date: Wed, 29 Jun 88 14:11 EDT
- Cc: firstname.lastname@example.org, KMP@STONY-BROOK.SCRC.Symbolics.COM
- In-reply-to: The message of 29 Jun 88 13:04 EDT from "AITG::VANROGGEN" <email@example.com>
Date: 29 Jun 88 13:04:00 EDT
From: "AITG::VANROGGEN" <firstname.lastname@example.org>
... 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
(LET ((*STANDARD-INPUT* *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).