On Tue, 2009-08-25 at 13:18 +0100, Simon Marlow wrote:
On 23/08/2009 20:34, Duncan Coutts wrote:
On Sun, 2009-08-23 at 15:09 -0300, Maurício CA wrote:
I understand we can't use 'foreign import ccall' to wrap inline C functions. Do you think it could be possible to have an option in cabal to generate such functions in an object file when #included in a C file, in a compiler independent, portable way?
It might be better to include this feature into hsc2hs and/or c2hs (which may in turn require some help from Cabal).
I think it would be easy to do in GHC. We already have the machinery to generate the _stub.c files and compile them.
The main question is what the syntax should look like. I was toying with
foreign import capi "foo" foo :: ...
While maybe it can be done in ghc, is that the best place to put it? Do we do so without extending the FFI spec? The advantage of using something like hsc2hs is that we can still compile the same code in hugs, nhc, jhc and uhc.
I wonder whether not being able to specify the actual calling convention will be a problem, however. We are relying on the calling convention of foo being implicit. Are there cases where this might cause a problem?
If we do it via hsc2hs or c2hs then there's no need to specify any calling convention. We just get the one declared in the header files. This means we can handle stdcall, ccall and even crazy platform-specific variations like __attribute__((regparam, 3)). A generalisation of this is needed for calling "functions" defined by macros, and C varargs functions. A similar case, that is not fully automatic, is cases like binding functions that pass C structures by value. The "C structs by value" problem is already on the IHG wishlist. Both hsc2hs and c2hs support a way of outputting extra C snippets and binding to them, though there are some limitations. Currently Cabal does not support this feature in hsc2hs and the limitation in c2hs is that one can only add extra C snippets to the header, not to something that goes into a .c file to be compiled. So, I think we should consider making these kinds of use cases easy via c2hs and hsc2hs (and Cabal). Duncan