On Thu, 14 Jul 2005, Thomas Bushnell BSG wrote:

> From my perspective, the problem with the current standard is
> that you *cannot* implement Unicode properly.  Far from
> requiring it, it is essentially prohibited.

> I fear that this SRFI is (ironically) in danger of doing the
> same damn thing all over again.

> If Scheme standardizers would just get out of the way, and
> allow Unicode-interested Schemes to implement Unicode
> correctly, I would be happy.  My concern is that I want to make
> sure that in the next go-round of the RnRS, it is possible to
> write a Unicode conformant Scheme system.

I think this is my essential position too.  Requiring a specific
form of unicode support (or requiring it at all) may be
premature; but at the very least removing requirements that
militate *AGAINST* proper unicode support must be done.

Making symbols case-sensitive and not requiring case operations
that work on single characters, I believe, is enough to make it
possible for interested implementors to create fully unicode
compliant schemata.

The standard may also require case operations that work on
strings without breaking the ability of an implementor to be
fully compliant with both RnRS and Unicode.  But this is
optional, and can be relegated to a library function.

Many implementors may choose to also have case operations that
work (non-compliantly) on single characters, but IMO the standard
must not require them.

This is not, however, enough to make it possible for these
schemata to handle unicode with any kind of uniform semantics.
For example, for a given external representation, I can imagine
different systems thinking that it was any of six different
lengths, depending on whether they do normaliztion, what choice
of normalization form they use, and whether they map characters
to codepoints or grapheme clusters (making normalization moot).

A standard could iron out these issues; but in the absence of
experience and the reports of satisfied or unsatisfied users, it
may actually be better if the standard does not.

				Bear