Hi, I was reading the RFC list, and I noticed this one. I haven't seen any discussion about it, so I wanted to say: 1. I fully agree that it is needed -- signed/unsigned integer support is sadly lacking in Perl5 2. When an implementation method is chosen, we should ensure that is extensible to cover other types other than signed and unsigned. I am particulary interested in saturated and unsaturated types. Though these are usually implemented as assembler ops that operate on standard integers, it would be more generally usable to have them asserted in the type: thus enabling saturation in the expression $c = $a + $b. Of course, the DSP-like instruction sets that support satuation usually also support thinks like packed arithmetic and other SIMD features: implementing support for these may be more interesting) More generally, I feel that the proposed declaration mechanism (extending the use Integer pragma) with block scope is too limited. I may wish to mix some types. They should either give the illusion of being first class objects (thus created as any other object), or a syntax like "my satInt32 ($a, $b)" (If this is abmiguous, then syntactic sugar might be needed). My feeling is that "use Integer" should continue to mean "use native integer operations", but that perl should define its own family of integer types which have guarenteed behaviors on all implementations. Obviously some overlap would be convenient. A final addition: "wouldn't it be nice..." if I could tell my integers to throw exceptions when they overflow. I don't ask for any of these features in the core language: I just want to be sure we can add them later. Dave. -- Dave Whipp, Senior Verification Engineer, Fast-Chip inc., 950 Kifer Rd, Sunnyvale, CA. 94086 tel: 408 523 8071; http://www.fast-chip.com Opinions my own; statements of fact may be in error.
