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 [email protected] hands thoroughly before going to the toilet. http://www.ccil.org/~cowan --gadicath _______________________________________________ Scheme-reports mailing list [email protected] http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports
