[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: shared-text substrings
>>>>> "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. [...] [...]
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