This is the mail archive of the guile@cygnus.com mailing list for the guile project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
> > > This bit of code seems to demonstrate a bug with shared substrings. > Can > > > someone confirm this, or else point out my mistake? > > Thanks for the bug report, and the patch. I've simply changed > string-set! to signal an error if the string argument is not a > writeable string. In other words, the function `bug' in John > Redford's example is not correct Guile code, because you cannot modify > shared substrings. > > I think Guile shouldn't have a substring-set! function. The original > reason for making substrings read-only was to allow code to use > make-shared-substring without fear that the consumer of the shared > substring would munge it and wipe out the original. Code should not > use make-shared-substring unless it can show that the original string > will not be munged. > > These rules are pretty complicated, which is why I would like, in the > future, to get rid of make-shared-substring, and make all substrings > shared, with copy-on-write handling to preserve the appearance of > separate objects. > Good enough then. But this leaves me with a naive Scheme question. What is the closest way in Scheme to approximate C's space & time efficient iteration over the elements in a mutable string? string->list/list->string are very elegant, but don't seem to have the right properties. I can imagine this role being filled by an efficient implementation of string->vector or mutable-string-as-vector. The former name is better, but I dot think anyone would expect vector-set! to modify the string as well; still, it would be better than string->list for immutable or copy-on-write strings. So, am I missing something? Should I just write a function C if I want better performance? Is there already some way to do this? If this sounds like a good idea, I can start working on a patch to implement something of this sort. Intuitively, I suspect that vector representation of strings would be friendlier to wide character encodings as well.