+1 for immutable strings. From: Ray Dillinger <[email protected]> Subject: Re: [r6rs-discuss] Proposed NON-features for small Scheme, part 8: string-set! must die Date: Sat, 19 Sep 2009 02:41:45 -0700
> On Sat, 2009-09-19 at 01:24 -0400, John Cowan wrote: > > This is a proposal for the removal of string-set! (and consequently > > string-fill!) from the R7RS small Scheme language. > > > While I certainly think that string-set! is in fact unnecessary, > I do not agree that it should be immediately removed. I'd support > moving mutable-strings to a library rather than keeping them in the > core language, but the world is not yet ready for scheme without > mutable strings. [...] > 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. We've already cleared step 1; in R6RS string-set! and string-fill! are *already* in a separate library (rnrs mutable-strings) which is not imported if you just say (import (rnrs (6))). > There is not a widespread scheme that has no string-set!, nor a > large body of scheme code that is known to run well without it. Right. But Gauche has deprecated string mutation from the beginning (it costs O(n) for every string-set!, since Gauche's string is just a pointer to a immutable string body and every mutation requires copying the body), and we've lived happily in that world for years. I remember a couple of times I rewrote the part using string-set! with string ports when porting third-party libraries. I haven't yet seen a nontrivial usage of string-set! that can't easily be replaced for string ports or using a vector then converts it to a string. > In the case of mutation operators in particular, people > will just write a "portable string-set!" library in terms of > vectors or lists, and then we will have many incompatible kinds > of incompatible strings to go with our many incompatible object > systems. It is a valid point. However, I'm optimisitc that it can be solved by a "text srfi" that implements generic mutable text on top of mutable strings. Especially such library would allow length-changing mutation. > Thirdly, it's growing more incorrect. Since new computers > these days use 64-bit pointers, the advantage of packed UTF8 > strings over general vectors is rapidly shifting to 8:1. Good point. This also supports using packed utf-8 string (or using several different representations according to the characters, e.g. ascii-only, 2octet-per-char, etc.), which favors immutable strings. From: Peter Bex <[email protected]> Subject: Re: [r6rs-discuss] Proposed NON-features for small Scheme, part 8: string-set! must die Date: Sat, 19 Sep 2009 13:01:25 +0200 > Agreed. It makes a whole lot of sense for ASCII-only implementations > (which should be allowed by Thing One, I believe ~everyone agrees on) > to supply a string-set!. Why wouldn't they, it's a cheap operation in > such an environment. Also, ASCII-only schemes would probably be the more > minimalistic ones, which likely are used in systems programming, where > string-set! can still be quite a useful operation. 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. --shiro _______________________________________________ r6rs-discuss mailing list [email protected] http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
