William D Clinger scripsit:

> SRFI 130, as it exists today (on what I believe to be the last
> day before it enters final status), says those cursor comparison
> procedures take three arguments, the first being a string.

Don't worry about that.  Art won't finalize anything that's still being
worked on or discussed.  Currently stuff gets finalized pretty much when
the proposer says it should be.  In principle, stuff can be finalized
by Art if neither the proposer nor the list objects, but that's never
happened yet.

> So long as SRFI 130 says that, the sample implementations need to take
> that number of arguments.

I think the three-argument version was in fact a hangover from the
span implementation, where two spans might contain component strings
in different orders, and therefore cursor comparison was necessarily
relative to a specific span.  This is not true in SRFI 130 as it exists
today, and I will remove these arguments from the text.

> As for whether we really need SRFI 130, that's a different question.
> I think the better approach is to define a new data type of immutable
> texts, using strings only for those few use cases that really need
> mutation.  Immutable texts can combine O(1)-time random access with
> the spatial efficiency associated with UTF-8.  John Cowan had written
> a proposal along these lines, but he called them spans instead of
> texts and made the proposed specification more complicated than
> necessary.

Spans were meant to handle shared content as well as cursors.  Revising
SRFI 130 to do only cursors was intended as a separation of concerns:
since there are no mutation operations in SRFI 130, you can build texts
on them and just say demons fly out of your nose if you mutate the
underlying strings.

Chicken has 8-bit and UTF-8 modes, and in UTF-8 mode string mutation is
very expensive: it may require a minor GC as the object is relocated
if the new value will not fit into the old allocated space.  This doesn't
seem to be a huge problem.

> I suspect that is why SRFI 130 was written.  In my opinion, however,
> SRFI 130 doesn't do the job that needs doing.

If you don't like it, vote against it in WG2.  That doesn't affect its
viability as a SRFI.

> That test program uncovered two very old bugs in Olin's implementation
> of SRFI 13, and it might be a good idea for people who are using
> that old implementation as a starting point for SRFI 130 to be aware
> of those bugs.  Basically, Olin's definitions of string-filter and
> string-delete swapped the order of the first two arguments, and his
> definition of string-trim-right ignored the optional start argument.

I believe both bugs are already fixed in the portable.scm file in the
SRFI 130 repo.  The second one was spotted some time back by the Chicken
team, which makes heavy use of SRFI 13 in the compiler.

--
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