Alex Shinn scripsit:

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

Correct, at the expense of string mutation, which seems to be little used
(there are only about five references to it in the Chicken source, excluding
of course the implementation of string-set!, string-fill!, and of SRFI 13).

> Given 1, you could be more aggressive with 2 by providing e.g. ropes,
> though this increases implementation complexity, makes FFIs more
> difficult (e.g. it's easier to pass a span to PCRE than a rope), and
> introduces the possibility that a given substring operation isn't actually
> cheap (if you need to copy many links in the rope).

This SRFI doesn't exclude those, but of course cursors would have to be
more complicated.

> So I think starting with spans and letting implementations experiment
> I agree the name is confusing,

What would you suggest?  I'd be fine with "istring", though it perhaps
put the emphasis on what is lost rather than what is gained.

--
John Cowan          http://www.ccil.org/~cowan        xxxxxx@ccil.org
Normally I can handle panic attacks on my own; but panic is, at the moment,
a way of life.                 --Joseph Zitt