[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: If you like "u8vector" ...

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's
Moiself> 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.