On Mon, Dec 7, 2015 at 9:17 AM, Alex Shinn <xxxxxx@gmail.com> wrote:
On Sat, Dec 5, 2015 at 8:32 PM, John Cowan <xxxxxx@mercury.ccil.org> wrote:
Alex Shinn scripsit:

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

What about "cord"?


I think it's reasonable if we emphasize not only ligthweight substring and indexing,
but rather an efficient immutable text handing based on tree of fragments implemented
on top of native strings, then I feel having a new type with mostly similar APIs justified.

If we stand on that viewpoint, I think span's (or cord's) API doesn't need to mirror
srfi-13 that closely.

- The assumption is concatenation of span being cheap, like O(1) to O(log n).
  Substring extraction may also be similar.

- For such text manipulation library, I'd like to have things like these:
  (span-replace span span2 from to)  - replace span's range between from and to with span2,
          from and to are cursors.
  (span-substitute span pattern replacement) - replace occurrence of pattern span by replacement span
  Curiously, srfi-13 has string-replace but srfi-130 doesn't.  Why?

- Given on the cheap concatenation, span-join may be unnecessary, for
  making interleaved list and span-concatenate can be just about as efficient.

- I doubt individual character-level operations such as -filter, -remove, -partition is as
  useful in the context of high-level text manipulation.  Even when we need it, we can
  lift string API to span easily by span-transform (assuming span-transform may call
  PROC multiple times if span consists of multiple string fragments).  Oh, but we need
  some tweak for multiple value handling in -partition case.