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? Thanks, Maurício
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). Duncan
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).
Do you imagine a nice way to include that in hsc2hs or c2hs? (Also: inline functions are exactly like normal functions, except at compilation time. For those who just want to wrap a few functions, isn't it too much to require them to learn a tool just to use them?) Thanks, Maurício
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 :: ... where "capi" means the C API as opposed to the ABI, which is what ccall means. This expresses the meaning without saying anything about the implementation - implementations that compile via C might not need a separate wrapper, so something like 'foreign import ccall "cwrapper foo"' would be wrong. 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? Cheers, Simon
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?
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 :: ...
Under that syntax, how would GHC know where to find declaration/definition for a function? Since it's not, by hypothesis, on an object or library file, a C file will have to be compiled to get both the declaration and the definition. Thanks, Maurício
On 25/08/2009 13:45, 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?
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 :: ...
Under that syntax, how would GHC know where to find declaration/definition for a function? Since it's not, by hypothesis, on an object or library file, a C file will have to be compiled to get both the declaration and the definition.
Yes, absolutely. GHC will inject a C wrapper function into the _stub.c file, compile it, and then call the wrapper from Haskell. Cheers, Simon
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
Duncan Coutts wrote:
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.
Yes, it could be done in hsc2hs. I don't think the GHC build system or Cabal currently handles the _hsc.c stub files that hsc2hs produces (at least, if it does, I can't see where). That can be fixed, of course. So the reason I thought of adding it to GHC is because in a sense it's just another calling convention for the FFI to support. If it was done in hsc2hs then the syntax becomes heavier - you need both a foreign import and an hsc2hs directive of some kind, compared to just a foreign import. In c2hs the syntax could be lighter, but c2hs isn't widely available.
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)).
And the same would be true if it was done in GHC. The point I failed to make very well was that you don't get to declare the calling convention, so you rely on the header file supplying it. Of course, if you do this in hsc2hs you could pick some syntax to declare the calling convention. This is only a minor point.
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.
I'm thinking of this as all part of the same thing: a "function" that can be "called" from C code by writing f(arg1, arg2, ...). My 'foreign import capi' would let you call any of these, as would a hsc2hs extension. Ok, I don't really mind where it's implemented, especially if someone else does the work :-) For doing it in GHC: - lighter syntax - no extra build system or Cabal support necessary For doing it in hsc2hs: - multiple compilers get to take advantage Cheers, Simon
Can't hsc2hs already do this? #def char w_some_inline_function(char foo) { return some_inline_function(foo); } foreign import ccall "w_some_inline_function" some_inline_function :: CChar -> CChar I have certainly used this idiom on several occasions to work around the issue. John -- John Meacham - ⑆repetae.net⑆john⑈ - http://notanumber.net/
participants (4)
-
Duncan Coutts -
John Meacham -
Maurício CA -
Simon Marlow