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