Position of the Judean People's Front

[sperber@xxxxxxxxxxxxxxxxxxxxxxxxxxx (Michael Sperber [Mr. Preprocessor])]

So I managed to read the latest draft.  Here are my comments, pretty
much unrelated to what anyone else thinks the open issues really are:

- What's the rationale for having STRING-DO-EACH on top of
  STRING-FOR-EACH?  I can't see any plausible efficiency gains, as
  there are for MAP.

- Everything is parameterized with STRING-COMPARE, why not the meaning
  of "mismatch"?

- I really am for dumping the case-fiddling and recognition procedures
  and suffixes.  The way they are now, they are woefully
  underspecified and thorougly anglocentric.  These things would be
  more useful alongside a better specification of the underlying
  character set.  (Unicode probably doesn't make sense here, but ISO
  8859-1 would at least make more sense than the present situation,
  for example.)

- The same holds for the inequality predicates, unless their
  specifications would change to refer to the return value of
  CHAR->INTEGER.

- There should be an explicit mention of SRFI 14 in the introduction.

- I think this shared-substring stuff is cool, but pretty specialized,
  and completely unnecessary for most applications.  I would love to
  see them in a separate SRFI.  You could actually *require* sharing
  there.

- I think the name STRING-CONCATENATE is badly chosen.  Why not
  STRING-APPEND-LIST?

- The "Lower-Level Procedures" are exclusively for argument checking.
  They're not particularly low-level, nor are they all procedures.
  This should be stated.

  The procedures contain veiled references to a condition system, and
  even try to pass information to it, which it may or not be able to
  use.  In their present form, they should go.

- The Knuth-Morris-Pratt stuff should also really go into a separate
  SRFI.  It's useful, but much more rarely than the other stuff.

- Oh, and I vote for bagging CAPITALIZE-STRING[!].

-- 
Cheers =8-} Mike
Friede, Völkerverständigung und überhaupt blabla