Notes about (^ revised 3) report

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

On p30, while reading the description of READ, the following questions
occurred to me, the answers to which are in some cases probably dependent 
upon the answers to the others in order to assure useful consistency:

 * Does the stream become closed as a side-effect of hitting eof?

 * Is it an error to read from a closed stream, or does eof just keep
   getting returned?

 * Can you read the eof object twice at the end of a file using READ ?
   How about if using READ-CHAR ? PEEK-CHAR ?

 * Is it possible to detect whether a file is closed?

 * Is it acceptable for close on certain streams to not really close the file?
   For example, I could imagine implementing terminal streams or streams into
   editor buffers in a way such that they just always claimed to be open and 
   close was a no-op.

Also on p30, it seems to me that the notion of CHAR-READY? is not a useful one. 
It's subject to timing errors in multi-processed systems and/or systems which 
allow asynchronous interrupts. The Lisp Machine's TYI-NO-HANG paradigm is much 
better, since it has a more test-and-set feel to it and is more easy to use 
reliably. I suggest that CHAR-READY? should be flushed and replaced by a 
READ-CHAR? which returns either a character if one is ready, or NIL otherwise. 
This gets you out of the bind with rubbing out stuff that CHAR-READY? has 
noticed, which is really an awful crock. I believe that TYI-NO-HANG will
interact satisfactorily with Lispm-style rubout handlers.

On p30, the issue with LOAD is that if we're going to define it, we need to give
it a standard meaning so it can be usefully used on different systems. If we
don't say it either types out or doesn't, then people can't use it in their
programs for fear it will screw up the display (this exact problem arose in real
situations in my work with Common Lisp). I feel that a LOAD which does
no typeout is a useful interface to the operating system and a necessary 
feature for bootstrapping other code. The absence to provide it will mean that
either every user will have to type in a definition of load at the keyboard
or every system will have to provide it anyway. Obviously, this translates
to that every system will provide one, since no one's going to force the user
to type it in. If every system is going to provide it, we might as well
standardize on it so people can know what they're getting. If particular 
dialects want to offer additional options, well, ... you're no doubt aware
of my feelings on this issue and i'll spare the cc'd folks for now.