Alex Shinn scripsit:
> The draft points out that the R6RS definition of string-titlecase in
> terms of char-titlecase is incorrect, however, it doesn't give the
> means to implement string-titlecase correctly.
Well, no; string-titlecase is not defined in terms of char-titlecase
in this SRFI, which is precisely what makes it different from R6RS.
Similarly, R7RS does not define string-{up,down}case in terms of
char-{up,down}case.
> A sufficient utility might be char-titlecase* from Chicken's utf8 egg
> which returns either a character or string if needed.
Why not just always return a string? It could be called
string-{up,down,title}case-one, being a version of these functions
that accepts a single-character string and returns a single- or
multiple-character string. Normal string-{up,down,title}case could then
be defined in terms of them. But I think it's over-late for that.
> This is the reason I argued against the char-oriented case procedures
> in R6RS - they not only aren't useful for correct Unicode casing
> implementations, they actively encourage incorrect ones.
Indeed. The whole notion of "character" is pretty much an anachronism:
we should just have strings containing varying numbers of codepoints.
But we are stuck with our elegant weapons from a less global age.
> I won't argue against their inclusion if you want them for backwards
> compatibility, but in that case we should provide the missing pieces.
I wanted to provide what R7RS provides, no more, no less. SRFI 129 got
started when Art Gleckler pointed out that an early draft of what is
now SRFI 130 lacked titlecase, and I said that was because R7RS lacked
it, which led to the creation of this SRFI. It's a limited device to a
limited end.
--
John Cowan http://www.ccil.org/~cowan xxxxxx@ccil.org
Lope de Vega: "It wonders me I can speak at all. Some caitiff rogue
did rudely yerk me on the knob, wherefrom my wits yet wander."
An Englishman: "Ay, belike a filchman to the nab'll leave you
crank for a spell." --Harry Turtledove, Ruled Britannia
