John Cowan wrote:

> I think my suggestions for saving the
> mapping procedures probably don't make sense: they were based on
> some false assumptions, and I revert to the more radical position
> that the mapping procedures should simply be flushed.

I would like to reduce the number of mapping procedures, but
some of them remain useful for special situations in which
you know a text consists entirely of ASCII characters or the
characters of interest can be processed independently.

By the way, allowing the procedure being mapped to return a
character or string or text makes the map procedures more
useful.  If map were guaranteed to proceed left to right,
the procedure being mapped could buffer characters whose
interpretation might be affected by subsequent characters,
and delay its decision by returning an empty text.  Adding
a sentinel at the end to flush the buffered output could
be done cheaply with texts because textual-concatenate is
fast.

> Note that R7RS requires that if `read` supports a syntax, so must
> the language processor, so your last two suggestions should be
> combined.

Thank you for catching that.

> Also, I think the
> constructors should all have "text-", not "textual-"; they don't accept
> textuals.

Thank you for catching that one too:

    textual-tabulate        reverts to    text-tabulate
    textual-unfold          reverts to    text-unfold
    textual-unfold-right    reverts to    text-unfold-right

> 1) You might want to include text-titlecase based on SRFI 129.

Will do.

> 2) Perhaps there should be a kernel that guarantees O(1) running
> time for subtext, if possible.

I don't know how to implement that in combination with the
other performance requirements.  In particular, I don't
know how to implement it without retaining too much of the
original text.  If you can tell me how, I'll do it.

> 3) The optional arguments of textual-concatenate-reverse make
> little sense in an immutable text world: if they are to be kept,
> the "textual-final" option should be changed to a string.

I am unaware of a world in which they make sense at all, but
they're in SRFI 135 because they're in SRFI 130.  SRFI 135
does allow the "textual-final" option to be a string, so I
think that part of your suggestion is already present in the
current draft.

Will