[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: the discussion so far

This page is part of the web mail archives of SRFI 75 from before July 7th, 2015. The new archives for SRFI 75 contain all messages, not just those from before July 7th, 2015.

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