On Sat, 2009-09-19 at 01:49 -1000, Shiro Kawai wrote:
> We *should* use bytevectors for systems programming when we
> need a mutable, fixed-length byte buffer. How much
> confusions and bugs have come because C API conflates strings
> and bytevectors into char[]? We should learn from that.
When we want a buffer of bytes for systems programming purposes,
and we have to care about things like binary representation or
encoding, we are manifestly not using that buffer as a string.
Since the word "string" has bytevectorish overloadings from
languages like C, I'll amplify: we are not using that buffer as
text that represents characters in human languages. Those
human-language characters can be mapped to binary in any way
at all, and if that doesn't matter because they still represent
the same characters, then it's text because the characters that
it represents are primary. If it does matter, then it's bytes
instead and its meaning, if any, as characters has to be
regarded as just a coincidence.
By assuming ascii representation, we were accustomed, in R5RS
scheme, to doing a bunch of binary stuff like reading JPG files,
etc, in terms of strings and character input - but that code
breaks horribly if the character representation changes, and
the "abstraction" from strings to bytevectors is a false one.
Bytevectors were new in R6RS, and badly needed for such
operations *especially* since R6 mandates unicode.
A valid abstraction from bytevectors to strings could be made;
strings can be implemented correctly in terms of bytevectors,
enforcing a choice of representation by fiat. We could move
all the character and string operations to libraries and
make bytevectors primitive (and I'd recommend it if I could
figure out how to make the _syntax_ for string and character
literals importable from a library). But abstracting in the
other direction, as we had been doing before bytevectors came
along in R6 and as a lot of older code still does, is invalid
in the presence of choices about how to represent strings.
Bear
_______________________________________________
r6rs-discuss mailing list
[email protected]
http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
