Re: Scheme String Operations

[Kent Dybvig <dyb%unc.csnet@csnet-relay.arpa>]

1.  I prefer Chris Hanson's names over the Common Lisp or Bartley names.
    I find the CL names confusing and nonsensical.  Why does "char=" imply
    case sensitivity, and "char-equal" insensitivity?  The issue is also
    confused because CL does not define "equal" to use "char-equal" as is
    implied by the naming convention.

    I have been using Common Lisp for over a year since helping to bring
    Data General's system into existence.  Many of us get confused about
    which is which.  There would be no confusion with a suffix such as
    "-ci".  Except for possible commercial interests, I can see no benefit
    in copying the mistakes of Common Lisp.

2.  I would rather spell out the name "character" in all functions rather
    than use the shorter "char" but that's probably too much to ask.

3.  I wish there weren't so many string functions.  I think Chris Hanson
    was on the right track with the very primitive set that can be used to
    construct all the others.  Perhaps we should have that set plus
    "string-ref", "string-equal?", "string-less?" "string-equal-ci?",
    and "string-less-ci?", "string->list", and "list->string".

4.  I have a "string" function in my system that comes in handy --
        (string char1 char2 ... charN)  =>  string of char1 ... charN, N >= 0.
    For example:
        (string #\a #\b #\c) => "abc".
    This is easy to write as (lambda x (list->string x)).
    It is particularly useful when creating a cursor-addressing string to
    send to the tty.

5.  I do not view "string->symbol" and "symbol->string" as string functions.
    They are symbol creation and destructuring primitives.  In fact, I
    strongly object to the names since they are not analogous to other
    type-conversion functions such as "string->list" and "character->integer".
    I'll say more about this in a separate note.

6.  As far as optionality is concerned, I would like to see Scheme adopt
    an optional argument mechanism.  It reduces the namespace and is really
    quite easy to implement efficiently.  A function like "member" becomes
    completely general, allowing not only "eq?", "eqv?" and "equal?" tests
    but also any user-defined test.  However, until we have optional
    arguments that can be defined using a lambda expression, I do not
    think we should have primitives with optional arguments.  Either the
    language has them or it doesn't.


        Kent Dybvig
        decvax!mcnc!unc!dyb
        dyb.unc@Csnet-Relay