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.
>>>>> "Olin" == shivers <shivers@xxxxxxxxxx> writes: Olin> I just doubt it's worth the tradeoff. Is there hard data that the Olin> optimizations you envision actually give significant performance Olin> gains? I've always found non-shared strings plenty fast. Olin> Let us suppose we read in a line of text, allocating a fresh string for it. Olin> We are working in a Scheme w/o shared-text substrings. We wish to trim Olin> whitespace from both ends of the string. Then we will throw away the original Olin> string, and further process the trimmed string. [...] [...] Olin> [...] Well, sure, anyone can see what you're talking about. You still don't have hard, experimental data that all of these things will make a difference in practice. Olin> You don't *have* to use these procedures. You can always, in a GC'd, Olin> functional language, play it safe and use pure functions. These procedures Olin> simply give you a portable way to write efficient code. I like to write Olin> efficient code. I have been burned using inefficient code. But it's a fallacy that additional functionality in a SRFI hurts nobody. The sheer size of SRFI 13 will make people who need only a handful of string ops shrink away from it, and the associated complexity will make it harder to handle in practice. I'm not saying shard-text substrings aren't useful. But there's no good reason not to move it to a different SRFI. There's a clear conceptual barrier, so it'll be easy to determine which SRFIs a programmer needs. I'll do the work if you want. This SRFI tries to do too many things at once. A good indicator is the fact that the discussion period is once again exceeding the limit. -- Cheers =8-} Mike Friede, Völkerverständigung und überhaupt blabla