Re: [Scheme-reports] Bytevectors should be called u8vectors

[Alex Shinn <alexshinn@x>]

On Mon, Jul 2, 2012 at 4:12 PM, Peter Bex <Peter.Bex@x> wrote:
> On Sun, Jul 01, 2012 at 06:59:33PM -0400, John Cowan wrote:
>> > I also find the names bytevector-u8-ref and bytevector-u8-set!
>> > very clumsy and verbose compared to u8vector-ref and u8vector-set!.
>>
>> http://trac.sacrideo.us/wg/wiki/BlobAPI , which was reviewed but not
>> adopted by WG1 (it may become part of R7RS-large, however) proposes two
>> sets of names, one of the form bytevector-<type>-ref which is indexed
>> by byte index, and one of the fomr <type>vector-ref which is indexed
>> by element number and is SRFI-4 compatible.  In the case of u8 and s8
>> these of course coincide.  However, it would be very inconsistent to
>> use u8vector-ref in the small language, where u8 is the only access type
>> directly supported.
>>
>> I am therefore closing this ticket.
>
> What's the point of opening a ticket and then immediately closing it
> again?  Can you even *do* that without input from the other members?

Other members are free to re-open the ticket, but I
think it would be better if we left the tickets open.
When drafting the ballot I review re-opened tickets
to see if there is sufficient grounds for revisiting them,
and other people may make the same complaint in
the meantime.

Although to be honest for this particular ticket I'd
be unlikely to put it on the ballot again.  We spent
quite a lot of time debating this already, and there
is no way we can make everyone happy.

To be clear, this is not just a naming convention,
but an API philosophy.  In R7RS large we will
_not_ be providing a SRFI-4 API, but instead be
following the R6RS style (i.e. bytevector-u32-ref
on the same underlying bytevector data type
instead of a new u32vector data type).  The
reasons for this were too many to summarize
right now - I'll have to leave that to a rationale
document.

Implementations which support it are still free to
(import (srfi 4)), which could in fact be built on
top of bytevectors (modulo read/write representations).

-- 
Alex

_______________________________________________
Scheme-reports mailing list
Scheme-reports@x
http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports