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.
From: sperber@xxxxxxxxxxxxxxxxxxxxxxxxxxx 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