This page is part of the web mail archives of SRFI 66 from before July 7th, 2015. The new archives for SRFI 66 contain all messages, not just those from before July 7th, 2015.
On 15-May-05, at 9:15 AM, Michael Sperber wrote:
... it'd be really nice if you could respond to:"Moiself" == Michael Sperber <sperber@xxxxxxxxxxxxxxxxxxxxxxxxxxx> writes:Moiself> I haven't done anything yet wrt. the naming issue---that's still Moiself> pending. I'd like to hold a little poll. For that, it'd be helpful Moiself> if the camp in favor of "u8vector" could suggest names for what'sMoiself> currently READ-BYTE, READ-BYTES, and READ-BYTES-N in SRFI 68.
First let me say that I dislike the read-bytes/read-bytes-n API proposed in SRFI 68. Programmers expect binary I/O to be fast, but that API requires the allocation of a new byte vector on each call, and this will have a negative impact on the throughput that is achievable. A better API is to have the client code (user program) allocate a byte vector buffer, and have procedures that read octets into this buffer at a specific position. For example:
(read-subu8vector! buffer start end)This procedure would read octets into the u8vector "buffer" starting at index "start" and ending at index "end", and return the number of octets read or end-of-file (or #f) when at end-of-file. A similar read-substring! would exist for reading blocks of characters into a string. Note that this API also supports I/O on non-blocking ports (it would be possible for the result to be less than "end - start" anywhere, not just when limited by the end-of-file).
As for read-bytes/read-bytes-n, if you keep that API, the names read-u8vector and read-u8vector-limited sound fine to me. The procedure read-byte would be read-u8. Future extensions of SRFI 68 could provide read-u16, read-u16-be, read-f64, etc. as suggested by Per.
Marc