Alaric Snell-Pym scripsit: > > 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.
I'll give my views on binary I/O in a later posting. > > Maybe not even bitwise logical operators. They are easily layered over bignums, which are layered (with some loss of space efficiency) over fixnums. Or bignums can be layered over blobs, as the old Unix implementation of dc(1) did, with its base-100 bignums. > > (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. R6RS bytevectors are in fact such blobs; apparently someone thought the name "blob" (used in SRFI 74) unattractive or otherwise undesirable, despite its well-established status as a technical term. > [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. Tom Lord scripsit: > Suppose that WG1 Scheme requireds regular vectors, a way to create > disjoint types, and fixnums. Then it is possible for library-code to > define objects with the semantics of bytevectors, though lacking an > assurance of a compact representation for these. As an adjunct to > the core specification (by appendix or via inclusion by reference) > bytevectors can be given a (usable, not optimal) definitional > implementation. I agree entirely, which is why I removed blobs from my Thing One proposals. -- Normally I can handle panic attacks on my own; John Cowan <[email protected]> but panic is, at the moment, a way of life. http://www.ccil.org/~cowan _______________________________________________ r6rs-discuss mailing list [email protected] http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
