shared-text substrings, start/end indices, xs><, etc.
shivers@xxxxxx
(25 Jan 2000 01:02 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
(28 Jan 2000 12:41 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