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 19:34 UTC

bear <xxxxxx@sonic.net> writes:

> This is why I think "glyph=character" is more or less required
> for a language that wants to have "single character" arguments to
> and returns from case mapping functions.  You cannot do it in a
> fashion compliant to the Unicode standard if you use
> "codepoint=character" instead.

We cannot have single character arguments for case mapping functions.
You can't even do it if you have "glyph=character", because there are
case mappings which map multiple characters.  (Es-zet being the
classic, but hardly the only, example.)

> The best we can hope for, and the point of language design, is to make
> it easy to do the right thing; there is no way we can prevent
> programmers from doing the wrong thing if they're so inclined, nor
> even make it the slightest bit difficult.  Our duty is to make sure
> the right thing is no harder to do than the wrong thing.

We should also not provide functions which are automatically the wrong
thing.