Ray Dillinger scripsit: > If we want to drop a feature that basic, then surely we should first > deprecate it and move it to a library (R7) and second make the library > optional (R8) so that its eventual absence does not come as a shock > to users.
As noted, that's what R6 did. > In the case of mutation operators in particular, people will just > write a "portable string-set!" library in terms of vectors or lists, I took a look at the SRFI-13 reference implementation to see what use it makes of string-set!, and the use is basically only for creating strings a little at a time. In general, the code allocates fixed-length strings and then uses string-set to construct them. In such circumstances, the general Builder pattern works well: have a mutable builder object which can be configured, and then a build operator that constructs from it an immutable object for all further use (the builder can then be discarded). > and then we will have many incompatible kinds of incompatible strings > to go with our many incompatible object systems. To discourage such proliferation, it would be sensible to add string->vector and vector->string to the small Scheme core. This follows the Builder pattern, with the former procedure constructing the builder and the latter constructing the immutable final result. > The point about strings having formerly enjoyed a 4:1 storage > advantage (8 vs. 32 bits) and 21-bit characters being a better fit > to 32-bit words? Firstly, irrelevant. [...] Secondly, incorrect. > [...] Thirdly, it's growing more incorrect. [...] Quite right on all points. I have removed this argument from the living version of the document, accessible from the link at the bottom of http://tinyurl.com/thing-one . >From a later posting: > 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. Indeed. > We could move all the character and string operations to libraries > and make bytevectors primitive The only reason blobs aren't part of the core in my small Scheme proposals is that they *can* be emulated with general vectors. I would hope that a small Scheme implementation would support them directly, though, and I intend to write a SRFI about them. > (and I'd recommend it if I could figure out how to make the _syntax_ > for string and character literals importable from a library). I've struggled with that too. See my proposal for semi-scoped extensible syntax; it's linked at the bottom of http://tinyurl.com/thing-one . > 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. Absolutely. Even if there was only one known encoding of characters (which has never been true, ever), it would be data punning: bytes are not really the same semantic domain as characters. -- If you have ever wondered if you are in hell, John Cowan it has been said, then you are on a well-traveled http://www.ccil.org/~cowan road of spiritual inquiry. If you are absolutely [email protected] sure you are in hell, however, then you must be on the Cross Bronx Expressway. --Alan Feuer, NYTimes, 2002-09-20 _______________________________________________ r6rs-discuss mailing list [email protected] http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
