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