Re: Notes about (^ revised 3) report

[willc%tekchips.tek.csnet@CSNET-RELAY.ARPA]

Here are the answers I prefer to KMP's starred questions; words within
brackets were edited by me.

 * Does the [port] become closed as a side-effect of hitting eof?

No.

 * Is it an error to read from a closed [port], or does [an eof-object]
   just keep getting returned?

It is an error.

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

Yes.  Yes.  Yes.

 * Is it possible to detect whether a [port] is closed?

Impossible using only the procedures documented in R^3RS.  I'd like the
language to remain silent on whether a closed port is still a port.

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

Yes.

KMP:
    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.

To some extent I agree with this, but I don't think READ-CHAR? by itself
is any better for multi-processing than CHAR-READY?.

Peace, Will