--- Dan Sugalski <[EMAIL PROTECTED]> wrote:
> 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.
Mostly because it seems to be a requirement for intelligent
integer-preserving maths (cf. PERL_PRESERVE_IVUV in perl5).
> > > 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... :)
My question here is whether each supported platform is
going to need to provide its own overflow
detection/autoconversion decision routines, since the
portable part of perl6 will have now idea how far it can go
with native numbers.
> > > 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)
But why is perl6 messing with them, since it has no idea
what they mean?
> > > 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.
The only issue is that the CRTL's versions may be in
hand-tuned assembler, and perl6 will be doing a _lot_ of
strlen()s, I expect. But with good compilers, I suppose,
its an open question on how much performance one really
gains from hand assembly.
-- BKS
__________________________________________________
Do You Yahoo!?
Yahoo! Shopping - Thousands of Stores. Millions of Products.
http://shopping.yahoo.com/
