On Mon, Aug 14, 2000 at 10:44:33PM -0400, Dan Sugalski wrote:
> > (I'm not really following Perl 6, but Unicode is obviously something
> > I have a concern about. Please *do* CC me replies, just this once.)
> > This is why we should:
> > i) Make the choice of internal encoding (UTF-8/UTF-16/UTF-32) decidable
> > at compile time.
>
> Perl compile time or perl program compile time?
Perl compile time. This is the *internal* encoding we're talking about.
> Regardless, I don't see any reason not to have a user-choosable default,
> since if we can handle bytes and utf-8 simultaneously there's no real reason
> it should matter to perl.
Exactly, keep it pluggable. I want to be able to write
while (s < send) {
PerlRune *i;
i = getchar(s);
s += nextchar(s);
}
and not *care* what's going on underneath.
> Say hi to Perl V(table) :)
What did Jarkko mean by this:
> (strict ANSI compiler was very unhappy with the vtables
> in the code)
Does this mean that Perl Vtable is going to throw portability?
> > iii) Never assume bytes.
> What, never? Not even in vectors and bitmaps? :)
I did say "assume". :)
> > iv) Provide the user a method of converting their input and output to and
> > from the UTF Perl uses.
>
> That'll go into the bits on line disciplines. Already there, I think.
Okay. FYI, I'm writing a everything-to-unicode-and-back library for Perl 5
right now.
> > "No UTF32 for you!" - Perl Nazi.
>
> Yeah, but the problem with that is that for each additional encoding
> scheme, perl needs to have some conversion to the other encodings so it
> can do reasonable comaprisons and suchlike things.
I don't see why. I don't think we should be dealing with *multiple* internal
encodings. That would be Bad and Wrong.
Simon
--
Oh my god! They killed Kennedy!
-- edfromo
