On Friday, November 15, 2002, at 01:10 AM, Dave Whipp wrote:
I still don't understand why we want to go to all this hassle ofIt depends on how much we want to encourage use of the "C-level" primitive types. The primary reason for having those types would obviously be to be able to map easily to and from C libraries, but a secondary reason would be to allow Perl to act as a lower-level language than it currently does (when you're trying for efficiency or specific low-level behaviors). So if you *knew* you were dealing with 16-bit unsigned integers, you could say
completing a vast list primitives to support mappings onto languages and architectures that have yet to be invented. I still prefer to keep things simple:
my Number $a is ctype("unsigned long int") = 42;
my Number $b is ctype("my_int32") = 42;
my uint16 @numarray;
and it would generate the optimal code for such an array. You could instead say:
my Int @numarray is ctype("unsigned short int");
.... but that's obviously more work, and we still have to support all possible combinations of unsigned/long/short/int/etc.
So the decision, I think, is whether or not using such types should be encouraged, or discouraged. I'd actually like to encourage them, for expert users: using primitive types when you want fast, primitive behaviors.
(One of my own "broad goals" is to see Perl be a valid choice for things like gif/jpeg manipulation -- not as fast as C, but not crippled either -- and other binary data. I think having enough builtin types to mirror the C types would make that goal more explicit.)
?
MikeL
