Re: PDD 4 To be a pain in the rumpus, I'm in need of some philosophical understandings.
Why is INTVAL one-size-fits-all for Perl? (I can think of two reasons right off the bat: it's always been that way, and it's simpler/easier to code and maintain (casting issues and the like). Currently, an INTVAL is a user-selected signed integer type, expected to be 32 or 64 bits wide. It's used in a variety of ways: - As an actual integer value. (1 + 1 = 2, sort of stuff.) - As a Parrot abstraction of a systemish value. (Pointer storage, length and sizes, etc.) - As a flag register. There's a couple of things about this that just don't gel in my mind. (And I had submittted a patch for this earlier, but it was violently ignored.) The first use makes sense for INTVAL. It's a number. There are few considerations. Sheer size comes to mind, as does efficiency. (64 bit operations in 32 bit/64 bit registers, for instance.) (It may be nice to have an unsigned version, though.) The second use is cause for potential problems. First off, the obvious case where there is a size differential. 32 bit INTVALs potentially trying to hold 64 bit values, for instance. It could be argued/coded to never exceed a 32 bit value, even in a 64 bit field (sizes and length come immediately to mind), but if that's going to be the case, why not simply make these sizes fixed, regardless of the size one wants to use for the first use? Secondly, there's often sign disparity between INTVAL and what it's being used to represent. PDD4 original had these things typed unsigned. That has been lost. Another cause for concern. The third use, well.... you can't exceed 32 bits without forking the code everywhere those bits are referenced. So all that these require is a simple unsigned 32 bit value. (On a 64 bit-only platform, the bottom 32 bits.) INTVALs are used everywhere. A lot. As 64 bit becomes more prevalent in the world, first case uses will be more evenly split between 32 and 64 bit size decisions, second case uses will lean more and more towards requiring 64 bit, and the last case uses will still remain fixed at 32 (or the minimum at more than 32). Memory is cheap and all, and it's not in Perl's nature to be frugal, but does Parrot need to be this wasteful, and potentially dangerous? What about (potential) languages other than Perl? Can someone clue me in, 'cause I really don't get it. -- Bryan C. Warnock [EMAIL PROTECTED]
