On Mon, Jul 2, 2012 at 4:12 PM, Peter Bex <[email protected]> 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 [email protected] http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports
