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

[David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>]

There are actually three parts to this proposal, and perhaps it
should be written in a way that makes the distinction even clearer.

First, the specification of *STANDARD-INPUT* etc. is changed to
specify them in terms of what they do, rather than in terms of
how they are implemented.  I wholeheartedly support this.  I think
the proposal needs to go a little farther in this direction.  For
instance, it seems to apply that the initial binding of *TERMINAL-IO*
will be a value returned by the MAKE-TWO-WAY-STREAM function.  That's
implementation.  Instead it should say only that the initial binding
of *TERMINAL-IO* behaves in such a way that input comes from, and
output goes to, an interactive place, if there is one.  If no interactive
places exist, I think you say (the wording is a bit confusing) that
*TERMINAL-IO* is bound to (MAKE-TWO-WAY-STREAM *STANDARD-INPUT*
*STANDARD-OUTPUT*), even though it's not a terminal.  I'm not sure, but
I think it might be better for *TERMINAL-IO* to be unbound, or a stream
that signals an error if used, in this case, since anything that explicitly
uses *TERMINAL-IO* is trying to do something that simply can't be done.

I suspect that the alignment of the *TERMINAL-IO* interactive place with
the *STANDARD-INPUT* and *QUERY-IO* interactive places should be left up
to the implementation, rather than trying to say (as you do) it goes
here if that's interactive, else it goes there.  There is probably a
great deal of variation among implementations on this point, and I don't
see that a portable program needs to know whether *TERMINAL-IO* is the
same as *STANDARD-INPUT*, the same as *QUERY-IO*, or the same as neither
of them; a portable program should use whichever stream is the one it
really means, not use some different one on the assumption that it's
really the same.

Second, you propose to add the variable *INITIAL-QUERY-INPUT*, which
doesn't quite correspond to *QUERY-IO*.  This gives access to a primitive
stream that hadn't been identified as primitive before, but that exists
in some implementations.  Although I don't understand how an application
program would use an input-only query stream, I see no harm in making
this change.  No one is forced to use it if they don't want to.  I'd
drop the word "initial" from the variable name.

Third, you propose to add three new variables that retain the initial
values of three of the existing stream variables, in case the existing
variables are rebound.  I don't see any value in this, except that it
helps you describe the meanings of the other streams.  A program that
wished to portably recover from a stream-binding error on any User
Stream could start by saving the values of the existing variables.
We don't need to add new variables for this.

This sounds a bit critical, but I think this is basically a very good
proposal.  I hope you find my suggested improvements constructive.