On Fri, Jul 20, 2012 at 4:18 AM, Andy Wingo <wingo@pobox.com> wrote:
> On Thu 19 Jul 2012 02:16, Alex Shinn <alexshinn@gmail.com> 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
Scheme-reports@scheme-reports.org
http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports