After thinking through portability problems I've had in the past, I think option one as you describe it best, provided that those modules are per-platform . ... > (+ x:int32 y:word) > > will compile on a 32-bit platform but not on a 64-bit platform.
I would think that this would be expected operation. I would like to be notified when I inadvertently mix paradigms as such. Since that is almost always the cause of overflow/misalignment problems. If "word" is a type in its own right, the compiler will complain about > this usage. This is why we made word a distinct type for vector sizes. > I think it should be aliased. I don't see why everything shouldn't be defined in terms of BitC's core types. It means that there will have to be a module specific to each platform, but that's minor compared to everything else that must be done to ensure portability between platforms. > > Introducing typealias raises some challenges related to name spaces. > These challenges are surmountable, but I'm really trying not to make > major language changes at this point. Adding new types for things like > c_int is very easy. So would it be wrong to put them in (something like)Prelude with the option to hide them if the user wished to override for some reason? I think aliasing word et all to the local platform int# is a great compromise between performance and portability. Adding the rest of the oddball type aliases that people have come up with will be a job for the user of that C module. _______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
