Shiro Kawai scripsit:

> (1) We want an efficient way to specify character position in a string.
> (cursor).
> (2) In some implementations it can be as lightweight as fixnum.
> (3) Because of 2, we can't simply extend srfi-13 to take cursors as
> start/end arguments.
> (4) So either we need to duplicate most of srfi-13 procedures as
> string-something/cursor, or to introduce a new abstraction (span) that
> embeds a range in a string and duplicate most of srfi-13 procedures
> as span-something.
> (5) The latter can also eliminate optional argument handling.

This is an excellent summary which I will incorporate into the Rationale.

> If I have to choose from the above options in (4), I'd
> still prefer having more procedures on a same kind of objects
> (string-something/cursor) rather than having another kind of objects
> (span) with mostly the same set of procedures.

In isolation, so would I.  But by using a separate datatype, we not
only get rid of the optional arguments, we eliminate the special
case of mutation by not allowing mutation on spans.

> But fundamentally, I feel both ways are net loss; any addition
> of string operations would require addition of their counterpart
> (or the consistency would somewhat be lost); it includes any future
> string-related srfi, and any implementation-specific string operation
> extensions.

The only string operations we are *stuck* with are those in R7RS-small;
we do not need to further standardize or extend SRFI-13 if SRFI-130 is
adopted in place of it.

> I'll ponder this more.

Please do.

--
John Cowan          http://www.ccil.org/~cowan        xxxxxx@ccil.org
"The serene chaos that is Courage, and the phenomenon of Unopened
Consciousness have been known to the Great World eons longer than Extaboulism."
"Why is that?" the woman inquired.
"Because I just made that word up", the Master said wisely.
        --Kehlog Albran, The Profit