This page is part of the web mail archives of SRFI 13 from before July 7th, 2015. The new archives for SRFI 13 contain all messages, not just those from before July 7th, 2015.
I just doubt it's worth the tradeoff. Is there hard data that the optimizations you envision actually give significant performance gains? I've always found non-shared strings plenty fast. Let us suppose we read in a line of text, allocating a fresh string for it. We are working in a Scheme w/o shared-text substrings. We wish to trim whitespace from both ends of the string. Then we will throw away the original string, and further process the trimmed string. Let us further suppose that most of the time, strings do not have extra whitespace on the ends; we are trimming to ensure an invariant which is rarely broken by the input data. The string-trimming procedures are allowed simply to return the input string if they do no trimming. Requiring them to redundantly copy the data is bogus. It wastes space and it wastes time. It can waste a *lot* of space, if I'm processing a long, long file of data. You get into doing that, and suddenly you care that this extra copy happens. I've blown out my heap in S48 because of the *one* extra copy of a really big mother string (in cases where I read an entire file into a string, processed it with regexp stuff, and blatted output into a string port... which keeps lists of strings around, under the hood. Just one copy too many.) Copying data from one buffer to another is something that happens a lot in data processing. If you need a fresh copy, great. But if you are processing the data in a linear fashion, then you'd like to allow the underlying system to reuse storage. Which, you'll note from the above example, does *NOT* require shared-text substrings! In some cases, you can simply return the original string. This is not as generally applicable a win, but one that can be provided even in Schemes w/o shared-text substring support. My portable reference implementation of SRFI-13 has these optmisations built-in. Another example of this is STRING-APPEND/SHARED applied to some strings, all but one of which are empty. Or STRING-CONCATENATE/SHARED applied to a singleton list. When singleton lists are the common or important case, it's nice to be able to pick up the win, without having to lard your code up with explicit checks. I have code in scsh that does *exactly* this kind of thing. I have to throw in a lot of obfuscatory code, which special-cases the basic op. I'd love to be able to simplify that stuff, and be able to rely on the string system. I can't rely on having shared-text substrings -- S48 doesn't have them, and it would destroy any possibility of porting to other Schemes that lack them, in any event. You don't *have* to use these procedures. You can always, in a GC'd, functional language, play it safe and use pure functions. These procedures simply give you a portable way to write efficient code. I like to write efficient code. I have been burned using inefficient code. I didn't throw these procedures into the library from scratch, hoping they'd turn out useful. They arose from programming. -Olin