Re: Bug in shared substrings?

[Jim Blandy <jimb@red-bean.com>]

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

Yeah, string->list are not really the right primitive.  You shouldn't
have to write a C function for something as simple as this.  I think
the official Scheme solution would be to maintain an index, as in:

(define (replace-x! text)
  (let loop ((start 0))
    (let ((next (string-index text #\X start)))
      (if next (begin
                 (string-set! text next #\_)
                 (loop next))))))
 

Hmm.  The "shared substrings are read-only" is certainly the thinking
we've had in the past, but I can see how they make a graceful solution
to what you're trying to do too.  One of the intended uses of shared
substrings was to make string manipulation functions also useful to
callers who only want to work on regions of a string.  Efficiency is
one issue, but side effects would certainly be nice to have as part of
the repetoire.

Maybe we should revisit the decisions we made about how shared
substrings behave.  I hope this list will let me know if I'm going
astray, but it seems to me that, if we had a fast copy-on-write
substring implementation, then we could safely make explicitly shared
substrings writable, because people wouldn't need to use it unless
they wanted the mutation-from-abroad effect.