On 15-May-05, at 9:15 AM, Michael Sperber wrote:

>
> ... it'd be really nice if you could respond to:
>
>>>>>> "Moiself" == Michael Sperber
>>>>>> <xxxxxx@informatik.uni-tuebingen.de> 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.

Marc