Bruce Korb <bk...@gnu.org> writes:
> You have to go to some extra trouble to be certain that a string
> value that you have assigned to an SCM is not read only.
If you're going to mutate a string, you'd better be safe and make a copy
before mutating it, unless you know very clearly where it came from.
Otherwise, you might be mutating a string that some other data structure
still references, and it might not take kindly to having its string
mutated behind its back.
The fact that some string (whose origin you don't know about) might be
read-only is the least of your problems. At least that problem will now
be flagged immediately, which is far better than the subtle and
hard-to-debug damage might be caused by mutating a string that other
data structures may reference.
All mutable values in Scheme are pointers. In the case of strings, that
means that they're like "char *", not "char []". A great deal of code
freely makes copies of these pointers instead of copying the underlying
string itself. That's a very old tradition, because it is rare to
mutate strings in Scheme.
> If Guile were to implement copy on write, then the user would not have
> to care whether a string were shared read only or not. It would be
> easier to use.
Guile already implements copy-on-write strings, but only in the sense of
postponing the copy done by `string-copy', `substring', etc.
Implementing copy-on-write transparently without the user explicitly
making a copy (that is postponed) is _impossible_. The problem is that
although we could make a new copy of the string, we have no way to know
which pointers to the old object should be changed to point to the new
one. We cannot read the user's mind.
Mark
