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.
Hi. Sorry I'm late to the party. I've organized this message somewhat strangely. Rather than going through each individual procedure, I've tried to figure out the overarching design goals of the library and treat each in turn. I've probably missed a few. After doing this for awhile I'll get to some function-specific weirdnesses I noticed. I'm harping on consistency here because I'm one of those programmers Olin mentions who can't be bothered to remember all the procedures in a library, but rather reconstitute the name (and calling convention) when they need it. So I'll favor a _consistent_ interface over a _concice_ interface (though I think the only times I found these to be in opposition is in string-<index/skip>-right, see below). ---- Naming The procedure-names in the library obey a very nice naming convention: [sub]string-<verb/noun>[-ci][!] for the most part. This is why I was surprised to see some breaking of these rules. For consistency, I would strongly support renaming the following procedure: join-strings ==> string-join I would also support renaming these two capitalize-string ==> string-capitalize capitalize-string! ==> string-capitalize except that would cause a strange discontinuity with capitalize-words[!]. So I probably wouldn't rename these two unless I could convince everybody to drop capitalize-words[!] entirely, which I'll try to do below when I get to individual procedures. ---- Optional [start end] arguments for single-string procedures The rule that is almost always followed is that if there is a _single_ string argument to a function, there will be optional start/end arguments for that string. There are four exceptions to this rule: string? string-length string-null? string-<take/drop>[-right] Adding optional arguments to the first three is clearly goofy. However, although adding the optionals to string-<take/drop>[-right] seems goofy, I'll ask for it anyway. Because my Scheme doesn't have shared substrings, when I start passing around start/end pairs to my functions, I do so for efficiency, and I really do treat the three arguments 's start end' as one: (define foo (lambda (s start end) ;; one conceptual argument ...stuff...)) I don't like to think when I do this, so I'll almost certainly try to do: (string-take s start end 10) As soon as I get the error message, I'll kick myself and rewrite it as one of the obvious (substring s start (+ start 10)) (values s start (+ start 10)) (values s start (min (+ start 10) end)) But I don't want to think. I want string-take to accept my conceptual shared string that happens to be split up into three arguments. ---- Mandatory 'start2 end2' arguments for multi-string procedures All procedures that take more than one string, if they accept start/end pairs for those strings, _require_ all start/end pairs. That is, none of them is optional. Except for string-replace, where [start2 end2] is optional. . This is a bit strange. Certainly, substring-compare[-ci] can't have optional [start2 end2] arguments, since the continuation arguments come last. But what would be wrong with (substring= mystr mystr-start mystr-end "foo") So it seems to me that the domains of substring[-ci]= substring[-ci]<> substring[-ci]< substring[-ci]> substring[-ci]<= substring[-ci]>= substring-<prefix/suffix>-length[-ci] substring-<prefix/suffix>[-ci]? should be changed from s1 start1 end1 s2 start2 end2 to s1 start1 end1 s2 [start2 end2] ---- Optional [end start] arguments for index and skip Because the optional [start end] convention is so firmly established in the library, it hurts me dearly to see [end start] in the index-right and skip-right procedures. Olin's defense that the start argument is almost never specified for these doesn't sway me, and the fact that I'll get a runtime error when I try it just irritates me. When I'm using the 's start end' convention to represent my strings, I'm not going to remember that these two arguments need to be reversed for these two procedures, and if I do I'll curse the fact that I've devoted brain cells to the exception. When I'm not using this convention and just using the optional arguments 'casually', I at least would be happy to always write a zero for my start point whenever I want to specify my end point. ---- Overflows Questions about some overflow cases: (string-take "foo" 5) ==> "foo" or error? (string-drop "foo" 5) ==> "" or error? (string-copy! "xx" 0 "yyy") ==> I assume an error, but am worried by the language 'the copy is guaranteed to work'. ---- Sharing I'll cast my vote for the liberal camp. However, I feel obligated to get a little wacky about it and ask why we're providing string-append/shared string-concatenate/shared reverse-string-concatenate/shared If we're breaking R5RS's substring, I see no reason not to also break R5RS's string-append. That is, by voting 'liberal' I believe that (eq? foo (string-append "" foo)) (eq? foo (string-concatenate (list "" foo))) (eq? foo (reverse-string-concatenate (list "" foo))) should all be allowed to be true. The problem with my firm stance is that I have no idea what the 'non-shared' versions should be named. string-append/copy? string-append/fresh? ---- string-for-each, string-iterate I'm definitely with Lars Arvestad on this one. String-for-each should require a left-to-right ordering. I mainly argue this because I've now sent approximately five years-worth of undergraduates out into the world with the factoid that they should use 'for-each' when they care about evaluation order. I'm willing to pay the price of an extra register-register comparison for that clarity. Well, I think I'm willing to do that, anyway. I'd be happier if there were a good, non-'for-each' identifier that would connote unorderdness. Sigh. ---- string-null? I worry (probably needlessly) about people confusing the 'null' lexeme with the character with ascii value 0 that C programmers use to terminate their strings. Or even worse, someone confusing it with the terminal value of a recursive datatype (grin). I was going to argue for 'empty-string?', but that would conflict with the 'string-first' naming convention. How about 'string-empty?'? ---- capitalize-string[!], capitalize-words[!] I just don't see a reason for having these procedures in this library, _especially_ capitalize-words. They seem much more suited for a 'natural language' sublibrary or the like. I'm not sure I can argue cogently why they don't belong, but they stick out a bit to me, where string-upcase and string-downcase don't. Capitalize-string[!] I can see as somewhat useful, but capitalize-words[!], for me, opens the same kind of bag of worms that string-split does. ---- join-strings Why no 'prefix grammar? ---- string-parse-start+end I didn't see anywhere in this spec where this procedure could be used. In every case where there is an optional [start end] argument pair, it's the last arguments of the function, and therefore sring-parse-final-start+end seems to be the only one of this pair that would be used. Not that I particularly object to it being in the string-lib-internals module, I'm just not sure why it's there. Also, you use the id 'rest' in the description of these two functions when you should probably use the id 'ARGS'. ---- Votes So I don't feel left out, here are my votes for the open (and closed) issues. STRING-APPEND accepts chars as well as strings? -- no Comparison functions n-ary? -- no Include STRING-TOKENIZE? -- can't decide Include STRING-REDUCE and STRING-REDUCE-RIGHT ? -- no SUBSTRING and copying/shared-text semantics: -- liberal STRING-ITER vs STRING-ITERATE -- iterate -COUNT versus -LENGTH -- length -------------------------------------------------- Thanks for taking the time to design this library, Olin. The fact that I'm picking on little inconsistencies should reflect that the design shows such great consistency and elegance. -erik