Shiro Kawai scripsit:

> Especially, the cluster splitter as specified in UAX#29 requires
> lookahead and such splitter could be implemented more efficiently if
> we allow keeping states,

I forgot to mention that this would require the mapping functions to
be performed in sequence order, in which case keeping state within the
function is no problem.

> Clustering algorithm can be provided as generators (e.g. Text -> (()
> -> Grapheme) or Text -> (() -> Word), etc.).  Such generators can be
> combined with generator mapping operators freely, and covers use cases
> of the proposed generalized text-map etc.

And of course such procedures don't have to be provided in this SRFI.

If that argument is convincing to Will, then I'd argue for flushing the
whole map & fold section as more misleading in a Unicode age than useful.
There might be an argument for textual-remove as a squelch function for
dangerous codepoints in secure code.  But in general, treating a string
like a sequence of codepoints doesn't make it one.  "How many legs does
a horse have if you call his tail a leg?"  Answer: "Four; calling a tail
'a leg' doesn't make it one."

In any case, textual-reverse should be flushed.  I retained it in SRFI 130
solely for backward compatibility with SRFI 13.  (List) reverse is used
all the time, and vector-reverse is the topological flip operation, but
string-reverse is nonsense, useful only when you don't want to remember
how to spell "sdrawkcab".

> (The only cases it can't cover is when you want to switch granularity
> as you consume input.  I assume it's rather rare case, though.)

I assume so too.

--
John Cowan          http://www.ccil.org/~cowan        xxxxxx@ccil.org
    "Mr. Lane, if you ever wish anything that I can do, all you will have
        to do will be to send me a telegram asking and it will be done."
    "Mr. Hearst, if you ever get a telegram from me asking you to do
        anything, you can put the telegram down as a forgery."