[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

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

I've also and made another list of resolved issues.

These aren't meant to be exhaustive lists; feel free to raise other issues.

Open isues:

- SUBSTRING and copying/shared-text semantics:
  Liberal: Olin
  Conservative: Egorov, Bornstein
  No opinion: amoroso

  The two choices are
  + Liberal -- Add STRING-COPY; alter SUBSTRING to allow shared-text

  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).

  No: bengt egorov amoroso shivers bornstein

- Comparison functions n-ary?
  Resolved: no.

  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.

  Resolved: yes
  Yes: bengt, shivers, egorov, amoroso, bornstein

  Yes: bengt, amoroso
  No: egorov

  Dead issue -- there is no good definition of STRING-REDUCE.

- -COUNT versus -LENGTH
  Resolved: -LENGTH

  -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