[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: the discussion so far
On Wed, 20 Jul 2005, Alex Shinn wrote:
>On 7/20/05, Thomas Bushnell BSG <tb@xxxxxxxxxx> 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
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.