READ on socket streams can block bogusly

[Nikodemus Siivola]

If the stream has "(foo)" in it, without any following whitespace and the socket remains open, READ will block while trying to READ-CHAR ahead to see if there is any whitespace to discard.

It should probably use (when (listen stream) (read-char ...)) instead of plain read-char.

[Wayne Iba (wayne-iba)]

In the case of having just read a closing paren, read probably shouldn't read anything more. If the next char turns out to be an open paren for the next list or some other character representing the beginning of a number or symbol, the reader will have to unread the char. Since a conditional check needs to be made one way or the other, why not check if a right paren closes the expression currently being read and, if so, be done with it? Since a closing paren delimits a list (whether or not whitespace follows), it strikes me that whitespace following the closing paren should not be consumed by read, even though it appears the spec would allow it.

[Wayne Iba (wayne-iba)]

OK, I take it back. I'm persuaded that (read stream) should consume any and ALL whitespace that might be there following a read object. That is, upon finishing reading something, consume all whitespace until (listen stream) returns false or until the start of a new object is reached. Unfortunately, the spec seems to leave this open and implementations seem to consume one whitespace character (when present). Since (read-preserving-whitespace) is available when needed, (read) should consistently consume all whitespace leaving the read-pointer at the end of the stream or at the next item.

Is there a rationale for consuming only one whitespace character? The different behaviors of different implementations while reading from socket streams is making life interesting.