[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Issue: CLOSED-STREAM-OPERATIONS (Version 6)
- To: Masinter.PA@Xerox.COM, gls@Think.COM
- Subject: Issue: CLOSED-STREAM-OPERATIONS (Version 6)
- From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
- Date: Mon, 6 Feb 89 13:11 EST
- Cc: email@example.com, firstname.lastname@example.org
- In-reply-to: <8902061645.AA27985@verdi.think.com>
Date: Mon, 6 Feb 89 11:45:54 EST
From: Guy Steele <gls@Think.COM>
Date: 3 Feb 89 22:55 PST
One reason to send it out to X3J13 is to arbitrate on our notes. I notice
that Moon's notes say "Accepted with amendment that CLOSE of a closed
stream returns NIL".
Mary (or anyone else): do you have a record of the amendment & vote on
For what it is worth, my notes say "amended that CLOSE of a closed
stream return NIL."
Personally, I think this is -awful-. I think one ought not be able to depend
on the result in this case because implementations might reasonably differ
about whether the first CLOSE really closed the stream. As such,
(LIST (CLOSE *TERMINAL-IO*) (CLOSE *TERMINAL-IO*))
might reasonably return (T T) or (T NIL), for example, depending on whether
the implementation represents the concept of `open-ness' for all streams.
The same is true for string streams.
The issue is even weirder for composite (eg, broadcast) streams where some
streams are initially open and others are not, since I think we have no
clear theory of whether such a stream is opened or closed.
I strongly suggest we consider reverting this decision in favor of either
the proposal as drafted, or some decision which is consistent with the model
I've cited above, or else that we bundle this stuff in with the issue which
is discussing the OPEN-STREAM-P operation since the issues are intimately
related. It's my understanding that that issue is now called
INPUT-STREAM-P-CLOSED and that there is no proposal written. Please correct
me if that's not so.