Re: Issue: STANDARD-INPUT-INITIAL-BINDING (Version 5)

[Dan L. Pierson <pierson%mist@multimax.ARPA>]

    As I recall, the current wording neither precludes synonym streams
    to two-way streams which are synonym streams nor does it preclude
    later bindings of these streams in ways that might introduce
    circularities, so I agree that the intent of that text might want
    to be clarified.
    
I'll try to clean this up.  The intent is that the streams in question
can all be synonyms for the same internal stream, but not for each
other, two-way-streams for each other, etc.

        I don't see the need for adding three more predicates...
    
    Heh,heh. This is why I suggested this should be two proposals, Dan.
    
I thought this might happen, but decided to wait and see.  The next
version will have two proposals if that's what people want.  If anyone
strongly opposes two proposals, speak now or...

        Furthermore the descriptions of those predicates seem controversial.
        What is STREAM-INTERACTIVE-P really trying to establish?  ...
    
    These are good points that I think should get nailed down. Among
    other things to add to the list of things interactiveness might
    want to include are:
     * Should I prompt for input?
     * Is input editing (ie, rubout handling) something that should
       be dealt with?
     * Should I expect that READ-CHAR might hang waiting for input
       (vs returning an eof if no chars are available).
    
Good questions.  I'll really rework this one.  I thinks that
STREAM-INTERACTIVE-P is the shakiest of the new predicates just
because it's the hardest to nail down.