Open issues summary #2 (and a list of resolved issues) shivers@xxxxxx 13 Nov 1999 23:00 UTC
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