[bitc-dev] C interfacing vs. portability

[Rick R]

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.