William D Clinger scripsit:

> SRFI 130 broke with SRFI 13 on this, so SRFI 135 can't be consistent
> with both SRFI 13 and with SRFI 130.  I chose consistency with SRFI
> 130, but that may have been a wrong choice.  Now that I think about
> it, I suspect that choice was made in SRFI 130 because returning the
> end cursor on failure is a cheap way to compute the end cursor as a
> by-product of the search.

More because I am not a fan of value-or-#f as a poor man's Maybe.  The
post-end cursor is always a valid object in SRFI 130, since it is needed
anyway to specify the largest possible endpoint.

> The arguments for text-concatenate-reverse, taken from SRFI 130, are
> already pretty funky.  I'm inclined to resist making this change
> unless there's a compelling use case, which I'm not seeing at the
> moment.

I agree with you.

I also believe that none of the "Fold & map & friends" make any
sense if treated as classical sequence functions.  Processing strings
codepoint-by-codepoint in a uniform way is too inflexible: the mapping
procedures should be passed a text representing the current position and
everything to its right, and return two values, a text to be included
in the result and a text representing the rest of the input.

As I noted on the WG2 list, I think that text-copy should force an
actual copy, not only to be able to release the string being partially
copied from if it is garbage, but also for security reasons.
This also permits copied texts to be used as unforgeable tokens:
I often create such a token today with (string-copy "whatever").

--
John Cowan          http://www.ccil.org/~cowan        xxxxxx@ccil.org
        You tollerday donsk?  N.  You tolkatiff scowegian?  Nn.
        You spigotty anglease?  Nnn.  You phonio saxo?  Nnnn.
                Clear all so!  `Tis a Jute.... (Finnegans Wake 16.5)