On Thu, Feb 26, 2009 at 7:05 PM, Rick R <[email protected]> wrote: > 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 you want to be notified, then a type alias is not what you want. The problem with using a type alias is precisely that you will *not* be notified. > 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. Everything is defined in terms of the core types either way. The issue here has to do with errors, portability, and diagnostics. >> 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? Yes. If we introduce typealias, it's a general mechanism, and we need to implement it generally. shap _______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
