On 21 Sep 2009, at 5:14 pm, John Cowan wrote: >> [I]f 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. > > I prefer a lower level (on top of which both of these are easily > layered) > like that of SRFI 74 or R6RS, which says "get/set at a specified byte > offset, a value of <type>". More details in a later posting, > hopefully > to become a SRFI.
Yes, that is a valid way of implementing a binary-interop system as a basic mechanism plus a layer that gives you arrays (and structs and arrays of structs with arrays in etc), just as long as the end user gets a nice high level API like that to play with, perhaps after installing a library to give them it, rather than having to do things in unpleasant or implementation-optimisation-hurting ways such as implementing everything themselves on top of raw bytes ;-) *looks at R6RS bytevectors* Yes, they look OK... as a blob type ;-) bytevector definitely implies u8vector to me! 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
