Taking this to p6i, in order to get Parroty for a few.... On Thu, 2004-09-02 at 19:47, Larry Wall wrote: > =head1 Overview > > This synopsis summarizes the non-existent Apocalypse 9, which > discussed in detail the design of Perl 6 data structures.
[...] > =head1 Sized types > > Sized low-level types are named most generally by appending the number > of bits to a generic low-level type name: > > int1 > int2 > int4 > int8 > int16 > int32 (aka int on 32-bit machines) > int64 (aka int on 64-bit machines) Ok, so Parrot doesn't have those. Parrot has "int". Presumably this means that when the high-level language programmer (Perl 6 here, but that's just an example) tries to get "lower level" by explicitly using a sized type, they're going to have to be working in a PMC of some type like PerlInt16, which (for reasons of overflow behavior and a few other things) can almost never be optimized down into an integer register. It seems to me that this causes a dilema for high-level languages where providing to the user what appears to be finer grained control over implementation actually makes them work at a higher level of abstraction. How would Parrot expect languages to implement such features? Should there be a set of (highly JIT-optimizable) PMCs that present sized type features, should the core register types be sizable somehow or should languages just be left to roll their own PMCs that do whatever they want? -- Aaron Sherman <[EMAIL PROTECTED]> Senior Systems Engineer and Toolsmith "It's the sound of a satellite saying, 'get me down!'" -Shriekback
