Alex Shinn scripsit:

> 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.

I'm proposing providing both bytevector-u32-ref and u32vector-ref, both
of which apply to the bytevector type; the first takes a byte offset,
the second an element offset.

But nothing about the bytevector API in R7RS-large is settled except
that there will be one.

--
Yes, chili in the eye is bad, but so is your    John Cowan
ear.  However, I would suggest you wash your    cowan@ccil.org
hands thoroughly before going to the toilet.    http://www.ccil.org/~cowan
        --gadicath

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