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

Re: Issue: CLOSE-CONSTRUCTED-STREAMS (not yet submitted)

Forum:	Cleanup

References:    Close (CLtL p. 332), WITH-OPEN-STREAM 
	(CLtL p 330), make-synonym-stream, make-broadcast-stream,
	make-concatenated-stream, make-two-way-stream,
	make-echo-stream, make-string-input-stream,
	make-string-output-stream, with-input-from-string,


Category:      Clarification/Change

Edit history:  Masinter,  6-Jan-89, Version 1

Problem description:

First some terminology:

A "composite" stream is one created with make-synonym-stream,
make-broadcast-stream, make-concatenated-stream, make-two-way-stream,

A "constructed" stream is either a composite stream or one created with
make-string-input-stream, make-string-output-stream,
with-input-from-string, with-output-from-string.

The function "CLOSE" is currently described in 21.3, which starts "This
section contains discussion of only those operations that are common to all
streams."  This would seem to imply that they apply to constructed streams.

The definition of CLOSE "The argument must be a stream. No further
input/output operations may be performed on it. ... "  It further states
"... and it is permissible to close an already closed stream."

However, the behavior on the constructed streams is not well defined, and
implementations (apparently) differ.


It "is an error" to call CLOSE on a constructed stream. CLOSE might signal
an error, or the result of CLOSE could cause the constituent streams to be
closed, etc, but the effect is implementation-dependent.


Calling CLOSE on a constructed stream signals an error.


The effect of CLOSE on a constructed stream is to close the "argument"
stream only, but none of the constituents; that is, 

a) no i/o operations are permitted after the call to CLOSE on the stream
given to CLOSE. In addition, for streams created with
make-string-output-stream, the result of get-output-stream-string is
unspecified. For other composite streams, the "links" 

b) the call to CLOSE has no effect on other streams:
	for broadcast, two-way,  synonym or echo streams, none of
	the constituent streams are closed (the "links"
	to the constituents may be broken; if the proposal
	in STREAM-ACCESS passes, the results of
	the accessor functions there are unspecified after
	the call to CLOSE.)




Signalling an error is reasonable if no Common Lisp program ever needs to
call CLOSE on a composite stream. We could not come up with a legitimate
case where you wouldn't instead close the underlying stream if that's what
you wanted.

Allowing the result to be implementation dependent is the "status quo". 

ARGUMENT-STREAM-ONLY is probably the "safest" in that it makes it harder to
accidentally close a stream that wasn't intended. 

Current practice:

Envos Medley seems to implement ARGUMENT-STREAM-ONLY.

Cost to Implementors:

Varying, depending on the current level of conformance. Making the changes
themselves is probably trivial (to the "close" method for each kind of
constructed stream type)

Cost to Users:

Likely small; we've not found any good uses for CLOSE on composite streams.

Cost of non-adoption:

Continued minor ambiguity

Performance impact:

near zero


The language would be more well specified.


Well-specified languages are usually easier to deal with.


We discussed, and there was some sentiment, for another alternative: CLOSE
closes the constituent streams as well.  It could be an incompatible change
for some implementations. it makes more sense for things like broadcast
streams (which are usually non-interactive) than it does for echo streams
(which are sometimes interactive).

ARGUMENT-STREAM-ONLY is weird. i can't figure out what i think of it. it
seems counterintuitive and yet it probably wouldn't be harmful if it were
well-defined that this was what it did.