In article <y9lg0x886xxxxxx@informatik.uni-tuebingen.de>,
xxxxxx@informatik.uni-tuebingen.de (Michael Sperber [Mr. Preprocessor]) wrote:

>- What's the rationale for having STRING-DO-EACH on top of
>  STRING-FOR-EACH?

I wonder that too. I haven't got any sensible explanation.

>- I really am for dumping the case-fiddling and recognition procedures
>  and suffixes.  The way they are now, they are woefully
>  underspecified and thorougly anglocentric.

I think they should be preserved (except for the CAPITALIZE stuff), but
better specified. An easy solution is to define it in terms of the
CHAR-CI procedures, CHAR-UPCASE and CHAR-DOWNCASE.

>- The same holds for the inequality predicates, unless their
>  specifications would change to refer to the return value of
>  CHAR->INTEGER.

I don't see the problem here. They are defined in terms of CHAR<?, and
CHAR<? does refer to CHAR->INTEGER in R5RS (page 29).

I think it's a good idea to define everything in terms of the character
procedures in R5RS (section 6.3.4).

>- I think the name STRING-CONCATENATE is badly chosen.  Why not
>  STRING-APPEND-LIST?

I wonder if it's really nessesary at all. Is there really a need to
concatenate so many strings that (apply string-append list-of-strings)
doesn't work? What is the lowest known limit on number of
arguments to procedures in a sensible Scheme implementation?

>- The "Lower-Level Procedures" are exclusively for argument checking.
>  They're not particularly low-level, nor are they all procedures.
>  This should be stated.
>
>  The procedures contain veiled references to a condition system, and
>  even try to pass information to it, which it may or not be able to
>  use.  In their present form, they should go.

I do agree.

>- The Knuth-Morris-Pratt stuff should also really go into a separate
>  SRFI.  It's useful, but much more rarely than the other stuff.

I think it can be useful, but it hasn't much to do with string
processing. The SUBSTRING? procedure is probably better implemented
with Boyer-Moore. Remove the KMP stuff from this SRFI and perhaps make
a separate SRFI with it.

>- Oh, and I vote for bagging CAPITALIZE-STRING[!].

Me too.