>>>>> "Olin" == shivers  <xxxxxx@ai.mit.edu> 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