Peter Seibel <pe
...@javamonkey.com> writes:
> I was trying to figure out what synonym streams are for and came up
> with the following explanation. I'm hoping someone can tell me if this
> is more or less right.
> Suppose I want to make an encapsulated stream (say an echo stream)
> that will track changes to a well-known stream variable such as
> *standard-input*. I can make it like this:
> (make-echo-stream (make-synonym-stream '*standard-input*) my-output-stream)
> Now if someone changes or rebinds *standard-output* while I'm still
> using the echo stream, it will pick up on the change. Whereas if I
> made the echo stream like:
> (make-echo-stream *standard-input* my-output-stream)
> it would keep using the stream referenced by *standard-input* at the
> time the echo stream was made, even if *standard-input* is later reset
> or rebound. A similar situation could arise when making a broadcast
> stream.
> Is that it? Or is there some other use that I'm totally missing?
circularities).
It's so you can have interdependent "well-known variables". In particular,
it allows *standard-input*, *standard-output*, *query-io*, and *debug-io*
to be synonym streams to *terminal-io* without having to rebind anything
other than *terminal-io* to change the "focus of attention" to another
window. On the Lisp Machine, *terminal-io* (which was very badly named),
meant what might better have been called *current-window*.
Unfortunately, because hte hygiene for maintaining window focus is
ill-specified in CL in general, being left to implementations, you
mostly can't use it in this way. You could, of course, make similar
mechanisms of your own, so that you only had to bind one focus variable
in order to change things.
Note that LispWorks, for example, just makes *terminal-io* go to some
tty-like window that I, for one, never want to talk to. I think they
decided (alas) that this icky DOS-like window was the "terminal". The
window more resembles what the Lisp Machine would call the "cold load
stream", the court of last resort in debugging. The
intended abstraction, I think, by those who created this set of names,
would have been that they would have let that be *terminal-io* until
they had bootstrapped their way into multiprocessing, and then would
have re-bound *terminal-io* per process, leaving *standard-input* and
friends alone (because they'd be synonym streams). By the time I found
what they'd one (which is not non-conforming, as far as I know, just
not what I and others intended), I'm not sure there was any way to get
them to back out of it.
Nor are they likely to be the only ones who did this. I think there
are other implementations that have said that there is always a
*standard-input* and *standard-output*, like stdin and stdout, but
that sometimes there is no (or no useful) *terminal-io* if windowing
operaitons of some class are not supported. THis is again, not what I
think would have been intended, but the spec is so vague that there's
no real way to prevent it.
[Historically, Maclisp had TYI ("tty input") and TYO ("tty output")
which were really both *terminal-io* and were very definitely not
anything you'd re-bind, mostly because the mechanisms for it were
terrible and mostly things would break. Everything relied on these
really holding a console, not just a stream, and being able to do
console-type IO to it. People would sometimes try
and then make a mess of things by getting them inconsistent (one
of TYO bound to a stream and one to the terminal), or worse, they'd
get one bound to one part of the screen and one part of another
(which was a neat trick since the operating systems Maclisp ran
under didn't really have "windows" in the modern sense, but
sometimes still could fake it by giving you lines n-m of the screen
as if it were a sort of window ,so you could write TALK programs
or so that you could reserve a line at the bottom as a status line
that other text didn't write over.)
There was a (status ttycons), a special form on each stream, that
could be changed by (sstatus ttycons ...) that would help you know
what to rebind TYI or TYO to if you undrestood all of this and
really wanted to rebind them to another
value... there was nothing like the CL spec forcing you to not do
things. The maclisp manual mostly tried to excavate "current practice"
and tell people how not to get hurt in what was really a wild, wild west
kind of environment that changed all the time in the way everyone here
is always complaining that ANSI CL doesn't... every monday (or so) an
email saying what had changed and asking you to please update your
programs. .. anyway, so TYI and TYO still had to be a screen stream
if you didn't want the aforementinoed big mess.
Maclisp's IO system underwent an upheaval at some point just before I
came on the scene, and it continued to support both "old i/o" and
"new i/o" even after the upgrade.
Old-IO really had no multiple streams, but had a way
of changing the reader with no args (or with
stream arg NIL) to read from an alternate place under control of
some variables with caret in their names (^R, ^W, etc.) that
corresponded to the interactive interrupt character you could do
to affect whether I/O was coming from such a stream. (The interrupt
character would just set or unset these variables.) When New-IO came
along, creating real "streams" you could open, pepole preferred
using those, but there was no way to talk about *standard-output*
because it was nowhere in the abstraction. The right thing would
have been contniued use of old-io's NIL stream but (a) having it
be part of old-io was daunting, and (b) it really did have those
awful enabling variables that were a mess and no one wanted to use.
I mentino all of this not to teach anyone how old-io or new-io worked
in Maclisp, but rather to say that if you think synonym streams are
not very elegant, you have to see where people were historically
digging themselves out from, because they were a MASSIVE improvement
over prior abstractions, even if they don't offer much today.]
