[bitc-dev] C interfacing vs. portability

[Jonathan S. Shapiro]

On Thu, Feb 26, 2009 at 12:20 PM, Sam Mason <sam at samason.me.uk> wrote:
> On Thu, Feb 26, 2009 at 09:55:09AM -0500, Jonathan S. Shapiro wrote:
>> In abstract, there seem to be two ways to handle this:
>>
>> 1. Have a module that defines *aliases* for c_int, c_long, c_short, etc.
>> 2. Introduce c_int and friends as first-class integer types that are
>> *distinct from* the BitC types, but also define conversion functions
>> and arithmetic operations over these types.
>
> As always I seem to go back to Haskell, it's got a similar type system
> and the best FFI I've used to solve real problems, and it does the
> second option.

This is where I am currently leaning.

> The FFI types are
> also hidden away in the "Foreign.C.Types" module, which will tend
> to encourage people to use more appropriately defined and generally
> available types in their code.

This as well.

>  How often are these types expected to be used?  I'm not expecting it
>  to be all that often.

Unfortunately this depends on which libraries you are interfacing with.

>  What about calling conventions and C macros?  Are you expecting people
>  to provide C wrappers for them?

The BitC calling convention is exactly the same as C (by design). C
macros are obviously not supported, and I have no plans to do so.


shap