*terminal-io*

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

    Date: Sun, 29 Mar 87 17:28:03 MST
    From: sandra%utah-orion@utah-cs.arpa (Sandra J Loosemore)

    Well, suppose the implementation doesn't provide any utilities
    that mess with the value of *terminal-io*:  it might initialize
    it on startup and that's that.  If *terminal-io* is never changed 
    in system code, and users aren't supposed to change it, why bother
    with the synonym stream?  I think the manual is being overly
    restrictive here....

The responsibility of CL goes beyond legislating simply what
implementations must and must not do for the sake of user code. It tries
to create formalisms where reasonable implementation-dependent
extensions to the language will not break CL programs.

This is an example of such a case. Although CL users are told not to
directly change *TERMINAL-IO*, users of some CL implementations may invoke
system-dependent commands which change it. And when they do so, they 
do not want their CL programs to break because those programs have made 
unwarranted assumptions about the constant nature of *TERMINAL-IO*.

In fact, once more progress has been made in the window system arena,
we may even want to lift the restriction that *TERMINAL-IO* should 
not change due to user programs. As such, it's best for now that programs
continue to assume that *TERMINAL-IO* might change, since some day it
might and it would be a shame for them not to be capable of accepting that
change.