On Thu, Feb 26, 2009 at 7:24 PM, Rick R <[email protected]> wrote: > Now that I think about it, if BitC disallows operations on mismatched > types, on x86 systems, (+ x:int32 y:word) should fail on both 32 and > 64 bit platforms, since a word is 16 bits.
Yes. That is what I claim to be the desired behavior. The problem with specifying word as a type alias is that the expression you give will compile on some, but not all, implementations. There is no alias that is correct in all cases. My view is that the compiler should flag this as an error on all platforms, especially so because the conversions may be information losing. Where information may be lost, a robust language design should certainly require the programmer to signal their awareness and intention that this is okay. In consequence, conversions should *never* be implicit. > I also find it entertaining that in C, int and long are the same > size... Where on earth did you get that idea? The only requirement of the standard is that type long must be able to represent all values of type int. It is a practical issue as well as a standardization issue. On some 64-bit platforms, int is 32 bit and long is 64 bit. > Going down this train of thought I think that trying to > correctly manage C's types is hopeless. Yes. Which seems like an excellent reason to keep them clearly separated from any sensibly defined range-constrained integer types. > I would be happy with BitC if it was simply internally correct. If I > dared venture down the path of associating with the unwashed masses of > C api's it would be my responsibility to ensure that all of the types > represented by that API are correctly aliased to BitC's for all > platforms I target. You wouldn't be happy, because this would preclude I/O. The problem with using type aliases as opposed to a separate collection of integral types is that there is absolutely no way to get 32-bit/64-bit portable code out of the result. That's exactly the issue that leads me to raise the question in the first place. shap _______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
