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.
Here is a list of the open issues on which I'd like to hear opinions and discussion. I've also and made another list of resolved issues. These aren't meant to be exhaustive lists; feel free to raise other issues. -Olin ------------------------------------------------------------------------------- Open isues: - SUBSTRING and copying/shared-text semantics: Liberal: Olin Conservative: Egorov, Bornstein No opinion: amoroso The two choices are + Conservative -- Drop SUBSTRING. Add STRING-COPY & SUBSTRING/SHARED + Liberal -- Add STRING-COPY; alter SUBSTRING to allow shared-text reuse. - STRING-ITER vs STRING-ITERATE Iter: Olin Iterate: Egorov, amoroso, bornstein ------------------------------------------------------------------------------- Resolved issues: - STRING-APPEND accepts chars as well as strings? Resolved: no Would give a kind of "string cons" for free... If we altered STRING-APPEND to accept characters as well as strings, we would get the ability to "cons" characters onto the head or tail of strings, e.g. (string-append c1 c2 s). Yes: No: bengt egorov amoroso shivers bornstein - Comparison functions n-ary? Resolved: no. Yes: No: shivers, bengt, egorov, amoroso, bornstein Should the string comparison functions such as STRING= and STRING< be generalised to be n-ary? E.g., should we be able to write (string< s1 s2 s3) I have specified these functions as dyadic only. You can certainly make a case for greater generality. However, - Unlike numeric inequalities, I do not think this generality will be useful in practice. - It doesn't extend well to the *sub*string comparison functions or the three-way comparison functions. To get it to work for the three-way comparison functions, you'd have to put the continuations first, then the strings after. This is pretty ugly; the usual convention is continuations last. This is not a completely compelling argument, but it does weigh some. Extending to the substring comparison functions -- both the predicates and the 3-way continuation-based functions is even uglier. Finally, if we were to do this, we ought to really follow through and make the 8 prefix-count functions n-ary. I think it's too much complexity. Note that Rice's MzScheme provides n-ary string comparison. - Include STRING-TOKENIZE? Resolved: yes Yes: bengt, shivers, egorov, amoroso, bornstein - Include STRING-REDUCE and STRING-REDUCE-RIGHT ? Yes: bengt, amoroso No: egorov Dead issue -- there is no good definition of STRING-REDUCE. - -COUNT versus -LENGTH Resolved: -LENGTH -COUNT: -LENGTH: Egorov, bornstein No opinion: Shivers, amoroso These or these? ------------------------- -------------------------- string-prefix-count string-prefix-length string-suffix-count string-suffix-length string-prefix-count-ci string-prefix-length-ci string-suffix-count-ci string-suffix-length-ci substring-prefix-count substring-prefix-length substring-suffix-count substring-suffix-length substring-prefix-count-ci substring-prefix-length-ci substring-suffix-count-ci substring-suffix-length-ci