On Thu, Feb 26, 2009 at 12:58 PM, Rodrigo Kumpera <[email protected]> wrote: > Won't it work if any (int32, native int) op results always in native int? > Since this is to provide bindings I would expect that all most uses are > typed or directly inferable.
It won't work. The first problem I have already mentioned: explosion of overloadings. Your proposal would require 8^3 overloadings of +, 8^3 overloadings of -, and so forth. The number of required implementations is not actually the bad part. The bad part is that the type inference engine needs to test every one of those overloadings when attempting to infer types. Worse, every instantiation introduced in the prelude needs to be tested against all previous instantiations to ensure non-collision in the current language specification. This requires 256! (yes, factorial) checks **per operator**. Early versions of BitC specified the arithmetic class this way, and we very quickly abandoned this approach. Compiling the prelude alone took several minutes. > But you know more about the type inference problem that I do. Opting > to have BitC aliases to C types will just make programs as portable > as the underlying C library. A library that explicitly mix int and long, for > example, is by design non trivially portable. It's actually worse than that. Things that in C will compile (incorrectly, but successfully) because of implicit widening and truncation will not compile in BitC at all. This is why I'm contemplating a parallel integer type system c_byte c_short c_int, c_long, where c_int and int32 are distinct integer types even when they turn out to be the same size, and we define sign/zero extend and truncate operations to convert between them. > Yes, I've never worked on critical systems. My experience is based on how > bindings works on the CLR, which work quite well. The problem for CLR is a little bit different. Most CLR languages implement implicit integer size promotions if they have more than one integer size. I don't think that we can do that. CLR can also use native methods, which bypass the type system at this level. Let's look at a concrete example: what does CLR specify as the return type of the open() system call, and if it is not "int" then where and how is that return type defined? shap _______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
