On Thursday, November 7, 2002, at 06:36 AM, Austin Hastings wrote:
Right. So it's a question of having a little extra storage (at least 1 bit, somewhere, for each "undef"), but more importantly a question of whether or not there are "primitive" types that circumvent that check. From A2 we have:For 'bit', the key value is (eenie, meenie, ...) '1'. Any '1' value will trigger a search for undef bit values. Presuming that bit values will not frequently be undef, the search should be cheap and the storage requirements will be something on the order of
"Run-time properties really are associated with the object in question, which implies some amount of overhead. For that reason, intrinsic data types like C<int> and C<num> may or may not allow run-time properties. In cases where it is allowed, the intrinsic type must generally be promoted to its corresponding object type (or wrapped in an object that delegates back to the original intrinsic for the actual value). But you really don't want to promote an array of a million bits to an array of a million objects just because you had the hankering to put a sticky note on one of those bits, so in those cases it's likely to be disallowed, or the bit is likely to be cloned instead of referenced, or some such thing."
If internals says that there's no runtime speed issue, that's awesome. I think we just have to be aware of one of our implied goals -- that Perl6 can be used for giant data-munging tasks without speed penalties so horrific as to send people to other languages.
MikeL
