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. I think this is at least in part because the basic Int type is only defined to have a range greater than [-2^29 .. 2^29-1] and nothing more prescriptive. I think this was to do with issues of portability and garbage collection not wanting to look up types at runtime and reserving a bit or two helps here. 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. As data for the first point; is this going to be the largest issue when porting? I'd expect there to me many more serious assumptions made by the code than this! Other things to consider: How often are these types expected to be used? I'm not expecting it to be all that often. What about calling conventions and C macros? Are you expecting people to provide C wrappers for them? I can't seem to find any published paper exploring the choices the Haskell people made when designing its FFI. There's the "The Haskell 98 Foreign Function Interface"[1] but it's presented more as a user guide and not an exploration of the problem space. -- Sam http://samason.me.uk/ [1] http://www.cse.unsw.edu.au/~chak/haskell/ffi/ _______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
