Alex Shinn scripsit:

> As I understand, the SRFI is attempting to do two orthogonal things: >
> 1. provide a cursor-oriented API for strings (to account for non-O(1)
     indexing)
> 2. provide a cheap substring API (to remove the optional start/end-arg API hell)

After a good deal of reflection and muddling, I've realized that making
these two fit into one SRFI is going to be troublesome.  I have therefore
abandoned objective 1, substring sharing, in favor of objective 2,
efficient sequential access to characters in strings.

Draft #2, soon to be posted, provides string cursors plus a set of
SRFI-13-style string operations that use cursors rather than indexes.
As it does not introduce a new string-style data structure, it is
considerably smaller than Draft #1 and has no overlaps with SRFI 13.
It is also smaller than SRFI 13, and there is probably a case for
making it smaller yet.  (Does string-map really make sense in a Unicode
environment where it cannot do case mapping?)

At some future time, I'll probably create a SRFI for
text trees (non-disjoint immutable objects that are either strings
or lists of text trees).  Some possible sources are Gauche text.tree
<http://practical-scheme.net/gauche/man/gauche-refe_197.html> and Taylor
Campbell's API <http://mumble.net/~campbell/proposals/new-text.txt>.

I look forward to more commentary from the usual suspects.

--
John Cowan          http://www.ccil.org/~cowan        xxxxxx@ccil.org
You cannot enter here.  Go back to the abyss prepared for you!  Go back!
Fall into the nothingness that awaits you and your Master.  Go! --Gandalf