On Thursday, January 30, 2003, at 12:03 AM, Leopold Toetsch wrote:
Why do you then use a primitive type in the first place?
IMHO:
1) primitive types are what they are - no undef, no attributes, just e.g. plain integers (or shorts or bits ...)
2) if you want to store additional information use a "normal" perl variable i.e. a parrot PMC.
Why on earth would we want to take advantage of primitive types - when then people additionally want to tuck their birthdate on it?
The array of 1e6 ints takes 1e6 words, the same array of PerlInts allocates ~10 times the memory and causes additional a lot of GC overhead.
And finally, if you a need a few more bits of information for your IntArray[1e6], then wrap it into your own array class - we are speaking of perl here - or do we?
I think this is a tremendously valuable point. The idea behind primitive types is that they are "small" and "fast" compared to full types. If you ask for them, you are explicitly saying you're willing to give up a lot of functionality in order to gain maximum efficiency.
It's not that we want to avoid making Perl6 too slow. It's that we want to actively try and make it *fast*. When dealing with primitive types -- for large image manipulation, for example -- every spent clock cycle matters. We MUST allow some mechanism in Perl6 -- short of escaping to C -- by which algorithms can be tweaked to have some degree of efficiency.
This is leading me to the conclusion that primitive-typed arrays should not be allowed to have defaults, period, and that attempting to place one should be a compile-time error. If you want a default, use C<Int> instead of an C<int>, and it will work fine.
MikeL
