On 21 Sep 2009, at 8:40 am, Brian Harvey wrote: >> I don't know about you but I *do* regard strings primarily as >> text intended for human readability > > +1
+1 from me too. > Does anyone think that bytevectors are a necessary feature of WG1 > Scheme? Not me. > I can see why WG2 should have both strings and bytevectors, but WG1 > shouldn't > (imho) include anything about bytes, binary, etc. Maybe not even > bitwise > logical operators. (Of course all that stuff will be loadable as > optional > libraries, like the rest of WG2's features.) I know where SRFI-4 is when I want it (I see no need for a special "bytevector" type). FWIW, though, I do think there's some value in a low-level and optional mechanism for representing a block of memory, without attaching any particular semantics to it. Let's call it a blob. There would be no blob-ref; if you want to access it as bytes, you do "(make- u8vector-aliasing-blob <blob> [<offset> <length> [<endianness>]])" to get an SRFI-4 byte vector (endianness is a bit moot for u8s, but included for consistency with the corresponding procedures for u16 and up, and it defaults to platform endianness), or "(make-record-aliasing- blob <blob> <fields> [<offset>])", where <fields> is some list of field descriptions documenting the layout of a binary structure. This sort of arrangement helps a lot when dealing with file formats and the like. Perhaps even "(make-string-from-blob [blob] [encoding] [<offset> <length>])". When I have some free time, I plan to write an implementation of it for Chicken, that allows the underlying blobs to manage their own storage so it's easier to interoperate with C code via the FFI without needing to copy large blocks of memory into and out of the GC heap; I'd hope to spit an SRFI out when I have a working implementation... ABS -- Alaric Snell-Pym Work: http://www.snell-systems.co.uk/ Play: http://www.snell-pym.org.uk/alaric/ Blog: http://www.snell-pym.org.uk/archives/author/alaric/ _______________________________________________ r6rs-discuss mailing list [email protected] http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
