According to Ilya Zakharevich:
> On Thu, Feb 03, 2000 at 08:35:04PM -0800, Chip Salzenberg wrote:
> > So: The _string_encoding_ state of each OP must be one of these:
> >   0. the default -- follow each string's current encoding
> >   1. "use byte"  -- all strings are one-byte
> >   2. "use utf8"  -- all strings are UTF-8 (*not* necessarily Unicode!)
> > 
> > And the _character_set_ state of each OP must one of these:
> >   0. the default  -- characters are Latin-1, UTF-8 is Unicode
> >   1. "use locale" -- characters are $ENV{LANG} (set at runtime)
> 
> Too complicated

For users, or for us?

> very few advantages (if any).

Granted there are not likely to be many users for anything but utf8
and byte.  Further arguments get into language design, which I've
found not to be my strongest skill....

> locale-ness should be addressed during i/o operations (here i/o is
> understood in wide sense).

Agreed that this sort of conversion will be vital; it's where
Unicode::Map8 (or its equivalent) comes into play.  But there
are other issues....

> `use locale' (or better, its equivalent) should better forget about
> C locales.  [...]  Now: please look around.  What nice properties of
> your favorite locale will be lost by interpreting it as a hint to
> Unicode conversion?

We have to at least provide effective access to C locale features like
collation.  Surely _some_ people are using C locales for e.g. sorting
words in Russian dictionary order.  And of course those people won't
like having a language feature pulled out from under them.
-- 
Chip Salzenberg          - a.k.a. -           <[EMAIL PROTECTED]>
        "He's Mr. Big of 'Big And Tall' fame."  // MST3K

Reply via email to