[bitc-dev] C interfacing vs. portability
sam at samason.me.uk
Thu Feb 26 19:32:56 EST 2009
On Thu, Feb 26, 2009 at 04:50:33PM -0500, Jonathan S. Shapiro wrote:
> On Thu, Feb 26, 2009 at 12:20 PM, Sam Mason <sam at samason.me.uk> wrote:
> > 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.
I was wondering how "thin" the wrappers around foreign code is likely to
be. For example, it would seem to make sense to wrap the pwrite(2) call
in something like:
(define (pwrite fd:int32 vec:(vector 't) offset:uint64)
(let ((n (vector-length vec))
(s (sizeof(vector-nth vec 0)))
(p (unsafe#vector-get-buf vec)))
(cast (pwrite64_c (cast fd) p (cast (n * s)) (cast offset))):int64))
That way, the real implementation of pwrite with all its C-types can
stay hidden away and it doesn't matter if the foreign types are a bit
more awkward to refer to.
Garg, I think I've just realized what you were meaning. Yes, it does
depend. You can probably ignore the above, except to confirm that I
still don't really understand BitC as the above took me about 20 minutes
to write and I failed to figure out how to convert between values of
differing integral type. "cast" seems wrong as you can't, in general,
cast between values of different type, but I hope the intent's obvious.
> > 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.
Lots of existing code assumes you're going to be using a C compiler
to access it and hence various functionality will only be accessible
through macros and other nastiness. Haskell's FFI works around this by
expecting the user to provide an object wrapping these in something more
useful. I can't see anything else being as general. Is that betterer?
More information about the bitc-dev