Issue: STANDARD-INPUT-INITIAL-BINDING (version 5)

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

[Lest anyone become confused with all these issue names being so similar,
I note that the issue name is STANDARD-INPUT-INITIAL-BINDING as in the
body of your message, not STANDARD-OUTPUT-INITIAL-BINDING as in
your subject line.]

The proposal's wording is somewhat too vague for my taste. For example,
it first says htat the streams are as per CLtL and then it lists a bunch
of streams with commentary after some and not others. Does it mean to say
they are as per CLtL except as indicated? When indicated, does the info
augment or replace what is in CLtL?

There is no such thing as "returning EOF". I think you want to say that
*TERMINAL-IO* can be an empty stream. In the case that it is indeed empty,
it must behave like any other empty file (e.g., signalling an error when
the ERROR-P argument to the read function used is not NIL). I'm not sure
why the issue of an empty *TERMINAL-IO* input stream is addressed, but the
issue of a bit-sink output stream (output being discarded) is not addressed.
Is there a natural asymmetry that I'm not seeing?

The wording "The initial bindings of these streams are undefined" also
doesn't suffice. Streams don't have bindings, variables have bindings.
We must say that the stream variables are bound and that the initial
values of these stream variables are streams. It is the kind of stream
which they are which we can leave unspecified.

In the phrase "the same implemntation-specific stream", "same" has no
antecedent. I think you mean to be drawing some correspondence between
Lisp's *ERROR-OUTPUT* and some Unix/Vax/...-specific error output stream,
but you haven't said that clearly.

It is critical that it say somewhere that *TERMINAL-IO* may not initially
be a synonym stream to *STANDARD-OUTPUT*, *STANDARD-INPUT*. (Don't say that
it may not be a synonym stream at all; it's ok for it to be a synonym to
some internal stream, for example, it's just not ok for it to be a synonym
to one of the other stream variables.)

In place of STREAM-SAME-DESTINATION-P and STREAM-SAME-SOURCE-P, I happen to
prefer the following:

 STREAM-SOURCE-ID-LIST stream				[Function]
 STREAM-DESTINATION-ID-LIST stream			[Function]

 Returns a list of tokens which identify the source or destination of the
 stream at the current time. The tokens may be any lisp objects
 distinguishable using EQL. The only valid operation on the list of tokens
 are non-desctructive set operations.

 A synonym stream always returns the same id list as the stream to which
 it is indirected.

 An encapsulated stream (such as an echo stream or a broadcast stream)
 always returns at least the union of the tokens which would be returned
 by each of the encapsulated streams.

Your STREAM-SAME-DESTINATION-P and STREAM-SAME-SOURCE-P would be possible
to write using set intersection operators, but it would be possible to
detect some other useful relationships as well.

STREAM-INTERACTIVE-P is definitely a good idea, though I would have called
it INTERACTIVE-STREAM-P for symmetry with INPUT-STREAM-P.

You've got a reference to *STANDARD-ERROR* in there where I think you
want *ERROR-OUTPUT*.

Under "cost to implementors", why do you say all implementations will have
to change? Additions are not traditionally counted as changes. Separate
things out so you don't scare people reading casually. The basic structure
of the streams is not changed by this proposal. The restrictions on what
those streams can be is in fact weakened so that if anything, some 
non-conforming implementations might become conforming. Make this two
paragraphs, I think, separating the issue of the stream hierarchy from the
issue of the new streams.

[In fact, I would very much prefer to see this go as two separate
proposals since they're really separable issues. That way, if we get
bogged down in the set of functions operating on streams and that takes
longer to get voted in (or never gets voted in), we'll still have the
important changes to the stream bindings taken care of -- I don't expect
that issue to be nearly so controversial now that this proposal is simplified
as you have it here.]

I'll reserve specific statements of approval until I see a redraft or
replies to these comments. I think it's getting better, though.