[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: shared-text substrings

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