[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*
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


More information about the bitc-dev mailing list