[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Position of the Judean People's Front
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
- 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,
- The same holds for the inequality predicates, unless their
specifications would change to refer to the return value of
- 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
- I think the name STRING-CONCATENATE is badly chosen. Why not
- 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