Issue: CLOSED-STREAM-OPERATIONS (Version 7)

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

What's weird about this whole thing is that CLOSE-CONSTRUCTED-STREAM
talks about the effect of most operations being `unspecified' after
close. 

Unless you intend it to be an implication of CLOSE-CONSTRUCTED-STREAM
that you actually carry a CLOSED-P bit around in every stream so you
can tell if the stream is open or not and return the right value from
CLOSE, then it's a bad idea to legislate that CLOSE returns a certain
value, because you can't really guarantee that value.

If you do intend me to carry around a CLOSED-P bit, why bother to
claim that the effect of I/O to the stream after it's closed is 
`unspecified.' My assumption before was that it was unspecified in
case I want to define it, but suddenly it sounds like I'm not really
allowed to extend it -- I'm just permitted to optimize out the error
checks for the sake of efficiency. If this is so, why not just put it
in the domain of `should signal' so that at least the users could get
some mileage out of it because my implementation pretty much has its
hands tied at this point.

We get calls all the time from users who claim we're in violation of
things that really CLtL leaves vague. This will be such a thing given
the way it's all worded.

Here I am implementing CLOSE. I -really- want to implement it correctly.
I am willing to do anything necessary to make it return the right value
as long as what I do is something that is backed up in writing.
Here you are designing CL -- creating the writing that will back me up.
If you cannot show me how to write CLOSE in a way so that I can simply
point to a sentence in the manual that explains off my behavior whenever
anyone complains so I can get them off the phone and get back to work,
then you owe me a sentence in the manual that says that I'm entitled to
do whatever I feel like and the user cannot depend on it.

False security is worse than no security at all.