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

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

    Date: 5 Dec 88 12:14 PST
    From: masinter.pa@Xerox.COM
    ...

	What does it mean to CLOSE a composite stream ( broadcast two-way
    synonym
	concatenated) ? The choices I can think of are:
	a) no effect
	b) implementation dependent (ugh)
	c) closes constituent streams
	d) the composite stream is "closed" (no I/O operations allowed) but
		the constituents are not.

    I prefer c.

There is another possibility:
 e) signals an error
I can't think of any reason why a Common Lisp program ever needs to call
CLOSE on a composite stream. Can someone suggest a legitimate case where
you wouldn't instead close the underlying stream?

My preferences are, in order of diminishing preference:

(e) is my preference unless someone cites a screw case.

(c) seems certainly justifiable. it -could- be an incompatible change for
    some implementations, i suppose. it makes more sense for things like
    broadcast streams (which are usually non-interactive) than it does
    for echo streams (which are sometimes interactive). Anything which
    might accidentally get mixed up with the terminal makes me nervous.
    I agree one shouldn't close terminal streams on purpose -- what I'm
    worried about is someone accidentally closing a terminal stream because
    of some indirection through a composite stream.

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

(b) is the status quo, and technically requires no action though a 
    clarification wouldn't bother me. making things explicit is often
    a good idea.

(a) is neither the status quo nor does it sound very desirable to me.
    if there were any place where this was desirable in some non-trivial
    application, i'd be curious to hear about it.

	What does it mean to close a constructed stream (e.g., STRING)? 
	a) no effect
	b) implementation dependent (ugh)
	c) the constructed stream is "closed" (no I/O operations allowed).

    I prefer a or c.

I don't care which of (a) or (c) as long as it's clearly documented.
(c) would be more consistent with good programming hygeine, though might
have some [probably trivial] storage and/or execution efficiency impact
in some implementations.

(b) is the status quo, and technically requires no action though a 
    clarification wouldn't bother me. making things explicit is often 
    a good idea.