[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
shared-text substrings, start/end indices, xs><, etc.
From: Tom Lord <lord@xxxxxxx>
* 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
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
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" <esl@xxxxxxxxxxxxxxx>
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 <drush@xxxxxxxxxxxx>
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'
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
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
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