On Wed, 20 Jul 2005, Alex Shinn wrote:

>On 7/20/05, Thomas Bushnell BSG <xxxxxx@becket.net> wrote:

>> We can standardize names that have ascii- as part of the name, because
>> they clearly and unambiguously name what the functions do.  But to use
>> confusing names in the hopes of helping broken code continue to limp
>> is not a decision that the standard should be making.

> 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?

I think I'm in agreement with Thomas here; I think that if
reference to a particular standard is an important (specified)
part of what a function does, then it should also be part
of that function's name.  But that's an argument from
aesthetics.  There is a far more practical argument to be
made here.

R5RS had char->integer and integer->char defined, but did
not specify the mapping they created, except to say that
the two functions were inverses of one another.

All those incompatible char->integer and integer->char
functions will still be out there when R6RS goes into effect,
and probably for a longish time thereafter.  R6RS wants
mapping functions that give integers for characters and
characters for integers according to unicode's character
mapping, for portability; but naming them char->integer and
integer->char would be unfortunate, because existing
implementations of  char->integer and integer->char will
then be confused for the new "conforming" implementations
of those functions, resulting in a bigger muddle.

If we're inviting people to rely on mappings that give
unicode codepoints for characters, I think it's important
to use function names that are not shared with functions
which currently exist and do not.

			Bear