From: xxxxxx@informatik.uni-tuebingen.de
   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.
    -Olin