On Fri, Jul 20, 2012 at 4:18 AM, Andy Wingo <[email protected]> wrote: > On Thu 19 Jul 2012 02:16, Alex Shinn <[email protected]> writes: > >> Personally, I was baffled by the R6RS decision to >> include the "v" prefix. Given a SRFI-4-style API it >> makes sense to use a single common prefix like "v" >> since you otherwise need to take up too many >> characters for #u8, #s16, #f32, #c64, etc. Given >> an R6RS-style API there's only one blob type and >> this isn't needed. The syntax change here just >> seemed gratuitous. > > Another data point :) Guile implements SRFI-4 vectors on top of R6RS > bytevectors. So we do support the #u32(...) read syntax. It is useful > to be able to specify a vector as a sequence of u32's without regard to > endianness. > > So what happens is that bytevectors in Guile have an additional field > indicating their presentation type. For example, if "v" was created via > #u32(...) or `list->u32vector' or what have you, then that type is u32, > and they print as u32's. Regardless one can use any SRFI-4 or > bytevector accessor on any uniform vector. > > The ability to address SRFI-4 vectors with accessors of different data > types can inhibit optimization, in the TBAA sense.
Also alignment issues. The most interesting idea proposed was by Alaric, who suggested overlaying SRFI-4 style vectors onto blobs (with the restriction that they be properly word-aligned), but this was straying into invention so we took the conservative approach. -- Alex _______________________________________________ Scheme-reports mailing list [email protected] http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports
