This is a consolidated response to a few points in people's messages: Peter Bex scripsit:
> 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. Even in an ASCII-only Scheme, there are still the same concerns as before with sharing, either between procedures or between threads. With any mutable object, the question "Who owns it?" must be asked and answered. Shiro Kawai scripsit: > Gauche has deprecated string mutation from the beginning (it costs O(n) > for every string-set! [...]) Wow. > 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. One reason that I want string ports to be a core part of Thing One, even if file ports are not present. > 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. I assume that you mean "immutable strings". Taylor Campbell has sketched just such a library at http://mumble.net/~campbell/proposals/new-text.txt . His version is a bit too general for my taste (he allows that the primitive unit of strings may *not* be characters, but bytes or something between), but it gives a good indication of what one might want. Brian Mastenbrook scripsit: > I'll add another reason for getting rid of mutable strings, as well as a > rejoinder to reason #4: I've used this to replace my reason #4, and also to supplement reason #2, which now talks of gap buffers as well as ropes. > I shouldn't have to use `string-copy' for this; my implementation should > do it for me. If there's no user-exposed backpointer from the substring to > the original string, the GC can dispose of the original string and copy > out the retaining displaced substrings when it makes sense to do so. Nevertheless, few extant GCs do so, notably not the Boehm conservative GC. So string-copy is a kludge, but a useful kludge. > There's really no sense to providing a copy operation for an immutable > type. That's rather strong. The proposed strings are immutable but not interned; two strings that are equal? may still not be eqv?. -- Is not a patron, my Lord [Chesterfield], John Cowan one who looks with unconcern on a man http://www.ccil.org/~cowan struggling for life in the water, and when [email protected] he has reached ground encumbers him with help? --Samuel Johnson _______________________________________________ r6rs-discuss mailing list [email protected] http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
