Re: 200alpha13

[Matthew Flatt <mflatt@cs.utah.edu>]

Previously, I was thinking of a locale as fixed for a particular
machine. Shifting results for `string<?' across machines doesn't bother
me much (it's little worse than shifting file name conventions), and
distinguishing characters comparisions from byte comparisons seems
fine.

But the idea that `string<?' can return different results at different
times on a single machine (which is what we have right now) does seem
like trouble.

At Thu,  7 Mar 2002 00:11:22 -0500 (EST), Kragen Sitaker wrote:
> If I were adding locale sensitivity to PLT Scheme, I would do it by
> adding new locale-sensitive functions, not by adding subtle
> dependencies on global state to standard functions.

I like the idea of adding `string-locale<?', etc., instead of changing
`string<?'. The new functions would be

  string-locale<?
  string-locale>?
  string-locale-ci<?
  string-locale-ci>?
  string-locale-ci=?

  char-locale<?
  char-locale>?
  char-locale-ci<?
  char-locale-ci>?
  char-locale-ci=?

  char-locale-alphabetic?
  char-locale-whitespace?
  char-locale-upper-case?
  char-locale-lower-case?

I don't like adding 14 more built-in names, but so it goes.

[Note: I left out `string-locale<=?', etc., because they can be written
with the others easily. I also left out `char-locale-numeric?' --- is
there any way it could be useful?]

Also, I start to think that case-insensitivity for reading symbols
should always use locale-insensitive conversions. (Someone who wants to
program in a non-ASCII language will probably want case sensitivity,
anyway.)

A global parameter is still needed to control `write' output for
strings and characters; that was the main motivation for using locales
at all.

Matthew

P.S. --- File names in Windows and Mac OS are "case insensitive", so
"e" is the same file name as "E". But how about "è" and "È"? "ñ" and
"Ñ"? "ö" and "Ö"?