RE: Bug in shared substrings?

["Redford, John" <John.Redford@fmr.com>]

> > > 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.