Open issues summary #2 (and a list of resolved issues)

[shivers@xxxxxxxxxx]

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