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