At 11:51 AM 8/15/00 +0900, Simon Cozens wrote:
>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.
That's fine. It ought to be fully switchable at runtime anyway, so it's
only a default.
> > 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.
If you want, sure.
> > 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?
Strict ANSI really loathes the SV structure in perl 5 too.
> > > "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.
Why not? We're going to have two already, binary and UTF-something, and if
we provide an option for UTF-8, -16, and -32 we're going to need the code
*anyway*, so what's wrong with having them all available?
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
