This page is part of the web mail archives of SRFI 13 from before July 7th, 2015. The new archives for SRFI 13 contain all messages, not just those from before July 7th, 2015.
In article <y9lg0x886hh.fsf@xxxxxxxxxxxxxxxxxxxxxxxxxxx>, sperber@xxxxxxxxxxxxxxxxxxxxxxxxxxx (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.