Email list hosting service & mailing list manager

shared-text substrings, start/end indices, xs><, etc. shivers@xxxxxx (25 Jan 2000 01:01 UTC)
Re: shared-text substrings, start/end indices, xs><, etc. sperber@xxxxxx (25 Jan 2000 07:47 UTC)
shared-text substrings shivers@xxxxxx (25 Jan 2000 16:06 UTC)
Re: shared-text substrings sperber@xxxxxx (25 Jan 2000 16:54 UTC)
Re: shared-text substrings shivers@xxxxxx (25 Jan 2000 17:15 UTC)
Re: shared-text substrings sperber@xxxxxx (25 Jan 2000 17:54 UTC)
Re: shared-text substrings shivers@xxxxxx (25 Jan 2000 19:18 UTC)
Re: shared-text substrings sperber@xxxxxx (26 Jan 2000 07:30 UTC)
Re: shared-text substrings, start/end indices, xs><, etc. d96-mst-ingen-reklam@xxxxxx (27 Jan 2000 13:54 UTC)

Re: shared-text substrings sperber@xxxxxx 26 Jan 2000 07:30 UTC

>>>>> "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