Alex Shinn <xxxxxx@gmail.com> writes:

> I'm sorry, perhaps I misunderstood, but I'm still not clear what you're
> arguing in favor of.  Do you want to leave all existing R5RS character and
> string procedures unspecified, optionally introducing new versions with
> ascii- or unicode- prefixes?

Well, what I'm arguing in favor of is standardizing only things which
will not hamper fancy-schmancy "full-Unicode" support (with all the
optional little bits that aren't Unicode-proper).  I am arguing
against the requirement of functions which are being specified to do
things which are the Wrong Thing on such systems, both because:

  The system shouldn't be forced to have a bogus function lying around
  confusing its users, and

  Portable code should automagically do the right thing on a
  fancy-schmancy system.

Suppose we made the mistake of saying that all numbers must be
comparable by <, with full trichotomy.  Or we demanded that
multiplication must be commutative.  Then we would have messed up.  We
would have prevented complex numbers or quaternions from being
implemented carefully.

By contrast, Scheme did this right.  Nobody has to support complex
numbers or quaternions, but we also don't specify whether
multiplication is commutative or whether < is a total order on
numbers.

I want generically-named procedures to do the correct generic thing on
the local system.  I want no generically-named procedures mandated by
the standard when they cannot be implemented correctly on a
fancy/schmancy system.

If there is a need or desire for non-generically-named procedures,
that's fine.  So ascii-upcase (or whatever) is fine.  But char-upcase
is not, even if you then say "oh, and it breaks if the character isn't
ascii."

This means we must get rid of the existing case-mapping functions in
R5RS.  They must go.  They are the *problem*.

Now if you want, as a system implementor, to continue to implement
them, go right ahead.  But *please* don't force every Scheme system,
include a fancy/schmancy one, to do so!

Thomas