On Thu, Feb 26, 2009 at 12:20 PM, Sam Mason <[email protected]> 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 _______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
