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

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

    Date: Tue, 05 Jul 88 17:55:32 EDT
    From: Dan L. Pierson <pierson%mist@multimax.ARPA>

    Issue:         STANDARD-INPUT-INITIAL-BINDING
    ...
    Proposal (STANDARD-INPUT-INITIAL-BINDING:DEFINED-CONTRACTS):
    ...
	*DEBUG-IO*
	    The initial bindings of these variables are undefined except
	    that:
		1. They are all initially bound to streams.
		2. The streams must support input and/or output as
		   indicated by the variable name.
		3. None of the streams may be synonym-streams for another
		   one of the streams, whether directly or by indirection
		   via some composite stream type such as a two-way
		   stream.

I would say something more like:

 "None of the standard streams (including *TERMINAL-IO*) may be directed
  by synonym stream to another of these stream variables (except *TERMINAL-IO*),
  whether directly or by indirection via some composite stream such as a
  two-way stream with one of the arms being a synonym stream."

The reason being that you need to restrict *TERMINAL-IO*, and also that
you don't want to restrict people pointing at the contents of one of
these variables, you just don't want them actually being synonyms for the
variable itself.

		4. Any or all of these streams may be synonym streams for
		   *TERMINAL-IO*.
		5. Any or all of these streams may be synonyms for the a

I believe the "the" here is spurious.

		   common implementation dependent stream.  For example,
    ...
    Test Cases/Examples:
    ...
    (LET ((*STANDARD-OUTPUT* *DEBUG-IO*))
      ...)

    In current Common Lisp: 
	Might cause a circular stream reference because *DEBUG-IO* was

I'd say "if" not "because" here.

	bound to a two-way stream made up of synonym streams to
	*STANDARD-INPUT* and *STANDARD-OUTPUT*.

Maybe also note that this could happen only if *DEBUG-IO* was not its original
setting, since the original setting of *DEBUG-IO* is currently a synonym stream
to *TERMINAL-IO*. So the example is in some sense more complicated than you
show. Maybe you could just change the example to be something that shows the
behavior. Eg,

 (DEFUN FOO () 
   (LET ((*DEBUG-IO* (MAKE-TWO-WAY-STREAM (MAKE-SYNONYM-STREAM '*STANDARD-INPUT*)
					  (MAKE-SYNONYM-STREAM '*STANDARD-OUTPUT*))))
     (BAR)))

 (DEFUN BAR ()
   (LET ((*STANDARD-OUTPUT* *DEBUG-IO*))
     (PRINT 'FOO)))

    With this proposal:
	Would be guaranteed not to cause a circular stream reference.

    (LET ((*STANDARD-INPUT*  *TERMINAL-IO*)
	  (*STANDARD-OUTPUT* *TERMINAL-IO*))
      ...)

Well, not guaranteed not to cause a circular reference. Rather, users would be
warned that the code that led to a circular reference was an error.

    In current Common Lisp: 
	Might cause a circular stream reference because *TERMINAL-IO* was
	bound to a two-way stream made up of synonym streams to
	*STANDARD-INPUT* and *STANDARD-OUTPUT*.

    With this proposal:
	Would be guaranteed not to cause a circular stream reference.

Right. Maybe mention that this could conceivably happen in the initial
configuration of some implementations.

    ...
    Current practice:

    Lucid binds *TERMINAL-IO* to a special internal stream type.  Franz
    binds *TERMINAL-IO* to a special internal stream type for terminal
    streams which reads from Unix standard input and writes to Unix
    standard output.  KCL binds *TERMINAL-IO* to a standard two-way-stream
    with input from Unix standard input and output to Unix standard
    output.

Symbolics Genera binds *TERMINAL-IO* as appropriate for each process,
usually to a `window' for interactive applications or to a stream which
will conjure an interaction window on demand for background tasks.

    ...
    Discussion:

    Pitman was concerned that the initial version of this proposal didn't
    provide a guaranteed way to get back the initial streams after
    rebinding, e.g. *standard-io*.  The second version of this proposal
    offered a solution to that problem which was generally considered too
    complex.  This problem should now be solved.

I'm not sure that this continues to be relevant enough to take up space
in the proposal. People can read the old proposal versions if they care.

    Moon says that *TERMINAL-IO* (and, by extension, *QUERY-IO*, and
    *DEBUG-IO*) should fail to work in a non-interactive environment where
    nothing like a terminal exists.

It might be well to plainly identify that this issue is not really
addressed by the above proposal.

    Masinter notes that:
	``In many multi-processing multi-window environments,
	  the "initial binding" for *STANDARD-INPUT*, *QUERY-INPUT*
	  differs for each process.''  

    Pitman suggests that this issue be renamed to remove "STANDARD-INPUT"
    from the name.  Pierson hasn't done this for fear of further confusing
    people's archives.
    ...

This doesn't need to be here either. If no one cares, I'll live with the
funny name. Brevity is most important, I think.