Re: Scheme String Operations: the Report

[David Bartley <Bartley%ti-csl.csnet@csnet-relay.arpa>]

Chris,

  Thanks for mailing out the preliminary report on your proposal for string
operations for Scheme.  Here are my initial reactions.

  -- You were clearly influenced by Common LISP (CL), since at least 27 of
your functions have direct analogues in CL.  You rarely use the same name
as CL uses, however.  I tend to agree with most of your name choices, with
one exception: CL uses the suffixes =, <, etc. for case sensitive
comparisons of characters and strings and the suffixes EQUAL, LESSP, etc
for case-insensitive comparisons.  I prefer to adopt that convention rather
than inventing the suffix -CI.

We should definitely preserve our conventions regarding suffixed ?  and !
characters.  Thus, CL's CHAR-LESSP and NSTRING-UPCASE should be renamed
CHAR-LESS? and STRING-UPCASE! for Scheme.

  -- We probably need a (CHAR? obj) predicate.  The following are useful;
can we agree on their meaning?

	(CHAR->INTEGER char)	; CL's CHAR-CODE ?
	(INTEGER->CHAR n)	; CL's CODE-CHAR ?

  -- The order of arguments to CHAR-SET-MEMBER? is reversed from that of
MEMBER, MEMV, and MEMQ.

  -- How is a CHAR-SET represented?  Created?  Modified?

  -- Why distinguish STRING-ALLOCATE from MAKE-STRING?  By analogy with
MAKE-VECTOR, shouldn't MAKE-STRING take the second argument optionally?

  -- May I assume that string and character values are printed (and read)
as defined by CL?

  -- May I assume that all of the operations you defined are procedures,
not special forms?

  -- May I assume that SUBSTRING and other names written without ! always
return a copy rather than sharing structure?

  -- One way to reduce the number of operations is to combine the STRING-
and SUBSTRING- operations by accepting optional substring operands.  For
example, specify only

		(STRING-FILL!     string  char  { start { end }} )
instead of
		(STRING-FILL!     string  char)			and
and		(SUBSTRING-FILL!  string  start  end  char)

Note that the <char> argument has been repositioned.

It would be useful to let either <start> or <end> default.  In the example
above, we could interpret

		(STRING-FILL!  string  char  start)

as filling from <start> to the end of the string.

  -- What should happen when indexes cross (start>end) or go outside the
proper range?

  -- Are you suggesting that the Basic Character Operations, Basic String
Operations, and Standard Operations be 'required' and the rest be
'optional'?  If not, where would you draw the line?  Do you use all of
these operations yourself?

  -- Is the character datatype in MIT Scheme extended the same way CL has
gone?  Do you support font and/or bit info?  Have you added operations to
MIT Scheme beyond those you've proposed in your report?

  -- In summary, the proposal looks sound and I have no arguments with the
functionality you are proposing.  I'll pass on further comments after we've
had time to digest it more thoroughly.

Regards,
David Bartley
-------