AFAICT r7rs will have two parts; a small core one (based on r5rs, with the additional features mentioned in the post), and a larger one building up something like a standard library (possibly including r6rs).
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.
Agreed. This report sounds like a (much needed) 5.1 rather than a major leap. I wonder if the community will ever accept anything more radical than this in the future.
Keep in mind that what you see on that Draft is just for the "small language", which is being worked on by the "Working Group 1". Then there is "Working Group 2" which is going to take care of building a standard library of non-core features. This means that R7RS in it's whole is going to be more than R5.1 -- but the separation is needed imo is wide adoption is desired.
This comes across as odd. I remember the brouhaha over R6, and many people weren't happy over it. I thought most people have got over it and adopted it. So why is R7 built on top of R5? None of the names on the report are known to me. Is this an "official" report? Is there such thing as an official report?
