> I agree uint_32t is fairly arbitrary. The intrinsics actually return 'int' > but I make stronger guarantees than those functions do - several input > values give you an undefined result with the intrinsics. I prefer your > solutions in the order of 1 >> 2 == 3. That could just be the Ada > programmer in me though.
I'd be curious what others think as well (Michael?). I'd take any of 1, 2, or 3 over uint(32)-everywhere, simply because they seem more rationalizable. > The intrinsics themselves take unsigned ints, and one really shouldn't be > doing any bit twiddling on signed numbers anyways. I'd rather have the > user cast if they really want to than doing it under the covers. Can you provide some supporting arguments for "shouldn't be doing any bit twiddling on signed numbers" rather than dogma? Fleshing out my side: I think that early on we kicked around only supporting bitwise ops (&, |, ^) for unsigned integers out of some notion of "purity;" but in the end, it seemed artificial and non-productive for many common idioms to require that (in part due to the poor casting from uint(64)s to anything else), and I've never second-guessed that decision. Practically speaking, I don't see why it's more reasonable to support bit operators on uints rather than ints -- both are "logically" integer numbers rather than collections of bits, and both have straightforward bit representations that one might want to operate on and reason about (where I'll argue that floats don't and therefore aren't worthy of automatic bitwise ops). One could take the really high road, support a bitvector type, and only support bitwise operators on that. But again, I don't think that optimizes for usability/productivity (and users have said fairly strongly that they don't want to live in that world). So, given that we permit bit-oriented operations on ints in other contexts, it seems more consistent to me to do so here as well (and I'd rather do that than to get consistency by dropping bitwise ops for signed ints). But maybe you've got an argument I'm not anticipating up your sleeve. >> * Do we fold param select statements in the compiler? > > Yes. Oh good! >> * I also feel nervous about the "assumes..." comments in the .h file. > > You'd be a little hard pressed to find a platform where this isn't true > anymore. I'd bet many more things will break if int's are not 32 bits. I > had just put it in there more as a mention that the builtins take 'int' > and 'long long' rather than the guarantees of int32_t or int64_t. If that's what the builtins take, it seems preferable (and, I think, more consistent with what we do elsewhere) to have the extern declarations in BitOps.chpl (and their definitions in chpl-bitops.h) take C types in order to push any coercion/type size mismatch questions into the Chapel source base rather than in the C code. (Given that Michael reviewed this, I'm curious for his thoughts since he's written a lot of code like this and, I think, has taken a similar approach to the above). Thanks, -Brad ------------------------------------------------------------------------------ "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available Simple to use. Nothing to install. Get started now for free." http://p.sf.net/sfu/SauceLabs _______________________________________________ Chapel-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/chapel-developers
