Email list hosting service & mailing list manager

case mappings Alex Shinn (13 Jul 2005 03:57 UTC)
Re: case mappings Thomas Bushnell BSG (13 Jul 2005 05:49 UTC)
Re: case mappings Michael Sperber (13 Jul 2005 06:41 UTC)
Re: case mappings Thomas Bushnell BSG (13 Jul 2005 06:47 UTC)
Re: case mappings Michael Sperber (13 Jul 2005 07:12 UTC)
Re: case mappings Thomas Bushnell BSG (13 Jul 2005 07:21 UTC)
Re: case mappings bear (13 Jul 2005 17:24 UTC)
Re: case mappings Thomas Bushnell BSG (13 Jul 2005 19:35 UTC)
Re: case mappings Alex Shinn (13 Jul 2005 07:55 UTC)
Re: case mappings Alex Shinn (13 Jul 2005 07:40 UTC)
Re: case mappings Thomas Bushnell BSG (13 Jul 2005 19:36 UTC)
Re: case mappings Alex Shinn (14 Jul 2005 02:39 UTC)
Re: case mappings Thomas Bushnell BSG (14 Jul 2005 07:15 UTC)
Re: case mappings Alex Shinn (14 Jul 2005 07:42 UTC)
Re: case mappings Thomas Bushnell BSG (14 Jul 2005 08:07 UTC)
Re: case mappings Alex Shinn (14 Jul 2005 08:24 UTC)
Re: case mappings bear (14 Jul 2005 16:47 UTC)
Re: case mappings Thomas Bushnell BSG (14 Jul 2005 20:29 UTC)
Re: case mappings bear (15 Jul 2005 18:23 UTC)
Re: case mappings Thomas Bushnell BSG (15 Jul 2005 19:52 UTC)
Re: case mappings Matthew Flatt (13 Jul 2005 13:05 UTC)
Re: case mappings Thomas Bushnell BSG (13 Jul 2005 19:39 UTC)
Re: case mappings Alex Shinn (14 Jul 2005 02:31 UTC)

Re: case mappings Thomas Bushnell BSG 13 Jul 2005 07:21 UTC

Michael Sperber <xxxxxx@informatik.uni-tuebingen.de> writes:

> I have expressed myself poorly: If I want my code to behave in a
> locale-specific way, then I'll use procedures that respect locale.
> Ditto for full string-to-string case-mapping in a locale-independent
> manner.  In other words, I need to indicate in my source code what I
> want.  Sometimes I want exactly the case mapping the current SRFI
> draft has---I *don't* want any of the others.

My concern is with code that *doesn't* specify anything, because it
"just wants ordinary case mapping".  What I'm concerned with is that
we don't name a procedure "turn this to upper case", with no locale
arguments, that just does some half-assed inadequate job.  It is
better to provide no procedure than such a procedure.

> I don't know what you think will become trivial.  Not much I can think
> of.  Even implementing the UnicodeDate.txt case mappings is not
> trivial to do efficiently---which is why we'll provide a reference
> implementation for those pretty soon.

Designing the interfaces becomes trivial.  Implementing
UnicodeData.txt is not trivial to do efficiently, but that's no excuse
for failing to do it.  *Language writing systems are complex.*  Many
people, brought up on the Latin alphabet alone, got lazy and
accustomed to thinking that things like case mapping are trivial and
quick.  They aren't.  There are efficient methods (though I agree with
you that it's tricky to find them!).

My concern is that the *interfaces* not

1) Prevent real conformance to Unicode.
2) Encourage Scheme programmers to do things which can't conform to
   Unicode even on a Scheme systems that want to conform.

The current Scheme spec violates (1).

The current SRFI here violates (2).

My proposal: to specify the existence of a locale argument, together
with the expectation that the argument defaults either to the current
environmental locale (LANG on Posix systems), or to a default of
UnicodeData+SpecialCasing.

I'm happy to then let this argument be optional, provided that in the
absence of the argument it defaults to a global variable, which in
turn is either the environment or the UnicodeData+SpecialCasing
default.

But if you insist on saying that the case-mapping procedures operate
on characters instead of strings, then you will violate both (1) and
(2).

Thomas