On 3/8/20 2:58 PM, John Cowan wrote: > By the same token (and this is why I have also copied xxxxxx@ on this email), incorporating SRFI-140 into R7RS-large violates the charter requirements, in my judgment. Charter requirements are less of a concern to me that what is better for the Scheme language and community in the long run. > The value of (string-set! (string-upcase (string #\a \#b \#c) 1 #\!) is defined by R7RS-small as "A!C". But in a SRFI-140 world, string-upcase returns an immutable string and so the string-set! call fails. I guess it is *possible* to write a correct and meaningful program that that calls string-set! on the result of string-upcase but I find that very hard to conceive of. So I think the concern with breaking program is valid, but string-upcase is ulikely to be an issue. While breaking old programs is unfortunate, srfi-140 is the best kind of incompatibility: Programs break cleanly (compile-time or run-time type-checking rather than wrong result or hard-to-detect performance degradation); the fix is local and trivial (usually add a call to string-copy); and the fixed programs work fine on older implementations. In my limited experience after making strings by default immutable, there were very few places I had to fix my code. It would be helpful if someone had larger programs that use strings, and tried running then with srfi-140 - perhaps using Kawa. I'd like to know if you had to change much, and if it was difficult to do so. On 3/9/20 12:42 AM, Marc Nieper-Wißkirchen wrote: > I agree with the problem the SRFI 140 string procedures have. The base language (R7RS-small) would have to be evolved first. The approach to call immutable strings something else (like `text's) seems the best way out. That would be an absolute disaster. It would break *every* existing string-using program, not in the sense of no longer working, but in the sense of using a deprecated/obsolete API, as well as performance issues for programs that are not updated. How do you visualize the state of Scheme if the new standard recommends text-upcase etc in place of string-upcase etc? How will tutorials and other documents be changed? Who will change their existing programs to use the new text-xxx APIs? My guess is almost nobody. Either leave strings R7RS-large unchanged from R7RS-small (perhaps with a deprecation warning), or some variant of srfi-152 (also perhaps with a deprecation warning), or go with srfi-140 (possibly with some tweaking). srfi-135 would be a disaster, IMO. -- --Per Bothner xxxxxx@bothner.com http://per.bothner.com/