> >> As I pointed out on p5p even EBCDIC machines can use that model - but
> >> the downside is that ord('A') == 65 which will breaks backward compatibility
> >> with EBCDIC scripts.
> >
> >Maybe we need $ENV{PERL_ENCODING} to control ord() and chr(), too?
>
> That was my suggestion last week some time - though not stated as clearly!
Though, after more caffeine, I see that I'm getting mixed up again :-)
PERL_ENCODING would be inappropriate for this purpose, here we would
want $ENV{PERL_CODESET}, or somesuch, for controlling the ord(),
chr(), %c (and pack)? And before someone pipes in, the $ENV{} thing(s)
would of course only be the initial value, there should be also more
fine-grained ways (compile/runtime) for controlling this.
> >ourselves to much nashing of the teeth. Off-hand, I think it's only
> >when there would be information loss when the One True Encoding
> >conversion shouldn't be done. What's the OTE, then? Well, UTF-16 or
> >UTF-32, I guess. The redeeming features of UTF-8, that it is 1:1 for
> >ASCII, and also compact for ASCII, frankly are getting rather thing in
s/thing/thin/
> >my eyes.
>
> But not in mine (yet) - but then IO is just throwing gobs of bytes about
> and regexps are introspecting. (And Encode has to handle variable-length
> multi-byte gunk anyway.)
>
> --
> Nick Ing-Simmons
--
$jhi++; # http://www.iki.fi/jhi/
# There is this special biologist word we use for 'stable'.
# It is 'dead'. -- Jack Cohen
