[bitc-dev] C interfacing vs. portability
Jonathan S. Shapiro
shap at eros-os.com
Thu Feb 26 21:19:58 EST 2009
On Thu, Feb 26, 2009 at 7:05 PM, Rick R <rick.richardson at gmail.com> 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*
> 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
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.
More information about the bitc-dev