> > it seems to me that STRING<? and
> > others are better left for trivial tasks like sorting strings of digits;
>
> Very few such trivial tasks exist in the application domain.
>
> > for example, if you want to implement string sets as
> > sorted lists, it's much better to use fast ordering predicate,
>
> I argue that this is the only time that a language-insensitive ordering
> predicate is useful: implementing ADTs on top of strings.  And for that,
> the character-ordering predicates remain.  (Indeed, the character-ordering
> predicates,
> much like the character-wise casemapping procedures, seem useful for
little
> else.)

I understand your position, but my point is a philosophical one: the
approach
to text processing in 21st century is very different from the one envisioned
by Scheme authors; now we know that text is a rather complex entity and
an array of bytes is not the best representation for it if you want to
implement
the text processes described in the UNICODE book effectively. Tweaking
old Scheme functions and data types cannot bring us significantly closer to
the ultimate solution because it's hard to modify the existing semantics
without breaking a lot of existing code. The old data types and functions
have their purpose: there's still a lot of language-insensitive processing
like manipulation with file names, compiler implementation, etc. for
which the simplicity and effectivenes of Scheme primitives is a bonus.
But if we want to design a real text processing library, I think we should
forget about strings and concentrate on a new data type: TEXT.

Sergei