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.
Apologies that I haven't had time to formulate a better reply before now (see previous excuse re: startup company and impending release that will be eating most of my time till the end of the year), but I'll at least try to quickly chime in on the issues: Olin writes: >C'mon. Do you really think that people would use STRING-SET ? >STRING-FILL is an easier case to make. Let's see, that would be Actually, my suggestions come from actual use. The Scheme variant that I'm working on for work started out life as a functional-only system (that is, no mutable data *at all*), and I ended up implementing string-set and using it quite a bit. Do I have to rehash the issues of why working with immutable data can be a big win? Anyway, the straightforward implementation is simple: (define (string-set str k ch) (set! str (string-copy str)) ; or substring or whatever (string-set! str k ch) str) and it (I know I harp on this) maintains the overall consistency of the library. More consistency means easier to learn and easier to understand. Big win. I'd actually just as soon drop string-fill! as add string-fill (I don't think I've ever had a compelling reason to use either), but I'm more in favor of doing one or the other than leaving the asymmetry. For the record: (define (string-fill str ch) (make-string (string-length str) ch)) >>[issue with string-copy and string-copy! not taking parallel args] >Yeah, you're right. However, your non-side-effecting STRING-COPY is subsumed >by the STRING-REPLACE Welsh proposes below. I think I'll leave things as-is. If by "as-is" you mean dropping the proposal for string-copy! then I'm for that. If you mean simply leaving your original proposal where the two procedures take different sets of args, then I'm against that. Again, I'm not against the particular functionality (which seems useful to me), just against calling two essentially different procedures by essentially similar names. >I see your point... but I'm going to stick with <>. None of the other choices >seem all that much better to me (and I don't have any better suggestions, >myself). I agree with using "<>"; the analogy with < and > works for me even though some things are simply unordered (if it gets extended beyond strings, which I'd expect). >[mismatch index with the (in)equality procedures] It turns out to be a >handy value to have around if you are comparing strings. However, requiring it means that implementations are precluded from using certain short-cut optimizations, in particular, = and <> can't return quickly based on the length of the arguments. I'm against returning mismatch indices in the standard (in)equality functions, but do see their benefit and would be in favor of specifying explicit mismatch-index-returning procedures, not just because of the above efficiency tweak but also because they would signal programmer intent. I don't have a strong opinion about what these functions would be named, "stringOP-mismatch-index" is an off-the-top-of-my-head suggestion. string=-mismatch-index string<-mismatch-index etc. >- STRING-APPEND accepts chars as well as strings? I vote no, mainly because it makes typing (as in data types not fingers on the keyboard) harder. (Waving hands slightly...) Keeping the args as strings uniformly makes it easier to do sanity checking and some optimizations. I would be in favor of a more generic display-append (bad name, yeah) which string-appended the display forms for its arguments. This would subsume a string-or-char variant. Assuming SRFI-6: (define (display-append . args) (define result-port (open-output-string)) (do ((args args (cdr args))) ((null? args) (get-output-string result-port)) (display (car args) result-port))) > (display-append "foo" #\b #\a #\r "baz" 42) => "foobarbaz42" >- Comparison functions n-ary? I've never had a need for that, but I'm willing to be convinced. A tentative no. >- Include STRING-TOKENIZE? Yes on string-tokenize, and I do also like the concept (suggested by oleg@xxxxxxxxx) of string-split, although I find the proposed definition rather arcane (should be clearer when to expect delimiters to be ignored; using '() to mean "whitespace-but-with-special-rules" seems like a bad idea; etc.) >- SUBSTRING and copying/shared-text semantics: > Liberal: Olin > Conservative: Egorov?, Bornstein? Yep, conservative. >- STRING-ITER vs STRING-ITERATE > Iter: Olin > Iterate: Egorov I'm slightly more in favor of "iterate"; not a strong conviction, but I do believe in autocompletion and creative use of newlines (i.e., so I don't butt up against column 80 even with long names). >- -COUNT versus -LENGTH > -COUNT: > -LENGTH: Egorov Length. Oleg writes: > -- procedure+: string->integer STR START END > >Makes sure a substring of the STR from START (inclusive) till END >(exclusive) is a representation of a non-negative integer in decimal >notation. If so, this integer is returned. Otherwise -- when the >substring contains non-decimal characters, or when the range from >START till END is not within STR, the result is #f. I don't like this particularly. I can think of a kabillion variants on parsing strings into numbers that I might find useful. The one that's built-in is the right one since it's about Scheme read form (which you gotta implement anyway). The moment you step into the territory of other number formats, you should be ready to define a full suite of procedures to deal with the plethora of possibilities. I think that about covers things for me now. Take care, all. -dan