[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Olin> SRFI-13 is trying to walk a third path. I'm not willing to *require*
Olin> shared-text substrings. That's just not going to happen out there in
Olin> Scheme-land, at least we can't just mandate it. I'm just trying to
Olin> allow people to write portable code that can run reasonably
Olin> efficiently across a wide range of platforms -- some with shared-text
Olin> substrings, some without.
But efficiency is not the only issue here: One might want shared-text
substrings for structural reasons.
Absolutely! One might want shared-text substrings for structural reasons. I
would. SRFI-13 doesn't give you this. It cannot do so without *requiring*
shared-text substrings. That's not going to fly.
I believe a specifically shared-text substring library is a valuable thing,
and should be designed and made into a SRFI. But remember that most Schemes
today do not provide shared-text substrings, so as soon as you start coding
to this API, you punt portability.
On the other hand, *optional* shard-text substrings make for very difficult
debugging, especially if your base implementation does not support them.
No it doesn't. Programmers do not have to use the shared-text-allowed
routines, ever. There are pure-copying alternatives for every
shared-text-allowed routine. So you can avoid using them except in the
cases where you know it's worth it, or there's a clear-cut opportunity
for optimisation that can be exploited by essentially annotating your
calls with the shared-text-allowed tag.
An analogy: Some list routines (e.g., FILTER) are allowed, but not required,
to share substructure when convenient and efficient to do so. The
shared-text-allowed routines give you the same ability in string processing.
And you want this ability. Redundant string copying is an irritating source of
inefficiency when coding.