At 10:31 AM 3/2/2001 -0800, Hong Zhang wrote:
> > Integer data types are generically referred to as C<INT>s. There is an
> > C<INT> typedef that is guaranteed to hold any integer type.
>
>Does such thing exist? Unless it is BIGINT.
I'm confused here, looks like you're missing some words from those sentences.
The intention is that if you need to deal with integers in an abstract way,
you'll use a variable of type INT. That way if you get handed an IV or a
bigint pointer, both will fit fine.
> > Should we scrap the buffer pointer and just tack the buffer on the end
> > of the structure? Saves a level of indirection, but means if we need
> > to make the buffer bigger we have to adjust anything pointing to it.
>
>It largely depends on whether these primitive types are mutable or
>immutable. Most languages chose immutable, such as Python or Smalltalk.
>I assume Perl will choose mutable semantics.
I think we're going with mutable, as it's pretty much standard perl stuff.
I don't mind bounded bigint/bignums, in which case we'd need a bounds field
in there. We could presumably replace the buffer pointer with it and thus
not make the struct any bigger. That might not be a bad idea anyway, since
we could allocate some extra space to avoid constant resizing.
> > Floating point data types are generically reffered to as
> > C<NUM>s. There is a C<NUM> typedef that is guaranteed to hold any
> > floating point data type.
>
>Can you clarify this? The __float80 on x86 has very bad alignment,
>and not all compilers support it.
I was unclear--I meant that the NUM type will be big enough to hold an NV
or a bignum pointer. Presumably we'll have only one platform-native float
type supported.
> > =item BINARY (0)
> >
> > =item ASCII (1)
> >
> > =item EBCDIC (2)
> >
> > =item UTF_8 (3)
> >
> > =item UTF_32 (4)
> >
> > =item NATIVE_1 (5) through NATIVE_3 (7)
>
>Why not to include UTF-16?
I'm waffling on officially supporting it internally more than anything
else. It's just one more encoding to have to deal with, and I don't see it
buying much with both UTF-8 and UTF-32 in there.
On the other hand, if UTF-16 is in wide use in some segments of the world
(and I don't know if it is) it would probably be worth the extra code.
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
