Jorgen Schaefer <xxxxxx@forcix.cx> writes:

> String collation is very complex, as the "preferred" order of
> characters depends on the locale. But since STRING<? and friends
> are often used for things like binary search trees where the exact
> order is irrelevant and the only important thing is the existance
> of any kind of total order, defining them the way this SRFI does -
> by using the codepoint sequence - is good, because it is fast. If
> the implementation wants to provide the locale-dependent string
> collation, fine, but that's not useful for this SRFI to define.

This would make sense *only* if users would know that string<? might
give them wrong results on fancy systems if they use it for indexing.

So how about specifying two functions, one that implements a total
order for use where you don't care what the order is, and another
which guarantees the human-sensible text sorting method.  Simple
systems can simply eq the procedures; fancy systems can make fancy
differences.

Programmers will be on alert, and can use the correct name for
whichever they are using.