Chris Vine <ch...@cvine.freeserve.co.uk>: > I think better non-blocking RnRS input procedures would be advantageous > for the reasons you have given, but R6RS and R7RS seem to me to be clear > on any reasonable reading: apart from get-bytevector-some they require > blocking behaviour if the request has not been met and end-of-file has > not been reached (as do other comparable things, such as fread())[1]. > Otherwise, get-bytevector-some, for all its inadequacies, would not > have been necessary.
Well, none of Guile's blocking I/O routines block when the port is nonblocking. Thus, they are in dire violation of the strict interpretation. > I would be very surprised if it was a result of careless wording. It seems to me whoever wrote the spec wasn't thinking of nonblocking ports at all. Are nonblocking ports recognized by RnRS? Marko
