As far as I can see, there is still no way to do anything with a part of a string without making a copy of it first. This is a major performance problem in scheme string handling as scheme implementations usually don't (and maybe can't) check to see if an original string is ever modified so that substring can safely return a window into the existing string instead of a brand new copy of the substring.
JavaScript has the same issue (strings are immutable), and over time, implementations have taken to implementing shared substrings or ropes to handle this efficiently.
At least one Scheme implementation (Guile) had shared substrings. In fact, when I first added shared substring support to JavaScriptCore (WebKit's JavaScript implementation), I was inspired by the Guile feature.
I don't know if other Scheme implementations have chosen to optimize string manipulation, but they are certainly free to do so, and this is an issue of implementation, not spec.
That's not useful though when the regular expression libraries written to be portable across different schemes all suffer because almost none of the actual implementations optimise string handling.
It's like tail recursion elimination. It's a major gotcha unless written into the standard.
Unfortunately guile's performance in so many other areas is so bad that it's not really an alternative for some projects. It does have a lot of nice features not available in many of the major scheme implementations. But if you code to them, your code is no longer portable.
Seems like the kind of thing that'll be nice for the big language. The nice thing about Scheme is you can implement it in a weekend. You want as little as possible in it. But having standard recommended ways is a good idea. I.e. "IF you include mutable strings, this is how you do it." Maybe the big language might have that.
Comments
As far as I can see, there is still no way to do anything with a part of a string without making a copy of it first. This is a major performance problem in scheme string handling as scheme implementations usually don't (and maybe can't) check to see if an original string is ever modified so that substring can safely return a window into the existing string instead of a brand new copy of the substring.
JavaScript has the same issue (strings are immutable), and over time, implementations have taken to implementing shared substrings or ropes to handle this efficiently.
At least one Scheme implementation (Guile) had shared substrings. In fact, when I first added shared substring support to JavaScriptCore (WebKit's JavaScript implementation), I was inspired by the Guile feature.
I don't know if other Scheme implementations have chosen to optimize string manipulation, but they are certainly free to do so, and this is an issue of implementation, not spec.
That's not useful though when the regular expression libraries written to be portable across different schemes all suffer because almost none of the actual implementations optimise string handling.
It's like tail recursion elimination. It's a major gotcha unless written into the standard.
Unfortunately guile's performance in so many other areas is so bad that it's not really an alternative for some projects. It does have a lot of nice features not available in many of the major scheme implementations. But if you code to them, your code is no longer portable.
Seems like the kind of thing that'll be nice for the big language. The nice thing about Scheme is you can implement it in a weekend. You want as little as possible in it. But having standard recommended ways is a good idea. I.e. "IF you include mutable strings, this is how you do it." Maybe the big language might have that.