From: Tom Lord <xxxxxx@emf.net>
    * A reasonable alternative is to have two SRFI's: One, a
      string library without ubiquitous index parameters and
      without "substring/shared", the other, a SRFI for
      "substring/shared" in which that procedure is guaranteed to
      return a value which shares state with its primary string
      argument.

SRFI-13 is trying to walk a third path. I'm not willing to *require*
shared-text substrings. That's just not going to happen out there in
Scheme-land, at least we can't just mandate it. I'm just trying to allow
people to write portable code that can run reasonably efficiently across a
wide range of platforms -- some with shared-text substrings, some without.
It's not acceptable to say "Those who want to use Scheme for hyper-efficient
string processing are thereby encouraged to choose an implementation or
environment which supports shared substrings." There are many reasons why
someone might be limited to a particular Scheme implementation; that person
might still need to write efficient code, even if his implementation doesn't
provide shared-text substrings.

		containing-string string => string start end

	  which converts a shared substring to its parent string and
	  indexes, and an ordinary string to itself, 0, and its
	  length.

I think others have beaten on this idea enough. It's none of my business
from where a particular string came; I should just deal with it as a string.

	  It is important that "substring/shared" return a truly
	  shared substring so that side effects on its result are
	  reflected in its argument.  That propagation of side effects
	  is an essential part of using shared substrings to write
	  code which manipulates strings efficiently.

Not within the charter of SRFI-13. Should be handled by a specifically
shared-text SRFI. Basically, Tom, you are saying that you want
shared-text functionality, because it's really good stuff. Agreed.
But SRFI-13 has lower aspirations. SRFI-13's /SHARED prefixes *allow*
the system to use shared-text, but they don't *require* it. You lose
some efficiency... but gain the ability to run correctly in *non*-shared-text
systems. Again, a shared-text string library *should* be defined, *after*
we put SRFI-13 to bed. Perhaps you should lead the effort!

    From: "Sergei Egorov" <xxxxxx@informaxinc.com>
    Shared substrings are practically unknown to
    the Scheme community and, even if they are
    implemented somewhere, I see no reason to
    make incompatible changes to the semantics
    of SUBSTRING (adding SUBSTRING/SHARED is
    definitely a better idea, but why put normal
    and /SHARED versions in one SRFI?).

OK, a message from the other camp!

As you have probably seen lately, shared-text substrings have rabid fans
in the guile community. I am among them, but that's not important. What's
important is that I allow for people to code in a way that will be portable
across shared-text and non-shared-text systems, but still leave open
opportunities to gain efficiencies in either case.

I am absolutely not interested in requiring shared-text substrings for
SRFI-13. A shared-text library is a whole other task, one which could not
be provided portably in Scheme 48, or Bigloo, or many other important
Scheme implementations. This is not what SRFI-13 is about.

    From: David Rush <xxxxxx@netscape.com>
    Shared-substrings are a separate data type in other languages for good
    reasons (I can't speak to Guile's issues, I use Guile, but I didn't even
    know they were there, the documentation *is* being rewritten), the
    simplest being that they have different lifecycle issues from 'full'
    strings.

    Of course, because Olin is very clever, this will be mostly invisible
    to the casual user of the library. I just feel very strongly that this
    can be better treated in a shared-substring SRFI, which will probably
    never get written if most of the functionality is already avaiable in
    this one.

Shared-text substrings are typically a subtype of general strings in most
Schemes I know that provide them. But SRFI-13 is not going to prevent a
shared-subtext SRFI from being developed, because there is a lot of stuff
you would provide in such a SRFI that is not in SRFI-13. (For starters,
a way to *reliably* even *make* a shared-text substring...) See old T
manuals for examples.

Oleg has proposed using an XS>< selector for marking substring arguments
to string procedures. This relies on the mythical "suitably optimising
compiler," a beast that featured prominently in many CommonLisp discussions.
With a suitably optimising compiler, we don't even need XS><, we can just
use SUBSTRING.

But there are no suitably optimising compilers. So no go.

The START/END indices can be used to efficiently bound operations on strings
without magic compiler analyses or shared-text substrings. That's why they are
there.
    -Olin