[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Issue: STANDARD-INPUT-INITIAL-BINDING (version 3)



Wow. I was about to button "Deliver" on a message poking you on this one...

I must admit that I didn't read earlier versions with much attention.  I am
uncomfortable with the imperative style of this proposal (and of CLtL). I can
easily imagine implimentations conforming to the spirit but not conforming to
the letter of this proposal. Suppose, for example, I have a program that records
user input and is able to duplicate it later. The second time I run it, it isn't
an "interactive" input stream, but does this mean I can't legally attach it to
*QUERY-INPUT* because reading from *QUERY-INPUT* must result in end-of-file?

 In many multi-processing multi-window environments, the "initial binding" for
*STANDARD-INPUT*, *QUERY-INPUT*  differs for each process. 

Your latest VERSION makes reference to *INITIAL-INPUT* and *INITIAL-OUTPUT*
still, even though you removed those items from the definition.

    *ERROR-OUTPUT*
    	If *initial-query-input* is bound to an interactive input source,
	this stream should be bound to the cooresponding interactive output
	destination such that *query-io* will work in the expected way if
	bound to a two-way stream between these two streams.  If the Lisp
	system is running under an operating system such as Aegis, Unix,
	or VMS which provides a separate error output destination, this
	stream should be bound to that destination.  In a non-interactive
	environment without a separate error destination, this stream should
	be bound to the same destination as *initial-output*.


a) what is *initial-query-input*?
b) what is "the expected way"?
c) what if "*initial-query-input* is bound to an interactive input source" and
also "If the Lisp
	system is running under an operating system such as Aegis, Unix,
	or VMS which provides a separate error output destination"? 
	This section gives conflicting requirements, does it not? If you are running
with an operating system that has error output streams but the initial query
input stream isn't it?

    *TRACE-OUTPUT*
    	The initial binding of *trace-output* is *initial-error-output*


what is *initial-error-output*?

what is "automagically"?

etc. etc.

I don't know how to say it more kindly, but I think this is a step backward from
version 2.