On Mon, Dec 7, 2015 at 10:25 AM, John Cowan <xxxxxx@mercury.ccil.org> wrote:

Shiro Kawai scripsit:

> (span-substitute span pattern replacement) - replace occurrence of
> pattern span by replacement span

It's omitted on purpose, as I didn't want to make this library dependent
on a regex library.

What I meant by 'pattern' is just another span. It's a convenience

procedure, can be written on top of span-contains and subspan looping

over entire range, but the implementation is a bit longer than one-liner

and I may wish to have that idiom packaged.

Yes, the purpose of -join is primarily convenience, not efficiency.
Inserting spaces or commas between items in a list is something that's
frequently done.

Unfortunately we don't have list counterparts in srfi-1, but for example

Gauche has intersperse (like Haskell's) and (span-join list delim) can

be written as (span-concatenate (intersperse delim list)).

We can still have it, but reframing the srfi as cheap text section/concatenation

instead of just a proxy of immutable substrings, join operation seems less

important to me.

> - I doubt individual character-level operations such as -filter, -remove,
> -partition is as useful in the context of high-level text manipulation.

I actually doubt they are useful at all, since they basically treat
strings and spans as character bags. That may make some sense for strings
because of their literal form and typically compact representation,
but not really for spans. I'll remove them from the next draft.

How about span-map, span-for-each, and span-fold(-right)? They can be

justified by that they can't be simply lifted by span-transform. However, viewing

spans (or cords) as tree of fragments, I think the more important one

is to map on each fragments.