At 08:02 AM 12/26/00 -0800, Benjamin Stuhl wrote:
>Thus spake the illustrious Dan Sugalski <[EMAIL PROTECTED]>:
> > For integers, we have two types, platform native, and
> > bigint. No guarantees
> > are made as to the size of a native int. bigints can be
> > of any size.
>
>I'm not sure about the wisdom of not making any guarrantees
>about int size, since that means that extensions have to go
>through the same hoops perl5 has, dealing with
>"unspecified" behaviors (cf. fun with ANSI stdio). To make
>life easy, we might want to ordain sizeof(p6int) >=
>sizeof(void *) && sizeof(p6int) >= 4.
Perl will (well, should at least) automagically upgrade to bigints if a
regular int overflows (Assuming that conversion's not been forbidden by a
particular variable), so that's not going to be an issue inside variables.
As for types presented to extensions, we can certainly provide I8, I16,
I32, and friends.
>On the other hand,
>this makes a port of the PVM to Palms and the like somewhat
>harder (but would it be much easier to wedge them into the
>standard PVM?). Also, can we please mandate 2s-complement
>integral math? Perl 5 really always has, but can we please
>make it official?
Why? For variables, math is math--2+2=4 regardless of whether you're one or
two's complement, or BCD-encoded, or use the EBCDIC signed characters,
or... Mandating representations seems rather too low-level to me, though if
you've got a good argument I'm OK with it.
> > For floats, we also have two types, C double and
> > bigfloat. No guarantees to
> > the size or accuracy of the double. bigfloats can be of
> > any size.
>
>Floating point is even harder, and will require a lot of
>build-time checks anyway.
The big issue I have with floats is that bigfloats will be more precise
than regular floats/doubles, and so downconverting will lose data, which I
don't like. Other than that, because floats should autoconvert like ints, I
don't see any problem. (Not to say there isn't one, just that I don't see
it... :)
> > Strings can be of three types--binary data, platform
> > native, and UTF-32.
>
>"platform native"?
ASCII, EBCDIC, 16-bit chars, whatever. I'd rather not deal with
variable-length characters at all, so things like UTF-8 and friends aren't
really on the list. (Though they could be with the regex engine dealing
with them in UTF-32 format)
> > No, we are not messing around with UTF-8 or 16, nor are
> > we messing with
> > EBCDIC, shift-JIS, or any of that stuff. Strings can be
> > stored internally
> > that way (and the native form might be one of them) but
> > as far as the
> > interface is concerned we have only three. Yes, this does
> > mean if we mess
> > with strings in UTF-8 format on a non-UTF-8 system
> > they'll need to be fed
> > out in UTF-32. It's bigger, but we can deal.
>
>The issue with UTF-32 is that we'd need to write an entire
>string-handling library, while quite a few modern platforms
>have _wstr* or equivalent.
I'm not sure there's much in the way of string handling that we need to do
that's not perl-specific. It's also not all that much work anyway and,
while it is stuff we'll need to do, the benefits seem worth it.
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
